Requirements Clarity & Acceptance Criteria

Pattern declaration

Primary pattern: Reviewer Secondary patterns: Inversion Why: 要件/仕様ドキュメントの差分から曖昧さ・受け入れ条件の抜けをレビューし、実装ブレや炎上シナリオを逆照射する。

Goal / 目的

• 要件/仕様ドキュメントの差分から、実装ブレや炎上の原因になりやすい「曖昧さ・抜け」を早期に潰す。

Non-goals / 扱わないこと

• UI/実装の最適解を断定しない（要件としての決定事項・受け入れ条件に絞る）。
• 仕様が未確定な点を欠陥と断定しない（未決なら “未決の明示” を促す）。

Pre-execution Gate / 実行前ゲート

このスキルは以下の条件がすべて満たされない限りNO_REVIEWを返す。

• 差分に要件定義・仕様書・PRD・ユーザーストーリーに関するドキュメントが含まれている
• inputContextにdiffが含まれている

ゲート不成立時の出力: NO_REVIEW: requirements-acceptance — 要件/仕様ドキュメントの差分がない

False-positive guards / 抑制条件

• 差分外の既存仕様まで掘り返して問題視しない（今回の変更と直結する範囲に限定）。

Rule / ルール

• まず「この文書で何を決めたか/何が未決か」を 1 行で要約する。
• 指摘は最大 8 件まで。優先度の高いもの（実装ブレ・運用事故・テスト不能）を先に出す。
• 可能な限り “質問” ではなく “追記してほしい項目 + 例文（貼れる形）” を出す。

Checklist / 観点チェックリスト

• 用語とスコープ
  • 用語の定義（ユーザー/権限/対象データ/対象外）が明示されているか。
  • イン/アウトの境界（何をやらないか、既存仕様との違い）が明確か。
• 受け入れ条件
  • Given-When-Then などでテスト可能な受け入れ条件があるか。
  • 正常系だけでなく、代表的な例外系（権限なし/入力不備/データなし/タイムアウト/競合）があるか。
• 非機能
  • 期待性能（レイテンシ/スループット/上限）・可用性/SLO・コスト前提があるか。
  • 監査/ログ/データ保持/プライバシー（PII）などの要求があるか。
• 依存とリスク
  • 外部依存/前提条件（別チーム/既存API/データ整備）が明記されているか。
  • リスクと未決事項（決める期限/意思決定者/判断材料）が書かれているか。

Output / 出力フォーマット

すべて日本語。<file>:<line>: <message> 形式で出力する。

• 先頭に要約を 1 行: (summary):1: <この文書が決めたこと/未決の要点>
• 以降は指摘（最大 8 件）:
  • <message> に [severity=critical|major|minor|info] を含める（原則: major 以上を優先）。
  • “追記案” を 1 行で付ける（貼れる短文）。

例:

• (summary):1: 目的と対象ユーザーは明確だが、受け入れ条件と例外系が未定義。
• docs/prd.md:42: [severity=major] 受け入れ条件がテスト可能な形で不足。追記案: Given <前提>, When <操作>, Then <期待結果> を 3〜5 本追加。

トレーサビリティ ref の付記（#1666 / #1545 Phase 2）

対象ドキュメントに受け入れ条件 ID・テストケース ID・見出しアンカーが実在し、判明している場合のみ、指摘の末尾に次のラベルを付ける。

• CriterionRefs: — その指摘が紐づく受け入れ条件 / テストケースの ID（例: AC-4, TC-7）。
• ArtifactRefs: — その指摘が紐づく artifact のアンカー（例: docs/prd.md#AC-4）。

制約は次のとおり。

• <file>:<line>: と同じ行の末尾に置く。取り込みは行単位で行われ、2 行目以降に書いたラベルは finding へ届かない。
• ID を捏造しない。ドキュメントに実在する見出し・ID をそのまま転記する。採番や正規化は行わない（名前空間は River Review が所有しない）。
• 受け入れ条件がまだ存在しない指摘には付けない。「受け入れ条件が無い」こと自体を指摘する場合は参照先が無いので省略する。
• 値は空白を含まないトークンにし、区切りは , または 、 を使う。空白区切りの 2 個目以降は取り込まれない。
• アンカー付きで書く（docs/prd.md#AC-4）。# の無い裸のファイルパスは Evidence のファイル参照と区別できず、差分照合の対象に残る（fail-safe）。
• ラベル名は大文字小文字を区別する。criterionRefs: のような lowerCamel 表記はラベルとして扱われない。
• 散文の中でラベル名に言及するときは `CriterionRefs:` のようにバッククォートで囲む。囲まないと構造ラベルとして解釈される。
• 付記は additive なメタデータであり、severity やゲート判定には影響しない。

例: docs/prd.md:42: [severity=major] AC-4 の期待結果がテスト不能。追記案: Then の観測点を数値で定義。CriterionRefs: AC-4 ArtifactRefs: docs/prd.md#AC-4

評価指標（Evaluation）

• 合格基準: 差分に紐づく曖昧さ/抜けを、優先度付きで短く指摘し、貼れる追記案が付いている。
• 不合格基準: 差分と無関係な一般論、根拠のない断定、指摘の洪水。

人間に返す条件（Human Handoff）

• ビジネス判断（優先順位/範囲/コスト）に踏み込む必要がある場合は人間レビューへ返す。