ideation

アイデア出し：アイデアを構造化されたドキュメントにする

自然な対話を通じて、漠然としたアイデアを構造化され、検証済みのアイデアドキュメントにまとめるのを支援します。まず現在のプロジェクトの状況を把握し、その後、アイデアを具体化するために一度に1つずつ質問します。アイデアが明確になったら、実現可能性を評価したうえで複数のアプローチを提示し、ユーザーの承認を得ます。

実装に進んではいけません。このスキルの目的は、要件定義（例：USDM）に活用したり、タスクとして追跡したりできる、十分に検討されたアイデアドキュメントを作成することです。単純に見えるアイデアでも、検討されていない前提が最も多くの無駄な作業を引き起こします。

プロセス

以下の手順を順番に実施します。

ステップ1：状況の調査

先に進む前に、ユーザーの入力で参照されているすべての情報源を調査します。

1a：外部参照

ユーザーの入力から、アプリ名、技術名、URL、仕様、標準、プロトコル、サービス、ドキュメントなどの外部参照を探します。見つかった場合は、次のように対応します。

• URL：リンク先の内容を取得して読み、対象範囲、API の概要、制約、仕様を把握します
• 名称が挙げられた技術／サービス：公式ドキュメント、機能、制限事項、統合パターンを調べます
• 既存のアプリや製品：ユーザーが何を指しているのか理解するため、その機能、動作、設計を調査します
• 標準／プロトコル：要件と制約を把握するため、仕様を調べます

すべての外部参照を調査するまで、ステップ2に進んではいけません。外部参照を誤解すると、その後のすべてのステップに誤りが波及します。

1b：プロジェクトの状況

既存の内容を把握するため、現在のプロジェクトを確認します。

• プロジェクトのファイル、ドキュメント、最近のコミットを確認します
• 既存のソリューション、パターン、規約を特定します
• 制約、依存関係、技術的な境界を記録します

これにより、白紙の状態から始めるのではなく、現実に即したアイデア出しができます。

ステップ2：確認の質問をする

焦点を絞った対話を通じて、アイデアを理解します。

• 一度に1つの質問をします。複数の質問をまとめて投げかけてはいけません
• 可能な場合は選択式の質問を優先します。自由回答よりも答えやすいためです
• 目的、対象ユーザー、制約、成功基準の理解に重点を置きます
• 新しい情報によって状況が変わった場合は、前の質問を見直します

ユーザーが何を望んでいるのか、なぜそれを望んでいるのかが明確になるまで続けます。

ステップ3：アプローチを提案する

トレードオフを含めて、異なるアプローチを2～3案提示します。

• 推奨するアプローチを最初に示し、その理由を説明します
• 根拠を添え、会話の流れに沿って選択肢を提示します
• 各アプローチには、次の実現可能性の評価を含めます。
  • 差別化：既存のソリューションとどう異なるか
  • 技術的なリスクと制約：技術面でどのような問題が起こりうるか
  • プレモーテム：「このアイデアが失敗するとしたら、その原因は何か」
• YAGNI を適用し、すべてのアプローチから不要な機能を取り除きます

ステップ4：提示して検証する

ユーザーがアプローチ（またはその組み合わせ）を選んだら、次のようにします。

• 複雑さに応じて、セクションに分けてアイデアを提示します
• 各セクションの後に、ここまでの内容で問題ないかを尋ねます
• 理解できない点があれば、前に戻って修正します

Step 5: アイデア文書を作成する

ユーザーがアイデアを承認したら、文書を作成します。

保存先：.docs/ideas/YYYY-MM-DD-<topic>.md

文書には、次のセクションを含める必要があります。

セクション	内容
What	何をするのか、どのような問題を解決するのか
Why	根拠、ユーザーにとってのメリット、ビジネス上の価値
Scope	対象範囲内／対象範囲外の境界
Stakeholders	対象ユーザー、影響を受けるシステム
Approaches	検討した代替案、トレードオフ、実現可能性の評価
Decision	選択したアプローチとその根拠

出力テンプレートについては、templates/idea-document.md を参照してください。

これらのセクションは、要件定義ツール（例：USDM）への入力として利用できるよう構成されています。

• What は Requirements に対応します
• Why は Reasons に対応します
• Scope は Descriptions（コンテキスト、制約）に対応します
• Stakeholders はスコープの確認に役立ちます

Step 6: 出力を選択する

アイデア文書の作成後、ユーザーに希望する出力を尋ねます。

選択肢	アクション
A: Markdown のみ（デフォルト）	アイデア文書を .docs/ideas/ に保存して完了
B: Markdown + GitHub Issue	文書を保存し、内容を含む GitHub Issue を作成
C: Markdown + 要件	文書を保存し、要件定義スキル（例：usdm）を呼び出す

主な原則

• 一度に質問は1つ — 1つのメッセージに複数の質問をまとめない
• 選択式を優先 — 可能であれば、自由回答よりも回答しやすい選択式にする
• YAGNI を徹底する — すべてのアプローチから不要な機能を取り除く
• 代替案を検討する — 決定する前に、必ず2～3のアプローチを提示する
• 段階的に検証する — セクションを提示し、承認を得てから次に進む
• 柔軟に対応する — 筋が通らない点があれば、立ち戻って明確にする
• 楽観視せず実現可能性を重視する — すべてのアプローチについて、リスクを率直に評価する

クレジット

このスキルは、obra/superpowers のブレインストーミングスキル（MIT License）を基にしています。