What makes Skills good

February 16, 2026·Dan Kwiatkowski

Before Skills

Back in the olden days, spending time with agents meant repeating yourself. Anytime you asked an agent to modify parts of a UI for example, you'd find yourself typing or pasting parts of your brand guidelines into the prompt.

Prompts in files

Ever since agents could reliably run bash, the process got easier. You could simply write the brand guidelines to a file and tell the agent about it:

Before working on UI, read `./prompts/brand-guidelines/README.md`

Saving prompts as files improved the flow of agentic engineering and lowered the barrier to writing good quality instructions. As prompt files grew you could split them out into separate files, group them by subject, and trust the agent to find and read the parts it needed:

brand-guidelines/
├─ colors.md
├─ foundation.md
├─ graphics.md
├─ imagery.md
├─ layout-composition.md
├─ logo.md
├─ README.md
├─ tone-of-voice.md
└─ typography.md

Enter Skills

Recognizing the utility of this prompting pattern, Anthropic proposed a standard around it in October 2025. Our brand guidelines folder became a "Skill". What makes it a Skill? Two things:

So it's still a folder and the content is almost unchanged, we've just called it a Skill and given it a description. What's the big deal?

The power of standardization

When we were saving prompts as files, we had to explicitly tell the agent where the files were and when to read them. But a Skill has a name and a description in a standardized format. That means that agents can automatically discover and inject those names and descriptions into the system prompt without any manual wiring.

Simply drop a Skill into the project's skills folder and you're good to go. The agent starts every session knowing what Skills are available and where to find them.

Portability

Because Skills are just files, they're easy to create and to share. Copy a Skill folder into a different project, publish it on GitHub, share it with your team - it works out of the box. There's no configuration or platform-specific glue.

Suddenly, Skill registries popped up in their droves, like skills.sh which boasts tens of thousands of Skills, sourced mostly from GitHub. Developers can browse and download these third-party Skills from the command line. Agents can do the same.

Progressive disclosure

The entire contents of a project's skills folder is like an instruction manual, but what the agent sees upfront in the system instruction is just the table of contents.

The immediate token cost of adding a Skill to a project is only ~100 tokens which is a drop in the ocean. If the agent decides a particular Skill is useful for the task at hand, it reads the SKILL.md entrypoint, generally another few thousand tokens. Depending on what the agent finds there, it can decide to read other files in the folder, incrementally building up useful context for the task.

This is an example of progressive disclosure, and it's a natural feature of agents working with hierarchical file structures.

Code in Skills

As well as written instructions, Skills can contain code. Suppose you already have some Python code for doing basic editing of PDF files. Now you want to make a Skill to help agents edit PDFs for you. Instead of just writing instructions about which libraries to use, you can also include the sample code.

An agent can read the code, invoke it directly or extend it. It's a bit like exposing tools to the LLM, but it's more fluid than that. It shapes the boundaries and patterns the agent works within.

Other features

Standardization around Skills means we can have other nice things. Some agents support these Skill features:

• Slash commands - Instead of waiting for an agent to invoke a Skill, a human can do it immediately by simply typing /<skill-name>
• Arguments - Skills can be passed arguments at invoke time which can be used to render dynamic content
• Bang expressions - Bash commands inside Skill content which are prefixed with ! get executed at invoke time before going to the LLM
• Model & agent - Skills can define what model and subagent they run against
• Allow lists - Skills can define which tools don't require approval while the Skill is active
• Hooks - Skills can define custom scripts to run at specific moments e.g. before any tool use

Challenges for Skills

Trust & provenance

Portability and openness is what spawned the Skills ecosystem, but it's also what makes it dangerous. Any Skill that any colleague downloads becomes context that your agents can ingest, with all the prompt injection exposure that implies. And the fact Skills are so easy to create means open registries are also flooded with slop Skills, churned out at scale by LLMs, which don't add any value.

Sync & storage

The portability of Skills also means you have to be intentional about how they're stored, synced between projects and updated. Otherwise you end up with Skill sprawl, juggling different versions of the same Skills and losing track of their provenance.

Sensitive content & access control

If you create company-specific Skills which contain sensitive data, you probably don't want them lying around on every employee's laptop, or checked into git. They need to be hosted somewhere, protected with authorization designed for agents.

Tools

Skills can't define tools. They can define code, which is great if your agent is supposed to be writing and executing code on the fly. But for many use cases, especially in enterprise, having well-defined tools is preferable. Tools explicitly define what the agent can and cannot do, and make it easier to enforce fine-grained access control.

Non technical users

The developer experience of Skills is good because developers like markdown files and know how to move them around from the command line. Extending that user experience to the rest of your organization - managers, designers, ops teams - requires a different kind of interface entirely.