nelson

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.

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

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

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