brainstorming

アイデアをデザインに落とし込む

概要

自然な対話を通じて、アイデアを十分に練られたデザインや仕様へと発展させます。

まず現在のプロジェクトの状況を把握し、アイデアを具体化するために質問を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案を提案する
• 段階的に検証する — デザインを提示し、先に進む前に承認を得る
• 柔軟に対応する — 不明点があれば、戻って確認する