bmad初始化
This commit is contained in:
258
bmad/bmm/workflows/2-plan-workflows/README.md
Normal file
258
bmad/bmm/workflows/2-plan-workflows/README.md
Normal file
@@ -0,0 +1,258 @@
|
||||
---
|
||||
last-redoc-date: 2025-10-01
|
||||
---
|
||||
|
||||
# Project Planning Workflow (Phase 2)
|
||||
|
||||
The Phase 2 Planning workflow is **scale-adaptive**, meaning it automatically determines the right level of planning documentation based on project complexity (Levels 0-4). This ensures planning overhead matches project value—from minimal tech specs for bug fixes to comprehensive PRDs for enterprise platforms.
|
||||
|
||||
## Scale-Adaptive Flow (Levels 0-4)
|
||||
|
||||
The workflow routes to different planning approaches based on project level:
|
||||
|
||||
### Level 0 - Single File Change / Bug Fix
|
||||
|
||||
**Planning:** Tech-spec only (lightweight implementation plan)
|
||||
**Output:** `tech-spec.md` with single story
|
||||
**Next Phase:** Direct to implementation (Phase 4)
|
||||
|
||||
### Level 1 - Small Feature (1-3 files, 2-5 stories)
|
||||
|
||||
**Planning:** Tech-spec only (implementation-focused)
|
||||
**Output:** `tech-spec.md` with epic breakdown and stories
|
||||
**Next Phase:** Direct to implementation (Phase 4)
|
||||
|
||||
### Level 2 - Feature Set / Small Project (5-15 stories, 1-2 epics)
|
||||
|
||||
**Planning:** PRD (product-focused) + Tech-spec (technical planning)
|
||||
**Output:** `PRD.md`, `epics.md`, `tech-spec.md`
|
||||
**Next Phase:** Tech-spec workflow (lightweight solutioning), then implementation (Phase 4)
|
||||
**Note:** Level 2 uses tech-spec instead of full architecture to keep planning lightweight
|
||||
|
||||
### Level 3 - Medium Project (15-40 stories, 2-5 epics)
|
||||
|
||||
**Planning:** PRD (strategic product document)
|
||||
**Output:** `PRD.md`, `epics.md`
|
||||
**Next Phase:** create-architecture workflow (Phase 3), then implementation (Phase 4)
|
||||
|
||||
### Level 4 - Large/Enterprise Project (40-100+ stories, 5-10 epics)
|
||||
|
||||
**Planning:** PRD (comprehensive product specification)
|
||||
**Output:** `PRD.md`, `epics.md`
|
||||
**Next Phase:** create-architecture workflow (Phase 3), then implementation (Phase 4)
|
||||
|
||||
**Critical Distinction:**
|
||||
|
||||
- **Levels 0-1:** No PRD, tech-spec only
|
||||
- **Level 2:** PRD + tech-spec (skips full architecture)
|
||||
- **Levels 3-4:** PRD → full create-architecture workflow
|
||||
|
||||
Critical to v6's flow improvement is this workflow's integration with the bmm-workflow-status.md tracking document, which maintains project state across sessions, tracks which agents participate in each phase, and provides continuity for multi-session planning efforts. The workflow can resume from any point, intelligently detecting existing artifacts and determining next steps without redundant work. For UX-heavy projects, it can generate standalone UX specifications or AI frontend prompts from existing specs.
|
||||
|
||||
## Key Features
|
||||
|
||||
- **Scale-adaptive planning** - Automatically determines output based on project complexity
|
||||
- **Intelligent routing** - Uses router system to load appropriate instruction sets
|
||||
- **Continuation support** - Can resume from previous sessions and handle incremental work
|
||||
- **Multi-level outputs** - Supports 5 project levels (0-4) with appropriate artifacts
|
||||
- **Input integration** - Leverages product briefs and market research when available
|
||||
- **Template-driven** - Uses validated templates for consistent output structure
|
||||
|
||||
### Configuration
|
||||
|
||||
The workflow adapts automatically based on project assessment, but key configuration options include:
|
||||
|
||||
- **scale_parameters**: Defines story/epic counts for each project level
|
||||
- **output_folder**: Where all generated documents are stored
|
||||
- **project_name**: Used in document names and templates
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
### Files Included
|
||||
|
||||
```
|
||||
2-plan-workflows/
|
||||
├── README.md # Overview and usage details
|
||||
├── checklist.md # Shared validation criteria
|
||||
├── prd/
|
||||
│ ├── epics-template.md # Epic breakdown template
|
||||
│ ├── instructions.md # Level 2-4 PRD instructions
|
||||
│ ├── prd-template.md # Product Requirements Document template
|
||||
│ └── workflow.yaml
|
||||
├── tech-spec/
|
||||
│ ├── epics-template.md # Epic-to-story handoff template
|
||||
│ ├── instructions-level0-story.md
|
||||
│ ├── instructions-level1-stories.md
|
||||
│ ├── instructions.md # Level 0-1 tech-spec instructions
|
||||
│ ├── tech-spec-template.md # Technical Specification template
|
||||
│ ├── user-story-template.md # Story template for Level 0/1
|
||||
│ └── workflow.yaml
|
||||
├── gdd/
|
||||
│ ├── instructions-gdd.md # Game Design Document instructions
|
||||
│ ├── gdd-template.md # GDD template
|
||||
│ ├── game-types.csv # Genre catalog
|
||||
│ ├── game-types/ # Genre-specific templates
|
||||
│ └── workflow.yaml
|
||||
├── narrative/
|
||||
│ ├── instructions-narrative.md # Narrative design instructions
|
||||
│ ├── narrative-template.md # Narrative planning template
|
||||
│ └── workflow.yaml
|
||||
└── create-ux-design/
|
||||
├── instructions.md # UX design instructions
|
||||
├── ux-design-template.md # UX design template
|
||||
├── checklist.md # UX design validation checklist
|
||||
└── workflow.yaml
|
||||
```
|
||||
|
||||
## Workflow Process
|
||||
|
||||
### Phase 1: Assessment and Routing (Steps 1-5)
|
||||
|
||||
- **Project Analysis**: Determines project type (greenfield/brownfield/legacy)
|
||||
- **Scope Assessment**: Classifies into 5 levels based on complexity
|
||||
- **Document Discovery**: Identifies existing inputs and documentation
|
||||
- **Workflow Routing**: Loads appropriate instruction set based on level
|
||||
- **Continuation Handling**: Resumes from previous work when applicable
|
||||
|
||||
### Phase 2: Level-Specific Planning (Steps vary by level)
|
||||
|
||||
**Level 0 (Single File Change / Bug Fix)**:
|
||||
|
||||
- Tech-spec only workflow
|
||||
- Single story implementation plan
|
||||
- Direct to Phase 4 (implementation)
|
||||
|
||||
**Level 1 (Small Feature)**:
|
||||
|
||||
- Tech-spec only workflow
|
||||
- Epic breakdown with 2-5 stories
|
||||
- Direct to Phase 4 (implementation)
|
||||
|
||||
**Level 2 (Feature Set / Small Project)**:
|
||||
|
||||
- PRD workflow (strategic product document)
|
||||
- Generates `PRD.md` and `epics.md`
|
||||
- Then runs tech-spec workflow (lightweight solutioning)
|
||||
- Then to Phase 4 (implementation)
|
||||
|
||||
**Level 3-4 (Medium to Enterprise Projects)**:
|
||||
|
||||
- PRD workflow (comprehensive product specification)
|
||||
- Generates `PRD.md` and `epics.md`
|
||||
- Hands off to Phase 3 (create-architecture workflow)
|
||||
- Full architecture design before implementation
|
||||
|
||||
### Phase 3: Validation and Handoff (Final steps)
|
||||
|
||||
- **Document Review**: Validates outputs against checklists
|
||||
- **Architect Preparation**: For Level 3-4, prepares handoff materials
|
||||
- **Next Steps**: Provides guidance for development phase
|
||||
|
||||
## Output
|
||||
|
||||
### Generated Files
|
||||
|
||||
- **Primary output**: PRD.md (except Level 0), tech-spec.md, bmm-workflow-status.md
|
||||
- **Supporting files**: epics.md (Level 2-4), PRD-validation-report.md (if validation run)
|
||||
|
||||
### Output Structure by Level
|
||||
|
||||
**Level 0 - Tech Spec Only**:
|
||||
|
||||
- `tech-spec.md` - Single story implementation plan
|
||||
- Direct to implementation
|
||||
|
||||
**Level 1 - Tech Spec with Epic Breakdown**:
|
||||
|
||||
- `tech-spec.md` - Epic breakdown with 2-5 stories
|
||||
- Direct to implementation
|
||||
|
||||
**Level 2 - PRD + Tech Spec**:
|
||||
|
||||
- `PRD.md` - Strategic product document (goals, requirements, user journeys, UX principles, UI goals, epic list, scope)
|
||||
- `epics.md` - Tactical implementation roadmap (detailed story breakdown)
|
||||
- `tech-spec.md` - Lightweight technical planning (generated after PRD)
|
||||
- Then to implementation
|
||||
|
||||
**Level 3-4 - PRD + Full Architecture**:
|
||||
|
||||
- `PRD.md` - Comprehensive product specification
|
||||
- `epics.md` - Complete epic/story breakdown
|
||||
- Hands off to create-architecture workflow (Phase 3)
|
||||
- `architecture.md` - Generated by architect workflow
|
||||
- Then to implementation
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Input Documents**: Product brief and/or market research (recommended but not required)
|
||||
- **Project Configuration**: Valid config.yaml with project_name and output_folder
|
||||
- **Assessment Readiness**: Clear understanding of project scope and objectives
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Before Starting
|
||||
|
||||
1. **Gather Context**: Collect any existing product briefs, market research, or requirements
|
||||
2. **Define Scope**: Have a clear sense of project boundaries and complexity
|
||||
3. **Prepare Stakeholders**: Ensure key stakeholders are available for input if needed
|
||||
|
||||
### During Execution
|
||||
|
||||
1. **Be Honest About Scope**: Accurate assessment ensures appropriate planning depth
|
||||
2. **Leverage Existing Work**: Reference previous documents and avoid duplication
|
||||
3. **Think Incrementally**: Remember that planning can evolve - start with what you know
|
||||
|
||||
### After Completion
|
||||
|
||||
1. **Validate Against Checklist**: Use included validation criteria to ensure completeness
|
||||
2. **Share with Stakeholders**: Distribute appropriate documents to relevant team members
|
||||
3. **Prepare for Architecture**: For Level 3-4 projects, ensure architect has complete context
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Issue**: Workflow creates wrong level of documentation
|
||||
|
||||
- **Solution**: Review project assessment and restart with correct scope classification
|
||||
- **Check**: Verify the bmm-workflow-status.md reflects actual project complexity
|
||||
|
||||
**Issue**: Missing input documents cause incomplete planning
|
||||
|
||||
- **Solution**: Gather recommended inputs or proceed with manual context gathering
|
||||
- **Check**: Ensure critical business context is captured even without formal documents
|
||||
|
||||
**Issue**: Continuation from previous session fails
|
||||
|
||||
- **Solution**: Check for existing bmm-workflow-status.md and ensure output folder is correct
|
||||
- **Check**: Verify previous session completed at a valid checkpoint
|
||||
|
||||
## Customization
|
||||
|
||||
To customize this workflow:
|
||||
|
||||
1. **Modify Assessment Logic**: Update instructions-router.md to adjust level classification
|
||||
2. **Adjust Templates**: Customize PRD, tech-spec, or epic templates for organizational needs
|
||||
3. **Add Validation**: Extend checklist.md with organization-specific quality criteria
|
||||
4. **Configure Outputs**: Modify workflow.yaml to change file naming or structure
|
||||
|
||||
## Version History
|
||||
|
||||
- **v6.0.0** - Scale-adaptive architecture with intelligent routing
|
||||
- Multi-level project support (0-4)
|
||||
- Continuation and resumption capabilities
|
||||
- Template-driven output generation
|
||||
- Input document integration
|
||||
|
||||
## Support
|
||||
|
||||
For issues or questions:
|
||||
|
||||
- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
|
||||
- Validate output using `checklist.md`
|
||||
- Consult project assessment in `bmm-workflow-status.md`
|
||||
- Check continuation status in existing output documents
|
||||
|
||||
---
|
||||
|
||||
_Part of the BMad Method v6 - BMM (Method) Module_
|
||||
@@ -0,0 +1,310 @@
|
||||
# Create UX Design Workflow Validation Checklist
|
||||
|
||||
**Purpose**: Validate UX Design Specification is complete, collaborative, and implementation-ready.
|
||||
|
||||
**Paradigm**: Visual collaboration-driven, not template generation
|
||||
|
||||
**Expected Outputs**:
|
||||
|
||||
- ux-design-specification.md
|
||||
- ux-color-themes.html (color theme visualizer)
|
||||
- ux-design-directions.html (design mockups)
|
||||
- Optional: ux-prototype.html, ux-component-showcase.html, ai-frontend-prompt.md
|
||||
|
||||
---
|
||||
|
||||
## 1. Output Files Exist
|
||||
|
||||
- [ ] **ux-design-specification.md** created in output folder
|
||||
- [ ] **ux-color-themes.html** generated (interactive color exploration)
|
||||
- [ ] **ux-design-directions.html** generated (6-8 design mockups)
|
||||
- [ ] No unfilled {{template_variables}} in specification
|
||||
- [ ] All sections have content (not placeholder text)
|
||||
|
||||
---
|
||||
|
||||
## 2. Collaborative Process Validation
|
||||
|
||||
**The workflow should facilitate decisions WITH the user, not FOR them**
|
||||
|
||||
- [ ] **Design system chosen by user** (not auto-selected)
|
||||
- [ ] **Color theme selected from options** (user saw visualizations and chose)
|
||||
- [ ] **Design direction chosen from mockups** (user explored 6-8 options)
|
||||
- [ ] **User journey flows designed collaboratively** (options presented, user decided)
|
||||
- [ ] **UX patterns decided with user input** (not just generated)
|
||||
- [ ] **Decisions documented WITH rationale** (why each choice was made)
|
||||
|
||||
---
|
||||
|
||||
## 3. Visual Collaboration Artifacts
|
||||
|
||||
### Color Theme Visualizer
|
||||
|
||||
- [ ] **HTML file exists and is valid** (ux-color-themes.html)
|
||||
- [ ] **Shows 3-4 theme options** (or documented existing brand)
|
||||
- [ ] **Each theme has complete palette** (primary, secondary, semantic colors)
|
||||
- [ ] **Live UI component examples** in each theme (buttons, forms, cards)
|
||||
- [ ] **Side-by-side comparison** enabled
|
||||
- [ ] **User's selection documented** in specification
|
||||
|
||||
### Design Direction Mockups
|
||||
|
||||
- [ ] **HTML file exists and is valid** (ux-design-directions.html)
|
||||
- [ ] **6-8 different design approaches** shown
|
||||
- [ ] **Full-screen mockups** of key screens
|
||||
- [ ] **Design philosophy labeled** for each direction (e.g., "Dense Dashboard", "Spacious Explorer")
|
||||
- [ ] **Interactive navigation** between directions
|
||||
- [ ] **Responsive preview** toggle available
|
||||
- [ ] **User's choice documented WITH reasoning** (what they liked, why it fits)
|
||||
|
||||
---
|
||||
|
||||
## 4. Design System Foundation
|
||||
|
||||
- [ ] **Design system chosen** (or custom design decision documented)
|
||||
- [ ] **Current version identified** (if using established system)
|
||||
- [ ] **Components provided by system documented**
|
||||
- [ ] **Custom components needed identified**
|
||||
- [ ] **Decision rationale clear** (why this system for this project)
|
||||
|
||||
---
|
||||
|
||||
## 5. Core Experience Definition
|
||||
|
||||
- [ ] **Defining experience articulated** (the ONE thing that makes this app unique)
|
||||
- [ ] **Novel UX patterns identified** (if applicable)
|
||||
- [ ] **Novel patterns fully designed** (interaction model, states, feedback)
|
||||
- [ ] **Core experience principles defined** (speed, guidance, flexibility, feedback)
|
||||
|
||||
---
|
||||
|
||||
## 6. Visual Foundation
|
||||
|
||||
### Color System
|
||||
|
||||
- [ ] **Complete color palette** (primary, secondary, accent, semantic, neutrals)
|
||||
- [ ] **Semantic color usage defined** (success, warning, error, info)
|
||||
- [ ] **Color accessibility considered** (contrast ratios for text)
|
||||
- [ ] **Brand alignment** (follows existing brand or establishes new identity)
|
||||
|
||||
### Typography
|
||||
|
||||
- [ ] **Font families selected** (heading, body, monospace if needed)
|
||||
- [ ] **Type scale defined** (h1-h6, body, small, etc.)
|
||||
- [ ] **Font weights documented** (when to use each)
|
||||
- [ ] **Line heights specified** for readability
|
||||
|
||||
### Spacing & Layout
|
||||
|
||||
- [ ] **Spacing system defined** (base unit, scale)
|
||||
- [ ] **Layout grid approach** (columns, gutters)
|
||||
- [ ] **Container widths** for different breakpoints
|
||||
|
||||
---
|
||||
|
||||
## 7. Design Direction
|
||||
|
||||
- [ ] **Specific direction chosen** from mockups (not generic)
|
||||
- [ ] **Layout pattern documented** (navigation, content structure)
|
||||
- [ ] **Visual hierarchy defined** (density, emphasis, focus)
|
||||
- [ ] **Interaction patterns specified** (modal vs inline, disclosure approach)
|
||||
- [ ] **Visual style documented** (minimal, balanced, rich, maximalist)
|
||||
- [ ] **User's reasoning captured** (why this direction fits their vision)
|
||||
|
||||
---
|
||||
|
||||
## 8. User Journey Flows
|
||||
|
||||
- [ ] **All critical journeys from PRD designed** (no missing flows)
|
||||
- [ ] **Each flow has clear goal** (what user accomplishes)
|
||||
- [ ] **Flow approach chosen collaboratively** (user picked from options)
|
||||
- [ ] **Step-by-step documentation** (screens, actions, feedback)
|
||||
- [ ] **Decision points and branching** defined
|
||||
- [ ] **Error states and recovery** addressed
|
||||
- [ ] **Success states specified** (completion feedback)
|
||||
- [ ] **Mermaid diagrams or clear flow descriptions** included
|
||||
|
||||
---
|
||||
|
||||
## 9. Component Library Strategy
|
||||
|
||||
- [ ] **All required components identified** (from design system + custom)
|
||||
- [ ] **Custom components fully specified**:
|
||||
- Purpose and user-facing value
|
||||
- Content/data displayed
|
||||
- User actions available
|
||||
- All states (default, hover, active, loading, error, disabled)
|
||||
- Variants (sizes, styles, layouts)
|
||||
- Behavior on interaction
|
||||
- Accessibility considerations
|
||||
- [ ] **Design system components customization needs** documented
|
||||
|
||||
---
|
||||
|
||||
## 10. UX Pattern Consistency Rules
|
||||
|
||||
**These patterns ensure consistent UX across the entire app**
|
||||
|
||||
- [ ] **Button hierarchy defined** (primary, secondary, tertiary, destructive)
|
||||
- [ ] **Feedback patterns established** (success, error, warning, info, loading)
|
||||
- [ ] **Form patterns specified** (labels, validation, errors, help text)
|
||||
- [ ] **Modal patterns defined** (sizes, dismiss behavior, focus, stacking)
|
||||
- [ ] **Navigation patterns documented** (active state, breadcrumbs, back button)
|
||||
- [ ] **Empty state patterns** (first use, no results, cleared content)
|
||||
- [ ] **Confirmation patterns** (when to confirm destructive actions)
|
||||
- [ ] **Notification patterns** (placement, duration, stacking, priority)
|
||||
- [ ] **Search patterns** (trigger, results, filters, no results)
|
||||
- [ ] **Date/time patterns** (format, timezone, pickers)
|
||||
|
||||
**Each pattern should have:**
|
||||
|
||||
- [ ] Clear specification (how it works)
|
||||
- [ ] Usage guidance (when to use)
|
||||
- [ ] Examples (concrete implementations)
|
||||
|
||||
---
|
||||
|
||||
## 11. Responsive Design
|
||||
|
||||
- [ ] **Breakpoints defined** for target devices (mobile, tablet, desktop)
|
||||
- [ ] **Adaptation patterns documented** (how layouts change)
|
||||
- [ ] **Navigation adaptation** (how nav changes on small screens)
|
||||
- [ ] **Content organization changes** (multi-column to single, grid to list)
|
||||
- [ ] **Touch targets adequate** on mobile (minimum size specified)
|
||||
- [ ] **Responsive strategy aligned** with chosen design direction
|
||||
|
||||
---
|
||||
|
||||
## 12. Accessibility
|
||||
|
||||
- [ ] **WCAG compliance level specified** (A, AA, or AAA)
|
||||
- [ ] **Color contrast requirements** documented (ratios for text)
|
||||
- [ ] **Keyboard navigation** addressed (all interactive elements accessible)
|
||||
- [ ] **Focus indicators** specified (visible focus states)
|
||||
- [ ] **ARIA requirements** noted (roles, labels, announcements)
|
||||
- [ ] **Screen reader considerations** (meaningful labels, structure)
|
||||
- [ ] **Alt text strategy** for images
|
||||
- [ ] **Form accessibility** (label associations, error identification)
|
||||
- [ ] **Testing strategy** defined (automated tools, manual testing)
|
||||
|
||||
---
|
||||
|
||||
## 13. Coherence and Integration
|
||||
|
||||
- [ ] **Design system and custom components visually consistent**
|
||||
- [ ] **All screens follow chosen design direction**
|
||||
- [ ] **Color usage consistent with semantic meanings**
|
||||
- [ ] **Typography hierarchy clear and consistent**
|
||||
- [ ] **Similar actions handled the same way** (pattern consistency)
|
||||
- [ ] **All PRD user journeys have UX design**
|
||||
- [ ] **All entry points designed**
|
||||
- [ ] **Error and edge cases handled**
|
||||
- [ ] **Every interactive element meets accessibility requirements**
|
||||
- [ ] **All flows keyboard-navigable**
|
||||
- [ ] **Colors meet contrast requirements**
|
||||
|
||||
---
|
||||
|
||||
## 14. Cross-Workflow Alignment (Epics File Update)
|
||||
|
||||
**As UX design progresses, you discover implementation details that affect the story breakdown**
|
||||
|
||||
### Stories Discovered During UX Design
|
||||
|
||||
- [ ] **Review epics.md file** for alignment with UX design
|
||||
- [ ] **New stories identified** during UX design that weren't in epics.md:
|
||||
- [ ] Custom component build stories (if significant)
|
||||
- [ ] UX pattern implementation stories
|
||||
- [ ] Animation/transition stories
|
||||
- [ ] Responsive adaptation stories
|
||||
- [ ] Accessibility implementation stories
|
||||
- [ ] Edge case handling stories discovered during journey design
|
||||
- [ ] Onboarding/empty state stories
|
||||
- [ ] Error state handling stories
|
||||
|
||||
### Story Complexity Adjustments
|
||||
|
||||
- [ ] **Existing stories complexity reassessed** based on UX design:
|
||||
- [ ] Stories that are now more complex (UX revealed additional requirements)
|
||||
- [ ] Stories that are simpler (design system handles more than expected)
|
||||
- [ ] Stories that should be split (UX design shows multiple components/flows)
|
||||
- [ ] Stories that can be combined (UX design shows they're tightly coupled)
|
||||
|
||||
### Epic Alignment
|
||||
|
||||
- [ ] **Epic scope still accurate** after UX design
|
||||
- [ ] **New epic needed** for discovered work (if significant)
|
||||
- [ ] **Epic ordering might change** based on UX dependencies
|
||||
|
||||
### Action Items for Epics File Update
|
||||
|
||||
- [ ] **List of new stories to add** to epics.md documented
|
||||
- [ ] **Complexity adjustments noted** for existing stories
|
||||
- [ ] **Update epics.md** OR flag for architecture review first
|
||||
- [ ] **Rationale documented** for why new stories/changes are needed
|
||||
|
||||
**Note:** If significant story changes are identified, consider running architecture workflow BEFORE updating epics.md, since architecture decisions might reveal additional adjustments needed.
|
||||
|
||||
---
|
||||
|
||||
## 15. Decision Rationale
|
||||
|
||||
**Unlike template-driven workflows, this workflow should document WHY**
|
||||
|
||||
- [ ] **Design system choice has rationale** (why this fits the project)
|
||||
- [ ] **Color theme selection has reasoning** (why this emotional impact)
|
||||
- [ ] **Design direction choice explained** (what user liked, how it fits vision)
|
||||
- [ ] **User journey approaches justified** (why this flow pattern)
|
||||
- [ ] **UX pattern decisions have context** (why these patterns for this app)
|
||||
- [ ] **Responsive strategy aligned with user priorities**
|
||||
- [ ] **Accessibility level appropriate for deployment intent**
|
||||
|
||||
---
|
||||
|
||||
## 16. Implementation Readiness
|
||||
|
||||
- [ ] **Designers can create high-fidelity mockups** from this spec
|
||||
- [ ] **Developers can implement** with clear UX guidance
|
||||
- [ ] **Sufficient detail** for frontend development
|
||||
- [ ] **Component specifications actionable** (states, variants, behaviors)
|
||||
- [ ] **Flows implementable** (clear steps, decision logic, error handling)
|
||||
- [ ] **Visual foundation complete** (colors, typography, spacing all defined)
|
||||
- [ ] **Pattern consistency enforceable** (clear rules for implementation)
|
||||
|
||||
---
|
||||
|
||||
## 17. Critical Failures (Auto-Fail)
|
||||
|
||||
- [ ] ❌ **No visual collaboration** (color themes or design mockups not generated)
|
||||
- [ ] ❌ **User not involved in decisions** (auto-generated without collaboration)
|
||||
- [ ] ❌ **No design direction chosen** (missing key visual decisions)
|
||||
- [ ] ❌ **No user journey designs** (critical flows not documented)
|
||||
- [ ] ❌ **No UX pattern consistency rules** (implementation will be inconsistent)
|
||||
- [ ] ❌ **Missing core experience definition** (no clarity on what makes app unique)
|
||||
- [ ] ❌ **No component specifications** (components not actionable)
|
||||
- [ ] ❌ **Responsive strategy missing** (for multi-platform projects)
|
||||
- [ ] ❌ **Accessibility ignored** (no compliance target or requirements)
|
||||
- [ ] ❌ **Generic/templated content** (not specific to this project)
|
||||
|
||||
---
|
||||
|
||||
## Validation Notes
|
||||
|
||||
**Document findings:**
|
||||
|
||||
- UX Design Quality: [Exceptional / Strong / Adequate / Needs Work / Incomplete]
|
||||
- Collaboration Level: [Highly Collaborative / Collaborative / Somewhat Collaborative / Generated]
|
||||
- Visual Artifacts: [Complete & Interactive / Partial / Missing]
|
||||
- Implementation Readiness: [Ready / Needs Design Phase / Not Ready]
|
||||
|
||||
## **Strengths:**
|
||||
|
||||
## **Areas for Improvement:**
|
||||
|
||||
## **Recommended Actions:**
|
||||
|
||||
**Ready for next phase?** [Yes - Proceed to Design / Yes - Proceed to Development / Needs Refinement]
|
||||
|
||||
---
|
||||
|
||||
_This checklist validates collaborative UX design facilitation, not template generation. A successful UX workflow creates design decisions WITH the user through visual exploration and informed choices._
|
||||
1301
bmad/bmm/workflows/2-plan-workflows/create-ux-design/instructions.md
Normal file
1301
bmad/bmm/workflows/2-plan-workflows/create-ux-design/instructions.md
Normal file
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,145 @@
|
||||
# {{project_name}} UX Design Specification
|
||||
|
||||
_Created on {{date}} by {{user_name}}_
|
||||
_Generated using BMad Method - Create UX Design Workflow v1.0_
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{project_vision}}
|
||||
|
||||
---
|
||||
|
||||
## 1. Design System Foundation
|
||||
|
||||
### 1.1 Design System Choice
|
||||
|
||||
{{design_system_decision}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Core User Experience
|
||||
|
||||
### 2.1 Defining Experience
|
||||
|
||||
{{core_experience}}
|
||||
|
||||
### 2.2 Novel UX Patterns
|
||||
|
||||
{{novel_ux_patterns}}
|
||||
|
||||
---
|
||||
|
||||
## 3. Visual Foundation
|
||||
|
||||
### 3.1 Color System
|
||||
|
||||
{{visual_foundation}}
|
||||
|
||||
**Interactive Visualizations:**
|
||||
|
||||
- Color Theme Explorer: [ux-color-themes.html](./ux-color-themes.html)
|
||||
|
||||
---
|
||||
|
||||
## 4. Design Direction
|
||||
|
||||
### 4.1 Chosen Design Approach
|
||||
|
||||
{{design_direction_decision}}
|
||||
|
||||
**Interactive Mockups:**
|
||||
|
||||
- Design Direction Showcase: [ux-design-directions.html](./ux-design-directions.html)
|
||||
|
||||
---
|
||||
|
||||
## 5. User Journey Flows
|
||||
|
||||
### 5.1 Critical User Paths
|
||||
|
||||
{{user_journey_flows}}
|
||||
|
||||
---
|
||||
|
||||
## 6. Component Library
|
||||
|
||||
### 6.1 Component Strategy
|
||||
|
||||
{{component_library_strategy}}
|
||||
|
||||
---
|
||||
|
||||
## 7. UX Pattern Decisions
|
||||
|
||||
### 7.1 Consistency Rules
|
||||
|
||||
{{ux_pattern_decisions}}
|
||||
|
||||
---
|
||||
|
||||
## 8. Responsive Design & Accessibility
|
||||
|
||||
### 8.1 Responsive Strategy
|
||||
|
||||
{{responsive_accessibility_strategy}}
|
||||
|
||||
---
|
||||
|
||||
## 9. Implementation Guidance
|
||||
|
||||
### 9.1 Completion Summary
|
||||
|
||||
{{completion_summary}}
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Related Documents
|
||||
|
||||
- Product Requirements: `{{prd_file}}`
|
||||
- Product Brief: `{{brief_file}}`
|
||||
- Brainstorming: `{{brainstorm_file}}`
|
||||
|
||||
### Core Interactive Deliverables
|
||||
|
||||
This UX Design Specification was created through visual collaboration:
|
||||
|
||||
- **Color Theme Visualizer**: {{color_themes_html}}
|
||||
- Interactive HTML showing all color theme options explored
|
||||
- Live UI component examples in each theme
|
||||
- Side-by-side comparison and semantic color usage
|
||||
|
||||
- **Design Direction Mockups**: {{design_directions_html}}
|
||||
- Interactive HTML with 6-8 complete design approaches
|
||||
- Full-screen mockups of key screens
|
||||
- Design philosophy and rationale for each direction
|
||||
|
||||
### Optional Enhancement Deliverables
|
||||
|
||||
_This section will be populated if additional UX artifacts are generated through follow-up workflows._
|
||||
|
||||
<!-- Additional deliverables added here by other workflows -->
|
||||
|
||||
### Next Steps & Follow-Up Workflows
|
||||
|
||||
This UX Design Specification can serve as input to:
|
||||
|
||||
- **Wireframe Generation Workflow** - Create detailed wireframes from user flows
|
||||
- **Figma Design Workflow** - Generate Figma files via MCP integration
|
||||
- **Interactive Prototype Workflow** - Build clickable HTML prototypes
|
||||
- **Component Showcase Workflow** - Create interactive component library
|
||||
- **AI Frontend Prompt Workflow** - Generate prompts for v0, Lovable, Bolt, etc.
|
||||
- **Solution Architecture Workflow** - Define technical architecture with UX context
|
||||
|
||||
### Version History
|
||||
|
||||
| Date | Version | Changes | Author |
|
||||
| -------- | ------- | ------------------------------- | ------------- |
|
||||
| {{date}} | 1.0 | Initial UX Design Specification | {{user_name}} |
|
||||
|
||||
---
|
||||
|
||||
_This UX Design Specification was created through collaborative design facilitation, not template generation. All decisions were made with user input and are documented with rationale._
|
||||
@@ -0,0 +1,42 @@
|
||||
# Create UX Design Workflow Configuration
|
||||
name: create-ux-design
|
||||
description: "Collaborative UX design facilitation workflow that creates exceptional user experiences through visual exploration and informed decision-making. Unlike template-driven approaches, this workflow facilitates discovery, generates visual options, and collaboratively designs the UX with the user at every step."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Input requirements - We work from PRD, Brief, or Brainstorming docs
|
||||
recommended_inputs:
|
||||
- prd: "Product Requirements Document with features and user journeys"
|
||||
- product_brief: "Product brief with vision and target users"
|
||||
- brainstorming: "Brainstorming documents with ideas and concepts"
|
||||
|
||||
# Input file references (fuzzy matched from output folder)
|
||||
prd_file: "{output_folder}/bmm-PRD.md or PRD.md or product-requirements.md"
|
||||
brief_file: "{output_folder}/product-brief.md or brief.md or project-brief.md"
|
||||
brainstorm_file: "{output_folder}/brainstorming.md or brainstorm.md or ideation.md"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/create-ux-design"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
template: "{installed_path}/ux-design-template.md"
|
||||
|
||||
# Knowledge bases for intelligent UX decisions
|
||||
ux_pattern_catalog: "{installed_path}/ux-pattern-catalog.yaml"
|
||||
color_psychology: "{installed_path}/color-psychology.yaml"
|
||||
layout_patterns: "{installed_path}/layout-patterns.yaml"
|
||||
|
||||
# Output configuration - Progressive saves throughout workflow
|
||||
default_output_file: "{output_folder}/ux-design-specification.md"
|
||||
color_themes_html: "{output_folder}/ux-color-themes.html"
|
||||
design_directions_html: "{output_folder}/ux-design-directions.html"
|
||||
|
||||
standalone: true
|
||||
222
bmad/bmm/workflows/2-plan-workflows/gdd/README.md
Normal file
222
bmad/bmm/workflows/2-plan-workflows/gdd/README.md
Normal file
@@ -0,0 +1,222 @@
|
||||
# Game Design Document (GDD) Workflow
|
||||
|
||||
This folder contains the GDD workflow for game projects, replacing the traditional PRD approach with game-specific documentation.
|
||||
|
||||
## Overview
|
||||
|
||||
The GDD workflow creates a comprehensive Game Design Document that captures:
|
||||
|
||||
- Core gameplay mechanics and pillars
|
||||
- Game type-specific elements (RPG systems, platformer movement, puzzle mechanics, etc.)
|
||||
- Level design framework
|
||||
- Art and audio direction
|
||||
- Technical specifications (platform-agnostic)
|
||||
- Development epics
|
||||
|
||||
## Architecture
|
||||
|
||||
### Universal Template
|
||||
|
||||
`gdd-template.md` contains sections common to ALL game types:
|
||||
|
||||
- Executive Summary
|
||||
- Goals and Context
|
||||
- Core Gameplay
|
||||
- Win/Loss Conditions
|
||||
- Progression and Balance
|
||||
- Level Design Framework
|
||||
- Art and Audio Direction
|
||||
- Technical Specs
|
||||
- Development Epics
|
||||
- Success Metrics
|
||||
|
||||
### Game-Type-Specific Injection
|
||||
|
||||
The template includes a `{{GAME_TYPE_SPECIFIC_SECTIONS}}` placeholder that gets replaced with game-type-specific content.
|
||||
|
||||
### Game Types Registry
|
||||
|
||||
`game-types.csv` defines 24+ game types with:
|
||||
|
||||
- **id**: Unique identifier (e.g., `action-platformer`, `rpg`, `roguelike`)
|
||||
- **name**: Human-readable name
|
||||
- **description**: Brief description of the game type
|
||||
- **genre_tags**: Searchable tags
|
||||
- **fragment_file**: Path to type-specific template fragment
|
||||
|
||||
### Game-Type Fragments
|
||||
|
||||
Located in `game-types/` folder, these markdown files contain sections specific to each game type:
|
||||
|
||||
**action-platformer.md**:
|
||||
|
||||
- Movement System (jump mechanics, air control, special moves)
|
||||
- Combat System (attack types, combos, enemy AI)
|
||||
- Level Design Patterns (platforming challenges, combat arenas)
|
||||
- Player Abilities and Unlocks
|
||||
|
||||
**rpg.md**:
|
||||
|
||||
- Character System (stats, classes, leveling)
|
||||
- Inventory and Equipment
|
||||
- Quest System
|
||||
- World and Exploration
|
||||
- NPC and Dialogue
|
||||
- Combat System
|
||||
|
||||
**puzzle.md**:
|
||||
|
||||
- Core Puzzle Mechanics
|
||||
- Puzzle Progression
|
||||
- Level Structure
|
||||
- Player Assistance
|
||||
- Replayability
|
||||
|
||||
**roguelike.md**:
|
||||
|
||||
- Run Structure
|
||||
- Procedural Generation
|
||||
- Permadeath and Progression
|
||||
- Item and Upgrade System
|
||||
- Character Selection
|
||||
- Difficulty Modifiers
|
||||
|
||||
...and 20+ more game types!
|
||||
|
||||
## Workflow Flow
|
||||
|
||||
1. **Router Detection** (instructions-router.md):
|
||||
- Step 3 asks for project type
|
||||
- If "Game" selected → sets `workflow_type = "gdd"`
|
||||
- Skips standard level classification
|
||||
- Jumps to GDD-specific assessment
|
||||
|
||||
2. **Game Type Selection** (instructions-gdd.md Step 1):
|
||||
- Presents 9 common game types + "Other"
|
||||
- Maps selection to `game-types.csv`
|
||||
- Loads corresponding fragment file
|
||||
- Stores `game_type` for injection
|
||||
|
||||
3. **Universal GDD Sections** (Steps 2-5, 7-13):
|
||||
- Platform and target audience
|
||||
- Goals and context
|
||||
- Core gameplay (pillars, loop, win/loss)
|
||||
- Mechanics and controls
|
||||
- Progression and balance
|
||||
- Level design
|
||||
- Art and audio
|
||||
- Technical specs
|
||||
- Epics and metrics
|
||||
|
||||
4. **Game-Type Injection** (Step 6):
|
||||
- Loads fragment from `game-types/{game_type}.md`
|
||||
- For each `{{placeholder}}` in fragment, elicits details
|
||||
- Injects completed sections into `{{GAME_TYPE_SPECIFIC_SECTIONS}}`
|
||||
|
||||
5. **Solutioning Handoff** (Step 14):
|
||||
- Routes to `3-solutioning` workflow
|
||||
- Platform/engine specifics handled by solutioning registry
|
||||
- Game-\* entries in solutioning `registry.csv` provide engine-specific guidance
|
||||
|
||||
## Platform vs. Game Type Separation
|
||||
|
||||
**GDD (this workflow)**: Game-type specifics
|
||||
|
||||
- What makes an RPG an RPG (stats, quests, inventory)
|
||||
- What makes a platformer a platformer (jump mechanics, level design)
|
||||
- Genre-defining mechanics and systems
|
||||
|
||||
**Solutioning (3-solutioning workflow)**: Platform/engine specifics
|
||||
|
||||
- Unity vs. Godot vs. Phaser vs. Unreal
|
||||
- 2D vs. 3D rendering
|
||||
- Physics engines
|
||||
- Input systems
|
||||
- Platform constraints (mobile, web, console)
|
||||
|
||||
This separation allows:
|
||||
|
||||
- Single universal GDD regardless of platform
|
||||
- Platform decisions made during architecture phase
|
||||
- Easy platform pivots without rewriting GDD
|
||||
|
||||
## Output
|
||||
|
||||
**GDD.md**: Complete game design document with:
|
||||
|
||||
- All universal sections filled
|
||||
- Game-type-specific sections injected
|
||||
- Ready for solutioning handoff
|
||||
|
||||
## Example Game Types
|
||||
|
||||
| ID | Name | Key Sections |
|
||||
| ----------------- | ----------------- | ------------------------------------------------- |
|
||||
| action-platformer | Action Platformer | Movement, Combat, Level Patterns, Abilities |
|
||||
| rpg | RPG | Character System, Inventory, Quests, World, NPCs |
|
||||
| puzzle | Puzzle | Puzzle Mechanics, Progression, Level Structure |
|
||||
| roguelike | Roguelike | Run Structure, Procgen, Permadeath, Items |
|
||||
| shooter | Shooter | Weapon Systems, Enemy AI, Arena Design |
|
||||
| strategy | Strategy | Resources, Units, AI, Victory Conditions |
|
||||
| metroidvania | Metroidvania | Interconnected World, Ability Gating, Exploration |
|
||||
| visual-novel | Visual Novel | Branching Story, Dialogue Trees, Choices |
|
||||
| tower-defense | Tower Defense | Waves, Tower Types, Placement, Economy |
|
||||
| card-game | Card Game | Deck Building, Card Mechanics, Turn System |
|
||||
|
||||
...and 14+ more!
|
||||
|
||||
## Adding New Game Types
|
||||
|
||||
1. Add row to `game-types.csv`:
|
||||
|
||||
```csv
|
||||
new-type,New Type Name,"Description",tags,new-type.md
|
||||
```
|
||||
|
||||
2. Create `game-types/new-type.md`:
|
||||
|
||||
```markdown
|
||||
## New Type Specific Elements
|
||||
|
||||
### System Name
|
||||
|
||||
{{system_placeholder}}
|
||||
|
||||
**Details:**
|
||||
|
||||
- Element 1
|
||||
- Element 2
|
||||
```
|
||||
|
||||
3. The workflow automatically uses it!
|
||||
|
||||
## Integration with Solutioning
|
||||
|
||||
When a game project completes the GDD and moves to solutioning:
|
||||
|
||||
1. Solutioning workflow reads `project_type == "game"`
|
||||
2. Loads GDD.md instead of PRD.md
|
||||
3. Matches game platforms to solutioning `registry.csv` game-\* entries
|
||||
4. Provides engine-specific guidance (Unity, Godot, Phaser, etc.)
|
||||
5. Generates architecture.md with platform decisions
|
||||
6. Creates per-epic tech specs
|
||||
|
||||
Example solutioning registry entries:
|
||||
|
||||
- `game-unity-2d`: Unity 2D games
|
||||
- `game-godot-3d`: Godot 3D games
|
||||
- `game-phaser`: Phaser web games
|
||||
- `game-unreal-3d`: Unreal Engine games
|
||||
- `game-custom-3d-rust`: Custom Rust game engines
|
||||
|
||||
## Philosophy
|
||||
|
||||
**Game projects are fundamentally different from software products**:
|
||||
|
||||
- Gameplay feel > feature lists
|
||||
- Playtesting > user testing
|
||||
- Game pillars > product goals
|
||||
- Mechanics > requirements
|
||||
- Fun > utility
|
||||
|
||||
The GDD workflow respects these differences while maintaining BMAD Method rigor.
|
||||
148
bmad/bmm/workflows/2-plan-workflows/gdd/checklist.md
Normal file
148
bmad/bmm/workflows/2-plan-workflows/gdd/checklist.md
Normal file
@@ -0,0 +1,148 @@
|
||||
# GDD Workflow Validation Checklist
|
||||
|
||||
**Purpose**: Validate GDD workflow outputs are complete, playable, and ready for solutioning.
|
||||
|
||||
**Scope**: All game project levels (0-4)
|
||||
|
||||
**Expected Outputs**: GDD.md, epics.md
|
||||
|
||||
---
|
||||
|
||||
## 1. Output Files Exist
|
||||
|
||||
- [ ] GDD.md created in output folder
|
||||
- [ ] epics.md created in output folder (separate file)
|
||||
- [ ] bmm-workflow-status.md updated
|
||||
- [ ] No unfilled {{template_variables}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Core Gameplay Definition (CRITICAL)
|
||||
|
||||
### Game Pillars
|
||||
|
||||
- [ ] **2-4 game pillars defined** (fundamental gameplay elements)
|
||||
- [ ] Each pillar is game-defining (not superficial)
|
||||
- [ ] Pillars are distinct (don't overlap)
|
||||
|
||||
### Core Gameplay Loop
|
||||
|
||||
- [ ] **Complete cycle documented** (what player does repeatedly)
|
||||
- [ ] Loop shows: player action → outcome → reward → motivation to repeat
|
||||
- [ ] Loop sounds compelling and repeatable
|
||||
|
||||
### Win/Loss Conditions
|
||||
|
||||
- [ ] Victory conditions clearly defined
|
||||
- [ ] Failure conditions defined (or N/A for sandbox games)
|
||||
- [ ] Conditions are testable
|
||||
|
||||
---
|
||||
|
||||
## 3. Game Mechanics and Systems
|
||||
|
||||
### Mechanics
|
||||
|
||||
- [ ] Primary mechanics described in detail
|
||||
- [ ] Mechanics support the game pillars
|
||||
- [ ] Player interaction with mechanics is clear
|
||||
|
||||
### Progression
|
||||
|
||||
- [ ] Player progression system defined (skill/power/unlock/narrative)
|
||||
- [ ] Difficulty curve explained
|
||||
- [ ] Progression feels rewarding
|
||||
|
||||
### Platform and Controls
|
||||
|
||||
- [ ] Target platforms specified
|
||||
- [ ] Control scheme appropriate for platforms
|
||||
- [ ] Input method clear (keyboard/gamepad/touch/etc.)
|
||||
|
||||
---
|
||||
|
||||
## 4. Story Quality (If epics.md exists)
|
||||
|
||||
### Epic Structure
|
||||
|
||||
- [ ] Epics represent deliverable game features
|
||||
- [ ] Epic sequence makes sense for game development
|
||||
- [ ] Stories show implementation path
|
||||
|
||||
### Story Sequencing (If stories present)
|
||||
|
||||
- [ ] **Vertical slices**: Each story delivers playable functionality
|
||||
- [ ] **Sequential ordering**: Stories build progressively
|
||||
- [ ] **No forward dependencies**: Each story builds on previous work only
|
||||
- [ ] Stories result in testable game features
|
||||
|
||||
---
|
||||
|
||||
## 5. Technical Specifications
|
||||
|
||||
### Performance and Platform
|
||||
|
||||
- [ ] Performance requirements specified (frame rate, resolution, etc.)
|
||||
- [ ] Platform-specific considerations noted
|
||||
- [ ] Asset requirements estimated
|
||||
|
||||
### Production Scope
|
||||
|
||||
- [ ] Art requirements realistic for project scale
|
||||
- [ ] Audio requirements documented
|
||||
- [ ] Scope matches project level and resources
|
||||
|
||||
---
|
||||
|
||||
## 6. Narrative Integration (If Applicable)
|
||||
|
||||
**If narrative-design.md was generated:**
|
||||
|
||||
- [ ] Narrative aligns with GDD game design
|
||||
- [ ] Story supports gameplay (not fighting it)
|
||||
- [ ] Tone consistent across GDD and narrative docs
|
||||
|
||||
---
|
||||
|
||||
## 7. Consistency
|
||||
|
||||
- [ ] Epic titles match between GDD.md and epics.md
|
||||
- [ ] Game type identified and appropriate
|
||||
- [ ] Terminology consistent throughout
|
||||
- [ ] No contradictions between sections
|
||||
|
||||
---
|
||||
|
||||
## 8. Readiness for Solutioning
|
||||
|
||||
- [ ] Sufficient detail for engine/platform selection
|
||||
- [ ] Game systems defined enough for technical architecture
|
||||
- [ ] Clear what needs to be built
|
||||
- [ ] Playable vision (reader can envision playing the game)
|
||||
|
||||
---
|
||||
|
||||
## 9. Critical Failures (Auto-Fail)
|
||||
|
||||
- [ ] ❌ **No core gameplay loop** (can't be a game without this)
|
||||
- [ ] ❌ **No game pillars** (game-defining elements missing)
|
||||
- [ ] ❌ **No mechanics** (what does player actually DO?)
|
||||
- [ ] ❌ **No epics.md file** (implementation roadmap required)
|
||||
- [ ] ❌ **Engine/tech in GDD** (should defer to solutioning workflow)
|
||||
|
||||
---
|
||||
|
||||
## Validation Notes
|
||||
|
||||
**Document any findings:**
|
||||
|
||||
- Game concept strength: [Compelling / Interesting / Unclear / Weak]
|
||||
- Strengths:
|
||||
- Issues to address:
|
||||
- Recommended actions:
|
||||
|
||||
**Ready for solutioning?** [Yes / No - explain]
|
||||
|
||||
---
|
||||
|
||||
_Adapt based on game type and narrative complexity. Core gameplay must always be solid._
|
||||
25
bmad/bmm/workflows/2-plan-workflows/gdd/game-types.csv
Normal file
25
bmad/bmm/workflows/2-plan-workflows/gdd/game-types.csv
Normal file
@@ -0,0 +1,25 @@
|
||||
id,name,description,genre_tags,fragment_file
|
||||
action-platformer,Action Platformer,"Side-scrolling or 3D platforming with combat mechanics","action,platformer,combat,movement",action-platformer.md
|
||||
puzzle,Puzzle,"Logic-based challenges and problem-solving","puzzle,logic,cerebral",puzzle.md
|
||||
rpg,RPG,"Character progression, stats, inventory, quests","rpg,stats,inventory,quests,narrative",rpg.md
|
||||
strategy,Strategy,"Resource management, tactical decisions, long-term planning","strategy,tactics,resources,planning",strategy.md
|
||||
shooter,Shooter,"Projectile combat, aiming mechanics, arena/level design","shooter,combat,aiming,fps,tps",shooter.md
|
||||
adventure,Adventure,"Story-driven exploration and narrative","adventure,narrative,exploration,story",adventure.md
|
||||
simulation,Simulation,"Realistic systems, management, building","simulation,management,sandbox,systems",simulation.md
|
||||
roguelike,Roguelike,"Procedural generation, permadeath, run-based progression","roguelike,procedural,permadeath,runs",roguelike.md
|
||||
moba,MOBA,"Multiplayer team battles, hero/champion selection, lanes","moba,multiplayer,pvp,heroes,lanes",moba.md
|
||||
fighting,Fighting,"1v1 combat, combos, frame data, competitive","fighting,combat,competitive,combos,pvp",fighting.md
|
||||
racing,Racing,"Vehicle control, tracks, speed, lap times","racing,vehicles,tracks,speed",racing.md
|
||||
sports,Sports,"Team-based or individual sports simulation","sports,teams,realistic,physics",sports.md
|
||||
survival,Survival,"Resource gathering, crafting, persistent threats","survival,crafting,resources,danger",survival.md
|
||||
horror,Horror,"Atmosphere, tension, limited resources, fear mechanics","horror,atmosphere,tension,fear",horror.md
|
||||
idle-incremental,Idle/Incremental,"Passive progression, upgrades, automation","idle,incremental,automation,progression",idle-incremental.md
|
||||
card-game,Card Game,"Deck building, card mechanics, turn-based strategy","card,deck-building,strategy,turns",card-game.md
|
||||
tower-defense,Tower Defense,"Wave-based defense, tower placement, resource management","tower-defense,waves,placement,strategy",tower-defense.md
|
||||
metroidvania,Metroidvania,"Interconnected world, ability gating, exploration","metroidvania,exploration,abilities,interconnected",metroidvania.md
|
||||
visual-novel,Visual Novel,"Narrative choices, branching story, dialogue","visual-novel,narrative,choices,story",visual-novel.md
|
||||
rhythm,Rhythm,"Music synchronization, timing-based gameplay","rhythm,music,timing,beats",rhythm.md
|
||||
turn-based-tactics,Turn-Based Tactics,"Grid-based movement, turn order, positioning","tactics,turn-based,grid,positioning",turn-based-tactics.md
|
||||
sandbox,Sandbox,"Creative freedom, building, minimal objectives","sandbox,creative,building,freedom",sandbox.md
|
||||
text-based,Text-Based,"Text input/output, parser or choice-based","text,parser,interactive-fiction,mud",text-based.md
|
||||
party-game,Party Game,"Local multiplayer, minigames, casual fun","party,multiplayer,minigames,casual",party-game.md
|
||||
|
@@ -0,0 +1,45 @@
|
||||
## Action Platformer Specific Elements
|
||||
|
||||
### Movement System
|
||||
|
||||
{{movement_mechanics}}
|
||||
|
||||
**Core movement abilities:**
|
||||
|
||||
- Jump mechanics (height, air control, coyote time)
|
||||
- Running/walking speed
|
||||
- Special movement (dash, wall-jump, double-jump, etc.)
|
||||
|
||||
### Combat System
|
||||
|
||||
{{combat_system}}
|
||||
|
||||
**Combat mechanics:**
|
||||
|
||||
- Attack types (melee, ranged, special)
|
||||
- Combo system
|
||||
- Enemy AI behavior patterns
|
||||
- Hit feedback and impact
|
||||
|
||||
### Level Design Patterns
|
||||
|
||||
{{level_design_patterns}}
|
||||
|
||||
**Level structure:**
|
||||
|
||||
- Platforming challenges
|
||||
- Combat arenas
|
||||
- Secret areas and collectibles
|
||||
- Checkpoint placement
|
||||
- Difficulty spikes and pacing
|
||||
|
||||
### Player Abilities and Unlocks
|
||||
|
||||
{{player_abilities}}
|
||||
|
||||
**Ability progression:**
|
||||
|
||||
- Starting abilities
|
||||
- Unlockable abilities
|
||||
- Ability synergies
|
||||
- Upgrade paths
|
||||
@@ -0,0 +1,84 @@
|
||||
## Adventure Specific Elements
|
||||
|
||||
<narrative-workflow-recommended>
|
||||
This game type is **narrative-heavy**. Consider running the Narrative Design workflow after completing the GDD to create:
|
||||
- Detailed story structure and beats
|
||||
- Character profiles and arcs
|
||||
- World lore and history
|
||||
- Dialogue framework
|
||||
- Environmental storytelling
|
||||
</narrative-workflow-recommended>
|
||||
|
||||
### Exploration Mechanics
|
||||
|
||||
{{exploration_mechanics}}
|
||||
|
||||
**Exploration design:**
|
||||
|
||||
- World structure (linear, open, hub-based, interconnected)
|
||||
- Movement and traversal
|
||||
- Observation and inspection mechanics
|
||||
- Discovery rewards (story reveals, items, secrets)
|
||||
- Pacing of exploration vs. story
|
||||
|
||||
### Story Integration
|
||||
|
||||
{{story_integration}}
|
||||
|
||||
**Narrative gameplay:**
|
||||
|
||||
- Story delivery methods (cutscenes, in-game, environmental)
|
||||
- Player agency in story (linear, branching, player-driven)
|
||||
- Story pacing (acts, beats, tension/release)
|
||||
- Character introduction and development
|
||||
- Climax and resolution structure
|
||||
|
||||
**Note:** Detailed story elements (plot, characters, lore) belong in the Narrative Design Document.
|
||||
|
||||
### Puzzle Systems
|
||||
|
||||
{{puzzle_systems}}
|
||||
|
||||
**Puzzle integration:**
|
||||
|
||||
- Puzzle types (inventory, logic, environmental, dialogue)
|
||||
- Puzzle difficulty curve
|
||||
- Hint systems
|
||||
- Puzzle-story connection (narrative purpose)
|
||||
- Optional vs. required puzzles
|
||||
|
||||
### Character Interaction
|
||||
|
||||
{{character_interaction}}
|
||||
|
||||
**NPC systems:**
|
||||
|
||||
- Dialogue system (branching, linear, choice-based)
|
||||
- Character relationships
|
||||
- NPC schedules/behaviors
|
||||
- Companion mechanics (if applicable)
|
||||
- Memorable character moments
|
||||
|
||||
### Inventory and Items
|
||||
|
||||
{{inventory_items}}
|
||||
|
||||
**Item systems:**
|
||||
|
||||
- Inventory scope (key items, collectibles, consumables)
|
||||
- Item examination/description
|
||||
- Combination/crafting (if applicable)
|
||||
- Story-critical items vs. optional items
|
||||
- Item-based progression gates
|
||||
|
||||
### Environmental Storytelling
|
||||
|
||||
{{environmental_storytelling}}
|
||||
|
||||
**World narrative:**
|
||||
|
||||
- Visual storytelling techniques
|
||||
- Audio atmosphere
|
||||
- Readable documents (journals, notes, signs)
|
||||
- Environmental clues
|
||||
- Show vs. tell balance
|
||||
@@ -0,0 +1,76 @@
|
||||
## Card Game Specific Elements
|
||||
|
||||
### Card Types and Effects
|
||||
|
||||
{{card_types}}
|
||||
|
||||
**Card design:**
|
||||
|
||||
- Card categories (creatures, spells, enchantments, etc.)
|
||||
- Card rarity tiers (common, rare, epic, legendary)
|
||||
- Card attributes (cost, power, health, etc.)
|
||||
- Effect types (damage, healing, draw, control, etc.)
|
||||
- Keywords and abilities
|
||||
- Card synergies
|
||||
|
||||
### Deck Building
|
||||
|
||||
{{deck_building}}
|
||||
|
||||
**Deck construction:**
|
||||
|
||||
- Deck size limits (minimum, maximum)
|
||||
- Card quantity limits (e.g., max 2 copies)
|
||||
- Class/faction restrictions
|
||||
- Deck archetypes (aggro, control, combo, midrange)
|
||||
- Sideboard mechanics (if applicable)
|
||||
- Pre-built vs. custom decks
|
||||
|
||||
### Mana/Resource System
|
||||
|
||||
{{mana_resources}}
|
||||
|
||||
**Resource mechanics:**
|
||||
|
||||
- Mana generation (per turn, from cards, etc.)
|
||||
- Mana curve design
|
||||
- Resource types (colored mana, energy, etc.)
|
||||
- Ramp mechanics
|
||||
- Resource denial strategies
|
||||
|
||||
### Turn Structure
|
||||
|
||||
{{turn_structure}}
|
||||
|
||||
**Game flow:**
|
||||
|
||||
- Turn phases (draw, main, combat, end)
|
||||
- Priority and response windows
|
||||
- Simultaneous vs. alternating turns
|
||||
- Time limits per turn
|
||||
- Match length targets
|
||||
|
||||
### Card Collection and Progression
|
||||
|
||||
{{collection_progression}}
|
||||
|
||||
**Player progression:**
|
||||
|
||||
- Card acquisition (packs, rewards, crafting)
|
||||
- Deck unlocks
|
||||
- Currency systems (gold, dust, wildcards)
|
||||
- Free-to-play balance
|
||||
- Collection completion incentives
|
||||
|
||||
### Game Modes
|
||||
|
||||
{{game_modes}}
|
||||
|
||||
**Mode variety:**
|
||||
|
||||
- Ranked ladder
|
||||
- Draft/Arena modes
|
||||
- Campaign/story mode
|
||||
- Casual/unranked
|
||||
- Special event modes
|
||||
- Tournament formats
|
||||
@@ -0,0 +1,89 @@
|
||||
## Fighting Game Specific Elements
|
||||
|
||||
### Character Roster
|
||||
|
||||
{{character_roster}}
|
||||
|
||||
**Fighter design:**
|
||||
|
||||
- Roster size (launch + planned DLC)
|
||||
- Character archetypes (rushdown, zoner, grappler, all-rounder, etc.)
|
||||
- Move list diversity
|
||||
- Complexity tiers (beginner vs. expert characters)
|
||||
- Balance philosophy (everyone viable vs. tier system)
|
||||
|
||||
### Move Lists and Frame Data
|
||||
|
||||
{{moves_frame_data}}
|
||||
|
||||
**Combat mechanics:**
|
||||
|
||||
- Normal moves (light, medium, heavy)
|
||||
- Special moves (quarter-circle, charge, etc.)
|
||||
- Super/ultimate moves
|
||||
- Frame data (startup, active, recovery, advantage)
|
||||
- Hit/hurt boxes
|
||||
- Command inputs vs. simplified inputs
|
||||
|
||||
### Combo System
|
||||
|
||||
{{combo_system}}
|
||||
|
||||
**Combo design:**
|
||||
|
||||
- Combo structure (links, cancels, chains)
|
||||
- Juggle system
|
||||
- Wall/ground bounces
|
||||
- Combo scaling
|
||||
- Reset opportunities
|
||||
- Optimal vs. practical combos
|
||||
|
||||
### Defensive Mechanics
|
||||
|
||||
{{defensive_mechanics}}
|
||||
|
||||
**Defense options:**
|
||||
|
||||
- Blocking (high, low, crossup protection)
|
||||
- Dodging/rolling/backdashing
|
||||
- Parries/counters
|
||||
- Pushblock/advancing guard
|
||||
- Invincibility frames
|
||||
- Escape options (burst, breaker, etc.)
|
||||
|
||||
### Stage Design
|
||||
|
||||
{{stage_design}}
|
||||
|
||||
**Arena design:**
|
||||
|
||||
- Stage size and boundaries
|
||||
- Wall mechanics (wall combos, wall break)
|
||||
- Interactive elements
|
||||
- Ring-out mechanics (if applicable)
|
||||
- Visual clarity vs. aesthetics
|
||||
|
||||
### Single Player Modes
|
||||
|
||||
{{single_player}}
|
||||
|
||||
**Offline content:**
|
||||
|
||||
- Arcade/story mode
|
||||
- Training mode features
|
||||
- Mission/challenge mode
|
||||
- Boss fights
|
||||
- Unlockables
|
||||
|
||||
### Competitive Features
|
||||
|
||||
{{competitive_features}}
|
||||
|
||||
**Tournament-ready:**
|
||||
|
||||
- Ranked matchmaking
|
||||
- Lobby systems
|
||||
- Replay features
|
||||
- Frame delay/rollback netcode
|
||||
- Spectator mode
|
||||
- Tournament mode
|
||||
86
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/horror.md
Normal file
86
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/horror.md
Normal file
@@ -0,0 +1,86 @@
|
||||
## Horror Game Specific Elements
|
||||
|
||||
<narrative-workflow-recommended>
|
||||
This game type is **narrative-important**. Consider running the Narrative Design workflow after completing the GDD to create:
|
||||
- Detailed story structure and scares
|
||||
- Character backstories and motivations
|
||||
- World lore and mythology
|
||||
- Environmental storytelling
|
||||
- Tension pacing and narrative beats
|
||||
</narrative-workflow-recommended>
|
||||
|
||||
### Atmosphere and Tension Building
|
||||
|
||||
{{atmosphere}}
|
||||
|
||||
**Horror atmosphere:**
|
||||
|
||||
- Visual design (lighting, shadows, color palette)
|
||||
- Audio design (soundscape, silence, music cues)
|
||||
- Environmental storytelling
|
||||
- Pacing of tension and release
|
||||
- Jump scares vs. psychological horror
|
||||
- Safe zones vs. danger zones
|
||||
|
||||
### Fear Mechanics
|
||||
|
||||
{{fear_mechanics}}
|
||||
|
||||
**Core horror systems:**
|
||||
|
||||
- Visibility/darkness mechanics
|
||||
- Limited resources (ammo, health, light)
|
||||
- Vulnerability (combat avoidance, hiding)
|
||||
- Sanity/fear meter (if applicable)
|
||||
- Pursuer/stalker mechanics
|
||||
- Detection systems (line of sight, sound)
|
||||
|
||||
### Enemy/Threat Design
|
||||
|
||||
{{enemy_threat}}
|
||||
|
||||
**Threat systems:**
|
||||
|
||||
- Enemy types (stalker, environmental, psychological)
|
||||
- Enemy behavior (patrol, hunt, ambush)
|
||||
- Telegraphing and tells
|
||||
- Invincible vs. killable enemies
|
||||
- Boss encounters
|
||||
- Encounter frequency and pacing
|
||||
|
||||
### Resource Scarcity
|
||||
|
||||
{{resource_scarcity}}
|
||||
|
||||
**Limited resources:**
|
||||
|
||||
- Ammo/weapon durability
|
||||
- Health items
|
||||
- Light sources (batteries, fuel)
|
||||
- Save points (if limited)
|
||||
- Inventory constraints
|
||||
- Risk vs. reward of exploration
|
||||
|
||||
### Safe Zones and Respite
|
||||
|
||||
{{safe_zones}}
|
||||
|
||||
**Tension management:**
|
||||
|
||||
- Safe room design
|
||||
- Save point placement
|
||||
- Temporary refuge mechanics
|
||||
- Calm before storm pacing
|
||||
- Item management areas
|
||||
|
||||
### Puzzle Integration
|
||||
|
||||
{{puzzles}}
|
||||
|
||||
**Environmental puzzles:**
|
||||
|
||||
- Puzzle types (locks, codes, environmental)
|
||||
- Difficulty balance (accessibility vs. challenge)
|
||||
- Hint systems
|
||||
- Puzzle-tension balance
|
||||
- Narrative purpose of puzzles
|
||||
@@ -0,0 +1,78 @@
|
||||
## Idle/Incremental Game Specific Elements
|
||||
|
||||
### Core Click/Interaction
|
||||
|
||||
{{core_interaction}}
|
||||
|
||||
**Primary mechanic:**
|
||||
|
||||
- Click action (what happens on click)
|
||||
- Click value progression
|
||||
- Auto-click mechanics
|
||||
- Combo/streak systems (if applicable)
|
||||
- Satisfaction and feedback (visual, audio)
|
||||
|
||||
### Upgrade Trees
|
||||
|
||||
{{upgrade_trees}}
|
||||
|
||||
**Upgrade systems:**
|
||||
|
||||
- Upgrade categories (click power, auto-generation, multipliers)
|
||||
- Upgrade costs and scaling
|
||||
- Unlock conditions
|
||||
- Synergies between upgrades
|
||||
- Upgrade branches and choices
|
||||
- Meta-upgrades (affect future runs)
|
||||
|
||||
### Automation Systems
|
||||
|
||||
{{automation}}
|
||||
|
||||
**Passive mechanics:**
|
||||
|
||||
- Auto-clicker unlocks
|
||||
- Manager/worker systems
|
||||
- Multiplier stacking
|
||||
- Offline progression
|
||||
- Automation tiers
|
||||
- Balance between active and idle play
|
||||
|
||||
### Prestige and Reset Mechanics
|
||||
|
||||
{{prestige_reset}}
|
||||
|
||||
**Long-term progression:**
|
||||
|
||||
- Prestige conditions (when to reset)
|
||||
- Persistent bonuses after reset
|
||||
- Prestige currency
|
||||
- Multiple prestige layers (if applicable)
|
||||
- Scaling between runs
|
||||
- Endgame infinite scaling
|
||||
|
||||
### Number Balancing
|
||||
|
||||
{{number_balancing}}
|
||||
|
||||
**Economy design:**
|
||||
|
||||
- Exponential growth curves
|
||||
- Notation systems (K, M, B, T or scientific)
|
||||
- Soft caps and plateaus
|
||||
- Time gates
|
||||
- Pacing of progression
|
||||
- Wall breaking mechanics
|
||||
|
||||
### Meta-Progression
|
||||
|
||||
{{meta_progression}}
|
||||
|
||||
**Long-term engagement:**
|
||||
|
||||
- Achievement system
|
||||
- Collectibles
|
||||
- Alternate game modes
|
||||
- Seasonal content
|
||||
- Challenge runs
|
||||
- Endgame goals
|
||||
@@ -0,0 +1,87 @@
|
||||
## Metroidvania Specific Elements
|
||||
|
||||
<narrative-workflow-recommended>
|
||||
This game type is **narrative-moderate**. Consider running the Narrative Design workflow after completing the GDD to create:
|
||||
- World lore and environmental storytelling
|
||||
- Character encounters and NPC arcs
|
||||
- Backstory reveals through exploration
|
||||
- Optional narrative depth
|
||||
</narrative-workflow-recommended>
|
||||
|
||||
### Interconnected World Map
|
||||
|
||||
{{world_map}}
|
||||
|
||||
**Map design:**
|
||||
|
||||
- World structure (regions, zones, biomes)
|
||||
- Interconnection points (shortcuts, elevators, warps)
|
||||
- Verticality and layering
|
||||
- Secret areas
|
||||
- Map reveal mechanics
|
||||
- Fast travel system (if applicable)
|
||||
|
||||
### Ability-Gating System
|
||||
|
||||
{{ability_gating}}
|
||||
|
||||
**Progression gates:**
|
||||
|
||||
- Core abilities (double jump, dash, wall climb, swim, etc.)
|
||||
- Ability locations and pacing
|
||||
- Soft gates vs. hard gates
|
||||
- Optional abilities
|
||||
- Sequence breaking considerations
|
||||
- Ability synergies
|
||||
|
||||
### Backtracking Design
|
||||
|
||||
{{backtracking}}
|
||||
|
||||
**Return mechanics:**
|
||||
|
||||
- Obvious backtrack opportunities
|
||||
- Hidden backtrack rewards
|
||||
- Fast travel to reduce tedium
|
||||
- Enemy respawn considerations
|
||||
- Changed world state (if applicable)
|
||||
- Completionist incentives
|
||||
|
||||
### Exploration Rewards
|
||||
|
||||
{{exploration_rewards}}
|
||||
|
||||
**Discovery incentives:**
|
||||
|
||||
- Health/energy upgrades
|
||||
- Ability upgrades
|
||||
- Collectibles (lore, cosmetics)
|
||||
- Secret bosses
|
||||
- Optional areas
|
||||
- Completion percentage tracking
|
||||
|
||||
### Combat System
|
||||
|
||||
{{combat_system}}
|
||||
|
||||
**Combat mechanics:**
|
||||
|
||||
- Attack types (melee, ranged, magic)
|
||||
- Boss fight design
|
||||
- Enemy variety and placement
|
||||
- Combat progression
|
||||
- Defensive options
|
||||
- Difficulty balance
|
||||
|
||||
### Sequence Breaking
|
||||
|
||||
{{sequence_breaking}}
|
||||
|
||||
**Advanced play:**
|
||||
|
||||
- Intended vs. unintended skips
|
||||
- Speedrun considerations
|
||||
- Difficulty of sequence breaks
|
||||
- Reward for sequence breaking
|
||||
- Developer stance on breaks
|
||||
- Game completion without all abilities
|
||||
74
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/moba.md
Normal file
74
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/moba.md
Normal file
@@ -0,0 +1,74 @@
|
||||
## MOBA Specific Elements
|
||||
|
||||
### Hero/Champion Roster
|
||||
|
||||
{{hero_roster}}
|
||||
|
||||
**Character design:**
|
||||
|
||||
- Hero count (initial roster, planned additions)
|
||||
- Hero roles (tank, support, carry, assassin, mage, etc.)
|
||||
- Unique abilities per hero (Q, W, E, R + passive)
|
||||
- Hero complexity tiers (beginner-friendly vs. advanced)
|
||||
- Visual and thematic diversity
|
||||
- Counter-pick dynamics
|
||||
|
||||
### Lane Structure and Map
|
||||
|
||||
{{lane_map}}
|
||||
|
||||
**Map design:**
|
||||
|
||||
- Lane configuration (3-lane, 2-lane, custom)
|
||||
- Jungle/neutral areas
|
||||
- Objective locations (towers, inhibitors, nexus/ancient)
|
||||
- Spawn points and fountains
|
||||
- Vision mechanics (wards, fog of war)
|
||||
|
||||
### Item and Build System
|
||||
|
||||
{{item_build}}
|
||||
|
||||
**Itemization:**
|
||||
|
||||
- Item categories (offensive, defensive, utility, consumables)
|
||||
- Gold economy
|
||||
- Build paths and item trees
|
||||
- Situational itemization
|
||||
- Starting items vs. late-game items
|
||||
|
||||
### Team Composition and Roles
|
||||
|
||||
{{team_composition}}
|
||||
|
||||
**Team strategy:**
|
||||
|
||||
- Role requirements (1-3-1, 2-1-2, etc.)
|
||||
- Team synergies
|
||||
- Draft/ban phase (if applicable)
|
||||
- Meta considerations
|
||||
- Flexible vs. rigid compositions
|
||||
|
||||
### Match Phases
|
||||
|
||||
{{match_phases}}
|
||||
|
||||
**Game flow:**
|
||||
|
||||
- Early game (laning phase)
|
||||
- Mid game (roaming, objectives)
|
||||
- Late game (team fights, sieging)
|
||||
- Phase transition mechanics
|
||||
- Comeback mechanics
|
||||
|
||||
### Objectives and Win Conditions
|
||||
|
||||
{{objectives_victory}}
|
||||
|
||||
**Strategic objectives:**
|
||||
|
||||
- Primary objective (destroy base/nexus/ancient)
|
||||
- Secondary objectives (towers, dragons, baron, roshan, etc.)
|
||||
- Neutral camps
|
||||
- Vision control objectives
|
||||
- Time limits and sudden death (if applicable)
|
||||
@@ -0,0 +1,79 @@
|
||||
## Party Game Specific Elements
|
||||
|
||||
### Minigame Variety
|
||||
|
||||
{{minigame_variety}}
|
||||
|
||||
**Minigame design:**
|
||||
|
||||
- Minigame count (launch + DLC)
|
||||
- Genre variety (racing, puzzle, reflex, trivia, etc.)
|
||||
- Minigame length (15-60 seconds typical)
|
||||
- Skill vs. luck balance
|
||||
- Team vs. FFA minigames
|
||||
- Accessibility across skill levels
|
||||
|
||||
### Turn Structure
|
||||
|
||||
{{turn_structure}}
|
||||
|
||||
**Game flow:**
|
||||
|
||||
- Board game structure (if applicable)
|
||||
- Turn order (fixed, random, earned)
|
||||
- Turn actions (roll dice, move, minigame, etc.)
|
||||
- Event spaces
|
||||
- Special mechanics (warp, steal, bonus)
|
||||
- Match length (rounds, turns, time)
|
||||
|
||||
### Player Elimination vs. Points
|
||||
|
||||
{{scoring_elimination}}
|
||||
|
||||
**Competition design:**
|
||||
|
||||
- Points-based (everyone plays to the end)
|
||||
- Elimination (last player standing)
|
||||
- Hybrid systems
|
||||
- Comeback mechanics
|
||||
- Handicap systems
|
||||
- Victory conditions
|
||||
|
||||
### Local Multiplayer UX
|
||||
|
||||
{{local_multiplayer}}
|
||||
|
||||
**Couch co-op design:**
|
||||
|
||||
- Controller sharing vs. individual controllers
|
||||
- Screen layout (split-screen, shared screen)
|
||||
- Turn clarity (whose turn indicators)
|
||||
- Spectator experience (watching others play)
|
||||
- Player join/drop mechanics
|
||||
- Tutorial integration for new players
|
||||
|
||||
### Accessibility and Skill Range
|
||||
|
||||
{{accessibility}}
|
||||
|
||||
**Inclusive design:**
|
||||
|
||||
- Skill floor (easy to understand)
|
||||
- Skill ceiling (depth for experienced players)
|
||||
- Luck elements to balance skill gaps
|
||||
- Assist modes or handicaps
|
||||
- Child-friendly content
|
||||
- Colorblind modes and accessibility
|
||||
|
||||
### Session Length
|
||||
|
||||
{{session_length}}
|
||||
|
||||
**Time management:**
|
||||
|
||||
- Quick play (5-10 minutes)
|
||||
- Standard match (15-30 minutes)
|
||||
- Extended match (30+ minutes)
|
||||
- Drop-in/drop-out support
|
||||
- Pause and resume
|
||||
- Party management (hosting, invites)
|
||||
58
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/puzzle.md
Normal file
58
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/puzzle.md
Normal file
@@ -0,0 +1,58 @@
|
||||
## Puzzle Game Specific Elements
|
||||
|
||||
### Core Puzzle Mechanics
|
||||
|
||||
{{puzzle_mechanics}}
|
||||
|
||||
**Puzzle elements:**
|
||||
|
||||
- Primary puzzle mechanic(s)
|
||||
- Supporting mechanics
|
||||
- Mechanic interactions
|
||||
- Constraint systems
|
||||
|
||||
### Puzzle Progression
|
||||
|
||||
{{puzzle_progression}}
|
||||
|
||||
**Difficulty progression:**
|
||||
|
||||
- Tutorial/introduction puzzles
|
||||
- Core concept puzzles
|
||||
- Combined mechanic puzzles
|
||||
- Expert/bonus puzzles
|
||||
- Pacing and difficulty curve
|
||||
|
||||
### Level Structure
|
||||
|
||||
{{level_structure}}
|
||||
|
||||
**Level organization:**
|
||||
|
||||
- Number of levels/puzzles
|
||||
- World/chapter grouping
|
||||
- Unlock progression
|
||||
- Optional/bonus content
|
||||
|
||||
### Player Assistance
|
||||
|
||||
{{player_assistance}}
|
||||
|
||||
**Help systems:**
|
||||
|
||||
- Hint system
|
||||
- Undo/reset mechanics
|
||||
- Skip puzzle options
|
||||
- Tutorial integration
|
||||
|
||||
### Replayability
|
||||
|
||||
{{replayability}}
|
||||
|
||||
**Replay elements:**
|
||||
|
||||
- Par time/move goals
|
||||
- Perfect solution challenges
|
||||
- Procedural generation (if applicable)
|
||||
- Daily/weekly puzzles
|
||||
- Challenge modes
|
||||
88
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/racing.md
Normal file
88
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/racing.md
Normal file
@@ -0,0 +1,88 @@
|
||||
## Racing Game Specific Elements
|
||||
|
||||
### Vehicle Handling and Physics
|
||||
|
||||
{{vehicle_physics}}
|
||||
|
||||
**Handling systems:**
|
||||
|
||||
- Physics model (arcade vs. simulation vs. hybrid)
|
||||
- Vehicle stats (speed, acceleration, handling, braking, weight)
|
||||
- Drift mechanics
|
||||
- Collision physics
|
||||
- Vehicle damage system (if applicable)
|
||||
|
||||
### Vehicle Roster
|
||||
|
||||
{{vehicle_roster}}
|
||||
|
||||
**Vehicle design:**
|
||||
|
||||
- Vehicle types (cars, bikes, boats, etc.)
|
||||
- Vehicle classes (lightweight, balanced, heavyweight)
|
||||
- Unlock progression
|
||||
- Customization options (visual, performance)
|
||||
- Balance considerations
|
||||
|
||||
### Track Design
|
||||
|
||||
{{track_design}}
|
||||
|
||||
**Course design:**
|
||||
|
||||
- Track variety (circuits, point-to-point, open world)
|
||||
- Track length and lap counts
|
||||
- Hazards and obstacles
|
||||
- Shortcuts and alternate paths
|
||||
- Track-specific mechanics
|
||||
- Environmental themes
|
||||
|
||||
### Race Mechanics
|
||||
|
||||
{{race_mechanics}}
|
||||
|
||||
**Core racing:**
|
||||
|
||||
- Starting mechanics (countdown, reaction time)
|
||||
- Checkpoint system
|
||||
- Lap tracking and position
|
||||
- Slipstreaming/drafting
|
||||
- Pit stops (if applicable)
|
||||
- Weather and time-of-day effects
|
||||
|
||||
### Powerups and Boost
|
||||
|
||||
{{powerups_boost}}
|
||||
|
||||
**Enhancement systems (if arcade-style):**
|
||||
|
||||
- Powerup types (offensive, defensive, utility)
|
||||
- Boost mechanics (drift boost, nitro, slipstream)
|
||||
- Item balance
|
||||
- Counterplay mechanics
|
||||
- Powerup placement on track
|
||||
|
||||
### Game Modes
|
||||
|
||||
{{game_modes}}
|
||||
|
||||
**Mode variety:**
|
||||
|
||||
- Standard race
|
||||
- Time trial
|
||||
- Elimination/knockout
|
||||
- Battle/arena modes
|
||||
- Career/campaign mode
|
||||
- Online multiplayer modes
|
||||
|
||||
### Progression and Unlocks
|
||||
|
||||
{{progression}}
|
||||
|
||||
**Player advancement:**
|
||||
|
||||
- Career structure
|
||||
- Unlockable vehicles and tracks
|
||||
- Currency/rewards system
|
||||
- Achievements and challenges
|
||||
- Skill-based unlocks vs. time-based
|
||||
79
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/rhythm.md
Normal file
79
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/rhythm.md
Normal file
@@ -0,0 +1,79 @@
|
||||
## Rhythm Game Specific Elements
|
||||
|
||||
### Music Synchronization
|
||||
|
||||
{{music_sync}}
|
||||
|
||||
**Core mechanics:**
|
||||
|
||||
- Beat/rhythm detection
|
||||
- Note types (tap, hold, slide, etc.)
|
||||
- Synchronization accuracy
|
||||
- Audio-visual feedback
|
||||
- Lane systems (4-key, 6-key, circular, etc.)
|
||||
- Offset calibration
|
||||
|
||||
### Note Charts and Patterns
|
||||
|
||||
{{note_charts}}
|
||||
|
||||
**Chart design:**
|
||||
|
||||
- Charting philosophy (fun, challenge, accuracy to song)
|
||||
- Pattern vocabulary (streams, jumps, chords, etc.)
|
||||
- Difficulty representation
|
||||
- Special patterns (gimmicks, memes)
|
||||
- Chart preview
|
||||
- Custom chart support (if applicable)
|
||||
|
||||
### Timing Windows
|
||||
|
||||
{{timing_windows}}
|
||||
|
||||
**Judgment system:**
|
||||
|
||||
- Judgment tiers (perfect, great, good, bad, miss)
|
||||
- Timing windows (frame-perfect vs. lenient)
|
||||
- Visual feedback for timing
|
||||
- Audio feedback
|
||||
- Combo system
|
||||
- Health/life system (if applicable)
|
||||
|
||||
### Scoring System
|
||||
|
||||
{{scoring}}
|
||||
|
||||
**Score design:**
|
||||
|
||||
- Base score calculation
|
||||
- Combo multipliers
|
||||
- Accuracy weighting
|
||||
- Max score calculation
|
||||
- Grade/rank system (S, A, B, C)
|
||||
- Leaderboards and competition
|
||||
|
||||
### Difficulty Tiers
|
||||
|
||||
{{difficulty_tiers}}
|
||||
|
||||
**Progression:**
|
||||
|
||||
- Difficulty levels (easy, normal, hard, expert, etc.)
|
||||
- Difficulty representation (stars, numbers)
|
||||
- Unlock conditions
|
||||
- Difficulty curve
|
||||
- Accessibility options
|
||||
- Expert+ content
|
||||
|
||||
### Song Selection
|
||||
|
||||
{{song_selection}}
|
||||
|
||||
**Music library:**
|
||||
|
||||
- Song count (launch + planned DLC)
|
||||
- Genre diversity
|
||||
- Licensing vs. original music
|
||||
- Song length targets
|
||||
- Song unlock progression
|
||||
- Favorites and playlists
|
||||
@@ -0,0 +1,69 @@
|
||||
## Roguelike Specific Elements
|
||||
|
||||
### Run Structure
|
||||
|
||||
{{run_structure}}
|
||||
|
||||
**Run design:**
|
||||
|
||||
- Run length (time, stages)
|
||||
- Starting conditions
|
||||
- Difficulty scaling per run
|
||||
- Victory conditions
|
||||
|
||||
### Procedural Generation
|
||||
|
||||
{{procedural_generation}}
|
||||
|
||||
**Generation systems:**
|
||||
|
||||
- Level generation algorithm
|
||||
- Enemy placement
|
||||
- Item/loot distribution
|
||||
- Biome/theme variation
|
||||
- Seed system (if deterministic)
|
||||
|
||||
### Permadeath and Progression
|
||||
|
||||
{{permadeath_progression}}
|
||||
|
||||
**Death mechanics:**
|
||||
|
||||
- Permadeath rules
|
||||
- What persists between runs
|
||||
- Meta-progression systems
|
||||
- Unlock conditions
|
||||
|
||||
### Item and Upgrade System
|
||||
|
||||
{{item_upgrade_system}}
|
||||
|
||||
**Item mechanics:**
|
||||
|
||||
- Item types (passive, active, consumable)
|
||||
- Rarity system
|
||||
- Item synergies
|
||||
- Build variety
|
||||
- Curse/risk mechanics
|
||||
|
||||
### Character Selection
|
||||
|
||||
{{character_selection}}
|
||||
|
||||
**Playable characters:**
|
||||
|
||||
- Starting characters
|
||||
- Unlockable characters
|
||||
- Character unique abilities
|
||||
- Character playstyle differences
|
||||
|
||||
### Difficulty Modifiers
|
||||
|
||||
{{difficulty_modifiers}}
|
||||
|
||||
**Challenge systems:**
|
||||
|
||||
- Difficulty tiers
|
||||
- Modifiers/curses
|
||||
- Challenge runs
|
||||
- Achievement conditions
|
||||
70
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/rpg.md
Normal file
70
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/rpg.md
Normal file
@@ -0,0 +1,70 @@
|
||||
## RPG Specific Elements
|
||||
|
||||
### Character System
|
||||
|
||||
{{character_system}}
|
||||
|
||||
**Character attributes:**
|
||||
|
||||
- Stats (Strength, Dexterity, Intelligence, etc.)
|
||||
- Classes/roles
|
||||
- Leveling system
|
||||
- Skill trees
|
||||
|
||||
### Inventory and Equipment
|
||||
|
||||
{{inventory_equipment}}
|
||||
|
||||
**Equipment system:**
|
||||
|
||||
- Item types (weapons, armor, accessories)
|
||||
- Rarity tiers
|
||||
- Item stats and modifiers
|
||||
- Inventory management
|
||||
|
||||
### Quest System
|
||||
|
||||
{{quest_system}}
|
||||
|
||||
**Quest structure:**
|
||||
|
||||
- Main story quests
|
||||
- Side quests
|
||||
- Quest tracking
|
||||
- Branching questlines
|
||||
- Quest rewards
|
||||
|
||||
### World and Exploration
|
||||
|
||||
{{world_exploration}}
|
||||
|
||||
**World design:**
|
||||
|
||||
- Map structure (open world, hub-based, linear)
|
||||
- Towns and safe zones
|
||||
- Dungeons and combat zones
|
||||
- Fast travel system
|
||||
- Points of interest
|
||||
|
||||
### NPC and Dialogue
|
||||
|
||||
{{npc_dialogue}}
|
||||
|
||||
**NPC interaction:**
|
||||
|
||||
- Dialogue trees
|
||||
- Relationship/reputation system
|
||||
- Companion system
|
||||
- Merchant NPCs
|
||||
|
||||
### Combat System
|
||||
|
||||
{{combat_system}}
|
||||
|
||||
**Combat mechanics:**
|
||||
|
||||
- Combat style (real-time, turn-based, tactical)
|
||||
- Ability system
|
||||
- Magic/skill system
|
||||
- Status effects
|
||||
- Party composition (if applicable)
|
||||
@@ -0,0 +1,79 @@
|
||||
## Sandbox Game Specific Elements
|
||||
|
||||
### Creation Tools
|
||||
|
||||
{{creation_tools}}
|
||||
|
||||
**Building mechanics:**
|
||||
|
||||
- Tool types (place, delete, modify, paint)
|
||||
- Object library (blocks, props, entities)
|
||||
- Precision controls (snap, free, grid)
|
||||
- Copy/paste and templates
|
||||
- Undo/redo system
|
||||
- Import/export functionality
|
||||
|
||||
### Physics and Building Systems
|
||||
|
||||
{{physics_building}}
|
||||
|
||||
**System simulation:**
|
||||
|
||||
- Physics engine (rigid body, soft body, fluids)
|
||||
- Structural integrity (if applicable)
|
||||
- Destruction mechanics
|
||||
- Material properties
|
||||
- Constraint systems (joints, hinges, motors)
|
||||
- Interactive simulations
|
||||
|
||||
### Sharing and Community
|
||||
|
||||
{{sharing_community}}
|
||||
|
||||
**Social features:**
|
||||
|
||||
- Creation sharing (workshop, gallery)
|
||||
- Discoverability (search, trending, featured)
|
||||
- Rating and feedback systems
|
||||
- Collaboration tools
|
||||
- Modding support
|
||||
- User-generated content moderation
|
||||
|
||||
### Constraints and Rules
|
||||
|
||||
{{constraints_rules}}
|
||||
|
||||
**Game design:**
|
||||
|
||||
- Creative mode (unlimited resources, no objectives)
|
||||
- Challenge mode (limited resources, objectives)
|
||||
- Budget/point systems (if competitive)
|
||||
- Build limits (size, complexity)
|
||||
- Rulesets and game modes
|
||||
- Victory conditions (if applicable)
|
||||
|
||||
### Tools and Editing
|
||||
|
||||
{{tools_editing}}
|
||||
|
||||
**Advanced features:**
|
||||
|
||||
- Logic gates/scripting (if applicable)
|
||||
- Animation tools
|
||||
- Terrain editing
|
||||
- Weather/environment controls
|
||||
- Lighting and effects
|
||||
- Testing/preview modes
|
||||
|
||||
### Emergent Gameplay
|
||||
|
||||
{{emergent_gameplay}}
|
||||
|
||||
**Player creativity:**
|
||||
|
||||
- Unintended creations (embracing exploits)
|
||||
- Community-defined challenges
|
||||
- Speedrunning player creations
|
||||
- Cross-creation interaction
|
||||
- Viral moments and showcases
|
||||
- Evolution of the meta
|
||||
@@ -0,0 +1,62 @@
|
||||
## Shooter Specific Elements
|
||||
|
||||
### Weapon Systems
|
||||
|
||||
{{weapon_systems}}
|
||||
|
||||
**Weapon design:**
|
||||
|
||||
- Weapon types (pistol, rifle, shotgun, sniper, explosive, etc.)
|
||||
- Weapon stats (damage, fire rate, accuracy, reload time, ammo capacity)
|
||||
- Weapon progression (starting weapons, unlocks, upgrades)
|
||||
- Weapon feel (recoil patterns, sound design, impact feedback)
|
||||
- Balance considerations (risk/reward, situational use)
|
||||
|
||||
### Aiming and Combat Mechanics
|
||||
|
||||
{{aiming_combat}}
|
||||
|
||||
**Combat systems:**
|
||||
|
||||
- Aiming system (first-person, third-person, twin-stick, lock-on)
|
||||
- Hit detection (hitscan vs. projectile)
|
||||
- Accuracy mechanics (spread, recoil, movement penalties)
|
||||
- Critical hits / weak points
|
||||
- Melee integration (if applicable)
|
||||
|
||||
### Enemy Design and AI
|
||||
|
||||
{{enemy_ai}}
|
||||
|
||||
**Enemy systems:**
|
||||
|
||||
- Enemy types (fodder, elite, tank, ranged, melee, boss)
|
||||
- AI behavior patterns (aggressive, defensive, flanking, cover use)
|
||||
- Spawn systems (waves, triggers, procedural)
|
||||
- Difficulty scaling (health, damage, AI sophistication)
|
||||
- Enemy tells and telegraphing
|
||||
|
||||
### Arena and Level Design
|
||||
|
||||
{{arena_level_design}}
|
||||
|
||||
**Level structure:**
|
||||
|
||||
- Arena flow (choke points, open spaces, verticality)
|
||||
- Cover system design (destructible, dynamic, static)
|
||||
- Spawn points and safe zones
|
||||
- Power-up placement
|
||||
- Environmental hazards
|
||||
- Sightlines and engagement distances
|
||||
|
||||
### Multiplayer Considerations
|
||||
|
||||
{{multiplayer}}
|
||||
|
||||
**Multiplayer systems (if applicable):**
|
||||
|
||||
- Game modes (deathmatch, team deathmatch, objective-based, etc.)
|
||||
- Map design for PvP
|
||||
- Loadout systems
|
||||
- Matchmaking and ranking
|
||||
- Balance considerations (skill ceiling, counter-play)
|
||||
@@ -0,0 +1,73 @@
|
||||
## Simulation Specific Elements
|
||||
|
||||
### Core Simulation Systems
|
||||
|
||||
{{simulation_systems}}
|
||||
|
||||
**What's being simulated:**
|
||||
|
||||
- Primary simulation focus (city, farm, business, ecosystem, etc.)
|
||||
- Simulation depth (abstract vs. realistic)
|
||||
- System interconnections
|
||||
- Emergent behaviors
|
||||
- Simulation tickrate and performance
|
||||
|
||||
### Management Mechanics
|
||||
|
||||
{{management_mechanics}}
|
||||
|
||||
**Management systems:**
|
||||
|
||||
- Resource management (budget, materials, time)
|
||||
- Decision-making mechanics
|
||||
- Automation vs. manual control
|
||||
- Delegation systems (if applicable)
|
||||
- Efficiency optimization
|
||||
|
||||
### Building and Construction
|
||||
|
||||
{{building_construction}}
|
||||
|
||||
**Construction systems:**
|
||||
|
||||
- Placeable objects/structures
|
||||
- Grid system (free placement, snap-to-grid, tiles)
|
||||
- Building prerequisites and unlocks
|
||||
- Upgrade/demolition mechanics
|
||||
- Space constraints and planning
|
||||
|
||||
### Economic and Resource Loops
|
||||
|
||||
{{economic_loops}}
|
||||
|
||||
**Economic design:**
|
||||
|
||||
- Income sources
|
||||
- Expenses and maintenance
|
||||
- Supply chains (if applicable)
|
||||
- Market dynamics
|
||||
- Economic balance and pacing
|
||||
|
||||
### Progression and Unlocks
|
||||
|
||||
{{progression_unlocks}}
|
||||
|
||||
**Progression systems:**
|
||||
|
||||
- Unlock conditions (achievements, milestones, levels)
|
||||
- Tech/research tree
|
||||
- New mechanics/features over time
|
||||
- Difficulty scaling
|
||||
- Endgame content
|
||||
|
||||
### Sandbox vs. Scenario
|
||||
|
||||
{{sandbox_scenario}}
|
||||
|
||||
**Game modes:**
|
||||
|
||||
- Sandbox mode (unlimited resources, creative freedom)
|
||||
- Scenario/campaign mode (specific goals, constraints)
|
||||
- Challenge modes
|
||||
- Random/procedural scenarios
|
||||
- Custom scenario creation
|
||||
75
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/sports.md
Normal file
75
bmad/bmm/workflows/2-plan-workflows/gdd/game-types/sports.md
Normal file
@@ -0,0 +1,75 @@
|
||||
## Sports Game Specific Elements
|
||||
|
||||
### Sport-Specific Rules
|
||||
|
||||
{{sport_rules}}
|
||||
|
||||
**Rule implementation:**
|
||||
|
||||
- Core sport rules (scoring, fouls, violations)
|
||||
- Match/game structure (quarters, periods, innings, etc.)
|
||||
- Referee/umpire system
|
||||
- Rule variations (if applicable)
|
||||
- Simulation vs. arcade rule adherence
|
||||
|
||||
### Team and Player Systems
|
||||
|
||||
{{team_player}}
|
||||
|
||||
**Roster design:**
|
||||
|
||||
- Player attributes (speed, strength, skill, etc.)
|
||||
- Position-specific stats
|
||||
- Team composition
|
||||
- Substitution mechanics
|
||||
- Stamina/fatigue system
|
||||
- Injury system (if applicable)
|
||||
|
||||
### Match Structure
|
||||
|
||||
{{match_structure}}
|
||||
|
||||
**Game flow:**
|
||||
|
||||
- Pre-match setup (lineups, strategies)
|
||||
- In-match actions (plays, tactics, timeouts)
|
||||
- Half-time/intermission
|
||||
- Overtime/extra time rules
|
||||
- Post-match results and stats
|
||||
|
||||
### Physics and Realism
|
||||
|
||||
{{physics_realism}}
|
||||
|
||||
**Simulation balance:**
|
||||
|
||||
- Physics accuracy (ball/puck physics, player movement)
|
||||
- Realism vs. fun tradeoffs
|
||||
- Animation systems
|
||||
- Collision detection
|
||||
- Weather/field condition effects
|
||||
|
||||
### Career and Season Modes
|
||||
|
||||
{{career_season}}
|
||||
|
||||
**Long-term modes:**
|
||||
|
||||
- Career mode structure
|
||||
- Season/tournament progression
|
||||
- Transfer/draft systems
|
||||
- Team management
|
||||
- Contract negotiations
|
||||
- Sponsor/financial systems
|
||||
|
||||
### Multiplayer Modes
|
||||
|
||||
{{multiplayer}}
|
||||
|
||||
**Competitive play:**
|
||||
|
||||
- Local multiplayer (couch co-op)
|
||||
- Online multiplayer
|
||||
- Ranked/casual modes
|
||||
- Ultimate team/card collection (if applicable)
|
||||
- Co-op vs. AI
|
||||
@@ -0,0 +1,71 @@
|
||||
## Strategy Specific Elements
|
||||
|
||||
### Resource Systems
|
||||
|
||||
{{resource_systems}}
|
||||
|
||||
**Resource management:**
|
||||
|
||||
- Resource types (gold, food, energy, population, etc.)
|
||||
- Gathering mechanics (auto-generate, harvesting, capturing)
|
||||
- Resource spending (units, buildings, research, upgrades)
|
||||
- Economic balance (income vs. expenses)
|
||||
- Scarcity and strategic choices
|
||||
|
||||
### Unit Types and Stats
|
||||
|
||||
{{unit_types}}
|
||||
|
||||
**Unit design:**
|
||||
|
||||
- Unit roster (basic, advanced, specialized, hero units)
|
||||
- Unit stats (health, attack, defense, speed, range)
|
||||
- Unit abilities (active, passive, unique)
|
||||
- Counter systems (rock-paper-scissors dynamics)
|
||||
- Unit production (cost, build time, prerequisites)
|
||||
|
||||
### Technology and Progression
|
||||
|
||||
{{tech_progression}}
|
||||
|
||||
**Progression systems:**
|
||||
|
||||
- Tech tree structure (linear, branching, era-based)
|
||||
- Research mechanics (time, cost, prerequisites)
|
||||
- Upgrade paths (unit upgrades, building improvements)
|
||||
- Unlock conditions (progression gates, achievements)
|
||||
|
||||
### Map and Terrain
|
||||
|
||||
{{map_terrain}}
|
||||
|
||||
**Strategic space:**
|
||||
|
||||
- Map size and structure (small/medium/large, symmetric/asymmetric)
|
||||
- Terrain types (passable, impassable, elevated, water)
|
||||
- Terrain effects (movement, combat bonuses, vision)
|
||||
- Strategic points (resources, objectives, choke points)
|
||||
- Fog of war / vision system
|
||||
|
||||
### AI Opponent
|
||||
|
||||
{{ai_opponent}}
|
||||
|
||||
**AI design:**
|
||||
|
||||
- AI difficulty levels (easy, medium, hard, expert)
|
||||
- AI behavior patterns (aggressive, defensive, economic, adaptive)
|
||||
- AI cheating considerations (fair vs. challenge-focused)
|
||||
- AI personality types (if multiple opponents)
|
||||
|
||||
### Victory Conditions
|
||||
|
||||
{{victory_conditions}}
|
||||
|
||||
**Win/loss design:**
|
||||
|
||||
- Victory types (domination, economic, technological, diplomatic, etc.)
|
||||
- Time limits (if applicable)
|
||||
- Score systems (if applicable)
|
||||
- Defeat conditions
|
||||
- Early surrender / concession mechanics
|
||||
@@ -0,0 +1,79 @@
|
||||
## Survival Game Specific Elements
|
||||
|
||||
### Resource Gathering and Crafting
|
||||
|
||||
{{resource_crafting}}
|
||||
|
||||
**Resource systems:**
|
||||
|
||||
- Resource types (wood, stone, food, water, etc.)
|
||||
- Gathering methods (mining, foraging, hunting, looting)
|
||||
- Crafting recipes and trees
|
||||
- Tool/weapon crafting
|
||||
- Durability and repair
|
||||
- Storage and inventory management
|
||||
|
||||
### Survival Needs
|
||||
|
||||
{{survival_needs}}
|
||||
|
||||
**Player vitals:**
|
||||
|
||||
- Hunger/thirst systems
|
||||
- Health and healing
|
||||
- Temperature/exposure
|
||||
- Sleep/rest (if applicable)
|
||||
- Sanity/morale (if applicable)
|
||||
- Status effects (poison, disease, etc.)
|
||||
|
||||
### Environmental Threats
|
||||
|
||||
{{environmental_threats}}
|
||||
|
||||
**Danger systems:**
|
||||
|
||||
- Wildlife (predators, hostile creatures)
|
||||
- Environmental hazards (weather, terrain)
|
||||
- Day/night cycle threats
|
||||
- Seasonal changes (if applicable)
|
||||
- Natural disasters
|
||||
- Dynamic threat scaling
|
||||
|
||||
### Base Building
|
||||
|
||||
{{base_building}}
|
||||
|
||||
**Construction systems:**
|
||||
|
||||
- Building materials and recipes
|
||||
- Structure types (shelter, storage, defenses)
|
||||
- Base location and planning
|
||||
- Upgrade paths
|
||||
- Defensive structures
|
||||
- Automation (if applicable)
|
||||
|
||||
### Progression and Technology
|
||||
|
||||
{{progression_tech}}
|
||||
|
||||
**Advancement:**
|
||||
|
||||
- Tech tree or skill progression
|
||||
- Tool/weapon tiers
|
||||
- Unlock conditions
|
||||
- New biomes/areas access
|
||||
- Endgame objectives (if applicable)
|
||||
- Prestige/restart mechanics (if applicable)
|
||||
|
||||
### World Structure
|
||||
|
||||
{{world_structure}}
|
||||
|
||||
**Map design:**
|
||||
|
||||
- World size and boundaries
|
||||
- Biome diversity
|
||||
- Procedural vs. handcrafted
|
||||
- Points of interest
|
||||
- Risk/reward zones
|
||||
- Fast travel or navigation systems
|
||||
@@ -0,0 +1,91 @@
|
||||
## Text-Based Game Specific Elements
|
||||
|
||||
<narrative-workflow-critical>
|
||||
This game type is **narrative-critical**. You MUST run the Narrative Design workflow after completing the GDD to create:
|
||||
- Complete story and all narrative paths
|
||||
- Room descriptions and atmosphere
|
||||
- Puzzle solutions and hints
|
||||
- Character dialogue
|
||||
- World lore and backstory
|
||||
- Parser vocabulary (if parser-based)
|
||||
</narrative-workflow-critical>
|
||||
|
||||
### Input System
|
||||
|
||||
{{input_system}}
|
||||
|
||||
**Core interface:**
|
||||
|
||||
- Parser-based (natural language commands)
|
||||
- Choice-based (numbered/lettered options)
|
||||
- Hybrid system
|
||||
- Command vocabulary depth
|
||||
- Synonyms and flexibility
|
||||
- Error messaging and hints
|
||||
|
||||
### Room/Location Structure
|
||||
|
||||
{{location_structure}}
|
||||
|
||||
**World design:**
|
||||
|
||||
- Room count and scope
|
||||
- Room descriptions (length, detail)
|
||||
- Connection types (doors, paths, obstacles)
|
||||
- Map structure (linear, branching, maze-like, open)
|
||||
- Landmarks and navigation aids
|
||||
- Fast travel or mapping system
|
||||
|
||||
### Item and Inventory System
|
||||
|
||||
{{item_inventory}}
|
||||
|
||||
**Object interaction:**
|
||||
|
||||
- Examinable objects
|
||||
- Takeable vs. scenery objects
|
||||
- Item use and combinations
|
||||
- Inventory management
|
||||
- Object descriptions
|
||||
- Hidden objects and clues
|
||||
|
||||
### Puzzle Design
|
||||
|
||||
{{puzzle_design}}
|
||||
|
||||
**Challenge structure:**
|
||||
|
||||
- Puzzle types (logic, inventory, knowledge, exploration)
|
||||
- Difficulty curve
|
||||
- Hint system (gradual reveals)
|
||||
- Red herrings vs. crucial clues
|
||||
- Puzzle integration with story
|
||||
- Non-linear puzzle solving
|
||||
|
||||
### Narrative and Writing
|
||||
|
||||
{{narrative_writing}}
|
||||
|
||||
**Story delivery:**
|
||||
|
||||
- Writing tone and style
|
||||
- Descriptive density
|
||||
- Character voice
|
||||
- Dialogue systems
|
||||
- Branching narrative (if applicable)
|
||||
- Multiple endings (if applicable)
|
||||
|
||||
**Note:** All narrative content must be written in the Narrative Design Document.
|
||||
|
||||
### Game Flow and Pacing
|
||||
|
||||
{{game_flow}}
|
||||
|
||||
**Structure:**
|
||||
|
||||
- Game length target
|
||||
- Acts or chapters
|
||||
- Save system
|
||||
- Undo/rewind mechanics
|
||||
- Walkthrough or hint accessibility
|
||||
- Replayability considerations
|
||||
@@ -0,0 +1,79 @@
|
||||
## Tower Defense Specific Elements
|
||||
|
||||
### Tower Types and Upgrades
|
||||
|
||||
{{tower_types}}
|
||||
|
||||
**Tower design:**
|
||||
|
||||
- Tower categories (damage, slow, splash, support, special)
|
||||
- Tower stats (damage, range, fire rate, cost)
|
||||
- Upgrade paths (linear, branching)
|
||||
- Tower synergies
|
||||
- Tier progression
|
||||
- Special abilities and targeting
|
||||
|
||||
### Enemy Wave Design
|
||||
|
||||
{{wave_design}}
|
||||
|
||||
**Enemy systems:**
|
||||
|
||||
- Enemy types (fast, tank, flying, immune, boss)
|
||||
- Wave composition
|
||||
- Wave difficulty scaling
|
||||
- Wave scheduling and pacing
|
||||
- Boss encounters
|
||||
- Endless mode scaling (if applicable)
|
||||
|
||||
### Path and Placement Strategy
|
||||
|
||||
{{path_placement}}
|
||||
|
||||
**Strategic space:**
|
||||
|
||||
- Path structure (fixed, custom, maze-building)
|
||||
- Placement restrictions (grid, free placement)
|
||||
- Terrain types (buildable, non-buildable, special)
|
||||
- Choke points and strategic locations
|
||||
- Multiple paths (if applicable)
|
||||
- Line of sight and range visualization
|
||||
|
||||
### Economy and Resources
|
||||
|
||||
{{economy}}
|
||||
|
||||
**Resource management:**
|
||||
|
||||
- Starting resources
|
||||
- Resource generation (per wave, per kill, passive)
|
||||
- Resource spending (towers, upgrades, abilities)
|
||||
- Selling/refund mechanics
|
||||
- Special currencies (if applicable)
|
||||
- Economic optimization strategies
|
||||
|
||||
### Abilities and Powers
|
||||
|
||||
{{abilities_powers}}
|
||||
|
||||
**Active mechanics:**
|
||||
|
||||
- Player-activated abilities (airstrikes, freezes, etc.)
|
||||
- Cooldown systems
|
||||
- Ability unlocks
|
||||
- Ability upgrade paths
|
||||
- Strategic timing
|
||||
- Resource cost vs. cooldown
|
||||
|
||||
### Difficulty and Replayability
|
||||
|
||||
{{difficulty_replay}}
|
||||
|
||||
**Challenge systems:**
|
||||
|
||||
- Difficulty levels
|
||||
- Mission objectives (perfect clear, no lives lost, etc.)
|
||||
- Star ratings
|
||||
- Challenge modifiers
|
||||
- Randomized elements
|
||||
- New Game+ or prestige modes
|
||||
@@ -0,0 +1,88 @@
|
||||
## Turn-Based Tactics Specific Elements
|
||||
|
||||
<narrative-workflow-recommended>
|
||||
This game type is **narrative-moderate to heavy**. Consider running the Narrative Design workflow after completing the GDD to create:
|
||||
- Campaign story and mission briefings
|
||||
- Character backstories and development
|
||||
- Faction lore and motivations
|
||||
- Mission narratives
|
||||
</narrative-workflow-recommended>
|
||||
|
||||
### Grid System and Movement
|
||||
|
||||
{{grid_movement}}
|
||||
|
||||
**Spatial design:**
|
||||
|
||||
- Grid type (square, hex, free-form)
|
||||
- Movement range calculation
|
||||
- Movement types (walk, fly, teleport)
|
||||
- Terrain movement costs
|
||||
- Zone of control
|
||||
- Pathfinding visualization
|
||||
|
||||
### Unit Types and Classes
|
||||
|
||||
{{unit_classes}}
|
||||
|
||||
**Unit design:**
|
||||
|
||||
- Class roster (warrior, archer, mage, healer, etc.)
|
||||
- Class abilities and specializations
|
||||
- Unit progression (leveling, promotions)
|
||||
- Unit customization
|
||||
- Unique units (heroes, named characters)
|
||||
- Class balance and counters
|
||||
|
||||
### Action Economy
|
||||
|
||||
{{action_economy}}
|
||||
|
||||
**Turn structure:**
|
||||
|
||||
- Action points system (fixed, variable, pooled)
|
||||
- Action types (move, attack, ability, item, wait)
|
||||
- Free actions vs. costing actions
|
||||
- Opportunity attacks
|
||||
- Turn order (initiative, simultaneous, alternating)
|
||||
- Time limits per turn (if applicable)
|
||||
|
||||
### Positioning and Tactics
|
||||
|
||||
{{positioning_tactics}}
|
||||
|
||||
**Strategic depth:**
|
||||
|
||||
- Flanking mechanics
|
||||
- High ground advantage
|
||||
- Cover system
|
||||
- Formation bonuses
|
||||
- Area denial
|
||||
- Chokepoint tactics
|
||||
- Line of sight and vision
|
||||
|
||||
### Terrain and Environmental Effects
|
||||
|
||||
{{terrain_effects}}
|
||||
|
||||
**Map design:**
|
||||
|
||||
- Terrain types (grass, water, lava, ice, etc.)
|
||||
- Terrain effects (defense bonus, movement penalty, damage)
|
||||
- Destructible terrain
|
||||
- Interactive objects
|
||||
- Weather effects
|
||||
- Elevation and verticality
|
||||
|
||||
### Campaign Structure
|
||||
|
||||
{{campaign}}
|
||||
|
||||
**Mission design:**
|
||||
|
||||
- Campaign length and pacing
|
||||
- Mission variety (defeat all, survive, escort, capture, etc.)
|
||||
- Optional objectives
|
||||
- Branching campaigns
|
||||
- Permadeath vs. casualty systems
|
||||
- Resource management between missions
|
||||
@@ -0,0 +1,89 @@
|
||||
## Visual Novel Specific Elements
|
||||
|
||||
<narrative-workflow-critical>
|
||||
This game type is **narrative-critical**. You MUST run the Narrative Design workflow after completing the GDD to create:
|
||||
- Complete story structure and script
|
||||
- All character profiles and development arcs
|
||||
- Branching story flowcharts
|
||||
- Scene-by-scene breakdown
|
||||
- Dialogue drafts
|
||||
- Multiple route planning
|
||||
</narrative-workflow-critical>
|
||||
|
||||
### Branching Story Structure
|
||||
|
||||
{{branching_structure}}
|
||||
|
||||
**Narrative design:**
|
||||
|
||||
- Story route types (character routes, plot branches)
|
||||
- Branch points (choices, stats, flags)
|
||||
- Convergence points
|
||||
- Route length and pacing
|
||||
- True/golden ending requirements
|
||||
- Branch complexity (simple, moderate, complex)
|
||||
|
||||
### Choice Impact System
|
||||
|
||||
{{choice_impact}}
|
||||
|
||||
**Decision mechanics:**
|
||||
|
||||
- Choice types (immediate, delayed, hidden)
|
||||
- Choice visualization (explicit, subtle, invisible)
|
||||
- Point systems (affection, alignment, stats)
|
||||
- Flag tracking
|
||||
- Choice consequences
|
||||
- Meaningful vs. cosmetic choices
|
||||
|
||||
### Route Design
|
||||
|
||||
{{route_design}}
|
||||
|
||||
**Route structure:**
|
||||
|
||||
- Common route (shared beginning)
|
||||
- Individual routes (character-specific paths)
|
||||
- Route unlock conditions
|
||||
- Route length balance
|
||||
- Route independence vs. interconnection
|
||||
- Recommended play order
|
||||
|
||||
### Character Relationship Systems
|
||||
|
||||
{{relationship_systems}}
|
||||
|
||||
**Character mechanics:**
|
||||
|
||||
- Affection/friendship points
|
||||
- Relationship milestones
|
||||
- Character-specific scenes
|
||||
- Dialogue variations based on relationship
|
||||
- Multiple romance options (if applicable)
|
||||
- Platonic vs. romantic paths
|
||||
|
||||
### Save/Load and Flowchart
|
||||
|
||||
{{save_flowchart}}
|
||||
|
||||
**Player navigation:**
|
||||
|
||||
- Save point frequency
|
||||
- Quick save/load
|
||||
- Scene skip functionality
|
||||
- Flowchart/scene select (after completion)
|
||||
- Branch tracking visualization
|
||||
- Completion percentage
|
||||
|
||||
### Art Asset Requirements
|
||||
|
||||
{{art_assets}}
|
||||
|
||||
**Visual content:**
|
||||
|
||||
- Character sprites (poses, expressions)
|
||||
- Background art (locations, times of day)
|
||||
- CG artwork (key moments, endings)
|
||||
- UI elements
|
||||
- Special effects
|
||||
- Asset quantity estimates
|
||||
153
bmad/bmm/workflows/2-plan-workflows/gdd/gdd-template.md
Normal file
153
bmad/bmm/workflows/2-plan-workflows/gdd/gdd-template.md
Normal file
@@ -0,0 +1,153 @@
|
||||
# {{game_name}} - Game Design Document
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Game Type:** {{game_type}}
|
||||
**Target Platform(s):** {{platforms}}
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
### Core Concept
|
||||
|
||||
{{description}}
|
||||
|
||||
### Target Audience
|
||||
|
||||
{{target_audience}}
|
||||
|
||||
### Unique Selling Points (USPs)
|
||||
|
||||
{{unique_selling_points}}
|
||||
|
||||
---
|
||||
|
||||
## Goals and Context
|
||||
|
||||
### Project Goals
|
||||
|
||||
{{goals}}
|
||||
|
||||
### Background and Rationale
|
||||
|
||||
{{context}}
|
||||
|
||||
---
|
||||
|
||||
## Core Gameplay
|
||||
|
||||
### Game Pillars
|
||||
|
||||
{{game_pillars}}
|
||||
|
||||
### Core Gameplay Loop
|
||||
|
||||
{{gameplay_loop}}
|
||||
|
||||
### Win/Loss Conditions
|
||||
|
||||
{{win_loss_conditions}}
|
||||
|
||||
---
|
||||
|
||||
## Game Mechanics
|
||||
|
||||
### Primary Mechanics
|
||||
|
||||
{{primary_mechanics}}
|
||||
|
||||
### Controls and Input
|
||||
|
||||
{{controls}}
|
||||
|
||||
---
|
||||
|
||||
{{GAME_TYPE_SPECIFIC_SECTIONS}}
|
||||
|
||||
---
|
||||
|
||||
## Progression and Balance
|
||||
|
||||
### Player Progression
|
||||
|
||||
{{player_progression}}
|
||||
|
||||
### Difficulty Curve
|
||||
|
||||
{{difficulty_curve}}
|
||||
|
||||
### Economy and Resources
|
||||
|
||||
{{economy_resources}}
|
||||
|
||||
---
|
||||
|
||||
## Level Design Framework
|
||||
|
||||
### Level Types
|
||||
|
||||
{{level_types}}
|
||||
|
||||
### Level Progression
|
||||
|
||||
{{level_progression}}
|
||||
|
||||
---
|
||||
|
||||
## Art and Audio Direction
|
||||
|
||||
### Art Style
|
||||
|
||||
{{art_style}}
|
||||
|
||||
### Audio and Music
|
||||
|
||||
{{audio_music}}
|
||||
|
||||
---
|
||||
|
||||
## Technical Specifications
|
||||
|
||||
### Performance Requirements
|
||||
|
||||
{{performance_requirements}}
|
||||
|
||||
### Platform-Specific Details
|
||||
|
||||
{{platform_details}}
|
||||
|
||||
### Asset Requirements
|
||||
|
||||
{{asset_requirements}}
|
||||
|
||||
---
|
||||
|
||||
## Development Epics
|
||||
|
||||
### Epic Structure
|
||||
|
||||
{{epics}}
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Technical Metrics
|
||||
|
||||
{{technical_metrics}}
|
||||
|
||||
### Gameplay Metrics
|
||||
|
||||
{{gameplay_metrics}}
|
||||
|
||||
---
|
||||
|
||||
## Out of Scope
|
||||
|
||||
{{out_of_scope}}
|
||||
|
||||
---
|
||||
|
||||
## Assumptions and Dependencies
|
||||
|
||||
{{assumptions_and_dependencies}}
|
||||
488
bmad/bmm/workflows/2-plan-workflows/gdd/instructions-gdd.md
Normal file
488
bmad/bmm/workflows/2-plan-workflows/gdd/instructions-gdd.md
Normal file
@@ -0,0 +1,488 @@
|
||||
# GDD Workflow - Game Projects (All Levels)
|
||||
|
||||
<workflow>
|
||||
|
||||
<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>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>This is the GDD instruction set for GAME projects - replaces PRD with Game Design Document</critical>
|
||||
<critical>Project analysis already completed - proceeding with game-specific design</critical>
|
||||
<critical>Uses gdd_template for GDD output, game_types.csv for type-specific sections</critical>
|
||||
<critical>Routes to 3-solutioning for architecture (platform-specific decisions handled there)</critical>
|
||||
<critical>If users mention technical details, append to technical_preferences with timestamp</critical>
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Concise, clear, actionable game design specs. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
|
||||
|
||||
<step n="0" goal="Validate workflow and extract project configuration">
|
||||
|
||||
<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
|
||||
<param>mode: data</param>
|
||||
<param>data_request: project_config</param>
|
||||
</invoke-workflow>
|
||||
|
||||
<check if="status_exists == false">
|
||||
<output>**Note: No Workflow Status File Found**
|
||||
|
||||
The GDD workflow can run standalone or as part of the BMM workflow path.
|
||||
|
||||
**Recommended:** Run `workflow-init` first for:
|
||||
|
||||
- Project context tracking
|
||||
- Workflow sequencing guidance
|
||||
- Progress monitoring across workflows
|
||||
|
||||
**Or continue standalone** without progress tracking.
|
||||
</output>
|
||||
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
||||
<check if="continue">
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
<check if="exit">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="status_exists == true">
|
||||
<action>Store {{status_file_path}} for later updates</action>
|
||||
|
||||
<check if="project_type != 'game'">
|
||||
<output>**Incorrect Workflow for Software Projects**
|
||||
|
||||
Your project is type: {{project_type}}
|
||||
|
||||
**Correct workflows for software projects:**
|
||||
|
||||
- Level 0-1: `tech-spec` (Architect agent)
|
||||
- Level 2-4: `prd` (PM agent)
|
||||
|
||||
{{#if project_level <= 1}}
|
||||
Use: `tech-spec`
|
||||
{{else}}
|
||||
Use: `prd`
|
||||
{{/if}}
|
||||
</output>
|
||||
<action>Exit and redirect to appropriate workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="0.5" goal="Validate workflow sequencing" tag="workflow-status">
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Check status of "gdd" workflow in loaded status file</action>
|
||||
|
||||
<check if="gdd status is file path (already completed)">
|
||||
<output>⚠️ GDD already completed: {{gdd status}}</output>
|
||||
<ask>Re-running will overwrite the existing GDD. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="gdd is not the next expected workflow (latter items are completed already in the list)">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. GDD is out of sequence.</output>
|
||||
<ask>Continue with GDD anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Load context and determine game type">
|
||||
|
||||
<action>Use {{project_type}} and {{project_level}} from status data</action>
|
||||
|
||||
<check if="continuation_mode == true">
|
||||
<action>Load existing GDD.md and check completion status</action>
|
||||
<ask>Found existing work. Would you like to:
|
||||
1. Review what's done and continue
|
||||
2. Modify existing sections
|
||||
3. Start fresh
|
||||
</ask>
|
||||
<action>If continuing, skip to first incomplete section</action>
|
||||
</check>
|
||||
|
||||
<action if="new or starting fresh">Check or existing game-brief in output_folder</action>
|
||||
|
||||
<check if="game-brief exists">
|
||||
<ask>Found existing game brief! Would you like to:
|
||||
|
||||
1. Use it as input (recommended - I'll extract key info)
|
||||
2. Ignore it and start fresh
|
||||
</ask>
|
||||
</check>
|
||||
|
||||
<check if="using game-brief">
|
||||
<action>Load and analyze game-brief document</action>
|
||||
<action>Extract: game_name, core_concept, target_audience, platforms, game_pillars, primary_mechanics</action>
|
||||
<action>Pre-fill relevant GDD sections with game-brief content</action>
|
||||
<action>Note which sections were pre-filled from brief</action>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="no game-brief was loaded">
|
||||
<ask>Describe your game. What is it about? What does the player do? What is the Genre or type?</ask>
|
||||
|
||||
<action>Analyze description to determine game type</action>
|
||||
<action>Map to closest game_types.csv id or use "custom"</action>
|
||||
</check>
|
||||
|
||||
<check if="else (game-brief was loaded)">
|
||||
<action>Use game concept from brief to determine game type</action>
|
||||
|
||||
<ask optional="true">
|
||||
I've identified this as a **{{game_type}}** game. Is that correct?
|
||||
If not, briefly describe what type it should be:
|
||||
</ask>
|
||||
|
||||
<action>Map selection to game_types.csv id</action>
|
||||
<action>Load corresponding fragment file from game-types/ folder</action>
|
||||
<action>Store game_type for later injection</action>
|
||||
|
||||
<action>Load gdd_template from workflow.yaml</action>
|
||||
|
||||
Get core game concept and vision.
|
||||
|
||||
<template-output>description</template-output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Define platforms and target audience">
|
||||
|
||||
<action>Guide user to specify target platform(s) for their game, exploring considerations like desktop, mobile, web, console, or multi-platform deployment</action>
|
||||
|
||||
<template-output>platforms</template-output>
|
||||
|
||||
<action>Guide user to define their target audience with specific demographics: age range, gaming experience level (casual/core/hardcore), genre familiarity, and preferred play session lengths</action>
|
||||
|
||||
<template-output>target_audience</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Define goals, context, and unique selling points">
|
||||
|
||||
<action>Guide user to define project goals appropriate for their level (Level 0-1: 1-2 goals, Level 2: 2-3 goals, Level 3-4: 3-5 strategic goals) - what success looks like for this game</action>
|
||||
|
||||
<template-output>goals</template-output>
|
||||
|
||||
<action>Guide user to provide context on why this game matters now - the motivation and rationale behind the project</action>
|
||||
|
||||
<template-output>context</template-output>
|
||||
|
||||
<action>Guide user to identify the unique selling points (USPs) - what makes this game different from existing games in the market</action>
|
||||
|
||||
<template-output>unique_selling_points</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Core gameplay definition">
|
||||
|
||||
<critical>These are game-defining decisions</critical>
|
||||
|
||||
<action>Guide user to identify 2-4 core game pillars - the fundamental gameplay elements that define their game's experience (e.g., tight controls + challenging combat + rewarding exploration, or strategic depth + replayability + quick sessions)</action>
|
||||
|
||||
<template-output>game_pillars</template-output>
|
||||
|
||||
<action>Guide user to describe the core gameplay loop - what actions the player repeats throughout the game, creating a clear cyclical pattern of player behavior and rewards</action>
|
||||
|
||||
<template-output>gameplay_loop</template-output>
|
||||
|
||||
<action>Guide user to define win and loss conditions - how the player succeeds and fails in the game</action>
|
||||
|
||||
<template-output>win_loss_conditions</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Game mechanics and controls">
|
||||
|
||||
<action>Guide user to define the primary game mechanics that players will interact with throughout the game</action>
|
||||
|
||||
<template-output>primary_mechanics</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<action>Guide user to describe their control scheme and input method (keyboard/mouse, gamepad, touchscreen, etc.), including key bindings or button layouts if known</action>
|
||||
|
||||
<template-output>controls</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Inject game-type-specific sections">
|
||||
|
||||
<action>Load game-type fragment from: {installed_path}/gdd/game-types/{{game_type}}.md</action>
|
||||
|
||||
<critical>Process each section in the fragment template</critical>
|
||||
|
||||
For each {{placeholder}} in the fragment, elicit and capture that information.
|
||||
|
||||
<template-output file="GDD.md">GAME_TYPE_SPECIFIC_SECTIONS</template-output>
|
||||
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Progression and balance">
|
||||
|
||||
<action>Guide user to describe how player progression works in their game - whether through skill improvement, power gains, ability unlocking, narrative advancement, or a combination of approaches</action>
|
||||
|
||||
<template-output>player_progression</template-output>
|
||||
|
||||
<action>Guide user to define the difficulty curve: how challenge increases over time, pacing rhythm (steady/spikes/player-controlled), and any accessibility options planned</action>
|
||||
|
||||
<template-output>difficulty_curve</template-output>
|
||||
|
||||
<action>Ask if the game includes an in-game economy or resource system, and if so, guide user to describe it (skip if not applicable)</action>
|
||||
|
||||
<template-output>economy_resources</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Level design framework">
|
||||
|
||||
<action>Guide user to describe the types of levels/stages in their game (e.g., tutorial, themed biomes, boss arenas, procedural vs. handcrafted, etc.)</action>
|
||||
|
||||
<template-output>level_types</template-output>
|
||||
|
||||
<action>Guide user to explain how levels progress or unlock - whether through linear sequence, hub-based structure, open world exploration, or player-driven choices</action>
|
||||
|
||||
<template-output>level_progression</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Art and audio direction">
|
||||
|
||||
<action>Guide user to describe their art style vision: visual aesthetic (pixel art, low-poly, realistic, stylized), color palette preferences, and any inspirations or references</action>
|
||||
|
||||
<template-output>art_style</template-output>
|
||||
|
||||
<action>Guide user to describe their audio and music direction: music style/genre, sound effect tone, and how important audio is to the gameplay experience</action>
|
||||
|
||||
<template-output>audio_music</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Technical specifications">
|
||||
|
||||
<action>Guide user to define performance requirements: target frame rate, resolution, acceptable load times, and mobile battery considerations if applicable</action>
|
||||
|
||||
<template-output>performance_requirements</template-output>
|
||||
|
||||
<action>Guide user to identify platform-specific considerations (mobile touch controls/screen sizes, PC keyboard/mouse/settings, console controller/certification, web browser compatibility/file size)</action>
|
||||
|
||||
<template-output>platform_details</template-output>
|
||||
|
||||
<action>Guide user to document key asset requirements: art assets (sprites/models/animations), audio assets (music/SFX/voice), estimated counts/sizes, and asset pipeline needs</action>
|
||||
|
||||
<template-output>asset_requirements</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Epic structure">
|
||||
|
||||
<action>Work with user to translate game features into development epics, following level-appropriate guidelines (Level 1: 1 epic/1-10 stories, Level 2: 1-2 epics/5-15 stories, Level 3: 2-5 epics/12-40 stories, Level 4: 5+ epics/40+ stories)</action>
|
||||
|
||||
<template-output>epics</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Generate detailed epic breakdown in epics.md">
|
||||
|
||||
<action>Load epics_template from workflow.yaml</action>
|
||||
|
||||
<critical>Create separate epics.md with full story hierarchy</critical>
|
||||
|
||||
<action>Generate epic overview section with all epics listed</action>
|
||||
|
||||
<template-output file="epics.md">epic_overview</template-output>
|
||||
|
||||
<action>For each epic, generate detailed breakdown with expanded goals, capabilities, and success criteria</action>
|
||||
|
||||
<action>For each epic, generate all stories in user story format with prerequisites, acceptance criteria (3-8 per story), and high-level technical notes</action>
|
||||
|
||||
<for-each epic="epic_list">
|
||||
|
||||
<template-output file="epics.md">epic\_{{epic_number}}\_details</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</for-each>
|
||||
|
||||
</step>
|
||||
<step n="13" goal="Success metrics">
|
||||
|
||||
<action>Guide user to identify technical metrics they'll track (e.g., frame rate consistency, load times, crash rate, memory usage)</action>
|
||||
|
||||
<template-output>technical_metrics</template-output>
|
||||
|
||||
<action>Guide user to identify gameplay metrics they'll track (e.g., player completion rate, session length, difficulty pain points, feature engagement)</action>
|
||||
|
||||
<template-output>gameplay_metrics</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="14" goal="Document out of scope and assumptions">
|
||||
|
||||
<action>Guide user to document what is explicitly out of scope for this game - features, platforms, or content that won't be included in this version</action>
|
||||
|
||||
<template-output>out_of_scope</template-output>
|
||||
|
||||
<action>Guide user to document key assumptions and dependencies - technical assumptions, team capabilities, third-party dependencies, or external factors the project relies on</action>
|
||||
|
||||
<template-output>assumptions_and_dependencies</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="15" goal="Update status and populate story sequence" tag="workflow-status">
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "gdd"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["gdd"] = "{output_folder}/bmm-gdd-{{game_name}}-{{date}}.md"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Parse {epics_output_file} to extract all stories</action>
|
||||
<action>Populate story_sequence section in status file with story IDs</action>
|
||||
<action>Set each story status to "not-started"</action>
|
||||
<output>Loaded {{total_stories}} stories from epics into story sequence.</output>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
<output>Next workflow: {{next_workflow}} ({{next_agent}} agent)</output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="16" goal="Generate solutioning handoff and next steps">
|
||||
|
||||
<action>Check if game-type fragment contained narrative tags indicating narrative importance</action>
|
||||
|
||||
<check if="fragment had <narrative-workflow-critical> or <narrative-workflow-recommended>">
|
||||
<action>Set needs_narrative = true</action>
|
||||
<action>Extract narrative importance level from tag</action>
|
||||
|
||||
## Next Steps for {{game_name}}
|
||||
|
||||
</check>
|
||||
|
||||
<check if="needs_narrative == true">
|
||||
<action>Inform user that their game type benefits from narrative design, presenting the option to create a Narrative Design Document covering story structure, character arcs, world lore, dialogue framework, and environmental storytelling</action>
|
||||
|
||||
<ask>This game type ({{game_type}}) benefits from narrative design.
|
||||
|
||||
Would you like to create a Narrative Design Document now?
|
||||
|
||||
1. Yes, create Narrative Design Document (recommended)
|
||||
2. No, proceed directly to solutioning
|
||||
3. Skip for now, I'll do it later
|
||||
|
||||
Your choice:</ask>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="user selects option 1 or fuzzy indicates wanting to create the narrative design document">
|
||||
<invoke-workflow>{project-root}/bmad/bmm/workflows/2-plan-workflows/narrative/workflow.yaml</invoke-workflow>
|
||||
<action>Pass GDD context to narrative workflow</action>
|
||||
<action>Exit current workflow (narrative will hand off to solutioning when done)</action>
|
||||
|
||||
Since this is a Level {{project_level}} game project, you need solutioning for platform/engine architecture.
|
||||
|
||||
**Start new chat with solutioning workflow and provide:**
|
||||
|
||||
1. This GDD: `{{gdd_output_file}}`
|
||||
2. Project analysis: `{{analysis_file}}`
|
||||
|
||||
**The solutioning workflow will:**
|
||||
|
||||
- Determine game engine/platform (Unity, Godot, Phaser, custom, etc.)
|
||||
- Generate architecture.md with engine-specific decisions
|
||||
- Create per-epic tech specs
|
||||
- Handle platform-specific architecture (from registry.csv game-\* entries)
|
||||
|
||||
## Complete Next Steps Checklist
|
||||
|
||||
<action>Generate comprehensive checklist based on project analysis</action>
|
||||
|
||||
### Phase 1: Architecture and Engine Selection
|
||||
|
||||
- [ ] **Run solutioning workflow** (REQUIRED)
|
||||
- Command: `workflow create-architecture`
|
||||
- Input: GDD.md, bmm-workflow-status.md
|
||||
- Output: architecture.md with engine/platform specifics
|
||||
- Note: Registry.csv will provide engine-specific guidance
|
||||
|
||||
### Phase 2: Prototype and Playtesting
|
||||
|
||||
- [ ] **Create core mechanic prototype**
|
||||
- Validate game feel
|
||||
- Test control responsiveness
|
||||
- Iterate on game pillars
|
||||
|
||||
- [ ] **Playtest early and often**
|
||||
- Internal testing
|
||||
- External playtesting
|
||||
- Feedback integration
|
||||
|
||||
### Phase 3: Asset Production
|
||||
|
||||
- [ ] **Create asset pipeline**
|
||||
- Art style guides
|
||||
- Technical constraints
|
||||
- Asset naming conventions
|
||||
|
||||
- [ ] **Audio integration**
|
||||
- Music composition/licensing
|
||||
- SFX creation
|
||||
- Audio middleware setup
|
||||
|
||||
### Phase 4: Development
|
||||
|
||||
- [ ] **Generate detailed user stories**
|
||||
- Command: `workflow generate-stories`
|
||||
- Input: GDD.md + architecture.md
|
||||
|
||||
- [ ] **Sprint planning**
|
||||
- Vertical slices
|
||||
- Milestone planning
|
||||
- Demo/playable builds
|
||||
|
||||
<ask>**✅ GDD Complete, {user_name}!**
|
||||
|
||||
Next immediate action:
|
||||
|
||||
</check>
|
||||
|
||||
<check if="needs_narrative == true">
|
||||
|
||||
1. Create Narrative Design Document (recommended for {{game_type}})
|
||||
2. Start solutioning workflow (engine/architecture)
|
||||
3. Create prototype build
|
||||
4. Begin asset production planning
|
||||
5. Review GDD with team/stakeholders
|
||||
6. Exit workflow
|
||||
|
||||
</check>
|
||||
|
||||
<check if="else">
|
||||
|
||||
1. Start solutioning workflow (engine/architecture)
|
||||
2. Create prototype build
|
||||
3. Begin asset production planning
|
||||
4. Review GDD with team/stakeholders
|
||||
5. Exit workflow
|
||||
|
||||
Which would you like to proceed with?</ask>
|
||||
</check>
|
||||
|
||||
<check if="user selects narrative option">
|
||||
<invoke-workflow>{project-root}/bmad/bmm/workflows/2-plan-workflows/narrative/workflow.yaml</invoke-workflow>
|
||||
<action>Pass GDD context to narrative workflow</action>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
33
bmad/bmm/workflows/2-plan-workflows/gdd/workflow.yaml
Normal file
33
bmad/bmm/workflows/2-plan-workflows/gdd/workflow.yaml
Normal file
@@ -0,0 +1,33 @@
|
||||
# Game Design Document (GDD) Workflow
|
||||
name: gdd
|
||||
description: "Game Design Document workflow for all game project levels - from small prototypes to full AAA games. Generates comprehensive GDD with game mechanics, systems, progression, and implementation guidance."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/gdd"
|
||||
instructions: "{installed_path}/instructions-gdd.md"
|
||||
template: "{installed_path}/gdd-template.md"
|
||||
game_types_csv: "{installed_path}/game-types.csv"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/GDD.md"
|
||||
|
||||
# Game type references (loaded based on game type selection)
|
||||
game_type_guides: "{installed_path}/game-types/"
|
||||
|
||||
# Recommended input documents
|
||||
recommended_inputs:
|
||||
- game_brief: "{output_folder}/game-brief.md"
|
||||
- narrative_design: "{output_folder}/narrative-design.md"
|
||||
- market_research: "{output_folder}/market-research.md"
|
||||
|
||||
standalone: true
|
||||
139
bmad/bmm/workflows/2-plan-workflows/narrative/checklist.md
Normal file
139
bmad/bmm/workflows/2-plan-workflows/narrative/checklist.md
Normal file
@@ -0,0 +1,139 @@
|
||||
# Narrative Design Workflow Validation Checklist
|
||||
|
||||
**Purpose**: Validate narrative design outputs are complete, cohesive, and ready for implementation.
|
||||
|
||||
**Scope**: Story-driven games and applications (follows GDD workflow)
|
||||
|
||||
**Expected Output**: narrative-design.md
|
||||
|
||||
---
|
||||
|
||||
## 1. Output File Exists
|
||||
|
||||
- [ ] narrative-design.md created in output folder
|
||||
- [ ] GDD.md exists (narrative workflow requires GDD first)
|
||||
- [ ] No unfilled {{template_variables}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Story Foundation
|
||||
|
||||
### Core Elements
|
||||
|
||||
- [ ] **Narrative premise** clearly stated (elevator pitch, 2-3 sentences)
|
||||
- [ ] **Core themes** identified (2-4 meaningful themes)
|
||||
- [ ] **Tone and atmosphere** established
|
||||
- [ ] Premise is compelling and fits game type
|
||||
|
||||
### Story Structure
|
||||
|
||||
- [ ] **Story structure chosen** (3-act, hero's journey, branching, etc.)
|
||||
- [ ] **Acts/sections broken down** with clear progression
|
||||
- [ ] **Major story beats** documented (key moments that drive narrative)
|
||||
- [ ] Structure fits narrative complexity level
|
||||
|
||||
---
|
||||
|
||||
## 3. Characters
|
||||
|
||||
### Protagonist(s)
|
||||
|
||||
- [ ] Background and motivation explained
|
||||
- [ ] Character arc defined (how they change)
|
||||
- [ ] Internal and external conflicts identified
|
||||
|
||||
### Antagonist(s)
|
||||
|
||||
- [ ] Motivation clear (why they oppose protagonist)
|
||||
- [ ] Goals and methods explained
|
||||
- [ ] Not one-dimensional
|
||||
|
||||
### Supporting Cast
|
||||
|
||||
- [ ] Major supporting characters documented
|
||||
- [ ] Each has distinct role in story
|
||||
- [ ] Character relationships mapped
|
||||
|
||||
### Character Arcs
|
||||
|
||||
- [ ] Major characters have starting → transformation → ending states
|
||||
- [ ] Arc progression makes sense
|
||||
|
||||
---
|
||||
|
||||
## 4. World and Lore
|
||||
|
||||
- [ ] **World setting** defined (time, place, world type)
|
||||
- [ ] **World rules** explained (magic, technology, society)
|
||||
- [ ] **History and backstory** documented
|
||||
- [ ] Key locations described with narrative significance
|
||||
|
||||
---
|
||||
|
||||
## 5. Dialogue and Delivery
|
||||
|
||||
### Dialogue Framework
|
||||
|
||||
- [ ] Dialogue style established
|
||||
- [ ] Key conversations identified
|
||||
- [ ] Branching dialogue system described (if applicable)
|
||||
|
||||
### Narrative Delivery
|
||||
|
||||
- [ ] Cutscenes/cinematics approach defined
|
||||
- [ ] In-game storytelling methods explained
|
||||
- [ ] Optional vs. required content distinguished
|
||||
- [ ] Multiple endings documented (if applicable)
|
||||
|
||||
---
|
||||
|
||||
## 6. Gameplay Integration
|
||||
|
||||
- [ ] **Narrative-gameplay harmony** addressed (how story and mechanics connect)
|
||||
- [ ] **Story gates** explained (how narrative controls progression)
|
||||
- [ ] **Player agency** level defined (can player affect story?)
|
||||
- [ ] Integration doesn't fight game design
|
||||
|
||||
---
|
||||
|
||||
## 7. Production Scope
|
||||
|
||||
- [ ] **Writing scope** estimated (word count, scene count, dialogue lines)
|
||||
- [ ] Scope realistic for project level
|
||||
- [ ] Localization considerations noted (if applicable)
|
||||
- [ ] Voice acting plans documented (if applicable)
|
||||
|
||||
---
|
||||
|
||||
## 8. Consistency with GDD
|
||||
|
||||
- [ ] Narrative aligns with GDD game design
|
||||
- [ ] Tone matches GDD art/audio direction
|
||||
- [ ] Story supports game mechanics (doesn't contradict)
|
||||
- [ ] No conflicts between narrative and gameplay
|
||||
|
||||
---
|
||||
|
||||
## 9. Critical Failures (Auto-Fail)
|
||||
|
||||
- [ ] ❌ **No GDD** (narrative workflow requires GDD first)
|
||||
- [ ] ❌ **No character arcs** (protagonist has no development)
|
||||
- [ ] ❌ **No story beats** (major moments not identified)
|
||||
- [ ] ❌ **Contradicts GDD** (narrative fights game design)
|
||||
|
||||
---
|
||||
|
||||
## Validation Notes
|
||||
|
||||
**Document any findings:**
|
||||
|
||||
- Narrative strength: [Compelling / Interesting / Adequate / Weak]
|
||||
- Strengths:
|
||||
- Issues to address:
|
||||
- Recommended actions:
|
||||
|
||||
**Ready for solutioning?** [Yes / No - explain]
|
||||
|
||||
---
|
||||
|
||||
_Adapt based on narrative complexity level (Critical/Heavy/Moderate/Light)._
|
||||
@@ -0,0 +1,608 @@
|
||||
# Narrative Design Workflow
|
||||
|
||||
<workflow>
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already completed the GDD workflow</critical>
|
||||
<critical>Communicate all responses in {communication_language}</critical>
|
||||
<critical>This workflow creates detailed narrative content for story-driven games</critical>
|
||||
<critical>Uses narrative_template for output</critical>
|
||||
<critical>If users mention gameplay mechanics, note them but keep focus on narrative</critical>
|
||||
<critical>Facilitate good brainstorming techniques throughout with the user, pushing them to come up with much of the narrative you will help weave together. The goal is for the user to feel that they crafted the narrative and story arc unless they push you to do it all or indicate YOLO</critical>
|
||||
|
||||
<step n="0" goal="Check for workflow status" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Narrative workflow is optional - you can continue without status tracking.</output>
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "narrative" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="narrative status is file path (already completed)">
|
||||
<output>⚠️ Narrative Design Document already completed: {{narrative status}}</output>
|
||||
<ask>Re-running will overwrite the existing narrative document. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="narrative is not the next expected workflow (latter items are completed already in the list)">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Narrative is out of sequence.</output>
|
||||
<ask>Continue with Narrative Design anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Load GDD context and assess narrative complexity">
|
||||
|
||||
<action>Load GDD.md from {output_folder}</action>
|
||||
<action>Extract game_type, game_name, and any narrative mentions</action>
|
||||
|
||||
<ask>What level of narrative complexity does your game have?
|
||||
|
||||
**Narrative Complexity:**
|
||||
|
||||
1. **Critical** - Story IS the game (Visual Novel, Text-Based Adventure)
|
||||
2. **Heavy** - Story drives the experience (Story-driven RPG, Narrative Adventure)
|
||||
3. **Moderate** - Story enhances gameplay (Metroidvania, Tactics RPG, Horror)
|
||||
4. **Light** - Story provides context (most other genres)
|
||||
|
||||
Your game type ({{game_type}}) suggests **{{suggested_complexity}}**. Confirm or adjust:</ask>
|
||||
|
||||
<action>Set narrative_complexity</action>
|
||||
|
||||
<check if="complexity == Light">
|
||||
<ask>Light narrative games usually don't need a full Narrative Design Document. Are you sure you want to continue?
|
||||
|
||||
- GDD story sections may be sufficient
|
||||
- Consider just expanding GDD narrative notes
|
||||
- Proceed with full narrative workflow
|
||||
|
||||
Your choice:</ask>
|
||||
|
||||
<action>Load narrative_template from workflow.yaml</action>
|
||||
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Define narrative premise and themes">
|
||||
|
||||
<ask>Describe your narrative premise in 2-3 sentences.
|
||||
|
||||
This is the "elevator pitch" of your story.
|
||||
|
||||
Examples:
|
||||
|
||||
- "A young knight discovers they're the last hope to stop an ancient evil, but must choose between saving the kingdom or their own family."
|
||||
- "After a mysterious pandemic, survivors must navigate a world where telling the truth is deadly but lying corrupts your soul."
|
||||
|
||||
Your premise:</ask>
|
||||
|
||||
<template-output>narrative_premise</template-output>
|
||||
|
||||
<ask>What are the core themes of your narrative? (2-4 themes)
|
||||
|
||||
Themes are the underlying ideas/messages.
|
||||
|
||||
Examples: redemption, sacrifice, identity, corruption, hope vs. despair, nature vs. technology
|
||||
|
||||
Your themes:</ask>
|
||||
|
||||
<template-output>core_themes</template-output>
|
||||
|
||||
<ask>Describe the tone and atmosphere.
|
||||
|
||||
Consider: dark, hopeful, comedic, melancholic, mysterious, epic, intimate, etc.
|
||||
|
||||
Your tone:</ask>
|
||||
|
||||
<template-output>tone_atmosphere</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Define story structure">
|
||||
|
||||
<ask>What story structure are you using?
|
||||
|
||||
Common structures:
|
||||
|
||||
- **3-Act** (Setup, Confrontation, Resolution)
|
||||
- **Hero's Journey** (Campbell's monomyth)
|
||||
- **Kishōtenketsu** (4-act: Introduction, Development, Twist, Conclusion)
|
||||
- **Episodic** (Self-contained episodes with arc)
|
||||
- **Branching** (Multiple paths and endings)
|
||||
- **Freeform** (Player-driven narrative)
|
||||
|
||||
Your structure:</ask>
|
||||
|
||||
<template-output>story_type</template-output>
|
||||
|
||||
<ask>Break down your story into acts/sections.
|
||||
|
||||
For 3-Act:
|
||||
|
||||
- Act 1: Setup and inciting incident
|
||||
- Act 2: Rising action and midpoint
|
||||
- Act 3: Climax and resolution
|
||||
|
||||
Describe each act/section for your game:</ask>
|
||||
|
||||
<template-output>act_breakdown</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Define major story beats">
|
||||
|
||||
<ask>List the major story beats (10-20 key moments).
|
||||
|
||||
Story beats are significant events that drive the narrative forward.
|
||||
|
||||
Format:
|
||||
|
||||
1. [Beat name] - Brief description
|
||||
2. [Beat name] - Brief description
|
||||
...
|
||||
|
||||
Your story beats:</ask>
|
||||
|
||||
<template-output>story_beats</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<ask>Describe the pacing and flow of your narrative.
|
||||
|
||||
Consider:
|
||||
|
||||
- Slow burn vs. fast-paced
|
||||
- Tension/release rhythm
|
||||
- Story-heavy vs. gameplay-heavy sections
|
||||
- Optional vs. required narrative content
|
||||
|
||||
Your pacing:</ask>
|
||||
|
||||
<template-output>pacing_flow</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Develop protagonist(s)">
|
||||
|
||||
<ask>Describe your protagonist(s).
|
||||
|
||||
For each protagonist include:
|
||||
|
||||
- Name and brief description
|
||||
- Background and motivation
|
||||
- Character arc (how they change)
|
||||
- Strengths and flaws
|
||||
- Relationships to other characters
|
||||
- Internal and external conflicts
|
||||
|
||||
Your protagonist(s):</ask>
|
||||
|
||||
<template-output>protagonists</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Develop antagonist(s)">
|
||||
|
||||
<ask>Describe your antagonist(s).
|
||||
|
||||
For each antagonist include:
|
||||
|
||||
- Name and brief description
|
||||
- Background and motivation
|
||||
- Goals (what they want)
|
||||
- Methods (how they pursue goals)
|
||||
- Relationship to protagonist
|
||||
- Sympathetic elements (if any)
|
||||
|
||||
Your antagonist(s):</ask>
|
||||
|
||||
<template-output>antagonists</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Develop supporting characters">
|
||||
|
||||
<ask>Describe supporting characters (allies, mentors, companions, NPCs).
|
||||
|
||||
For each character include:
|
||||
|
||||
- Name and role
|
||||
- Personality and traits
|
||||
- Relationship to protagonist
|
||||
- Function in story (mentor, foil, comic relief, etc.)
|
||||
- Key scenes/moments
|
||||
|
||||
Your supporting characters:</ask>
|
||||
|
||||
<template-output>supporting_characters</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Map character arcs">
|
||||
|
||||
<ask>Describe the character arcs for major characters.
|
||||
|
||||
Character arc: How does the character change from beginning to end?
|
||||
|
||||
For each arc:
|
||||
|
||||
- Starting state
|
||||
- Key transformation moments
|
||||
- Ending state
|
||||
- Lessons learned
|
||||
|
||||
Your character arcs:</ask>
|
||||
|
||||
<template-output>character_arcs</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Build world and lore">
|
||||
|
||||
<ask>Describe your world.
|
||||
|
||||
Include:
|
||||
|
||||
- Setting (time period, location, world type)
|
||||
- World rules (magic systems, technology level, societal norms)
|
||||
- Atmosphere and aesthetics
|
||||
- What makes this world unique
|
||||
|
||||
Your world:</ask>
|
||||
|
||||
<template-output>world_overview</template-output>
|
||||
|
||||
<ask>What is the history and backstory of your world?
|
||||
|
||||
- Major historical events
|
||||
- How did the world reach its current state?
|
||||
- Legends and myths
|
||||
- Past conflicts
|
||||
|
||||
Your history:</ask>
|
||||
|
||||
<template-output>history_backstory</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Define factions and locations">
|
||||
|
||||
<ask optional="true">Describe factions, organizations, or groups (if applicable).
|
||||
|
||||
For each:
|
||||
|
||||
- Name and purpose
|
||||
- Leadership and structure
|
||||
- Goals and methods
|
||||
- Relationships with other factions
|
||||
|
||||
Your factions:</ask>
|
||||
|
||||
<template-output>factions_organizations</template-output>
|
||||
|
||||
<ask>Describe key locations in your world.
|
||||
|
||||
For each location:
|
||||
|
||||
- Name and description
|
||||
- Narrative significance
|
||||
- Atmosphere and mood
|
||||
- Key events that occur there
|
||||
|
||||
Your locations:</ask>
|
||||
|
||||
<template-output>locations</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Define dialogue framework">
|
||||
|
||||
<ask>Describe your dialogue style.
|
||||
|
||||
Consider:
|
||||
|
||||
- Formal vs. casual
|
||||
- Period-appropriate vs. modern
|
||||
- Verbose vs. concise
|
||||
- Humor level
|
||||
- Profanity/mature language
|
||||
|
||||
Your dialogue style:</ask>
|
||||
|
||||
<template-output>dialogue_style</template-output>
|
||||
|
||||
<ask>List key conversations/dialogue moments.
|
||||
|
||||
Include:
|
||||
|
||||
- Who is involved
|
||||
- When it occurs
|
||||
- What's discussed
|
||||
- Narrative purpose
|
||||
- Emotional tone
|
||||
|
||||
Your key conversations:</ask>
|
||||
|
||||
<template-output>key_conversations</template-output>
|
||||
|
||||
<check if="game has branching dialogue">
|
||||
<ask>Describe your branching dialogue system.
|
||||
|
||||
- How many branches/paths?
|
||||
- What determines branches? (stats, choices, flags)
|
||||
- Do branches converge?
|
||||
- How much unique dialogue?
|
||||
|
||||
Your branching system:</ask>
|
||||
|
||||
<template-output>branching_dialogue</template-output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Environmental storytelling">
|
||||
|
||||
<ask>How will you tell story through the environment?
|
||||
|
||||
Visual storytelling:
|
||||
|
||||
- Set dressing and props
|
||||
- Environmental damage/aftermath
|
||||
- Visual symbolism
|
||||
- Color and lighting
|
||||
|
||||
Your visual storytelling:</ask>
|
||||
|
||||
<template-output>visual_storytelling</template-output>
|
||||
|
||||
<ask>How will audio contribute to storytelling?
|
||||
|
||||
- Ambient sounds
|
||||
- Music emotional cues
|
||||
- Voice acting
|
||||
- Audio logs/recordings
|
||||
|
||||
Your audio storytelling:</ask>
|
||||
|
||||
<template-output>audio_storytelling</template-output>
|
||||
|
||||
<ask optional="true">Will you have found documents (journals, notes, emails)?
|
||||
|
||||
If yes, describe:
|
||||
|
||||
- Types of documents
|
||||
- How many
|
||||
- What they reveal
|
||||
- Optional vs. required reading
|
||||
|
||||
Your found documents:</ask>
|
||||
|
||||
<template-output>found_documents</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="13" goal="Narrative delivery methods">
|
||||
|
||||
<ask>How will you deliver narrative content?
|
||||
|
||||
**Cutscenes/Cinematics:**
|
||||
|
||||
- How many?
|
||||
- Skippable?
|
||||
- Real-time or pre-rendered?
|
||||
- Average length
|
||||
|
||||
Your cutscenes:</ask>
|
||||
|
||||
<template-output>cutscenes</template-output>
|
||||
|
||||
<ask>How will you deliver story during gameplay?
|
||||
|
||||
- NPC conversations
|
||||
- Radio/comm chatter
|
||||
- Environmental cues
|
||||
- Player actions
|
||||
- Show vs. tell balance
|
||||
|
||||
Your in-game storytelling:</ask>
|
||||
|
||||
<template-output>ingame_storytelling</template-output>
|
||||
|
||||
<ask>What narrative content is optional?
|
||||
|
||||
- Side quests
|
||||
- Collectible lore
|
||||
- Optional conversations
|
||||
- Secret endings
|
||||
|
||||
Your optional content:</ask>
|
||||
|
||||
<template-output>optional_content</template-output>
|
||||
|
||||
<check if="multiple endings">
|
||||
<ask>Describe your ending structure.
|
||||
|
||||
- How many endings?
|
||||
- What determines ending? (choices, stats, completion)
|
||||
- Ending variety (minor variations vs. drastically different)
|
||||
- True/golden ending?
|
||||
|
||||
Your endings:</ask>
|
||||
|
||||
<template-output>multiple_endings</template-output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="14" goal="Gameplay integration">
|
||||
|
||||
<ask>How does narrative integrate with gameplay?
|
||||
|
||||
- Does story unlock mechanics?
|
||||
- Do mechanics reflect themes?
|
||||
- Ludonarrative harmony or dissonance?
|
||||
- Balance of story vs. gameplay
|
||||
|
||||
Your narrative-gameplay integration:</ask>
|
||||
|
||||
<template-output>narrative_gameplay</template-output>
|
||||
|
||||
<ask>How does story gate progression?
|
||||
|
||||
- Story-locked areas
|
||||
- Cutscene triggers
|
||||
- Mandatory story beats
|
||||
- Optional vs. required narrative
|
||||
|
||||
Your story gates:</ask>
|
||||
|
||||
<template-output>story_gates</template-output>
|
||||
|
||||
<ask>How much agency does the player have?
|
||||
|
||||
- Can player affect story?
|
||||
- Meaningful choices?
|
||||
- Role-playing freedom?
|
||||
- Predetermined vs. dynamic narrative
|
||||
|
||||
Your player agency:</ask>
|
||||
|
||||
<template-output>player_agency</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="15" goal="Production planning">
|
||||
|
||||
<ask>Estimate your writing scope.
|
||||
|
||||
- Word count estimate
|
||||
- Number of scenes/chapters
|
||||
- Dialogue lines estimate
|
||||
- Branching complexity
|
||||
|
||||
Your scope:</ask>
|
||||
|
||||
<template-output>writing_scope</template-output>
|
||||
|
||||
<ask>Localization considerations?
|
||||
|
||||
- Target languages
|
||||
- Cultural adaptation needs
|
||||
- Text expansion concerns
|
||||
- Dialogue recording implications
|
||||
|
||||
Your localization:</ask>
|
||||
|
||||
<template-output>localization</template-output>
|
||||
|
||||
<ask>Voice acting plans?
|
||||
|
||||
- Fully voiced, partially voiced, or text-only?
|
||||
- Number of characters needing voices
|
||||
- Dialogue volume
|
||||
- Budget considerations
|
||||
|
||||
Your voice acting:</ask>
|
||||
|
||||
<template-output>voice_acting</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="16" goal="Completion and next steps">
|
||||
|
||||
<action>Generate character relationship map (text-based diagram)</action>
|
||||
<template-output>relationship_map</template-output>
|
||||
|
||||
<action>Generate story timeline</action>
|
||||
<template-output>timeline</template-output>
|
||||
|
||||
<ask optional="true">Any references or inspirations to note?
|
||||
|
||||
- Books, movies, games that inspired you
|
||||
- Reference materials
|
||||
- Tone/theme references
|
||||
|
||||
Your references:</ask>
|
||||
|
||||
<template-output>references</template-output>
|
||||
|
||||
<ask>**✅ Narrative Design Complete, {user_name}!**
|
||||
|
||||
Next steps:
|
||||
|
||||
1. Proceed to solutioning (technical architecture)
|
||||
2. Create detailed script/screenplay (outside workflow)
|
||||
3. Review narrative with team/stakeholders
|
||||
4. Exit workflow
|
||||
|
||||
Which would you like?</ask>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="17" goal="Update status if tracking enabled" tag="workflow-status">
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "narrative"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["narrative"] = "{output_folder}/bmm-narrative-{{game_name}}-{{date}}.md"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
</check>
|
||||
|
||||
<output>**✅ Narrative Design Complete, {user_name}!**
|
||||
|
||||
**Narrative Document:**
|
||||
|
||||
- Narrative design saved to {output_folder}/bmm-narrative-{{game_name}}-{{date}}.md
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
**Status Updated:**
|
||||
|
||||
- Progress tracking updated: narrative marked complete
|
||||
- Next workflow: {{next_workflow}}
|
||||
{{else}}
|
||||
**Note:** Running in standalone mode (no progress tracking)
|
||||
{{/if}}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
|
||||
- **Next workflow:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- **Optional:** Review narrative with writing team or stakeholders
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
{{else}}
|
||||
Since no workflow is in progress:
|
||||
|
||||
- Review narrative design with team
|
||||
- Refer to the BMM workflow guide if unsure what to do next
|
||||
- Or run `workflow-init` to create a workflow path and get guided next steps
|
||||
{{/if}}
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,195 @@
|
||||
# {{game_name}} - Narrative Design Document
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Game Type:** {{game_type}}
|
||||
**Narrative Complexity:** {{narrative_complexity}}
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
### Narrative Premise
|
||||
|
||||
{{narrative_premise}}
|
||||
|
||||
### Core Themes
|
||||
|
||||
{{core_themes}}
|
||||
|
||||
### Tone and Atmosphere
|
||||
|
||||
{{tone_atmosphere}}
|
||||
|
||||
---
|
||||
|
||||
## Story Structure
|
||||
|
||||
### Story Type
|
||||
|
||||
{{story_type}}
|
||||
|
||||
**Structure used:** (3-act, hero's journey, kishōtenketsu, episodic, branching, etc.)
|
||||
|
||||
### Act Breakdown
|
||||
|
||||
{{act_breakdown}}
|
||||
|
||||
### Story Beats
|
||||
|
||||
{{story_beats}}
|
||||
|
||||
### Pacing and Flow
|
||||
|
||||
{{pacing_flow}}
|
||||
|
||||
---
|
||||
|
||||
## Characters
|
||||
|
||||
### Protagonist(s)
|
||||
|
||||
{{protagonists}}
|
||||
|
||||
### Antagonist(s)
|
||||
|
||||
{{antagonists}}
|
||||
|
||||
### Supporting Characters
|
||||
|
||||
{{supporting_characters}}
|
||||
|
||||
### Character Arcs
|
||||
|
||||
{{character_arcs}}
|
||||
|
||||
---
|
||||
|
||||
## World and Lore
|
||||
|
||||
### World Overview
|
||||
|
||||
{{world_overview}}
|
||||
|
||||
### History and Backstory
|
||||
|
||||
{{history_backstory}}
|
||||
|
||||
### Factions and Organizations
|
||||
|
||||
{{factions_organizations}}
|
||||
|
||||
### Locations
|
||||
|
||||
{{locations}}
|
||||
|
||||
### Cultural Elements
|
||||
|
||||
{{cultural_elements}}
|
||||
|
||||
---
|
||||
|
||||
## Dialogue Framework
|
||||
|
||||
### Dialogue Style
|
||||
|
||||
{{dialogue_style}}
|
||||
|
||||
### Key Conversations
|
||||
|
||||
{{key_conversations}}
|
||||
|
||||
### Branching Dialogue
|
||||
|
||||
{{branching_dialogue}}
|
||||
|
||||
### Voice and Characterization
|
||||
|
||||
{{voice_characterization}}
|
||||
|
||||
---
|
||||
|
||||
## Environmental Storytelling
|
||||
|
||||
### Visual Storytelling
|
||||
|
||||
{{visual_storytelling}}
|
||||
|
||||
### Audio Storytelling
|
||||
|
||||
{{audio_storytelling}}
|
||||
|
||||
### Found Documents
|
||||
|
||||
{{found_documents}}
|
||||
|
||||
### Environmental Clues
|
||||
|
||||
{{environmental_clues}}
|
||||
|
||||
---
|
||||
|
||||
## Narrative Delivery
|
||||
|
||||
### Cutscenes and Cinematics
|
||||
|
||||
{{cutscenes}}
|
||||
|
||||
### In-Game Storytelling
|
||||
|
||||
{{ingame_storytelling}}
|
||||
|
||||
### Optional Content
|
||||
|
||||
{{optional_content}}
|
||||
|
||||
### Multiple Endings
|
||||
|
||||
{{multiple_endings}}
|
||||
|
||||
---
|
||||
|
||||
## Integration with Gameplay
|
||||
|
||||
### Narrative-Gameplay Harmony
|
||||
|
||||
{{narrative_gameplay}}
|
||||
|
||||
### Story Gates
|
||||
|
||||
{{story_gates}}
|
||||
|
||||
### Player Agency
|
||||
|
||||
{{player_agency}}
|
||||
|
||||
---
|
||||
|
||||
## Production Notes
|
||||
|
||||
### Writing Scope
|
||||
|
||||
{{writing_scope}}
|
||||
|
||||
### Localization Considerations
|
||||
|
||||
{{localization}}
|
||||
|
||||
### Voice Acting
|
||||
|
||||
{{voice_acting}}
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Character Relationship Map
|
||||
|
||||
{{relationship_map}}
|
||||
|
||||
### Timeline
|
||||
|
||||
{{timeline}}
|
||||
|
||||
### References and Inspirations
|
||||
|
||||
{{references}}
|
||||
29
bmad/bmm/workflows/2-plan-workflows/narrative/workflow.yaml
Normal file
29
bmad/bmm/workflows/2-plan-workflows/narrative/workflow.yaml
Normal file
@@ -0,0 +1,29 @@
|
||||
# Narrative Design Workflow
|
||||
name: narrative
|
||||
description: "Narrative design workflow for story-driven games and applications. Creates comprehensive narrative documentation including story structure, character arcs, dialogue systems, and narrative implementation guidance."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/narrative"
|
||||
instructions: "{installed_path}/instructions-narrative.md"
|
||||
template: "{installed_path}/narrative-template.md"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/narrative-design.md"
|
||||
|
||||
# Recommended input documents
|
||||
recommended_inputs:
|
||||
- game_brief: "{output_folder}/game-brief.md"
|
||||
- gdd: "{output_folder}/GDD.md"
|
||||
- product_brief: "{output_folder}/product-brief.md"
|
||||
|
||||
standalone: true
|
||||
117
bmad/bmm/workflows/2-plan-workflows/prd/checklist.md
Normal file
117
bmad/bmm/workflows/2-plan-workflows/prd/checklist.md
Normal file
@@ -0,0 +1,117 @@
|
||||
# PRD Workflow Validation Checklist
|
||||
|
||||
**Purpose**: Validate PRD workflow outputs are complete, consistent, and ready for next phase.
|
||||
|
||||
**Scope**: Levels 2-4 software projects
|
||||
|
||||
**Expected Outputs**: PRD.md, epics.md, updated bmm-workflow-status.md
|
||||
|
||||
---
|
||||
|
||||
## 1. Output Files Exist
|
||||
|
||||
- [ ] PRD.md created in output folder
|
||||
- [ ] epics.md created in output folder (separate file)
|
||||
- [ ] bmm-workflow-status.md updated
|
||||
- [ ] No unfilled {{template_variables}}
|
||||
|
||||
---
|
||||
|
||||
## 2. PRD.md Core Quality
|
||||
|
||||
### Requirements Coverage
|
||||
|
||||
- [ ] Functional requirements describe WHAT capabilities (not HOW to implement)
|
||||
- [ ] Each FR has unique identifier (FR001, FR002, etc.)
|
||||
- [ ] Non-functional requirements (if any) have business justification
|
||||
- [ ] Requirements are testable and verifiable
|
||||
|
||||
### User Journeys
|
||||
|
||||
- [ ] User journeys reference specific FR numbers
|
||||
- [ ] Journeys show complete user paths through system
|
||||
- [ ] Success outcomes are clear
|
||||
|
||||
### Strategic Focus
|
||||
|
||||
- [ ] PRD focuses on WHAT and WHY (not technical HOW)
|
||||
- [ ] No specific technology choices in PRD (those belong in technical-decisions.md)
|
||||
- [ ] Goals are outcome-focused, not implementation-focused
|
||||
|
||||
---
|
||||
|
||||
## 3. epics.md Story Quality
|
||||
|
||||
### Story Format
|
||||
|
||||
- [ ] All stories follow user story format: "As a [role], I want [capability], so that [benefit]"
|
||||
- [ ] Each story has numbered acceptance criteria
|
||||
- [ ] Prerequisites/dependencies explicitly stated
|
||||
|
||||
### Story Sequencing (CRITICAL)
|
||||
|
||||
- [ ] **Epic 1 establishes foundation** (infrastructure, initial deployable functionality)
|
||||
- Exception noted if adding to existing app
|
||||
- [ ] **Vertical slices**: Each story delivers complete, testable functionality (not horizontal layers)
|
||||
- [ ] **No forward dependencies**: No story depends on work from a LATER story or epic
|
||||
- [ ] Stories are sequentially ordered within each epic
|
||||
- [ ] Each story leaves system in working state
|
||||
|
||||
### Coverage
|
||||
|
||||
- [ ] All FRs from PRD.md are covered by stories in epics.md
|
||||
- [ ] Epic list in PRD.md matches epics in epics.md (titles and count)
|
||||
|
||||
---
|
||||
|
||||
## 4. Cross-Document Consistency
|
||||
|
||||
- [ ] Epic titles consistent between PRD.md and epics.md
|
||||
- [ ] FR references in user journeys exist in requirements section
|
||||
- [ ] Terminology consistent across documents
|
||||
- [ ] No contradictions between PRD and epics
|
||||
|
||||
---
|
||||
|
||||
## 5. Readiness for Next Phase
|
||||
|
||||
**Adapt based on project level from bmm-workflow-status.md:**
|
||||
|
||||
### If Level 2:
|
||||
|
||||
- [ ] PRD provides sufficient context for tech-spec workflow (lightweight solutioning)
|
||||
- [ ] Epic structure supports 5-15 story implementation scope
|
||||
|
||||
### If Level 3-4:
|
||||
|
||||
- [ ] PRD provides sufficient context for create-architecture workflow
|
||||
- [ ] Epic structure supports phased delivery approach
|
||||
- [ ] Clear value delivery path through epic sequence
|
||||
|
||||
---
|
||||
|
||||
## 6. Critical Failures (Auto-Fail)
|
||||
|
||||
- [ ] ❌ **No epics.md file** (two-file output is required)
|
||||
- [ ] ❌ **Epic 1 doesn't establish foundation** (violates core principle)
|
||||
- [ ] ❌ **Stories have forward dependencies** (would break sequential implementation)
|
||||
- [ ] ❌ **Stories not vertically sliced** (horizontal layers block value delivery)
|
||||
- [ ] ❌ **Technical decisions in PRD** (should be in technical-decisions.md)
|
||||
- [ ] ❌ **Epics don't cover all FRs** (orphaned requirements)
|
||||
- [ ] ❌ **User journeys don't reference FR numbers** (missing traceability)
|
||||
|
||||
---
|
||||
|
||||
## Validation Notes
|
||||
|
||||
**Document any findings:**
|
||||
|
||||
- Strengths:
|
||||
- Issues to address:
|
||||
- Recommended actions:
|
||||
|
||||
**Ready for next phase?** [Yes / No - explain]
|
||||
|
||||
---
|
||||
|
||||
_Adapt this checklist based on actual outputs. Not all sections may apply to every project._
|
||||
63
bmad/bmm/workflows/2-plan-workflows/prd/epics-template.md
Normal file
63
bmad/bmm/workflows/2-plan-workflows/prd/epics-template.md
Normal file
@@ -0,0 +1,63 @@
|
||||
# {{project_name}} - Epic Breakdown
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
**Project Level:** {{project_level}}
|
||||
**Target Scale:** {{target_scale}}
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides the detailed epic breakdown for {{project_name}}, expanding on the high-level epic list in the [PRD](./PRD.md).
|
||||
|
||||
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
|
||||
|
||||
---
|
||||
|
||||
{{epic_details}}
|
||||
|
||||
---
|
||||
|
||||
## Story Guidelines Reference
|
||||
|
||||
**Story Format:**
|
||||
|
||||
```
|
||||
**Story [EPIC.N]: [Story Title]**
|
||||
|
||||
As a [user type],
|
||||
I want [goal/desire],
|
||||
So that [benefit/value].
|
||||
|
||||
**Acceptance Criteria:**
|
||||
1. [Specific testable criterion]
|
||||
2. [Another specific criterion]
|
||||
3. [etc.]
|
||||
|
||||
**Prerequisites:** [Dependencies on previous stories, if any]
|
||||
```
|
||||
|
||||
**Story Requirements:**
|
||||
|
||||
- **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
|
||||
|
||||
---
|
||||
|
||||
**For implementation:** Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown.
|
||||
431
bmad/bmm/workflows/2-plan-workflows/prd/instructions.md
Normal file
431
bmad/bmm/workflows/2-plan-workflows/prd/instructions.md
Normal file
@@ -0,0 +1,431 @@
|
||||
# PRD Workflow Instructions
|
||||
|
||||
<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>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>This workflow is for Level 2-4 projects. Level 0-1 use tech-spec workflow.</critical>
|
||||
<critical>Produces TWO outputs: PRD.md (strategic) and epics.md (tactical implementation)</critical>
|
||||
<critical>TECHNICAL NOTES: If ANY technical details, preferences, or constraints are mentioned during PRD discussions, append them to {technical_decisions_file}. If file doesn't exist, create it from {technical_decisions_template}</critical>
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Concise, clear, actionable requirements. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. PRD workflow can run standalone or as part of BMM workflow path.</output>
|
||||
<output>**Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing.</output>
|
||||
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
||||
<check if="continue">
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
<check if="exit">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "prd" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_level < 2">
|
||||
<output>**Incorrect Workflow for Level {{project_level}}**
|
||||
|
||||
PRD is for Level 2-4 projects. Level 0-1 should use tech-spec directly.
|
||||
|
||||
**Correct workflow:** `tech-spec` (Architect agent)
|
||||
</output>
|
||||
<action>Exit and redirect to tech-spec</action>
|
||||
</check>
|
||||
|
||||
<check if="prd status is file path (already completed)">
|
||||
<output>⚠️ PRD already completed: {{prd status}}</output>
|
||||
<ask>Re-running will overwrite the existing PRD. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="prd is not the next expected workflow">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. PRD is out of sequence.</output>
|
||||
<ask>Continue with PRD anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Initialize PRD context">
|
||||
|
||||
<action>Use {{project_level}} from status data</action>
|
||||
<action>Check for existing PRD.md in {output_folder}</action>
|
||||
|
||||
<check if="PRD.md exists">
|
||||
<ask>Found existing PRD.md. Would you like to:
|
||||
1. Continue where you left off
|
||||
2. Modify existing sections
|
||||
3. Start fresh (will archive existing file)
|
||||
</ask>
|
||||
<action if="option 1">Load existing PRD and skip to first incomplete section</action>
|
||||
<action if="option 2">Load PRD and ask which section to modify</action>
|
||||
<action if="option 3">Archive existing PRD and start fresh</action>
|
||||
</check>
|
||||
|
||||
<action>Load PRD template: {prd_template}</action>
|
||||
<action>Load epics template: {epics_template}</action>
|
||||
|
||||
<ask>Do you have a Product Brief? (Strongly recommended for Level 3-4, helpful for Level 2)</ask>
|
||||
|
||||
<check if="yes">
|
||||
<action>Load and review product brief: {output_folder}/product-brief.md</action>
|
||||
<action>Extract key elements: problem statement, target users, success metrics, MVP scope, constraints</action>
|
||||
</check>
|
||||
|
||||
<check if="no and level >= 3">
|
||||
<warning>Product Brief is strongly recommended for Level 3-4 projects. Consider running the product-brief workflow first.</warning>
|
||||
<ask>Continue without Product Brief? (y/n)</ask>
|
||||
<action if="no">Exit to allow Product Brief creation</action>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Goals and Background Context">
|
||||
|
||||
**Goals** - What success looks like for this project
|
||||
|
||||
<check if="product brief exists">
|
||||
<action>Review goals from product brief and refine for PRD context</action>
|
||||
</check>
|
||||
|
||||
<check if="no product brief">
|
||||
<action>Gather goals through discussion with user, use probing questions and converse until you are ready to propose that you have enough information to proceed</action>
|
||||
</check>
|
||||
|
||||
Create a bullet list of single-line desired outcomes that capture user and project goals.
|
||||
|
||||
**Scale guidance:**
|
||||
|
||||
- Level 2: 2-3 core goals
|
||||
- Level 3: 3-5 strategic goals
|
||||
- Level 4: 5-7 comprehensive goals
|
||||
|
||||
<template-output>goals</template-output>
|
||||
|
||||
**Background Context** - Why this matters now
|
||||
|
||||
<check if="product brief exists">
|
||||
<action>Summarize key context from brief without redundancy</action>
|
||||
</check>
|
||||
|
||||
<check if="no product brief">
|
||||
<action>Gather context through discussion</action>
|
||||
</check>
|
||||
|
||||
Write 1-2 paragraphs covering:
|
||||
|
||||
- What problem this solves and why
|
||||
- Current landscape or need
|
||||
- Key insights from discovery/brief (if available)
|
||||
|
||||
<template-output>background_context</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Requirements - Functional and Non-Functional">
|
||||
|
||||
**Functional Requirements** - What the system must do
|
||||
|
||||
Draft functional requirements as numbered items with FR prefix.
|
||||
|
||||
**Scale guidance:**
|
||||
|
||||
- Level 2: 8-15 FRs (focused MVP set)
|
||||
- Level 3: 12-25 FRs (comprehensive product)
|
||||
- Level 4: 20-35 FRs (enterprise platform)
|
||||
|
||||
**Format:**
|
||||
|
||||
- FR001: [Clear capability statement]
|
||||
- FR002: [Another capability]
|
||||
|
||||
**Focus on:**
|
||||
|
||||
- User-facing capabilities
|
||||
- Core system behaviors
|
||||
- Integration requirements
|
||||
- Data management needs
|
||||
|
||||
Group related requirements logically.
|
||||
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<template-output>functional_requirements</template-output>
|
||||
|
||||
**Non-Functional Requirements** - How the system must perform
|
||||
|
||||
Draft non-functional requirements with NFR prefix.
|
||||
|
||||
**Scale guidance:**
|
||||
|
||||
- Level 2: 1-3 NFRs (critical MVP only)
|
||||
- Level 3: 2-5 NFRs (production quality)
|
||||
- Level 4: 3-7+ NFRs (enterprise grade)
|
||||
|
||||
<template-output>non_functional_requirements</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="User Journeys - scale-adaptive" optional="level == 2">
|
||||
|
||||
**Journey Guidelines (scale-adaptive):**
|
||||
|
||||
- **Level 2:** 1 simple journey (primary use case happy path)
|
||||
- **Level 3:** 2-3 detailed journeys (complete flows with decision points)
|
||||
- **Level 4:** 3-5 comprehensive journeys (all personas and edge cases)
|
||||
|
||||
<check if="level == 2">
|
||||
<ask>Would you like to document a user journey for the primary use case? (recommended but optional)</ask>
|
||||
<check if="yes">
|
||||
Create 1 simple journey showing the happy path.
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="level >= 3">
|
||||
Map complete user flows with decision points, alternatives, and edge cases.
|
||||
</check>
|
||||
|
||||
<template-output>user_journeys</template-output>
|
||||
|
||||
<check if="level >= 3">
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="UX and UI Vision - high-level overview" optional="level == 2 and minimal UI">
|
||||
|
||||
**Purpose:** Capture essential UX/UI information needed for epic and story planning. A dedicated UX workflow will provide deeper design detail later.
|
||||
|
||||
<check if="level == 2 and minimal UI">
|
||||
<action>For backend-heavy or minimal UI projects, keep this section very brief or skip</action>
|
||||
</check>
|
||||
|
||||
**Gather high-level UX/UI information:**
|
||||
|
||||
1. **UX Principles** (2-4 key principles that guide design decisions)
|
||||
- What core experience qualities matter most?
|
||||
- Any critical accessibility or usability requirements?
|
||||
|
||||
2. **Platform & Screens**
|
||||
- Target platforms (web, mobile, desktop)
|
||||
- Core screens/views users will interact with
|
||||
- Key interaction patterns or navigation approach
|
||||
|
||||
3. **Design Constraints**
|
||||
- Existing design systems or brand guidelines
|
||||
- Technical UI constraints (browser support, etc.)
|
||||
|
||||
<note>Keep responses high-level. Detailed UX planning happens in the UX workflow after PRD completion.</note>
|
||||
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<template-output>ux_principles</template-output>
|
||||
<template-output>ui_design_goals</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Epic List - High-level delivery sequence">
|
||||
|
||||
**Epic Structure** - Major delivery milestones
|
||||
|
||||
Create high-level epic list showing logical delivery sequence.
|
||||
|
||||
**Epic Sequencing Rules:**
|
||||
|
||||
1. **Epic 1 MUST establish foundation**
|
||||
- Project infrastructure (repo, CI/CD, core setup)
|
||||
- Initial deployable functionality
|
||||
- Development workflow established
|
||||
- Exception: If adding to existing app, Epic 1 can be first major feature
|
||||
|
||||
2. **Subsequent Epics:**
|
||||
- Each delivers significant, end-to-end, fully deployable increment
|
||||
- Build upon previous epics (no forward dependencies)
|
||||
- Represent major functional blocks
|
||||
- Prefer fewer, larger epics over fragmentation
|
||||
|
||||
**Scale guidance:**
|
||||
|
||||
- Level 2: 1-2 epics, 5-15 stories total
|
||||
- Level 3: 2-5 epics, 15-40 stories total
|
||||
- Level 4: 5-10 epics, 40-100+ stories total
|
||||
|
||||
**For each epic provide:**
|
||||
|
||||
- Epic number and title
|
||||
- Single-sentence goal statement
|
||||
- Estimated story count
|
||||
|
||||
**Example:**
|
||||
|
||||
- **Epic 1: Project Foundation & User Authentication**
|
||||
- **Epic 2: Core Task Management**
|
||||
|
||||
<ask>Review the epic list. Does the sequence make sense? Any epics to add, remove, or resequence?</ask>
|
||||
<action>Refine epic list based on feedback</action>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<template-output>epic_list</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Out of Scope - Clear boundaries and future additions">
|
||||
|
||||
**Out of Scope** - What we're NOT doing (now)
|
||||
|
||||
Document what is explicitly excluded from this project:
|
||||
|
||||
- Features/capabilities deferred to future phases
|
||||
- Adjacent problems not being solved
|
||||
- Integrations or platforms not supported
|
||||
- Scope boundaries that need clarification
|
||||
|
||||
This helps prevent scope creep and sets clear expectations.
|
||||
|
||||
<template-output>out_of_scope</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Finalize PRD.md">
|
||||
|
||||
<action>Review all PRD sections for completeness and consistency</action>
|
||||
<action>Ensure all placeholders are filled</action>
|
||||
<action>Save final PRD.md to {default_output_file}</action>
|
||||
|
||||
**PRD.md is complete!** Strategic document ready.
|
||||
|
||||
Now we'll create the tactical implementation guide in epics.md.
|
||||
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Epic Details - Full story breakdown in epics.md">
|
||||
|
||||
<critical>Now we create epics.md - the tactical implementation roadmap</critical>
|
||||
<critical>This is a SEPARATE FILE from PRD.md</critical>
|
||||
|
||||
<action>Load epics template: {epics_template}</action>
|
||||
<action>Initialize epics.md with project metadata</action>
|
||||
|
||||
For each epic from the epic list, expand with full story details:
|
||||
|
||||
**Epic Expansion Process:**
|
||||
|
||||
1. **Expanded Goal** (2-3 sentences)
|
||||
- Describe the epic's objective and value delivery
|
||||
- Explain how it builds on previous work
|
||||
|
||||
2. **Story Breakdown**
|
||||
|
||||
**Critical Story Requirements:**
|
||||
- **Vertical slices** - Each story delivers complete, testable functionality
|
||||
- **Sequential** - Stories must be logically ordered within epic
|
||||
- **No forward dependencies** - No story depends on work from a later story/epic
|
||||
- **AI-agent sized** - Completable in single focused session (2-4 hours)
|
||||
- **Value-focused** - Minimize pure enabler stories; integrate technical work into value delivery
|
||||
|
||||
**Story Format:**
|
||||
|
||||
```
|
||||
**Story [EPIC.N]: [Story Title]**
|
||||
|
||||
As a [user type],
|
||||
I want [goal/desire],
|
||||
So that [benefit/value].
|
||||
|
||||
**Acceptance Criteria:**
|
||||
1. [Specific testable criterion]
|
||||
2. [Another specific criterion]
|
||||
3. [etc.]
|
||||
|
||||
**Prerequisites:** [Any dependencies on previous stories]
|
||||
```
|
||||
|
||||
3. **Story Sequencing Within Epic:**
|
||||
- Start with foundational/setup work if needed
|
||||
- Build progressively toward epic goal
|
||||
- Each story should leave system in working state
|
||||
- Final stories complete the epic's value delivery
|
||||
|
||||
**Process each epic:**
|
||||
|
||||
<repeat for-each="epic in epic_list">
|
||||
|
||||
<ask>Ready to break down {{epic_title}}? (y/n)</ask>
|
||||
|
||||
<action>Discuss epic scope and story ideas with user</action>
|
||||
<action>Draft story list ensuring vertical slices and proper sequencing</action>
|
||||
<action>For each story, write user story format and acceptance criteria</action>
|
||||
<action>Verify no forward dependencies exist</action>
|
||||
|
||||
<template-output file="epics.md">{{epic_title}}\_details</template-output>
|
||||
|
||||
<ask>Review {{epic_title}} stories. Any adjustments needed?</ask>
|
||||
|
||||
<action if="yes">Refine stories based on feedback</action>
|
||||
|
||||
</repeat>
|
||||
|
||||
<action>Save complete epics.md to {epics_output_file}</action>
|
||||
|
||||
**Epic Details complete!** Implementation roadmap ready.
|
||||
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Update status and complete" tag="workflow-status">
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "prd"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["prd"] = "{default_output_file}"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
</check>
|
||||
|
||||
<output>**✅ PRD Workflow Complete, {user_name}!**
|
||||
|
||||
**Deliverables Created:**
|
||||
|
||||
1. ✅ bmm-PRD.md - Strategic product requirements document
|
||||
2. ✅ bmm-epics.md - Tactical implementation roadmap with story breakdown
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
- **Next required:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- **Optional:** Review PRD and epics with stakeholders, or run `create-design` if you have UI requirements
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
|
||||
Would you like to:
|
||||
|
||||
1. Review/refine any section
|
||||
2. Proceed to next phase
|
||||
3. Exit and review documents
|
||||
</output>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
62
bmad/bmm/workflows/2-plan-workflows/prd/prd-template.md
Normal file
62
bmad/bmm/workflows/2-plan-workflows/prd/prd-template.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# {{project_name}} Product Requirements Document (PRD)
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
**Project Level:** {{project_level}}
|
||||
**Target Scale:** {{target_scale}}
|
||||
|
||||
---
|
||||
|
||||
## Goals and Background Context
|
||||
|
||||
### Goals
|
||||
|
||||
{{goals}}
|
||||
|
||||
### Background Context
|
||||
|
||||
{{background_context}}
|
||||
|
||||
---
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
{{functional_requirements}}
|
||||
|
||||
### Non-Functional Requirements
|
||||
|
||||
{{non_functional_requirements}}
|
||||
|
||||
---
|
||||
|
||||
## User Journeys
|
||||
|
||||
{{user_journeys}}
|
||||
|
||||
---
|
||||
|
||||
## UX Design Principles
|
||||
|
||||
{{ux_principles}}
|
||||
|
||||
---
|
||||
|
||||
## User Interface Design Goals
|
||||
|
||||
{{ui_design_goals}}
|
||||
|
||||
---
|
||||
|
||||
## Epic List
|
||||
|
||||
{{epic_list}}
|
||||
|
||||
> **Note:** Detailed epic breakdown with full story specifications is available in [epics.md](./epics.md)
|
||||
|
||||
---
|
||||
|
||||
## Out of Scope
|
||||
|
||||
{{out_of_scope}}
|
||||
36
bmad/bmm/workflows/2-plan-workflows/prd/workflow.yaml
Normal file
36
bmad/bmm/workflows/2-plan-workflows/prd/workflow.yaml
Normal file
@@ -0,0 +1,36 @@
|
||||
# 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."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/bmad/bmm/config.yaml"
|
||||
project_name: "{config_source}:project_name"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
|
||||
# Templates
|
||||
prd_template: "{installed_path}/prd-template.md"
|
||||
epics_template: "{installed_path}/epics-template.md"
|
||||
|
||||
# Output files
|
||||
status_file: "{output_folder}/bmm-workflow-status.md"
|
||||
default_output_file: "{output_folder}/PRD.md"
|
||||
epics_output_file: "{output_folder}/epics.md"
|
||||
technical_decisions_file: "{output_folder}/technical-decisions.md"
|
||||
technical_decisions_template: "{project-root}/bmad/bmm/_module-installer/assets/technical-decisions.md"
|
||||
|
||||
# Recommended input documents
|
||||
recommended_inputs:
|
||||
- product_brief: "{output_folder}/product-brief.md"
|
||||
- market_research: "{output_folder}/market-research.md"
|
||||
|
||||
standalone: true
|
||||
107
bmad/bmm/workflows/2-plan-workflows/tech-spec/checklist.md
Normal file
107
bmad/bmm/workflows/2-plan-workflows/tech-spec/checklist.md
Normal file
@@ -0,0 +1,107 @@
|
||||
# Tech-Spec Workflow Validation Checklist
|
||||
|
||||
**Purpose**: Validate tech-spec workflow outputs are definitive, complete, and implementation-ready.
|
||||
|
||||
**Scope**: Levels 0-1 software projects
|
||||
|
||||
**Expected Outputs**: tech-spec.md + story files (1 for Level 0, 2-3 for Level 1)
|
||||
|
||||
---
|
||||
|
||||
## 1. Output Files Exist
|
||||
|
||||
- [ ] tech-spec.md created in output folder
|
||||
- [ ] Story file(s) created in dev_story_location
|
||||
- Level 0: 1 story file (story-{slug}.md)
|
||||
- Level 1: epics.md + 2-3 story files (story-{epic-slug}-N.md)
|
||||
- [ ] bmm-workflow-status.md updated to Phase 4
|
||||
- [ ] No unfilled {{template_variables}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Tech-Spec Definitiveness (CRITICAL)
|
||||
|
||||
### No Ambiguity Allowed
|
||||
|
||||
- [ ] **Zero "or" statements**: NO "use X or Y", "either A or B", "options include"
|
||||
- [ ] **Specific versions**: All frameworks, libraries, tools have EXACT versions
|
||||
- ✅ GOOD: "Python 3.11", "React 18.2.0", "winston v3.8.2"
|
||||
- ❌ BAD: "Python 2 or 3", "React 18+", "a logger like pino or winston"
|
||||
- [ ] **Definitive decisions**: Every technical choice is final, not a proposal
|
||||
|
||||
### Implementation Clarity
|
||||
|
||||
- [ ] Source tree shows EXACT file paths (not "somewhere in src/")
|
||||
- [ ] Each file marked as create/modify/delete
|
||||
- [ ] Technical approach describes SPECIFIC implementation
|
||||
- [ ] Implementation stack has complete toolchain with versions
|
||||
|
||||
---
|
||||
|
||||
## 3. Story Quality
|
||||
|
||||
### Story Format
|
||||
|
||||
- [ ] All stories use "As a [role], I want [capability], so that [benefit]" format
|
||||
- [ ] Each story has numbered acceptance criteria
|
||||
- [ ] Tasks reference AC numbers: (AC: #1), (AC: #2)
|
||||
- [ ] Dev Notes section links back to tech-spec.md
|
||||
|
||||
### Story Sequencing (If Level 1)
|
||||
|
||||
- [ ] **Vertical slices**: Each story delivers complete, testable functionality
|
||||
- [ ] **Sequential ordering**: Stories in logical progression
|
||||
- [ ] **No forward dependencies**: No story depends on later work
|
||||
- [ ] Each story leaves system in working state
|
||||
|
||||
### Coverage
|
||||
|
||||
- [ ] Story acceptance criteria derived from tech-spec testing section
|
||||
- [ ] Story tasks map to tech-spec implementation guide
|
||||
- [ ] Files in stories match tech-spec source tree
|
||||
|
||||
---
|
||||
|
||||
## 4. Workflow Status Integration
|
||||
|
||||
- [ ] bmm-workflow-status.md shows current_phase = "4-Implementation"
|
||||
- [ ] Phase 2 ("2-Plan") marked complete
|
||||
- [ ] First story in TODO section, others in BACKLOG (if Level 1)
|
||||
- [ ] Next action clear (review story, run story-ready)
|
||||
|
||||
---
|
||||
|
||||
## 5. Readiness for Implementation
|
||||
|
||||
- [ ] Developer can start coding from tech-spec alone
|
||||
- [ ] All technical questions answered definitively
|
||||
- [ ] Testing approach clear and verifiable
|
||||
- [ ] Deployment strategy documented
|
||||
|
||||
---
|
||||
|
||||
## 6. Critical Failures (Auto-Fail)
|
||||
|
||||
- [ ] ❌ **Non-definitive technical decisions** (any "option A or B" or vague choices)
|
||||
- [ ] ❌ **Missing versions** (framework/library without specific version)
|
||||
- [ ] ❌ **Stories don't match template** (incompatible with story-context/dev-story workflows)
|
||||
- [ ] ❌ **Missing tech-spec sections** (required section missing from tech-spec.md)
|
||||
- [ ] ❌ **Stories have forward dependencies** (would break sequential implementation)
|
||||
- [ ] ❌ **Vague source tree** (file changes not specific)
|
||||
|
||||
---
|
||||
|
||||
## Validation Notes
|
||||
|
||||
**Document any findings:**
|
||||
|
||||
- Definitiveness score: [All definitive / Some ambiguity / Significant ambiguity]
|
||||
- Strengths:
|
||||
- Issues to address:
|
||||
- Recommended actions:
|
||||
|
||||
**Ready for implementation?** [Yes / No - explain]
|
||||
|
||||
---
|
||||
|
||||
_Adapt based on Level 0 vs Level 1. Focus on definitiveness above all else._
|
||||
@@ -0,0 +1,11 @@
|
||||
# {{project_name}} - Epic Breakdown
|
||||
|
||||
## Epic Overview
|
||||
|
||||
{{epic_overview}}
|
||||
|
||||
---
|
||||
|
||||
## Epic Details
|
||||
|
||||
{{epic_details}}
|
||||
@@ -0,0 +1,167 @@
|
||||
# Level 0 - Minimal User Story Generation
|
||||
|
||||
<workflow>
|
||||
|
||||
<critical>This generates a single user story for Level 0 atomic changes</critical>
|
||||
<critical>Level 0 = single file change, bug fix, or small isolated task</critical>
|
||||
<critical>This workflow runs AFTER tech-spec.md has been completed</critical>
|
||||
<critical>Output format MUST match create-story template for compatibility with story-context and dev-story workflows</critical>
|
||||
|
||||
<step n="1" goal="Load tech spec and extract the change">
|
||||
|
||||
<action>Read the completed tech-spec.md file from {output_folder}/tech-spec.md</action>
|
||||
<action>Load bmm-workflow-status.md from {output_folder}/bmm-workflow-status.md</action>
|
||||
<action>Extract dev_story_location from config (where stories are stored)</action>
|
||||
<action>Extract the problem statement from "Technical Approach" section</action>
|
||||
<action>Extract the scope from "Source Tree Structure" section</action>
|
||||
<action>Extract time estimate from "Implementation Guide" or technical details</action>
|
||||
<action>Extract acceptance criteria from "Testing Approach" section</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Generate story slug and filename">
|
||||
|
||||
<action>Derive a short URL-friendly slug from the feature/change name</action>
|
||||
<action>Max slug length: 3-5 words, kebab-case format</action>
|
||||
|
||||
<example>
|
||||
- "Migrate JS Library Icons" → "icon-migration"
|
||||
- "Fix Login Validation Bug" → "login-fix"
|
||||
- "Add OAuth Integration" → "oauth-integration"
|
||||
</example>
|
||||
|
||||
<action>Set story_filename = "story-{slug}.md"</action>
|
||||
<action>Set story_path = "{dev_story_location}/story-{slug}.md"</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Create user story in standard format">
|
||||
|
||||
<action>Create 1 story that describes the technical change as a deliverable</action>
|
||||
<action>Story MUST use create-story template format for compatibility</action>
|
||||
|
||||
<guidelines>
|
||||
**Story Point Estimation:**
|
||||
- 1 point = < 1 day (2-4 hours)
|
||||
- 2 points = 1-2 days
|
||||
- 3 points = 2-3 days
|
||||
- 5 points = 3-5 days (if this high, question if truly Level 0)
|
||||
|
||||
**Story Title Best Practices:**
|
||||
|
||||
- Use active, user-focused language
|
||||
- Describe WHAT is delivered, not HOW
|
||||
- Good: "Icon Migration to Internal CDN"
|
||||
- Bad: "Run curl commands to download PNGs"
|
||||
|
||||
**Story Description Format:**
|
||||
|
||||
- As a [role] (developer, user, admin, etc.)
|
||||
- I want [capability/change]
|
||||
- So that [benefit/value]
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
- Extract from tech-spec "Testing Approach" section
|
||||
- Must be specific, measurable, and testable
|
||||
- Include performance criteria if specified
|
||||
|
||||
**Tasks/Subtasks:**
|
||||
|
||||
- Map directly to tech-spec "Implementation Guide" tasks
|
||||
- Use checkboxes for tracking
|
||||
- Reference AC numbers: (AC: #1), (AC: #2)
|
||||
- Include explicit testing subtasks
|
||||
|
||||
**Dev Notes:**
|
||||
|
||||
- Extract technical constraints from tech-spec
|
||||
- Include file paths from "Source Tree Structure"
|
||||
- Reference architecture patterns if applicable
|
||||
- Cite tech-spec sections for implementation details
|
||||
</guidelines>
|
||||
|
||||
<action>Initialize story file using user_story_template</action>
|
||||
|
||||
<template-output file="{story_path}">story_title</template-output>
|
||||
<template-output file="{story_path}">role</template-output>
|
||||
<template-output file="{story_path}">capability</template-output>
|
||||
<template-output file="{story_path}">benefit</template-output>
|
||||
<template-output file="{story_path}">acceptance_criteria</template-output>
|
||||
<template-output file="{story_path}">tasks_subtasks</template-output>
|
||||
<template-output file="{story_path}">technical_summary</template-output>
|
||||
<template-output file="{story_path}">files_to_modify</template-output>
|
||||
<template-output file="{story_path}">test_locations</template-output>
|
||||
<template-output file="{story_path}">story_points</template-output>
|
||||
<template-output file="{story_path}">time_estimate</template-output>
|
||||
<template-output file="{story_path}">architecture_references</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Update status - Level 0 single story">
|
||||
|
||||
<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
|
||||
<param>mode: update</param>
|
||||
<param>action: complete_workflow</param>
|
||||
<param>workflow_name: tech-spec</param>
|
||||
</invoke-workflow>
|
||||
|
||||
<check if="success == true">
|
||||
<output>✅ Tech-spec complete! Next: {{next_workflow}}</output>
|
||||
</check>
|
||||
|
||||
<action>Load {{status_file_path}}</action>
|
||||
<action>Set STORIES_SEQUENCE: [{slug}]</action>
|
||||
<action>Set TODO_STORY: {slug}</action>
|
||||
<action>Set TODO_TITLE: {{story_title}}</action>
|
||||
<action>Set IN_PROGRESS_STORY: (empty)</action>
|
||||
<action>Set STORIES_DONE: []</action>
|
||||
<action>Save {{status_file_path}}</action>
|
||||
|
||||
<output>Story queue initialized with single story: {slug}</output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Provide user guidance for next steps">
|
||||
|
||||
<action>Display completion summary</action>
|
||||
|
||||
**Level 0 Planning Complete!**
|
||||
|
||||
**Generated Artifacts:**
|
||||
|
||||
- `tech-spec.md` → Technical source of truth
|
||||
- `story-{slug}.md` → User story ready for implementation
|
||||
|
||||
**Story Location:** `{story_path}`
|
||||
|
||||
**Next Steps (choose one path):**
|
||||
|
||||
**Option A - Full Context (Recommended for complex changes):**
|
||||
|
||||
1. Load SM agent: `{project-root}/bmad/bmm/agents/sm.md`
|
||||
2. Run story-context workflow
|
||||
3. Then load DEV agent and run dev-story workflow
|
||||
|
||||
**Option B - Direct to Dev (For simple, well-understood changes):**
|
||||
|
||||
1. Load DEV agent: `{project-root}/bmad/bmm/agents/dev.md`
|
||||
2. Run dev-story workflow (will auto-discover story)
|
||||
3. Begin implementation
|
||||
|
||||
**Progress Tracking:**
|
||||
|
||||
- All decisions logged in: `bmm-workflow-status.md`
|
||||
- Next action clearly identified
|
||||
|
||||
<ask>Ready to proceed? Choose your path:
|
||||
|
||||
1. Generate story context (Option A - recommended)
|
||||
2. Go directly to dev-story implementation (Option B - faster)
|
||||
3. Exit for now
|
||||
|
||||
Select option (1-3):</ask>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,278 @@
|
||||
# Level 1 - Epic and Stories Generation
|
||||
|
||||
<workflow>
|
||||
|
||||
<critical>This generates epic and user stories for Level 1 projects after tech-spec completion</critical>
|
||||
<critical>This is a lightweight story breakdown - not a full PRD</critical>
|
||||
<critical>Level 1 = coherent feature, 1-10 stories (prefer 2-3), 1 epic</critical>
|
||||
<critical>This workflow runs AFTER tech-spec.md has been completed</critical>
|
||||
<critical>Story format MUST match create-story template for compatibility with story-context and dev-story workflows</critical>
|
||||
|
||||
<step n="1" goal="Load tech spec and extract implementation tasks">
|
||||
|
||||
<action>Read the completed tech-spec.md file from {output_folder}/tech-spec.md</action>
|
||||
<action>Load bmm-workflow-status.md from {output_folder}/bmm-workflow-status.md</action>
|
||||
<action>Extract dev_story_location from config (where stories are stored)</action>
|
||||
<action>Identify all implementation tasks from the "Implementation Guide" section</action>
|
||||
<action>Identify the overall feature goal from "Technical Approach" section</action>
|
||||
<action>Extract time estimates for each implementation phase</action>
|
||||
<action>Identify any dependencies between implementation tasks</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Create single epic">
|
||||
|
||||
<action>Create 1 epic that represents the entire feature</action>
|
||||
<action>Epic title should be user-facing value statement</action>
|
||||
<action>Epic goal should describe why this matters to users</action>
|
||||
|
||||
<guidelines>
|
||||
**Epic Best Practices:**
|
||||
- Title format: User-focused outcome (not implementation detail)
|
||||
- Good: "JS Library Icon Reliability"
|
||||
- Bad: "Update recommendedLibraries.ts file"
|
||||
- Scope: Clearly define what's included/excluded
|
||||
- Success criteria: Measurable outcomes that define "done"
|
||||
</guidelines>
|
||||
|
||||
<example>
|
||||
**Epic:** JS Library Icon Reliability
|
||||
|
||||
**Goal:** Eliminate external dependencies for JS library icons to ensure consistent, reliable display and improve application performance.
|
||||
|
||||
**Scope:** Migrate all 14 recommended JS library icons from third-party CDN URLs (GitHub, jsDelivr) to internal static asset hosting.
|
||||
|
||||
**Success Criteria:**
|
||||
|
||||
- All library icons load from internal paths
|
||||
- Zero external requests for library icons
|
||||
- Icons load 50-200ms faster than baseline
|
||||
- No broken icons in production
|
||||
</example>
|
||||
|
||||
<action>Derive epic slug from epic title (kebab-case, 2-3 words max)</action>
|
||||
<example>
|
||||
|
||||
- "JS Library Icon Reliability" → "icon-reliability"
|
||||
- "OAuth Integration" → "oauth-integration"
|
||||
- "Admin Dashboard" → "admin-dashboard"
|
||||
</example>
|
||||
|
||||
<action>Initialize epics.md summary document using epics_template</action>
|
||||
|
||||
<template-output file="{output_folder}/epics.md">epic_title</template-output>
|
||||
<template-output file="{output_folder}/epics.md">epic_slug</template-output>
|
||||
<template-output file="{output_folder}/epics.md">epic_goal</template-output>
|
||||
<template-output file="{output_folder}/epics.md">epic_scope</template-output>
|
||||
<template-output file="{output_folder}/epics.md">epic_success_criteria</template-output>
|
||||
<template-output file="{output_folder}/epics.md">epic_dependencies</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Determine optimal story count">
|
||||
|
||||
<critical>Level 1 should have 2-3 stories maximum - prefer longer stories over more stories</critical>
|
||||
|
||||
<action>Analyze tech spec implementation tasks and time estimates</action>
|
||||
<action>Group related tasks into logical story boundaries</action>
|
||||
|
||||
<guidelines>
|
||||
**Story Count Decision Matrix:**
|
||||
|
||||
**2 Stories (preferred for most Level 1):**
|
||||
|
||||
- Use when: Feature has clear build/verify split
|
||||
- Example: Story 1 = Build feature, Story 2 = Test and deploy
|
||||
- Typical points: 3-5 points per story
|
||||
|
||||
**3 Stories (only if necessary):**
|
||||
|
||||
- Use when: Feature has distinct setup, build, verify phases
|
||||
- Example: Story 1 = Setup, Story 2 = Core implementation, Story 3 = Integration and testing
|
||||
- Typical points: 2-3 points per story
|
||||
|
||||
**Never exceed 3 stories for Level 1:**
|
||||
|
||||
- If more needed, consider if project should be Level 2
|
||||
- Better to have longer stories (5 points) than more stories (5x 1-point stories)
|
||||
</guidelines>
|
||||
|
||||
<action>Determine story_count = 2 or 3 based on tech spec complexity</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Generate user stories from tech spec tasks">
|
||||
|
||||
<action>For each story (2-3 total), generate separate story file</action>
|
||||
<action>Story filename format: "story-{epic_slug}-{n}.md" where n = 1, 2, or 3</action>
|
||||
|
||||
<guidelines>
|
||||
**Story Generation Guidelines:**
|
||||
- Each story = multiple implementation tasks from tech spec
|
||||
- Story title format: User-focused deliverable (not implementation steps)
|
||||
- Include technical acceptance criteria from tech spec tasks
|
||||
- Link back to tech spec sections for implementation details
|
||||
|
||||
**Story Point Estimation:**
|
||||
|
||||
- 1 point = < 1 day (2-4 hours)
|
||||
- 2 points = 1-2 days
|
||||
- 3 points = 2-3 days
|
||||
- 5 points = 3-5 days
|
||||
|
||||
**Level 1 Typical Totals:**
|
||||
|
||||
- Total story points: 5-10 points
|
||||
- 2 stories: 3-5 points each
|
||||
- 3 stories: 2-3 points each
|
||||
- If total > 15 points, consider if this should be Level 2
|
||||
|
||||
**Story Structure (MUST match create-story format):**
|
||||
|
||||
- Status: Draft
|
||||
- Story: As a [role], I want [capability], so that [benefit]
|
||||
- Acceptance Criteria: Numbered list from tech spec
|
||||
- Tasks / Subtasks: Checkboxes mapped to tech spec tasks (AC: #n references)
|
||||
- Dev Notes: Technical summary, project structure notes, references
|
||||
- Dev Agent Record: Empty sections for context workflow to populate
|
||||
</guidelines>
|
||||
|
||||
<for-each story="1 to story_count">
|
||||
<action>Set story_path_{n} = "{dev_story_location}/story-{epic_slug}-{n}.md"</action>
|
||||
<action>Create story file from user_story_template with the following content:</action>
|
||||
|
||||
<template-output file="{story_path_{n}}">
|
||||
- story_title: User-focused deliverable title
|
||||
- role: User role (e.g., developer, user, admin)
|
||||
- capability: What they want to do
|
||||
- benefit: Why it matters
|
||||
- acceptance_criteria: Specific, measurable criteria from tech spec
|
||||
- tasks_subtasks: Implementation tasks with AC references
|
||||
- technical_summary: High-level approach, key decisions
|
||||
- files_to_modify: List of files that will change
|
||||
- test_locations: Where tests will be added
|
||||
- story_points: Estimated effort (1/2/3/5)
|
||||
- time_estimate: Days/hours estimate
|
||||
- architecture_references: Links to tech-spec.md sections
|
||||
</template-output>
|
||||
</for-each>
|
||||
|
||||
<critical>Generate exactly {story_count} story files (2 or 3 based on Step 3 decision)</critical>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Create story map and implementation sequence">
|
||||
|
||||
<action>Generate visual story map showing epic → stories hierarchy</action>
|
||||
<action>Calculate total story points across all stories</action>
|
||||
<action>Estimate timeline based on total points (1-2 points per day typical)</action>
|
||||
<action>Define implementation sequence considering dependencies</action>
|
||||
|
||||
<example>
|
||||
## Story Map
|
||||
|
||||
```
|
||||
Epic: Icon Reliability
|
||||
├── Story 1: Build Icon Infrastructure (3 points)
|
||||
└── Story 2: Test and Deploy Icons (2 points)
|
||||
```
|
||||
|
||||
**Total Story Points:** 5
|
||||
**Estimated Timeline:** 1 sprint (1 week)
|
||||
|
||||
## Implementation Sequence
|
||||
|
||||
1. **Story 1** → Build icon infrastructure (setup, download, configure)
|
||||
2. **Story 2** → Test and deploy (depends on Story 1)
|
||||
</example>
|
||||
|
||||
<template-output file="{output_folder}/epics.md">story_summaries</template-output>
|
||||
<template-output file="{output_folder}/epics.md">story_map</template-output>
|
||||
<template-output file="{output_folder}/epics.md">total_points</template-output>
|
||||
<template-output file="{output_folder}/epics.md">estimated_timeline</template-output>
|
||||
<template-output file="{output_folder}/epics.md">implementation_sequence</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Update status and populate story backlog">
|
||||
|
||||
<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
|
||||
<param>mode: update</param>
|
||||
<param>action: complete_workflow</param>
|
||||
<param>workflow_name: tech-spec</param>
|
||||
<param>populate_stories_from: {epics_output_file}</param>
|
||||
</invoke-workflow>
|
||||
|
||||
<check if="success == true">
|
||||
<output>✅ Status updated! Loaded {{total_stories}} stories from epics.</output>
|
||||
<output>Next: {{next_workflow}} ({{next_agent}} agent)</output>
|
||||
</check>
|
||||
|
||||
<check if="success == false">
|
||||
<output>⚠️ Status update failed: {{error}}</output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Finalize and provide user guidance">
|
||||
|
||||
<action>Confirm all stories map to tech spec implementation tasks</action>
|
||||
<action>Verify total story points align with tech spec time estimates</action>
|
||||
<action>Verify stories are properly sequenced with dependencies noted</action>
|
||||
<action>Confirm all stories have measurable acceptance criteria</action>
|
||||
|
||||
**Level 1 Planning Complete!**
|
||||
|
||||
**Epic:** {{epic_title}}
|
||||
**Total Stories:** {{story_count}}
|
||||
**Total Story Points:** {{total_points}}
|
||||
**Estimated Timeline:** {{estimated_timeline}}
|
||||
|
||||
**Generated Artifacts:**
|
||||
|
||||
- `tech-spec.md` → Technical source of truth
|
||||
- `epics.md` → Epic and story summary
|
||||
- `story-{epic_slug}-1.md` → First story (ready for implementation)
|
||||
- `story-{epic_slug}-2.md` → Second story
|
||||
{{#if story_3}}
|
||||
- `story-{epic_slug}-3.md` → Third story
|
||||
{{/if}}
|
||||
|
||||
**Story Location:** `{dev_story_location}/`
|
||||
|
||||
**Next Steps - Iterative Implementation:**
|
||||
|
||||
**1. Start with Story 1:**
|
||||
a. Load SM agent: `{project-root}/bmad/bmm/agents/sm.md`
|
||||
b. Run story-context workflow (select story-{epic_slug}-1.md)
|
||||
c. Load DEV agent: `{project-root}/bmad/bmm/agents/dev.md`
|
||||
d. Run dev-story workflow to implement story 1
|
||||
|
||||
**2. After Story 1 Complete:**
|
||||
|
||||
- Repeat process for story-{epic_slug}-2.md
|
||||
- Story context will auto-reference completed story 1
|
||||
|
||||
**3. After Story 2 Complete:**
|
||||
{{#if story_3}}
|
||||
|
||||
- Repeat process for story-{epic_slug}-3.md
|
||||
{{/if}}
|
||||
- Level 1 feature complete!
|
||||
|
||||
**Progress Tracking:**
|
||||
|
||||
- All decisions logged in: `bmm-workflow-status.md`
|
||||
- Next action clearly identified
|
||||
|
||||
<ask>Ready to proceed? Choose your path:
|
||||
|
||||
1. Generate context for story 1 (recommended - run story-context)
|
||||
2. Go directly to dev-story for story 1 (faster)
|
||||
3. Exit for now
|
||||
|
||||
Select option (1-3):</ask>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
253
bmad/bmm/workflows/2-plan-workflows/tech-spec/instructions.md
Normal file
253
bmad/bmm/workflows/2-plan-workflows/tech-spec/instructions.md
Normal file
@@ -0,0 +1,253 @@
|
||||
# PRD Workflow - Small Projects (Level 0-1)
|
||||
|
||||
<workflow>
|
||||
|
||||
<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>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>This is the SMALL instruction set for Level 0-1 projects - tech-spec with story generation</critical>
|
||||
<critical>Level 0: tech-spec + single user story | Level 1: tech-spec + epic/stories</critical>
|
||||
<critical>Project analysis already completed - proceeding directly to technical specification</critical>
|
||||
<critical>NO PRD generated - uses tech_spec_template + story templates</critical>
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Technical, precise, definitive. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Tech-spec workflow can run standalone or as part of BMM workflow path.</output>
|
||||
<output>**Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing.</output>
|
||||
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
||||
<check if="continue">
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
<check if="exit">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "tech-spec" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_level >= 2">
|
||||
<output>**Incorrect Workflow for Level {{project_level}}**
|
||||
|
||||
Tech-spec is for Level 0-1 projects. Level 2-4 should use PRD workflow.
|
||||
|
||||
**Correct workflow:** `prd` (PM agent)
|
||||
</output>
|
||||
<action>Exit and redirect to prd</action>
|
||||
</check>
|
||||
|
||||
<check if="tech-spec status is file path (already completed)">
|
||||
<output>⚠️ Tech-spec already completed: {{tech-spec status}}</output>
|
||||
<ask>Re-running will overwrite the existing tech-spec. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="tech-spec is not the next expected workflow">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Tech-spec is out of sequence.</output>
|
||||
<ask>Continue with tech-spec anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Confirm project scope and update tracking">
|
||||
|
||||
<action>Use {{project_level}} from status data</action>
|
||||
|
||||
<action>Update Workflow Status:</action>
|
||||
<template-output file="{{status_file_path}}">current_workflow</template-output>
|
||||
<check if="project_level == 0">
|
||||
<action>Set to: "tech-spec (Level 0 - generating tech spec)"</action>
|
||||
</check>
|
||||
<check if="project_level == 1">
|
||||
<action>Set to: "tech-spec (Level 1 - generating tech spec)"</action>
|
||||
</check>
|
||||
|
||||
<template-output file="{{status_file_path}}">progress_percentage</template-output>
|
||||
<action>Set to: 20%</action>
|
||||
|
||||
<action>Save {{status_file_path}}</action>
|
||||
|
||||
<check if="project_level == 0">
|
||||
<action>Confirm Level 0 - Single atomic change</action>
|
||||
<ask>Please describe the specific change/fix you need to implement:</ask>
|
||||
</check>
|
||||
|
||||
<check if="project_level == 1">
|
||||
<action>Confirm Level 1 - Coherent feature</action>
|
||||
<ask>Please describe the feature you need to implement:</ask>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Generate DEFINITIVE tech spec">
|
||||
|
||||
<critical>Generate tech-spec.md - this is the TECHNICAL SOURCE OF TRUTH</critical>
|
||||
<critical>ALL TECHNICAL DECISIONS MUST BE DEFINITIVE - NO AMBIGUITY ALLOWED</critical>
|
||||
|
||||
<action>Update progress:</action>
|
||||
<template-output file="{{status_file_path}}">progress_percentage</template-output>
|
||||
<action>Set to: 40%</action>
|
||||
<action>Save {{status_file_path}}</action>
|
||||
|
||||
<action>Initialize and write out tech-spec.md using tech_spec_template</action>
|
||||
|
||||
<critical>DEFINITIVE DECISIONS REQUIRED:</critical>
|
||||
|
||||
**BAD Examples (NEVER DO THIS):**
|
||||
|
||||
- "Python 2 or 3" ❌
|
||||
- "Use a logger like pino or winston" ❌
|
||||
|
||||
**GOOD Examples (ALWAYS DO THIS):**
|
||||
|
||||
- "Python 3.11" ✅
|
||||
- "winston v3.8.2 for logging" ✅
|
||||
|
||||
**Source Tree Structure**: EXACT file changes needed
|
||||
<template-output file="tech-spec.md">source_tree</template-output>
|
||||
|
||||
**Technical Approach**: SPECIFIC implementation for the change
|
||||
<template-output file="tech-spec.md">technical_approach</template-output>
|
||||
|
||||
**Implementation Stack**: DEFINITIVE tools and versions
|
||||
<template-output file="tech-spec.md">implementation_stack</template-output>
|
||||
|
||||
**Technical Details**: PRECISE change details
|
||||
<template-output file="tech-spec.md">technical_details</template-output>
|
||||
|
||||
**Testing Approach**: How to verify the change
|
||||
<template-output file="tech-spec.md">testing_approach</template-output>
|
||||
|
||||
**Deployment Strategy**: How to deploy the change
|
||||
<template-output file="tech-spec.md">deployment_strategy</template-output>
|
||||
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Validate cohesion" optional="true">
|
||||
|
||||
<action>Offer to run cohesion validation</action>
|
||||
|
||||
<ask>Tech-spec complete! Before proceeding to implementation, would you like to validate project cohesion?
|
||||
|
||||
**Cohesion Validation** checks:
|
||||
|
||||
- Tech spec completeness and definitiveness
|
||||
- Feature sequencing and dependencies
|
||||
- External dependencies properly planned
|
||||
- User/agent responsibilities clear
|
||||
- Greenfield/brownfield-specific considerations
|
||||
|
||||
Run cohesion validation? (y/n)</ask>
|
||||
|
||||
<check if="yes">
|
||||
<action>Load {installed_path}/checklist.md</action>
|
||||
<action>Review tech-spec.md against "Cohesion Validation (All Levels)" section</action>
|
||||
<action>Focus on Section A (Tech Spec), Section D (Feature Sequencing)</action>
|
||||
<action>Apply Section B (Greenfield) or Section C (Brownfield) based on field_type</action>
|
||||
<action>Generate validation report with findings</action>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Generate user stories based on project level">
|
||||
|
||||
<action>Use {{project_level}} from status data</action>
|
||||
|
||||
<check if="project_level == 0">
|
||||
<action>Invoke instructions-level0-story.md to generate single user story</action>
|
||||
<action>Story will be saved to user-story.md</action>
|
||||
<action>Story links to tech-spec.md for technical implementation details</action>
|
||||
</check>
|
||||
|
||||
<check if="project_level == 1">
|
||||
<action>Invoke instructions-level1-stories.md to generate epic and stories</action>
|
||||
<action>Epic and stories will be saved to epics.md
|
||||
<action>Stories link to tech-spec.md implementation tasks</action>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Finalize and determine next steps">
|
||||
|
||||
<action>Confirm tech-spec is complete and definitive</action>
|
||||
|
||||
<check if="project_level == 0">
|
||||
<action>Confirm user-story.md generated successfully</action>
|
||||
</check>
|
||||
|
||||
<check if="project_level == 1">
|
||||
<action>Confirm epics.md generated successfully</action>
|
||||
</check>
|
||||
|
||||
## Summary
|
||||
|
||||
<check if="project_level == 0">
|
||||
- **Level 0 Output**: tech-spec.md + user-story.md
|
||||
- **No PRD required**
|
||||
- **Direct to implementation with story tracking**
|
||||
</check>
|
||||
|
||||
<check if="project_level == 1">
|
||||
- **Level 1 Output**: tech-spec.md + epics.md
|
||||
- **No PRD required**
|
||||
- **Ready for sprint planning with epic/story breakdown**
|
||||
</check>
|
||||
|
||||
## Next Steps
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "tech-spec"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["tech-spec"] = "{output_folder}/bmm-tech-spec-{{date}}.md"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
</check>
|
||||
|
||||
<output>**✅ Tech-Spec Complete, {user_name}!**
|
||||
|
||||
**Deliverables Created:**
|
||||
|
||||
<check if="project_level == 0">
|
||||
- ✅ tech-spec.md - Technical specification
|
||||
- ✅ user-story.md - Single user story
|
||||
</check>
|
||||
|
||||
<check if="project_level == 1">
|
||||
- ✅ tech-spec.md - Technical specification
|
||||
- ✅ epics.md - Epic and story breakdown
|
||||
</check>
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
- **Next required:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- **Optional:** Create test plan or document UI changes if applicable
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
</output>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,55 @@
|
||||
# {{project_name}} - Technical Specification
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
**Project Level:** {{project_level}}
|
||||
**Project Type:** {{project_type}}
|
||||
**Development Context:** {{development_context}}
|
||||
|
||||
---
|
||||
|
||||
## Source Tree Structure
|
||||
|
||||
{{source_tree}}
|
||||
|
||||
---
|
||||
|
||||
## Technical Approach
|
||||
|
||||
{{technical_approach}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Stack
|
||||
|
||||
{{implementation_stack}}
|
||||
|
||||
---
|
||||
|
||||
## Technical Details
|
||||
|
||||
{{technical_details}}
|
||||
|
||||
---
|
||||
|
||||
## Development Setup
|
||||
|
||||
{{development_setup}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Guide
|
||||
|
||||
{{implementation_guide}}
|
||||
|
||||
---
|
||||
|
||||
## Testing Approach
|
||||
|
||||
{{testing_approach}}
|
||||
|
||||
---
|
||||
|
||||
## Deployment Strategy
|
||||
|
||||
{{deployment_strategy}}
|
||||
@@ -0,0 +1,56 @@
|
||||
# Story: {{story_title}}
|
||||
|
||||
Status: Draft
|
||||
|
||||
## Story
|
||||
|
||||
As a {{role}},
|
||||
I want {{capability}},
|
||||
so that {{benefit}}.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
{{acceptance_criteria}}
|
||||
|
||||
## Tasks / Subtasks
|
||||
|
||||
{{tasks_subtasks}}
|
||||
|
||||
## Dev Notes
|
||||
|
||||
### Technical Summary
|
||||
|
||||
{{technical_summary}}
|
||||
|
||||
### Project Structure Notes
|
||||
|
||||
- Files to modify: {{files_to_modify}}
|
||||
- Expected test locations: {{test_locations}}
|
||||
- Estimated effort: {{story_points}} story points ({{time_estimate}})
|
||||
|
||||
### References
|
||||
|
||||
- **Tech Spec:** See tech-spec.md for detailed implementation
|
||||
- **Architecture:** {{architecture_references}}
|
||||
|
||||
## Dev Agent Record
|
||||
|
||||
### Context Reference
|
||||
|
||||
<!-- Path(s) to story context XML will be added here by context workflow -->
|
||||
|
||||
### Agent Model Used
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
### Debug Log References
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
### Completion Notes List
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
### File List
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
39
bmad/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml
Normal file
39
bmad/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml
Normal file
@@ -0,0 +1,39 @@
|
||||
# Technical Specification Workflow (Level 0)
|
||||
name: tech-spec-sm
|
||||
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"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/bmad/bmm/config.yaml"
|
||||
project_name: "{config_source}:project_name"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/tech-spec"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
template: "{installed_path}/tech-spec-template.md"
|
||||
|
||||
# Story generation instructions (invoked based on level)
|
||||
instructions_level0_story: "{installed_path}/instructions-level0-story.md"
|
||||
instructions_level1_stories: "{installed_path}/instructions-level1-stories.md"
|
||||
|
||||
# Templates
|
||||
user_story_template: "{installed_path}/user-story-template.md"
|
||||
epics_template: "{installed_path}/epics-template.md"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/tech-spec.md"
|
||||
user_story_file: "{output_folder}/user-story.md"
|
||||
epics_file: "{output_folder}/epics.md"
|
||||
|
||||
# Recommended input documents (optional for Level 0)
|
||||
recommended_inputs:
|
||||
- bug_report: "Bug description or issue ticket"
|
||||
- feature_request: "Brief feature description"
|
||||
|
||||
standalone: true
|
||||
Reference in New Issue
Block a user