Create PRD

引数で受け取ったアイデアについて AskUserQuestion で不明点を潰し、確定した内容を PRD 形式の GitHub Issue として作成するスキル。

このスキルは対話専用。ユーザーと直接やり取りするため context: fork は持たず、ワーカーからも自動起動しない。

スコープ: PRD（何を・なぜ作るか）までを扱い、実装プラン・コード分析は行わない（それらは breakdown-issues 以降の責務）。

モデル: 本文の起草（ステップ3）は fable のサブエージェントへ委譲する。PRD は散文が成果物なので文章生成に強いモデルを使いたい一方、スキル本体に model: は書けない（model: は context: fork が無いと効かず、fork すると別コンテキストになって AskUserQuestion でユーザーへ質問できなくなる）。質問はメインセッションで行い、モデル指定が意味を持つ起草だけを切り出す。

Instructions

GitHub アクセス

本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。

実行ステップ

1. 入力の把握

依頼内容:

$ARGUMENTS

引数が空の場合は、何の PRD を作りたいかを AskUserQuestion で尋ねてから続行する。

リポジトリに .claude/requirements/README.md があれば読み、関係するカテゴリファイルだけを読む（過去に確定した仕様判断を質問として蒸し返さないため）。コードの詳細調査はここでは行わない。

2. 不明点の質問（繰り返し）

PRD を確定させるうえで結論が変わる論点だけを AskUserQuestion で質問する。1回の呼び出しにつき最大4問、最大3ラウンドまで繰り返す。

質問の候補（該当するものだけ。網羅ではなく、依頼内容から欠けているものを選ぶ）:

• 解きたい課題と、その課題を持つ利用者は誰か
• スコープに入れないもの（対象外の明示）
• 成功をどう測るか（指標・受け入れ基準）
• 優先度・リリース時期の制約
• 既存機能との関係（置き換えか、追加か）
• 非機能要件（性能・権限・データ保持など）で外せないもの

規律:

• 調べれば分かることは質問しない（リポジトリ・.claude/requirements/ を先に見る）
• 一般的な既定値で埋まる論点は質問せず、既定を選んで PRD の「前提」に1行で書く
• 3ラウンドで解消しない論点は質問を打ち切り、PRD の ## 未決事項 へ移して先へ進む（合意形成でループさせない）

3. PRD 本文の起草（fable へ委譲）

Agent ツールで model: "fable" を指定したサブエージェント（subagent_type: "general-purpose"）に本文の起草を委譲する。渡すのは以下だけで、サブエージェントは本文の markdown を返すだけにする（Issue の作成・gh の実行はメインが行う。サブエージェントはユーザーへ質問できないため、判断が要る点は起草側で埋めず未決事項として返させる）。

• 引数の依頼内容
• ステップ2でユーザーから得た回答（逐語で）
• ステップ1で読んだ要件ルールのうち関係する記述
• 下記の本文テンプレートと分量の規律

返ってきた本文がテンプレートの見出し構成を満たしていない場合はメインで直す（再委譲はしない）。fable が利用できない環境ではメインセッションでそのまま起草する（委譲の失敗を理由に中断しない）。

以下のテンプレートに従う。内容がある分だけ書く（埋めるための言い換え・無内容な行を書かない）。該当が無いセクションは - なし の1行で残す（省略しない）。

## 背景
（なぜ今これが必要か。1-3段落）

## 課題
- （解きたい課題を箇条書き。誰のどの困りごとか）

## ゴール
- （このPRDが達成したい状態。測れる形で）

## スコープ外
- （今回やらないことを明示）

## ユーザーストーリー
- （〜として、〜したい。なぜなら〜）

## 要件
### 機能要件
- （箇条書き。1項目1行）

### 非機能要件
- （性能・権限・データ・運用など。無ければ `- なし`）

## 成功指標
- （どうなったら成功と判断するか）

## 前提
- （質問せず既定で埋めた判断があればここに残す。無ければ `- なし`）

## 未決事項
- （ステップ2で解消しなかった論点。無ければ `- なし`）

4. Issue の作成

--body "..." 形式は使わない（本文中のバッククォート・$・改行でエスケープが壊れるため）。必ず --body-file - + <<'EOF' の heredoc を使う。

ラベルは付けない。cc-triage-scope などのトリガーラベルを付けると PRD がそのままワーカーへ流れ、タスク分解を経ずに実装が始まってしまう。分解は /breakdown-issues <番号> が担い、その中で cc-epic-issue が付与される。

ME=$(gh api user --jq '.login')

PRD_ISSUE_URL=$(gh issue create \
  --title "[PRD] <プロダクト・機能名>" \
  --assignee "$ME" \
  --body-file - <<'EOF'
## 背景
...
EOF
)

5. 報告

結論から3行以内で報告する。PRD 本文の再掲はしない。

• 作成した Issue の番号・タイトル・URL
• ## 未決事項 が空でない場合はその件数と内容（1行ずつ）
• 次のステップとして /breakdown-issues <番号> でタスク分解できる旨

中断条件

以下のいずれかに該当する場合のみ、理由を1-2行で出力して即中断する。

• gh issue create が失敗し、再試行しても解消しない
• ユーザーが質問への回答を拒否し、PRD の骨子（課題・ゴール）が確定しない

注意事項

• 本スキルはコードを一切変更しない。Issue の作成のみを行う
• 実装プラン・影響ファイル一覧は書かない（PRD の粒度を超え、後続の実装スコープを先に固定してしまう）