Accelerate

---
name: accelerate
description: Systematic performance profiling and optimization with a mandatory baseline-first gate — measure before changing, re-measure after. Use when something is slow or you need to hit a latency/throughput target.
allowed-tools: Read, Grep, Glob, Bash(kg query *), Bash(kg blast *), Bash(kg neighbors *)
argument-hint: "[what is slow] [target, e.g. p99<500ms]"
---

# /accelerate — Performance Profiling

Profile and optimize performance systematically. No optimization without measurement.

Scale [/effort](../../lore/models.md) to the optimization scope: low for a single hot path, high for cross-cutting work. (Haiku and the 4.5 generation have no effort axis at all — don't suggest a level there.)

Scope the work with the knowledge graph when the repo is indexed: `kg query "<slow area>"` to locate the hot code and `kg blast`/`kg neighbors` to see what it touches — so you profile and change the right thing, in fewer tokens than grepping.

<HARD-GATE>
Establish a baseline measurement BEFORE making any changes. Optimization without a baseline is guesswork.
</HARD-GATE>

## Process

### Phase 1: Define the Target

Ask both questions in one message:
> "Before I start profiling, two quick questions:
> 1. What specifically is slow? (page load, API response, query, computation — be as specific as possible)
> 2. What's the acceptable performance target? (e.g., 'under 200ms', 'p99 < 500ms')"

**End your turn. Wait for both answers before proceeding to Phase 2. Do not run any benchmarks until you have a defined target.**

## Autonomy — approve the plan, then run

After the Phase 1 gate (the two target answers — what's slow, and the acceptable target), run **Phases 2–5 autonomously**: reading, searching, `kg query`/`blast`, read-only git, and every profiling read, baseline, and benchmark go ahead without a confirmation question from you. Claude Code still shows its own permission prompt for commands this skill does not pre-approve (benchmarks, profilers) unless the session is in auto mode or the user already allowed them. After baseline + profiling, show the proposed **Phase 4 targeted fix** ONCE for approval; the bounded evaluator-optimizer loop then iterates without per-round prompts.

Re-gate **only** on real side effects — applying the fix (file edits) and any `git add`/`commit`/`push`. See [lore/autonomy.md](../../lore/autonomy.md).

### Phase 2: Baseline
Measure current performance using the appropriate tool:

**API:**
```bash
wrk -t4 -c100 -d30s http://localhost:8080/api/endpoint
# or: hey -n 1000 -c 50 http://localhost:8080/api/endpoint
```

**Web (browser):**
Use the Lighthouse CLI if it is already installed (or the project's own Lighthouse script):
```bash
lighthouse http://localhost:3000 --output json --output-path baseline.json
```

**Python:**
```python
import cProfile, pstats
profiler = cProfile.Profile()
profiler.enable()
# ... run the slow code ...
profiler.disable()
stats = pstats.Stats(profiler).sort_stats('cumulative')
stats.print_stats(20)
```

**Go:**
```go
import _ "net/http/pprof"
// Then: go tool pprof http://localhost:6060/debug/pprof/profile
```

Record baseline numbers.

### Phase 3: Profile to Find Bottleneck
Use the profiler to identify the actual bottleneck. The bottleneck is where the most time is spent — not the most obvious place.

### Phase 4: Targeted Fix
Fix ONLY the identified bottleneck. Common fixes:
- DB: add index, use JOIN instead of N+1, batch queries
- API: cache response, reduce payload size, move work async
- Frontend: code splitting, lazy loading, image optimization
- Computation: use better algorithm, vectorize, parallelize

### Phase 5: Measure Again
Run the same benchmark as Phase 2. Compare: baseline vs. optimized.

This is a **bounded evaluator-optimizer loop**: if the target isn't met, return to Phase 3 and attack the next bottleneck — but stop after a few rounds, when a round's marginal gain is negligible, or when the `/effort`/token budget is exhausted, then report the best result with the target marked met/not-met. Never loop indefinitely. For long benchmarks or load tests, start them with the Bash tool's background option and read the output when Claude Code reports the command finished, instead of blocking the turn.

## Circulate the result (optional)

For a result worth circulating, you can publish the baseline→optimized report as a Claude Code **Artifact** (a live page on claude.ai, team-co-editable on Team/Enterprise) — offer it, don't create it unprompted. Publishing to a **public** link (anyone with the URL can view it) is an outward sharing action: **confirm it, keep it account-private by default, and never expose proprietary/internal system detail or secrets to a public link.**

## Obstacles

If this skill runs as a dispatched unit (under /orchestrate, /weave, /manifest, /transmute, or another skill) and hits something that blocks or degrades the work, do not wait for a human who is not there and do not silently ship a degraded result — return an Obstacles block to the caller, alongside whatever you did complete:

```
STATUS: BLOCKED | DEGRADED | NEEDS_CONTEXT
OBSTACLE: <one-line label of what blocked or degraded the task — the claim alone>
BLOCKER: <the specific, actionable cause — distilled, never a raw traceback or dumped log>
SEVERITY: Critical | High | Medium | Low
WORKAROUND: <what you did to proceed and what it leaves unverified; empty if still fully blocked>
RECURRENCE: First-seen | Recurring | Systemic
SCOPE: <this task only | likely hits sibling/downstream work too>
NEXT: <the action or decision the caller must make to clear it — retry with X, supply input Y, accept degraded, or escalate>
```

When invoked interactively by a human, surface the same obstacle in prose instead. Omit the block entirely on a clean run. See [lore/obstacles.md](../../lore/obstacles.md).

## Completion Signal

"Accelerate complete. Baseline: <N>. Optimized: <N>. Improvement: <X>%. Target <met/not met>."