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

package/src/modules/bmm/workflows/4-implementation/epic-tech-context/checklist.md

@@ -1,17 +0,0 @@
-# Tech Spec Validation Checklist
-
-```xml
-<checklist id="bmad/bmm/workflows/4-implementation/epic-tech-context/checklist">
-  <item>Overview clearly ties to PRD goals</item>
-  <item>Scope explicitly lists in-scope and out-of-scope</item>
-  <item>Design lists all services/modules with responsibilities</item>
-  <item>Data models include entities, fields, and relationships</item>
-  <item>APIs/interfaces are specified with methods and schemas</item>
-  <item>NFRs: performance, security, reliability, observability addressed</item>
-  <item>Dependencies/integrations enumerated with versions where known</item>
-  <item>Acceptance criteria are atomic and testable</item>
-  <item>Traceability maps AC → Spec → Components → Tests</item>
-  <item>Risks/assumptions/questions listed with mitigation/next steps</item>
-  <item>Test strategy covers all ACs and critical paths</item>
-</checklist>
-```

package/src/modules/bmm/workflows/4-implementation/epic-tech-context/instructions.md

@@ -1,160 +0,0 @@
-<!-- BMAD BMM Tech Spec Workflow Instructions (v6) -->
-
-```xml
-<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}</critical>
-<critical>This workflow generates a comprehensive Technical Specification from PRD and Architecture, including detailed design, NFRs, acceptance criteria, and traceability mapping.</critical>
-<critical>If required inputs cannot be auto-discovered HALT with a clear message listing missing documents, allow user to provide them to proceed.</critical>
-
-<workflow>
-  <step n="1" goal="Collect inputs and discover next epic" tag="sprint-status">
-    <action>Identify PRD and Architecture documents from recommended_inputs. Attempt to auto-discover at default paths.</action>
-    <ask if="inputs are missing">ask the user for file paths. HALT and wait for docs to proceed</ask>
-
-    <!-- Intelligent Epic Discovery -->
-    <critical>MUST read COMPLETE sprint-status.yaml file to discover next epic</critical>
-    <action>Load the FULL file: {{output_folder}}/sprint-status.yaml</action>
-    <action>Read ALL development_status entries</action>
-    <action>Find all epics with status "backlog" (not yet contexted)</action>
-    <action>Identify the FIRST backlog epic as the suggested default</action>
-
-    <check if="backlog epics found">
-      <output>📋 **Next Epic Suggested:** Epic {{suggested_epic_id}}: {{suggested_epic_title}}</output>
-      <ask>Use this epic?
-- [y] Yes, use {{suggested_epic_id}}
-- [n] No, let me specify a different epic_id
-      </ask>
-
-      <check if="user selects 'n'">
-        <ask>Enter the epic_id you want to context</ask>
-        <action>Store user-provided epic_id as {{epic_id}}</action>
-      </check>
-
-      <check if="user selects 'y'">
-        <action>Use {{suggested_epic_id}} as {{epic_id}}</action>
-      </check>
-    </check>
-
-    <check if="no backlog epics found">
-      <output>✅ All epics are already contexted!
-
-No epics with status "backlog" found in sprint-status.yaml.
-      </output>
-      <ask>Do you want to re-context an existing epic? Enter epic_id or [q] to quit:</ask>
-
-      <check if="user enters epic_id">
-        <action>Store as {{epic_id}}</action>
-      </check>
-
-      <check if="user enters 'q'">
-        <action>HALT - No work needed</action>
-      </check>
-    </check>
-
-    <action>Extract {{epic_title}} from PRD based on {{epic_id}}.</action>
-    <action>Resolve output file path using workflow variables and initialize by writing the template.</action>
-  </step>
-
-  <step n="2" goal="Validate epic exists in sprint status" tag="sprint-status">
-    <action>Look for epic key "epic-{{epic_id}}" in development_status (already loaded from step 1)</action>
-    <action>Get current status value if epic exists</action>
-
-    <check if="epic not found">
-      <output>⚠️ Epic {{epic_id}} not found in sprint-status.yaml
-
-This epic hasn't been registered in the sprint plan yet.
-Run sprint-planning workflow to initialize epic tracking.
-      </output>
-      <action>HALT</action>
-    </check>
-
-    <check if="epic status == 'contexted'">
-      <output>ℹ️ Epic {{epic_id}} already marked as contexted
-
-Continuing to regenerate tech spec...
-      </output>
-    </check>
-  </step>
-
-  <step n="3" goal="Overview and scope">
-    <action>Read COMPLETE found {recommended_inputs}.</action>
-    <template-output file="{default_output_file}">
-      Replace {{overview}} with a concise 1-2 paragraph summary referencing PRD context and goals
-      Replace {{objectives_scope}} with explicit in-scope and out-of-scope bullets
-      Replace {{system_arch_alignment}} with a short alignment summary to the architecture (components referenced, constraints)
-    </template-output>
-  </step>
-
-  <step n="4" goal="Detailed design">
-    <action>Derive concrete implementation specifics from all {recommended_inputs} (CRITICAL: NO invention). If a epic tech spec precedes this one and exists, maintain consistency where appropriate.</action>
-    <template-output file="{default_output_file}">
-      Replace {{services_modules}} with a table or bullets listing services/modules with responsibilities, inputs/outputs, and owners
-      Replace {{data_models}} with normalized data model definitions (entities, fields, types, relationships); include schema snippets where available
-      Replace {{apis_interfaces}} with API endpoint specs or interface signatures (method, path, request/response models, error codes)
-      Replace {{workflows_sequencing}} with sequence notes or diagrams-as-text (steps, actors, data flow)
-    </template-output>
-  </step>
-
-  <step n="5" goal="Non-functional requirements">
-    <template-output file="{default_output_file}">
-      Replace {{nfr_performance}} with measurable targets (latency, throughput); link to any performance requirements in PRD/Architecture
-      Replace {{nfr_security}} with authn/z requirements, data handling, threat notes; cite source sections
-      Replace {{nfr_reliability}} with availability, recovery, and degradation behavior
-      Replace {{nfr_observability}} with logging, metrics, tracing requirements; name required signals
-    </template-output>
-  </step>
-
-  <step n="6" goal="Dependencies and integrations">
-    <action>Scan repository for dependency manifests (e.g., package.json, pyproject.toml, go.mod, Unity Packages/manifest.json).</action>
-    <template-output file="{default_output_file}">
-      Replace {{dependencies_integrations}} with a structured list of dependencies and integration points with version or commit constraints when known
-    </template-output>
-  </step>
-
-  <step n="7" goal="Acceptance criteria and traceability">
-    <action>Extract acceptance criteria from PRD; normalize into atomic, testable statements.</action>
-    <template-output file="{default_output_file}">
-      Replace {{acceptance_criteria}} with a numbered list of testable acceptance criteria
-      Replace {{traceability_mapping}} with a table mapping: AC → Spec Section(s) → Component(s)/API(s) → Test Idea
-    </template-output>
-  </step>
-
-  <step n="8" goal="Risks and test strategy">
-    <template-output file="{default_output_file}">
-      Replace {{risks_assumptions_questions}} with explicit list (each item labeled as Risk/Assumption/Question) with mitigation or next step
-      Replace {{test_strategy}} with a brief plan (test levels, frameworks, coverage of ACs, edge cases)
-    </template-output>
-  </step>
-
-  <step n="9" goal="Validate and mark epic contexted" tag="sprint-status">
-    <invoke-task>Validate against checklist at {installed_path}/checklist.md using bmad/core/tasks/validate-workflow.xml</invoke-task>
-
-    <!-- Mark epic as contexted -->
-    <action>Load the FULL file: {{output_folder}}/sprint-status.yaml</action>
-    <action>Find development_status key "epic-{{epic_id}}"</action>
-    <action>Verify current status is "backlog" (expected previous state)</action>
-    <action>Update development_status["epic-{{epic_id}}"] = "contexted"</action>
-    <action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
-
-    <check if="epic key not found in file">
-      <output>⚠️ Could not update epic status: epic-{{epic_id}} not found</output>
-    </check>
-
-    <output>**✅ Tech Spec Generated Successfully, {user_name}!**
-
-**Epic Details:**
-- Epic ID: {{epic_id}}
-- Epic Title: {{epic_title}}
-- Tech Spec File: {{default_output_file}}
-- Epic Status: contexted (was backlog)
-
-**Note:** This is a JIT (Just-In-Time) workflow - run again for other epics as needed.
-
-**Next Steps:**
-1. Load SM agent and run `create-story` to begin implementing the first story under this epic.
-    </output>
-  </step>
-
-</workflow>
-```

package/src/modules/bmm/workflows/4-implementation/epic-tech-context/template.md

@@ -1,76 +0,0 @@
-# Epic Technical Specification: {{epic_title}}
-
-Date: {{date}}
-Author: {{user_name}}
-Epic ID: {{epic_id}}
-Status: Draft
-
----
-
-## Overview
-
-{{overview}}
-
-## Objectives and Scope
-
-{{objectives_scope}}
-
-## System Architecture Alignment
-
-{{system_arch_alignment}}
-
-## Detailed Design
-
-### Services and Modules
-
-{{services_modules}}
-
-### Data Models and Contracts
-
-{{data_models}}
-
-### APIs and Interfaces
-
-{{apis_interfaces}}
-
-### Workflows and Sequencing
-
-{{workflows_sequencing}}
-
-## Non-Functional Requirements
-
-### Performance
-
-{{nfr_performance}}
-
-### Security
-
-{{nfr_security}}
-
-### Reliability/Availability
-
-{{nfr_reliability}}
-
-### Observability
-
-{{nfr_observability}}
-
-## Dependencies and Integrations
-
-{{dependencies_integrations}}
-
-## Acceptance Criteria (Authoritative)
-
-{{acceptance_criteria}}
-
-## Traceability Mapping
-
-{{traceability_mapping}}
-
-## Risks, Assumptions, Open Questions
-
-{{risks_assumptions_questions}}
-
-## Test Strategy Summary
-
-{{test_strategy}}

package/src/modules/bmm/workflows/4-implementation/epic-tech-context/workflow.yaml

@@ -1,34 +0,0 @@
-name: tech-spec
-description: "Generate a comprehensive Technical Specification from PRD and Architecture with acceptance criteria and traceability mapping"
-author: "BMAD BMM"
-
-# Critical variables
-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"
-date: system-generated
-
-# Inputs expected ( check output_folder or ask user if missing)
-recommended_inputs:
-  - prd
-  - gdd
-  - spec
-  - architecture
-  - ux_spec
-  - ux-design
-  - if there is an index.md then read the index.md to find other related docs that could be relevant
-  - prior epic tech-specs for model, style and consistency reference
-
-# Workflow components
-installed_path: "{project-root}/bmad/bmm/workflows/4-implementation/epic-tech-context"
-template: "{installed_path}/template.md"
-instructions: "{installed_path}/instructions.md"
-validation: "{installed_path}/checklist.md"
-
-# Output configuration
-default_output_file: "{output_folder}/tech-spec-epic-{{epic_id}}.md"
-
-standalone: true
-
-web_bundle: false

package/src/modules/bmm/workflows/4-implementation/retrospective/README.md

@@ -1,77 +0,0 @@
----
-last-redoc-date: 2025-10-01
----
-
-# Retrospective Workflow
-
-The retrospective workflow is v6's learning capture mechanism, run by the Scrum Master (SM) after epic completion to systematically harvest insights, patterns, and improvements discovered during implementation. Unlike traditional retrospectives that focus primarily on process and team dynamics, this workflow performs deep technical and methodological analysis of the entire epic journey—from story creation through implementation to review—identifying what worked well, what could improve, and what patterns emerged. The retrospective produces actionable intelligence that informs future epics, improves workflow templates, and evolves the team's shared knowledge.
-
-This workflow represents a critical feedback loop in the v6 methodology. Each epic is an experiment in adaptive software development, and the retrospective is where we analyze the results of that experiment. The SM examines completed stories, review feedback, course corrections made, story-context effectiveness, technical decisions, and team collaboration patterns to extract transferable learning. This learning manifests as updates to workflow templates, new story-context patterns, refined estimation approaches, and documented best practices.
-
-The retrospective is not just a compliance ritual but a genuine opportunity for continuous improvement. By systematically analyzing what happened during the epic, the team builds institutional knowledge that makes each subsequent epic smoother, faster, and higher quality. The insights captured here directly improve future story creation, context generation, development efficiency, and review effectiveness.
-
-## Usage
-
-```bash
-# Conduct retrospective after epic completion
-bmad run retrospective
-```
-
-The SM should run this workflow:
-
-- After all stories in an epic are completed
-- Before starting the next major epic
-- When significant learning has accumulated
-- As preparation for improving future epic execution
-
-## Inputs
-
-**Required Context:**
-
-- **Epic Document**: Complete epic specification and goals
-- **All Story Documents**: Every story created for the epic
-- **Review Reports**: All review feedback and findings
-- **Course Corrections**: Any correct-course actions taken
-- **Story Contexts**: Generated expert guidance for each story
-- **Implementation Artifacts**: Code commits, test results, deployment records
-
-**Analysis Targets:**
-
-- Story creation accuracy and sizing
-- Story-context effectiveness and relevance
-- Implementation challenges and solutions
-- Review findings and patterns
-- Technical decisions and outcomes
-- Estimation accuracy
-- Team collaboration and communication
-- Workflow effectiveness
-
-## Outputs
-
-**Primary Deliverable:**
-
-- **Retrospective Report** (`[epic-id]-retrospective.xml`): Comprehensive analysis including:
-  - Executive summary of epic outcomes
-  - Story-by-story analysis of what was learned
-  - Technical insights and architecture learnings
-  - Story-context effectiveness assessment
-  - Process improvements identified
-  - Patterns discovered (good and bad)
-  - Recommendations for future epics
-  - Metrics and statistics (velocity, cycle time, etc.)
-
-**Actionable Outputs:**
-
-- **Template Updates**: Improvements to workflow templates based on learning
-- **Pattern Library**: New story-context patterns for common scenarios
-- **Best Practices**: Documented approaches that worked well
-- **Gotchas**: Issues to avoid in future work
-- **Estimation Refinements**: Better story sizing guidance
-- **Process Changes**: Workflow adjustments for next epic
-
-**Artifacts:**
-
-- Epic marked as complete with retrospective attached
-- Knowledge base updated with new patterns
-- Workflow templates updated if needed
-- Team learning captured for onboarding

package/src/modules/bmm/workflows/4-implementation/sprint-planning/README.md

@@ -1,156 +0,0 @@
-# Sprint Planning Workflow
-
-## Overview
-
-The sprint-planning workflow generates and manages the sprint status tracking file that serves as the single source of truth for Phase 4 implementation. It extracts all epics and stories from epic files and tracks their progress through the development lifecycle.
-
-In Agile terminology, this workflow facilitates **Sprint Planning** or **Sprint 0 Kickoff** - the transition from planning/architecture into actual development execution.
-
-## Purpose
-
-This workflow creates a `sprint-status.yaml` file that:
-
-- Lists all epics, stories, and retrospectives in order
-- Tracks the current status of each item
-- Provides a clear view of what needs to be worked on next
-- Ensures only one story is in progress at a time
-- Maintains the development flow from backlog to done
-
-## When to Use
-
-Run this workflow:
-
-1. **Initially** - After Phase 3 (solutioning) is complete and epics are finalized
-2. **After epic context creation** - To update epic status to 'contexted'
-3. **Periodically** - To auto-detect newly created story files
-4. **For status checks** - To see overall project progress
-
-## Status State Machine
-
-### Epic Flow
-
-```
-backlog → contexted
-```
-
-### Story Flow
-
-```
-backlog → drafted → ready-for-dev → in-progress → review → done
-```
-
-### Retrospective Flow
-
-```
-optional ↔ completed
-```
-
-## Key Guidelines
-
-1. **Epic Context Recommended**: Epics should be `contexted` before their stories can be `drafted`
-2. **Flexible Parallelism**: Multiple stories can be `in-progress` based on team capacity
-3. **Sequential Default**: Stories within an epic are typically worked in order, but parallel work is supported
-4. **Review Flow**: Stories should go through `review` before `done`
-5. **Learning Transfer**: SM typically drafts next story after previous is `done`, incorporating learnings
-
-## File Locations
-
-### Input Files
-
-- **Epic Files**: `{output_folder}/epic*.md` or `{output_folder}/epics.md`
-- **Epic Context**: `{output_folder}/epic-{n}-context.md`
-- **Story Files**: `{story_dir}/{epic}-{story}-{title}.md`
-  - Example: `stories/1-1-user-authentication.md`
-- **Story Context**: `{story_dir}/{epic}-{story}-{title}-context.md`
-  - Example: `stories/1-1-user-authentication-context.md`
-
-### Output File
-
-- **Status File**: `{output_folder}/sprint-status.yaml`
-
-## Usage by Agents
-
-### SM (Scrum Master) Agent
-
-```yaml
-Tasks:
-  - Check sprint-status.yaml for stories in 'done' status
-  - Identify next 'backlog' story to draft
-  - Run create-story workflow
-  - Update status to 'drafted'
-  - Create story context
-  - Update status to 'ready-for-dev'
-```
-
-### Developer Agent
-
-```yaml
-Tasks:
-  - Find stories with 'ready-for-dev' status
-  - Update to 'in-progress' when starting
-  - Implement the story
-  - Update to 'review' when complete
-  - Address review feedback
-  - Update to 'done' after review
-```
-
-### Test Architect
-
-```yaml
-Tasks:
-  - Monitor stories entering 'review'
-  - Track epic progress
-  - Identify when retrospectives are needed
-```
-
-## Example Output
-
-```yaml
-# Sprint Status
-# Generated: 2025-01-20
-# Project: MyPlantFamily
-
-development_status:
-  epic-1: contexted
-  1-1-project-foundation: done
-  1-2-app-shell: done
-  1-3-user-authentication: in-progress
-  1-4-plant-data-model: ready-for-dev
-  1-5-add-plant-manual: drafted
-  1-6-photo-identification: backlog
-  epic-1-retrospective: optional
-
-  epic-2: contexted
-  2-1-personality-system: in-progress
-  2-2-chat-interface: drafted
-  2-3-llm-integration: backlog
-  2-4-reminder-system: backlog
-  epic-2-retrospective: optional
-```
-
-## Integration with BMM Workflow
-
-This workflow is part of Phase 4 (Implementation) and integrates with:
-
-1. **epic-tech-context** - Creates technical context for epics
-2. **create-story** - Drafts individual story files
-3. **story-context** - Adds implementation context to stories
-4. **dev-story** - Developer implements the story
-5. **code-review** - SM reviews implementation
-6. **retrospective** - Optional epic retrospective
-
-## Benefits
-
-- **Clear Visibility**: Everyone knows what's being worked on
-- **Flexible Capacity**: Supports both sequential and parallel work patterns
-- **Learning Transfer**: SM can incorporate learnings when drafting next story
-- **Progress Tracking**: Easy to see overall project status
-- **Automation Friendly**: Simple YAML format for agent updates
-
-## Tips
-
-1. **Initial Generation**: Run immediately after epics are finalized
-2. **Regular Updates**: Agents should update status as they work
-3. **Manual Override**: You can manually edit the file if needed
-4. **Backup First**: The workflow backs up existing status before regenerating
-5. **Validation**: The workflow validates legal status transitions