Every behavioral instruction you write into a skill, an agent file, or a system prompt is a bet against the next model. Most of those bets lose. The instruction that wins is the one that was too lean to be wrong.

Thesis: The durable instruction is the generic one. Specific, procedural guidance is pinned to the model it was written for — it rots into dead weight or hardens into a straitjacket the moment a smarter model arrives. Lean, intent-shaped instructions ride model improvements instead of fighting them. When you author for reuse, bake in less, and inherit the capability the model already has.

---

This is Post 2 of the "Intent Over Instructions" series. Post 1 made the case for bounding a single task by outcome instead of scripting it. This post applies the same discipline to the instructions you write once and reuse forever — skills, agent definitions, system prompts.

The Instruction That Ages

A per-task prompt is disposable. A skill is not. You write a skill, an agent persona, or a system prompt once and then it runs across a thousand sessions and — if you're not careful — across three model generations. That longevity changes the economics of every word.

When I first wrote a skill for a colleague's agent framework, its description read like an operating manual:

Comprehend the ask, then inventory the available MCP tools, then discover paths at runtime — never hardcode connector IDs — then decompose into phases, emit findings as JSON…

Roughly 890 characters of it. Every clause was true. Every clause was also a liability, because every clause encoded an assumption about what the model couldn't be trusted to do on its own. "Inventory the MCP tools first." "Never hardcode IDs." That's not intent — that's me, in 2026, hand-holding a model through mechanics I didn't trust it to get right.

Then the model got better at exactly those mechanics. And now the hand-holding wasn't helping. It was noise the agent had to read, reconcile, and route around on every single invocation.

Two Kinds of Content, Two Fates

Not all instruction text ages the same way. There are two kinds, and they have opposite fates as models improve.

flowchart TD
    Instr["A line in your skill / agent file"]
    Instr --> Q{"Is this WHAT/WHY,<br/>or HOW?"}

    Q -->|"WHAT / WHY / negative scope<br/>('surface the true intent';<br/>'don't act on unverified data')"| Durable["Durable core"]
    Q -->|"HOW / mechanics<br/>('inventory tools first';<br/>'never hardcode the ID')"| Fragile["Fragile scaffolding"]

    Durable --> D2["Model improves →<br/>still true, executed better.<br/>Gains capability for free."]
    Fragile --> F2["Model improves →<br/>redundant at best,<br/>a straitjacket at worst."]

    style Instr fill:#5a5a8a,color:#fff
    style Durable fill:#2d6a4f,color:#fff
    style D2 fill:#2d6a4f,color:#fff
    style Fragile fill:#9d4444,color:#fff
    style F2 fill:#9d4444,color:#fff

The split has a fast test: swap in a smarter model and reread the line. If it still parses as true, it was durable — a constraint on what counts as success, not a description of the steps to get there. "Surface the true intent behind the ask" passes that test at any capability level.

The fragile lines fail the same test in a specific, three-stage way. They don't go from true to false in one jump — they go from helpful (the model needs the hand-holding) to redundant (the model does it anyway, so the line is now dead weight) to presumptuous (the model has found a better path and the line is now actively steering it back to the worse one). That's the real cost of scaffolding: it's not that it ages badly on day one, it's that it silently crosses from asset to liability sometime later, on a day you didn't touch the file and have no reason to go looking.

The authoring rule falls straight out of the diagram: push everything you can toward the durable core, and write as little scaffolding as you can get away with.

The Description Is a Trigger, Not a Spec

The sharpest version of this shows up in how you write a skill's description — the text that decides whether the skill activates at all.

The temptation is to cram the description full of behavior: what the skill does, in what order, with what tools. But the description isn't where behavior belongs. Its only job is to help the agent decide whether this is the right tool for the situation. That's intent and triggers — and, importantly, negative scope ("not for X"). Runtime behavior — "inventory the tools, never hardcode IDs" — belongs in the body, if anywhere, because it's scaffolding, and scaffolding shouldn't be paying rent in the one field that's read on every routing decision.

This is the same colleague's-framework skill from the opening — the ~890-character description — and the refactor was almost entirely subtraction:

	Before	After
Description	~890 chars narrating the workflow	~560 chars: intent + triggers + negative scope
Body	~143 lines, dense step-by-step	~103 lines, goals + exit bars
"Never hardcode IDs"	In the description	Moved to a gotcha, stated as terrain, not a step
Tool-inventory procedure	Spelled out up front	Deleted — the model does this unprompted

Nothing about the skill's purpose changed. What changed is that I stopped writing down the parts the model had grown able to figure out. The skill got shorter, triggered more cleanly, and — this is the point — got better on the next model instead of worse, because there was less of my 2026-era hand-holding left to get in the way.

Reference, Don't Duplicate

There's a second kind of rot, and it comes from copying instead of pointing.

It's tempting to paste the canonical rules — the framework's spec, the style guide, the API contract — directly into your skill so it's "self-contained." Don't. The moment you paste, you've forked. The source updates; your copy doesn't; and now your skill is confidently teaching last quarter's rules.

flowchart LR
    subgraph dup["Duplicated"]
        Src1["Canonical spec<br/>(updated quarterly)"] -.->|"copy-paste once"| Copy["Pasted into<br/>your skill"]
        Copy --> Drift["6 months later:<br/>teaching stale rules"]
    end

    subgraph ref["Referenced"]
        Skill2["Your skill"] -->|"links to"| Src2["Canonical spec<br/>(updated quarterly)"]
        Src2 --> Fresh["Always current<br/>at load time"]
    end

    style Skill2 fill:#5a5a8a,color:#fff
    style Drift fill:#9d4444,color:#fff
    style Fresh fill:#2d6a4f,color:#fff

The durable move is to hold a thin local index — what rules exist and when they apply — and link out to the living source for the detail. Your skill says "author descriptions per the spec's description-field guidance" and links it; it doesn't paste three paragraphs of that guidance and quietly freeze them. Same principle as externalizing knowledge out of an MCP server: the thing that changes on someone else's cadence shouldn't be baked into your artifact.

Cut What the Model Already Knows

The hardest habit to break is writing down things the model already knows.

You do not need to tell a current frontier model what JSON is, that it should read a file before editing it, or that grep finds text in files. Every such line is pure cost: it spends context, it adds nothing, and — worse — a wall of obvious instructions trains the agent to skim, so it's primed to skim past the one non-obvious line that actually mattered.

The test for keeping a line of instruction:

• Would a competent practitioner already know this? If yes, cut it. The model is that practitioner.
• Is this a non-obvious fact about my terrain? "This API silently truncates batches over 500." Keep it — the model can't derive it.
• Is this a what/why, or a how? Keep the what/why. Be ruthless with the how.
• If the model doubled in capability tomorrow, would this line help it or box it? Cut whatever boxes it.

What survives that filter is short, and it's mostly intent plus a few load-bearing facts about your specific world. Which is exactly what you want, because it's exactly the part that doesn't rot.

The Counterintuitive Payoff

Here's what makes this more than tidiness. A lean, generic instruction doesn't just survive a model upgrade — it appreciates.

A specific procedural instruction is frozen at the capability level it was written for; the best it can do on a smarter model is get out of the way, and the worst it can do is actively suppress the improvement. A generic intent-shaped instruction has no such ceiling. "Surface the true intent and abstain when you can't ground it" is executed more shrewdly by every stronger model, with no edit from you. You wrote the instruction once; each release makes it better.

That inverts the usual maintenance story. Normally, code and config decay — they need constant tending to stay useful as the world moves. Lean instructions do the opposite: the less you wrote, the more the platform underneath does the tending for you. The leanest instruction is the one with the most room left for the model to grow into.

When to Write the Scaffolding Anyway

Generic-by-default is not generic-always. Keep the scaffolding when:

• The model is genuinely weak or small. A local 7B model may need the step-by-step. Just log that scaffolding as a tax on a capability gap, and delete it when you upgrade — don't let it calcify.
• The mechanics are the requirement. If the skill's whole point is "do it via the streaming API specifically," then the how is the what. Keep it.
• A gotcha is non-derivable. Facts about your terrain the model can't know are not scaffolding — they're the durable core in disguise. Keep them, but phrase them as facts ("the API truncates at 500"), not steps ("call it in a loop of 500").

The line is the same one from the last post: tell it the things a smart, briefed contractor couldn't know, and stop telling it the things that would insult one.

What to Do Next

• Read your longest skill and highlight every how. That highlighted text is your rot surface. Ask which lines the current model would do correctly unprompted, and cut those.
• Shrink your descriptions to triggers. Intent, when-to-use, and negative scope. Move every runtime behavior out of the description and into the body — or delete it.
• Replace every pasted spec with a link. Hold a thin index of what and when; point to the living source for the how.
• Delete what the model already knows. If a competent practitioner wouldn't need the line, neither does the model — and the line is teaching it to skim.
• Re-audit on every model upgrade. Treat a new model release as a prompt to remove instructions, not add them. The upgrade is doing work your scaffolding used to do.

---

Next in the series: Bind the Goal, Not the Gesture — what happens when you take "specify the what, not the how" all the way down into how an automation is stored and executed. Related: How Cursor Finds Skills, The alwaysApply Tax, and Rules vs Skills in AI Dev.