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](../../../docs/policy/ai-review-gate-policy.md) の合格条件（残してよい例外以外の 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