Performance Capacity
Purpose
Use this skill to make performance measurable before optimizing. It turns vague "make it faster" work into budgets, probes, bottleneck hypotheses, and regression gates.
Baseline First
Before changing code, capture:
- User-facing operation or background job under test.
- Current p50/p95/p99 latency or throughput.
- Data size and concurrency assumptions.
- Resource limits: CPU, memory, IO, network, database, queue.
- Existing cache behavior and invalidation rules.
- Cost or quota constraints.
If no baseline can be gathered, state the nearest measurable proxy and its limitations.
Budget Design
Define budgets by surface:
| Surface |
Examples |
| UI |
TTI, interaction latency, bundle size, render count |
| API |
p95 latency, error rate, DB query count, payload size |
| Jobs |
throughput, max lag, retry cost, idempotency |
| Data |
query plan, index coverage, backfill duration |
| Infra |
CPU/RSS, concurrency, autoscaling, cost per request |
Optimization Rules
- Optimize the measured bottleneck, not the most familiar code.
- Prefer algorithmic, query, batching, and cache correctness fixes before capacity-only fixes.
- Define cache invalidation and stale-data tolerance.
- Add a regression test, benchmark, or dashboard check for risky paths.
- Do not trade correctness, authorization, or tenant isolation for speed.
Output Shape
operation:
baseline:
target_budget:
bottleneck_hypothesis:
measurement_plan:
optimization_options:
capacity_estimate:
regression_gate:
verification_commands:
1---2name: performance-capacity3description: Plan, diagnose, and verify performance budgets, latency targets, load tests, capacity estimates, bottleneck analysis, caching strategy, query efficiency, queue throughput, and regression gates. Use when a feature may be slow, a system must scale, a performance regression is suspected, or release readiness depends on throughput, cost, memory, CPU, or response time.4---5
6# Performance Capacity
7
8## Purpose
9
10Use this skill to make performance measurable before optimizing. It turns vague "make it faster" work into budgets, probes, bottleneck hypotheses, and regression gates.
11
12## Baseline First
13
14Before changing code, capture:
15
161. User-facing operation or background job under test.
172. Current p50/p95/p99 latency or throughput.
183. Data size and concurrency assumptions.
194. Resource limits: CPU, memory, IO, network, database, queue.
205. Existing cache behavior and invalidation rules.
216. Cost or quota constraints.
22
23If no baseline can be gathered, state the nearest measurable proxy and its limitations.
24
25## Budget Design
26
27Define budgets by surface:
28
29| Surface | Examples |
30|---|---|
31| UI | TTI, interaction latency, bundle size, render count |
32| API | p95 latency, error rate, DB query count, payload size |
33| Jobs | throughput, max lag, retry cost, idempotency |
34| Data | query plan, index coverage, backfill duration |
35| Infra | CPU/RSS, concurrency, autoscaling, cost per request |
36
37## Optimization Rules
38
39- Optimize the measured bottleneck, not the most familiar code.
40- Prefer algorithmic, query, batching, and cache correctness fixes before capacity-only fixes.
41- Define cache invalidation and stale-data tolerance.
42- Add a regression test, benchmark, or dashboard check for risky paths.
43- Do not trade correctness, authorization, or tenant isolation for speed.
44
45## Output Shape
46
47```text
48operation:
49baseline:
50target_budget:
51bottleneck_hypothesis:
52measurement_plan:
53optimization_options:
54capacity_estimate:
55regression_gate:
56verification_commands:
57```
majiayu000