prd-interview

name	prd-interview
description	This skill should be used when conducting PRD interviews, creating product requirements documents, planning new features, documenting bug fixes, or when using commands like "/prd-builder:prd", "/prd-builder:feature", "/prd-builder:bugfix", or "/prd-builder:refine". Provides comprehensive interview frameworks and question templates for building thorough PRDs.

PRD Interview Skill

Guide comprehensive interviews to transform rough ideas into actionable Product Requirements Documents — a brief Launch Framing phase (thesis + hero flow) followed by structured discovery across 8 categories.

Launch Discipline Principles

Apply these to every PRD (skip thesis/hero-flow only for bug fixes). They shape how the interview and document are organized, regardless of stack:

1. Thesis & hero flow first. Open the PRD with a one-line product thesis and a single hero flow — the demo that proves the value. Technology comes after, in service of that flow.
2. Brutally lean v1. The launch scope contains only what serves the hero flow. Everything else goes to a sequenced post-launch roadmap — deferred, not discarded — each item with the reason it was deferred.
3. Decide over defer. When something is ambiguous, prefer to decide and record it in the Decisions table with a named owner. List as an open question only what genuinely cannot be decided now.
4. Start with the simplest thing that works. Each heavy piece (architecture, roles, internal tools) needs an explicit "needed now" justification; when in doubt, defer it.
5. Vet every dependency. Third-party packages must be open source and actively maintained (verify by search), recorded in the dependency table; prefer first-party/native solutions.

Default Stack & Conventions

When the user has not specified a stack or architecture, apply the default SaaS profile in references/default-stack.md as a pre-selected recommended default. That file is the single source of truth for the profile — stack versions, multi-tenancy, RBAC, auth, MFA, dependency policy, and payments-out-of-scope. Don't restate the version list elsewhere; point to it.

• Offer it, don't impose it. During the Technical category, present the profile as the first option, marked "(Recommended default)" and pre-selected, so the user confirms or overrides. The user opts out; they do not have to opt in.
• Offer the full profile (tenancy/RBAC/auth conventions included) as the pre-selected default, dropping whatever the user declines.
• Exception for /feature: a feature lives inside an existing product, so default to that product's current stack. Fall back to the full profile only when the host stack is unknown or the product is greenfield.
• Whatever stack is chosen, record it in the PRD Decisions table with an owner.

Core Interview Process

Interview Flow

1. Initial Prompt: Capture the base idea in user's own words
2. Thesis & Hero Flow: Before features, pin down the one-line product thesis and the single hero flow that proves the value (skip for bug fixes)
3. Category-Based Discovery: Work through relevant categories using AskUserQuestion
4. Adaptive Branching: Skip irrelevant questions based on context
5. Progressive Summarization: Summarize after each category before moving on
6. Draft Generation: Build the PRD draft (with Mermaid diagrams) in memory — not yet saved
7. Design Review & Redesign: Silently run the two review lenses over the draft, reconcile, and rewrite the product (see references/design-review.md); save only the final PRD
8. Architecture Handoff: For non-trivial work, recommend /architect:design on the saved PRD before tasks — the architecture (docs/architecture/ + docs/adr/) is what taskmanager decomposes and verifies against; size the ceremony to the work and skip it for trivial/low-risk changes
9. Task Integration: Offer to generate hierarchical tasks via taskmanager

Interview Categories

After the Launch Framing phase, conduct interviews across these 8 categories (adapt based on PRD type):

Category	Focus Areas	When to Use
Problem & Context	Pain points, current state, why now	Always
Users & Customers	Personas, segments, user journeys	Always
Solution & Features	Feature list, MVP scope, priorities	Always
Technical Implementation	Architecture, stack (default profile), integrations, dependency vetting	Always
Business & Value	ROI, pricing, revenue model	Products, major features
UX & Design	Flows, wireframes, accessibility	UI-facing work
Risks & Concerns	Dependencies, assumptions, blockers	Always
Testing & Quality	Test strategies, acceptance criteria	Always

Question Guidelines

When using AskUserQuestion:

• Ask 2-4 questions per round maximum
• Provide concrete options when possible
• Enable multiSelect for non-mutually-exclusive choices
• Include "Other" automatically (tool handles this)
• Use short headers (max 12 chars)

Adaptive Branching Rules

Skip categories based on context:

• Internal tool: Skip pricing/revenue questions in Business & Value
• Backend-only: Minimize UX & Design category
• Bug fix: Focus on Problem & Context, Technical, Testing
• Feature: Full interview but lighter on Business & Value

Session State Management

State File Location

Save interview progress to: .taskmanager/prd-state.json

State Structure

{
  "sessionId": "uuid",
  "prdType": "product|feature|bugfix",
  "slug": "feature-name",
  "startedAt": "ISO timestamp",
  "lastUpdatedAt": "ISO timestamp",
  "currentCategory": "category-name",
  "completedCategories": ["category1", "category2"],
  "answers": {
    "category-name": {
      "question-key": "answer-value"
    }
  },
  "initialPrompt": "User's original description"
}

Resuming Sessions

When /prd-builder:prd or similar is invoked:

1. Check for existing state in .taskmanager/prd-state.json
2. If found, ask user: "Resume previous session for '{slug}' or start fresh?"
3. If resuming, continue from currentCategory
4. If starting fresh, archive old state and begin new session

PRD Document Structure

Output Location

Save PRDs to: docs/prd/prd-{slug}.md

Document Template

templates/prd-template.md is the authoritative section structure — generate PRDs by filling it; don't maintain a second copy of the section list here. The ordering principle: the Product Thesis and Hero Flow lead and the technology follows in service of the hero flow; scope lives in Features & Requirements (a lean Launch Scope v1 plus a sequenced Deferred Roadmap); every resolved choice is recorded in Decisions with an owner; Open Questions holds only what genuinely can't be decided yet.

Mermaid Diagrams

Include these diagrams where appropriate:

Architecture Diagram:

graph TB
    subgraph Frontend
        UI[User Interface]
    end
    subgraph Backend
        API[API Layer]
        DB[(Database)]
    end
    UI --> API --> DB

User Flow Diagram:

flowchart LR
    A[Start] --> B{Decision}
    B -->|Yes| C[Action]
    B -->|No| D[Alternative]

Architecture Handoff

The PRD is the what; the architecture is the how. For non-trivial work (a new system, a new data model/ownership decision, a new service boundary or public contract — anything expensive to change later), recommend running /architect:design docs/prd/prd-{slug}.md before tasks. The architect writes docs/architecture/ + docs/adr/ (per scribe's docs contract), and taskmanager then decomposes and verifies design-conformance against them — not just against the PRD. Size the ceremony to the work: skip the architecture pass for trivial/low-risk changes that need no seam or decision. The architect plugin is part of this suite; if it is not installed, proceed to tasks and note the design step was skipped.

TaskManager Integration

Task Generation Process

After PRD completion:

1. Parse all features from the PRD
2. Create hierarchical task structure:
   • Parent task per major feature
   • Child tasks for implementation steps
3. Use /taskmanager:plan with the PRD file path

Task Hierarchy Example

Feature: User Authentication
├── Setup authentication infrastructure
├── Implement login endpoint
├── Implement registration endpoint
├── Add password reset flow
├── Create authentication middleware
└── Write authentication tests

Automatic Execution

After generating tasks, ask: "Tasks created. Start autonomous execution?" If yes, invoke /taskmanager:run to begin implementation.

PRD Types

Full Product PRD (/prd-builder:prd)

Complete interview covering all 8 categories in depth:

• 10-15 question rounds
• Comprehensive documentation
• Full Mermaid diagrams
• Complete task breakdown

Feature PRD (/prd-builder:feature)

Lighter interview focused on implementation:

• 5-8 question rounds
• Skip or minimize Business & Value (unless monetized feature)
• Focus on Technical, UX, Testing
• Assume product context exists

Bug Fix PRD (/prd-builder:bugfix)

Problem-focused documentation:

• 3-5 question rounds
• Heavy focus on Problem & Context
• Technical root cause analysis
• Regression testing strategy
• Skip Business, minimize UX

Refine PRD (/prd-builder:refine)

Enhance existing PRDs:

1. Read and analyze existing PRD
2. Identify weak or missing sections
3. Ask targeted questions for gaps only
4. Merge new answers into existing document
5. Preserve original content where adequate

Additional Resources

Reference Files

Detailed question banks, default profile, and review lenses:

• references/question-bank.md - Complete question library organized by category
• references/default-stack.md - Default SaaS stack & conventions profile, applied as a pre-selected default when the user has not specified a stack
• references/design-review.md - Dual-lens design review (Experience & Simplicity + First-Principles Engineering) run silently after the draft to redesign the product; only the final PRD is saved

Template Files

PRD output template:

• templates/prd-template.md - Full PRD document structure