Writing goals

Turn a fuzzy task into a /goal condition that can be judged from the conversation transcript alone; the evaluator never runs commands at evaluation time. Refuse to write the condition until five components are concrete.

For /goal syntax, limits, and enablement, read the bundled reference for the host tool: Claude Code in references/claude-code-goal.md, Codex in references/codex-goal.md.

If the user passed an argument, treat it as their framing. Otherwise ask one sentence about the task. If the goal is a multi-module refactor, migration, or new feature and no plan.md exists, suggest the user produce one first, manually or via an installed planning skill (scan available skills by description; never invent names).

Grill these five, one focused structured question per round. Use your tool's structured-question mechanism if one is available; otherwise ask in prose with labeled (a)/(b)/(c)/Other options:

1. End state — one observable signal: test result, exit code, file/byte count, empty queue, lint clean.
2. Stated check — the exact CLI command + stdout pattern proving the end state from the transcript (e.g., pnpm test exits 0 with 0 failed in stdout). Reject answers that defer to model judgment ("Claude verifies", "the agent confirms"). Push for a concrete command whose stdout lands in the transcript. If the test runner is unclear, scan the project's manifest files and bias options to the user's ecosystem.
3. Constraints — scope fence (paths in/out), quality fence (no eslint-disable, no as any, no test deleted or skipped), process fence (one logical change per commit).
4. Disciplines — name installed skills the agent should follow throughout. Scan available skills for descriptions matching planning, test-first, diagnosis, pre-completion verification, or general hygiene; offer the matches by their actual installed names, filtered by goal type. Never invent skill names. If none match, "none" is fine.
5. Stopping budget — a hard ceiling on how long the goal can run, in whatever unit your tool exposes: "stop after 40 turns", "stop after 2 hours", or similar (defaults: 20 for short tasks, 40 for migrations). If your tool is turn-based, check whether resuming a session resets the counter. Many do.

Demand concrete answers verifiable from transcript output. Do not infer; ask.

For long goals (>10 turns), ask whether to maintain a per-turn progress log (e.g. progress.md appended and committed per turn, recording what changed and the stated-check result). This guards against context summarization in long sessions erasing the trail. Skip for short goals.

Write the goal document with: title, the /goal condition one-liner in a fenced block, plain-English goal, the user's answers, and a one-line invocation note. Save it to a path produced by mktemp -t goal-XXXXXX.md (read the file before you write to it).

Report the file path and the /goal <condition> in a fenced code block. Do not fire /goal; the user does.