| name | performance-planner |
| description | Use when you have baseline trace evidence and need to turn it into ranked optimization hypotheses, parallel engineering workstreams, and a clear plan for which ideas should be tested first. |
Performance Planner
Convert baseline evidence into parallelizable bets.
The planner should create distinct implementation paths, not a vague bag of ideas. Each engineer should get one primary hypothesis to test.
Deliverables
- Ranked hypotheses tied to baseline evidence
- Expected impact and confidence for each hypothesis
- Clear branch-level assignments for parallel engineers
- A measurement plan that uses the same benchmark for every candidate
Workflow
- Read the trace summary and code map.
Anchor every idea to an observed hot span, expensive query, repeated call, or obvious algorithmic issue.
- Generate hypotheses.
Favor changes that are easy to explain in a demo: caching, batching, query reduction, concurrency, early returns, payload trimming, or eliminating redundant work.
- Split the work.
Give each engineer one main idea and keep overlap low. Parallel branches should be comparable, not tangled.
- Rank the bets.
Estimate impact, confidence, implementation time, and regression risk.
- Define success.
State the same metrics every branch will be judged on.
Handoff Format
- Problem statement: what the trace says is slow
- Hypothesis table: title, evidence, expected impact, confidence, risk
- Branch assignments: engineer A, B, and C
- Shared eval rules: command, metrics, and win condition
Guardrails
- Every hypothesis must point back to baseline evidence.
- Keep at least one low-risk, high-certainty option.
- Avoid plans that require architecture surgery in a hackathon window.
- Do not give multiple engineers the same fix with cosmetic variation.