brainstorming

アイデアを仕様にまとめるブレインストーミング

概要

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

創造的または複雑な作業を行う前、およびユーザーが「ブレインストーミング」「設計」「仕様を作成」などのリクエストをした場合は、必ずこのスキルを使用してください。

まず、@investogator スキルを使って現在のプロジェクトのコンテキストを把握します。次に、アイデアを具体化するため、質問を一度に1つずつ行います。作成するものを理解できたら、@investigator スキルをもう一度使って、変更がプロジェクトにどのような影響を与えるかを分析します。その後、仕様を200〜300語程度の短いセクションに分けて提示し、各セクションの後で、ここまでの内容に問題がないか確認します。

プロセス

アイデアの理解：

• まず、@investogator スキルを使って現在のプロジェクトの状態（ファイル、ドキュメント、最近の Git コミット）を確認します
• アイデアを具体化するため、質問を一度に1つずつ行います
• 可能であれば選択式の質問を優先しますが、自由回答形式でも構いません
• 質問の選択肢として、トレードオフと推奨案を添えて、2〜3種類のアプローチを提示します
• 1回のメッセージで質問するのは1つだけです。さらに掘り下げる必要がある場合は、複数の質問に分けます
• プロジェクトのコンテキストなどから簡単に推測できないことだけを質問します
• 目的、制約、成功基準の理解に重点を置きます

既存のスキルを活用する

• 関連するエージェントスキルを特定します
• 次の形式で出力します：「ブレインストーミングには、次のスキルを使用します：@skill1、@skill2、...」
• 特定したスキルを使ってアイデアを検討します

仕様の提示：

• 作成するものを理解できたら、仕様を提示します
• 仕様を200〜300語程度のセクションに分けます
• 各セクションの後で、ここまでの内容に問題がないか確認します
• 重要な項目をすべて扱います：
  • コーディングプロジェクトの場合：アーキテクチャ、コンポーネント、データフロー、パフォーマンス、セキュリティ、マルチスレッド処理／非同期処理、エラー処理、テスト
  • コーディング以外のプロジェクトの場合：対象とする項目の一覧をユーザーに確認します
• 内容に不明な点があれば、いつでも戻って確認します

重要：ユーザーの確認があるまでは、変更の適用やその他の操作を行わないでください

• 検討、質問、仕様の提示のみを行います
• タスクの分解や変更の適用に進む前に、ユーザーから明示的な確認を待ちます

仕様をまとめた後

ドキュメント化：

• 確認済みの仕様を docs/YYYY-MM-DD-<topic>-specs.md に書き込みます

詳細な実行計画（続行する場合）：

• 「詳細なタスク分解に進みますか？」と質問します
• task-breakdown スキルを使って、詳細なタスク分解を作成します
• 重要：変更の適用は開始せず、タスク分解ドキュメントの作成のみを行います
• タスク分解に基づく変更を適用する前に、ユーザーから明示的な確認を待ちます

基本原則

• 質問は一度に1つ - 複数の質問でユーザーを圧倒しないでください
• 選択式を優先 - 可能な場合は、自由回答形式よりも回答しやすい選択式を使います
• YAGNIを徹底する - すべての設計から不要な機能を取り除きます
• 代替案を検討する - 決定する前に、必ず2〜3種類のアプローチを提示します
• 段階的に確認する - 仕様をセクションごとに提示し、それぞれを確認します
• 柔軟に対応する - 内容に不明な点があれば、戻って確認します
• 先走って行動しない - ユーザーがタスク分解を確認するまでは、変更の適用を決して開始しません