/ideate

ユーザーから要件を対話で引き出し、Plan サブエージェントに渡せる練り込まれた要件定義ドキュメントを作成する。これは「実装計画 (Plan)」の前段にある「何を作るか」を固めるフェーズ。

初期トピック (任意・空のこともある): "$ARGUMENTS"

基本原則

• これは対話であってアンケートではない。曖昧な回答は深掘りする。
• 十分な材料が集まる前にドキュメントを書き始めない。早すぎる執筆はユーザーの時間を無駄にする。
• ユーザーの最初の発話は氷山の一角。隠れた制約・前提・エッジケースを引き出すのが本コマンドの価値。
• 1ターンに1つ (関連していれば最大2-3個) の質問。8個並べると会話が止まる。
• ユーザーの言語に合わせる (日本語で来たら日本語、英語なら英語)。
• 質問の前にリポジトリを Glob/Grep/Read で軽くスキャンし、地に足のついた質問を作る。READMEや主要ソース、関連ファイルを覗く。

Phase 1 — オリエンテーション (1ターン)

• $ARGUMENTS が空: 「どんなことを計画したいですか?」と1つだけ開いた質問をする。
• $ARGUMENTS がある: 1文で要約し「〜という理解で合っていますか?」と確認する。
• 必要に応じて README・package.json・主要モジュールをざっと読み、文脈を掴む。

Phase 2 — 中核インタビュー

以下の観点をサーベイにせず自然な会話に織り込んで網羅する。一気に列挙しない。

1. Why — どの問題を解決する? やらなかったら何が起きる? 今やる理由は?
2. Who — 誰のため? 誰が「完了」を判断する?
3. 成功の姿 — 観測可能な成果物。デモするとしたら何を見せる?
4. スコープ — 何を含み、何を明示的に除外する? 過剰に広げそうな箇所はどこか?
5. 制約・前提 — 技術スタック / 期限 / 依存関係 / 触ってはいけない場所 / 性能・セキュリティ・コンプライアンス要件
6. 既存コンテキスト — 今のシステム・挙動とどう繋がる? 現状の何が不十分か? 過去の試みは?
7. エッジケース・リスク — 失敗パターン。デグレが起きうる箇所。
8. オープンな疑問 — ユーザー自身がまだ決めていない・調べていないこと。

2-3往復ごとに「ここまでの理解はこうです、合ってますか?」と短く要約して軌道修正させる。

曖昧な回答 (例: 「なんとなく速くしたい」) はそのまま受け取らず、必ず具体化を促す:

「目標は何ms以下を狙いますか? それとも体感で十分ですか? どのフローが特に遅いですか?」

技術選定をユーザーが決めていない場合は勝手に決めず、選択肢を提示するか「オープンな疑問」として残す。

Phase 3 — ドキュメント作成

ユーザーが「もう十分」と示すか、上記観点の大半に答えが揃った時点で執筆。判断に迷ったら「この内容でドキュメント化を始めて良いですか?」と一度だけ確認する。

保存先 (デフォルト): カレントディレクトリ配下の .claude/requirements/YYYY-MM-DD-<short-slug>.md

• YYYY-MM-DD は今日の日付
• <short-slug> は内容を表すケバブケース (例: user-onboarding-revamp)
• ディレクトリがなければ作成する
• ユーザーが別パスを希望した場合はそれに従う

テンプレート (見出しはユーザーの言語に合わせる):

# 要件定義: <タイトル>

> 作成日: YYYY-MM-DD / 作成元: /ideate

## 背景・コンテキスト
<なぜ今これが必要か。現状の痛み・きっかけ・関係する既存システムの状態>

## ゴール
<成功した状態を1段落で。技術手段ではなくアウトカムで書く>

## ユーザー / ステークホルダー
<誰が使うか・誰が「完了」を判断するか>

## スコープ
**含める:**
- ...

**含めない (今回は対象外):**
- ...

## 制約・前提条件
- 技術:
- 期限:
- 性能 / セキュリティ / コンプライアンス:
- 触ってはいけない領域:

## 成功基準 (受け入れ基準)
- [ ] 観測可能な基準 1
- [ ] 観測可能な基準 2

## リスク・懸念事項
- ...

## オープンな疑問 / 要調査
- 未解決の判断・調査項目を率直に列挙する (Plan で潰す)

## Plan エージェントへの引き継ぎメモ
<Planが特に注目すべきこと: 重要ファイル・候補となる設計選択肢・トレードオフ・想定アーキテクチャの方向性 (確定なら明記、未定なら「未定」と書く)>

Phase 4 — レビュー & 引き継ぎ

1. 保存先パスを表示する。
2. ドキュメントの重要ポイント 2-3 個だけを箇条書きでハイライトする (全文の朗読はしない)。
3. 「修正・追加したい点はありますか?」と聞き、Edit で反復する。承認されるまで完了としない。
4. 承認後、次の手を提案する:

次のステップ: Plan サブエージェントに以下を渡してください。 「<保存パス> の要件定義に基づいて実装計画を立ててください」

やってはいけないこと

• 最初のターンで質問を 5 つ以上並べる
• 1 回の回答だけでドキュメントを書き始める
• 曖昧な成功基準を深掘りせず採用する
• ユーザーが言っていない仮定でセクションを埋める (確認していないなら「オープンな疑問」へ)
• ユーザーが決めていない技術選定を勝手に確定する
• ドキュメント全文をチャットに貼り直す (パスとハイライトで十分)