Instruction debt

The desk has a stack of files that all claim to be the rules.

AGENTS.md. Three SKILL.md files that overlap. An MCP tool list with descriptions that sound like invitations. A rules folder from last month that nobody deleted. A project note that says Always. Another that says Never. Both still load.

I open a session and the model already has half a novel of instructions before anyone has asked it to do a job. That surface is not free. It is context. It is activation. It is authority the agent thinks it has.

Instruction debt is the real skill-platform risk. Not the absence of skills. The pile of always-on markdown that wastes tokens, fires when it should stay quiet, contradicts itself, stops early, or grants a bound nobody named.

If skills are a valuable form of software, then the instruction surface is a surface that can carry debt. More markdown is not more platform. A thicker binder is not a better operating system.

I already wrote the earlier gates: identity, description as the trigger, owner and verifier, approval fatigue, one stack to build the stack. This note is the corpus those gates sit on. Pointer, then move.

A skill becomes a platform object. A headless agent is a job, a machine, and a schedule. HiTL is an SLA. Instruction debt is how the platform rots before the job even starts.

More files are not a platform

Teams treat every miss as a reason to add a rule. The agent failed once, so someone pastes a new Always into AGENTS.md. The skill misfired, so someone lengthens the description. The tool was used for the wrong job, so someone adds a paragraph that says do not do that.

The file count goes up. The confidence goes up in the wrong place. Nobody asks what the new line costs every session, or who owns the contradiction when two Alwayses disagree.

A platform is not the sum of markdown on disk. A platform is a load policy: what must be present, what loads on need, what is retired, and who may change the bound. Files without that policy are inventory. Inventory without an owner is debt.

I will not invent an overnight audit of my own folder. The Thursday folder is still a sketch. The categories below are public craft categories for any AGENTS.md, SKILL.md, or MCP stack. Audit them like code. Diff them. Delete them. Do not only append.

Four failure modes

Waste context. The always-on surface eats tokens before the task exists. Long preambles, duplicated policy, historical notes that should be dated logs, and “for completeness” paragraphs that never change a decision. The model arrives already tired. The job has not started.

Activate unnecessarily. A skill description that matches half the verbs in the language will load when the session did not need it. An MCP tool that sounds helpful will be called because the description invited curiosity. The description is still the trigger. Debt here is a trigger that fires for free.

Contradict. Two files both claim to be the rules. One says ask before write. One says prefer autonomous write for small edits. One skill says never touch production. Another grants a path that is production by another name. The agent picks one, or blends both, or stops. Contradiction is not nuance. It is an unowned merge conflict in prose.

Grant unclear authority, or stop early. Soft verbs - “prefer”, “consider”, “where appropriate” - look polite and behave like fog. The agent either assumes a grant it does not have, or refuses a job it was hired to finish. Unclear authority and early stop are the same debt seen from two sides: a bound nobody can name, so the run either overreaches or collapses.

These four are categories, not a scorecard from a night I did not run. If you cannot point at which of them a file creates, you are collecting markdown, not operating a platform.

Always-on versus load-on-need

The useful cut is not “how many skill files we have.” It is what sits in the always-on path versus what loads because the job asked for it.

Dimension	Always-on instruction pile	Audited load-on-need corpus
What loads every session	Everything that can claim to be rules	A thin, named core
What a skill does	Exists, therefore may fire	Loads when the job matches a tight trigger
Who owns a contradiction	Nobody; both files stay	A named owner merges or deletes
What happens after a miss	A new Always is appended	The miss is classified; a line is changed or removed
What you optimise	File count and coverage rhetoric	Token cost, activation rate, clear authority
What you actually have	A binder	A platform object with a load policy

More files can mean more coverage. They can also mean more debt per session. The table is the distinction. Count the always-on surface. Count what loads on need. If you cannot tell them apart, you do not have a corpus. You have a pile.

Audit them like code

Treat AGENTS.md, SKILL.md, and MCP descriptions as code that runs on every call.

Ask who owns the file. Ask when it last changed for a reason other than append. Ask what it costs in context on a cold start. Ask what would break if you deleted half of it. Ask which skill activates on a prompt that should have stayed in the thin core. Ask where two lines disagree, and which one wins.

A delete is a product decision. A merge is a product decision. An Always without an owner is not governance. It is folklore with a filename.

I am not pasting a viral audit prompt into this note. Prompts go stale. Categories do not. Waste, unnecessary activation, contradiction, unclear authority. Those four survive a model change. A pasted checklist that promises to score your folder overnight does not make the corpus owned.

The same expert lock applies after the audit. The skill that survives is still a platform object. The headless job is still a job, a machine, and a schedule. HiTL is still an SLA. Cleaning the instruction surface does not replace those gates. It stops them from drowning in prose.

Steal this

You do not need my desk. You need five cuts on the next AGENTS.md or skill folder before you add another Always.

1. Name the always-on core. Everything else loads on need, or it does not load. If you cannot list the core on one card, you do not have a core.
2. Price the context. For each always-on file, say what it costs every session and what decision it changes. If it changes nothing, it is decoration.
3. Tighten the trigger. Skill and MCP descriptions should fail closed. Broad verbs are activation debt. Prefer a miss that stays quiet over a hit that arrives uninvited.
4. Resolve contradictions with a delete or a merge, not a third file. Two Alwayses that disagree are a bug. A third Always is not a fix.
5. Name the authority. Soft verbs that grant or refuse without a bound are fog. Write what may run, what must escalate, and what must stop. Then put a name on who may change that list.

The product question is no longer how many instruction files you have. It is whether the corpus earns its keep every session, and whether anyone can delete a line without a ceremony.

---

Field note from the build-in-public log. NDA-safe, no client names, rounded figures only. If this matches what you are seeing, get in touch.

§

BELOW THE LINE

PODČÁRNÍK · SIDEWAYS GLANCE, NOT A SUMMARY

On the colleague who added one more Always after every miss

He keeps a binder. Not for the job. For the misses. Every time something goes wrong, he prints a new Always and sticks it on the wall, then slides a copy into the binder so the wall has a backup.

The first Always was short. Prefer ask before write. The second arrived after a loud afternoon: Always confirm the path. The third after a quiet one: Always finish unless blocked. He reads them in order. They do not agree. He nods anyway. Nodding is cheaper than deleting.

By spring the binder is thicker than the brief for the job it was meant to protect. The wall has run out of clean paint. Coffee rings mark the pages where he paused to invent the next line. In the corridor he tells a new hire that the binder is how we keep standards.

The new hire asks which Always to obey when two of them fight. He points at the newest one. Then at the oldest. Then at the binder as a whole, as if thickness were an answer.

Nobody asked him to stop adding. That is the unfunny part. Addition looks like care. Deletion looks like risk. So the wall grows. The job stays the same size. The person who could have removed a line is busy printing the next one.

The pile is not a platform. It is a habit of not deleting.

ČESKY. ORIGINAL PODČÁRNÍK

O kolegovi, který po každé chybě přidal další Vždycky

Drží si pořadač. Ne kvůli práci. Kvůli chybám. Kdykoli něco selže, vytiskne nové Vždycky, nalepí ho na zeď a kopii zasune do pořadače, ať má zeď zálohu.

První Vždycky bylo krátké. Raději se zeptej, než píšeš. Druhé přišlo po hlučném odpoledni: Vždycky ověř cestu. Třetí po tichém: Vždycky dotaž, pokud tě nic nezastaví. Čte je postupně. Neshodují se. Přikývne. Kývnutí je levnější než mazání.

Na jaře je pořadač tlustší než zadání práce, kterou měl chránit. Zeď došla na čistou barvu. Kroužky od kafe značí stránky, kde se zastavil, aby vymyslel další řádek. Na chodbě říká nováčkovi, že pořadač je, jak držíme standard.

Nováček se zeptá, které Vždycky poslouchat, když se dvě perou. Ukáže na nejnovější. Pak na nejstarší. Pak na pořadač jako celek, jako by tloušťka byla odpověď.

Nikdo ho neprosil, ať přestane přidávat. To je ta část, která není vtipná. Přidání vypadá jako péče. Smazání jako riziko. Takže zeď roste. Práce zůstává stejně velká. Člověk, který mohl řádek smazat, zrovna tiskne další.

Ten bordel není platforma. Je to zvyk nemazat.