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.

/accelerate — Performance Profiling

Profile and optimize performance systematically. No optimization without measurement.

Scale /effort to the optimization scope: low for a single hot path, high for cross-cutting work.

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.

Establish a baseline measurement BEFORE making any changes. Optimization without a baseline is guesswork.

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 NEVER pause for permission. 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 (Edit/Write) and any git add/commit/push. See lore/autonomy.md.

Phase 2: Baseline

Measure current performance using the appropriate tool:

API:

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

Web (browser):

npx lighthouse http://localhost:3000 --output json --output-path baseline.json

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:

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, run them via the Monitor tool so results stream back as they finish 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.

Completion Signal

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