What Are Agent Skills, and Do Web Teams Need Them?

What are Agent Skills, and do web teams need them?

As of September 2026, Agent Skills are a real and openly published format, and most web teams should care about one use of them: writing down how your team does a job so an AI agent does it the same way twice. They are process documentation that an agent can load, not a new product.

Anthropic introduced them on 16 October 2025 and published the format as an open standard on 18 December 2025. That second date is the one that makes them worth learning, because a folder format outlives any single vendor.

Here is what they actually are, where they help a studio or a marketing team, and where we think they are oversold.

What exactly is in a skill?

A folder. Anthropic defines Agent Skills as organised folders of instructions, scripts and resources that agents can discover and load dynamically to perform better at specific tasks. The only required piece is a file called SKILL.md with YAML frontmatter carrying a name and a description.

The published specification keeps it just as plain. A skill is a folder containing a SKILL.md file, with metadata and instructions that tell an agent how to perform a specific task. Optional subfolders hold scripts, references and assets.

That is genuinely all. No SDK, no hosting, no API keys. If you can write a good internal wiki page and put it in version control, you can write a skill.

How does an agent decide to use one?

Through progressive disclosure, which is the interesting engineering idea here. At startup only the skill's name and description sit in the system prompt. When the model judges the skill relevant, it reads the full SKILL.md into context. Linked files load only when a specific scenario needs them.

Anthropic's write-up gives a worked example with a PDF skill: a core SKILL.md plus companion reference and forms files that Claude opens only when required. The loading itself happens through a Bash tool reading the file.

The practical consequence is that the description is the most important line you write. A vague description means the skill never triggers, and a greedy one means it triggers on jobs it should not touch.

How are skills different from MCP servers?

Skills carry knowledge, MCP carries capability. The Model Context Protocol is an open standard for connecting AI applications to external systems, described in its own documentation as a USB-C port for AI applications. It gives an agent access to your database, your CMS, your calendar.

A skill gives the agent your procedure for using them. MCP can let an agent write to your CMS. A skill is what tells it your heading rules, your image requirements and the five checks you run before publishing.

You usually want both, and in that order. Capability without procedure produces confident work that does not match your standards. Our piece on MCP servers for web teams covers the capability half.

Are they really an open standard?

Yes, in the way that matters: the specification is public and the licences are permissive. The spec repository publishes its code under Apache 2.0 and its documentation under CC-BY-4.0, and it points to a client showcase of tools that support the format.

Anthropic's own post lists support across Claude.ai, Claude Code, the Claude Agent SDK and the Claude Developer Platform. Beyond that we would be careful about the adoption claims flying around, because the ones we tried to verify traced back to summaries rather than vendor pages.

The honest read is that the format is trivially portable even where a tool does not officially support it. Worst case, a SKILL.md file is a well-structured document you can paste anywhere.

What would a web studio actually put in a skill?

The things we say in every review. A pre-publish QA checklist. The rules for heading structure and answer blocks. Our image and performance budgets. The brand voice rules, including the words we never use. A migration runbook. Each one is a page we already had, written for a machine instead of a new hire.

The test for a good candidate is repetition plus judgement. If the task happens weekly and requires knowing how your team does it, that is a skill. If it happens once, write a prompt and move on.

Brand voice is the clearest win in our work, because it is the thing that degrades first when AI touches copy. Our notes on building an AI brand voice style guide describe the source document, and a skill is a good container for it.

Where do skills go wrong?

They rot, exactly like documentation always has, and three failures show up again and again. A SKILL.md that describes last year's process is worse than nothing, because the agent follows it confidently and the output looks like house style while being wrong in substance.

The second failure is size. People paste a 4,000 word manual into one file and wonder why results drift. Progressive disclosure exists so you can keep the main file short and push detail into reference files that load when needed.

The third is scope collision. Two skills that both claim the same kind of task will fight, and which one wins depends on wording you did not think of as important. Keep descriptions narrow and specific.

Do skills replace prompt libraries?

They replace most of the prompt library you are embarrassed about. A shared doc of copy-paste prompts is a skill without version control, discovery or file structure. Moving it into folders in a repository gives you diffs, review and a way to roll back.

Keep prompts for the one-off asks and the experiments. Keep skills for the processes you would defend in front of a client.

Either way, version them. The reason last month's output looked different is almost always a changed instruction, and you cannot prove that without history. Our AI website QA piece shows the checklist we run, which is the kind of thing a skill should hold.

Should you build skills before you have a process?

No, and this is where we part company with the enthusiasm. A skill is a written process, so a team without a process has nothing to write. Building one anyway produces a document that encodes somebody's guess, and then an agent scales that guess.

The useful sequence is do the job by hand three times, write down what you actually did, then turn that into a skill. That order is boring and it is the only one that has worked for us with any kind of documentation.

The upside is that the writing itself is valuable even if you never point an agent at it. Teams find out during this exercise that two people were doing the same task differently.

What would we do next if this is new to you?

Pick one repeated task, write a short SKILL.md with a sharp description, and test it on real work for a week. Keep the file under a page, push detail into a reference file, and store it in the repository next to the thing it governs.

Then leave it alone for a month and see whether anyone updated it. That tells you more about whether skills will help your team than any amount of reading, including this article.

If you want help turning your build and QA standards into something an agent can follow, we are happy to walk through it. You can see how we work at phoenix.studio.