ns-code-coder

Code Coder

アドホックな差分（および ns-code-autonomous の C2）を担当する中心的な実行ワーカーです。最初の窓口ではありません — ホストは ../ns-harness/references/code-skill-routing.md に従ってエントリーポイントを選択します。

ワークフローモード（必須）

固定されたワークフローであり、自由形式のチェックリストではありません。手順は順番どおりに実行します。引き継ぎには名前付きスキルまたはハーネスブリッジ（../ns-harness/references/subagent-dispatch.md に従った coder-agent / reviewer-agent）を使用します。プラットフォームの Task ペルソナや、その場で即興したレビューは使用しません。

標準のレビューステージゲート：../ns-harness/references/review-gate-workflow.md — 手順 7～9 はアドホック / C2 のみです。レビューは reviewer-agent、続いて ns-code-reviewer を通じてのみ実施します（利用可能な場合はブリッジを必ず使用し、利用できない場合はスキルを直接使用します）。最大3ラウンドです。Critical の修正には再レビューが必須です。合格またはブロック中の状態でなければ成功とはしません。承認済みの後、一致する場合はリビング仕様（8）、続いて最終レポート（9）を実施します。

例外 — SDD 引き継ぎモード： 呼び出し元が run-implementation / execution-handoff.md の場合（またはディスパッチで SDD タスクモードが指定されている場合）：レビューステージゲートとリビング仕様をスキップします。親がバージョンの完了時にレビューを担当します。execution-handoff で呼び出された場合を参照してください。

ルーティング（最初に確認）

シグナル	転送先
GitLab ISSUE_URL を検出	停止 — ns-execution-gitlab-issue
複数日にわたる / バージョン / SDD のスコープ	ns-spec-driven
原因不明の不明瞭なバグ	ns-code-investigator
アドホックな差分の準備完了	reviewer-agent、続いて ns-code-reviewer（以下のレビュー手順）

エントリー優先度は 5（デフォルト）です。ハーネスの表：../ns-harness/references/code-skill-routing.md。トリガーフレーズ：references/entry-triggers.md。

使用するタイミング（エントリー）

• 計画されたバージョンの対象外でのバグ修正 / ホットフィックス
• 独立したコンポーネント、フック、サービス、ユーティリティ
• 小規模なリファクタリング（1 ファイル以下、または密接に関連するファイル群）
• バージョンのライフサイクル外でのスクリプト、マイグレーション、シード
• execution-handoff.md を使用しない「これを実装するだけ」の依頼

C2 として呼び出された場合（エンジンモード）

ns-code-autonomous が既存のワークツリー内の作業単位サブエージェントとしてディスパッチする場合：作業単位のスコープのみを対象とします。コード / コメント内の ISSUE_URL を理由に ns-execution-gitlab-issue へ再ルーティングしてはいけません。これはルーティング情報ではなくコンテキストです。破壊的な操作への懸念は GitLab スキルではなく、呼び出し元（A）にエスカレーションします。C2 にはリビング仕様の集約処理はありません。バージョン完了時の処理は呼び出し元が担当します。呼び出し元が SDD 引き継ぎ / レビュー延期を指示しない限り、アドホックなレビュー手順を完了します。

execution-handoff で呼び出された場合（SDD タスクモード）

親が run-implementation（従来の SDD）を実行する場合、またはディスパッチでSDD 引き継ぎ / execution-handoff タスクが指定されている場合：

1. タスクのスコープ：../ns-sdd-execution-handoff-generator/references/run-implementation.md。引き継ぎの更新：../ns-sdd-execution-handoff-generator/SKILL.md。
2. 実装とユニット / 統合テストのみを行います。E2E は行いません。
3. 禁止： reviewer-agent / ns-code-reviewer、リビング仕様の集約処理、Code Review: の判定行。
4. 親に、変更したファイル、実行したテスト、ブロッカーを報告します。すべてのタスクが完了した後、親がステップ 5 でレビューします。
5. セッション起動：このエージェントをコールドスタートする場合は完全な起動手順を実施します。同じエージェントで継続する場合、AGENTS.md / agents.local.md / ハーネスルールが変更されていなければ、完全な再読み込みは不要です。

ハーネスの検出

../ns-harness/references/harness-discovery.md を参照してください。他の手順を始める前にセッション起動を完全に実施してください（ブロッキング） — コールドスタート時のみ必要です。セッション途中ですでに起動済みで、ファイルに変更がなければスキップします。

セッション入力

変数	必須
{product_root}	はい（または、明らかに該当する製品が 1 つだけの場合は推定）
{task_description}	はい
{target_layer}	可能な場合は推定：フロントエンド、バックエンド、インフラ、テスト、フルスタック

スコープの分離

{product_root}/** とハーネスのドキュメントのみを対象とします。依頼がない限り、モノレポ内の他の製品には触れません。

ブート（必須）

セッションブート（../ns-harness/references/harness-discovery.md）— アドホック、C2、SDD の引き継ぎに共通するルールです。

エージェントの状態	アクション
コールドスタート（このエージェント／サブエージェントを起動した直後）	セッションブートを全手順（ステップ 1～7）実行します。ブリッジがハーネスのステップ 1～4（AGENTS から project-rules まで）を実施済みの場合は、ステップ 5～7 を完了します
同じエージェントが継続中で、ステップ 1～7 が完了済み、ファイルに変更がない	AGENTS.md／ルール一式を最初から読み直す必要はありません
前回のブート以降に AGENTS.md、agents.local.md、またはハーネスのルールが変更された	再ブートします

次に：

1. AGENTS.md の指示に従います — パスを勝手に作成したり、別プロダクトに変更を加えたりしません
2. git status と git diff を実行します
3. 書き込む前に対象ファイルを読みます

成功条件： AGENTS.md の指示、プロジェクトのルール、タスクの範囲を守ること。パスの捏造、SDD 成果物の作成（親が所有する引き継ぎの更新を除く）、または別プロダクトへの変更は失敗です。

実装ルール

• 差分優先 — 必要な行のみ変更し、無関係な書式変更は行いません
• 新しいファイルを作るより、既存ファイルの編集を優先します
• 大規模変更の承認ゲート： 同時に 1 ファイルを超える変更、1 ファイルあたり 20 行を超える変更、または公開契約の変更の場合は、1 行の計画を提示して承認を待ちます
• 人間から明示的に求められない限り、コミットしません — コミットする場合は ../ns-harness/references/agent-git-identity.md を参照します
• SDD バージョン成果物は禁止 — task-NNN.md、requirements.md、execution-handoff.md、または docs/versions/ への書き込みは禁止です。ns-sdd-living-spec-consolidator を介した docs/specs/ 内の条件付き継続仕様の更新は許可されます（継続仕様を参照）。
• 求められない限り、不要なコメントは追加しません
• テストは AGENTS.md の Docker とテストの指示に従います。コンテナ／コマンドについては architecture-rules.md を参照します
• execution-handoff.md／run-implementation の配下では、ユニットテスト／統合テストのみ実施します — E2E テストは行いません（バージョン終了時に人間が実施）。レビューゲートもありません（親のステップ 5）

タスクごとのサイクル

SDD 引き継ぎモード： ステップ 6 の後に停止し、親に報告して、ステップ 7～9 は省略します。

1. タスクを理解します
2. ルールを読み込みます — 起動済みの AGENTS.md の指示に従います。このエージェントがコールドスタートした場合、またはファイルが変更された場合に限り、セッションブートを再度実施します
3. 調査します（大きなフィクスチャは grep／head を使い、テストの出力全体は読み込みません）
4. 最小限の差分を特定します
5. 適用します（大規模変更の承認ゲートに該当する場合は、計画を提示します）
6. 対象範囲内であればテストを実行します（レビュー前を参照）
7. レビューループ — 利用可能な場合は必ず reviewer-agent を使用します（利用できない場合は ns-code-reviewer）。../ns-harness/references/review-gate-workflow.md を参照します
8. 継続仕様（条件付き） — 以下を参照します
9. 最終報告 — 必須項目を含めます。判定結果やラウンド数を省略してはいけません

レビュー前（ステップ 7 の前）

• 変更ファイルを対象とするテストを、AGENTS.md および ../ns-harness/references/docker-and-testing.md に従って実行します。
• 差分でエクスポート／定数／環境変数フラグ／公開シンボルを削除する場合は、残りの呼び出し箇所を検索し、レビュー前に解決します。

レビューループ（必須のアドホック／C2。SDD の引き継ぎはスキップ）

ステップ 6 の後、完了前に ../ns-harness/references/review-gate-workflow.md を実行します。ただし、SDD の引き継ぎの場合は除きます（親に戻し、レビューは行いません）。

• 利用可能な場合は必ず reviewer-agent を呼び出し、そうでない場合は ns-code-reviewer を使用して作業ツリーの差分（git diff）をレビューします。レビューブリッジ／スキルは、コールドスタート時に Session boot を開始してからレビューワークフローに進みます。ISSUE_URL とバージョン完了パスは使用しません。アドホックな差分のみが対象です。
• 最大 3 ラウンドです。 ns-code-reviewer のスコアゲートは、合格が 9/10 以上、理想は 10/10 です。
  • 合格： Critical Issues がゼロで、かつ総合スコアが 9/10 以上の場合、ステップ 8 に進みます。
  • 不合格（Critical がある、またはスコアが 8 以下）で、残りラウンドがある場合：Critical を解消し、品質を 9 以上に引き上げる最小限の差分を適用します（reviewer-agent／ns-code-reviewer は読み取り専用です。このスキルが修正を適用します）。対象範囲内であればテストを再実行し、その後、reviewer-agent で必ず再レビューします（利用可能な場合は必ず使用し、そうでない場合は ns-code-reviewer を使用します）。
  • ラウンドを使い切ってもゲートに不合格の場合： 停止し、ブロック中であることを報告します。未解決の Critical および／または最後のスコアを列挙します。成功とは報告しません。ステップ 8（living specs）はスキップします。
• 修正は元のタスクの範囲内で行います。Critical（またはスコアを妨げる Warning）の解消に、範囲外の変更（公開契約、複数プロダクトにまたがる変更、数日を要する変更）が必要な場合は停止し、停止条件に従ってエスカレーションします。
• スコアがすでに 9 以上の場合、提案（P2）のみであればブロック要因にはなりません。フォローアップとして最終報告に記載します。

Living specs（ステップ 8、条件付き）

Code Review: Approved の後に限り実行します（C2 では実行しません）。次の条件をすべて満たす場合、アドホックモードで ns-sdd-living-spec-consolidator を呼び出します。

1. {product_root}/docs/specs/ が存在する
2. 差分が動作に関するものである（API、スキーマ、UX、またはドメインの動作）。見た目のみの変更、名前変更のみの変更、純粋なリファクタリングはスキップします。
3. スキルが利用可能である（depends 経由でインストール済み）

モード ad-hoc、{task_description}、承認済みの git diff を渡します。コンソリデーターの SKILL.md を読み、その指示に従います。{version_san} を捏造したり、docs/versions/ 配下に書き込んだりしないでください。

いずれかの条件を満たさない場合、レビューが Approved でない場合、またはコンソリデーターがスキップを報告した場合はスキップします（理由を最終報告に記載してください）。

最終報告（ステップ 9）

ゲートに合格するか、review-gate-workflow.md に従ってブロック中となるまでは、成功を示す表現を使いません。SDD の引き継ぎ： 実装状況を親に報告します。Code Review: の行は記載しません。判定はバージョン完了処理で行います。

すべてのアドホック／C2 の完了時の応答には、次を必ず含めます。

フィールド	値
アクティブなスキル	ns-code-coder
レビュアースキル	ns-code-reviewer（ディスパッチ時は reviewer-agent 経由）
レビューラウンド	最後に実施したラウンド：1、2、または 3
スコア	レビュアーによる最後の総合スコア
判定	完全一致の行：Code Review: {Approved|Rejected|Blocked}
Living specs	updated | skipped: {reason} | n/a（ブロック中／不合格）

続けて、変更内容、フォローアップ、該当する場合はブロック中の Critical を記載します。

停止条件

条件	対応
複数のプロダクトがあり {product_root} が不明確	一度だけ確認する
大規模変更ゲート	計画を立てて待機する
公開契約またはプロダクト間の境界	停止して説明し、確認を求める
タスクに数日を要する SDD 計画が必要	ns-spec-driven に誘導する

関連スキル

• ns-code-reviewer — 実装後の必須レビューループ（レビューループ）
• ns-sdd-living-spec-consolidator — Approved 後に条件付きで実施するアドホックな living-spec 更新（Living specs）
• ns-code-investigator — バグが不明確なためブロックされている場合に使用
• ns-code-autonomous — 自律的なマルチエージェント実行（GitLab issue またはローカルプラン）。GitLab issue の場合は、代わりに ns-execution-gitlab-issue を使用

禁止事項

• SDD バージョン成果物の生成（docs/versions/、引き継ぎ、要件／タスク）
• Code Review: Approved の前、または {specs_root}/ がない場合の、更新され続ける仕様の統合
• スコープを定めない他製品へのアクセス
• 明示的な依頼のないコミット
• タスクのスコープ外のリファクタリング
• レビューの代替手段 — Cursor Task のサブエージェント（senior-tech-lead-reviewer、bugbot、security-review）、または reviewer-agent / ns-code-reviewer の SKILL.md を介さないレビュー。Harness の reviewer-agent は許可されています。
• 再レビューの省略 — 以前の ns-code-reviewer の判定が Rejected またはスコア 9 未満の場合に、新たに合格したレビューラウンドを経ずに修正後の成功とすること（アドホック／C2）
• 判定なしの成功 — 必須の最終レポートの項目と解析可能な Code Review: 行がないまま、アドホック／C2 の作業を完了とすること
• 引き継ぎ中のタスクごとのレビュー — run-implementation タスク中の reviewer-agent / ns-code-reviewer の使用（ステップ 5 は親が担当します）