reviewing-prd

reviewing-prd — SKILL.md

バリアント： standard · 使用するタイミング： 完成した（または修正された）PRDを合否判定のゲートとして評価します。計画可能かを確認し、実行可能な指摘とともに VERDICT: approve|revise を出力します。

概要

このスキルは、PRDを作成する側と評価する側のペアのうち、レビューを担います。完成したPRDを手にしたレビュアーが読み込み、次の問いに照らして評価します。後続のビルドを計画できますか？ 固定された計画可能性に関する12項目のチェックリストを適用します。これは authoring-prd が作成時に目指す基準と同じであり、作成基準とレビュー基準がずれないようにします。また、捏造された証拠を検出し、機械で解析できる単一の判定と、作成者が1回の修正で対応できる指摘を出力します。これは合否判定のゲートです。PRDを作成、修正、書き換えはしません。評価して指摘を返し、作成者が修正します。

有効化するタイミング

• 後続の計画を開始する前に、完成したPRDの承認／修正を判断する必要がある場合。
• 作成者が作成したPRDを評価する、独立したレビュアー／ゲート担当者である場合。
• 以前の revise 判定を受けて修正されたPRDを再評価する場合。
• 修正されたPRD（バージョン付き差分）を評価する場合 — 差分の範囲に限定したレビューを適用します（cond-12）。

次の場合は有効化しないでください：

• PRDを作成または修復する場合 → authoring-prd を使用してください。このスキルはPRDを作成しません。
• エンジニアリング設計文書（feature-spec、technical-design、plan、ADR、RFC）をレビューする場合 → design-review スキルを使用してください。そのゲートはコードベースに照らしてエンジニアリング上の主張を検証します。このゲートはプロダクトの計画可能性を評価するものであり、PRDのエンジニアリング上の後続文書には使用しません。
• テンプレートやセクションへの準拠を確認する場合 → それはテンプレートの問題です。このスキルが評価するのは基準に照らした品質であり、すべての見出しが含まれているかどうかではありません。
• その他の文書タイプをレビューする場合。

ワークフロー

ステップ1：新鮮な独立した視点でPRD全体を読む

作成者の説明に左右されず、初めて目にする文書であるかのように、PRDを最初から最後まで読みます。あなたの立場は、次のステップ（計画）のゲートキーパーです。指摘に意味があるのは、記載どおりではビルドを計画できないことを示す場合に限られます。主張、指標、スコープの記述、依存関係のうち、重要な前提となっている箇所をメモします。ステップ2ではそうした箇所を精査します。修正版の場合は、変更履歴／バージョン差分も読みます（cond-12）。

ステップ2：計画可能性に関する12項目のチェックリストを実施し、各項目を評価する

該当する各項目について、合格か不足かを判断します。項目が不合格となるのは、具体的に特定できる実際の欠陥がある場合に限ります。「別の表現にしたかった」は不足ではありません。不足がある場合は、正確な箇所と欠けている内容を記録します（ステップ4で実行可能な指摘にまとめます）。項目9～12はv1.2.0で追加され、それぞれに比例性の適用があります。そのため、内容の薄いPRDが新たに不合格になることはありません（項目10の孤立要素を設けないという中核部分は適用を緩和しない基準であり、内容の薄いPRDで緩和されるのはマトリックスだけです）。

能力境界のチェック項目（以下）は、capability_record が作成時の呼び出しに注入され、レビューのコンテキストとして利用できる場合にのみ適用されます。存在しない場合は該当なしとして扱います。境界が定義されていないのに、能力境界を示すマーカーがないことを理由に文書を減点してはいけません。

1. 問題が主張ではなく証拠で裏付けられている。 定性的な証拠（インタビュー、チケット、フィードバック）および／または定量的な証拠（コンバージョン、解約、離脱）に裏付けられ、具体的に規模が示され（例：「ステップ3での離脱は新規アカウントの42％に影響する」）、実際のユーザーの課題として提示されています。問題が根拠のない主張にすぎない場合、または情報源・規模・影響を受ける対象が示されず、証拠が曖昧な場合は 不足 です。
2. ユーザー／ペルソナが具体的である。 少なくとも主要なペルソナについて、現実的なニーズとシナリオ（ユーザーストーリー）が示されています。ユーザーが「ユーザー」という一般的な表現にとどまり、プランナーが設計の基準にできるニーズやシナリオがない場合は 不足 です。
3. 測定可能な成功指標（およびガードレール）がある。 成果指標は最大約4つ（小規模なプロジェクトなら1つでも十分）とし、各指標に目標値と測定方法を設定します。目標値や測定方法のない指標、虚栄指標は 不足 です。優先順位のないKPIを10個並べるのも不足です。ガードレールの確認： 見出しとなる指標が、明示された目標を損なう形で明らかに不正操作可能な場合に限り、ガードレール／逆指標の欠落を指摘します（「不正操作される可能性がある」という推測だけでは指摘しません）。妥当な指標が1つあるだけの簡素なPRDを修正対象にしてはいけません。
4. 根拠のあるMVPの範囲。 対象範囲と対象外の範囲が明確に分けられ、非目標とリリース基準が明示されています。v1の対象が何もかも含んでいる場合、非目標がない場合、または「リリース可能」の基準がない場合は 不足 です。
5. 具体的で計画可能な機能。 マイルストーンやタスクを導き出せるほど具体的な機能セットと受け入れ基準があり、それぞれを個別にテストできます（Given／When／Then形式は有力な指標です）。機能が抽象的な目標にとどまり、テスト可能な「完了」条件がない場合は 不足 です。
6. 証拠を捏造しない。 引用・統計・数値はすべて実在して検証可能であるか、検証が必要な仮定であると正直に明記されています。正確そうに見えて出典のない数値や、追跡できない調査は疑わしいものとして扱います。AIが作成したPRDでは、もっともらしい引用やデータが高い頻度で捏造されるためです。証拠が捏造されたように見えるのに事実として提示されている場合は、重大な 不足 です。仮定であることが正直に明記されていれば、不足ではありません。捏造された数値を事実として決して通してはいけません。（規模にかかわらず適用される、簡略化されない基準です。）
7. リスク、依存関係の状況、未解決の疑問が表に出ている。 真の不確実性とリスクが率直に示されています（リスクには発生可能性・影響・軽減策を記載し、未解決の疑問は列挙します）。PRDが誤って完成済みであるかのように読める場合は 不足 です。（依存関係の網羅性は条件11で扱います。この条件はリスクや不確実性を正直に表に出すことに関するものです。）
8. 明確で曖昧さがない。 専門用語を避け、用語が一貫しており（各エンティティに名前が1つだけ付けられている）、部門横断の読者がそれぞれの要件を一通りに解釈できます。曖昧さによって2人のプランナーが異なるものを作ることになる場合は 不足 です。（規模にかかわらず適用される、簡略化されない基準です。）
9. 非機能要件に目標値がある。 プロジェクトの類型で重要な非機能要件（NFR）のカテゴリが網羅され、それぞれに数値または確認可能な目標値があります（該当する場合、パフォーマンス／SLO／セキュリティ／プライバシー／アクセシビリティ WCAG 2.2 AA／スケーラビリティ／コンプライアンス）。重要なNFRが「高速であるべき」「安全であるべき」といった曖昧な形容詞だけで、目標値がない場合は 不足 です。簡略化： 簡素な社内ツールに必要なカテゴリは少数です。また、意図的にベストエフォートとし、その旨が明記されたNFRは不足ではありません。些細なツールに不要なSLOを要求してはいけません。
10. 追跡可能である（孤立した項目がない）。 目標セクションと要件／機能セクションを相互参照し、構造的に確認します。すべての機能が明記された目標を1つ以上支え、すべての目標に機能が1つ以上対応しています。指標は目標に結び付いており、ストーリーにはACがあります。機能が明記された目標を何も支えていない場合、または目標に対応する機能が1つもない場合は 不足 です。簡略化： 目標が1つ、機能が1つの小規模なPRDなら、追跡関係は自明です。（孤立項目がないというルールは、規模にかかわらず簡略化されない基準です。どの規模でも、目標に結び付かない機能は不適切です。簡略化されるのは、小規模なPRDでは複雑な対応表が不要という点だけです。）
11. 依存関係が明記されている。 実行順序を左右する、チーム間および外部の依存関係（サービス、データ、サードパーティ、必要な承認）が表に出ています。実行順序を妨げる重大な依存関係が本文に埋もれている、または記載されていない場合は 不足 です。簡略化： 外部依存関係のない単独のツールなら、自明にこの条件を満たします（「なし」も有効な回答です）。
12. 変更の整合性（差分の範囲に限定 — 変更のレビュー時のみ）。 変更されていないPRD全体を再レビューするのではなく、変更点とその波及をレビューします。（a）変更箇所が計画可能性の基準を満たしている。（b）変更履歴（誰が／いつ／何を／なぜ）がある。（c）置き換えられた内容が、黙って削除されるのではなく明示されている。（d）波及の整合性が保たれている（機能の削除によって、その指標／ACが孤立するなど、後続の追跡関係が宙に浮いていない）。簡略化： 新規の初回開発ではこの条件は適用されません。差分が適切に範囲設定され、追跡可能であれば approve とします。小規模な変更について、変更されていないセクションを再検証していないことを理由に誤って修正を求めてはいけません。
13. ケイパビリティの網羅性（ケイパビリティの記録がない場合は該当なし）： アクティブな L1 ケイパビリティ領域がすべて、名前付きのスコープセクションとして記載されています。

作成支援は、存在の有無ではなく成果で評価します。 指標・優先順位付けのフレームワーク（North Star／OKR／HEART／AARRR、RICE／MoSCoW／Kano）、アーキタイプ固有のオーバーレイ、GTM／ローンチ／サポートの準備状況、機会規模の算定、プレモーテム、JTBD の表記法は、作成者を支援するためのものです。評価するのは成果（適切な指標が選ばれているか、根拠のある境界が設定されているか、アーキタイプに応じた完成度があるか）であり、名前付きのフレームワークや特定のセクションを決して必須にしないでください。 基準に記載されていない GTM セクション、RICE スコア、「ML セクション」などを要求するのは、条件を勝手に作り出す誤りです（アンチパターンを参照）。

比例性。 「計画に十分な具体性」は、プロジェクトの規模に応じて変わります。規模の小さいプロジェクトでは、不要なセクションを正当に省略できます。該当する条件をすべて満たした、小規模で完全な PRD は合格です。文章量ではなく、意思決定の網羅性を評価してください。簡潔であることや、該当しないセクションが省略されていることを理由に不足を作り出さないでください（より充実したテンプレートには任意のセクションが多く含まれています。テンプレートのセクションの有無ではなく、基準に照らして評価してください）。

ステップ 3：判定を決める

• approve — 該当する条件をすべて満たしています。この PRD の記載どおりにビルドを計画できます。文体上の改善点を思いつく場合でも、承認してください。基準となるのは計画可能であることであり、完璧さではありません。
• revise — 該当する条件の 1 つ以上に、計画を妨げる具体的な不足があります（目標値のない指標、非目標の記載がない、抽象的な機能、捏造された統計、曖昧で重要な NFR、孤立した機能、埋もれた重大な依存関係、変更履歴のない修正など）。

努力を示すため、またはあれば望ましい項目を求めるために、修正を要求しないでください。条件は満たされているか、満たされていないかのどちらかです。

ステップ 4：判定と実行可能な指摘を出力する

判定は 1 行で出力してください。文字列 VERDICT: approve または VERDICT: revise を、単独の行に記載し、周囲にコードフェンス、引用符、余分な語句を付けないでください（ここでのフェンスは説明用にすぎません）。

VERDICT: approve

続く行に指摘を列挙してください。revise の場合、すべての指摘は実行可能である必要があります。つまり、不合格となった条件（番号または名前）、正確な箇所、修正方法を記載し、作成者が一度の作業で解決できるようにしてください。approve の場合、指摘は任意の非ブロッキングな注記です。修正が必要だと受け取られるような書き方は避けてください。

良い指摘は、不足点と修正方法を明示します。

revise — NFR（条件 9）：API の PRD に「高速であること」と記載されていますが、目標値がありません。修正：数値目標を記載してください（例：「ローリング 30 日間のウィンドウで p95 < 300ms」）。 revise — トレーサビリティ（条件 10）：機能「一括エクスポート」が、記載された目標のいずれにも対応付けられていません。修正：目標に関連付けるか、非目標に移してください。

悪い指摘は曖昧で、実行に移せません。

要件セクションをもっと充実させるとよいでしょう。(どの要件ですか？なぜ不合格なのですか？どう修正すればよいですか？)

ルール

絶対ルール（決して違反しないでください）：

• 判定行は VERDICT: approve または VERDICT: revise のいずれか1行だけを出力してください — その文字列を単独の行に記載し、同じ行にはほかに何も書かないでください。後続のツールがこれを解析します。
• 判断者に徹してください。作成者になってはいけません。 指摘事項を返してください。PRDを書き直したり、修正したり、内容を補ったりしないでください。修正するのは作成者です。
• 単一の基準に従ってください。 Step 2 の12の条件に照らして判断してください。これは作成者が成果物を作る際に用いるものと同じ基準です。独自の条件を作ったり、個人的により厳しい基準を設けたりしてはいけません。
• 条件を作り出さないでください。 作成支援（フレームワーク、類型別の補足、GTM、機会規模の推定、プレモーテム）は、名称ではなく結果で評価します。条件として列挙されていないのに「GTM／競合／ML のセクションも必要だ」や「RICE を使うべきだ」とするのは、レビュー基準を作成基準から逸脱させる行為です。禁止です。
• 誤って revise にしないでください。 適用されるすべての条件を満たす PRD は、簡潔なものであっても approve にしてください（簡潔な PRD では条件9〜12が該当しなくなります）。実際に特定できる欠落がある場合に限り revise にしてください。
• 誤って approve にしないでください。 相手に合わせるために、実際にある欠落を見逃して approve にしてはいけません。
• 捏造は阻止対象です。 証拠が捏造された疑いがある場合は、出典が示されるか削除されるまで、必ず revise にしてください。事実として通してはいけません。
• 文書に与えられた上流文書に照らして判断してください。 文書の depends_on セットに基づいて評価します。未作成の上流文書は、決して revise の理由になりません。参照すべき作成済みの上流文書を無視した文書については、正当な指摘事項になります。
• 修正は差分の範囲に限定してください。 修正内容をレビューする場合は、変更点とその波及（条件12）を確認し、変更されていない PRD 全体を再レビューしないでください。
• revise の指摘事項はすべて、実行可能な内容にしてください — 不合格となった条件、該当箇所、具体的な修正方法を示してください。

推奨事項（上書き可能）：

• 指摘事項は重大度順に並べてください — まず阻止対象となる欠落、次に軽微なものを記載します。
• 作成者が基準と照合できるよう、各指摘事項に条件番号または条件名を記載してください。
• approve の補足は少数にとどめ、阻止対象ではないことを明確にしてください。

注意点

• 計画可能性ではなく、完全性を基準に承認してしまうこと。 すべてのセクションが揃っていても、PRD が計画可能とは限りません（目標値のない指標、抽象的な機能、曖昧な NFR など）。テンプレートが埋まっているかではなく、構築計画を立てられるかを判断してください。
• 簡潔なプロジェクトを誤って revise にすること。 小規模プロジェクトの PRD が短いのは適切です。該当しないセクション（NFR マトリクス、依存関係、変更履歴がないなど）が省略されていたり、簡略化されていたりしても、欠落ではありません。短いことを理由に欠落を作り出すこと、またはより充実したテンプレートの任意セクションが空欄であることを問題にするのは、レビュー担当者が最もよく犯す誤りです。
• 条件を作り出すこと。 基準にない GTM／競合／ML のセクションや特定のフレームワークを要求するのは、独自の要件を加えてレビュー基準をずらす行為です。目次の項目ではなく、結果を判断してください。
• 推測に基づくガードレールの要求。 PRD に記載された目標が何も脅かされていないのに、「この指標は理論上、攻略される可能性がある」と指摘すること。条件3のガードレール確認が適用されるのは、明らかに攻略可能な指標が、明記された目標を損なう場合に限られます。
• 自信ありげな数値をうのみにすること。 追跡可能な出典のない精密な統計値は、厳密さではなく、証拠の捏造を示す兆候です。
• 修正時に PRD 全体を再レビューすること。 条件12は差分の範囲に限定されます。変更されていない、すでに承認済みのセクションを revise にしてはいけません。
• これをエンジニアリングの設計レビューと混同すること。 PRD はコードの整合性ではなく、プロダクトの計画可能性に基づいて評価します。機能仕様／ADR／RFC の承認基準を PRD に適用したり、それに判断を委ねたりしないでください。
• 判定トークンの揺れ。 「Approved」、「LGTM」、「要対応」や、段落の途中に埋め込まれた判定は解析できません。単独の行に、文字列 VERDICT: approve|revise をそのまま出力してください。

アンチパターン

• 無条件で承認する。 ざっと目を通して承認すると、捏造された指標や、孤立した機能を見過ごすことになり、後続の計画を損ないます。
• 些細な点にこだわって修正を求める。 表現、書式、あると望ましい程度の要素を不足として取り上げ、作業を止めます。
• 黙って書き換える。 「そのまま直したほうが早かった」――レビュー中に文書を作成すると、作成と評価の分離が崩れます。
• 条件を勝手に作る。 「競合分析／GTM セクションも必要です」「RICE を使うべきです」など、12 条件の基準に含まれていない要件を追加します。
• 簡素な PRD に対して NFR／トレーサビリティを厳しく求めすぎる。 些細な社内ツールに SLO を要求したり、目標が 1 つの PRD にトレーサビリティマトリクスを要求したりすることです。条件の適用範囲は、文書の規模に応じて縮小します。
• 判断をぼかす。 「ほぼ承認ですが……」や、判断を 2 行に分けることです。判断は 1 つだけ、トークンも 1 つだけにします。

出力

1 つの PRD に対するレビュー結果を 1 つ出力します。

• 判断行を 1 行 — VERDICT: approve または VERDICT: revise をそのまま、独立した行に記載します。
• 指摘事項 — revise の場合は、ブロック要因となる不足 1 件につき、対応可能な指摘を 1 件記載します（未達条件＋該当箇所＋具体的な修正内容）。approve の場合は、ブロック要因ではない補足を任意で記載できます。

抽象的なコンシューマーは、作成→レビューのループを調整するものです。approve は次のフェーズ（計画）に PRD を進め、revise は指摘事項を作成者に返して、範囲を限定した修正を依頼します。

関連項目

• authoring-prd — このスキルと対になる作成側のスキルです。このスキルが評価する 12 条件のプランニング可能性基準に沿って PRD を作成します。2 つを組み合わせることで基準を一元化し、作成とレビューの間でずれが生じないようにします。
• design-review スキル — エンジニアリング設計ドキュメント（feature-spec、technical-design、plans、ADR、RFC）を対象とする、対になるゲートです。別のゲートであり、基準も異なります。PRD には使用しません。
• PRD テンプレート／content-template ツール — セクションの構成を管理します。このスキルは基準に照らした品質を評価し、構成への準拠は評価しません。

段階的な開示

• references/plannability-bar.md — 12 のチェックリスト条件について、条件ごとの合格／不足の判断基準と、指摘例を詳しく説明します（構造的なトレーサビリティチェック、基準をすり抜けられる度合い、NFR の負荷を考慮したスコープ設定、差分に限定した修正レビューを含みます）。境界的な条件について、より明確な合格／不足の判断が必要な場合に読み込みます。
• references/sources.md — レビューメソッドおよび捏造の検出ガイダンスの調査根拠です。

本文の予算

• description は 1,024 文字以下（agentskills.io の上限）。Claude は一覧表示で、description と when_to_use の合計が 1,536 文字を超えると切り詰めます。
• 本文は約 500 行／5,000 トークン（目安。品質を優先し、継続的に 700 行／7,000 トークンを超える場合は指摘してください）。毎回のターンでコンテキストに保持されます。
• 参照ファイルごとに、10k トークン超で警告、25k 超でエラー。参照ファイル全体では、25k トークン超で警告、50k 超でエラー。