/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
$ npx -y skills add bonfire-systems/goalkeeper --skill goal-supervisor --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-supervisor
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
goal-supervisor.SKILL.mdname: goal-supervisor
description: 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 user invokes /goal-supervisor after a goal completes, or when running a multi-goal arc where each next goal's shape is informed by the prior goal's actual output.
You are operating the **goal-supervisor** skill — the mission-level layer sitting one above individual goals. Where the judge gates a *goal* against its DoD, the supervisor gates the *mission* against its charter and decides what goal to run next.
Mental model
Mission ← .claude/mission.md (user-authored charter)
├─ Goal A (done, in _archive) ← goalkeeper contract — within-goal loop works
├─ Goal B (done, in _archive) ← drafted in response to A's output
└─ Goal … (drafted on demand by supervisor) ← what /goal-supervisor produces
The supervisor is **NOT** a chain. Chains commit to a linear sequence at chain-start. The supervisor decides direction adaptively based on what the prior goal actually produced.
When to invoke
- After a standalone goal completes (status `done` or `cleared`, active.json terminal-shape).
- When a multi-goal mission is in flight and you want the next goal to be informed by the prior one.
- NEVER while a goal is `active` — supervisor refuses if a goal is still running.
Inputs
- `.claude/mission.md` — the user-authored mission charter. **Required** — supervisor refuses without it.
- `.claude/active.json` — must be terminal-shape (no active goal).
- `.claude/mission.json` — supervisor state. May not exist on first invocation; supervisor initializes it.
- `.claude/mission-log.md` — append-only mission-level audit trail. May not exist on first invocation.
- The most-recently-ended goal's artifacts:
- `.claude/goals/_archive/<slug-with-timestamp>/log.md` (preferred, if cleared)
- or `.claude/goals/<slug>/log.md` (if done but not yet archived)
- and the same goal's `state.json` for verdict + rejection_count context
Mission charter (`mission.md`) — expected shape
The supervisor expects users to author `mission.md` with these sections. None are syntactically required (no JSON Schema), but all are strongly recommended:
# Mission: <name>
## Objective
<one-paragraph statement of the mission's high-level intent>
## Success condition
<concrete, observable condition for "mission done." Like a goal's definition_of_done
but at the mission level. Specific. Measurable.>
## Constraints
<bulleted list of hard rules. The supervisor will refuse to propose goals
that violate these.>
## Legal next-goal shapes
<bulleted catalog of the kinds of goals this mission may need. The supervisor
draws from this list when proposing next-objectives. Each entry: name +
1-sentence description.>
## Done is not
<bulleted list of things that look like progress but don't satisfy the
success condition — equivalent to a contract's non_goals at the mission level.>
Flow
Step 1 — pre-flight
1. Read `.claude/mission.md`. If missing, halt with: "Supervisor requires `.claude/mission.md`. See goal-supervisor skill docs for the expected shape." Do not proceed. 2. Read `.claude/active.json`. If `slug != null` AND the corresponding `state.json.status == "active"`, halt with: "Supervisor refuses while a goal is active. Pause or complete the current goal first." 3. Read `.claude/mission.json` if it exists; otherwise initialize:
{
"name": "<from mission.md heading>",
"status": "active",
"started_at": "<ISO8601 now>",
"goals_completed": [],
"supervisor_verdicts": []
}Step 2 — locate the prior goal
The most-recently-ended goal is the supervisor's primary input. In order of preference:
1. If `active.json.previous_slug` is non-null: that's the slug. 2. Else look in `.claude/goals/_archive/` for the most-recently-archived directory. 3. Else look in `.claude/goals/` for a directory whose `state.json.status == "done"` and isn't yet archived.
If no prior goal exists (first supervisor invocation on a new mission), the supervisor treats this as "the mission just started, no prior context — propose the first goal from `mission.md`'s `Legal next-goal shapes` section."
Step 3 — spawn the supervisor subagent
Use the Agent tool with `subagent_type: general-purpose`. Fresh context — supervisor must NOT inherit the executing agent's reasoning.
Pass a self-contained prompt with:
1. **The full `mission.md`** — verbatim. 2. **The prior goal's `log.md`** — verbatim. (May be long. If > 50KB, include the last 200 lines + activation entry + every "judge approved" and "judge rejected" block.) 3. **The prior goal's `state.json`** — verbatim. (Tells the supervisor whether the goal was approved, how many rejections, etc.) 4. **The current `mission.json.goals_completed`** — list of prior slug + brief result summary. 5. **A list of supervisor-relevant repo state**: `git rev-parse HEAD` at this moment, `git status --porcelain` (first 20 lines). 6. **The task** — verbatim, in this exact format:
You are the mission supervisor. The user's mission is described above.
One goal has just completed. Your job: decide what happens next.
You have three legal outputs:
PROCEED — the mission is still active and the next goal can be named.
Output a one-sentence objective for the next goal. Reference what the
prior goal produced and how it shapes this one. The objective will be
fed to /goalkeeper:goal-prep, which drafts a full contract from it.
DONE — the mission's success condition is satisfied. Cite the specific
evidence in the prior goal(s) that demonstrates each part of the
success condition.
ESCALATE — you cannot decide. Either the prior goal's output is
a
Read more
name: goal-supervisor description: 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 user invokes /goal-supervisor after a goal completes, or when running a multi-goal arc where each next goal's shape is informed by the prior goal's actual output.
You are operating the **goal-supervisor** skill — the mission-level layer sitting one above individual goals. Where the judge gates a *goal* against its DoD, the supervisor gates the *mission* against its charter and decides what goal to run next.
Mental model
Mission ← .claude/mission.md (user-authored charter) ├─ Goal A (done, in _archive) ← goalkeeper contract — within-goal loop works ├─ Goal B (done, in _archive) ← drafted in response to A's output └─ Goal … (drafted on demand by supervisor) ← what /goal-supervisor produces
The supervisor is **NOT** a chain. Chains commit to a linear sequence at chain-start. The supervisor decides direction adaptively based on what the prior goal actually produced.
When to invoke
- After a standalone goal completes (status `done` or `cleared`, active.json terminal-shape).
- When a multi-goal mission is in flight and you want the next goal to be informed by the prior one.
- NEVER while a goal is `active` — supervisor refuses if a goal is still running.
Inputs
- `.claude/mission.md` — the user-authored mission charter. **Required** — supervisor refuses without it.
- `.claude/active.json` — must be terminal-shape (no active goal).
- `.claude/mission.json` — supervisor state. May not exist on first invocation; supervisor initializes it.
- `.claude/mission-log.md` — append-only mission-level audit trail. May not exist on first invocation.
- The most-recently-ended goal's artifacts:
- `.claude/goals/_archive/<slug-with-timestamp>/log.md` (preferred, if cleared)
- or `.claude/goals/<slug>/log.md` (if done but not yet archived)
- and the same goal's `state.json` for verdict + rejection_count context
Mission charter (`mission.md`) — expected shape
The supervisor expects users to author `mission.md` with these sections. None are syntactically required (no JSON Schema), but all are strongly recommended:
# Mission: <name> ## Objective <one-paragraph statement of the mission's high-level intent> ## Success condition <concrete, observable condition for "mission done." Like a goal's definition_of_done but at the mission level. Specific. Measurable.> ## Constraints <bulleted list of hard rules. The supervisor will refuse to propose goals that violate these.> ## Legal next-goal shapes <bulleted catalog of the kinds of goals this mission may need. The supervisor draws from this list when proposing next-objectives. Each entry: name + 1-sentence description.> ## Done is not <bulleted list of things that look like progress but don't satisfy the success condition — equivalent to a contract's non_goals at the mission level.>
Flow
Step 1 — pre-flight
1. Read `.claude/mission.md`. If missing, halt with: "Supervisor requires `.claude/mission.md`. See goal-supervisor skill docs for the expected shape." Do not proceed. 2. Read `.claude/active.json`. If `slug != null` AND the corresponding `state.json.status == "active"`, halt with: "Supervisor refuses while a goal is active. Pause or complete the current goal first." 3. Read `.claude/mission.json` if it exists; otherwise initialize:
{
"name": "<from mission.md heading>",
"status": "active",
"started_at": "<ISO8601 now>",
"goals_completed": [],
"supervisor_verdicts": []
}Step 2 — locate the prior goal
The most-recently-ended goal is the supervisor's primary input. In order of preference:
1. If `active.json.previous_slug` is non-null: that's the slug. 2. Else look in `.claude/goals/_archive/` for the most-recently-archived directory. 3. Else look in `.claude/goals/` for a directory whose `state.json.status == "done"` and isn't yet archived.
If no prior goal exists (first supervisor invocation on a new mission), the supervisor treats this as "the mission just started, no prior context — propose the first goal from `mission.md`'s `Legal next-goal shapes` section."
Step 3 — spawn the supervisor subagent
Use the Agent tool with `subagent_type: general-purpose`. Fresh context — supervisor must NOT inherit the executing agent's reasoning.
Pass a self-contained prompt with:
1. **The full `mission.md`** — verbatim. 2. **The prior goal's `log.md`** — verbatim. (May be long. If > 50KB, include the last 200 lines + activation entry + every "judge approved" and "judge rejected" block.) 3. **The prior goal's `state.json`** — verbatim. (Tells the supervisor whether the goal was approved, how many rejections, etc.) 4. **The current `mission.json.goals_completed`** — list of prior slug + brief result summary. 5. **A list of supervisor-relevant repo state**: `git rev-parse HEAD` at this moment, `git status --porcelain` (first 20 lines). 6. **The task** — verbatim, in this exact format:
You are the mission supervisor. The user's mission is described above. One goal has just completed. Your job: decide what happens next. You have three legal outputs: PROCEED — the mission is still active and the next goal can be named. Output a one-sentence objective for the next goal. Reference what the prior goal produced and how it shapes this one. The objective will be fed to /goalkeeper:goal-prep, which drafts a full contract from it. DONE — the mission's success condition is satisfied. Cite the specific evidence in the prior goal(s) that demonstrates each part of the success condition. ESCALATE — you cannot decide. Either the prior goal's output is a
Showing the first part of this file.
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-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
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

