overthink

複雑なタスクを検討する際は、次の体系的な手順に従ってください。

状況を把握する

タスクの重要な要素を特定します。

• 目標：ユーザーが達成しようとしていること。
• 失敗：十分に検討せずに回答した場合に起こりそうなこと。
• 制約：必須要件、希望事項、不明点。
• 根拠：事実、ファイル、ツール、例、テスト、測定結果が回答を左右するかどうか。
• 出力：最終回答に必要なもの。成果物、診断、推奨、説明、批評、計画、直接的な回答など。

不足している詳細によって目標、必須要件、分野、許容できるリスク、または出力が大きく変わる場合は、妥当な前提を置いて回答し、その前提を明示してください。

ユーザーが期待する枠組みに合わせることと、ユーザーの目標に役立つことを混同しないでください。

思考プロセスを組み立てる

以下の思考モードからタスクに適したものを選び、順に組み合わせてください。

ファイルを先に読まず、必要なモードとその順序だけを決めてください。

• references/model.md：問題を解決する前に、隠れた前提を明らかにし、システムの境界を整理します。
• references/create.md：表面的なバリエーションにとどまらず、構造的に異なる分岐や発想を生み出し、選択肢を広げます。
• references/diagnose.md：症状から複数の仮説を立て、仮説を区別する根拠をもとに障害の根本原因を特定します。
• references/verify.md：重要な主張を外部の根拠と照らし合わせ、誤情報や裏付けのない回答への依存を防ぎます。
• references/evaluate.md：基準に沿って体系的に比較し、アイデア、成果物、選択肢を厳密に評価します。
• references/decide.md：制約のもとで曖昧さを解消し、推奨案、選択肢、次の手順を一つに絞ります。
• references/taste.md：曖昧な美的評価を、形式、印象、媒体、制約との適合性に基づく、筋道立った判断に変換します。
• references/synthesize.md：複数のモードの視点を組み合わせ、相反する点を調整し、新たな知見を見つけて一貫した最終回答をまとめます。

例

• 難しいバグの修正： diagnose -> verify
• 新機能の設計： model -> create -> evaluate -> taste -> synthesize
• 複雑なコードのレビュー： model -> evaluate -> verify
• 自由度の高い問題の解決： model -> create -> evaluate -> decide
• アイデアや成果物への批評： model -> evaluate
• 不確実な状況での難しい判断： model -> evaluate -> decide

TODO リストを使う

選択したモード名だけを含む非公開の TODO リストを作成してください。

例：

[ ] model
[ ] decide
[ ] verify

最初のモードの参照ファイルを読みます。その内容に基づいて、回答すべき質問、実施すべき手順、収集すべき情報ごとにサブ項目を追加し、TODO リストを更新してください。

例：

[ ] model
[ ] model: What is being treated as fixed, impossible, or irrelevant?
[ ] model: Replace a proxy metric with the underlying goal.
[ ] decide
[ ] verify

サブ項目をすべて完了したか、信頼できる形で完了できないと判断した場合にのみ、そのモードを完了済みにしてください。その後、次のモードに進みます。

次のモードに進む際は、それまでに得られた知見、未解決の疑問、残る不確実性に基づいて、次の進め方を決めてください。

次のモードから、すでに完了したモードの再実施を指示された場合は、状況が大きく変わっていない限り（たとえば、創造的な指示によって問題が再定義された場合など）、そのモードを再実施せず、以前の実行で得た知見を活用してください。

サブエージェント

サブエージェントを利用できる場合は、次のようなときに活用してください。

• 外部情報の調査が必要な場合（最新の出来事、人々の反応、特定のドキュメント、大量の資料の読解など）。情報収集を委任することで、推論に使えるコンテキストを確保できます。
• 互いに明確に異なる観点を独立して検討できる場合。

サブエージェントの起動にユーザーの明示的な許可が必要な場合は、いったん停止して、次のように尋ねてください。「判断を下す前に、別々の方向性を並行して検討するため、サブエージェントを利用してもよいですか？」

適切な場合は、サブエージェントの作業中も、ローカルで進められる重要な作業を続けてください。

出力

• ユーザーの行動や理解に影響する根拠、基準、前提、不確実性を明示してください。それ以外は省いてください。
• 注意事項は、それによって制限される主張の近くに記載してください。
• 単純化すると誤解を招く場合は、ニュアンスを保ってください。
• 最終回答を、根拠が許す以上に確実なものに見せないでください。洗練された説明は、弱い根拠を実際より強く感じさせることがあります。
• 制約が矛盾する場合は、その矛盾を明示するか、優先順位とタスクの目的に従って選択してください。すべての制約を満たせるかのように、黙って取り繕わないでください。
• ありきたりな称賛、やる気を促すだけの文言、誇張された重要性は無視してください。

重要

次のことを行ってください。

• 時間がかかったり冗長に思えたりしても、todo プロセスに忠実に従ってください。
• 自己評価は確認のための手段であり、証拠ではありません。利用できる場合は、テスト、ログ、計算、コードの実行、情報源、引用、例、測定結果、観察された挙動、プロンプトの制約、またはユーザーが提供した根拠など、外部から得られる手がかりを優先してください。

次のことをしないでください。

• モードファイルを複数同時に読まないでください。
• 最終回答を早く出すことを優先しないでください。
• ユーザーまたはシステムの指示に明示されていない限り、このスキルファイルの明示的な指示を無視しないでください。