Cut checkout p95 under 120ms
Optimize checkout-service code until the p95 latency benchmark hits 120ms and correctness tests pass, recording each iteration's change and result.
Prompt
/goal Reduce checkout p95 latency below 120 ms, verified by the checkout benchmark, while keeping the correctness suite green. Use only checkout-service code, benchmark fixtures, and related tests. Work in checkpoints: after each iteration, record the change, benchmark result, test result, and next experiment. Stop when p95 is below 120 ms and correctness passes, or if the benchmark cannot run or no valid optimization path remains; then report attempted paths, evidence, blockers, and next input needed
claude-code
Source: andy4917 ↗graded C · 65/100 — how grades work (Safety Score v2) →
Similar loops
All performance loops →C
/loopPerformancemedium risk
Fix slow queries, ship index PR
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.
C
/goalPerformancemedium risk
Measure and ship performance gains
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
B
/goalPerformancemedium risk
Bundle size budget
Shrink the production JavaScript bundle under a hard budget by attacking the largest modules with code-splitting, lighter imports, and dead-weight removal.
/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