Product-Manager-Skills: 77 PM Frameworks Packaged as Agent Skills

The Problem: An Agent Writing a PRD From Nothing

The README states the motivation directly: generic AI output is a PM's worst enemy, and an agent told to write a PRD without shared context produces a document that no stakeholder trusts and no engineer can act on. That is a real failure mode and it is not specific to any one model. The agent has no default opinion about which prioritisation method fits a given team, no memory of the anti-patterns that make a user story useless, and no vocabulary for the difference between a positioning statement and a value proposition. It fills the gap with plausible-sounding structure.

This repository addresses that by shipping the framework text itself. Each skill is a directory containing a SKILL.md file, and the README links them by name. The intended audience is a working product manager who already uses an agent for drafting and wants the agent to argue from a named method rather than from generalities. The secondary audience is the PM who wants to learn the method. The README is explicit that the goal is dual, functional and pedagogic in equal measure, and that neither is a byproduct of the other. That is an unusual claim for a tool repository and it shapes how the content is written.

What a Skill File Actually Contains

The repository is Shell as its primary language, which is worth pausing on. The substance is Markdown: each skill lives at a path like skills/problem-framing-canvas/SKILL.md, and the README describes the content as the why behind each framework, the failure modes to avoid, and the judgment to apply them correctly. A skill is therefore a structured knowledge document that an agent reads, not a function the agent calls.

That design decision has consequences. Because there is no executable layer, the quality ceiling of the output depends entirely on how well the Markdown is written and how completely the agent loads it. A poorly prompted agent can read the positioning-statement skill and still produce something that ignores Geoffrey Moore's template. The README's claim that skills teach the human the reasoning behind each framework is the compensating mechanism: a PM who knows the method can spot when the agent has drifted from it.

The repository also has a commands/ directory alongside skills/.

How the Skills Are Organised, and Where the Curation Shows

The README groups skills by the job a PM is trying to accomplish rather than by framework family. Framing and strategy holds problem-framing-canvas, which the README attributes to MITRE's Look Inward, Look Outward, Reframe sequence; positioning-statement, attributed to Geoffrey Moore; and product-strategy-session, described as a full arc running from positioning through problem framing and solution exploration to a roadmap, with a stated duration of 2 to 4 weeks.

The durations are the most interesting detail in the README. prd-development is listed at 2 to 4 days. roadmap-planning is 1 to 2 weeks. discovery-process is 3 to 4 weeks. These are not decorative. They tell a reader whether a skill is a single sitting or a multi-week engagement, and they set an expectation the agent can be held to. A skill that claims a 2 to 4 day PRD and produces a page of bullet points has failed visibly.

Attribution is handled the same way throughout. user-story is described as the Mike Cohn format plus Gherkin acceptance criteria with anti-patterns. epic-breakdown-advisor cites Richard Lawrence's 9 patterns. press-release cites Amazon Working Backwards. organic-growth-advisor cites the McKinsey Growth Pyramid. Naming the source matters here because it gives a reviewer something to check the skill text against. If the user-story skill misstates Cohn's format, that is a defect a reader can identify without running anything.

Getting It Running: Plugin Marketplace and Manual Installation

The README badges the project as a Claude Code Plugin Marketplace and links to the Claude Code plugin marketplace documentation. That is the intended install path for Claude Code users: register the marketplace, then install the plugin from it. Check the plugin marketplace documentation linked in the README for the current syntax.

For agents that do not support plugin marketplaces, the README names Claude, Codex and ChatGPT and describes the skills as ready for any agent that can read structured knowledge. That points to the manual path: clone the repository and point the agent at the skill directories, or copy the relevant SKILL.md files into whatever directory your agent reads for context. Because the files are plain Markdown, there is no build step and no dependency to install.

The practical configuration question is selection, not installation. With 77 skills available, loading all of them into context is wasteful and probably counterproductive. The README's own organisation by job to be done is the right index: pick the handful of skills that match the current engagement, such as prioritization-advisor and user-story for a delivery cycle, or discovery-interview-prep and opportunity-solution-tree for a research phase.

The Skills That Ask Questions Before They Answer

Several skills in the README are described as advisory rather than generative, and the distinction is the most useful thing in the repository. prioritization-advisor is described as asking 3 to 5 questions about your context and then recommending RICE, ICE, Kano or an alternative. stakeholder-engagement-advisor diagnoses a stakeholder's profile and context before delivering message framing, medium, cadence and a named next action. pol-probe-advisor recommends a prototype type based on your hypothesis and risk level.

That pattern is a deliberate constraint on the agent. A generative skill takes a request and produces a document. An advisory skill refuses to produce the document until it has extracted context, which is closer to how a senior PM actually behaves and much harder to get from a bare model. It also means these skills will feel slower. If you want a RICE score in thirty seconds, prioritization-advisor is the wrong tool and you should just ask the model for RICE directly. If you want to know whether RICE is the wrong framework for your situation, the question-first design is the point.

The same logic applies to business-health-diagnostic, which the README says diagnoses SaaS health across growth, retention, efficiency and capital using your real metrics. The skill is only as good as the numbers you feed it.

Licence: CC BY-NC-SA 4.0 and the NOASSERTION Gap

The repository metadata reports the licence as NOASSERTION, which means GitHub's classifier could not match the licence file to a known template. A LICENSE file sits at the repository root, and that file is the operative statement.

Read the LICENSE file before folding these skills into a paid product or an internal commercial workflow.

The NOASSERTION mismatch is itself a signal. A repository at v0.84 with 77 skills should have a licence file that GitHub recognises. Until it does, anyone running licence scanning will get an ambiguous result, which is a friction point for adoption inside a company with automated compliance checks.

The Real Alternative: Prompt Libraries and Your Own Templates

The obvious alternative is a prompt library: a shared document or Notion page where a team keeps the prompts that produce acceptable PRDs, user stories and positioning statements. The difference in approach is where the reasoning lives. A prompt library encodes what to ask for. This repository encodes the framework, its provenance, its failure modes and its expected duration, and leaves the asking to the agent. A prompt library degrades quietly because nobody records why a prompt is worded a certain way. A SKILL.md at least carries the why alongside the instruction.

The second alternative is writing your own skills. If your organisation has its own product process, its own metrics definitions and its own definition of a good PRD, a house skill file will beat a general one. The trade-off is attribution and maintenance: you inherit the work of getting the framework right, and you own it forever. This repository's value is that someone else has already named the sources and written the anti-patterns.

The third alternative is doing nothing and relying on the model's built-in knowledge of RICE and Kano. For a PM who already knows the frameworks and just needs a fast draft, that is often sufficient. The repository earns its place when the agent's output has to survive review by people who will ask which framework was used and why.

Maintenance, Versioning and What to Verify Before Adopting

The release cadence is visible from the release dates. v0.82 landed on 8 July 2026, v0.83 on 17 July 2026, v0.84 on 10 August 2026, and the last push to main was 16 October 2026. Three releases in roughly five weeks, and the version numbers are still in the 0.8x range. That combination, frequent releases and a pre-1.0 version, tells you the skill text is still being revised rather than settled. If you pin to a release, expect to review the diff before upgrading, because a changed SKILL.md changes agent behaviour in ways that are not obvious from a version number.

Because there is no executable dependency, the upgrade cost is reading time rather than integration work. You pull the new tag, diff the skill directories you actually use, and decide whether the changes improve or regress your output. Teams that use two or three skills have a small review surface. Teams that load all 77 do not.

The README badge and the ASCII banner both state 77 skills. If that count matters to you, verify it against the skills directory at the tag you install rather than trusting the badge, since the release history shows the repository moving quickly.

Editorial conclusion

Adopt this if your team already runs Claude Code or Codex and wants named PM frameworks (RICE, Kano, Mom Test interviews, Amazon Working Backwards) available to the agent without pasting prompts each time, and if the terms in its LICENSE file fit how you work. Do not adopt it if you need a hosted tool with a UI, or if you expect the agent to reason about your metrics without you supplying them. Before committing, verify two things: what the LICENSE file permits, since GitHub's metadata reports the licence as NOASSERTION, and whether the version tag you install matches the skill count you expect, because the README states 77 skills while the release history shows frequent increments.

Frequently asked questions

Official sources

1. deanpeters/Product-Manager-Skills on GitHub
2. Issues
3. README
4. Releases