AI Agentに改善を任せる、その頼み方まで残す ​

/goal

目的:
競技終了 <YYYY-MM-DD HH:MM JST> までに、公式benchmarkが正しいと認めるscoreを最大化し、
再起動後にも再現できる提出状態を完成させてください。
目標は <1位score>、最低目標は <通過border> です。

与えられている環境:
- 作業場所: <WSL / local path>
- server: <SSH user、public IP、private IP、役割>
- 使用可能台数: 最大 <N> 台。必要なら増設してよい
- repository: <URL / branch>
- benchmark 1回の所要時間: 約 <秒数>
- applicationとbenchmarkの配置: <同居 / 別host>
- 使用言語: <Goなど>

権限と禁止事項:
- SSH、package導入、設定変更、service restart、reboot、Git commit/pushを許可する
- instanceのterminate、AMI・snapshot・volumeの削除は行わない
- credential、秘密鍵、生の巨大log、build済みbinaryをcommitしない
- 解説記事、他teamの解答、過去の優勝者記事は見ない
- 公式manual、公式source、server内の実装、実測値だけを根拠にする
- 仕様を守れるなら、大規模refactor、memory化、serverの役割分割を許可する

最初の15分で行うこと:
1. date、残り時間、server台数、CPU、memory、disk、OS、service、portをinventoryする
2. 変更対象だけをGit管理し、戻せるcheckpointを作る
3. 初回benchmarkを変更前に1回行う
4. score、pass、deduction、timeout、採点内訳、測定場所、Git commitを記録する
5. benchmark実行中に公式manualと公式benchmark sourceを読み、加点と失格条件を要約する
6. 外部依存、DNS、認証、initialize、再起動時のstateを図にする

改善loop:
- slow query log、access log、pprof、vmstatなどを必要な順に導入する
- 「計測→上限の仮説→同じ仮説に属する変更→test→同条件の再計測」を繰り返す
- benchmarkが1分動いている間は、前runのlog解析、公式source確認、記録更新を並行する
- 一度にまとめる変更は、一つの仮説で説明できる範囲にする
- scoreだけでなく、route別件数とlatency、DB時間、CPU total sample、OS idle、networkを確認する
- applicationがidleなら、測定経路、benchmark、外部service、同期方式を疑う
- 小さい改善で上限が動かないときは、仕様上のstateを整理して構造変更を検討する
- 失敗runも、観測、原因、revert理由を消さずに記録する
- passしないrun、deductionがあるrun、測定条件が違うrunを最高記録にしない

subagent:
- 独立したread-only作業にはsubagentを使ってよい。明示的に並列化する
- main Agentだけがlive serverのdeploy、restart、benchmark、Git統合を行う
- 例: 公式仕様・採点担当、telemetry担当、code/state境界とtest担当
- subagentには結論、根拠のfile/line、次に試す仮説だけを短く返させる
- 2つのAgentに同じfileや同じserverを書かせない
- benchmark中に別Agentが環境を変更しない

各runの記録:
- 時刻、残り時間、構成、測定場所、Git commit
- score、pass、deduction、timeout、採点内訳
- 見えたこと、仮説、変えたこと、結果、採用/不採用、次に見るもの
- 判断に使ったslow query要約、access log集計、pprof top、必要な画像

時間管理:
- 30分ごとにscore推移と現在の上限を振り返り、次の30分の仮説を一つ選ぶ
- 終了60分前から、根拠の弱い大規模変更を始めない
- 終了30分前に改善を止め、fresh deploy相当の確認へ移る
- 全serverをrebootし、service、port、内部通信、initializeを確認する
- 最終benchmarkを実行し、pass / deduction 0を確認する
- READMEだけでclone、deploy、benchmarkを再現できるか確認する

完了条件:
- 有効な最高scoreと同条件の再現runが記録されている
- test、build、設定syntax checkが通る
- reboot後の最終benchmarkがpass / deduction 0である
- 必要なsource、設定、deploy script、score履歴、判断材料がGitにある
- 最終構成、残ったrisk、不採用案、次に試す案が短くまとめられている

人間への報告は各benchmark後または10分ごとに短く行ってください。
権限内の通常作業で確認待ちにならず、完了条件まで自走してください。

/goal

目的:
競技終了 <YYYY-MM-DD HH:MM JST> までに、公式benchmarkが正しいと認めるscoreを最大化し、
再起動後にも再現できる提出状態を完成させてください。
目標は <1位score>、最低目標は <通過border> です。

与えられている環境:
- 作業場所: <WSL / local path>
- server: <SSH user、public IP、private IP、役割>
- 使用可能台数: 最大 <N> 台。必要なら増設してよい
- repository: <URL / branch>
- benchmark 1回の所要時間: 約 <秒数>
- applicationとbenchmarkの配置: <同居 / 別host>
- 使用言語: <Goなど>

権限と禁止事項:
- SSH、package導入、設定変更、service restart、reboot、Git commit/pushを許可する
- instanceのterminate、AMI・snapshot・volumeの削除は行わない
- credential、秘密鍵、生の巨大log、build済みbinaryをcommitしない
- 解説記事、他teamの解答、過去の優勝者記事は見ない
- 公式manual、公式source、server内の実装、実測値だけを根拠にする
- 仕様を守れるなら、大規模refactor、memory化、serverの役割分割を許可する

最初の15分で行うこと:
1. date、残り時間、server台数、CPU、memory、disk、OS、service、portをinventoryする
2. 変更対象だけをGit管理し、戻せるcheckpointを作る
3. 初回benchmarkを変更前に1回行う
4. score、pass、deduction、timeout、採点内訳、測定場所、Git commitを記録する
5. benchmark実行中に公式manualと公式benchmark sourceを読み、加点と失格条件を要約する
6. 外部依存、DNS、認証、initialize、再起動時のstateを図にする

改善loop:
- slow query log、access log、pprof、vmstatなどを必要な順に導入する
- 「計測→上限の仮説→同じ仮説に属する変更→test→同条件の再計測」を繰り返す
- benchmarkが1分動いている間は、前runのlog解析、公式source確認、記録更新を並行する
- 一度にまとめる変更は、一つの仮説で説明できる範囲にする
- scoreだけでなく、route別件数とlatency、DB時間、CPU total sample、OS idle、networkを確認する
- applicationがidleなら、測定経路、benchmark、外部service、同期方式を疑う
- 小さい改善で上限が動かないときは、仕様上のstateを整理して構造変更を検討する
- 失敗runも、観測、原因、revert理由を消さずに記録する
- passしないrun、deductionがあるrun、測定条件が違うrunを最高記録にしない

subagent:
- 独立したread-only作業にはsubagentを使ってよい。明示的に並列化する
- main Agentだけがlive serverのdeploy、restart、benchmark、Git統合を行う
- 例: 公式仕様・採点担当、telemetry担当、code/state境界とtest担当
- subagentには結論、根拠のfile/line、次に試す仮説だけを短く返させる
- 2つのAgentに同じfileや同じserverを書かせない
- benchmark中に別Agentが環境を変更しない

各runの記録:
- 時刻、残り時間、構成、測定場所、Git commit
- score、pass、deduction、timeout、採点内訳
- 見えたこと、仮説、変えたこと、結果、採用/不採用、次に見るもの
- 判断に使ったslow query要約、access log集計、pprof top、必要な画像

時間管理:
- 30分ごとにscore推移と現在の上限を振り返り、次の30分の仮説を一つ選ぶ
- 終了60分前から、根拠の弱い大規模変更を始めない
- 終了30分前に改善を止め、fresh deploy相当の確認へ移る
- 全serverをrebootし、service、port、内部通信、initializeを確認する
- 最終benchmarkを実行し、pass / deduction 0を確認する
- READMEだけでclone、deploy、benchmarkを再現できるか確認する

完了条件:
- 有効な最高scoreと同条件の再現runが記録されている
- test、build、設定syntax checkが通る
- reboot後の最終benchmarkがpass / deduction 0である
- 必要なsource、設定、deploy script、score履歴、判断材料がGitにある
- 最終構成、残ったrisk、不採用案、次に試す案が短くまとめられている

人間への報告は各benchmark後または10分ごとに短く行ってください。
権限内の通常作業で確認待ちにならず、完了条件まで自走してください。

直近5runでscoreの上限が動いていません。
小さいhotspot修正を一度止め、採点式、load generator、外部service、server間同期、
測定経路のどこが上限かを再評価してください。
必要ならUltra相当の深いreasoningで、大規模変更を含む仮説を3案比較し、
最も検証が速い案から1つだけ実行してください。

直近5runでscoreの上限が動いていません。
小さいhotspot修正を一度止め、採点式、load generator、外部service、server間同期、
測定経路のどこが上限かを再評価してください。
必要ならUltra相当の深いreasoningで、大規模変更を含む仮説を3案比較し、
最も検証が速い案から1つだけ実行してください。

最大3台を使えます。
増やす前に、現在のCPU、memory、I/O、request分布から、分ける役割を説明してください。
stateの所有者、初期化、登録直後、更新順序、障害時のfallbackを表にし、
contract testを追加してからdeployしてください。
main Agentだけが3台へ変更を反映し、subagentはread-onlyで検証してください。

最大3台を使えます。
増やす前に、現在のCPU、memory、I/O、request分布から、分ける役割を説明してください。
stateの所有者、初期化、登録直後、更新順序、障害時のfallbackを表にし、
contract testを追加してからdeployしてください。
main Agentだけが3台へ変更を反映し、subagentはread-onlyで検証してください。

残り60分です。新しい高速化より提出可能性を優先してください。
未commit差分、設定file、秘密情報、起動時依存を監査し、30分後には改善を止めます。
3台reboot、readiness、initialize、最終benchmark、Git pushまでの順番と所要時間を出し、
そのまま実行してください。

残り60分です。新しい高速化より提出可能性を優先してください。
未commit差分、設定file、秘密情報、起動時依存を監査し、30分後には改善を止めます。
3台reboot、readiness、initialize、最終benchmark、Git pushまでの順番と所要時間を出し、
そのまま実行してください。