Goal Contract

Triggers automatically when relevant; invoke directly with /goal-contract or ask, e.g. "define done before we start".

Plan backward from the goal, never forward from the first step. A step that serves no check is speculative work; a check without a command is an opinion.

Step 1 — Derive the contract

GOAL:   <one sentence, in the user's words>
PROOFS: <observable facts that will exist if and only if the goal is met>
CHECKS: <one runnable command or action per proof>
STEPS:  <minimal work to make each check pass>
        format: N. <step> → check: <command>

Derive proofs from the goal, checks from proofs, steps from checks — in that order. Working forward ("what do I do first?") produces plausible activity; working backward produces verifiable progress.

Step 2 — Strength test

Ask: could another agent, given ONLY the CHECKS list, decide alone whether the work is done? If not, the checks are too weak — "works", "looks good", "is clean" are adjectives, not checks. Rewrite until the answer is yes. Strong checks are what make autonomous execution safe; weak checks force constant clarifying questions.

Step 3 — Surface invariants

List project rules the steps could silently violate (auth boundaries, data model separations, vocabulary distinctions, fail-closed security rules). Add one check per invariant at risk. Most damage from capable models comes from confidently violating an invariant nobody restated.

Step 4 — Lock and prune

Checks are now locked: weakening or dropping a failing check later requires an explicit statement of why THAT CHECK was wrong — never a silent change. Delete any step that serves no check. If a step feels necessary but has no check, either invent the check or admit the step is speculative.

Anti-patterns

• ✗ Writing code before the contract exists.
• ✗ Checks phrased as adjectives ("robust", "clean", "works").
• ✗ Asking the user how to verify — derive checks yourself, state assumptions.
• ✗ A 10-step plan where 4 steps serve no check.

Relationship to other skills

• universal-loop executes this contract: its Step 1 consumes CHECKS as-is.
• recon-first runs before edits on unfamiliar code — the contract says what "done" is; recon establishes ground truth of what exists.
• brainstorming explores WHAT to build; this skill formalizes DONE for work already decided.