performance-optimization
Use for measured latency, throughput, memory or cost problems, profiling, or explicit resource targets. Skip prose optimization and speculative tuning.
SKILL.md.claude/skills/performance-optimization/SKILL.md
GitHubPerformance Optimization
Improve a named user outcome with comparable evidence. Prose shortening and
ordinary cleanup are outside this skill. A newly introduced regression whose
cause is the main question is a bug. To fix it, route to the bug-fix playbook:
at top level return to mvp-mode; inside a delegated task, report that route to
the parent. For the diagnosis alone, use systematic-debugging.
- Define the relevant metric, workload and target. If unclear, propose the measurement or ask about the consequential tradeoff before tuning code.
- Capture a baseline with representative data, cache state, concurrency and environment. Repeat enough to estimate variability for the decision; use percentiles when the service target concerns tail latency. Record the command, conditions and results rather than assuming a fixed repeat count proves significance.
- Locate the material cost using existing measurements, focused instrumentation
or profiling. Code inspection can suggest candidates; measurements determine
whether they matter. Use
references/measurement-recipes.mdfor unfamiliar tools andreferences/frontend-performance.mdfor browser performance. - Change one attributable factor where practical. For an inseparable set, explain the coupling. Preserve required semantics, freshness, safety and accessibility.
- Compare under the same conditions and run applicable correctness checks. Keep changes whose benefit justifies their complexity; remove only your ineffective experimental edits, preserving other work. A result within noise is inconclusive, not evidence of a speedup. Record cost/latency/memory tradeoffs explicitly.
Keep a compact attempt record with baseline → result, decision and reason so failed experiments are not repeated after context recovery. Persist it in the task/report when the work needs handoff, not as an extra artifact for every tiny experiment.
For a material recurring risk, add an economical regression guard: query counts, bounded allocations or a controlled benchmark, using existing tooling. Scale its cost to the risk; avoid flaky wall-clock assertions and unnecessary frameworks. Report measured outcomes, applicable checks and limits. Performance improvement does not excuse a correctness regression or authorize unrelated edits.