goal-builderlisted

# Goal Builder Helps a user write a Claude Code `/goal` condition that actually works, by interview. The deliverable is a ready-to-run `/goal …` line (and, when the pattern recurs, a reusable `.claude/commands/` command). Read `references/goal-mechanics.md` for how `/goal` works and `references/good-vs-bad-goals.md` for the worked examples. ## The one idea that makes or breaks a goal `/goal` keeps a Claude Code session looping across turns until a **separate evaluator** (a fresh, fast model — not the one doing the work) confirms your condition holds. The evaluator **only reads the transcript**: it does not run commands or open files. So the condition must be something Claude's own *printed output* can prove. That single fact is why people get `/goal` wrong: they write a **prompt** (open-ended, judged by a human) when `/goal` needs a **condition** (resolves to yes/no from the transcript). "Clean up my code" has no checkable finish line, so the loop either churns forever or quietly declares victory. "`npm test` exits 0" works, because Claude runs it and the result lands in the transcript for the evaluator to read. A durable condition (per Anthropic's docs) has three parts, and is bounded: 1. **A measurable end state** — a test result, a build exit code, a file count, an empty queue. 2. **A stated check** — how Claude should prove it (`npm test` exits 0, `git status` is clean). 3. **Constraints that must hold** — what must not change on the way there (and what would count