performance-review
Performance Review
Purpose
code-review checks the performance of a single change as one dimension among several. That catches the N+1 query in the diff in front of you — but it never steps back to ask where the system actually spends its time, what the user actually waits on, or whether the architecture holds at 10× the data. Slowness that users feel is almost always systemic: an accumulation of individually-reasonable choices that no single diff review would flag.
This skill performs a measurement-driven performance review: it establishes what "slow" concretely means with a baseline measurement, then sweeps six dimensions of the system's performance posture — not line by line, but layer by layer. The output is a prioritized, severity-tiered findings report. Because it can be written in PRD format, the findings feed directly into design-to-tasks for remediation — the same handoff ui-design-audit and security-review use.
It is one of the suite's three audit skills, and shares their contract: standalone, whole-system, PRD-emitting. What ui-design-audit is to consistency and security-review is to posture, this skill is to speed.
When to use this vs. code-review
code-review (performance dimension) |
performance-review (this skill) |
|
|---|---|---|
| Unit of work | One diff / PR / changed file set | The whole application or a subsystem |
| Question | "Does this change introduce a performance problem?" | "Where does the system spend the user's time?" |
| Trigger | Every PR | Before launch; after "it feels slow" reports; when data volume grows; on request |
| Finds | An unbounded loop in this diff | The absence of pagination as a pattern; a request waterfall spanning three components |
| Output | Inline review feedback / review.md |
A standalone findings report, optionally a PRD |