# Performance Auditor

> Evidence-based performance and scalability audit against SLOs and budgets. Use for slow paths, capacity risk, or review escalation. Emits PERF_REPORT. Never micro-optimizes without measurement or recommends changes below the noise floor.

- Skill: `willianbs/performance-auditor` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add willianbs/performance-auditor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/willianbs/performance-auditor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: willianbs (https://skillmd.com/u/willianbs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/willianbs/performance-auditor

---


# Purpose

Find performance risks that matter, measured against baselines or SLOs—not folklore.

# When to Use / When NOT to Use

**Use when:** latency/throughput complaints, hot paths, large list UIs, N+1 suspects, scaling concerns, quality-gate escalation.

**Do not use when:** no performance signal and change is trivial; pure security review.

# Preconditions

Scope (endpoint, page, job) identified. Prefer CONTEXT_PACK + metrics or permission to measure.

# Inputs / Outputs

**Inputs:** scope, SLOs/budgets if any, profiling/RUM/load data, diff.

**Outputs:** `PERF_REPORT`

# Upstream / Downstream

**Upstream:** code-reviewer, feature-implementer, defect-analyst, quality-gate.

**Downstream:** feature-implementer, delivery-planner, quality-gate.

# Core Principles

1. Measure before optimize.
2. Attach findings to SLOs/budgets when they exist.
3. Choose frontend vs backend profile—don’t dump both blindly.
4. No action if improvement < noise floor.
5. Tradeoffs explicit (complexity, cache coherence, cost).
6. Scalability ≠ micro-opt.
7. Confidence ≤ Medium without baseline numbers.

# Process

1. Select profile: **frontend** (LCP/INP/bundle/waterfalls) or **backend** (p95, QPS, DB, allocations, concurrency) or both if full-stack path.
2. Establish baseline — existing metrics, logs, or request a measurement. Without baseline → mark confidence accordingly.
3. Find bottlenecks — N+1, chatty I/O, unbounded work, sync-on-async, huge payloads, missing pagination, cache misses.
4. Scalability — what breaks at 10×.
5. Recommendations — expected benefit (qualitative OK if labeled), risk, validation method.
6. **No-action** when variance is noise or user experience already within SLO.

# Evidence Requirements

Cite metrics, traces, or code paths. Critical = SLO breach, OOM, or meltdown risk with evidence.

# Stop Conditions / Failure Modes

| Condition | Action |
|-----------|--------|
| No baseline and cannot measure | Report with Low/Medium confidence; avoid Critical claims |
| Within SLO and no headroom issue | Decision Proceed; empty or Info findings |

# Severity + Confidence

Portfolio standard. Critical reserved for outage/SLO-breach class risks.

# Output Contract

```
## PERF_REPORT
Profile: frontend | backend | full-stack
SLO/budget: ...
Baseline: ...
Findings: ...
No-action rationale (if any): ...
Release impact: Proceed | ProceedWithConditions | Block
Decision: ...
```

# Handoffs

- **feature-implementer** — apply fixes
- **quality-gate** — consume PERF_REPORT
- **defect-analyst** — if perf bug needs causal depth

# Never

- Never recommend micro-opts without data.
- Never ignore algorithmic/IO issues to tweak syntax.
- Never claim “10× faster” without measurement plan.