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.
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
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/create-prd/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How create-prd Compares
| Feature / Agent | create-prd | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/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
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
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
triage
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
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
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
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
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
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
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
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
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
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.