When to load

This skill focuses on locating and understanding an application performance problem. For an already identified SQL bottleneck, use sql-performance and reuse sufficient existing measurements; its bounded experiments do not require a fresh 4–24-hour monitoring period.

architect — designing a performance-critical system
worker — implementing a hot path or data-intensive operation
reviewer — reviewing a PR that touches a hot path, query, or cache
research — investigating a reported slowness or latency spike

The 5 rules

1. Read the data before forming a hypothesis.

p50 fine + p99 bad is a tail problem, not a slow endpoint. Bimodal distributions (fast + slow requests) differ from a smooth long tail. Identify which shape the data has before suggesting a fix. Before diagnosing on a percentile, confirm the tail with p99.9 — p99 worse than p99.9 is reverse tail, usually a measurement artifact.

2. Convert latency into user-impact numbers.

"p99=8s" is abstract. "5,000 requests/day take >8s; 10-second complaints are p99.9 (~50/day)" is concrete. Leadership reacts to concrete.

3. Ask 3 questions before analyzing.

What does the code path look like (branches, conditional logic)? Is the slowness clustered by time, user cohort, or deploy? What does the existing instrumentation show? A 5-minute question round shifts hypothesis ranking more than an hour of analysis. If the answer is "I don't have that data," that's the first instrumentation to add — not a reason to guess.