brainstorming

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

概要

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

まず現在のプロジェクトの状況を把握し、次に質問を一つずつ行ってアイデアを掘り下げます。何を作るのか理解できたら、デザインを200～300語程度の短いセクションに分けて提示し、各セクションの後に内容に問題がないか確認します。

プロセス

アイデアを理解する：

• まず現在のプロジェクトの状態（ファイル、ドキュメント、最近のコミット）を確認します
• 質問を一つずつ行い、アイデアを掘り下げます
• フィードバックツール：mcp-feedback-enhanced（例：ask_followup_question）が利用できる場合は、質問に必ず使用します。利用できない場合は、通常のチャットを使用します
• 可能であれば選択式の質問を優先しますが、自由回答式でも構いません
• 1つのメッセージにつき質問は1つだけにします。さらに掘り下げる必要がある場合は、複数の質問に分けます
• 目的、制約、成功基準の把握に重点を置きます

ドキュメントと仕様の作成：

• PRD（需求规格说明书）：背景、ユーザーフロー、機能の詳細、受け入れ基準を含む標準化された要件ドキュメントを作成します。
• 项目介绍（Project Introduction）：ステークホルダーやユーザーに向けて、プロジェクトのビジョン、コアバリュー、ロードマップを作成します。
• 特性说明（Feature Docs）：個別のモジュールについて、インタラクションの詳細とロジックを記述します。

アプローチの検討：

• トレードオフを示しながら、2～3種類の異なるアプローチを提案します
• 推奨案とその理由を添えて、選択肢を対話形式で提示します
• 推奨案を最初に示し、その理由を説明します

デザインの提示：

• 何を作るのか理解できたと判断したら、デザインを提示します
• 200～300語程度のセクションに分けます
• 各セクションの後に、内容に問題がないか確認します
• アーキテクチャ、コンポーネント、データフロー、エラー処理、テストを扱います
• 不明な点があれば、立ち戻って確認します

デザイン作成後

ドキュメント作成：

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

実装（続行する場合）：

• 「実装の準備を始めてもよいですか？」と尋ねます
• superpowers:using-git-worktrees を使用して、分離されたワークスペースを作成します
• superpowers:writing-plans を使用して、詳細な実装計画を作成します

主な原則

• 質問は一度に一つ - 複数の質問で相手を圧倒しないようにします
• 選択式を優先 - 可能な場合は、自由回答式より答えやすい選択式を優先します
• YAGNIを徹底する - すべてのデザインから不要な機能を取り除きます
• 代替案を検討する - 最終決定の前に、常に2～3種類のアプローチを提案します
• 段階的に検証する - デザインをセクションごとに提示し、それぞれを検証します
• 柔軟に対応する - 不明な点があれば、立ち戻って確認します