happier-profile-and-optimize
FeaturedThe method for profiling and optimizing anything whose success is a measured cost — frame the phase and metric, choose an instrument that can actually see the cost, label the waste, falsify the hypothesis with a cheap control before building a fix, and prove the result without over-claiming. Covers app/device and server/database work. Use when work is about slowness, jank, startup/open time, blocked JS, hangs, memory, render churn, a slow query, or a claimed speedup. It does not carry the write-time gotchas for UI code — those live in `apps/ui/AGENTS.md`.
Install
Quality Score: 95/100
Skill Content
Details
- Author
- happier-dev
- Repository
- happier-dev/happier
- Created
- 8 months ago
- Last Updated
- today
- Language
- TypeScript
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
performance-profiler
Systematically finds and fixes performance bottlenecks by measuring first, profiling hot paths, reducing algorithmic and I/O cost, and verifying gains with before/after benchmarks. Use this skill when code, an endpoint, a page, a query, or a job is "slow", "laggy", "timing out", "using too much CPU/memory", or "doesn't scale"; when asked to optimize, speed up, profile, or benchmark something; when chasing high latency / low throughput, p99 spikes, memory leaks, N+1 queries, or excessive allocations; or before/after a perf-sensitive change to prove it actually helped. Covers Python, Node/JS, Go, Java, SQL, and HTTP/web frontends.
performance-profiling-method
The measurement discipline for all performance work - establish a baseline, profile, identify the single dominant bottleneck, fix only that, then re-profile to prove the change. Use whenever anything is described as slow, laggy, stuttering, dropping frames, taking too long to load, or using too much memory, and before accepting any optimisation suggestion.
optimization
Measure-first performance optimization playbook — profiling discipline, bottleneck triage (CPU/memory/I/O), caching layers, and the algorithm/DB/frontend/network fix patterns. Use when the user reports something is slow ("dashboard takes forever", "API is laggy", "bundle is 2MB", "memory keeps growing"), asks to profile, benchmark, reduce latency/bundle-size, or fix N+1 queries — and to interpret the output of the /forge:optimize command or the `performance` agent.