The Prompt Is Dead, Long Live the Skill Doc
I realized recently that I haven't written a real prompt in over a month. Not because I stopped working with AI. I work with it every day. But almost nothing I ask it to do starts from a blank instruction anymore, and that shift turned out to matter more than any prompting technique I ever picked up.
The prompt had a good run. Three years of collective effort went into learning how to phrase requests: be specific, give context, assign a role, show an example. All of it works. None of it compounds. A prompt is a transaction. It shapes one response, in one session, and then it's gone. The next session starts from zero, and you find yourself re-explaining the same preferences, the same constraints, the same house rules you explained last Tuesday.
The fix I've landed on, working with a persistent agent, is the skill doc. Prompting is a skill the way haggling is a skill: useful in the moment, worthless as infrastructure. A skill doc is different. It's standing policy, a file that teaches the system how I work once and applies it forever. The difference sounds small. In practice it's the difference between briefing a contractor on every single task and working with a colleague who already knows how you like things done.
What standing policy actually looks like
Two of mine do most of the work. A voice doc encodes how I write, the rhythm rules, the words I won't use, the structure each format needs, checked automatically before anything drafted under my name reaches me. A second encodes how each project actually runs: where the repo lives, how the build fires, which rules are non-negotiable.
A third is smaller and more particular: exactly which shade of orange counts as the brand's, and where on a page it's allowed to appear. That single rule used to eat five minutes of every design conversation. Now it's just true, every session, without me saying it out loud.
None of this happened in one sitting. Every one of those docs started as a correction I got tired of making twice.
Corrections should only happen once
The deeper shift is what a correction means now. When the agent gets something wrong, I have two options: fix the output, or fix the doc that produced it. Fixing the output is the prompt-shaped instinct. Handle this instance, move on. Fixing the doc makes the correction permanent, and every future task inherits it. I've started treating every repeated correction as a bug in my documentation, not in the model.
This is the part people miss when they call prompting a skill: skill docs are infrastructure, not technique. They turn taste, process, and hard-won preferences into something durable and inspectable. I can version them. I can diff them. When the agent does something I like, I can usually trace it back to a line I wrote months ago.
What I haven't solved: skill docs accumulate. Mine now occasionally contradict each other, and deciding which one wins is a governance problem wearing a new costume. There's also a real question about portability. My docs encode my own judgment, which is exactly what makes them valuable and exactly what makes them hard to hand to a team. I suspect the next year of this work is less about writing better instructions and more about managing a growing body of policy. I didn't expect prompt engineering to end in something that looks like law.
This post was written collaboratively with AI. The ideas, arguments, and editorial judgment are mine. The drafting process involved AI assistance for structure, phrasing, and pressure-testing the argument.