AI Skills: What they are and 5 examples to improve your agent

AI models keep getting better at more things: they write code, browse the internet, generate interfaces, reason about data. And yet, if you work with an agent every day, you’ll surely recognize this feeling: you keep repeating the same instructions over and over.

You explain again how you want it to design an interface so it doesn’t look “made by AI.” You remind it again to check performance before touching a component. You tell it again to write the test first and the code after. You ask it again to open the browser and visually check the result instead of taking it on faith.

The model hasn’t lost that capability from one conversation to the next — it simply never had it packaged. It knows how to code, it knows how to reason, but by default it doesn’t know how you specifically want a given task done.

That’s where skills come in.

An AI agent can already know how to code, browse the internet, or generate interfaces, but a skill gives it something different: a specific way of doing a task. It’s not strictly a new capability — it’s procedure, judgment, and experience packaged so the agent can reuse them every time it needs them, without you having to explain them again.

What an AI skill actually is

The name isn’t a coincidence, and it’s the fastest shortcut to understanding the concept: skill means exactly that — a learned, applied ability. The comparison isn’t just about the word matching; the idea itself is the same. When we say someone “has a skill for negotiating” or “has a skill for public speaking,” we don’t mean an innate gift — we mean a specific technique that person learned at some point and now applies consistently whenever the situation calls for it. An AI skill is exactly that, translated to an agent: it’s not a new capability of the model, it’s a learned, reusable way of applying capabilities it already has — like someone who already knew how to write, and on top of that, learned to write in a particular way.

Up to now, when we talk about how to work with agents we usually talk about models, prompts, tools, and protocols like MCP. Skills add a different piece: reusable procedural knowledge.

A simple way to see it:

• A prompt tells the AI what you want done.
• A tool gives the AI the capability to do something (call an API, run a command, touch a file).
• A skill teaches it a particular way of doing it.

The separation isn’t technically absolute — a skill can include tools, and a well-written prompt can get close to what a skill does within a single conversation — but as a framework for understanding the concept it works well: the skill is the layer where the “how” lives, so you don’t have to rewrite it every time.

In practice, a skill usually consists of:

• A SKILL.md file with the instructions the agent loads when it detects the task matches that skill.
• Additional resources: scripts, templates, reference documents, examples.
• Rules about when to activate and when not to.

There are third-party directories that let you search, install, and manage skills through a CLI, similar to how you manage npm packages or editor extensions. There are several to choose from; which one you use is your call, not something this article is going to decide for you.

Are they built into the model, or do you have to install them?

There’s a common misunderstanding worth clearing up here: no skill lives inside the model. Not the ones Anthropic publishes, not the ones OpenAI publishes, not the ones an independent developer publishes. A skill is always a folder with a SKILL.md file that gets loaded into the conversation’s context when the agent detects it matches the task — it’s not part of the training or the model’s weights. What does change from one skill to another is who publishes it, and whether your agent already ships with it available or you have to install it yourself:

• Official first-party skills. Anthropic maintains its own public repository, anthropics/skills , with skills like Frontend Design from our first example, or the ones Claude uses to generate Word, PDF, PowerPoint, or Excel documents. OpenAI maintains the equivalent for Codex at openai/skills . They’re still not “in the model,” but in some products (Claude.ai, for instance) they come toggleable out of the box without you having to touch a terminal.
• Third-party skills. The vast majority — including four of the five examples in this article — are published by companies or developers outside Anthropic and OpenAI: teams like Vercel Labs, or independent developers like Matt Pocock. They install the same way as the official ones, just pointing to a different repository.

And there’s a relevant fact if you’re coming from other AI ecosystems: Agent Skills isn’t a Claude-exclusive format. Anthropic published it as an open standard (spec at agentskills.io ), and since then it’s been adopted by, among others, OpenAI’s Codex CLI, Cursor, GitHub Copilot, and Gemini CLI. In practice, the same SKILL.md you install for Claude Code usually works unchanged in Codex or Cursor — each agent simply looks for it in its own folder (.claude/skills/, .cursor/skills/, ~/.agents/skills/ in Codex…).

How they’re installed, in general. Under the hood, installing a skill just means putting a folder with a SKILL.md inside it in the place your agent reads from. The most direct way is a git clone of the skill’s repository into that folder. There are also several third-party CLIs and installers that automate that step — they download the skill from its repository and copy it into the right directory — which one to use depends on your agent and your own preferences, so we’re not going to recommend a specific one. One of the most common command patterns looks like this:

  npx skills add <user-or-organization>/<repository> --skill <skill-name>
    

For each of the five examples that follow, we note who publishes the skill and exactly how to install it, so you know where it comes from and can reproduce it with whichever installer you prefer.

Why they’re starting to matter

Before diving into the five examples, it’s worth pausing on why this isn’t just a technical curiosity.

Reuse. You don’t need to re-explain the same rules in every new conversation. Install it once and it stays available.

Specialization. A generalist agent can temporarily “put on” the knowledge of a specialist — a designer, a React performance expert, a strict TDD practitioner — without you having to switch models or tools.

Reproducible procedures. The key difference from a loose prompt: the agent doesn’t just know what to do, it has instructions on how to do it, step by step, consistently across runs.

Let’s get to the five examples.

The 5 skills we’re going to look at

We haven’t picked five similar programming skills, but five that cover very different tasks. Before getting into the detail of each one, here’s a quick summary of what each does:

For each one we follow the same structure: what problem it solves, what changes in the agent’s behavior, a practical example, and what you should look for in the result.

1. Frontend Design — teaching AI to design better

What problem it solves. Anyone who’s ever asked an agent to “build me a landing page” recognizes the typical result: cards with a soft shadow, a blue-to-violet gradient, generic typography, lots of whitespace with no clear reason. It’s a correct interface, but interchangeable with any other one generated the same way.

Frontend Design attacks that problem head-on.

Who publishes it. It’s an official Anthropic skill, inside their public anthropics/skills repository. Install it with npx skills add anthropics/skills --skill frontend-design.

What changes when the agent uses it. The skill forces the agent to make conscious decisions before writing a single line of CSS: aesthetic direction, palette, typography, hierarchy, composition. Instead of applying the default visual pattern, the skill itself insists on producing distinctive interfaces and deliberately avoiding the generic-template look.

Practical example. For the comparison to be obvious, it helps to pick something where the agent has a lot of aesthetic freedom — not a SaaS landing page, but content it can use to express its own artistic direction. The text you give it is exactly the same in both cases; the only thing that changes is whether the agent has the judgment to turn it into something with personality.

First, with no skill at all:

“Create a web page about Mars exploration that shows the main missions that have reached the planet.”

Then, with the skill active:

“Use Frontend Design to create a web page about Mars exploration that shows the main missions that have reached the planet. Design a visual experience with real personality, and avoid the typical look of an AI-generated website.”

What you should look for. It’s not enough for it to “look different” — you need to check whether there’s a coherent design decision behind it: a limited, purposeful palette, a typeface that isn’t the framework’s default choice, a layout with clear visual hierarchy instead of stacked blocks with no reason. If the second result only changed the color but kept the same generic structure, the skill hasn’t contributed much.

2. Agent Browser — giving the agent an operational browser

What problem it solves. An agent that only writes code never checks what it builds. It can generate a perfect responsive menu on paper and never notice it breaks on mobile until a human looks at it.

Agent Browser gives the agent operational access to Chrome/Chromium: keeping a session, navigating, inspecting the DOM, interacting with elements, extracting information, and executing actions on real pages.

Who publishes it. It’s a third-party skill: maintained by Vercel Labs, not Anthropic or OpenAI, in the vercel-labs/agent-browser repository. Install it with npx skills add vercel-labs/agent-browser --skill agent-browser.

What changes when the agent uses it. The leap here is different from the previous skill — it’s not a matter of judgment, it’s a matter of verification capability. The agent stops just generating code and can check what it built, the same way a person testing the website would.

Practical example. Here it’s worth avoiding “your local app” entirely — the goal isn’t to simulate a professional QA task, but to confirm, with something any reader can reproduce on the spot, that the agent actually navigates and interacts:

“Open Wikipedia, look up the movie Interstellar, and check who directed it, what year it was released, and which actors appear as lead cast. Then tell me the steps you followed to find the information.”

Or, to push for even more thorough navigation:

“Open Wikipedia, search for ‘Solar System,’ go into the Mars article from that page, and tell me the diameter listed in its infobox.”

The second prompt is the more interesting of the two: even though the model probably already knows Mars’s diameter from memory, the prompt explicitly asks for a navigation sequence — opening the page, finding the link to Mars, clicking it, finding the value in the infobox — so it’s easier to check whether it actually followed it, or just handed you the number without opening anything.

What you should look for. It’s not so much the final fact about Mars that matters, but the sequence that produced it: which page it opened first, which link it found and followed, what it did once it reached the target article. Ask it to describe those steps. If the answer is generic (“everything looks correct,” or just the fact with no explanation of how it got there) with no detail of the actual navigation, the agent is probably generating plausible-sounding text — or even recalling the fact from training — instead of having actually navigated.

3. Vercel React Best Practices — turning expert knowledge into reusable instructions

What problem it solves. Writing React that “works” is easy. Writing React that performs well — no request waterfalls, no unnecessary re-renders, good bundle size, correct hydration — requires the kind of knowledge that usually lives inside a senior engineer’s head, not in a one-line prompt.

This skill encapsulates on the order of 70 optimization rules, organized by impact: waterfalls, bundle size, server performance, re-renders, hydration, and JavaScript optimizations.

Who publishes it. Also from Vercel Labs, this time from the vercel-labs/agent-skills repository. Install it with npx skills add vercel-labs/agent-skills --skill react-best-practices.

What changes when the agent uses it. This is the clearest example of a skill that doesn’t always add a new tool — sometimes it adds specialized judgment. The agent still has the same technical capabilities as before (reading code, editing it), but now applies them with the accumulated knowledge of a performance team.

Practical example. We start from a small React app that displays a list of Pokémon fetched from an API and lets you mark them as favorites — something any reader visualizes immediately, instead of “an enterprise component that needs optimizing.” The component intentionally includes several typical problems: a poorly structured data fetch, filtering that repeats on every render, images that load unnecessarily, child components that re-render for no reason, and imports that are bigger than they need to be.

“This small React app shows a list of Pokémon and lets you mark them as favorites. Analyze the code using Vercel React Best Practices. First identify the performance problems, rank them by impact, and then apply the improvements.”

What you should look for. The sign that the skill is contributing something real is that the agent prioritizes: it doesn’t just dump a list of changes, it explains which ones matter more and why (for example, removing a network waterfall usually outweighs a micro-tweak to memoization). If every suggestion is presented as equally important, the skill isn’t applying its own sense of impact.

4. TDD — teaching the agent a working methodology

What problem it solves. Asking an agent to “write tests for this” usually produces tests that confirm what the code already does, not tests that define what the code should do. It’s just as easy to generate badly as it is to write badly by hand.

Matt Pocock’s TDD skill doesn’t just explain what a test is — it defines how the agent should approach development: the red → green → refactor cycle, behavior-based tests (not implementation-based), working against public interfaces, vertical slicing of features.

Who publishes it. It’s a third-party skill published by Matt Pocock (an independent developer well known in the TypeScript community), in the mattpocock/skills repository. Install it with npx skills@latest add mattpocock/skills, picking the TDD skill from the ones the installer offers; it’s also available as a plugin installable directly from Claude Code (/plugin install mattpocock-skills).

What changes when the agent uses it. This is a third type of skill, different from the previous two: it doesn’t give design judgment or a new tool — it changes the agent’s reasoning and execution process. The order in which it does things changes, not just the final result.

Practical example. Email validation is the most common example for TDD, but it has a problem: “what actually counts as a valid email” has too many debatable subtleties, and that distracts from the process. A converter from integers to Roman numerals is more intuitive — any reader can immediately tell whether 4 → IV is right or wrong — and it also grows case by case very naturally, which is exactly where TDD shines.

“Create a function that converts integers to Roman numerals using TDD. Don’t write the full implementation up front: define one behavior first, write a test that fails, implement only what’s needed to make it pass, and keep iterating with new cases.”

The expected result is a visible progression, where each new case forces the implementation to generalize a bit further:

  // 1. RED — test fails because the function doesn't exist yet
  test("converts 1 to I", () => {
    expect(toRoman(1)).toBe("I");
  });
    

  // 2. GREEN — minimal implementation that makes the test pass
  function toRoman(num) {
    return "I";
  }
    

  // 3. REFACTOR — a new case forces generalization, not a patch
  test("converts 4 to IV", () => {
    expect(toRoman(4)).toBe("IV");
  });
    

And so on, with each case forcing a new rule in the implementation: 2 → II, 5 → V, 9 → IX, 14 → XIV, 49 → XLIX. The reader can follow the whole progression without needing extra context, and it’s easy to see how the RED → GREEN → REFACTOR cycle evolves the function case by case.

What you should look for. The proof that the skill is working isn’t that “there are tests” — it’s the order: the test has to be written and run red before any implementation exists. If the agent writes the full function first and then tests that simply confirm it, it’s simulating TDD, not applying it. Also check whether each new case (the 4, the 9, the 49…) actually forces a change to the implementation, or whether the agent just adds tests that already passed with the previous code — that would be a sign it’s not letting the tests drive the design.

5. Oil Motion — moving from generating code to producing experiences

What problem it solves. Making an element “animate on scroll” is simple. Coordinating AI video generation, key-state design, frame-by-frame cleanup, per-device weight optimization, and mapping that animation to real interaction (scroll, mouse, drag, touch, orientation) no longer is.

We’re not including Oil Motion because it’s among the most installed skills — we don’t have data to back that claim — but because it’s by far the most striking example of how far a complete workflow can go when packaged into a skill. And editorially, we cared more about having five examples that were distinct from each other than five consecutive entries from the same leaderboard.

Who publishes it. It’s an independent open-source project, maintained at oil-oil/oil-motion, unrelated to Anthropic, OpenAI, or Vercel. It’s also the example with the most informal installation of the five: it doesn’t offer a CLI command — its own documentation simply tells you to ask your agent to install the skill from the GitHub repository URL.

What changes when the agent uses it. Here the skill doesn’t give judgment or methodology: it coordinates a complete multi-stage pipeline that would normally require several different tools and several people. The agent goes from “writing the animation’s code” to producing the animation from start to finish: reference images → key states → AI-generated video → frame-by-frame cleanup → asset optimization → wiring to scroll control.

Practical example. Instead of “two product images” — which sounds like an ecommerce demo — a conceptually simple example works better, one where anyone immediately understands the relationship between scroll and what’s on screen:

“Use Oil Motion to create an experience where a closed flower progressively opens its petals as we scroll, until it’s fully open by the end of the page.”

The relationship is instant: scroll at the top → closed bud; scroll midway → progressive opening; end of the page → fully open flower.

What you should look for. The final animation is what’s visible, but what proves the skill is doing its job well is what happens before that: whether it fixes the key states first — closed bud, partial opening, open flower — before generating continuous video between them, and whether it respects the distinction between what the AI generates (the organic motion of the petals, texture, light) and what the code itself controls (exactly which scroll point triggers each state, speed, limits). If the flower looks good but loses its shape or proportion between one state and the next, the problem isn’t in the video — it’s that the key states weren’t properly defined.

Don’t install just any skill you find

This section isn’t optional. A skill shouldn’t be treated like some random prompt you found online.

Unlike a prompt, a skill can include instructions that load automatically, run scripts, access files on your system, and use any tool the agent has available. The people who maintain skill directories are usually upfront about this: they can’t guarantee the quality or safety of everything published there, and they recommend reviewing it before installing.

And there’s a very current reason not to treat this as a generic textbook warning: this very week, there have been reports of campaigns using malicious skills, with typosquatted names imitating popular ones, to try to steal credentials and other data from the teams running them.

Before installing a skill:

• Check who maintains the repository.
• Read the full SKILL.md, not just the directory description.
• Review the scripts it includes, if any.
• Check what permissions or access it needs to work.
• Be wary of names nearly identical to popular skills.
• Don’t install it just because it has a lot of downloads — that tells you it’s popular, not that it’s safe.

Wrapping up

We’re not going to close by saying skills are “the future of AI agents.” The interesting shift isn’t simply giving a model more capabilities — we’ve already been talking about that for a while with tools and MCP. What’s interesting is being able to package experience, procedures, and judgment so an agent reuses them exactly when it needs them, without you having to repeat them every time.

If you want to experiment, don’t start by installing twenty skills at once. Pick a single task that lets you clearly see the difference between before and after — it doesn’t have to be something you repeat daily at work: it can be as simple as asking your agent for the same web page with and without Frontend Design, or having it actually navigate Wikipedia with Agent Browser. Install a single skill, try the same prompt with and without it, and compare the result. That comparison, more than any install list, is what will tell you whether it’s worth it.

Happy Building!!