Claude Skills: The Complete Guide for Product Managers

The first time I read a Claude Skills folder out loud to a product manager, her reaction was: "wait, that's it? It's just a markdown file that tells Claude how to do the thing right, every time?" Yes. That is the entire mechanism, and it is also why Claude Skills has quietly become the most useful primitive in the Claude Code ecosystem for non-engineers.

If you've used Claude Code for more than a week, you've probably typed the same detailed prompt three or four times: "write a PRD, but make sure it has a problem section, evidence, non-goals, and success metrics, and don't let me skip the evidence part." Every time, you re-explain the rules from scratch. Claude Skills exist so you never have to do that again. You write the rules once, in a file called SKILL.md, and Claude picks it up automatically whenever the task matches.

This guide covers the mechanism end to end: what a skill actually is, how it differs from an agent or a custom command, the exact anatomy of a SKILL.md file, how Claude decides which skill to load, and a step-by-step walkthrough of writing your first one. Then we build three complete, copy-paste skills for the work PMs actually do every week: writing a one-page PRD, analyzing a funnel in Amplitude, and running a competitor teardown.

What Claude Skills Actually Are (and What They Are Not)

A Claude Skill is a folder containing a SKILL.md file (plus, optionally, supporting scripts, templates, or reference documents) that teaches Claude how to perform a specific, repeatable task the way you want it done. It is not a new AI model, and it is not a plugin in the traditional sense. It is closer to an onboarding document you'd hand a new hire: here is the task, here is the format we use, here are the mistakes to avoid.

The confusion usually comes from how similar skills sound to agents and custom commands, so it's worth being precise about the three:

• Skills are procedural knowledge. A skill tells Claude how to do one kind of task well, and Claude loads it automatically when your request matches its description. You never type a command name.
• Subagents are delegated workers. A subagent is a separate Claude instance with its own context window and its own restricted tool access, invoked to do one job and hand back a result, usually as part of a bigger flow.
• Custom commands are saved prompts you trigger explicitly by typing /command-name. You decide when they run.

The practical difference: skills are invoked implicitly (Claude decides), commands are invoked explicitly (you decide), and subagents are invoked by something else (the main agent or a command, as a delegation step). A well-built system usually uses all three together, which is exactly what our series on mastering Claude Code walks through step by step, and it's also the last section of this guide.

According to Anthropic's own engineering writeup on Agent Skills, the format was built precisely to solve the "re-explain everything every time" problem at scale, and Anthropic published Agent Skills as an open standard at agentskills.io in December 2025, meaning a skill you write for Claude can, in principle, work across other agent systems that adopt the same standard too. That's a strong signal this isn't a throwaway feature: it's becoming the default way agentic tools package expertise. As Anthropic's own engineering team put it when they introduced the format, "Claude is powerful, but real work requires procedural knowledge and organizational context." That's precisely the gap a SKILL.md file closes.

The adoption data backs that up from the other direction. In Anthropic's 2026 Agentic Coding Trends Report, 71% of developers who regularly use AI agents name Claude Code as their primary tool, the highest share of any agentic coding product. Skills are one of the main reasons that loyalty compounds: once your team has a shared library of skills, switching tools means rebuilding all of that institutional knowledge from zero.

The Anatomy of a SKILL.md File

Every skill is a single markdown file with two parts: YAML frontmatter, and an instructions body.

---
name: prd-writer
description: Writes a one-page PRD from a raw problem statement or feature
  request, following our opinionated template. Use whenever the user asks
  to write, draft, or structure a PRD, product spec, or feature brief.
---

[the instructions body goes here]

The frontmatter has two required fields, and one of them is doing more work than people realize. name is just an identifier. description is the trigger. Claude scans every skill's description (not its full body) to decide whether a skill is relevant to what you just asked. If your description is vague ("helps with product work"), Claude won't reliably match it to the right request. If it's specific and includes the phrases a PM would actually type ("write a PRD," "draft a spec," "structure a feature brief"), Claude matches it correctly almost every time.

This is the single most common mistake in skills people write badly: treating the description as a summary instead of as a search index. Write it the way you'd write a job posting title, specific enough that the right request finds it and the wrong ones don't.

The instructions body is where the actual behavior lives. This is plain markdown, and Claude reads it in full once the skill is triggered. Good instruction bodies include:

• The exact structure or template to follow
• Explicit rules about what to refuse or push back on (this is where a skill becomes opinionated instead of generic)
• Step-by-step process, if order matters
• Edge cases and what to do about them

Skills can also bundle supporting files (a reference template, a scoring rubric, a script Claude should run) in the same folder. The SKILL.md stays the entry point; anything else in the folder is available to Claude as context or as a tool to execute, but only gets pulled in when the instructions body actually references it.

Where Skills Live and How Claude Decides to Invoke One

Skills live in one of two places: ~/.claude/skills/ for skills you want available across every project, or .claude/skills/ inside a specific repo for skills scoped to that project. Each skill gets its own subfolder, named after the skill, containing at minimum a SKILL.md.

At the start of a session, Claude Code loads the name and description of every available skill, not the full instructions. This keeps the baseline context window small even if you have dozens of skills installed. When you send a message, Claude compares your request against every skill's description and decides whether one (or more) apply. If a match is strong enough, Claude loads that skill's full instructions body into its working context before responding, and follows it for that task.

This is why the description field matters so much: it is the only thing Claude sees before deciding whether to read the rest. A skill with a sharp, request-shaped description gets triggered reliably. A skill with a mushy one gets ignored even when it would have been the right tool for the job.

Since a January 2026 release, skills also hot-reload: if you edit a SKILL.md while a session is running, the change takes effect immediately, no restart required. That makes iterating on a skill's wording (tightening the description, adding an edge case you just hit) close to instant.

Skills persist across every new session the same way Claude Code Memory does, the difference is that a skill encodes a repeatable procedure rather than passive context about your product or team.

How to Write Your First Skill, Step by Step

1. Pick one recurring task you keep re-explaining. Good candidates: a document format you always want followed, a data source you always check the same way, a review you always run from the same angle. Bad candidates: anything that changes shape every time you do it.
2. Write the description first, not last. Draft three or four phrases a person would actually type when they want this task done, and fold them into the description. This is the step people skip, and it's the one that determines whether the skill ever gets used.
3. Write the instructions body as if training a sharp new hire. Include the template or structure, the specific rules ("never write a solution before X is confirmed"), and what "good" looks like versus what to reject.
4. Save it as .claude/skills/your-skill-name/SKILL.md (project-scoped) or under ~/.claude/skills/ (global).
5. Test it with a request that should trigger it, and one that shouldn't. If Claude doesn't pick it up on the request that should trigger it, tighten the description. If it fires on a request that shouldn't trigger it, narrow the description instead of broadening the instructions.
6. Iterate on real use, not in the abstract. The first version of a skill is never right. Use it for a week, note where Claude followed the letter of the instructions but missed the intent, and rewrite that part.

Three Worked Examples You Can Copy

These are complete, working SKILL.md files for the three tasks that eat the most PM hours: writing a PRD, reading a funnel, and tearing down a competitor. Copy any of them into .claude/skills/, adjust the specifics to your product, and they'll work immediately.

Example 1: prd-writer

This skill enforces an opinionated one-page PRD template and, critically, refuses to jump to solutions before the problem is actually validated. It interviews you first, the way a good engineering manager would before agreeing to scope work.

---
name: prd-writer
description: Writes a one-page PRD from a raw problem statement, feature
  idea, or stakeholder request. Use when the user asks to write, draft,
  outline, or structure a PRD, product requirements doc, or feature spec.
---

You write one-page PRDs using this exact template, no more, no fewer
sections:

1. Problem (2-3 sentences, framed as a user or business problem, never
   as a solution)
2. Evidence (what data, user feedback, or observed behavior justifies
   solving this now)
3. Non-goals (explicitly what this PRD does NOT cover, to prevent scope
   creep)
4. Success metrics (the 1-2 metrics that will tell us this worked,
   with a target number if one exists)
5. Open questions (anything still unresolved that a reviewer should
   flag)

Before writing anything, ask the user these five questions, one at a
time, the way a sharp engineering manager would before agreeing to
scope work:

1. Who exactly has this problem, and how do you know?
2. What happens today, without this feature? What's the workaround?
3. What evidence do you have that this is worth solving now, versus
   next quarter?
4. How will we know, in numbers, that this worked?
5. What are you explicitly choosing NOT to solve with this first
   version?

If the user's answers are vague or unsupported ("I think users want
this," with no evidence), say so directly and ask for something more
concrete before proceeding. Do not write the PRD until the problem
and evidence sections are solid. If the user tries to jump straight to
a solution or feature spec before the problem is validated, redirect
them back to the problem first. A clear no-solution PRD is more useful
than a detailed one built on an unvalidated problem.

Once the problem and evidence hold up, write the full one-page PRD in
the template above, in clean markdown, ready to paste into a doc.

Example 2: funnel-analyst

This skill points Claude at Amplitude (or any product analytics tool exposed via MCP), makes sure it asks for the right segmentation before running any query, and forces every analysis to end with one concrete recommendation instead of a wall of numbers.

---
name: funnel-analyst
description: Analyzes a product funnel or conversion flow using Amplitude
  data. Use when the user asks to check drop-off, conversion rates, or
  funnel performance, or wants to know why a metric moved.
---

You analyze funnels using the Amplitude MCP connection. Follow this
process every time:

1. Confirm the funnel steps with the user before querying anything
   (e.g., "Signup Started -> Email Verified -> Onboarding Completed ->
   First Feature Used"). Never assume the steps; ask if unclear.
2. Pick the right chart type for the question:
   - Use a Funnel chart for step-by-step conversion and drop-off.
   - Use a Segmentation chart when the question is about a trend over
     time, not a conversion rate.
   - Use Retention only when the question is explicitly about
     returning usage, not first-time conversion.
3. Always segment the result by at least one dimension that could
   explain the number: acquisition source, plan tier, platform
   (mobile vs. desktop), or user cohort (new vs. existing). A single
   blended conversion rate hides more than it reveals.
4. Compare against the prior period (week-over-week or month-over-
   month) so the number has context. A 40% conversion rate means
   nothing on its own.
5. Never end with just a table of numbers. Every analysis must close
   with a single "Highest-ROI action" recommendation: the one change,
   backed by the biggest drop-off step and the clearest segment
   difference, that would move this funnel the most if fixed first.
   If the data doesn't clearly point to one action, say so honestly
   rather than manufacturing a false recommendation.

Keep the write-up short: the funnel result, the segment that explains
it, and the one recommended action. No restating the request, no
generic filler about "the importance of conversion optimization."

Example 3: competitor-teardown

This skill produces a full competitive teardown, positioning map, feature-gap table, pricing comparison, and screenshots, using browser automation to actually visit the competitor's site rather than guessing from memory.

---
name: competitor-teardown
description: Produces a full competitive teardown of a named competitor,
  including positioning, feature gaps, pricing, and screenshots. Use
  when the user asks to research, analyze, or tear down a competitor
  or alternative product.
---

You produce a structured competitor teardown for the named competitor.
Use browser automation to visit their live site, pricing page, and
changelog directly rather than relying on memory, since pricing and
feature sets change often.

Produce these four sections in order:

1. **Positioning map.** A short 2x2 description (state the two axes
   explicitly, chosen to fit the category, e.g., "ease of use" vs.
   "depth of customization") placing the competitor and our product
   on it, with one sentence justifying each placement.
2. **Feature-gap table.** A markdown table with rows for the 8-12
   features that matter most in this category, and columns for
   "Us" and "Them," marked as Yes / No / Partial. Flag any feature
   they have that we don't as a gap worth discussing.
3. **Pricing comparison.** Pull their actual current pricing tiers
   from their live pricing page (not cached knowledge), and lay it
   side-by-side with ours at equivalent tiers. Note any pricing
   model difference (seat-based vs. usage-based vs. flat) since that
   often matters more than the raw number.
4. **Screenshots.** Capture their homepage, pricing page, and one
   core product screen (signup flow or main dashboard, whichever is
   reachable without an account) using browser automation, and embed
   them in the output with a one-line caption each.

Close with a 3-bullet summary: their clearest strength, their
clearest weakness, and the one competitive move we should consider
in response. Do not pad the teardown with generic industry
commentary; every line should be about this specific competitor.

Between the three, you can already see the shape a good skill takes: a sharp, request-matching description, an explicit structure, and at least one rule that stops Claude from taking the lazy path (jumping to solutions, blending segments, guessing at pricing instead of checking). If you want the full set, plus a few more covering discovery synthesis and stakeholder updates, the Product Builder Kit repository has the whole library ready to copy into your own .claude/skills/ folder.

How Skills Compose With Subagents and Custom Commands

The real leverage shows up once you stop thinking of skills, subagents, and commands as competing options and start treating them as layers. A skill is the "how" for one kind of task. A subagent is a delegated worker that might use one or more skills while it works. A custom command is the trigger that kicks off a bigger flow, calling several subagents (each possibly using its own skills) and stitching the results together.

Take the funnel-analyst skill above. On its own, it makes any funnel question you ask better. But wrap it inside a subagent dedicated to weekly analytics review, and pair that with a custom command that also calls a feedback-synthesis subagent and a competitor-watch subagent in parallel, and you've gone from "a skill that helps me analyze funnels" to "a Monday morning report that assembles itself." That is the same idea behind building an agent stack that replaces hand-offs to growth, data, and eng: the skill didn't change. What changed is that it's now one ingredient in a bigger, automated system instead of something you invoke by hand every time.

That's the actual promise of Claude Skills for product managers: not a smarter chatbot, but a growing library of "how we do this here" that Claude applies automatically, consistently, and that composes into bigger systems the moment you're ready to build them.

The Takeaway

Claude Skills are the least hyped, most useful primitive in the Claude Code ecosystem right now, precisely because they're boring in the right way: a markdown file, a sharp description, a clear set of rules. Write one for the task you re-explain most often this week (a PRD template, a funnel review, a competitor check), test it against a request that should trigger it, and tighten the description until it fires reliably. That's the whole learning curve. Everything after that is just writing down, once, what "good" looks like for the work you already do.

If you haven't opened a terminal before, skills are also the fastest way to get real value out of Claude Code without touching a line of code yourself, which is exactly the ground our first-week guide for non-technical PMs covers.