Claude Skills: The Automation Feature Nobody Talks About

Prompting is labor. Skills are capital. That distinction is the entire reason Claude Skills matter, and it is strange to me how little coverage they get compared to shinier features. A prompt is effort you spend again every single time; a skill is a procedure you write once, version, share, and invoke forever. I currently maintain 53 skills on my agent skills marketplace and run about 35 of them in my own ~/.claude/skills directory daily, so what follows is not a feature-announcement summary. It is what shipping that many of them teaches you.

What a Skill Literally Is

Strip away the branding and a Claude skill is a folder containing a SKILL.md file:

---
name: seo-audit
description: Run a full technical SEO audit of a site: crawlability,
  schema, sitemaps, hreflang. Use when the user asks for an SEO audit,
  indexation investigation, or search visibility review.
---

Instructions:
1. Collect the site's routes, templates, and any GSC exports provided.
2. Run each sub-check and rank findings by indexation impact.
3. Output findings with the file and line that causes each issue.
...

Two parts: frontmatter that tells Claude when the skill applies, and a body that tells it how to do the job. Skills live in ~/.claude/skills (available everywhere) or a project's .claude directory (versioned with the repo). You invoke one explicitly with /seo-audit, or Claude loads it automatically when your request matches its description.

That is the whole mechanism. The consequences are bigger than the mechanism suggests.

The Part Nobody Talks About: The Description Is the API

Here is the lesson that took me the longest to learn, and I learned it by shipping skills that did not fire. Claude decides whether to load a skill by reading its description, not its body. The body can be a masterpiece of process documentation; if the description does not match how users actually phrase the task, the skill sits there unused, and the model improvises instead.

Almost every "my skill doesn't trigger" complaint I have received about marketplace skills traces back to this. The description was written like a summary ("Handles SEO tasks") instead of like a routing rule ("Use when the user asks for an SEO audit, indexation investigation, or search visibility review").

This is also why my SEO tooling is thirteen narrow skills (seo-audit, seo-schema, seo-hreflang, seo-sitemap, and so on) rather than one mega-skill. Narrow descriptions route correctly. A skill that claims to do everything matches everything weakly and nothing well. When I split my original monolithic SEO skill into the family, misfires largely disappeared. Treat the description field the way you would treat a function signature in a public API, because that is what it is.

Skills vs Prompts vs MCP

The three get confused constantly, and the confusion causes people to build the wrong thing:

The test I use: if I have typed substantially the same instructions three times, that is a skill now. If the task needs live data from an external system, that is MCP. If it is truly novel, it stays a prompt. Most people over-invest in the first column and never discover the second.

Real Skills From My Own Stack

Concrete beats abstract, so here is a sample of what runs on my machine and what each automates:

• skill-creator — the meta-skill: it interviews me about a workflow and drafts the SKILL.md. Most of my newer skills started here; I wrote up what building dozens of them taught me in lessons from building Claude Code skills.
• handoff — writes a structured continuation document at the end of a session so the next session starts with full context instead of archaeology. Multi-day work stopped degrading when this became automatic.
• caveman — a token-diet skill that compresses verbose context. Unglamorous, directly measurable savings.
• tdd — enforces test-first on features. Not because I lack discipline, but because encoded discipline survives deadlines and moods.
• the seo family — thirteen auditors that found the cause of my own site's deindexing crash, a story I told in full in my Claude Code SEO audit.

Notice what these have in common: none of them are "chat better." Every one encodes a procedure I used to perform manually, with my standards baked in.

Writing Your First Skill (Do This Today)

1. Pick a task you performed at least three times this month. Not your hardest task; your most repeated one.
2. Do it manually once more, narrating. Write down every step, including the checks you do implicitly ("verify the file exists before editing"). The implicit checks are the valuable part.
3. Create ~/.claude/skills/your-skill/SKILL.md with a routing-rule description and your steps as the body.
4. Run it on a real case immediately. The first run always reveals a step you forgot you do.
5. Edit the file, not your prompts. From now on, every improvement is permanent. This is the compounding step, and it is the entire reason skills beat prompting.

For a broader map of the ecosystem around this, my complete guide to Claude Skills covers formats and capabilities in more depth.

When a Skill Is the Wrong Tool

Honesty section. Skills are wrong for: genuinely one-off work (writing the skill costs more than the task), anything requiring live external state (that is MCP's job), and processes you have not stabilized yet. A skill is frozen judgment; freezing judgment you have not formed yet just automates your confusion. Stabilize the workflow manually first, then encode it. And once you have a stack of skills that work, they become surprisingly packageable, which is a commercial story of its own that I told in Claude Code skills businesses pay for, and an architectural one in my three-layer agentic OS.

Install one of my 53 production skills from the agent skills marketplace — SEO auditors, design critics, workflow glue — and read its frontmatter before you read its body. The description is what decides whether your own version ever fires, and copying a routing rule that already works beats guessing at one.