Generate PRD Skill

Degree of freedom: MIXED. Clarifying questions, scope, and requirements [HIGH freedom]; stack/feature/schema detection [LOW freedom — run exactly].

Create detailed, actionable Product Requirements Documents through structured conversation, informed by codebase analysis and competitive research.

How to reason

1. Discover — stack, features, schema, existing PRDs
2. Clarify — only what is unclear, numbered with lettered options
3. Scope — P0/P1/P2 plus explicit non-goals
4. Specify — testable requirements, not implementation

Worked example

Discover: Next.js + Supabase; notifications table missing; no prd-*.md. Clarify: in-app vs email vs push? (user: 1A in-app only). MVP vs polish? (2A MVP). Scope: P0 in-app bell + read state; non-goal: email/push (design-email / mobile-capacitor-platform). Specify: FR-1 "unread count on the header within 2s of insert" — not "feel realtime".

Self-critique before reporting

• Context recorded — stack, features, schema, and existing PRDs were listed first
• Questions minimal — only what was unclear, lettered; coding did not start first
• Testable FRs — no "should be fast" without a number
• Right owner — ready to implement → workflow-build-feature; UI from scratch → design-frontend; RLS matrix → plan-rls-audit

Step 0: Auto-Detect Project Context [LOW freedom — run exactly]

Before writing any PRD, understand the project from its source code.

0a. Detect Tech Stack

Read package.json (or equivalent) to extract:

• Framework: Next.js, Remix, SvelteKit, Nuxt, Django, Rails, etc.
• UI library: React, Vue, Svelte, Angular
• Database: Supabase, Prisma, Drizzle, raw SQL
• Auth: Supabase Auth, NextAuth, Clerk, Auth0
• State management: TanStack Query, Zustand, Redux, Pinia
• CSS: Tailwind, CSS Modules, Styled Components

0b. Discover Existing Features

Glob: **/app/**/page.tsx → Next.js routes (features)
Glob: **/features/*/ → Feature directories
Glob: **/src/routes/**/*.tsx → Route-based features
Grep: pattern "export default" glob "**/page.tsx" output_mode "files_with_matches"

Read feature READMEs if they exist:

Glob: **/*README*.md → Feature docs
Glob: **/docs/*.md → Documentation

0c. Discover Data Model

Glob: **/supabase/migrations/*.sql → SQL migrations
Glob: **/prisma/schema.prisma → Prisma schema
Glob: **/drizzle/schema.ts → Drizzle schema
Glob: **/types/*.ts → TypeScript type definitions

0d. Check for Existing PRDs

Glob: **/tasks/prd-*.md → Existing PRDs
Glob: **/docs/prd-*.md → Existing PRDs (alt location)
Glob: **/specs/*.md → Spec documents

0e. Record Context

PROJECT CONTEXT:
- Framework: [name + version]
- Database: [type + ORM]
- Existing features: [list of routes/feature dirs]
- Existing PRDs: [list or none]
- Data entities: [list from schema]
- Auth system: [provider]

Step 1: Research Before Writing [HIGH freedom]

1a. Competitive Research (Firecrawl)

When the user describes a feature, research how others have solved it:

firecrawl:firecrawl_search
{
 "query": "<FEATURE_TYPE> UX patterns best practices [current year]",
 "limit": 5,
 "sources": [{ "type": "web" }]
}

Feature-type search queries (CRUD, dashboard, onboarding, e-commerce, social, CMS, search, settings): references/research-and-questions.md §Feature-type search queries.

Scrape the most relevant result for detailed patterns. Competitor rows in section 7 come from fetched pages, not memory — recognizing a product name is not knowing its current feature set; search the name as written:

firecrawl:firecrawl_scrape
{
 "url": "<BEST_RESULT_URL>",
 "formats": ["markdown"],
 "onlyMainContent": true
}

1b. Technical Feasibility (Context7)

Check if the framework supports what the feature needs:

context7:resolve-library-id
{
 "libraryName": "<FRAMEWORK>",
 "query": "<FEATURE_CAPABILITY> support"
}

context7:query-docs
{
 "libraryId": "<RESOLVED_ID>",
 "query": "<FEATURE_CAPABILITY> implementation guide"
}

1c. Data Model Feasibility (Supabase MCP)

If the feature involves data, check the existing schema:

supabase:list_tables
{
 "schemas": ["public"],
 "verbose": true
}

Or for specific tables:

supabase:execute_sql
{
 "query": "SELECT column_name, data_type, is_nullable FROM information_schema.columns WHERE table_name = '<RELEVANT_TABLE>' ORDER BY ordinal_position"
}

Determine:

• Can existing tables support this feature?
• What new tables/columns are needed?
• What relationships need to be added?
• Do RLS policies need updating?

Step 2: Understand the Request [HIGH freedom]

When the user describes a feature, sort what is clear from what is unclear before writing anything:

• Clear: problem statement, target user, basic functionality
• Unclear: scope boundaries, success metrics, edge cases, technical constraints

Check for Similar Functionality

SemanticSearch: "How does the app currently handle <FEATURE_AREA>?" target: []
Grep: pattern "<FEATURE_KEYWORDS>" glob "*.{ts,tsx,js,jsx}"

If similar functionality already exists, the PRD should extend it rather than duplicate.

Step 3: Ask Clarifying Questions [HIGH freedom]

Rules

1. Ask only what is truly unclear — usually a handful; if nothing is, say so and proceed
2. Number all questions (1, 2, 3...)
3. Provide lettered options (A, B, C, D) for easy response
4. Make responding easy — user can reply "1A, 2C, 3B"

Question Categories

Example Format

Numbered questions, lettered A–D options, closing with Reply with selections (e.g., "1B, 2A, 3B"): references/research-and-questions.md §Clarifying questions.

Step 4: Generate PRD [HIGH freedom]

Template

Ten sections, in order: Overview (problem, proposed solution) → Goals table with success metrics → User Stories (primary + edge case) → Functional Requirements as P0/P1/P2 checkboxes → Non-Goals → Technical Feasibility (existing vs new infrastructure, complexity table) → Competitive Analysis table from the Firecrawl research → UI/UX Considerations (screens, borrowed patterns, accessibility) → Data Model (tables used, SQL for new tables, RLS policies) → Open Questions.

Full template: references/prd-template.md.

Step 5: Iterate [HIGH freedom]

Present the PRD, take the user's edits, resolve the open questions, and confirm it is ready to save before writing the file.

Step 6: Save [LOW freedom — run exactly]

Location: tasks/prd-[feature-name].md

Naming:

• All lowercase
• Use hyphens for spaces
• Examples: prd-dark-mode.md, prd-export-csv.md, prd-user-onboarding.md

Writing Guidelines

Target audience: a junior developer should understand this.

• Clear, simple language
• Define acronyms on first use
• Be explicit — no implied knowledge
• Every requirement is testable ("fast" is vague; "loads in under 200ms" is testable)
• Use tables for structured comparisons
• Include "Not doing" section to prevent scope creep

Anti-Patterns

• Starting to code before asking questions
• Asking questions the repo or the request already answers
• Writing implementation details (PRD = WHAT/WHY, not HOW)
• Vague requirements ("should be fast" -> "response time under 200ms")
• Skipping competitive research (leads to reinventing the wheel)
• Skipping technical feasibility (leads to impossible requirements)
• Not checking existing codebase (leads to duplicate features)