🇺🇸English

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.

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.

Admiralty Action List: For each task, consciously mark admiralty-action-required: as yes or no. Then scan the battle plan for tasks marked admiralty-action-required: yes. If any exist, surface an Admiralty Action List to the user before spawning any agents:

ADMIRALTY ACTION LIST — Actions required from Admiralty

1. [Task name]
   action: [what you must do]
   timing: [before task starts | after task completes]
   unblocks: [task name or stand-down]

No action needed now. These will be raised by the captain when each step is reached.

If no tasks are marked admiralty-action-required: yes, omit the list — no noise on routine missions. This list is informational, not a gate. The user acknowledges by continuing the conversation. Squadron formation proceeds immediately after.

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.
  • Stand down completed ships immediately — see references/standing-orders/paid-off.md. Only hold a ship if a named re-task trigger in the sailing orders has not yet been evaluated.
  • Track burn against token/time budget.
  • Check hull integrity: collect damage reports from all ships, update the squadron readiness board, and take action per . The admiral must also check its own hull integrity at each checkpoint.

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.

Damage Control

Consult the specific procedure that matches the situation.

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.

Weekly Installs

1.2K

Repository

harrymunro/nelson

GitHub Stars

198

First Seen

Feb 13, 2026

Security Audits

Gen Agent Trust HubPassSocketPassSnykPass

Installed on

gemini-cli940

github-copilot940

codex940

opencode940

kimi-cli939

amp939