intent-discovery

アイデアを実行可能な設計に変える

概要

体系的な対話を通じて、漠然としたアイデアを、仕様が明確で検証済みの設計へと導きます。まず既存のプロジェクトの状況を調査し、次に的を絞った質問を重ねて理解を深めます。設計がまとまったら、承認を得るために提示します。

最優先の指針

NO IMPLEMENTATION WITHOUT A VALIDATED DESIGN FIRST

例外はありません。回避策もありません。近道もありません。

使用する場面

必須：

• 新しい機能やコンポーネントを作成する
• 既存のシステムの機能を拡張する
• 既存のコードの動作を変更する
• 新しいプロジェクトやモジュールを立ち上げる
• 既存のシステムを再構築または再設計する

省略する場合：

• 誤字やスペルミスを修正する
• ユーザーが指定したとおりにインポートを更新する
• ユーザーが逐語的に指定した設定変更
• ユーザーが明示的に指定したファイルを削除する
• ユーザーが正確に指定したコマンドを実行する

設計を提示し、ユーザーが承認するまで、実装スキルの呼び出し、コードの生成、プロジェクトのスキャフォールディング、その他の実装作業を行ってはいけません。これは、どれほど単純に見えるプロジェクトにも例外なく適用されます。

認知上の落とし穴

正当化の理由	実際のところ
「これは設計するほどのことではありません」	単純なプロジェクトほど、検証されていない前提が潜みがちです。メモアプリでさえ、データモデル、ストレージ、操作方法を決める必要があります。
「ユーザーから正確な仕様が提示されています」	ユーザーが示すのは目標であって、設計ではありません。意図の発見を通じて、ユーザーの希望と実現方法の隔たりを埋めます。
「最適なアプローチはすでにわかっています」	わかっているのは、あくまで一つのアプローチです。代替案を提示すれば、トレードオフが明らかになり、見落としにも気づけます。
「設計に時間をかけると遅くなります」	間違ったものを作るほうが時間がかかります。5 分間の設計で、2 時間のやり直しを防げます。
「ちょっとした変更にすぎません」	方向を誤った小さな変更も、積み重なれば大きな問題になります。先へ進む前に方向性を確認してください。
「ユーザーはすぐに始めたがっているようです」	ユーザーが望んでいるのは成果であって、急ぐことではありません。簡潔な設計の確認が信頼につながります。

すべてのプロジェクトで、このプロセスを実施します。ToDo リスト、ユーティリティ関数、設定の微調整も例外ではありません。「単純な」プロジェクトこそ、検証されていない前提が大きな無駄を生みます。設計は簡潔でもかまいません（本当に単純な作業なら数文程度でも構いません）が、必ず提示して承認を得てください。

チェックリスト

以下の各項目について、必ずタスクを作成し、順番に完了させてください。

1. プロジェクトの状況を調査する -- ファイル、ドキュメント、最近のコミットを確認する
2. 参考資料を見つける -- 適切な参照システムに振り分けるため、reference-engine スキルを呼び出す（外部のリポジトリやライブラリには github-search、内部のパターンには codebase-research、ビジュアルテーマには design-research、UI には ux-patterns、API／スキーマ／テスト／インフラには組み込みライブラリを使用）
3. 確認の質問をする -- 1 回のメッセージにつき 1 つ質問し、目的／制約／成功基準を把握する
4. 2～3 つのアプローチを提示する -- トレードオフを添えたラベル付きの選択肢（A／B／C）として提示し、推奨案には星印を付ける
5. 設計を提示する -- 複雑さに応じたセクションに分け、各セクションの後にユーザーの確認を得る（YoloMode の場合は、提示してそのまま進める）
6. 設計ドキュメントを記録する -- docs/plans/YYYY-MM-DD-<topic>-design.md に保存してコミットする
7. 実装に引き継ぐ -- 実装計画を作成するため、task-planning スキルを呼び出す

ワークフロー図

digraph intent_discovery {
    "Survey project landscape" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Present 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User confirms design?" [shape=diamond];
    "Record design document" [shape=box];
    "Invoke task-planning" [shape=doublecircle];

    "Survey project landscape" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Present 2-3 approaches";
    "Present 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User confirms design?";
    "User confirms design?" -> "Present design sections" [label="no, revise"];
    "User confirms design?" -> "Record design document" [label="yes"];
    "Record design document" -> "Invoke task-planning";
}

最終段階は task-planning の呼び出しです。 ui-engineering やその他の実装スキルを呼び出してはいけません。意図の発見の後に呼び出すスキルは、task-planning のみです。

詳細なプロセス

アイデアの検討：

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

既存のソリューションの調査：

• 必須のサブスキル： godmode:reference-engine を使用して、適切なリファレンスシステムに振り分けます
• reference-engine スキルは、github-search（外部リポジトリやライブラリ）、codebase-research（内部のコードベースパターン）、design-research（ビジュアルテーマ）、ux-patterns（UI）、または組み込みライブラリ（API、スキーマ、テスト、CI/CD、インフラ）に振り分けます
• 調査結果を要約します：「[参照元]から参照情報が見つかりました：[関連する内容]」
• 提案に調査結果を反映します。どのリファレンスを基にするか、活用するか、調査するかを示します

アプローチの評価：

• トレードオフを添えて、異なるアプローチを2～3案、A、B、Cの選択肢として提示します
• 推奨案には星印（⭐）を付けます
• 推奨案を最初に示し、その理由を説明します
• 調査結果を引用します：「アプローチAは github.com/x/y（スター5k、MITライセンス）に着想を得ています」
• YoloMode が有効な場合： すべての選択肢を提示したうえで、ユーザーの選択を待ちます。アプローチを自動選択することはありません。

設計の提示：

• 設計が明確になったと判断したら、設計を提示します
• 各セクションの分量は複雑さに応じて調整します。単純な内容は数文、微妙な点を含む内容は200～300語程度にします
• 各セクションの後に、ここまでの内容に問題がないか確認します
• アーキテクチャ、コンポーネント、データフロー、エラー処理、テスト戦略を扱います
• 不明点があれば、再検討して明確にする準備をしておきます
• YoloMode が有効な場合： 設計全体を一度に提示し、セクションごとの確認を挟まずに記録へ進みます。ユーザーは推奨案を信頼しています。

設計の承認後

ドキュメント作成：

• 検証済みの設計を docs/plans/YYYY-MM-DD-<topic>-design.md に記述します
• 設計ドキュメントをバージョン管理にコミットします

実装：

• task-planning スキルを呼び出し、詳細な実装計画を作成します
• 他のスキルは呼び出さないでください。次のステップは task-planning です。

ガードレール

決して行わないこと：

• 「簡単な」作業だからと設計を省略しません。単純な作業ほど、前提が隠れています
• 依頼を受けてすぐにコーディングに進みません
• 1つのアプローチだけを提示しません。必ずトレードオフを添えて2～3案を示します
• ユーザーの承認を形式的な確認として扱いません。フィードバックを実際に反映します
• 設計ドキュメントを作成してコミットする前に、実装を始めません

必ず行うこと：

• トレードオフと明確な推奨案を添えて、2～3案を提示します
• 次に進む前に、設計の各セクションについてユーザーから明示的な承認を得ます
• 設計ドキュメントを docs/plans/ に作成し、コミットします
• 次のステップとして task-planning を呼び出します（実装スキルは呼び出しません）
• 設計の深さは複雑さに応じて調整します。単純な場合は簡潔に、複雑な場合は綿密にします

基本原則

• 質問は一度に1つ - 複数の質問でユーザーを圧倒しないようにします
• 選択式を優先 - 可能な場合、自由回答式よりも回答しやすい形式を選びます
• YAGNI を徹底する - 設計から不要な機能を取り除きます
• 代替案を検討する - 決定する前に、必ず2～3案を提示します
• 段階的に検証する - 設計を提示し、次に進む前に承認を得ます
• 柔軟に対応する - 筋が通らない点は再検討し、明確にします

接続

このスキルは、より広範な GodMode ワークフローの一部です。

• task-planning -- intent-discovery の後に進む唯一の次のステップです。検証済みの設計を、実行可能な実装計画に変換します。
• reference-engine -- 設計に関連するリファレンス実装、テーマ、UX パターン、組み込みライブラリを見つけるため、intent-discovery の実行中に呼び出されます。
• github-search -- ゼロから構築する前に、既存のオープンソース実装、ライブラリ、パターンを見つけるため、調査中に使用します。
• codebase-research -- reference-engine が、内部のコードベースにあるパターン、規約、類似の実装を見つけるために使用します。
• specification-first -- 正式な仕様を必要とするプロジェクトでは、ここで作成した設計ドキュメントを仕様駆動型ワークフローに活用します。