The 8 Claude Skills every product manager should build this week
Stop re-explaining yourself to Claude. Build these 8 PM Skills instead.
If you’ve been using Claude to write PRDs, prep for stakeholder conversations or synthesise user research, you’ve probably noticed a problem: you re-explain yourself every single session. Who you are, what your product does, how your team works, what format you want. Every time.
Claude Skills fixes that.
A Skill is a small folder of instructions you build once and upload to Claude. After that, Claude loads it automatically whenever you’re doing the kind of work it covers. No re-prompting. No re-explaining. You describe what you need, Claude recognises the task, loads the right instructions, and runs your workflow.
For product managers specifically, this changes things considerably. The prompts you’d normally type from scratch become repeatable systems. Your PRD template, your stakeholder prep process, your research synthesis format - all of it lives in Claude and fires when you need it.
This article covers 8 Skills worth building if you’re a PM. Each one comes with a real scenario, the prompt logic behind it, and a look at what the actual Skill file contains so you can build it yourself.
How to build a Skill (the short version)
A Skill is a folder with one required file: skill.md. That file has two parts - a short header block that tells Claude when to load the Skill, and the body that tells Claude what to do once it loads.
The header looks like this:
---
name: your-skill-name
description: What it does and when to use it. Use when user asks to [specific phrases].
---The description is the most important thing you’ll write. Claude reads it to decide whether your Skill is relevant to what you’re asking. Vague descriptions mean the Skill either never loads or loads at the wrong time. Specific ones - including the phrases you’d actually type - work reliably.
Once your folder is ready, zip it and go to Settings > Capabilities > Skills > Upload [‘Skills’ now moved to ‘Customise’] in Claude.ai. Code execution needs to be on for Skills to work. You’ll find that toggle in the same Capabilities section.
Now, the 8 Skills.
Skill #1: Discovery notes to requirements
What it does: Takes raw, messy stakeholder notes and turns them into a structured requirements document with contradictions flagged rather than silently resolved.
When it loads: When you paste in discovery notes, meeting transcripts or anything that looks like unstructured input and ask Claude to turn it into requirements.
The scenario:
Sarah just ran a 90-minute discovery call with sales, customer success and two enterprise clients. Her Notion page is full of half-sentences. She has a voice memo transcript, four Slack messages from stakeholders adding things they forgot, and one comment from Legal that says “GDPR thing — need to follow up” with nothing else. She opens Claude, pastes everything in and types “extract requirements from these notes.”
The Skill loads automatically. Claude doesn’t need her to explain the format she wants or what sections to include. It already knows.
The SKILL.md:
markdown
---
name: pm-requirements-extractor
description: Extracts structured requirements from messy discovery notes, stakeholder
inputs, meeting transcripts or Slack threads. Use when user pastes raw notes and asks
to "extract requirements", "structure these notes", "turn this into a requirements doc"
or similar.
---
# Requirements extractor
When given raw discovery notes or stakeholder input, produce a structured requirements
document with these sections:
**Core problem being solved**
One clear sentence. If the notes don't agree on this, say so.
**User needs**
Who wants what and why. One line per need. If the same need appears from multiple
sources, note how many mentioned it.
**Functional requirements**
What the product must do. Number them. Write in plain language.
**Constraints and non-negotiables**
Technical, legal, resource or timeline limits that are fixed.
**Open questions**
Anything vague, contradictory or incomplete. Frame as questions to be answered,
not problems. These become the agenda for the next stakeholder meeting.
Rules:
- Where stakeholders contradict each other, flag the contradiction explicitly.
Do not pick a side or average the two positions.
- Where something is vague, add it to open questions. Do not invent specifics.
- Keep language plain. No jargon unless the user's notes used it.What Sarah gets: A clean doc where the SSO vs reporting priority conflict is called out directly, the GDPR comment becomes a specific open question (”What did Legal mean by ‘GDPR thing’? Needs follow-up before any data handling decisions”), and functional requirements are separated from the noise.
Advanced note: After the requirements doc is generated, paste it back in with “rank these by user impact versus implementation effort.” You get a rough prioritisation view without opening a separate session.
Skill #2: PRD first draft
What it does: Writes a complete product requirements document from a brief description of what you’re building, in your team’s format, every time.
When it loads: When you ask Claude to write a PRD, spec or product requirements document.
The scenario:
Marcus leads product at a fintech startup. His CTO wants a PRD for a new transaction alerts feature by end of week. Marcus has the idea clear in his head and a few rough notes. He knows writing from scratch takes half a day. He opens Claude and types “write a PRD for real-time transaction alerts.” The Skill loads, asks two clarifying questions, and delivers a full draft in about 10 minutes.
He spends the rest of his time editing rather than writing.
The SKILL.md:
markdown
---
name: pm-prd-writer
description: Writes product requirements documents from brief descriptions. Use when
user asks to "write a PRD", "draft a spec", "create product requirements" or describes
a feature and wants it documented formally.
---
# PRD writer
Before writing, confirm these if not already provided:
1. What is the product and who uses it? (2 sentences max)
2. What are the known technical or resource constraints?
If context is already clear from the conversation, skip to the PRD.
## PRD structure
**Problem statement**
What user problem does this solve? Why now?
**Goals and success metrics**
2-3 measurable outcomes. Include how each will be measured.
**User stories**
Minimum 5. Format: "As a [user type], I want to [action] so that [outcome]."
Write for at least two different user types.
**Functional requirements**
Numbered list. Plain language. One requirement per line.
**Out of scope**
Explicit list of related things this feature will NOT include.
This section is as important as the requirements themselves.
**Open questions**
Anything that needs a decision before development can start.
Rules:
- Plain language throughout. No technical jargon unless the user used it.
- Out of scope section must include at least 3 items.
- Do not write vague success metrics. Write measurable ones with a number attached.What Marcus gets: A full seven-section PRD with user stories covering at least two user types, plus an out-of-scope section that flags joint accounts, bill splitting and savings goals before anyone raises them in the review meeting.
Advanced note: Once the draft is done, ask Claude to read it as a senior engineer seeing it for the first time. Ask what questions they’d have. You’ll surface ambiguities before sprint planning rather than during it.
You just got 2 Skills that turn raw input into structured PM output.
But the heavier work in product is everything that happens after the doc exists — getting stakeholders aligned, handling pushback, writing for different audiences, making prioritisation calls under pressure.
The next 6 Skills cover that:
A roadmap narrative Skill that explains your sequencing decisions before anyone asks
A stakeholder prep Skill that generates the hardest questions you’ll face and helps you answer them honestly
A user research Skill that synthesises interview notes into findings in minutes
A spec review Skill that reads your spec as an engineer would and flags every ambiguity
A prioritisation Skill that argues against your own decision so you find the holes first
Plus: a one-page alignment template you can use before any major review
Upgrade to get the complete system.
Skill #3: Roadmap narrative builder
What it does: Turns a list of roadmap items into a coherent narrative for exec, board or all-hands presentations - one that explains the sequencing logic and addresses likely pushback before it happens.
When it loads: When you paste a roadmap list and ask Claude to write a narrative, presentation story or exec summary of your roadmap.