An AI skill pack for product managers. Runs in Claude Code and Codex.

AI can draft your PRD. It cannot call the draft slop.

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

Already using a 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 experience¹ so users² feel more engaged³ and retention goes up over time⁴.

1Vague. Name what is actually broken.
2Which users? New, returning, mobile?
3Vanity metric. Cut it.
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 through your provider's pm skill, 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 repository instructions 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. Persistent-context runs can log to pmdecisions.md; session-only decisions stay in the conversation.

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

Pick your runtime. Keep the same standard.

Step 1

Install for your provider

Claude Code

# Add the marketplace and install the plugin
/plugin marketplace add jameshemson/pm-skills
/plugin install pm@pm-skills

Codex

# Add the marketplace and install the plugin
codex plugin marketplace add jameshemson/pm-skills
codex plugin add pm@pm-skills

Working directly in this repository? Codex also discovers .agents/skills/pm without a plugin install.

Step 2
Teach

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

# Installed Codex plugin
$pm:pm teach

# Repo-local Codex skill
$pm teach
```

Step 3

Work

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

# Claude Code
/pm review path/to/spec.md

# Installed Codex plugin
$pm:pm review path/to/spec.md

# Repo-local Codex skill
$pm review path/to/spec.md

05 Start

Stop shipping vague specs.

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