proposal-readiness-check

name	proposal-readiness-check
description	proposal.md が /spec の入力として十分な情報を含んでいるかを確認する。「ユーザーにとっての承認」ではなく「/spec にとっての準備完了度」を検証する軽量チェック

Proposal Readiness Check

Overview

proposal.md が /spec フェーズの入力として「準備完了」かを確認する。

目的: 不完全な proposal が /spec に入り、エスカレーション多発や低品質な仕様生成を防ぐ。 タイミング: /brainstorm の proposal.md 生成後、ユーザー承認前。 原則: 5項目の Yes/No チェック。不足があれば追加質問で補完。ユーザー判断で進行可能。

Definition of Ready for /spec（5項目）

1. 意図の明確性

「なぜこの変更が必要か」と「何が達成されれば完了か」が明確か。

• Yes: Intent セクションが具体的な問題や目標を述べている
• No: 「〇〇を追加する」のみで、なぜ必要かが不明

No の場合の追加質問:
→「この変更が完了したとき、何がどう変わっていれば成功ですか？」

2. ストーリーの具体性

各ストーリーの「行動」が具体的な操作を示しているか。

• Yes: 「検索する」「登録する」「一覧を見る」等の具体的動詞
• No: 「改善する」「最適化する」「対応する」等の抽象的動詞

No の場合の追加質問:
→「具体的にユーザーはどんな操作をしますか？ 画面で何をクリック/入力しますか？」

3. スコープの境界

Out of Scope が最低1つ定義され、対象領域が具体的か。

• Yes: Out of Scope に除外項目あり、対象領域がシステム領域を指している
• No: Out of Scope が空、または対象領域が「全体」「各所」等の曖昧表現

No の場合の追加質問:
→「あえて今回やらないことは何ですか？ 後回しにすることを1つ挙げるとしたら？」

4. 変更の規模感

ユーザーが変更の大きさを認識しているか。

• Yes: 対象領域から規模感が推測可能（1画面の修正 / 新API追加 / DBスキーマ変更 等）
• No: 影響範囲が読めない、または複数領域にまたがるのに認識されていない

No の場合の追加質問:
→「この変更は〇〇と△△に影響しそうです。この規模感で合っていますか？
   それとも、もっと小さく分割しますか？」

5. 未解決の疑問点

Open Questions セクションが適切に機能しているか。

• Yes: /spec で解決すべき具体的な技術的疑問が列挙されている
• No（空）: 疑問点が本当にないのか、考慮不足なのか判断できない
• No（/brainstorm レベル）: /spec ではなく /brainstorm で解決すべき疑問が残っている

空の場合の追加質問:
→「疑問点が空ですが、例えば〇〇についてはどうしますか？
   本当に不明点はありませんか？」

/brainstorm レベルの疑問が残っている場合:
→ 該当の疑問を対話で解決してから proposal に反映

適用ルール

1. 全5項目 Yes → 「/spec の準備完了です」と伝え、ユーザー承認を求める
2. No が 1-2 個 → 追加質問で補完を試みる。補完後に proposal を更新
3. No が 3 個以上 → 要件の深掘りが不足している可能性を伝え、追加対話を推奨

提示形式

/spec 準備完了チェック:

1. 意図の明確性:    ✓
2. ストーリーの具体性: ✓
3. スコープの境界:   ✓
4. 変更の規模感:    ⚠ 複数領域にまたがる可能性
5. 未解決の疑問点:   ⚠ Open Questions が空

→ 2点確認させてください:
  - この変更は画面とAPIの両方に影響しそうですが、その規模感で合っていますか？
  - 技術的な疑問点は本当にありませんか？

重要な制約

• チェックはあくまで「/spec への準備完了度」であり、要件の正しさの判断ではない
• ユーザーが「このまま進める」と判断すれば、No 項目があっても承認を妨げない
• No 項目は proposal.md の「未解決の疑問点」に転記し、/spec のリサーチで解決を試みる