/performance-optimization
Measure first, optimize second. Data-driven performance improvements with before/after benchmarks and production validation.
$ npx -y skills add DevelopersGlobal/ai-agent-skills --skill performance-optimization --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/performance-optimization
Context preview
The summary Claude sees to decide when to auto-load this skill.
Measure first, optimize second. Data-driven performance improvements with before/after benchmarks and production validation.
SKILL.md
performance-optimization.SKILL.mdname: performance-optimization
description: Measure first, optimize second. Data-driven performance improvements with before/after benchmarks and production validation.
category: review
applies-to: [claude, gemini, cursor, copilot, any]
version: 1.0.0
Overview
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.
When to Use
- When performance issues are reported in production
- Before optimizing any code (to ensure you're optimizing the right thing)
- When reviewing changes that touch performance-sensitive paths
Process
Step 1: Measure the Baseline
1. Reproduce the performance issue reliably. 2. Measure current performance: latency p50/p95/p99, throughput, memory, CPU. 3. Profile to find the actual bottleneck — not where you think it is. 4. Write the performance test you'll use to validate improvement.
**Verify:** You have concrete baseline numbers, not gut feelings.
Step 2: Identify the Real Bottleneck
5. Use profiling tools: flame graphs, CPU profiles, memory profiles. 6. Find the top 3 hotspots by actual execution time (not lines of code). 7. The bottleneck is rarely where you expect it to be. Trust the data.
**Verify:** Bottleneck identified by profiling data, not assumption.
Step 3: Optimize Only the Bottleneck
8. Fix only the profiled bottleneck — nothing else. 9. Common optimizations by type:
- **CPU**: Algorithmic improvement (O(n²) → O(n log n)), caching, batching
- **Memory**: Streaming instead of buffering, object pooling, lazy loading
- **I/O**: Connection pooling, N+1 query elimination, caching, async/parallel calls
- **AI**: Prompt caching, batch inference, smaller models for simpler tasks
**Verify:** Change targets the profiled bottleneck, not speculative improvements.
Step 4: Measure the Improvement
10. Run the same performance test from Step 1. 11. Compare before vs. after metrics. 12. If improvement < 20%: the optimization may not be worth the complexity.
**Verify:** Improvement measured with the same test harness as baseline.
Common Rationalizations (and Rebuttals)
| Excuse | Rebuttal | |--------|----------| | "I know where the bottleneck is" | You're probably wrong. Profile first. | | "This is clearly slow" | "Clearly slow" rarely matches profiler output. Measure. | | "We'll optimize later" | If it's slow enough to mention, it's slow enough to measure now. |
Verification
- [ ] Baseline metrics captured before any optimization
- [ ] Bottleneck identified by profiler (not assumption)
- [ ] Optimization targets only the profiled bottleneck
- [ ] Improvement measured with same test harness
- [ ] Before/after numbers documented
References
- [references/performance-checklist.md](../../references/performance-checklist.md)
- [observability skill](../observability/SKILL.md)
Read more
name: performance-optimization description: Measure first, optimize second. Data-driven performance improvements with before/after benchmarks and production validation. category: review applies-to: [claude, gemini, cursor, copilot, any] version: 1.0.0
Overview
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.
When to Use
- When performance issues are reported in production
- Before optimizing any code (to ensure you're optimizing the right thing)
- When reviewing changes that touch performance-sensitive paths
Process
Step 1: Measure the Baseline
1. Reproduce the performance issue reliably. 2. Measure current performance: latency p50/p95/p99, throughput, memory, CPU. 3. Profile to find the actual bottleneck — not where you think it is. 4. Write the performance test you'll use to validate improvement.
**Verify:** You have concrete baseline numbers, not gut feelings.
Step 2: Identify the Real Bottleneck
5. Use profiling tools: flame graphs, CPU profiles, memory profiles. 6. Find the top 3 hotspots by actual execution time (not lines of code). 7. The bottleneck is rarely where you expect it to be. Trust the data.
**Verify:** Bottleneck identified by profiling data, not assumption.
Step 3: Optimize Only the Bottleneck
8. Fix only the profiled bottleneck — nothing else. 9. Common optimizations by type:
- **CPU**: Algorithmic improvement (O(n²) → O(n log n)), caching, batching
- **Memory**: Streaming instead of buffering, object pooling, lazy loading
- **I/O**: Connection pooling, N+1 query elimination, caching, async/parallel calls
- **AI**: Prompt caching, batch inference, smaller models for simpler tasks
**Verify:** Change targets the profiled bottleneck, not speculative improvements.
Step 4: Measure the Improvement
10. Run the same performance test from Step 1. 11. Compare before vs. after metrics. 12. If improvement < 20%: the optimization may not be worth the complexity.
**Verify:** Improvement measured with the same test harness as baseline.
Common Rationalizations (and Rebuttals)
| Excuse | Rebuttal | |--------|----------| | "I know where the bottleneck is" | You're probably wrong. Profile first. | | "This is clearly slow" | "Clearly slow" rarely matches profiler output. Measure. | | "We'll optimize later" | If it's slow enough to mention, it's slow enough to measure now. |
Verification
- [ ] Baseline metrics captured before any optimization
- [ ] Bottleneck identified by profiler (not assumption)
- [ ] Optimization targets only the profiled bottleneck
- [ ] Improvement measured with same test harness
- [ ] Before/after numbers documented
References
- [references/performance-checklist.md](../../references/performance-checklist.md)
- [observability skill](../observability/SKILL.md)
AI agent skills for production grade applications
Other skills on ai-agent-skills.
- /ai-output-validation
Validates, parses, and sanitizes AI-generated outputs before they reach end users or downstream systems. Structured output enforcement, schema validation, and fallback handling.
Open skill - /api-design
Design stable, versioned, self-documenting APIs. Easy to use correctly, hard to use incorrectly. Apply Hyrum's Law from day one.
Open skill - /ci-cd-pipelines
Automated quality gates from commit to production. Every merge to main is potentially shippable. No manual steps in the deployment path.
Open skill - /code-explanation
Get layered, context-aware explanations of unfamiliar code. Understand what it does, why it was written that way, and how to work with it safely.
Open skill - /code-review
Structured code review focusing on correctness, security, and maintainability. Correctness before style. Every reviewer comment must be actionable.
Open skill - /context-loading
Load minimum necessary context into agent context windows. Prevents token bloat, reduces cost, and improves focus. Only load what the current task needs.
Open skill

