brainstorming

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

概要

自然な対話を通じて、アイデアを具体的なデザインや仕様へと仕上げるお手伝いをします。

まず現在のプロジェクトの状況を把握し、アイデアを深めるために一度に一つずつ質問します。何を作るのかを把握したら、デザインを提示してユーザーの承認を得ます。

デザインを提示し、ユーザーの承認を得るまでは、実装スキルを呼び出したり、コードを書いたり、プロジェクトのひな形を作成したり、その他の実装作業を行ったりしてはいけません。これは、どれほど簡単に見えるプロジェクトであっても、すべてに適用されます。

アンチパターン：「デザインが必要なほど複雑ではない」

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

チェックリスト

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

1. プロジェクトの状況を調べる — ファイル、ドキュメント、最近のコミットを確認します
2. 確認の質問をする — 目的、制約、成功基準を理解するため、一度に一つずつ質問します
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回のメッセージにつき質問は一つだけにします。さらに掘り下げる必要がある場合は、複数の質問に分けます
• 目的、制約、成功基準の理解に重点を置きます

アプローチを検討する：

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

デザインを提示する：

• 作るものを十分に理解したら、デザインを提示します
• 各セクションの長さは複雑さに応じて調整します。単純な内容なら数文、複雑な内容なら最大200～300語にします
• 各セクションの後に、ここまでの内容に問題がないか尋ねます
• アーキテクチャ、コンポーネント、データフロー、エラー処理、テストを扱います
• 不明点があれば、戻って確認する準備をしておきます

デザインの後

ドキュメント作成：

• 承認済みのデザインを docs/plans/YYYY-MM-DD-<topic>-design.md に記載します
• 使用可能であれば、elements-of-style:writing-clearly-and-concisely スキルを使います
• デザインドキュメントを git にコミットします

実装：

• writing-plans スキルを呼び出して詳細な実装計画を作成します
• その他のスキルは呼び出さないでください。次のステップは writing-plans です。

主な原則

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