Outcome Contract
Organize technical proposals and ambiguous requirements into problems, objectives, success and rejection criteria, and undecided choices that do not depend on technical terms. For formal handoff, create a Problem Frame and Context Packet.
The root of the authoritative package isproblem_framing_package.
Supported modes: design, review.
Reference Routing
- On the first occasion, read
skills/mino-core/references/shared-policies.mdand apply Evidence, approval, and judgment. If already read in the same context, do not read again. Ordinary judgments are made with the main body and these common rules. - When discovering the semantic boundaries of terms in detail, read
skills/mino-core/references/domain-discovery.mdand create examples, counterexamples, and differences in context. - If there are requirements for file/process/test execution on the target system or multiple OSes, read
skills/mino-core/references/platform-compatibility.mdand separate host, target, and verification layer. Do not load additional material merely to save a record of an answer. - Only when asked to create, update, or hand off the authoritative package, read
skills/mino-problem-framing/schemas/package.mdand preserve required fields and existing references.
Workflow
- Fix the actor, context, and scope to be decided this time from the original text, specifications, observations, code, and existing approvals. The document list is a set of search candidates, and do not wait for all documents to be submitted.
- Separate observation, evaluation, causal hypotheses, and candidate means. For existing failures or debt, investigate causality, and for undetermined causes, leave unknown and a confirmation procedure. For new capabilities, show demand Evidence and unmet capabilities, and do not create nonexistent false responsibilities or causes.
- Return technology to candidate_means, and connect concrete Evidence -> objective/loss -> success criteria -> rejection criteria -> verification. Stop abstraction at a height where candidates can be compared, and stop concretization at a depth where a third party can falsify it.
- Present alternative interpretations and falsification conditions only for terms and premises that branch the outcome. Compare stakeholders' expectations using concrete examples and counterexamples of the same input, and distinguish illustrative hypothetical examples from the basis of actual work.
- Leave statement, comparison_basis, proposed_status, and differences in the AI restatement. matched is a comparison proposal, not an approval. Apply the common rules to high-impact semantic matching and reuse of a confirmed baseline. Semantic matching does not substitute for human-owned adoption decisions.
- Place undecided choices in the Selection Gate with candidates, identifying Evidence, confirmation method, owner, and impact. Reflect additional instructions in the differences, and do not recreate observations or approvals that are still valid.
Hard Gates
- If the problem disappears when technical terms are removed, if there is no method to falsify an important premise, or if success and rejection criteria cannot be traced from Evidence, supplement them.
- Even if the semantic difference is mismatched / blocked, the current design / review that safely reports the difference can be completed. Stop only the dependent choices and implementation.
- The next deliverable indicates up to its type and obligation. Do not add uncreated model, contract, or test IDs, or changes to the target system.
Completion
If the purpose, meaning, success conditions, and necessary choices are all in place, subject_verdict is ready. If the options and confirmation conditions can be presented, it is conditional. If a safe problem statement itself cannot be created, it is blocked. Separate this from the current completion of the artifact, and do not claim problem resolution or implementation success.