Prd

Skill srg-sphynx/MDForge/Sources/MDForge/Resources/SkillLibrary/Product/prd

Native macOS skill-catalog studio for Claude Code — browse 1,492 Markdown skills, customize with variables or AI (hosted or local), export to .claude/skills. SwiftUI + Liquid Glass.

Install

npx -y skills add srg-sphynx/MDForge --skill prd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Gated PRD generation — interrogates problem, user, and metric before drafting; refuses to draft on unknowns. Usage: /prd <feature-or-problem>

SKILL.md

2.9 KB, as published. Nobody here has run it

/prd

Generate a concise, evidence-gated product requirements document for $ARGUMENTS.

Usage

/prd <feature-or-problem>

$ARGUMENTS is the feature, initiative, or problem statement. If empty, ask for it before doing anything else.

Phase 1 — Forcing Questions (before any drafting)

Walk these one at a time. Do not batch them. Each answer feeds a required PRD section.

Problem — What user problem does this solve, and how do you know it exists? (Evidence: support tickets, interview quotes, funnel data — "the CEO wants it" is not evidence.)
User — Who specifically has this problem? (Segment, role, frequency of pain. "Everyone" is a non-answer.)
Metric — What single number moves if this works, by how much, measured where?
Alternatives — What do these users do today instead? Why is that not good enough?
Non-goals — What adjacent asks are explicitly out of scope for v1?

Drafting Gate (hard refusal)

Refuse to draft the PRD if the answer to question 1 (problem), 2 (user), or 3 (metric) is unknown, circular, or "we'll figure it out later." Instead, output the open questions and the cheapest way to answer each (e.g., 5 customer interviews, a funnel query, a fake-door test). A PRD without a problem, a user, and a metric is a feature wish, not a requirements document.

Phase 2 — Draft (required-sections checklist)

Every PRD must contain all of these sections — emit the checklist at the end and mark each:

Problem statement (with the evidence from Q1)
Target user and segment (from Q2)
Goals and explicit non-goals (from Q5)
User stories with acceptance criteria
Success metric + threshold + measurement source (from Q3)
Alternatives considered / "do nothing" baseline (from Q4)
Scope, dependencies, and timeline assumptions
Open questions and risks

Keep it to ~2 pages. Use the repo template as the skeleton.

Phase 3 — Prioritization hook (optional)

If the user has multiple candidate features, offer to RICE-score them before committing the PRD:

python3 product-team/skills/product-manager-toolkit/scripts/rice_prioritizer.py features.csv --capacity 20

Repo Assets (verified paths)

Skill: product-team/skills/product-manager-toolkit/SKILL.md
PRD template: product-team/skills/product-manager-toolkit/assets/prd_template.md
PRD patterns reference: product-team/skills/product-manager-toolkit/references/prd_templates.md
RICE tool: product-team/skills/product-manager-toolkit/scripts/rice_prioritizer.py

/code-to-prd — reverse-engineer a PRD from an existing codebase
/rice — standalone RICE prioritization

Prd