goal-prep

You are operating the goal-prep skill. Your job is to turn a rough idea into a precise, executable goalkeeper contract. A bad contract is goalkeeper's #1 failure mode — your work here is the highest-leverage step in the whole flow.

Inputs

• args (rough idea, may be empty)
• The current repo (you can read code, configs, docs)

Flow

1. Reconnaissance (read-only)

Before drafting anything, briefly survey the repo to ground the contract in reality:

• Detect language/framework: package.json, pyproject.toml, Cargo.toml, go.mod, *.csproj, etc.
• Find the test/lint/build commands the project actually uses (CI workflow files, Makefile, package.json scripts).
• Skim the README and any AGENTS.md / CLAUDE.md for project conventions.
• If the rough idea points to specific files or features, locate them.

Spend ~2–5 read-only tool calls here. Do not edit anything.

2. Draft the contract via interactive Q&A

Use AskUserQuestion to collect each field. Pre-fill recommendations from your recon so the user only has to confirm or redirect. Ask in this order:

1. Slug — propose a kebab-case slug; let user confirm or rename.
2. Objective — one sentence. If the rough idea is already crisp, just confirm. If vague, propose 2–3 sharper rewrites.
3. Non-goals — propose 2–4 things explicitly out of scope based on the recon (e.g. "don't change CI", "don't refactor src/"). Multi-select with edit.
4. Definition of Done — propose 3–6 measurable criteria. Mix qualitative ("no test files contain jest.") with quantitative ("≥20% test runtime improvement"). Multi-select with edit. DoD is what the judge checks — be specific, no fluff.
5. Validator command — propose the most relevant command(s) you found in recon (e.g. pnpm test && pnpm lint). Confirm or override.
6. Checkpoint cadence — propose default (every 5 file edits OR every 20 minutes). Confirm or override.
7. Max rejections — default 5. Confirm or override.
8. Judge mode — default subagent. Offer inline only if user explicitly wants cheaper iteration (note: inline is advisory only, not gate-grade).
9. Wakeup seconds — only ask if validator is unusually fast or slow. Otherwise let goal skill pick cache-aware default.

3. Write the contract file

Write .claude/goals/<slug>/contract.md with frontmatter from the answers above, plus a body containing:

• ## Context — 1–3 paragraphs grounding the work

• ## Files to know — bullet list of relevant paths from recon

• ## Constraints — anything the agent must NOT do that isn't already a non-goal

• ## Anti-placeholder rule — copy this verbatim:

  DO NOT stub, mock, skip, or .todo work to make the validator pass. If something cannot be done, surface it in the next checkpoint and stop. Skipped work is an automatic judge rejection.

4. Confirm and (optionally) activate

After writing, show the user the contract file path and the rendered frontmatter. Ask one final question via AskUserQuestion: "Activate this goal now?" with options:

• Yes, start now (Recommended) — hand off to the goal skill with the slug to begin execution.
• No, review first — print path and stop. User can /goal "<objective>" later to start.

If the user chose to start, immediately re-enter the goal skill set-mode flow at step 3 (skip prep since contract now exists).

Hard rules

• No silent defaults on DoD. Every DoD criterion must be confirmed by the user. The DoD is the judge's grading rubric — sloppiness here breaks everything downstream.

• Validator must be a real command that can be run in this repo right now. Don't propose make test if there's no Makefile. Run it once during prep to confirm it executes (not necessarily that it passes — just that it runs).

• Capture the baseline result. When you run the validator during prep, record:

  • exit code (0 → pass; non-zero → fail; command not found / crashed → not_runnable)
  • the list of file paths the validator reports as failing (parse from output; e.g. for ESLint, the paths that have errors; for vitest, the test files with failed assertions). Empty array on pass or when paths aren't extractable.

  Pass these to the goal skill's activation step so it can populate state.validator_baseline_result and state.validator_baseline_failing_paths. The judge uses these to distinguish goal-caused validator failures from pre-existing failures on files the goal never touched. This is the mechanism that lets a goal proceed when the validator is partly polluted by pre-existing debt — without it, every checkpoint fails for reasons unrelated to the work.

• Slug uniqueness: if .claude/goals/<slug>/ already exists, ask the user whether to overwrite or pick a new slug. Never silently overwrite.

• Don't write the contract until all questions are answered. Partial contracts are worse than no contract.