一键导入
performance-optimization
Profile before optimizing; optimize with evidence, not intuition
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Profile before optimizing; optimize with evidence, not intuition
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
| name | performance-optimization |
| description | Profile before optimizing; optimize with evidence, not intuition |
| difficulty | senior |
| domains | ["general"] |
Performance optimization without profiling is guessing. This skill enforces: measure first, optimize the bottleneck, measure again. It prevents wasted effort on non-bottlenecks and ensures optimizations don't regress correctness.
/review workflow for latency-sensitive pathsBefore touching any code, record: current p50/p95/p99 latency, throughput, error rate under representative load. Without a baseline, you can't prove improvement.
Run a profiler, not your intuition:
The bottleneck is almost never where you think it is.
The single slowest operation in the critical path. Fix that first. Do not optimize non-bottlenecks.
Create a benchmark that isolates the bottleneck and can be run repeatedly. This is your before/after comparison.
Common patterns:
Run the benchmark before and after. Calculate: % improvement in p99, % reduction in resource usage. If the improvement is not measurable, the optimization was not worth the complexity.
Run the full test suite. Performance optimizations frequently introduce bugs.
Record: what was slow, why, what was done, and the measured improvement. Future engineers will need to understand why this code looks unusual.
"I know this is slow — I don't need to profile" Everyone thinks they know where the bottleneck is. Profilers are always more accurate than intuition.
"This optimization is obvious — I don't need a benchmark" Without a benchmark, "obvious improvement" is also "unmeasured claim."