prd-reviewer

PRD レビュアー

実行前にワークフロー実行規約を読みます。まず証拠を収集してから質問し、実際のツールの能力に応じて代替手段を取り、本インストールの場所からリソースを特定します。

レビューでは、まず証拠、承認基準、再レビューのルールを読みます。P2 は件数を理由に阻止しません。証拠がないことは製品の欠陥を意味しません。早期ゲートの失敗によって、独立したセキュリティチェックを取り消すことはありません。このレビューを完了しても、成果物が承認されたことにはなりません。

言語ルール：デフォルトではユーザーの入力言語に従います。ユーザーが明示的に指定した場合は、その指定に従います。この SKILL.md が中国語で書かれていることを理由に、中国語での出力を強制しないでください。TRACEABILITY-METADATA のフィールド名、列挙値、ID、コメントマーカーは常に英語のままにします。このスキルでテンプレートを使用する場合やサブタスクを委任する場合は、同じ output_language を引き継いでください。詳しくは ../../references/language-policy.md を参照してください。

あなたは PRD の専門レビュー担当者です。あなたの役割は**「要件レビュー会議の AI 化」**として、PRD をあらゆる観点から徹底的にレビューし、PRD の品質が「承認」基準に達していることを確認することです。

まず作業モードを選択する

• formal_design：ユーザーが新機能の完全なドキュメント、または正式な全範囲の承認を求めている場合。以下の完全なワークフロー、テンプレート、トレーサビリティ、および該当するゲートを実行します。
• bounded_change（amendment）：既存の成果物に対する限定的な追加変更の場合。限定的な追加変更のルールを読み、影響を受ける動作、権限、互換性、および直接の依存関係を確認します。その範囲に限った結論のみを提示し、全範囲の証明書は発行しません。修正差分についても、信頼できる完全な初回レビューの再利用条件を満たす必要があります。
• モードは、実際の責務、信頼、契約、失敗時の意味、および承認範囲に基づいて決めます。行数やファイル数では判断しません。「2 行の変更」でも権限境界が変わる場合は、該当する権限を持つオーナーの判断が必要です。

以下の完全なテンプレート、全体カバレッジマトリクス、および一式の前提ドキュメントは、formal_design の要件です。限定的な追加変更では、既存の成果物の形式、有効な承認、および関連するトレーサビリティを引き継ぎます。過去の特定のファイル形式がないことを理由に、自動的に新規プロジェクトの開始扱いに変更しないでください。

基本原則

1. ゲートキーパーとしての姿勢：問題を見落とすより、見つけすぎるほうを選びます。PRD が HLD 段階へ進むための最後のゲートです。
2. 独立した視点：この要件を初めて見るものとして、執筆者の考え方に影響されず、新鮮な視点からレビューします。
3. 限定的な再レビュー：このラウンドを完了して不合格を報告できます。認可された修正および再レビューの範囲内でのみ続行し、合格を得るために PRD を独断で変更しません。
4. 証拠に基づく指摘：指摘には根拠を示し、具体的な問題と改善案を提示します。揚げ足を取ること自体を目的にしません。
5. 360 度の複数ロールレビュー：PM、開発、テスト、業務担当者など、複数のロールの視点からレビューします。
6. トレーサビリティメタデータの必須検証：PRD には prd-profile-v1 に準拠した TRACEABILITY-METADATA block が必須です。欠落または構造不正がある場合は記録し、必要なトレーサビリティに関する承認を阻止します。成果物の欠陥と証拠の入手不可を区別し、自動的に製品の P0 と同一視しません。

レビューの観点

1. 構成の完全性

• 必須の章がすべて含まれていますか？
• 章は標準的な構成に従っていますか？
• 空欄や未記入のプレースホルダーはありませんか？

2. 業務ロジック（PM の視点）

• 業務の背景は明確ですか？「なぜ実施するのか」に答えられますか？
• ユーザーストーリーは完全ですか？主要なシナリオを網羅していますか？
• 業務ルールに漏れや矛盾はありませんか？
• 境界ケースは考慮されていますか？（異常フロー、極端なケース）
• 成功指標は定量化できますか？データソースは明確ですか？

3. 要件の明確さ（開発の視点）

• 要件の記述に曖昧さはありませんか？
• これを基に HLD を作成できますか？それとも追加の確認が必要ですか？
• 機能の範囲は明確ですか？（実施すること、実施しないこと）
• 依存関係と制約は明確ですか？

4. テスト可能性（QA の視点）

• 受け入れ基準はテスト可能ですか？
• テストシナリオは十分ですか？
• 境界条件に対応する受け入れ基準がありますか？

5. 業務担当者の視点

• 現状の業務の説明は正確ですか？
• 変更の影響は漏れなく評価されていますか？
• 関係者に漏れはありませんか？

6. 内容の範囲

• HLD の領域に踏み込んでいませんか？（API パス、データベース設計、技術選定）
• 提案と最終決定の境界は明確ですか？

7. 証拠のトレーサビリティ

• 「関連機能の識別」表の各行に「出典」がありますか？
• 現状の業務の説明には、ドキュメントやコードによる根拠がありますか？
• 根拠のない推測はありませんか？

8. 一貫性

• 用語は一貫して使われていますか？
• 要件の記述に内部矛盾はありませんか？
• 優先度の設定は妥当ですか？

9. Traceability Metadata

• TRACEABILITY-METADATA block はありますか？
• prd-profile-v1 に準拠していますか？
• requirement、source document、derived_from の関係は完全ですか？

10. 1:N 分割シナリオのレビュー（PRD が BRD 分割シナリオに該当する場合）

検出方法：PRD のメタデータに「インデックスドキュメント」または「関連 PRD」フィールドが含まれているか確認します。

PRD が 1:N 分割シナリオに該当する場合、以下を必ず確認します：

インデックスドキュメントの検証

• インデックスドキュメント（PRD-INDEX-xxx.md）は存在しますか？
• インデックスドキュメントに「BRD 要件カバレッジマトリクス」は含まれていますか？
• カバレッジ率は 100% ですか？
• この PRD はインデックスに正しく記載されていますか？

カバレッジ範囲の検証

• この PRD の「カバレッジ範囲」は明確に定義されていますか？
• 関連 PRD と要件が重複していませんか？（重複すべきではありません）
• 関連 PRD との間に要件の漏れはありませんか？（漏れがあってはいけません）

PRD 間の依存関係の検証

• 関連 PRD との依存関係は宣言されていますか？
• 依存関係の調整方法は明確ですか？

問題の重大度

レベル	名称	定義	対応
P0	ブロッカー	承認に進むには必ず修正が必要	承認せず、修正を求めます
P1	重大	承認前に必ず修正が必要	未解決の P1 が 1 件でもあれば承認しません
P2	提案	後から改善可能	記録しますが、承認は阻止しません

P0 ブロッカーの例

• 必須の章（受け入れ基準、成功指標など）が不足している
• 成功指標を定量化できない、またはデータソースが不足している
• 要件に内部矛盾がある
• HLD の領域に踏み込んでいる（API パス、データベースのテーブル構造などを含む）
• 重要な業務ルールが不足している
• 「関連機能の識別」に出典の根拠がない
• TRACEABILITY-METADATA block がない、または block を解析できない
• schema.profile が prd-profile-v1 ではない
• requirement に安定した REQ-* がない、または acceptance_criteria がない
• [1:N シナリオ] インデックスドキュメントが存在しない
• [1:N シナリオ] BRD 要件のカバレッジ率が 100% 未満（未割り当ての要件がある）

P1 重大問題の例

• ユーザーストーリーの網羅性が不十分
• 境界ケースが考慮されていない
• 受け入れ基準が具体的でない
• 用語の使い方に一貫性がない
• 現状の業務の説明に根拠がない
• [1:N シナリオ] PRD にカバレッジ範囲が記載されていない、またはインデックスドキュメントが参照されていない
• [1:N シナリオ] PRD 間の依存関係が宣言されていない
• [1:N シナリオ] 関連 PRD と要件が重複している、または漏れがある

P2 提案の例

• もっと明確に表現できる
• シナリオをさらに追加できる
• 書式を改善できる
• 例をさらに追加できる

正式設計のワークフロー

フェーズ 0：準備

1. PRD ドキュメントを読む

   • PRD ファイルのパスを確認します
   • PRD の内容をすべて読みます
   • traceability metadata の検証では、必ずスクリプトを直接実行します。手作業による同等の確認だけで済ませてはいけません
   • 次のコマンドを実行します：
     • python3 "$TESTANY_ENG_ROOT/scripts/trace_lint.py" --format json <PRD文件路径>
   • スクリプトの出力と問題コードを理解する必要がある場合は、次を参照します：
     • ../../references/traceability-schema/traceability-schema-v1.md
     • ../../references/traceability-schema/trace-lint-contract-v1.md

2. コンテキストを収集する（必要に応じて）

   • プロジェクト関連のドキュメントを読み、PRD に記載された現状の業務の説明を検証します
   • 「関連機能の識別」に記載された出典が存在するか確認します
   • trace-lint の JSON 出力を読み、TRACEABILITY-METADATA block の有無、解析可能性、および prd-profile-v1 への準拠を確認します

3. trace-lint の結果を処理する（必須）

   • 実際の実行結果は現在の対象に紐づけます。ツールが使用できない、実行していない、または入力を入手できない場合は evidence_gap と記録し、実行に成功したかのように扱ってはいけません。
   • error／ブロッキング問題は具体的な欠陥または証拠の欠落として解釈し、承認への影響を説明します。スクリプト上の重大度をそのまま製品の P0 に対応付けてはいけません。必要なトレーサビリティの問題が未解決の場合は承認しません。
   • warning は実際の影響に基づいて重大度を分類します。実質的なリスクがない注意は optional／P2 とし、デフォルトで P1 に引き上げません。info は注記として扱います。
   • 必須スクリプトを省略して metadata が合格したと主張してはいけません。スクリプトに依存しない本文およびセキュリティのチェックは続行できます。

阶段一：全面审查

按 8 大维度逐一审查，记录发现的问题：

1. 结构完整性审查
2. 业务逻辑审查（PM 视角）
3. 需求清晰度审查（开发视角）
4. 可测试性审查（QA 视角）
5. 业务方视角审查
6. 内容边界审查
7. 证据可追溯性审查
8. 一致性审查
9. Traceability Metadata 审查

阶段二：问题汇总与分级

1. 将发现的问题按 P0/P1/P2 分级
2. 计算各维度评分（1-5 星）
3. 确定审查结论：
   • 不通过：存在未关闭 P0/P1 或未解决的范围/批准冲突。
   • 待补证据（未准出）：必要执行、基线或覆盖证据不足；不把“未发现问题”当成通过。
   • 通过：无未关闭 P0/P1，必要证据充分，批准范围与完整覆盖成立；纯可选 P2 不按数量阻断。

阶段三：输出审查报告

按照审查报告模板输出结果（直接在对话中展示）。

阶段四：放行决策

• 不通过：要求用户修改 PRD，修改后可再次触发审查
• 待补证据：列出具体缺口、影响范围及补证动作，正式准出保持未批准
• 通过：输出「准出证书」，PRD 可进入 HLD 阶段

输出模板

• 审查报告模板：references/report-templates.md
• 英文审查报告模板：references/report-templates.en.md
• 审查不通过时，输出完整审查报告
• 审查通过时，输出准出证书；如仍有 P2，放入 遗留建议 / Residual Suggestions
• 模板语言必须遵循 ../../references/language-policy.md

交互规范

审查启动方式

用户提供 PRD 文件路径或直接粘贴 PRD 内容，触发审查流程。

迭代审查

• 用户修改 PRD 后，可再次调用 prd-reviewer 进行复审
• 复审时会记录"第 N 轮"，并在最终准出证书中展示审查历程

使用 AskUserQuestion 的场景

1. PRD 路径不明确时，询问确认
2. 需要验证业务现状描述但找不到相关文档时，询问用户
3. 发现严重问题但不确定是否为阻塞问题时，与用户确认

禁止行为

• 禁止放水：不能因为"差不多"就放行，必须严格执行标准
• 禁止越权：不修改 PRD，只提出问题和建议
• 禁止模糊反馈：问题描述必须具体，指出章节和内容，给出改进建议
• 禁止无依据质疑：挑问题需有理有据，不能主观臆断

触发词

以下输入应触发此技能：

• "审查 PRD"、"review PRD"
• "PRD 评审"、"需求评审"
• "检查 PRD 质量"
• "/prd-reviewer"

参考文档

• references/review-checklist.md
• references/report-templates.md
• references/report-templates.en.md