build-prd

build-prd

ユーザーとの共同ディスカッションを通じてプロダクト要件定義書を作成し、実装にすぐ着手できる完全な GitHub issue として仕上げます。

使用する場面

• ユーザーが「PRD を作成して」や「要件を書いて」と依頼した場合
• feature-request または enhancement ラベルが付いた GitHub issue をもとに作業する場合
• ユーザーが実装前に要件を文書化する必要がある場合
• 曖昧なアイデアを、構造化された実装可能な仕様に変換する場合

使用しない場面

• issue に完全な PRD がすでにある場合（タイトルに [PRD] が付いているか確認します）
• 純粋なバグ報告の場合 — 要件ではなく再現手順が必要です
• すでに実装が始まっている場合 — 代わりに仕様を遡って作成します

前提条件

gh auth status        # GitHub CLI authenticated
gh repo view          # Inside a valid repo (or org/repo provided)

ワークフロー

ステップ 1：依頼を理解する

GitHub issue から開始する場合：

gh issue view ISSUE_NUMBER --repo ORG/REPO

プロジェクトのコンテキストを確認します：

cat project-instructions.md  # or equivalent project instructions file
cat README.md

依頼の核心を 1～2 文で説明します。説明できない場合は、続行する前にユーザーに確認を求めます。

ステップ 2：不足点を特定する

必要な PRD セクションと依頼内容を照合します。

セクション	必須？	情報源
問題の説明	はい	なぜ重要ですか？
ユーザーストーリー	はい	誰が、なぜ必要としていますか？
成功指標	はい	成功をどのように測定しますか？
スコープ（対象範囲と対象外）	はい	何を含め、何を除外しますか？
技術的制約	はい	制限、統合、パターンはありますか？
モックアップ／例	いいえ	利用可能な視覚的参考資料
依存関係	いいえ	関連する機能やシステム
タイムライン	いいえ	優先度や期限

不足している項目について質問のリストを作成します。

ステップ 3：すべての質問をまとめて尋ねる

To create a complete PRD, I need some additional information:

Q1: [specific question]
Q2: [specific question]
Q3: [specific question]
Q4 (Optional): [nice-to-have question]

警告： 質問はすべて一度に尋ねてください。1 つずつ小出しにしないでください。ユーザーの時間を無駄にし、やり取りの流れを妨げます。

GitHub issue をもとに作業する場合は、question ラベルを追加します：

gh issue edit ISSUE_NUMBER --repo ORG/REPO --add-label "question"

続行する前に、ユーザーの回答を待ちます。

ステップ 4：PRD の下書きを作成する

このテンプレートを使い、すべてのプレースホルダーを実際の内容に置き換えます。

# [Feature Name]

## Problem Statement
[2-3 sentences: what user problem this solves and why it matters now]

## User Stories
- As a [user type], I want [goal] so that [benefit]
- As a [user type], I want [goal] so that [benefit]

## Success Metrics
- [Metric]: [specific target or measurement approach]
- [Metric]: [specific target or measurement approach]

## Scope

### In Scope
- [Concrete feature or deliverable]
- [Concrete feature or deliverable]

### Out of Scope
- [Explicitly excluded item — prevents scope creep]
- [Explicitly excluded item]

## Technical Requirements
- [Requirement referencing existing codebase patterns]
- [Constraint or integration point]

## Dependencies
- [Related system or feature, if any]

## Open Questions
- [Anything unresolved — do not guess]

## Implementation Notes
[Architectural decisions, patterns to follow, files to reference]

ステップ 5：ユーザーと確認する

PRD の下書き全体を提示します。前提事項を明示します。

I've drafted a PRD based on our discussion. Please review:

[FULL PRD]

Assumptions I made:
- [Assumption 1]
- [Assumption 2]

Does this capture everything? Anything to change?

警告： ユーザーの明示的な承認なしに、ステップ 6 に進んではいけません。「よさそうです」や「はい」は承認とみなします。返答がない場合は承認とみなしません。

ステップ 6：GitHub issue を更新する

ユーザーの承認後に限り、次の操作を行います。

gh issue edit ISSUE_NUMBER --repo ORG/REPO \
  --body "$(cat /tmp/prd-draft.md)" \
  --title "[PRD] Feature Name" \
  --add-label "ready-to-work"

gh issue edit ISSUE_NUMBER --repo ORG/REPO --remove-label "question" 2>/dev/null || true

ラベル	操作
ready-to-work	追加 — PRD が完成したことを示します
question	存在する場合は削除
feature-request、enhancement	維持 — 元のラベルを保持します

ステップ 7：確認する

gh issue comment ISSUE_NUMBER --repo ORG/REPO \
  --body "PRD created. Issue updated with complete requirements. Ready for implementation planning."

エラー処理

ユーザーがスコープを決められない場合 — MVP を提案します。中核となる価値に不可欠なものだけを含め、それ以外は「スコープ外（今後対応）」に移します。

スコープが広すぎる場合 — それぞれ 1 つの機能に焦点を当てた複数の PRD に分割するよう提案します。まず基盤となる PRD から始めます。

ユーザーが要件ではなく実装の詳細を提示する場合 — 次のように促します。「実装の前に、何を解決するのかを明確にしましょう。ユーザーが現在できないことで、できるようになるべきことは何ですか？」

成功指標が不足している場合 — 機能の種類に応じて、次の指標を提案します。

機能の種類	推奨指標
ユーザー向け	採用率、使用頻度、満足度
パフォーマンス	レイテンシの削減、エラー率の低下
開発者向けツール	削減できた時間、コード品質の向上
インフラストラクチャ	稼働時間、コスト削減、インシデント発生頻度

重要なルール

• ユーザーの明示的な承認なしに GitHub issue を更新してはいけません — PRD は合意事項です
• 技術的な詳細を決して捏造してはいけません — 不明な点は未解決の質問として記載します
• すべての質問をまとめて尋ねます — 1 回のメッセージで Q1～Qn の番号を付けます
• 最終 PRD にプレースホルダーテキストを残しません — すべての角括弧内を置き換えます
• 元のラベルを保持します — ready-to-work のみを追加し、feature-request や enhancement は削除しません