Start with a risky assumption before asking for a PRD
PM Skills gives your assistant instructions for product work, including /discover and /write-prd. The useful choice comes before the document: should you investigate an assumption or describe a feature you've already decided to build? Its discovery workflow links idea generation to assumption mapping, prioritization, and experiments. If your team jumps straight from a plausible idea to a polished specification, that sequence is a good reason to try it.
The 6.3 MB checkout we measured is modest, and the project is MIT licensed. Most of the product value sits in written instructions that an assistant follows. You bring the customer evidence and business context. A skill can ask better questions about a proposed onboarding change, but it cannot establish that customers want the change merely by producing a convincing answer. Keep that distinction visible when you share the resulting document.
What happened when we ran it
Our sandbox installed commit 6058e29 in 5 seconds, adding 35 packages and using 37 MB on disk. The build step succeeded in 0 seconds. Pytest passed all 15 tests in 1 second, with 0 failures, and pip-audit reported 0 known vulnerabilities. We ran this on October 9, 2026, in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and Python 3.12, without secrets.
The checkout contained 151 files and roughly 798 lines of source. Our scan found 2 CI workflow files and a tests directory, with no Dockerfile. These are reassuring repository mechanics. They do not measure whether an assistant's market analysis is accurate, its interview summary preserves a customer's meaning, or its recommendation improves a product decision. None of those outcomes appears in our lab results. The repository's plugin validation script checks manifests, skill files, commands, and cross-references. That is useful housekeeping for a marketplace whose parts refer to one another. Our 15 passing tests should still be read as the result of the suite we ran, rather than proof of every framework's correctness. The package audit also says nothing about the factual quality of generated advice.
Your assistant determines which workflows you can use
The README groups capabilities into plugins, including product discovery and execution. Claude Code and Cowork are its main workflow targets. Other supported assistants can read the skill files, while the README explicitly limits slash-command portability. For those hosts, expect to express the workflow in ordinary language or adapt command instructions yourself. Read the host-specific installation guidance before expecting the same interaction everywhere.
The 37 MB environment from our run excludes the assistant service you choose. The marketplace supplies no independent model runtime, and access to your host assistant follows that host's account and authentication requirements. Supplying interview transcripts or internal plans therefore needs the same data judgment as any other assistant conversation. A small repository footprint doesn't tell you where the model processes your material or what your provider retains.
The A/B sample-size guidance needs an independent check
An open sample-size correction, PR #64, reports that the A/B analysis formula omits target power. The current skill file still shows a formula built around significance, baseline proportion, and minimum detectable effect, followed by an instruction to flag low power. That mismatch matters: deciding how much traffic an experiment needs can determine whether a team waits, ships, or abandons a change.
Our run's 0 known vulnerabilities and 15 passing tests do not resolve that statistical concern. The proposed correction is an upstream contribution, not a change we observed merged. I would use this skill to organize an experiment discussion, then verify sample planning with a trusted calculation outside the assistant. If you need an unattended statistical decision system, this instruction pack is the wrong dependency to treat as your authority.
Navigation and shipping checks still need a human owner
Issue #46 reports difficulty routing among the installed skills and asks for a clearer hierarchy. That is a specific usability objection, especially if you're trying to keep an existing coding assistant focused. Start with the plugin connected to today's decision rather than enabling everything and hoping the host consistently chooses well. The README's discovery and PRD entry points help, but they don't settle the issue reporter's concern.
The 151-file sandbox snapshot also predates the latest release. Version v2.2.0 shipped on October 10 with revised PRD guidance and shipping-review instructions, including a separate model review. Those release notes describe useful precautions for AI-written code. They do not make /ship-check a deterministic certification process. Someone still needs to assess surviving findings and approve the change against the application's actual requirements.
October activity earns a trial with narrow responsibilities
The last push was October 10, 2026, and GitHub showed 26,871 stars plus 43 open issues and PRs. Recent merged contributions revised shipping artifacts and check-only workflows, while the sample-size correction remained open. Taken together, the push date and concrete discussion show maintenance rather than a dormant prompt collection. They also show that important details remain open to correction.
Anthropic's skills repository suits someone who wants general examples to adapt. Superpowers is the closer choice when software development methodology is the main job. Pick PM Skills when product discovery and execution are the missing structure. Its 5-second install makes a trial inexpensive in our environment. Bring one unresolved customer assumption, supply the evidence, and judge whether the workflow improves the next experiment before trusting it with a launch decision.