development-brainstorming

開発のブレインストーミング：アイデアを技術設計に変える

概要

自然な対話を通じて、アイデアを詳細な設計や仕様にまとめるのを支援します。

まず、現在のプロジェクトの状況を把握してから、アイデアを具体化するために一度に1つずつ質問します。何を構築するのかを理解したら、設計を小さなセクション（200～300語）に分けて提示し、各セクションの後に、ここまでの内容に問題がないか確認します。

プロセス

アイデアを理解する：

• まず現在のプロジェクトの状態を確認します（ファイル、ドキュメント、最近のコミット）
• アイデアを具体化するために、一度に1つずつ質問します
• 可能な場合は選択式の質問を優先しますが、自由回答でも構いません
• 1つのメッセージにつき質問は1つだけにします。あるトピックをさらに掘り下げる必要がある場合は、複数の質問に分けます
• 目的、制約、成功基準の理解に重点を置きます

アプローチを検討する：

• トレードオフを含め、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 を使用して、詳細な実装計画を作成します

主な原則

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