This article is part of a set of free Claude skills
These rules are packaged as Claude skills: small files you drop into Claude Code so your own assistant works this way too. The published set is at blonderoofrat/agent-skills. They are public domain: copy them, change them, no attribution and no permission needed. How to install them is at the end of this article.
I found it in a planning document, in a paragraph I had written months earlier: we should check whether the contact form is still forwarding correctly.
Nobody had checked. Nobody had decided not to. There was no argument about it, no deprioritisation, no note saying it had turned out to be unnecessary. The sentence had simply been written down in a place where writing things down feels like doing something about them, and then the document was closed.
I went looking for siblings, the way you do. There were about thirteen – thirteen pieces of work that were, in the most literal sense, not happening, and had never been decided against.
The failure mode is silence, not overrun
The thing that makes this hard to see is that nothing goes wrong. A dropped commitment produces no error, no alert, no angry message. It produces nothing at all, which is indistinguishable from a commitment that was quietly and correctly cancelled.
That is why “just be more organised” does not work. You are not fighting a lack of discipline. You are fighting the fact that the failure state and the success state look identical from outside, so there is no signal to be disciplined about.
And the natural home for a promise is the worst possible one. Commitments get written where they are made – in a design document, a code comment, a message, a plan. Every one of those is a place you will not be looking when you next decide what to do. The promise is not lost. It is filed under the context that produced it, which is precisely the context that has ended.
Parked and killed are honest endings
The design that fixed this is smaller than the problem suggests. Every promise gets an entry, and every entry has to reach one of four states:
- done – finished, with a reference to the actual evidence, not a claim
- parked – deliberately not now, with the condition that would revive it
- killed – deliberately never, with the reason
- blocked – waiting on a specific named input from a specific person
And nothing may leave the list any other way. A silent drop is the only bug.
That framing is the whole trick, and it took me a while to appreciate why it works. It removes the guilt. If the only acceptable outcome were done, the list would become a monument to failure and people would stop adding things to it, which is exactly the behaviour you cannot afford. Killing something with a stated reason is a completely respectable outcome. So is parking it. What is not respectable is the item quietly evaporating, and once those are the terms, writing things down stops being a commitment to do them and starts being a commitment to decide about them.
The blocked state needs one extra rule, because it is the one that rots. A blocked item has to name the specific input it needs and who supplies it. “Blocked” on its own becomes a shelf. The test I use is: if that person replied “use your judgement”, could I proceed? If yes, I was never blocked – I wanted reassurance, which is a different thing and not their problem.
It has to resurface, or it is just a longer document
A list you have to remember to read is a document, and documents are what failed. The ledger is loaded and printed at the start of every working session, and every open item appears until it is disposed of. It is the first thing seen and it is not dismissible.
There is one number worth watching: the count of open items older than three weeks. Not the total, which mostly measures ambition, and not the completion rate, which you can improve by promising less. The age of the oldest open items is the only figure that detects the actual failure – things that are technically tracked and functionally abandoned. It has to trend down. When it does not, the answer is usually a round of honest killing rather than a burst of work.
What surprised me
I expected this to be a chore. It is not, and the reason is the thing I would tell anyone building one.
Most of the items get killed. Written months ago, in a context that has since dissolved, by someone with less information than I have now. Reading them back and writing no, and here is why is not a failure of follow-through. It is the system working: a decision that never got made, finally getting made, with the benefit of everything learned since.
The thirteen that started this became a handful of real pieces of work and a lot of honest nos. The handful got done. The nos are still there, with their reasons, so nobody proposes them again in six months without at least reading why they were dropped.
Get the skills
Everything above is generic. None of it is about rats, and none of it is specific to this site. So these rules are also published on their own as Claude skills: small Markdown files that an AI coding assistant reads and applies when the situation comes up.
The set: blonderoofrat/agent-skills
git clone https://github.com/blonderoofrat/agent-skillsInstalling them in Claude Code. Copy any skill’s folder into one of these, so the file ends up at .../skills/<skill-name>/SKILL.md:
~/.claude/skills/(available in every project on your machine)your-project/.claude/skills/(that one project only)
Claude reads them at the start of the next session and applies one when what you are doing matches the description at the top of that file. You can also ask for one by name.
Using a different assistant? They are plain Markdown with a two-line header. Paste the body into whatever system prompt, rules file or instructions file your tool uses. Nothing in the rules themselves is Claude-specific.
Licence: CC0, public domain. Copy them, adapt them, ship them in commercial work, no attribution required. These are deliberately frozen snapshots rather than a maintained project, so if one is wrong for your situation, change it. That is easier than asking us to.
The particular rule in this article is being added to that set; it is not up there yet.
Part of Notes from building this site: articles about working practices that exist because something here went wrong first. Most of these rules are also published on their own, as free public-domain instruction files for AI coding assistants, at blonderoofrat/agent-skills on GitHub. This one is not up there yet.
Filed under News about this site
