| name | performance-code-review |
| enabled | true |
| description | Use when performing performance code review — performance-focused code review
template covering N+1 query detection, memory leak identification, caching
strategy evaluation, algorithmic complexity analysis, and resource utilization
review. Provides a systematic framework for identifying performance
bottlenecks and regressions before they impact production systems.
|
| required_connections | [{"prefix":"github","label":"GitHub"}] |
| config_fields | [{"key":"repository","label":"Repository","required":true,"placeholder":"e.g., org/backend-service"},{"key":"pr_number","label":"PR Number","required":true,"placeholder":"e.g., 1234"},{"key":"performance_sla","label":"Performance SLA","required":false,"placeholder":"e.g., p99 < 200ms"}] |
| features | ["CODE_REVIEW"] |
Performance Code Review Skill
Performance review of PR #{{ pr_number }} in {{ repository }} against SLA {{ performance_sla }}.
Workflow
Phase 1 — Database and Query Performance
DATABASE PERFORMANCE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] N+1 queries:
[ ] No loops issuing individual queries
[ ] Eager loading / joins used for related data
[ ] Batch operations for bulk inserts/updates
[ ] Query optimization:
[ ] Queries use appropriate indexes
[ ] No SELECT * (only needed columns)
[ ] EXPLAIN plan reviewed for complex queries
[ ] Pagination for large result sets
[ ] No full table scans on large tables
[ ] Connection management:
[ ] Connection pooling configured
[ ] Connections properly released
[ ] No connection leaks in error paths
Phase 2 — Memory and Resource Management
MEMORY REVIEW
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Memory leaks:
[ ] Event listeners removed on cleanup
[ ] Subscriptions unsubscribed
[ ] Large objects released after use
[ ] Circular references avoided
[ ] Resource management:
[ ] File handles closed properly
[ ] Streams consumed and closed
[ ] Buffers bounded in size
[ ] Temporary files cleaned up
[ ] Data structures:
[ ] Appropriate data structure chosen (map vs list vs set)
[ ] Collections pre-sized when size is known
[ ] No unbounded collection growth
Phase 3 — Algorithmic Complexity
COMPLEXITY REVIEW
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Time complexity:
[ ] No O(n^2) or worse in hot paths
[ ] Nested loops reviewed for optimization
[ ] String concatenation in loops uses builder/buffer
[ ] Space complexity:
[ ] No unnecessary data copies
[ ] Streaming used for large data processing
[ ] Lazy evaluation where appropriate
[ ] Caching:
[ ] Expensive computations cached
[ ] Cache invalidation strategy defined
[ ] Cache TTL appropriate for data freshness
[ ] Cache size bounded
Phase 4 — Concurrency and I/O
CONCURRENCY REVIEW
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Async operations:
[ ] I/O operations are non-blocking
[ ] Async/await used correctly (no fire-and-forget)
[ ] Parallel execution for independent operations
[ ] Concurrency limits for external calls
[ ] Thread safety:
[ ] Shared state properly synchronized
[ ] No race conditions
[ ] Lock granularity appropriate
[ ] Network calls:
[ ] Timeouts configured for all external calls
[ ] Retry logic with exponential backoff
[ ] Circuit breakers for downstream dependencies
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
Output Format
Produce a performance review report with:
- Performance risk summary (high / medium / low impact findings)
- Estimated performance impact per finding
- Benchmark recommendations where applicable
- Specific optimization suggestions with code examples
- Load testing recommendations for validation
