arthai-marketplace

/perf

Run a performance optimization pass with a cross-functional team.

Synopsis

/perf [scope] [--backend-only] [--frontend-only] [--audit-only] [--deep]

When to use it

Quickstart

/perf

What you’ll see: a quick codebase scan, a mode prompt (audit / targeted / deep), then a prioritized performance audit — findings classified CRITICAL/HIGH/MEDIUM/LOW with file:line citations — followed by fixes and a validation report if you picked a fixing mode.

Examples

/perf                              # full codebase audit, mode chosen interactively
/perf GET /api/products --backend-only   # one endpoint: queries, caching, serialization
/perf --frontend-only              # bundle size, code splitting, images, Web Vitals
/perf src/api/routes/ --audit-only # read-only report, no code changes — fast and cheap
/perf --deep                       # full team + load tests/benchmarks, most thorough

Arguments & flags

Flag Values Default What it does
scope file, directory, feature, endpoint, all all What to audit/optimize
--backend-only off Limit to backend optimizations
--frontend-only off Limit to frontend optimizations
--audit-only off Report findings only — read-only, no code changes
--deep off Deep profiling: benchmarks and load tests if configured

What it does

  1. Gathers context — reads CLAUDE.md, the project profile, and past performance findings from the knowledge base so the audit is calibrated to your stack and stage.
  2. Quick scan — a cheap explore-light pass flags N+1 queries, unbounded queries, missing indexes, heavy bundles, missing caching/compression, and similar hotspots.
  3. Mode selectionuser-confirmation checkpoint: asks you to pick Audit (~15x cost), Targeted (~30x), Deep (~50x), or auto. Skipped if you passed --audit-only or --deep.
  4. Audit phase — performance lead profiles the critical path and produces a severity-tiered, file-cited report; the architect assesses scalability bottlenecks with stage-appropriate recommendations (no distributed-systems advice for early-stage projects).
  5. Optimize phase (Targeted/Deep only) — backend and frontend agents implement the CRITICAL/HIGH fixes from the audit, running tests, linters, and type checks after each change.
  6. Validate phase — QA runs the full test suite (plus load tests and bundle-size comparison when applicable) and reports any regressions.
  7. Report + continuation — aggregates everything into a final report, writes findings to the knowledge base, then presents a menu: [1] fix remaining items, [2] run /qa commit, [3] create PR (/pr), [4] deeper analysis (/perf {scope} --deep), [5] done for now. The pass isn’t “finished” until you pick one — the report alone doesn’t close it out. (Skipped if autopilot is active.)
  8. Completion verification — after you respond to that menu, a completion-verifier agent runs a separate spec/plan-compliance check (only meaningful if a plan/spec file exists for the scope) and prints PASS, GAPS FOUND, or INCONCLUSIVE. This does not re-measure performance — that validation already happened in the QA phase above.

Agents spawned

Agent Model tier Role
explore-light haiku Cheap hotspot scan before the team spins up
performance sonnet Leads the audit, prioritizes findings
architect sonnet Scalability assessment, stage-appropriate recommendations
backend sonnet Implements backend fixes (Targeted/Deep)
frontend sonnet Implements frontend fixes (Targeted/Deep)
qa sonnet Regression validation after optimization

Models shown are defaults, loaded from model-policy.yml. A project with a custom model-policy override will use different models for some or all of these roles.

After the continuation menu, a separate completion-verifier agent (sonnet) runs a spec/plan-compliance check — it’s not part of the main team and doesn’t validate performance itself.

Output & artifacts

Troubleshooting

Problem Fix
Run is expensive/slow for a quick question Use --audit-only or narrow the scope to a file or endpoint
Optimizations broke a test The QA validation phase reports it — fix before shipping, or revert the specific change
No load-test comparison in the report Load tests only run in Deep mode, and only if a load-test tool (k6, locust, etc.) is already set up in the project — /perf does not install or configure one for you
Findings ignore project-specific known-slow patterns Run /calibrate first so the team inherits project knowledge

Context management

/perf can accumulate a lot of context — profiling output, benchmark data, and optimization proposals from multiple agents — especially after a --deep or full-codebase run. After the report, the skill prints a tip block to help you decide what to do next: