self-extensionlisted

# Self-extension Two things bring you here: a capability gap that sourcing could not fill, or a session that went unusually well - a deliverable markedly better than usual is itself the signal to interrogate the run (what did you consider, how did you verify, why did this actually work) and mine it before its context is gone. Either way you author one new skill from what you understand, and only let it reach the live tree once it has passed a check and an explicit yes. There is no distillation engine - you gather the sources and write the `SKILL.md` with the tools you already have, so this runs the same on any harness. Creating is the fallback, not the first move. `/tool-sourcing` hands off here only after discovery, vetting, and try-before-adopt all came up empty; a proven, installed skill beats a fresh one every time. Carry the gap line and the vetting note across - they are the spec for what to build. Read `.better-dev/overrides.md` first and honor any project override - a repo may pin where skills live, forbid new ones, or already name the shape it wants. ## 1. Earn the create Two questions gate whether to author anything, and they run before you write a line. **Is the lesson durable?** A skill is a standing instruction the agent carries for months, so a transient truth hardens into a self-imposed constraint that bites later. Don't encode a passing "X is broken", an environment or setup failure someone can fix, or a one-off task narrative - capture the *fix* (the in