Agent skill

Prp Prd

by Wirasm in Wirasm/prp

Interactive PRD generator - problem-first, hypothesis-driven product spec.

MITAuto-check passedProduct & Project Management

Install Prp Prd

skills CLI
$ npx skills add Wirasm/prp --skill prp-prd -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Wirasm/prp prp-prd --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Wirasm/prp.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/prp-prd .claude/skills/prp-prd && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
prp-prd
GitHub stars
2.3k
Token cost
~3.5k tokens
SKILL.md length
637 words
Files
1
Skills in repo
37
Repo updated
First seen
Licence
MIT

At a glance

Interactive PRD generator - problem-first, hypothesis-driven product spec.

  • Works in 8 steps: INITIATE - Core Problem → FOUNDATION - Problem Discovery → GROUNDING - Market & Context Research → …
  • The user wants to create a PRD
  • SKILL.md covers Your Role, Process Overview, Phase 1: INITIATE - Core Problem and Phase 2: FOUNDATION - Problem…, plus 8 more sections
  • Calls git

What it does

Prp Prd is an agent skill from Wirasm/prp. Interactive PRD generator - problem-first, hypothesis-driven product spec. Use when the user wants to create a PRD, write a product or feature spec, scope a new product, or invokes $prp-prd.

Its SKILL.md is about 3.5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Product & Project Management, covering PRD writing. The repository describes itself as: Prompts, workflows and more for agentic engineering. The licence is MIT.

When your agent uses it

  • The user wants to create a PRD
  • Write a product
  • Scope a new product
  • Invokes $prp-prd

Example prompts

  • “/prp-prd”

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. INITIATE - Core Problem
  2. FOUNDATION - Problem Discovery
  3. GROUNDING - Market & Context Research
  4. DEEP DIVE - Vision & Users
  5. GROUNDING - Technical Feasibility
  6. DECISIONS - Scope & Approach
  7. GENERATE - Write PRD
  8. OUTPUT - Summary

What it can do on your machine

Read from SKILL.md and the folder at commit 4352925. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Prp Prd loads about 3.5k tokens when it runs. Until then it costs about 50 tokens; SKILL.md has 637 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~50
When it runs · the whole SKILL.md, loaded when a task matches
~3.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Wirasm/prp at commit 4352925, republished under its MIT licence (© Wirasm). 637 words, ~3,477 tokens.

Download SKILL.mdSave it as .claude/skills/prp-prd/SKILL.md (or your agent's skills folder).
name
prp-prd
description
Interactive PRD generator - problem-first, hypothesis-driven product spec. Use when the user wants to create a PRD, write a product or feature spec, scope a new product, or invokes $prp-prd.

Arguments: $ARGUMENTS (and $1, $2, ...) refer to the arguments given when this skill was invoked. Take them from the user's request; if absent, infer them from the conversation.

Product Requirements Document Generator

Input: $ARGUMENTS


Your Role

You are a sharp product manager who:

  • Starts with PROBLEMS, not solutions
  • Demands evidence before building
  • Thinks in hypotheses, not specs
  • Asks clarifying questions before assuming
  • Acknowledges uncertainty honestly

Anti-pattern: Don't fill sections with fluff. If info is missing, write "TBD - needs research" rather than inventing plausible-sounding requirements.


Process Overview

QUESTION SET 1 → GROUNDING → QUESTION SET 2 → RESEARCH → QUESTION SET 3 → GENERATE

Each question set builds on previous answers. Grounding phases validate assumptions.


Phase 1: INITIATE - Core Problem

If no input provided, ask:

What do you want to build? Describe the product, feature, or capability in a few sentences.

If input provided, confirm understanding by restating:

I understand you want to build: {restated understanding} Is this correct, or should I adjust my understanding?

GATE: Wait for user response before proceeding.


Phase 2: FOUNDATION - Problem Discovery

Ask these questions (present all at once, user can answer together):

Foundation Questions:

  1. Who has this problem? Be specific - not just "users" but what type of person/role?

  2. What problem are they facing? Describe the observable pain, not the assumed need.

  3. Why can't they solve it today? What alternatives exist and why do they fail?

  4. Why now? What changed that makes this worth building?

  5. How will you know if you solved it? What would success look like?

GATE: Wait for user responses before proceeding.


Phase 3: GROUNDING - Market & Context Research

After foundation answers, conduct research using specialized agents:

Spawn the web-researcher subagent:

Research the market context for: {product/feature idea}

FIND:
1. Similar products/features in the market
2. How competitors solve this problem
3. Common patterns and anti-patterns
4. Recent trends or changes in this space

Return findings with direct links, key insights, and any gaps in available information.

If codebase exists, spawn the codebase-explorer subagent:

Find existing functionality relevant to: {product/feature idea}

LOCATE:
1. Related existing functionality
2. Patterns that could be leveraged
3. Technical constraints or opportunities

Return file locations, code patterns, and conventions observed.

Summarize findings to user:

What I found:

  • {Market insight 1}
  • {Competitor approach}
  • {Relevant pattern from codebase, if applicable}

Does this change or refine your thinking?

GATE: Brief pause for user input (can be "continue" or adjustments).


Phase 4: DEEP DIVE - Vision & Users

Based on foundation + research, ask:

Vision & Users:

  1. Vision: In one sentence, what's the ideal end state if this succeeds wildly?

  2. Primary User: Describe your most important user - their role, context, and what triggers their need.

  3. Job to Be Done: Complete this: "When [situation], I want to [motivation], so I can [outcome]."

  4. Non-Users: Who is explicitly NOT the target? Who should we ignore?

  5. Constraints: What limitations exist? (time, budget, technical, regulatory)

GATE: Wait for user responses before proceeding.


Show full SKILL.md (241 more words)Show less

Phase 5: GROUNDING - Technical Feasibility

If codebase exists, launch two agents in parallel:

Spawn the codebase-explorer subagent:

Assess technical feasibility for: {product/feature}

LOCATE:
1. Existing infrastructure we can leverage
2. Similar patterns already implemented
3. Integration points and dependencies
4. Relevant configuration and type definitions

Return file locations, code patterns, and conventions observed.

Spawn the codebase-analyst subagent:

Analyze technical constraints for: {product/feature}

TRACE:
1. How existing related features are implemented end-to-end
2. Data flow through potential integration points
3. Architectural patterns and boundaries
4. Estimated complexity based on similar features

Document what exists with precise file:line references. No suggestions.

If no codebase, spawn the web-researcher subagent:

Research technical approaches for: {product/feature}

FIND:
1. Technical approaches others have used
2. Common implementation patterns
3. Known technical challenges and pitfalls

Return findings with citations and gap analysis.

Summarize to user:

Technical Context:

  • Feasibility: {HIGH/MEDIUM/LOW} because {reason}
  • Can leverage: {existing patterns/infrastructure}
  • Key technical risk: {main concern}

Any technical constraints I should know about?

GATE: Brief pause for user input.


Phase 6: DECISIONS - Scope & Approach

Ask final clarifying questions:

Scope & Approach:

  1. MVP Definition: What's the absolute minimum to test if this works?

  2. Must Have vs Nice to Have: What 2-3 things MUST be in v1? What can wait?

  3. Key Hypothesis: Complete this: "We believe [capability] will [solve problem] for [users]. We'll know we're right when [measurable outcome]."

  4. Out of Scope: What are you explicitly NOT building (even if users ask)?

  5. Open Questions: What uncertainties could change the approach?

GATE: Wait for user responses before generating.


Phase 7: GENERATE - Write PRD

Use plain, specific language and the product's actual terms. Cut filler, invented jargon, generic claims, and formulaic phrasing.

bash
# --- PRP store resolver (canonical; keep byte-identical across skills) ---
# Adopt the store that already records this root; mint a key only when none does.
_gd="$(git rev-parse --path-format=absolute --git-common-dir 2>/dev/null)"
case "$_gd" in */.git) _root="${_gd%/.git}" ;; "") _root="$PWD" ;; *) _root="$_gd" ;; esac
_root="$(cd "$_root" && pwd -P)"
_name="$(basename "$_root" | tr '[:upper:]' '[:lower:]' | tr -cs 'a-z0-9' '-' | sed 's/^-*//;s/-*$//')"
_home="${PRP_HOME:-$HOME/.prp}"
_hit="$(grep -lsF "\"path\": \"$_root\"" "$_home"/*/project.json 2>/dev/null | head -1)"
PRP_DIR="${_hit%/project.json}"
[ -n "$PRP_DIR" ] || PRP_DIR="$_home/${_name:-project}-$(printf %s "$_root" | git hash-object --stdin | cut -c1-8)"
mkdir -p "$PRP_DIR"; [ -f "$PRP_DIR/project.json" ] || printf '{"path": "%s", "name": "%s"}\n' "$_root" "${_name:-project}" > "$PRP_DIR/project.json"

Output path: $PRP_DIR/prds/{kebab-case-name}.prd.md

Create directory if needed: mkdir -p "$PRP_DIR/prds"

PRD Template
markdown
# {Product/Feature Name}

## Problem Statement

{2-3 sentences: Who has what problem, and what's the cost of not solving it?}

## Evidence

- {User quote, data point, or observation that proves this problem exists}
- {Another piece of evidence}
- {If none: "Assumption - needs validation through [method]"}

## Proposed Solution

{One paragraph: What we're building and why this approach over alternatives}

## Key Hypothesis

We believe {capability} will {solve problem} for {users}.
We'll know we're right when {measurable outcome}.

## What We're NOT Building

- {Out of scope item 1} - {why}
- {Out of scope item 2} - {why}

## Success Metrics

| Metric | Target | How Measured |
|--------|--------|--------------|
| {Primary metric} | {Specific number} | {Method} |
| {Secondary metric} | {Specific number} | {Method} |

## Open Questions

- [ ] {Unresolved question 1}
- [ ] {Unresolved question 2}

---

## Users & Context

**Primary User**
- **Who**: {Specific description}
- **Current behavior**: {What they do today}
- **Trigger**: {What moment triggers the need}
- **Success state**: {What "done" looks like}

**Job to Be Done**
When {situation}, I want to {motivation}, so I can {outcome}.

**Non-Users**
{Who this is NOT for and why}

---

## Solution Detail

### Core Capabilities (MoSCoW)

| Priority | Capability | Rationale |
|----------|------------|-----------|
| Must | {Feature} | {Why essential} |
| Must | {Feature} | {Why essential} |
| Should | {Feature} | {Why important but not blocking} |
| Could | {Feature} | {Nice to have} |
| Won't | {Feature} | {Explicitly deferred and why} |

### MVP Scope

{What's the minimum to validate the hypothesis}

### User Flow

{Critical path - shortest journey to value}

---

## Technical Approach

**Feasibility**: {HIGH/MEDIUM/LOW}

**Architecture Notes**
- {Key technical decision and why}
- {Dependency or integration point}

**Technical Risks**

| Risk | Likelihood | Mitigation |
|------|------------|------------|
| {Risk} | {H/M/L} | {How to handle} |

---

## Implementation Phases

<!--
  STATUS: pending | in-progress | complete
  PARALLEL: phases that can run concurrently (e.g., "with 3" or "-")
  DEPENDS: phases that must complete first (e.g., "1, 2" or "-")
  PLAN: link to generated plan file once created
  REPORT: link to the implementation report once implemented
  PR: link to the pull request once opened
-->

| # | Phase | Description | Status | Parallel | Depends | Plan | Report | PR |
|---|-------|-------------|--------|----------|---------|------|--------|----|
| 1 | {Phase name} | {What this phase delivers} | pending | - | - | - | - | - |
| 2 | {Phase name} | {What this phase delivers} | pending | - | 1 | - | - | - |
| 3 | {Phase name} | {What this phase delivers} | pending | with 4 | 2 | - | - | - |
| 4 | {Phase name} | {What this phase delivers} | pending | with 3 | 2 | - | - | - |
| 5 | {Phase name} | {What this phase delivers} | pending | - | 3, 4 | - | - | - |

### Phase Details

**Phase 1: {Name}**
- **Goal**: {What we're trying to achieve}
- **Scope**: {Bounded deliverables}
- **Success signal**: {How we know it's done}

**Phase 2: {Name}**
- **Goal**: {What we're trying to achieve}
- **Scope**: {Bounded deliverables}
- **Success signal**: {How we know it's done}

{Continue for each phase...}

### Parallelism Notes

{Explain which phases can run in parallel and why, e.g., "Phases 3 and 4 can run in parallel in separate worktrees as they touch different domains (frontend vs auth)"}

---

## Decisions Log

| Decision | Choice | Alternatives | Rationale |
|----------|--------|--------------|-----------|
| {Decision} | {Choice} | {Options considered} | {Why this one} |

---

## Research Summary

**Market Context**
{Key findings from market research}

**Technical Context**
{Key findings from technical exploration}

---

*Generated: {timestamp}*
*Status: DRAFT - needs validation*

Phase 8: OUTPUT - Summary

After generating, report:

markdown
## PRD Created

**File**: `{expanded absolute path to $PRP_DIR/prds/{name}.prd.md}`

### Summary

**Problem**: {One line}
**Solution**: {One line}
**Key Metric**: {Primary success metric}

### Validation Status

| Section | Status |
|---------|--------|
| Problem Statement | {Validated/Assumption} |
| User Research | {Done/Needed} |
| Technical Feasibility | {Assessed/TBD} |
| Success Metrics | {Defined/Needs refinement} |

### Open Questions ({count})

{List the open questions that need answers}

### Recommended Next Step

{One of: user research, technical spike, prototype, stakeholder review, etc.}

### Implementation Phases

| # | Phase | Status | Can Parallel |
|---|-------|--------|--------------|
{Table of phases from PRD}

### To Start Implementation

Run: `$prp-plan {expanded absolute path to $PRP_DIR/prds/{name}.prd.md}`

This will automatically select the next pending phase and create an implementation plan.

Question Flow Summary

┌─────────────────────────────────────────────────────────┐
│  INITIATE: "What do you want to build?"                 │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  FOUNDATION: Who, What, Why, Why now, How to measure    │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  GROUNDING: Market research, competitor analysis        │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  DEEP DIVE: Vision, Primary user, JTBD, Constraints     │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  GROUNDING: Technical feasibility, codebase exploration │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  DECISIONS: MVP, Must-haves, Hypothesis, Out of scope   │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  GENERATE: Write PRD to $PRP_DIR/prds/                  │
└─────────────────────────────────────────────────────────┘

Success Criteria

  • PROBLEM_VALIDATED: Problem is specific and evidenced (or marked as assumption)
  • USER_DEFINED: Primary user is concrete, not generic
  • HYPOTHESIS_CLEAR: Testable hypothesis with measurable outcome
  • SCOPE_BOUNDED: Clear must-haves and explicit out-of-scope
  • QUESTIONS_ACKNOWLEDGED: Uncertainties are listed, not hidden
  • ACTIONABLE: A skeptic could understand why this is worth building

© Wirasm, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/prp-prd of Wirasm/prp.

Open the folder on GitHubat commit 4352925

Compare with similar skills

Prp Prd next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Prp Prd compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Prp Prd this skillWirasm/prp2.3k—~3.5kAutomated safety check: PassMIT
CCPM Project Managementautomazeio/ccpm8.4k—~1.1kAutomated safety check: PassMIT
Ralph Tui Create Beadssubsy/ralph-tui2.5k1 repos~2.6kAutomated safety check: PassMIT
Trellis Brainstormanjiemo/SunnyBeach1787 repos~4kAutomated safety check: PassApache-2.0
Adversarial Speczscole/adversarial-spec5561 repos~8.3kAutomated safety check: NotesMIT
Ralph Tui Create Beads Rustsubsy/ralph-tui2.5k1 repos~2.8kAutomated safety check: PassMIT

Similar skills

  • Runs a spec-driven workflow from PRD to epic to GitHub issues to parallel agents, with status, standup and blocked-work reports from bundled scripts.

    8.4k GitHub stars~1.1k tokensUpdated 6 mo ago
    Product & Project ManagementAuto-check passed
  • Ralph Tui Create Beads

    subsy/ralph-tui

    Convert PRDs to beads for ralph-tui execution. An agent skill from subsy/ralph-tui.

    2.5k GitHub starsUsed in 1 repo~2.6k tokens
    Product & Project ManagementAuto-check passed
  • Trellis Brainstorm

    anjiemo/SunnyBeach

    Guides collaborative requirements discovery before implementation.

    178 GitHub starsUsed in 7 repos~4k tokens
    Product & Project ManagementAuto-check passed
  • Adversarial Spec

    zscole/adversarial-spec

    Iteratively refine a product spec by debating with multiple LLMs (GPT, Gemini, Grok, etc.) until all models agree.

    556 GitHub starsUsed in 1 repo~8.3k tokens
    Product & Project ManagementAuto-check: notes
  • Convert PRDs to beads for ralph-tui execution using beads-rust (br CLI).

    2.5k GitHub starsUsed in 1 repo~2.8k tokens
    Product & Project ManagementAuto-check passed
  • To Issues

    ywwynm/EverythingDone

    Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.

    144 GitHub starsUsed in 12 repos~893 tokens
    Product & Project ManagementAuto-check passed

More from Wirasm/prp

All 37 skills in this repo
  • PRP Loop

    Wirasm/prp

    Runs the plan, implement and review pipeline detached in fresh headless sessions, looping review and fix until the pull request is clean.

    2.3k GitHub stars~894 tokensUpdated 5 days ago
    Auto-check passed
  • Runs a detached, resumable loop that plans, implements, opens a PR, reviews and fixes a feature across headless CLI sessions until the review is clean.

    2.3k GitHub stars~863 tokensUpdated 5 days ago
    Auto-check passed
  • Coordinates several PRP workstreams in isolated Git worktrees from one session, verifying proof, holding merge gates and sequencing the merges.

    2.3k GitHub stars~3.5k tokensUpdated 5 days ago
    Auto-check passed
  • Turns a PRD, issue or description into an implementation-ready plan grounded in codebase evidence, adding root-cause analysis for bugs and publishing issue plans back to the issue.

    2.3k GitHub stars~4.1k tokensUpdated 5 days ago
    Auto-check passed
  • PRP Plan

    Wirasm/prp

    Writes an implementation-ready plan for a feature, bug fix, refactor or chore from a PRD, issue or description, grounded in codebase evidence, and can post it back to the source issue.

    2.3k GitHub stars~4k tokensUpdated 5 days ago
    Auto-check passed
  • PRP Spike

    Wirasm/prp

    Settles a feasibility question with the smallest throwaway build that could disprove it, in an isolated worktree, ending in a verdict backed by evidence instead of a PR.

    2.3k GitHub stars~3.8k tokensUpdated 5 days ago
    Auto-check passed

Questions about Prp Prd

What does Prp Prd do?

Interactive PRD generator - problem-first, hypothesis-driven product spec. Prp Prd is an agent skill from Wirasm/prp. Interactive PRD generator - problem-first, hypothesis-driven product spec.

When should I use Prp Prd?

Prp Prd fits situations like: the user wants to create a PRD; write a product; scope a new product; invokes $prp-prd.

How do I install Prp Prd in Claude Code?

Run `npx skills add Wirasm/prp --skill prp-prd -a claude-code`. Or copy the skill folder (.agents/skills/prp-prd in Wirasm/prp) into .claude/skills/prp-prd in your project. Claude Code loads it when a task matches its description.

How do I install Prp Prd in Codex?

Run `npx skills add Wirasm/prp --skill prp-prd -a codex`. Or copy the skill folder (.agents/skills/prp-prd in Wirasm/prp) into .agents/skills/prp-prd in your project. Codex loads it when a task matches its description.

Can I use Prp Prd in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Wirasm/prp --skill prp-prd -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/prp-prd, .gemini/skills/prp-prd, .github/skills/prp-prd and .opencode/skills/prp-prd in your project.

What does Prp Prd need to run?

Going by SKILL.md and its folder, Prp Prd needs the command-line tools its instructions call (git).

Does Prp Prd access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Prp Prd safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Prp Prd use?

Prp Prd is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Prp Prd use?

About 3.5k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Prp Prd?

Skills that share tags, products or a category with Prp Prd: CCPM Project Management (automazeio/ccpm, 8.4k stars), Ralph Tui Create Beads (subsy/ralph-tui, 2.5k stars), Trellis Brainstorm (anjiemo/SunnyBeach, 178 stars) and Adversarial Spec (zscole/adversarial-spec, 556 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Prp Prd?

Wirasm (a GitHub user) maintains it in Wirasm/prp, which has 2,258 GitHub stars. The repository holds 37 skills in this directory. The repository was last updated on October 2, 2026.

Source: Wirasm/prp on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.