$npx -y skills add DevelopersGlobal/ai-agent-skills --skill performance-optimizationMeasure first, optimize second. Data-driven performance improvements with before/after benchmarks and production validation.
| 1 | ## Overview |
| 2 | |
| 3 | Premature optimization is the root of all evil. But ignoring performance until it's a crisis is equally harmful. This skill enforces data-driven optimization: profile first, optimize the bottleneck, measure the improvement. |
| 4 | |
| 5 | ## When to Use |
| 6 | |
| 7 | - When performance issues are reported in production |
| 8 | - Before optimizing any code (to ensure you're optimizing the right thing) |
| 9 | - When reviewing changes that touch performance-sensitive paths |
| 10 | |
| 11 | ## Process |
| 12 | |
| 13 | ### Step 1: Measure the Baseline |
| 14 | |
| 15 | 1. Reproduce the performance issue reliably. |
| 16 | 2. Measure current performance: latency p50/p95/p99, throughput, memory, CPU. |
| 17 | 3. Profile to find the actual bottleneck — not where you think it is. |
| 18 | 4. Write the performance test you'll use to validate improvement. |
| 19 | |
| 20 | **Verify:** You have concrete baseline numbers, not gut feelings. |
| 21 | |
| 22 | ### Step 2: Identify the Real Bottleneck |
| 23 | |
| 24 | 5. Use profiling tools: flame graphs, CPU profiles, memory profiles. |
| 25 | 6. Find the top 3 hotspots by actual execution time (not lines of code). |
| 26 | 7. The bottleneck is rarely where you expect it to be. Trust the data. |
| 27 | |
| 28 | **Verify:** Bottleneck identified by profiling data, not assumption. |
| 29 | |
| 30 | ### Step 3: Optimize Only the Bottleneck |
| 31 | |
| 32 | 8. Fix only the profiled bottleneck — nothing else. |
| 33 | 9. Common optimizations by type: |
| 34 | - **CPU**: Algorithmic improvement (O(n²) → O(n log n)), caching, batching |
| 35 | - **Memory**: Streaming instead of buffering, object pooling, lazy loading |
| 36 | - **I/O**: Connection pooling, N+1 query elimination, caching, async/parallel calls |
| 37 | - **AI**: Prompt caching, batch inference, smaller models for simpler tasks |
| 38 | |
| 39 | **Verify:** Change targets the profiled bottleneck, not speculative improvements. |
| 40 | |
| 41 | ### Step 4: Measure the Improvement |
| 42 | |
| 43 | 10. Run the same performance test from Step 1. |
| 44 | 11. Compare before vs. after metrics. |
| 45 | 12. If improvement < 20%: the optimization may not be worth the complexity. |
| 46 | |
| 47 | **Verify:** Improvement measured with the same test harness as baseline. |
| 48 | |
| 49 | ## Common Rationalizations (and Rebuttals) |
| 50 | |
| 51 | | Excuse | Rebuttal | |
| 52 | |--------|----------| |
| 53 | | "I know where the bottleneck is" | You're probably wrong. Profile first. | |
| 54 | | "This is clearly slow" | "Clearly slow" rarely matches profiler output. Measure. | |
| 55 | | "We'll optimize later" | If it's slow enough to mention, it's slow enough to measure now. | |
| 56 | |
| 57 | ## Verification |
| 58 | |
| 59 | - [ ] Baseline metrics captured before any optimization |
| 60 | - [ ] Bottleneck identified by profiler (not assumption) |
| 61 | - [ ] Optimization targets only the profiled bottleneck |
| 62 | - [ ] Improvement measured with same test harness |
| 63 | - [ ] Before/after numbers documented |
| 64 | |
| 65 | ## References |
| 66 | |
| 67 | - [references/performance-checklist.md](../../references/performance-checklist.md) |
| 68 | - [observability skill](../observability/SKILL.md) |