performance

Statically flags performance anti-patterns across the codebase and, when a backend exists, performs API load testing.

Interaction. Wherever this skill asks the user something, use the host's blocking question tool already in your tool list, matched by capability rather than by a host-specific name; if it is listed but not loaded, load it first with the host's tool-discovery primitive; only when no such tool is listed, or a question call errors, offer numbered options in chat and end your turn to wait for the reply — never answer the question yourself or skip it.

1. Stack Detection

First consume the host documentation; if none exists, fall back to the built-in catalog.

# Check for documentation generated by the host harness-researcher (Phase 4; consume first if present)
ls docs/verification/performance.md 2>/dev/null && cat docs/verification/performance.md

• If docs/verification/performance.md exists: read the stack list, SSOT, and tools from the file and run those sections. Also independently run Automatic Stack Detection (below) — for any detected stack that the host doc does NOT mention, run that stack's fallback reference file too (the host doc may be stale or predate a newly added stack; do not silently skip undocumented stacks).
• If docs/verification/performance.md is absent: fall back entirely to Automatic Stack Detection.

Automatic Stack Detection (fallback / gap-fill)

If multiple stacks are detected, run all of them. Always also run static-checks-complexity.md (language-agnostic via lizard), regardless of which stacks were detected.

2. Language-Specific Static Anti-Pattern Flagging

Authoritative catalogs (SSOT) — one file per stack, listed in the table in §1. Each stack's detection patterns live in its references/static-checks-<stack>.md.

For each detected stack, open its reference file from §1's table and follow its detection commands and verification-delegated runtime tools. Every stack file follows the same shape: a detection-pattern table, the statically-safe grep/tool command, the correct fix, and the runtime tool to delegate final verification to.

DB query-plan caution patterns (SELECT *, function-wrapped WHERE, leading-wildcard LIKE, etc.) are DB-engine-based, not language-based — always consult static-checks-db.md when a DB is present, regardless of the application language.

3. API Load Analysis When a Backend Exists

The authoritative procedure = references/api-load.md — OpenAPI spec discovery (§1), the openapi-to-k6 invocation (§2.1), and the report template (§3). Follow it exactly; both the spec paths and the CLI syntax have traps that re-deriving them inline reliably gets wrong.

Confirm BASE_URL — ask the user (structured choice) — before running any load — api-load.md §1 gathers candidates from several sources, but a guessed BASE_URL points load at the wrong host.

MIT fallback (when avoiding AGPL): oha, autocannon, vegeta — see references/api-load.md §2.2.

The iteration count (default 100) and SLO thresholds are the skill's defaults. If a team-specific load profile is needed, do not fork the skill; place it in the host's docs/verification/performance.md (generated by the harness) so those values take precedence (config-driven principle).

3.1 Report Collection Criteria

Follow the report template in references/api-load.md. Key requirements:

• No mean alone — always report the p50/p95/p99 (+p99.9) distribution
• Include throughput (RPS) + concurrency (VU) + error rate
• State PASS/FAIL against the SLO explicitly
• Record measurement metadata: tool, version, load model, duration, whether warm-up was excluded, whether CO correction was applied
• Do not average percentiles (non-additive — see the statistical-conventions section of references/api-load.md)

4. Report Format (Four Golden Signals skeleton)

## Performance Check Results — <date>

### Static Flagging Results
| Stack | Pattern | Location | Verdict | Recommendation |
|---|---|---|---|---|
| Python/Django | Suspected N+1 | users/views.py:42 | Needs review | Use select_related('profile') |
| React | Inline object prop | components/List.tsx:17 | Needs review | Memoize with useMemo |

> The items above are static-detection candidates — delegate the final verdict to a runtime tool.

### API Load Results (if applicable)
| Endpoint | p50 | p95 | p99 | RPS | VU | Error rate | SLO | Verdict |
|---|---|---|---|---|---|---|---|---|
| GET /users | 12ms | 45ms | 120ms | 850 | 10 | 0.0% | p99≤200ms | PASS |
| POST /orders | 80ms | 350ms | 890ms | 210 | 10 | 1.2% | p99≤500ms | FAIL |

**Measurement metadata**: openapi-to-k6 0.3.x + k6 0.52.x / iterations=100 per endpoint / VU=10 /
warm-up excluded (first 10 runs) / no CO correction / local execution (no network overhead)

### Golden Signals Summary
- **Latency**: …
- **Traffic**: …
- **Errors**: …
- **Saturation**: …

References

• references/static-checks-python.md — Python static anti-pattern catalog (N+1)
• references/static-checks-node.md — Node.js (Prisma/TypeORM) static anti-pattern catalog (N+1)
• references/static-checks-java.md — Java/Hibernate static anti-pattern catalog (N+1)
• references/static-checks-ruby.md — Ruby/Rails static anti-pattern catalog (N+1)
• references/static-checks-dotnet.md — .NET/EF Core static anti-pattern catalog (N+1)
• references/static-checks-react.md — React frontend re-render anti-pattern catalog
• references/static-checks-db.md — DB query-plan caution patterns (language-agnostic)
• references/static-checks-complexity.md — recursion/algorithmic complexity detection (language-agnostic, lizard)
• references/api-load.md — OpenAPI discovery + BASE_URL confirmation + openapi-to-k6/k6 + report standard