mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00:00
feat(workflows): Implement intelligent file discovery protocol and Phase 4 BMGD workflows
## Core Workflow Engine Enhancements
### discover_inputs Protocol (MAJOR)
- Added reusable `discover_inputs` protocol to workflow.xml for intelligent file loading
- Supports three loading strategies:
- FULL_LOAD: Load all shards for PRD, Architecture, UX (changed pattern from /index.md to /*/*.md)
- SELECTIVE_LOAD: Load specific shard via template variable (e.g., epic-{{epic_num}}.md)
- INDEX_GUIDED: Load index, analyze TOC, intelligently load relevant docs (with "DO NOT BE LAZY" mandate)
- Auto-discovers whole vs sharded documents with proper fallback
- Provides transparent reporting of loaded content with file counts
- Invoked via <invoke-protocol name="discover_inputs" /> tag in workflow instructions
### Advanced Elicitation Improvements
- Renamed adv-elicit.xml to advanced-elicitation.xml for clarity
- Updated all references across agents and commands
### Shard Document Tool Enhancement
- Added Step 6: Handle Original Document with three options:
- [d] Delete - Remove original (recommended, prevents confusion)
- [m] Move to archive - Backup original to archive folder
- [k] Keep - Warning about defeating sharding purpose
- Prevents issue where both whole and sharded versions exist, confusing discover_inputs protocol
## BMM Module - Input File Pattern Standardization
### Phase 1 - Analysis (1 workflow)
- product-brief: Added load_strategy (FULL_LOAD for research/brainstorming, INDEX_GUIDED for document_project)
- Updated instructions.md to use invoke-protocol, replaced manual fuzzy matching
### Phase 2 - Planning (4 workflows)
- prd: Added load_strategy, updated instructions to reference {product_brief_content}, {research_content}
- create-ux-design: Added load_strategy, removed fuzzy matching from instructions
- tech-spec: Added load_strategy for brownfield context discovery
- All epics patterns updated to support SELECTIVE_LOAD for specific epic shards
### Phase 3 - Solutioning (2 workflows)
- architecture: Added load_strategy, updated instructions to use pre-loaded {prd_content}, {epics_content}, {ux_design_content}
- solutioning-gate-check: Added load_strategy, replaced manual discovery with protocol invocation
### Phase 4 - Implementation (8 workflows)
- code-review: Added load_strategy, fixed sharded patterns to /*/*.md, added step 1.5 for protocol
- correct-course: Added complete input_file_patterns section (was missing), added step 0.5
- create-story: Added load_strategy, updated to SELECTIVE_LOAD for epics, added step 1.5
- dev-story: Added complete input_file_patterns section (was missing), added step 0.5
- epic-tech-context: Added load_strategy, updated PRD extraction to use {prd_content}, added step 1.5
- retrospective: Added load_strategy for architecture/prd (FULL_LOAD), epics (SELECTIVE_LOAD), added step 0.5
- sprint-planning: Fixed sharded pattern to load ALL epics (/*/*.md), added step 0.5
- story-context: Added load_strategy, updated doc collection to reference pre-loaded content, added step 1.5
### Sprint Artifacts Path Corrections
- story-done: Added missing sprint_artifacts variable, fixed sprint_status path from {context_dir} to {sprint_artifacts}
- story-ready: Added missing sprint_artifacts variable
- story-context: Fixed undefined {context_dir} -> {sprint_artifacts}
- correct-course: Added sprint_artifacts and sprint_status variables
## BMGD Module - Phase 4 Production Workflows (NEW)
Added complete Phase 4 implementation workflows for game development:
- code-review: Senior developer review for completed game features
- correct-course: Sprint change management for game projects
- create-story: Story generation for game mechanics/features
- dev-story: Feature implementation workflow
- epic-tech-context: Technical spec generation per game epic
- retrospective: Epic completion review and lessons learned
- sprint-planning: Game development sprint status tracking
- story-context: Dynamic context assembly for game stories
- story-done: Story completion workflow
- story-ready: Story readiness workflow
All BMGD workflows follow BMM patterns with game-specific adaptations.
## Agent Updates
### BMM Agents
- Updated all 7 BMM agents (analyst, architect, dev, pm, sm, tea, tech-writer, ux-designer)
- Standardized web bundle configurations
### BMGD Agents
- Updated 4 game development agents (game-architect, game-designer, game-dev, game-scrum-master)
- Aligned with BMM agent structure
### CIS Agents
- Updated 5 creative intelligence agents for consistency
## Documentation & Configuration
- Updated CHANGELOG.md with Phase 4 workflow additions
- Updated files-manifest.csv and task-manifest.csv
- Updated .claude commands for all agents
- Fixed formatting issues from previous commits
## Breaking Changes
NONE - All changes are backward compatible. Workflows without input_file_patterns continue to work.
Workflows with input_file_patterns now benefit from intelligent auto-loading.
## Migration Notes
Existing workflows can gradually adopt discover_inputs protocol by:
1. Adding load_strategy to existing input_file_patterns in workflow.yaml
2. Adding <invoke-protocol name="discover_inputs" /> step in instructions.md
3. Replacing manual file loading with references to {pattern_name_content} variables
This commit is contained in:
Brian Madison
@@ -51,10 +51,15 @@
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="0.5" goal="Discover and load input documents">
|
||||
<invoke-protocol name="discover_inputs" />
|
||||
<note>After discovery, these content variables are available: {prd_content}, {product_brief_content}, {epics_content}, {brainstorming_content}, {document_project_content}</note>
|
||||
</step>
|
||||
|
||||
<step n="1a" goal="Confirm project understanding or gather basic context">
|
||||
<critical>A UX designer must understand the WHY before designing the HOW</critical>
|
||||
|
||||
<action>Attempt to load context documents using fuzzy matching: - PRD: {prd_file} - Product Brief: {brief_file} - Brainstorming: {brainstorm_file}
|
||||
<action>Review loaded context from Step 0.5: {prd_content}, {product_brief_content}, {epics_content}, {brainstorming_content}
|
||||
</action>
|
||||
|
||||
<check if="documents_found">
|
||||
|
||||
@@ -25,25 +25,31 @@ brainstorm_file: "{output_folder}/brainstorming.md or brainstorm.md or ideation.
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
|
||||
input_file_patterns:
|
||||
prd:
|
||||
whole: "{output_folder}/*prd*.md"
|
||||
sharded: "{output_folder}/*prd*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
product_brief:
|
||||
whole: "{output_folder}/*brief*.md"
|
||||
sharded: "{output_folder}/*brief*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
epics:
|
||||
whole: "{output_folder}/*epic*.md"
|
||||
sharded: "{output_folder}/*epic*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
brainstorming:
|
||||
whole: "{output_folder}/*brainstorm*.md"
|
||||
sharded: "{output_folder}/*brainstorm*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
load_strategy: "INDEX_GUIDED"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/2-plan-workflows/create-ux-design"
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
### Core Sections Present
|
||||
|
||||
- [ ] Executive Summary with vision alignment
|
||||
- [ ] Product magic essence clearly articulated
|
||||
- [ ] Product differentiator clearly articulated
|
||||
- [ ] Project classification (type, domain, complexity)
|
||||
- [ ] Success criteria defined
|
||||
- [ ] Product scope (MVP, Growth, Vision) clearly delineated
|
||||
@@ -38,7 +38,7 @@
|
||||
|
||||
- [ ] No unfilled template variables ({{variable}})
|
||||
- [ ] All variables properly populated with meaningful content
|
||||
- [ ] Product magic woven throughout (not just stated once)
|
||||
- [ ] Product differentiator reflected throughout (not just stated once)
|
||||
- [ ] Language is clear, specific, and measurable
|
||||
- [ ] Project type correctly identified and sections match
|
||||
- [ ] Domain complexity appropriately addressed
|
||||
@@ -210,7 +210,7 @@
|
||||
### Alignment Checks
|
||||
|
||||
- [ ] Success metrics in PRD align with story outcomes
|
||||
- [ ] Product magic articulated in PRD reflected in epic goals
|
||||
- [ ] Product differentiator articulated in PRD reflected in epic goals
|
||||
- [ ] Technical preferences in PRD align with story implementation hints
|
||||
- [ ] Scope boundaries consistent across all documents
|
||||
|
||||
|
||||
@@ -11,10 +11,24 @@
|
||||
|
||||
This document provides the complete epic and story breakdown for {{project_name}}, decomposing the requirements from the [PRD](./PRD.md) into implementable stories.
|
||||
|
||||
**Living Document Notice:** This is the initial version. It will be updated after UX Design and Architecture workflows add interaction and technical details to stories.
|
||||
|
||||
{{epics_summary}}
|
||||
|
||||
---
|
||||
|
||||
## Functional Requirements Inventory
|
||||
|
||||
{{fr_inventory}}
|
||||
|
||||
---
|
||||
|
||||
## FR Coverage Map
|
||||
|
||||
{{fr_coverage_map}}
|
||||
|
||||
---
|
||||
|
||||
<!-- Repeat for each epic (N = 1, 2, 3...) -->
|
||||
|
||||
## Epic {{N}}: {{epic_title_N}}
|
||||
@@ -49,4 +63,18 @@ So that {{value_benefit}}.
|
||||
|
||||
---
|
||||
|
||||
## FR Coverage Matrix
|
||||
|
||||
{{fr_coverage_matrix}}
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
{{epic_breakdown_summary}}
|
||||
|
||||
---
|
||||
|
||||
_For implementation: Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown._
|
||||
|
||||
_This document will be updated after UX Design and Architecture workflows to incorporate interaction details and technical decisions._
|
||||
|
||||
@@ -4,6 +4,11 @@
|
||||
<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>BMAD METHOD WORKFLOW POSITION: This is the FIRST PASS at epic breakdown</critical>
|
||||
<critical>After this workflow: UX Design will add interaction details → UPDATE epics.md</critical>
|
||||
<critical>After UX: Architecture will add technical decisions → UPDATE epics.md AGAIN</critical>
|
||||
<critical>Phase 4 Implementation pulls context from: PRD + epics.md + UX + Architecture</critical>
|
||||
<critical>This is a LIVING DOCUMENT that evolves through the BMad Method workflow chain</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>
|
||||
@@ -20,21 +25,49 @@ Load required documents (fuzzy match, handle both whole and sharded):
|
||||
- domain-brief.md (if exists)
|
||||
- product-brief.md (if exists)
|
||||
|
||||
**CRITICAL - PRD FRs Are Now Flat and Strategic:**
|
||||
|
||||
The PRD contains FLAT, capability-level functional requirements (FR1, FR2, FR3...).
|
||||
These are STRATEGIC (WHAT capabilities exist), NOT tactical (HOW they're implemented).
|
||||
|
||||
Example PRD FRs:
|
||||
|
||||
- FR1: Users can create accounts with email or social authentication
|
||||
- FR2: Users can log in securely and maintain sessions
|
||||
- FR6: Users can create, edit, and delete content items
|
||||
|
||||
**Your job in THIS workflow:**
|
||||
|
||||
1. Map each FR to one or more epics
|
||||
2. Break each FR into stories with DETAILED acceptance criteria
|
||||
3. Add ALL the implementation details that were intentionally left out of PRD
|
||||
|
||||
Extract from PRD:
|
||||
|
||||
- All functional requirements
|
||||
- ALL functional requirements (flat numbered list)
|
||||
- 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)
|
||||
- Product differentiator (what makes it special)
|
||||
- Technical constraints
|
||||
- User types and their goals
|
||||
- Success criteria</action>
|
||||
</step>
|
||||
- Success criteria
|
||||
|
||||
**Create FR Inventory:**
|
||||
|
||||
List all FRs to ensure coverage:
|
||||
|
||||
- FR1: [description]
|
||||
- FR2: [description]
|
||||
- ...
|
||||
- FRN: [description]
|
||||
|
||||
This inventory will be used to validate complete coverage in Step 4.
|
||||
</action>
|
||||
|
||||
<template-output>fr_inventory</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Propose epic structure from natural groupings">
|
||||
<action>Analyze requirements and identify natural epic boundaries
|
||||
@@ -76,18 +109,56 @@ Present proposed epic structure showing:
|
||||
|
||||
- Epic titles with clear value statements
|
||||
- High-level scope of each epic
|
||||
- **FR COVERAGE MAP: Which FRs does each epic address?**
|
||||
- Example: "Epic 1 (Foundation): Covers infrastructure needs for all FRs"
|
||||
- Example: "Epic 2 (User Management): FR1, FR2, FR3, FR4, FR5"
|
||||
- Example: "Epic 3 (Content System): FR6, FR7, FR8, FR9"
|
||||
- Suggested sequencing
|
||||
- Why this grouping makes sense</action>
|
||||
- Why this grouping makes sense
|
||||
|
||||
**Validate FR Coverage:**
|
||||
|
||||
Check that EVERY FR from Step 1 inventory is mapped to at least one epic.
|
||||
If any FRs are unmapped, add them now or explain why they're deferred.
|
||||
</action>
|
||||
|
||||
<template-output>epics_summary</template-output>
|
||||
<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
|
||||
<template-output>fr_coverage_map</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Decompose each epic into bite-sized stories" repeat="for-each-epic">
|
||||
<step n="3" goal="Decompose each epic into bite-sized stories with DETAILED AC" repeat="for-each-epic">
|
||||
<action>Break down Epic {{N}} into small, implementable stories
|
||||
|
||||
INTENT: Create stories sized for single dev agent completion
|
||||
|
||||
**CRITICAL - ALTITUDE SHIFT FROM PRD:**
|
||||
|
||||
PRD FRs are STRATEGIC (WHAT capabilities):
|
||||
|
||||
- ✅ "Users can create accounts"
|
||||
|
||||
Epic Stories are TACTICAL (HOW it's implemented):
|
||||
|
||||
- Email field with RFC 5322 validation
|
||||
- Password requirements: 8+ chars, 1 uppercase, 1 number, 1 special
|
||||
- Password strength meter with visual feedback
|
||||
- Email verification within 15 minutes
|
||||
- reCAPTCHA v3 integration
|
||||
- Account creation completes in < 2 seconds
|
||||
- Mobile responsive with 44x44px touch targets
|
||||
- WCAG 2.1 AA compliant
|
||||
|
||||
**THIS IS WHERE YOU ADD ALL THE DETAILS LEFT OUT OF PRD:**
|
||||
|
||||
- UI specifics (exact field counts, validation rules, layout details)
|
||||
- Performance targets (< 2s, 60fps, etc.)
|
||||
- Technical implementation hints (libraries, patterns, APIs)
|
||||
- Edge cases (what happens when...)
|
||||
- Validation rules (regex patterns, constraints)
|
||||
- Error handling (specific error messages, retry logic)
|
||||
- Accessibility requirements (ARIA labels, keyboard nav, screen readers)
|
||||
- Platform specifics (mobile responsive, browser support)
|
||||
|
||||
For each epic, generate:
|
||||
|
||||
- Epic title as `epic_title_{{N}}`
|
||||
@@ -138,32 +209,84 @@ For each story in epic {{N}}, output variables following this pattern:
|
||||
<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_folder}/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Review and finalize epic breakdown">
|
||||
<step n="4" goal="Review initial epic breakdown and prepare for updates">
|
||||
<action>Review the complete epic breakdown for quality and completeness
|
||||
|
||||
Validate:
|
||||
**Validate FR Coverage:**
|
||||
|
||||
Create FR Coverage Matrix showing each FR mapped to epic(s) and story(ies):
|
||||
|
||||
- FR1: [description] → Epic X, Story X.Y
|
||||
- FR2: [description] → Epic X, Story X.Z
|
||||
- FR3: [description] → Epic Y, Story Y.A
|
||||
- ...
|
||||
- FRN: [description] → Epic Z, Story Z.B
|
||||
|
||||
Confirm: EVERY FR from Step 1 inventory is covered by at least one story.
|
||||
If any FRs are missing, add stories now.
|
||||
|
||||
**Validate Story Quality:**
|
||||
|
||||
- All functional requirements from PRD are covered by stories
|
||||
- Epic 1 establishes proper foundation
|
||||
- All stories are vertically sliced
|
||||
- No forward dependencies exist
|
||||
- Epic 1 establishes proper foundation (if greenfield)
|
||||
- All stories are vertically sliced (deliver complete functionality, not just one layer)
|
||||
- No forward dependencies exist (only backward references)
|
||||
- Story sizing is appropriate for single-session completion
|
||||
- BDD acceptance criteria are clear and testable
|
||||
- Details added (what was missing from PRD FRs: UI specifics, performance targets, etc.)
|
||||
- Domain/compliance requirements are properly distributed
|
||||
- Sequencing enables incremental value delivery
|
||||
|
||||
**BMad Method Next Steps:**
|
||||
|
||||
This epic breakdown is the INITIAL VERSION. It will be updated as you progress:
|
||||
|
||||
1. **After UX Design Workflow:**
|
||||
- UX Designer will design interactions for capabilities
|
||||
- UPDATE story acceptance criteria with UX specs (mockup references, flow details)
|
||||
- Add interaction patterns, visual design decisions, responsive breakpoints
|
||||
|
||||
2. **After Architecture Workflow:**
|
||||
- Architect will define technical implementation approach
|
||||
- UPDATE story technical notes with architecture decisions
|
||||
- Add references to data models, API contracts, tech stack choices, deployment patterns
|
||||
|
||||
3. **During Phase 4 Implementation:**
|
||||
- Each story pulls context from: PRD (why) + epics.md (what/how) + UX (interactions) + Architecture (technical)
|
||||
- Stories may be further refined as implementation uncovers edge cases
|
||||
- This document remains the single source of truth for story details
|
||||
|
||||
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>
|
||||
- All FRs covered by stories (validated via coverage matrix)
|
||||
- Story breakdown is actionable with detailed acceptance criteria
|
||||
- Ready for UX Design workflow (next BMad Method step)
|
||||
</action>
|
||||
|
||||
<template-output>epic_breakdown_summary</template-output>
|
||||
<template-output>fr_coverage_matrix</template-output>
|
||||
|
||||
<output>**✅ Epic Breakdown Complete (Initial Version)**
|
||||
|
||||
**Created:** epics.md with epic and story breakdown
|
||||
|
||||
**FR Coverage:** All functional requirements from PRD mapped to stories (see coverage matrix in document)
|
||||
|
||||
**Next Steps in BMad Method:**
|
||||
|
||||
1. **UX Design** (if UI exists) - Run: `workflow ux-design`
|
||||
→ Will add interaction details to stories in epics.md
|
||||
|
||||
2. **Architecture** - Run: `workflow create-architecture`
|
||||
→ Will add technical details to stories in epics.md
|
||||
|
||||
3. **Phase 4 Implementation** - Stories ready for context assembly
|
||||
|
||||
**Important:** This is a living document that will be updated as you progress through the workflow chain. The epics.md file will evolve with UX and Architecture inputs before implementation begins.
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 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"
|
||||
description: "Transform PRD requirements into bite-sized stories organized into deliverable functional epics. This workflow takes a Product Requirements Document (PRD) and breaks it down into epics and user stories that can be easily assigned to development teams. It ensures that all functional requirements are captured in a structured format, making it easier for teams to understand and implement the necessary features."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
@@ -25,11 +25,9 @@ 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"
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<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>GUIDING PRINCIPLE: Identify what makes this product special and ensure it's reflected throughout the PRD</critical>
|
||||
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
|
||||
|
||||
<workflow>
|
||||
@@ -44,10 +44,15 @@ PRD is for BMad Method and Enterprise Method tracks that need comprehensive requ
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="0.5" goal="Discover and load input documents">
|
||||
<invoke-protocol name="discover_inputs" />
|
||||
<note>After discovery, these content variables are available: {product_brief_content}, {research_content}, {document_project_content}</note>
|
||||
</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)
|
||||
2. Review loaded content: {product_brief_content}, {research_content}, {document_project_content} (auto-loaded in Step 0.5)
|
||||
3. Detect project type AND domain complexity
|
||||
|
||||
Load references:
|
||||
@@ -69,9 +74,9 @@ 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'?"
|
||||
IDENTIFY WHAT MAKES IT SPECIAL early with questions such as: "What excites you most about this product?", "What would make users love this?", "What's the unique value or compelling moment?"
|
||||
|
||||
This excitement becomes the thread woven throughout the PRD.</action>
|
||||
This becomes a thread that connects throughout the PRD.</action>
|
||||
|
||||
<template-output>vision_alignment</template-output>
|
||||
<template-output>project_classification</template-output>
|
||||
@@ -81,7 +86,7 @@ This excitement becomes the thread woven throughout the PRD.</action>
|
||||
<check if="complex domain">
|
||||
<template-output>domain_context_summary</template-output>
|
||||
</check>
|
||||
<template-output>product_magic_essence</template-output>
|
||||
<template-output>product_differentiator</template-output>
|
||||
<template-output>product_brief_path</template-output>
|
||||
<template-output>domain_brief_path</template-output>
|
||||
<template-output>research_documents</template-output>
|
||||
@@ -107,15 +112,14 @@ Make it specific:
|
||||
- NOT: "99.9% uptime"
|
||||
- BUT: "Zero data loss during critical operations"
|
||||
|
||||
Weave in the magic:
|
||||
Connect to what makes the product special:
|
||||
|
||||
- "Success means users experience [that special moment] and [desired outcome]"</action>
|
||||
- "Success means users experience [key value moment] and achieve [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_folder}/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Scope Definition">
|
||||
@@ -140,7 +144,6 @@ For complex domains:
|
||||
<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_folder}/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Domain-Specific Exploration" optional="true">
|
||||
@@ -219,8 +222,8 @@ FOR SAAS B2B:
|
||||
|
||||
[Continue for other types...]
|
||||
|
||||
Always relate back to the product magic:
|
||||
"How does [requirement] enhance [the special thing]?"</action>
|
||||
Always connect requirements to product value:
|
||||
"How does [requirement] support the product's core value proposition?"</action>
|
||||
|
||||
<template-output>project_type_requirements</template-output>
|
||||
|
||||
@@ -253,8 +256,8 @@ Light touch on UX - not full design:
|
||||
"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>
|
||||
Connect UX to product vision:
|
||||
"The UI should reinforce [core value proposition] through [design approach]"</action>
|
||||
|
||||
<check if="has UI">
|
||||
<template-output>ux_principles</template-output>
|
||||
@@ -263,33 +266,148 @@ Connect to the magic:
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Functional Requirements Synthesis">
|
||||
<action>Transform everything discovered into clear functional requirements
|
||||
<critical>This section is THE CAPABILITY CONTRACT for all downstream work</critical>
|
||||
<critical>UX designers will ONLY design what's listed here</critical>
|
||||
<critical>Architects will ONLY support what's listed here</critical>
|
||||
<critical>Epic breakdown will ONLY implement what's listed here</critical>
|
||||
<critical>If a capability is missing from FRs, it will NOT exist in the final product</critical>
|
||||
|
||||
Pull together:
|
||||
<action>Before writing FRs, understand their PURPOSE and USAGE:
|
||||
|
||||
- Core features from scope
|
||||
- Domain-mandated features
|
||||
- Project-type specific needs
|
||||
- Innovation requirements
|
||||
**Purpose:**
|
||||
FRs define WHAT capabilities the product must have. They are the complete inventory
|
||||
of user-facing and system capabilities that deliver the product vision.
|
||||
|
||||
Organize by capability, not technology:
|
||||
**How They Will Be Used:**
|
||||
|
||||
- User Management (not "auth system")
|
||||
- Content Discovery (not "search algorithm")
|
||||
- Team Collaboration (not "websockets")
|
||||
1. UX Designer reads FRs → designs interactions for each capability
|
||||
2. Architect reads FRs → designs systems to support each capability
|
||||
3. PM reads FRs → creates epics and stories to implement each capability
|
||||
4. Dev Agent reads assembled context → implements stories based on FRs
|
||||
|
||||
Each requirement should:
|
||||
**Critical Property - COMPLETENESS:**
|
||||
Every capability discussed in vision, scope, domain requirements, and project-specific
|
||||
sections MUST be represented as an FR. Missing FRs = missing capabilities.
|
||||
|
||||
- Be specific and measurable
|
||||
- Connect to user value
|
||||
- Include acceptance criteria
|
||||
- Note domain constraints
|
||||
**Critical Property - ALTITUDE:**
|
||||
FRs state WHAT capability exists and WHO it serves, NOT HOW it's implemented or
|
||||
specific UI/UX details. Those come later from UX and Architecture.
|
||||
</action>
|
||||
|
||||
The magic thread:
|
||||
Highlight which requirements deliver the special experience</action>
|
||||
<action>Transform everything discovered into comprehensive functional requirements:
|
||||
|
||||
**Coverage - Pull from EVERYWHERE:**
|
||||
|
||||
- Core features from MVP scope → FRs
|
||||
- Growth features → FRs (marked as post-MVP if needed)
|
||||
- Domain-mandated features → FRs
|
||||
- Project-type specific needs → FRs
|
||||
- Innovation requirements → FRs
|
||||
- Anti-patterns (explicitly NOT doing) → Note in FR section if needed
|
||||
|
||||
**Organization - Group by CAPABILITY AREA:**
|
||||
Don't organize by technology or layer. Group by what users/system can DO:
|
||||
|
||||
- ✅ "User Management" (not "Authentication System")
|
||||
- ✅ "Content Discovery" (not "Search Algorithm")
|
||||
- ✅ "Team Collaboration" (not "WebSocket Infrastructure")
|
||||
|
||||
**Format - Flat, Numbered List:**
|
||||
Each FR is one clear capability statement:
|
||||
|
||||
- FR#: [Actor] can [capability] [context/constraint if needed]
|
||||
- Number sequentially (FR1, FR2, FR3...)
|
||||
- Aim for 20-50 FRs for typical projects (fewer for simple, more for complex)
|
||||
|
||||
**Altitude Check:**
|
||||
Each FR should answer "WHAT capability exists?" NOT "HOW is it implemented?"
|
||||
|
||||
- ✅ "Users can customize appearance settings"
|
||||
- ❌ "Users can toggle light/dark theme with 3 font size options stored in LocalStorage"
|
||||
|
||||
The second example belongs in Epic Breakdown, not PRD.
|
||||
</action>
|
||||
|
||||
<example>
|
||||
**Well-written FRs at the correct altitude:**
|
||||
|
||||
**User Account & Access:**
|
||||
|
||||
- FR1: Users can create accounts with email or social authentication
|
||||
- FR2: Users can log in securely and maintain sessions across devices
|
||||
- FR3: Users can reset passwords via email verification
|
||||
- FR4: Users can update profile information and preferences
|
||||
- FR5: Administrators can manage user roles and permissions
|
||||
|
||||
**Content Management:**
|
||||
|
||||
- FR6: Users can create, edit, and delete content items
|
||||
- FR7: Users can organize content with tags and categories
|
||||
- FR8: Users can search content by keyword, tag, or date range
|
||||
- FR9: Users can export content in multiple formats
|
||||
|
||||
**Data Ownership (local-first products):**
|
||||
|
||||
- FR10: All user data stored locally on user's device
|
||||
- FR11: Users can export complete data at any time
|
||||
- FR12: Users can import previously exported data
|
||||
- FR13: System monitors storage usage and warns before limits
|
||||
|
||||
**Collaboration:**
|
||||
|
||||
- FR14: Users can share content with specific users or teams
|
||||
- FR15: Users can comment on shared content
|
||||
- FR16: Users can track content change history
|
||||
- FR17: Users receive notifications for relevant updates
|
||||
|
||||
**Notice:**
|
||||
✅ Each FR is a testable capability
|
||||
✅ Each FR is implementation-agnostic (could be built many ways)
|
||||
✅ Each FR specifies WHO and WHAT, not HOW
|
||||
✅ No UI details, no performance numbers, no technology choices
|
||||
✅ Comprehensive coverage of capability areas
|
||||
</example>
|
||||
|
||||
<action>Generate the complete FR list by systematically extracting capabilities:
|
||||
|
||||
1. MVP scope → extract all capabilities → write as FRs
|
||||
2. Growth features → extract capabilities → write as FRs (note if post-MVP)
|
||||
3. Domain requirements → extract mandatory capabilities → write as FRs
|
||||
4. Project-type specifics → extract type-specific capabilities → write as FRs
|
||||
5. Innovation patterns → extract novel capabilities → write as FRs
|
||||
|
||||
Organize FRs by logical capability groups (5-8 groups typically).
|
||||
Number sequentially across all groups (FR1, FR2... FR47).
|
||||
</action>
|
||||
|
||||
<action>SELF-VALIDATION - Before finalizing, ask yourself:
|
||||
|
||||
**Completeness Check:**
|
||||
|
||||
1. "Did I cover EVERY capability mentioned in the MVP scope section?"
|
||||
2. "Did I include domain-specific requirements as FRs?"
|
||||
3. "Did I cover the project-type specific needs (API/Mobile/SaaS/etc)?"
|
||||
4. "Could a UX designer read ONLY the FRs and know what to design?"
|
||||
5. "Could an Architect read ONLY the FRs and know what to support?"
|
||||
6. "Are there any user actions or system behaviors we discussed that have no FR?"
|
||||
|
||||
**Altitude Check:**
|
||||
|
||||
1. "Am I stating capabilities (WHAT) or implementation (HOW)?"
|
||||
2. "Am I listing acceptance criteria or UI specifics?" (Remove if yes)
|
||||
3. "Could this FR be implemented 5 different ways?" (Good - means it's not prescriptive)
|
||||
|
||||
**Quality Check:**
|
||||
|
||||
1. "Is each FR clear enough that someone could test whether it exists?"
|
||||
2. "Is each FR independent (not dependent on reading other FRs to understand)?"
|
||||
3. "Did I avoid vague terms like 'good', 'fast', 'easy'?" (Use NFRs for quality attributes)
|
||||
|
||||
COMPLETENESS GATE: Review your FR list against the entire PRD written so far.
|
||||
Did you miss anything? Add it now before proceeding.
|
||||
</action>
|
||||
|
||||
<template-output>functional_requirements_complete</template-output>
|
||||
<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Non-Functional Requirements Discovery">
|
||||
@@ -341,7 +459,6 @@ Skip categories that don't apply!</action>
|
||||
Does this capture your product vision?"</action>
|
||||
|
||||
<template-output>prd_summary</template-output>
|
||||
<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<action>After PRD review and refinement complete:
|
||||
|
||||
@@ -374,7 +491,7 @@ Generate epic_details for the epics breakdown document</action>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Complete PRD and suggest next steps">
|
||||
<template-output>product_magic_summary</template-output>
|
||||
<template-output>product_value_summary</template-output>
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {status_file}</action>
|
||||
@@ -401,7 +518,7 @@ Your product requirements are documented and ready for implementation.
|
||||
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.
|
||||
What makes your product special - {product_value_summary} - is captured throughout the PRD and will guide all subsequent work.
|
||||
</output>
|
||||
</step>
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### What Makes This Special
|
||||
|
||||
{{product_magic_essence}}
|
||||
{{product_differentiator}}
|
||||
|
||||
---
|
||||
|
||||
@@ -232,6 +232,6 @@ Requirements must be decomposed into epics and bite-sized stories (200k context
|
||||
|
||||
---
|
||||
|
||||
_This PRD captures the essence of {{project_name}} - {{product_magic_summary}}_
|
||||
_This PRD captures the essence of {{project_name}} - {{product_value_summary}}_
|
||||
|
||||
_Created through collaborative discovery between {{user_name}} and AI facilitator._
|
||||
|
||||
@@ -31,17 +31,21 @@ recommended_inputs:
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
|
||||
input_file_patterns:
|
||||
product_brief:
|
||||
whole: "{output_folder}/*brief*.md"
|
||||
sharded: "{output_folder}/*brief*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
research:
|
||||
whole: "{output_folder}/*research*.md"
|
||||
sharded: "{output_folder}/*research*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
load_strategy: "INDEX_GUIDED"
|
||||
|
||||
standalone: true
|
||||
|
||||
@@ -66,7 +70,7 @@ web_bundle:
|
||||
|
||||
# Task dependencies (referenced in instructions.md)
|
||||
- "{bmad_folder}/core/tasks/workflow.xml"
|
||||
- "{bmad_folder}/core/tasks/adv-elicit.xml"
|
||||
- "{bmad_folder}/core/tasks/adv-elicit-methods.csv"
|
||||
- "{bmad_folder}/core/tasks/advanced-elicitation.xml"
|
||||
- "{bmad_folder}/core/tasks/advanced-elicitation-methods.csv"
|
||||
child_workflows:
|
||||
- create-epics-and-stories: "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml"
|
||||
|
||||
@@ -100,14 +100,19 @@ Let's build your tech-spec!</output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="0.5" goal="Discover and load input documents">
|
||||
<invoke-protocol name="discover_inputs" />
|
||||
<note>After discovery, these content variables are available: {product_brief_content}, {research_content}, {document_project_content}</note>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Comprehensive context discovery - gather everything available">
|
||||
|
||||
<action>Welcome {user_name} warmly and explain what we're about to do:
|
||||
|
||||
"I'm going to gather all available context about your project before we dive into the technical spec. This includes:
|
||||
"I'm going to gather all available context about your project before we dive into the technical spec. The following content has been auto-loaded:
|
||||
|
||||
- Any existing documentation (product briefs, research)
|
||||
- Brownfield codebase analysis (if applicable)
|
||||
- Product briefs and research: {product_brief_content}, {research_content}
|
||||
- Brownfield codebase documentation: {document_project_content} (loaded via INDEX_GUIDED strategy)
|
||||
- Your project's tech stack and dependencies
|
||||
- Existing code patterns and structure
|
||||
|
||||
@@ -119,13 +124,13 @@ This ensures the tech-spec is grounded in reality and gives developers everythin
|
||||
Search for and load (using dual-strategy: whole first, then sharded):
|
||||
|
||||
1. **Product Brief:**
|
||||
- Search pattern: {output-folder}/_brief_.md
|
||||
- Sharded: {output-folder}/_brief_/index.md
|
||||
- Search pattern: {output*folder}/\_brief*.md
|
||||
- Sharded: {output*folder}/\_brief*/index.md
|
||||
- If found: Load completely and extract key context
|
||||
|
||||
2. **Research Documents:**
|
||||
- Search pattern: {output-folder}/_research_.md
|
||||
- Sharded: {output-folder}/_research_/index.md
|
||||
- Search pattern: {output*folder}/\_research*.md
|
||||
- Sharded: {output*folder}/\_research*/index.md
|
||||
- If found: Load completely and extract insights
|
||||
|
||||
3. **Document-Project Output (CRITICAL for brownfield):**
|
||||
@@ -801,8 +806,6 @@ What to watch after deployment:
|
||||
<template-output file="tech-spec.md">rollback_plan</template-output>
|
||||
<template-output file="tech-spec.md">monitoring_approach</template-output>
|
||||
|
||||
<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Auto-validate cohesion, completeness, and quality">
|
||||
|
||||
@@ -38,15 +38,19 @@ sprint_artifacts: "{output_folder}/sprint_artifacts"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
|
||||
input_file_patterns:
|
||||
product_brief:
|
||||
whole: "{output_folder}/*brief*.md"
|
||||
sharded: "{output_folder}/*brief*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
research:
|
||||
whole: "{output_folder}/*research*.md"
|
||||
sharded: "{output_folder}/*research*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
load_strategy: "INDEX_GUIDED"
|
||||
|
||||
standalone: true
|
||||
|
||||
|
||||
Reference in New Issue
Block a user