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つのアプローチを提案する
• 段階的に検証する — デザインを提示し、次に進む前に承認を得る
• 柔軟に対応する — 内容に不明な点があれば、立ち戻って確認する