| name | pr-plan |
| description | 実装を始める前に計画をGitHub Issueとして記録する。grilling形式で要求・要件を徹底的に掘り下げてからgh issue createする。「実装計画を立てたい」「コードを書く前にIssueを作りたい」「この機能の計画を立てたい」「何かを実装したい（まだコードは書いていない）」時に使う。 |
pr-plan — grilling形式の要求定義 → Issue化
コードを書く前に「意図と要件」を徹底的に掘り下げるスキル。
mattpocock の grilling アプローチ（1問ずつ・推奨回答付き・決定木を完全に辿る）で
実装の前提となる判断をすべて解決してから Issue を作成する。
引数
$ARGUMENTS に課題の概要が渡された場合はそれを起点にする。なければゼロから聞く。
Phase 1: Grilling（徹底的な要求・要件定義）
「問いの決定木」を1問ずつ辿る。共通理解が得られるまで続ける。
Grilling のルール
- 1問ずつ送る。複数を一度に出すと混乱させる
- 各問いに推奨回答を添える（沈黙ではなく仮説を提示する）
- 答えで次の枝が決まる。依存関係を解決しながら進む
- コードベースを探れば答えられる問いは聞く前に自分で調べる
- 「もう聞くことはない」と確信できるまで止めない
辿るべき決定木の枝
以下を順番ではなく依存関係の順に解決する。すでに明らかな枝はスキップしてよい。
枝1: 問題の本質
- 今何が起きているか（現状）
- なぜ今それが問題なのか（タイミングの理由）
- 誰が困っているか（影響範囲）
- この問題を放置するとどうなるか
枝2: 解決策の選択
- 候補となるアプローチは何か
- 各アプローチのトレードオフは何か
- なぜ今回のアプローチを選ぶのか
- 却下した代替案と却下理由は何か（これが後の「やらなかったこと」になる）
枝3: 成功の定義
- 完了とはどういう状態か（観察可能・テスト可能な形で）
- 失敗とはどういう状態か
- どうやって「動いた」と確認するか
枝4: スコープの境界
- 今回やることとやらないことの境界線はどこか
- やらないと決めた理由は何か（「時間不足」でなく設計上の理由で）
- スコープ外のことが必要になったらどうするか
枝5: 制約・依存関係
- 他のチームや機能に影響するか
- 既存のコードやデータモデルとの整合性は
- パフォーマンス・セキュリティ・後方互換性の制約は
枝6: エッジケース・リスク
- 「うまくいかない」シナリオは何か
- データが不正・欠損の場合はどうするか
- 並行アクセスや競合状態が起きる可能性は
Grilling の終了条件
以下がすべて満たされたら終了する：
- 「なぜやるか」「何をやるか」「何をやらないか」「完了条件」が明確
- 主要な代替案とその却下理由が記録されている
- 実装者が迷う判断ポイントがない状態になっている
終了時に「これで十分に理解できました。Issueを作成します。」と宣言する。
Phase 2: Issue の下書きを提示して確認
Grilling の結果をまとめ、作成するIssueの内容を提示する。
作成するIssue:
タイトル: <type>: <subject>
## 課題
<背景と動機>
## 解決策・意図
<選んだアプローチ。代替案と却下理由も記載>
## やること
- [ ] <作業1>
- [ ] <作業2>
## やらないこと（スコープ外）
- <除外した内容>: <設計上の除外理由>
## 完了条件
- [ ] <テスト可能な条件1>
- [ ] <テスト可能な条件2>
## エッジケース・注意点
- <Grilling で発見したリスクや制約>
このIssueを作成しますか？
「はい」または修正指示を待つ。
Phase 3: Issue 作成
gh issue create \
--title "<タイトル>" \
--body "<生成したbody>"
作成後：
Issue #<番号> を作成しました。
次は /pr-develop #<番号> で開発セッションを開始してください。
