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.

8 stars

Best use case

create-prd is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

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.

Teams using create-prd should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/create-prd/SKILL.md --create-dirs "https://raw.githubusercontent.com/drvoss/everything-copilot-cli/main/skills/product/create-prd/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/create-prd/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How create-prd Compares

Feature / Agentcreate-prdStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

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.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 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.

## 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)*

Related Skills

verification-before-completion

8
from drvoss/everything-copilot-cli

Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.

using-git-worktrees

8
from drvoss/everything-copilot-cli

Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly

triage

8
from drvoss/everything-copilot-cli

Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.

to-issues

8
from drvoss/everything-copilot-cli

Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice

sprint-workflow

8
from drvoss/everything-copilot-cli

Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.

sprint-retro

8
from drvoss/everything-copilot-cli

Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.

security-audit

8
from drvoss/everything-copilot-cli

Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.

release

8
from drvoss/everything-copilot-cli

Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.

prompt-optimizer

8
from drvoss/everything-copilot-cli

Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.

outside-voice

8
from drvoss/everything-copilot-cli

Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice

llm-wiki

8
from drvoss/everything-copilot-cli

Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance

interview-me

8
from drvoss/everything-copilot-cli

Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.