Most of my AI work habits formed gradually. Skills sharpen: better at structuring prompts, more deliberate about context, better at steering conversations toward useful output. But there was a gap that kept surfacing — one that took time to name clearly: none of that improvement was accumulating anywhere. Every session reset to zero. The next time similar work came up, the same approach needed re-explaining, the same quality bar re-establishing, the same output structure re-creating. The methodology lived in my head, not in the system.
This is the fundamental problem with prompt-based workflows: they’re perishable. You can get genuinely skilled at prompting and still end up rebuilding the same setup every time. What we need instead is something more durable — a skill. Not a prompt. A file that captures the methodology once and applies it every time the task arrives, without re-explanation.
What makes a skill different from a prompt
A prompt is what you type into a chat window. A skill — often called a SKILL.md file in systems like Claude Code — is a reusable document that encodes how to approach a recurring type of work: the quality criteria, the output structure, the edge case handling, the routing instructions that tell the system when to fire it. When you invoke a skill, the methodology is already there. You describe the task; the skill handles the approach.
The practical difference is significant. Prompts require you to reconstruct context every session. Skills accumulate. A well-built skill runs across hundreds of conversations, different team members, automated pipelines — all applying the same underlying methodology consistently. That’s a very different return on your time than a one-off prompt, however good it is.
Building from examples, not intentions
Here’s something worth learning the harder way: the most natural instinct — sitting down to document “how this type of work gets done” — produces the least reliable result. What you write from intention is what you think you do, a somewhat idealized version. The real methodology lives in the decisions you’ve made so many times they’ve become automatic and invisible.
A better approach is to build backward from your actual output. Take ten or fifteen pieces of your best completed work — not descriptions of the work, the work itself — and ask an AI to analyze what’s structurally consistent across them. What sections appear every time? What judgment calls seem to drive quality? What patterns are you applying without realizing it? The analysis tends to surface things you couldn’t have articulated from intention alone.
That becomes the raw material for a skill that reflects how you actually work, not how you imagine you work.
The bar changes when agents are calling
If you’re building skills that automated agents will invoke rather than a person in a chat session, the requirements change meaningfully. A human caller absorbs vagueness — they redirect, ask a follow-up, catch the gap and fill it in. An automated caller cannot. If the output format isn’t fully specified, the next step in a pipeline treats whatever comes back as correct input and proceeds confidently in the wrong direction. By the time the error surfaces, it may be several steps downstream and look like something else entirely.
This means skills built for pipelines need exact output structures — not “a structured summary” but specific fields in a specific order. They need explicit handling for edge cases: what happens when required input is missing, when the request is partially out of scope, when something is ambiguous? Prose instructions work well enough for a human reader; they’re unreliable for an automated caller that takes them literally.
We’re at a moment where this gap matters more than it used to. The same skill file runs in a developer terminal, in an Excel sidebar, in an overnight pipeline with no one watching. The distance between “works interactively” and “works reliably in production” is widening, and the cost of the mismatch is growing with it.
What’s worth encoding
Not everything qualifies. The tasks worth building skills for tend to share three characteristics: they recur regularly enough to constitute a pattern, they require a specific methodology rather than just a competent prompt, and output variability costs something — rework, quality problems, downstream errors. If a task ticks all three, the return on building once and reusing indefinitely is significant. If it doesn’t, a direct prompt is probably the right tool.
The question worth returning to: as automated pipelines become more common and more of our AI work runs without a human in the loop, which of our current workflows are built on perishable prompts that should have become durable skills by now? That audit is worth doing before the cost of the answer compounds.
Text summarized and optimized using Anthropic’s models and reviewed by a human.