refactor: comprehensive workflow modernization and standardization
## Major Improvements
### 1. Elicitation System Modernization
- Removed legacy `<elicit-required />` tag from workflow.xml
- Replaced with direct `<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>` pattern
- More explicit, self-documenting, and eliminates indirection layer
- Added strategic elicitation points across all planning workflows:
- PRD: After success criteria, scope, functional requirements, and final review
- Create-Epics-And-Stories: After epic proposals and each epic's stories
- Architecture: After decisions, structure, patterns, implementation patterns, and final doc
- Updated audit-workflow tag scanner to remove obsolete elicit-required reference
### 2. Input Document Discovery Streamlined
- Replaced verbose 19-line "Input Document Discovery" sections with single critical tag
- New format: `<critical>Input documents specified in workflow.yaml input_file_patterns...</critical>`
- Eliminates duplication - workflow.yaml already defines patterns
- Updated across 6 workflows (PRD, create-epics-and-stories, architecture, tech-spec, UX, gate-check)
- Saved ~114 lines of repeated bloat
### 3. Scale System Migration (Levels 0-4 → 3 Tracks)
- Updated PRD workflow from "Level 0-4" to "Quick Flow / BMad Method / Enterprise Method"
- Changed `project_level` variable to `project_track`
- Removed `target_scale` variable (no longer needed)
- Updated workflow.yaml descriptions to reference tracks not levels
- Updated checklist from "Level 2" and "Level 3-4" to "BMad Method" and "Enterprise Method"
- Aligns with new scale-adaptive-system.md (3-track methodology)
### 4. Epic/Story Template Standardization
- Replaced hardcoded 8-epic template with clean repeating pattern using N/M variables
- Added BDD-style acceptance criteria (Given/When/Then/And)
- Removed instructional bloat from templates (moved to instructions.md where it belongs)
- Template shows OUTPUT structure, instructions show PROCESS
- Applied to both create-epics-and-stories and tech-spec workflows
- Templates now use HTML comments to indicate repeating sections
### 5. Workflow.yaml Pattern Consistency
- Standardized input_file_patterns across all workflows
- Separated `recommended_inputs` (semantic WHAT) from `input_file_patterns` (file discovery WHERE)
- Removed duplication between recommended_inputs file paths and input_file_patterns
- Create-epics-and-stories now uses proper whole/sharded pattern like architecture workflow
- Solutioning-gate-check cleaned up to use semantic descriptions not file paths
## Files Changed (18)
- Core: workflow.xml (removed elicit-required tag and references)
- Audit workflow: Updated tag pattern scanner
- PRD workflow: Elicitation points, track migration, input discovery
- Create-epics-and-stories: Template rebuild, BDD format, elicitation, input patterns
- Tech-spec: Template rebuild, BDD format, input discovery
- UX Design: Input discovery streamlined
- Architecture: Elicitation at 5 key decision points, input discovery
- Gate-check: Input pattern cleanup, input discovery
## Impact
- More consistent elicitation across workflows
- Cleaner, more maintainable templates
- Better separation of concerns (templates vs instructions)
- Aligned with v6 3-track scale system
- Reduced bloat and duplication significantly
This commit is contained in:
Brian Madison
parent
c5117e5382
commit
accae5d789
|
|
@ -161,7 +161,7 @@
|
|||
<action if="condition met">Do something</action>
|
||||
```
|
||||
|
||||
<action>Scan instructions.md for nested tag references using pattern: <(action|ask|check|template-output|invoke-workflow|goto|step|elicit-required)> within text content</action>
|
||||
<action>Scan instructions.md for nested tag references using pattern: <(action|ask|check|template-output|invoke-workflow|invoke-task|goto|step)> within text content
|
||||
<action>Record any instances of nested tag references with line numbers</action>
|
||||
<action>Scan instructions.md for conditional execution antipattern: self-closing check tags</action>
|
||||
<action>Detect pattern: `<check>.*</check>` on single line (self-closing check)</action>
|
||||
|
|
|
|||
|
|
@ -13,8 +13,7 @@
|
|||
<rule n="1">Steps execute in exact numerical order (1, 2, 3...)</rule>
|
||||
<rule n="2">Optional steps: Ask user unless #yolo mode active</rule>
|
||||
<rule n="3">Template-output tags: Save content → Show user → Get approval before continuing</rule>
|
||||
<rule n="4">Elicit tags: Execute immediately unless #yolo mode (which skips ALL elicitation)</rule>
|
||||
<rule n="5">User must approve each major section before continuing UNLESS #yolo mode active</rule>
|
||||
<rule n="4">User must approve each major section before continuing UNLESS #yolo mode active</rule>
|
||||
</WORKFLOW-RULES>
|
||||
|
||||
<flow>
|
||||
|
|
@ -75,14 +74,6 @@
|
|||
<action>Display generated content</action>
|
||||
<ask>Continue [c] or Edit [e]? WAIT for response</ask>
|
||||
</if>
|
||||
|
||||
<if tag="elicit-required">
|
||||
<mandate critical="true">YOU MUST READ the file at {project-root}/bmad/core/tasks/adv-elicit.xml using Read tool BEFORE presenting
|
||||
any elicitation menu</mandate>
|
||||
<action>Load and run task {project-root}/bmad/core/tasks/adv-elicit.xml with current context</action>
|
||||
<action>Show elicitation menu 5 relevant options (list 1-5 options, Continue [c] or Reshuffle [r])</action>
|
||||
<mandate>HALT and WAIT for user selection</mandate>
|
||||
</if>
|
||||
</substep>
|
||||
|
||||
<substep n="2d" title="Step Completion">
|
||||
|
|
@ -123,7 +114,6 @@
|
|||
</execution>
|
||||
<output>
|
||||
<tag>template-output - Save content checkpoint</tag>
|
||||
<tag>elicit-required - Trigger enhancement</tag>
|
||||
<tag>critical - Cannot be skipped</tag>
|
||||
<tag>example - Show example output</tag>
|
||||
</output>
|
||||
|
|
|
|||
|
|
@ -13,8 +13,7 @@
|
|||
<rule n="1">Steps execute in exact numerical order (1, 2, 3...)</rule>
|
||||
<rule n="2">Optional steps: Ask user unless #yolo mode active</rule>
|
||||
<rule n="3">Template-output tags: Save content → Show user → Get approval before continuing</rule>
|
||||
<rule n="4">Elicit tags: Execute immediately unless #yolo mode (which skips ALL elicitation)</rule>
|
||||
<rule n="5">User must approve each major section before continuing UNLESS #yolo mode active</rule>
|
||||
<rule n="4">User must approve each major section before continuing UNLESS #yolo mode active</rule>
|
||||
</WORKFLOW-RULES>
|
||||
|
||||
<flow>
|
||||
|
|
@ -75,14 +74,6 @@
|
|||
<action>Display generated content</action>
|
||||
<ask>Continue [c] or Edit [e]? WAIT for response</ask>
|
||||
</if>
|
||||
|
||||
<if tag="elicit-required">
|
||||
<mandate critical="true">YOU MUST READ the file at {project-root}/bmad/core/tasks/adv-elicit.xml using Read tool BEFORE presenting
|
||||
any elicitation menu</mandate>
|
||||
<action>Load and run task {project-root}/bmad/core/tasks/adv-elicit.xml with current context</action>
|
||||
<action>Show elicitation menu 5 relevant options (list 1-5 options, Continue [c] or Reshuffle [r])</action>
|
||||
<mandate>HALT and WAIT for user selection</mandate>
|
||||
</if>
|
||||
</substep>
|
||||
|
||||
<substep n="2d" title="Step Completion">
|
||||
|
|
@ -123,7 +114,6 @@
|
|||
</execution>
|
||||
<output>
|
||||
<tag>template-output - Save content checkpoint</tag>
|
||||
<tag>elicit-required - Trigger enhancement</tag>
|
||||
<tag>critical - Cannot be skipped</tag>
|
||||
<tag>example - Show example output</tag>
|
||||
</output>
|
||||
|
|
|
|||
|
|
@ -161,7 +161,7 @@
|
|||
<action if="condition met">Do something</action>
|
||||
```
|
||||
|
||||
<action>Scan instructions.md for nested tag references using pattern: <(action|ask|check|template-output|invoke-workflow|goto|step|elicit-required)> within text content</action>
|
||||
<action>Scan instructions.md for nested tag references using pattern: <(action|ask|check|template-output|invoke-workflow|invoke-task|goto|step)> within text content</action>
|
||||
<action>Record any instances of nested tag references with line numbers</action>
|
||||
<action>Scan instructions.md for conditional execution antipattern: self-closing check tags</action>
|
||||
<action>Detect pattern: `<check>.*</check>` on single line (self-closing check)</action>
|
||||
|
|
|
|||
|
|
@ -9,26 +9,8 @@
|
|||
<critical>Communicate all responses in {communication_language} and tailor to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>SAVE PROGRESS after each major step - use <template-output> tags throughout</critical>
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Professional, specific, actionable UX design decisions WITH RATIONALE. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
|
||||
|
||||
## 📚 Input Document Discovery
|
||||
|
||||
This workflow requires: PRD or product brief, and may reference epics/stories, brainstorming documents, or brownfield project documentation.
|
||||
|
||||
**Discovery Process** (execute for each referenced document):
|
||||
|
||||
1. **Search for whole document first** - Use fuzzy file matching to find the complete document
|
||||
2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand the document structure
|
||||
- Read ALL section files listed in the index
|
||||
- Treat the combined content as if it were a single document
|
||||
4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md`
|
||||
|
||||
**Priority**: If both whole and sharded versions exist, use the whole document.
|
||||
|
||||
**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions.
|
||||
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
|
|
|||
|
|
@ -234,21 +234,22 @@
|
|||
- [ ] Dependencies on external systems documented
|
||||
- [ ] Data requirements specified
|
||||
|
||||
### Level-Appropriate Detail
|
||||
### Track-Appropriate Detail
|
||||
|
||||
**If Level 2:**
|
||||
|
||||
- [ ] PRD supports lightweight tech-spec workflow
|
||||
- [ ] 5-15 story scope reasonable for project size
|
||||
- [ ] Complexity appropriate for small team/solo dev
|
||||
|
||||
**If Level 3-4:**
|
||||
**If BMad Method:**
|
||||
|
||||
- [ ] PRD supports full architecture workflow
|
||||
- [ ] Epic structure supports phased delivery
|
||||
- [ ] Scope appropriate for team-based development
|
||||
- [ ] 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
|
||||
|
|
|
|||
|
|
@ -9,55 +9,44 @@
|
|||
|
||||
## Overview
|
||||
|
||||
This document provides the detailed epic breakdown for {{project_name}}, expanding on the high-level epic list in the [PRD](./PRD.md).
|
||||
This document provides the complete epic and story breakdown for {{project_name}}, decomposing the requirements from the [PRD](./PRD.md) into implementable stories.
|
||||
|
||||
Each epic includes:
|
||||
|
||||
- Expanded goal and value proposition
|
||||
- Complete story breakdown with user stories
|
||||
- Acceptance criteria for each story
|
||||
- Story sequencing and dependencies
|
||||
|
||||
**Epic Sequencing Principles:**
|
||||
|
||||
- Epic 1 establishes foundational infrastructure and initial functionality
|
||||
- Subsequent epics build progressively, each delivering significant end-to-end value
|
||||
- Stories within epics are vertically sliced and sequentially ordered
|
||||
- No forward dependencies - each story builds only on previous work
|
||||
{{epics_summary}}
|
||||
|
||||
---
|
||||
|
||||
{{epic_details}}
|
||||
<!-- Repeat for each epic (N = 1, 2, 3...) -->
|
||||
|
||||
---
|
||||
## Epic {{N}}: {{epic_title_N}}
|
||||
|
||||
## Story Guidelines Reference
|
||||
{{epic_goal_N}}
|
||||
|
||||
**Story Format:**
|
||||
<!-- Repeat for each story (M = 1, 2, 3...) within epic N -->
|
||||
|
||||
```
|
||||
**Story [EPIC.N]: [Story Title]**
|
||||
### Story {{N}}.{{M}}: {{story_title_N_M}}
|
||||
|
||||
As a [user type],
|
||||
I want [goal/desire],
|
||||
So that [benefit/value].
|
||||
As a {{user_type}},
|
||||
I want {{capability}},
|
||||
So that {{value_benefit}}.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
1. [Specific testable criterion]
|
||||
2. [Another specific criterion]
|
||||
3. [etc.]
|
||||
|
||||
**Prerequisites:** [Dependencies on previous stories, if any]
|
||||
```
|
||||
**Given** {{precondition}}
|
||||
**When** {{action}}
|
||||
**Then** {{expected_outcome}}
|
||||
|
||||
**Story Requirements:**
|
||||
**And** {{additional_criteria}}
|
||||
|
||||
- **Vertical slices** - Complete, testable functionality delivery
|
||||
- **Sequential ordering** - Logical progression within epic
|
||||
- **No forward dependencies** - Only depend on previous work
|
||||
- **AI-agent sized** - Completable in 2-4 hour focused session
|
||||
- **Value-focused** - Integrate technical enablers into value-delivering stories
|
||||
**Prerequisites:** {{dependencies_on_previous_stories}}
|
||||
|
||||
**Technical Notes:** {{implementation_guidance}}
|
||||
|
||||
<!-- End story repeat -->
|
||||
|
||||
---
|
||||
|
||||
**For implementation:** Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown.
|
||||
<!-- End epic repeat -->
|
||||
|
||||
---
|
||||
|
||||
_For implementation: Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown._
|
||||
|
|
|
|||
|
|
@ -1,395 +1,169 @@
|
|||
# Epic and Story Decomposition - Bite-Sized Implementation Planning
|
||||
# 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 limited context agents</critical>
|
||||
<critical>EVERY story must be completable by a single limited context window dev agent in one session</critical>
|
||||
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</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="0" goal="Load context and requirements">
|
||||
<action>Welcome the {user_name} to the project inception high level epic and story planning.
|
||||
<step n="1" goal="Load PRD and extract requirements">
|
||||
<action>Welcome {user_name} to epic and story planning
|
||||
|
||||
Load required documents:
|
||||
Load required documents (fuzzy match, handle both whole and sharded):
|
||||
|
||||
1. PRD.md (must exist - fuzzy match on name, might be a folder with an index and smaller sharded files also)
|
||||
2. domain-brief.md (if exists)
|
||||
3. product-brief.md (if exists)
|
||||
- PRD.md (required)
|
||||
- domain-brief.md (if exists)
|
||||
- product-brief.md (if exists)
|
||||
|
||||
Extract from PRD:
|
||||
|
||||
- Functional requirements
|
||||
- All functional requirements
|
||||
- Non-functional requirements
|
||||
- Domain considerations
|
||||
- Project type
|
||||
- MVP scope vs growth features
|
||||
- Domain considerations and compliance needs
|
||||
- Project type and complexity
|
||||
- MVP vs growth vs vision scope boundaries
|
||||
|
||||
If continuing from PRD workflow:
|
||||
"Great! Now let's break down your requirements into actionable epics and bite-sized stories that development agents can implement independently."
|
||||
Understand the context:
|
||||
|
||||
If starting fresh:
|
||||
"I'll help you transform your PRD into organized epics with implementable stories. Each story will be small enough for a single dev agent to complete in one session."</action>
|
||||
</step>
|
||||
- What makes this product special (the magic)
|
||||
- Technical constraints
|
||||
- User types and their goals
|
||||
- Success criteria</action>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Form epics from natural groupings">
|
||||
<action>Transform requirements into epics organically
|
||||
<step n="2" goal="Propose epic structure from natural groupings">
|
||||
<action>Analyze requirements and identify natural epic boundaries
|
||||
|
||||
INTENT: Find natural boundaries that make sense for THIS product
|
||||
INTENT: Find organic groupings that make sense for THIS product
|
||||
|
||||
Look at the requirements and find patterns:
|
||||
Look for natural patterns:
|
||||
|
||||
- Features that work together
|
||||
- Features that work together cohesively
|
||||
- User journeys that connect
|
||||
- Technical systems that relate
|
||||
- Business capabilities that group
|
||||
- Domain requirements that cluster (compliance, validation, etc.)
|
||||
- Business capabilities that cluster
|
||||
- Domain requirements that relate (compliance, validation, security)
|
||||
- Technical systems that should be built together
|
||||
|
||||
Examples of natural epic formation:
|
||||
Name epics based on VALUE, not technical layers:
|
||||
|
||||
- Auth features → "User Management" epic
|
||||
- Payment features → "Monetization" epic
|
||||
- Social features → "Community" epic
|
||||
- Admin features → "Administration" epic
|
||||
- Compliance requirements → "Regulatory Compliance" epic
|
||||
- API endpoints → "API Infrastructure" epic
|
||||
|
||||
But let the product guide you - don't force standard patterns
|
||||
- Good: "User Onboarding", "Content Discovery", "Compliance Framework"
|
||||
- Avoid: "Database Layer", "API Endpoints", "Frontend"
|
||||
|
||||
Each epic should:
|
||||
|
||||
- Have a clear business goal
|
||||
- Have clear business goal and user value
|
||||
- Be independently valuable
|
||||
- Contain 3-8 related features
|
||||
- Be completable in 1-2 sprints
|
||||
- Contain 3-8 related capabilities
|
||||
- Be deliverable in cohesive phase
|
||||
|
||||
Name epics based on value, not technical components:
|
||||
GOOD: "User Onboarding", "Content Discovery", "Team Collaboration"
|
||||
NOT: "Database", "Frontend", "API"
|
||||
For greenfield projects:
|
||||
|
||||
If domain considerations exist:
|
||||
- First epic MUST establish foundation (project setup, core infrastructure, deployment pipeline)
|
||||
- Foundation enables all subsequent work
|
||||
|
||||
- Create dedicated compliance/validation epics
|
||||
- Note special expertise needed per epic
|
||||
- Flag epics with regulatory dependencies
|
||||
For complex domains:
|
||||
|
||||
Present epic groupings conversationally:
|
||||
"Based on your requirements, I see these natural epic groupings:
|
||||
- Consider dedicated compliance/regulatory epics
|
||||
- Group validation and safety requirements logically
|
||||
- Note expertise requirements
|
||||
|
||||
1. [Epic Name] - [Brief description]
|
||||
2. [Epic Name] - [Brief description]
|
||||
3. [Epic Name] - [Brief description]
|
||||
Present proposed epic structure showing:
|
||||
|
||||
Does this organization make sense for how you think about the product?"</action>
|
||||
- Epic titles with clear value statements
|
||||
- High-level scope of each epic
|
||||
- Suggested sequencing
|
||||
- Why this grouping makes sense</action>
|
||||
|
||||
<template-output>epics_structure</template-output>
|
||||
<template-output>epics_summary</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Decompose into bite-sized stories">
|
||||
<critical>Small vertical sliced small stories are best for agentic dumb developers to implement without forgetting things</critical>
|
||||
<step n="3" goal="Decompose each epic into bite-sized stories" repeat="for-each-epic">
|
||||
<action>Break down Epic {{N}} into small, implementable stories
|
||||
|
||||
<action>Break each epic into small, implementable stories
|
||||
INTENT: Create stories sized for single dev agent completion
|
||||
|
||||
INTENT: Create stories that one dev agent can complete independently
|
||||
For each epic, generate:
|
||||
|
||||
For each epic, decompose into stories that are:
|
||||
- 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
|
||||
|
||||
- Small enough for single context window
|
||||
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
|
||||
- Independent enough to develop in parallel when possible
|
||||
- Specific enough to have clear acceptance criteria
|
||||
|
||||
GOOD story examples:
|
||||
For each story in epic {{N}}, output variables following this pattern:
|
||||
|
||||
- "Create login API endpoint that accepts email/password and returns JWT"
|
||||
- "Build user profile component with avatar upload to S3"
|
||||
- "Add password reset email template and sending logic"
|
||||
- "Implement rate limiting on auth endpoints (5 attempts per minute)"
|
||||
- "Create HIPAA-compliant audit log for patient data access"
|
||||
- "Build FDA 21 CFR Part 11 electronic signature component"
|
||||
- story*title*{{N}}_1, story_title_{{N}}\_2, etc.
|
||||
- Each containing: user story, BDD acceptance criteria, prerequisites, technical notes</action>
|
||||
|
||||
BAD story examples:
|
||||
<template-output>epic*title*{{N}}</template-output>
|
||||
<template-output>epic*goal*{{N}}</template-output>
|
||||
|
||||
- "Build complete authentication system" (too big)
|
||||
- "Handle user management" (too vague)
|
||||
- "Make it secure" (not specific)
|
||||
- "Integrate everything" (requires multiple contexts)
|
||||
<action>For each story M in epic {{N}}, generate story content</action>
|
||||
<template-output>story*title*{{N}}\_{{M}}</template-output>
|
||||
|
||||
Story format:
|
||||
"As a [user type], I want [specific feature], so that [clear value]"
|
||||
|
||||
Technical notes to include:
|
||||
|
||||
- Affected files/components if known
|
||||
- Required endpoints/methods
|
||||
- Data structures needed
|
||||
- Specific validation rules
|
||||
- Compliance requirements if applicable
|
||||
- Dependencies on other stories
|
||||
|
||||
Domain-aware story creation:
|
||||
|
||||
- For healthcare: Include specific regulations per story
|
||||
- For fintech: Note PCI/security requirements per story
|
||||
- For govtech: Flag accessibility needs per story
|
||||
- For aerospace: Include safety/validation requirements
|
||||
|
||||
Check each story:
|
||||
|
||||
- Can this be explained in <1000 words?
|
||||
- Can one agent complete without another's output?
|
||||
- Is the scope crystal clear?
|
||||
- Are success criteria obvious?
|
||||
- Are domain requirements specified?
|
||||
|
||||
If too big → split into smaller stories
|
||||
If too vague → add specifics
|
||||
If dependent → note the dependency clearly
|
||||
If domain-critical → flag compliance needs</action>
|
||||
|
||||
<template-output>epic_1_stories</template-output>
|
||||
<template-output>epic_2_stories</template-output>
|
||||
<template-output>epic_3_stories</template-output>
|
||||
|
||||
<!-- Continue for each epic discovered -->
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Sequence for smart implementation">
|
||||
<action>Order stories for successful development
|
||||
<step n="4" goal="Review and finalize epic breakdown">
|
||||
<action>Review the complete epic breakdown for quality and completeness
|
||||
|
||||
INTENT: Create a logical flow that minimizes blockers and maximizes progress
|
||||
Validate:
|
||||
|
||||
Consider dependencies:
|
||||
TECHNICAL:
|
||||
- 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
|
||||
|
||||
- Authentication before protected features
|
||||
- Data models before business logic
|
||||
- Core features before enhancements
|
||||
- API before frontend that uses it
|
||||
Confirm with {user_name}:
|
||||
|
||||
DOMAIN:
|
||||
- Epic structure makes sense
|
||||
- Story breakdown is actionable
|
||||
- Dependencies are clear
|
||||
- BDD format provides clarity
|
||||
- Ready for architecture and implementation phases</action>
|
||||
|
||||
- Compliance infrastructure before features
|
||||
- Validation framework before clinical features
|
||||
- Audit logging before financial transactions
|
||||
- Safety systems before operational features
|
||||
|
||||
PRACTICAL:
|
||||
|
||||
- What gives visible progress early?
|
||||
- What reduces risk soonest?
|
||||
- What enables parallel work?
|
||||
- What delivers value fastest?
|
||||
|
||||
Create implementation phases:
|
||||
|
||||
Phase 1 - Foundation:
|
||||
|
||||
- Core data models
|
||||
- Authentication/authorization
|
||||
- Basic infrastructure
|
||||
- Essential APIs
|
||||
- Compliance foundation (if domain requires)
|
||||
|
||||
Phase 2 - Core Features:
|
||||
|
||||
- MVP functionality
|
||||
- Key user flows
|
||||
- Basic UI/UX
|
||||
- Critical integrations
|
||||
- Domain validations (if applicable)
|
||||
|
||||
Phase 3 - Enhancement:
|
||||
|
||||
- Polish and refinement
|
||||
- Additional features
|
||||
- Performance optimization
|
||||
- Extended functionality
|
||||
- Advanced compliance features
|
||||
|
||||
Phase 4 - Growth:
|
||||
|
||||
- Analytics and monitoring
|
||||
- Advanced features
|
||||
- Scaling preparations
|
||||
- Nice-to-have additions
|
||||
|
||||
For complex domains, add gates:
|
||||
|
||||
- "Gate: Security audit before payment processing"
|
||||
- "Gate: Clinical validation before patient features"
|
||||
- "Gate: Compliance review before launch"
|
||||
|
||||
Present the sequencing conversationally:
|
||||
"Here's a smart implementation order:
|
||||
|
||||
**Phase 1 (Foundation) - Week 1-2:**
|
||||
|
||||
- Story 1.1: [Description]
|
||||
- Story 1.2: [Description] (can parallel with 1.1)
|
||||
- Story 1.3: [Description] (depends on 1.1)
|
||||
|
||||
**Phase 2 (Core) - Week 3-4:**
|
||||
[Continue...]
|
||||
|
||||
This gives you something working by [milestone] and allows [X] stories to run in parallel."</action>
|
||||
|
||||
<template-output>implementation_sequence</template-output>
|
||||
<template-output>development_phases</template-output>
|
||||
<template-output>dependency_graph</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Validate story sizing and clarity">
|
||||
<action>Review all stories for dev agent compatibility
|
||||
|
||||
Run through each story and verify:
|
||||
|
||||
SIZE CHECK:
|
||||
|
||||
- Story description < 500 words
|
||||
- Clear inputs and outputs defined
|
||||
- Single responsibility principle
|
||||
- No hidden complexity
|
||||
|
||||
CLARITY CHECK:
|
||||
|
||||
- Acceptance criteria explicit
|
||||
- Technical approach clear
|
||||
- No ambiguous requirements
|
||||
- Success measurable
|
||||
|
||||
DEPENDENCY CHECK:
|
||||
|
||||
- Dependencies documented
|
||||
- Can start with clear inputs
|
||||
- Outputs well-defined
|
||||
- Parallel opportunities noted
|
||||
|
||||
DOMAIN CHECK (if applicable):
|
||||
|
||||
- Compliance requirements stated
|
||||
- Validation criteria defined
|
||||
- Regulatory references included
|
||||
- Special expertise noted
|
||||
|
||||
If any issues found:
|
||||
"Story [X] seems too large. Let me split it:
|
||||
|
||||
- [Smaller story 1]
|
||||
- [Smaller story 2]"
|
||||
|
||||
"Story [Y] needs clarification on [aspect]. How should we handle [specific question]?"
|
||||
|
||||
Final validation:
|
||||
"All stories are now sized for 200k context limits.
|
||||
|
||||
- Total stories: [count]
|
||||
- Can run in parallel: [count]
|
||||
- Sequential dependencies: [count]
|
||||
- Estimated completion: [timeframe]"</action>
|
||||
|
||||
<template-output>story_validation</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Create development guidance">
|
||||
<action>Add practical guidance for implementation teams
|
||||
|
||||
Create quick reference for development:
|
||||
|
||||
GETTING STARTED:
|
||||
"Start with Phase 1 stories - multiple can run in parallel.
|
||||
Key files to create first: [list]
|
||||
Recommended agent allocation: [suggestion]"
|
||||
|
||||
DOMAIN GUIDANCE (if applicable):
|
||||
"Critical compliance checkpoints:
|
||||
|
||||
- After story [X]: Run [validation]
|
||||
- Before story [Y]: Review [regulation]
|
||||
- Throughout: Maintain [audit trail]"
|
||||
|
||||
TECHNICAL NOTES:
|
||||
"Architecture decisions needed:
|
||||
|
||||
- [Decision 1] affects stories [A, B, C]
|
||||
- [Decision 2] blocks story [D]
|
||||
|
||||
Consider these patterns:
|
||||
|
||||
- [Pattern] for [epic]
|
||||
- [Pattern] for [requirement]"
|
||||
|
||||
RISK MITIGATION:
|
||||
"Watch out for:
|
||||
|
||||
- [Risk] in story [X]
|
||||
- [Complexity] in epic [Y]
|
||||
- [Dependency] between [A] and [B]"
|
||||
|
||||
SUCCESS METRICS:
|
||||
"You'll know Phase 1 is complete when:
|
||||
|
||||
- [Measurable outcome]
|
||||
- [Testable feature]
|
||||
- [Validation passed]"</action>
|
||||
|
||||
<template-output>implementation_guidance</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Finalize and prepare handoff">
|
||||
<action>Complete the epics document and prepare for development
|
||||
|
||||
Review what we've created:
|
||||
"We've successfully decomposed your requirements into:
|
||||
|
||||
- [x] epics
|
||||
- [Y] total stories
|
||||
- [Z] phases of development
|
||||
|
||||
Every story is sized for a single dev agent to complete independently."
|
||||
|
||||
Highlight key achievements:
|
||||
|
||||
- Stories respect 200k context limit
|
||||
- Dependencies clearly mapped
|
||||
- Domain requirements integrated
|
||||
- Parallel development enabled
|
||||
|
||||
Save completed epics.md with:
|
||||
|
||||
- Full epic descriptions
|
||||
- All stories with acceptance criteria
|
||||
- Implementation sequence
|
||||
- Development phases
|
||||
- Dependency notes
|
||||
- Domain compliance requirements (if applicable)</action>
|
||||
|
||||
<output>**✅ Epic Decomposition Complete, {user_name}!**
|
||||
|
||||
Your requirements are now organized into **{epic_count} epics** with **{story_count} bite-sized stories**.
|
||||
|
||||
**Created:**
|
||||
|
||||
- **epics.md** - Complete epic breakdown with implementable stories
|
||||
|
||||
**Key Stats:**
|
||||
|
||||
- Average story size: Fits in 200k context
|
||||
- Parallel stories: {parallel_count} can run simultaneously
|
||||
- Sequential chains: {sequential_count} dependency chains
|
||||
- Estimated velocity: {velocity_estimate}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
1. Review epics.md for the complete breakdown
|
||||
2. Start Phase 1 implementation with parallel stories
|
||||
3. Use story IDs for tracking progress
|
||||
|
||||
Each story is crafted for a single dev agent to complete autonomously. No monoliths, no confusion, just clear implementation paths.
|
||||
|
||||
Ready to begin development with any story marked "can start immediately"!</output>
|
||||
<template-output>epic_breakdown_summary</template-output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
|
|||
|
|
@ -13,23 +13,35 @@ document_output_language: "{config_source}:document_output_language"
|
|||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
# 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"
|
||||
|
||||
# Input files (from parent PRD workflow)
|
||||
prd_file: "{output_folder}/PRD.md"
|
||||
|
||||
# Output files
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/epics.md"
|
||||
|
||||
# Optional input documents
|
||||
recommended_inputs:
|
||||
- prd: "{output_folder}/PRD.md"
|
||||
- product_brief: "{output_folder}/product-brief.md"
|
||||
- domain_brief: "{output_folder}/domain-brief.md"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle:
|
||||
|
|
|
|||
|
|
@ -7,24 +7,7 @@
|
|||
<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>
|
||||
|
||||
## 📚 Input Document Discovery
|
||||
|
||||
This workflow requires: product brief, and may reference market research or brownfield project documentation.
|
||||
|
||||
**Discovery Process** (execute for each referenced document):
|
||||
|
||||
1. **Search for whole document first** - Use fuzzy file matching to find the complete document
|
||||
2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand the document structure
|
||||
- Read ALL section files listed in the index
|
||||
- Treat the combined content as if it were a single document
|
||||
4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md`
|
||||
|
||||
**Priority**: If both whole and sharded versions exist, use the whole document.
|
||||
|
||||
**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions.
|
||||
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
|
|
@ -37,14 +20,14 @@ This workflow requires: product brief, and may reference market research or brow
|
|||
<action>Load the FULL file: {status_file}</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "prd" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Get project_track from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_level < 2">
|
||||
<output>**Level {{project_level}} Project - Redirecting**
|
||||
<check if="project_track is Quick Flow">
|
||||
<output>**Quick Flow Track - Redirecting**
|
||||
|
||||
Level 0-1 projects use tech-spec workflow for simpler planning.
|
||||
PRD is for Level 2-4 projects that need comprehensive requirements.</output>
|
||||
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>
|
||||
|
||||
|
|
@ -132,6 +115,7 @@ Weave in the magic:
|
|||
<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">
|
||||
|
|
@ -156,6 +140,7 @@ 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/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Domain-Specific Exploration" optional="true">
|
||||
|
|
@ -256,8 +241,8 @@ Always relate back to the product magic:
|
|||
</check>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="UX Principles" optional="true">
|
||||
<action>Only if product has a UI
|
||||
<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:
|
||||
|
||||
|
|
@ -271,10 +256,10 @@ Light touch on UX - not full design:
|
|||
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>
|
||||
<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">
|
||||
|
|
@ -304,6 +289,7 @@ 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">
|
||||
|
|
@ -339,9 +325,6 @@ Skip categories that don't apply!</action>
|
|||
<check if="integration matters">
|
||||
<template-output>integration_requirements</template-output>
|
||||
</check>
|
||||
<check if="no NFRs discussed">
|
||||
<template-output>no_nfrs</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Review PRD and transition to epics">
|
||||
|
|
@ -355,9 +338,13 @@ Skip categories that don't apply!</action>
|
|||
- Requirements: [count] functional, [count] non-functional
|
||||
- Special considerations: [domain/innovation]
|
||||
|
||||
Does this capture your product vision?"
|
||||
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:
|
||||
|
||||
After confirmation:
|
||||
"Excellent! Now we need to break these requirements into implementable epics and stories.
|
||||
|
||||
For the epic breakdown, you have two options:
|
||||
|
|
@ -379,12 +366,10 @@ This keeps each session focused and manageable."
|
|||
If continue:
|
||||
"Let's continue with epic breakdown here..."
|
||||
[Proceed with epics-stories subworkflow]
|
||||
Set project_level and target_scale based on project analysis
|
||||
Set project_track based on workflow status (BMad Method or Enterprise Method)
|
||||
Generate epic_details for the epics breakdown document</action>
|
||||
|
||||
<template-output>prd_summary</template-output>
|
||||
<template-output>project_level</template-output>
|
||||
<template-output>target_scale</template-output>
|
||||
<template-output>project_track</template-output>
|
||||
<template-output>epic_details</template-output>
|
||||
</step>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Product Requirements Document (PRD) Workflow
|
||||
name: prd
|
||||
description: "Unified PRD workflow for project levels 2-4. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Level 0-1 use tech-spec workflow."
|
||||
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
|
||||
|
|
@ -47,7 +47,7 @@ standalone: true
|
|||
|
||||
web_bundle:
|
||||
name: "prd"
|
||||
description: "Unified PRD workflow for project levels 2-4. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Level 0-1 use tech-spec workflow."
|
||||
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"
|
||||
instructions: "bmad/bmm/workflows/2-plan-workflows/prd/instructions.md"
|
||||
validation: "bmad/bmm/workflows/2-plan-workflows/prd/checklist.md"
|
||||
|
|
|
|||
|
|
@ -5,51 +5,73 @@
|
|||
|
||||
---
|
||||
|
||||
## Epic: {{epic_title}}
|
||||
<!-- Repeat for each epic (N = 1, 2, 3...) -->
|
||||
|
||||
**Slug:** {{epic_slug}}
|
||||
## Epic {{N}}: {{epic_title_N}}
|
||||
|
||||
**Slug:** {{epic_slug_N}}
|
||||
|
||||
### Goal
|
||||
|
||||
{{epic_goal}}
|
||||
{{epic_goal_N}}
|
||||
|
||||
### Scope
|
||||
|
||||
{{epic_scope}}
|
||||
{{epic_scope_N}}
|
||||
|
||||
### Success Criteria
|
||||
|
||||
{{epic_success_criteria}}
|
||||
{{epic_success_criteria_N}}
|
||||
|
||||
### Dependencies
|
||||
|
||||
{{epic_dependencies}}
|
||||
{{epic_dependencies_N}}
|
||||
|
||||
---
|
||||
|
||||
## Story Map
|
||||
## Story Map - Epic {{N}}
|
||||
|
||||
{{story_map}}
|
||||
{{story_map_N}}
|
||||
|
||||
---
|
||||
|
||||
## Story Summaries
|
||||
## Stories - Epic {{N}}
|
||||
|
||||
{{story_summaries}}
|
||||
<!-- 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}}
|
||||
|
||||
**Estimated Effort:** {{story_points}} points ({{time_estimate}})
|
||||
|
||||
<!-- End story repeat -->
|
||||
|
||||
---
|
||||
|
||||
## Implementation Timeline
|
||||
## Implementation Timeline - Epic {{N}}
|
||||
|
||||
**Total Story Points:** {{total_points}}
|
||||
**Total Story Points:** {{total_points_N}}
|
||||
|
||||
**Estimated Timeline:** {{estimated_timeline}}
|
||||
**Estimated Timeline:** {{estimated_timeline_N}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Sequence
|
||||
|
||||
{{implementation_sequence}}
|
||||
<!-- End epic repeat -->
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -10,26 +10,8 @@
|
|||
<critical>Level 0: tech-spec + single user story | Level 1: tech-spec + epic/stories</critical>
|
||||
<critical>LIVING DOCUMENT: Write to tech-spec.md continuously as you discover - never wait until the end</critical>
|
||||
<critical>CONTEXT IS KING: Gather ALL available context before generating specs</critical>
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Technical, precise, definitive. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
|
||||
|
||||
## 📚 Input Document Discovery
|
||||
|
||||
This workflow intelligently discovers and loads all available context including: product brief, research documents, brownfield project documentation, and project setup files.
|
||||
|
||||
**Discovery Process** (execute for each referenced document):
|
||||
|
||||
1. **Search for whole document first** - Use fuzzy file matching to find the complete document
|
||||
2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand the document structure
|
||||
- Read ALL section files listed in the index
|
||||
- Treat the combined content as if it were a single document
|
||||
4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md`
|
||||
|
||||
**Priority**: If both whole and sharded versions exist, use the whole document.
|
||||
|
||||
**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions.
|
||||
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness and detect project level" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
|
|
|||
|
|
@ -1,32 +1,53 @@
|
|||
# Story: {{story_title}}
|
||||
# Story {{N}}.{{M}}: {{story_title}}
|
||||
|
||||
Status: Draft
|
||||
**Status:** Draft
|
||||
|
||||
## Story
|
||||
---
|
||||
|
||||
As a {{role}},
|
||||
## User Story
|
||||
|
||||
As a {{user_type}},
|
||||
I want {{capability}},
|
||||
so that {{benefit}}.
|
||||
So that {{value_benefit}}.
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
{{acceptance_criteria}}
|
||||
**Given** {{precondition}}
|
||||
**When** {{action}}
|
||||
**Then** {{expected_outcome}}
|
||||
|
||||
## Tasks / Subtasks
|
||||
**And** {{additional_criteria}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Tasks / Subtasks
|
||||
|
||||
{{tasks_subtasks}}
|
||||
|
||||
## Dev Notes
|
||||
|
||||
### Technical Summary
|
||||
|
||||
{{technical_summary}}
|
||||
|
||||
### Tech-Spec Reference
|
||||
### Project Structure Notes
|
||||
|
||||
**Full details:** See [tech-spec.md](../tech-spec.md)
|
||||
- **Files to modify:** {{files_to_modify}}
|
||||
- **Expected test locations:** {{test_locations}}
|
||||
- **Estimated effort:** {{story_points}} story points ({{time_estimate}})
|
||||
- **Prerequisites:** {{dependencies}}
|
||||
|
||||
The tech-spec contains comprehensive context including:
|
||||
### Key Code References
|
||||
|
||||
{{existing_code_references}}
|
||||
|
||||
---
|
||||
|
||||
## Context References
|
||||
|
||||
**Tech-Spec:** [tech-spec.md](../tech-spec.md) - Primary context document containing:
|
||||
|
||||
- Brownfield codebase analysis (if applicable)
|
||||
- Framework and library details with versions
|
||||
|
|
@ -34,32 +55,14 @@ The tech-spec contains comprehensive context including:
|
|||
- Integration points and dependencies
|
||||
- Complete implementation guidance
|
||||
|
||||
### Project Structure Notes
|
||||
**Architecture:** {{architecture_references}}
|
||||
|
||||
- **Files to modify:** {{files_to_modify}}
|
||||
- **Expected test locations:** {{test_locations}}
|
||||
- **Estimated effort:** {{story_points}} story points ({{time_estimate}})
|
||||
- **Dependencies:** {{dependencies}}
|
||||
|
||||
### Key Code References
|
||||
|
||||
{{existing_code_references}}
|
||||
|
||||
### References
|
||||
|
||||
- **Tech Spec:** [tech-spec.md](../tech-spec.md) - Primary context document
|
||||
- **Architecture:** {{architecture_references}}
|
||||
<!-- Additional context XML paths will be added here if story-context workflow is run -->
|
||||
|
||||
---
|
||||
|
||||
## Dev Agent Record
|
||||
|
||||
### Context Reference
|
||||
|
||||
**Primary Context:** [tech-spec.md](../tech-spec.md) - Contains all brownfield analysis, framework details, and implementation guidance
|
||||
|
||||
<!-- Additional context XML paths will be added here if story-context workflow is run -->
|
||||
|
||||
### Agent Model Used
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
|
@ -68,11 +71,11 @@ The tech-spec contains comprehensive context including:
|
|||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
### Completion Notes List
|
||||
### Completion Notes
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
### File List
|
||||
### Files Modified
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# Technical Specification Workflow (Level 0)
|
||||
name: tech-spec-sm
|
||||
# Technical Specification
|
||||
name: tech-spec
|
||||
description: "Technical specification workflow for Level 0 projects (single atomic changes). Creates focused tech spec for bug fixes, single endpoint additions, or small isolated changes. Tech-spec only - no PRD needed."
|
||||
author: "BMad"
|
||||
|
||||
|
|
|
|||
|
|
@ -9,24 +9,8 @@
|
|||
<critical>Communicate all responses in {communication_language} and tailor to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>This workflow replaces architecture with a conversation-driven approach</critical>
|
||||
|
||||
## 📚 Input Document Discovery
|
||||
|
||||
This workflow requires: PRD and epics/stories, and may reference UX design specifications or brownfield project documentation.
|
||||
|
||||
**Discovery Process** (execute for each referenced document):
|
||||
|
||||
1. **Search for whole document first** - Use fuzzy file matching to find the complete document
|
||||
2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand the document structure
|
||||
- Read ALL section files listed in the index
|
||||
- Treat the combined content as if it were a single document
|
||||
4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md`
|
||||
|
||||
**Priority**: If both whole and sharded versions exist, use the whole document.
|
||||
|
||||
**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions.
|
||||
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
|
||||
<critical>ELICITATION POINTS: After completing each major architectural decision area (identified by template-output tags for decision_record, project_structure, novel_pattern_designs, implementation_patterns, and architecture_document), invoke advanced elicitation to refine decisions before proceeding</critical>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
|
@ -379,6 +363,7 @@ Provided by Starter: {{yes_if_from_starter}}
|
|||
</action>
|
||||
|
||||
<template-output>decision_record</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Address cross-cutting concerns">
|
||||
|
|
@ -408,6 +393,7 @@ Provided by Starter: {{yes_if_from_starter}}
|
|||
</action>
|
||||
|
||||
<template-output>project_structure</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Design novel architectural patterns" optional="true">
|
||||
|
|
@ -481,6 +467,7 @@ Provided by Starter: {{yes_if_from_starter}}
|
|||
</check>
|
||||
|
||||
<template-output>novel_pattern_designs</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Define implementation patterns to prevent agent conflicts">
|
||||
|
|
@ -573,6 +560,7 @@ Enforcement: "All agents MUST follow this pattern"
|
|||
</action>
|
||||
|
||||
<template-output>implementation_patterns</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Validate architectural coherence">
|
||||
|
|
@ -626,6 +614,7 @@ Enforcement: "All agents MUST follow this pattern"
|
|||
</action>
|
||||
|
||||
<template-output>architecture_document</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Validate document completeness">
|
||||
|
|
|
|||
|
|
@ -3,24 +3,7 @@
|
|||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {project-root}/bmad/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml</critical>
|
||||
<critical>Communicate all findings and analysis in {communication_language} throughout the assessment</critical>
|
||||
|
||||
## 📚 Input Document Discovery
|
||||
|
||||
This workflow validates: PRD, epics/stories, architecture, and may reference UX design, tech specs, or brownfield project documentation.
|
||||
|
||||
**Discovery Process** (execute for each referenced document):
|
||||
|
||||
1. **Search for whole document first** - Use fuzzy file matching to find the complete document
|
||||
2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand the document structure
|
||||
- Read ALL section files listed in the index
|
||||
- Treat the combined content as if it were a single document
|
||||
4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md`
|
||||
|
||||
**Priority**: If both whole and sharded versions exist, use the whole document.
|
||||
|
||||
**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions.
|
||||
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
|
|
|
|||
|
|
@ -24,13 +24,13 @@ validation: "{installed_path}/checklist.md"
|
|||
# Output configuration
|
||||
default_output_file: "{output_folder}/implementation-readiness-report-{{date}}.md"
|
||||
|
||||
# Expected input documents (varies by project level)
|
||||
# Input requirements
|
||||
recommended_inputs:
|
||||
- prd: "{output_folder}/prd*.md"
|
||||
- architecture: "{output_folder}/architecture*.md or {output_folder}/architecture*.md"
|
||||
- tech_spec: "{output_folder}/tech-spec*.md"
|
||||
- epics_stories: "{output_folder}/epic*.md"
|
||||
- ux_artifacts: "{output_folder}/ux*.md"
|
||||
- prd: "Product Requirements Document with FRs and NFRs"
|
||||
- architecture: "System Architecture with decisions and patterns"
|
||||
- tech_spec: "Technical Specification (for Quick Flow track)"
|
||||
- epics: "Epic breakdown with user stories"
|
||||
- ux_design: "UX design specification (if UI components)"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
|
|
|
|||
Loading…
Reference in New Issue