A prompt is not a skill: what shipping 59 marketing agents taught me

7 min read

TL;DR: Marketers are publishing their Claude skills, and most of them are prompts wearing a new name. A real skill decides when it runs, knows what it must not do, and carries checks the model cannot argue with. Here is the anatomy, learned from shipping 59 agents, and how to rebuild one prompt properly.

On June 10, Kyle Poyar published the four Claude skills that run Growth Unhinged: an editor, a LinkedIn punch-up pass, a newsletter advisor, an SEO checker. Two weeks earlier, MKT1 ran a buildathon around their own MCP server, with named skills for briefs, AEO audits, and candidate screening. Kieran Flanagan tells his readers that “before you build a single skill in Claude Code, you need a foundation layer” of markdown files.

The genre of the quarter is marketers publishing their AI setups. I think this is good. I also think most of what ships under the name “skill” is a prompt in a trenchcoat: useful instructions, pasted into a file, renamed.

I have some standing to be annoying about this. I maintain an open-source collection of 59 marketing agents, packaged as 13 installable skill bundles. Most of them started life as prompts. The ones that survived daily use did not survive because the instructions were good. They survived because of everything around the instructions.

The difference is not the file extension

A prompt is a request. You are present when it runs, you read the output, you catch the failures. The quality lives in your attention.

A skill is infrastructure. It runs when you are not paying attention, which is the entire point, and that changes the engineering requirements completely. Poyar defines skills as “curated instructions and resources that train AI models to produce better, more personal outputs.” That is true and incomplete. Curated instructions are the easy 60 percent. The hard 40 percent is the part almost nobody publishes, and it is the part the official skill spec treats as first-class.

Five parts separate a skill from a saved prompt.

1. The trigger is the product

A prompt runs when you paste it. A skill has to know when to fire on its own, and in the current spec that decision rides almost entirely on one frontmatter field: the description. The docs are blunt about it. If a skill does not trigger, “check the description includes keywords users would naturally say.” If it triggers too often, “make the description more specific.”

There is also a budget. Combined trigger text gets truncated at 1,536 characters, and when many skills are installed, descriptions compete for roughly one percent of the context window, with the least-used skills dropped first. Your skill is competing for attention before it ever runs. Writing a description is positioning work: who is this for, when does it apply, what words will the user actually say. Marketers should be unusually good at this. Most skill files I see have a description written as an afterthought, which is like running ads with the targeting left on default.

2. Scope boundaries: what the skill refuses to do

A prompt does whatever the conversation drifts into. A skill needs edges. The spec gives you real enforcement for this: allowed-tools restricts what a skill can touch, disable-model-invocation makes dangerous workflows manual-only so the model can never decide on its own to run your deploy, and path rules gate a skill to the files it is actually for.

In my collection, the difference shows up as agents that state what they do not cover. The paid-media reviewer does not write creative. The brief generator does not invent positioning. This sounds like pedantry until an agent confidently does the adjacent thing badly, at volume, in your name.

3. Guardrails as data, not vibes

Every marketer’s prompt says “match our brand voice.” That is a vibe. A guardrail is a file: a banned-word list, a redaction list, a claims policy the skill reads every run. My own publishing pipeline carries a list of phrases that must never appear (the usual AI tells: “empower,” “elevate,” “streamline”), a list of facts that must never ship, and punctuation rules. I cannot even quote the worst offenders here, because the build would fail. That is the point. They live as data next to the instructions, not as adjectives inside them.

The reason is simple. Instructions compete with everything else in context, and they lose more often as conversations get longer. Data that a deterministic check reads does not compete with anything.

4. Checks the model cannot talk its way past

This is the one that separates the operators from the prompt publishers.

The model is a colleague who argues. A gate does not argue.

Poyar says he is “not letting AI write for me. But I am letting it argue with me about my writing.” That is the right posture, and it works because he personally reads every output. The moment you run AI work you do not personally read, arguing stops scaling and gating starts. The spec supports bundling executable scripts inside a skill, and this is what they are for: a script that greps the draft for banned phrases and fails loudly, a check that every URL in the piece returns a 200, a linter for sentence length or em-dashes or whatever your voice rules are.

My blog’s build fails, hard, if a banned phrase or a redacted number appears anywhere in the output. The model never gets a vote. When a check fails, a human looks. That single pattern has caught more embarrassments than every clever instruction I have ever written, combined.

5. Versioning, because the ground moves

Prompts feel finished. Skills decay. The model under your skill will change, and behavior you tuned for one model drifts on the next: instructions that were reliably followed become suggestions, formats that held become approximate. A skill needs what any production system needs: a version note, a date, a quick re-test ritual when the underlying model updates, and pruning. The spec even encodes maintainability guidance, keep the main file under 500 lines and push reference material into separate files that load only on demand, so a skill stays cheap until invoked and reviewable when it matters.

Of my 59 agents, the ones I trust are not the cleverest. They are the ones I have re-tested across model versions and trimmed twice.

Before and after

The naive version, which is most of what gets shared:

Write a LinkedIn post in my voice. Be punchy, use short sentences,
avoid corporate jargon, hook in the first line. Here are three
examples of my posts: [...]

The skill version of the same capability:

linkedin-post/
  SKILL.md      description: "Drafts LinkedIn posts in Shivaa's voice.
                Use when asked for a LinkedIn post, social copy, or to
                repurpose an essay for LinkedIn."
                scope: drafts only; never posts, never schedules
  voice.md      rules as data: rhythm, hook patterns, 12 banned phrases
  examples/     six real posts, annotated with why each worked
  check.sh      fails on banned phrases, em-dashes, >280-char first line
  CHANGELOG     last re-tested: model X, date Y

Same instructions at the core. What changed is that the second one knows when to fire, knows what it must not do, carries its rules as data, gets checked by something that cannot be charmed, and admits it will need maintenance. That is the 40 percent. It is not glamorous, and it is exactly the part I had to learn the hard way as a marketer who reads code but does not write it for a living.

Take one prompt and promote it

If you have a prompt you reuse every week, you have a skill candidate. Give it the five parts: a description written like ad targeting, explicit boundaries, guardrails as files, one deterministic check, a version note. One evening of work, roughly.

The marketers publishing their skills are doing the right thing, and I would rather see a thousand prompts in trenchcoats than a return to gatekept “AI strategy” decks. But the gap between a prompt that works for its author and a skill a stranger can trust is engineering, not writing. The 59 agents taught me that the instructions were never the asset. The system around them is.

Sources