pr-plan

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 #<番号> で開発セッションを開始してください。