pm-skills: 68 Product Management Skills Packaged for AI Agents

The gap pm-skills fills between a blank prompt and a real PM process

Ask an AI agent to write a PRD and you get a document. It will be fluent, well organised and almost certainly missing the parts a team argues about: which problem is being solved, what was ruled out, what would falsify the bet. The output depends entirely on how you phrased the request, and two people on the same team will get two incompatible documents.

pm-skills takes the opposite approach. It ships 68 named skills, each covering a defined step in a product lifecycle, organised as 11 foundation skills, 30 Triple Diamond phase skills, 12 utility skills and 15 tool skills covering Foundation Sprint and Design Sprint. The README describes them as "plug-and-play" and pairs them with 200+ sample outputs that set the expected quality bar. The intended user is a product manager, or an engineer doing PM work, who already has an agent installed and wants the agent to follow a process rather than improvise one.

The library's structure is the argument. The Triple Diamond phases are split into Discover (5 skills), Define (5), Develop (4), Deliver (6), Measure (6) and Iterate (4). That is a sequence, not a menu, and the skill names reflect it: the README gives /pm-skills:deliver-prd, /pm-skills:define-hypothesis and /pm-skills:deliver-user-stories as invocation examples. If your team has no shared vocabulary for where a piece of work sits, the phase names supply one.

How the skill library, sub-agents and workflows fit together

Each skill is a directory in skills/ with frontmatter that the repository validates in CI. The README links the Agent Skills specification at agentskills.io, so the format is not bespoke to this project: a skill is a prompt bundle an agent can discover and load by name. The repository root also carries a skill-manifest.json, which is the machine-readable index of what is available.

Above the individual skills sit two orchestration layers. The first is sub-agents: six of them, in agents/. The second is workflows, described in the README as "skill chaining". Installing the plugin gives you 10 /workflow-* orchestrator commands plus a /chain ad-hoc runner. So there are three levels of granularity: one skill for one artefact, a workflow for a multi-step sequence, and /chain when you want to compose your own sequence on the spot.

The tooling around this is deliberately thin. package.json names the root package pm-skills-tooling, marks it private, and describes it as "Repo validator-tooling dependencies. NOT the documentation site (that lives in site/ as its own package)." Its only devDependency is js-yaml, used by scripts/check-frontmatter-yaml.mjs to parse-validate YAML in the frontmatter lint. There is no runtime dependency to audit, because the skills are content, not a service. The trade-off is that quality control lives in CI contracts and review, not in a type system or a test harness that exercises the prompts.

Installing pm-skills in Claude Code and running a first skill

The README marks Claude Code as the recommended path, and it goes through a plugin marketplace rather than npm. Two commands add the marketplace and install the plugin from it.

/plugin marketplace add product-on-purpose/agent-plugins
/plugin install pm-skills@product-on-purpose

After that, the README states you have all 68 skills available, invocable by name. A first real use is the PRD skill, which sits in the Deliver phase.

/pm-skills:deliver-prd

The README does not document the arguments this command accepts, so expect the agent to ask for the context it needs. If you want the agent to frame the problem before writing anything, run /pm-skills:define-hypothesis first and let the PRD skill build on it. Note the README's warning about the old marketplace: installs via pm-skills-marketplace keep working, and the v2.21.0 release notes cover moving to the new home.

For agents other than Claude Code, the README points at the open skills CLI, naming Cursor, Copilot and Cline as supported targets.

npx skills add product-on-purpose/pm-skills

Cloning the repository works too, and the README links a Getting Started guide, a per-platform setup page covering Claude.ai, Codex, Cursor, Windsurf, GitHub Copilot, VS Code extensions and ChatGPT, and a short quickstart reference card. One caveat is stated plainly in the README: "By default every skill starts cold, so you re-supply your phase, your current initiative, and anything a previous skill already produced." Persistence is an optional configuration you set up, not a default.

Where pm-skills stops being the right tool

The cold-start behaviour is the largest practical limitation, and it is the project's own framing. Skills do not share state out of the box. If you run five skills across a discovery cycle, you are the integration layer, pasting outputs forward. The README offers an optional way to let the skills remember your project, but the default is stateless, and any workflow longer than two or three steps inherits that cost.

There is a second boundary worth naming. This is a library of prompts and reference outputs, not a system of record. Nothing here enforces that a PRD written in week one matches the measurement plan written in week six. The CI contracts the README mentions check the shape of skill files, not the quality of the product decisions they produce.

Finally, consider what 68 skills implies. Choosing between deliver-prd, define-hypothesis and the four Develop-phase skills requires you to already know the Triple Diamond vocabulary. A team without that background will spend its first sessions reading the library instead of using it. If you want a single general-purpose writing assistant, the library is more structure than you asked for. The repository also notes that its companion MCP server, product-on-purpose/pm-skills-mcp, is in maintenance mode, so do not plan an architecture around that integration.

pm-skills versus a general prompt library

The obvious alternative is a shared folder of prompts your team maintains itself. The difference is not the text of any individual prompt, it is the contract around it. A prompt library has no frontmatter schema, no manifest, no CI check that a file parses, and no sample outputs defining what good looks like. Adding a prompt is a copy-paste; adding a skill here means satisfying the frontmatter lint and the repository's contributing rules.

That overhead buys discoverability. An agent reads skill-manifest.json and knows what it can invoke. In a prompt folder, the agent knows nothing until someone pastes text in. The cost is that you cannot quietly fork a skill for your own team without either keeping the fork outside the manifest or maintaining the frontmatter contract yourself.

A second alternative is to skip the library and write a long system prompt encoding your process. That works until the process has branches. pm-skills handles branching by splitting phases into separate skills and letting workflows chain them, which is more files but also more inspectable: you can read the Discover skills without reading the Measure ones. The trade is real in both directions, and the deciding question is whether your team's process is stable enough to name its steps.

Versioning, licensing and the maintenance cost you are signing up for

The repository is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notices intact. It also includes an explicit patent grant, which matters if you embed the skills in a product you ship. Nothing here constitutes legal advice, and if you redistribute modified skills you should read the LICENSE and NOTICE handling yourself rather than relying on a summary.

The project tracks its own version in .claude-plugin/plugin.json, and the README's version badge is generated from that file by scripts/gen-derived-surfaces.mjs, with an instruction to edit the plugin manifest rather than the badge block. Release cadence has been steady: v2.31.1 on 2026-07-31, v2.32.0 on 2026-08-14, v2.33.0 on 2026-09-01, and the last push to main was on 2026-09-10. That is recent enough that pinning a version and reviewing the CHANGELOG before upgrading is a reasonable habit rather than a precaution against abandonment.

The real upgrade cost is not the code, it is your team's muscle memory. Skill names are the interface, and a rename changes what people type. The v2.21.0 marketplace move is the precedent: the README reassures existing users that the old marketplace "keeps working", but anyone who wants the new home has to follow release notes. Budget for a periodic read of CHANGELOG.md, and treat your own custom skills as the fragile part, since they must keep passing the frontmatter contract as the schema evolves.

Who should install pm-skills, and who should wait

Install it if your team already runs Claude Code, Codex, Cursor or a comparable agent, and if the friction you feel is inconsistency rather than capability. A PRD written by /pm-skills:deliver-prd will still be wrong in places, but it will be wrong in the same places as the last one, which is what makes review possible. The 200+ sample outputs are the part worth reading first, because they tell you faster than the skill list whether the library's quality bar matches yours.

Wait if you are looking for a product management tool with a UI, a database or shared state. This is a content repository with a validator, and the README's own note about cold starts should be read as a design statement, not a bug report. Wait also if your process is still changing month to month, because the phase structure will date faster than your thinking does.

The concrete first step is to open skill-manifest.json and count how many of the 68 skills map to work your team already does. If the answer is fewer than ten, the library is a reference document for you, not a workflow, and installing the plugin will add more surface than it removes.

Editorial conclusion

Adopt pm-skills if you already work inside Claude Code, Codex or Cursor and you want product artefacts produced against a named phase model rather than a blank prompt. Do not adopt it if you expect the skills to remember your project: the README states every skill starts cold unless you configure persistence yourself. Before committing, verify the current version in .claude-plugin/plugin.json, check that skill-manifest.json lists the skills you intend to invoke, and read the CI-enforced frontmatter contract in the repository's scripts directory, because that contract is what governs whether a skill you write will be accepted.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. product-on-purpose/pm-skills on GitHub
3. Project website
4. README
5. Releases