bmad-product-planning

プロダクト要件スキル

呼び出すタイミング

ユーザーが次のような場合、このスキルを自動的に有効にします：

• 「〜を作りたい」「作りましょう」「〜を作成して」と言う
• 「PRDを作成して」「要件を書いて」「この機能を計画して」と依頼する
• 「プロダクト要件」「PRD」「エピックロードマップ」に言及する
• ディスカバリーフェーズを完了し、正式な要件を必要としている
• 構造化された計画を必要とするレベル2〜4のプロジェクトを開始する
• build、create、PRD、requirements、plan、feature、product のような単語を使う

具体的なトリガーフレーズ：

• 「[何か]を作りたい」
• 「[プロジェクト]のPRDを作成して」
• 「この機能を計画して」
• 「要件を書いて」
• 「PRDには何を含めるべき？」
• 「これをエピックに分割して」
• 「[プロジェクト]のプロダクト要件」

前提条件の確認：

• レベル3〜4のプロジェクトの場合：分析フェーズが完了していることを確認します（ディスカバリーブリーフが存在すること）。
• 分析が未完了の場合：まずbmad-discovery-researchを呼び出すよう提案します。
• レベル0〜1の場合：代わりにOpenSpecワークフローを提案します。

次の場合は呼び出さないでください：

• ユーザーがまだ探索やブレインストーミングの段階にある（まずbmad-discovery-researchを使用します）
• アーキテクチャ設計に進む準備ができている（代わりにbmad-architecture-designを使用します）
• ユーザーがすぐにコーディングしたい（まず前提条件がそろっているか確認します）
• プロジェクトがレベル0〜1の単純な変更である（OpenSpecを使用します）

ミッション

検証済みのディスカバリーインサイトを、ステークホルダーの認識を合わせ、後続のアーキテクチャ、UX、デリバリー作業に備える、プロダクション対応のプロダクト要件定義書（PRD）とエピックロードマップにまとめます。

必要な入力

• business_goal：測定可能な成功指標に結び付いた、明確な成果の記述
• stakeholders：意思決定者と、その承認状況または未解決の懸念
• constraints：技術、規制、財務、またはスケジュール上の制約
• discovery_artifacts：ブリーフ、調査メモ、またはディスカバリー分析スキルで作成したメモ

入力が不足している、または古くなっている場合は、作業を中断し、必要な成果物を具体的に求めてください。

出力

assets/内のテンプレートに沿って、次の2つのMarkdown成果物を作成します：

1. assets/prd-template.md.templateをもとに作成したPRD.md
2. assets/epic-roadmap-template.md.templateをもとに作成したepics.md

成果物はプロジェクトのドキュメントフォルダー（既定ではdocs/）に書き込み、依頼者向けに要約します。

プロセス

1. CHECKLIST.mdのゲートを使用して準備状況を確認します。
2. ディスカバリーの入力資料を確認し、残っている不明点を明確にします。
3. 目標、スコープ、制約を構造化されたPRDのセクションにまとめます。
4. デリバリーに向けて、エピックの優先順位、順序、受け入れ基準を決定します。
5. 構造化データがある場合はscripts/generate_prd.pyを実行します。ない場合は、テンプレートに沿って手動で成果物を作成します。
6. 品質チェックリストを適用してから、成果物と推奨する次のステップを提示します。

品質ゲート

PRD一式を提出する前に、CHECKLIST.mdのすべての項目が満たされていることを確認します。満たされていない項目があれば、作業を止めて修正します。

エラー処理

前提条件が不足している、または矛盾が見つかった場合：

• 不足している必須入力と、それが作業を妨げる理由を特定します。
• 必要な追加質問や関係者を最小限のリストで提示します。
• スコープが不明確な場合は、ディスカバリー分析スキルまたはオーケストレーターに再度確認するよう提案します。