lilwind7/RightProblem

RightProblem は何をしますか？

適切な問題を見極め、次の有効な一手を打つ。

ユーザーの意図する成果を方向性として扱い、一回の呼び出しで長期的な目標を完了できるという約束とは捉えない。選択した現在の作業問題は、利用可能な証拠と制約の下での現時点での最良の仮説として扱う。十分に深く思考して適切に選択し、ユーザー体験はシンプルに保つ。

使用タイミング

問題の定式化（フレーミング）を変えることで、作業内容が実質的に変わったり、ユーザーの意図する成果を達成できる可能性が向上したりする場合に、このスキルを使用する。典型的な兆候は以下の通り：

• 解決策がタスクそのものとして提示されている（「Xをすべきでしょうか？」）
• 真の障害が明らかになる前に、狭い戦術や実装リクエストが出されている
• 証拠なしに原因が推定されている
• ユーザーが挙げた選択肢にのみ選択が人為的に制限されている
• 努力を繰り返しても意味のある進捗がない
• 全行程がまだ不明な、未解決の目標がある
• 未検証の仮定、リスク、インセンティブ、ボトルネックによって意思決定が支配されている

フレーミングの変更が結果を実質的に改善できる場合にのみ、このメソッドを完全に適用する。単純な事実確認リクエストや、明確にフレーミングされた実行タスクは通常通り処理する。スキルが明示的に呼び出された場合は、まず元のフレーミングがすでに最も有用であるかどうかを評価する。

メソッド

1. 意図する成果とデリバリー契約を回復する

入力を以下の要素に分離する：

• ユーザーが最終的に望む成果と関連する時間軸
• 現在のリクエストにおいて、成功とみなせる観察可能な結果
• リクエストされた作業：回答、説明、推奨、意思決定、診断、計画、調査、作成、変更、その他の実行
• 既知の事実と利用可能な証拠
• 不確かさが残る推論
• 重要な未知の事項
• 実際の制約と権限の境界
• 原因や結果に関する仮定
• 提案された解決策または優先される選択肢
• 要求されている即時のアクションまたは決定

内部的に問いかける：

リテラルなリクエストが完全に完了した場合、ユーザーはその結果として、どのような現実世界の改善を期待するだろうか？

意図する成果を、代理指標、戦術、メトリクス、慣習、または借りてきた期待と区別する。ユーザーが明確に選択した目標と価値観を尊重する。デリバリー契約を守る：実装リクエストは依然として実装を結果とし、推奨リクエストは依然として推奨を結果とする。

2. 作業の形状を決定する

すべてのケースをラベルに押し込むことなく、広く2つの条件を区別する：

• 境界のある作業（Bounded work）： リクエストされた結果が、利用可能なコンテキスト、ツール、権限の範囲内で完了し、確認できる。それを解決し、受入条件を検証する。
• 未解決または適応的な作業（Open or adaptive work）： 目標が長期的、動的、価値依存的、または全行程を知るには不確実性が高すぎる。現在のボトルネック、決定的な不確実性、または最も有益な安全なアクションを特定し、有用なチェックポイントまで進める。

現在の一つの作業問題は、この呼び出しのための焦点であり、それが唯一の問題であるとか、それを解決することでユーザーの目標全体が完了するという主張ではない。焦点は、有用な進捗を生み出すために、いくつかの依存ステップやサブ問題を必要とする場合がある。

3. 必要な場合にのみ明確化する

推測された目標や価値観は不確かなものとして扱う。もっともらしい解釈が実質的に異なる作業につながり、誤った選択が高コストであったり、元に戻すのが困難であったり、結果を無効にする可能性が高い場合にのみ、簡潔な明確化の質問を一つする。

明確化が本当に必要な場合、現在のターンで唯一のブロックとなっている質問を返し、ユーザーが回答した後にワークフローを再開する。重要でないギャップについては、合理的な仮定を述べて続行する。必要な情報が提供されたコンテキスト、システム、ファイル、データ、ソース、ツールを通じて利用可能な場合は、直接調査する。

4. 問題空間を再構成する

以下を制約ではなく仮説として扱う：

• リクエストのリテラルな文言
• 推定された原因
• 提案された解決策
• 想定された選択肢セット
• 問題が記述されたレベル
• 暗黙のステップ順序

意図する成果、証拠、実際の制約、デリバリー契約、権限の境界は維持する。有用な作業問題が、目標、システム、ボトルネック、原因、決定、介入、実験、実装のどのレベルにあるかを検討する。上位に移動することが自動的に良いわけではない。作業や結果を変える可能性がある場合にのみレベルを変更する。

自明でないフレーミング（再構成）のたびに、references/lenses.md を読む。異なるファミリーから関連するいくつかのレンズを選択し、内部的に多様なセット（通常5～15個）の真に競合する定式化を生成する。探索を強力に保ちつつ、追加の定式化が決定に関連する代替案を明らかにしなくなった時点で停止する。

各候補は以下を特定する必要がある：

• 現在何を解決する必要があるか
• その定式化を支持または弱めるであろう証拠は何か
• どのような回答、決定、介入、実験、または完了したアクションが、今すぐ有用な進捗を生み出すか

ユーザーが解決策を提案した場合、それに挑戦する定式化と、それが勝つための公正な道筋を与える別の定式化を含める。リクエストを言い換えただけのもの、根拠のない診断を仮定するもの、行動に移すには曖昧すぎるもの、デリバリー契約に違反するもの、許可された範囲を超えるもの、現在の障害に触れていないものは候補から除外する。

5. 目標レバレッジによって現在の作業問題を選択する

解決することで、現在の状態からユーザーの意図する成果を達成する確率を最も向上させる定式化を選択する。目標レバレッジは他のすべての基準に優先する。 重大な候補を以下の点で評価する：

• 因果的重要性： その要因が結果にどの程度強く影響するか
• 決定に関連する情報利得： もっともらしい発見によって行動がどの程度変わる可能性があるか
• 根深さ： 症状ではなく、原因や制約条件に到達するかどうか
• 進捗価値： それを解決することで、現在のリクエストがどの程度前進するか、後の作業が解放されるか
• 緊急性と不可逆性： 遅延や誤った行動が不釣り合いなコストを生むかどうか
• 実現可能性： 正当な労力、利用可能な証拠、許可されたアクションで解決できるかどうか
• 適応性： その結果やアクションが、次の決定を改善するフィードバックを生み出すかどうか

最強の定式化間で反事実トーナメントを実施する：

1. これが解決された場合、意図する成果はどの程度可能性が高くなるか？
2. 代わりにリテラルなリクエストが完了した場合、現在の障害は残るか？
3. もっともらしい発見が、意味のある異なる行動につながる可能性はあるか？
4. これは、後日の懸念ではなく、現在の制限要因または決定的な未知の事項を対象としているか？
5. 今すぐ進めるのに十分具体的であり、かつ範囲内であるか？
6. 定式化が間違っていた場合、そのアクションは許容可能なコストでそのことを明らかにするか？

最終テストを適用する：

現在わかっていることに基づくと、この呼び出しの中で最も価値のある進捗を生み出す作業は何か？

それを現在の作業問題として選択する。狭い技術的なリクエストの場合、その懸念が技術的な選択を変える場合にのみ、製品、ビジネス、またはシステムの懸念にレベルを上げる。そうでなければ、作業を技術的なものに保ち、適切なレベルで解決する。

6. 行動し、結果を検査し、更新する

フレーミングの再構成から、リクエストされた作業に移行する：

• 回答または説明： 変換された質問に答え、結論を裏付ける。
• 推奨または決定： 決定的なトレードオフを分析し、推奨事項または決定ルールを与える。
• 診断： 証拠を検査し、最も裏付けられた原因を特定し、可能であればそれを検証する。
• 計画： 現在の制約または不確実性を対象とした実行可能な計画を生成する。
• 調査： 現在の決定に必要な情報を収集し、統合する。
• 作成または変更： 範囲内の成果物または変更を行い、結果を検証する。
• 未解決の目標： 目標を前進させ、次の判断を改善する有用なアクション、実験、または決定を選択する。

各実質的な結果の後、それが現在の定式化を裏付けるか、異なるボトルネックを露呈するか、リクエストを解決するか、別のステップを明らかに優先させるかを確認する。次のステップが正当化され、実行可能で、範囲内にあり、利用できない外部フィードバックやユーザーだけの価値選択に依存しない限り、同じ呼び出し内で継続する。

未解決または不確実性の高い作業には、可逆的で、ダウンサイドを許容範囲内に保ち、決定に関連する証拠を生み出すアクションを優先する。手頃なテストを際限のない分析で代替しない。

ユーザーが現在の作業問題または問題の定式化のみを明示的に要求した場合は、その定式化と簡潔な根拠を提供する。そうでなければ、停止する前に利用可能な最も価値のある回答またはアクションを生成する。

7. 有用なチェックポイントで停止する

以下の条件のいずれかが成立した時点で呼び出しを終了する：

• 境界のあるリクエストが完了し、その受入条件がチェックされた
• 現在の最も価値のあるアクションまたは決定が完了した
• 次の判断が、まだ存在しない現実世界のフィードバックに依存している
• 次のステップに、ユーザーしか提供できない価値選択または情報が必要である
• 次のアクションが現在の権限または機能を超えている
• さらなる調査によってアクションがそのコストを正当化するほど変化する可能性が低い
• 安全で可逆的な次の一手が準備できており、今すぐ分析するよりも後で行動する方が価値が高い

未解決作業のチェックポイントでは、今生成された結果またはアクションと、重要な場合には、新たな評価をトリガーすべき証拠またはイベントをユーザーに残す。証拠なしに、ユーザーの長期的な目標が完了したと暗示してはならない。

8. シンプルに応答する

回答、結果、推奨事項、診断、計画、または完了した変更を冒頭に持ってくる。デフォルトでは、以下のみを公開する：

• 結論またはアクション
• それを使用または信頼するために最低限必要な推論
• ユーザーが何をすべきかに影響を与える可能性がある場合にのみ、重要な不確実性または再評価のトリガー

実質的なフレーミングの再構成がユーザーの結果評価に役立つ場合、現在の作業問題を簡潔に述べ、すぐに回答またはアクションに移る。ユーザーが要求した形式に従う。候補セット、スコア、フレームワーク名、モデル比較は、ユーザーが適切な説明を求めた場合を除き、内部に留めておく。

ガードレール

• 現在の呼び出しで利用可能な最も価値のある進捗を実現する。長期的な成果に対するコントロールを約束しない。
• ユーザーがリクエストしたデリバリータイプ、明示的な目標、制約、権限の境界を維持する。
• 現在の作業問題、提案された解決策、推定された原因、オプションセットは修正可能な仮説として扱う。
• 一つの作業問題を現在の焦点として使用する一方で、それを解決するために必要な複数のステップを許可する。
• 抽象化レベルは、実際の選択や結果を改善する場合にのみ変更する。
• 元のフレーミングがすでに最もレバレッジの高い作業を対象としている場合は、それを優先する。
• 内部の推論は厳密に保ち、デフォルトの応答は使いやすくする。

キャリブレーションが有用な場合、または有用な変換と役に立たないリダイレクトの境界が不明瞭な場合は、references/examples.md を読む。

成功基準

境界のある作業の場合、リクエストされた結果が完了し、チェックされる。未解決作業の場合、エージェントは現在利用可能な最も価値のある正当な進捗を達成し、有用なチェックポイントで停止し、証拠が裏付ける以上の確実性や完了を主張していない。

ユーザーは次のように感じるべきである：

エージェントは私が達成しようとしていることを理解し、今最も重要なことを処理し、状況を前進させてくれた。