brainstorming

ブレインストーミング

ソクラテス式の質疑応答を通じて、アイデアを対話形式で探る進行役を務めます。目標は、実装の前に理解を深めることです。セッション中にドキュメントを段階的に充実させ、最終的には /research または /create-plan に引き継ぐ、簡潔な事前 PRD としてまとめます。

作業上の合意事項

ブレインストーミングは対話形式で行うことを前提としており、質疑応答そのものが目的です。すべての質問には AskUserQuestion を使用し、一度に1つの質問だけを尋ねてください（ループについてはステップ3を参照）。このスキルは、意図的に desplega:ask-user の一括質問の慣例には従いません。ソクラテス式の探索には、焦点を絞った質問を1つずつ行う必要があります。

ファイルレビューはデフォルトで有効です。統合後、ブレインストーミングのドキュメントに対して実行してください。

使用するタイミング

このスキルは、次の場合に有効になります。

• ユーザーが /brainstorm コマンドを実行した場合
• 別のスキルが **REQUIRED SUB-SKILL:** Use desplega:brainstorming を参照している場合
• ユーザーが調査や計画に進む前に、アイデアを探りたい場合
• ユーザーがまだ正式な調査に進む準備ができていない場合

自律性モード

ブレインストーミングは本質的に対話形式であるため、サポートされるモードは2つだけです。

モード	動作
Verbose（デフォルト）	ソクラテス式の探索を十分に行い、一度に1つずつ質問し、充実した議論を行います
Critical	質問を減らし、影響の大きい領域に焦点を当て、より早く統合に進みます

Autopilot はサポートされていません。ブレインストーミングは人間の入力を前提としているためです。Autopilot が要求された場合は、その理由を説明する注記を添えて Critical に切り替えてください。

自律性モードは、呼び出し元のコマンドから渡されます。指定されていない場合は、デフォルトの Verbose を使用します。

プロセスの手順

ステップ1：ドキュメントを初期化する

cc-plugin/base/skills/brainstorming/template.md のテンプレートを使って、thoughts/<username|shared>/brainstorms/YYYY-MM-DD-<topic>.md を作成します。

パスの選択： コンテキストからユーザー名がわかる場合は（例：thoughts/taras/brainstorms/）、その名前を使用します。不明な場合は thoughts/shared/brainstorms/ を使用します。

判明している情報を使って、フロントマターと Context セクションに記入します。トピック、提供されたコンテキスト、初期の考えなどを含めます。現時点でわかっていることを記述してください。

事前学習の参照

任意のサブスキル： ~/.agentic-learnings.json が存在する場合は、先に /learning recall <current topic> を実行し、関連する過去の学習内容を確認してください。

ステップ2：フェーズを評価する

探索の方向性を把握します。次の質問を使って AskUserQuestion を実行します。

質問	選択肢
「どのような探索を行いますか？」	1. 解決すべき問題、2. 発展させたいアイデア、3. 比較、4. 改善したいワークフロー、5. その他（説明してください）

ドキュメントの exploration_type フロントマターと Context セクションを更新し、探索の枠組みを記載します。

Step 3: 探索フェーズ

ソクラテス式の質疑応答を繰り返します。要件、制約、洞察を体系的に明らかにすることが目標です。

ルール：

• AskUserQuestion を使って、一度に質問を1つだけ尋ねます。
• すべての質問には推奨回答を付けます。推奨する回答を最初の選択肢にし、「(Recommended)」と表示して、その理由を説明欄に記載します。提案できる既定値について自由回答形式で尋ねてはいけません。ユーザーには確認または変更してもらいます。
• 事実と決定事項：調べればわかることをユーザーに尋ねてはいけません。コードの動作、ライブラリがサポートする機能、現在の挙動などは事実です。セッション中にバックグラウンドのサブエージェントを速やかに起動し（desplega:delegate-work に従い、場所の特定には Haiku、分析には Sonnet を使用）、回答を洞察として記録します。ユーザーに尋ねるのは、トレードオフ、好み、スコープの判断など、真の決定事項に限ります。
• 未解決事項を追跡します：未解決の決定分岐を管理します（短い TodoWrite リストで構いません）。回答によって分岐が解消されることもあれば、新たに生じることもあります。未解決事項がなくなり、すべての分岐が解決または明示的に保留され、暗黙のままになっている事項がなくなったら、探索は完了です。
• 回答を受けるたびに、ドキュメントの ## Exploration の下に新しいセクションを追加します。

  ### Q: [Your question]
  [User's answer]
  
  **Insights:** [Any observations, implications, or connections you noticed]
  

• スコープを絞り込む、または理解を深めるために、次に最も重要な質問を特定します。
• ユーザーが満足したと伝えるか、自然に十分な情報が得られるまで続けます。

質問の方針：

• 広い範囲から始めます。問題領域と目標を把握します。
• 徐々に絞り込みます。制約、既存の解決策、非機能要件を確認します。
• 境界を探ります。「何が原因で失敗しますか？」「最もシンプルな形はどのようなものですか？」「解決しようとしていないことは何ですか？」

YAGNI の原則

重要：探索フェーズでは、早まって解決策を提示しないでください。目標は理解であり、実装ではありません。ユーザーが早い段階で解決策を考え始めた場合：

• アイデアを簡潔に受け止めます。
• 要件の確認へと話題を戻します。「興味深いアプローチですね。それに決める前に、まず［関連する制約／要件］を確認しましょう。［追加の質問］」
• 解決策の検討は、Synthesis または後続の /create-plan で行います。

Step 4: 統合フェーズ

探索が完了したら（未解決事項がなくなった場合、またはユーザーが終了を伝えた場合）、## Synthesis セクションを追加します。

## Synthesis

### Key Decisions
- [Decision 1]
- [Decision 2]
- [Deferred: <decision> — defaulting to <recommended answer> unless revisited]

### Open Questions
- [FACT-shaped question only — answerable by /research, tagged as its input]

### Constraints Identified
- [Constraint 1]
- [Constraint 2]

### Core Requirements
- [Requirement 1 — lightweight PRD-style]
- [Requirement 2]

決定事項が未決のまま終わるブレインストーミングは不完全です。 未解決の質問には、/research でコードベースやドキュメントを調べれば回答できる事実に関する項目のみを含めます。決定に関する質問は、「主要な決定事項」で解決するか、「推奨案を記したうえで、X を既定値として保留」と記録する必要があります。ユーザーが決定事項を未解決のままセッションを切り上げた場合は、統合する前に、各項目の既定値をまとめて一度だけ確認します。または、自分の推奨案を既定値として明記します。

学びの記録

任意のサブスキル： このワークフローで重要な洞察、パターン、注意点、決定事項が得られた場合は、desplega:learning を使って /learning capture で記録することを検討してください。今後のセッションでほかの人に役立つ学びに重点を置きます。

Step 5: 引き継ぎフェーズ

引き継ぎの前に、ブレインストーミングのドキュメントで /review を実行し、未調査の領域を特定するかどうかを尋ねます。

次に AskUserQuestion を使って、以下を尋ねます。

質問	選択肢
「次のステップは何ですか？」	1. このブレインストーミングをもとに調査を始める（→ /research）、2. 直接計画を作成する（→ /create-plan）、3. 今回はここまでにする（ブレインストーミングを保留する）

回答に応じて：

• 調査：ブレインストーミングのファイルを入力コンテキストとして /research コマンドを提案します。
• 計画：ブレインストーミングのファイルを入力コンテキストとして /create-plan コマンドを提案します。
• 完了：適切に、ドキュメントの status を parked または complete に設定します。

ドキュメントの変遷

ブレインストーミングのドキュメントは、セッション中に内容が変化する生きた成果物です。最初は大まかな状態から始まり、質疑応答を通じて構成が整っていきます。最終的には、ほかの人が読んで内容を理解できる、単独で完結したコンテキストドキュメントに仕上げます。

レビューの統合

ファイルレビューはデフォルトで有効です。

• 統合後、インラインの人間によるコメントを得るために /file-review:file-review <path> を実行します
• フィードバックは file-review:process-review スキルで処理します