update-skilllisted

# Update Skill Improve a skill from **batched feedback**, not from a single complaint. Treat skills like code: they drift, and they earn maintenance only when enough signal has accumulated to see the real pattern. The failure mode this skill exists to prevent is **monkey-patching**: addressing each report independently until the skill is a pile of special cases that miss the broader picture. The fix is to wait, cluster, reflect, then make one coherent change. ## Named heuristics Use these by name when you reason out loud with the user. - **Two-data-point rule.** You would not extract an abstraction because you did something twice. Do not reshape a skill on one or two reports. Wait for a third independent signal before treating something as a pattern. - **Batch window.** Let feedback accumulate for a few days to a week before acting. Reacting per-comment overfits to noise. - **Monkey-patch test.** Before writing an edit, ask: "Does this fix one report, or the class of reports behind it?" If it only fixes the instance, you are patching, not improving. Go back up a level. - **EM-coaching reflection.** Interpret feedback the way a good engineering manager coaches a report: identify what went wrong, look for patterns, ask why, self-reflect, zoom out, check against the skill's stated principles. Then, and only then, edit. Full rubric in [REFLECTION.md](REFLECTION.md). - **Terseness ratchet.** Every edit must leave the skill as tight as it found it. If a change adds lines, look