# Create Prd

> Use when you're ready to define a feature before building it — generates a structured PRD using Jobs-to-be-Done thinking, success metrics, and explicit scope boundaries.

- Skill: `drvoss/create-prd` (Agent Skill)
- Install (CLI): `npx skillmds@latest add drvoss/create-prd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/drvoss/create-prd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: drvoss (https://skillmd.com/u/drvoss)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/drvoss/create-prd

---


# Create PRD

## When to Use

- Before starting a new feature — to align engineering, product, and stakeholders on scope
- When a GitHub Issue or Slack request needs formal requirements before implementation
- When writing a PRD from scratch for a feature you're about to build solo
- As a handoff document: from discovery → design → implementation
- When the current conversation already contains enough context to synthesize a first PRD draft

**Note**: This skill works best for well-scoped, single-feature PRDs. For large epics with
many sub-features, use this per sub-feature and link them together.

## Before You Write This PRD (Risk Gate)

Before formalizing requirements, briefly verify that the feature is worth building.
Skip this gate only when the build decision is already validated (e.g., a committed
roadmap item, a contractual requirement, or a P0 bug fix).

### Feature Demand Level Check

| Level | Signal | Action |
|-------|--------|--------|
| 0 | Founder/stakeholder anxiety — "competitors have it" or "feels incomplete" | Defer; validate first |
| 1 | One user request, no behavior proof | Validate before writing a PRD |
| 2 | Repeated requests from target users, no usage proof yet | Write a lightweight PRD; plan validation alongside it |
| 3 | Workflow blocker — users cannot complete the core job without it | Write the PRD and build |
| 4 | Revenue or retention blocker — users churn or refuse to pay without it | Write the PRD and build now |

**Proceed to a full PRD for Level 3 or Level 4.** For Level 0–2, start with the
smallest validation step (a buyer conversation, a landing page, a manual pilot) and
feed the findings into the PRD's Problem Statement and JTBD sections instead of
skipping straight to requirements.

### Minimum Risk Check (for Level 1–2)

Answer these before writing requirements:

- **Demand**: Is there evidence a specific user urgently needs this?
- **Switching reason**: What makes the current alternative insufficient?
- **Distribution**: Is there a repeatable way to reach the target user after launch?
- **Retention**: Is there a reason users would return after the first use?

If any answer is "unknown", record it in the PRD's **Open Questions** section and tag
it `needs-validation-before-implementation` rather than silently assuming a "yes".

## Prerequisites

- A feature idea, GitHub Issue, or user request to formalize
- Access to any existing context: user research, analytics, prior PRDs, or `CLAUDE.md`/`copilot-instructions.md`

## Workflow

### 1. Gather Context

If the current conversation, issue, or spec thread already contains enough information,
draft from that context first. Do **not** restart discovery from zero unless the missing
gaps would materially change scope.

Before writing, collect:

```powershell
# What does the product currently do?
Get-Content README.md | Select-Object -First 40
if (Test-Path .github/copilot-instructions.md) {
    Get-Content .github/copilot-instructions.md | Select-Object -First 50
}

# Any existing product docs?
Get-ChildItem -Recurse -Include "*.md" | Where-Object { $_.Name -match 'product|spec|prd|requirements' }

# Related GitHub issues
# Tool: github-mcp-server-search_issues
#   query: "feature-keyword in:title is:open"
#   owner: "my-org"
#   repo: "my-app"
```

### 2. Define the Job-to-be-Done (JTBD)

Before writing requirements, anchor in the user's actual goal:

```text
When [situation/trigger],
I want to [motivation],
So that I can [expected outcome].
```

Example:
> When I've finished coding a feature and want to commit,
> I want to automatically format my commit message to follow conventions,
> So that I can maintain a clean, readable git history without remembering the format.

### 3. Write the PRD

Use this template:

```markdown
# PRD: [Feature Name]

## Overview
One paragraph: what this feature does and why it matters.

## Problem Statement
What user pain point or business opportunity does this address?
Include data or quotes if available.

## Jobs-to-be-Done
**Primary JTBD:**
> When [situation], I want to [motivation], so that [outcome].

**Secondary JTBDs (optional):**
- ...

## Goals & Success Metrics
| Goal | Metric | Target |
|------|--------|--------|
| Reduce time to commit | Time from ready-to-commit to pushed | < 30 seconds |
| Adoption | % of commits using conventional format | > 80% after 30 days |

## Non-Goals (Out of Scope)
- Explicit list of what this does NOT include
- Helps prevent scope creep

## User Stories
### Must Have (P0)
- As a [user], I can [action] so that [benefit]
- As a [user], I can [action] so that [benefit]

### Should Have (P1)
- As a [user], I can [action] so that [benefit]

### Nice to Have (P2)
- As a [user], I can [action] so that [benefit]

## Functional Requirements
### Core Behavior
1. [Requirement] — [Acceptance criterion]
2. [Requirement] — [Acceptance criterion]

### Edge Cases
- [Edge case] → [Expected behavior]
- [Edge case] → [Expected behavior]

## Technical Constraints
- Platform: [e.g., Windows + macOS + Linux]
- Existing systems to integrate with: [e.g., GitHub MCP, git CLI]
- Performance: [e.g., < 2s response time]

## Open Questions
- [ ] [Question that needs decision before implementation]
- [ ] [Question that needs design input]

## Appendix
- Related issues: #123, #456
- Inspired by: [prior art, competitor feature, user research]
```

### 4. Save and Link

```powershell
# Save to docs directory or alongside issue
$featureName = "commit-workflow"
$prdPath = "docs/prd-$featureName.md"
# (Write the PRD content to file)

# Link from GitHub Issue (via comment or issue body update)
# gh issue comment 123 --body "PRD: docs/prd-$featureName.md"
```

If your workflow uses GitHub Issues as the system of record, link the PRD from the issue
or publish the summary there so implementation and triage can find it later.

## Examples

### Minimal PRD (Solo Developer)

For a solo project, a PRD can be much lighter:

```markdown
# PRD: Commit Workflow Skill

## What & Why
Add a skill that guides conventional commit message creation with emoji.
Developers lose time formatting commits manually; this automates the pattern.

## JTBD
When I'm ready to commit, I want auto-formatted conventional commit messages,
so that my git history is readable without manual effort.

## Must Have
- Emoji + type + scope + description format
- Atomic commit splitting guidance
- PowerShell code blocks for Windows compat

## Non-Goals
- Automatic commit (user still types `git commit -m`)
- Integration with GUI git clients
```

### PRD from GitHub Issue

```text
Issue #145: "Users can't tell which commits are breaking changes"

JTBD: When I'm reviewing git log, I want breaking changes visually distinct,
so that I can identify risky commits without reading every message.

Requirements:
- 💥 emoji + `!` suffix for breaking changes
- BREAKING CHANGE footer in body
- CI lint rule for enforcement
```

## Tips

- **Start with JTBD, not features**: features are solutions; jobs are the problems worth solving
- **Synthesize before interviewing again**: if the conversation already answers the key questions,
  produce the first draft and ask only targeted follow-ups for true unknowns
- **Non-goals are as important as goals**: they prevent scope creep during implementation
- **Acceptance criteria are testable**: "users can X" is not; "clicking Save triggers validation and shows error within 200ms" is
- **PRD ≠ design spec**: leave implementation details out; focus on *what*, not *how*
- **Link your PRD to the GitHub Issue**: keeps traceability from discovery → delivery

## See Also

- [`github-issue-triage`](../../copilot-exclusive/github-issue-triage/SKILL.md) — understand the issue backlog first
- [`fix-github-issue`](../../development/fix-github-issue/SKILL.md) — execute after PRD is approved
- *Inspired by: [awesome-claude-code/resources/slash-commands/create-prd](https://github.com/hesreallyhim/awesome-claude-code)*