explore-unknowns

不明点を探る

地図は現地そのものではありません。プロンプト、計画、コンテキストウィンドウは地図であり、コードベース、ドメイン、ユーザーの実際の意図は現地です。その隔たりが不明点です。コードを書く前に見つかった不明点の解消には数分で済みますが、同じ不明点を PR を3つ進めた後に見つけると、その3つの PR 分のコストがかかります。

このスキルは、四象限をたどるガイド付きの対話です。ユーザーと一緒に、タスクを四つの象限に分けたマップを各段階で一つずつ埋めていきます。ユーザーは完成したマップを手にして対話を終えます。成果物はマップです。実装は別のタスクであり、マップを渡してから始めます。

すべての段階で、次の二つの進め方を適用します。

• 想像してもらうより、反応してもらう。 具体的なものを提示して反応してもらえるなら、ユーザーに希望を説明してもらう質問はしないでください。たとえば、レンダリングした選択肢、クリックできるモック、決定事項の表などです。反応してもらうことで、ユーザーが持っていても自発的には言葉にできない知識を引き出せます。
• すべての成果物に返信の下書きを組み込む。 各成果物の最後には、ユーザーが次に送るメッセージの下書きを用意します。たとえば、採用／スキップのチップ、共感する項目のチェックボックス、決定事項の表、コピー可能なブラッシュアップ済みプロンプトなどです。そうすれば、ほとんど入力しなくても反応を次のメッセージにできます。

四象限をたどる

五つの段階を、一度に一つずつ順番に進めます。段階に入ったら、その参照ファイルを読み、指示に従ってください。 進行中は現在の象限を明示します。ユーザーがマップ上のどこにいるか常にわかるようにし、目の前の段階を終えてから次に進みます。

1. 既知の既知 — 現地を調べてから、確定している事項から始めます。
2. 既知の未知 — 名を挙げられる疑問を、一つずつ解消します。
3. 未知の既知 — 誰も言葉にしていない好みや暗黙のコンテキストを引き出します。
4. 未知の未知 — 現地をくまなく調べ、落とし穴を探します。
5. マップを渡す — 完成した四象限のマップです。これが、この対話を完了とする唯一の条件です。

ユーザーが、この対話でマッピングした内容の構築、レビュー、またはマージに進むときは、対話の後を読んでください。計画の後もマップは役に立ちます。

設定の確認ポイント — 代わりに回答することを提案する

ユーザーがウォーク全体で回答した質問の数を数えます。ターン数やテリトリー内で見つかった回答の数ではありません。およそ5、6問を終えた時点で、ユーザーの好みに明確な傾向があり、まだ質問が残っている場合は、インタビューをいったん止めてこの確認ポイントに進みます。傾向がまだ明確でなければ、対象を絞った質問を続け、明確になった時点で一度提案します。数に達するためだけに質問を作ってはいけません。

1. 回答に基づいて推測した好みを列挙し、訂正を促します。それらに沿った質問にあなたが代わりに答えると役立つかどうかを尋ねます。好みを確認または編集して委任に同意するか、自分で回答を続けるかを選んでもらいます。これにより、次のインタビュー質問に代えます。
2. 明示的に同意されるまで待ちます。好みを確認しただけでは委任への同意にはなりません。沈黙も同意ではありません。好みだけが確認された場合は、委任するかどうかを一度確認し、回答がなければインタビューを続けます。断られた場合は、繰り返し提案せずに続けます。
3. 同意を得たら、確認済みの好みから明確に導ける質問に、委任された範囲内で回答します。好みが相反する場合や、新たなトレードオフが委任範囲を外れる場合は、ユーザーに尋ねます。情報が不足している場合は、まずテリトリーを調べます。そこで解決できない場合にのみ尋ねます。好みをテリトリーに関する事実の代わりにしてはいけません。
4. 委任した回答は、その都度すべて開示します。質問 → 回答 → 好みと理由の順に記し、エージェントが代わりに回答とラベルを付けます。少数ずつ回答して構いません。異なる質問を隠れた判断にまとめてはいけません。各項目にはその帰属を付けたままマップに記録し、ユーザー本人が回答したかのように示してはいけません。すべての回答の承認を求めずに、訂正を促します。
5. 訂正や委任の撤回には直ちに従います。訂正があれば好みの要約を更新し、その訂正によって無効になる判断を再び検討します。撤回されたら、それ以降の委任回答を停止します。ユーザーから見直しを求められない限り、それまでの回答は委任によるものとして記録し続けます。委任はこのウォーク中に限られ、実装を許可するものでも、残りのクアドラントを省略するものでもありません。

完了条件：ユーザーが委任するかどうかを選び、委任に同意した場合は、確認済みの好みと委任範囲が、マップの判断記録と併せて記録されていること。

ルール

• クアドラントを順番に、各段階を一つずつ進め、現在のクアドラントを明示します。マップをユーザーに渡して初めてウォークは完了です。マップがなければ完了ではありません。
• 段階はウォークの順序を定めるものであり、情報の開示を禁じるものではありません。進行中の判断に実質的に関わる発見があれば、判明した時点で開示し、その後マップの該当クアドラントに記録します。予定された段階まで開示を保留してはいけません。
• 画面外で決定を確定してはいけません。マップに確定事項として記録する質問や判断は、テリトリーから答えが得られたものも含め、すべて事前にユーザーに示す必要があります。
• 議論ではなく決定として項目を確定します。解決した不明点は、それぞれ一行の決定とその理由で締めくくり、仕様に確定事項としてそのまま記載できる表現にします。ビルダーが後から監督なしに決めることになる選択肢は、ウォークで見落とした不明点です。実装者に判断を委ねるマップは不完全です。
• テリトリーに関する主張には、実際に読んだ実在のファイルを引用します。創作したデータは創作であると明記します。具体的な情報を捏造すると、マップの信頼性が損なわれます。
• HTML の成果物は、CSS／JS をインラインにした自己完結型の単一ファイルにします。外部へのリクエストは使わず、lorem ipsum ではなく、もっともらしい架空のデータを使います。
• ユーザーの反応が必要な各段階の境界で必ず止まります。確認されていない推測に基づいて実装へ進んではいけません。実装は別のタスクであり、マップの提出後に始まります。