performance-review

name	performance-review
description	Use when non-embedded application code changes request paths, render paths, input-proportional collection processing, loop I/O, N+1 queries, repeated serialization/allocation, serial awaits, or cache/memoization decisions. Declare hot paths, complexity, I/O counts, scale assumptions, and improve-or-accept decisions. For target-local embedded hot paths, use embedded-hot-path-review instead.
metadata	{"short-description":"Generic performance review"}

Purpose

Use this skill to catch avoidable performance costs in ordinary application code before they ship.

It answers one question:

Will this change scale acceptably on the path where users, requests, jobs, or frames wait?

When to use

Use this skill for non-embedded code when a change includes:

• request, render, job, or user-visible paths where latency matters
• loops over input-sized collections
• database queries, filesystem calls, network calls, or serialization inside loops
• N+1 query risk or repeated SDK/API calls
• repeated JSON parsing/serialization, regex, sorting, copying, allocation, or formatting
• serial await chains that could be batched, parallelized, cached, or moved off the path
• cache, memoization, batching, pagination, or streaming decisions

Do not use it for:

• target-local embedded loops, polling, sampling, collectors, recorders, or sub-100ms work; use embedded-hot-path-review
• pure documentation, schema-only changes, or tests with no runtime path
• one-shot scripts where input size and runtime cost are bounded and not user-visible
• broad architecture option comparison; use