The problem

You use Claude Code. It gets the job done. You say "add a contact form", it adds one. You say "make this page cleaner", it does.

But you keep repeating yourself. Every new session, the same explanations. "Use a direct tone, no jargon." "The project colors are cream, olive and forest." "When you write, no em dashes, no emojis." Maybe you've put that in your CLAUDE.md, and that's fine. But some tasks need more than a line of convention.

You want Claude to write your articles in a specific tone. To analyze a competitor's site with your own framework. To generate creative briefs formatted for your design team. That doesn't belong in a global config file. It deserves its own space.

That's exactly what Skills do.

Before we go further: Claude Code is not just about code

The name is misleading. Claude Code is a tool that can read files, create them, browse the web, run commands, structure information. Yes, it's excellent at coding. But on a daily basis, I use it just as much to write an article, analyze positioning, prepare a brief or synthesize research as I do to write JavaScript.

Everything in this article (Skills, commands, libraries) applies to any use case. Writing, research, design, strategy, organization. Code is just one case among many.

What is a Skill?

A Skill is a set of instructions you give Claude for a specific task. Not code. Not a plugin. A text file with structured instructions.

You type /site-analysis in Claude Code, it reads the Skill's instructions and gets to work. It knows what to look at, in what order, with what output format. You don't need to explain anything. It's the same result as spending 5 minutes briefing Claude at the start of a conversation. Except you did it once and for all.

The difference with CLAUDE.md: CLAUDE.md is loaded in every conversation, it's the project rules, always present in the background. A Skill is only loaded when you call it. It's knowledge on demand.

What you need

Prerequisites

• Claude Code installed (CLI, VS Code, or directly on claude.ai/code)
• A text editor. Any will do: VS Code, TextEdit, Notepad, doesn't matter
• Basic markdown knowledge. If you can put a # before a heading and - before a list item, you're good. More on this just below

That's it. No coding skills required.

The anatomy of a Skill

A Skill is a folder with a SKILL.md file inside.

my-skill/
  SKILL.md

The file has two parts. First the frontmatter, the configuration, between two --- lines. Then the content, the instructions Claude will follow, written in markdown.

Here's what it looks like for a Skill that analyzes a website:

---
name: site-analysis
description: Analyzes a website for design, content and user experience
disable-model-invocation: true
allowed-tools: Read, Grep, WebFetch
---

## Your mission

Analyze the requested site. Evaluate:

1. Message clarity (can you understand what the product does in 5 seconds?)
2. Visual hierarchy (headings, spacing, contrast)
3. User journey (from landing to main action)
4. Editorial tone (formal, conversational, technical?)

## Output format

For each point:
- Observation (what is)
- Verdict (what works / what doesn't)
- Concrete suggestion

It's markdown. If you can write a reasonably structured email, you can write a Skill.

What's markdown?

A simple text format used everywhere in the tech ecosystem. # makes headings, ** makes bold, - makes lists. You've seen it in README files on GitHub. No special software needed, a text editor is all you need.

The frontmatter in 4 lines

Four fields, no more, and you cover 90% of cases:

• name: your Skill's name. It's also your slash command. site-analysis gives you /site-analysis.
• description: what the Skill does. Important: Claude uses this description to decide whether to invoke it on its own. The more precise, the better it decides.
• disable-model-invocation: true if you want to stay in control. Claude will only run the Skill when you explicitly ask.
• allowed-tools: tools allowed without asking your permission. Read, Grep for read-only. Add WebFetch if it needs to go on the web.

Other fields exist (model choice, effort level, isolated execution) but you don't need them to get started.

Invoking a Skill

Couldn't be simpler. Type the slash command:

/site-analysis

Claude loads the Skill's instructions. It asks for what's missing, here the URL of the site to analyze. You provide it, and it runs through the analysis point by point, exactly as you defined it.

Sometimes you don't even need to type anything. If your Skill has a good description and auto-invocation is active, Claude detects it on its own. You say "give me your take on this competitor's website", it finds your analysis Skill and applies it.

The common sense rule: if the Skill modifies files, publishes something, or has any side effect, keep control with disable-model-invocation: true. If it's read-only (analysis, research, writing), let Claude decide.

Going further: passing arguments

You can inject information directly into the command. The Skill picks it up via $ARGUMENTS.

Example: a Skill that generates a creative brief.

---
name: design-brief
description: Generates a structured creative brief for the design team
disable-model-invocation: true
---

## Creative brief

Create a design brief on the following topic: $ARGUMENTS

Brief structure:
- Context and objective
- Target user
- Desired art direction
- Technical constraints (formats, responsive, accessibility)
- 3 relevant inspiration references (search the web)

The invocation:

/design-brief pricing page redesign for the SMB segment

Claude receives the entire phrase after the command and generates the full brief. The structure stays the same, only the topic changes. You produce a brief in 30 seconds instead of 10 minutes.

You can also split arguments by position when you have multiple distinct inputs:

---
name: compare-sites
description: Compares two websites on design and content
---

Compare these two sites:
- Site A: $ARGUMENTS[0]
- Site B: $ARGUMENTS[1]

For each criterion (message clarity, design, user journey, editorial tone),
indicate which is more effective and why.

/compare-sites https://stripe.com https://lemonsqueezy.com

Your personal library

Skills live in two places depending on their scope:

Project Skills are shared: you commit them to your repo, the whole team benefits. Personal Skills are your own toolbox. Your style, your methods, your shortcuts.

Example personal library:

~/.claude/skills/
  site-analysis/SKILL.md       → UX audit of a website
  write-article/SKILL.md       → Writing in your voice
  design-brief/SKILL.md        → Creative brief for the team
  tech-watch/SKILL.md          → Trend synthesis

And in a specific project:

.claude/skills/
  editorial-guidelines/SKILL.md → Project writing rules
  a11y-audit/SKILL.md           → Project-specific accessibility checklist

If a project Skill and a personal Skill share the same name, the project wins. Makes sense: project conventions take precedence over individual preferences.

Sharing Skills

This is where it gets interesting. Skills follow an open standard, Agent Skills, designed to work beyond Claude Code.

Sharing happens at three levels:

The Git repo, the most natural. Your Skills are in .claude/skills/, you push, your colleagues have them. The team builds its standards, Claude applies them. The new hire who joins? They get the same Skills from day one.

Plugins, for sharing beyond a single project. You package your Skills with a JSON manifest, distribute via GitHub or an internal registry. Useful when multiple teams want the same workflows.

The marketplace, for the community. Anthropic offers a space to publish your plugins. You submit, it gets reviewed, and it becomes available to everyone.

The core idea is simple. The best workflows aren't decreed from above. They emerge from practice. Someone finds a good way to analyze a market, write a landing page, structure a research process. They turn it into a Skill, they share it. Others adapt it, improve it. It's open source applied to work methods.

What's next

If you use Claude Code occasionally, Skills won't change much. But if you use it every day, to design, write, analyze, structure, Skills turn a generic assistant into a tool that knows your methods.

You stop repeating yourself, you start compounding. Every good practice you find, you lock it into a Skill. Next time, it's automatic.

The first article covered the pipeline: Claude Code, GitHub, Vercel, domain name. The foundation. Skills are the first layer of customization on top. Your AI, your rules.