このプロンプトのミニチュア版をここに含めたのは、「My Favorite Prompts」シリーズはコンパクトで一口サイズの自己完結型のナゲットであるはずだからです。 しかし今日、私はこれを本当に狂気じみたシステムに変えてしまいました。Reactで別のCRUDプログラムやTODOリストを作る場合は関係ありませんが、RustやGolangでかなり複雑なことや複雑なデータを扱う場合、この方法はできることがほとんど怖いほどです。 これは2ラウンドのプロセスです。ラウンド1はこちらです: --- まず、すべてのAGENTS dot mdファイルとREADME dot mdファイルを非常に注意深く読み、両方を理解することが大切です!その後、コード調査エージェントモードを使って、コードや技術的アーキテクチャ、プロジェクトの目的を完全に理解しましょう。 そして、それらすべてを非常に徹底的かつ綿密に取り組み、既存のシステム全体とその役割、目的、実装方法、そしてすべての要素がどのように相互に繋がっているのかを深く理解した後、このプロジェクトに関連するこれらの疑問を徹底的に調査し、研究し、熟考してください。 コアシステムに他に重大な非効率はあるのでしょうか?コードベース上で、1) 変更によって全体のレイテンシやレスポンス、スループットの面で実際に変化が起こる場所、2) 機能的には変化が証明可能に同型であり、同じ入力で結果の出力が変わらないことを確実に知ること;3) アルゴリズムやデータ構造に関して明らかにより良いアプローチを明確に示すビジョンがある場合(この場合は、あまり知られていないデータ構造やより難解・洗練・数学的なアルゴリズム、さらに問題を再構築して別のパラダイムを露出させる方法を含めることができます。以下のリストのように(注: 最適化を提案する前に、基準指標(p50/p95/p99のレイテンシ、スループット、ピークメモリ)を設定し、CPU/割り当て/I/Oプロファイルを取得して実際のホットスポットを特定してください: - N+1クエリ/フェッチパターンの排除 - ゼロコピー/バッファ再利用/散発集いI/O - シリアライゼーションフォーマットコスト(パース/エンコードオーバーヘッド) - 有界キュー+バックプレッシャー(メモリのブローアップやテールレイテンシーの防止) - 競合を減らすためのシャーディング/ストライプロック - キャッシュ無効化戦略を用いたメモ化 - 動的計画法技術 - 凸最適化理論 - 遅延評価/遅延計算 - 大規模なコレクションの物質化を避けるためのイテレーター/ジェネレーターパターン - メモリ制限作業のためのストリーミング/チャンク処理 - 事前計算およびルックアップテーブル - インデックスベースのルックアップと線形スキャン認識の比較 - 二分探索(データおよび回答空間上) - 2ポイントおよびスライディングウィンドウ技術 - 接頭辞和/累積集計 - 依存グラフの位相的ソートとDAG認識 - サイクル検出 - 動的接続のためのユニオン探索 - 早期終了を伴うグラフトラバーサル(BFS/DFS) - ダイクストラの / A* (重み付き最短経路) - 優先度キュー/ヒープ - プレフィックス操作のためのトライ - 確率的メンバーシップのためのブルームフィルター - レンジクエリ用の区間/セグメント木 - 空間インデックス付け(k-d木、クアッドツリー、R木) - 永続的/不変データ構造 - コピーオンライトの意味論 - オブジェクト/接続プーリング - キャッシュ追放ポリシー選択(LRU/LFU/ARC) - バッチ認識アルゴリズム選択 - 非同期I/Oバッチとコイレッシング - 高競合シナリオ向けのロックフリー構造 - 再帰的並列性のための作業盗用 - メモリレイアウト最適化(SoAとAoS、キャッシュ局所性) - ショートサーキットおよび早期終端 - 繰り返し値に対する文字列インターニング - 償却分析推論 該当する場合は以下の一般的なガイドを考慮します: DP適用性チェック: - 重複する部分問題?→安定状態キー付きのメモズ - 最適なパーティショニング/バッチング?→接頭辞 + 区間DP - 繰り返し走査を伴う依存グラフ?→ 単一通過位相的DP 凸最適化チェック: - ブルートフォーシングで正確な割り当てやスケジューリング?→ 決定論的なタイブレークを伴うLP/最小コストフロー - 明示的な損失を伴う連続パラメータフィッティング?→ 正則化最小二乗法 / QP - 大きな分解可能な凸対物レンズ?→ ADMM / 近接法 また、もしよく書かれたサードパーティ製ライブラリがご存知であれば、プロジェクトに含めることも可能です。 方法論要件: A) まずベースライン:テストスイートと代表的なワークロードを実行し、P50/P95/P99のレイテンシ、スループット、ピークメモリを正確なコマンドで記録します。 B) 提案前のプロファイル:キャプチャ CPU + 割り当て + I/O プロファイル;変更を提案する前に、トップ3〜5のホットスポットをパーセントタイムで特定してください。 C) 同値オラクル:明示的な金出力+不変量を定義する。大きな入力空間の場合は、性質に基づく検定や変成検定を加えます。 D) 変更ごとに同型証明:提案されるすべての差分には、出力が変更できない理由を説明する短い証明スケッチ(順序付け、タイブレーク、浮動小数点挙動、RNGシードなど)が含まれなければなりません。 E) 機会マトリックス:実施前の(インパクト×自信)/努力で候補者をランク付け;P95+やスループットが意味のある動きを期待できるアイテムだけに焦点を当ててください。 F) 最小限のデフ:変更ごとにパフォーマンスレバーを1つずつ。無関係なファクタリングは禁止。リスクがある場合はロールバックの指針を含めてください。 G) 回帰ガードレール:ベンチマークの閾値やモニタリングフックを追加し、将来の回帰を防ぐ。 Ultrathinkを使いましょう。 --- Claude CodeのOpus 4.5とCodexのGPT 5.2 Codexで一度だけ実行できます(私はExtra Highが遅すぎて寝る直前以外はHighだけを使い始めました)。 終わったら、それぞれにこれを5回ほど素早く撃ち込んでください: 「いいね。明らかな見落としや抜け、ミス、概念の誤り、ミスなどをもう一度見直してください。ウルトラシンクを使え」 そして、出力をこのように保存してもらいます: 「よし、全部PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.mdとして保存しておけ」 「よし、全部PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.mdとして保存しておけ」 次にClaude Codeで、次の動作を行います: 「PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.mdにしたことを比較し、そこから最良の要素を取り入れて、元のプランファイルを編集してハイブリッドで両方の世界の優位を兼ね備えたプランを作り上げろ。」 そしてこれです: AGENTS dot mdを再読して、まだ記憶に新鮮に残してください。では、PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md.の全文をお読みください。それから一粒一粒をすごく注意深く確認してください――本当に意味が通っていますか?最適でしょうか?ユーザーにとってシステムをより良く機能させるために何か変更できるでしょうか?これらすべてに対して包括的かつ細かいビーズセットを作りたいと考えています。タスク、サブタスク、依存構造を重ね、詳細なコメントを付けて、全体が完全に自己完結し、自己文書化できるようにしたいです(関連する背景、理由・正当化、考慮事項など、将来の自分に知ってほしい目標や意図、思考過程、そしてそれがプロジェクトの大きな目標にどう役立つかなど)。ビーズは非常に詳細で、元の割引プランのドキュメントを参照する必要がないようにしましょう。マークダウンプランのファイル全体を包括的に正確に反映しているのでしょうか? 変更が必要な場合はビーズを修正したり、新しいものを作成したり、無効または適用できないものを閉じてください。これらのことを導入する前に「計画空間」で運営する方がずっと簡単で速いのです!物事を単純化しすぎないでください!機能や機能性を失わないでください!また、これらのビーズの一部として、包括的なユニットテストやe2eテストスクリプト、そして詳細なログ記録を含めて、実装後にすべてが完璧に動作していることを確実にしてください。ビーズの作成・修正、そしてビーズへの依存関係の追加には、必ず『bd』ツールを使うことを忘れないでください。」 その後、次のラウンドを数回行いました: 「一粒一粒をすごく注意深く確認して――本当に意味が通じてるの?最適でしょうか?ユーザーにとってシステムをより良く機能させるために何か変更できるでしょうか?もしそうなら、ビーズを修正してください。これらのことを導入する前に「計画空間」で運営する方がずっと簡単で速いのです!物事を単純化しすぎないでください!機能や機能性を失わないでください!また、ビーズの一部として包括的なユニットテストやe2eテストスクリプト、そして詳細なログ記録を盛り込み、実装後にすべてが完璧に動作していることを確実にしてください。 ウルトラシンクを使え。」 その後、スウォームを解き放ってすべて実装させましょう。そしてラウンド2の準備をしましょう。