/goalperformancemedium riskintermediatesafety C · 65Forward Futurepre-dates current gate · under review

Hold a stable frame rate

Measure frame time, CPU, GPU, and memory under fixed conditions and keep only regression-free optimizations.

prompt
→ Claude
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

  1. Freeze a representative benchmark scenario and record the frame-time, FPS, CPU, GPU, and memory baseline.
  2. Identify the largest measured bottleneck and make one focused optimization.
  3. Rerun the full benchmark and keep the change only when it improves the target without another regression.
  4. 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.

Source: Forward Future

More performance loops

Benchmark regression watch

/looploopreponew

Run the benchmark suite every 30 minutes during active development and raise a flag the moment any benchmark slips more than 5 percent from baseline.

prompt
→ Claude
/loop 30m run `npm run bench`, compare each result to the baselines in bench/baseline.json, and if any benchmark regressed more than 5%, show me the numbers and the commits since the last clean run
performancemedium risk

Bundle size budget

/goalloopreponew

Shrink the production JavaScript bundle under a hard budget by attacking the largest modules with code-splitting, lighter imports, and dead-weight removal.

prompt
→ Claude
/goal the main production bundle is under 250 KB gzipped — run the build with the bundle analyzer, address the single largest contributor each turn (code-split it, replace it with a lighter import, or drop it), and confirm the build and tests stay green; stop at the budget or after 10 turns
performancemedium risk

AutoLoop — metric-driven optimization loops

/ralphnew

Agent-agnostic hill-climbing loops inspired by Karpathy's autoresearch: define a metric, let the agent propose a change, measure, keep it only if the number improved, and repeat.

prompt
→ Claude
Iterative optimization loops (inspired by Karpathy's autoresearch): define a metric, agent proposes change, harness measures, keep if improved, repeat. Works with Claude Code, Codex, Cursor, Gemini CLI.
performancemedium risk