requirements-review

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・ヒアリング議事録等）のパスとして扱います。

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

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

続いて 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