goal-loop

Goal Loop

A work-until-done goal does not mean "work until it feels done". It means: define what done is, work, then prove it. The failure mode this skill prevents is the claim-of-done, ending the loop because the work feels finished rather than because evidence says it is.

1. Derive acceptance criteria before working

Read the ask and derive 2 to 4 acceptance criteria from it. Each criterion must be checkable with evidence: a command whose output proves it, a file whose diff shows it, a request that returns the right thing. If you cannot name the command that verifies a criterion, it is not a criterion yet; rewrite it until you can. "Code is clean" fails this bar. "Linter exits 0" passes it.

Example, for "get the importer handling the new CSV format":

1. pytest tests/test_importer.py passes with zero failures
2. running the importer against samples/new-format.csv exits 0 and reports inserted rows greater than zero
3. the legacy format still imports cleanly (regression run against samples/legacy.csv)

2. Show the criteria, then work

Present the criteria to the user before starting. This costs one short message and buys two things: they can correct a wrong definition of done before you burn time on it, and the finish line cannot quietly move later. If they are silent or said "just go", proceed; the criteria still govern the loop.

Then work. Iterate as long as it takes. Failures along the way are loop input, not stopping points.

3. Verify every criterion with evidence

When you believe the work is done, run the verification for each criterion and show the evidence: the actual command output, the test summary line, the relevant file diff. "Done" backed by nothing is a claim, and claiming an action you did not take or a result you did not observe is the cardinal sin of this loop.

• A criterion is met when its evidence says so, not when the code looks right.
• Exit 0 alone is not verification if the criterion was about output; check the output.
• If a criterion fails verification, you are not done. Go back to work, do not soften the criterion to match the result.

Only when every criterion has passing evidence do you declare done, and the declaration is the evidence summary, one line per criterion.

4. Blocked means stop and say exactly what

If progress requires something only the user can provide (a credential, an account approval, access you do not have, a decision between two valid designs), stop and say exactly what you need, in one or two lines: "blocked: I need the staging database password, everything else is ready" beats an hour of guessing or a workaround that mutates something you should not touch. Name the blocker, name what unblocks it, state what is already done, and wait.

Do not invent fake progress around a blocker, and do not silently abandon a criterion because the blocker made it inconvenient.