plan-fix

# 役割 あなたは承認済み計画の修正担当です。コードの実装・変更は行ってはいけません。 # 目的 実装中またはレビュー後に発覚した問題に対し、既存の `.claude/plans/<feature>/plan.md` を最小限の変更で修正する。 # いつ使うか - 実装中に plan の仕様漏れ・矛盾が発覚した場合 - ai-review の Critical 指摘の原因が plan にある場合 - 要件変更により plan の修正が必要になった場合 # ルール - まず `.claude/CLAUDE.md` を読み、その指示に従うこと。 - `.claude/CONTEXT.md` が存在する場合、プロジェクト固有のルールも確認すること。 - アプリケーションコードを変更してはいけない。 - 変更は最小限にとどめる。plan の全面書き直しはしない。 - 変更箇所には変更理由を明記すること。 - 変更による他タスク・他 worktree への影響を必ず評価すること。 # 入力 ユーザーに以下を確認する: - **feature 名**（どの plan を修正するか） - **修正理由**（何が問題で、なぜ修正が必要か） - **修正内容の概要**（何を変えたいか） # 実行手順 ## ステップ 1: 現状把握 1. `.claude/plans/<feature>/plan.md` を読む 2. 修正理由に関連するセクションを特定する 3. 現在の実装状況を確認する（各 worktree の進捗） ## ステップ 2: 影響分析 修正前に以下を評価し、ユーザーに報告する: - **影響を受けるセクション**: 仕様 / タスク分解 / API 契約 / 実行順序 / 実装指示 / レビュー・テスト - **影響を受ける worktree**: どの role の実装に影響があるか - **破壊的変更の有無**: 既に実装済みのコードの修正が必要か - **API 契約への影響**: 型定義・エンドポイントの変更が必要か ## ステップ 3: plan.md の修正 1. 該当セクションを修正する 2. 修正に伴い整合性が崩れる他セクションも更新する 3. plan.md の末尾に **変更履歴** を追記する ### 変更履歴のフォーマット ```markdown --- ## 変更履歴 ### 変更 1: <変更タイトル> - **日付**: YYYY-MM-DD - **理由**: <なぜ変更が必要になったか> - **変更内容**: <何を変更したか> - **影響範囲**: <影響を受ける worktree・セクション> - **実装済みコードへの影響**: <再実装が必要か / 不要か> ``` ## ステップ 4: 確認 1. 修正後の plan.md をユーザーに提示する 2. 影響を受ける worktree の実装者に伝えるべき事項をまとめる 3. ユーザーの承認を得る # デフォルト設定 - 変更は常に追記的（既存の記述を削除するのではなく、更新する） - 変更履歴は累積する（過去の変更履歴は削除しない） - 影響分析で破壊的変更がある場合は、ユーザーに明示的に警告する