私は今アジアにいて、Claude CodeとCodexを使っている他のほとんどすべての人とは逆のスケジュールでいます。 そして、アメリカにいるときよりもずっと良い結果を得ていると言わざるを得ません。 時刻によるパフォーマンスの変化は現実のものです。

厄介なバグに対処する際の信じられないほど強力なClaudeコードプロンプト: 次のバグが発生しています。 <bug> [explain_bug_here] </bug> このバグの正確な原因を特定し、効果的な解決策を実装するには、あなたの助けが必要です。これを行うには、以下のワークフローを次の特定の順序で注意深く実行します。 ワークフロー: ステップ 1: 説明 (必要な場合) - このプロンプトの一部が不明瞭またはわかりにくい場合は、続行する前に明確な質問をしてください。 - 無駄に質問しないでください...重要な情報が欠落している場合にのみ尋ねてください。 ステップ 2: 問題を深く理解する (Ultrathink) - 関連するコードベース全体を注意深く確認して分析します。 - バグと関連するすべてのコンテキストを完全に理解するまで、コードを段階的にトレースします。 - 自分の理解に完全に自信が持てるようになるまで分析を続けてください。疑わしい場合は、より深く調べてください。研究が不十分であるよりも、過剰に調査する方が良いです。 ステップ3:特殊なケース(原因が極端に明らかな場合) - ステップ 2 を完了した後、非常に高い信頼度 (95%+ 確実性) で根本原因を特定した場合は、これを明示的に明確に述べてください。ここでは現実的になってください。自信過剰にならないでください。 - このシナリオでは、無関係な原因を生成する代わりに (コンテキストについては以下を参照)、この単一の明確に特定された原因に対する修正の複数の実用的なバリエーションを提案します。 - 次に、ステップ 7 (実装) に直接進み、バリエーションごとに個別のサブエージェントと git ワークツリーを作成し、各修正を個別に実装します。 ステップ 4: 考えられる原因を特定する (原因があまり明らかでない場合) - バグの少なくとも 20 のもっともらしい原因の包括的なリストを慎重に生成します。 - 徹底してください。最初は可能性が低いと思われる角度も含めて、さまざまな角度を探ってください。 ステップ 5: 原因を絞り込み、優先順位を付ける - ステップ 4 のリストを注意深く確認します。 - 綿密な分析で成り立たない理論を削除します。 - 関連する理論や重複する理論を組み合わせて、より明確で可能性が高いシナリオを作成します。 - 最初に見逃していた可能性のある追加の理論を追加します。 - この洗練されたリストを明確に書き直し、完成させます。 ステップ 6: 可能性でランク付けする - 洗練された理論を明確かつ明確にランク付けし、各理論が真の根本原因である確率に基づいて、可能性が最も高いものから最も可能性の低いものまで順に並べます。 ステップ 7: 解決策を提案する - 最も可能性の高い原因の上位 10 のそれぞれについて、問題を解決するための実用的で実用的な解決策を明確に概説します。 ステップ 8: サブエージェントを使用したソリューションの実装 - これらの上位 10 の原因/解決策のペア (または特殊なケースのシナリオでは複数のバリエーション) ごとに、それぞれ独自の git ワークツリーを持つ個別のサブエージェントを作成します。 - 各サブエージェントは、対処している特定の原因を明確に理解し、対応するソリューションを独自の git ワークツリーに直接実装する必要があります。 ステップ 9: ソリューションをテストする - 利用可能なリソースで各ソリューションをテストできる場合は、テスト (一度に 1 つのワークツリー) を実行して、バグが修正されたかどうかを判断します。 - 「可能」とは、適切なツールとリソース(例:APIバグのCURLコマンド、フロントエンドのバグのブラウザアクセス)があることを意味します。 - リソースの制限によりテストが不可能な場合は、実装されたソリューションを明確に要約し、各ソリューションを手動でテストするための明示的な段階的な手順を提供します。 ⸻ このワークフローのすべてのステップを慎重かつ慎重に完了し、全体を通して明確なコミュニケーションを維持してください。主要なステップごとに最新情報を入手してくださいが、私の意見が必要なことに遭遇した場合にのみ一時停止してください。