REQ Decision Gate

新しい機能・変更を「既存REQに追加」するか「新規REQ」にするかを判断するスキル。

入力情報

以下の情報を収集してください：

•new_change_summary: 今回追加・検討したい内容（1〜3文）
•active_reqs: 現在 active な REQ の一覧（REQ-ID / 目的 / Phase）
•product_principles: プロダクトの設計思想（省略可）

Decision Flow

以下の質問に順番に Yes / No で答えること。

Q1. この変更は、既存REQの「目的」を直接強化するか？

•既存REQの Why がそのまま使えるか？
•「完成度を上げる」「自然に続く」内容か？

→ No → ❌ 新規REQ → Yes → 次へ

Q2. この変更がなくても、既存REQは「Done」と言えるか？

•今なくても「REQ完了」と宣言できるか？
•"あると嬉しい" ではないか？

→ Yes → ❌ 新規REQ（ただし将来Phaseとして既存REQ内に保持も可） → No → 次へ

Q3. この変更は、既存REQの Phase を壊さないか？

•今のPhase設計（A/B/Cなど）に自然に収まるか？
•フェーズを飛ばしたり、前提を増やしたりしないか？

→ No → ❌ 新規REQ → Yes → 次へ

Q4. 実装・レビュー・ロールバックを同一文脈で扱えるか？

•PRを分ければ安全に扱えるか？
•「一緒に考えないと理解できない」変更か？

→ No → ❌ 新規REQ → Yes → 次へ

Q5. その変更が「別の評価軸」を持ち始めていないか？

•成功/失敗の判断基準が変わらないか？
•KPI・UX評価がズレないか？

→ Yes（別軸） → ❌ 新規REQ → No（同軸） → ✅ 既存REQに追加

Decision Rules

✅ 既存REQに追加してよい条件

すべて満たす場合：

•Q1 = Yes
•Q2 = No
•Q3 = Yes
•Q4 = Yes
•Q5 = No

👉 REQの中で Phase / サブタスク として切る

❌ 新規REQにすべき条件（1つでも該当）

•目的がズレる
•完了条件が変わる
•評価軸が増える
•実装順を入れ替えないと成立しない
•「将来やりたい」の色が強い

👉 REQ-ID を新しく切る

出力フォーマット

markdown

### REQ Decision Result

- **new_change_summary**: [変更内容の要約]
- **decision**: [Append to existing REQ | Create new REQ]
- **target_req_id**: [追加先REQ-ID（appendの場合）]
- **reason**:
  - Q1: [Yes/No] - [理由]
  - Q2: [Yes/No] - [理由]
  - Q3: [Yes/No] - [理由]
  - Q4: [Yes/No] - [理由]
  - Q5: [Yes/No] - [理由]

### If Append
- **proposed_phase**: [追加するフェーズ名]
- **proposed_subtasks**: [サブタスク一覧]

### If New
- **proposed_req_title**: [新規REQタイトル]
- **initial_scope**: [スコープ]
- **out_of_scope**: [スコープ外]

適用例

例1: commit diff検知をREQ-0000002に追加

code

Q1: Yes（Evidence auto-suggest を強化）
Q2: Yes（なくてもPhase1-3はDone）
→ 新規REQではないが、既存REQに"今は入れない"
→ Phase4 として REQ-0000002 内に保持

例2: RECALL機能

code

Q1: No（目的が違う：過去の類似作業を想起させる）
Q5: Yes（評価軸が変わる：想起率が新しい指標）
→ 新規REQ (REQ-0000003)

なぜこのスキルが効くか

Claude Code は本質的に「要求を1つのゴールにまとめたがる」性質があります。

このスキルは：

•ゴール（REQ）を増やすことを許可し
•でも乱立は防ぎ
•「いつ切るか」を論理で固定する

= PMの判断をAIに移植している状態です。

運用ルール

•新しいアイデアが出たら必ずこのスキルを通す
•判断ログを markdown で残す → 後から「なぜ分けたか」が分かる
•迷ったら新規REQにする（後から統合は容易、分割は困難）