Your Prompts Don't Compound. Your Skills Do.

I have eighty-two skills installed in my Notis account. I could not show you a single prompt I wrote back in March.

That gap is the entire post.

Somewhere on your machine there is a file called prompts.md. Or a Notion page named "Good ChatGPT prompts." Or a Slack channel where someone drops a clever one every few weeks and everybody reacts with 🔥 and nobody opens it again. Be honest about the last time you actually used yours.

Mine died quietly. Not because the prompts were bad — some were genuinely good — but because a prompt only pays off if a human remembers it exists, finds it, copies it, and pastes it into the right box at the right moment. That is four failure points stacked in front of any real work. Miss one and you retype the whole thing from memory, slightly worse than last time.

Skills remove all four. That is the boring, unglamorous reason they matter.

The format quietly became infrastructure

A skill is not a clever paragraph. Anthropic describes skills as "organized folders of instructions, scripts, and resources that agents can discover and load dynamically to perform better at specific tasks."

In practice it is a folder with a SKILL.md file in it. The file needs a name and a description. Everything else — scripts, reference docs, templates, assets — is optional and lives alongside it.

That is it. A folder and a markdown file. The unsexiness is the feature.

What makes it more than a naming convention is that the format was released as an open standard and everyone shipped support for it. The client showcase now runs from Claude Code and ChatGPT's Codex through Cursor, GitHub Copilot, VS Code, Gemini CLI, Block's Goose, JetBrains' Junie and a long tail of smaller agents.

This is the same playbook that already worked once. Anthropic donated the Model Context Protocol to the Linux Foundation's new Agentic AI Foundation on 9 December 2025, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare and Bloomberg. The same foundation stewards AGENTS.md, which is used by over 60k open-source projects.

Read that as a founder rather than as an engineer: the plumbing of agent work is being standardised in public, by competitors, on purpose. MCP standardised what your agent can reach. Skills standardise what your agent knows how to do. Both are now portable across vendors.

Why prompts never compounded

Here is the honest comparison, from someone who kept a prompt library for two years and got very little out of it.

The row that matters most is the second one. Agents load skills through what the spec calls progressive disclosure, in three stages: at startup the agent reads only each skill's name and description, just enough to know when it might be relevant. When a task matches, it pulls in the full instructions. Then it executes, loading bundled files only if it needs them.

So the retrieval problem — the thing that actually killed your prompt library — is now the agent's job, not yours. You can hold dozens of procedures on hand and pay almost nothing in context until one is genuinely needed. That is why eighty-two of them is a reasonable number to live with and eighty-two saved prompts is a graveyard.

The mistake almost everyone makes

People write the description field like a summary. It is not a summary. It is a trigger.

The agent only sees names and descriptions at discovery time. If your description says "guidelines for content work," it will never fire, because nothing a human types looks like that. If it says "use when drafting, rewriting, or scheduling a blog post," it fires exactly when it should.

I rewrote a third of my own skill descriptions once I understood this, and the hit rate changed more than any model upgrade did. Write the description for the moment of use, not for a catalogue. It is the same discipline as context engineering: decide what the agent needs to know, and when.

The second mistake is writing a skill for something you have done once. A skill is a procedure with a stable shape. If the shape is still moving, you are writing fiction.

My rule: the third time I explain the same thing to an agent, it becomes a file. Not the first — the first time I am still figuring out what I want. Not the second — the second might be a coincidence. The third time is evidence of a pattern, and patterns are what deserve to be written down. It is the same instinct behind briefing an agent like an intern instead of hoping it guesses your standards.

Skills escaped the terminal

Here is the part the developer-tooling crowd keeps missing.

Every product in that adoption list is a coding tool. Editors, CLIs, IDEs. Which means the default assumption is that skills are for engineers, sitting at a laptop, in a repo.

But almost nothing in a SKILL.md is about code. "How we qualify an inbound lead." "What our weekly report must contain." "How to write a customer refund email without sounding like a lawyer." Those are operating procedures. They were only ever trapped in a terminal because that is where the tooling landed first.

This is exactly why I built Notis around the same format. My skills run from WhatsApp, from email, from a scheduled automation at 7am — the same folder, the same instructions, no laptop involved. When I ask for a blog draft from my phone, the drafting skill loads, follows the rules I wrote three months ago about slugs and word counts and image requirements, and hands back something I can actually ship. I did not remember any of those rules. I did not have to.

The interface stopped mattering. That is the whole point of a portable standard, and it is a much bigger deal for operators than for developers, because operators were never going to open a repo in the first place. If you want the reachability side of this too, MCP servers are the other half of the same story.

What to do about it this week

If you are a solo founder or operator: pick the one thing you explain to an AI most often and write it down as a skill. One folder, one file, a name and a description written as a trigger. Then delete the corresponding entry from your prompt doc so you are not maintaining both.

If you run a small team: put skills in the repo, not in someone's private setup. The moment a procedure lives in git, it gets reviewed, improved and inherited by the next person instead of dying with the laptop it was written on.

If you are still evaluating agents: add "does it read SKILL.md" to your checklist, above most feature comparisons. A tool that reads the open format cannot hold your procedures hostage. A tool with its own proprietary prompt library can, and will.

If you are not sure yet: do nothing for a week, but keep a note of every time you re-explain something to an AI. That list is your first three skills, and you will not have to guess.

The library is the asset

Models will keep getting better and you will not control any of that. Tools will keep changing and you will switch some of them within the year. Pricing will move under you.

The written-down knowledge of how your work gets done is the only layer in that stack you own outright — and now, for the first time, it is portable by design. Not locked in a vendor's prompt library. Not stuck in one chat interface. A folder you can copy.

Start the folder. In six months the difference between people who did and people who kept collecting clever prompts will not be subtle.