| name | requirements-review |
| description | 要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。 |
| argument-hint | [--force] [file-path] [input-materials...]（省略時は docs/requirements.md。入力資料パスを追加で渡せる。--force で機械ゲートを通過扱いにする） |
| allowed-tools | Task, Bash, Read |
要件定義書（PRD）をレビューしてください。あなたはレビュー本体を行わず、レンズごとに割って並列に走らせ、返ってきた結果を統合する役です。
1体に全部を見せると、チェックリスト全行・BABOK 全項目・非機能要件カタログ・入力資料を同時に照合することになり、読むものが多すぎて見きれません。判定がぶれると要件定義書はいつまでも凍結できません。
Phase 0: 機械ゲート（レビュー本体の前に必ず実行）
引数から --force を取り除き、残った第1引数（無ければ docs/requirements.md）を対象に実行します。
node scripts/check-requirements.mjs <対象パス>
| スクリプトの結果 | すること |
|---|
| exit 0 | 出力末尾の「判定した観点」を控え、レビュー本体へ進む |
exit 1（--force なし） | 違反一覧をそのまま報告して終了する。レビュー本体は実行しない |
exit 1（--force あり） | 違反一覧を報告したうえでレビュー本体へ進む |
exit 1 で止めるのは、機械が確定させた欠陥を抱えた文書をレビューしても、こちらの指摘がその欠陥に埋もれて読まれないからです。--force は執筆途中の文書にも中身のレビューを掛けられるようにするための逃げ道で、違反の報告自体は省きません。
スクリプトが判定した観点は、レビュー本体で担当から外します。 同じ照合をやり直すと、機械ゲートを置いた意味（一意に決まる事実を AI の推論から外す）が消えます。
[警告] で出た行は、そのまま L2 へ渡します。 警告は「ビジネスルールが1行も無い属性」の候補であって、違反ではありません（exit code も変えません）。ルールの不在は読んでも目に入らないので探索だけ機械にやらせ、違反かどうかは本文を読んで判定します。属性名の切り出しは自然文のパースなので、正当な記述が混じります。
機械ゲートで終了した場合は Issue を起票しません。違反は原文と行番号つきで出るので、その場で直せます。
Phase 1: 入力を特定し、レンズを並列に起動する
引数が空の場合は docs/requirements.md を対象とします。第1引数にファイルパスがある場合はそれを対象とし、第2引数以降があれば入力資料（RFC・ヒアリング議事録等）のパスとして扱います。
入力資料の特定（起動前に必ず実施）：ポリシーのチェックリストには入力資料との突合が不可欠な行（出所ラベル・網羅性〔要求の全数仕分け〕）があります。次の順で入力資料を特定してください。
- 引数で入力資料パスが渡されていればそれを使う
- 渡されていなければ、要件定義書の「背景・入力元」セクションから参照を辿る（辿れる参照が無い場合、それ自体を「背景・入力元の不備」として NG 指摘する）
- どちらでも特定できない場合、入力資料に依存するチェック行を推測で判定せず「判定不能（入力資料未提供）」とレビュー結果に明記し、合否は保留側（凍結不可）に倒す
続いて requirements-reviewer-agent を、レンズごとに1回ずつ、1メッセージ内でまとめて Task 起動します。逐次に投げると、読む量を分けた意味（速さ）が消えます。各起動には次を渡してください。
| 渡すもの | 内容 |
|---|
| レンズ名 | レンズ表のうち1つ |
| 対象パス | レビュー対象の要件定義書 |
| 入力資料のパス | 特定できたもの（L1 が使う。無ければ渡さない） |
| 機械ゲートの出力 | 「判定した観点」の一覧と、[警告] の行（警告は L2 へ渡す） |
レンズの一覧と担当は requirements-reviewer-agent の定義が正典です。 ここに書き写しません——2箇所に持つと、割り方を変えたときに片方が古いまま残ります。
Phase 2: 統合とカバレッジ検証
指摘を統合する
各レンズのレポートを1つにまとめます。
- 同じ箇所への重複指摘は1件にまとめる。 引用が重なっていれば同じ指摘とみなし、理由・修正案が食い違う場合は両方を併記する
- 引用の無い指摘は、統合の時点で落とす
- severity（Critical / 推奨 / 提案）はレンズの判定を尊重し、統合側で下げない
カバレッジを検証する
docs/policy/requirements-doc-policy.md の「レビューチェックリスト」表と「業務要件の品質検証（BABOK チェックリスト）」を Read し、どのレンズも判定していない観点を洗い出します。
判定済みとみなすのは次の2つだけです。
- 各レンズの「判定した観点」に名前が挙がっている観点
- 機械ゲートの「判定した観点」に載っている観点
どちらにも無い観点は「未判定」として、観点名をそのまま報告に載せます。これはレビュー対象の欠陥ではなく、レンズの割り方の穴です。 黙って埋めず（1体で後から見に行くと、分けた意味が消えます）、穴として見えるようにします。
Phase 3: ゲート判定と起票
ゲート判定：Critical（原則違反・必須項目の欠落・トレーサビリティ断絶・非機能の黙った欠落）が1件でもあれば 🚫 要修正、無ければ ✅ 凍結可。判定の根拠を1〜2文で書きます。未判定の観点が残っている場合も、その事実を判定の根拠に併記します。
レビュー結果を出力したら、続けて gh issue create で GitHub Issue を起票してください。ユーザーへの確認は行いません（CLAUDE.md の boy-scout ルール）。
起票の対象は、原文の引用が付いた指摘だけです。 引用の無い指摘は裏が取れていないので、Issue にしません。引用付きの指摘が1件も無ければ起票しません。
| 起票対象 | 粒度 | タイトル | なぜ |
|---|
| [必須] Critical | 1件ごとに1 Issue | [Critical] 要件定義書: <問題の概要> | 凍結を止める欠陥は1件ずつ着手・クローズされる。束ねると一部だけ直った状態が残る |
| [推奨] ＋ [提案] | 全件まとめて1 Issue | [推奨・提案] 要件定義書レビュー指摘まとめ | 1件ずつ判断するほど重くない。件数分に割ると Critical の Issue が埋もれる |
タイトルの先頭ラベルは省略しないでください——Issue 一覧を眺めただけで、凍結を止める指摘かどうかが分かる必要があります。
本文の書き方・ラベル・起票前セルフチェックは .claude/skills/quick-issue/SKILL.md が正典です。Read して従ってください。ラベルは quick-issue の指定に加えて requirement（説明：要件定義書のレビュー指摘に起因するIssue）を必ず付けます——要件定義の指摘だけを後から一括で追うためです。
Issue 本文の「現状」には、レビュー結果の引用・理由・修正案を書き写してください（レビュー結果を読み返さずに着手できるように）。
未判定の観点は Issue にしません。対象文書の欠陥ではないので、requirements-reviewer-agent のレンズの割り方を直す話になります。
引数: $ARGUMENTS
