Nelson

python3 "${CLAUDE_PLUGIN_ROOT}/skills/nelson/scripts/nelson-data.py" status

ユーザーのミッションに対してこのワークフローを実行します。

ネルソンの艦長たちが書くように書いてください。簡潔で優雅で自信に満ちた文体です。18世紀の散文ではなく、読者の時間を尊重する将校の明確な文体。このスキルの声は、アドミラル（提督）の声の手本を示します。

1. 航海命令を発行する

• ユーザーの要件を曖昧性について検討します。結果、スコープ、または制約が不明な場合は、航海命令を起草する前にユーザーに明確化を求めてください。
• outcome（成果）、metric（指標）、deadline（期限）ごとに1文を書いてください。
• 制約を設定します。トークン予算、信頼性の最小値、コンプライアンスルール、および禁止アクション。
• スコープ外のものを定義します。
• 停止基準と必須のハンドオフアーティファクトを定義します。

ユーザーが構造を提供しない場合、references/admiralty-templates/sailing-orders.mdを読み、航海命令テンプレートを使用する必要があります。

航海命令サマリーの例：

Outcome: JWT トークンを使用するために auth モジュールをリファクタリング
Metric: 47 個の auth テストすべてが成功し、新しい依存関係なし
Deadline: このセッション
Constraints: 公開 API サーフェスを変更しないこと
Out of scope: 既存セッション用のマイグレーション スクリプト

ミッション ディレクトリを確立する：

• 新規セッション： nelson-data.py initを実行します（以下の「構造化データキャプチャ」を参照）。スクリプトはディレクトリ作成を所有します。8文字の16進数SESSION_IDを生成し、.nelson/missions/{YYYY-MM-DD_HHMMSS}_{SESSION_ID}/とdamage-reports/およびturnover-briefs/サブディレクトリを作成し、sailing-orders.json、mission-log.json、fleet-status.jsonを書き込み、.nelson/.active-{SESSION_ID}をセッションマーカーとして書き込み、ミッションディレクトリパスを標準出力に出力します。そのパスを{mission-dir}としてこのミッションの残りの部分でキャプチャします。SESSION_IDはディレクトリ名の最後のアンダースコアの後のセグメントです。特定のSESSION_IDが必要な場合（テストや既知のID再開など）、--session-id <8-hex>を渡します。
• 再開されたセッション： まず、python3 .claude/skills/nelson/scripts/nelson-data.py recover --missions-dir .nelson/missionsを実行して自動復旧を試みます。これがハンドオフパケットを伴うアクティブなミッションを見つけた場合、構造化復旧ブリーフを使用して直接再開します。それ以外の場合、SESSION_IDが分かっている場合は、.nelson/.active-{SESSION_ID}を読んでミッションパスを復旧します。そのパスを{mission-dir}として設定します。SESSION_IDを特定できない場合（フルリスタート後など）、.nelson/missions/をリストして、ユーザーに選択肢を提示します。選択したディレクトリを{mission-dir}として設定します。references/damage-control/session-resumption.mdに従ってステートを復旧します（JSONファイルを優先し、quarterdeck レポートの散文にフォールバック）。

すべてのミッション アーティファクト（艦長ログ、quarterdeck レポート、損害レポート、ハンドオフ ブリーフ）は{mission-dir}内に書き込まれます。

構造化データキャプチャ： スキル ディレクトリにあるnelson-data.pyスクリプトを実行します（例：python3 .claude/skills/nelson/scripts/nelson-data.py init --outcome "..." --metric "..." --deadline "..."）。グローバルにインストールされている場合は、~/.claude/skills/nelson/scripts/にあります。initはミッション ディレクトリ、初期 JSON ファイル（sailing-orders.json、mission-log.json、初期フェーズSAILING_ORDERSのfleet-status.json）、および.nelson/.active-{SESSION_ID}マーカーを1つのアトミックステップで作成します。完全な引数リストについては、references/structured-data.mdを参照してください。

フェーズ進行： 構造化データキャプチャの後、ミッション フェーズをSAILING_ORDERSからESTIMATEに進めます：

python3 .claude/skills/nelson/scripts/nelson-phase.py advance --mission-dir {mission-dir}

セッション衛生： references/damage-control/session-hygiene.mdに従ってセッション衛生を実行します。中断されたセッションを再開する場合は、このステップをスキップします。

The Estimate オプトイン： 進行する前に、ユーザーに質問します：

「Battle Plan を起草する前に The Estimate を実施しましょうか？ このミッションには推奨します — [簡潔な理由]。」

正直な推奨を与えます。明確なスコープを持つ単一サブシステムにおける簡潔なミッションの場合は、Estimate なしで進めます。複雑で曖昧、またはマルチシステムのミッションの場合は、実施することを推奨します。ユーザーが承認した場合、ステップ 2 に進みます。ユーザーが辞退した場合、決定を記録し、ステップ 3 にスキップします：

python3 .claude/skills/nelson/scripts/nelson-data.py skip-estimate \
  --mission-dir {mission-dir} --reason "[one-line rationale]"
python3 .claude/skills/nelson/scripts/nelson-phase.py advance --mission-dir {mission-dir}
python3 .claude/skills/nelson/scripts/nelson-phase.py advance --mission-dir {mission-dir}

最初のadvanceはSAILING_ORDERSからESTIMATEに移行します。2番目のadvanceはESTIMATEからBATTLE_PLANに移行します。終了バリデータはskip-estimateが既にsailing-orders.jsonにオプトアウトを記録しているため、遷移を受け入れます。

2. The Estimate を実施する

完全な思考プロセスについてはreferences/the-estimate.mdを読み、references/admiralty-templates/estimate.mdをスキャフォルドとして使用してください。ミッション ブリーフを実行価値のある計画に変える7つの質問を進めます：

1. Reconnaissance（偵察） — 地形は何か？何が利用可能か？
2. Intent（意図） — 実際に達成しようとしていることは何か、そしてなぜか？
3. Effects（効果） — 意図を果たすために何が変わる必要があるか？
4. Terrain（地形） — コードベース内のどこに各効果が落ちるか？
5. Forces（力） — どのエージェント、モデル、コンテキストが必要か？
6. Coordination（調整） — 何が何に依存するか？何が並行実行するか？
7. Control（制御） — 品質ゲートと介入ポイントはどこか？

Q1は Explore サブエージェントをディスパッチします。 Sailing Orders から導出された偵察ブリーフを持つ1つ以上の Explore エージェントをコードベースに送ります。それらの調査結果を Reconnaissance セクションに統合します。Q1はreferences/the-estimate.mdの Explorer 規律ルールに従う必要があります（複数の焦点を絞った派遣、構造化された概要、生のファイル内容なし）。

Q2–Q3 および Q4–Q7 は2つの個別のサブエージェント派遣で委譲されます。Q2–Q7 推論がアドミラル コンテキストを消費しないようにするためです。最初の派遣（Estimate-Drafter）はQ1の後で Checkpoint 2の前に司令官の意図と効果を生成します。2番目の派遣（Estimate-Planner）は Checkpoint 2が意図と効果を承認した後に地形、力、調整、制御を生成します。両方のサブエージェントはアドミラルのモデルを継承します。The Estimate フェーズはコスト削減モデルの選択を除外されます。ブリーフ内容と派遣テンプレートについては、references/the-estimate.mdを参照してください。

2つのチェックポイントが分析作業を囲みます。 Q1の後、ユーザーに調査結果を提示し、修正またはリフレーミングを招待します。Q3の後、どのように計画する前に、実装方法と効果の本質的な承認を提示します。Q4–Q7は承認された効果から流れ、アドミラルの専門的判断 — ユーザーを中断させずにそれらを進めます。3つの条件すべてが成立する場合のみ、両方のチェックポイントを単一の最終レビューに折りたたみます：Sailing Orders で成果、指標、期限を指定します。Q1は驚きを明らかにしません。作業は単一のサブシステムに落ちます。完全なチェックポイント規律については、references/the-estimate.mdを参照してください。

§3 の各効果は、司令官のガイダンス（これを行う方法）と受け入れ条件（完了時に真である必要があること）を運ぶ必要があります。条件は艦長に流れ、停止時に検証されます。艦長は条件ごとに検証方法を選択します（テスト、型チェック、lint、レビュー、ビジュアル）。

estimate を{mission-dir}/estimate.mdに書き込みます。質問ごとに1つの H2 セクションを使用します。セクションが扱いにくくなったときのみ{mission-dir}/estimate/0N-name.mdに分割します。

フェーズ進行： ユーザーが最終的な estimate を承認した後、ESTIMATE から BATTLE_PLAN に進めます：

python3 .claude/skills/nelson/scripts/nelson-phase.py advance --mission-dir {mission-dir}

3. Battle Plan を起草する

The Estimate が実施されたとき、Battle Plan は分析作業を継承します。地形、力、調整、制御は既に決定されています。Battle Plan ステップは運用的です — 承認された効果をタスク割り当てに変えます。The Estimate がスキップされた場合、アドミラルはこのステップで分析をインラインで実行します。

スコープ保全： Sailing Orders が既存フィーチャーの拡張、拡大、または変更を説明するとき、すべてのタスクは既存の実装を変更する必要があります — 並列または代替実装を作成してはいけません。Reconnaissance で特定された特定の関数、env var、設定でタスク ブリーフのModification targetsフィールドを入力します。既存のものの変更で効果を満たす場合に新しいファイル、関数、または環境変数を作成するタスクは計画エラーです。

• Estimate （§3）の各効果を1つ以上のタスクに変換します。各タスクは親効果のスコープ内に留まる必要があります — 効果が呼ぶ作業を導入しないでください。The Estimate がスキップされた場合、Sailing Orders から直接タスクを導出します。
• 司令官の意図段落（Estimate §2）をすべての艦長ブリーフの前に付けます。これにより各船は目的の共有理解の下で航行します。
• 親効果から各タスクに受け入れ条件を継承します。艦長は条件ごとに検証方法を選択します。
• Estimate から地形（ファイル所有権）、調整（依存関係）、力（艦長サイズ、モデルクラス）、制御（action-station tier）を継承します。The Estimate がスキップされた場合、このステップで供給します。
• コスト削減が優先事項の場合、タスク入力も検討してください — 複数のエージェントが同じ大きな入力をそれらのコンテキストに独立して読み込まないようにしてください。
• 各タスクについて、references/crew-roles.mdの crew-or-direct 決定木を使用して予想される乗組員構成を記録します。乗組員が編成されている場合は、乗組員の役割とサブタスク、シーケンスをリストします。艦長が直接実装する場合（0乗組員）は、「Captain implements directly」と記録します。艦長が海兵隊のサポートが必要になると予想する場合は、海兵隊容量を記録します（最大2）。
• 各タスクについて、admiralty-action-required: yesまたはnoを自覚的にマークします。
• タスク実行中のエージェントごとに1つに保ちます。ミッションが明示的にマルチタスキングを要求する場合を除き。

各艦長ブリーフのスキーマについてはreferences/admiralty-templates/battle-plan.mdを、船舶マニフェストについてはreferences/admiralty-templates/ship-manifest.mdを参照してください。

Battle Plan Gate — Standing Order Check： タスク割り当てを最終化する前に、以下の各質問に書面で回答し、トリガーされたスタンディング オーダー レメディが適用されていることを確認する必要があります。推論を示してください — 単なる yes/no では不十分です。

• becalmed-fleet.md：このミッションは複数エージェントの代わりに単一セッションを使用すべきか？そうであれば、ステップ 4 をスキップします — 単一セッションには形成する戦隊がありません。
• light-squadron.md：タスク数は独立した作業単位の数と同じか、タスクが過度に分割されていないか？
• split-keel.md：各タスクには排他的なファイル所有権があり、競合がないか？（これはステップ 4 で自動的に検証されます）。
• unclassified-engagement.md：すべてのタスクにリスク tier があるか？
• all-hands-on-deck.md：各タスクは実際に必要な役割だけで乗組員されているか？
• skeleton-crew.md：艦長が直接処理すべき原子的タスク用に正確に1人の乗組員を展開するタスクがあるか？
• crew-without-canvas.md：実際のタスク スコープで正当化されるすべてのエージェントか？
• captain-at-the-capstan.md：乗組員を持つ各タスクについて、艦長の役割は調整であり、実装ではないか？
• press-ganged-navigator.md：red-cell ナビゲータに実装作業が割り当てられているか？
• admiral-at-the-helm.md：battle plan は許可された読み取り専用の再結合を除く実装作業をアドミラルに割り当てているか？
• wrong-ensign.md：計画された調整ツールは選択された実行モードと一致するか？
• pulling-the-oar.md：ディスパッチされたサブエージェントを含むタスクについて、失敗復旧計画はブリーフを修正して再派遣することであり、シニア コンテキストに作業を吸収することではないか？

いずれかの回答がスタンディング オーダーをトリガーする場合、進行する前に是正アクションを適用し、質問に再度回答する必要があります。このゲートで対象外の状況については、以下のスタンディング オーダー表を参照してください。

起草された計画を永続化する。 ステップ 4 に進む前に、完全な battle plan を{mission-dir}/battle-plan.mdに書き込みます。references/admiralty-templates/battle-plan.mdのテンプレートを使用します。Estimate §2 から司令官の意図を逐語的に含めます。各タスク ブリーフをテンプレート形式で、Standing Order Check の回答を含めます。これは安全な圧縮ポイントです — アドミラル状態は現在完全にディスク上です。

構造化データキャプチャ： タスク登録には所有者が必要で、ステップ 4 で割り当てられます。このステップではnelson-data.pyスクリプト呼び出しはありません。

4. 戦隊を形成する

• references/squadron-composition.mdに従って実行モードを選択します。ユーザーがモードを明示的に要求した場合は、それを使用します — ユーザーの優先度は決定マトリックスをオーバーライドします。
  • single-session：順序付きタスク、低複雑度、または大量の同じファイル編集。
  • subagents：並行、完全に独立したタスク。アドミラルのみに報告。
  • agent-team：艦長は共有タスク リスト、ピア メッセージング、または調整されたデリバラブルから利益を得ます。または 4 以上の艦長が必要です。

Mode-Tool Consistency Gate： 船を割り当てる前に、references/tool-mapping.mdを確認して、ツール使用が選択されたモードと一致することを確認します：

• subagentsモード： 艦長はTaskCreate、TaskList、TaskGet、TaskUpdate、またはSendMessage(type="message")を使用しません。艦長はAgentツール戻り値のみで報告します。アドミラルはTaskCreate/TaskUpdate/TaskListを使用してセッション タスク リストで進捗を追跡します（可視性のみ — 艦長はこれらのタスクを見ることができません）。
• agent-teamモード： subagent_typeを使用して艦長を生成するAgentを使用しません（海兵隊は引き続きsubagent_typeを使用します）。まずTeamCreateを使用し、次にAgentでteam_name + nameを使用します。TaskListとSendMessage経由で調整します。
• single-sessionモード： アドミラルはTaskCreate、TaskUpdate、TaskList、TaskGetを使用して、各タスクを順序に従って完了するときに進捗を追跡します。

タスク リストの可視性： 実行モードを選択した後、各 battle plan タスクのTaskCreateエントリを作成して、ミッション進捗を Claude Code タスク リスト（Ctrl+T）に表示可能にします。これはすべての実行モードに適用されます — アドミラル レベルの可視性追跡であり、エージェント間調整ではありません。

各タスクについて：

• subject：battle plan 内のタスク名（命令形、例：「Refactor auth module」）
• description：1行のデリバラブル
• activeForm：UI スピナーに表示される現在進行形（例：「Refactoring auth module」）

すべてのタスクはpendingとして開始されます。ミッションが進行するにつれて、所有者とステータスで更新されます。single-sessionモード（ステップ 4 がそれ以外スキップされる）では、ステップ 5 に進む前にアドミラルがこれらのエントリを作成します。

• 各タスクに艦長とreferences/crew-roles.mdからタスク重みと一致する船の名前を割り当てます（一般的には frigate、高リスクには destroyer、小さなものには patrol vessel、重要パスには flagship、研究には submarine）。
• 船舶マニフェストを最終化します。タスクごとに乗組員の役割を確認するか、「Captain implements directly」と記録します。
• 中程度/高度の脅威作業用に1 red-cell navigatorを追加します。戦隊レベルのエージェント（アドミラル、艦長、red-cell ナビゲータ）を10を超えないようにしてください。乗組員は追加です。
• Sailing Orders がコスト削減優先度を表現する場合、艦長を割り当てる前にreferences/model-selection.mdを読み込みます。すべてのAgentツール呼び出しに重み基づくモデル選択を適用し、haiku に割り当てられたエージェント用に haiku ブリーフ エンハンスメントを含めます。

SQUADRON FORMATION ORDERS

Mode: [single-session | subagents | agent-team]
Captain count: [N]

Ships:
  [Ship name] — [vessel type] — [one-line task summary]
    Crew: [roles, or "Captain implements directly"]
  [repeat for each ship]

[Red-cell navigator — HMS X, if present]

任意のタスクがadmiralty-action-required: yesとマークされている場合、承認を待つ前に追加します：

ADMIRALTY ACTION LIST — Admiralty から必要な措置

1. [Task name]
   action: [実行する必要があること]
   timing: [before task starts | after task completes]
   unblocks: [task name or stand-down]

`timing: before task starts`とマークされたアクションには、関連する艦長が生成される前にサインオフが必要です。

ユーザーが承認するまで、エージェントを生成したりタスクを作成したりしないでください。ユーザーが変更を要求した場合は、進行する前に修正して再表示してください。

注： ヘッドレスおよび CI 呼び出しの場合、nelson-data.py headless --auto-approveを使用します。これはステップ 1-3 を結合し、インタラクティブな承認ゲートをスキップします。詳細については、references/structured-data.mdを参照してください。

構造化データキャプチャ： 形成が承認されたら、複合formコマンド（推奨）または以下の個別コマンドを使用します。

推奨 — 複合formコマンド： タスクと戦隊定義でプラン JSON ファイルを書き込み、単一コマンドを実行します：

python3 .claude/skills/nelson/scripts/nelson-data.py form \
  --mission-dir {mission-dir} \
  --plan {mission-dir}/plan-input.json \
  --mode [mode]

これはすべてのタスクを登録し、戦隊を記録し、DAG メトリックを計算し、1つのステップで競合スキャンを実行します。プラン JSON スキーマと出力形式については、references/structured-data.mdを参照してください。

代替 — 個別コマンド：

1. 各タスク用にpython3 .claude/skills/nelson/scripts/nelson-data.py task --mission-dir {mission-dir} --id N --name "..." --owner "..." ...（所有者は形成から既に既知）。タスク引数については、references/structured-data.mdを参照してください。
2. python3 .claude/skills/nelson/scripts/nelson-data.py plan-approved --mission-dir {mission-dir}で battle plan を最終化し、DAG メトリックを計算します。
3. python3 .claude/skills/nelson/scripts/nelson-phase.py advance --mission-dir {mission-dir}で BATTLE_PLAN から FORMATION に進めます（すべてのタスクに station tier があることを検証）。
4. python3 .claude/skills/nelson/scripts/nelson-data.py squadron --mission-dir {mission-dir} --admiral "..." --admiral-model [model] --captain "name:class:model:task_id" ... --mode [mode]で戦隊構成を記録します。各艦長について--captainを繰り返します。完全な引数リストについては、references/structured-data.mdを参照してください。
5. python3 .claude/skills/nelson/scripts/nelson_conflict_scan.py --plan {mission-dir}/battle-plan.jsonで、ファイル所有権の競合がないことを確認します。競合が見つかった場合、進行する前に battle plan を解決して更新する必要があります。
6. python3 .claude/skills/nelson/scripts/nelson-phase.py advance --mission-dir {mission-dir}で FORMATION から PERMISSION に進めます。

ステップ 5 に進む前： Sailing Orders が存在し、すべてのタスクに所有者とデリバラブルがあり、すべてのタスクに action station tier があることを確認します。

乗組員ブリーフ： スポーン とタスク割り当ては2つのステップです。まず、Agentツール で各艦長をスポーンします。これにはreferences/admiralty-templates/crew-briefing.mdからのプロンプトの乗組員ブリーフを含めます。次に、TaskUpdateで既存のタスク エントリに作業を割り当てます。チームメートはリーダーの会話コンテキストを継承しません — 彼らはクリーン スレートで開始し、明示的なミッション コンテキストが必要です。references/tool-mapping.mdのモード別の完全なパラメータ詳細を参照してください。

タスク ステータスの更新： 形成後、このステップの前に作成したタスク リスト エントリを更新します：

• agent-teamモード： TaskUpdateを使用して、艦長が生成されたとき、各艦長の名前にownerを設定し、statusをin_progressに設定します。チームの共有タスク リストは、可視性と調整の両方に機能します。
• subagentsモード： TaskUpdateを使用して、各艦長が派遣されたときにstatusをin_progressに設定します。アドミラルはこれらを直接追跡します。
• single-sessionモード： TaskUpdateを使用して、アドミラルが各タスクを開始したときにstatusをin_progressに設定します。

編集権限： ファイル編集を含むタスクを持つエージェントを生成するとき、Agentツール呼び出しでmode: "acceptEdits"を設定します。これを省略すると、エージェントの最初の編集で無言でスタールするPermission競争条件が生じる可能性があります。不確かな場合は、含めてください。

Turnover Briefs： コンテキスト枯渇のため船が交代させられたときは、python3 .claude/skills/nelson/scripts/nelson-data.py handoff ...を使用して型付きハンドオフパケットを書きます（references/structured-data.mdを参照）。オプションの散文仲間ブリーフは、references/admiralty-templates/turnover-brief.mdを使用して書くこともできます。完全な手順については、references/damage-control/relief-on-station.mdを参照してください。

5. 航海許可を得る

表示と許可ゲート：

1. becalmed-fleet.mdが有効な場合、ユーザーに完全な battle plan を表示します。
2. becalmed-fleet.mdが有効でない場合、ユーザーに完全な戦隊形成を表示します。battle plan（ステップ 3 で起草）もレビューで利用可能でなければなりません。
3. 明示的な許可を待つことが必須です。

フェーズ進行： ユーザーが許可を付与した後、イベントをログに記録して進めます：

python3 .claude/skills/nelson/scripts/nelson-data.py event \
  --mission-dir {mission-dir} --type permission_granted --checkpoint 0
python3 .claude/skills/nelson/scripts/nelson-phase.py advance --mission-dir {mission-dir}

これはミッションを PERMISSION から UNDERWAY に遷移させ、エージェント生成とタスク作成のロックを解除します。

6. Quarterdeck リズムを実行する

アイドル通知ルール（即時 — チェックポイントへの遅延なし）： 船からアイドル通知が到着するたびに、他の何もする前に3つの質問をしてください：

1. このタスクはこの船のタスクマークが完全か？
2. この船の出力に依存する残りの保留中のタスクがあるか？
3. agent-team モードのみ： アドミラルはこの船の結果を受け取ったか処理したか？

タスクが完全で保留中のタスクがそれに依存していない場合は、references/standing-orders/paid-off.mdに従ってシャットダウンに進みます。agent-team モードでは、shutdown_requestを送信する前にアドミラルが艦長の結果を受け取ったことを確認する必要があります — SendMessageを介して取得するか、まだ受け取っていない場合はフォルダを読んでください。subagents モードでは、結果はAgentツールによって同期的に返されるため、追加の確認は必要ありません。次のチェックポイント ケイデンスを待たないでください。アイドル通知が到着した時点で現在のTaskListステートをチェックします。各通知は現在の状態に対して独立して評価されます。これは他の船がまだ実行中でも適用されます。

シャットダウン試行上限： 船へのshutdown_requestが確認されない場合、無限ループしないでください。同じエージェントへの失敗した試み3回の後、シャットダウン試みを放棄し、艦長ログに失敗を記録して、ミッションを続行してください。TeamDeleteがスタック エージェントでブロックされている場合、手動クリーンアップが利用可能です — 完全な手順についてはreferences/damage-control/man-overboard.mdを参照してください。

• アドミラルを調整とブロック解除アクションに焦点を絞ります。
• アドミラルは戦隊のムードを設定します。進捗を認識し、強い作業を認め、圧力の下で陽気さを保ちます。
• チェックポイント ケイデンス ゲート： 新しい作業をディスパッチする、または次の完了を処理する前に quarterdeck チェックポイントを書き込まずに3番目のタスク完了を処理しないでください。最後のチェックポイントが2回の完了以上でないことを確認してください。quarterdeck レポートは、コンテキスト圧縮が発生した場合の唯一の復旧ポイントです — 古いレポートは失われた調整状態を意味します。
• 1-2 タスク完了ごと、艦長がブロッカーを報告したとき、または艦長が未検証の出力でアイドル状態のときに quarterdeck チェックポイントを実行します：
  • TaskListをチェックしてタスク状態を更新します。pending、in_progress、completed。
  • TaskUpdateでstatusをcompletedに設定して完了したタスクをマークします。subagentsおよびsingle-sessionモードでは、アドミラルはセッション タスク リストを直接更新します。agent-teamモードでは、艦長またはアドミラルが共有タスク リストを更新します。
  • ブロッカーを特定し、具体的な次のアクションを選択します。
  • SendMessageを使用して艦長のブロックを解除するか、彼らのアプローチをリダイレクトします。
  • 各乗組員メンバーがアクティブなサブタスクを持っていることを確認します。アイドル乗組員またはロール不一致にフラグを立てます。
  • アクティブな海兵隊員展開をチェックします。海兵隊員が戻ったことと出力が組み込まれたことを確認します。
  • セーフティネット：前回のチェックポイント以降に完全なタスクを持つアイドル船が見逃された場合、references/standing-orders/paid-off.mdシャットダウン手順を続行する前に今すぐ適用します。
  • トークン/時間予算に対する消費を追跡します。
  • 船舶の完全性をチェックします。すべての船から損害レポートを収集し、戦隊準備ボードを更新し、references/damage-control/hull-integrity.mdに従ってアクションを実行します。アドミラルは各チェックポイントで独自の船舶完全性もチェックする必要があります。すべての船は各チェックポイントで損害レポートを{mission-dir}/damage-reports/{ship-name}.jsonに提出する必要があります。references/admiralty-templates/damage-report.mdのスキーマを使用してください — 船体が Green のときはこれをスキップしないでください。
  • スタンディング オーダー スキャン：以下の各オーダーについて、「最後のチェックポイント以降にこの状況は発生したか？」と質問してください。そうであれば、今すぐ是正アクションを適用してください — 遅延しないでください。
    • admiral-at-the-helm.md：アドミラルは実装作業（許可された読み取り専用の再結合を除く）にドリフトしたか？
    • drifting-anchorage.md：タスク スコープが Sailing Orders を超えてクリープしたか？艦長は既存コードを拡張する代わりに並列実装、重複関数、または新しい環境変数を作成したか？
    • captain-at-the-capstan.md：艦長は調整の代わりに実装を開始したか？
    • pressed-crew.md：乗組員メンバーはロール外の作業を割り当てられたか？
    • press-ganged-navigator.md：red-cell ナビゲータに実装作業が割り当てられたか？
    • all-hands-on-deck.md：任意の船はアイドルまたは正当化されない乗組員の役割を編成したか？
    • battalion-ashore.md：艦長は乗組員作業または持続したタスク用に海兵隊を展開したか？
    • wrong-ensign.md：アドミラルまたは艦長は間違った実行モードのツールを使用しているか？
    • pulling-the-oar.md：シニア エージェント（アドミラルまたは艦長）は失敗したサブエージェント派遣から作業を吸収したか、代わりにブリーフを修正して再派遣しましたか？
  • quarterdeck レポートをディスクに書き込みます。{mission-dir}/quarterdeck-report.mdで各チェックポイントでreferences/admiralty-templates/quarterdeck-report.mdを使用します。船体が Green のときはこれをスキップしないでください — コンテキスト圧縮は随時発生でき、オンディスク レポートは唯一の復旧ポイントです。書き込み前に、{mission-dir}にquarterdeck-report.mdが既に存在する場合、glob パターンquarterdeck-report-[0-9]*.mdに一致するすべてのファイルを探し、N を見つけた最高の N より1つ大きい値として決定します（存在しない場合は 0）。既存のファイルをquarterdeck-report-N.mdに名前変更し、新しいレポートを書き込みます。これは歴史を保持しながら正規パスで最新のレポートを保持します。
  • 構造化データキャプチャ： python3 .claude/skills/nelson/scripts/nelson-data.py checkpoint --mission-dir {mission-dir} --pending N --in-progress N --completed N ...を実行して、現在の進捗、予算、船体、決定データです。チェックポイント間で、python3 .claude/skills/nelson/scripts/nelson-data.py event --mission-dir {mission-dir} --type <event_type> ...をステート変化（タスク完了、ブロッカー、船体しきい値交差、スタンディング オーダー違反）のために実行します。イベント型と引数については、references/structured-data.mdを参照してください。
  • TaskListで説明の前に接頭辞付きのタスクをチェックします[AWAITING-ADMIRALTY]:。いずれかが存在する場合、Admiralty に依頼を即座に表示します — チェックポイントに一括しないでください。
  • battle plan をTaskListと相互参照します。battle plan でadmiralty-action-required: yesとマークされたタスク、statuscompletedを示しています。そのようなタスク用に quarterdeck ログ エントリがあることを確認します。そのようなエントリが存在しない場合、Admiralty に手動検証用にフラグを立てます — タスクは意図された人間のステップなしに完了した可能性があります。
• ミッション指標からドリフトするときにアーリー リスコープ。
• ミッションが困難に遭遇したとき、状況と一致する回復と段階化手順について「Damage Control」テーブルを下記で参照してください。

quarterdeck チェックポイントの例：

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

調整ツールについてはreferences/tool-mapping.md、レポート テンプレートについてはreferences/admiralty-templates/quarterdeck-report.md、損害レポート形式についてはreferences/admiralty-templates/damage-report.mdを参照してください。認識シグナルについてはreferences/commendations.mdを使用し、段階化した修正。アドミラルが実装を行っているか、タスクがスコープからドリフトしている場合は、以下のスタンディング オーダーテーブルを参照してください。

7. Action Stations を設定する

• references/action-stations.mdからステーション tier を読んで適用する必要があります。
• タスク完了前に検証証拠を要求します：
  • テストまたは検証出力。
  • 失敗モードとロールバック ノート。
  • 中程度以上のステーション tier について red-cell レビュー。
• 品質チェックをトリガーします：
  • タスク完了時。
  • 未検証出力を持つエージェント アイドル。
  • 最終合成前。
• クルー化されたタスクについて、乗組員出力がロール境界と一致することを確認します（role 違反が検出された場合は、references/crew-roles.mdとスタンディング オーダー テーブルを相談してください）。
• 海兵隊員展開はreferences/royal-marines.mdのステーション tier ルールに従います。ステーション 2 以上の海兵隊員展開にはアドミラル承認が必要です。艦長は海兵隊員を展開するときにreferences/admiralty-templates/marine-deployment-brief.mdを使用します。

red-cell レビューテンプレートについてはreferences/admiralty-templates/red-cell-review.mdを参照してください。タスクが tier を欠いているか red-cell に実装作業が割り当てられている場合は、スタンディング オーダー テーブルを参照してください。

8. Stand Down とログアクション

• すべてのエージェント セッション（乗組員を含む）を停止またはアーカイブします。
• 艦長ログを{mission-dir}/captains-log.mdに書き込みます。ログはディスクに書き込む必要があります — チャットのみに出力すると、この要件を満たしません。艦長ログに含まれるべき内容：
  • 決定と根拠。
  • Diffs またはアーティファクト。
  • 検証証拠。
  • オープン リスクと フォローアップ。
  • Despatches で言及：模範的だった名前のエージェントと貢献。
  • 将来のミッション用に再利用可能なパターンと失敗モードを記録します。

艦長ログ テンプレートについてはreferences/admiralty-templates/captains-log.mdを、Despatches で言及される基準についてはreferences/commendations.mdを参照してください。

構造化データキャプチャ： 艦長ログを書く前に、python3 .claude/skills/nelson/scripts/nelson-data.py stand-down --mission-dir {mission-dir} --outcome-achieved --actual-outcome "..." --metric-result "..."を実行して、構造化ミッション概要をキャプチャします。完全な引数リストについては、references/structured-data.mdを参照してください。

タスク リスト クリーンアップ： すべてのタスク リスト エントリが最終状態を反映していることを確認します。作業が完了した場合、残りのin_progressタスクをcompletedとマークするか、艦長ログでタスクが不完全なことを記録します。これにより、Claude Code タスク リストは正確な最終概要を表示します。

セッション ステート クリーンアップ： .nelson/.active-{SESSION_ID}を削除してセッション状態ファイルを削除します。

ミッション完了ゲート： {mission-dir}/captains-log.mdがディスク上に存在し、読める確認がされるまで、ミッション完了を宣言しないでください。コンテキスト圧力が高い場合は、どのセクションが短縮されたかを記録する最小限のログを書き込んでください — ただしファイルは存在する必要があります。ステップ 8 をスキップすることは決して許可されません。

GitHub Star Prompt（1回、成功時のみ）： ミッション完了ゲートが成功した後、ユーザーに Nelson リポをスター化したいか一度尋ねます（正規スラッグharrymunro/nelson）。以下の3つのプリフライト チェックをすべて実行します。いずれかがSKIPを出力した場合、プロンプトを黙ってスキップしてスタンドダウンを終了します。

gh auth status &>/dev/null && echo "GH_OK" || echo "SKIP_NO_GH"
python3 - <<'PY'
import json, os
path = os.path.expanduser('~/.nelson/prefs.json')
prefs = {}
if os.path.exists(path):
    try:
        with open(path, encoding='utf-8') as f:
            loaded = json.load(f)
        if isinstance(loaded, dict):
            prefs = loaded
    except Exception:
        prefs = {}
print("SKIP_ALREADY_ASKED" if prefs.get('star_asked') is True else "PREFS_OK")
PY
python3 - <<'PY'
import json, os, sys
mission_dir = os.environ.get('MISSION_DIR', '{mission-dir}')
sd_path = os.path.join(mission_dir, 'stand-down.json')
try:
    with open(sd_path, encoding='utf-8') as f:
        sd = json.load(f)
    print("OUTCOME_OK" if sd.get('outcome_achieved') is True else "SKIP_OUTCOME_NOT_ACHIEVED")
except Exception:
    print("SKIP_NO_STAND_DOWN")
PY

{mission-dir}を実際のミッション ディレクトリ パスに置き換えます（または最初にMISSION_DIRをエクスポート）。3つのライン すべてがGH_OK、PREFS_OK、OUTCOME_OKの場合、AskUserQuestionを次で呼び出します：

• 質問： 「Nelson がそのミッションを完了させるのを助けました。GitHub でレポをスター化しますか？」
• Star Nelson — 「プロジェクトの成長を助けます。」
• Maybe later — 「今のところスキップします（再度質問しません）。」

Star Nelson では、gh api -X PUT /user/starred/harrymunro/nelsonを実行します（べき等 — レポが既にスター化されているかどうかに関わらず 204 を返します）。呼び出しが失敗した場合は、Couldn't reach GitHub — try 'gh api -X PUT /user/starred/harrymunro/nelson' manually.を出力して続行します。このステップがスタンドダウンをブロックさせないようにしてください。

いずれかの回答（カスタムの「Other」応答を含む）では、~/.nelson/prefs.jsonでstar_asked: trueを設定し、既存のキーを保持します：

python3 - <<'PY'
import json, os
path = os.path.expanduser('~/.nelson/prefs.json')
os.makedirs(os.path.dirname(path), exist_ok=True)
try:
    with open(path, encoding='utf-8') as f:
        prefs = json.load(f)
    if not isinstance(prefs, dict):
        prefs = {}
except Exception:
    prefs = {}
prefs['star_asked'] = True
with open(path, 'w', encoding='utf-8') as f:
    json.dump(prefs, f, indent=2)
    f.write('\n')
PY

これはすべての Nelson プロジェクト全体でユーザー当たり単一の依頼です。いずれかの回答はプロンプトを永遠にロックします。

Standing Orders

状況に一致する特定のスタンディング オーダーを参照してください。ライブラリは経験的に拡張可能です。scripts/nelson_data_patterns.pyを参照して、ミッション パターンから新しい候補オーダーをマイニングし、人間によるレビュー用に表示する昇格ワークフロー。

状況	Standing Order
単一セッションとマルチエージェント間で選択する	references/standing-orders/becalmed-fleet.md
タスクがより少ない艦長に過度に分割されたもの。独立性が正当化する	references/standing-orders/light-squadron.md
別のエージェント追加かどうか決める	references/standing-orders/crew-without-canvas.md
battle plan でファイルをエージェントに割り当てる	references/standing-orders/split-keel.md
タスク スコープが Sailing Orders からドリフトしている	references/standing-orders/drifting-anchorage.md
アドミラルが調整の代わりに実装をしている（許可された読み取り専用の再結合を除く）	references/standing-orders/admiral-at-the-helm.md
red-cell ナビゲータに作業を割り当てる	references/standing-orders/press-ganged-navigator.md
リスク tier 分類なしで進むタスク	references/standing-orders/unclassified-engagement.md
乗組員調整の代わりに実装している艦長	references/standing-orders/captain-at-the-capstan.md
タスク ニーズに関わらずすべてのロールを装備する	references/standing-orders/all-hands-on-deck.md
原子的タスク用に1人の乗組員を生成する	references/standing-orders/skeleton-crew.md
ロール外の乗組員に作業を割り当てる	references/standing-orders/pressed-crew.md
艦長が乗務員作業または持続したタスク用に海兵隊を展開する	references/standing-orders/battalion-ashore.md
艦長は自律作業を完了し、続行するために人間アクションが必要	references/standing-orders/awaiting-admiralty.md
エージェントは依存関係グラフで残り作業がなくタスクを完了	references/standing-orders/paid-off.md
間違った実行モードからツールを使用する	references/standing-orders/wrong-ensign.md
シニア は失敗したサブエージェントから作業を吸収する。代わりにブリーフを修正して再派遣	references/standing-orders/pulling-the-oar.md

Damage Control

状況に一致する特定の手順を参照してください。

状況	手順
エージェント応答なし、ループしている、または有用な出力がない	references/damage-control/man-overboard.md
セッション中断（コンテキスト制限、クラッシュ、タイムアウト）	references/damage-control/session-resumption.md
完了したタスクが障害がある。他のタスクは健全	references/damage-control/partial-rollback.md
ミッションが成功できない、続行は予算を浪費する	references/damage-control/scuttle-and-reform.md
問題が現在の権限を超える、または明確化が必要	references/damage-control/escalation.md
船の乗務員が不均衡なトークンまたは時間を消費する	references/damage-control/crew-overrun.md
船のコンテキスト ウィンドウが枯渇し、置き換えが必要	references/damage-control/relief-on-station.md
船のコンテキスト ウィンドウが制限に近づいている	references/damage-control/hull-integrity.md
自動予算、船体、アイドル アラームがしきい値を超えている	references/damage-control/circuit-breakers.md
セッション スタート時にミッション ディレクトリを準備する	references/damage-control/session-hygiene.md
エージェント チーム通信失敗（失われたエージェント ID、メッセージ バス ダウン）	references/damage-control/comms-failure.md

Admiralty Doctrine

• 任意のアドミラルの圧縮概要にこの指示を含めます：ミッション ディレクトリ パス{mission-dir}で quarterdeck レポートを再読します。パスが不明な場合、SESSION_IDが分かっている場合は.nelson/.active-{SESSION_ID}を読みます。それ以外の場合は.nelson/missions/をリストしてユーザーに選択肢を提示します。次に、references/standing-orders/admiral-at-the-helm.mdを再読んで、調整ロールにいることを確認します。
• /compactを任意のフェーズ境界で安全として扱う（ステップ 1, 2, 3, 4 の後および ステップ 6 のすべての quarterdeck チェックポイントで）。狭い安全でないウィンドウはステップ 5 内です — ユーザー承認とアドミラルのpermission_granted / フェーズ進行 / エージェント生成ターンの間。
• スループットに対して最適化します。等しい作業配布ではなく。
• スタール エージェント交換よりも未定義のブロッカーを待つことに優先します。
• 強いパフォーマンスを認識します。動機はミッション全体で化合します。
• 調整メッセージをターゲットして簡潔にしてください。
• オプションと1つの推奨を持つアーリー アップスケール不確実性。