Improve the frame-rate stability of [game or interactive build]. Before editing, define one repeatable benchmark with the same scene, inputs, hardware, build, resolution, and settings. If no scenario or targets are supplied, propose representative values and state them before proceeding. Record frame-time distribution, average FPS, minimum FPS, CPU use, GPU use, and memory behavior. Identify the largest measured bottleneck and make one focused optimization. Rerun the complete benchmark under the same conditions. Keep the change only if it improves the target without regressing another metric or changing expected behavior. Repeat until [FPS target] holds for [stability period] with no dip below [FPS floor], memory remains below [memory target] without an upward trend, and CPU stays below [CPU target] across two consecutive runs. Stop on success, two rounds without measurable progress, a blocker, or [iteration budget]. Finish with the benchmark setup, before-and-after measurements, retained changes, reverted attempts, and remaining bottlenecks.
claude-code · codex
Use this when
Use this when a game or interactive build has unstable frame rate and performance can be measured under one representative, repeatable scenario.
How it runs
Freeze a representative benchmark scenario and record the frame-time, FPS, CPU, GPU, and memory baseline.
Identify the largest measured bottleneck and make one focused optimization.
Rerun the full benchmark and keep the change only when it improves the target without another regression.
Repeat until every threshold holds twice, progress stalls, the budget ends, or a blocker appears.
Done when
✓ The frame-rate targets hold under the fixed benchmark without another metric regressing. Two consecutive runs meet the FPS, frame-time, CPU, GPU, and memory criteria under the original scene, inputs, hardware, build, resolution, and settings.
Why it works
Average FPS can hide stutter, resource growth, and tradeoffs between CPU and GPU work. Fixed conditions and full-metric retesting prevent a local improvement from becoming a broader regression.
Implementation note
Record the exact hardware, build, scene, inputs, resolution, and settings. Do not compare runs made under different conditions as if they were equivalent.
Discover and execute a benchmark optimization goal, freeze the protocol, compare candidates under identical conditions, and deploy only validated improvements with regression protection.
/goal Use the installed shape-goal and goal-engine skills to discover, approve, and complete this repository's next Measured Optimization / Benchmark objective. During shaping, load shape-goal's required-input specification for Measured Optimization / Benchmark; exhaustively inspect repository instructions, Git state and history, requirements, architecture, plans, tests and CI, runtime behavior, prior goal state, the project harness, and any connected authoritative sources before asking the user. Resolve every material input from evidence where possible; ask only unresolved owner decisions, one at a time with a recommended answer, and do not make production changes until the user approves a Goal Contract. Then hand off within this same goal to goal-engine to freeze the benchmark protocol, compare champion and challengers under identical conditions, and retain only meaningful improvements; apply relevant assurance overlays, repository-native verification, regression protection, independent review where warranted, durable progress state, and reusable closeout. Do not declare success when shaping is complete. Finish only when every approved acceptance and overlay gate passes with surfaced evidence and protected behavior has not regressed. Stop only for a contract-defined blocker, approval boundary, budget, material goal drift, or two consecutive no-progress cycles
Pull the slowest PostgreSQL statement, optimize its query plan with an index or rewrite, verify the improvement, and repeat until all captured queries run under 100ms or hit eight iterations.
/loop pull the 10 slowest statements from pg_stat_statements, take the single worst one, and EXPLAIN ANALYZE it. Fix only that query this iteration — add the missing index, rewrite the predicate, or batch the N+1 — then re-run EXPLAIN ANALYZE to verify the plan improved and run the test suite to prove behavior is unchanged. Only touch indexes and query shape, never application behavior. Continue until every statement in the captured set runs under its 100ms budget — stop after 8 turns, then propose the accumulated index changes as a single PR for review and report any remaining offenders.