A product skill pack for Claude Code

Claude can draft your PRD. It can't tell you it's slop.

pm-skills can. Nine modes that critique and sharpen the product docs your AI generates.

Already using Anthropic's official PM plugin? pm-skills reviews what it writes.

One pm skill, nine modes teach · setup · brief · spec · stories · metrics · review · decide · discover

Install pm-skills See the nine modes →
Worked example What review does to a vague brief.
Draft unreviewed

We want to improve the onboarding experience1 so users2 feel more engaged3 and retention goes up over time4.

  1. 1Vague. Name what is actually broken.
  2. 2Which users? New, returning, mobile?
  3. 3Vanity metric. Cut it.
  4. 4No baseline, no target, no date.
/pm review selects 3 to 4 reviewer personas
Sharpened reviewed

New mobile users reach a 12-field address form at onboarding step 3. 42% abandon it. Cut the form to one field. Target: step-3 completion rate from 58% to 80% this quarter.

Slop-tested: audience, problem, metric, timeframe

01 Method

Three things a prompt won't do.

A prompt turns a feature idea into a draft spec in seconds. It will not reject its own defaults, review its own work, or learn how you work. pm-skills does all three.

aReject its own defaults

Before a word is written, every generation mode throws out the AI-PM defaults: generic personas, vanity metrics, untestable acceptance criteria, circular risk mitigations. What is left is specific to your product.

bReview its own work

The review mode picks 3 to 4 expert personas for the document in front of it (Senior Engineer, QA Lead, VP Stakeholder, End User, Skeptical PM), reviews from each independently, then ranks every finding by severity.

cLearn how you work

Run teach once. It captures your frameworks, your doc formats, the things you never want to see again. Every other mode inherits it, so pm-skills works the way you already do.

02 The modes

One skill. Nine modes.

Call a mode directly with /pm <mode>, or describe what you need in plain language and the right one runs. The drafting modes end with the critic's pass on their own output, so even our drafts get the review treatment.

/pm review

Adversarial critique of any doc, plan, strategy, or message. It frames the audience, reviews against the document type, then always asks whether to draft fixes for the P0s and P1s. If you only learn one mode, learn this one.

Set up
/pm teach One-time setup. Captures your product, users, strategy, and how you prefer to work, then writes .pmcontext.md. Every other mode inherits that context.
/pm setup Generates a CLAUDE.md for your product team from team norms, domain, and ways of working.
Create, then critique
/pm brief An audience-aware brief from a feature description, design, or screenshot. Asks who it is for, then writes it structured and slop-tested.
/pm spec A full product specification: success metrics, risks, rollout plan, and what is explicitly out of scope.
/pm stories Breaks a feature into JTBD-framed user stories with testable acceptance criteria, and flags hidden dependencies.
/pm metrics Defines primary, secondary, guardrail, and counter-metrics with baselines and measurement plans. Pushes back on vanity metrics.
Decide and discover
/pm decide Structures a decision: options, weighted criteria, trade-offs, bias checks. Writes the result to pmdecisions.md in your repo, then resurfaces open decisions on the next run.
/pm discover Plans customer conversations that get truth, not politeness, then debriefs them to extract signal.

Missing a mode? Suggest one on GitHub.

03 Quality gate

The PM Slop Test.

Every mode runs this before it hands anything back. Show the result to engineering, and if the first hour fills with clarifying questions, it was slop.

PM Slop Test 7 checks
  • 01Audience specified Not "users". Which users, in what context, with what constraints?
  • 02Problem stated Not "better experience". What's broken, for whom, and what's the evidence?
  • 03Success measurable Not "positive feedback". What metric, what target, measured how?
  • 04Edge cases covered Not just the happy path. What happens when it fails, when data is empty, when users race?
  • 05Scope bounded Not infinite. At least three things explicitly out of scope.
  • 06Trade-offs explicit Not "obviously correct". What are you giving up, and what does it cost?
  • 07Concise enough to read Could this be half as long? If a section exists only to sound thorough, cut it.
04 Install

Up and running in three minutes.

  1. Step 1

    Install

    Two commands. No dependencies, no config.

    # Add the marketplace
/plugin marketplace add jameshemson/pm-skills

# Install the plugin
/plugin install pm@pm-skills
  2. Step 2

    Teach

    Run /pm teach once. It learns your product, your users, and how you work, so every mode starts from real context.

    # Run once to set up your product context
/pm teach
  3. Step 3

    Work

    Call any mode, or describe the task in plain language. Each one inherits what teach captured.

    # Then call any mode
/pm brief "User can filter dashboard by date range"
/pm review path/to/spec.md
/pm decide "Should we build SSO or focus on onboarding?"
05 Start

Stop shipping vague specs.

pm-skills is free and open source. Install it, run /pm teach, then point /pm review at the next thing you are about to ship.

View on GitHub See the install steps →