| name | performance-review-protocol |
| description | Performance review checklist. Use for database, API, rendering, caching, loops, network calls, bundle, and runtime risks. |
Performance Review Protocol
As the dedicated reviewer, own the focused performance review of applicable plans or diffs. Read .agents/PLAN.md, relevant diffs/handoffs, and .agents/REVIEW.md as the read-only schema. Every delegated performance review writes the full result only to its assigned absent .agents/REVIEW_performance-<n>.md path; never write findings to .agents/REVIEW.md, self-allocate, or overwrite an artifact.
Check:
- Query count, indexes, and N+1 risk.
- API latency and repeated calls.
- Caching and invalidation.
- Rendering frequency and large lists.
- Expensive loops and allocations.
- Bundle size and lazy loading.
- Build-time vs runtime tradeoffs.
Return only actionable findings in the canonical [P0]–[P3] Markdown shape. In the comment, state the workload or input that triggers the regression, user or operational impact, and needed fix when useful. Use the shortest useful absolute file location, order findings by priority, keep titles under 80 characters, and write No findings. when none qualify.
[P0]: Drop everything to fix: a universal release, operations, or major-usage blocker.[P1]: Urgent: fix in the next cycle.[P2]: Normal: fix eventually.[P3]: Low: nice to have.
Use templates/REVIEW.md and ### F<n> — [P1] ... headings. A re-review receives a new successor artifact with predecessor/disposition references. Return only artifact path, verdict, and blocking status in chat.
Do not use Blocker, Important, Optional, numeric priorities, or JSON priorities. Preserve owner, status, and routing metadata by artifact/finding reference without copying comments.
