brainstorming

ブレインストーミング

実装方法を計画する前に、何を構築するのかを明確にします。

範囲と対話

実装ではなく、探索と設計を行います。対話形式で引き継ぐ前に承認を得ます。呼び出し元が非対話型の実行とその判断範囲を明示的に委任した場合に限り、ヘッドレスモードを有効にします。disable-model-invocation は選択に関するメタデータであり、承認ではありません。ヘッドレス実行で確認が必要な場合は、保守的な前提を明示して置き換えます。安全で承認済みの既定値を設定できない重要な判断は、未解決のままにしません。推測した選択をユーザーが承認したものとして扱ったり、このスキルから実装、コミット、公開の権限を推定したりしてはいけません。

自由回答形式の質問は通常のチャット文として尋ね、回答を待つためにターンを終了します。選択肢を提示すると、ユーザーの視点がエージェントの枠組みに固定されてしまいます。ブロッキング形式のメニューツールは、メニュー形式の選択肢に限って使用してください。選択肢は、実際に選べる二つから四つまでにします（Blindspot Pass、アプローチの選択、計画へのスキップの提案、承認、または行き詰まったユーザーや「お任せします」というユーザーへの対応）。Claude Code では AskUserQuestion（必要に応じて ToolSearch select:AskUserQuestion で読み込みます）、サポートされている場合は Codex では request_user_input を使い、それ以外の場合は保留中の判断事項を最初の行に明記したうえで、チャット内に番号付きの選択肢を提示します。無人ワーカーで不足している判断事項があれば、親に返します。

プロセス

1. 評価して根拠を確認する。 既存のプロジェクトでは、質問する前に関連するコード、ドキュメント、制約、最近のコミットを確認します。依頼内容と確認できた動作の矛盾を明らかにします。抽象的なトピックでは、リポジトリの調査を省略します。目標が曖昧な場合、解釈が複数ある場合、未解決のトレードオフがある場合、ニーズが不確かな場合、解決策を前提とした依頼の場合、または独立したサブシステムが複数ある場合は、ブレインストーミングを行います。要件が明確なら、対話を無理に求めず、計画または実装を提案します。
2. 規模を適切に調整し、分解する。 3回のやり取りでまとまるブレインストーミングなら、要約だけで十分な場合があります。継続的なアーキテクチャ作業には、長期的に参照できる設計が必要です。独立したサブシステムが複数ある場合は、境界と依存関係を特定し、構築順序を決めてから、各サブプロジェクトで設計 → 計画 → 実装のサイクルを個別に進めます。最初のサブプロジェクトから着手します。
3. 理解して比較する。 対話やアプローチの選定が必要な場合は、interview-and-approaches.mdを読みます。ユーザーの語彙に合わせます。通常は、複数の観点にまたがる質問を1つ、または1つの観点について2～3つの質問をします。最初の説明がかなり長い場合（200語超）は、リファレンスに記載された、範囲を限定した質問セットを使用します。目的、ユーザー、制約、成功の定義、エッジケース、パターン、対象外事項を検討します。前提、根拠、なじみのない領域、または複数の回答をまとめて検討する必要がある場合は、deep-interview.mdを適用します。インタビューを終える前に、同リファレンスの統合チェックを行います。明確になった場合、または先へ進むよう指示された場合は、質問を終了します。3～5個の箇条書きで要約し、対話モードでは確認を求めます。
4. アプローチを選ぶ。 具体的な選択肢を2～3案、説明、長所、短所、適した条件とともに比較します。推奨案を最初に示し、既存のパターンに触れ、トレードオフを明らかにします。2回のやり取りを経ても合意できない場合は、希望する方向性を尋ねます。設計の選択肢が広い場合は、アプローチのリファレンスから2～3個の観点を用います。選択したアプローチで実施しないことを明示し、主要な前提ごとに検証方法を示します。
5. 解釈したスコープを確認する。 実質的な対話の後に執筆する前に、scope-synthesis.mdを読みます。明示された要件、推測した前提、対象外事項を内部で分け、リファレンスにある簡潔なスコープの統合結果だけを提示します。質問による中断を伴わない軽量な作業では、告知モードを使用します。標準／詳細な作業、または進行を妨げる対話では、対話形式で確認を求めます。修正があった場合は再提示し、確認を待ちます。ヘッドレスモードでは、プロンプトを使わず、情報源と未解決の前提を保持します。対話を省略した明確な要件では、確認のための統合ステップは不要です。
6. 記録し、自己レビューする。 長期的に参照する成果物を作成する場合は、design-and-handoff.mdを読みます。日付とトピックのフロントマター、作成するもの、アプローチを選ぶ理由、主要な決定とその根拠、未解決の質問、次のステップを含めて、docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.mdに保存します。インタビューの履歴はdetailsブロックにまとめます。各コンポーネントの目的、使い方、依存関係、テスト可能な境界を説明します。コミットは依頼者の権限の範囲内でのみ行います。
7. 引き継ぐ。 確定した決定とその根拠を保持し、繰り返し覆そうとしないでください。冷淡な指示に対しては、1回だけアプローチの再検討を促します。いずれの対応でも、具体的な欠陥や実現不可能性の根拠を無視してはなりません。用語の一貫性、具体的な基準、スコープの追跡可能性、曖昧さのない決定、明示的な対象外事項、前提の検証、生成した値ごとの情報源の明記を徹底します。問題があれば、アプローチの選定または草案作成に戻ります。対話モードでは設計を提示して承認を求めます。ヘッドレスモードでは、依頼者に委任された決定と未解決の前提を返します。

完了

対象範囲の要約または保存済みの設計パス、決定事項、解決済みまたは理由を明示して保留した未解決事項を返します。引き継ぎの前に対話的な承認を行います。ヘッドレスでの引き継ぎは、引き続き呼び出し元の権限の範囲内です。計画（ia-planning、または Claude Code の /ia-plan）は設計後に行い、確定した要件を再利用します。認証、決済、外部 API、またはマルチテナントデータについては、計画の前に利用可能なセキュリティ脅威モデリングのレビューを提案してください。