Claude Skills and AI Prompts for Product Managers in 2026

Claude Skills, which Anthropic calls Agent Skills, are folders of instructions that teach Claude to do a specific job your way. Each holds a SKILL.md file with a name and description in YAML front matter, Markdown instructions below, and any templates or scripts you bundle (Anthropic).

Skills load in three stages, which Anthropic calls progressive disclosure:

1. At startup: only the name and description, about 100 tokens per skill.
2. When a request matches: the SKILL.md body, typically under 5,000 tokens.
3. As needed: bundled files. Scripts run, and only their output enters the conversation.

So you can install dozens of skills without crowding Claude's context, and the description becomes the most important line in the file: Claude matches your request against it. Anthropic says it "must say both what the Skill does and when to use it," in at most 1,024 characters.

Skills run in claude.ai, Claude Code, the Claude API, and ChatGPT and Codex, and each one shares them differently:

The format is portable. Anthropic released it as an open standard at agentskills.io, and OpenAI's Academy says ChatGPT skills can be exported to other tools that support it, including Codex (OpenAI Academy). Keep one master copy of each skill, because Anthropic's docs say skills uploaded to claude.ai and to the API do not sync with each other.

Treat a community skill like software you install. Anthropic warns that a malicious skill "can direct Claude to call tools or run code in ways that don't match the Skill's stated purpose," so read every file before you let it near customer data.

Build discovery and prioritization first: the method is easy to write down, and a model left alone will happily invent the evidence. The six prompts below work as written in Claude, ChatGPT, Gemini, or Copilot. Fill in the brackets, and use the template further down when one is ready to become a skill.

Feedback Synthesis

Give every row an account and a date, then count accounts and mentions separately. One loud customer posting in five channels is one account, not five.

Synthesize customer feedback about [product area] from [date range].
Each row below has the feedback text, account, source, and date.

1. Group rows by the underlying problem, not the feature requested.
2. For each problem, count unique accounts and total mentions.
3. List the source types behind it (tickets, calls, surveys).
4. Add two verbatim quotes with account and date.
5. Mark problems that first appeared in the last 30 days.

Output a table: problem | accounts | mentions | sources | new? | quotes.
Rules: quote only text that appears in the rows. Put problems with
fewer than 3 accounts under "Thin signal" instead of the table.

To run this as a weekly team habit, see how to synthesize customer feedback without a research team.

Discovery Interview Prep and Debrief

Run the prep half before the call and the debrief half after. Questions about specific past moments get real behavior; questions about what someone would do get guesses.

Prep: I'm interviewing a [role] at a [segment] company about [problem space].
Write 8 questions about specific past moments ("Tell me about the last
time you..."). No leading questions and no questions about our features.

Debrief: Here is the transcript. Extract:
- The job they were trying to get done
- Each pain point, with the exact quote and timestamp
- The workaround they use today and what it costs them
- Anything that contradicts our assumption that [assumption]
Label your own reading "Interpretation:" and keep it apart from quotes.

Prioritization

Give every option the same evidence fields. The last two lines do the most work, because they let the model call a tie and disagree with you.

Compare these options: [A], [B], [C]. Our goal this quarter is [outcome].
Using only the evidence below, report for each option: accounts affected,
segments and ARR, severity (1-3), 90-day trend, explicit requests versus
the underlying problem, and the strongest quote.

Rank the options and say what new evidence would change the ranking.
If two options are close, say so instead of forcing a winner.
If the evidence does not support the option I seem to prefer, tell me.

For the method behind these signals, see how to decide what to build next, and for where an AI ranking should stop and your judgment take over, see what an AI product manager agent is.

PRDs and Briefs

A brief generator's worst habit is filling every section with plausible text. Make "Unknown" an allowed answer, and the gaps become your research list.

Draft a one-page brief for [problem]. Sections: Problem (in the
customer's words), Who is affected (segments, accounts), Evidence
(counts plus 3 quotes with sources), Proposed scope, Non-goals,
Success metric and the date we check it, Risks and open questions.
Use only the evidence I provide. If a section has no evidence, write
"Unknown" and the question we need to answer. Do not fill it in.

NPS Breakdown

The score is the least useful number in an NPS report; the drivers by segment are what you act on. The 30-response floor below is a rule of thumb, not a statistical test, so pick your own and keep it the same every wave.

Here are NPS responses with score, comment, account, segment, and date.
Promoters score 9-10, passives 7-8, detractors 0-6.
NPS = % promoters minus % detractors.

Report: the score and sample size; counts for each group; NPS by segment,
flagging any segment with fewer than [30] responses; the top 3 detractor
and promoter drivers with quotes; and the change since [previous period].
Show the denominator for every percentage. Do not claim a cause from
score movement alone.

Competitor Analysis from Public Reviews

Your competitors' unhappy customers describe your openings in their own words. Keep the model on what reviewers said, not guesses about the rival's plans.

Here are public reviews of [competitor] from [G2, Capterra, Reddit, app stores].
Group them into what customers praise and what they complain about.
For each group, give the number of reviews, two short quotes with links,
and whether it touches [our product area].
Then list: complaints we already solve, complaints we could solve,
and praise we need to match. Do not speculate about their roadmap.

For how to collect reviews within site terms and check gaps against your own customers, see how to find product opportunities in competitor reviews.

The rules in a PM skill matter more than its steps, because they tie the model's confidence to evidence. Put these five in every skill:

1. Quote only from the input. An invented quote is the worst failure, because it looks exactly like evidence.
2. Show the denominator. "12 of 140 accounts" can be checked. "Many customers" cannot.
3. Separate the request from the problem. "Add a CSV export" is a solution. "I rebuild this report by hand every Monday" is the problem.
4. Label interpretation. Keep what customers said apart from what the model thinks it means.
5. Flag thin evidence. Set a line, such as three accounts, and send anything below it to a "needs research" list.

Turn a prompt into a skill the third time you paste it, when the steps have stopped changing. Plan on about an hour per skill:

1. Run the job once in a normal chat. Fix the output until you would send it to your team.
2. Ask Claude to turn it into a skill. Anthropic notes that Claude handles the skill format natively, so "turn what we just did into a skill" is enough.
3. Rewrite the description. Write it in the third person, say what the skill does and when to use it, and include the words you actually type, such as "NPS" or "detractors."
4. Move long templates into their own file. Link it from SKILL.md and keep the main file under 500 lines, as Anthropic recommends (Anthropic).
5. Test it on three real cases. Make one a case where the right answer is "not enough evidence."

A minimal SKILL.md for feedback synthesis looks like this:

---
name: synthesizing-feedback
description: Groups customer feedback into problems with account counts, mentions, sources, and verbatim quotes. Use when the user asks to synthesize, summarize, or find patterns in support tickets, call notes, surveys, or interview notes.
---

# Feedback Synthesis

## Steps
1. Group feedback by the underlying problem, not the feature requested.
2. Count unique accounts and total mentions separately.
3. List source types and two verbatim quotes per problem.

## Output
Table: problem | accounts | mentions | sources | new? | quotes

## Rules
- Quote only text that appears in the input.
- Put problems with fewer than 3 accounts under "Thin signal."

Save it as .claude/skills/synthesizing-feedback/SKILL.md in a repo, and Claude Code runs it as /synthesizing-feedback. For claude.ai, zip the folder and upload it. Skill names cannot include the words "claude" or "anthropic."

A skill that runs on pasted text analyzes a sample, not your customer base. A skill holds the method; it still needs a way to reach the evidence. Three things break as you grow:

• Coverage. You paste what fits, so quiet accounts and older tickets drop out.
• Context. The model does not know an account's plan, ARR, or segment unless every row carries it.
• Repeatability. Next week's paste is a different sample, so a "trend" compares two samples, not two periods.

Once the feedback no longer fits in one paste, or you run the job weekly, connect the source through an MCP server so the skill queries the system of record directly. For that and the other options, including files and RAG, see how to connect customer feedback to Claude or ChatGPT.

Deck publishes seven skills that run the jobs above on your Deck workspace instead of pasted text. Deck groups feedback from your connected sources into Themes and a ranked Opportunity Backlog, and the skills query it through Deck's MCP server before they answer (Deck docs).