ns-coder

Code Coder

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

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

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

標準レビューゲート：../ns-reviewer/references/review-gate-workflow.md — 手順 7〜9 は場当たり的な差分 / C2 のみが対象です。コードレビューは reviewer-agent、続いて ns-reviewer を経由する場合に限ります（利用可能な場合はブリッジを必ず使用し、それ以外は直接実行）。その後、Code Review: Approved の場合に限り、セッション内で ns-judge を実行します。各ゲートのラウンドは最大 3 回です。Approved はスコア 10 の場合に限ります。スコア 9 は Rejected（引き上げて必須の再レビュー）です。Approved またはブロック済みの両方の条件が満たされない限り、成功とはみなしません。Delivery Review: Approved の後、一致する場合は Living specs（8）を実行し、その後に最終レポート（9）を作成します。

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

ルーティング（最初に読む）

シグナル	リダイレクト先
GitLab の ISSUE_URL が検出された	停止 — ns-execution-gitlab-issue
複数日 / バージョン / SDD のスコープ	ns-spec-driven
diagnosis_complete がない製品バグ報告 / 画面の期待結果と実際の結果	ns-bug-report-diagnosis
diagnosis_complete: true の BRD 引き継ぎ	実装 — ns-bug-report-diagnosis に戻ってはいけません
原因が不明な、調査が困難なバグ（スタック / CI）	ns-investigator
場当たり的な差分の準備が完了	reviewer-agent、続いて ns-reviewer。Code Review: Approved の場合に限り ns-judge

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

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

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

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

ns-autonomous は、既存のワークツリー内の作業単位サブエージェントとしてディスパッチします。対象は単位のスコープのみです。コード / コメント内の ISSUE_URL を理由に ns-execution-gitlab-issue にルーティングし直してはいけません。これはコンテキストであり、ルーティング情報ではありません。破壊的な操作に関する疑問は GitLab スキルではなく、呼び出し元（A）にエスカレーションしてください。C2 では Living-spec 統合担当を設けません。バージョンの完了と呼び出し元が担当します。エンジン / 複数ユニットの C2： 実装のみ行い、レビューは G フェーズ 4 または A の単独完了時まで延期してください（SDD 引き継ぎと同様です）。呼び出し元が場当たり的な窓口であり、レビューを延期するよう指定していない場合に限り、場当たり的なレビューのループを完了します。

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

親の run-implementation（従来型 SDD）またはディスパッチ SDD handoff / execution-handoff：

1. スコープ： 従来型の場合は、同じレイヤーで連続する pending のタスクを 1 バッチ（4～7 件を推奨、最大 7 件。1 件の場合は単一タスク）とします（references/run-implementation.md を参照）。分割されたスライスの場合は、そのスライスのタスクが対象です。ハンドオフファイルの更新は親が担当します。
2. 各タスクのカード（ヘッダーから Validation criteria まで）を読みます。Detailed description は、曖昧な場合または blocked の場合に必要に応じて開きます（../ns-spec-driven/references/task-schema.md）。
3. 実装と単体テスト／統合テストのみを行います。E2E テストは行いません。
4. 禁止事項： reviewer-agent ／ ns-reviewer ／ ns-judge、生きた仕様の統合、Code Review: ／ Delivery Review: の判定行。
5. 完了報告の前に必ず実施： 公開エクスポートの grep（Pre-review）。引き続きレビュアーは使用しません。
6. 親にはタスクごとに以下を報告します：変更したファイル、実行したテスト、ブロッカー、トークン数（内訳または ~N）、Layout SSoT: {path} read | none registered、Skipped / not checked / risk:（形式：../ns-reviewer/references/review-gate-workflow.md の Final report）。行の更新は親が行います。バージョンの完了処理（手順 4～6）には、バッチごとのファイルではなく references/run-implementation-closure.md を使用します。セッション起動：このエージェントのコールドスタート時は session-boot.md に従って完全に起動します。同じエージェントで続行する場合は、agents.local.md またはハーネスのルールが変更されていない限り、完全な再読み込みは不要です。

セッションの起動

../../ns-harness/references/session-boot.md を参照してください。他の手順に進む前に セッションの起動を完了してください（必須）。コールドスタートの場合のみ実施し、起動済みでファイルに変更がない場合は、セッション途中での再実施を省略します。AGENTS.md をツールで読み込んではいけません。

session-boot の手順 1～6 の後：

• ハーネスの manifest.json で 常時適用 とマークされた .nextstage-harness/rules/*.md をすべて読み込み、対象レイヤーのレイヤールールも読み込みます。
• manifest.json の description がタスクのスコープ（persistence、auth、tenancy、build）に一致する場合は、エージェントが要求するルールも読み込みます。マニフェストがない場合は、rules/*.md を確認し、スコープが一致するファイルを読み込みます。
• 必須ルールを読み込んでいない場合、起動未完了です。不足分を埋めるためにスタックのデフォルトを選んではいけません。
• スタックのシグナル： 検出されたスタックには、対応する関連ルールがある想定です（../../ns-harness/references/architecture-rules/stack-signals.md）。ルールが存在する場合は読み込みます。存在しない場合は質問するか、needs-clarification として記録します。フレームワークのデフォルトを決めつけてはいけません。

セッション入力

変数	必須
{task_description}	はい
{target_layer}	可能な場合に推定します：frontend、backend、infra、tests、fullstack

スコープの分離

リポジトリとハーネスのドキュメント内のみで作業します。

起動（必須）

セッションの起動（../../ns-harness/references/session-boot.md）は、アドホック、C2、SDD handoff に共通する唯一のルールです：

エージェントの状態	アクション
コールドスタート（このエージェント／サブエージェントを起動した直後）	セッションを完全に起動します（手順 1～6）。ブリッジがローカルルールとアーキテクチャ／プロジェクトルールを適用済みの場合があります。レイヤールールとコンテキストの読み込みを完了します
同じエージェントで続行中で、手順 1～6 が完了し、ファイルに変更がない	ルール群を再読み込みしません
前回の起動後に agents.local.md またはハーネスのルールが変更された	再起動します

その後：

1. AGENTS.md の指示（すでにコンテキスト内）に従います。パスを勝手に作成してはいけません
2. git status と git diff を実行します
3. 書き込みの前に対象ファイルを読みます

成功条件： AGENTS.md の指示、プロジェクトのルール、タスクのスコープに従っていること。パスや SDD 成果物を勝手に作成した場合（親が担当するハンドオフの更新を除く）は失敗です。

実装ルール

• カードより憲章を優先： カードが永続化／API／ゲート／パターンのルールで禁止されている内容を指示している場合は、ルールに従って実装し、## Execution notes に card deviation: {card} -> {rules} と注記します。大規模または曖昧な逸脱は blocked とします。
• 差分作成前に根拠を確認： カードで指定されたクラス／コマンドがリポジトリにもルールにも存在しない場合は、停止して報告します。実装してはいけません。
• 永続化の根拠： 永続化パスは architecture-rules.md と必須のプロジェクトルール（セッション開始時）に従います。ルールに記載がない場合、ORM や upsert のデフォルト動作を勝手に仮定してはいけません。確認するか、blocked とします。
• ルールとコードは同じターンで： ルールのリクエストとコードのリクエストがある場合、ハーネスのテキストだけでなく、同じターンで差分を提示します。
• 差分を優先 — 必要な行だけを変更し、無関係なフォーマット変更はしません。
• 新規ファイルより既存ファイルの編集を優先します。
• 変更を最小限に — 再利用の段階的な選択肢を使い、推測に基づくコードは追加せず、共通の呼び出し元で根本原因を修正します：references/minimal-change.md
• 大規模変更のゲート： 同時に2ファイル超、1ファイルあたり20行超、または公開コントラクトの変更に該当する場合は、1行の計画を提示して承認を待ちます。
• 明示的に依頼されない限りコミットしません — コミットする場合は、../../ns-harness/references/agent-git-identity.md を参照します。
• SDD バージョン成果物は作成しません — task-NNN.md、requirements.md、execution-handoff.md、docs/versions/ への書き込みは禁止です。docs/specs/ での条件付きの継続的仕様更新は ns-living-spec を通じて許可されます（Living specs を参照）。
• 依頼されない限り、不要なコメントは追加しません。
• テストは AGENTS.md の Docker とテストの指示に従います。コンテナ／コマンドについては architecture-rules.md を参照します。
• 次の作業の前には確認します（ゲート — 停止して確認）：新しい依存関係の追加、具体的な用途が2つ未満の抽象化、DB スキーマまたは共有コントラクトの変更、CI／デプロイ／インフラ設定の変更、パッケージをまたぐファイルの移動。
• 保護対象のテスト： architecture-rules.md でドメイン不変条件／保護対象テストとして指定されたパスは、成功状態を維持します。テストを通すために弱体化、削除、スキップしてはいけません。
• ライブラリとの相違： ドキュメント／ルールと実際のライブラリ API が食い違う場合は、ライブラリに従い、相違を報告します。
• execution-handoff.md／run-implementation の場合：ユニット／統合テストのみ — E2E テストは実施しません（バージョン終了時に人間が実施）。レビューゲートもありません（親のステップ5）。

補完スキルへの委譲

spec-driven／gitlab プリセットは depends を通じて補完スキルをインストールします（各セッションで .agents/skills/ を一度確認）。委譲してください — ワークフローをインラインで重複して実装してはいけません。

シグナル	スキル	実行タイミング
作成対象の画面に対応する Layout SSoT が登録されていないフロントエンド UI（reference-sources.md の role: ui-layout、またはカードに *-visual.md の記載がある場合）	ns-frontend-design	大規模な UI 差分の前（ステップ4～5）、またはタスクの主な目的がビジュアルである場合
作成対象の画面に対応する Layout SSoT が登録されている	(なし — SSoT を読む)	差分作成前に、引用されたガイド／プロトタイプを開きます。登録済みのパターンとプロジェクトの UI アプローチに合わせます。ns-frontend-design の anti-slop は呼び出しません。
セキュリティヘッダー、CSP/CORS、依存関係の CVE 一括確認、a11y/Web Interface Guidelines の監査	ns-best-practices	明示的な依頼があった場合、またはフロントエンド作業後、衛生面の確認が対象範囲であればレビュー前に実施
README／docs/ のガイド（コードコメントを除く）	ns-docs-writer	明示的な依頼があった場合、またはバージョン／ドキュメントの完了時。単発の修正ごとには実施しません。

MR/SOLID のレビューは**ns-reviewer のみ**で行います。補完スキルがない場合はハーネスのルールに従って続行し、各セッションで一度だけインストールを推奨します（../ns-spec-driven/references/skill-integrations.md）。

タスクごとのサイクル

SDD 引き継ぎモード： 1 回のディスパッチで複数のタスクを扱う場合があります。それでもステップ 6 の後で停止し、親にタスクごとに報告してください。7～9 はスキップします。

1. タスクを理解する
2. ルールを読み込む — すでに起動時に読み込まれた AGENTS.md に従ってください。セッションの起動処理は、このエージェントがコールドスタートした場合、またはファイルが変更された場合にのみ再度行ってください
3. 調査する（大きなフィクスチャは grep/head で確認し、テストの出力全体は表示しない）
4. 最小限の差分を特定する — references/minimal-change.md を適用してください
5. 変更を適用する（大規模変更ゲートに該当する場合は計画を立てる）
6. 対象範囲内でテストを実行し、公開エクスポートを grep する（レビュー前）
7. レビューループ — アドホックのみ：利用可能な場合は必ず reviewer-agent を使用し、それ以外は ns-reviewer を使用してください。その後、Code Review: Approved の場合に限り、セッション内で ns-judge を実行します。../ns-reviewer/references/review-gate-workflow.md を参照してください。SDD 引き継ぎ／エンジンによる保留の場合はスキップします。
8. 生きた仕様（条件付き） — 以下を参照してください
9. 最終報告 — 必須項目を記載し、判定またはラウンド数を省略しないでください

レビュー前（ステップ 7 の前、および SDD 報告の完了前）

• デフォルトのテスト階層のみを実行してください（ユニット／統合テスト、またはデフォルトの test — ../../ns-harness/references/docker-and-testing.md のテスト階層を参照）。人間から今回の実行を依頼されない限り、ライブ階層は絶対に実行しないでください。
• 実際の LLM やライブのサードパーティを必要とする新しいテストは、ライブグループ／マーカーに入れ、実行方法を報告してください。実行してはいけません。
• 差分でエクスポート、定数、環境変数フラグ、公開シンボルを削除する場合は、残っている呼び出し箇所を検索し、レビュー前に解決してください。
• 新規または新たにエクスポートされた公開名を列挙してください（return { }、module.exports、export、public／public static、window／グローバルへのアタッチ）。
• それぞれを grep してください。定義モジュールの外部に呼び出し元がない場合は、非公開／未エクスポートのままにしてください。その後続行します（アドホック：レビュー。SDD：親に報告）。SDD 引き継ぎではレビュー担当者の起動は禁止です。
• 内部／プライベート／ネストされたヘルパーは、そのままにしてください。

レビューループ（アドホックでは必須。SDD 引き継ぎ／エンジンによる保留ではスキップ）

ステップ 6 の後、完了前に ../ns-reviewer/references/review-gate-workflow.md を実行してください。ただし、SDD 引き継ぎ、または呼び出し元がレビューの延期／エンジン C2／G 単一ユニットのディスパッチを指示した場合を除きます（親に戻し、レビュー担当者も判定担当者も起動しないでください）。却下後の対応／修正／再レビューの流れは、同ワークフローのみに従ってください（網羅的に実施 → コーダー 1 人 → delta と前回の ID）。ここでは評価基準を再掲しません。

• 作業ツリーの差分（git diff）に対して、利用可能な場合は必ず reviewer-agent を呼び出し、それ以外は ns-reviewer を使用してください。レビューブリッジ／スキルはコールドスタート時にセッションの起動処理を開始し、その後レビューワークフローを実行します。ISSUE_URL は使用せず、バージョンクローズの手順も実行しません。アドホックの差分のみが対象です。レビュー担当者は判定担当者をディスパッチしてはいけません。
• コードラウンドは最大 3 回です。 Code Review: Approved となるのはスコアが10の場合のみです。Rejected／Blocked の場合は ns-judge を実行してはいけません。
  • 合格： Code Review: Approved（スコア = 10、Critical は 0 件）。その後、セッション内で ../ns-judge/SKILL.md を読み込んでください（adhoc）。--requirements／--ac-file がない限り、AC 証明はスキップします。判定ラウンドは最大 3 回です。Delivery Review: Approved となるのはスコアが 10 の場合のみです。判定が Rejected となった後にプロダクトファイルを変更した場合は、コードレビュー（必ず Approved）を再度受けてから、判定をやり直してください。
  • 残りのラウンドがある状態で却下： review-gate-workflow.md のコードラウンドに従って対応内容を適用してください（コーダー 1 人、マップをそのまま使用し、再レビューのプロンプトには delta と前回のマップ ID を指定）。reviewer-agent／ns-reviewer／ns-judge は読み取り専用です。このスキルに従って修正してください。利用可能な場合は必ず reviewer-agent を使用し、それ以外は ns-reviewer を使用してください。
  • 停止： Blocked、3 回目の呼び出しでスコアが10未満、または 3 ラウンドを使い切った場合は、ブロックされたと報告してください。Blocked の場合、コーダーを起動してはいけません。未解決の Critical、および／または最後のスコアを列挙してください。成功として報告してはいけません。ステップ 8 はスキップしてください。
• 修正は元のタスクの範囲内で行ってください。Critical（またはスコアを阻害する Warning）の修正に、範囲外の変更（公開契約、複数プロダクトにまたがる変更、数日を要する変更）が必要な場合は停止し、停止条件に従ってエスカレーションしてください。
• コードレビューが Approved の場合、提案（P2）のみではブロックされません。スコア 9 は、P2 のみの場合でも Lift です。

リビングスペック（ステップ 8、条件付き）

Delivery Review: Approved の後に限り（C2 としてではありません）、ns-living-spec を必要に応じて呼び出します。次の条件をすべて満たす場合に限ります。

1. 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:／Delivery Review: の行は記載しません。判定はバージョンクローズ時に行います。

すべての ad-hoc／C2 クローズ回答には、../ns-reviewer/references/review-gate-workflow.md の Final report にあるフィールドを必ず含め、Code Review: と Delivery Review: の行を正確に記載してください（コードが Approved にならなかった場合、デリバリーは n/a）。

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

停止条件

条件	対応
大規模変更ゲート	計画を立てて待機
公開コントラクトの変更	停止し、説明して確認を求める
事前確認ゲート（依存関係／抽象化／スキーマ／CI／パッケージ間の移動）	停止して確認を求める
保護対象テストの変更によってカバレッジが低下する	停止し、動作を修正するか確認を求める
ライブラリ API とドキュメント／ルールが一致しない	ライブラリに従い、差異を報告
タスクに複数日にわたる SDD 計画が必要	ns-spec-driven に引き継ぐ

関連スキル

• ns-reviewer — 実装後のコード品質ゲート（レビューの反復）
• ns-judge — Code Review: Approved 後にセッション内で行うデリバリーの証明
• ns-living-spec — Delivery Review: Approved 後に条件に応じて行う ad-hoc のリビングスペック更新（リビングスペック）
• ns-investigator — スタック／CI の問題が不明瞭でブロックされている場合
• ns-bug-report-diagnosis — 製品レポート／画面のストーリー。diagnosis_complete がない場合に限り差し戻す
• ns-autonomous — 自律型のマルチエージェント実行（GitLab issue またはローカルプラン）。GitLab issue を使う場合は、代わりに ns-execution-gitlab-issue を使用
• ns-frontend-design — UI／デザイン作業（補完的な委任）
• ns-best-practices — セキュリティ／CSP／a11y の衛生確認（補完的な委任）
• ns-docs-writer — 依頼に応じた README／docs/ ガイドの作成（補完的な委任）

禁止事項

• SDD のバージョン成果物の生成（docs/versions/、引き継ぎ、要件／タスク）
• Delivery Review: Approved より前、または docs/specs/ がない場合のリビングスペック統合
• 範囲の指定がない状態でのリポジトリ外へのアクセス
• バージョン管理対象ファイルへのシークレット／キー／接続文字列の記載
• 明示的な依頼のないコミット
• タスク範囲外のリファクタリング
• レビューの代替手段 — Cursor Task サブエージェント（senior-tech-lead-reviewer、bugbot、security-review）、または reviewer-agent／ns-reviewer の SKILL.md を経由しないレビュー。Harness の reviewer-agent は許可されています。Judge は Approved 後にセッション内で行う ns-judge を使用します。v1 では judge-agent は使用しません
• コードが Approved になる前の Judge — 直近の Code Review: が Approved でない状態での ns-judge
• 再レビューの省略 — ad-hoc／C2 で Rejected（スコア 9 を含む）の後、新たにそのゲートで Approved となるラウンドを経ずに成功とすること
• 判定なしの成功 — 必須の Final report フィールドと、解析可能な Code Review:／Delivery Review: の行を含めずに ad-hoc／C2 をクローズすること
• 引き継ぎ中のタスクごと／バッチ途中のレビュー — run-implementation のタスクまたはバッチ中に reviewer-agent／ns-reviewer／ns-judge を実行すること（ステップ 5 は親が担当）