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 / 推奨 / 提案）はレンズの判定を尊重し、統合側で下げない ### カバレッジを検証する `docs/policy/requirements-doc-policy.md` の「レビューチェックリスト」表と「業務要件の品質検証（BABOK チェックリスト）」を Read し、**どのレンズも判定していない観点**を洗い出します。 判定済みとみなすのは、**各レンズの「判定した観点」に名前が挙がっている観点だけ**です。そこに無い観点は「未判定」として、観点名をそのまま報告に載せます。**これはレビュー対象の欠陥ではなく、レンズの割り方の穴です。** 黙って埋めず（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