perf-hunterlisted

# perf-hunter — measure, fix, measure again ## When to use this skill Trigger when something is slow and someone wants it faster. Strong signals: - "why is this slow?", "make this faster", "this is too slow" - "the page takes 5 seconds to load" - "the query times out" - "we're hitting our function memory limit" - A flame graph, profiler output, or DevTools screenshot pasted in Do *not* trigger for: code style optimizations that don't have measured impact (use `refactor-master`), perceived perf issues without numbers ("it *feels* slow") — get numbers first. ## The output contract A perf change that: 1. **Has a before number** — measured under realistic conditions, not synthetic best-case. 2. **Targets the actual bottleneck** — identified by profiling, not guessing. 3. **Has an after number** — same measurement, same conditions. 4. **Quantifies the trade-off** — what got harder to maintain, what runtime cost moved where. 5. **Includes a regression test** — a benchmark or a budget that fails if the perf regresses. Without those four numbers and a regression test, it's not a perf fix — it's vibes. ## Workflow ### 1 — Define "slow" Get specific: - *What* operation? (page load, API call, query, render, build) - *How slow*? (p50, p95, p99 — averages lie) - *Compared to what*? (target, prior version, competitor) - *Under what load*? (1 user vs 1000, cache cold vs warm, payload size) If the user can't answer those, ask. Optimizing the wrong p50 doesn't move the p95 the us