Skills drift.

You teach an AI assistant how to do something, it works, you move on. Six months later, that same “skill” gives you a different answer — because someone edited a copy, or a dependency shifted underneath it, or four different people each tweaked their own version and never told each other. The name of the skill stays the same. What it actually does does not.

That’s not hypothetical. I watched one bad instruction produce five separate wrong answers, across different tools and different AI agents, before anyone realized it was the same mistake wearing different clothes each time. Nothing announced it. Every copy looked fine on its own.

The uncomfortable part: if AI assistants everywhere start relying on shared “skills” like this, quiet drift is the real risk — not some sci-fi AI takeover, just a slow loss of agreement about what a given instruction actually does, with no easy way to check.

So I wanted a way to catch it. A backup that works even if everything around it gets messy.

The idea

My approach treats a capability as one portable file with a clear job — drop it in a folder, it runs, no setup required.

This pattern goes one step further: it puts the working code inside the plain-English instructions themselves, so the document explaining what a skill does is also, literally, the thing that does it. It reads like a normal explanation to a person, and it can also run directly as working code. There’s no second, separate copy sitting somewhere else that could quietly drift out of sync — because there’s only one copy, period.

The real benefit isn’t for me. It’s that anyone can pick up that one file, with no special setup on their end, and get the exact same behavior I do.

That’s the claim. A claim is worth nothing until you test it, so I tested it.

Putting it to the test

I built the same capability two ways: the normal way (spread across several files) and the “one file” way described above. Then I ran both versions dozens of times, side by side, and compared the results byte for byte.

Every single time, both versions produced identical output. Not “close enough” — identical.

Then I deliberately broke it: I edited the normal, spread-out version in place, the way an innocent well-meaning edit usually happens. Its output changed, as expected. The single-file version’s output did not change at all — and, importantly, the mismatch between the two was easy to spot immediately, instead of surfacing months later when two AI agents quietly disagree about what a rule says.

That’s the whole value, proven rather than assumed: one copy stayed trustworthy, and when the other one drifted, it was obvious right away.

What it costs

Honestly, some convenience. A single file can get long, and you lose the ability to test small pieces of it separately. Mine landed at a comfortable size — ten times longer would start to hurt.

I also hit a real bug while building this, worth naming because it’s exactly the kind of thing that quietly erodes trust: embedding code inside a plain-text document accidentally mangled a couple of special characters, so two of five commands printed a broken symbol instead of a proper line break. The other three were fine, because they happened to be built slightly differently.

A quick spot-check of just one command would have missed it and shipped it broken. Only checking every single case caught it — which is the same lesson every time: the check itself can be wrong too, and nobody double-checks the checker.

The pattern, stated plainly

Ship a capability as one self-contained, readable document. If the surrounding ecosystem holds up over time, you’ve lost nothing. If it drifts, you have one clearly labeled, trustworthy copy that makes the drift obvious instead of invisible.

It’s a cheap insurance policy against a quiet, slow-moving risk — and so far, it’s the best way I’ve found to share something’s strengths with people who have no interest in adopting my whole system, just the one useful piece.

It’s the same lesson at the heart of The Buzzsaw: the thing meant to keep you honest can quietly become the thing you stop questioning.

Update: it holds up beyond one example

One capability working this way could be a fluke. So I automated the conversion process — turning a normal, spread-out capability into the “one file” version automatically, and refusing to finish if even a single byte comes out different — and tried it on two more capabilities.

All three matched perfectly, every time, without needing anyone to hand-check the conversion. That the conversion itself is automatic matters more than any individual result — if a person had to convert each one by hand, that manual step would become a brand-new place for drift to sneak back in, which defeats the whole point.

One test along the way even reported a false alarm — the two versions looked “different” only because of an unrelated quirk in how I’d named the test files, not because the actual code differed. Worth mentioning honestly: that’s now the eighth time in this stretch of work that a reported failure turned out to be a flaw in the test itself, not the thing being tested. I’ve started treating that as the normal rate, not a fluke — which is exactly why checking your checks matters as much as checking your code.

Every number in this post comes from a script anyone could re-run, and it fails loudly if the equivalence claim doesn’t hold. If it had failed, this post would say so.