The skill that edits its own instructions
Self-editing skills, the ecosystem racing to build them, and the flywheel that makes any of it compound.
One of the routines I run a few times a day rewrote a line of its own instructions this week, and I let it.
The routine checks on a fleet of small agents I keep running, fixes what it knows how to fix, and flags the rest for me. The new part is the last step. Before it signs off, it reads back over the run and asks one question: what did this teach me that my instructions did not already cover? When the answer is real, it edits the checklist it works from, so the next run starts a little smarter.
It did not change the model. It changed its skill, the separate written set of instructions a tool loads when the task comes up. I thought this was a clever trick I had built. Then I went looking, and found half the field had built it too.
Why skills are the unit
A skill is less exotic than it sounds. It is a written set of instructions, plus any helper files, that an assistant pulls off the shelf when a task matches: a checklist for triaging your inbox, a runbook for closing the monthly books, the house style your team writes in. Claude Code keeps each one in its own folder and loads it only when it is relevant.
Here is why it reaches anyone who does not write code. The model is rented, and it gets swapped for a better one every few months. The skill is the part you own. It is where your specific know-how lives, the institutional memory that survives the upgrade. Most teams pour that knowledge into documents nobody opens twice. A skill is the same knowledge in a form the assistant actually uses, every time the work comes up. And it has crossed from a Claude Code feature to an open standard: the same plain-text file now runs across Codex, Cursor, Copilot, and more than thirty other tools.
My clever trick wasn't clever
So I swept the last thirty days to see who else was doing this. The answer was humbling and useful: nearly everyone.
The pattern I thought I invented is written up as a recipe, a reflection step that runs after a skill is used, asks whether it helped, and proposes an edit to its own file. Anthropic's own skill builder does a sharper version, splitting your examples into train and test sets and keeping only the change that scores better on the held-out half. Microsoft's SkillOpt tunes a skill's written instructions the way you would train a model, and its standout result is the one I care about: a skill tuned inside one tool kept almost all of its gain when they moved it to another. The know-how lived in the skill, not the software. It is already shipping inside products that crystallize skills as you work.
The thing I built to make my own setup compound turned out to be a pattern the whole field is converging on. My problem was not unique, which is exactly why the answer is worth keeping.
The scale is the real headline. One directory has now scraped 1.6 million of these skill files off public GitHub, up from the roughly 790,000 a research team catalogued six months ago. Which is also the catch.
What's oversold
Two things to hold back on, both visible in that same sweep.
The flood is real, and most of it is noise. The ecosystem went from empty to crowded in about six months, and the directories admit most skills barely trigger or quietly burn context. A skill that edits itself inside that flood does not automatically improve. It compounds whatever it already was, noise included, unless you gate the edits.
Write-once-run-everywhere is also sold harder than it ships. The open standard is real, but the formats are still converging, not interchangeable. A skill that sings in one tool can stumble in the next.
Why this is worth watching
I have written before that the real skill is delegation, not automation, knowing what to hand off and when to step back in. A skill that edits itself is the next turn of that screw, and the sweep handed me the guards that separate the durable version from the noise. Don't edit on a fluke: a problem has to recur before it earns a permanent change. Prove the new rule works: the added check has to catch the thing it was written for before it stays. Never re-add what you deleted. None of that is exotic. It is what you would want from a sharp junior teammate keeping the runbook current.
That loop is the real point, and it is bigger than skills. I write up something I think is clever, sweep the field to find the dozen people who already hit it, take the best of what they worked out, fold it back into my own setup, and share the result forward. The writing and the searching are not separate from the building. They are how the building compounds. This post is that loop turning once.
The systems getting the press rewrite their own code against a scoreboard. The skills that will run your operations next year just keep better notes, in a file you can read, borrow the best ideas from everyone else, and get a little sharper every time they run.
Around the Corner: short reviews of ideas worth watching. Opt-in section, not part of the weekly Run Data Run email. [Subscribe to the main list](https://rundatarun.io/subscribe) for longer essays.Subscribe to the main list for longer essays.*