tanabee/plan

GitHub issue ( $ARGUMENTS ) から実装計画を作成する。$ARGUMENTS は issue 番号（123、#123）または URL。

本スキルは 意思決定 + 計画策定 に責務を持つ。/research が列挙した候補から実装方法を選択し、受け入れ条件をタスクにマッピングし、TDD で計画化する。

手順

1. プロジェクト固有の注意点を読み込む

このスキルのディレクトリにある config.json を読み込み、attentions 配列に記載されたプロジェクト固有の注意点（副作用カスケード、暗黙の必須セット、フレームワーク特有のエントリポイント、過去の手戻り事例など）を把握する。以降の計画策定で該当する変更が含まれる場合、対応する波及範囲を計画に反映する。

2. 既存成果物の読み込み

tmp/issues/<issue番号>/ 配下の以下を確認し、存在すればインプットとして活用する。

• research.md: 受け入れ条件・影響範囲・実装方法の候補（必須相当。なければ step 3 で警告）
• plan.md: 既存の計画（再計画モード: テスト失敗等で再実行された場合は、新規作成ではなく既存計画を更新する）

3. 受け入れ条件の取得

• research.md がある場合: その「受け入れ条件」セクションから AC を読み込む
• research.md が無い場合: gh issue view で issue を取得し、AC を抽出する。issue に AC が無い・曖昧な場合は AskUserQuestion でユーザーに確認する（本来 /research で行う作業の fallback）

4. 実装方法の選択

• research.md の「実装方法の候補」セクションから候補を読み込む
• 各候補の概要・Pros / Cons・推奨度を整理して AskUserQuestion で ユーザーに選択してもらう（自由入力でのフィードバックも受け付ける）
• research.md が無い場合は本スキル内でコードベース調査 + 候補列挙を行ってから選択を求める
• 再計画モード（既存 plan.md がある）の場合: 既存計画で選択された方式を尊重し、変更が必要な場合のみユーザーに再選択を求める

5. 副作用 identifier の抽出

選択された実装方法から、変更が引き起こす 副作用 identifier（コードに直接現れない間接依存の起点）を洗い出す。例:

• データ書き込み: コレクション名 / テーブル名 / ドキュメントパスのパターン（orders/{orderId} など）
• イベント発火: イベント名 / トピック名 / channel 名
• キュー投入: キュー名 / job 名
• ファイル出力: バケット名 / パスプレフィックス
• HTTP 発火: URL パス / endpoint 名
• 設定書き込み: 設定キー / feature flag 名

抽出方法:

• 変更対象コードに含まれる書き込み系 API 呼び出し（.set() .update() publish() emit() enqueue() 等）から identifier を列挙
• step 1 で読み込んだ config.json の attentions のうち、該当する identifier に関する注意点を波及範囲に組み込む

6. 受け入れ条件カバレッジ・タスク策定

選択された方法・AC・副作用 identifier をもとに、TDD（Red → Green → Refactor）の流れで実装計画を立てる。

• 各タスクは「テストを書く（Red）→ 実装する（Green）→ /simplify でリファクタリングする（Refactor）」の順で構成する
• 各タスクの影響範囲（対象ファイル・関数）、具体的な変更内容、完了条件を特定する
• step 5 で抽出した副作用 identifier の波及先（trigger / subscriber / consumer 等）も影響範囲に含める
• AC ごとに対応タスクをマッピングする（AC1 → タスク 1, 2 のように、全 AC が 1 つ以上のタスクで満たされる状態にする）。マッピングできない AC があればタスク追加を検討する

7. plan.md への書き出し

結果を Write ツールで tmp/issues/<issue番号>/plan.md に書き込む（フォーマットは template.md を参照）。再計画モードの場合は新規作成ではなく Edit で既存内容を更新する。

注意事項

• 実装方法の 選択は本スキルが行う（/research は候補列挙までで選択しない）
• 受け入れ条件は本スキルでは原則新規作成しない（/research で確定済みのものを使う）。research が無い場合のみ fallback として本スキルで AC を確定する
• issue の内容が曖昧で計画に落とし込めない部分がある場合は、ユーザーに確認を取る
• config.json の attentions は LLM が解釈する自然言語のメモ。形式を厳密に判定せず、関連しそうな注意点は積極的に計画に反映する