/goal-prep
Interactively draft a goalkeeper contract before executing. Use this skill when the user invokes /goal-prep "<rough idea>", or when /goal is called for a slug that has no contract yet. Produces a well-formed contract.md with explicit objective, definition-of-done, validator
$ npx -y skills add bonfire-systems/goalkeeper --skill goal-prep --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/goal-prep
Context preview
The summary Claude sees to decide when to auto-load this skill.
Interactively draft a goalkeeper contract before executing. Use this skill when the user invokes /goal-prep "<rough idea>", or when /goal is called for a slug that has no contract yet. Produces a well-formed contract.md with explicit objective, definition-of-done, validator
SKILL.md
goal-prep.SKILL.mdname: goal-prep
description: Interactively draft a goalkeeper contract before executing. Use this skill when the user invokes /goal-prep "<rough idea>", or when /goal is called for a slug that has no contract yet. Produces a well-formed contract.md with explicit objective, definition-of-done, validator command, and non-goals.
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.
Read more
name: goal-prep description: Interactively draft a goalkeeper contract before executing. Use this skill when the user invokes /goal-prep "<rough idea>", or when /goal is called for a slug that has no contract yet. Produces a well-formed contract.md with explicit objective, definition-of-done, validator command, and non-goals.
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.
Durable contract-driven goal execution for Claude Code. A subagent judge gates completion against an explicit Definition of Done.
Repo: bonfire-systems/goalkeeper
Other skills on goalkeeper.
- /goal-chain
Run a linear sequence of goalkeeper goals where the judge gates progression between them. Use when the user invokes /goal-chain "<file>" to start a chain. Also auto-invoked by the judge skill on approval to advance the chain cursor.
Open skill - /goal-clear
Stop and archive the currently active goalkeeper goal. Use when the user invokes /goal-clear to abandon or finalize a goal. Files are moved to .claude/goals/_archive/, never deleted.
Open skill - /goal-judge
The gate. Reviews the active goalkeeper goal against its definition-of-done and either approves (advance / mark done) or rejects (with a structured fix-list). Auto-fired by the goal skill when the validator passes (inline mode), or invoked by the goal-chain orchestrator after
Open skill - /goal-pause
Pause the currently active goalkeeper goal without losing state. Use when the user invokes /goal-pause. The goal can later be resumed with /goal-resume.
Open skill - /goal-resume
Resume a paused or needs_human goalkeeper goal. Use when the user invokes /goal-resume after they've manually unblocked the goal (e.g. fixed a problem the judge flagged).
Open skill - /goal-supervisor
The mission-level supervisor. One level above goals. Reads the user's mission charter and the most-recently-completed goal's artifacts, then decides whether to PROCEED (draft + activate the next goal), declare the mission DONE, or ESCALATE to the user. Use this skill when the
Open skill

