implement

GitHub issue ( $ARGUMENTS ) の内容をもとに実装を行う。

引数

$ARGUMENTS は <issue> [mode] [fix] の形式で受け取る。

• <issue>: issue 番号(123、#123)または URL。空の場合はユーザーに issue 番号を質問する
• [mode]: auto / normal。auto の場合、実装中に要件が不明確でもユーザーに質問せず、保守的な選択肢を選んで implementation-notes.md に記録して続行する。省略時は質問してよい
• subagent として実行され AskUserQuestion が使えない場合(/dev から起動されたとき): normal でも直接は質問できない。質問は呼び出し元の指示どおり tmp/issues/<issue番号>/questions.json(AskUserQuestion と同じ構造: question / header / multiSelect / options[])に書き、最終メッセージを status: needs-input として一旦終了する。回答(answers)が渡されたら文脈を保ったまま続きから進める
• [fix]: 修正モード。/dev の test 失敗ループ(内側)または review 差し戻しから再実行されたときに渡される。この場合「修正モード」(後述)に従う

修正モード(fix)

/dev が test 失敗(内側ループ)または review 差し戻しで本スキルを再実行するときのモード。計画は変更せず、指摘された箇所だけを直すのが責務。

呼び出し元から失敗した checklist 項目 / review の must 指摘がプロンプトで渡される。

1. 渡された失敗・指摘の内容と、plan.md の該当タスク・implementation-notes.md を読む
2. 原因を特定してから直す。症状を隠す変更(テストの期待値を緩める、条件を特別扱いする等)はしない
3. 直した内容を implementation-notes.md の ## Fixes セクションに「何が失敗していたか / 原因 / 修正内容 / ラウンド番号」で記録する
4. 計画自体に手を入れない。plan.md の編集は /plan の責務

エスカレーション(計画の欠陥だと判断した場合)

修正を試みる前または途中で、失敗の原因が実装ではなく計画にあると判断したら、直さずにエスカレーションする。該当するのは次のような場合:

• plan が前提にしていた既存実装・データ構造・依存が実際と違う
• plan に無い副作用 identifier(trigger / subscriber / 設定キー等)の対応が必要
• AC の解釈が plan と実装で食い違っており、どちらが正しいか plan を直さないと決められない
• 同じ失敗を前のラウンドでも修正したが再発した(## Fixes を見れば分かる)

この場合、コードを変更せず次の形で終了する:

• implementation-notes.md の ## Deviations に「なぜ実装では直せないか」を記録する
• 最終メッセージを status: needs-replan とし、plan の何を直す必要があるかを 1〜3 行で書く

/dev はこれを受けて内側ループを打ち切り、外側(plan 巻き戻し)へエスカレーションする。内側で同じ箇所を繰り返し直すより、計画を直す方が速いことを早く申告するのが本スキルの責務。

implementation-notes.md(実装ノート)

実装開始時に tmp/issues/<issue番号>/implementation-notes.md を作成する(既にあれば追記)。計画と実装現場のギャップをリアルタイムに記録するためのファイルで、後工程(/test のチェックリスト整合、/review / /quiz のコンテキスト、/dev の config 学習)の一次情報になる。

• 計画から逸脱せざるを得ない事象(plan に無いエッジケース、想定と異なる既存実装、依存の発見など)に遭遇したら、その時点で保守的な選択肢を選び、## Deviations セクションに「何が起きたか / なぜ逸脱したか / どう対処したか」を記録して続行する
• 発見したエッジケース・後続ステップへの注意点は ## Notes セクションに記録する
• 修正モードでの修正は ## Fixes セクションに記録する(ラウンド番号を含める。同じ箇所の再発を検出するために使う)
• 事後にまとめて書くのではなく、発生の都度追記する(コンテキスト圧縮や中断を跨いでも判断の履歴が残るように)

タスク管理

実装の進行状況は Claude Code のタスク管理ツール(TaskCreate / TaskUpdate / TaskList)で管理する。

初期化

plan.md を読み込んだ直後に、計画書に記載された各タスク(および TDD の Red / Green / Refactor フェーズ)を TaskCreate で一括登録する。命名規則の例:

• task-1-red / task-1-green / task-1-refactor
• task-2-red / task-2-green / task-2-refactor
• ...
• final-test-run(全タスク完了後の既存テスト実行)
• report(report.md / report.html 書き出し)

進行管理ルール

• 各フェーズに入る直前に該当タスクを in_progress に変更
• フェーズが正常完了したら即座に completed に変更(バッチ更新しない)
• 同時に in_progress にできるのは 1 タスクのみ
• タスクの完了条件を満たせず実装を中断する場合は、理由を implementation-notes.md に記録した上でユーザーに報告する

実行手順

1. tmp/issues/<issue番号>/plan.md(md が無ければ plan.html。以降も同様)を確認する。なければユーザーに plan スキルの実行を提案する
2. gh issue view で issue を取得し、目的・要件を把握する
3. implementation-notes.md を作成する(上記参照)
4. plan.md のタスク・フェーズ構成を読み込み、TaskCreate で実装タスクを一括登録する
5. plan.md のタスクを上から順に実装する。各タスクの影響範囲に記載されたファイルを確認してから変更する。計画とのズレが出たら implementation-notes.md に記録する
6. 各タスクの完了条件を満たしていることを確認し、/simplify スキルでコードを整理した後、次のタスクに進む
7. 全タスク完了後、既存のテストがあれば実行して通ることを確認する
8. 実装の解説を tmp/issues/<issue番号>/report.md に書き出す(md が正。/review / /quiz / /create-pr-text はこちらを読む。implementation-notes.md を材料にする)。続けて同じ内容を人間用に report.html としてレンダリングする(タスクのカード化・テスト結果の色分けなどはこちらに)。更新時は md → html の順で両方に反映する

出力構造(必須セクション)

レイアウトや図表は実装内容に応じて自由に設計してよい(テンプレートは置かない)。ただし後続スキルがレポートを参照しやすいよう、以下のセクションは md の見出し(##)として含めること(html も同構成にする)。

• 概要: 何を実装したかのサマリ
• タスクごとの実装内容: 各タスクの変更ファイル・主要な変更点・完了条件の達成状況
• 計画からの逸脱: implementation-notes.md の Deviations の要約(逸脱なしならその旨)
• テスト結果: 既存テストの実行結果(成功/失敗)
• 懸念点・追加変更: 計画外の変更や、レビュアに注意してほしい点
• コミットメッセージ案: 1 行のコミットメッセージ案。複数コミットに分けるべき場合は分割案(各 1 行)

注意事項

• 実装中に要件が不明確な場合はユーザーに確認を取る(auto では保守的に選択し、Deviations に記録して続行する)
• タスクの完了条件を満たせない場合は、その理由をユーザーに伝える
• コミットは行わない(ユーザーが任意のタイミングで実施する)。代わりに完了報告とレポートに 1 行のコミットメッセージ案を必ず添える