Generate comprehensive Product Requirements Document (PRD) through interactive discovery and research. Interviews the user, conducts web research for best practices and current tech specs, and produces a professional PRD. Use when starting a new project, web app, codebase, ML pipeline, or any development initiative.
Generate a PRD through interactive discovery, web research, and synthesis. Interview users, research best practices, then produce a professional requirements document.
This skill implements the Architect phase of ATLAS development.
When to create a PRD:
When NOT to create a PRD:
/pr:feature-dev with RFD)A PRD answers the core questions that prevent building failures:
The PRD also begins the Trace phase by documenting:
For complete ATLAS framework details, see atlas-development skill.
PRD creation is primarily an interactive interview process, so multi-agent approaches apply mainly to the research phase (Phase 2).
When to use subagents: During deep research, dispatch subagents to research different domains in parallel — one for tech stack analysis, one for security/compliance, one for competitive landscape. Each returns findings independently. This is the default and sufficient approach.
When agent teams could help: For PRDs covering very complex domains with many interacting technology choices (e.g., a full-stack application with multiple external integrations, compliance requirements, and competing architectural approaches). In this case, research agents could challenge each other's technology recommendations and surface conflicts. In practice, PRD research tasks are independent enough that subagents work well.
If the calling command passes --team, respect that flag. Otherwise, default to subagents for research phases.
Goal: Process any provided input
Arguments: $ARGUMENTS
Actions:
If arguments provided, read and analyze:
Extract key information:
If no arguments, proceed directly to discovery interview
Goal: Understand what the user wants to build
Stage 1: Core Vision
Research: Search for existing solutions, market landscape, user demographics
Stage 2: Scope Definition
Research: Search for MVP best practices in the domain, feature prioritization frameworks
Stage 3: Technical Direction
Research: Verify latest versions, search for recommended tech stacks, compatibility issues
Stage 4: Design & Experience (if applicable)
Research: Search for UX patterns in the domain, accessibility standards, design system options
Stage 5: Constraints & Context
Research: Search for compliance requirements, industry regulations if applicable
Stop when: user says "use your judgment", indicates they've shared everything, critical sections have enough information, or continuing adds no value.
Goal: Research technology choices and best practices
Actions:
Search: "recommended tech stack [project type] 2024"
Search: "[framework] latest stable version"
Search: "[framework A] vs [framework B] for [use case]"
Search: "[service] API documentation"
Search: "[service] [framework] integration guide"
Search: "[service] authentication oauth setup"
Search: "[service] rate limits pricing"
Search: "[compliance standard] requirements checklist"
Search: "[industry] data protection requirements"
Search: "authentication best practices [year]"
Search: "[framework] security best practices"
Goal: Share research findings and confirm decisions
Actions:
Goal: Create comprehensive PRD document
Output Location: {project_root}/.claude/checkpoints/checkpoint-0/prd.md
Create directory if needed:
mkdir -p {project_root}/.claude/checkpoints/checkpoint-0
PRD Structure (see embedded template below):
Goal: Write file and confirm completion
Actions:
Write PRD to .claude/checkpoints/checkpoint-0/prd.md
Report completion with:
Use the template at references/prd-template.md. Copy and fill in each section based on discovery and research findings.
Apply the writing-clearly-and-concisely skill when drafting prose sections (Executive Summary, Problem Statement, etc.) to ensure clear, direct writing.
When user is uncertain:
"For [topic], let me search for current best practices... Based on my research, [finding]. Does that approach work for you?"
When user wants to defer:
"I'll research this and use the current best practices for [topic]. You can always refine this later."
When scope is creeping:
"That's a great idea. Should we include it in the MVP, or save it for a future version?"
When proposing technologies:
"Based on my research, [framework] v[X.Y.Z] is the current stable version and is well-suited for [reason]. Would you like me to explore alternatives?"
Before finalizing, verify: