Performance Review

Use this skill as a cross-stack review lens. Always load review-verification-protocol before reporting findings. For repository changes, also load code-review.

Use systematic-debugging first when an active regression has not been reproduced or narrowed. Use language, runtime, browser, and SQL skills for implementation mechanics. Use observability-engineering when the work changes durable production signals, dashboards, alerts, or SLOs.

For photo/video DAM workloads, compose with digital-asset-management to define representative catalog sizes, media fixtures, rendition/cache states, and viewer workflows before measuring performance.

Local CPU Parallelism Routing

When a performance-sensitive implementation needs a new local CPU-bound data or task decomposition, compose with parallelism-engineering and the matching language owner. That skill owns partitioning, worker bounds, reductions, cancellation, and nested-parallelism design; this skill evaluates the workload, baseline, profiles, and resulting evidence.

Do not route a benchmark, profile, scalability audit, or other evidence-only performance review to parallelism-engineering; it remains here unless an implementation design actually changes. Routine async I/O, event-loop/runtime concurrency, and Spark/PySpark execution likewise remain with their existing runtime or data-platform owners rather than becoming local CPU-parallelism work.

When profiles, traces, logs, responses, or production evidence may expose secrets, credentials, PII, tenant data, payloads, or private paths, also load security-review and security-review-evidence. Keep raw artifacts local and ignored; report sanitized measurements and summaries only. This routing is unnecessary for non-sensitive evidence.

Workflow

1. Define the supported workload, data size, traffic or concurrency shape, environment, user-visible impact, and target threshold.
2. Establish a representative baseline from benchmarks, profiles, traces, browser measurements, query plans, production-safe telemetry, or reproducible timing. Label estimates and missing measurements explicitly.
3. Identify the hot path and scaling variable before reviewing allocations, cloning, I/O, query count and shape, serialization, rendering, caching, contention, queueing, backpressure, and resource bounds.
4. Verify each finding against repository evidence and distinguish measured bottlenecks from plausible risks that still require an experiment.
5. Recommend the smallest change that addresses the demonstrated cause, plus the benchmark, load test, query-plan comparison, or runtime measurement that would prove the improvement and catch regressions.
6. Report environment limits, skipped measurements, assumptions, tradeoffs, and residual capacity risk.

Output

Return prioritized findings with workload and baseline evidence, expected user or operational impact, a concrete remedy, a measurement plan, skipped checks, and residual risk. Do not claim an optimization without a way to compare before and after behavior.

Zod Hot-Path Evidence

Before z.compile() or z.validate(), benchmark representative valid, invalid-with-diagnostics, boolean-validation, construction/reuse, transform, depth, and async workloads. Load zod-engineering for version-specific limits.