Major Enhancements:

- Installation path is now fully configurable, allowing users to specify custom installation directories during setup
  - Default installation location changed to .bmad (hidden directory) for cleaner project root organization

    Web Bundle Improvements:

    - All web bundles (single agent and team) now include party mode support for multi-agent collaboration!
    - Advanced elicitation capabilities integrated into standalone agents
    - All bundles enhanced with party mode agent manifests
    - Added default-party.csv files to bmm, bmgd, and cis module teams
    - The default party file is what will be used with single agent bundles. teams can customize for different party configurations before web bundling through a setting in the team yaml file
    - New web bundle outputs for all agents (analyst, architect, dev, pm, sm, tea, tech-writer, ux-designer, game-*, creative-squad)

    Phase 4 Workflow Updates (In Progress):

    - Initiated shift to separate phase 4 implementation artifacts from documentation
        - Phase 4 implementation artifacts (stories, code review, sprint plan, context files) will move to dedicated location outside docs folder
        - Installer questions and configuration added for artifact path selection
        - Updated workflow.yaml files for code-review, sprint-planning, story-context, epic-tech-context, and retrospective workflows to support this, but still might require some udpates

    Additional Changes:

    - New agent and action command header models for standardization
    - Enhanced web-bundle-activation-steps fragment
    - Updated web-bundler.js to support new structure
    - VS Code settings updated for new .bmad directory
    - Party mode instructions and workflow enhanced for better orchestration

   IDE Installer Updates:

    - Show version number of installer in cli
    - improved Installer UX
    - Gemini TOML Improved to have clear loading instructions with @ commands
    - All tools agent launcher mds improved to use a central file template critical indication isntead of hardcoding in 2 different locations.
This commit is contained in:
Brian Madison
2025-11-09 17:39:05 -06:00
parent fd2521ec69
commit 7eb52520fa
433 changed files with 125975 additions and 689 deletions

View File

@@ -0,0 +1,350 @@
# PRD + Epics + Stories Validation Checklist
**Purpose**: Comprehensive validation that PRD, epics, and stories form a complete, implementable product plan.
**Scope**: Validates the complete planning output (PRD.md + epics.md) for Levels 2-4 software projects
**Expected Outputs**:
- PRD.md with complete requirements
- epics.md with detailed epic and story breakdown
- Updated bmm-workflow-status.yaml
---
## 1. PRD Document Completeness
### Core Sections Present
- [ ] Executive Summary with vision alignment
- [ ] Product magic essence clearly articulated
- [ ] Project classification (type, domain, complexity)
- [ ] Success criteria defined
- [ ] Product scope (MVP, Growth, Vision) clearly delineated
- [ ] Functional requirements comprehensive and numbered
- [ ] Non-functional requirements (when applicable)
- [ ] References section with source documents
### Project-Specific Sections
- [ ] **If complex domain:** Domain context and considerations documented
- [ ] **If innovation:** Innovation patterns and validation approach documented
- [ ] **If API/Backend:** Endpoint specification and authentication model included
- [ ] **If Mobile:** Platform requirements and device features documented
- [ ] **If SaaS B2B:** Tenant model and permission matrix included
- [ ] **If UI exists:** UX principles and key interactions documented
### Quality Checks
- [ ] No unfilled template variables ({{variable}})
- [ ] All variables properly populated with meaningful content
- [ ] Product magic woven throughout (not just stated once)
- [ ] Language is clear, specific, and measurable
- [ ] Project type correctly identified and sections match
- [ ] Domain complexity appropriately addressed
---
## 2. Functional Requirements Quality
### FR Format and Structure
- [ ] Each FR has unique identifier (FR-001, FR-002, etc.)
- [ ] FRs describe WHAT capabilities, not HOW to implement
- [ ] FRs are specific and measurable
- [ ] FRs are testable and verifiable
- [ ] FRs focus on user/business value
- [ ] No technical implementation details in FRs (those belong in architecture)
### FR Completeness
- [ ] All MVP scope features have corresponding FRs
- [ ] Growth features documented (even if deferred)
- [ ] Vision features captured for future reference
- [ ] Domain-mandated requirements included
- [ ] Innovation requirements captured with validation needs
- [ ] Project-type specific requirements complete
### FR Organization
- [ ] FRs organized by capability/feature area (not by tech stack)
- [ ] Related FRs grouped logically
- [ ] Dependencies between FRs noted when critical
- [ ] Priority/phase indicated (MVP vs Growth vs Vision)
---
## 3. Epics Document Completeness
### Required Files
- [ ] epics.md exists in output folder
- [ ] Epic list in PRD.md matches epics in epics.md (titles and count)
- [ ] All epics have detailed breakdown sections
### Epic Quality
- [ ] Each epic has clear goal and value proposition
- [ ] Each epic includes complete story breakdown
- [ ] Stories follow proper user story format: "As a [role], I want [goal], so that [benefit]"
- [ ] Each story has numbered acceptance criteria
- [ ] Prerequisites/dependencies explicitly stated per story
- [ ] Stories are AI-agent sized (completable in 2-4 hour session)
---
## 4. FR Coverage Validation (CRITICAL)
### Complete Traceability
- [ ] **Every FR from PRD.md is covered by at least one story in epics.md**
- [ ] Each story references relevant FR numbers
- [ ] No orphaned FRs (requirements without stories)
- [ ] No orphaned stories (stories without FR connection)
- [ ] Coverage matrix verified (can trace FR → Epic → Stories)
### Coverage Quality
- [ ] Stories sufficiently decompose FRs into implementable units
- [ ] Complex FRs broken into multiple stories appropriately
- [ ] Simple FRs have appropriately scoped single stories
- [ ] Non-functional requirements reflected in story acceptance criteria
- [ ] Domain requirements embedded in relevant stories
---
## 5. Story Sequencing Validation (CRITICAL)
### Epic 1 Foundation Check
- [ ] **Epic 1 establishes foundational infrastructure**
- [ ] Epic 1 delivers initial deployable functionality
- [ ] Epic 1 creates baseline for subsequent epics
- [ ] Exception: If adding to existing app, foundation requirement adapted appropriately
### Vertical Slicing
- [ ] **Each story delivers complete, testable functionality** (not horizontal layers)
- [ ] No "build database" or "create UI" stories in isolation
- [ ] Stories integrate across stack (data + logic + presentation when applicable)
- [ ] Each story leaves system in working/deployable state
### No Forward Dependencies
- [ ] **No story depends on work from a LATER story or epic**
- [ ] Stories within each epic are sequentially ordered
- [ ] Each story builds only on previous work
- [ ] Dependencies flow backward only (can reference earlier stories)
- [ ] Parallel tracks clearly indicated if stories are independent
### Value Delivery Path
- [ ] Each epic delivers significant end-to-end value
- [ ] Epic sequence shows logical product evolution
- [ ] User can see value after each epic completion
- [ ] MVP scope clearly achieved by end of designated epics
---
## 6. Scope Management
### MVP Discipline
- [ ] MVP scope is genuinely minimal and viable
- [ ] Core features list contains only true must-haves
- [ ] Each MVP feature has clear rationale for inclusion
- [ ] No obvious scope creep in "must-have" list
### Future Work Captured
- [ ] Growth features documented for post-MVP
- [ ] Vision features captured to maintain long-term direction
- [ ] Out-of-scope items explicitly listed
- [ ] Deferred features have clear reasoning for deferral
### Clear Boundaries
- [ ] Stories marked as MVP vs Growth vs Vision
- [ ] Epic sequencing aligns with MVP → Growth progression
- [ ] No confusion about what's in vs out of initial scope
---
## 7. Research and Context Integration
### Source Document Integration
- [ ] **If product brief exists:** Key insights incorporated into PRD
- [ ] **If domain brief exists:** Domain requirements reflected in FRs and stories
- [ ] **If research documents exist:** Research findings inform requirements
- [ ] **If competitive analysis exists:** Differentiation strategy clear in PRD
- [ ] All source documents referenced in PRD References section
### Research Continuity to Architecture
- [ ] Domain complexity considerations documented for architects
- [ ] Technical constraints from research captured
- [ ] Regulatory/compliance requirements clearly stated
- [ ] Integration requirements with existing systems documented
- [ ] Performance/scale requirements informed by research data
### Information Completeness for Next Phase
- [ ] PRD provides sufficient context for architecture decisions
- [ ] Epics provide sufficient detail for technical design
- [ ] Stories have enough acceptance criteria for implementation
- [ ] Non-obvious business rules documented
- [ ] Edge cases and special scenarios captured
---
## 8. Cross-Document Consistency
### Terminology Consistency
- [ ] Same terms used across PRD and epics for concepts
- [ ] Feature names consistent between documents
- [ ] Epic titles match between PRD and epics.md
- [ ] No contradictions between PRD and epics
### Alignment Checks
- [ ] Success metrics in PRD align with story outcomes
- [ ] Product magic articulated in PRD reflected in epic goals
- [ ] Technical preferences in PRD align with story implementation hints
- [ ] Scope boundaries consistent across all documents
---
## 9. Readiness for Implementation
### Architecture Readiness (Next Phase)
- [ ] PRD provides sufficient context for architecture workflow
- [ ] Technical constraints and preferences documented
- [ ] Integration points identified
- [ ] Performance/scale requirements specified
- [ ] Security and compliance needs clear
### Development Readiness
- [ ] Stories are specific enough to estimate
- [ ] Acceptance criteria are testable
- [ ] Technical unknowns identified and flagged
- [ ] Dependencies on external systems documented
- [ ] Data requirements specified
### Track-Appropriate Detail
**If BMad Method:**
- [ ] PRD supports full architecture workflow
- [ ] Epic structure supports phased delivery
- [ ] Scope appropriate for product/platform development
- [ ] Clear value delivery through epic sequence
**If Enterprise Method:**
- [ ] PRD addresses enterprise requirements (security, compliance, multi-tenancy)
- [ ] Epic structure supports extended planning phases
- [ ] Scope includes security, devops, and test strategy considerations
- [ ] Clear value delivery with enterprise gates
---
## 10. Quality and Polish
### Writing Quality
- [ ] Language is clear and free of jargon (or jargon is defined)
- [ ] Sentences are concise and specific
- [ ] No vague statements ("should be fast", "user-friendly")
- [ ] Measurable criteria used throughout
- [ ] Professional tone appropriate for stakeholder review
### Document Structure
- [ ] Sections flow logically
- [ ] Headers and numbering consistent
- [ ] Cross-references accurate (FR numbers, section references)
- [ ] Formatting consistent throughout
- [ ] Tables/lists formatted properly
### Completeness Indicators
- [ ] No [TODO] or [TBD] markers remain
- [ ] No placeholder text
- [ ] All sections have substantive content
- [ ] Optional sections either complete or omitted (not half-done)
---
## Critical Failures (Auto-Fail)
If ANY of these are true, validation FAILS:
- [ ]**No epics.md file exists** (two-file output required)
- [ ]**Epic 1 doesn't establish foundation** (violates core sequencing principle)
- [ ]**Stories have forward dependencies** (breaks sequential implementation)
- [ ]**Stories not vertically sliced** (horizontal layers block value delivery)
- [ ]**Epics don't cover all FRs** (orphaned requirements)
- [ ]**FRs contain technical implementation details** (should be in architecture)
- [ ]**No FR traceability to stories** (can't validate coverage)
- [ ]**Template variables unfilled** (incomplete document)
---
## Validation Summary
**Total Validation Points:** ~85
### Scoring Guide
- **Pass Rate ≥ 95% (81+/85):** ✅ EXCELLENT - Ready for architecture phase
- **Pass Rate 85-94% (72-80/85):** ⚠️ GOOD - Minor fixes needed
- **Pass Rate 70-84% (60-71/85):** ⚠️ FAIR - Important issues to address
- **Pass Rate < 70% (<60/85):** ❌ POOR - Significant rework required
### Critical Issue Threshold
- **0 Critical Failures:** Proceed to fixes
- **1+ Critical Failures:** STOP - Must fix critical issues first
---
## Validation Execution Notes
**When validating:**
1. **Load ALL documents:**
- PRD.md (required)
- epics.md (required)
- product-brief.md (if exists)
- domain-brief.md (if exists)
- research documents (if referenced)
2. **Validate in order:**
- Check critical failures first (immediate stop if any found)
- Verify PRD completeness
- Verify epics completeness
- Cross-reference FR coverage (most important)
- Check sequencing (second most important)
- Validate research integration
- Check polish and quality
3. **Report findings:**
- List critical failures prominently
- Group issues by severity
- Provide specific line numbers/sections
- Suggest concrete fixes
- Highlight what's working well
4. **Provide actionable next steps:**
- If validation passes: "Ready for architecture workflow"
- If minor issues: "Fix [X] items then re-validate"
- If major issues: "Rework [sections] then re-validate"
- If critical failures: "Must fix critical items before proceeding"
---
**Remember:** This validation ensures the entire planning phase is complete and the implementation phase has everything needed to succeed. Be thorough but fair - the goal is quality, not perfection.

View File

@@ -0,0 +1,52 @@
# {{project_name}} - Epic Breakdown
**Author:** {{user_name}}
**Date:** {{date}}
**Project Level:** {{project_level}}
**Target Scale:** {{target_scale}}
---
## Overview
This document provides the complete epic and story breakdown for {{project_name}}, decomposing the requirements from the [PRD](./PRD.md) into implementable stories.
{{epics_summary}}
---
<!-- Repeat for each epic (N = 1, 2, 3...) -->
## Epic {{N}}: {{epic_title_N}}
{{epic_goal_N}}
<!-- Repeat for each story (M = 1, 2, 3...) within epic N -->
### Story {{N}}.{{M}}: {{story_title_N_M}}
As a {{user_type}},
I want {{capability}},
So that {{value_benefit}}.
**Acceptance Criteria:**
**Given** {{precondition}}
**When** {{action}}
**Then** {{expected_outcome}}
**And** {{additional_criteria}}
**Prerequisites:** {{dependencies_on_previous_stories}}
**Technical Notes:** {{implementation_guidance}}
<!-- End story repeat -->
---
<!-- End epic repeat -->
---
_For implementation: Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown._

View File

@@ -0,0 +1,169 @@
# Epic and Story Decomposition - Intent-Based Implementation Planning
<critical>The workflow execution engine is governed by: {project-root}/.bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>This workflow transforms requirements into BITE-SIZED STORIES for development agents</critical>
<critical>EVERY story must be completable by a single dev agent in one focused session</critical>
<critical>Communicate all responses in {communication_language} and adapt to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>LIVING DOCUMENT: Write to epics.md continuously as you work - never wait until the end</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
<workflow>
<step n="1" goal="Load PRD and extract requirements">
<action>Welcome {user_name} to epic and story planning
Load required documents (fuzzy match, handle both whole and sharded):
- PRD.md (required)
- domain-brief.md (if exists)
- product-brief.md (if exists)
Extract from PRD:
- All functional requirements
- Non-functional requirements
- Domain considerations and compliance needs
- Project type and complexity
- MVP vs growth vs vision scope boundaries
Understand the context:
- What makes this product special (the magic)
- Technical constraints
- User types and their goals
- Success criteria</action>
</step>
<step n="2" goal="Propose epic structure from natural groupings">
<action>Analyze requirements and identify natural epic boundaries
INTENT: Find organic groupings that make sense for THIS product
Look for natural patterns:
- Features that work together cohesively
- User journeys that connect
- Business capabilities that cluster
- Domain requirements that relate (compliance, validation, security)
- Technical systems that should be built together
Name epics based on VALUE, not technical layers:
- Good: "User Onboarding", "Content Discovery", "Compliance Framework"
- Avoid: "Database Layer", "API Endpoints", "Frontend"
Each epic should:
- Have clear business goal and user value
- Be independently valuable
- Contain 3-8 related capabilities
- Be deliverable in cohesive phase
For greenfield projects:
- First epic MUST establish foundation (project setup, core infrastructure, deployment pipeline)
- Foundation enables all subsequent work
For complex domains:
- Consider dedicated compliance/regulatory epics
- Group validation and safety requirements logically
- Note expertise requirements
Present proposed epic structure showing:
- Epic titles with clear value statements
- High-level scope of each epic
- Suggested sequencing
- Why this grouping makes sense</action>
<template-output>epics_summary</template-output>
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
</step>
<step n="3" goal="Decompose each epic into bite-sized stories" repeat="for-each-epic">
<action>Break down Epic {{N}} into small, implementable stories
INTENT: Create stories sized for single dev agent completion
For each epic, generate:
- Epic title as `epic_title_{{N}}`
- Epic goal/value as `epic_goal_{{N}}`
- All stories as repeated pattern `story_title_{{N}}_{{M}}` for each story M
CRITICAL for Epic 1 (Foundation):
- Story 1.1 MUST be project setup/infrastructure initialization
- Sets up: repo structure, build system, deployment pipeline basics, core dependencies
- Creates foundation for all subsequent stories
- Note: Architecture workflow will flesh out technical details
Each story should follow BDD-style acceptance criteria:
**Story Pattern:**
As a [user type],
I want [specific capability],
So that [clear value/benefit].
**Acceptance Criteria using BDD:**
Given [precondition or initial state]
When [action or trigger]
Then [expected outcome]
And [additional criteria as needed]
**Prerequisites:** Only previous stories (never forward dependencies)
**Technical Notes:** Implementation guidance, affected components, compliance requirements
Ensure stories are:
- Vertically sliced (deliver complete functionality, not just one layer)
- Sequentially ordered (logical progression, no forward dependencies)
- Independently valuable when possible
- Small enough for single-session completion
- Clear enough for autonomous implementation
For each story in epic {{N}}, output variables following this pattern:
- story*title*{{N}}_1, story_title_{{N}}\_2, etc.
- Each containing: user story, BDD acceptance criteria, prerequisites, technical notes</action>
<template-output>epic*title*{{N}}</template-output>
<template-output>epic*goal*{{N}}</template-output>
<action>For each story M in epic {{N}}, generate story content</action>
<template-output>story*title*{{N}}\_{{M}}</template-output>
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
</step>
<step n="4" goal="Review and finalize epic breakdown">
<action>Review the complete epic breakdown for quality and completeness
Validate:
- All functional requirements from PRD are covered by stories
- Epic 1 establishes proper foundation
- All stories are vertically sliced
- No forward dependencies exist
- Story sizing is appropriate for single-session completion
- BDD acceptance criteria are clear and testable
- Domain/compliance requirements are properly distributed
- Sequencing enables incremental value delivery
Confirm with {user_name}:
- Epic structure makes sense
- Story breakdown is actionable
- Dependencies are clear
- BDD format provides clarity
- Ready for architecture and implementation phases</action>
<template-output>epic_breakdown_summary</template-output>
</step>
</workflow>

View File

@@ -0,0 +1,45 @@
# Epic and Story Decomposition Workflow
name: create-epics-and-stories
description: "Transform PRD requirements into bite-sized stories organized in epics for 200k context dev agents"
author: "BMad"
# Critical variables from config
config_source: "{project-root}/.bmad/bmm/config.yaml"
project_name: "{config_source}:project_name"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level"
date: system-generated
# Input requirements
recommended_inputs:
- prd: "Product Requirements Document with FRs and NFRs"
- product_brief: "Product Brief with vision and goals (optional)"
- domain_brief: "Domain-specific requirements and context (optional)"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
input_file_patterns:
prd:
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/index.md"
product_brief:
whole: "{output_folder}/*product*brief*.md"
sharded: "{output_folder}/*product*brief*/index.md"
domain_brief:
whole: "{output_folder}/*domain*brief*.md"
sharded: "{output_folder}/*domain*brief*/index.md"
# Module path and component files
installed_path: "{project-root}/.bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories"
instructions: "{installed_path}/instructions.md"
template: "{installed_path}/epics-template.md"
# Output configuration
default_output_file: "{output_folder}/epics.md"
standalone: true

View File

@@ -0,0 +1,13 @@
domain,signals,complexity,key_concerns,required_knowledge,suggested_workflow,web_searches,special_sections
healthcare,"medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug",high,"FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability","Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements","domain-research","FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software","clinical_requirements;regulatory_pathway;validation_methodology;safety_measures"
fintech,"payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech",high,"Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection","KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations","domain-research","fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date}","compliance_matrix;security_architecture;audit_requirements;fraud_prevention"
govtech,"government,federal,civic,public sector,citizen,municipal,voting",high,"Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency","Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements","domain-research","government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards","procurement_compliance;security_clearance;accessibility_standards;transparency_requirements"
edtech,"education,learning,student,teacher,curriculum,assessment,K-12,university,LMS",medium,"Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards","Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity","domain-research","educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards","privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment"
aerospace,"aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation",high,"Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls","Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements","domain-research + technical-model","DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements","safety_certification;simulation_validation;performance_requirements;export_compliance"
automotive,"vehicle,car,autonomous,ADAS,automotive,driving,EV,charging",high,"Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification","Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements","domain-research","ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards","safety_standards;functional_safety;communication_protocols;certification_requirements"
scientific,"research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI",medium,"Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources","Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards","technical-model","scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software","validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements"
legaltech,"legal,law,contract,compliance,litigation,patent,attorney,court",high,"Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration","Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality","domain-research","legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology","ethics_compliance;data_retention;confidentiality_measures;court_integration"
insuretech,"insurance,claims,underwriting,actuarial,policy,risk,premium",high,"Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance","Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting","domain-research","insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance","regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance"
energy,"energy,utility,grid,solar,wind,power,electricity,oil,gas",high,"Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations","Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems","domain-research","energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards","grid_compliance;safety_protocols;environmental_compliance;operational_requirements"
gaming,"game,player,gameplay,level,character,multiplayer,quest",redirect,"REDIRECT TO GAME WORKFLOWS","Game design","game-brief","NA","NA"
general,"",low,"Standard requirements;Basic security;User experience;Performance","General software practices","continue","software development best practices {date}","standard_requirements"
1 domain signals complexity key_concerns required_knowledge suggested_workflow web_searches special_sections
2 healthcare medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug high FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements domain-research FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software clinical_requirements;regulatory_pathway;validation_methodology;safety_measures
3 fintech payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech high Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations domain-research fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date} compliance_matrix;security_architecture;audit_requirements;fraud_prevention
4 govtech government,federal,civic,public sector,citizen,municipal,voting high Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements domain-research government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards procurement_compliance;security_clearance;accessibility_standards;transparency_requirements
5 edtech education,learning,student,teacher,curriculum,assessment,K-12,university,LMS medium Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity domain-research educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment
6 aerospace aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation high Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements domain-research + technical-model DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements safety_certification;simulation_validation;performance_requirements;export_compliance
7 automotive vehicle,car,autonomous,ADAS,automotive,driving,EV,charging high Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements domain-research ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards safety_standards;functional_safety;communication_protocols;certification_requirements
8 scientific research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI medium Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards technical-model scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements
9 legaltech legal,law,contract,compliance,litigation,patent,attorney,court high Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality domain-research legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology ethics_compliance;data_retention;confidentiality_measures;court_integration
10 insuretech insurance,claims,underwriting,actuarial,policy,risk,premium high Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting domain-research insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance
11 energy energy,utility,grid,solar,wind,power,electricity,oil,gas high Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems domain-research energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards grid_compliance;safety_protocols;environmental_compliance;operational_requirements
12 gaming game,player,gameplay,level,character,multiplayer,quest redirect REDIRECT TO GAME WORKFLOWS Game design game-brief NA NA
13 general low Standard requirements;Basic security;User experience;Performance General software practices continue software development best practices {date} standard_requirements

View File

@@ -0,0 +1,408 @@
# PRD Workflow - Intent-Driven Product Planning
<critical>The workflow execution engine is governed by: {project-root}/.bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>This workflow uses INTENT-DRIVEN PLANNING - adapt organically to product type and context</critical>
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>LIVING DOCUMENT: Write to PRD.md continuously as you discover - never wait until the end</critical>
<critical>GUIDING PRINCIPLE: Find and weave the product's magic throughout - what makes it special should inspire every section</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
<workflow>
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
<action>Check if {status_file} exists</action>
<action if="status file not found">Set standalone_mode = true</action>
<check if="status file found">
<action>Load the FULL file: {status_file}</action>
<action>Parse workflow_status section</action>
<action>Check status of "prd" workflow</action>
<action>Get project_track from YAML metadata</action>
<action>Find first non-completed workflow (next expected workflow)</action>
<check if="project_track is Quick Flow">
<output>**Quick Flow Track - Redirecting**
Quick Flow projects use tech-spec workflow for implementation-focused planning.
PRD is for BMad Method and Enterprise Method tracks that need comprehensive requirements.</output>
<action>Exit and suggest tech-spec workflow</action>
</check>
<check if="prd status is file path (already completed)">
<output>⚠️ PRD already completed: {{prd status}}</output>
<ask>Re-running will overwrite the existing PRD. Continue? (y/n)</ask>
<check if="n">
<output>Exiting. Use workflow-status to see your next step.</output>
<action>Exit workflow</action>
</check>
</check>
<action>Set standalone_mode = false</action>
</check>
</step>
<step n="1" goal="Discovery - Project, Domain, and Vision">
<action>Welcome {user_name} and begin comprehensive discovery, and then start to GATHER ALL CONTEXT:
1. Check workflow-status.yaml for project_context (if exists)
2. Look for existing documents (Product Brief, Domain Brief, research)
3. Detect project type AND domain complexity
Load references:
{installed_path}/project-types.csv
{installed_path}/domain-complexity.csv
Through natural conversation:
"Tell me about what you want to build - what problem does it solve and for whom?"
DUAL DETECTION:
Project type signals: API, mobile, web, CLI, SDK, SaaS
Domain complexity signals: medical, finance, government, education, aerospace
SPECIAL ROUTING:
If game detected → Inform user that game development requires the BMGD module (BMad Game Development)
If complex domain detected → Offer domain research options:
A) Run domain-research workflow (thorough)
B) Quick web search (basic)
C) User provides context
D) Continue with general knowledge
CAPTURE THE MAGIC EARLY with a few questions such as for example: "What excites you most about this product?", "What would make users love this?", "What's the moment that will make people go 'wow'?"
This excitement becomes the thread woven throughout the PRD.</action>
<template-output>vision_alignment</template-output>
<template-output>project_classification</template-output>
<template-output>project_type</template-output>
<template-output>domain_type</template-output>
<template-output>complexity_level</template-output>
<check if="complex domain">
<template-output>domain_context_summary</template-output>
</check>
<template-output>product_magic_essence</template-output>
<template-output>product_brief_path</template-output>
<template-output>domain_brief_path</template-output>
<template-output>research_documents</template-output>
</step>
<step n="2" goal="Success Definition">
<action>Define what winning looks like for THIS specific product
INTENT: Meaningful success criteria, not generic metrics
Adapt to context:
- Consumer: User love, engagement, retention
- B2B: ROI, efficiency, adoption
- Developer tools: Developer experience, community
- Regulated: Compliance, safety, validation
Make it specific:
- NOT: "10,000 users"
- BUT: "100 power users who rely on it daily"
- NOT: "99.9% uptime"
- BUT: "Zero data loss during critical operations"
Weave in the magic:
- "Success means users experience [that special moment] and [desired outcome]"</action>
<template-output>success_criteria</template-output>
<check if="business focus">
<template-output>business_metrics</template-output>
</check>
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
</step>
<step n="3" goal="Scope Definition">
<action>Smart scope negotiation - find the sweet spot
The Scoping Game:
1. "What must work for this to be useful?" → MVP
2. "What makes it competitive?" → Growth
3. "What's the dream version?" → Vision
Challenge scope creep conversationally:
- "Could that wait until after launch?"
- "Is that essential for proving the concept?"
For complex domains:
- Include compliance minimums in MVP
- Note regulatory gates between phases</action>
<template-output>mvp_scope</template-output>
<template-output>growth_features</template-output>
<template-output>vision_features</template-output>
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
</step>
<step n="4" goal="Domain-Specific Exploration" optional="true">
<action>Only if complex domain detected or domain-brief exists
Synthesize domain requirements that will shape everything:
- Regulatory requirements
- Compliance needs
- Industry standards
- Safety/risk factors
- Required validations
- Special expertise needed
These inform:
- What features are mandatory
- What NFRs are critical
- How to sequence development
- What validation is required</action>
<check if="complex domain">
<template-output>domain_considerations</template-output>
</check>
</step>
<step n="5" goal="Innovation Discovery" optional="true">
<action>Identify truly novel patterns if applicable
Listen for innovation signals:
- "Nothing like this exists"
- "We're rethinking how [X] works"
- "Combining [A] with [B] for the first time"
Explore deeply:
- What makes it unique?
- What assumption are you challenging?
- How do we validate it?
- What's the fallback?
<WebSearch if="novel">{concept} innovations {date}</WebSearch></action>
<check if="innovation detected">
<template-output>innovation_patterns</template-output>
<template-output>validation_approach</template-output>
</check>
</step>
<step n="6" goal="Project-Specific Deep Dive">
<action>Based on detected project type, dive deep into specific needs
Load project type requirements from CSV and expand naturally.
FOR API/BACKEND:
- Map out endpoints, methods, parameters
- Define authentication and authorization
- Specify error codes and rate limits
- Document data schemas
FOR MOBILE:
- Platform requirements (iOS/Android/both)
- Device features needed
- Offline capabilities
- Store compliance
FOR SAAS B2B:
- Multi-tenant architecture
- Permission models
- Subscription tiers
- Critical integrations
[Continue for other types...]
Always relate back to the product magic:
"How does [requirement] enhance [the special thing]?"</action>
<template-output>project_type_requirements</template-output>
<!-- Dynamic sections based on project type -->
<check if="API/Backend project">
<template-output>endpoint_specification</template-output>
<template-output>authentication_model</template-output>
</check>
<check if="Mobile project">
<template-output>platform_requirements</template-output>
<template-output>device_features</template-output>
</check>
<check if="SaaS B2B project">
<template-output>tenant_model</template-output>
<template-output>permission_matrix</template-output>
</check>
</step>
<step n="7" goal="UX Principles" if="project has UI or UX">
<action>Only if product has a UI
Light touch on UX - not full design:
- Visual personality
- Key interaction patterns
- Critical user flows
"How should this feel to use?"
"What's the vibe - professional, playful, minimal?"
Connect to the magic:
"The UI should reinforce [the special moment] through [design approach]"</action>
<check if="has UI">
<template-output>ux_principles</template-output>
<template-output>key_interactions</template-output>
</check>
</step>
<step n="8" goal="Functional Requirements Synthesis">
<action>Transform everything discovered into clear functional requirements
Pull together:
- Core features from scope
- Domain-mandated features
- Project-type specific needs
- Innovation requirements
Organize by capability, not technology:
- User Management (not "auth system")
- Content Discovery (not "search algorithm")
- Team Collaboration (not "websockets")
Each requirement should:
- Be specific and measurable
- Connect to user value
- Include acceptance criteria
- Note domain constraints
The magic thread:
Highlight which requirements deliver the special experience</action>
<template-output>functional_requirements_complete</template-output>
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
</step>
<step n="9" goal="Non-Functional Requirements Discovery">
<action>Only document NFRs that matter for THIS product
Performance: Only if user-facing impact
Security: Only if handling sensitive data
Scale: Only if growth expected
Accessibility: Only if broad audience
Integration: Only if connecting systems
For each NFR:
- Why it matters for THIS product
- Specific measurable criteria
- Domain-driven requirements
Skip categories that don't apply!</action>
<!-- Only output sections that were discussed -->
<check if="performance matters">
<template-output>performance_requirements</template-output>
</check>
<check if="security matters">
<template-output>security_requirements</template-output>
</check>
<check if="scale matters">
<template-output>scalability_requirements</template-output>
</check>
<check if="accessibility matters">
<template-output>accessibility_requirements</template-output>
</check>
<check if="integration matters">
<template-output>integration_requirements</template-output>
</check>
</step>
<step n="10" goal="Review PRD and transition to epics">
<action>Review the PRD we've built together
"Let's review what we've captured:
- Vision: [summary]
- Success: [key metrics]
- Scope: [MVP highlights]
- Requirements: [count] functional, [count] non-functional
- Special considerations: [domain/innovation]
Does this capture your product vision?"</action>
<template-output>prd_summary</template-output>
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
<action>After PRD review and refinement complete:
"Excellent! Now we need to break these requirements into implementable epics and stories.
For the epic breakdown, you have two options:
1. Start a new session focused on epics (recommended for complex projects)
2. Continue here (I'll transform requirements into epics now)
Which would you prefer?"
If new session:
"To start epic planning in a new session:
1. Save your work here
2. Start fresh and run: workflow epics-stories
3. It will load your PRD and create the epic breakdown
This keeps each session focused and manageable."
If continue:
"Let's continue with epic breakdown here..."
[Proceed with epics-stories subworkflow]
Set project_track based on workflow status (BMad Method or Enterprise Method)
Generate epic_details for the epics breakdown document</action>
<template-output>project_track</template-output>
<template-output>epic_details</template-output>
</step>
<step n="11" goal="Complete PRD and suggest next steps">
<template-output>product_magic_summary</template-output>
<check if="standalone_mode != true">
<action>Load the FULL file: {status_file}</action>
<action>Update workflow_status["prd"] = "{default_output_file}"</action>
<action>Save file, preserving ALL comments and structure</action>
</check>
<output>**✅ PRD Complete, {user_name}!**
Your product requirements are documented and ready for implementation.
**Created:**
- **PRD.md** - Complete requirements adapted to {project_type} and {domain}
**Next Steps:**
1. **Epic Breakdown** (Required)
Run: `workflow create-epics-and-stories` to decompose requirements into implementable stories
2. **UX Design** (If UI exists)
Run: `workflow ux-design` for detailed user experience design
3. **Architecture** (Recommended)
Run: `workflow create-architecture` for technical architecture decisions
The magic of your product - {product_magic_summary} - is woven throughout the PRD and will guide all subsequent work.
</output>
</step>
</workflow>

View File

@@ -0,0 +1,237 @@
# {{project_name}} - Product Requirements Document
**Author:** {{user_name}}
**Date:** {{date}}
**Version:** 1.0
---
## Executive Summary
{{vision_alignment}}
### What Makes This Special
{{product_magic_essence}}
---
## Project Classification
**Technical Type:** {{project_type}}
**Domain:** {{domain_type}}
**Complexity:** {{complexity_level}}
{{project_classification}}
{{#if domain_context_summary}}
### Domain Context
{{domain_context_summary}}
{{/if}}
---
## Success Criteria
{{success_criteria}}
{{#if business_metrics}}
### Business Metrics
{{business_metrics}}
{{/if}}
---
## Product Scope
### MVP - Minimum Viable Product
{{mvp_scope}}
### Growth Features (Post-MVP)
{{growth_features}}
### Vision (Future)
{{vision_features}}
---
{{#if domain_considerations}}
## Domain-Specific Requirements
{{domain_considerations}}
This section shapes all functional and non-functional requirements below.
{{/if}}
---
{{#if innovation_patterns}}
## Innovation & Novel Patterns
{{innovation_patterns}}
### Validation Approach
{{validation_approach}}
{{/if}}
---
{{#if project_type_requirements}}
## {{project_type}} Specific Requirements
{{project_type_requirements}}
{{#if endpoint_specification}}
### API Specification
{{endpoint_specification}}
{{/if}}
{{#if authentication_model}}
### Authentication & Authorization
{{authentication_model}}
{{/if}}
{{#if platform_requirements}}
### Platform Support
{{platform_requirements}}
{{/if}}
{{#if device_features}}
### Device Capabilities
{{device_features}}
{{/if}}
{{#if tenant_model}}
### Multi-Tenancy Architecture
{{tenant_model}}
{{/if}}
{{#if permission_matrix}}
### Permissions & Roles
{{permission_matrix}}
{{/if}}
{{/if}}
---
{{#if ux_principles}}
## User Experience Principles
{{ux_principles}}
### Key Interactions
{{key_interactions}}
{{/if}}
---
## Functional Requirements
{{functional_requirements_complete}}
---
## Non-Functional Requirements
{{#if performance_requirements}}
### Performance
{{performance_requirements}}
{{/if}}
{{#if security_requirements}}
### Security
{{security_requirements}}
{{/if}}
{{#if scalability_requirements}}
### Scalability
{{scalability_requirements}}
{{/if}}
{{#if accessibility_requirements}}
### Accessibility
{{accessibility_requirements}}
{{/if}}
{{#if integration_requirements}}
### Integration
{{integration_requirements}}
{{/if}}
{{#if no_nfrs}}
_No specific non-functional requirements identified for this project type._
{{/if}}
---
## Implementation Planning
### Epic Breakdown Required
Requirements must be decomposed into epics and bite-sized stories (200k context limit).
**Next Step:** Run `workflow epics-stories` to create the implementation breakdown.
---
## References
{{#if product_brief_path}}
- Product Brief: {{product_brief_path}}
{{/if}}
{{#if domain_brief_path}}
- Domain Brief: {{domain_brief_path}}
{{/if}}
{{#if research_documents}}
- Research: {{research_documents}}
{{/if}}
---
## Next Steps
1. **Epic & Story Breakdown** - Run: `workflow epics-stories`
2. **UX Design** (if UI) - Run: `workflow ux-design`
3. **Architecture** - Run: `workflow create-architecture`
---
_This PRD captures the essence of {{project_name}} - {{product_magic_summary}}_
_Created through collaborative discovery between {{user_name}} and AI facilitator._

View File

@@ -0,0 +1,11 @@
project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
game,"game,player,gameplay,level,character","REDIRECT TO GAME WORKFLOWS","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"
1 project_type detection_signals key_questions required_sections skip_sections web_search_triggers innovation_signals
2 api_backend API,REST,GraphQL,backend,service,endpoints Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed? endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs ux_ui;visual_design;user_journeys framework best practices;OpenAPI standards API composition;New protocol
3 mobile_app iOS,Android,app,mobile,iPhone,iPad Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance? platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance desktop_features;cli_commands app store guidelines;platform requirements Gesture innovation;AR/VR features
4 saas_b2b SaaS,B2B,platform,dashboard,teams,enterprise Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance? tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs cli_interface;mobile_first compliance requirements;integration guides Workflow automation;AI agents
5 developer_tool SDK,library,package,npm,pip,framework Language support?;Package managers?;IDE integration?;Documentation?;Examples? language_matrix;installation_methods;api_surface;code_examples;migration_guide visual_design;store_compliance package manager best practices;API design patterns New paradigm;DSL creation
6 cli_tool CLI,command,terminal,bash,script Interactive or scriptable?;Output formats?;Config method?;Shell completion? command_structure;output_formats;config_schema;scripting_support visual_design;ux_principles;touch_interactions CLI design patterns;shell integration Natural language CLI;AI commands
7 web_app website,webapp,browser,SPA,PWA SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility? browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level native_features;cli_commands web standards;WCAG guidelines New interaction;WebAssembly use
8 game game,player,gameplay,level,character REDIRECT TO GAME WORKFLOWS game-brief;GDD most_sections game design patterns Novel mechanics;Genre mixing
9 desktop_app desktop,Windows,Mac,Linux,native Cross-platform?;Auto-update?;System integration?;Offline? platform_support;system_integration;update_strategy;offline_capabilities web_seo;mobile_features desktop guidelines;platform requirements Desktop AI;System automation
10 iot_embedded IoT,embedded,device,sensor,hardware Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates? hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism visual_ui;browser_support IoT standards;protocol specs Edge AI;New sensors
11 blockchain_web3 blockchain,crypto,DeFi,NFT,smart contract Chain selection?;Wallet integration?;Gas optimization?;Security audit? chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization traditional_auth;centralized_db blockchain standards;security patterns Novel tokenomics;DAO structure

View File

@@ -0,0 +1,46 @@
# Product Requirements Document (PRD) Workflow
name: prd
description: "Unified PRD workflow for BMad Method and Enterprise Method tracks. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Quick Flow track uses tech-spec workflow."
author: "BMad"
# Critical variables from config
config_source: "{project-root}/.bmad/bmm/config.yaml"
project_name: "{config_source}:project_name"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level"
date: system-generated
# Workflow components
installed_path: "{project-root}/.bmad/bmm/workflows/2-plan-workflows/prd"
instructions: "{installed_path}/instructions.md"
# Templates
prd_template: "{installed_path}/prd-template.md"
# Output files
status_file: "{output_folder}/bmm-workflow-status.yaml"
default_output_file: "{output_folder}/PRD.md"
# Recommended input documents
recommended_inputs:
- product_brief: "{output_folder}/product-brief.md"
- market_research: "{output_folder}/market-research.md"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
input_file_patterns:
product_brief:
whole: "{output_folder}/*brief*.md"
sharded: "{output_folder}/*brief*/index.md"
research:
whole: "{output_folder}/*research*.md"
sharded: "{output_folder}/*research*/index.md"
document_project:
sharded: "{output_folder}/docs/index.md"
standalone: true