brainstorming

アイデアをデザインにまとめる

概要

自然な対話を通じて、アイデアを具体的なデザインや仕様にまとめるのを支援します。

まず現在のプロジェクトの状況を把握し、その後、アイデアを洗練させるために質問を一つずつ行います。何を作るのかを理解したら、デザインを提示してユーザーの承認を得ます。

デザインを提示し、ユーザーが承認するまで、実装スキルの呼び出し、コードの記述、プロジェクトのひな形作成、その他いかなる実装作業も行わないでください。これは、簡単に見えるかどうかにかかわらず、すべてのプロジェクトに適用されます。

アンチパターン：「デザインは不要なほど簡単」

すべてのプロジェクトでこのプロセスを実施します。「簡単な」プロジェクトほど、検討されていない前提によって多くの作業が無駄になるものです。デザインは簡潔でもかまいませんが、必ず提示して承認を得てください。

チェックリスト

以下の各項目についてタスクを作成し、順番どおりに完了する必要があります。

1. プロジェクトの状況を確認する — ファイル、ドキュメント、最近のコミットを確認します
2. 確認の質問をする — 目的、制約、成功基準を理解するため、一度に一つずつ質問します
3. 2～3種類のアプローチを提案する — トレードオフと推奨案を示します
4. デザインを提示する — 複雑さに応じたセクションに分け、テスト戦略、エラー処理の方針、検証基準を含めます（下記の品質原則を参照）。各セクションごとにユーザーの承認を得ます
5. デザインドキュメントを作成する — .claude/plans/YYYY-MM-DD-<topic>-design.md に保存し、コミットします
6. 実装へ移行する — writing-plans スキルを呼び出して、実装計画を作成します

品質原則

このスキルで作成する計画では、設計時に以下の事項を検討する必要があります。

• テスト戦略：references/tdd-principles.md
• エラー処理とデバッグの方針：references/debugging-principles.md
• 検証基準：references/verification-principles.md

プロセスの流れ

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、その他の実装スキルは呼び出さないでください。

質問の進め方、デザインの提示、ドキュメント作成、主要な原則など、プロセスの詳細については、references/detailed-process.md を参照してください。