PM Skills is Paweł Huryn's third-party collection of product-management methods for an AI agent, including interview synthesis and PRD drafting in Claude Code. Start with its discovery and execution plugins for this task. A PM still needs to check whether the original interview supports a proposed requirement: a complete summary and a polished PRD do not establish that an inference is true.
Suppose you already have three interview records and need to decide which problem the first release should address. This guide combines the upstream interview and PRD commands with a human evidence check; it is an editorial workflow, not a promised automatic transcript-to-requirements conversion. The documented capabilities come from the interview command and PRD command.
Original Gwarket diagram. The human evidence gate and delivery checks are editorial recommendations, not claims that the plugin automatically verifies the source material.
Start with two plugins
| Job | Plugin and method | Handoff |
|---|---|---|
| Organize an existing interview | pm-product-discovery: the interview command uses summarize-interview |
Context, current behavior, pain points, quotes and contradictions |
| Draft the first PRD | pm-execution: the write-prd command uses create-prd |
A lean PRD, first-release scope, assumptions and open questions |
The interview command accepts transcripts or rough notes. It asks for a distinction between reported statements and behavior, with timestamps where available. A template cannot turn missing notes into reliable evidence.
As checked on November 6, 2026, the latest formal release is v2.2.0, dated October 10. The current README snapshot also points the AI Shipping Kit to phuryn/product-engineering; do not assume that every item in an old inventory still works from its old location. The four core interview and PRD files used here are unchanged between v2.2.0 and that main-branch snapshot.
Skills, commands and plugins
A skill supplies method instructions; a command is a workflow entry point; a plugin packages related files. This project's interview and write-prd are still command files. Under Claude Code's command naming rule, an installed command includes its plugin prefix, such as /pm-product-discovery:interview. Upstream documentation often uses the short /interview form. If it is missing or ambiguous, use the complete name shown in the / menu.
Set up the Claude Code route
You need a working, signed-in Claude Code installation and access to the GitHub project. PM Skills is third-party software; an organization's plugin policy still applies. The upstream installation section supplies these shell commands; only the two plugins needed for this task are included:
claude plugin marketplace add phuryn/pm-skills
claude plugin install pm-product-discovery@pm-skills
claude plugin install pm-execution@pm-skills
Start a new Claude Code session, or use /reload-plugins in an open one, then check the plugins in /plugin and the commands in the / menu. These checks follow Claude's installation and loading guidance. Adding a marketplace alone does not mean both plugins are installed and loaded. These commands do not pin a Git tag: inspect what was actually installed rather than assuming it is the source snapshot quoted here.
De-identify the material and keep an unchanged original. Decide whether the selected model may process it under the interview permissions and your organization's rules. A local source file does not imply offline model processing.
Codex and Cowork are separate routes
The upstream README gives a Codex installation route but explicitly says these commands do not run as Codex slash commands. Follow that interface's skill-loading approach and describe the workflow in natural language; do not paste Claude's command invocation as though it were a built-in Codex feature.
The project also documents Cowork installation. However, supported components differ across Claude Code, Cowork and claude.ai, as Claude's plugin overview explains. The steps below cover Claude Code, without treating another interface's controls, permissions or billing as identical.
Four handoffs from interview notes to a PRD
1. Summarize before prescribing a feature
After loading the plugin, invoke its complete command name and supply authorized, de-identified material:
/pm-product-discovery:interview summarize [attach the interview record]
This adapts the upstream short-form example to Claude's plugin namespace; the brackets indicate material to supply, not a literal file path. Separate context, current workflow, pain points, quotes and observations that contradict your assumptions. The documented command provides these synthesis fields; it is not a transcription service or a guarantee that quotations are authentic.
2. Check the evidence and choose one problem
Editorial judgment one: use the summary to focus source review, rather than to certify the source. Match proposed requirements to timestamps, paragraphs or line numbers. Keep direct quotations, paraphrases and your inferences separate. A quote that cannot be found in the original should not be presented as a participant's words.
The following is a fictional Gwarket example, not customer research or a captured plugin output:
| Source and location | A claim you can retain | What remains unsupported |
|---|---|---|
| Interview A, line 18: “I reconcile the tables manually every week.” | This participant reports weekly manual reconciliation | Every customer has this problem; automatic export is necessarily the solution |
| Two other records do not mention frequency | The current evidence leaves frequency unknown | Three participants each spend two hours every week |
Carry counterexamples into the next step as well. This evidence table is our handoff recommendation; upstream synthesis and contradiction handling are documented in summarize-interview and interview.
3. Draft a lean PRD from the checked material
The official short example is /write-prd SSO support for enterprise customers. For this workflow, select /pm-execution:write-prd, attach the reviewed summary and evidence table, and explain the problem, target users, existing workaround, first-release exclusions and any missing success-metric evidence.
The v2.2.0 write-prd command asks up to three questions in one message when the problem, users or success metrics are missing. It proceeds with marked assumptions only when told to go ahead. Do not invent a baseline to make the document look complete.
The default is a lean PRD of roughly one or two pages, with length treated as guidance. Its eight-part structure covers summary, contacts, background, objective, segments, value propositions, solution and release. Unknown contacts may be omitted; segments and value propositions are required. Each value proposition uses Who, Why, What before, How, What after and Alternatives. Ask separately for the detailed version. Source: create-prd.
4. Compare the proposed requirements with their sources
Editorial judgment two: first decide whether the document enables a first-release decision, then decide what detail to add. Keep the original records, checked evidence table and draft PRD as separate readable artifacts. Before handing it over, check:
- Can each customer claim in Background be traced to a particular record? Have counterexamples disappeared?
- Does the solution deliver the value proposition's How, and do success measures address its What after? This alignment is an explicit create-prd review requirement.
- Are unknowns, assumptions and first-release exclusions still visible? Has a pending question become a definite date or number?
- Who must decide on the draft, and which commitments have not been agreed with product, engineering or design?
Cost, limits and common obstacles
The repository uses the MIT license; that does not supply Claude Code model usage. Your Claude subscription, Console account or supported cloud provider has its own access, billing and limits. See the Claude Code prerequisites. This task does not require every marketplace plugin.
If a command is missing, check the installed plugin, session loading and complete name first. Loading a skill does not establish that a particular command entry point is present. If the PRD command and skill show different templates, check the version: the v2.2.0 changelog explicitly unified them. Do not present a resolved older difference as a current defect.
PM Skills cannot supply research evidence, a representative user sample, business trade-offs or decision accountability. It fits a PM who has material to organize and a first-release decision to make. With only a request for a polished PRD, gather evidence or label the assumptions before treating it as a requirement.
Next: organize material with reviewable AI meeting notes. If generated results routinely go straight into a team knowledge base, read why AI output is not knowledge.
Sources and verification date
Verified November 6, 2026. The formal release basis is v2.2.0, pinned to c68487d721e419ec87af1ae6412a842978eab785; installation and current repository scope also use the main README snapshot. Method sources: interview, summarize-interview, write-prd, create-prd, CHANGELOG and MIT LICENSE. Claude loading and names follow its installation guide, component rules and prerequisites. The diagram, fictional evidence table and two editorial judgments are Gwarket's work.