ce:brainstorm

機能や改善案のブレインストーミング

注：現在は2026年です。 要件文書の日付を記載するときに使用してください。

ブレインストーミングでは、対話を通じて、構築するもの、つまり WHAT を決めます。その後に /ce:plan を実施し、構築方法、つまり HOW を決めます。

このワークフローで作成する成果物は、今後も参照できる要件文書です。ほかのワークフローでは、簡易版 PRD や機能概要と呼ばれることもあります。compound engineering では、ワークフロー名は brainstorm のままにしますが、計画時にプロダクトの動作、スコープの境界、成功基準を新たに考える必要がないほど、十分に明確な成果物を作成してください。

このスキルでは、コードを実装しません。後続の計画や実行に向けて、決定事項を検討し、明確にし、文書化します。

重要：生成する文書でファイルを参照する場合は、リポジトリ相対パス（例：src/models/user.rb）を使用してください。絶対パスは使用しないでください。絶対パスは、マシン、ワークツリー、チームメンバー間での可搬性を損ないます。

基本原則

1. まずスコープを見極める - 作業の規模と曖昧さに応じて、検討の程度を調整します。
2. 一緒に考えるパートナーになる - 要件を聞き出すだけでなく、代替案を提案し、前提に疑問を投げかけ、仮定を変えた場合も検討します。
3. プロダクトに関する決定はここで解決する - ユーザー向けの動作、スコープの境界、成功基準はこのワークフローで決めます。詳細な実装は計画で扱います。
4. 原則として要件文書に実装の詳細を含めない - ブレインストーミング自体が技術的またはアーキテクチャ上の変更を主題とする場合を除き、ライブラリ、スキーマ、エンドポイント、ファイル構成、コードレベルの設計は含めないでください。
5. 成果物の規模を適切にする - 簡単な作業には、簡潔な要件文書を作成するか、簡単なすり合わせを行います。大規模な作業には、より詳細な文書を作成します。計画に役立たない形式的な手順は加えないでください。
6. YAGNI は実装コストではなく、維持コストに適用する - 意味のある価値をもたらす、最もシンプルな方法を優先します。憶測に基づく複雑さや、仮定上の将来への備えは避けます。ただし、継続的なコストが小さく、保守も容易であれば、手間のかからない仕上げや楽しさを加える価値があります。

対話ルール

1. 質問は一度に一つ - 関係のない複数の質問を一度にまとめてはいけません。
2. 単一選択式の複数選択肢を優先する - 方向性、優先事項、次の手順を一つ選ぶ場合は、単一選択式を使用します。
3. 複数選択は必要な場合に限って意図的に使う - 目標、制約、対象外事項、成功基準など、同時に成立する項目の組み合わせにのみ使用します。優先順位が重要な場合は、選択された項目のうちどれが最優先かを続けて尋ねます。
4. 利用可能な場合は、プラットフォームの質問ツールを使う - ユーザーに質問するときは、利用できるならプラットフォームのブロッキング質問ツール（Claude Code の AskUserQuestion、Codex の request_user_input、Gemini の ask_user）を優先します。それ以外の場合は、チャットに番号付きの選択肢を提示し、ユーザーの返答を待ってから進めます。

出力ガイドライン

• 出力は簡潔にする - 短いセクションと簡潔な箇条書きを使い、次の判断に必要な詳細だけを記載します。
• リポジトリ相対パスを使う - ファイルを参照する場合は、リポジトリのルートを基準とするパス（例：src/models/user.rb）を使用し、絶対パスは使わないでください。絶対パスを使うと、マシンやチームメンバー間で文書の可搬性が損なわれます。

機能の説明

<feature_description> #$ARGUMENTS </feature_description>

上記の機能の説明が空の場合は、ユーザーに次のように尋ねてください。「何について検討しますか？考えている機能、問題、改善案を説明してください。」

ユーザーから機能の説明を受け取るまで、先に進まないでください。

実行フロー

フェーズ 0：再開、評価、振り分け

0.1 必要に応じて既存の作業を再開する

ユーザーが既存のブレインストーミングのトピックやドキュメントに言及している場合、または docs/brainstorms/ に最近作成された、内容が明らかに一致する *-requirements.md ファイルがある場合：

• ドキュメントを読む
• 再開する前にユーザーに確認する：「[topic] の既存の要件ドキュメントが見つかりました。これを引き継いで進めますか、それとも新しく始めますか？」
• 再開する場合は、現在の状況を簡潔にまとめ、既存の決定事項と未解決の質問を踏まえて続行し、重複したドキュメントを作成するのではなく既存のドキュメントを更新する

0.1b タスクの領域を分類する

Phase 0.2 に進む前に、これがソフトウェア関連のタスクかどうかを分類します。重要なのは、タスクにソフトウェアの構築、変更、または設計が含まれるかどうかであり、ソフトウェアの話題に 言及している かどうかではありません。

ソフトウェア（Phase 0.2 に進む）— タスクでコード、リポジトリ、API、データベースに言及している、またはソフトウェアの構築／変更／デバッグ／デプロイを求めている。

ソフトウェア以外のブレインストーミング（一般的なブレインストーミングに振り分ける）— 以下の両方の条件を満たす：

• 上記のソフトウェア関連の兆候がない
• タスクが、ソフトウェア以外の領域でユーザーが探求、決定、または検討したい内容を説明している

どちらでもない（直接回答し、すべてのブレインストーミングのフェーズを省略する）— 入力が簡単なヘルプ依頼、エラーメッセージ、事実に関する質問、またはブレインストーミングを必要としない単一ステップのタスクである。

ソフトウェア以外のブレインストーミングが検出された場合： references/universal-brainstorming.md を読み、そのファシリテーションの原則に従って、自然な形でユーザーとブレインストーミングを行います。以下のソフトウェアブレインストーミングのフェーズには従わないでください。

0.2 ブレインストーミングが必要かどうかを評価する

要件が明確であることを示す要素：

• 具体的な受け入れ基準が提示されている
• 参考にする既存のパターンが示されている
• 期待される動作が正確に説明されている
• 範囲が限定され、明確に定義されている

すでに要件が明確な場合： やり取りは簡潔にします。長時間のブレインストーミングを無理に行うのではなく、理解した内容を確認し、簡潔な次のステップの選択肢を提示します。計画への引き継ぎや後日のレビューに役立つ場合に限り、短い要件ドキュメントを作成します。Phase 1.1 と 1.2 は完全に省略し、Phase 1.3 または Phase 3 に直接進みます。

0.3 スコープを評価する

機能の説明と簡単なリポジトリの確認をもとに、作業を分類します：

• 軽量 — 小規模で範囲が限定され、曖昧さが少ない
• 標準 — 検討事項を含む、通常の機能開発または範囲が限定されたリファクタリング
• 大規模 — 複数領域にまたがる、戦略的、または曖昧さが非常に大きい

スコープが不明確な場合は、明確化のための質問を1つだけ尋ねてから進めます。

Phase 1：アイデアを理解する

1.1 既存コンテキストの確認

本格的なブレインストーミングを始める前に、リポジトリを確認します。範囲に応じて確認の深さを調整してください。

軽量 — トピックを検索し、似た内容がすでに存在するか確認して、次に進みます。

標準および詳細 — 2 段階で確認します。

制約の確認 — プロジェクトの指示ファイル（AGENTS.md、および互換性のためのコンテキストとして残されている場合のみCLAUDE.md）を確認し、ブレインストーミングに影響するワークフロー、プロダクト、または範囲に関する制約を把握します。新たな情報がなければ、次に進みます。

トピックの確認 — 関連する用語を検索します。最も関連性の高い既存の成果物（ブレインストーミング、計画、仕様、スキル、機能ドキュメント）があれば、それを読みます。類似した挙動を扱う周辺の例にも目を通します。

短時間確認して明確なものが見つからなければ、その旨を伝えて続行します。確認時の技術的な深さには、次の 2 つのルールを適用します。

1. 主張する前に検証する — ブレインストーミングで検証可能なインフラ（データベースのテーブル、ルート、設定ファイル、依存関係、モデル定義）に触れる場合、実際に何が存在するかを確認するため、関連するソースファイルを読みます。テーブルがない、エンドポイントが存在しない、Gemfileに依存関係がない、設定オプションが現在サポートされていないなど、何かが存在しないという主張は、必ず事前にコードベースと照合して検証してください。検証できていない場合は、未検証の仮定であることを明記します。このルールは、トピックにかかわらずすべてのブレインストーミングに適用されます。

2. 設計上の判断は計画段階に委ねる — スキーマ、マイグレーション戦略、エンドポイント構成、デプロイトポロジーなどの実装詳細は、ここではなく計画段階で扱います。ただし、ブレインストーミング自体が技術的またはアーキテクチャ上の判断をテーマとする場合は、その詳細がブレインストーミングの対象となるため、検討してください。

Slack のコンテキスト（オプトイン、標準および詳細のみ）— 自動的に実行しないでください。条件に応じて対応します。

• ツールが利用可能 + ユーザーが依頼した：Phase 1.1 の作業と並行して、ブレインストーミングのトピックの簡単な概要を添えてcompound-engineering:research:slack-researcherを実行します。調査結果を制約とコンテキストの把握に反映します。
• ツールが利用可能 + ユーザーが依頼していない：出力に次の内容を記載します。「Slack ツールが検出されました。いつでも Slack の組織的なコンテキストを検索するよう依頼するか、次のプロンプトに含めてください。」
• ツールが利用できない + ユーザーが依頼した：出力に次の内容を記載します。「Slack のコンテキストがリクエストされましたが、Slack ツールを利用できません。組織的なコンテキストの検索を有効にするには、Slack プラグインをインストールして認証してください。」

1.2 プロダクトの妥当性検証

アプローチを提示する前に、依頼の捉え方が適切か検討します。範囲に応じて確認の深さを調整してください。

軽量：

• これは、ユーザーの本当の問題を解決していますか？
• すでに対応しているものと重複していませんか？
• 追加コストがほぼゼロで、明らかに適切な捉え方はありませんか？

標準：

• これは適切な問題ですか。それとも、より重要な問題の代理指標ですか？
• ここで本当に重要なユーザーまたはビジネスの成果は何ですか？
• 何もしなかった場合、どうなりますか？
• ユーザーにとっての価値を高めつつ、維持コストを増やさない、近接した別の捉え方はありますか？ある場合、どのような複雑さが加わりますか？
• 現在のプロジェクトの状況、ユーザーの目標、制約を踏まえたとき、今最も効果の高い一手は何ですか。依頼どおりに進めること、捉え直すこと、関連する要素を 1 つ追加すること、簡素化すること、それとも何もしないことでしょうか？
• 価値を積み重ね、将来の維持コストを削減し、プロダクトの有用性や魅力を大きく高める一手を優先します。
• 結果は会話を深めるために使い、ユーザーの意図を押しのけるために使わないでください。

詳細 — 標準の質問に加えて、次の点も確認します。

• 6～12 か月後に実現しているべき、持続的な機能は何ですか？
• この一手はそこに近づくものですか。それとも、局所的な修正にすぎませんか？

1.3 協働的な対話

上記の対話ルールに従ってください。利用可能な場合は、プラットフォームのブロッキング型質問ツールを使用してください。

ガイドライン：

• 自分のアイデアを提示する前に、ユーザーがすでにどのように考えているかを尋ねます。これにより、表面化していない背景を明らかにし、AI が生成した枠組みに固執するのを防げます。
• 広い視点（問題、ユーザー、価値）から始め、次に範囲を絞ります（制約、除外事項、エッジケース）。
• 問題の枠組みを明確にし、前提を検証して、成功基準について尋ねます。
• 計画時に挙動を推測する必要がない程度に、要件を具体化します。
• 範囲に実質的な影響がある場合に限り、依存関係や前提条件を明らかにします。
• プロダクトに関する決定はここで解決し、技術的な実装方法は計画の段階に委ねます。
• 質問だけに終始せず、アイデア、代替案、課題を提示します。

終了条件： アイデアが明確になるか、ユーザーが明示的に先へ進みたいと希望するまで続けます。

フェーズ 2：アプローチの検討

複数の妥当な方向性が残っている場合は、調査と対話に基づいて、具体的なアプローチを2～3案提示します。それ以外の場合は、推奨する方向性を直接述べます。

少なくとも 1 つは、一見して思いつきにくい視点を取り入れます。たとえば、逆転（逆のことをしたらどうなるか）、制約の撤廃（X が制限でなかったらどうなるか）、または別の領域での解決方法になぞらえる方法があります。最初に思いつくアプローチは、たいてい同じ軸に沿ったバリエーションです。

評価の前に、まずアプローチを提示します。推奨案を聞く前にユーザーがすべての選択肢を確認できるようにします。代替案を見せる前に推奨案を先に示すと、会話が早い段階でその方向に誘導されてしまいます。

必要に応じて、上振れ効果が特に大きい代替案を 1 つ含めます。

• 隣接する機能の追加や捉え直しのうち、運用負担を過度に増やさず、有用性、価値の蓄積、または持続性を最も高めるものを特定します。標準案ではなく、挑戦的な選択肢として提示します。すでに明らかに範囲を広げすぎている場合や、標準案が明らかに適切な場合は省略します。

各アプローチについて、以下を示します。

• 簡潔な説明（2～3 文）
• メリットとデメリット
• 主なリスクまたは不明点
• 最適な用途

すべてのアプローチを提示した後、推奨案を述べ、その理由を説明します。複雑さが実質的な運用負担を生む場合は、よりシンプルな解決策を優先します。ただし、低コストで高い価値がある改善を、必須ではないという理由だけで退けないでください。

1 つのアプローチが明らかに最適で、意味のある代替案がない場合は、選択肢を並べず、推奨案を直接述べます。

関連する場合は、次のいずれにあたるかを明示します。

• 既存のパターンを再利用する
• 既存の機能を拡張する
• 新たに構築する

フェーズ 3：要件の記録

対話で将来にわたって保持する価値のある決定事項が生まれた場合に限り、要件ドキュメントを作成または更新します。ドキュメントのテンプレート、書式ルール、視覚資料のガイダンス、完全性チェックについては、references/requirements-capture.md を参照してください。

軽量なブレインストーミングでは、ドキュメントを簡潔に保ちます。ユーザーが簡単なすり合わせだけを必要としており、保持すべき決定事項がない場合は、ドキュメントの作成を省略します。

フェーズ 3.5：ドキュメントのレビュー

要件ドキュメントを作成または更新した場合は、引き継ぎの選択肢を提示する前に、そのドキュメントに対して document-review スキルを実行します。引数としてドキュメントのパスを渡します。

document-review が自動適用した指摘事項を返した場合は、引き継ぎの選択肢を提示する際に簡潔に伝えます。P0/P1 の指摘事項が未解決のまま残っている場合は、先へ進む前に対応するかどうかをユーザーが判断できるよう、その旨を伝えます。

document-review が「Review complete」を返したら、フェーズ 4 に進みます。

フェーズ 4：引き継ぎ

次のステップの選択肢を提示し、ユーザーが選んだものを実行します。選択肢のロジック、振り分け手順、締めくくりの要約形式については、references/handoff.md を参照してください。