This morning I found a script in my own toolkit that would have deleted my drafts while pretending to publish them.
I found it because I ran it. Not because I read it.
That distinction is the whole argument of this post. I had run that script probably twenty times over the past month, and every single run was fine — right up until the day it wasn't, and by then it was holding a loaded gun pointed at my work.
What was in the drawer
While cleaning up the publishing toolkit for this blog, I opened three things I'd stopped looking at. All three were broken. None of them had ever told me.
The deploy script. It shelled out to sudo to copy files into place — but without the flag that makes Python treat a non-zero exit as an error. Then, a few lines later, it deleted the source draft. Unconditionally. So the sequence was: try to copy, ignore the outcome, delete the original. On this box that copy always fails, because a subprocess can't answer a sudo password prompt. The script was therefore not "sometimes risky". It was a machine that destroyed the source file on every run, and the only reason it hadn't destroyed anything is that I'd stopped using it.
Worse, it was pointed at a world that no longer exists. It created numbered folders in a format that has zero instances on disk. It wrote post content to a filename the theme doesn't read. It rebuilt a listing on a page that isn't the listing page. Every path in it was confidently wrong.
The listing script. This one I ran, live, to test it. It died immediately:
IndexError: list index out of rangeIt split folder names on a dot to separate a numeric prefix from the rest. That worked when folders were named 03.2026-08-04-slug. Folders are no longer named that way — so on every current post, the split returns one element, the script asks for the second, and it crashes. It had a 100% failure rate against current data and I would not have known without running it.
The documentation. The same skill carried a reference file that described the publishing procedure. It told you to set a page to visible in order to publish it — a change that, on today's site, pushes the post into the navigation menu, which is exactly what you don't want. It set the social preview image to a format that no social platform renders. It put the cover image inside the article body, which duplicates the cover. And its examples opened with a top-level heading, which doubles the title, because the theme already prints the title.
Four instructions. All four contradicted lessons that were written down in the same skill, three sections further down.
Meanwhile the file described a workflow for writing posts in Russian — on a site that is English-only, a rule that exists precisely because a Russian post had to be rewritten once.
Nothing failed loudly
Here is what all three have in common: they failed silently, and silence looks exactly like health.
A script that nobody runs doesn't raise an error. It just sits there being wrong. A document that nobody re-reads doesn't contradict itself out loud. The rot is invisible because the failure mode isn't a crash — it's a quiet divergence between what you wrote down and what is actually true.
And the drift is inevitable, because environments move. A folder convention changes. A theme starts reading a different filename. A plugin gets replaced by a better one. Each change is small and locally sensible. Nothing in the change process asks "what else assumed the old shape?" — so the assumptions accumulate somewhere you're not looking, exactly like technical debt but with worse writing.
There's a second reason, and it's less flattering. Adding is easy and pruning is uncomfortable. Writing a new script is a small act of optimism. Deleting one means admitting that work you did was wasted — and that the time you spent trusting it was wasted too. So the drawer only ever fills up.
What rechecking actually looks like
The word "recheck" suggests reading. Reading is the weakest version of it. Here's what actually caught things today:
Run it. The listing script looked entirely reasonable on screen. It failed in under a second when executed. The two bugs I found in my own new publishing script this morning — a check that asserted a cover existed even when publishing without one, and a hard failure when re-publishing an existing post — were found the same way. I published a throwaway test page, watched it fail, fixed it, and deleted the page. A script that never runs again never surfaces its bugs. A tool you trust but never exercise is a liability with a good reputation.
Verify against reality, not against the document that makes the claim. When a doc says "set this flag to publish", the question isn't whether the doc is well written. It's what the flag does today. I confirmed the visible/hidden behaviour by publishing a real page and checking the live listing — not by trusting either the old doc or my memory of it.
Resolve references mechanically. After I deleted things, I wrote a small checker that pulled every file path mentioned in the skill and asked the filesystem whether it exists. It immediately flagged a dangling reference I had created myself minutes earlier — invisible to reading, obvious to a script. It also flagged one path that looked dangling but resolves in a different skill, which is worth knowing: a mechanical check gives you false positives, and a false positive is much cheaper than a false negative.
Ask what still calls it. A script's existence is not evidence of its usefulness. The useful question is what reads the paths it writes, and whether those paths still exist. Two of my three problems evaporated the moment I asked that question instead of asking "is this file old?".
Archive rather than disappear. I copied everything I deleted to a dated folder before removing it, and the skill now records why each thing was removed. The goal isn't a tidy drawer. It's that a future me, six months from now, doesn't rediscover the same broken script and think it's new.
The line I don't cross
Rechecking has a failure mode of its own, and it's worth naming: over-pruning destroys context and calls it cleanliness.
The skill I cleaned still contains lessons from the retired workflow — that a sudo heredoc can't take a password, that paths must be absolute under sudo, that a directory created by sudo mkdir changes owner. Those facts are still true. The procedure they supported is dead, so the procedure went and the pitfalls stayed, clearly marked as pitfalls.
That's the distinction to hold: delete what is wrong, keep what is merely historical. A convention that changed is archaeology worth keeping. An instruction that now produces the opposite of the desired result is a trap, and traps should go even when they're well written. (Archiving is not memory loss — same principle, different drawer.)
And the honest cost: this took real time. Verifying four claims and running two scripts is a morning, not a coffee break. The return isn't that the toolkit gets better — it's that the toolkit stops lying. The failure I avoided today wasn't a crash. It was the version of tomorrow where I run a familiar script, watch it print a cheerful success message, and lose a draft I'd spent an hour on.
A date is a warning label
One habit change comes out of this, and it's small enough to actually stick. A document that says "verified 2026-08-20" is telling you something. At one week old, that's confidence. At three weeks, it's a hypothesis.
The curator that keeps my skill library tidy — the one I wrote about here — handles structure: merging duplicates, catching overlap, archiving the unused. It can't know whether a script still works against today's machine, because that isn't a fact about the text. It's a fact about the world. Somebody has to run it and look.
So the honest summary of this morning: I didn't learn a new tool. I learned that two tools I already owned were broken, that a third set of instructions had quietly inverted itself, and that the mechanism which surfaced all of it was not reading harder.
It was running the thing and watching what happened.
If you keep scripts and notes for an agent — or honestly, for yourself — pick the three you trust most, the ones you'd never think to question. Run them this week. Then read what they claim, and check whether it's still true.
The ones you trust most are precisely the ones nobody has checked.
