sdd-brainstorm

SDD ブレインストーミング

このスキルの最初の応答では、次の行を一度だけ最初に記載してください： sdd-brainstorm v1.0.0 · out/2026 · versão atual: https://github.com/robertodiasduarte/sdd-starter/releases/latest

クイックスタート

初期のアイデアを、要件として正式に定義する前に、検証済みの方向性へと導きます。

1. 元のアイデアを、確定した要件として書き換えずに記録します。
2. 実際に利用できるプロジェクトのコンテキストのみを洗い出します。
3. 発見のための質問を一度に1つずつ行います。
4. アプローチを提案する前に、最低3つの質問を行います。
5. サンプル、出力例、グラウンドトゥルース、または関連コードについて必ず質問します。
6. 2〜3つの異なるアプローチを提案し、明確な推奨案を示します。
7. スコープにYAGNIを適用します。
8. アプローチについてユーザーの確認を得ます。
9. 段階的な検証チェックポイントを最低2回設けます。
10. その後にのみ、BRAINSTORM ドキュメントを生成します。

対話ポリシーについては、references/brainstorm-protocol.mdを参照してください。最終成果物には、正式な構成テンプレートとして必ずassets/BRAINSTORM_TEMPLATE.mdを使用してください。

使用する場合／使用しない場合

アイデアの検討がまだ必要な場合、重要な選択肢がある場合、解決策よりも問題のほうが明確な場合、または後続フェーズの定義に向けて準備したい場合に使用します。

問題、ユーザー、目標、成功基準、制約、スコープがすでに明確な場合は、正式な仕様の代わりとして使用しないでください。その場合は、定義フェーズへ直接進むことを推奨します。コードの実装、詳細なアーキテクチャの設計、リリースの実行には使用しないでください。

必要なデータ

最小限必要な入力：

• 検討対象のアイデア、問題、依頼、メモ、または機能。

任意の入力：

• ユーザーのファイル／メモ；
• プロジェクトのコンテキスト；
• ディレクトリ構成と既存のパターン；
• 入力サンプル；
• 期待される出力例；
• グラウンドトゥルースまたは検証済みデータ；
• 関連コード；
• 技術面、運用面、期限、または予算の制約。

外部コネクターを必須としないでください。インターネット、リモートリポジトリ、またはユーザーのシステムへのアクセスを前提としないでください。コンテキストにアクセスできない場合は、観察内容を捏造せず、制限事項を記録してください。

必須の出力アセット

assets/BRAINSTORM_TEMPLATE.mdは、このスキルが作成するブレインストーミングの正式なテンプレートです。これは概念を参照するための資料ではなく、出力アセットです。最終的な.mdを作成する際は、記憶だけを頼りにドキュメントを再構成するのではなく、必ずこのテンプレートを再利用してください。

手順

1. 入力を分類する

主な種類を特定します：

• 曖昧なアイデア；
• 具体的な依頼；
• 問題；
• 機能リクエスト；
• 選択肢の比較；
• メモ／ファイル。

必須の手順を省略せずに、焦点を調整します。曖昧なアイデアでは探索が必要です。具体的な依頼では理解の妥当性確認が必要です。問題では解決策を考える前に痛点を調査します。機能リクエストでは、その必要性を問い直します。比較ではトレードオフを重視します。

2. コンテキストを収集する

アイデアの原文をRaw Inputとして保持します。

以下を区別します：

• ユーザーから提供された事実；
• ファイルやアクセス可能なコンテキストから確認できる観察事項；
• 推論。

推論を事実として扱わないでください。プロジェクトにアクセスできる場合は、構成、既存のパターン、想定される場所、関連する技術領域、インフラへの影響を確認します。アクセスできない場合は、N/A、desconhecido、またはnão fornecidoと記載します。

3. 対話形式でニーズを把握する

1回のメッセージにつき質問を1つだけ行います。

選択肢が明確な場合は選択式を優先し、必要に応じて自由回答の選択肢を含めます。まだ状況が把握できていない場合は、自由回答形式の質問を使います。回答が曖昧または矛盾している場合は、先に進む前に明確化を求めます。

最低限、次の項目を確認します。

1. 中心となる目的／課題
2. ユーザーまたは受益者
3. 制約、限界、関連する状況
4. まだ明確でない場合は、成功の指標

アプローチを提案する前に、最低3つのニーズ把握の質問を行います。サンプルについての質問は、この3つには数えません。

回答のたびに、次の内容を内部で記録します。

• 質問
• 回答
• 解決策への影響

4. サンプルを収集する

1回のやり取りで、次のものがあるか尋ねます。

• 入力ファイル
• 期待される出力の例
• ground truth／検証済みデータ
• 関連するコードや規約
• 利用できるサンプルがない

サンプルがある場合は、利用可能なツールだけで分析し、解決策にどのような影響を与えるかを記録します。サンプルがない場合も、ユーザーに不利益を与えることなく通常どおり進めます。

5. 2～3つのアプローチを提案する

ニーズ把握のゲートを通過した後にのみ提案します。

まず推奨するアプローチを示し、その理由を説明します。各アプローチについて、次の内容を伝えます。

• 名前
• 説明
• メリット
• デメリット／トレードオフ

アプローチは、表面的な違いではなく、実質的に異なるものにします。関連する場合は、複雑さ、リスク、労力、柔軟性、課題への適合性を比較します。

ユーザーにアプローチの確認を求めます。すべて却下された場合は、理解を見直し、必要な段階に戻ります。

6. YAGNIを適用する

提案したコンポーネントや機能について、次の点を確認します。

• これはMVPに必要ですか？
• これは今、中心となる課題を解決しますか？

この確認を満たさない項目は削除するか、後回しにします。削除／延期した項目とその理由を記録します。妥当な理由で削除できる項目がない場合は、YAGNIの見直しを実施し、追加で削減できる項目はなかったと記録します。この節を埋めるためだけに、削減項目を作り出してはいけません。

7. 段階的に検証する

進む方向が決まったら、短く検証可能な単位で解決策を提示します。内容に応じて、200～300語を目安にします。

たとえば、次のようなチェックポイントを最低2回設けます。

• チェックポイント1：コンセプト、範囲、コンポーネント
• チェックポイント2：データフロー、障害、依存関係、期待される動作

各チェックポイントでは、次の手順を踏みます。

1. セクションを提示する
2. フィードバックを求め、理解が合っているか確認する
3. 必要に応じて調整する
4. その後で次に進む

ユーザーが以前の理解を訂正した場合は、前に戻り、依存する決定を更新します。

8. BRAINSTORMを生成する

次の条件を満たした場合にのみ、成果物を生成します。

• 3つ以上の発見のための質問に回答していること。
• サンプルについて質問していること。
• 2つ以上のアプローチを検討していること。
• YAGNIを適用していること。
• 1つのアプローチについて合意していること。
• 2つ以上のチェックポイントを完了していること。

最終ドキュメントの唯一の正式な情報源として、必ずassets/BRAINSTORM_TEMPLATE.mdを使用します。

ファイルを生成する際は、次の手順に従います。

1. アセットをひな形としてコピー／使用します。
2. すべての{...}プレースホルダーを、会話で裏付けられた情報に置き換えます。
3. Approach Cなど、明示的に任意とされている該当しないセクションのみを削除します。
4. 主要セクションの順序と見出しを維持します。
5. アセットが利用できる場合、別の構成でBrainstormを作成しません。
6. 未解決の不足情報は、テンプレート内の適切な箇所にTBD、N/A、制約、または既知の依存関係として記録します。

最終ファイルの推奨ファイル名はBRAINSTORM_{FEATURE_NAME}.mdです。{FEATURE_NAME}には、プロジェクト内で読みやすく、一貫して使用できる形式を指定します。

保存先。 プロジェクトのルートにあるsdd/に保存します。どのエージェントでも同じ場所に表示されます。プロジェクトに.claude/sdd/がすでにある場合は、引き続きそのフォルダーを使用します。5つのフェーズのドキュメントはサブフォルダーを作成せず、同じ場所に保存します。

書き込み可能なプロジェクトのファイルシステムがある場合は、既存のファイルを確認なしに上書きせず、sdd/BRAINSTORM_{FEATURE_NAME}.md（既存のフォルダーがある場合は.claude/sdd/BRAINSTORM_{FEATURE_NAME}.md）として保存します。

ファイルシステムにアクセスできない場合は、Markdown全体をチャットで提示し、推奨するファイル名を明記します。

8.1. 発見プロセスを二重に設けずに完了する

引き継ぎの前に、判明している不足情報をすべてBRAINSTORM自体にまとめます。締めくくりで、新たな作業を始めないようにします。たとえば、次のような提案は避けてください。

• 「並行して最優先で入手する情報は……」
• 「次のフェーズの前に、……を収集してください」
• 「準備ができたら/define ...を実行します」

次のフェーズでは、Brainstormを入力成果物として使用します。検討中に入手できなかった情報は、以下に定めるNext Stepを変更せず、MarkdownにTBD、制約、または依存関係として記録します。

9. 引き継ぎを準備する

Suggested Requirements for /defineセクションには、会話で裏付けられた内容のみを記載します。

• 問題提起のドラフト
• 対象ユーザー
• 入手できる場合は、測定可能な成功基準
• 制約
• 対象外

指標を捏造しないでください。成功基準をまだ数値化できない場合は、数値を作り出さず、定義が必要な項目として記載します。

完了時、Next Stepには次の指示のみを記載します。

Execute o **SDD Define by RDD**.

Ready for: /define ...のようなコマンドで締めくくらないでください。 締めくくりで、サンプル、グラウンドトゥルース、コード、その他の情報を並行して収集するよう提案しないでください。そうしたニーズはBrainstormフェーズ自体で扱い、既知の不足情報として残る場合はドキュメントに記録します。

検証と品質チェックリスト

ブレインストーミングの完了を宣言する前に、次の項目を確認してください。

• Raw Input が保持されている。
• コンテキストで事実と推論が分けられている。
• 少なくとも3つの発見質問に回答している。
• 質問は一度に1つずつ行われている。
• サンプルについての質問が行われている。
• 実質的に異なるアプローチを少なくとも2つ検討している。
• 推奨するアプローチとその理由がある。
• 選択したアプローチをユーザーが確認している。
• YAGNI を適用し、その結果を記録している。
• 少なくとも2つの検証チェックポイントを完了している。
• 重要な決定と却下した代替案を記録している。
• Define への引き継ぎには、会話によって裏付けられた要件のみが含まれている。
• Next Step に含まれているのは、次の文のみである。Execute o **SDD Define by RDD**.
• 締めくくりに Ready for: /define ... を含めず、情報を並行して収集するよう勧めていない。
• 不確実なことを、暗黙のうちに事実へ置き換えていない。
• 最終文書が assets/BRAINSTORM_TEMPLATE.md に基づいて作成され、標準の構成が暗黙のうちに変更されていない。

例外への対応

• ユーザーが質問を省略したい場合： ブレインストーミングは続行できるものの、最低限のゲートを満たすまでは引き継ぎを完了できないことを簡潔に説明します。
• ユーザーがすでに要件をすべて提示している場合： ブレインストーミングを不必要に長引かせず、直接定義へ進むことを提案します。
• 回答に矛盾がある場合： 一度に1つずつ確認し、影響を受ける決定を更新します。
• サンプルがない場合： None available／N/A と記録して続行します。
• プロジェクトにアクセスできない場合： 構成、コミット、規約を確認したと主張しません。
• ユーザーがアプローチを選択した後に方向性を変更した場合： 比較と YAGNI の検討を再開し、影響を受けたチェックポイントをやり直します。
• 責任を持って削除できる YAGNI 項目がない場合： 削除なしで見直したことを記録し、除外項目を捏造しません。

例

曖昧な入力 Quero automatizar o processamento de notas fiscais, mas ainda não sei como.

まず、問題と望ましい結果の発見から始めます。最初の回答でアーキテクチャを提示しないでください。

機能リクエスト Quero adicionar um chatbot ao portal do cliente.

まず、必要性、対象ユーザー、期待する結果について質問します。その後、完全なチャットボットよりもシンプルな解決策を含め、代替案を比較します。

コンテキストを含むメモ Tenho estas notas de reunião e alguns exemplos de entrada/saída. Faça o brainstorm.

利用可能な資料を読み、事実を保持し、不足している質問を一度に1つずつ行います。また、アプローチを提案する前に、サンプルを根拠として活用します。

---

SDD Open by RDD の一部 — https://github.com/robertodiasduarte/sdd-open