pm-skills: A 68-Skill Library for Product Managers Working Inside AI Agents

The Problem pm-skills Targets Is Prompt Structure, Not Model Capability

Most product managers who use an AI agent for writing work start from a blank chat and describe what they want. The result depends heavily on how they phrase the request that day. pm-skills takes the opposite position: the request should be a named, versioned artefact with a fixed shape, and the PM should supply only the specifics of their situation. The library ships 68 such artefacts, split by the README into 30 Triple Diamond phase skills, 11 foundation skills, 12 utility skills, and 15 tool skills covering Foundation Sprint and Design Sprint. The intended user is a product manager who already runs an agent such as Claude Code, Cursor, or Codex and is willing to learn command names in exchange for repeatable output. It is not aimed at someone who wants a graphical tool, and it is not a substitute for product judgement. The README's own framing is a library of skills plus templates, workflows, and sample outputs that set a quality bar, which is a claim about consistency, not about the agent becoming smarter.

How a Skill Is Invoked and What the Phase Folders Contain

Skills are addressed as slash commands under a namespace. The README gives three examples: /pm-skills:deliver-prd, /pm-skills:define-hypothesis, and /pm-skills:deliver-user-stories. The phase prefix is part of the command name, so the taxonomy is visible at the point of use. Discover, Define, Develop, Deliver, Measure, and Iterate each hold between four and six skills, and the foundation family holds eleven cross-cutting ones. Two tool families sit alongside the phases: Foundation Sprint with seven skills and Design Sprint with seven. One standalone tool skill is listed separately. A further twelve utility skills handle meta-tooling, which in practice means working on the skill library itself rather than on a product. The README states the project conforms to the agentskills.io specification, so the unit of distribution is a skill folder with metadata rather than a monolithic prompt file. That matters for anyone who wants to vendor a subset: you can copy the phase directories you care about instead of the whole tree.

Install Paths Diverge Sharply Between Claude Code and Everything Else

For Claude Code the README recommends a plugin marketplace route: /plugin marketplace add product-on-purpose/agent-plugins followed by /plugin install pm-skills@product-on-purpose. The marketplace lives in a separate repository from the skills themselves, which is worth noting if you audit dependencies, because the install pulls from agent-plugins while the content lives in pm-skills. For Cursor, Copilot, Cline, and other agents the documented route is npx skills add product-on-purpose/pm-skills, using the open skills CLI. A third option is a plain git clone of the repository. The README also notes that installs made through the older pm-skills-marketplace keep working, with migration instructions in the v2.21.0 release notes. After install, the README says you get all 68 skills plus 10 /workflow-* orchestrator commands, a /chain ad-hoc runner, templates, sub-agents, and more than 200 sample outputs. Those counts are the project's own; I have not run the install, so treat the exact command surface as documentation rather than verified behaviour. The README also points to a getting-started guide and a per-platform setup page for Claude.ai, Codex, Cursor, Windsurf, GitHub Copilot, VS Code extensions, and ChatGPT.

Sessions Start Cold Unless You Configure Project Memory

The README is direct about a default that will annoy anyone using the library daily: every skill starts cold, so you re-supply your phase, your current initiative, and anything a previous skill already produced. The README begins describing an optional mechanism for letting skills remember your project, but the supplied text is cut off at that point, so I cannot confirm how it is configured or where state is stored. That is a real gap for evaluation. If you are considering adoption, the question to answer first is whether the memory feature persists across sessions and where it writes, because a product management workflow that spans a discovery phase and a delivery phase needs continuity. Without it, each command is an isolated prompt with a fixed shape, which is still useful but much closer to a well-organised snippet collection than to a process tool. The README's own phrasing, that you re-supply what a previous skill already produced, is the honest description of the default.

Sub-Agents and Workflow Chaining Are Where the Process Claim Lives

The library includes six sub-agents and a set of workflows described as skill chaining. Ten /workflow-* orchestrator commands ship after install, plus a /chain runner for ad-hoc sequences. This is the part that distinguishes pm-skills from a folder of prompt templates: chaining implies that the output of one skill becomes structured input to the next, so a hypothesis skill can feed a delivery skill without the PM retyping context. The README does not, in the supplied text, spell out the chaining contract, so I cannot say whether outputs are validated against a schema or simply passed as text. The project does mention CI-enforced contracts, which suggests some machine-checkable structure exists in the repository, most likely around skill metadata rather than around generated product artefacts. Anyone whose workflow depends on the chain should read the workflow documentation before assuming typed handoffs. The distinction matters: text passthrough degrades quietly, while a contract fails loudly.

The Library Is Opinionated About Method and That Is the Main Trade-off

Triple Diamond is a specific process model, and Foundation Sprint and Design Sprint are specific workshop formats with their own facilitation rules. Adopting pm-skills means adopting those framings for whatever you produce with it. If your organisation runs a different discovery process, the phase names will not match your vocabulary, and you will be translating on every invocation. The 200+ sample outputs compound this: they set a quality bar, per the README, but they also encode house style. A PM who disagrees with that style has two options, edit the skills locally or stop using them, and the README's note that the version badge block is generated by scripts/gen-derived-surfaces.mjs with the instruction to edit .claude-plugin/plugin.json instead is a warning that at least some files are regenerated and local edits there will not survive. The practical alternative to pm-skills is not another skill library but a small set of your own prompt files committed to your team's repository. That approach costs more upfront and gives you nothing off the shelf, yet it produces artefacts in your format and depends on no external release cadence. The difference is ownership of the format versus speed of setup.

Maintenance Signals, Licensing, and What Changes Between Releases

The repository is active, not archived, with a last push in September 2026 and releases v2.33.0, v2.32.0, and v2.31.1 between late July and early September 2026. That cadence, roughly one release every two to three weeks, tells you the skill definitions move. If you fork or vendor a subset, you inherit a rebase cost at that rhythm, and the version badge generation note suggests the project maintains derived surfaces that drift from hand-edited files. The licence is Apache 2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirements around notices and changed files. That is a permissive arrangement, and I am not a lawyer, so have someone check your obligations if you redistribute modified skills inside a product. The README also flags that the companion MCP server repository is in maintenance mode, which is a signal about where the project is investing: skills distributed to agents, not a protocol server.

Who Should Install It and What to Check Before You Do

Install pm-skills if you already work in a terminal with an agent and want product artefacts produced through named, sequenced steps. Start with the plugin route if you use Claude Code, the npx skills route otherwise, then run /pm-skills:define-hypothesis on a real initiative and compare the output against what you would have written. Skip it if you need a hosted interface, if your team will not standardise on Triple Diamond vocabulary, or if you cannot accept an external dependency in your product process. Verify three things first: how the project memory feature stores state and whether it survives a session, whether workflow chaining passes structured data or plain text, and which files in the repository are generated rather than hand-edited. The README's own instruction to edit .claude-plugin/plugin.json rather than the generated badge block is the clearest available clue to that last point, and it is the one that will bite anyone who customises the library in place.

Editorial conclusion

Adopt pm-skills if you already drive a coding agent from a terminal and want product artefacts produced through a defined sequence rather than a blank chat: the Claude Code plugin install is two commands, and the phase names give you a shared vocabulary with the rest of your team. Do not adopt it if you need a hosted tool with a UI, or if your organisation will not accept Apache 2.0 terms and an external dependency in its workflow. Before committing, run one skill end to end on a real initiative, confirm the output matches your own quality bar rather than the library's samples, and check the plugin manifest and generated version badge in the README to see which surfaces the project regenerates automatically, since that tells you where local edits will be overwritten.

Official sources

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