code-coder

Code Coder

プロジェクトのルールを守りながら、差分を最小限に抑えて、その場限りのコーディングタスクを実装します。

ハーネスの検出

../nextstage-harness/references/harness-discovery.md を参照してください。{harness_root}/rules/*.md からルールを読み込みます。最初に architecture-rules.md を読んでください。レガシー版：{harness_root} が存在しない場合に限り、.cursor/rules/*.mdc を使用します。

使用する場合

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

execution-handoff.md を伴う、計画済みバージョン全体を対象とする場合は、 ../execution-handoff-generator/references/run-implementation.md に従い、 ../execution-handoff-generator/SKILL.md に従ってハンドオフを更新してください。以下の、このスキルのその場対応サイクルは使用しないでください。

依頼に GitLab の issue URL（ISSUE_URL）が含まれている場合は、このスキルではなく execution-gitlab-issue を使用してください。

セッション入力

変数	必須
{product_root}	はい（または、対象の製品が明らかに 1 つだけの場合は推定）
{task_description}	はい
{target_layer}	可能であれば推定：frontend、backend、infra、tests、fullstack

スコープの分離

{product_root}/** とハーネスのドキュメントのみを対象に作業します。依頼がない限り、モノレポ内の他の製品は読み込まないでください。

起動（必須）

1. AGENTS.md を読む
2. ハーネスがある場合はレイヤールールを読み込む（アーキテクチャは常に読み込み、レイヤーに応じて backend/frontend/tests/e2e を読み込む）
3. 製品のコンテキストを読み込む：../nextstage-harness/references/artifact-layout.md の Implementation boot rule に従う
4. git status と git diff
5. 書き込み前に対象ファイルを読む

実装ルール

• 差分優先 — 必要な行のみを変更し、無関係な書式は変更しない
• 新規ファイルの作成より、既存ファイルの編集を優先する
• 大規模変更のゲート： 同時に 1 ファイルを超える変更、1 ファイルあたり 20 行を超える変更、または公開契約の変更 → 1 行の計画を提示し、承認を待つ
• 人間から明示的に依頼されない限り、コミットしない — コミットする場合は ../nextstage-harness/references/agent-git-identity.md を参照
• SDD 成果物は作成しない — task-NNN.md、requirements.md、execution-handoff.md は作成しない
• 依頼がない限り、不要なコメントは追加しない
• AGENTS.md の Docker およびテストの指示に従ってテストを実行する。プロジェクト固有のコンテナとコマンドは architecture-rules.md に記載されています

タスクごとのサイクル

1. タスクを理解する
2. ルールを読み込む
3. 関連ファイルを調査する
4. 最小限の差分を特定する
5. 適用する（または、大規模変更のゲートに該当する場合は計画を提示する）
6. 対象範囲内であればテストを実行する
7. レビューループ — code-reviewer を呼び出し、指摘に対応する（以下を参照）
8. 変更内容、最終レビュー判定、フォローアップを報告する

レビューループ（必須）

テストに合格した後（手順 6）、完了を報告する前に、内部レビューループを実行します。

• 作業ツリーの差分（git diff）を対象に code-reviewer を呼び出します。ISSUE_URL やバージョン完了処理のパスは使用せず、その場対応の差分のみを対象にします。
• 最大 3 ラウンド。 各レビュー後：
  • Critical Issues なし（評価が満足できる）→ 報告に進みます。
  • Critical Issues があり、残りのラウンドがある → 各 Critical を解消する最小限の差分を適用します（code-reviewer は読み取り専用なので、このスキルで修正を適用します）。対象範囲内であればテストを再実行し、再レビューします。
  • ラウンドを使い切っても Critical が残る → 停止してブロックされたと報告します。 未解決の Critical を列挙してください。成功として報告してはいけません。
• 修正は元のタスクの範囲内にとどめてください。Critical の指摘にスコープ外の変更（公開契約、製品間の変更、数日かかる作業）が必要な場合は、差分を拡大せず、停止条件に従って停止し、エスカレーションしてください。
• Warnings と Suggestions は作業をブロックしません。フォローアップとして最終報告に含めてください。

停止条件

条件	対応
複数の製品があり {product_root} が不明確な場合	一度だけ確認する
大規模な変更のゲート	計画を立てて待機する
パブリックコントラクトまたは製品間の境界	停止して説明し、確認する
タスクに複数日にわたる SDD 計画が必要な場合	計画策定に誘導する

関連スキル

• code-reviewer — 実装後の必須レビューサイクル（Review loop を参照）
• code-investigator — 不明確なバグで行き詰まった場合
• code-autonomous — 自律型のマルチエージェント実行（GitLab issue またはローカル計画）。GitLab issue の場合は、代わりに execution-gitlab-issue を使用する

禁止事項

• SDD 成果物の生成
• スコープ指定なしでの製品間アクセス
• 明示的な依頼のないコミット
• タスクの範囲外のリファクタリング