requirements-review

要件定義書（PRD）をレビューしてください。あなたはレビュー本体を行わず、レンズごとに割って並列に走らせ、返ってきた結果を統合する役です。

1体に全部を見せると、チェックリスト全行・BABOK 全項目・非機能要件カタログ・入力資料を同時に照合することになり、読むものが多すぎて見きれません。判定がぶれると要件定義書はいつまでも凍結できません。

Phase 1: 入力を特定し、レンズを並列に起動する

引数が空の場合は docs/requirements.md を対象とします。第1引数にファイルパスがある場合はそれを対象とし、第2引数以降があれば入力資料（RFC・ヒアリング議事録等）のパスとして扱います。

入力資料の特定（起動前に必ず実施）：ポリシーのチェックリストには入力資料との突合が不可欠な行（出所ラベル・網羅性〔要求の全数仕分け〕）があります。次の順で入力資料を特定してください。

1. 引数で入力資料パスが渡されていればそれを使う
2. 渡されていなければ、要件定義書の「背景・入力元」セクションから参照を辿る（辿れる参照が無い場合、それ自体を「背景・入力元の不備」として NG 指摘する）
3. どちらでも特定できない場合、入力資料に依存するチェック行を推測で判定せず「判定不能（入力資料未提供）」とレビュー結果に明記し、合否は保留側（凍結不可）に倒す

続いて requirements-reviewer-agent を、レンズごとに1回ずつ、1メッセージ内でまとめて Task 起動します。逐次に投げると、読む量を分けた意味（速さ）が消えます。各起動には次を渡してください。

• レンズ名：レンズ一覧のうち1つ
• 対象パス：レビュー対象の要件定義書
• 入力資料のパス：特定できたもの（L1 が使う。無ければ渡さない）

レンズの一覧と担当は requirements-reviewer-agent の定義が正典です。 ここに書き写しません——2箇所に持つと、割り方を変えたときに片方が古いまま残ります。

Phase 2: 統合とカバレッジ検証

指摘を統合する

各レンズのレポートを1つにまとめます。

• 同じ箇所への重複指摘は1件にまとめる。 引用が重なっていれば同じ指摘とみなす
• 引用の無い指摘は、統合の時点で落とす
• severity（Critical / High / Medium）はレンズの判定を尊重し、統合側で下げない
• 修正案が食い違ったら裁定する：同じ箇所に別々のレンズが逆向きの修正案を出したら、ポリシーの条文（該当が無ければ docs/policy/refined-engineer-judgment-principles.md）を引用して一方を採り、捨てた修正案と根拠を添える。迷ったら AI が決める。ただし、どちらを採っても要件・プロダクトの方針が変わるとき、またはどちらかが取り消せない操作・外部に出る操作になるときだけは裁定せず、Phase 3 でその食い違い1件をラベル issue:needs-human-decision で起票する。本文には、食い違った各指摘の観点名と引用を書き写す。同じワークフローの前回のレビューでこの手順により起票した Issue と同じ指摘なら、起票せず、既存の Issue 番号のまま起票済みとして扱う。同じ指摘かどうかは ai-review-gate-policy の「再レビューで同じ指摘が出たら、既存の Issue 番号で数える」で決める

カバレッジを検証する

docs/policy/requirements-doc-policy.md の「レビューチェックリスト」表と「業務要件の品質検証（BABOK チェックリスト）」を Read し、どのレンズも判定していない観点を洗い出します。

判定済みとみなすのは、各レンズの「判定した観点」に名前が挙がっている観点だけです。そこに無い観点は「未判定」として、観点名をそのまま報告に載せます。これはレビュー対象の欠陥ではなく、レンズの割り方の穴です。 黙って埋めず（1体で後から見に行くと、分けた意味が消えます）、穴として見えるようにします。

Phase 3: ゲート判定と起票

ゲート判定：合否は ai-review-gate-policy の合格条件（残してよい例外以外の Critical が0件）で決めます。対象の全指摘を通じた Critical の合計から、Phase 2 の「修正案が食い違ったら裁定する」で issue:needs-human-decision として起票した（または既存の Issue 番号のまま扱った）食い違いに含まれる Critical 指摘の件数を引き、残りが0件なら ✅ 凍結可、1件以上なら 🚫 要修正、と判定します。根拠を1〜2文で書き、起票・照合した Issue 番号があればそこに書きます。未判定の観点が残っている場合も、その事実を判定の根拠に併記します。

レビュー結果を出力したら、続けて gh issue create で GitHub Issue を起票してください。ユーザーへの確認は行いません（CLAUDE.md の boy-scout ルール）。

起票の対象は、原文の引用が付いた指摘だけです。 引用の無い指摘は裏が取れていないので、Issue にしません。引用付きの指摘が1件も無ければ起票しません。

起票対象	粒度	タイトル	なぜ
Critical	1件ごとに1 Issue	[Critical] 要件定義書: <問題の概要>	凍結を止める欠陥は1件ずつ着手・クローズされる。束ねると一部だけ直った状態が残る
High ＋ Medium	全件まとめて1 Issue	[High・Medium] 要件定義書レビュー指摘まとめ	1件ずつ判断するほど重くない。件数分に割ると Critical の Issue が埋もれる

タイトルの先頭ラベルは省略しないでください——Issue 一覧を眺めただけで、凍結を止める指摘かどうかが分かる必要があります。タイトルの先頭には段番号を付けてください（例：1. [Critical] …）。振り方は Issueの階層ガイド（docs/reference/issue-hierarchy.md）の「段番号（着手順）」に従います。

本文の書き方・ラベル・起票前セルフチェックは .claude/skills/quick-issue/SKILL.md が正典です。Read して従ってください。ラベルは quick-issue の指定に加えて requirement（説明：要件定義書のレビュー指摘に起因するIssue）を必ず付けます——要件定義の指摘だけを後から一括で追うためです。

Issue 本文の「現状」には、レビュー結果の引用・理由・修正案を書き写してください（レビュー結果を読み返さずに着手できるように）。

未判定の観点は Issue にしません。対象文書の欠陥ではないので、requirements-reviewer-agent のレンズの割り方を直す話になります。

引数: $ARGUMENTS