| 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 に反映
適用ルール
- 全5項目 Yes → 「/spec の準備完了です」と伝え、ユーザー承認を求める
- No が 1-2 個 → 追加質問で補完を試みる。補完後に proposal を更新
- No が 3 個以上 → 要件の深掘りが不足している可能性を伝え、追加対話を推奨
提示形式
/spec 準備完了チェック:
1. 意図の明確性: ✓
2. ストーリーの具体性: ✓
3. スコープの境界: ✓
4. 変更の規模感: ⚠ 複数領域にまたがる可能性
5. 未解決の疑問点: ⚠ Open Questions が空
→ 2点確認させてください:
- この変更は画面とAPIの両方に影響しそうですが、その規模感で合っていますか?
- 技術的な疑問点は本当にありませんか?
重要な制約
- チェックはあくまで「/spec への準備完了度」であり、要件の正しさの判断ではない
- ユーザーが「このまま進める」と判断すれば、No 項目があっても承認を妨げない
- No 項目は proposal.md の「未解決の疑問点」に転記し、/spec のリサーチで解決を試みる