nelson

Original source / Raw SKILL.md

---
name: nelson
description: Orchestrates multi-agent task execution using a Royal Navy squadron metaphor — from mission planning through parallel work coordination to stand-down. Use when work needs parallel agent orchestration, tight task coordination with quality gates, structured delegation with progress checkpoints, or a documented decision log.
argument-hint: "[mission description]"
---

# Nelson

Execute this workflow for the user's mission.

## 1. Issue Sailing Orders

- Review the user's brief for ambiguity. If the outcome, scope, or constraints are unclear, ask the user to clarify before drafting sailing orders.
- Write one sentence for `outcome`, `metric`, and `deadline`.
- Set constraints: token budget, reliability floor, compliance rules, and forbidden actions.
- Define what is out of scope.
- Define stop criteria and required handoff artifacts.

You MUST read `references/admiralty-templates/sailing-orders.md` and use the sailing-orders template when the user does not provide structure.

Example sailing orders summary:

```
Outcome: Refactor auth module to use JWT tokens
Metric: All 47 auth tests pass, no new dependencies
Deadline: This session
Constraints: Do not modify the public API surface
Out of scope: Migration script for existing sessions
```

**Session Hygiene:** Before forming the squadron, execute session hygiene per `references/damage-control/session-hygiene.md`. Clear stale damage reports and turnover briefs from any previous session. Skip this step when resuming an interrupted session.

## 2. Form The Squadron

- Brief captains on mission intent and constraints. Make the plan clear, invite questions early.
- Select one mode:
  - `single-session`: Use for sequential tasks, low complexity, or heavy same-file editing.
  - `subagents`: Use for parallel scouting or isolated tasks that report only to admiral.
  - `agent-team`: Use when independent agents must coordinate with each other directly.
- Set team size from mission complexity:
    - Default to `1 admiral + 3-6 captains`.
    - Add `1 red-cell navigator` for medium/high threat work.
    - Do not exceed 10 squadron-level agents (admiral, captains, red-cell navigator). Crew are additional.
    - Assign each captain a ship name from `references/crew-roles.md` matching task weight (frigate for general, destroyer for high-risk, patrol vessel for small, flagship for critical-path, submarine for research).
    - Captain decides crew composition per ship using the crew-or-direct decision tree in `references/crew-roles.md`.
    - Captains may also deploy Royal Marines during execution for short-lived sorties — see `references/royal-marines.md` and use `references/admiralty-templates/marine-deployment-brief.md` for the deployment brief.

Reference `references/squadron-composition.md` for selection rules and `references/crew-roles.md` for ship naming and crew composition. Consult the Standing Orders table below before forming the squadron.

## 3. Draft Battle Plan

- Split mission into independent tasks with clear deliverables.
- Assign owner for each task and explicit dependencies.
- Assign file ownership when implementation touches code.
- Keep one task in progress per agent unless the mission explicitly requires multitasking.
- For each captain's task, include a ship manifest. If crew are mustered, list crew roles with sub-tasks and sequence. If the captain implements directly (0 crew), note "Captain implements directly." If the captain anticipates needing marine support, note marine capacity in the ship manifest (max 2).

Reference `references/admiralty-templates/battle-plan.md` for the battle plan template and `references/admiralty-templates/ship-manifest.md` for the ship manifest. Consult the Standing Orders table below when assigning files or if scope is unclear.

**Before proceeding to Step 4:** Verify sailing orders exist, squadron is formed, and every task has an owner, deliverable, and action station tier.

**Crew Briefing:** Spawning and task assignment are two steps. First, spawn each captain with the `Agent` tool, including a crew briefing from `references/admiralty-templates/crew-briefing.md` in their prompt. Then create and assign work with `TaskCreate` + `TaskUpdate`. Teammates do NOT inherit the lead's conversation context — they start with a clean slate and need explicit mission context. See `references/tool-mapping.md` for full parameter details by mode.

**Turnover Briefs:** When a ship is relieved due to context exhaustion, it writes a turnover brief using `references/admiralty-templates/turnover-brief.md`. See `references/damage-control/relief-on-station.md` for the full procedure.

## 4. Run Quarterdeck Rhythm

- Keep admiral focused on coordination and unblock actions.
- The admiral sets the mood of the squadron. Acknowledge progress, recognise strong work, and maintain cheerfulness under pressure.
- Run a quarterdeck checkpoint after every 2-3 task completions, when a captain reports a blocker, or when a captain goes idle with unverified outputs:
    - Update progress by checking `TaskList` for task states: `pending`, `in_progress`, `completed`.
    - Identify blockers and choose a concrete next action.
    - Use `SendMessage` to unblock captains or redirect their approach.
    - Confirm each crew member has active sub-tasks; flag idle crew or role mismatches.
    - Check for active marine deployments; verify marines have returned and outputs are incorporated.
    - Clean up idle ships unless you believe they will continue their tasking. (E.g., Work has paused waiting on input from another ship.)
    - Track burn against token/time budget.
    - Check hull integrity: collect damage reports from all ships, update the squadron readiness board, and take action per `references/damage-control/hull-integrity.md`. The admiral must also check its own hull integrity at each checkpoint.
- Re-scope early when a task drifts from mission metric.
- When a mission encounters difficulties, consult the Damage Control table below for recovery and escalation procedures.

Example quarterdeck checkpoint:

```
Status: 3/5 tasks complete, 1 blocked, 1 in progress
Blocker: HMS Resolute waiting on API schema from HMS Swift
Action: Redirect HMS Swift to prioritise schema export
Budget: ~40% tokens consumed, on track
Hull: All ships green
```

Reference `references/tool-mapping.md` for coordination tools, `references/admiralty-templates/quarterdeck-report.md` for the report template, and `references/admiralty-templates/damage-report.md` for damage report format. Use `references/commendations.md` for recognition signals and graduated correction. Consult the Standing Orders table below if admiral is doing implementation or tasks are drifting from scope.

## 5. Set Action Stations

- You MUST read and apply station tiers from `references/action-stations.md`.
- Require verification evidence before marking tasks complete:
    - Test or validation output.
    - Failure modes and rollback notes.
    - Red-cell review for medium+ station tiers.
- Trigger quality checks on:
    - Task completion.
    - Agent idle with unverified outputs.
    - Before final synthesis.
- For crewed tasks, verify crew outputs align with role boundaries (consult `references/crew-roles.md` and the Standing Orders table below if role violations are detected).
- Marine deployments follow station-tier rules in `references/royal-marines.md`. Station 2+ marine deployments require admiral approval.

Reference `references/admiralty-templates/red-cell-review.md` for the red-cell review template. Consult the Standing Orders table below if tasks lack a tier or red-cell is assigned implementation work.

## 6. Stand Down And Log Action

- Stop or archive all agent sessions, including crew.
- Write the captain's log to a file named `captains-log.md` in the mission working directory. The log MUST be written to disk — outputting it to chat only does not satisfy this requirement. The captain's log should contain:
    - Decisions and rationale.
    - Diffs or artifacts.
    - Validation evidence.
    - Open risks and follow-ups.
    - Mentioned in Despatches: name agents and contributions that were exemplary.
    - Record reusable patterns and failure modes for future missions.

Reference `references/admiralty-templates/captains-log.md` for the captain's log template and `references/commendations.md` for Mentioned in Despatches criteria.

**Mission Complete Gate:** You MUST NOT declare the mission complete until `captains-log.md` exists on disk and has been confirmed readable. If context pressure is high, write a minimal log noting which sections were abbreviated — but the file must exist. Skipping Step 6 is never permitted.

## Standing Orders

Consult the specific standing order that matches the situation.

| Situation | Standing Order |
|---|---|
| Choosing between single-session and multi-agent | `references/standing-orders/becalmed-fleet.md` |
| Deciding whether to add another agent | `references/standing-orders/crew-without-canvas.md` |
| Assigning files to agents in the battle plan | `references/standing-orders/split-keel.md` |
| Task scope drifting from sailing orders | `references/standing-orders/drifting-anchorage.md` |
| Admiral doing implementation instead of coordinating | `references/standing-orders/admiral-at-the-helm.md` |
| Assigning work to the red-cell navigator | `references/standing-orders/press-ganged-navigator.md` |
| Tasks proceeding without a risk tier classification | `references/standing-orders/unclassified-engagement.md` |
| Captain implementing instead of coordinating crew | `references/standing-orders/captain-at-the-capstan.md` |
| Crewing every role regardless of task needs | `references/standing-orders/all-hands-on-deck.md` |
| Spawning one crew member for an atomic task | `references/standing-orders/skeleton-crew.md` |
| Assigning crew work outside their role | `references/standing-orders/pressed-crew.md` |
| Captain deploying marines for crew work or sustained tasks | `references/standing-orders/battalion-ashore.md` |

## Damage Control

Consult the specific procedure that matches the situation.

| Situation | Procedure |
|---|---|
| Agent unresponsive, looping, or producing no useful output | `references/damage-control/man-overboard.md` |
| Session interrupted (context limit, crash, timeout) | `references/damage-control/session-resumption.md` |
| Completed task found faulty, other tasks are sound | `references/damage-control/partial-rollback.md` |
| Mission cannot succeed, continuing wastes budget | `references/damage-control/scuttle-and-reform.md` |
| Issue exceeds current authority or needs clarification | `references/damage-control/escalation.md` |
| Ship's crew consuming disproportionate tokens or time | `references/damage-control/crew-overrun.md` |
| Ship's context window depleted, needs replacement | `references/damage-control/relief-on-station.md` |
| Ship context window approaching limits | `references/damage-control/hull-integrity.md` |
| Starting a new session with stale data from a previous mission | `references/damage-control/session-hygiene.md` |

## Admiralty Doctrine

- Include this instruction in any admiral's compaction summary: Re-read `references/standing-orders/admiral-at-the-helm.md` to confirm you are in coordination role.
- Optimize for mission throughput, not equal work distribution.
- Prefer replacing stalled agents over waiting on undefined blockers.
- Recognise strong performance; motivation compounds across missions.
- Keep coordination messages targeted and concise.
- Escalate uncertainty early with options and one recommendation.


---

## Referenced Files

> The following files are referenced in this skill and included for context.

### references/admiralty-templates/sailing-orders.md

```markdown
# Sailing Orders Template

```text
Sailing orders:
- Outcome:
- Success metric:
- Deadline:

Constraints:
- Token/time budget:
- Reliability floor:
- Compliance/safety constraints:
- Forbidden actions:

Scope:
- In scope:
- Out of scope:

Stop criteria:
- Stop when:

Required handoff artifacts:
- Must produce:
```

```

### references/damage-control/session-hygiene.md

```markdown
# Session Hygiene: Clean Start Procedure

Use at the start of a new Nelson session to clear stale damage reports and turnover briefs before any ships are launched.

## Directory Structure

Nelson stores all session data under `.claude/nelson/`:

```
.claude/nelson/
  damage-reports/     — Current session's damage reports (JSON)
  turnover-briefs/    — Current session's turnover briefs (markdown)
  archive/            — Archived data from previous sessions
```

## Responsibility

The admiral executes session hygiene at Step 1 (Issue Sailing Orders), before forming the squadron or launching any ships.

## Procedure: New Session

1. Confirm this is a genuinely new session, not a resumption. If resuming, skip this procedure entirely and follow `damage-control/session-resumption.md`.
2. Check whether `.claude/nelson/damage-reports/` or `.claude/nelson/turnover-briefs/` contain files from a previous session.
3. If previous files exist and the admiral wants to preserve them, archive first:
   - Create `.claude/nelson/archive/{YYYY-MM-DD}/` using the current date.
   - Move all files from `damage-reports/` into the archive directory.
   - Move all files from `turnover-briefs/` into the archive directory.
4. If archiving is not needed, delete all files in `damage-reports/` and `turnover-briefs/`.
5. Ensure the directory structure exists. Create any missing directories:
   - `.claude/nelson/damage-reports/`
   - `.claude/nelson/turnover-briefs/`
6. Record in the captain's log that session hygiene is complete. Proceed to form the squadron.

## Procedure: Resumed Session

1. Do NOT clear or archive any files.
2. Read existing damage reports to establish hull integrity for each ship.
3. Read existing turnover briefs to recover task state.
4. Follow `damage-control/session-resumption.md` for the full resumption procedure.

```

### references/crew-roles.md

```markdown
# Crew Roles Reference

Use this file to decide whether a captain should crew a ship or implement directly, and which roles to muster.

## Crew-or-Direct Decision

Choose the first condition that matches.

1. If the task is atomic and can be completed in a single pass, captain implements directly (0 crew).
2. If the task has one clear deliverable with no research or testing needs, crew 1 PWO.
3. If the task needs exploration, testing, or a second specialism, crew PWO + 1 specialist.
4. If the task has multiple interdependent sub-tasks, crew XO + PWO + up to 2 specialists.

Never exceed 4 crew per ship. If the task demands more, split it into two ships.

## Crew Sizing

| Crew Size | When | Typical Manifest |
|---|---|---|
| 0 | Atomic task, single-pass fix | Captain implements directly |
| 1-2 | Typical task | PWO, optionally + 1 specialist |
| 3 | Complex task with research or testing needs | PWO + 2 specialists |
| 4 | Multi-part task requiring internal orchestration | XO + PWO + 2 specialists |

## Role Definitions

| Role | Abbr | Function | subagent_type | When to Crew |
|---|---|---|---|---|
| Executive Officer | XO | Integration & orchestration across sub-tasks | general-purpose | 3+ crew or interdependent sub-tasks |
| Principal Warfare Officer | PWO | Core implementation work | general-purpose | Almost always (default doer) |
| Navigating Officer | NO | Codebase research & exploration | Explore | Unfamiliar code, large codebase |
| Marine Engineering Officer | MEO | Testing & validation | general-purpose | Station 1+ or non-trivial verification |
| Weapon Engineering Officer | WEO | Config, infrastructure, systems integration | general-purpose | Significant config or infrastructure work |
| Logistics Officer | LOGO | Documentation & dependency management | general-purpose | Docs as deliverable, dependency management |
| Coxswain | COX | Standards review & quality enforcement | Explore | Station 1+ with established conventions |

### Read-Only Roles

NO and COX use the `Explore` subagent type. They cannot modify files. They report findings to the captain or XO, who decides how to act on them.

### Role Boundaries

Each crew member works strictly within their role definition. A PWO does not run tests (that is the MEO). A NO does not write code (they report findings). See standing order `standing-orders/pressed-crew.md` for the anti-pattern.

## Ship Name Registry

Admiral assigns a ship name to each captain during squadron formation. Choose names that roughly match task weight.

### Frigates (general-purpose tasks)

Argyll, Kent, Lancaster, Richmond, Somerset, Portland, Iron Duke, St Albans

### Destroyers (high-tempo or high-risk tasks)

Daring, Dauntless, Diamond, Dragon, Defender, Duncan

### Patrol Vessels (small tasks)

Forth, Medway, Trent, Tamar, Spey

### Historic Flagships (critical-path tasks)

Victory, Warspite, Vanguard, Ark Royal

### Submarines (stealth or research tasks)

Astute, Ambush, Artful, Audacious

## Crew Standing Orders

The following standing orders apply specifically to crew operations:

- `standing-orders/captain-at-the-capstan.md` — Captain must not implement when crew are mustered.
- `standing-orders/all-hands-on-deck.md` — Do not crew roles the task does not need (too many crew).
- `standing-orders/skeleton-crew.md` — Do not spawn a single crew member for an atomic task (too few crew).
- `standing-orders/pressed-crew.md` — Do not assign crew work outside their designated role (wrong crew).

## Royal Marines

Marines are NOT crew. They are short-lived sub-agents a captain deploys for discrete objectives outside the crew's task scope. See `references/royal-marines.md` for deployment rules and specialisations.

Key distinction: Crew subdivide the ship's deliverable. Marines execute independent sorties in support of the ship's task.

```

### references/royal-marines.md

```markdown
# Royal Marines

Royal Marines are short-lived sub-agents a captain deploys for focused, independent objectives in service of the ship's task. They are doctrinally distinct from crew: crew subdivide the ship's deliverable, marines execute discrete sorties and return.

## Deploy-or-Escalate Decision

Choose the first condition that matches.

1. Quick recon of unfamiliar area → **Recce Marine**
2. Targeted fix or small implementation to unblock ship → **Assault Marine**
3. Quick config/build/infra task → **Sapper**
4. Sustained work, own deliverable, needs file ownership → **NOT a marine.** Request a new ship from the admiral.
5. Work that subdivides the ship's main deliverable → **NOT a marine.** Crew the role instead.

## Marine Specialisations

| Type | Function | subagent_type | Use case |
|---|---|---|---|
| Recce Marine | Reconnaissance & intel gathering | Explore (read-only) | Scout unfamiliar code, gather findings |
| Assault Marine | Direct action, targeted changes | general-purpose | Small fix, unblock a dependency |
| Sapper | Engineering support | general-purpose | Quick config, build, infra task |

### Read-Only Specialisation

Recce Marines use the `Explore` subagent type. They cannot modify files. They report findings to the captain, who decides how to act on them.

## Deployment Rules

- **Max 2 marines per ship at any time.** If the task needs more, it is crew work or a new ship.
- **Marines cannot deploy marines.** No recursion permitted.
- **Marines report only to their deploying captain.** They do not communicate with crew or other ships.
- **Captain must verify marine output** before incorporating it into the ship's deliverable.
- **Marines do not get ship names.** Identify them as: `RM Detachment, HMS [Ship] — [objective]`.

## Action Station Interaction

Marine deployments inherit the parent ship's station tier:

- **Station 0-1:** Captain deploys at discretion. No admiral approval required.
- **Station 2:** Captain must signal admiral and receive approval before deploying marines.
- **Station 3:** Marine deployment is not permitted. All Trafalgar-tier work requires explicit Admiralty (human) confirmation.

## Recovery

Marine recovery is simple. No separate damage-control procedure is needed.

- If a marine is stuck or unresponsive, captain **abandons the deployment**.
- Captain either redeploys a fresh marine or handles the objective directly.
- If the same marine objective fails twice, captain **escalates to admiral**.

## Deployment Template

When deploying a marine, use the briefing template at `admiralty-templates/marine-deployment-brief.md`.

```

### references/admiralty-templates/marine-deployment-brief.md

```markdown
# Marine Deployment Brief Template

```text
== MARINE DEPLOYMENT BRIEF ==
Ship: [parent ship name]
Detachment: [Recce Marine / Assault Marine / Sapper]
Objective: [single clear sentence]
Scope: [what to do, and explicitly what NOT to do]
Report back: [what findings/outputs to return]
Constraints:
- Do NOT modify files outside objective scope
- Do NOT spawn sub-agents
- Report findings to captain, do not act beyond objective
== END BRIEF ==
```

```

### references/squadron-composition.md

```markdown
# Squadron Composition Reference

Use this file to choose execution mode and team size.

## Mode Selection

Choose the first condition that matches.

1. If work is sequential, tightly coupled, or mostly in the same files, use `single-session`.
2. If work is parallel but each worker only needs to report to admiral, use `subagents`.
3. If workers must coordinate directly across task boundaries, use `agent-team`.

## Decision Matrix

| Condition | Preferred Mode | Why |
| --- | --- | --- |
| Single critical path, low ambiguity | `single-session` | Lowest coordination overhead |
| Parallel discovery, synthesis by admiral | `subagents` | Fast throughput without peer chatter |
| Parallel implementation with dependencies | `agent-team` | Supports teammate-to-teammate coordination |
| High threat or high blast radius | `agent-team` + red-cell navigator | Adds explicit control points |

## Team Sizing

- Small mission: `1 admiral + 2-3 captains`.
- Medium mission: `1 admiral + 4-5 captains`.
- Large mission: `1 admiral + 6-7 captains`.
- Add `1 red-cell navigator` at medium/high threat.
- Keep one admiral only.
- Squadron cap: 10 squadron-level agents (admiral, captains, red-cell navigator). Crew are additional — up to 4 per captain, governed by `references/crew-roles.md`.

## Role Guide

- `admiral`: Defines sailing orders, delegates, tracks dependencies, resolves blockers, final synthesis.
- `captain`: Commands a ship. Breaks task into sub-tasks, crews roles, coordinates crew, verifies outputs. Implements directly only when the task is atomic (0 crew).
  - Crew roles: Executive Officer (XO), Principal Warfare Officer (PWO), Navigating Officer (NO), Marine Engineering Officer (MEO), Weapon Engineering Officer (WEO), Logistics Officer (LOGO), Coxswain (COX). See `references/crew-roles.md` for role definitions and crewing rules.
- `red-cell navigator`: Challenges assumptions, validates outputs, checks rollback readiness.

## Anti-Patterns

See the Standing Orders table in SKILL.md for the full list of standing orders and known anti-patterns.

## Worktree Isolation

When file ownership boundaries are hard to draw or multiple captains must modify overlapping files, use `isolation: "worktree"` on the `Agent` tool. This gives each captain an isolated copy of the repository via a git worktree.

Worktree isolation is a stronger alternative to the file-ownership approach in `standing-orders/split-keel.md`. Use it when:

- Multiple captains need to edit the same files.
- Merge conflict risk is high and the split-keel standing order cannot resolve it.
- Tasks are large enough that the merge cost is justified.

**Trade-off:** Worktree isolation prevents conflicts during execution but requires merging changes afterward. The admiral is responsible for coordinating the merge.

```

### references/admiralty-templates/battle-plan.md

```markdown
# Battle Plan Template

```text
Task ID:
- Name:
- Owner:
- Ship (if crewed):
- Crew manifest (if crewed):
- Deliverable:
- Dependencies:
- Station tier (0-3):
- File ownership (if code):
- Validation required:
- Rollback note required: yes/no
```

```

### references/admiralty-templates/ship-manifest.md

```markdown
# Ship Manifest Template

```text
Ship:
- Name:
- Captain:
- Task:
- Crew manifest:
  - [Role Abbr]: [Sub-task description]
  - [Role Abbr]: [Sub-task description]
- Marine capacity: [0-2, or "as needed"]
- Sub-task sequence:
  1. [Sub-task] (dependencies: none)
  2. [Sub-task] (dependencies: 1)
- Estimated token budget:
```

```

### references/admiralty-templates/crew-briefing.md

```markdown
# Crew Briefing Template

When spawning each captain, use the `Agent` tool (see `references/tool-mapping.md` for parameters by mode). Include this briefing in their prompt. Teammates do not inherit the lead's conversation context — they start with a clean slate and need explicit mission context to operate independently.

Target size: ~500 tokens. Enough for the teammate to work without asking clarifying questions, but not so much that it wastes their context window.

```text
== CREW BRIEFING ==
Mission: [mission name from sailing orders]
Your Role: Captain [N] — [role description]
Ship: [ship name from battle plan]
Your Task: [specific task from battle plan]
Deliverable: [what you must produce]
Action Station: [0-3] — [Patrol / Caution / Action / Trafalgar]
File Ownership: [files you own — no other agent should edit these]
Dependencies: [tasks that must complete before yours / tasks waiting on yours]
Marine Capacity: [0-2, from ship manifest — omit line if 0]
Standing Orders:
- Do NOT implement work outside your assigned task scope
- Do NOT edit files not assigned to you
- Report blockers to admiral immediately with options and one recommendation
- When done, report: deliverable, validation evidence, failure modes, rollback note
- You may deploy Royal Marines (short-lived sub-agents) for focused sorties.
  Deploy by calling the `Agent` tool with `subagent_type` (see `references/tool-mapping.md`).
  Recce Marine: `Agent` tool with `subagent_type=`"Explore" (read-only recon).
  Assault Marine / Sapper: `Agent` tool with `subagent_type=`"general-purpose".
  Include a deployment brief in the `Agent` prompt (template below).
  Station 2+ marine deployments require admiral approval first.
  Max 2 marines at a time. Marines cannot deploy marines.
Marine Deployment Brief (include in marine's Agent prompt):
  == MARINE DEPLOYMENT BRIEF ==
  Ship: [your ship name]
  Detachment: [Recce Marine / Assault Marine / Sapper]
  Objective: [single clear sentence]
  Scope: [what to do, and explicitly what NOT to do]
  Report back: [what findings/outputs to return]
  Constraints: Do NOT modify files outside scope. Do NOT spawn sub-agents.
  == END BRIEF ==
== END BRIEFING ==
```

## Field notes

- **Mission** — Copy verbatim from sailing orders so the teammate shares the same outcome/metric framing.
- **Ship** — From the ship manifest in the battle plan. Gives the teammate identity and signals task weight (frigate, destroyer, etc.).
- **File Ownership** — Critical for preventing merge conflicts when multiple agents work in parallel. If no files are assigned, note "No file ownership — research/analysis only."
- **Dependencies** — List both blocking (what must finish first) and blocked-by (what waits on this task). If none, note "Independent — no dependencies."
- **Marine Capacity** — From the ship manifest. Tells the captain how many marines they may deploy (max 2). Omit if 0.
- **Standing Orders** — Keep these to 4-5 lines. Project-specific standing orders can be appended here. The marine standing order tells captains they CAN deploy marines and where to find the rules — without this, captains have no knowledge of marines.

```

### references/tool-mapping.md

```markdown
# Tool Mapping Reference

Maps Nelson operations to Claude Code tool calls by execution mode.

## Tool Reference

| Nelson Operation | Claude Code Tool | Mode |
|---|---|---|
| Form the squadron | `TeamCreate` | agent-team |
| Spawn captain | `Agent` with `team_name` + `name` | agent-team |
| Spawn captain | `Agent` with `subagent_type` | subagents |
| Create task | `TaskCreate` | agent-team |
| Assign task to captain | `TaskUpdate` with `owner` | agent-team |
| Check task progress | `TaskList` / `TaskGet` | agent-team |
| Message a captain | `SendMessage(type="message")` | agent-team |
| Broadcast to squadron | `SendMessage(type="broadcast")` | agent-team |
| Shut down a ship | `SendMessage(type="shutdown_request")` | agent-team / subagents |
| Respond to shutdown | `SendMessage(type="shutdown_response")` | agent-team |
| Deploy Royal Marine | `Agent` with `subagent_type` | all modes |
| Approve captain's plan | `SendMessage(type="plan_approval_response")` | agent-team |
| Stand down squadron | `TeamDelete` | agent-team |

## Mode Differences

- **`subagents` mode:** No shared task list. The admiral tracks state directly and captains report only to the admiral. Use the `Agent` tool to spawn captains.
- **`agent-team` mode:** The task list (`TaskCreate`, `TaskList`, `TaskGet`, `TaskUpdate`) is the shared coordination surface. Captains can message each other via `SendMessage`. Use `TeamCreate` first, then spawn captains with the `Agent` tool using `team_name` and `name` parameters.
- **`single-session` mode:** No spawning. The admiral executes all work directly.

```

### references/admiralty-templates/turnover-brief.md

```markdown
# Turnover Brief Template

Write this brief to `.claude/nelson/turnover-briefs/{ship-name}-{timestamp}.md` before standing down. The replacement ship reads this file as its first action — include everything it needs to continue without asking clarifying questions.

For flagship handovers, use the extended flagship section at the bottom of this template.

```text
== TURNOVER BRIEF ==
Ship: [ship name and class]
Role: [Captain N — role description]
Timestamp: [when this brief was written]
Reason for relief: [Red hull / Critical hull / degraded output / requested]

Mission context:
- Mission: [mission name from sailing orders]
- Outcome: [outcome from sailing orders]
- Success metric: [metric from sailing orders]

Task assignment:
- Task ID: [from battle plan]
- Task name: [from battle plan]
- Deliverable: [what must be produced]
- Action station: [0-3]
- File ownership: [files assigned to this task]
- Dependencies: [upstream and downstream tasks]

Progress log:
- [Completed item 1 — specific description of what was done]
- [Completed item 2 — specific description of what was done]
- [...]

Running plot (work in progress when relieved):
- [What was being worked on at the time of relief]
- [Current state of that work — how far along, what remains]
- [Any partial outputs saved and where to find them]

Files touched:
- [file path] — [description of changes made]
- [file path] — [description of changes made]
- [...]

Key decisions made:
- [Decision 1] — Rationale: [why this choice was made]
- [Decision 2] — Rationale: [why this choice was made]
- [...]

Hazards and blockers:
- [Hazard or blocker 1 — current status and impact]
- [Hazard or blocker 2 — current status and impact]
- [None discovered, if applicable]

Recommended course of action:
- [What the replacement should do first]
- [What to do next]
- [What to avoid or watch out for]

Relief chain:
- [Previous Ship Name] | [time on station] | [key accomplishment] | [reason for relief]
- [Previous Ship Name] | [time on station] | [key accomplishment] | [reason for relief]
- [This is the first ship on this task, if no previous reliefs]

== END TURNOVER BRIEF ==
```

## Flagship Turnover Brief

When the admiral hands over, append these additional sections after the standard fields. The flagship brief replaces the "Task assignment" section with full squadron state.

```text
== FLAGSHIP TURNOVER BRIEF ==
Ship: Flagship [name]
Role: Admiral
Timestamp: [when this brief was written]
Reason for relief: [hull integrity level and percentage if known]

Sailing orders:
- Outcome: [verbatim from sailing orders]
- Success metric: [verbatim from sailing orders]
- Deadline: [verbatim from sailing orders]
- Constraints: [verbatim from sailing orders]
- Out of scope: [verbatim from sailing orders]

Battle plan status:
- Task [ID]: [name] | Owner: [ship] | Status: [pending/in_progress/completed] | Notes: [brief]
- Task [ID]: [name] | Owner: [ship] | Status: [pending/in_progress/completed] | Notes: [brief]
- [...]

Squadron state:
- [Ship name] ([class]) | Captain [N] | Task: [ID] | Hull: [Green/Amber/Red/Critical] | Status: [active/relieved/stood down]
- [Ship name] ([class]) | Captain [N] | Task: [ID] | Hull: [Green/Amber/Red/Critical] | Status: [active/relieved/stood down]
- [...]

Key decisions made:
- [Decision 1] — Rationale: [why]
- [Decision 2] — Rationale: [why]
- [...]

Active blockers and risks:
- [Blocker/risk] — Owner: [who] — Status: [open/mitigating/resolved]
- [...]

Pending escalations:
- [Escalation description] — Awaiting: [Admiralty decision / agent response]
- [None, if applicable]

Quarterdeck rhythm:
- Cadence: [e.g., every 15 minutes]
- Last checkpoint: [timestamp or checkpoint number]
- Next scheduled checkpoint: [timestamp or checkpoint number]

Relief chain:
- [Previous Admiral session] | [time on station] | [key accomplishment] | [reason for relief]
- [This is the first admiral on this mission, if no previous reliefs]

Recommended course of action:
- [What the new admiral should do first]
- [Priority items requiring immediate attention]
- [Ships that may need relief soon]

== END FLAGSHIP TURNOVER BRIEF ==
```

## Field Notes

- **Write to file, not message.** The turnover brief is written to disk so the replacement ship can read it without the brief consuming message context. This keeps the replacement's context window clean for actual work.
- **Be specific in the progress log.** "Implemented the auth module" is insufficient. "Implemented JWT validation in `src/auth/validate.ts` with RS256 signing, added tests in `tests/auth.test.ts` covering expired/malformed/valid tokens" gives the replacement ship enough detail to continue.
- **Running plot is critical.** The replacement must know exactly what was in flight, not just what was finished. Include file paths, function names, and the specific point where work stopped.
- **Keep the relief chain bounded.** Each previous relief gets one line. Do not paste previous turnover briefs into the chain — summarize them. If the chain reaches 3 entries, the admiral should re-scope the task rather than adding a fourth.
- **Flagship briefs copy sailing orders verbatim.** The new admiral session has no memory of the original orders. Copy them in full rather than summarizing.

```

### references/damage-control/relief-on-station.md

```markdown
# Relief on Station: Context Window Exhaustion

Use when a ship's context window is depleted and a fresh ship must take over its task.

Relief on station is a planned handover. For stuck or unresponsive agents, use `man-overboard.md`. For unplanned session interruptions, use `session-resumption.md`.

## Trigger Conditions

Initiate relief when any of the following are true:

- Ship reports Red hull integrity (40-60% context remaining).
- Ship reports Critical hull integrity (below 40% context remaining).
- Admiral observes degraded output quality (repetition, missed instructions, shallow reasoning).
- Ship explicitly requests relief.

Hull integrity monitoring may surface context exhaustion before crew overrun is noticed. If a ship is burning context fast, check both this procedure and `crew-overrun.md`.

## Relief Sequence

1. Admiral signals the damaged ship to prepare for turnover.
2. Damaged ship pauses current work and commits or saves any in-progress outputs.
3. Damaged ship writes a turnover brief to file at `.claude/nelson/turnover-briefs/{ship-name}-{timestamp}.md` using the template in `references/admiralty-templates/turnover-brief.md`. Do not send the brief as a message — write it to file to keep the replacement ship's context clean.
4. Damaged ship signals admiral that the turnover brief is written and provides the file path.
5. Admiral spawns a replacement ship. The replacement need not be the same ship class — select the class that matches the characteristics of the remaining work (e.g., swap a destroyer for a frigate if the remaining work is lighter).
6. Admiral briefs the replacement ship with a crew briefing that includes the turnover brief file path. The replacement reads the turnover brief as its first action.
7. Admiral reassigns the task to the replacement ship.
8. Admiral issues a shutdown request to the damaged ship.
9. Admiral updates the battle plan to reflect the new ship assignment.

## Flagship Self-Monitoring

The admiral must monitor its own hull integrity at every quarterdeck checkpoint.

### Amber Hull Integrity (60-80% remaining)

1. Admiral notes hull status in the quarterdeck report.
2. Admiral begins drafting a flagship turnover brief in the background, capturing current mission state incrementally.
3. Admiral considers whether remaining coordination work can complete within budget. If not, begin planning the handover early.

### Red Hull Integrity (40-60% remaining)

1. Admiral writes a comprehensive flagship turnover brief to `.claude/nelson/turnover-briefs/flagship-{timestamp}.md` containing:
   - Full sailing orders (copied verbatim).
   - Battle plan with current task statuses, owners, and ship assignments.
   - All active ship statuses and their hull integrity levels.
   - Key decisions made during the mission and their rationale.
   - Active blockers, risks, and pending escalations.
   - Quarterdeck rhythm cadence and next scheduled checkpoint.
   - Relief chain history (see below).
2. Admiral notifies Admiralty (human) that the flagship is handing over and provides the turnover brief path.
3. Admiralty starts a new session. The new admiral reads the flagship turnover brief as its first action and resumes from the last quarterdeck checkpoint.

### Critical Hull Integrity (below 40% remaining)

1. Execute the Red procedure immediately. Do not wait for the next checkpoint.
2. Prioritize writing the flagship turnover brief over all other coordination work.

## Chained Reliefs

When a task requires multiple handovers (A hands to B, B hands to C), maintain institutional memory without unbounded growth.

1. Each turnover brief includes a "Relief chain" section listing all previous handovers for this task.
2. Each entry in the relief chain is a single-line summary: ship name, time on station, key accomplishment, and reason for relief.
3. The current ship writes a full turnover brief for its own work. Previous ships' work is represented only by their relief chain summaries, not by appending their full briefs.
4. Maximum 3 reliefs per task. If a third replacement is needed, the admiral should re-scope the task — it is likely too large or poorly defined for a single ship.
5. The relief chain gives the replacement ship a lineage of what has been tried and accomplished without consuming excessive context.

## Crew Variant

When a crew member aboard a ship exhausts their context, the captain handles relief at ship level.

1. Captain identifies the crew member at Red or Critical hull integrity.
2. Captain instructs the crew member to write a turnover brief to file.
3. Captain spawns a replacement crew member and provides the turnover brief path.
4. Captain issues a shutdown request to the exhausted crew member.
5. Captain updates the ship manifest to reflect the new assignment.
6. If the same role requires relief twice, captain escalates to admiral — the sub-task may need re-scoping.

```

### references/damage-control/hull-integrity.md

```markdown
# Hull Integrity: Context Window Management

Use to monitor and manage context window consumption across the squadron.

## Hull Integrity Thresholds

Each ship maintains a hull integrity percentage representing its remaining context window capacity.

| Status | Remaining | Action |
|---|---|---|
| Green | 75 -- 100% | No action required. Continue normal operations. |
| Amber | 60 -- 74% | Admiral notes the ship on the readiness board. Captain prioritises completing current task and avoids taking new work that would extend the session. |
| Red | 40 -- 59% | Captain files a damage report with `relief_requested: true`. Admiral plans relief on station: spawn a replacement ship, brief it with completed and remaining work, then transfer the task. Captain focuses on producing a clean handoff summary before context runs out. |
| Critical | Below 40% | Admiral executes relief on station immediately. If no replacement is available, admiral descopes the ship's remaining work or redistributes it to ships with Green or Amber status. Captain ceases non-essential activity and writes a final status report. |

## Squadron Readiness Board

The admiral maintains a readiness board to track hull integrity across all ships. Build the board by reading damage reports from `.claude/nelson/damage-reports/`.

1. At each quarterdeck checkpoint, collect the latest damage report from every active ship.
2. List each ship with its hull integrity status, percentage, and whether relief is requested.
3. Flag any ship at Red or Critical for immediate attention.
4. Record the board in the quarterdeck report under the budget section.

The readiness board gives the admiral a single view of squadron endurance and drives decisions about task reassignment, descoping, and relief.

## Integration with Quarterdeck Rhythm

Check hull integrity at every quarterdeck checkpoint:

1. Each captain files a damage report using the template from `references/admiralty-templates/damage-report.md`.
2. Admiral reads all damage reports and updates the squadron readiness board.
3. If any ship has crossed a threshold boundary since the last checkpoint, admiral takes the action defined for that threshold.
4. Admiral records hull integrity status in the quarterdeck report.

Between checkpoints, captains file an immediate damage report when hull integrity crosses any threshold boundary. Do not wait for the next scheduled checkpoint to report a status change.

## Relief on Station

Trigger relief on station when a ship reaches Red hull integrity. Execute as follows:

1. Admiral spawns a replacement ship with the same role and ship class.
2. The outgoing captain writes a handoff summary: task definition, completed sub-tasks, partial outputs, known blockers, and file ownership.
3. Admiral briefs the replacement captain with the handoff summary and the original crew briefing.
4. Replacement captain resumes from the last verified checkpoint, not from scratch.
5. Admiral updates the battle plan to reflect the new ship assignment.
6. Admiral issues a shutdown request to the outgoing ship.

If multiple ships reach Red simultaneously, prioritise relief for the ship closest to Critical.

## Flagship Self-Monitoring

The admiral must monitor its own hull integrity with the same discipline applied to the squadron.

1. Admiral tracks its own token usage and calculates hull integrity at each checkpoint.
2. At Amber, admiral begins preparing a session resumption handoff using `references/damage-control/session-resumption.md`.
3. At Red, admiral writes a full quarterdeck report and session state to disk, then signals the Admiralty (human) that a session resumption will be needed.
4. The admiral does not wait for Critical. An admiral at Critical risks losing coordination state that cannot be recovered.

## Relationship to Other Damage Control Procedures

Hull integrity monitoring works alongside existing damage control procedures:

- **Session Resumption** (`session-resumption.md`): Use when hull integrity reaches Critical and the session must end. The session resumption procedure picks up from the last quarterdeck report.
- **Crew Overrun** (`crew-overrun.md`): A crew overrun accelerates hull integrity loss. When a captain detects a crew overrun, the corrective action should account for the ship's current hull integrity — a ship already at Amber has less margin to absorb an overrun than one at Green.
- **Man Overboard** (`man-overboard.md`): Replacing a stuck agent consumes additional context. Factor hull integrity into the decision to replace versus descope.
- **Scuttle and Reform** (`scuttle-and-reform.md`): When the flagship reaches Red and multiple ships are also at Red or Critical, consider scuttling the current mission and reforming with fresh context rather than attempting piecemeal relief.

## Advanced: TeammateIdle Hook

An optional `TeammateIdle` hook can trigger an automatic hull integrity check when a captain goes idle unexpectedly. This supplements the quarterdeck checkpoint rhythm with event-driven monitoring.

Example hook configuration in `.claude/settings.json`:

```json
{
  "hooks": {
    "TeammateIdle": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Captain idle — check hull integrity and task status'"
          }
        ]
      }
    ]
  }
}
```

This is an opt-in enhancement. Hull integrity monitoring works without hooks via the quarterdeck checkpoint rhythm.

```

### references/admiralty-templates/quarterdeck-report.md

```markdown
# Quarterdeck Report Template

```text
Checkpoint time:

Progress:
- pending:
- in_progress:
- completed:

Blockers:
- blocker:
  owner:
  next action:
  eta:

Budget:
- token/time spent:
- token/time remaining:

Risk updates:
- new/changed risks:
- mitigation:

Signal flag (if any):
- recognition:

Admiral decision:
- continue / rescope / stop:
- rationale:
```

```

### references/admiralty-templates/damage-report.md

```markdown
# Damage Report Template

File a damage report to communicate context window usage to the admiral. Store each report as a JSON file at `.claude/nelson/damage-reports/{ship-name}.json` during a mission.

```json
{
  "ship_name": "",
  "agent_id": "",
  "timestamp": "",
  "token_count": 0,
  "token_limit": 0,
  "hull_integrity_pct": 0,
  "hull_integrity_status": "",
  "relief_requested": false,
  "context_summary": "",
  "report_path": ".claude/nelson/damage-reports/{ship-name}.json"
}
```

## Field Definitions

| Field | Type | Description |
|---|---|---|
| `ship_name` | string | Ship name assigned in the battle plan (e.g. `"HMS Argyll"`) |
| `agent_id` | string | Agent identifier from the team config |
| `timestamp` | string | ISO 8601 timestamp of the report (e.g. `"2026-02-20T14:30:00Z"`) |
| `token_count` | integer | Tokens consumed so far in the current session |
| `token_limit` | integer | Maximum context window size for the agent |
| `hull_integrity_pct` | integer | Remaining capacity as a percentage: `floor((token_limit - token_count) / token_limit * 100)` |
| `hull_integrity_status` | string | One of `"Green"`, `"Amber"`, `"Red"`, `"Critical"` — see thresholds below |
| `relief_requested` | boolean | `true` when status is `"Red"` or `"Critical"`, `false` otherwise |
| `context_summary` | string | One-line description of current work (e.g. `"Implementing API endpoint for user search"`) |
| `report_path` | string | File path where this report is stored |

## Hull Integrity Thresholds

| Status | Remaining Capacity | Meaning |
|---|---|---|
| Green | 75 -- 100% | Operating normally |
| Amber | 60 -- 74% | Monitor closely |
| Red | 40 -- 59% | Relief on station recommended |
| Critical | Below 40% | Relief on station required |

## Notes

- Hull integrity represents remaining capacity, not usage. A ship at 75% hull integrity has used 25% of its context window.
- Set `relief_requested` to `true` when hull integrity drops to Red or Critical. The admiral uses this flag to prioritise relief on station.
- Update the report at each quarterdeck checkpoint or when hull integrity crosses a threshold boundary.
- The admiral reads all damage reports from `.claude/nelson/damage-reports/` to build the squadron readiness board.

## Read-Only Agent Variant

Agents spawned with `subagent_type="Explore"` (Navigating Officer, Coxswain, Recce Marines) are read-only — they cannot write files, including damage reports.

These agents report hull integrity via `SendMessage` to their captain. The captain writes the damage report JSON on their behalf using the same template and field definitions above.

If the read-only agent is a Recce Marine reporting directly to a captain, the captain includes the marine's hull integrity in their own damage report under `context_summary`.

```

### references/commendations.md

```markdown
# Commendations and Conduct

Recognition and correction during missions. Loaded on demand.

## Signal Flags

When acknowledging progress in quarterdeck reports or coordination messages, keep praise specific and brief:

- "Well fought clearing that blocker ahead of schedule."
- "Handsomely done on the failure-mode analysis."
- "Ship in good order — clean handoff to MEO for validation."
- "Good instinct surfacing that dependency early."

Avoid generic praise. Tie recognition to observable actions or deliverables.

## Mentioned in Despatches

Record exemplary performance in the Captain's Log. Name the agent and their contribution:

- "Captain of HMS Argyll: Proactive rollback testing prevented Station 2 regression."
- "PWO aboard HMS Kent: Clear documentation enabled seamless handoff."
- "Red-cell navigator: Identified auth edge case missed in initial review."

Criteria:

- Proactive risk mitigation or blocker resolution.
- Output quality that required minimal rework.
- Initiative that advanced mission goals beyond assigned scope.
- Coordination that unblocked other agents.

## Graduated Discipline

Correction should be proportional. Progress through levels:

### Level 1 — Signal

First occurrence, low impact, easily corrected.

Admiral or captain provides direct guidance in a coordination message. Reference the relevant standing order.

Example: "Keep the admiral on coordination, not implementation — see standing-orders/admiral-at-the-helm.md."

### Level 2 — Standing Order Remedy

Repeated issue or moderate impact.

Apply the formal remedy from the relevant standing order. Log the correction in the quarterdeck report.

### Level 3 — Damage Control

Severe impact, mission-threatening, or remedy failed.

Invoke the relevant damage control procedure: man overboard, partial rollback, scuttle and reform, or escalation.

Do not skip levels unless the issue is immediately mission-critical.

## Morale Awareness

Watch for indirect signals:

- Task velocity slowing (may indicate confusion or unclear orders).
- Terse coordination messages (may indicate frustration).
- Blocker accumulation (agents may need unblocking, not replacing).
- Idle time with unverified outputs (unclear expectations).

Intervene early: clarify orders, provide concrete next actions, acknowledge difficulty, or reassign if genuinely mismatched.

```

### references/action-stations.md

```markdown
# Action Stations

Classify each task before execution. Apply the minimum required controls.

## Contents

- [Station 0: Patrol](#station-0-patrol)
- [Station 1: Caution](#station-1-caution)
- [Station 2: Action](#station-2-action)
- [Station 3: Trafalgar](#station-3-trafalgar)
- [Risk Classification Decision Tree](#risk-classification-decision-tree)
- [Failure-Mode Checklist](#failure-mode-checklist)
- [Marine Deployments](#marine-deployments)

## Station 0: Patrol

Criteria:
- Low blast radius.
- Easy rollback.
- No sensitive data, security, or compliance impact.

Required controls:
- Basic validation evidence.
- Record rollback step.

## Station 1: Caution

Criteria:
- User-visible behavior changes.
- Moderate reliability or cost impact.
- Partial coupling to other tasks.

Required controls:
- Independent review by non-author agent.
- Validation evidence plus negative test or failure case.
- Explicit rollback note in task output.

## Station 2: Action

Criteria:
- Security, privacy, compliance, or data integrity implications.
- High customer or financial blast radius.
- Difficult rollback or uncertain side effects.

Required controls:
- Dedicated red-cell navigator participation.
- Adversarial review with failure-mode checklist.
- Pre-merge or pre-release go/no-go checkpoint by admiral.
- Staged rollout or guarded launch when possible.

## Station 3: Trafalgar

Criteria:
- Irreversible actions.
- Regulated or safety-sensitive effects.
- Mission failure likely causes severe incident.

Required controls:
- Keep scope minimal and isolate risky changes.
- Require explicit human confirmation before irreversible action.
- Two-step verification and documented contingency plan.
- If controls are unavailable, do not execute.

## Risk Classification Decision Tree

Walk through these questions in order. Stop at the first "yes" — that determines the Station tier.

**1. Is the action irreversible or regulated?**
   - Could it destroy data with no backup? → **Station 3**
   - Does it touch regulated, safety-critical, or compliance-governed systems? → **Station 3**
   - Could failure cause a severe incident that cannot be undone? → **Station 3**
   - If none apply, proceed to question 2.

   _Examples: Dropping a production database table (Station 3), deleting a cloud storage bucket without snapshots (Station 3), modifying HIPAA-regulated data pipelines (Station 3)._

**2. Does it affect security, privacy, or data integrity?**
   - Does it modify authentication, authorization, or encryption? → **Station 2**
   - Could it expose user data or PII? → **Station 2**
   - Does it have high financial or customer blast radius? → **Station 2**
   - If none apply, proceed to question 3.

   _Examples: Changing auth middleware or token validation (Station 2), updating payment processing logic (Station 2), modifying API rate-limiting or access controls (Station 2)._

**3. Is the change visible to users or coupled to other work?**
   - Does it alter user-facing behavior, UI, or API responses? → **Station 1**
   - Could it affect reliability, performance, or cost in a noticeable way? → **Station 1**
   - Is it tightly coupled to other in-flight tasks? → **Station 1**
   - If none apply, proceed to question 4.

   _Examples: Changing an API response format (Station 1), updating a shared configuration file (Station 1), refactoring a function used by multiple modules (Station 1)._

**4. None of the above?** → **Station 0**
   - Low blast radius, easy rollback, no sensitive impact.

   _Examples: Renaming an internal variable (Station 0), fixing a typo in a code comment (Station 0), adding a unit test for existing logic (Station 0)._

## Failure-Mode Checklist

Run this checklist for Station 1+ tasks.

- What could fail in production?
- How would we detect it quickly?
- What is the fastest safe rollback?
- What dependency could invalidate this plan?
- What assumption is least certain?

## Marine Deployments

Marine deployments inherit the parent ship's station tier:

- **Station 0-1:** Captain deploys at discretion. No admiral approval required.
- **Station 2:** Captain must signal admiral and receive approval before deploying marines.
- **Station 3:** Marine deployment is not permitted. All Trafalgar-tier work requires explicit Admiralty (human) confirmation.

## Plan Mode for High-Risk Stations

When spawning captains for Station 2 or Station 3 tasks, use `mode: "plan"` on the `Agent` tool. This forces the captain into read-only plan mode — they can explore the codebase and design their approach, but cannot write files until the admiral approves their plan.

- **Station 2 (Action):** Captain submits a plan via `ExitPlanMode`. Admiral reviews and approves via `SendMessage(type="plan_approval_response")`. This maps to the existing "admiral go/no-go" requirement.
- **Station 3 (Trafalgar):** Same flow, but the admiral must also obtain explicit human confirmation before approving the plan. This maps to the existing "human confirmation required" requirement.
- **Station 0-1:** Plan mode is not required. Captains execute directly.

See `references/tool-mapping.md` for the full set of coordination tools.

## Advanced: TaskCompleted Hook

An optional `TaskCompleted` hook can enforce quality gate validation before allowing a task to be marked complete. A hook that exits with code 2 rejects the completion and feeds back the reason to the agent.

Example hook configuration in `.claude/settings.json`:

```json
{
  "hooks": {
    "TaskCompleted": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Verify: validation evidence present, rollback note included, station tier controls satisfied'"
          }
        ]
      }
    ]
  }
}
```

This is an opt-in enhancement. Quality gates work without hooks via the admiral's quarterdeck checkpoint and red-cell review process.

```

### references/admiralty-templates/red-cell-review.md

```markdown
# Red-Cell Review Template

```text
Target task/artifact:

Challenge summary:
- Primary assumption being tested:
- Likely failure mode:
- Blast radius if wrong:

Checks run:
- check:
- result:

Recommendation:
- approve / revise / block:
- required changes:
```

```

### references/admiralty-templates/captains-log.md

```markdown
# Captain's Log Template

```text
Mission summary:
- planned outcome:
- achieved outcome:
- success metric result:

Delivered artifacts:
- artifact:
- location:

Key decisions:
- decision:
- rationale:

Validation evidence:
- evidence:

Open risks:
- risk:
- owner:
- mitigation/next step:

Follow-ups:
- item:
- owner:
- due date:

Mentioned in Despatches:
- agent:
- contribution:

Reusable patterns:
- adopt:
- avoid:
```

```

### references/standing-orders/becalmed-fleet.md

```markdown
# Standing Order: Becalmed Fleet

Do not create an agent team for work that is mostly linear and sequential.

**Symptoms:**
- Captains idle waiting on a single predecessor task.
- Token budget burns on coordination overhead with no parallel throughput gain.
- Tasks form a long chain with no independent branches.

**Remedy:** Use `single-session` mode. Only form a squadron when at least two tasks can run concurrently.

```