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) — MCP is the open protocol most agents use to expose those tools.
- 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.mdfile 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 atopenai/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.
If you want to see this working end to end in a real coding workflow rather than in isolated examples, we already covered a concrete case: how Superpowers turns Claude Code into a senior developer by packaging TDD and systematic debugging as reusable skills.
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:
| Skill | What it does |
|---|---|
| Frontend Design | Gives the agent aesthetic judgment to design interfaces with personality, instead of the generic default look. |
| Agent Browser | Gives it access to a real browser so it can check, on the actual page, what it just built. |
| Vercel React Best Practices | Applies expert-level performance rules when analyzing and refactoring React components. |
| TDD (Matt Pocock) | Forces the agent to follow the red-green-refactor cycle instead of writing tests after the code. |
| Oil Motion | Coordinates an interactive animation end to end: AI video generation, frame cleanup, and scroll wiring. |
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 (specifically under skills/frontend-design). Install it with npx skills add anthropics/skills --skill frontend-design; if you work from Claude Code, the alternative documented in the repository itself is /plugin marketplace add anthropics/skills followed by /plugin install example-skills@anthropic-agent-skills.
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.”
Without the skill:
With Frontend Design:
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 40+ optimization rules, organized into 8 categories 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 (the TDD skill lives under skills/engineering/tdd). 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
Heads-up: unlike the other four skills in this article, Oil Motion doesn’t work “for free” just by installing it. It needs a paid API key from an external service (ZenMux) to actually generate the AI video; without it, it installs fine but can’t produce any animation. We go into the details a bit further down.
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.
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 like npx skills add — its own README literally tells you to ask your agent to install the skill from the repository URL, with an instruction along these lines:
“Tell your agent: help me install the skill at https://github.com/oil-oil/oil-motion."
What you need before you can generate anything. Installing the skill itself is painless: the deterministic part of the pipeline only depends on Python 3, Pillow, numpy, ffmpeg, and ffprobe — tools you likely already have if you work with video or images. But having the skill installed isn’t the same as being able to generate animations yet. Per its own SKILL.md, Oil Motion hard-codes its default video model to minimax/minimax-h3
, served through ZenMux
— a third-party gateway that unifies access to several AI models behind a single API — and the skill itself avoids offering other models unless you explicitly ask for one or MiniMax can’t do what you need. Generating your first video requires setting up a ZenMux API key: it’s a paid service (MiniMax H3 bills per second of generated video, both for input and output, and ZenMux has no free tier), and until you configure it the skill stays installed but can’t produce a single new frame. The agent walks you through entering it the first time with python3 scripts/oil_motion_config.py set; the key isn’t asked for again or stored in the project — it lives in ~/.config/oil-motion/config.json, with permissions restricted to your user, and can also be set as an environment variable (ZENMUX_API_KEY).
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. Generating our own video with Oil Motion means paying per second through ZenMux, so instead of billing ourselves for an original example we’d rather show the demo the project itself uses to present its work — that way you see firsthand the kind of output the pipeline produces, without taking our word for it.
In the video, the English headline “Oil makes things.” appears in large, bold type next to a black-and-white, sketch-style illustration of a character with glasses leaning against the word “things.”, with a color-illustrated dog (brown, white, and yellow) right below. In the bottom-left corner there’s a Chinese signature (“歐呦”) next to “ENGINEER / DESIGNER / OPEN-SOURCE” and the prompt “↓ 往下滑” to scroll down. A cursor moves through the scene: first it drags the dog slightly, then it moves up to the main text and interacts with the period at the end of “things.”, and finally it drifts back toward the bottom-right corner, next to the dog.
What you should look for. Even though we didn’t generate this video ourselves, it illustrates well what the skill promises: a scene where a hand-drawn illustration (the black-and-white sketch) coexists with a color element, and where the motion isn’t a standalone looping clip but reacts to real interaction — the cursor drags the dog, touches the period at the end of the sentence, moves across the screen. That’s exactly what Oil Motion coordinates: AI-generated visual states that trigger and respond according to what the visitor does, not a decorative background animation.
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.
This isn’t a generic textbook warning either: skills carry the same supply-chain risk as any package you install from a third-party registry, and scam and fraud campaigns keep finding new distribution vectors as soon as a new install mechanism becomes popular. It already happened with skills: in July 2026, attackers uploaded trojanized skills to a popular marketplace under typosquatted names impersonating legitimate tools, and by early August the campaign had reached 1.7 million combined installs while stealing SSH keys, cloud credentials, and other secrets from developer machines .
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.
One last thing worth being explicit about: not every skill is free just because it’s public. Skills come from all kinds of origins — an Anthropic team, a company like Vercel, an independent developer, an open-source project maintained by a couple of people — and that origin shapes what it actually costs you to use one, beyond the time it takes to install it. Four of today’s five examples work the moment you install them, at no extra cost. Oil Motion is deliberately the exception: we included it precisely so you’d see, with a real case, that some skills depend on a paid third-party service to do anything at all, and that “installed” doesn’t always mean “ready to use for free.”
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!!