How to create your first Claude skill: a step-by-step guide for designers.

Introduction

Every designer has a list of checks they run from memory before handing a file over: empty states, error messages, contrast, the extra-long name that breaks the layout. From memory means that sometimes a check gets skipped.

A skill puts that list in writing once, in a format Claude reads and applies whenever it is needed. In The 13 Claude Skills to Use if You Are an Experience Designer I collected the ready-made ones. Here we build yours, step by step, on a real example: a skill that runs a design review of a screen.

The timing is good. Since 22 October 2026 skills are an open standard run by the Linux Foundation, which according to Anthropic more than 70 platforms have adopted. The skill you write today for Claude also works in Cursor, GitHub Copilot or ChatGPT.

What a skill is, concretely

A skill is a folder. It holds at least one file, SKILL.md, in two parts: a header with the name and the description, and the instructions below it in Markdown. You can add more folders: references/ for documents to consult, scripts/ for code, assets/ for templates and images.

reviewing-designs/
├── SKILL.md
└── references/
    └── checklist.md

Claude loads it in layers, which is what keeps skills light:

• At startup it reads only the name and description of each installed skill: about a hundred tokens per skill, according to the specification.
• When a request matches the description, it reads the whole SKILL.md.
• Only when needed it opens the reference files the instructions point to.

You can install dozens of skills without weighing conversations down. In exchange, the description has a precise job: it is the only thing Claude reads to decide whether to use the skill.

Choose what goes into a skill

A good first skill comes from work you do often, with rules you can write down. Three typical candidates for a designer:

• Design review: the checklist before a user test or a handoff.
• Tone of voice: the approved vocabulary and microcopy rules of a product.
• Handoff notes: the annotation format your development team expects.

Leave out whatever depends on taste of the moment. If you cannot explain a rule to a colleague in two lines, Claude will not apply it any better than they would.

Step 1: the folder and the name

The name has strict rules, because it has to work on every platform:

• 64 characters at most, lowercase letters, numbers and hyphens only;
• no hyphen at the start, at the end, or doubled;
• identical to the folder name;
• no reserved words such as "claude" or "anthropic", which the API rejects.

Anthropic's guide suggests an "-ing" verb that names the action: reviewing-designs, writing-microcopy. It is a recommendation, not a requirement. Avoid generic names like helper or tools: with ten skills installed you would no longer know what each one does.

Step 2: the description

This is the most important part, and the one most often done wrong. The description says two things: what the skill does and when to use it. The official guidelines ask for the third person and for the words a user would put in the request.

Two tips:

• Be a little pushy. Anthropic's skill-creator notes that Claude tends to leave skills unused when it could use them. Listing the ways a request may arrive ("review", "feedback", "check") helps.
• Stay under 200 characters. The standard allows up to 1,024, but the Claude.ai help center gives 200 as the maximum. At 200 you are safe everywhere.

Step 3: the instructions

Below the header, write what Claude should do. The rules that matter, from the official guidelines:

• Short. Claude already knows what an interface is: write only what it cannot know, meaning your method and your criteria. Under 500 lines, ideally far fewer.
• Imperative. "Check the empty states", not "it would be useful to check".
• With the reason. A rule that comes with its reason gets applied with judgment, even to cases you did not foresee. A rule shouted in capitals gets applied blindly.
• With the output format. If you want a table with priorities, say so. Otherwise every review will take a different shape.

Step 4: the reference files

The full checklist is long, and Claude does not need to read it for every request. Put it in references/checklist.md and mention it in SKILL.md: Claude opens it when it gets there. The specification recommends keeping references one level deep, with no files pointing to other files.

The complete skill

This is the SKILL.md. Copy it and adapt it.

---
name: reviewing-designs
description: Reviews screens, mockups and Figma frames for missing states, accessibility, copy and edge cases. Use when the user asks for a review, feedback or a check on an interface.
---

# Design review

Review the interface the way a senior designer would before a user
test. Look for the problems that get expensive after release; leave
aesthetic taste out of it.

## How to proceed

1. Understand what you are looking at: which screen, for whom, which
   task it must support. If that is unclear, ask before starting.
2. Go through the five groups in references/checklist.md, in order.
3. Report only problems you can see or infer with confidence. Whatever
   a static image cannot show (keyboard focus, animation) goes into the
   open questions.

## Response format

A table with four columns: priority (blocking, important, polish),
where, what happens to the user, how to fix it.
Then three open questions at most.
End with one line on the strongest part of the screen, so whoever gets
the review knows what not to touch.

## Avoid

- Proposing a full redesign: fix what is there.
- Commenting on colours or fonts unless they break a checklist item.

And this is references/checklist.md:

# Review checklist

## 1. States
Empty, loading, error, success, partial content, offline, first use.
Every missing state is a screen development will improvise.

## 2. Accessibility
- Text contrast at least 4.5:1; 3:1 for large text and UI components
  (WCAG 2.2, level AA).
- Touch targets of 44x44 pt on iOS and 48x48 dp on Android.
- Every icon without text has a label.
- Information never relies on colour alone.

## 3. Copy
- One concept, one word: no synonyms for the same action.
- Buttons with a verb that says what happens.
- Every error says what to do next.

## 4. Edge cases
Very long names, large numbers, zero items, a thousand items, slow
network, translations longer than the original.

## 5. Design system
Components, tokens and spacing of the system in use. Every exception
needs a reason.

Step 5: install it

It depends on where you work.

• Claude Code. Put the folder in ~/.claude/skills/ to have it in all your projects, or in .claude/skills/ inside a project to share it with your team through the repository. You can also call it by hand with /reviewing-designs.
• Claude.ai and the desktop app. Zip the folder, then go to Customize, Skills, press "+", "Create skill" and "Upload a skill". Skills are available on every plan, Free included, with code execution enabled; on Enterprise plans an admin has to turn them on.
• API. Skills are uploaded through their own endpoint and passed to the request along with the code execution tool.

The other platforms that adopted the standard read the same folder: only the place you put it changes.

Step 6: test it

A skill does not work until you have seen it trigger. Prepare two sets of requests.

• Requests that should trigger it, with an image attached: "Can you give me feedback on this checkout screen?", "Check this frame before I hand it to the developers".
• Requests that should not: "Design a login screen for me". Here the user asks to create, not to review.

To see whether the skill loaded, look at Claude's reasoning on Claude.ai; in Claude Code, ask "What skills are available?". If it does not trigger when it should, the description is almost always the problem: add the words you used in the request.

Anthropic suggests writing at least three test cases before the instructions, and working with two conversations: one where you write the skill with Claude, another where you use it as a user would. What goes wrong in the second tells you what to fix in the first.

The most common mistakes

• A generic description. "Helps with design" triggers never, or always.
• Instructions that explain the obvious. Every useless line takes attention away from the useful ones.
• Too many alternatives. "You can do A, or B, or C" leaves Claude to pick at random. Give one route and say when to switch.
• Information with a date. "Starting next month" ages. Write rules that stay true.
• Claude Code fields elsewhere. Claude Code accepts extra header fields. Uploaded to Claude.ai or through the API, the same fields block the installation: for a skill that travels, use only the name and description.
• Passwords and keys in the file. A skill gets shared like a document: put nothing in it you would not give a colleague.

A note on security

A skill can contain scripts and ask for access to tools. Anthropic recommends using skills only from sources you trust and reading all their files before installing them, as you would with a program. Skills you write yourself raise no issue. For the ones you find online, five minutes of reading are worth it.

Frequently asked questions

Do I need to code to create a skill?

No. A design skill is a Markdown text file with a two-line header. Scripts are optional.

Can I write the skill in a language other than English?

Yes. Claude understands instructions in other languages, and if your requests are in that language the description should be too, because it holds the words that trigger the skill.

How long should the description be?

The standard allows up to 1,024 characters, but the Claude.ai help center gives 200 as the maximum. Under 200 characters works everywhere.

Do skills work on Claude's free plan?

According to the Claude help center, yes: skills are available on every plan, Free included, with code execution enabled.

Can I use the same skill outside Claude?

Yes, if you follow the Agent Skills standard: a valid name, a description and instructions in SKILL.md, and no field specific to a single platform.

Conclusion

Your first skill does not need to be ambitious. It needs to hold something you do well and today repeat from memory, written so that another person, or Claude, can do it in your place with the same criteria.

Start from the design review in this article, try it on three real screens and fix the description until it triggers when it should. Then move on to your product's tone of voice, and once the copy is ready, give it a pass with Stop Slop.

Updated 2 November 2026, based on the agentskills.io specification and Anthropic's official documentation.