/think - 批判的要件調査モード
「何を作るか」「どこに影響するか」を明確にするための対話モード。ユーザーが見落としている制約（外部サービスの制限、既存機能との衝突、設計思想との不整合など）を批判的に調査し、実装前に障壁を潰す。
プロセス
$ARGUMENTS を受け取る ↓ Issue番号？ ──yes──→ gh issue view で内容取得 │ ↓ │ Issue内容を「やりたいこと」として使用 ↓ no ↓ テキストをそのまま使用 ←──┘ ↓ 関連コード・仕様を調査（Spec確認を含む） ↓ ┌→ 質問（1つずつ） │ ↓ │ 回答を受けて追加調査 │ ↓ │ アプローチ提案（選択肢がある場合） │ ↓ │ 中間まとめ（適宜） │ ↓ │ 未決事項あり？ ──yes──┐ │ │ └────────────────────────┘ ↓ no ユーザーが「OK」 ↓ Spec整備フェーズ ↓ モード終了
- Issue番号の解決（該当時のみ）
$ARGUMENTS が #123 や 123 のようなIssue番号パターンの場合：
gh issue view {番号} --json title,body,labels
を実行し、Issueのタイトルと本文を取得する。以降の調査では Issueのタイトルを「やりたいこと」、本文を初期の要件情報 として扱う。
初回メッセージでIssueの内容を要約して提示する：
📋 Issue #{番号}: {タイトル}
{本文の要約}
この内容をもとに調査を進めます。
- 初回調査
$ARGUMENTS（またはIssueから取得した内容）をやりたいことの初期情報として受け取り、すぐに関連コード、ドキュメントを調査する。
Spec確認（必須）:
docs/specs/ が存在する場合、関連するspecファイルの有無を確認する。
-
specが存在する場合: specを読み、現行仕様を把握した上で調査を進める。初回メッセージで仕様の要点を提示する
-
specが存在しない場合: 初回メッセージでその旨を記載する（「関連specはまだ作成されていません」）
-
docs/specs/ 自体が存在しない場合: スキップする
制約チェック（必須）:
調査と並行して、やりたいことに対する制約・障壁を批判的に洗い出す。以下の観点で確認する：
観点 確認すること
外部サービス制約 利用するAPI・サービスのレート制限、料金体系、機能制限、廃止予定
既存機能との衝突 既存の処理フロー・データ構造・UIと矛盾しないか
設計思想との整合 プロジェクトのアーキテクチャ方針（CLAUDE.md, rules/）と合っているか
データ整合性 スキーマ変更が既存データや他機能に波及しないか
権限・セキュリティ 認証・認可モデルと整合するか
スケーラビリティ データ量増加時に問題が起きないか（DynamoDBのパーティション設計等）
全観点を毎回網羅する必要はない。やりたいことに対して該当する観点のみを確認する。
制約の判断根拠を自分の知識だけに頼らない。外部サービス・ライブラリ・AWSの制約が関わる場合は、WebSearchで公式ドキュメントを積極的に確認し、事実に基づいて判断する。少しでも不確かなら検索して裏を取る。確認結果を共有する際は出典を明記する。
調査結果をもとに、最初の質問をユーザーに投げる。
- 対話サイクル
以下を繰り返す:
質問:
-
1メッセージにつき1つの質問。 複数の論点がある場合は分割する
-
選択肢がある場合はAskUserQuestionで提示する（選びやすくする）
-
目的・制約・成功基準を理解することに集中する
調査共有:
-
既存コードの関連箇所（ファイルパスと概要）
-
再利用できそうなコンポーネントやサービス
-
スキーマの現状と変更が必要そうな箇所
批判的レビュー（対話中に随時）:
ユーザーの回答や方針が固まってきた段階で、以下を自問し、懸念があれば率直に伝える：
-
「この方針で見落としている制約はないか？」
-
「ユーザーが暗黙に前提としていることは本当に正しいか？」
-
「もっとシンプルな方法で同じ目的を達成できないか？」
懸念が浮かんだら、まず WebSearchで公式ドキュメントを確認して裏を取ってから ユーザーに伝える。自分の記憶だけで「〜のはず」と言わない。出典を添える。
批判的レビューは「やらない理由探し」ではない。実現するために障壁を先に潰すのが目的。懸念を伝えた上で、対処法も一緒に提示する。
アプローチ提案（選択肢がある場合）:
-
2-3のアプローチをトレードオフ付きで提示する
-
推奨案を先に出し、理由を説明する
- 中間まとめ
3-4ラリーに1回、または情報が揃ったタイミングで整理する:
📋 ここまでの整理:
■ やりたいこと
- {要件の要約}
■ Spec状況
- {specファイルパス}: {存在する→要点 / 存在しない}
- {今回の変更との整合}: {一致 / 仕様変更が必要 / 新規作成が必要}
■ 影響範囲
- {変更が必要なファイル・モジュール}
■ 制約・リスク
- {見つかった制約とその対処方針。なければ「特になし」}
■ 確認済みの仕様
- {決まったこと}
■ 未決事項
- {まだ決まっていないこと}
- 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。 不要な機能を提案しない
-
批判的に、しかし建設的に。 「できない理由」ではなく「実現するために先に潰すべき障壁」を見つける。懸念には必ず対処案を添える