performance-audit-featurelisted

Focused performance and resource-cost audit of ONE specific feature/change in the-platform (not the whole codebase) — scope taken from a directory/branch/diff, a requirements document, or a YouTrack issue; the same measurement discipline as the full audit (EXPLAIN ANALYZE, py-spy, bundle size, k6), a "before/after" comparison if the feature replaces existing functionality, an explicit production-readiness verdict. Use when asked to check the performance/resource consumption of a specific feature, branch, PR, or YouTrack task before merge/release, to assess whether a new implementation degraded existing functionality in speed/resources, or to give the resource-cost green light for that specific change — even without the word "audit", e.g. "will this feature take down the database", "how much will this eat at real volumes", "is this branch ready performance-wise".
smirnovalex-qa/qa-skills · ★ 1 · Data & Documents · score 75

Install: claude install-skill smirnovalex-qa/qa-skills

# Feature-scoped performance audit For the-platform project: a microservices CRM platform — FastAPI + asyncpg + PostgreSQL + Redis + RabbitMQ backend services, a React/Vite/TS frontend (the-frontend), Docker/Kubernetes/Helm infrastructure, load testing with k6 in `load-testing/`. This is the focused version of the full repository audit (see the `performance-audit-full` skill if the task is the whole repository rather than a single feature). The measurement principles are the same, but the scope, findings, and report are strictly limited to the code that belongs to this feature and to what it touches. ## INPUT Feature: `$ARGUMENTS` The prompt is universal in input format. Depending on what is passed, first reconstruct the feature's scope: **A. Directory/branch/diff** (e.g. `the-frontend/src/features/leads-import` or "diff between dev and the feature/PROJ-XXXX branch"): - Determine the affected files via `git diff --stat` against the base branch (main/dev), or read the whole directory contents if it is a self-contained module. - Determine which services/packages those files touch (services/*, the-frontend, libs/*) — that is the scope of PASS 2 below. **B. Requirements document** (path to a .md/.txt/design doc, etc.): - Read the document in full, write out the described use cases and the expected endpoints/screens/background processes. - Find the code implementing those use cases in the repository (grep by the endpoint/route/component names and the names from th