doc-prd

doc-prd

目的

**製品要件定義書（PRD）**を作成します。SDD フローのレイヤー 2 です。 PRD では、C4 コンテナレベルで製品の機能、ペルソナ、成功指標、受け入れ基準を定義します（製品が何をするかであり、どのように実現するかではありません）。

レイヤー：2（コンテナレベル）。上流：BRD。 下流：EARS → BDD → ADR → SPEC → TDD → IPLAN → Code。

BRD の反復サイクル（MVP → PROD → 新しい MVP）ごとに PRD を 1 つ作成します。新しいスコープには新しい PRD を作成し、@depends: PRD-NN でサイクルをリンクします。

使用するタイミング

次の場合に doc-prd を使用します。

• BRD が存在し、製品機能とユーザー要件を定義する必要がある場合。
• ビジネスニーズを製品の機能、ペルソナ、KPI に落とし込む場合。
• BRD §8 のアーキテクチャに関するトピックを、ADR 向けの技術的な選択肢として詳述する場合。

BRD、プロンプト、または IPLAN からエンドツーエンドで生成する場合は、 ../doc-prd-autopilot/SKILL.md を使用してください。

前提条件

PRD には上流の BRD が必要です。作成する前に、以下を確認してください。

1. 上流 BRD — この PRD の基となる BRD です。セクションファイル（docs/01_BRD/BRD-NN_{slug}/）に分割されている場合は、すべてのファイルを 1 つの論理文書として読んでください。
2. テンプレート（信頼できる唯一の情報源）： ${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/PRD-TEMPLATE.yaml
3. レイヤーの README： ${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/README.md
4. ID とタグの標準： ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md
5. 文書作成スタイル： ${CLAUDE_PLUGIN_ROOT}/framework/governance/AUTHORING_STYLE.md

ID が重複していないことを確認します：ls docs/02_PRD/ 2>/dev/null。存在する BRD の要素のみを参照し、BRD-XXX や TBD のようなプレースホルダーを作成しないでください。PRD の ID は BRD の ID と一致する必要はありません（PRD-09 が BRD-16 を実装してもかまいません）。

レイヤーのガイダンス

内容の境界（ここに含める内容を判断する）

PRD はコンテナレベルです。製品の機能、ユーザージャーニー、エラー処理を記述し、それ以外はすべて下流に委ねてください。

内容	該当レイヤー
製品機能、ペルソナ、KPI、ユーザージャーニー	PRD（このレイヤー）
WHEN-THE-SHALL-WITHIN 形式の正式な要件	EARS（レイヤー 3）
実行可能な Given-When-Then シナリオ	BDD（レイヤー 4）
アーキテクチャ上の決定	ADR（レイヤー 5）
スキーマ、エンドポイント、インフラ設定	SPEC（レイヤー 6）

必須の構成（15 セクション）

document_control を最初に配置します（製品名、バージョン、ステータス、日付、作成者／レビュー担当者／承認者、@brd: 参照、EARS 対応度スコア、改訂履歴）。続いて：

2. エグゼクティブサマリー（MVP 仮説を含む） · 3. 問題の説明 ·
3. 対象読者とユーザーペルソナ · 5. 成功指標と KPI ·
4. 目標と目的 · 7. スコープと要件 · 8. ユーザーストーリーとユーザーロール ·
5. 機能要件（ユーザージャーニーと図の契約を含む） ·
6. 顧客向けコンテンツとメッセージング · 11. 受け入れ基準 ·
7. 制約と前提 · 13. リスク評価 · 14. トレーサビリティ （ADR トピックの詳述を含む） · 15. 用語集。

各セクションの内容と埋め込みの _guidance については、PRD-TEMPLATE.yaml を参照してください。

セクション 8 — ユーザーストーリー（レイヤー分離、必須注記）

ロールの定義とストーリーの要約（As a [role], I want [capability] so that [benefit]）を、製品レベルの受け入れ基準のみとともに記載します。次の注記を含めてください：詳細な動作は EARS に、実行可能なシナリオは BDD に記載します。 ここに WHEN-THE-SHALL や Given-When-Then を記述しないでください。

セクション 10 — 顧客向けコンテンツ（必須、ブロッキング）

次のカテゴリのうち少なくとも 3 つについて、実質的な内容を記載する必要があります：製品の位置づけ、主要メッセージ、機能の説明、ドキュメント、ヘルプテキスト、エラーメッセージ、成功確認、オンボーディング、リリースノート。プレースホルダーのみの内容はブロッキングエラーです。

セクション 14 — ADR トピックの詳述

BRD §8 のトピックについて、技術的な選択肢と評価基準を詳述します。レイヤーの分離：BRD = 何を、なぜ · PRD = 評価方法 · ADR = 決定。ADR の番号は参照しないでください — ADR はまだ存在しません。

要素 ID とタグ

• 階層型の要素 ID：PRD.{doc_id}.{section_id}.{hash}（例： PRD.01.09.b3f2）。各要素には、セクション内で重複しない安定した 4 桁の 16 進数識別子（HASH01）を付与します。衝突した場合は 8 桁に拡張します。このプロンプトでは SHA-256 を計算しないでください。ハッシュ形式は、決定論的なツール処理で生成される正規化のターゲットであり、バイト単位で厳密なフィールド抽出が定義されているのは BRD §7 のみです（PRD では Phase 2 以降）。参照元：framework/governance/ID_NAMING_STANDARDS.md。 SS は要素が存在するセクションを示します。数値のタイプコードは使用しません。
• PRD は Layer 2 のため、@brd: タグを付与します（例： @brd: BRD.01.07.a7f3）。下流の成果物では、PRD にタグを付与します：@prd: PRD.01.09.b3f2。
• 廃止されたパターン（使用禁止）：FR-XXX、US-XXX、AC-XXX、F-XXX、および旧形式の 3 セグメント PRD.NN.xxxx。
• 変更される可能性がある定量値には、@threshold: PRD.NN.{category}.{key} を使用します（カテゴリ：quota、risk、perf、timeout、rate）。

作成プロセス

1. 親 BRD を読む — すべてのセクションファイルを 1 つのドキュメントとして扱い、目標、ステークホルダー、成功基準、§8 のトピックを抽出します。
2. ID を予約する — 次に空いている PRD-NN（2 桁：PRD-01、PRD-99、PRD-102）。 レイヤーごとの独立性（CLEANUP-PR-F item 18）： 自分のレイヤーのインデックスで次に空いている番号を選びます。上流の番号は自分の番号ではありません（ドキュメント番号はレイヤーごとに連番で独立しています。framework/governance/ID_NAMING_STANDARDS.md §Cross-layer cardinality を参照）。
3. ネストされたフォルダーを作成する — サイズにかかわらず、すべての PRD を docs/02_PRD/PRD-NN_{slug}/ に配置します。モノリシック形式：フォルダー内に PRD-NN_{slug}.md を配置。セクション形式（>25 KB）：PRD-NN.S_{section}.md を配置します。
   • ${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/PRD-00_index.TEMPLATE.md のインデックスを使用します。
4. 最初に Document Control を記述し、その後テンプレートの全 15 セクションを完成させます。
5. §10 を記入し（顧客向けカテゴリを 3 つ以上）、§14 の ADR トピックを詳述します（ADR 番号なし）。
6. 既存の BRD 要素を参照する @brd: タグを追加します。
7. PRD インデックス docs/02_PRD/PRD-00_index.md を更新し、同じ変更で親 BRD の Downstream Artifacts にこの PRD を追加します。
8. 検証し（以下を参照）、PRD、インデックス、BRD の更新をまとめてコミットします。

検証

このスキルがバリデーターです（ランタイムコードはありません）。${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/README.md と ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md に照らして適用します。

• Document Control が最初のセクションであり、@brd: 参照と EARS-Ready スコアが記載されている。
• 全 15 セクションが存在し、空ではない。
• §10 に 3 つ以上のカテゴリの実質的な内容がある（プレースホルダーではない）。
• §8 には PRD レベルの要約のみが記載され、レイヤー分離に関する注記がある。
• §14 で ADR トピックが詳述されており、ADR 番号を参照していない。
• 要素 ID が PRD.NN.SS.xxxx と一致し、SS が所属セクションと一致している。廃止されたパターンはない。
• @brd: タグが既存の BRD 要素を参照している。
• トレーサビリティ／インデックスが更新されている。親 BRD も更新され、リンク切れがない。
• 図の要件：@diagram: c4-l2 と @diagram: dfd-l2 がある（../charts-flow/SKILL.md を使用）。シーケンス図には alt/else が含まれている。

コード	意味	重大度
XDOC-002	必須の上流タグ（@brd）がない	エラー
XDOC-006	タグ形式が無効	エラー
XDOC-008	内部リンク切れ	エラー
XDOC-009	トレーサビリティセクションがない	エラー

品質ゲート（ブロッキング）： 次の工程に進む前に、EARS-Ready スコアが 90/100 以上であること。問題が見つかった場合は修正して再確認します。修正できない場合は、手動レビュー用に記録します。

次のスキル

../doc-ears/SKILL.md — EARS はこの PRD を参照し（@prd: PRD.NN.SS.xxxx）、PRD の機能を WHEN-THE-SHALL-WITHIN 要件として正式化します。（必要な上流契約に従い、EARS 自体が必要とするのは @prd のみです。上流の BRD との系譜は、@ タグの連鎖を通じて間接的にたどれます。）

適応

.aidoc/profile.yaml を読み込み、このスキルの設定項目 （section_toggles、glossary）のみを適用してください。 不明なキーは無視してください。プロファイルがない場合は、 フレームワークのデフォルト設定を使用してください。準拠先： ${CLAUDE_PLUGIN_ROOT}/framework/governance/ADAPTATION.md。

関連リソース

• テンプレート／作成ルール：${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/PRD-TEMPLATE.yaml
• レイヤーの README：${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/README.md
• インデックスのテンプレート：${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/PRD-00_index.TEMPLATE.md
• ID とタグの標準：${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md
• 上流の BRD：../doc-brd/SKILL.md
• 品質ゲート：../doc-prd-audit/SKILL.md · 修正：../doc-prd-fixer/SKILL.md
• 生成パイプライン：../doc-prd-autopilot/SKILL.md

クイックリファレンス

目的	プロダクトの機能、ペルソナ、KPI を定義します
レイヤー	2（コンテナー）
上流タグ	@brd（必要な上流契約に従う）
主要な判断事項	PRD レベルに残す内容と、下流に引き継ぐ内容
必須項目	ドキュメント管理（最初）、§10（3 カテゴリー以上）、§14 の ADR トピック、15 セクション
次へ	doc-ears