bmad-method 6.0.0-alpha.5 → 6.0.0-alpha.7

package/bmad/bmm/workflows/2-plan-workflows/prd/workflow.yaml

@@ -1,46 +0,0 @@
-# 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"
-
-# Output files
-status_file: "{output_folder}/bmm-workflow-status.yaml"
-default_output_file: "{output_folder}/PRD.md"
-
-# Recommended input documents
-recommended_inputs:
-  - product_brief: "{output_folder}/product-brief.md"
-  - market_research: "{output_folder}/market-research.md"
-
-# Smart input file references - handles both whole docs and sharded docs
-# Priority: Whole document first, then sharded version
-input_file_patterns:
-  product_brief:
-    whole: "{output_folder}/*brief*.md"
-    sharded: "{output_folder}/*brief*/index.md"
-
-  research:
-    whole: "{output_folder}/*research*.md"
-    sharded: "{output_folder}/*research*/index.md"
-
-  document_project:
-    sharded: "{output_folder}/docs/index.md"
-
-standalone: true

package/bmad/bmm/workflows/2-plan-workflows/tech-spec/checklist.md

@@ -1,214 +0,0 @@
-# Tech-Spec Workflow Validation Checklist
-
-**Purpose**: Validate tech-spec workflow outputs are context-rich, 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)
-
-**New Standard**: Tech-spec should be comprehensive enough to replace story-context for Level 0-1 projects
-
----
-
-## 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.yaml updated (if not standalone mode)
-- [ ] No unfilled {{template_variables}} in any files
-
----
-
-## 2. Context Gathering (NEW - CRITICAL)
-
-### Document Discovery
-
-- [ ] **Existing documents loaded**: Product brief, research docs found and incorporated (if they exist)
-- [ ] **Document-project output**: Checked for {output_folder}/docs/index.md (brownfield codebase map)
-- [ ] **Sharded documents**: If sharded versions found, ALL sections loaded and synthesized
-- [ ] **Context summary**: loaded_documents_summary lists all sources used
-
-### Project Stack Detection
-
-- [ ] **Setup files identified**: package.json, requirements.txt, or equivalent found and parsed
-- [ ] **Framework detected**: Exact framework name and version captured (e.g., "Express 4.18.2")
-- [ ] **Dependencies extracted**: All production dependencies with specific versions
-- [ ] **Dev tools identified**: TypeScript, Jest, ESLint, pytest, etc. with versions
-- [ ] **Scripts documented**: Available npm/pip/etc scripts identified
-- [ ] **Stack summary**: project_stack_summary is complete and accurate
-
-### Brownfield Analysis (if applicable)
-
-- [ ] **Directory structure**: Main code directories identified and documented
-- [ ] **Code patterns**: Dominant patterns identified (class-based, functional, MVC, etc.)
-- [ ] **Naming conventions**: Existing conventions documented (camelCase, snake_case, etc.)
-- [ ] **Key modules**: Important existing modules/services identified
-- [ ] **Testing patterns**: Test framework and patterns documented
-- [ ] **Structure summary**: existing_structure_summary is comprehensive
-
----
-
-## 3. 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 (from package.json)"
-  - ❌ BAD: "Python 2 or 3", "React 18+", "a logger like pino or winston"
-- [ ] **Definitive decisions**: Every technical choice is final, not a proposal
-- [ ] **Stack-aligned**: Decisions reference detected project stack
-
-### Implementation Clarity
-
-- [ ] **Source tree changes**: EXACT file paths with CREATE/MODIFY/DELETE actions
-  - ✅ GOOD: "src/services/UserService.ts - MODIFY - Add validateEmail() method"
-  - ❌ BAD: "Update some files in the services folder"
-- [ ] **Technical approach**: Describes SPECIFIC implementation using detected stack
-- [ ] **Existing patterns**: Documents brownfield patterns to follow (if applicable)
-- [ ] **Integration points**: Specific modules, APIs, services identified
-
----
-
-## 4. Context-Rich Content (NEW)
-
-### Context Section
-
-- [ ] **Available Documents**: Lists all loaded documents
-- [ ] **Project Stack**: Complete framework and dependency information
-- [ ] **Existing Codebase Structure**: Brownfield analysis or greenfield notation
-
-### The Change Section
-
-- [ ] **Problem Statement**: Clear, specific problem definition
-- [ ] **Proposed Solution**: Concrete solution approach
-- [ ] **Scope In/Out**: Clear boundaries defined
-
-### Development Context Section
-
-- [ ] **Relevant Existing Code**: References to specific files and line numbers (brownfield)
-- [ ] **Framework Dependencies**: Complete list with exact versions from project
-- [ ] **Internal Dependencies**: Internal modules listed
-- [ ] **Configuration Changes**: Specific config file updates identified
-
-### Developer Resources Section
-
-- [ ] **File Paths Reference**: Complete list of all files involved
-- [ ] **Key Code Locations**: Functions, classes, modules with file:line references
-- [ ] **Testing Locations**: Specific test directories and patterns
-- [ ] **Documentation Updates**: Docs that need updating identified
-
----
-
-## 5. 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 to tech-spec.md
-
-### Story Context Integration (NEW)
-
-- [ ] **Tech-Spec Reference**: Story explicitly references tech-spec.md as primary context
-- [ ] **Dev Agent Record**: Includes all required sections (Context Reference, Agent Model, etc.)
-- [ ] **Test Results section**: Placeholder ready for dev execution
-- [ ] **Review Notes section**: Placeholder ready for code review
-
-### 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
-- [ ] Story tasks map to tech-spec implementation guide
-- [ ] Files in stories match tech-spec source tree
-- [ ] Key code references align with tech-spec Developer Resources
-
----
-
-## 6. Epic Quality (Level 1 Only)
-
-- [ ] **Epic title**: User-focused outcome (not implementation detail)
-- [ ] **Epic slug**: Clean kebab-case slug (2-3 words)
-- [ ] **Epic goal**: Clear purpose and value statement
-- [ ] **Epic scope**: Boundaries clearly defined
-- [ ] **Success criteria**: Measurable outcomes
-- [ ] **Story map**: Visual representation of epic → stories
-- [ ] **Implementation sequence**: Logical story ordering with dependencies
-- [ ] **Tech-spec reference**: Links back to tech-spec.md
-
----
-
-## 7. Workflow Status Integration
-
-- [ ] bmm-workflow-status.yaml updated (if exists)
-- [ ] Current phase reflects tech-spec completion
-- [ ] Progress percentage updated appropriately
-- [ ] Next workflow clearly identified
-
----
-
-## 8. Implementation Readiness (NEW - ENHANCED)
-
-### Can Developer Start Immediately?
-
-- [ ] **All context available**: Brownfield analysis + stack details + existing patterns
-- [ ] **No research needed**: Developer doesn't need to hunt for framework versions or patterns
-- [ ] **Specific file paths**: Developer knows exactly which files to create/modify
-- [ ] **Code references**: Can find similar code to reference (brownfield)
-- [ ] **Testing clear**: Knows what to test and how
-- [ ] **Deployment documented**: Knows how to deploy and rollback
-
-### Tech-Spec Replaces Story-Context?
-
-- [ ] **Comprehensive enough**: Contains all info typically in story-context XML
-- [ ] **Brownfield analysis**: If applicable, includes codebase reconnaissance
-- [ ] **Framework specifics**: Exact versions and usage patterns
-- [ ] **Pattern guidance**: Shows examples of existing patterns to follow
-
----
-
-## 9. Critical Failures (Auto-Fail)
-
-- [ ] ❌ **Non-definitive technical decisions** (any "option A or B" or vague choices)
-- [ ] ❌ **Missing versions** (framework/library without specific version)
-- [ ] ❌ **Context not gathered** (didn't check for document-project, setup files, etc.)
-- [ ] ❌ **Stack mismatch** (decisions don't align with detected project stack)
-- [ ] ❌ **Stories don't match template** (missing Dev Agent Record sections)
-- [ ] ❌ **Missing tech-spec sections** (required section missing from enhanced template)
-- [ ] ❌ **Stories have forward dependencies** (would break sequential implementation)
-- [ ] ❌ **Vague source tree** (file changes not specific with actions)
-- [ ] ❌ **No brownfield analysis** (when document-project output exists but wasn't used)
-
----
-
-## Validation Notes
-
-**Document any findings:**
-
-- **Context Gathering Score**: [Comprehensive / Partial / Insufficient]
-- **Definitiveness Score**: [All definitive / Some ambiguity / Significant ambiguity]
-- **Brownfield Integration**: [N/A - Greenfield / Excellent / Partial / Missing]
-- **Stack Alignment**: [Perfect / Good / Partial / None]
-
-## **Strengths:**
-
-## **Issues to address:**
-
-## **Recommended actions:**
-
-**Ready for implementation?** [Yes / No - explain]
-
-**Can skip story-context?** [Yes - tech-spec is comprehensive / No - additional context needed / N/A]
-
----
-
-_The tech-spec should be a RICH CONTEXT DOCUMENT that gives developers everything they need without requiring separate context generation._

package/bmad/bmm/workflows/2-plan-workflows/tech-spec/epics-template.md

@@ -1,58 +0,0 @@
-# {{project_name}} - Epic Breakdown
-
-**Date:** {{date}}
-**Project Level:** {{project_level}}
-
----
-
-## Epic: {{epic_title}}
-
-**Slug:** {{epic_slug}}
-
-### Goal
-
-{{epic_goal}}
-
-### Scope
-
-{{epic_scope}}
-
-### Success Criteria
-
-{{epic_success_criteria}}
-
-### Dependencies
-
-{{epic_dependencies}}
-
----
-
-## Story Map
-
-{{story_map}}
-
----
-
-## Story Summaries
-
-{{story_summaries}}
-
----
-
-## Implementation Timeline
-
-**Total Story Points:** {{total_points}}
-
-**Estimated Timeline:** {{estimated_timeline}}
-
----
-
-## Implementation Sequence
-
-{{implementation_sequence}}
-
----
-
-## Tech-Spec Reference
-
-See [tech-spec.md](../tech-spec.md) for complete technical implementation details.

package/bmad/bmm/workflows/2-plan-workflows/tech-spec/instructions-level0-story.md

@@ -1,200 +0,0 @@
-# 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.yaml from {output_folder}/bmm-workflow-status.yaml (if exists)</action>
-<action>Extract dev_story_location from config (where stories are stored)</action>
-
-<action>Extract from the ENHANCED tech-spec structure:
-
-- Problem statement from "The Change → Problem Statement" section
-- Solution overview from "The Change → Proposed Solution" section
-- Scope from "The Change → Scope" section
-- Source tree from "Implementation Details → Source Tree Changes" section
-- Time estimate from "Implementation Guide → Implementation Steps" section
-- Acceptance criteria from "Implementation Guide → Acceptance Criteria" section
-- Framework dependencies from "Development Context → Framework/Libraries" section
-- Existing code references from "Development Context → Relevant Existing Code" section
-- File paths from "Developer Resources → File Paths Reference" section
-- Key code locations from "Developer Resources → Key Code Locations" section
-- Testing locations from "Developer Resources → Testing Locations" 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 "Developer Resources → File Paths Reference"
-- Include existing code references from "Development Context → Relevant Existing Code"
-- Reference architecture patterns if applicable
-- Cite tech-spec sections for implementation details
-- Note dependencies (internal and external)
-
-**NEW: Comprehensive Context**
-
-Since tech-spec is now context-rich, populate all new template fields:
-
-- dependencies: Extract from "Development Context" and "Implementation Details → Integration Points"
-- existing_code_references: Extract from "Development Context → Relevant Existing Code" and "Developer Resources → Key Code Locations"
-  </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}">dependencies</template-output>
-<template-output file="{story_path}">existing_code_references</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:**
-
-**🎯 RECOMMENDED - Direct to Development (Level 0):**
-
-Since the tech-spec is now CONTEXT-RICH with:
-
-- ✅ Brownfield codebase analysis (if applicable)
-- ✅ Framework and library details with exact versions
-- ✅ Existing patterns and code references
-- ✅ Complete file paths and integration points
-
-**You can skip story-context and go straight to dev!**
-
-1. Load DEV agent: `{project-root}/bmad/bmm/agents/dev.md`
-2. Run `dev-story` workflow
-3. Begin implementation immediately
-
-**Option B - Generate Additional Context (optional):**
-
-Only needed for extremely complex scenarios:
-
-1. Load SM agent: `{project-root}/bmad/bmm/agents/sm.md`
-2. Run `story-context` workflow (generates additional XML context)
-3. Then load DEV agent and run `dev-story` workflow
-
-**Progress Tracking:**
-
-- All decisions logged in: `bmm-workflow-status.yaml`
-- Next action clearly identified
-
-<ask>Ready to proceed? Choose your path:
-
-1. Go directly to dev-story (RECOMMENDED - tech-spec has all context)
-2. Generate additional story context (for complex edge cases)
-3. Exit for now
-
-Select option (1-3):</ask>
-
-</step>
-
-</workflow>