How to build Claude Code skills for product managers

When is a prompt ready to become a skill?

On the third time you write it. Builders Camp's Building your AI Operating System bootcamp teaches this as the third-use rule: write the prompt the first time, notice the repetition the second time, convert it into a reusable skill on the third. The first two runs are where you find out what the prompt actually needs. The third is where you stop paying for that discovery again.

Most product work qualifies faster than people expect. A weekly experiment readout, a competitor pricing page diff, a support-ticket theme count: the content changes every week, the shape never does.

For the concept itself, the glossary entry on agent skills covers the definition and where it sits next to memory and context. This page builds one.

What is actually inside a skill?

A skill is a directory with a SKILL.md file in it. Claude Code reads ~/.claude/skills/<name>/SKILL.md for skills you want everywhere, and .claude/skills/<name>/SKILL.md for skills that belong to one repository and travel with it through version control. The directory name becomes the command, so a folder called experiment-readout gives you /experiment-readout.

The file is YAML front matter followed by plain markdown. Four fields carry most of the weight for product work:

---
name: experiment-readout
description: Write the decision readout for a finished A/B test. Use when an experiment has stopped and someone needs a ship or kill call, not a summary.
arguments: [experiment, primary_metric]
allowed-tools: Read Grep
---

description is the one people get wrong. Claude reads it to decide whether to run the skill on its own, so it has to describe a trigger condition, not a title. Anthropic's documentation truncates the description at 1,536 characters combined with the optional when_to_use field, which is far more room than a good trigger needs. allowed-tools pre-approves tools for the skill's turn only, and the grant clears when you send your next message.

What does a product skill look like end to end?

Here is the body of that readout skill, which is where the real work sits.

## Required inputs
Stop and ask if any of these are missing. Do not guess.
- The experiment name and the dates it ran
- The primary metric that was pre-registered before launch
- The observed effect and whether the test reached its planned sample

## Steps
1. State the decision first: ship, kill, or extend. One line.
2. Give the primary metric result with the interval, not the point estimate alone.
3. Name one guardrail metric that moved and one that did not.
4. Name what this test does not tell us.
5. List the next decision this readout unblocks, and who owns it.

## Output
Five short sections in the order above. No more than 250 words.
Every number appears once, with its source.

Three things are doing work there. The decision leads, so the readout cannot hide behind a narrative. The required-inputs block gives the skill something to refuse on. The word cap forces the analysis into a shape a stakeholder will actually read, which is the same constraint Builders Camp's own AI operating system material puts on every automation: a hard limit, or the output grows until people stop reading it.

If the skill needs a longer reference, such as how to read a confidence interval or which metrics your company treats as guardrails, put that in a separate file next to SKILL.md and link to it from the instructions. Anthropic recommends keeping SKILL.md under 500 lines for exactly this reason: the linked file stays out of context until the moment it is needed.

How does the skill get used in an actual week?

You type /experiment-readout checkout-banner conversion_rate and the skill loads with those two values substituted into its instructions. Claude Code also loads it on its own when your message matches the description, which is why the trigger wording earns its place: "use when an experiment has stopped and someone needs a ship or kill call" fires on "the banner test finished, what do we do," while "experiment analysis helper" fires on nothing.

Once loaded, the skill content stays in the conversation across turns rather than evaporating after one exchange, and it re-attaches after the session compacts, so a long Thursday of follow-up questions still runs against the same standard you wrote in March. You can also stack skills, up to six at once, which is how a readout skill and a stakeholder-summary skill end up running back to back on the same numbers without you restating either one.

Why should a skill be allowed to refuse?

Because the failure mode of a useful skill is not a bad answer, it is a plausible one. Builders Camp's Building your AI Operating System certification material makes this the dividing line between a skill and a shortcut: a good skill validates the inputs it requires, a target user and supporting evidence for example, and refuses to run without them. Refusal is the feature.

Run the readout skill on an experiment that never had a pre-registered primary metric and it should stop, not pick the metric that moved most. That is the single highest-value line in the whole file, and it is one sentence. The version without it still produces five tidy sections, a confident decision and a number, which is precisely why nobody catches it: the output looks identical to the output of a test that was actually designed.

Write the refusal as a list of named inputs rather than a general instruction to be careful. "Ask for anything unclear" gets interpreted away under pressure. "Stop if no pre-registered primary metric is recorded" does not.

What quietly makes a skill worse?

• A description written as a label ("Experiment analysis helper") rather than a trigger, so Claude never selects it without being told to.
• A SKILL.md that has crept past 500 lines because every edge case was pasted inline instead of moved into a supporting file.
• One skill doing two jobs, such as drafting the readout and deciding whether to ship, so a bad output gives you no way to tell which half failed.

The second one is the sneakiest, because a growing file feels like progress. Every exception you paste in costs context on every run, and the instructions that matter most get diluted by the ones that apply once a quarter. The fix is boring and works: keep the steps in SKILL.md, move the "how we treat a metric that only moved for logged-out users" paragraph into a neighbouring file, and reference it by name.

When is a skill the wrong tool?

A skill is instructions, and instructions are followed, not enforced. If the requirement is "this must happen every single time," a skill is the wrong mechanism and a hook is the right one, because a hook is a shell command Claude Code runs at a fixed point regardless of what the model decides. The glossary entry on automation hooks draws that line in full.

Two other cases. If the job floods your session with file reads you will never look at again, you want a subagent with its own context window, not a skill in your main one. And if the rule is true in every session about this project, such as where the specs live or who signs off on pricing copy, it belongs in CLAUDE.md rather than in a skill nobody remembers to invoke.

The honest limitation is that a skill only compounds if someone maintains it. A file written once in March and never revisited encodes March's understanding of the job, and it will keep producing March's answer with total confidence.

The skill is the onboarding document you never wrote

The second use for a good skill has nothing to do with speed. Hand experiment-readout/SKILL.md to a product manager joining the team and they learn, in about ninety seconds, what your company thinks a readout owes its reader: a decision first, an interval rather than a point estimate, a named limit, a named owner. That is the training document you kept meaning to write, and it stays current because it is the thing you actually run.

Builders Camp teaches this layer directly. Building with Claude Code, taught by Guilherme Salgueiro, runs one week with 2 live sessions and 9 self-paced microlessons, and covers skills, agents and memory as a single module alongside context architecture and automation pipelines. Claude Code for Product Managers is the lighter entry point for PMs who want the workflow before the systems, and both sit inside the AI Agentic Builders Expert Track for anyone building the full operating layer rather than one file.

See the Building with Claude Code bootcamp for the curriculum, or start from Claude Code for Product Managers if this is your first week in an agentic environment.