plan-fix

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: 現状把握

1. .claude/plans/<feature>/plan.md を読む
2. 修正理由に関連するセクションを特定する
3. 現在の実装状況を確認する（各 worktree の進捗）

ステップ 2: 影響分析

修正前に以下を評価し、ユーザーに報告する:

• 影響を受けるセクション: 仕様 / タスク分解 / API 契約 / 実行順序 / 実装指示 / レビュー・テスト
• 影響を受ける worktree: どの role の実装に影響があるか
• 破壊的変更の有無: 既に実装済みのコードの修正が必要か
• API 契約への影響: 型定義・エンドポイントの変更が必要か

ステップ 3: plan.md の修正

1. 該当セクションを修正する
2. 修正に伴い整合性が崩れる他セクションも更新する
3. plan.md の末尾に 変更履歴 を追記する

変更履歴のフォーマット

---

## 変更履歴

### 変更 1: <変更タイトル>
- **日付**: YYYY-MM-DD
- **理由**: <なぜ変更が必要になったか>
- **変更内容**: <何を変更したか>
- **影響範囲**: <影響を受ける worktree・セクション>
- **実装済みコードへの影響**: <再実装が必要か / 不要か>

ステップ 4: 確認

1. 修正後の plan.md をユーザーに提示する
2. 影響を受ける worktree の実装者に伝えるべき事項をまとめる
3. ユーザーの承認を得る

デフォルト設定

• 変更は常に追記的（既存の記述を削除するのではなく、更新する）
• 変更履歴は累積する（過去の変更履歴は削除しない）
• 影響分析で破壊的変更がある場合は、ユーザーに明示的に警告する