/think - 批判的要件調査モード

「何を作るか」「どこに影響するか」を明確にするための対話モード。ユーザーが見落としている制約（外部サービスの制限、既存機能との衝突、設計思想との不整合など）を批判的に調査し、実装前に障壁を潰す。

プロセス

$ARGUMENTS を受け取る
    ↓
Issue番号？ ──yes──→ gh issue view で内容取得
    │                      ↓
    │              Issue内容を「やりたいこと」として使用
    ↓ no                   ↓
テキストをそのまま使用 ←──┘
    ↓
関連コード・仕様を調査（Spec確認を含む）
    ↓
┌→ 質問（1つずつ）
│   ↓
│  回答を受けて追加調査
│   ↓
│  アプローチ提案（選択肢がある場合）
│   ↓
│  中間まとめ（適宜）
│   ↓
│  未決事項あり？ ──yes──┐
│                        │
└────────────────────────┘
    ↓ no
ユーザーが「OK」
    ↓
Spec整備フェーズ
    ↓
モード終了

0. Issue番号の解決（該当時のみ）

$ARGUMENTS が #123 や 123 のようなIssue番号パターンの場合：

gh issue view {番号} --json title,body,labels

を実行し、Issueのタイトルと本文を取得する。以降の調査では Issueのタイトルを「やりたいこと」、本文を初期の要件情報 として扱う。

初回メッセージでIssueの内容を要約して提示する：

📋 Issue #{番号}: {タイトル}

{本文の要約}

この内容をもとに調査を進めます。

1. 初回調査

$ARGUMENTS（またはIssueから取得した内容）をやりたいことの初期情報として受け取り、すぐに関連コード、ドキュメントを調査する。

Spec確認（必須）:

docs/specs/ が存在する場合、関連するspecファイルの有無を確認する。

• specが存在する場合: specを読み、現行仕様を把握した上で調査を進める。初回メッセージで仕様の要点を提示する
• specが存在しない場合: 初回メッセージでその旨を記載する（「関連specはまだ作成されていません」）
• docs/specs/ 自体が存在しない場合: スキップする

制約チェック（必須）:

調査と並行して、やりたいことに対する制約・障壁を批判的に洗い出す。以下の観点で確認する：

観点	確認すること
外部サービス制約	利用するAPI・サービスのレート制限、料金体系、機能制限、廃止予定
既存機能との衝突	既存の処理フロー・データ構造・UIと矛盾しないか
設計思想との整合	プロジェクトのアーキテクチャ方針（CLAUDE.md, rules/）と合っているか
データ整合性	スキーマ変更が既存データや他機能に波及しないか
権限・セキュリティ	認証・認可モデルと整合するか
スケーラビリティ	データ量増加時に問題が起きないか（DynamoDBのパーティション設計等）

全観点を毎回網羅する必要はない。やりたいことに対して該当する観点のみを確認する。

制約の判断根拠を自分の知識だけに頼らない。外部サービス・ライブラリ・AWSの制約が関わる場合は、WebSearchで公式ドキュメントを積極的に確認し、事実に基づいて判断する。少しでも不確かなら検索して裏を取る。確認結果を共有する際は出典を明記する。

調査結果をもとに、最初の質問をユーザーに投げる。

2. 対話サイクル

以下を繰り返す:

質問:

• 1メッセージにつき1つの質問。 複数の論点がある場合は分割する
• 選択肢がある場合はAskUserQuestionで提示する（選びやすくする）
• 目的・制約・成功基準を理解することに集中する

調査共有:

• 既存コードの関連箇所（ファイルパスと概要）
• 再利用できそうなコンポーネントやサービス
• スキーマの現状と変更が必要そうな箇所

批判的レビュー（対話中に随時）:

ユーザーの回答や方針が固まってきた段階で、以下を自問し、懸念があれば率直に伝える：

• 「この方針で見落としている制約はないか？」
• 「ユーザーが暗黙に前提としていることは本当に正しいか？」
• 「もっとシンプルな方法で同じ目的を達成できないか？」

懸念が浮かんだら、まず WebSearchで公式ドキュメントを確認して裏を取ってから ユーザーに伝える。自分の記憶だけで「〜のはず」と言わない。出典を添える。

批判的レビューは「やらない理由探し」ではない。実現するために障壁を先に潰すのが目的。懸念を伝えた上で、対処法も一緒に提示する。

アプローチ提案（選択肢がある場合）:

• 2-3のアプローチをトレードオフ付きで提示する
• 推奨案を先に出し、理由を説明する

3. 中間まとめ

3-4ラリーに1回、または情報が揃ったタイミングで整理する:

📋 ここまでの整理:

■ やりたいこと
- {要件の要約}

■ Spec状況
- {specファイルパス}: {存在する→要点 / 存在しない}
- {今回の変更との整合}: {一致 / 仕様変更が必要 / 新規作成が必要}

■ 影響範囲
- {変更が必要なファイル・モジュール}

■ 制約・リスク
- {見つかった制約とその対処方針。なければ「特になし」}

■ 確認済みの仕様
- {決まったこと}

■ 未決事項
- {まだ決まっていないこと}

4. Spec整備フェーズ

ユーザーが「OK」や完了の意思を示したら、specの整備に移行する:

specが存在しない場合（新規作成）

docs/specs/_template.md をベースに新規作成する。

• 対話で明らかになった仕様をSPEC-IDテーブルに記載する
• 安定度は全項目 draft とする
• 画面仕様・データモデル・エラーハンドリング・テスト観点も対話で判明した範囲で記載する

specが存在する場合（更新）

今回の変更で影響を受ける箇所を更新する。

• 変更・追加した項目の安定度を draft に戻す
• 既存の stable 項目は変更しない

設計判断の記録（該当時のみ）

対話中に大きな設計判断（2つ以上の選択肢からの選択）があった場合、 docs/decisions/_template.md をベースにADRを作成する。

終了

spec整備が完了したら:

✅ 調査完了。

📄 Spec: docs/specs/{機能名}.md（新規作成 or 更新済み）
📄 Decision: docs/decisions/{タイトル}.md（該当時のみ）

次のアクションを指示してください。

原則

• 推測で仕様を決めない。 不明点は必ずユーザーに確認する
• 1メッセージ1質問。 質問を詰め込まない
• YAGNI。 不要な機能を提案しない
• 批判的に、しかし建設的に。 「できない理由」ではなく「実現するために先に潰すべき障壁」を見つける。懸念には必ず対処案を添える