Claude Code skills explained: what they are and which to write for a website

A Claude Code skill is a saved set of instructions, stored as a SKILL.md file, that Claude can use whenever a task calls for it. Anthropic's docs put it simply: "Create a SKILL.md file with instructions, and Claude adds it to its toolkit. Claude uses skills when relevant, or you can invoke one directly with /skill-name." If you keep pasting the same checklist or procedure into chat, that is a skill waiting to be written.

For a website team, skills are where repeatable jobs live: the SEO check you run on every changed page, the steps for publishing a blog post, the rules for adding a redirect. This guide explains how skills work as of October 2026, where the files go, how to control who triggers them, and which ones are worth writing first. You don't need to be a developer to write one, but a person should review every skill before the team relies on it.

What a skill is, and how it differs from CLAUDE.md

Claude Code reads two kinds of standing instructions. CLAUDE.md holds facts and rules that apply to every session: your build command, your branch rules, where the content lives. A skill holds a procedure for one kind of job. Anthropic's advice is to create a skill "when a section of CLAUDE.md has grown into a procedure rather than a fact." The difference matters for cost: "Unlike CLAUDE.md content, a skill's body loads only when it's used, so long reference material costs almost nothing until you need it."

Anthropic's docs describe two kinds of skill content:

• Reference content: knowledge Claude applies to current work, such as your style guide or schema conventions.
• Task content: step-by-step instructions for a specific action, such as publishing a post or deploying to staging. These are usually run on purpose with /skill-name.

Skills follow the Agent Skills open standard, so a simple skill can work in other tools that support it. Claude Code adds its own extras, such as invocation control and running a skill in a subagent. For what belongs in CLAUDE.md itself, see how to write a CLAUDE.md for a website.

Where skill files live

Where you save a skill decides which sessions load it. These are the locations a website team will use most:

One trap: cloud sessions, including routines, don't read ~/.claude/skills/ on your machine. A routine that calls a skill stored only in your personal folder reports that the skill was not found. Commit skills that automated jobs depend on to the repository, or enable them on your claude.ai account. If two skills share a name, enterprise beats personal and personal beats project.

A skill folder can also hold supporting files, such as a longer reference document, examples or a script. Anthropic recommends keeping SKILL.md under 500 lines and pointing to the extra files from it, so Claude reads them only when needed.

Anatomy of a SKILL.md

Every skill has two parts: YAML frontmatter between --- lines that tells Claude when to use it, and Markdown instructions after it. All frontmatter fields are optional, but Anthropic recommends a description, because Claude uses it to decide when the skill applies. Here is a short example for a website project:

---
name: seo-check
description: Checks changed pages for missing or duplicate titles, meta descriptions, H1s and canonicals. Use after editing page content or templates.
allowed-tools: Read Grep
---
For each page changed on this branch: confirm one H1, a title and meta description within our length limits, and a canonical that points to itself. Report problems as a table. Do not edit files.

The frontmatter fields that matter most for website work:

• description: what the skill does and when to use it. Put the main use case first; the description and when_to_use text together are cut off at 1,536 characters in the skill listing.
• disable-model-invocation: set to true so only you can run it.
• user-invocable: set to false for background knowledge only Claude should load.
• allowed-tools: tools Claude may use without asking during the turn that invokes the skill.
• paths: file patterns that limit when Claude loads the skill automatically, such as your templates folder.
• context: fork with agent: runs the skill in a separate subagent instead of your main conversation.

Field names must match the docs exactly. Claude Code silently ignores a field it doesn't recognize, so a typo means a setting you think is on simply isn't. A ready-made SEO-check skill is in our Claude Code templates.

Who can run a skill: you, Claude, or both

By default, both you and Claude can invoke any skill. You type /skill-name, or Claude loads it when your request matches the description. Two fields change that:

Anthropic's reasoning for the first setting fits websites well: "You don't want Claude deciding to deploy because your code looks ready." If Claude tries to run a manual-only skill anyway, Claude Code blocks the call. Placement also matters: /deploy staging at the start of a message runs the skill, while "go ahead and /deploy to staging" later in a sentence only gives Claude permission to run it.

Skills can take arguments. Whatever follows the skill name replaces $ARGUMENTS in the instructions, so /publish-post winter-hours could hand the post's slug to a publishing skill. A skill can also pull live data in before Claude reads it: a line such as !`git diff HEAD` runs the command and inserts its output.

Skills that come with Claude Code

Claude Code ships with bundled skills, such as /doctor, /code-review, /batch, /debug, /loop and /claude-api. Three work together on running your site: /run launches your app, /verify builds and runs it to confirm a change works, and /run-skill-generator records how your project builds and starts as a project skill, so later sessions don't have to work it out again.

One detail is worth knowing. When a session starts with a project or personal skill named verify or simplify, Claude Code's commit instructions tell Claude to run it right before each commit, except for docs or test changes (Claude Code v2.1.286 or later). A website team can use that: a project skill named verify that builds the site and checks key pages becomes a habit before every commit. It is still an instruction to Claude, not a hard gate. For the full list of built-in commands, see the commands a website team actually uses.

Skills worth writing for website work

These are examples of skills that pay off on most business sites. Write the ones that match jobs you already repeat:

The last row comes from a rule we follow on eseospace.com, where more than 300 articles have gone through a scripted publishing pipeline and an accuracy audit applied more than 4,400 corrections across about 750 pages as scripted edits, each tested on a copy first. Writing a routine down once means nobody has to remember it under deadline. For the checks an SEO skill should run, see Claude Code for technical SEO.

Limits and safety: what a skill can't do

A skill is text Claude reads. It is not a rule Claude Code enforces. Anthropic's troubleshooting advice is direct: if Claude skipped "a rule that must hold every time", move the rule into a hook, which runs every time its event occurs. Our guide to hooks for website projects covers that. Three more limits matter:

• Long sessions: after compaction, Claude Code re-attaches only the first 5,000 tokens of each invoked skill, within a 25,000-token total. Put the most important instructions at the top, and invoke the skill again if Claude drifts.
• allowed-tools in shared repos: Claude Code applies a project skill's allowed-tools even in a folder you have never trusted. Anthropic says to review the allowed-tools of skills in a repository before running Claude Code there. Don't pre-approve push or deploy commands in a skill.
• Forked skills and rewind: a context: fork skill running in the background makes edits outside your checkpoints, so /rewind won't undo them. Use git.

Every skill in the listing also adds to your context on every turn, whether or not Claude uses it. Run /skills to list them and /skill-doctor (v2.1.252 or later) to see what each costs and how often it gets used.

Test, share and maintain skills

1. Test in a fresh session. Anthropic recommends running a few realistic prompts with the skill on and again with it off, then comparing. Leftover context from writing the skill hides gaps.
2. Check that it triggers. Ask "What skills are available?" If Claude doesn't use it when expected, add the words people actually say to the description.
3. Review it like code. Commit project skills to .claude/skills/ and change them through pull requests, so a person approves what every future session will follow.
4. Share wider when needed. Package skills with hooks and subagents as a plugin, covered in plugins and marketplaces, or deploy them through managed settings.

A skill can also preload into a subagent, which is useful when a review job needs your checklist in a separate context. See subagents explained. Anthropic's skills documentation has the full field reference.

Conclusion

Skills turn the procedures your team repeats into files that every session can follow: write them small, describe them clearly, keep anything that publishes or deploys manual, and put must-never-happen rules in hooks instead. Start with one check and one publishing routine, commit them, and refine them when Claude gets something wrong. If you want help designing skills, hooks and permissions for your site and team, that is part of our Claude Code consulting. More guides are in our Claude Code Guide.

Frequently asked questions