performance-audit-fulllisted

Full performance and resource-cost audit of the entire the-platform repository (FastAPI/asyncpg/PostgreSQL/Redis/RabbitMQ backend services, the-frontend, shared libraries libs/*, Docker/Kubernetes/Helm infrastructure, k6 load testing in load-testing/) — three independent passes (instrumental profiling, line-by-line code review, architectural review), findings only with measurement (EXPLAIN ANALYZE, py-spy, bundle size, k6 runs), severity, file:line, and a final verdict. Use when asked to run a performance/resource-cost audit of the whole codebase or infrastructure, to check CPU/RAM/network-traffic/infrastructure-cost consumption, to find bottlenecks across the whole repository, to assess the economy of the architecture as load grows, or to re-verify the status of findings from a previous audit/load-testing reports — even if the user doesn't say the word "audit" literally, but says "why does the service eat so much CPU/memory", "let's look at the performance of the whole project", etc.
smirnovalex-qa/qa-skills · ★ 1 · API & Backend · score 75

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

# Full repository performance and resource-cost 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/`. ## ROLE The company the product is built for is extremely sensitive to the consumption of compute resources (CPU, RAM, network traffic, infrastructure cost) — performance and economy are treated as a first-class priority, not as tech debt to handle "someday later". The audit must find real, measurable problems tied to file:line and with a quantitative impact estimate (latency, CPU, RAM, number of DB queries, traffic size), not produce a generic "best practices" checklist without verification against the concrete codebase. ## INPUT `$ARGUMENTS` — optionally a path to the previous audit report or to load-testing/reports for a "before → after" comparison. If not passed, look for it yourself: `load-testing/ANALYSIS_GUIDE.md`, `load-testing/reports`, and any previous performance-audit reports mentioned in the dialogue or the repository. This is an audit of the WHOLE repository. If the task actually concerns only one feature/branch/PR — this is not the right skill; use `performance-audit-feature` instead of a full review of the entire codebase (otherwise the scope will be excessive and the findings will not be tied to what really matters to check). ## KEY PRINCIPLE: MEASURE, DON'T