← ClaudeAtlas

performance-budget-checklisted

Set a latency budget and say where the number came from, prove a limited resource cannot be oversold under concurrency, and pick the CT-PT test type the question actually calls for. Use when a performance number needs a justification — spike and soak change what green means and are not load with different numbers. Self-hosted targets only.
QAIA-Project/QAIA · ★ 0 · Testing & QA · score 70
Install: claude install-skill QAIA-Project/QAIA
# Performance Check > **Standalone adaptation.** Self-contained version of the `perf-check` skill from > [QAIA](https://github.com/QAIA-Project/QAIA) (MIT). QAIA is pre-alpha and says so. ## Before anything: self-hosted targets only **Load-testing a shared public demo is forbidden and usually against its terms.** Refuse a public shared target and require a self-hosted URL — Docker, VPS or local. This is not a formality; it is the difference between a test and an incident on someone else's infrastructure. ## 1. Latency budget — and say where both numbers came from Fire N concurrent requests at a key endpoint, assert p95 below budget, log p50 / p95 / max. **N and the budget decide whether the test passes, so leaving them implicit means two runs of the same skill disagree.** - If the project states a budget — an SLO, a ticket, a documented rule — **use it and cite it**. - Absent that, start from **N = 10** concurrent virtual users and **p95 < 500 ms** for a server-rendered page or a JSON endpoint, **say explicitly that these are defaults and not a project commitment**, and offer to replace them before the run. **A "key endpoint" is the one the highest-priority scenarios actually exercise most.** Name it. Do not pick the homepage by reflex. ## 2. Concurrency integrity — the check that is not about speed Race N clients on a limited resource — one bookable slot, one unit of stock, one coupon — and assert **exactly one succeeds**. No oversell, no double-spend. This fi