npm - bmad-method - Versions diffs - 6.0.0-alpha.2 → 6.0.0-alpha.20 - Mend

bmad-method 6.0.0-alpha.2 → 6.0.0-alpha.20

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1280) hide show

package/src/modules/bmm/workflows/2-plan-workflows/README.md DELETED Viewed

@@ -1,258 +0,0 @@
----
-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_

package/src/modules/bmm/workflows/2-plan-workflows/create-ux-design/checklist.md DELETED Viewed

@@ -1,310 +0,0 @@
-# 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._