anneallisted

# /anneal — Measure Before You Commit A lightweight discipline: at a fork, explore a few directions and let a **cheap measurement** pick the winner, before you invest in the expensive build. Named for simulated annealing (explore, then converge) — but it is a checklist you run inline, not an engine you launch. ## 1. When to run Only when the user types `/anneal`. Never auto-invoke. Run it at a **decision fork where the best approach is not obvious** — and run it **cheap and early**, before significant effort goes into any one direction. - **Skip it when the direction is obvious** (e.g. an O(n) hash-set plainly beats an O(n²) loop). Measuring obvious choices is pure overhead — just build it. - **Use it when your intuition might be wrong** — competing approaches where only a measurement can say which wins (cache vs. better algorithm vs. precompute; table vs. graph; index vs. denormalize). ## 2. The two oracles — the rule this skill exists to enforce There are two different scorers, and conflating them is the failure mode: 1. **Direction-fitness oracle** — answers *"which direction is better?"* It must be **measurable and task-based**: a benchmark number, a test pass-rate, coverage, or for taste targets an operationalized task ("clicks to find an orphan node"). This, and only this, picks the direction. It should also expose an **improvement surface**: the weak rows/questions that tell you what to improve next, not just a vague "good/bad" verdict. 2. **Polish rubric** — a