← ClaudeAtlas

performancelisted

Use when a task has efficiency requirements or touches a hot path — make performance a measured requirement (benchmarks as tests, budgets as gates), keep interfaces clean and optimizations local, and version the WHY so future agents don't "clean up" fast code back to slow.
HECer/yoke · ★ 2 · API & Backend · score 75
Install: claude install-skill HECer/yoke
# Performance (measured, not vibed) "Efficient" is a requirement, not a code style. Untested performance claims rot exactly like untested behavior claims. This skill makes efficiency mechanical — the same move Yoke makes for everything else. ## The decision ladder 1. **Default: clean + minimal.** For ~90% of code, the `minimal-code` rules ARE the performance strategy — less code, fewer layers, no speculative abstraction. Do not micro-optimize code that no measurement flagged (premature optimization). 2. **Performance requirement? Make it an acceptance criterion.** A number, not an adjective: - Good: "imports 1M rows in < 2s", "p95 request latency < 50ms in the bench test", "no allocation inside the render loop (verified by the bench assertion)" - Bad: "should be fast", "optimize the importer" 3. **Whole-project budget? Use the perf gate.** Set `perf.command` in `.yoke/config.yaml` (a benchmark script; exit 0 = within budget). The loop runs it after verify — a story that breaks the budget is blocked, no matter how clean its diff is. ## Writing efficient code that agents can maintain - **Clean at the boundaries, aggressive in the leaves.** Interfaces, data flow, and names stay simple and obvious. Optimization lives inside a few clearly-bounded leaf functions whose contracts are pinned by tests. An ugly-fast function is maintainable; an ugly-fast architecture is not. - **Profile before optimizing.** Find the actual hot 5% (a profiler, a timing h