/refine-plan

description: 既存コードやドキュメントへの小規模な修正を計画します。修正対象の特定・影響範囲の調査・実施内容の定義を行い、refine-executeで実行可能なplanファイルを出力します。
allowed-tools: Read, Glob, Grep, Task, Write, AskUserQuestion
argument-hint: "[修正内容の概要（任意）]"

既存の実装・ドキュメントに対する小規模な修正計画を立てます。対象ファイルの調査・影響範囲の確認を行い、refine-executeで参照するplanファイルを出力します。

context

出力ディレクトリ=".dcs" カレントディレクトリ={{プロジェクトルート}} 修正概要="" 修正種別="" 対象ファイルリスト=[] 影響ファイルリスト=[] timestamp=""

steps

• $1 がある場合、その内容を 修正概要 に設定して簡潔に説明する
• step1 を実行する

step1: 情報収集

• AskUserQuestion ツールを使って以下を確認し、context を更新する：

1. 修正の種別を確認（コード / ドキュメント / 設定ファイル） 2. 修正内容の詳細を確認（修正概要が空の場合は必ず確認） 3. 対象ファイルが判明しているかを確認

• 収集した内容をまとめてユーザーに宣言する
• step2 を実行する

step2: 対象ファイルの調査

• 対象ファイルが指定されている場合: Read で内容を確認し、修正箇所・行番号を特定する
• 対象ファイルが不明の場合: Glob と Grep を使ってキーワード検索で候補を特定する
• 複数の候補が見つかった場合は AskUserQuestion でユーザーに絞り込みを確認する
• 対象ファイルリストを確定する
• step3 を実行する

step3: 影響範囲の調査

• 対象ファイルリストの各ファイルについて以下を調査する：
• そのファイルを import / require / 参照しているファイルを Grep で検索
• 関連するテストファイルを Glob で検索（例: `*.test.*`, `*.spec.*`, `__tests__/` 等）
• ドキュメントや設定ファイルへの影響を確認
• 影響ファイルリストを確定する
• step4 を実行する

step4: planファイルの作成

• 出力先ディレクトリを決定する：
• timestamp を現在時刻（yyyyMMddHHmmss 形式）で生成する
• 修正内容を簡潔な英語に変換する（スネークケース、最大30文字）
• ベースディレクトリ = "{{出力ディレクトリ}}/{{timestamp}}_refine_{{英語化した修正名}}"
• 例: ".dcs/20260224143022_refine_user_auth_fix"
• 同じ timestamp と名前のディレクトリが存在する場合は末尾の連番を +1 する
• <plan_template> の内容を context の情報で埋めて Write ツールでファイルに出力する
• 出力ファイル: "{{ベースディレクトリ}}/plan.md"
• 出力したファイルのパスをユーザーに報告する
• 「`/tsumiki:refine-execute {{ベースディレクトリ}}/plan.md` を実行すると修正を開始します」と案内する

rules

情報収集のルール

質問1: 修正種別

• **質問**: 修正の対象は何ですか？
• **header**: "修正種別"
• **options**:
• "コード" - ソースコードファイルの修正
• "ドキュメント" - Markdown、設計書等の修正
• "設定ファイル" - JSON、YAML、TOML等の設定修正
• "複合（コード＋ドキュメント等）" - 複数種別にまたがる修正

質問2: 修正内容の詳細

• **質問**: どのような修正を行いたいですか？（具体的に教えてください）
• **header**: "修正内容"
• **options**:
• "バグ修正" - 既存の動作上の問題を修正
• "リファクタリング" - 動作は変えずにコード品質を改善
• "誤字・記述修正" - テキストの誤りを修正
• "仕様変更への対応" - 要件変更に合わせて既存実装を修正

質問3: 対象ファイルの有無

• **質問**: 修正対象のファイルはわかっていますか？
• **header**: "対象ファイル"
• **options**:
• "はい（ファイルパスがわかる）" - ユーザーに具体的なパスを入力してもらう
• "いいえ（キーワードから調査する）" - キーワードから自動調査する

ファイル名のルール

timestamp の形式

• yyyyMMddHHmmss 形式（例: 20260224143022）

修正内容の英語化

• 修正内容を簡潔な英語に変換する
• スネークケース（snake_case）を使用
• 最大30文字程度
• 例:
• "ユーザー認証のバグ修正" → "user_auth_fix"
• "READMEの誤字修正" → "readme_typo_fix"
• "ログ出力の設定変更" → "log_config_update"

ファイルパスの記載ルール

• **プロジェクトルートを基準とした相対パスを使用する**
• フルパス（絶対パス）は記載しない

info

<plan_template>

修正計画

**作成日時**: {{timestamp}} **修正概要**: {{修正概要}} **修正種別**: {{修正種別}}

---

修正対象ファイル

| ファイル | 該当行 | 内容 | |---------|--------|------| | `{{ファイルパス}}` | L{{開始行}}-L{{終了行}} | {{修正箇所の概要}} |

修正前後の詳細

`{{ファイルパス}}`

**修正前**:

{{修正前のコード/テキスト}}

**修正後**:

{{修正後のコード/テキスト}}

**修正理由**: {{なぜこの修正が必要か}}

---

影響範囲

影響を受けるファイル

| ファイル | 影響の種類 | 対応要否 | |---------|-----------|---------| | `{{ファイルパス}}` | {{import参照 / テスト / ドキュメント}} | {{要 / 不要}} |

関連テストファイル

| テストファイル | 対応内容 | |--------------|---------| | `{{テストファイルパス}}` | {{テストの変更が必要な場合はその内容、不要な場合は「変更不要」}} |

---

リスク・注意事項

• {{リスク1: 例）他のモジュールへの影響}}
• {{リスク2: 例）破壊的変更の有無}}
• {{注意事項1}}

---

確認手順

ビルド確認

{{ビルドコマンド（例: npm run build / make build / go build ./... 等）}}

テスト実行

{{テスト実行コマンド（例: npm test / pytest / go test ./... 等）}}

セキュリティ確認観点

• 入力値のバリデーション変更の有無
• 認証・認可ロジックの変更の有無
• 外部入力を扱う箇所の変更の有無
• SQLインジェクション・XSS等のリスクの有無

---

*このplanファイルは `/tsumiki:refine-execute {{ベースディレクトリ}}/plan.md` で実行できます* </plan_template>