cold-start-optimizerlisted

A cold start is not one number — it is runtime boot, dependency/module load, framework init, and first-connection setup stacked on top of each other, and you are usually optimizing a guess about which one dominates. This skill makes it measured: split the init into phases, find the phase that actually costs you, and attack *that* — shrink the artifact and lazy-load the heavy deps off the first-request path, hoist one-time work to module scope so warm invocations reuse it, right-size memory (more CPU often means a *faster and cheaper* cold start), and reuse connections across invocations instead of opening a fresh one every cold start. Provisioned concurrency / keep-warm is the last resort for genuinely latency-critical paths, not the first reflex — because it bills you to mask a slow init rather than fixing it. ## When to use this skill - Serverless p99 (or p999) spikes on the first request after a quiet period, while warm requests are fast. - A function intermittently times out *during init* — before your handler code even runs. - Scale-to-zero or aggressive autoscaling is hurting user-facing latency on a path that can't tolerate a 2–5s tail. - You've been told to "just turn on provisioned concurrency" and want to know whether the init is fixable first (and cheaper). - A deploy bloated the artifact (new dependency, bundling change) and cold starts regressed. ## Instructions 1. **Measure the cold start and split it into phases — don't optimize a guess.** Force a cold star