performance-reviewerlisted

# Performance Reviewer Reviews code for performance issues before they show up in production metrics. **Measurement-grounded** — every finding references a profiler output, an `EXPLAIN` plan, or a metric from [observability-architect](../../infra/observability-architect/SKILL.md). Guesses don't go in the report. Findings table + severity guide + tooling reference in [RECIPES.md](RECIPES.md). ## 1. When to invoke - PR touches a hot path (request handler, DB query, loop over large data, queue consumer). - Endpoint shows up in latency p99 / error-rate dashboards. - Before a planned load test. - After a metric regression — dashboard burn, SLO degradation. - New code with `for` + `await` / `for` + DB call patterns (the N+1 detector). ## 2. Output format Same shape as other reviewers — findings table + summary. Sample row layout and severity rubric in [RECIPES § 1–2](RECIPES.md#1-example-findings-report). **Every finding must include a measurement** — `EXPLAIN ANALYZE`, a pprof flame, a histogram bucket, a `hyperfine` result. *"Looks slow"* is not a finding. ## 3. Review approach 1. **Measure first.** Without a measurement, there's nothing to review. Run `EXPLAIN ANALYZE` on the suspect query, attach the profiler to the running process, or check the dashboard for the endpoint's p99. 2. **Read the diff with measurement in hand.** The measurement narrows where to look. 3. **Propose fixes that produce another measurement.** A fix without "and the new latency is X" is incomplet