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