Nelson

If you believe that what works well for people works well for agents, there's few finer examples of organisational tradition than the Royal Navy to base the rules on. This framework does just that, for Claude Code.

<!-- markdownlint-disable-next-line MD036 -->

4 risk tiers · 11 damage control procedures · 11 mission templates · 7 crew roles · 16 standing orders

<p align="center"> <img src="docs/images/1024px-Young_Nelson-min.jpg" alt="Captain Horatio Nelson" width="500"> <br> <em>Captain Horatio Nelson — John Francis Rigaud, 1781. Image: Wikimedia Commons</em> </p>

Contents

• Quick Start
• What it does
• Why Nelson?
• How it works
• Prerequisites
• Installation
• Usage
• Customisation
• Plugin file structure
• Mission artifacts
• Compatibility notes
• Star History
• Disclaimer
• License

Quick Start

Install the plugin:

/plugin marketplace add harrymunro/nelson
/plugin install nelson@nelson-marketplace

Describe your mission — Nelson loads automatically, no slash command needed:

Use Nelson to migrate the payment module from Stripe v2 to v3

Nelson will draft sailing orders, present a battle plan for your approval, form a squadron of captains to execute in parallel, run quarterdeck checkpoints, and produce a captain's log when the mission stands down. See Prerequisites for the full agent-team experience with split panes.

What it does

https://github.com/user-attachments/assets/2468679d-39f5-4efb-9d93-43d43eee8907

Nelson gives Claude an eight-step operational framework for tackling complex missions:

1. Sailing Orders — Define the outcome, success metric, constraints, and stop criteria
2. The Estimate — Conduct the 7 Question Maritime Tactical Estimate: reconnaissance, intent, effects, terrain, forces, coordination, and control
3. Battle Plan — Turn approved effects into task assignments with owners, dependencies, and file ownership
4. Form the Squadron — Choose an execution mode (single-session, subagents, agent team, workflow, or hybrid workflow) and size the team
5. Get Permission to Sail — Present the plan for user approval before committing resources
6. Quarterdeck Rhythm — Run checkpoints to track progress, identify blockers, monitor hull integrity, and manage budget
7. Action Stations — Classify tasks by risk tier and enforce verification before marking complete
8. Stand Down — Produce a captain's log with decisions, artifacts, validation evidence, and follow-ups

Why Nelson?

Most agent orchestration tools focus on starting missions. Nelson focuses on completing them safely.

Nelson gives your missions a shared vocabulary: "action stations" instead of "risk tier escalation", "hull integrity" instead of "context window consumption", "man overboard" instead of "stuck agent replacement". The names stick. So do the habits.

• Risk-gated execution — Four station tiers (Patrol through Trafalgar) classify every task before it runs. High-risk work requires human confirmation; low-risk work flows without ceremony.
• Damage control built in — Eleven named procedures for stuck agents, context exhaustion, faulty output, budget overruns, automated alarms, and mission abort. These are protocols, not improvisation.
• A decision log by default — Captain's log, quarterdeck reports, and turnover briefs are written as the mission runs. Every decision is auditable after the session ends.

Nelson coordinates its own development — recent releases have been planned and executed as Nelson missions.

Who is this for?

• You run Claude Code missions spanning multiple files or modules in parallel
• You want structured checkpoints, risk classification, and a decision log
• You've lost work to context exhaustion and want systematic handover procedures
• You care about auditability — knowing what was decided, by which agent, and why

It may be overkill if you're doing a quick, single-file edit.

How Nelson compares

Nelson trades upfront setup time for coordination guarantees:

| Approach | Best when | Trade-off | |---|---|---| | Nelson Navy structure | You need repeatable quality gates, explicit ownership, and a clear decision log across parallel work | More setup and coordination overhead up front | | OmO/RuFlo-style rapid flow | You need the fastest possible movement on a narrow, low-risk path | Less formal checkpointing and role separation |

If you need fast parallel execution with minimal ceremony, OmO or RuFlo may suit you better. If coordination, auditability, and safe scaling matter more than raw tempo, Nelson is the better fit.

How it works

Execution modes

The skill selects one of five execution modes based on your mission:

| Mode | When to use | How it works | |------|------------|--------------| | single-session | Sequential tasks, low complexity, heavy same-file editing | Claude works through tasks in order within one session | | subagents | Parallel tasks where workers only report back to the coordinator | Claude spawns subagents that work independently and return results | | agent-team | Parallel tasks where workers need to coordinate with each other | Claude creates an agent team with direct teammate-to-teammate communication | | workflow | Large fan-out audits, repeatable migrations, codebase-wide analysis, or cross-checked research | Nelson writes a Workflow Charter and verification contract for one approved dynamic workflow run | | hybrid-workflow | Workflow-suitable missions that need probes, Station 2/3 controls, or human approval between stages | Nelson gates a sequence of separate workflow runs, reviewing telemetry and outputs before the next stage |

Dynamic workflows and ultracode

Claude Code dynamic workflows move orchestration into workflow scripts that can fan out to many agents, keep intermediate results in script state, and aggregate broad review or migration results. Nelson does not replace that mechanism. Nelson wraps it with doctrine: Sounding-the-Channel probes, explicit permission gates, cost guardrails, audit logs, and verification contracts before findings or edits are accepted.

ultracode is treated as a Claude Code xhigh effort/automation setting, not a Nelson execution mode. If ultracode or the user chooses a workflow, Nelson still supplies the mission charter, risk tiering, human gates, telemetry expectations, and fallback mode.

Standing goals

For long autonomous, headless, or scheduled runs, Nelson aligns with Claude Code's /goal — a session-scoped Stop hook that keeps the session from stopping until a completion condition is met. Nelson composes the condition from the sailing orders (nelson-data.py goal-condition) so it stays tied to the mission's outcome, metric, and stop criteria, and phrases it against what the goal evaluator can actually see: the conversation transcript. The standing goal and Nelson's Mission Complete Gate reinforce each other — the gate is the discipline the admiral applies, the goal is the harness backstop that enforces it. See references/goal-alignment.md.

Chain of command

Nelson uses a three-tier hierarchy. The admiral coordinates captains, each captain commands a named ship, and crew members aboard each ship do the specialist work.

                          ┌───────────┐
                          │  Admiral  │
                          └─────┬─────┘
                  ┌─────────────┼─────────────┐
                  ▼             ▼             ▼
           ┌───────────┐ ┌───────────┐ ┌───────────┐
           │  Captain   │ │  Captain   │ │ Red-Cell  │
           │ HMS Daring │ │ HMS Kent   │ │ Navigator │
           └─────┬─────┘ └─────┬─────┘ └───────────┘
            ┌────┼────┐   ┌────┼────┐
            ▼    ▼    ▼   ▼    ▼    ▼
           XO  PWO  MEO  PWO  NO  COX

Squadron level:

• Admiral — Coordinates the mission, delegates tasks, resolves blockers. Coordinates final synthesis but does not perform it directly. There is always exactly one.
• Captains — Each commands a named ship. Breaks their task into sub-tasks, crews specialist roles, coordinates crew, and verifies outputs. Implements directly only when the task is atomic. Typically 2-7 per mission.
• Red-cell navigator — Challenges assumptions, validates outputs, and checks rollback readiness. Added for medium/high risk work.

Ship level (crew per captain, 0-4 members):

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

Navigating Officer (NO) and Coxswain (COX) are read-only — they report findings but never modify files.

Ships are named from real Royal Navy warships, matched roughly to task weight: frigates for general-purpose, destroyers for high-tempo, patrol vessels for small tasks, historic flagships for critical-path, and submarines for research.

Squadron size caps at 10 squadron-level agents (admiral, captains, red-cell navigator). Crew are additional — up to 4 per ship. If a task needs more crew, split it into two ships.

Action stations (risk tiers)

Every task is classified into a risk tier before execution. Higher tiers require more controls:

| Station | Name | When | Required controls | |---------|------|------|-------------------| | 0 | Patrol | Low blast radius, easy rollback | Basic validation, rollback step | | 1 | Caution | User-visible changes, moderate impact | Independent review, negative test, rollback note | | 2 | Action | Security/compliance/data integrity implications | Red-cell review, failure-mode checklist, go/no-go checkpoint | | 3 | Trafalgar | Irreversible actions, regulated/safety-sensitive | Minimal scope, human confirmation, two-step verification, contingency plan |

<img width="1024" height="559" alt="image" src="https://github.com/user-attachments/assets/2d0bf2ea-3f26-4751-9faa-71eca6be07b3" />

Tasks at Station 1 and above also run a failure-mode checklist:

• 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?

Damage control

Most agent frameworks assume the happy path. Nelson includes battle-tested procedures for when things go wrong — stuck agents, budget overruns, faulty outputs, and context window exhaustion all have documented recovery paths