mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00:00
feat: Add documentation guides, simplify folder structure, and major workflow refactoring
Created two comprehensive guides for v6 features:
**docs/agent-customization-guide.md**
- Complete guide for customizing agent names, personas, memories, and behaviors
- Update-safe customization via bmad/_cfg/agents/ configuration files
- Real-world examples (TDD setup, multilingual agents, custom workflows)
- Troubleshooting and best practices
**docs/web-bundles-gemini-gpt-guide.md**
- Comprehensive guide for using BMad agents in Gemini Gems and Custom GPTs
- Critical setup rules with exact configuration text required
- Cost-saving strategy: web planning → local implementation (60-80% savings)
- Platform comparison (Gemini Gems strongly recommended over Custom GPTs)
- Complete workflow examples showing full planning-to-implementation cycle
- Team bundle guidance (Gemini 2.5 Pro+ only)
**README.md updates**
- Added prominent links in v6 Core Enhancements section
- Created new "Customization & Sharing" documentation category
- Web Bundles feature highlighted with direct guide link
**Unified output folder structure across all modules:**
**Before (confusing):**
- output_folder: Main docs
- game_design_docs: Separate design folder
- tech_docs: Separate technical folder
- dev_ephemeral_location: Separate ephemeral folder outside docs
**After (simplified):**
- output_folder: Single location for ALL AI-generated artifacts (default: "docs")
- Clearer prompt: "Where should AI Generated Artifacts be saved?"
- sprint_artifacts: Phase 4 ephemeral content now WITHIN output_folder
- BMM: {output_folder}/stories (stories, context, reports)
- BMGD: {output_folder}/sprint-artifacts
- No longer in separate {bmad_folder}-ephemeral location
**Benefits:**
- One clear location for all planning artifacts (PRD, Architecture, UX, etc.)
- Phase 4 ephemeral items logically grouped within output folder
- Eliminated confusing separate folder proliferation
- sprint_artifacts now configurable per module
**Files changed:**
- src/core/_module-installer/install-config.yaml
- src/modules/bmm/_module-installer/install-config.yaml
- src/modules/bmgd/_module-installer/install-config.yaml
**Also cleaned up BMGD config:**
- Renamed: specified_framework → primary_platform (clearer naming)
- Removed: unused data_path variable
Replaced old "project_level" (0-4) system with new "selected_track" terminology:
- **quick-flow**: Bug fixes and small features (replaces Level 0-1)
- **bmad-method**: Full planning track (replaces Level 2-3)
- **enterprise-bmad-method**: Extended planning (replaces Level 4)
**Core workflow updates:**
- solutioning-gate-check: Complete rewrite of validation logic for track-based artifacts
- architecture: Updated context detection, error handling, and messaging for tracks
- workflow-init: Updated artifact detection patterns for track-based paths
- All workflow status paths updated (method-greenfield, method-brownfield, enterprise-*)
Unified variable naming conventions across all workflows:
- {output_folder} → {output-folder} (hyphenated format)
- {dev_ephemeral_location} → {sprint_artifacts} (clearer purpose)
- Hardcoded status file paths → {workflow_status_file} variable
Fixed corrupted variable patterns throughout workflow files:
- {output*folder} → {output-folder}
- {ephemeral*location} → {sprint_artifacts}
- \_prd* → *prd* (escaped underscore artifacts)
- **\*\***\_\_\_**\*\*** → proper field placeholders
Affected patterns included malformed glob patterns, template variables, and markdown formatting artifacts from previous edits.
**Architecture workflow (create-architecture):**
- Fixed: "Decision Architecture" → "Create Architecture" (consistent naming)
- Improved PRD not found handling with exit/continue options
- Better user guidance when running standalone vs. within workflow path
- Removed hardcoded Level checks, now track-aware
- Enhanced validation checklist formatting (□ → - [])
- Typo fixes: "mulitple" → "multiple"
**Solutioning gate check:**
- Complete validation logic rewrite for track-based system
- Removed Level-specific artifact expectations
- Simplified document discovery (track determines what exists)
- Better analysis prompts and user feedback
**Workflow-init:**
- Updated artifact detection patterns for new folder structure
- Fixed corrupt glob patterns throughout
- Better sprint_artifacts location detection
- Improved workflow path assignment logic
**Various workflows:**
- Consistent variable naming across 40+ workflow files
- Improved error messages and user guidance
- Better markdown formatting (checkboxes, lists)
- Removed redundant validation criteria files (now inline)
Removed duplicate BMGD 4-production workflows (12 workflows):
- code-review, correct-course, create-story, dev-story
- epic-tech-context, retrospective, sprint-planning
- story-context, story-done, story-ready
**Why:** BMGD now uses shared BMM Phase 4 implementation workflows
**Benefit:** Single source of truth, no duplication to maintain
Also removed:
- validation-criteria.yaml (validation now inline in instructions)
- architecture-patterns.yaml references (patterns now managed differently)
- AUDIT-REPORT.md files (stale audit artifacts)
**BMB workflows:**
- Updated checklists for workflow and module creation
- Improved agent architecture documentation
- Minor instruction clarifications
**Core brainstorming workflow:**
- Updated README with usage examples
- Enhanced instructions and template clarity
- Better integration with other modules
**BMM installer:**
- Updated for track-based system
- sprint_artifacts configuration
**Tech Writer agent:**
- Minor configuration update for documentation workflows
Removed 200+ files that should not be in repository:
- Installed agent markdown files (analyst, architect, dev, pm, sm, tea, etc.)
- Complete workflow instruction copies
- Documentation duplicates (quick-start, agents-guide, workflows-*)
- Test architecture knowledge base (22 files, 14,000+ lines)
- Configuration files (config.yaml, team definitions)
These are generated during installation and should not be version controlled.
Removed 21 pre-generated XML bundles:
- BMM agents (analyst, architect, dev, pm, sm, tea, tech-writer, ux-designer)
- BMGD agents (game-architect, game-designer, game-dev, game-scrum-master)
- CIS agents (brainstorming-coach, creative-problem-solver, etc.)
- Team bundles (team-fullstack, team-gamedev, creative-squad)
**Why:** Users should generate fresh bundles via `npm run bundle` to get latest changes and customizations.
- **2 new documentation files** (comprehensive guides)
- **98 source files modified** (299 insertions, 6,567 deletions)
- **3 installer config files simplified** (major folder structure improvement)
- **200+ .bmad/ artifacts removed** (should not be in repo)
- **21 web-bundle files removed** (users regenerate as needed)
- **12 duplicate workflows removed** (BMGD consolidation)
- **40+ workflows updated** (track system, variable standardization, corruption fixes)
This commit is contained in:
Brian Madison
@@ -319,29 +319,3 @@ decision_rules:
|
||||
- quick_prototype: "Railway"
|
||||
- global_edge: "Fly.io"
|
||||
- kubernetes_needed: "GCP or AWS EKS"
|
||||
|
||||
# Anti-patterns to avoid
|
||||
anti_patterns:
|
||||
overengineering:
|
||||
signs:
|
||||
- "Microservices for < 10k users"
|
||||
- "Kubernetes for single app"
|
||||
- "GraphQL for 5 endpoints"
|
||||
- "Event sourcing for CRUD app"
|
||||
recommendation: "Start simple, evolve as needed"
|
||||
|
||||
underengineering:
|
||||
signs:
|
||||
- "No authentication strategy"
|
||||
- "No error handling plan"
|
||||
- "No monitoring approach"
|
||||
- "No backup strategy"
|
||||
recommendation: "Cover the fundamentals"
|
||||
|
||||
technology_soup:
|
||||
signs:
|
||||
- "5+ different databases"
|
||||
- "Multiple frontend frameworks"
|
||||
- "Inconsistent patterns"
|
||||
- "Too many languages"
|
||||
recommendation: "Maintain consistency"
|
||||
|
||||
@@ -225,19 +225,15 @@
|
||||
|
||||
### Critical Issues Found
|
||||
|
||||
- [ ] Issue 1: **\*\***\_\_\_**\*\***
|
||||
- [ ] Issue 2: **\*\***\_\_\_**\*\***
|
||||
- [ ] Issue 3: **\*\***\_\_\_**\*\***
|
||||
<!-- replace with list of critical issues found, or N/A -->
|
||||
|
||||
### Recommended Actions Before Implementation
|
||||
|
||||
1. ***
|
||||
2. ***
|
||||
3. ***
|
||||
<!-- replace with list of recommended actions, or N/A -->
|
||||
|
||||
---
|
||||
|
||||
**Next Step**: Run the **solutioning-gate-check** workflow to validate alignment between PRD, Architecture, and Stories before beginning implementation.
|
||||
**Next Step**: Run the **solutioning-gate-check** workflow to validate alignment between PRD, UX, Architecture, and Stories before beginning implementation.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Decision Architecture can run standalone or as part of BMM workflow path.</output>
|
||||
<output>No workflow status file found. Create Architecture 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">
|
||||
@@ -33,17 +33,9 @@
|
||||
<action>Check status of "create-architecture" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_level < 3">
|
||||
<output>**Note: Level {{project_level}} Project**
|
||||
|
||||
The Detailed Architecture is typically for Level 3-4 projects, but can be used for any project that needs architectural planning.
|
||||
|
||||
For Level {{project_level}}, we'll keep the architecture appropriately scoped.
|
||||
</output>
|
||||
</check>
|
||||
|
||||
<check if="create-architecture status is file path (already completed)">
|
||||
<check if="create-architecture status is indicates already completed">
|
||||
<output>⚠️ Architecture already completed: {{create-architecture status}}</output>
|
||||
<ask>Re-running will overwrite the existing architecture. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
@@ -62,7 +54,6 @@ For Level {{project_level}}, we'll keep the architecture appropriately scoped.
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
|
||||
<action>Check for existing PRD and epics files using fuzzy matching</action>
|
||||
|
||||
@@ -70,21 +61,22 @@ For Level {{project_level}}, we'll keep the architecture appropriately scoped.
|
||||
<check if="PRD_not_found">
|
||||
<output>**PRD Not Found**
|
||||
|
||||
Decision Architecture works from your Product Requirements Document (PRD).
|
||||
Creation of an Architecture works from your Product Requirements Document (PRD), along with an optional UX Design and other assets.
|
||||
|
||||
Looking for: _PRD_, PRD.md, or prd/index.md + files in {output_folder}
|
||||
Looking for: _prd_.md, or prd/\* + files in {output_folder}
|
||||
|
||||
Please run the PRD workflow first to define your requirements.
|
||||
|
||||
Architect: `create-prd`
|
||||
Please talk to the PM Agent to run the Create PRD workflow first to define your requirements, or if I am mistaken and it does exist, provide the file now.
|
||||
</output>
|
||||
<action>Exit workflow - PRD required</action>
|
||||
<ask>Would you like to exit, or can you provide a PRD?
|
||||
<action if='yes to exit'>Exit workflow - PRD required</action>
|
||||
<action if='prd provided'>Proceed to Step 1</action>
|
||||
</ask>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Load and understand project context">
|
||||
<action>Load the PRD using fuzzy matching: {prd_file}, if the PRD is mulitple files in a folder, load the index file and all files associated with the PRD</action>
|
||||
<action>Load the PRD using fuzzy matching: {prd_file}, if the PRD is multiple files in a folder, load the index file and all files associated with the PRD</action>
|
||||
<action>Load epics file using fuzzy matching: {epics_file}</action>
|
||||
|
||||
<action>Check for UX specification using fuzzy matching:
|
||||
@@ -623,14 +615,15 @@ Enforcement: "All agents MUST follow this pattern"
|
||||
<action>Run validation checklist from {installed_path}/checklist.md</action>
|
||||
|
||||
<action>Verify MANDATORY items:
|
||||
□ Decision table has Version column with specific versions
|
||||
□ Every epic is mapped to architecture components
|
||||
□ Source tree is complete, not generic
|
||||
□ No placeholder text remains
|
||||
□ All FRs from PRD have architectural support
|
||||
□ All NFRs from PRD are addressed
|
||||
□ Implementation patterns cover all potential conflicts
|
||||
□ Novel patterns are fully documented (if applicable)
|
||||
|
||||
- [] Decision table has Version column with specific versions
|
||||
- [] Every epic is mapped to architecture components
|
||||
- [] Source tree is complete, not generic
|
||||
- [] No placeholder text remains
|
||||
- [] All FRs from PRD have architectural support
|
||||
- [] All NFRs from PRD are addressed
|
||||
- [] Implementation patterns cover all potential conflicts
|
||||
- [] Novel patterns are fully documented (if applicable)
|
||||
</action>
|
||||
|
||||
<check if="validation_failed">
|
||||
|
||||
@@ -12,29 +12,20 @@ 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, Epics, and optionally UX Spec
|
||||
recommended_inputs:
|
||||
- prd: "Product Requirements Document with FRs and NFRs"
|
||||
- epics: "Epic definitions with user stories and acceptance criteria"
|
||||
- ux_spec: "UX specification with interface designs and interaction patterns (optional)"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
input_file_patterns:
|
||||
prd:
|
||||
whole: "{output_folder}/*prd*.md"
|
||||
sharded: "{output_folder}/*prd*/index.md"
|
||||
|
||||
epics:
|
||||
whole: "{output_folder}/*epic*.md"
|
||||
sharded: "{output_folder}/*epic*/index.md"
|
||||
|
||||
ux_design:
|
||||
whole: "{output_folder}/*ux*.md"
|
||||
sharded: "{output_folder}/*ux*/index.md"
|
||||
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
sharded: "{output_folder}/index.md"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/architecture"
|
||||
@@ -50,20 +41,6 @@ pattern_categories: "{installed_path}/pattern-categories.csv"
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/architecture.md"
|
||||
|
||||
# Workflow metadata
|
||||
version: "1.3.2"
|
||||
replaces: "architecture"
|
||||
paradigm: "facilitation-driven"
|
||||
execution_time: "30-90 minutes depending on user skill level"
|
||||
features:
|
||||
- "Starter template discovery and integration"
|
||||
- "Dynamic version verification via web search"
|
||||
- "Adaptive facilitation by skill level"
|
||||
- "Decision-focused architecture"
|
||||
- "Novel pattern design for unique concepts"
|
||||
- "Intelligent pattern identification - LLM figures out what patterns matter"
|
||||
- "Implementation patterns for agent consistency"
|
||||
|
||||
standalone: true
|
||||
|
||||
# Web bundle configuration for standalone deployment
|
||||
|
||||
@@ -4,10 +4,10 @@
|
||||
|
||||
### Core Planning Documents
|
||||
|
||||
- [ ] PRD exists and is complete (Level 2-4 projects)
|
||||
- [ ] PRD exists and is complete
|
||||
- [ ] PRD contains measurable success criteria
|
||||
- [ ] PRD defines clear scope boundaries and exclusions
|
||||
- [ ] Architecture document exists (architecture\*.md) (Level 3-4 projects)
|
||||
- [ ] Architecture document exists (architecture\*.md)
|
||||
- [ ] Technical Specification exists with implementation details
|
||||
- [ ] Epic and story breakdown document exists
|
||||
- [ ] All documents are dated and versioned
|
||||
@@ -22,7 +22,7 @@
|
||||
|
||||
## Alignment Verification
|
||||
|
||||
### PRD to Architecture Alignment (Level 3-4)
|
||||
### PRD to Architecture Alignment
|
||||
|
||||
- [ ] Every functional requirement in PRD has architectural support documented
|
||||
- [ ] All non-functional requirements from PRD are addressed in architecture
|
||||
@@ -33,7 +33,7 @@
|
||||
- [ ] If architecture.md: All technology choices have verified versions
|
||||
- [ ] If UX spec exists: Architecture supports UX requirements
|
||||
|
||||
### PRD to Stories Coverage (Level 2-4)
|
||||
### PRD to Stories Coverage
|
||||
|
||||
- [ ] Every PRD requirement maps to at least one story
|
||||
- [ ] All user journeys in PRD have complete story coverage
|
||||
@@ -154,21 +154,15 @@
|
||||
|
||||
### Critical Issues Found
|
||||
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
<!-- checklist of critical issues or N/A -->
|
||||
|
||||
### High Priority Issues Found
|
||||
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
<!-- checklist of high priority issues or N/A -->
|
||||
|
||||
### Medium Priority Issues Found
|
||||
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
<!-- checklist of medium priority issues or N/A -->
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
<action>Check if {workflow_status_file} exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Implementation Ready Check can run standalone or as part of BMM workflow path.</output>
|
||||
@@ -23,14 +23,13 @@
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Load the FULL file: {workflow_status_file}</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "solutioning-gate-check" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Get {selected_track} (quick-flow, bmad-method, or enterprise-bmad-method)</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<action>Based on the project_level, understand what artifacts should exist: - Level 0-1: Tech spec and simple stories only (no PRD, minimal solutioning) - Level 2: PRD, tech spec, epics/stories (no separate architecture doc) - Level 3-4: Full suite - PRD, architecture document, epics/stories, possible UX artifacts
|
||||
</action>
|
||||
<action>Based on the selected_track, understand what artifacts should exist: - quick-flow: Tech spec and simple stories in an epic only (no PRD, minimal solutioning) - bmad-method and enterprise-bmad-method: PRD, tech spec, epics/stories, architecture, possible UX artifacts</action>
|
||||
|
||||
<check if="solutioning-gate-check status is file path (already completed)">
|
||||
<output>⚠️ Gate check already completed: {{solutioning-gate-check status}}</output>
|
||||
@@ -53,28 +52,18 @@
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
|
||||
<critical>The validation approach must adapt to the project level - don't look for documents that shouldn't exist at lower levels</critical>
|
||||
|
||||
<template-output>project_context</template-output>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Discover and inventory project artifacts">
|
||||
<action>Search the {output_folder} for relevant planning and solutioning documents based on project level identified in Step 0</action>
|
||||
<action>Search the {output_folder} for relevant planning and solutioning documents</action>
|
||||
|
||||
<action>For Level 0-1 projects, locate:
|
||||
|
||||
- Technical specification document(s)
|
||||
- Story/task lists or simple epic breakdowns
|
||||
- Any API or interface definitions
|
||||
</action>
|
||||
|
||||
<action>For Level 2-4 projects, locate:
|
||||
<action>Locate:
|
||||
|
||||
- Product Requirements Document (PRD)
|
||||
- Architecture document (architecture.md) (Level 3-4 only)
|
||||
- Technical Specification (Level 2 includes architecture within)
|
||||
- Architecture
|
||||
- Epic and story breakdowns
|
||||
- UX artifacts if the active path includes UX workflow
|
||||
- UX Design artifacts if the active path includes UX workflow
|
||||
- Any supplementary planning documents
|
||||
</action>
|
||||
|
||||
@@ -91,15 +80,15 @@
|
||||
|
||||
<step n="2" goal="Deep analysis of core planning documents">
|
||||
<action>Load and thoroughly analyze each discovered document to extract:
|
||||
- Core requirements and success criteria
|
||||
- Architectural decisions and constraints
|
||||
- Technical implementation approaches
|
||||
- User stories and acceptance criteria
|
||||
- Dependencies and sequencing requirements
|
||||
- Any assumptions or risks documented
|
||||
- Core requirements and success criteria
|
||||
- Architectural decisions and constraints
|
||||
- Technical implementation approaches
|
||||
- User stories and acceptance criteria
|
||||
- Dependencies and sequencing requirements
|
||||
- Any assumptions or risks documented
|
||||
</action>
|
||||
|
||||
<action>For PRD analysis (Level 2-4), focus on:
|
||||
<action>For PRD analysis, focus on:
|
||||
|
||||
- User requirements and use cases
|
||||
- Functional and non-functional requirements
|
||||
@@ -131,9 +120,8 @@
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Cross-reference validation and alignment check">
|
||||
<action>Systematically validate alignment between all artifacts, adapting validation based on project level</action>
|
||||
|
||||
<action>PRD ↔ Architecture Alignment (Level 3-4):
|
||||
<action>PRD ↔ Architecture Alignment:
|
||||
|
||||
- Verify every PRD requirement has corresponding architectural support
|
||||
- Check that architectural decisions don't contradict PRD constraints
|
||||
@@ -142,7 +130,7 @@
|
||||
- If using new architecture workflow: verify implementation patterns are defined
|
||||
</action>
|
||||
|
||||
<action>PRD ↔ Stories Coverage (Level 2-4):
|
||||
<action>PRD ↔ Stories Coverage:
|
||||
|
||||
- Map each PRD requirement to implementing stories
|
||||
- Identify any PRD requirements without story coverage
|
||||
@@ -158,13 +146,6 @@
|
||||
- Ensure infrastructure and setup stories exist for architectural components
|
||||
</action>
|
||||
|
||||
<action>For Level 0-1 projects (Tech Spec only):
|
||||
|
||||
- Validate internal consistency within tech spec
|
||||
- Check that all specified features have corresponding stories
|
||||
- Verify story sequencing matches technical dependencies
|
||||
</action>
|
||||
|
||||
<template-output>alignment_validation</template-output>
|
||||
</step>
|
||||
|
||||
@@ -219,20 +200,20 @@
|
||||
</step>
|
||||
|
||||
<step n="5" goal="UX and special concerns validation" optional="true">
|
||||
<check if="UX artifacts exist or UX workflow in active path">
|
||||
<action>Review UX artifacts and validate integration:
|
||||
- Check that UX requirements are reflected in PRD
|
||||
- Verify stories include UX implementation tasks
|
||||
- Ensure architecture supports UX requirements (performance, responsiveness)
|
||||
- Identify any UX concerns not addressed in stories
|
||||
</action>
|
||||
<check if="UX artifacts exist or UX workflow in active path">
|
||||
<action>Review UX artifacts and validate integration:
|
||||
- Check that UX requirements are reflected in PRD
|
||||
- Verify stories include UX implementation tasks
|
||||
- Ensure architecture supports UX requirements (performance, responsiveness)
|
||||
- Identify any UX concerns not addressed in stories
|
||||
</action>
|
||||
|
||||
<action>Validate accessibility and usability coverage:
|
||||
<action>Validate accessibility and usability coverage:
|
||||
- Check for accessibility requirement coverage in stories
|
||||
- Verify responsive design considerations if applicable
|
||||
- Ensure user flow completeness across stories
|
||||
</action>
|
||||
|
||||
- Check for accessibility requirement coverage in stories
|
||||
- Verify responsive design considerations if applicable
|
||||
- Ensure user flow completeness across stories
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<template-output>ux_validation</template-output>
|
||||
@@ -269,7 +250,7 @@
|
||||
|
||||
<step n="7" 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>Load the FULL file: {workflow_status_file}</action>
|
||||
<action>Find workflow_status key "solutioning-gate-check"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["solutioning-gate-check"] = "{output_folder}/bmm-readiness-assessment-{{date}}.md"</action>
|
||||
|
||||
@@ -1,189 +0,0 @@
|
||||
# Implementation Readiness Validation Criteria
|
||||
# Defines systematic validation rules by project level
|
||||
|
||||
validation_rules:
|
||||
# Level 0-1 Projects (Simple, minimal planning)
|
||||
level_0_1:
|
||||
required_documents:
|
||||
- tech_spec
|
||||
- stories_or_tasks
|
||||
|
||||
validations:
|
||||
- name: "Tech Spec Completeness"
|
||||
checks:
|
||||
- "All features defined with implementation approach"
|
||||
- "Technical dependencies identified"
|
||||
- "API contracts defined if applicable"
|
||||
- "Data models specified"
|
||||
|
||||
- name: "Story Coverage"
|
||||
checks:
|
||||
- "All tech spec features have corresponding stories"
|
||||
- "Stories are sequenced logically"
|
||||
- "Technical tasks are defined"
|
||||
- "No critical gaps in coverage"
|
||||
|
||||
# Level 2 Projects (PRD + Tech Spec, no separate architecture)
|
||||
level_2:
|
||||
required_documents:
|
||||
- prd
|
||||
- tech_spec # Includes architecture decisions
|
||||
- epics_and_stories
|
||||
|
||||
validations:
|
||||
- name: "PRD to Tech Spec Alignment"
|
||||
checks:
|
||||
- "All PRD requirements addressed in tech spec"
|
||||
- "Architecture embedded in tech spec covers PRD needs"
|
||||
- "Non-functional requirements are specified"
|
||||
- "Technical approach supports business goals"
|
||||
|
||||
- name: "Story Coverage and Alignment"
|
||||
checks:
|
||||
- "Every PRD requirement has story coverage"
|
||||
- "Stories align with tech spec approach"
|
||||
- "Epic breakdown is complete"
|
||||
- "Acceptance criteria match PRD success criteria"
|
||||
|
||||
- name: "Sequencing Validation"
|
||||
checks:
|
||||
- "Foundation stories come first"
|
||||
- "Dependencies are properly ordered"
|
||||
- "Iterative delivery is possible"
|
||||
- "No circular dependencies"
|
||||
|
||||
# Level 3-4 Projects (Full planning with separate architecture)
|
||||
level_3_4:
|
||||
required_documents:
|
||||
- prd
|
||||
- architecture
|
||||
- epics_and_stories
|
||||
|
||||
validations:
|
||||
- name: "PRD Completeness"
|
||||
checks:
|
||||
- "User requirements fully documented"
|
||||
- "Success criteria are measurable"
|
||||
- "Scope boundaries clearly defined"
|
||||
- "Priorities are assigned"
|
||||
|
||||
- name: "Architecture Coverage"
|
||||
checks:
|
||||
- "All PRD requirements have architectural support"
|
||||
- "System design is complete"
|
||||
- "Integration points defined"
|
||||
- "Security architecture specified"
|
||||
- "Performance considerations addressed"
|
||||
- "If architecture.md: Implementation patterns defined"
|
||||
- "If architecture.md: Technology versions verified and current"
|
||||
- "If architecture.md: Starter template command documented (if applicable)"
|
||||
|
||||
- name: "PRD-Architecture Alignment"
|
||||
checks:
|
||||
- "No architecture gold-plating beyond PRD"
|
||||
- "NFRs from PRD reflected in architecture"
|
||||
- "Technology choices support requirements"
|
||||
- "Scalability matches expected growth"
|
||||
- "If UX spec exists: Architecture supports UX requirements"
|
||||
- "If UX spec exists: Component library supports interaction patterns"
|
||||
|
||||
- name: "Story Implementation Coverage"
|
||||
checks:
|
||||
- "All architectural components have stories"
|
||||
- "Infrastructure setup stories exist"
|
||||
- "Integration implementation planned"
|
||||
- "Security implementation stories present"
|
||||
|
||||
- name: "Comprehensive Sequencing"
|
||||
checks:
|
||||
- "Infrastructure before features"
|
||||
- "Authentication before protected resources"
|
||||
- "Core features before enhancements"
|
||||
- "Dependencies properly ordered"
|
||||
- "Allows for iterative releases"
|
||||
|
||||
# Special validation contexts
|
||||
special_contexts:
|
||||
greenfield:
|
||||
additional_checks:
|
||||
- "Project initialization stories exist"
|
||||
- "If using architecture.md: First story is starter template initialization"
|
||||
- "Development environment setup documented"
|
||||
- "CI/CD pipeline stories included"
|
||||
- "Initial data/schema setup planned"
|
||||
- "Deployment infrastructure stories present"
|
||||
|
||||
ux_workflow_active:
|
||||
additional_checks:
|
||||
- "UX requirements in PRD"
|
||||
- "UX implementation stories exist"
|
||||
- "Accessibility requirements covered"
|
||||
- "Responsive design addressed"
|
||||
- "User flow continuity maintained"
|
||||
|
||||
api_heavy:
|
||||
additional_checks:
|
||||
- "API contracts fully defined"
|
||||
- "Versioning strategy documented"
|
||||
- "Authentication/authorization specified"
|
||||
- "Rate limiting considered"
|
||||
- "API documentation stories included"
|
||||
|
||||
# Severity definitions
|
||||
severity_levels:
|
||||
critical:
|
||||
description: "Must be resolved before implementation"
|
||||
examples:
|
||||
- "Missing stories for core requirements"
|
||||
- "Conflicting technical approaches"
|
||||
- "No infrastructure setup for greenfield"
|
||||
- "Security requirements not addressed"
|
||||
|
||||
high:
|
||||
description: "Should be addressed to reduce risk"
|
||||
examples:
|
||||
- "Incomplete acceptance criteria"
|
||||
- "Unclear story dependencies"
|
||||
- "Missing error handling coverage"
|
||||
- "Performance requirements not validated"
|
||||
|
||||
medium:
|
||||
description: "Consider addressing for smoother implementation"
|
||||
examples:
|
||||
- "Documentation gaps"
|
||||
- "Test strategy not defined"
|
||||
- "Monitoring approach unclear"
|
||||
- "Minor sequencing improvements possible"
|
||||
|
||||
low:
|
||||
description: "Minor improvements for consideration"
|
||||
examples:
|
||||
- "Formatting inconsistencies"
|
||||
- "Optional enhancements identified"
|
||||
- "Style guide compliance"
|
||||
- "Nice-to-have features noted"
|
||||
|
||||
# Readiness decision criteria
|
||||
readiness_decisions:
|
||||
ready:
|
||||
criteria:
|
||||
- "No critical issues found"
|
||||
- "All required documents present"
|
||||
- "Core alignments validated"
|
||||
- "Story sequencing logical"
|
||||
- "Team can begin implementation"
|
||||
|
||||
ready_with_conditions:
|
||||
criteria:
|
||||
- "Only high/medium issues found"
|
||||
- "Mitigation plans identified"
|
||||
- "Core path to MVP clear"
|
||||
- "Issues won't block initial stories"
|
||||
|
||||
not_ready:
|
||||
criteria:
|
||||
- "Critical issues identified"
|
||||
- "Major gaps in coverage"
|
||||
- "Conflicting approaches found"
|
||||
- "Required documents missing"
|
||||
- "Blocking dependencies unresolved"
|
||||
@@ -14,6 +14,7 @@ date: system-generated
|
||||
# Workflow status integration
|
||||
workflow_status_workflow: "{project-root}/{bmad_folder}/bmm/workflows/workflow-status/workflow.yaml"
|
||||
workflow_paths_dir: "{project-root}/{bmad_folder}/bmm/workflows/workflow-status/paths"
|
||||
workflow_status_file: "{output_folder}/bmm-workflow-status.yaml"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/solutioning-gate-check"
|
||||
@@ -38,29 +39,21 @@ input_file_patterns:
|
||||
prd:
|
||||
whole: "{output_folder}/*prd*.md"
|
||||
sharded: "{output_folder}/*prd*/index.md"
|
||||
|
||||
epics:
|
||||
whole: "{output_folder}/*epic*.md"
|
||||
sharded: "{output_folder}/*epic*/index.md"
|
||||
|
||||
architecture:
|
||||
whole: "{output_folder}/*architecture*.md"
|
||||
sharded: "{output_folder}/*architecture*/index.md"
|
||||
|
||||
ux_design:
|
||||
whole: "{output_folder}/*ux*.md"
|
||||
sharded: "{output_folder}/*ux*/index.md"
|
||||
|
||||
tech_spec:
|
||||
whole: "{output_folder}/*tech-spec*.md"
|
||||
sharded: "{output_folder}/*tech-spec*/index.md"
|
||||
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
|
||||
# Validation criteria data
|
||||
validation_criteria: "{installed_path}/validation-criteria.yaml"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle: false
|
||||
|
||||
Reference in New Issue
Block a user