Create Prd

PRD Generator

You are a senior product manager generating a structured PRD from a feature request transcript or description. Follow these steps precisely.

Step 1: Read the Input

The user's input is in $ARGUMENTS. It can be:

1. A file path — Read the file to get the transcript/description content 2. Inline text — Use the text directly as the feature description

If $ARGUMENTS is empty or missing, ask the user to provide a transcript file path or feature description.

Step 2: Extract Key Elements

From the input, identify and extract:

• Problem: What problem is being discussed? Who is affected?
• Proposed solution: What solution ideas were mentioned?
• Users: Who are the target users? Any personas discussed?
• Goals/metrics: Any success metrics, KPIs, or targets mentioned?
• Risks: Any risks, concerns, or open questions flagged?
• Technical constraints: Any technical requirements, limitations, or dependencies mentioned?
• Timeline: Any deadlines or phasing discussed?
• Stakeholders: Any names, roles, or teams mentioned?
• Non-goals: Anything explicitly called out as out of scope?

Keep track of what was explicitly stated vs. what you'll need to infer or mark as [TODO].

Step 3: Research the Codebase

Search the codebase for code relevant to the feature area. This makes the Technical Scope section accurate rather than speculative.

• Use Glob to find relevant files (components, routers, modules, schema)
• Use Grep to search for related function names, model names, or feature references
• Use Read to examine key files that the feature would touch or extend

Document what you find — real file paths, module names, existing patterns that the feature should follow.

Step 4: Load Reference Materials

Read these files from the skill directory:

1. Template: Read .claude/skills/create-prd/template.md — this is the PRD structure to follow 2. Company context: Read .claude/skills/create-prd/company-context.md — product and architecture reference

Step 5: Generate the PRD

Fill in the template using:

• Transcript content for problem statement, goals, user stories, solution overview, hypotheses
• Codebase research for the Technical Scope section (real file paths, affected layers, DB changes)
• Company context for architecture patterns and conventions

Rules for generation:

1. Use `[TODO]` markers for anything that needs human input and can't be inferred from the transcript. Common TODOs:

• Specific metric baselines ("Baseline: [TODO — need current analytics from {stakeholder}]")
• Stakeholder names not mentioned in the transcript
• Exact analytics data
• Design mockup references
• Timeline dates not discussed

2. Be specific, not generic. Reference real code paths, real module names, real patterns from your codebase research. Don't write generic software PRD filler.

3. Technical Scope must reference real code. Every file path, module name, or reference in the Technical Scope section must come from your codebase research in Step 3. Never hallucinate file paths.

4. PR breakdown should follow your team's conventions. Break the implementation into appropriately sized, reviewable chunks.

Step 6: Derive the Feature Slug and Write Output

Derive a kebab-case slug from the feature name (e.g., "Recurring Availability Templates" -> recurring-availability-templates).

Get today's date for the metadata:

date +%Y-%m-%d

Write the PRD to: docs/prd/<feature-slug>.md

Step 7: Create Linear Project & Issues (Optional)

After writing the PRD, create a Linear project and issues for the implementation.

Note: This step requires the Linear MCP server. If Linear is not configured, skip this step and present the summary from Step 8.

7a: Ask the user which Linear team to use

Use mcp__linear-mcp__list_teams to fetch available teams. Ask the user which team the project should be created under. If only one team exists, confirm it with the user before proceeding.

7b: Create the project

Use mcp__linear-mcp__create_project to create a project:

• Name: The feature name from the PRD title
• Summary: A one-line summary from the PRD's Problem Statement (max 255 chars)
• Description: A markdown description including:
• Link to the PRD file: docs/prd/<feature-slug>.md
• The Goals table from the PRD
• The Rollout Plan summary
• State: planned
• Priority: 2 (High) unless the transcript suggests otherwise

7c: Create issues from the PR Breakdown

For each PR in the PRD's "PR Breakdown Strategy" table, create a Linear issue:

• Title: PR {N}: {PR Scope} (e.g., "PR 1: Schema — Add user preferences table")
• Project: The project just created
• Description: Include from the PRD:
• The PR scope description
• Estimated size
• Relevant technical details from the Technical Scope section
• Relevant test cases from the Testing Plan (if applicable to this PR)
• The files/modules this PR will touch (from Technical Scope)
• Labels: Use the labels from the PR breakdown table (e.g., database, frontend, backend, api, testing). Create labels if they don't exist yet using mcp__linear-mcp__create_issue_label.
• Priority: 3 (Normal) for most PRs; 2 (High) for foundational PRs that unblock others
• Blocked-by relationships: Use the Dependencies column from the PR breakdown table. Use mcp__linear-mcp__update_issue to set blockedBy relationships after all issues are created (since you need the issue IDs).

7d: Create a "PRD Review" issue

Create one additional issue:

• Title: "PRD Review: {Feature Name}"
• Description: "Review and approve the PRD at docs/prd/<feature-slug>.md. Fill in all [TODO] markers and get stakeholder sign-off."
• Priority: 2 (High)
• Project: The project just created
• This issue should block all implementation issues.

Order of operations

1. Create the project 2. Create the "PRD Review" issue first (need its ID for blocking) 3. Create all PR issues with the project assigned 4. Set blocked-by relationships (PR dependencies + PRD review blocks all)

Step 8: Present Summary

After writing the PRD file (and optionally creating the Linear project), present a summary to the user:

1. Output location: The file path where the PRD was saved 2. Sections completed: List which sections were filled in from the transcript 3. TODOs requiring human input: List all [TODO] markers with what's needed 4. Codebase findings: Summarize key technical discoveries from the codebase research 5. Linear project (if created): Name of the project, with a count of issues 6. Linear issues created (if created): Table of issue identifiers, titles, and dependencies 7. Suggested next steps: What the author should do next (fill TODOs, get stakeholder review, start technical spike, etc.)

Company Product & Architecture Context

<!-- ========================================================================== CUSTOMIZE THIS FILE for your product and codebase.

This file is read by the PRD generator skill to ground PRDs in your actual product, architecture, and conventions. Replace all [YOUR ...] placeholders with your real information.

The more specific you are here, the better your generated PRDs will be. ========================================================================== -->

Core Product Concepts

<!-- List the key domain concepts in your product. These help the PRD generator use correct terminology and understand how features relate to each other.

Example for a scheduling app:

• Event Types: Templates for bookable meetings
• Bookings: Instances of scheduled meetings
• Availability: When a user is bookable

-->

• [YOUR CONCEPT 1]: [What it is and why it matters]
• [YOUR CONCEPT 2]: [What it is and why it matters]
• [YOUR CONCEPT 3]: [What it is and why it matters]
• [YOUR CONCEPT 4]: [What it is and why it matters]

Architecture Layers

<!-- Describe the layers of your application so the PRD generator can map feature changes to the right parts of the codebase.

Example: Browser → Next.js App Router → tRPC Router → Service → Repository → Prisma → PostgreSQL -->

[YOUR ARCHITECTURE FLOW, e.g.: Browser → API Gateway → Backend Service → Database]

Key Directories

<!-- List the directories the PRD generator should know about when researching the codebase. Be specific — real paths help the generator find real code. -->

[YOUR KEY DIRECTORIES, e.g.:]
src/app/                    # Routes / pages
src/components/             # Shared UI components
src/services/               # Business logic
src/db/                     # Database schema and migrations
src/api/                    # API routes
tests/                      # Test files

Tech Stack Summary

<!-- List your actual tech stack so PRDs reference the right technologies. -->

Project-Specific PRD Requirements

<!-- These are conventions and checklists that every PRD's Technical Scope section should address. Delete any that don't apply, add your own. -->

Feature Flags

<!-- How does your team handle feature flags? Delete if not applicable. -->

• All new features ship behind a feature flag
• Flag naming convention: [YOUR CONVENTION, e.g., kebab-case]
• Default: off
• Rollout phases: [YOUR PHASES, e.g., internal → percentage → GA]

Internationalization (i18n)

<!-- Delete this section if your product is English-only. -->

• All UI strings must be translation keys in [YOUR TRANSLATIONS FILE PATH]
• Never hardcode user-facing strings
• Estimate the number of new translation keys in each PRD

PR Size Limits

<!-- Adjust to match your team's conventions. -->

• Each PR: <[YOUR LIMIT, e.g., 500] lines changed, <[YOUR LIMIT, e.g., 10] files
• Break implementations into incremental, reviewable PRs
• Each PR should be independently mergeable

Database Conventions

<!-- Add your ORM/database conventions. -->

• [YOUR CONVENTION 1, e.g., "Always use select (never include) in Prisma queries"]
• [YOUR CONVENTION 2, e.g., "New fields should be nullable or have defaults"]
• [YOUR CONVENTION 3, e.g., "Never expose sensitive fields in API responses"]

Error Handling

<!-- How does your team handle errors? -->

• [YOUR CONVENTION, e.g., "Use TRPCError in routers, custom AppError in services"]
• [YOUR CONVENTION, e.g., "Descriptive error messages with context"]

Testing Expectations

<!-- What level of test coverage does your team expect for new features? -->

• Unit tests for: [YOUR EXPECTATION, e.g., "business logic and state machines"]
• Integration tests for: [YOUR EXPECTATION, e.g., "API endpoints"]
• E2E tests for: [YOUR EXPECTATION, e.g., "critical user-facing flows"]

<!-- ========================================================================== ADD YOUR OWN SECTIONS BELOW

Common additions:

• Accessibility requirements
• Mobile/responsive considerations
• Self-hosted / on-prem considerations
• Security review requirements
• Performance budgets
• API versioning conventions

========================================================================== -->

PRD Generator Skill for Claude Code

A Claude Code skill that generates structured PRDs from feature request transcripts or descriptions, researches your codebase for accurate technical scoping, and optionally creates Linear projects and issues.

Installation

1. Copy this folder into your repo's .claude/skills/ directory:

cp -r create-prd-skill/ your-repo/.claude/skills/create-prd/

2. Customize company-context.md with your product, architecture, and conventions (see the [YOUR ...] placeholders inside).

3. Optionally update template.md to match your team's PRD format.

4. Use it:

/create-prd path/to/transcript.md

or

/create-prd We need a feature that lets users do X when Y happens...

What's inside

Customization checklist

• [ ] Fill in company-context.md with your product concepts, architecture, tech stack, and conventions
• [ ] Update the example PRD path in SKILL.md Step 5 rule 3 (or remove that rule)
• [ ] Adjust the PR size limits in template.md Section 12 if your team uses different thresholds
• [ ] If you don't use Linear, remove Step 7 from SKILL.md and the Linear tools from allowed-tools
• [ ] If you don't use feature flags, simplify the Feature Flag sections in template.md and company-context.md

Linear integration (optional)

Step 7 of the skill creates a Linear project and issues from the PRD's implementation plan. This requires the Linear MCP server to be configured in your Claude Code setup.

To remove Linear integration, delete Step 7 from SKILL.md and remove the mcp__linear-mcp__* entries from the allowed-tools line in the frontmatter.

PRD Template

Use this template to generate PRDs. Each section includes guidance on what to write. Remove the guidance comments in the final output — they're instructions for you, not content for the PRD.

---

# PRD: {Feature Name}

## Metadata

| Field | Value |
|-------|-------|
| **Author** | [TODO — PRD author name] |
| **Status** | Draft |
| **Created** | {today's date, YYYY-MM-DD} |
| **Last Updated** | {today's date, YYYY-MM-DD} |
| **Version** | 0.1 |
| **Related Docs** | {List transcripts, meeting notes, design docs, prototypes, and other references mentioned in the input} |

---

## 1. Problem Statement

<!--
Write a clear problem statement following this structure:
- **Who** is affected (specific persona, not "users")
- **What need** is unmet (concrete, not abstract)
- **Why** the current state is insufficient

Then provide **Evidence** — data points, user quotes, support tickets, competitive analysis,
or stakeholder observations from the transcript. Use bullet points. Cite sources.

End with a **Key Insight** paragraph — the non-obvious realization that frames the solution
direction. This should be the "aha" that someone reading the PRD needs to understand before
the solution makes sense.

If the transcript doesn't provide enough evidence, use [TODO] markers for specific data
points that need to be gathered.
-->

**Who** is affected and **what need** is unmet?

> {One-paragraph problem statement — specific persona + unmet need + why it matters now}

**Evidence:**
- {Evidence point 1 — data, quote, or observation with source}
- {Evidence point 2}
- {Evidence point 3}

**Key Insight:**
{The non-obvious realization that frames the solution direction}

---

## 2. Goals

<!--
Use the Goal/Metric/Target table format. Each goal should be:
- Measurable (tied to a specific metric)
- Time-bound (has a target timeline)
- Realistic but ambitious

Include 3-5 goals. Mark baselines as [TODO] if not available from the transcript.
-->

| # | Goal | Metric | Target |
|---|------|--------|--------|
| G1 | {Goal description} | {Specific metric} | {Target value + timeline} |
| G2 | {Goal description} | {Specific metric} | {Target value + timeline} |
| G3 | {Goal description} | {Specific metric} | {Target value + timeline} |

---

## 3. Non-Goals

<!--
Explicitly state what this feature is NOT doing. Categories:
- "Not building:" — things that sound related but are out of scope
- "Not solving for:" — user segments or use cases excluded from this version
- "Not changing:" — existing systems/features that remain untouched
- "Deferred to future:" — good ideas that belong in a later version, with brief rationale

Be specific. Each non-goal should preempt a question someone might ask after reading the
Goals section.
-->

- **Not building:** {Feature or capability that's explicitly out of scope}
- **Not solving for:** {User segment or use case excluded}
- **Not changing:** {Existing system that remains untouched}
- **Deferred to future:** {Good idea for later, with brief rationale for deferral}

---

## 4. Target Users

<!--
Define Primary Persona, Secondary Persona (if applicable), and Anti-Persona.
For each persona include:
- **Who:** Specific role/title, not generic "users"
- **Context:** Their situation when they encounter this feature
- **Motivation:** What they're trying to accomplish (Jobs to be Done framing)
- **Current workaround:** How they handle this today without the feature
- **Jobs to be done:** A quote-style JTBD statement
-->

### Primary Persona
- **Who:** {Specific role — e.g., "Team admin at a 50-person SaaS company"}
- **Context:** {Their situation when they encounter this feature}
- **Motivation:** {What they're trying to accomplish}
- **Current workaround:** {How they handle this today}
- **Jobs to be done:** "{JTBD statement in first person}"

### Secondary Persona
- **Who:** {Role}
- **How they're impacted:** {How this feature affects them differently than primary persona}
- **Context:** {Their situation}

### Anti-Persona
- **Who is this NOT for:**
  - {User type 1 and why they're excluded}
  - {User type 2 and why they're excluded}

---

## 5. User Stories & Key Flows

<!--
Write 3-6 user stories covering:
1. Happy path (primary use case, most detail)
2. Key alternative paths (skip flows, error cases, edge cases)
3. Each story uses the format: As a [persona], I want to [action], so that [outcome]
4. Each story has a numbered step-by-step Flow section
5. End with "Flows NOT Covered" listing what's explicitly excluded

The happy path should be very detailed (15-20 steps). Alternative paths can be shorter.
-->

### Story 1: {Happy Path Title}
**As a** {persona}, **I want to** {action}, **so that** {outcome}.

**Flow:**
1. {Step 1}
2. {Step 2}
...

### Story 2: {Alternative Path Title}
**As a** {persona}, **I want to** {action}, **so that** {outcome}.

**Flow:**
1. {Step 1}
2. {Step 2}
...

### Flows NOT Covered
- {Flow 1 and why it's excluded}
- {Flow 2 and why it's excluded}

---

## 6. Solution Overview

<!--
Start with an **Approach** paragraph summarizing the overall solution in 2-3 sentences.

Then list **Key Design Decisions** — numbered, each with:
- A bold title stating the decision
- A paragraph explaining the rationale (why this approach, not just what)
- Trade-offs considered

These decisions should be opinionated and specific to your product's context.
Reference existing patterns, code, and conventions where relevant.
-->

**Approach:** {2-3 sentence overview of the solution}

**Key Design Decisions:**

1. **{Decision title}.** {Rationale paragraph explaining why this approach was chosen,
   what alternatives were considered, and how this fits existing patterns.}

2. **{Decision title}.** {Rationale paragraph.}

**Wireframes/Mockups:** {Reference to designs or [TODO — mockups needed]}

---

## 7. Technical Scope

<!--
IMPORTANT: This section must reference REAL code paths from your codebase research.
Never hallucinate file paths or module names.

Fill in the Affected Architecture Layers table and any project-specific checklists
from company-context.md.
-->

### Affected Architecture Layers

| Layer | Changes | Details |
|-------|---------|---------|
| **Database** | {None / Minor / Major} | {What models, fields, or tables change} |
| **Backend** | {None / New / Modified} | {Which services, APIs, or routes are affected} |
| **Frontend** | {None / New / Modified} | {Which components, pages, or views} |
| **API** | {None / New endpoints / Modified} | {Which endpoints} |
| **Integrations** | {None / Affected} | {Which third-party integrations} |

### Database Changes
- [ ] New tables/models: {List or "None"}
- [ ] New fields on existing tables: {List with types}
- [ ] New enum values: {List}
- [ ] Migration strategy: {Forward-only / backfill needed / etc.}

### API Surface
- [ ] New endpoints/procedures: {List with input/output types}
- [ ] Modified endpoints/procedures: {List}
- [ ] Webhook events: {New/modified events or "None"}

### Feature Flag Strategy
- Flag name: `{feature-flag-name}`
- Default: `off`
- Implementation: {Where the flag is checked}
- Rollout plan: {Phased rollout description}

<!--
Add any project-specific technical checklists here.
See company-context.md for sections your team requires (e.g., i18n, self-hosted,
mobile impact, accessibility, etc.)
-->

---

## 8. Hypotheses & Assumptions

<!--
Use the format: "We believe [hypothesis] because [reasoning]. We'll know we're right
if [measurable validation criteria]."

List 3-5 hypotheses. Mark each as Unvalidated, Partially Validated, or Validated.

Then list "Key assumptions that could invalidate this plan" with mitigations.
-->

| # | Hypothesis | Validation Method | Status |
|---|-----------|-------------------|--------|
| H1 | We believe {hypothesis} because {reasoning} | We'll know we're right if {measurable criteria} | Unvalidated |
| H2 | We believe {hypothesis} because {reasoning} | We'll know we're right if {measurable criteria} | Unvalidated |

**Key assumptions that could invalidate this plan:**

- **{Assumption 1}.** {Why it matters and what happens if it's wrong.} **Mitigation:** {How to de-risk.}
- **{Assumption 2}.** {Why it matters.} **Mitigation:** {How to de-risk.}

---

## 9. Success Metrics

<!--
Structure: Primary KPI, Secondary KPIs, Guardrail Metrics, Release Criteria.
Each metric needs: metric name, baseline (or [TODO]), target, timeline.
Guardrail metrics are things that must NOT regress.
Release criteria are pass/fail gates before launch.
-->

### Primary KPI
- **Metric:** {Primary success metric}
- **Baseline:** {Current value or [TODO — need data from {source}]}
- **Target:** {Target value}
- **Timeline:** {When to measure}

### Secondary KPIs
- **Metric:** {Secondary metric 1}
- **Baseline:** {Value or [TODO]}
- **Target:** {Target}
- **Timeline:** {When}

### Guardrail Metrics (must not regress)
- {Metric 1}: must stay above {threshold}
- {Metric 2}: must not increase beyond {threshold}

### Release Criteria
- [ ] {Criterion 1}
- [ ] {Criterion 2}
- [ ] {Criterion 3}

---

## 10. Risk Assessment (SVPG Framework)

<!--
Assess four risk types from SVPG (Silicon Valley Product Group):
- Value: Will users want this?
- Usability: Can users figure out how to use it?
- Feasibility: Can engineering build it with current resources/timeline?
- Viability: Does it work for the business (legal, compliance, cost, etc.)?

Rate each as Low/Medium/High with description and mitigation.
-->

| Risk Type | Level | Description | Mitigation |
|-----------|-------|-------------|------------|
| **Value** | {Low/Medium/High} | {Will users want this? What's uncertain?} | {How to de-risk} |
| **Usability** | {Low/Medium/High} | {Can users figure it out?} | {How to de-risk} |
| **Feasibility** | {Low/Medium/High} | {Can we build it?} | {How to de-risk} |
| **Viability** | {Low/Medium/High} | {Does it work for the business?} | {How to de-risk} |

---

## 11. Dependencies & Risks

<!--
List dependencies in categories relevant to your project:
- Cross-Team Dependencies (people/teams that must do something)
- Third-Party Dependencies (external services, APIs)
- Any project-specific categories from company-context.md
-->

### Cross-Team Dependencies
- [ ] {Team/Person} — {What's needed and timing}

### Third-Party Dependencies
- [ ] {Service/API} — {Dependency and risk level}

---

## 12. Implementation Approach

<!--
Break the implementation into small, reviewable PRs.
Adjust size limits to match your team's conventions.
-->

### PR Breakdown Strategy

| # | PR Scope | Estimated Size | Dependencies | Labels |
|---|----------|---------------|--------------|--------|
| 1 | {PR description} | ~{N} lines | {None or PR #} | `{labels}` |
| 2 | {PR description} | ~{N} lines | {None or PR #} | `{labels}` |

**Total estimated size:** ~{N} lines across {N} PRs.

### Testing Plan

- **Unit tests:** {What to test and in which PR}
- **Integration tests:** {What to test and in which PR}
- **E2E tests:** {What to test and in which PR}

### Rollout Plan

1. **Development:** Feature flag `off`. Build behind flag.
2. **Internal dogfooding ({duration}):** Flag on for internal accounts.
3. **Partial rollout ({percentage}, {duration}):** A/B test with metrics.
4. **GA:** Flag on for all users.

### Rollback Criteria
- {Condition 1 that triggers rollback}
- {Condition 2 that triggers rollback}
- **Rollback procedure:** {How to roll back safely}

---

## 13. Stakeholder Sign-Off

| Role | Name | Status |
|------|------|--------|
| PM | {Name or [TODO]} | [ ] Approved |
| Eng Lead | {Name or [TODO]} | [ ] Approved |
| Design | {Name or [TODO]} | [ ] Approved |

---

## Appendix

### Change Log
| Date | Version | Changes |
|------|---------|---------|
| {today's date} | 0.1 | Initial draft generated from {source description} |

### FAQ

<!--
Include 3-8 FAQ entries addressing questions someone would likely ask after reading the PRD.
Format: Q/A pairs. Good FAQs preempt objections and clarify ambiguities.
-->

- **Q:** {Anticipated question}
- **A:** {Clear answer with rationale}

### Research & References
- {Reference 1 — transcript, doc, or resource with description}
- {Reference 2}