flamegraph-analyzerlisted

When code is slow and CPU-bound, the most expensive thing you can do is guess. Intuition about "the slow part" is wrong often enough that optimizing it usually buys nothing while the real hotspot sits untouched. A flamegraph answers the question directly — *which frames are actually burning CPU* — but only if you capture it under a realistic workload and read it correctly. This skill does both: it gets a representative sampling profile, reads width as time and the y-axis as depth (not a timeline), pins the hotspot to the widest self-time leaves, classifies the work as unnecessary / redundant / algorithmically wrong, fixes the biggest contributor, and re-profiles — because the bottleneck always moves after a fix, and your intuition about the new one is just as unreliable. ## When to use this skill - A request, job, or function is slow, CPU usage is high, and you don't know which part of the call tree is responsible. - You have a profile or flamegraph SVG but can't tell where the time is going or whether you're reading it right. - Something is "obviously" slow and you're about to optimize the part you suspect — stop and confirm it with a profile first. - A hot path got optimized and got no faster, or only a little — the real bottleneck was elsewhere and you need to find it. - You want to know whether the latency is *computation* (on-CPU) or *waiting* (I/O, locks) before you pick where to spend effort. ## Instructions 1. **Capture a profile under a realistic workload with a