version: "1.0.0" name: performance-review description: Review performance and scalability using workload, baseline, profiling, query-plan, rendering, concurrency, and resource evidence. Use for bottleneck audits, benchmark plans, capacity risks, or performance-sensitive changes; do not use for active unexplained regressions or implementation mechanics alone.

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.

1. Establish a representative baseline from benchmarks, profiles, traces,

browser measurements, query plans, production-safe telemetry, or reproducible timing. Label estimates and missing measurements explicitly.

1. 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.

1. Verify each finding against repository evidence and distinguish measured

bottlenecks from plausible risks that still require an experiment.

1. 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.

1. 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.