Skip to content

/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

shell
$ npx -y skills add bonfire-systems/goalkeeper --skill goal-supervisor --agent claude-code

How 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
How auto-invocation works

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.md
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
Read more
Read it on GitHub ↗

Showing the first part of this file.

Ships withgoalkeeper

Durable contract-driven goal execution for Claude Code. A subagent judge gates completion against an explicit Definition of Done.

Get the whole plugin, auto-invoked
Stats
12
Stars
0
Views
2
Forks
Maintained
Maintenance
Python
Language
MIT
License
1mo ago
Last commit
2mo ago
Created

Repo: bonfire-systems/goalkeeper