Purpose
Review only performance issue code. Do not define scope (diff vs codebase) or perform security/architecture/language framework convention analysis; these are handled by other atomic skills. Emit in standard formatresult listfor aggregation. Focus on algorithmic complexity, query efficiency, I/O and network cost, memory behavior, contention and concurrency bottlenecks, caching strategy, and measurable regression risk.
Core Objective
Primary objective: generate a performance-focused result list covering complexity hotspots, query efficiency, I/O cost, memory behavior, concurrency contention, caching, and regression risk for the given code scope.
Success criteria(all requirements must be met):
- ✅ Performance scope only: review only the performance dimension; do not perform scope selection, security, architecture, or language/framework style review
- ✅ Evaluate all eight categories: where relevant, evaluate complexity, database/query efficiency, I/O/network cost, memory/allocation, concurrency/contention, caching/reuse, load-oriented behavior, and observability
- ✅ Conform to the findings format: each finding includes location, category ("cognitive-performance"), severity, title, description, and optional recommendation
- ✅ Accurately assigned severity: issues affecting production are marked "critical"; scalability risks are marked "major"; localized optimizations are marked "minor"/"suggestion"
- ✅ Actionable output: each finding has a specific location reference and a concrete fix or improvement recommendation; do not require benchmark numbers unless measurement evidence is provided
AcceptanceTest: does the output contain a performance result list covering all relevant dimensions, along with evidence-based severity ratings and actionable, location-referenced recommendations?
Scope boundaries (Scope boundaries)
This skill is responsible for：
- Algorithmic complexity hotspots (O(n²)+, nested loops, repeated scans)
- Database/query efficiency (N+1, missing pagination, broad selects)
- I/O and network cost (chattiness, missing batching, blocking on the critical path)
- Memory and allocation behavior (churn, large object retention, unbounded growth)
- Concurrency and contention (lock contention, goroutine starvation, queue backpressure)
- Caching strategy (missing cache on hot paths, invalidation risk, stampede risk)
- Load-oriented behavior (missing limits/guards, expensive defaults)
- Performance observability (missing metrics/tracing on hot paths)
This skill is not responsible for：
- Scope selection (deciding which files/paths to analyze) — scope is provided by the caller
- Security review — use "review-security"
- Architecture review — use "review-architecture"
- Language/framework-specific conventions - use
review-dotnet、review-java、review-go, etc. - Comprehensive SQL performance analysis — use
review-sql - Full orchestrated review — use "review code"
Handoff point: after all performance results are published, hand off to the "review code" orchestrator for aggregation, or deliver directly to the user for a performance-focused review session.
Use cases
- Deliberate review: when orchestrate-code-review runs scope -> language -> framework -> library -> cognitive, used as the cognitive step.
- Performance-focused review: when the user only wants to check the performance dimension before merging or releasing.
- Regression prevention: verify that changes do not introduce obvious latency, throughput, or memory regressions.
When to use: when the task includes a performance review. The scope and code scope are determined by the caller or user.
Behavior
The scope of this skill
- Analyze：the performance dimensions in the given code scope(files or diffs provided by the caller). Do not decide the scope; accept the code scope as input.
- Do not: perform scope selection, security review, architecture review, or language/framework style review. Focus only on performance.
Review checklist (performance dimensions only)
- Complexity hotspots: detect unnecessary O(n^2)+ behavior, repeated scans, nested loops over large collections, and avoidable recomputation.
- Database and query efficiency: N+1 access patterns, missing pagination, broad selects, inefficient joins/filters, and query frequency amplification.
- I/O and network cost: frequent remote calls, missing batching, blocking calls on the critical path, unbounded retries/timeouts, and poor backoff behavior.
- Memory and allocation: excessive allocation/churn, large object retention, unnecessary copies, unbounded growth, and avoidable buffering.
- Concurrency and contention: lock contention, serialized critical sections, thread/goroutine starvation, queue backpressure, and oversubscription risk.
- Caching and reuse: missing caching opportunities on hot read paths, invalidation correctness risks, stampede risks, and low-value cache layers.
- Load-oriented behavior: missing limits/guards (batch size, page size, concurrency caps), expensive defaults, and lack of degradation strategies under load.
- Performance observability: missing metrics/traces around hot paths, which hinders regression detection and capacity planning.
Severity guidance
- Critical: may have an obvious impact on production (e.g., unbounded loops/growth, repeated expensive I/O in hot paths, catastrophic query patterns).
- Major: strong regression or scalability risk from realistic traffic/data growth.
- Minor/Suggestion: localized or lower-impact optimization opportunities.
Tone and references
- Professional and technical: reference specific locations (file:line or query/block).
- Emit findings containing location, category, severity, title, description, and recommendation.
Input & Output
Input
- Code scope: the files or directories (or diff) already selected by the user or scope skill. This skill does not decide the scope; it only checks the performance of the provided code.
Output
- withAppendix: Output contractEmit zero or more in the format defined inresults。
- The category of this skill iscognitive-performance。
Limits (Limits)
Hard Boundaries
- Do notperform scope selection, security, architecture, or language/framework style reviews. Stay within the performance scope.
- Do notgive conclusions without specific locations or actionable recommendations.
- Do notclaim benchmark numbers unless measurement evidence is provided in the input.
Skill Boundaries
Do not do these(other skills can handle them):
- Do not select or define the code scope - the scope is determined by the caller or "review code"
- Do not perform security, architecture, or language/framework reviews - use the respective atomic skills
- Do not perform comprehensive SQL performance analysis - use
review-sql - Do not run or execute code to measure performance - use "run-automated-tests" for test execution
When to stop and hand off：
- After all performance results are published, hand them off to "review code" for aggregation in a curated review
- When the user needs a comprehensive review (scope + language + cognitive), redirect to "review code"
- When SQL performance issues dominate, suggest also running "review-sql" for deeper SQL coverage
Self-Check
Core success criteria
- Performance scope only: review only the performance dimension; do not perform scope selection, security, architecture, or language/framework style reviews
- Evaluate all eight categories: where relevant, evaluate complexity, database/query efficiency, I/O/network cost, memory/allocation, concurrency/contention, caching/reuse, load-oriented behavior, and observability
- Conform to the findings format: each finding includes location, category ("cognitive-performance"), severity, title, description, and optional recommendation
- Accurately assigned severity: issues affecting production are marked as "critical"; scalability risks are marked as "major"; localized optimizations are marked as "minor"/"suggestion"
- Actionable output: each finding has a specific location reference and a specific fix or improvement recommendation, and does not claim benchmark numbers unless measurement evidence is provided
Process quality checks
- Was only the performance dimension reviewed (no scope/security/architecture/style)?
- Were the relevant complexity, query efficiency, I/O, memory, concurrency, caching, and loading behavior covered?
- Does each finding include location, category=cognitive-performance, severity, title, description, and optional recommendation?
- Are high-impact regression risks clearly distinguished from minor optimizations?
Acceptance tests
Does the output include a list of performance results covering all relevant dimensions, along with evidence-based severity ratings and actionable, location-referenced recommendations?
Examples (Examples)
Example 1: N+1 query pattern
- Input: loop through fetching each parent's child records with one query per iteration.
- Expected: Emit a major/critical finding for the N+1 behavior; recommend batch queries or a join strategy. Category=cognitive-performance.
Example 2: Hot-path allocation churn
- Input: The request handler repeatedly allocates large temporary buffers and serializes the payload multiple times.
- Expected: Publish a major finding about allocation pressure and latency impact; recommend reuse/pooling or a single-pass conversion. Category=cognitive-performance.
Edge case: No obvious performance risk in a small formatting difference
- Input: The diff includes only comments/renames, with no behavior change.
- Expected: Emit no findings or one advisory-level note; do not invent optimization work. The category remains cognitive-performance for any findings emitted.