未知を発見する（Find Your Unknowns）
概要
ユーザーによるタスクの説明（プロンプト、コンテキスト、参照情報）と実際の作業（コードベース、制約、現実）との間のギャップこそが、未知の領域（unknowns） の存在する場所です。エージェントが未知の領域に直面すると、ユーザーの意図を推測することになります。このスキルの目的は、推測を排除することです。ユーザーが実装の 前、最中、後 にわたって反復的に、一度きりの事前計画ではなく、自分の未知の領域を発見し名前付けできるよう支援します。
これはツールボックスであり、固定のパイプラインではありません。まず診断し、次に適合するテクニックのみを適用してください。簡単なタスクにすべてのテクニックを適用しないでください。
4種類の未知（The Four Unknowns）
テクニックを選択する前に、何が不足しているかを分類します。
- 既知の既知（Known knowns） — プロンプトですでに述べられていること。
- 既知の未知（Known unknowns） — ユーザーはまだ決定していないことを認識している。
- 未知の既知（Unknown knowns） — 書くまでもなく明白だが、ユーザーは見れば認識できること（多くの場合、視覚的/UXの好み）。
- 未知の未知（Unknown unknowns） — これまで考慮されたことがなく、ユーザーは自分が何を知らないのかを自覚していない。
ステップ0 — 診断（Diagnose）
何かを行う前に、どの未知の領域が支配的かを判断し、それに応じてテクニックを選択します。
- 馴染みのないドメインやコードベースの馴染みのない部分 → ブラインドスポットスキャン（未知の未知）。
- 説明が難しく、「見ればわかる」タイプ → プロトタイプ（未知の既知）。
- 方向性は明確だが詳細が曖昧 → ユーザーインタビュー + 計画草案（既知の未知）。
常にユーザーが誰であり、何をすでに知っているかについてのコンテキストを提供してください。これにより、以下のすべてのテクニックがより効果的になります。
他のスキルへのハンドオフ（Hand Off to Other Skills）
このスキルは発見レイヤーとして使用し、ワークフロー全体として使用しないでください。未知の領域を特定した後は、次の不確実性を解決する最小のフォローアップスキルを選択してください。
| 未知の領域または次のニーズ | ハンドオフ先 | 使用するタイミング |
|---|---|---|
| ユーザーが意図を完全に表現していない | interview-me | 基礎となるニーズが明確になるまで、一度に1つの質問をする。 |
| 計画にストレステストが必要 | grill-me または grill-with-docs | 前提条件をストレステストする。ADRや用語集の更新を記録する必要がある場合はドキュメントバリアントを使用する。 |
| 外部の事実が不足している | research または source-driven-development | 決定する前に一次情報の証拠を収集する。 |
| ユーザーは見ればわかるタイプ | prototype | 実装にコミットする前に、偽のデータを使って具体的なオプションを示す。 |
| 作業に正式な仕様が必要 | spec-driven-development | 発見された制約と決定事項をPRD/仕様書に変換する。 |
| 作業が大きすぎて直接実行できない | planning-and-task-breakdown または writing-plans | 調整された仕様を順序付けられた検証可能なスライスに分割する。 |
| インターフェース境界が不明確 | api-and-interface-design または design-an-interface | API、モジュール、または型の契約を決定する。 |
| コードベースの形状が不確実 | codebase-design または improve-codebase-architecture | 適切なモジュール境界、抽象化、またはリファクタリングの方向性を見つける。 |
| UIの動作やビジュアル品質が不確実 | frontend-ui-engineering | 選択されたプロトタイプや好みを本番UI作業に変換する。 |
| バグは存在するが原因が不明確 | systematic-debugging または diagnosing-bugs | 再現、分離、仮説立案、計装、修正を行う。 |
| 実装が独立したタスクに及ぶ | subagent-driven-development または dispatching-parallel-agents | タスクが状態や順序依存関係を共有しない場合にのみ作業を分割する。 |
| 作業が完了したように見える | verification-before-completion、requesting-code-review または code-review | 証拠を検証し、完了またはマージを主張する前にレビューを実施する。 |
ハンドオフする前に、以下を要約します。
- 現在判明していること。
- まだ未知のままであること。
- 実装を変更する可能性のある決定。
- 引き継ぐべきアーティファクト：プロトタイプ、仕様書、実装ノート、または受入レポート。
フェーズ別テクニック（Techniques by Phase）
各テクニックにはトリガーと、すぐに使用できるプロンプトテンプレートがあります。角括弧で囲まれた部分を適応させてください。
探索（未知を見つける）（Explore）
1. ブラインドスポットスキャン（Blindspot scan） — 馴染みのない領域での最初の一手。
[X]を追加しようとしていますが、このコードベースの[Y]モジュールについてはほとんど知りません。ブラインドスポットパスを実行して、私の「未知の未知」を見つけて説明してください。そうすれば、より良いプロンプトを書くことができます。
2. プロトタイプ（Prototype） — 説明できない場合、見せる。偽のデータを使用し、バックエンドは不要。
実際のアプリに触れる前に、[インターフェース]を模擬したHTMLファイルを偽のデータで作成してください。まったく異なる4つのデザイン方向性を示して、どれが適切か判断できるようにしてください。
3. ユーザーインタビュー（Interview the user） — 残っている曖昧な点を絞り出す。
一度に1つの質問を私に投げかけてください。曖昧な領域をターゲットにし、その答えがアーキテクチャを変えるような質問を優先してください。
計画（意図を調整する）（Plan）
4. リファレンスを示す（Show a reference） — 最良のリファレンスはソースコードであり、スクリーンショットではない。
[パス/ライブラリ]は、私が望む[動作]を実装しています。それを読み、同じセマンティクスを[私たちのスタック]に再実装してください。
5. 計画草案（Draft a plan） — 最も変更される可能性の高い決定を最初に表面化する。
HTML実装計画を書いてください。ただし、私が最も調整する可能性の高い決定（データモデルの変更、新しい型インターフェース、ユーザーに見えるもの）を上部に配置してください。機械的なリファクタリングは最後にしてください — それらは信頼します。
実装（作業中に発生する未知を捉える）（Implement）
6. 随時メモ（Notes as you go） — 新しいセッションを開始し、仕様/プロトタイプを取り込み、次のように指示：
implementation-notes.md を維持してください。エッジケースにより計画から逸脱せざるを得なくなった場合は、保守的なオプションを選択し、「逸脱（Deviations）」セクションに記録して続行してください。
リリース（他者と調整し、理解を検証する）（Ship）
7. ハンドオフ説明資料（Handoff explainer）
プロトタイプ、仕様書、実装ノートを1つのドキュメントにまとめ、チャットにドロップして賛同を得られるようにしてください。先頭にデモGIFを配置してください。
8. 受入クイズ（Acceptance quiz） — 作者の厳格なルール：マージ前には必ず合格すること。
この変更を完全に理解していることを確認したいです。変更のコンテキスト、直感、行われたことを示すHTMLレポートを作成し、最後に私が合格しなければならないクイズを配置してください。
運用ルール（Operating Rules）
- ユーザーの意図を推測しそうになったら、常に一旦停止し、代わりに該当するテクニックを適用してください。
- アーティファクトを連鎖させてください：プロトタイプ → 仕様書 → 実装ノート → 受入レポート。それぞれが次の入力となるため、新しいセッションでもコンテキストが失われません。
- 小さなタスクの場合、
ブラインドスポットスキャン + 計画草案 + 受入クイズでほとんどの価値が得られます。やりすぎないでください。