goal-supervisor

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:

``json { "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
  ambiguous, the mission charter is internally inconsistent, the
  success condition isn't observable from the artifacts, or you've
  hit a constraint that requires human judgment. Explain in 3-5
  sentences exactly what decision needs human input.

Output ONCE. Pre-think before writing. Do not self-correct mid-response.

Respond in this exact format:

VERDICT: proceed
or
VERDICT: done
or
VERDICT: escalate

REASONING:
<3-8 sentences explaining what the prior goal produced, what it tells
you about mission progress, and why this verdict>

NEXT_OBJECTIVE: (only if proceed — single sentence, will be passed to /goal-prep)

DONE_EVIDENCE: (only if done — bulleted list of mission success-condition
items, each with the specific prior-goal artifact that satisfies it)

ESCALATION: (only if escalate — exactly what human input is needed and why)

Step 4 — apply the verdict

Read the subagent's structured response. Then:

PROCEED

1. Append to .claude/mission-log.md:

`` ## <ISO8601> — supervisor verdict: proceed Prior goal: <prior-slug> Reasoning: <from REASONING block> Proposed next objective: <from NEXT_OBJECTIVE> ``

1. Append to mission.json.supervisor_verdicts:

``json {"at": "<ISO8601>", "prior_slug": "<prior-slug>", "verdict": "proceed", "next_objective": "<...>"} ``

1. Append to mission.json.goals_completed:

``json {"slug": "<prior-slug>", "result": "<approved|cleared|...>", "rejection_count": <n>} ``

1. Hand off to /goalkeeper:goal-prep with the proposed next-objective as the rough idea. The user reviews and approves/edits the drafted contract per the standard prep flow. Do NOT auto-activate — the user-review checkpoint at prep is the human-in-the-loop safety property and stays mandatory in v0.2.
2. Tell the user: "Supervisor verdict: PROCEED. Drafting next goal: <objective>. Review the contract before activating."

DONE

1. Append to .claude/mission-log.md:

`` ## <ISO8601> — supervisor verdict: done Mission: <mission name> Reasoning: <from REASONING block> Evidence: <from DONE_EVIDENCE block> ``

1. Update mission.json:

``json { "status": "done", "completed_at": "<ISO8601>", "goals_completed": [...append final...] } ``

1. Write .claude/mission-completed.md — a final snapshot with the verdict text, every prior goal's slug + result, total elapsed time, and a copy of the original mission.md for posterity.
2. Tell the us