Targeted Performance Fix
Make a measured, targeted performance improvement — profile to find the real bottleneck, optimize it, then prove the speedup with before/after numbers while keeping behavior correct. Profiles FIRST and locks a measurable target, because optimizing without measuring is guessing, then applies the focused change, then a reviewer confirms the improvement is real, behavior is unchanged, and the code is not needlessly obfuscated. Covers profiling/benchmarking, hotspot identification, algorithmic vs micro optimization, before/after measurement, and correctness-preserving speedups.
Steps
Entry step: profile. Each step names the specialist role it wants; the full working prompt is expandable.
- Profile and targetdeveloperentry
measure the bottleneck, lock a numeric target
Show working prompt
Measure before you optimize — optimizing without profiling is guessing. Step 1: Establish a representative workload/benchmark and record the BASELINE numbers (time, memory, or the relevant metric). Step 2: Profile to find where the time actually goes; identify the single biggest hotspot rather than guessing. Step 3: Form a hypothesis for WHY it is slow (algorithmic complexity, repeated work, allocation, IO) and what change should help. Step 4: Lock a measurable target (e.g. 'cut p50 latency by 2x', 'O(n^2) → O(n log n)'). Step 5: Write a numbered acceptance-criteria checklist of 4-7 items (e.g. 'the benchmark improves by the target amount', 'output is identical to baseline on the test inputs', 'the change targets the profiled hotspot', 'no new correctness regressions'). `write_task_note` the baseline numbers + hotspot + target + checklist and write the same to the produces path.
- Optimize the hotspotdeveloper
apply the focused change, re-measure
Show working prompt
Apply the optimization to the profiled hotspot. Step 1: Make the focused change your hypothesis called for — prefer algorithmic wins (better data structure, removing repeated work, caching) over fragile micro-tweaks. Step 2: Re-run the same benchmark and record the AFTER numbers; confirm the target is hit. Step 3: Confirm output is byte-for-byte identical to baseline on the test inputs — speed that changes results is a bug. Step 4: Keep the code readable; do not obfuscate for marginal gains. Write the optimized source to the produces path. On a loop-back, address only the reviewer's concern. `write_task_note` the before/after numbers and which criteria now pass.
- Verify the speedupreviewer
confirm real improvement, unchanged output
Show working prompt
Verify the optimization is real and safe. Step 1: Re-run the benchmark and confirm the measured improvement meets the target (and is not noise — run it a few times). Step 2: Confirm output is identical to the baseline on the test inputs (correctness preserved). Step 3: Confirm the change actually addressed the profiled hotspot rather than a different spot. Step 4: Confirm the code remains readable and maintainable. Write a verification note with the before/after numbers and a correctness confirmation to the produces path.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Run the benchmark and a correctness check. For EACH acceptance criterion: confirm the measured speedup meets the target and is reproducible (not noise), confirm output is identical to baseline on the test inputs, confirm the change targeted the profiled hotspot, and confirm no correctness regression. Write PASS/FAIL per criterion with the before/after numbers; output that changed is an automatic FAIL. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "optimize" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- optimize performance
- make this faster
- fix a slow function
- profile and optimize
- reduce latency
Source
View this craftbook on GitHub · MIT license