brainstorming

アイデアを設計に落とし込む

目的

自然な対話を通じて、アイデアを十分に練られた設計や仕様にまとめます。

使用するタイミング

次のような場合にこのスキルを使用します。

• リクエストに、動作や機能の作成または変更が含まれている
• 要件が曖昧または不完全である
• 実装前にトレードオフの分析が必要である
• コーディング前に設計ドキュメントの承認が必要である

進捗の追跡

各主要フェーズの前に進捗ゲージを表示します。

[████░░░░░░░░░░░░░░░░] 20% — Phase 1/5: Exploring Project Context
[████████░░░░░░░░░░░░] 40% — Phase 2/5: Clarifying Requirements
[████████████░░░░░░░░] 60% — Phase 3/5: Proposing Approaches
[████████████████░░░░] 80% — Phase 4/5: Presenting Design
[████████████████████] 100% — Phase 5/5: Writing Design Doc

ワークフロー

1. プロジェクトのコンテキストを調査する
2. 質問を一度に1つずつ行い、詳細を確認する
3. トレードオフを添えて2～3個のアプローチを提案する
4. 設計の各セクションを提示して承認を得る
5. 設計ドキュメントを保存し、writing-plans に引き継ぐ

概要

まず現在のプロジェクトのコンテキストを把握し、次に質問を一度に1つずつ行ってアイデアを具体化します。何を構築するのかを理解したら、設計を提示してユーザーの承認を得ます。

設計を提示し、ユーザーの承認を得るまでは、実装スキルの呼び出し、コードの作成、プロジェクトのひな型作成、その他の実装作業を一切行ってはいけません。これは、どれほど簡単に思えるプロジェクトであっても例外なく適用されます。

アンチパターン：「これは設計するほど複雑ではない」

すべてのプロジェクトでこのプロセスを行います。ToDo リスト、単一関数のユーティリティ、設定の変更も例外ではありません。「簡単な」プロジェクトほど、検討されていない前提によって無駄な作業が最も多く発生します。設計は短くてもかまいません（本当に簡単なプロジェクトなら数文程度）。ただし、必ず提示して承認を得てください。

チェックリスト

次の各項目について必ずタスクを作成し、順番に完了してください。

1. プロジェクトのコンテキストを調査する — ファイル、ドキュメント、最近のコミットを確認する
2. 確認の質問をする — 目的、制約、成功基準を理解できるまで、一度に1つずつ質問する
3. 2～3個のアプローチを提案する — トレードオフと推奨案を示す
4. 設計を提示する — 複雑さに応じたセクションに分けて提示し、各セクションの後にユーザーの承認を得る
5. 設計ドキュメントを書く — docs/plans/YYYY-MM-DD-<topic>-design.md に保存し、コミットする
6. 実装に移行する — writing-plans スキルを呼び出して実装計画を作成する

プロセスフロー

digraph brainstorming {
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Invoke writing-plans skill";
}

最終状態は writing-plans の呼び出しです。 frontend-design、mcp-builder、その他の実装スキルを呼び出してはいけません。ブレインストーミングの後に呼び出すスキルは、writing-plans のみです。

プロセス

アイデアを理解する：

• まず現在のプロジェクトの状態（ファイル、ドキュメント、最近のコミット）を確認する
• アイデアを具体化するため、質問を一度に1つずつ行う
• 可能であれば選択式の質問を優先する。ただし、自由回答形式でもかまいません
• 1つのメッセージにつき質問は1つだけにする。さらに掘り下げる必要がある場合は、質問を複数回に分ける
• 目的、制約、成功基準の理解に重点を置く

アプローチを検討する：

• トレードオフを添えて、異なるアプローチを2～3個提案する
• 推奨案とその理由を含め、会話形式で選択肢を提示する
• 推奨案から先に示し、推奨する理由を説明する

設計を提示する：

• 何を構築するのかを理解できたら、設計を提示する
• 各セクションの詳しさは複雑さに応じて調整する。単純な内容なら数文、詳細な検討が必要な内容なら200～300語程度までとする
• 各セクションの後に、ここまでの内容で問題ないかを尋ねる
• アーキテクチャ、コンポーネント、データフロー、エラー処理、テストを扱う
• 内容が不明瞭な場合は、立ち戻って確認できるようにする

設計の後

ドキュメント作成：

• 検証済みの設計を docs/plans/YYYY-MM-DD-<topic>-design.md に書き込む
• 利用可能であれば elements-of-style:writing-clearly-and-concisely スキルを使用する
• 設計ドキュメントを Git にコミットする

実装：

• writing-plans スキルを呼び出し、詳細な実装計画を作成する
• 他のスキルは呼び出してはいけません。次のステップは writing-plans です。

主要な原則

• 質問は一度に1つ - 複数の質問で圧倒しないでください
• 選択式を優先 - 可能であれば、自由回答よりも答えやすい形式にします
• YAGNI を徹底する - すべての設計から不要な機能を取り除きます
• 代替案を検討する - 決定する前に、必ず2〜3つのアプローチを提案します
• 段階的に検証する - 設計を提示し、次に進む前に承認を得ます
• 柔軟に対応する - 筋が通らない点があれば、戻って確認します

重要なルール

• ユーザーが設計を承認する前に、実装を始めてはいけません。
• 少なくとも2つのアプローチ間のトレードオフについて、話し合いを省略してはいけません。
• ブレインストーミングから実装スキルを直接呼び出してはいけません（引き継ぎ先は writing-plans のみ）。

使用例

1. 「ブレインストーミングを使って、コーディングを始める前にダッシュボードの再設計を定義してください。」
2. 「ブレインストーミングを使って、API の要件と制約を明確にしてください。」
3. 「ブレインストーミングを使って、新機能のアーキテクチャの選択肢を比較してください。」