Most of us keep teaching AI the same things over and over. Use these tokens. Match this grid. Don't hardcode that hex value. You paste the same context into a new chat, get a decent result, and then do it all again next week like it never happened.
Agent skills fix that. You build one once (or grab one someone else already made), wire it into your design system, and your AI just reaches for it when the moment calls for it. No pasting, no re-explaining. Below I'll walk through what a skill actually is, why it's a big unlock for design systems specifically, real examples we run with clients, and how to create your own in about five minutes.
In this guide I'll break down what an agent skill is and how it's different from the markdown files and saved prompts you're probably already using. Then we'll get into why this matters so much for design systems, a handful of real examples, and a step-by-step playbook for building your own.
Table of contents:
- What is an agent skill?
- Why agent skills matter for design systems
- Agent skills examples
- How to create an agent skill
- Agent skills tools and resources
What is an agent skill?
An agent skill is a packaged set of instructions your AI loads on its own, only when a task matches it. Unlike a static file you have to attach, a skill carries a name and a description, and the AI reads that description to decide whether your request fits. If it does, the skill loads automatically. If it doesn't, it stays out of the way.
That last part is the whole point. A skill is not just a .md markdown file. It's more than that, because a markdown file sits there until you remember it exists and manually pull it in. A skill is already "programmed" into your environment, so the right context triggers it without you naming it.
In practice, this looks like:
- You prompt "I need to design a new screen," and a design skill loads because its description matches.
- You start building a component, and an accessibility skill quietly makes sure what you ship is accessible, without you asking for it.
- You take a design from Figma into code, and a Figma skill kicks in to clean up the messy bits before anything gets written.
A skill can also bundle more than instructions. It can carry a template, company context, or pointers to specific files, so when it runs it already knows which template to apply and which files to pull. That's what turns a skill from "a prompt I saved" into "a repeatable piece of my workflow my whole team shares."
Agent skill vs. markdown file
A markdown file is passive. You have to call it, upload it, or say "hey, use this file here." A skill is active: it's described well enough that the AI recognizes when it applies and pulls it in for you. The difference sounds small, but it's the difference between a reference doc you forget to open and a teammate who knows when to step in.
Agent skill vs. MCP
People mix these up because they show up together. An MCP (like a Figma MCP) is the connection, the pipe between your AI and a tool or data source. A skill is the know-how layered on top of it: the rules for how to use that connection well. The Figma MCP gives your agent access to your file; the Figma skill tells it how to clean up and structure what comes through.
Agent skill vs. a saved prompt
A saved prompt is something you copy and paste when you remember to. A skill is a saved prompt that's been given a job description and the judgment to apply itself. Once it's installed, you stop thinking about it. You run it once, and then it just lives in your workflow.
Why agent skills matter for design systems
Design systems are made almost entirely of repeatable patterns. Your component conventions, your tokens, your handoff rules: those don't change shape from feature to feature. They're exactly the kind of thing you should encode once and never re-explain. Right now, most teams re-explain them constantly, which is slow and leaves room for drift every time someone forgets a rule.
This isn't a magic button. A skill is only as good as the description that triggers it and the patterns you put inside it, and the best ones get refined over time. But when you get it right, the payoff compounds across your whole team.
Done well, agent skills give you:
- Consistency by default. Every component gets checked against your tokens and conventions automatically, so hardcoded values and one-off spacing stop sneaking in.
- Speed without hand-holding. Designers spin up new features and the rules apply themselves, instead of someone re-pasting the same context into every session.
- Shared institutional knowledge. The way your best person handles your grid or your handoff becomes a thing the whole team runs, not tribal knowledge that walks out the door.
Agent skills examples
Skills earn their keep on the stuff you'd otherwise do by hand on every single feature. Here are a few real examples of what that looks like in practice.
Example 1: a custom grid skill for a client
The problem: One of our clients runs a genuinely complex grid in their product, with a lot of rules about how and when to use it. Every time a designer spun up a new feature, getting the grid right was a manual, error-prone pass. The solution: We built a skill for that grid. It encodes the rules and functions for how the grid is supposed to work, so when a designer starts a new feature, they run the skill and it compiles and aligns everything to spec. The grid knowledge lives in the skill, not in one person's head. The result: What used to be a careful manual check on every new feature is now a single step that applies the same rules the same way, every time.
Example 2: Figma skills that ride on the Figma MCP
The problem: Moving designs between Figma and code is where things get messy: weird artifacts, structure that doesn't translate cleanly, and a lot of cleanup after the fact. The solution: A pair of Figma skills that come alongside the Figma MCP. When you bring a design from Figma into code, one skill debugs the weird Figma quirks before anything gets written. Going the other direction, from code back into Figma, another skill makes sure the file gets built the right way. Because they're described well, they trigger automatically when you cross between the two. The result: The design-to-code trip stops being a cleanup chore and starts being something the agent handles in stride.
Example 3: extracting a design system from scratch
The problem: We're building an open-source product called Carrot (a feedback widget that lets stakeholders leave inline comments on any page of a prototype, then routes them to an agent that fixes them in the codebase). Early on, it had no tokens or styling to work from.
The solution: We pointed an "extract design system" skill at the site we were building on and asked it to pull the design system out. We never named the skill in the prompt. We just gave it the right context, and it recognized which skill to use on its own. It produced a structured file with the primary colors, fonts, and spacing keys: a clean starting point for building real tokens.
The result: A blank project went from no design language to a documented set of tokens in one pass, ready to build on.
Example 4: a token-audit skill, created from a one-off task
The problem: While auditing a component library, we found components leaning on hardcoded hex values instead of design tokens, the kind of drift that quietly erodes a system.
The solution: We had the agent extract the widget tokens and swap the hardcoded values for the correct token colors. Then, instead of repeating that by hand on every component, we asked it to turn the action into a skill, so every new component gets checked for tokenized values automatically.
The result: Token enforcement moved from "something we remember to do" to "something that happens on every component by default." (More on how we built that one below.)
How to create an agent skill
You don't need to be a heavy engineer to build a skill. The trick is to let a real piece of work become the skill, instead of trying to author one from a blank page. At TDP this is exactly how we build skills with clients: we do the thing once, then capture it.
Here's the playbook.
1. Notice a repeating action
Watch for the task you keep doing. Auditing components, aligning a grid, extracting tokens, checking accessibility. If you've done it more than twice and it follows the same shape each time, it's a candidate. The repetition is the signal.
Ask yourself: what do I re-explain to my AI almost every session?
2. Do it manually once, the right way
Just prompt it. For the token audit, that was "do an audit of the components we currently have in the product," then "let's start by extracting the widget tokens." This isn't a skill yet, it's you working through the task normally and getting the output you actually want. Get it right here, because this becomes the template for the skill.
3. Ask your agent to turn it into a skill
Once the output is good, say something like "I'd like to create a skill for this, so every component I create gets checked for tokens." Your agent uses its skill-creation guidance (which is itself a skill) to build the new one following the correct structure and layout. You're not writing boilerplate, you're describing the job.
4. Review the name and description
This is the part that matters most. The description is what decides whether the skill ever triggers, so read it closely. A good one reads like a job description: "audit and create product components so UI styling uses the repo's design tokens instead of scattered hardcoded values." If the description is vague, the skill won't load when you need it.
5. Use it, then keep it updated
The skill now lives in your skills folder and reaches for itself when the context matches. As you build more, you'll find edges where it falls short or patterns worth adding. When that happens, just say "update the skill." Skills are living things, so the goal is for yours to always reflect your latest, best way of working.
Building a skill doesn't have to be complex. Do the work once, capture it, refine it, and your team inherits the best version of every repeatable task.
Agent skills tools and resources
The fastest way to start is to not start from scratch. Our team keeps a public agent skills repo with the skills we use regularly, and you can pull the whole bundle or pick individual ones.
A well-built skill ships with install instructions, so getting one running is usually a copy-paste into your terminal followed by a couple of prompts: which skills you want (spacebar to select), whether to take the recommended extras, and whether to install at the project level or globally so it applies across everything you work on.
A few skills worth grabbing first:
- The skill-creation skill, so every skill you build follows a clean, consistent structure.
- Figma skills, if you're regularly moving between Figma and code.
- An "extract design system" skill, for getting tokens out of an existing site or product fast.
- A component-metadata skill, for documenting when, where, and how each component should and shouldn't be used.
If your product team is staring at this wondering how to actually build a design-to-code process, or how to keep a design system from drifting as you scale, that's the exact problem we help with at TDP. We run a small number of workshop slots where we come in, assess what's working and what isn't, and build a process you and your team can carry into the product yourselves.
Get started
Go wire a skill into your design system this week. Start with one repeating task, capture it, and let it run. If you want a hand building the process, book a design systems workshop with our team.
