Nelson: a Royal Navy command framework for Claude Code missions

The problem Nelson targets: missions that start but do not finish

The README states the premise directly: most agent orchestration tools focus on starting missions, while Nelson focuses on completing them safely. That is a narrower claim than it first appears, and it is the one worth evaluating. Starting a Claude Code task is easy. Keeping a multi-file migration coherent across parallel workers, knowing which agent touched which file, and reconstructing why a decision was made three sessions later are the parts that break down. Nelson frames those as command problems rather than prompting problems, and borrows Royal Navy vocabulary to make the abstractions memorable: action stations for risk tier escalation, hull integrity for context window consumption, man overboard for stuck agent replacement. The README argues the names stick, and so do the habits. Whether naval metaphor aids recall is a matter of taste, but the underlying objects are real: a risk tier, a context budget, a replacement procedure. The target user is someone running Claude Code missions spanning multiple files or modules in parallel, who wants structured checkpoints and a decision log, and who has already lost work to context exhaustion. The README is explicit that it may be overkill for a quick, single-file edit.

The eight-step mission loop and the 7 Question Maritime Tactical Estimate

The framework is an eight-step sequence. Sailing Orders define the outcome, success metric, constraints and stop criteria. The Estimate runs what the README calls the 7 Question Maritime Tactical Estimate: reconnaissance, intent, effects, terrain, forces, coordination and control. The Battle Plan converts approved effects into task assignments with owners, dependencies and file ownership. Form the Squadron picks an execution mode and sizes the team. Get Permission to Sail presents the plan for user approval before resources are committed. Quarterdeck Rhythm runs checkpoints for progress, blockers, hull integrity and budget. Action Stations classifies tasks by risk tier and enforces verification before a task is marked complete. Stand Down produces a captain's log with decisions, artifacts, validation evidence and follow-ups. Two details in that list carry more weight than the rest. File ownership is assigned at planning time, which is what prevents two parallel captains from editing the same module. Stop criteria are written before execution begins, which is the mechanism that makes the budget checkpoint meaningful rather than decorative. The README counts four risk tiers, eleven damage control procedures, eleven mission templates, seven crew roles and sixteen standing orders, so the vocabulary is not purely cosmetic; each named concept maps to a definition somewhere in the skill.

Five execution modes and where dynamic workflows fit

Mode selection is the part of Nelson with the clearest operational consequence. The README lists five modes. single-session suits sequential, low-complexity work with heavy same-file editing. subagents suits parallel tasks where workers only report back to the coordinator. agent-team suits parallel tasks where workers need to talk to each other directly. workflow suits large fan-out audits, repeatable migrations, codebase-wide analysis and cross-checked research, and in that mode Nelson writes a Workflow Charter and verification contract for one approved dynamic workflow run. hybrid-workflow gates a sequence of separate workflow runs, reviewing telemetry and outputs between stages. The README is careful about the boundary: Claude Code dynamic workflows move orchestration into workflow scripts that fan out to many agents, keep intermediate results in script state, and aggregate broad review results. Nelson does not replace that mechanism. It wraps it with what the README calls doctrine: Sounding-the-Channel probes, explicit permission gates, cost guardrails and audit logs. That is the honest description of the project's layer. If you already use dynamic workflows and only want them to run faster, Nelson adds a wrapper you did not ask for. If you use them and cannot reconstruct afterwards which stage produced which artifact, the wrapper is the point.

Installation, invocation and the prerequisites the README flags

Installation is two plugin commands: /plugin marketplace add harrymunro/nelson followed by /plugin install nelson@nelson-marketplace. There is no slash command to invoke the skill afterwards. The README says you describe your mission in natural language and Nelson loads automatically, giving the example: Use Nelson to migrate the payment module from Stripe v2 to v3. From there the README describes the expected sequence: draft sailing orders, present a battle plan for approval, form a squadron of captains to execute in parallel, run quarterdeck checkpoints, and produce a captain's log when the mission stands down. The full agent-team experience with split panes is listed under Prerequisites rather than Installation, which is worth reading before you assume parallel captains will appear in your terminal. The README also points to external Claude Code documentation for subagents, agent teams and dynamic workflows, which means Nelson inherits whatever those features require in your Claude Code build. The customisation section exists in the table of contents but the supplied README text does not include its body, so the exact set of user-editable files is not something I can confirm from this material. The repository is Python, MIT licensed, with no homepage listed and the default branch named main.

Damage control as protocol, not improvisation

The eleven named damage control procedures are the most distinctive claim in the README, which lists stuck agents, context exhaustion, faulty output, budget overruns, automated alarms and mission abort among the cases they cover, and describes them as protocols rather than improvisation. The distinction matters. A protocol has a trigger, a defined response and a written outcome, which means a context exhaustion event produces a handover artifact instead of a silently truncated session. The README also ties the captain's log, quarterdeck reports and turnover briefs to the running mission rather than to the end of it, so the audit trail is written as work proceeds. That is a design choice with a cost the README acknowledges indirectly: more setup and coordination overhead up front. Damage control procedures only pay off if the failure they describe actually occurs. On a mission that runs clean, you have paid for eleven procedures and used none. The supplied README does not enumerate all eleven by name, so I cannot describe the trigger conditions for each. Anyone deciding whether to adopt should read the damage control definitions before installing, particularly the context exhaustion and mission abort entries, because those are the two that determine whether the framework saves work or merely documents its loss.

Risk tiers, trust calibration and the release history

The four station tiers, named Patrol through Trafalgar, classify every task before it runs. High-risk work requires human confirmation; low-risk work flows without ceremony. That gradient is what keeps the framework from becoming pure ceremony, since a tier system that gated everything would stall on trivial edits. Release naming suggests the tier logic has been extended over time. v2.3.0 is titled Override-Learned Trust Calibration, which implies the skill adjusts how much it trusts a given class of action based on how often a human has overridden it. v2.2.4 is titled Learned Standing Orders, and v2.4.0, the most recent release at the time of writing, is Dynamic Workflows and Standing Goals. The README notes that Nelson coordinates its own development and that recent releases have been planned and executed as Nelson missions. That is a real dogfooding signal, but it is also a closed loop: the framework's own release process is the primary evidence offered for the framework's suitability, and the README does not present an external case study. The trust calibration feature in particular is described only by its release title in the material available, so the mechanism by which overrides feed back into behaviour is not something I can confirm.

Where Nelson is the wrong tool, and what to use instead

The README names its own limits. A quick, single-file edit does not need sailing orders, a tactical estimate, a battle plan and a captain's log, and the framework's own comparison table concedes more setup and coordination overhead up front. The alternative it names is the OmO and RuFlo family of rapid flow tools, described as best when you need the fastest possible movement on a narrow, low-risk path, with less formal checkpointing and role separation. The difference in approach is structural rather than a matter of degree. OmO and RuFlo optimise for tempo on a constrained path; Nelson optimises for coordination guarantees across parallel work, with explicit owners, dependencies and file ownership assigned at planning time. If your mission is a codebase-wide audit that fans out to many agents and you need to know afterwards which agent produced which finding, the rapid flow tools give you less to reconstruct from. If your mission is a two-file change and you want it done in one pass, Nelson's eight steps are pure overhead. The README's framing is that Nelson is the better fit when coordination, auditability and safe scaling matter more than raw tempo, and that is a fair summary of the trade rather than a claim of general superiority.

Maintenance cost, licence and what to verify before adopting

Nelson is MIT licensed, which permits commercial and private use with the licence and copyright notice retained. That is a permissive baseline, and nothing in the supplied material suggests additional terms, but MIT says nothing about the operational cost of running the framework, which is where the real expense sits. The maintenance surface is the skill's own definitions: sixteen standing orders, eleven damage control procedures, eleven mission templates and seven crew roles, all of which are vocabulary your team has to learn before the checkpoints mean anything. The release cadence shown is three releases in roughly two months, v2.2.4 in May, v2.3.0 in June and v2.4.0 in July 2026, which is frequent enough that pinned behaviour may shift between missions. The README's compatibility notes section exists in the table of contents but its body is not in the supplied text, so I cannot state which Claude Code versions are supported. Verify three things before installing: that your Claude Code build exposes subagents, agent teams and dynamic workflows, since the mode table depends on them; that the split-pane agent-team experience described under Prerequisites works in your terminal; and that the damage control procedure for context exhaustion produces a handover artifact you would actually use. If the third check fails, the framework's central promise does not hold for your setup.

Editorial conclusion

Adopt Nelson if your Claude Code work spans multiple files or modules in parallel, you have lost work to context exhaustion, and you need an auditable record of who decided what. Skip it for one-file edits or narrow low-risk changes where the eight-step framework costs more than it saves. Before installing, verify that your Claude Code build exposes the agent-team and dynamic workflow features the execution mode table depends on, and read the damage control definitions for context exhaustion and mission abort, since those are the procedures you will actually lean on.

Official sources

1. Aspegio/nelson on GitHub
2. Issues
3. License: MIT
4. README
5. Releases