Claude Code Skills, what actually matters and what's just noise

There's a lot of junk commentary floating around Claude Code Skills right now. Marketplaces hawking 1.2 million skills. Tutorials that explain the YAML syntax without ever telling you which Skills are worth installing. Twitter threads where every folder gets called a productivity revolution. We run Claude Code every day at Market Correct. We've built our own Skills, installed plenty more, and deleted most of them. This post is the working version of what we wish someone had handed us when we started.

What Claude Code Skills actually are. How to use them. The ones that earn their place in a daily stack. The ones that don't. Where to find good ones. And how we build our own when nothing off the shelf fits.

Spoiler. The right number of Skills is smaller than you think.

What Claude Code Skills actually are

A Claude Code Skill is a folder with a SKILL.md file in it. The Markdown describes a procedure. Optionally, there are reference files (more Markdown), scripts (Python or shell), and templates the procedure can pull in. Claude reads the SKILL.md when a request matches the skill's trigger conditions and executes whatever the file tells it to do.

That's it. There's no compiled binary, no proprietary format, no platform lock-in. A Skill is a folder. The folder lives in ~/.claude/skills/ for global use or in a project's .claude/skills/ for project-specific use. Claude Code finds them on its own.

The reason this matters is the indirection. Without Skills, every workflow lives in your head. You open Claude Code, you remember to tell it the rules, you remember the steps, you remember the constraints. With a Skill, those rules live in a file you wrote once. The next time you say "humanize this draft," Claude reads the SKILL.md, applies the rules, and produces output that matches your standards without you re-explaining them. The file is the procedure. The procedure is the asset.

The official docs sit at code.claude.com/docs/en/skills. The official Anthropic Skills repo is on GitHub at github.com/anthropics/skills. Both are worth reading once before you go shopping.

How to use Skills in Claude Code

The mental model is simple. Skills can be triggered three ways.

1. Automatically. Claude detects that a request matches a Skill's description and reaches for it on its own. This is the path you'll use most.
2. Manually. You type the Skill's name into the chat. "Use the em-dash-bouncer skill on this file." Useful when you want to force a specific Skill instead of waiting for the trigger to fire.
3. Programmatically. One Skill loads another as part of its procedure. This is how composite Skills work, and it's where the lift is biggest.

To install a Skill, drop the folder into ~/.claude/skills/your-skill-name/ and make sure there's a SKILL.md inside. Claude Code picks it up on the next session start. To verify it's loaded, run /skills in Claude Code or look at the system reminder that lists available skills. No restart, no install command, no package manager needed.

Triggering one is the same flow. If your Skill's description says "use when reviewing files for em dashes," Claude will reach for it any time you ask to clean up punctuation. You don't have to remember the Skill exists. That's the part that wins. The Skills that don't trigger reliably are almost always the ones with vague or overlapping descriptions, and the fix is to tighten the description, not to add more Skills.

The Skills we use every day

Here's the actual roster, not the aspirational one. About 30 Skills installed across the agency. Twelve we touch every day. The rest sit there for the once a month case.

Custom Skills we built

Off-the-shelf Skills we keep installed

Not every Skill we run is custom. The ones we kept off the shelf are the ones that filled a real gap and produced output we acted on. The list is shorter than people expect.

• ai-seo, seo-geo, seo-audit. Three SEO Skills we reach for during keyword research and audits. We've trimmed them down. The ones we kept are the ones that produced findings we acted on.
• brand-identity. For new client brand work and guideline drafting. A solid frame for conversations that would otherwise sprawl.
• social-media-designer. For LinkedIn carousels and stat cards. Strong opinions on what works on each platform built into the file.
• typeset. For typography passes when something feels off but we can't articulate why. Picks up the issues we'd miss.
• ui-ux-pro-max. For design conversations where we need a structured frame instead of vibes. Big enough that we don't load it on every task, small enough to pull when the work calls for it.
• legal-advisor. Once a quarter for contract reviews and privacy policy updates. Doesn't replace counsel. Does flag the obvious gaps before counsel sees the draft.

Skills we installed and deleted

The marketplace is full of "agent" Skills that are mostly persona prompts. "Act like a senior developer." "Behave like a product manager." Most of them don't do anything a one-line system prompt couldn't do. We deleted those. Skills that wrap other tools (CLI commands, formatters, linters) without adding judgment, we kept the actual tools and deleted the wrappers. Skills that were 80% repeating standard advice we'd already absorbed, gone. They aren't useful and they crowd the description list, which makes Claude worse at picking the right Skill when it matters.

The principle is harsh but fair. A Skill that doesn't change what you'd do is fluff. A Skill that captures a procedure too complex to keep in your head every time is gold.

Skills with other Skills baked in

The richest pattern in this stack is composition. The market-correct skill loads reference files (brand-context.md, design-system.md, blog-redesign-runbook.md). When a task fits one of those, the parent Skill points to it. That's the basic version. The richer version is one Skill loading another Skill loading another Skill.

Our blog production runs as a chain. market-correct-blog kicks off, loads market-correct for brand context, loads new-humanizer for voice, loads em-dash-bouncer for punctuation, then loads mrktcorrect-blog-finisher for the quality gate. One Skill kicks off five. The blog post that takes 90 minutes manually takes 15 with the pipeline running, and the output is more consistent than anything we'd produce by hand.

The trick is keeping the parent Skill's SKILL.md short. Long parents drown the index and confuse the trigger logic. The version we run says, in essence, "for blog posts, load these other Skills in this order, and follow their instructions." Most of the actual content lives in the leaf Skills. The parent is glue.

That's the difference between a useful composite Skill and a bloated one. The bloated version tries to do everything itself and overlaps with leaf Skills. The useful version is a manifest, not a manual. If you're considering building a parent Skill that has more than 100 lines of instructions, stop and ask whether half the content belongs in a child Skill it loads instead.

What's needed and what's fluff

Three filters before installing any Skill.

1. Does it encode a procedure I'd otherwise type by hand every time? If yes, install. If no, don't. The Skills that earn their place are the ones that capture work you keep redoing.
2. Is the SKILL.md short enough to scan in a minute? If yes, the author respects your context window. If no, it's bloat dressed up as completeness.
3. Does it produce a different output than I'd produce without it? If yes, the rules in the file are doing real work. If no, you have a placebo.

The fluffiest Skills wrap a one-line prompt around an existing capability and call it a "framework." The best Skills do something specific and stop. em-dash-bouncer is one regex and a fail condition. That's why it's the Skill I trust most. market-correct-blog is glue plus five well-tested children. That's why it ships our content.

Avoid Skill packs that bundle 50 capabilities without any selection. Find the three that matter. Keep them. Delete the rest. The cost of a bloated Skill folder isn't disk space. It's the noise it adds to Claude's decision about which Skill to reach for, and the noise gets worse with every Skill you add.

Where to find good Claude Code Skills

The marketplace situation has matured fast in 2026. A few places worth bookmarking.

• SkillsMP has the broadest catalog. Claims roughly 1.2 million agent skills, though most are duplicates and template prompts. Strong filtering by occupation, author, and popularity. Worth a browse, with the caveat that you should read every SKILL.md before you install it.
• github.com/anthropics/skills is the official Anthropic repo. Smaller catalog, higher signal. The skill-creator and skill-creator-update Skills here are useful starting points if you want to build your own.
• Claude Marketplaces is a directory of directories. Catalogs Skills, MCP servers, and plugins so you can compare what's out there without bouncing between five different sites.
• Claude Skills Market at skills.pawgrammer.com hosts a community-curated collection of around 280 Skills focused on practical workflows. Less commercial than SkillsMP, more opinionated about what's worth shipping.
• LobeHub aggregates Skills, agents, and prompts together, which is useful if you want one search across the whole agent ecosystem instead of just Skills.
• github.com/daymade/claude-code-skills and github.com/mhattingpete/claude-skills-marketplace are two solo-maintained Skill repos that lean toward software engineering workflows. Higher signal than most of the marketplace listings because they're curated by humans who use the Skills themselves.

The same caution applies everywhere. Treat marketplace Skills like any other code you install. Read the SKILL.md before you drop it in. Check what scripts it includes, what files it touches, what external services it calls. The marketplaces filter for low-quality repos but they don't audit for malicious code, and a Skill can run shell commands and read files just like any process you start on your machine. The good news, Skills are plain text. Five minutes of reading tells you what one does.

How we build our own Skills

When nothing off the shelf fits, we build. The process is short.

1. Identify a procedure we run more than once. If we run it weekly and it has steps, it's a Skill candidate. If we run it daily and we keep forgetting steps, it's a Skill priority.
2. Write the SKILL.md by hand on the first try. Plain Markdown, with a name, a description, and the steps. Don't optimize. Make it work end to end before you make it pretty.
3. Use it for two weeks. Note where it failed, where we had to override it, where it produced output we re-edited. Those are the fix points.
4. Iterate the SKILL.md to handle the failures. Move generic content into reference files the Skill loads on demand, so the SKILL.md stays scannable.
5. Once the Skill is producing output we ship without edits, lock it down. Move on to the next procedure. A Skill that's "good enough" today is more valuable than one you keep tinkering with for another month.

The failure mode is over-engineering early. Don't write a 400-line SKILL.md on day one. Write 40 lines, run them, and let the real failures tell you what to add. Half the Skills we keep started as ten-line files that we extended over the first two weeks of use. A few stayed at ten lines because that was enough.

The other failure mode is description drift. The trigger conditions in the description field decide whether Claude reaches for the Skill on the right tasks. Vague descriptions get ignored. Overlapping descriptions get pulled in for tasks they shouldn't run on. Tighten the language. Include the words a user would actually say. Drop the marketing copy and write what the Skill is for in one sentence.

Pairing Skills with MCP and the Pocket workflow

The reason Skills matter as part of a working stack, not just a productivity novelty, is what they let you compose. Skills handle procedures. MCP servers handle data and external system access. Claude Code orchestrates both. A Skill says "when the user asks about a meeting, look up the transcript." An MCP server is what actually fetches the transcript. Different jobs, complementary tools, and the combined output is where the value compounds.

Pocket is the AI voice recorder we run for off-laptop meetings. It captures audio, writes summaries, and ships an MCP server that lets Claude Code read across the captures without opening Pocket's app. Pocket also lets you pick the AI model that writes the summaries, and we run ours on Claude Opus 4.7. So when we ask Claude Code "what did the client say about budget on the Tuesday call?" the question routes through our Skill stack (which knows our voice and our client context) and pulls answers from the Pocket MCP server (which has the actual transcripts). Skills give Claude the procedure. MCP gives Claude the data. The combined output is what makes the workflow stick.

If you're already running Claude Code and you want the off-laptop capture half of the same workflow, Pocket is where to start. We've broken the head-to-head with Plaud down separately in our Pocket vs Plaud post, and the longer story of how Pocket fits into our day in our Granola and Pocket review. Most of the other AI recorders don't expose an MCP server, which is the bottleneck for any Skill-driven retrieval. It's the same reason we run Granola for desktop calls instead of the alternatives. The MCP server is the part that lets the rest of the stack reach the data.

The bottom line