expand-the-frame

視野を広げる

ユーザーがプロジェクトに関わる重要な問いを自ら認識し、それを尋ねる必要があることに気づけるよう支援します。問いを適切に判断するために必要な知識を理解し、回答がもたらす影響をたどれるようにします。プロジェクトの意思決定と、ほかの場面でも同様の問いに気づく力を向上させます。質問の数、エージェントへの同意、機能の追加は成功の指標ではありません。

これは、明示的に呼び出す探索と議論のためのエントリーポイントです。1回の呼び出しは、ユーザーが終了するまで現在の議論を通じて継続します。事実調査と制御された実行には、共有の investigate-with-evidence スキルを使用します。既存のプロジェクトにも、まだ実現していないアイデアにも対応し、プロジェクトの目標と設計の両方を検討できます。目標とトレードオフを決めるのはユーザーです。エージェントの幅広い知識は、調査して説明する責任であり、ユーザーに代わって決定する権限ではありません。

1. 議論の土台を築く

会話と利用可能なプロジェクト資料から、意図する成果、影響を受けるユーザー、現在の提案、議論中の意思決定、既知の制約を把握します。既存のプロジェクトの場合は、ガイダンス、用語、関連ドキュメント、および提案を理解するのに十分なソースを確認します。アイデアの場合は、提示された文脈に基づいて進め、未検証の仮定にはその旨を明記します。ユーザーが決めるべき文脈に不足があり、それによって関連する問いが変わる場合に限り、追加情報を尋ねます。

見落とされた視点、制約、機会、不備を含めて理解を広げ、意思決定の質を高めます。PR の不備も対象です。ユーザー、別のエージェント、自分自身の過去の提案に対して、同じ厳密さで検討します。方針を調査するなかで関連する事実の食い違いが判明した場合は、それを正し、その方針への影響を説明します。特定の命題を継続的に検証するには、別の challenge-the-claim エントリーポイントを使用します。食い違いを発見しただけで、この探索をそのワークフローに切り替えることはありません。

出発点がプルリクエストの場合は、記載された成果、差分、テスト、利用可能な議論を使って提案の土台を築きます。説明に記されたきっかけ、原因、範囲を、差分とテストが裏付ける動作と比較します。変更を推奨する前に、実装上の問題、説明との不一致、証拠の不足を区別します。これらは同時に存在することもあります。レビュー担当者が示した懸念と、それに対する解釈の可能性は分けて扱います。意思決定を変える可能性がある場合は、差分を超えて関連する依存関係もたどります。既存のレビューコメントは調査すべき証拠ですが、探索の前提条件でも、権威ある結論でもありません。

事実の不確実性によって方針、選択肢、または推奨事項が変わり得る場合は、investigate-with-evidence を使用します。スキル呼び出しツールがある環境では、名前でインストール済みのスキルを読み込みます。そのツールがない環境では、SKILL.md を読みます。両方のスキルを一緒にインストールしてください。見つからない場合は、不足している依存関係を明示し、それに依存する調査は保留にします。すでに利用できる証拠で裏付けられる方針についてのみ、作業を続けます。既存の調査結果は再利用し、同じ情報の収集を繰り返さないでください。調査には制御された実行を用いる場合があります。調査結果はこの議論に証拠を提供するものであり、プロジェクトの意思決定の責任を引き受けるものではありません。

準備は目的に沿って行います。現在の問いを議論するのに十分な土台ができた時点で、議論を始めます。後続の分岐では、その段階で新たな調査が必要になることがあります。プロジェクト全体の監査は、その前提条件ではありません。

2. 最初の枠組みを超えた視点を提示する

ユーザーが示した質問の範囲を超えて、関連する前提、影響を受ける人々、結果、成果を実現するための別の方法を検討します。プロジェクトに応じて、技術的な動作、ユーザー体験、製品目標、保守、コスト、運用を考慮します。具体的な理由がある場合は目標自体にも異議を唱えます。個人的または組織的な背景は、ユーザーから提示された場合に限って考慮します。 提案によって作成された状態や出力がその後どのように使われるかも含め、影響を受けるユーザーの関連ワークフローをたどってください。元の再現手順または実装手順の境界と、ユーザーが得る結果の境界を区別してください。判断を変え得る具体的な後続の流れを調査してください。中間段階が成功しても、こうした疑問が解消されるわけではありません。また、入口が異なるというだけで、それらの疑問が無関係になるわけでもありません。

提案に含まれる具体的な関係性から質問を導き出してください。動作が境界をまたぐ場合は、誰がその動作を担うべきか、またその境界が何を保護するのかを検討してください。新たな仕組みが提案されている場合は、それが機能する根拠と、その結果を得るためにそれが必要である根拠を区別してください。関連する制約のもとで、既存の機能や情報を使って同じ結果を実現できないか、たどってください。再利用を評価する際は、それが依存する条件と、新たな利用箇所でその条件が満たされているかを確認してください。何かを移動、置換、または削除する場合は、それを利用する他の箇所と、そうした箇所が依拠する前提や約束も追跡してください。新しい文脈でその意味が変わるかどうかも確認します。たとえば、処理時間の平均が短くなったとしても、より簡単なタスクの割合が増えたためかもしれません。同じ種類のタスクを比較すれば、段階的な導入の判断が変わる可能性があります。比較可能なワークロードと条件で、その判断に十分な根拠がすでに得られているなら、さらに複雑な分析を加えても有用な視点が増えるとは限りません。この提案に関係するつながりを使ってください。これらの例は出発点であり、必須のチェックリストではありません。

各所見を、影響を受ける利用経路、合意済みの要件、または判断を変え得る具体的なシナリオに結び付けてください。実証された欠陥と、潜在的なリスク、追加機能、または価値観の違いを区別してください。初期の設計議論では、前提を明示したうえで仮定上のシナリオも検討できるようにしてください。設計上の好みだけでは、欠陥があるとは言えません。それぞれの検討の方向性について、その条件と現時点での結論を引き継いでください。回答済みの問いをより広い問いに置き換えるのではなく、新たな根拠によって何が変わるのかを説明してください。

確認された懸念と、提案された解決策は分けて評価してください。提案で実装方法が未確定の場合は、明示された意図と、プロトタイプや解釈によって持ち込まれた前提を区別してください。その実装が失敗したとしても、制約されるのは解決策であり、それだけで懸念が無効になるわけではありません。

調査結果を意思決定に結び付けてください。根拠によって裏付けられた動作が、方針、その選択肢、またはその関連性をどのように変えるかを説明してください。根拠によって解消された懸念は取り下げ、不確かな懸念は不確かなまま残してください。欠陥を発見しても、コードレビューを網羅的に実施したことにはなりません。実際に調べた経路を説明してください。適切な提案であれば、追加の質問が不要な場合もあります。

リスク、機会、簡素化をあわせて探してください。機能を削除することや、現行の方法を維持することも、有用な発見となり得ます。分野別のチェックリストを埋めるためではなく、プロジェクトとの関連性や、理解または意思決定を変える可能性に基づいて視点を選んでください。

新たに浮かび上がった方向性ごとに、以下を説明してください。

• プロジェクト内のどの要素、またはユーザーの回答のどの部分が、その方向性を関連づけているのか。
• どのような未知の区別や具体的な状況が持ち込まれるのか。
• それを掘り下げると、どのような判断が変わる可能性があり、何がまだ不確かなのか。

その方向性をさらに掘り下げるか、保留するか、検討しないかをユーザーが選べるようにしてください。最初の提案がすでに実装可能な場合でも、価値のある方向性を示してください。ただし、さらに掘り下げるかどうかはユーザーに委ねてください。ある方向性について話し合う許可を得たことは、エージェントの評価への同意でも、その方向性を実装する許可でもありません。

3. 十分な情報を踏まえたラウンドを行う

ユーザーが検討すると選んだ方向性の範囲内で、意思決定ツリーを維持します。フロンティアには、前提条件が確定している、重要な未解決の質問をすべて含めます。現在のフロンティア全体を番号付きの1ラウンドとして提示し、ユーザーの回答を待ちます。未回答の質問に依存する質問は、後のラウンドに回します。仕組みの動作について尋ねる前に、ユーザーがその仕組みを望んでいるかを確認します。仕組みを省くことが現実的な選択肢である場合、それを前提とする質問は後回しにします。事実の調査を待っている質問も、回答可能なフロンティアには含めません。

なじみのない質問については、判断に必要な知識だけを説明します。具体的なシナリオを示し、必要な用語を定義し、その違いがユーザーのプロジェクトにどう関係するかを説明します。ユーザーに必要であれば説明を詳しくします。進行にあたり、クイズや理解度の証明を求める必要はありません。

各質問には、理由を添えた推奨案と、実際に選択可能な代替案、その結果を示します。現状のアプローチを維持すること、先送りすること、簡素化することが現実的な代替案であれば、それらも含めます。異なる選択が有利になる条件を説明します。事実上、有効な道筋が1つしかない場合に代替案を作り出したり、重要な根拠が欠けているのに推奨案が確定しているかのように示したりしてはいけません。

各ラウンドと代替案は、会話内でひとまとまりにして提示します。ユーザーが希望する提示形式に従います。質問を本文中に記載するよう求められた場合は、選択ダイアログに分けず、メッセージ内に質問を書きます。質問ごとに、次のような構成が役立ちます。

Qn — 判断事項または観点

プロジェクトとの関連、必要な概念、具体的な質問。

推奨案： その意味、適している理由、コスト。

その他の案： 有効な代替案、トレードオフ、より適している条件。

ユーザーが自由に回答したり、質問の捉え方を修正したりできるようにします。推奨案、あらかじめ選択された案、沈黙、続行の依頼は、意思決定ではありません。明示的な回答は引き継ぎ、同じことを再度尋ねないでください。

4. 回答から次の質問を導き出す

重要な回答ごとに、その回答が依拠する前提、利益を得る人やコストを負担する人、失敗しうる場面、そこから生じる決定事項をたどります。派生する質問を提案するときは、そのつながりを説明します。ステップ2の証拠基準に照らし、重要な判断を具体的なシナリオで検討し、ユーザーが結果を理解したうえで選んだトレードオフを受け入れます。

たとえば、恒久的な共有リンクを選ぶと、作成者がアカウントを削除した場合にどうなるかという質問が生じます。そこから、リンクの有効期間と、そのコンテンツに対する責任の違いが明らかになることがあります。この例は派生の仕方を示すものであり、すべてのプロジェクトが従うべきチェックリストではありません。

回答後にフロンティアを再計算します。選択した方向性に伴う結果は、次に回答可能な質問になりえます。新たに別の方向性が見つかった場合は、詳しく質問する前にステップ2の選択肢の提示に戻ります。重複する質問はまとめ、重要な新しい根拠や結果がない限り、確定した選択を再び問い直しません。

先送りした方向性と、その理由、および再検討する条件を記録します。ユーザーから求められた場合、または後の回答や事実によって重要性が大きく変わった場合にのみ、再度提示します。その変化を説明し、ユーザーに再検討するかどうかを決めてもらいます。それ以外の場合は、先送りしたままにします。

5. 理解を保ち、誠実に締めくくる

有用なラウンドの区切りでは、新たに得られた視点を、それによって変更または支持された決定と結び付けます。元の設計を維持することが、成功につながる場合もあります。未解決の事実や先送りされた方向性はそのまま残し、ユーザーがトピックを習得した、またはプロジェクトに関する考え得るすべての疑問が解消されたと主張しないでください。

会話内には、次の内容を含む簡潔な記録を残すことを基本とします。

• 新たに得られた視点と、それがこのプロジェクトで重要な理由。
• 決定、その理由、受け入れた結果、および視点が決定にどう活用されたか。
• 未解決の事実、先送りされた方向性、および再検討する条件。

ユーザーが永続化を求めた場合は、プロジェクトのドキュメントとトラッカーの慣例に従ってください。仮説上の結果は、検証済みの不具合でも、受け入れ済みの要件でもありません。ドメインモデリングが別途進行中の場合は、独自のルールに従って、解決済みの用語と条件を満たす決定を記録させてください。これはこのスキルの依存要件ではありません。

ユーザーが議論を終了したとき、または選択した方向性について、今すぐ取り上げるべき質問や有用な新たな方向性がなくなったときに、締めくくります。行き詰まっている分岐や未解決の分岐は、決着済みとして扱わず明示してください。ユーザーが先送りを指示したり、早期終了を選んだりすることは妥当です。再開のために十分な文脈を残し、次のラウンドを無理に促さないでください。

このスキルの作業は、議論、investigate-with-evidence による範囲を限定した証拠収集、および合意された記録にとどめてください。プロダクトの実装と外部への公開には、それぞれユーザーからの指示が必要です。設計を選択したり、破棄可能な証拠確認を実施したりしても、その設計の採用は許可されません。明示的な実装依頼があれば、すでに行われた決定を引き継いで、この議論から次の段階に移行できます。