How do I install the Prd skill?

Run npx skillmds@latest add rawgroundbeef/prd in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Prd?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

rawgroundbeef (@rawgroundbeef) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Prd by rawgroundbeef — Agent Skill

Name: Prd
Author: rawgroundbeef

Prd

Create a PRD through user interview, codebase exploration, and module design, then output as a markdown file. Use when user wants to write a PRD, create a product requirements document, plan a new feature, or scope out work before implementation. Triggers on "write a prd", "create a prd", "let's plan this feature", "scope this out", "product requirements", or any request to formalize feature planning into a document.

rawgroundbeef 4a8d89d 2 files · 4.1 KB Updated Sep 17, 2026

File contents

PRD Skill

Turn conversation context and codebase understanding into a PRD markdown file.

Process

Step 1: Understand the Feature

Synthesize what you already know from the conversation. If context is thin, ask the user 3-5 focused questions:

What problem does this solve?
Who is the user?
What does success look like?
Any constraints or non-negotiables?
What's explicitly out of scope?

Don't over-interview. If the conversation already covers these, move on.

Step 2: Explore the Codebase

Explore the repo to understand the current state relevant to the feature. Look for:

Existing patterns and conventions
Models, services, and views that will be touched
API contracts already in place
How similar features were built

Step 3: Sketch Modules

Identify the major modules to build or modify. Favor deep modules — ones that encapsulate significant functionality behind a simple interface.

Present the module sketch to the user and confirm before writing the full PRD. Keep it brief:

Here's what I'm thinking:
1. GifPicker — Tenor/Giphy API integration, search + trending
2. Post model — add gif_url field
3. Feed rendering — animate GIFs inline
4. Compose UI — GIF button + picker sheet

Does this match your thinking?

Step 4: Write the PRD

Write the PRD to prd-{feature-name}.md in the project root. Use kebab-case for the filename.

PRD Template

ALWAYS use this exact structure:

# PRD: {Feature Name}

**Date:** {YYYY-MM-DD}
**Status:** Draft

## Problem Statement

The problem from the user's perspective. Why does this matter?

## Solution

The solution from the user's perspective. What will they experience?

## User Stories

Extensive numbered list. Each story follows:

> As a {actor}, I want {feature}, so that {benefit}

Cover the happy path, edge cases, error states, and accessibility. Be thorough — 10-20 stories minimum.

## Implementation Decisions

Decisions about how to build it:

- Modules to build or modify
- Architecture and data flow
- Schema changes
- API contracts
- External service integrations
- Key technical choices and their rationale

Do NOT include specific file paths or code snippets — they go stale fast.

## Testing Decisions

- What makes a good test for this feature
- Which modules need tests
- Integration vs unit test balance
- Any existing test patterns to follow

## Out of Scope

What this PRD explicitly does NOT cover. Be specific — this prevents scope creep.

## Open Questions

Unresolved decisions that need input before or during implementation.

Writing Tips

User stories are the heart of the PRD. Make them extensive and specific.
Implementation decisions should explain why, not just what.
Out of scope is as important as in scope — it sets boundaries.
Open questions are OK. Better to flag unknowns than to guess.
No file paths or code in the PRD. It's a planning doc, not a spec.

---name: prddescription: Create a PRD through user interview, codebase exploration, and module design, then output as a markdown file. Use when user wants to write a PRD, create a product requirements document, plan a new feature, or scope out work before implementation. Triggers on "write a prd", "create a prd", "let's plan this feature", "scope this out", "product requirements", or any request to formalize feature planning into a document.---# PRD SkillTurn conversation context and codebase understanding into a PRD markdown file.## Process### Step 1: Understand the FeatureSynthesize what you already know from the conversation. If context is thin, ask the user 3-5 focused questions:- What problem does this solve?- Who is the user?- What does success look like?- Any constraints or non-negotiables?- What's explicitly out of scope?Don't over-interview. If the conversation already covers these, move on.### Step 2: Explore the CodebaseExplore the repo to understand the current state relevant to the feature. Look for:- Existing patterns and conventions- Models, services, and views that will be touched- API contracts already in place- How similar features were built### Step 3: Sketch ModulesIdentify the major modules to build or modify. Favor deep modules — ones that encapsulate significant functionality behind a simple interface.Present the module sketch to the user and confirm before writing the full PRD. Keep it brief:```Here's what I'm thinking:1. GifPicker — Tenor/Giphy API integration, search + trending2. Post model — add gif_url field3. Feed rendering — animate GIFs inline4. Compose UI — GIF button + picker sheetDoes this match your thinking?```### Step 4: Write the PRDWrite the PRD to `prd-{feature-name}.md` in the project root. Use kebab-case for the filename.## PRD TemplateALWAYS use this exact structure:```markdown# PRD: {Feature Name}**Date:** {YYYY-MM-DD}**Status:** Draft## Problem StatementThe problem from the user's perspective. Why does this matter?## SolutionThe solution from the user's perspective. What will they experience?## User StoriesExtensive numbered list. Each story follows:> As a {actor}, I want {feature}, so that {benefit}Cover the happy path, edge cases, error states, and accessibility. Be thorough — 10-20 stories minimum.## Implementation DecisionsDecisions about how to build it:- Modules to build or modify- Architecture and data flow- Schema changes- API contracts- External service integrations- Key technical choices and their rationaleDo NOT include specific file paths or code snippets — they go stale fast.## Testing Decisions- What makes a good test for this feature- Which modules need tests- Integration vs unit test balance- Any existing test patterns to follow## Out of ScopeWhat this PRD explicitly does NOT cover. Be specific — this prevents scope creep.## Open QuestionsUnresolved decisions that need input before or during implementation.```### Writing Tips- User stories are the heart of the PRD. Make them extensive and specific.- Implementation decisions should explain **why**, not just **what**.- Out of scope is as important as in scope — it sets boundaries.- Open questions are OK. Better to flag unknowns than to guess.- No file paths or code in the PRD. It's a planning doc, not a spec.

Frequently asked questions

Prd