sdd-requirement — Phase 1: 意図の捕捉

グリリングフェーズ。機能が何をすべきかについての真実の源となる requirement.md を作成します。.claude/sdd/SPEC.md と .claude/sdd/templates/requirement.md を参照してください。

呼び出し時

1. features/<name>/state.md の前提条件を検証します:

   • ファイルが存在すること(存在しない場合は、ユーザーに /sdd-init を最初に実行するよう指示します)
   • phase: requirement。それ以外の場合は中止して説明します。

2. コンテキストをロードします:

   • state.md を読み込み → input: フィールド(ユーザーの元のプロンプト)を取得します
   • CLAUDE.md を読み込み(ワークスペース + 現在のリポジトリ)
   • インプットが特定のパスに言及している場合は、関連するコードをざっと確認します

3. input + cwd に基づいて、ロードするナレッジスキルを決定します (下記のCompose セクションを参照)。

4. grill-me インタビューを実施します:

   • grill-me スキルを呼び出します(フルプロトコル)。
   • 組み込み必須事項(多層防御、grill-me がロードされていない場合の念のため):
     • 1度に1つの質問。回答を待ちます。
     • 各質問に常に推奨回答を含めます。
     • 質問する前にコードベースを確認します。コードに存在するものを聞かないでください。
   • 意思決定ツリーを進めて、最低限、以下を扱います:
     • 意図とスコープ
     • 受け入れ基準(検証可能)
     • データモデルへの影響
     • エラーハンドリングと障害モード
     • 可観測性の必要性
     • ロールバック / マイグレーション戦略
     • セキュリティと認証情報
     • パフォーマンス制約
     • 後方互換性
     • 明示的なスコープ外
   • ユーザーが「approved」/ 「requirement is ready」と言うまで進まないでください。

5. .claude/sdd/templates/requirement.md に従い、requirement.md を作成します**:

   • FR-### ID を目標に使用
   • SC-### ID を受け入れ基準に使用(それぞれ検証可能/テスト可能である必要があります)
   • 残存している曖昧さについては、[NEEDS CLARIFICATION: <what>] をインラインで記述します
   • オプションセクションは空のままにするのではなく削除します

6. ドラフトを表示して、反復します: レンダリングされたファイルを出力します。承認/編集/変更を待ちます。ユーザーが明示的に承認するまで反復します。

7. state.md を更新します:

   • phase: requirement、phase_status: approved
   • 履歴エントリを追加します

8. 次のステップを提案します: /sdd-research。

コンテキストに基づいてこれらのスキルで構成します

• インタビューパターン → grill-me(インストールされている場合は常に)
• プロダクトフレーミング → product-manager サブエージェント(オプション、プロダクト機能の場合)
• プロダクト/ドメイン知識 → ユーザーがインストールしているプロジェクト固有のナレッジスキル(例: <your-product>-overview スキル)
• 言語ガイダンス(軽微、主に語彙のため): コードベースに適用される言語固有のガイドラインスキル

アンチパターン

• 質問をまとめてはいけません。
• 「要件は明確に見える」という理由でグリリングをスキップしてはいけません。暗黙的な前提を表面化させます。
• ユーザーがグリル出力を承認する前に requirement.md を作成してはいけません。
• /sdd-research に自動で進まないでください。
• ユーザーが要件ドラフトを承認する前に state.md を変更してはいけません。