Product-Manager-Skills: 77 PM Frameworks Packaged as Agent Skills
Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.
At a glance
- What is it?
- A Shell-based repository that turns named product management methods into structured skill files for Claude Code, Codex and other agents. The value is in the framework text and the failure modes it encodes, not in any runtime machinery.
- Who is it for?
- 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 a CC BY-NC-SA 4.0 licence fits 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.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
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. There is no compiled runtime and no service to start. 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. There is also no validation step. Nothing in the repository checks that the agent followed the framework, so 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 README also lists 6 command workflows alongside the 77 skills. The material does not describe what those workflows contain or how they are invoked, so I cannot say more about them than that they are counted separately from the 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. The repository does not reproduce the exact marketplace commands in the material I have, so I will not invent them. Check the plugin marketplace documentation linked in the README for the current syntax.
For agents that do not support plugin marketplaces, the banner lists Cursor, Codex, n8n and OpenClaw as targets, and the README 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 README does not document a mechanism for scoping which skills load, so that selection is manual.
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. It cannot compute those metrics. It can structure the conversation about them, and 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. The README banner and footer state CC BY-NC-SA 4.0, and the version line repeats it. That is the operative statement.
CC BY-NC-SA 4.0 carries three conditions that matter for adoption. Attribution is required. NonCommercial use is restricted, so an organisation planning to fold these skills into a paid product or an internal commercial workflow needs to examine that clause rather than assume it is fine. ShareAlike means adaptations are distributed under the same terms. I am not a lawyer and this is not legal advice, but the NonCommercial condition is the one that will surprise people, because the repository reads like a developer tool and developer tools are usually permissively licensed.
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 in the supplied data. 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 1 September 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 count is maintained by hand and the release history shows the repository moving quickly. The same applies to the six command workflows, which are mentioned but not enumerated in the material available to me.
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 a CC BY-NC-SA 4.0 licence fits 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: whether your use is commercial, since the README carries a NonCommercial clause, and whether the version tag you install matches the skill count you expect, because the README badge and the banner both state 77 skills while the release history shows frequent increments.
Community notes