ros/BMAD-METHOD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

checklist standardization and improvement with llm eliciatation

Browse Source
This commit is contained in:
Brian Madison
2025-06-08 20:34:07 -05:00
parent 460c47f5c8
commit 8788c1d20f
24 changed files with 2419 additions and 884 deletions
Download Patch File Download Diff File Expand all files Collapse all files

269
agent-team-workflows/brownfield-fullstack.yml
View File

@@ -2,192 +2,115 @@ workflow:
id: brownfield-fullstack
name: Brownfield Full-Stack Enhancement
description: >-
Workflow for adding features, refactoring, or modernizing existing applications.
Handles legacy code analysis and incremental improvements.
Agent workflow for enhancing existing full-stack applications with new features,
modernization, or significant changes. Handles existing system analysis and safe integration.
type: brownfield
project_types:
- feature-addition
- refactoring
- modernization
- bug-fix
- integration-enhancement
stages:
- id: system-analysis
name: Existing System Analysis
description: Understand current system and identify improvement areas
steps:
- agent: analyst
action: System Assessment
description: >-
Analyze existing system, codebase, and identify pain points
inputs:
- existing-documentation
- codebase-access
outputs:
- system-assessment
- improvement-opportunities
- technical-debt-analysis
prompts:
- "Let's analyze the existing system architecture"
- "What are the main pain points and technical debt?"
- "Share any existing documentation or system diagrams"
- "You can also share the codebase if you have access to it"
# For Complex Enhancements (Multiple Stories, Architectural Changes)
complex_enhancement_sequence:
- step: scope_assessment
agent: any
action: assess complexity
notes: "First, assess if this is a simple change (use simple_enhancement_sequence) or complex enhancement requiring full planning."
- agent: fullstack-architect
action: Code Analysis
description: >-
Deep dive into codebase quality and structure
inputs:
- codebase-access
outputs:
- code-quality-report
- dependency-analysis
- refactoring-candidates
prompts:
- "Let me analyze the code structure and quality"
- "Identifying areas that need refactoring"
- step: project_analysis
agent: analyst
action: analyze existing project
notes: "Review existing documentation, codebase structure, and identify integration points. Document current system understanding before proceeding."
- id: enhancement-planning
name: Enhancement Planning
description: Plan improvements and new features
steps:
- agent: pm
action: Enhancement Strategy
description: >-
Define enhancement goals and success criteria
inputs:
- system-assessment
- improvement-opportunities
outputs:
- enhancement-prd
- success-metrics
- risk-assessment
prompts:
- "What specific enhancements are we targeting?"
- "Define success metrics for these improvements"
- agent: pm
creates: brownfield-prd.md
uses: brownfield-prd-tmpl
requires: existing_project_analysis
notes: "Creates comprehensive brownfield PRD with existing system analysis and enhancement planning. SAVE OUTPUT: Copy final brownfield-prd.md to your project's docs/ folder."
- agent: fullstack-architect
action: Integration Architecture
description: >-
Design how new features integrate with existing system
inputs:
- enhancement-prd
- system-assessment
outputs:
- integration-architecture
- migration-strategy
- compatibility-matrix
prompts:
- "How will new features integrate with existing code?"
- "Design migration strategy for gradual rollout"
- agent: fullstack-architect
creates: brownfield-architecture.md
uses: brownfield-architecture-tmpl
requires: brownfield-prd.md
notes: "Creates brownfield architecture with integration strategy and existing system constraints. SAVE OUTPUT: Copy final brownfield-architecture.md to your project's docs/ folder."
- id: incremental-design
name: Incremental Design
description: Design changes that don't break existing functionality
steps:
- agent: fullstack-architect
action: Incremental Architecture
description: >-
Design architecture that allows gradual migration
inputs:
- integration-architecture
- technical-debt-analysis
outputs:
- incremental-architecture
- feature-flags-design
- rollback-strategy
prompts:
- "Design architecture for incremental deployment"
- "How do we maintain backward compatibility?"
- agent: po
validates: all_artifacts
uses: brownfield-checklist
notes: "Validates all brownfield documents for integration safety and completeness. May require updates to any document."
- agent: devops
action: Deployment Strategy
description: >-
Plan zero-downtime deployment and rollback procedures
inputs:
- incremental-architecture
outputs:
- deployment-strategy
- canary-release-plan
- monitoring-upgrades
prompts:
- "Design blue-green or canary deployment"
- "Upgrade monitoring for new features"
- agent: various
updates: any_flagged_documents
condition: po_checklist_issues
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
- id: risk-mitigation
name: Risk Assessment & Mitigation
description: Identify and plan for risks in brownfield changes
steps:
- agent: qa
action: Regression Risk Analysis
description: >-
Identify regression risks and test coverage gaps
inputs:
- code-quality-report
- integration-architecture
outputs:
- regression-risk-matrix
- test-gap-analysis
- test-automation-plan
prompts:
- "What existing functionality might break?"
- "Where do we need additional test coverage?"
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
- agent: po
action: Change Impact Review
description: >-
Review all changes for business impact
inputs:
- enhancement-prd
- risk-assessment
- regression-risk-matrix
outputs:
- impact-analysis
- stakeholder-communication
- approval-checklist
prompts:
- "Review impact on existing users and workflows"
- "Prepare stakeholder communication plan"
# For Simple Enhancements (1-3 Stories, Following Existing Patterns)
simple_enhancement_sequence:
- step: enhancement_type
action: choose approach
notes: "Choose between creating single story (very small change) or epic (1-3 related stories)."
- id: implementation-planning
name: Phased Implementation
description: Create phased implementation plan
steps:
- agent: sm
action: Phased Story Creation
description: >-
Create stories for incremental implementation
inputs:
- incremental-architecture
- impact-analysis
outputs:
- implementation-phases
- user-stories
- dependency-map
prompts:
- "Break down into safe, incremental phases"
- "Map dependencies between stories"
- agent: pm|po|sm
creates: brownfield_epic OR brownfield_story
uses: brownfield-create-epic OR brownfield-create-story
notes: "Create focused enhancement with existing system integration. Choose agent based on team preference and context."
transitions:
- from: system-analysis
to: enhancement-planning
condition: assessment complete
- from: enhancement-planning
to: incremental-design
condition: strategy defined
- from: incremental-design
to: risk-mitigation
condition: architecture approved
- from: risk-mitigation
to: implementation-planning
condition: risks assessed
- workflow_end:
action: move_to_ide
notes: "Enhancement defined. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
special_considerations:
- name: Legacy Code
description: Handle undocumented or poorly structured code
- name: Data Migration
description: Plan for data structure changes
- name: User Training
description: Consider impact on existing users
- name: Rollback Plan
description: Always have a way to revert changes
flow_diagram: |
```mermaid
graph TD
A[Start: Brownfield Enhancement] --> B{Enhancement Complexity?}
B -->|Complex/Significant| C[analyst: analyze existing project]
B -->|Simple| D{1 Story or 2-3 Stories?}
C --> E[pm: brownfield-prd.md]
E --> F[fullstack-architect: brownfield-architecture.md]
F --> G[po: validate with brownfield-checklist]
G --> H{PO finds issues?}
H -->|Yes| I[Return to relevant agent for fixes]
H -->|No| J[Move to IDE Environment]
I --> G
D -->|1 Story| K[pm/po/sm: brownfield-create-story]
D -->|2-3 Stories| L[pm/po/sm: brownfield-create-epic]
K --> M[Move to IDE Environment]
L --> M
style J fill:#90EE90
style M fill:#90EE90
style E fill:#FFE4B5
style F fill:#FFE4B5
style K fill:#FFB6C1
style L fill:#FFB6C1
```
decision_guidance:
use_complex_sequence_when:
- Enhancement requires multiple coordinated stories (4+)
- Architectural changes are needed
- Significant integration work required
- Risk assessment and mitigation planning necessary
- Multiple team members will work on related changes
use_simple_sequence_when:
- Enhancement can be completed in 1-3 stories
- Follows existing project patterns
- Integration complexity is minimal
- Risk to existing system is low
- Change is isolated with clear boundaries
handoff_prompts:
analyst_to_pm: "Existing project analysis complete. Create comprehensive brownfield PRD with integration strategy."
pm_to_architect: "Brownfield PRD ready. Save it as docs/brownfield-prd.md, then create the integration architecture."
architect_to_po: "Architecture complete. Save it as docs/brownfield-architecture.md. Please validate all artifacts for integration safety."
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
simple_to_ide: "Enhancement defined with existing system integration. Move to IDE environment to begin development."
complex_complete: "All brownfield planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."

324
agent-team-workflows/brownfield-service.yml
View File

@@ -2,252 +2,116 @@ workflow:
id: brownfield-service
name: Brownfield Service/API Enhancement
description: >-
Workflow for modernizing, refactoring, or enhancing existing backend services and APIs.
Handles performance optimization, API versioning, microservice extraction, and technical debt.
Agent workflow for enhancing existing backend services and APIs with new features,
modernization, or performance improvements. Handles existing system analysis and safe integration.
type: brownfield
project_types:
- service-modernization
- api-enhancement
- microservice-extraction
- performance-optimization
- technical-debt-reduction
- integration-enhancement
stages:
- id: service-analysis
name: Service Assessment
description: Analyze existing service and identify improvement areas
steps:
- agent: analyst
action: Service Assessment
description: >-
Analyze current service architecture, performance, and technical debt
inputs:
- existing-service-code
- performance-metrics
- error-logs
outputs:
- service-assessment
- performance-bottlenecks
- technical-debt-analysis
- integration-dependencies
prompts:
- "Let's analyze the current service architecture"
- "What performance issues are you experiencing?"
- "Share service metrics, logs, or documentation"
# For Complex Service Enhancements (Multiple Stories, Architectural Changes)
complex_enhancement_sequence:
- step: scope_assessment
agent: any
action: assess complexity
notes: "First, assess if this is a simple service change (use simple_enhancement_sequence) or complex enhancement requiring full planning."
- agent: fullstack-architect
action: Architecture Analysis
description: >-
Deep dive into service architecture and identify improvement opportunities
inputs:
- service-assessment
- existing-service-code
outputs:
- architecture-assessment
- refactoring-opportunities
- modernization-candidates
prompts:
- "Analyze the service architecture patterns"
- "Identify areas for modernization"
- step: service_analysis
agent: analyst
action: analyze existing service
notes: "Review existing service documentation, codebase, performance metrics, and identify integration dependencies."
- id: enhancement-planning
name: Service Enhancement Strategy
description: Plan service improvements and modernization approach
steps:
- agent: pm
action: Enhancement Strategy
description: >-
Define enhancement goals, priorities, and migration strategy
inputs:
- service-assessment
- architecture-assessment
outputs:
- enhancement-strategy
- migration-roadmap
- risk-assessment
prompts:
- "What are the primary enhancement goals?"
- "Define the migration strategy and timeline"
- agent: pm
creates: brownfield-prd.md
uses: brownfield-prd-tmpl
requires: existing_service_analysis
notes: "Creates comprehensive brownfield PRD focused on service enhancement with existing system analysis. SAVE OUTPUT: Copy final brownfield-prd.md to your project's docs/ folder."
- agent: fullstack-architect
action: Modernization Architecture
description: >-
Design target architecture for service modernization
inputs:
- enhancement-strategy
- modernization-candidates
outputs:
- target-architecture
- migration-patterns
- backward-compatibility-plan
prompts:
- "Design the target service architecture"
- "Plan for backward compatibility during migration"
- agent: architect
creates: brownfield-architecture.md
uses: brownfield-architecture-tmpl
requires: brownfield-prd.md
notes: "Creates brownfield architecture with service integration strategy and API evolution planning. SAVE OUTPUT: Copy final brownfield-architecture.md to your project's docs/ folder."
- id: incremental-refactoring
name: Incremental Refactoring Design
description: Design safe, incremental refactoring approach
steps:
- agent: fullstack-architect
action: Refactoring Strategy
description: >-
Design strangler fig pattern or other safe refactoring approaches
inputs:
- target-architecture
- integration-dependencies
outputs:
- refactoring-strategy
- service-extraction-plan
- data-migration-strategy
prompts:
- "Design strangler fig or parallel run strategy"
- "Plan service extraction and data migration"
- agent: po
validates: all_artifacts
uses: brownfield-checklist
notes: "Validates all brownfield documents for service integration safety and API compatibility. May require updates to any document."
- agent: devops
action: Infrastructure Evolution
description: >-
Plan infrastructure changes and deployment strategy
inputs:
- refactoring-strategy
- target-architecture
outputs:
- infrastructure-migration
- deployment-strategy
- monitoring-evolution
- scaling-improvements
prompts:
- "Plan infrastructure for new architecture"
- "Design zero-downtime deployment strategy"
- agent: various
updates: any_flagged_documents
condition: po_checklist_issues
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
- id: api-evolution
name: API Versioning & Evolution
description: Plan API changes and versioning strategy
steps:
- agent: fullstack-architect
action: API Evolution Strategy
description: >-
Design API versioning and backward compatibility
inputs:
- target-architecture
- integration-dependencies
outputs:
- api-versioning-strategy
- contract-evolution-plan
- deprecation-timeline
prompts:
- "Design API versioning strategy"
- "Plan contract evolution and deprecation"
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
- id: data-strategy
name: Data Migration & Consistency
description: Plan data migration and consistency strategies
steps:
- agent: fullstack-architect
action: Data Migration Planning
description: >-
Plan data migration, consistency, and synchronization
inputs:
- refactoring-strategy
- data-migration-strategy
outputs:
- data-migration-plan
- consistency-strategy
- rollback-procedures
prompts:
- "Plan data migration with zero data loss"
- "Design data consistency during transition"
# For Simple Service Enhancements (1-3 Stories, Following Existing Patterns)
simple_enhancement_sequence:
- step: enhancement_type
action: choose approach
notes: "Choose between creating single story (simple API endpoint) or epic (1-3 related service changes)."
- id: quality-assurance
name: Testing & Quality Strategy
description: Plan comprehensive testing for service changes
steps:
- agent: qa
action: Service Testing Strategy
description: >-
Design testing approach for service modernization
inputs:
- refactoring-strategy
- api-versioning-strategy
outputs:
- service-test-strategy
- contract-testing-plan
- performance-testing-plan
- chaos-testing-strategy
prompts:
- "Design comprehensive service testing"
- "Plan contract tests for API evolution"
- "Design chaos engineering tests"
- agent: pm|po|sm
creates: brownfield_epic OR brownfield_story
uses: brownfield-create-epic OR brownfield-create-story
notes: "Create focused service enhancement with existing API integration. Choose agent based on team preference and context."
- id: monitoring-observability
name: Enhanced Observability
description: Plan improved monitoring and observability
steps:
- agent: devops
action: Observability Enhancement
description: >-
Design enhanced monitoring, logging, and alerting
inputs:
- target-architecture
- performance-bottlenecks
outputs:
- observability-strategy
- sli-slo-definitions
- alerting-improvements
- dashboards-design
prompts:
- "Design comprehensive service observability"
- "Define SLIs and SLOs for the service"
- workflow_end:
action: move_to_ide
notes: "Service enhancement defined. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
- id: implementation-planning
name: Phased Implementation
description: Create detailed implementation plan
steps:
- agent: sm
action: Migration Story Planning
description: >-
Create stories for incremental service migration
inputs:
- migration-roadmap
- refactoring-strategy
outputs:
- migration-stories
- implementation-phases
- dependency-management
prompts:
- "Break down migration into safe phases"
- "Plan story dependencies and risks"
flow_diagram: |
```mermaid
graph TD
A[Start: Service Enhancement] --> B{Enhancement Complexity?}
B -->|Complex/Significant| C[analyst: analyze existing service]
B -->|Simple| D{1 Story or 2-3 Stories?}
C --> E[pm: brownfield-prd.md]
E --> F[architect: brownfield-architecture.md]
F --> G[po: validate with brownfield-checklist]
G --> H{PO finds issues?}
H -->|Yes| I[Return to relevant agent for fixes]
H -->|No| J[Move to IDE Environment]
I --> G
D -->|1 Story| K[pm/po/sm: brownfield-create-story]
D -->|2-3 Stories| L[pm/po/sm: brownfield-create-epic]
K --> M[Move to IDE Environment]
L --> M
style J fill:#90EE90
style M fill:#90EE90
style E fill:#FFE4B5
style F fill:#FFE4B5
style K fill:#FFB6C1
style L fill:#FFB6C1
```
transitions:
- from: service-analysis
to: enhancement-planning
condition: assessment complete
- from: enhancement-planning
to: incremental-refactoring
condition: strategy defined
- from: incremental-refactoring
to: api-evolution
condition: refactoring planned
- from: api-evolution
to: data-strategy
condition: api strategy defined
- from: data-strategy
to: quality-assurance
condition: data strategy planned
- from: quality-assurance
to: monitoring-observability
condition: testing planned
- from: monitoring-observability
to: implementation-planning
condition: observability designed
decision_guidance:
use_complex_sequence_when:
- Service enhancement requires multiple coordinated stories (4+)
- API versioning or breaking changes needed
- Database schema changes required
- Performance or scalability improvements needed
- Multiple integration points affected
special_considerations:
- name: Zero Downtime
description: Ensure service remains available during migration
- name: Data Integrity
description: Maintain data consistency throughout migration
- name: Client Impact
description: Minimize impact on service consumers
- name: Rollback Plan
description: Always have a way to revert changes safely
- name: Performance SLA
description: Maintain or improve existing performance SLAs
use_simple_sequence_when:
- Adding simple endpoints or modifying existing ones
- Enhancement follows existing service patterns
- API compatibility maintained
- Risk to existing service is low
- Change is isolated with clear boundaries
handoff_prompts:
analyst_to_pm: "Service analysis complete. Create comprehensive brownfield PRD with service integration strategy."
pm_to_architect: "Brownfield PRD ready. Save it as docs/brownfield-prd.md, then create the service architecture."
architect_to_po: "Architecture complete. Save it as docs/brownfield-architecture.md. Please validate all artifacts for service integration safety."
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
simple_to_ide: "Service enhancement defined with existing API integration. Move to IDE environment to begin development."
complex_complete: "All brownfield planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."

302
agent-team-workflows/brownfield-ui.yml
View File

@@ -2,216 +2,126 @@ workflow:
id: brownfield-ui
name: Brownfield UI/Frontend Enhancement
description: >-
Workflow for modernizing, redesigning, or enhancing existing frontend applications.
Handles UI/UX improvements, framework migrations, and frontend refactoring.
Agent workflow for enhancing existing frontend applications with new features,
modernization, or design improvements. Handles existing UI analysis and safe integration.
type: brownfield
project_types:
- ui-modernization
- framework-migration
- design-refresh
- frontend-refactoring
- frontend-enhancement
stages:
- id: ui-analysis
name: Current UI Assessment
description: Analyze existing frontend and identify improvement areas
steps:
- agent: analyst
action: Frontend Assessment
description: >-
Analyze current frontend, user feedback, and performance issues
inputs:
- existing-frontend
- user-feedback
- analytics-data
outputs:
- frontend-assessment
- usability-issues
- performance-analysis
prompts:
- "Let's analyze the current frontend application"
- "What are users' main pain points with the current UI?"
- "Share analytics data or user feedback if available"
# For Complex UI Enhancements (Multiple Stories, Design Changes)
complex_enhancement_sequence:
- step: scope_assessment
agent: any
action: assess complexity
notes: "First, assess if this is a simple UI change (use simple_enhancement_sequence) or complex enhancement requiring full planning."
- agent: ux-expert
action: UX Audit
description: >-
Conduct comprehensive UX audit and competitive analysis
inputs:
- frontend-assessment
- user-feedback
outputs:
- ux-audit-report
- competitor-analysis
- accessibility-audit
prompts:
- "Let's audit the current user experience"
- "How do competitors handle similar flows?"
- step: ui_analysis
agent: analyst
action: analyze existing UI
notes: "Review existing frontend application, user feedback, analytics data, and identify improvement areas."
- id: enhancement-strategy
name: UI Enhancement Strategy
description: Define UI improvement strategy and goals
steps:
- agent: pm
action: UI Enhancement Planning
description: >-
Define enhancement goals, priorities, and success metrics
inputs:
- ux-audit-report
- usability-issues
outputs:
- ui-enhancement-strategy
- improvement-priorities
- success-metrics
prompts:
- "What are the priority UI improvements?"
- "Define success metrics for the redesign"
- agent: pm
creates: brownfield-prd.md
uses: brownfield-prd-tmpl
requires: existing_ui_analysis
notes: "Creates comprehensive brownfield PRD focused on UI enhancement with existing system analysis. SAVE OUTPUT: Copy final brownfield-prd.md to your project's docs/ folder."
- agent: ux-expert
action: Design Strategy
description: >-
Create design strategy and visual direction
inputs:
- ui-enhancement-strategy
- competitor-analysis
outputs:
- design-strategy
- visual-direction
- brand-evolution
prompts:
- "Define the new visual direction"
- "How should the brand evolve?"
- agent: ux-expert
creates: front-end-spec.md
uses: front-end-spec-tmpl
requires: brownfield-prd.md
notes: "Creates UI/UX specification for brownfield enhancement that integrates with existing design patterns. SAVE OUTPUT: Copy final front-end-spec.md to your project's docs/ folder."
- id: incremental-design
name: Incremental UI Design
description: Design improvements that can be rolled out incrementally
steps:
- agent: ux-expert
action: Progressive Design System
description: >-
Create new design system that can coexist with existing UI
inputs:
- design-strategy
- frontend-assessment
outputs:
- progressive-design-system
- component-migration-plan
- style-guide-evolution
prompts:
- "Design a system that can coexist with current UI"
- "Plan component-by-component migration"
- agent: ui-architect
creates: brownfield-architecture.md
uses: brownfield-architecture-tmpl
requires:
- brownfield-prd.md
- front-end-spec.md
notes: "Creates brownfield frontend architecture with component integration strategy and migration planning. SAVE OUTPUT: Copy final brownfield-architecture.md to your project's docs/ folder."
- agent: ui-architect
action: Frontend Migration Architecture
description: >-
Design technical approach for gradual frontend migration
inputs:
- progressive-design-system
- existing-frontend
outputs:
- migration-architecture
- component-strategy
- bundling-strategy
prompts:
- "Design incremental migration approach"
- "How to avoid breaking existing functionality?"
- agent: po
validates: all_artifacts
uses: brownfield-checklist
notes: "Validates all brownfield documents for UI integration safety and design consistency. May require updates to any document."
- id: user-validation
name: User Testing & Validation
description: Validate new designs with users
steps:
- agent: ux-expert
action: Prototype & Test
description: >-
Create prototypes and conduct user testing
inputs:
- progressive-design-system
- improvement-priorities
outputs:
- interactive-prototypes
- user-testing-results
- design-iterations
prompts:
- "Let's create testable prototypes"
- "Test with real users and iterate"
- agent: various
updates: any_flagged_documents
condition: po_checklist_issues
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
- id: technical-planning
name: Implementation Planning
description: Plan technical implementation of UI changes
steps:
- agent: ui-architect
action: Technical Implementation Plan
description: >-
Create detailed technical plan for UI migration
inputs:
- migration-architecture
- design-iterations
outputs:
- implementation-roadmap
- risk-mitigation-plan
- rollback-strategy
prompts:
- "Create step-by-step implementation plan"
- "Plan for safe rollbacks if needed"
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
- agent: qa
action: UI Testing Strategy
description: >-
Plan testing approach for UI changes
inputs:
- implementation-roadmap
- user-testing-results
outputs:
- ui-test-strategy
- visual-regression-tests
- cross-browser-testing
- accessibility-testing
prompts:
- "Plan comprehensive UI testing"
- "Ensure no regressions in existing flows"
# For Simple UI Enhancements (1-3 Stories, Following Existing Design)
simple_enhancement_sequence:
- step: enhancement_type
action: choose approach
notes: "Choose between creating single story (simple component change) or epic (1-3 related UI changes)."
- id: deployment-strategy
name: Gradual Rollout Planning
description: Plan safe deployment of UI changes
steps:
- agent: ui-architect
action: Feature Flag Strategy
description: >-
Design feature flagging for gradual UI rollout
inputs:
- implementation-roadmap
- risk-mitigation-plan
outputs:
- feature-flag-design
- a-b-testing-plan
- monitoring-strategy
prompts:
- "Design A/B testing for new UI components"
- "Plan feature flags for safe rollout"
- agent: pm|po|sm
creates: brownfield_epic OR brownfield_story
uses: brownfield-create-epic OR brownfield-create-story
notes: "Create focused UI enhancement with existing design system integration. Choose agent based on team preference and context."
transitions:
- from: ui-analysis
to: enhancement-strategy
condition: assessment complete
- from: enhancement-strategy
to: incremental-design
condition: strategy defined
- from: incremental-design
to: user-validation
condition: designs ready
- from: user-validation
to: technical-planning
condition: designs validated
- from: technical-planning
to: deployment-strategy
condition: implementation planned
- workflow_end:
action: move_to_ide
notes: "UI enhancement defined. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
special_considerations:
- name: User Adoption
description: Plan for user training and change management
- name: SEO Impact
description: Ensure URL structure and SEO aren't negatively affected
- name: Performance
description: Maintain or improve existing performance metrics
- name: Analytics
description: Preserve analytics tracking through UI changes
flow_diagram: |
```mermaid
graph TD
A[Start: UI Enhancement] --> B{Enhancement Complexity?}
B -->|Complex/Significant| C[analyst: analyze existing UI]
B -->|Simple| D{1 Story or 2-3 Stories?}
C --> E[pm: brownfield-prd.md]
E --> F[ux-expert: front-end-spec.md]
F --> G[ui-architect: brownfield-architecture.md]
G --> H[po: validate with brownfield-checklist]
H --> I{PO finds issues?}
I -->|Yes| J[Return to relevant agent for fixes]
I -->|No| K[Move to IDE Environment]
J --> H
D -->|1 Story| L[pm/po/sm: brownfield-create-story]
D -->|2-3 Stories| M[pm/po/sm: brownfield-create-epic]
L --> N[Move to IDE Environment]
M --> N
style K fill:#90EE90
style N fill:#90EE90
style E fill:#FFE4B5
style F fill:#FFE4B5
style G fill:#FFE4B5
style L fill:#FFB6C1
style M fill:#FFB6C1
```
decision_guidance:
use_complex_sequence_when:
- UI enhancement requires multiple coordinated stories (4+)
- Design system changes needed
- New component patterns required
- User research and testing needed
- Multiple team members will work on related changes
use_simple_sequence_when:
- Enhancement can be completed in 1-3 stories
- Follows existing design patterns exactly
- Component changes are isolated
- Risk to existing UI is low
- Change maintains current user experience
handoff_prompts:
analyst_to_pm: "UI analysis complete. Create comprehensive brownfield PRD with UI integration strategy."
pm_to_ux: "Brownfield PRD ready. Save it as docs/brownfield-prd.md, then create the UI/UX specification."
ux_to_architect: "UI/UX spec complete. Save it as docs/front-end-spec.md, then create the frontend architecture."
architect_to_po: "Architecture complete. Save it as docs/brownfield-architecture.md. Please validate all artifacts for UI integration safety."
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
simple_to_ide: "UI enhancement defined with existing design integration. Move to IDE environment to begin development."
complex_complete: "All brownfield planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."

125
agent-team-workflows/greenfield-fullstack.yml
View File

@@ -2,15 +2,18 @@ workflow:
id: greenfield-fullstack
name: Greenfield Full-Stack Application Development
description: >-
Agent workflow for building production-ready full-stack applications
from concept to development-ready artifacts.
Agent workflow for building full-stack applications from concept to development.
Supports both comprehensive planning for complex projects and rapid prototyping for simple ones.
type: greenfield
project_types:
- web-app
- saas
- enterprise-app
- prototype
- mvp
sequence:
# For Complex Projects (Production-Ready, Multiple Features)
complex_project_sequence:
- agent: analyst
creates: project-brief.md
optional_steps:
@@ -18,7 +21,7 @@ workflow:
- market_research_prompt
notes: "Can do brainstorming first, then optional deep research before creating project brief. SAVE OUTPUT: Copy final project-brief.md to your project's docs/ folder."
- agent: pm
- agent: pm
creates: prd.md
requires: project-brief.md
notes: "Creates PRD from project brief using prd-tmpl. SAVE OUTPUT: Copy final prd.md to your project's docs/ folder."
@@ -38,7 +41,7 @@ workflow:
- agent: fullstack-architect
creates: fullstack-architecture.md
requires:
requires:
- prd.md
- front-end-spec.md
optional_steps:
@@ -75,47 +78,91 @@ workflow:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
# For Simple Projects (Prototypes, MVPs, Quick Experiments)
simple_project_sequence:
- step: project_scope
action: assess complexity
notes: "First, assess if this needs full planning (use complex_project_sequence) or can be a simple prototype/MVP."
- agent: analyst
creates: project-brief.md
optional_steps:
- brainstorming_session
notes: "Creates focused project brief for simple project. SAVE OUTPUT: Copy final project-brief.md to your project's docs/ folder."
- agent: pm
creates: simple_epic OR single_story
uses: create-epic OR create-story
requires: project-brief.md
notes: "Create simple epic or story instead of full PRD for rapid development. Choose based on scope."
- workflow_end:
action: move_to_ide
notes: "Simple project defined. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
flow_diagram: |
```mermaid
graph TD
A[Start] --> B[analyst: project-brief.md]
B --> C[pm: prd.md]
C --> D[ux-expert: front-end-spec.md]
D --> D2{Generate v0 prompt?}
D2 -->|Yes| D3[ux-expert: create v0 prompt]
D2 -->|No| E[fullstack-architect: fullstack-architecture.md]
D3 --> D4[User: generate UI in v0/Lovable]
D4 --> E
E --> F{Architecture suggests PRD changes?}
F -->|Yes| G[pm: update prd.md]
F -->|No| H[po: validate all artifacts]
G --> H
H --> I{PO finds issues?}
I -->|Yes| J[Return to relevant agent for fixes]
I -->|No| K{Generated UI?}
K -->|Yes| L[Guide project structure setup]
K -->|No| M[Guide development order]
L --> M
M --> N[Move to IDE Environment]
J --> H
A[Start: Greenfield Project] --> B{Project Complexity?}
B -->|Complex/Production| C[analyst: project-brief.md]
B -->|Simple/Prototype| D[analyst: focused project-brief.md]
B -.-> B1[Optional: brainstorming]
B -.-> B2[Optional: market research]
D -.-> D1[Optional: user research]
E -.-> E1[Optional: technical research]
C --> E[pm: prd.md]
E --> F[ux-expert: front-end-spec.md]
F --> F2{Generate v0 prompt?}
F2 -->|Yes| F3[ux-expert: create v0 prompt]
F2 -->|No| G[fullstack-architect: fullstack-architecture.md]
F3 --> F4[User: generate UI in v0/Lovable]
F4 --> G
G --> H{Architecture suggests PRD changes?}
H -->|Yes| I[pm: update prd.md]
H -->|No| J[po: validate all artifacts]
I --> J
J --> K{PO finds issues?}
K -->|Yes| L[Return to relevant agent for fixes]
K -->|No| M[Move to IDE Environment]
L --> J
style N fill:#90EE90
style D3 fill:#E6E6FA
style D4 fill:#E6E6FA
style L fill:#E6E6FA
style M fill:#E6E6FA
style B fill:#FFE4B5
D --> N[pm: simple epic or story]
N --> O[Move to IDE Environment]
C -.-> C1[Optional: brainstorming]
C -.-> C2[Optional: market research]
F -.-> F1[Optional: user research]
G -.-> G1[Optional: technical research]
D -.-> D1[Optional: brainstorming]
style M fill:#90EE90
style O fill:#90EE90
style F3 fill:#E6E6FA
style F4 fill:#E6E6FA
style C fill:#FFE4B5
style D fill:#FFE4B5
style E fill:#FFE4B5
style F fill:#FFE4B5
style G fill:#FFE4B5
style D fill:#FFB6C1
style N fill:#FFB6C1
```
decision_guidance:
use_complex_sequence_when:
- Building production-ready applications
- Multiple team members will be involved
- Complex feature requirements (4+ stories)
- Need comprehensive documentation
- Long-term maintenance expected
- Enterprise or customer-facing applications
use_simple_sequence_when:
- Building prototypes or MVPs
- Solo developer or small team
- Simple requirements (1-3 stories)
- Quick experiments or proof-of-concepts
- Short-term or throwaway projects
- Learning or educational projects
handoff_prompts:
# Complex sequence prompts
analyst_to_pm: "Project brief is complete. Save it as docs/project-brief.md in your project, then create the PRD."
pm_to_ux: "PRD is ready. Save it as docs/prd.md in your project, then create the UI/UX specification."
ux_to_architect: "UI/UX spec complete. Save it as docs/front-end-spec.md in your project, then create the fullstack architecture."
@@ -123,4 +170,8 @@ workflow:
architect_to_pm: "Please update the PRD with the suggested story changes, then re-export the complete prd.md to docs/."
updated_to_po: "All documents ready in docs/ folder. Please validate all artifacts for consistency."
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
workflow_complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
complex_complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
# Simple sequence prompts
simple_analyst_to_pm: "Focused project brief complete. Save it as docs/project-brief.md, then create simple epic or story for rapid development."
simple_complete: "Simple project defined. Move to IDE environment to begin development."

99
agent-team-workflows/greenfield-service.yml
View File

@@ -2,16 +2,19 @@ workflow:
id: greenfield-service
name: Greenfield Service/API Development
description: >-
Agent workflow for building REST APIs, GraphQL services, or microservices
without frontend requirements.
Agent workflow for building backend services from concept to development.
Supports both comprehensive planning for complex services and rapid prototyping for simple APIs.
type: greenfield
project_types:
- rest-api
- graphql-api
- microservice
- backend-service
- api-prototype
- simple-service
sequence:
# For Complex Services (Production APIs, Multiple Endpoints)
complex_service_sequence:
- agent: analyst
creates: project-brief.md
optional_steps:
@@ -51,36 +54,90 @@ workflow:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
# For Simple Services (Simple APIs, Single Purpose Services)
simple_service_sequence:
- step: service_scope
action: assess complexity
notes: "First, assess if this needs full planning (use complex_service_sequence) or can be a simple API/service."
- agent: analyst
creates: project-brief.md
optional_steps:
- brainstorming_session
notes: "Creates focused project brief for simple service. SAVE OUTPUT: Copy final project-brief.md to your project's docs/ folder."
- agent: pm
creates: simple_epic OR single_story
uses: create-epic OR create-story
requires: project-brief.md
notes: "Create simple epic or story for API endpoints instead of full PRD for rapid development."
- workflow_end:
action: move_to_ide
notes: "Simple service defined. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
flow_diagram: |
```mermaid
graph TD
A[Start] --> B[analyst: project-brief.md]
B --> C[pm: prd.md]
C --> D[architect: architecture.md]
D --> E{Architecture suggests PRD changes?}
E -->|Yes| F[pm: update prd.md]
E -->|No| G[po: validate all artifacts]
F --> G
G --> H{PO finds issues?}
H -->|Yes| I[Return to relevant agent for fixes]
H -->|No| J[Move to IDE Environment]
I --> G
A[Start: Service Development] --> B{Service Complexity?}
B -->|Complex/Production| C[analyst: project-brief.md]
B -->|Simple/Prototype| D[analyst: focused project-brief.md]
B -.-> B1[Optional: brainstorming]
B -.-> B2[Optional: market research]
D -.-> D1[Optional: technical research]
C --> E[pm: prd.md]
E --> F[architect: architecture.md]
F --> G{Architecture suggests PRD changes?}
G -->|Yes| H[pm: update prd.md]
G -->|No| I[po: validate all artifacts]
H --> I
I --> J{PO finds issues?}
J -->|Yes| K[Return to relevant agent for fixes]
J -->|No| L[Move to IDE Environment]
K --> I
style J fill:#90EE90
style B fill:#FFE4B5
D --> M[pm: simple epic or story]
M --> N[Move to IDE Environment]
C -.-> C1[Optional: brainstorming]
C -.-> C2[Optional: market research]
F -.-> F1[Optional: technical research]
D -.-> D1[Optional: brainstorming]
style L fill:#90EE90
style N fill:#90EE90
style C fill:#FFE4B5
style D fill:#FFE4B5
style E fill:#FFE4B5
style F fill:#FFE4B5
style D fill:#FFB6C1
style M fill:#FFB6C1
```
decision_guidance:
use_complex_sequence_when:
- Building production APIs or microservices
- Multiple endpoints and complex business logic
- Need comprehensive documentation and testing
- Multiple team members will be involved
- Long-term maintenance expected
- Enterprise or external-facing APIs
use_simple_sequence_when:
- Building simple APIs or single-purpose services
- Few endpoints with straightforward logic
- Prototyping or proof-of-concept APIs
- Solo developer or small team
- Internal tools or utilities
- Learning or experimental projects
handoff_prompts:
# Complex sequence prompts
analyst_to_pm: "Project brief is complete. Save it as docs/project-brief.md in your project, then create the PRD."
pm_to_architect: "PRD is ready. Save it as docs/prd.md in your project, then create the service architecture."
architect_review: "Architecture complete. Save it as docs/architecture.md. Do you suggest any changes to the PRD stories or need new stories added?"
architect_to_pm: "Please update the PRD with the suggested story changes, then re-export the complete prd.md to docs/."
updated_to_po: "All documents ready in docs/ folder. Please validate all artifacts for consistency."
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
workflow_complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
complex_complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
# Simple sequence prompts
simple_analyst_to_pm: "Focused project brief complete. Save it as docs/project-brief.md, then create simple epic or story for API development."
simple_complete: "Simple service defined. Move to IDE environment to begin development."

117
agent-team-workflows/greenfield-ui.yml
View File

@@ -2,16 +2,19 @@ workflow:
id: greenfield-ui
name: Greenfield UI/Frontend Development
description: >-
Agent workflow for building frontend applications that consume existing APIs.
Perfect for SPAs, mobile apps, or micro-frontends.
Agent workflow for building frontend applications from concept to development.
Supports both comprehensive planning for complex UIs and rapid prototyping for simple interfaces.
type: greenfield
project_types:
- spa
- mobile-app
- micro-frontend
- static-site
- ui-prototype
- simple-interface
sequence:
# For Complex UIs (Production Apps, Multiple Views)
complex_ui_sequence:
- agent: analyst
creates: project-brief.md
optional_steps:
@@ -70,45 +73,91 @@ workflow:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
# For Simple UIs (Simple Interfaces, Few Components)
simple_ui_sequence:
- step: ui_scope
action: assess complexity
notes: "First, assess if this needs full planning (use complex_ui_sequence) or can be a simple interface."
- agent: analyst
creates: project-brief.md
optional_steps:
- brainstorming_session
notes: "Creates focused project brief for simple UI. SAVE OUTPUT: Copy final project-brief.md to your project's docs/ folder."
- agent: ux-expert
creates: simple_wireframes OR quick_spec
uses: create-epic OR create-story
requires: project-brief.md
notes: "Create simple wireframes and component list instead of full UI/UX spec for rapid development."
- workflow_end:
action: move_to_ide
notes: "Simple UI defined. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
flow_diagram: |
```mermaid
graph TD
A[Start] --> B[analyst: project-brief.md]
B --> C[pm: prd.md]
C --> D[ux-expert: front-end-spec.md]
D --> D2{Generate v0 prompt?}
D2 -->|Yes| D3[ux-expert: create v0 prompt]
D2 -->|No| E[ui-architect: front-end-architecture.md]
D3 --> D4[User: generate UI in v0/Lovable]
D4 --> E
E --> F{Architecture suggests PRD changes?}
F -->|Yes| G[pm: update prd.md]
F -->|No| H[po: validate all artifacts]
G --> H
H --> I{PO finds issues?}
I -->|Yes| J[Return to relevant agent for fixes]
I -->|No| K{Generated UI?}
K -->|Yes| L[Guide project structure setup]
K -->|No| M[Move to IDE Environment]
L --> M
J --> H
A[Start: UI Development] --> B{UI Complexity?}
B -->|Complex/Production| C[analyst: project-brief.md]
B -->|Simple/Prototype| D[analyst: focused project-brief.md]
B -.-> B1[Optional: brainstorming]
B -.-> B2[Optional: market research]
D -.-> D1[Optional: user research]
E -.-> E1[Optional: technical research]
C --> E[pm: prd.md]
E --> F[ux-expert: front-end-spec.md]
F --> F2{Generate v0 prompt?}
F2 -->|Yes| F3[ux-expert: create v0 prompt]
F2 -->|No| G[ui-architect: front-end-architecture.md]
F3 --> F4[User: generate UI in v0/Lovable]
F4 --> G
G --> H{Architecture suggests PRD changes?}
H -->|Yes| I[pm: update prd.md]
H -->|No| J[po: validate all artifacts]
I --> J
J --> K{PO finds issues?}
K -->|Yes| L[Return to relevant agent for fixes]
K -->|No| M[Move to IDE Environment]
L --> J
D --> N[ux-expert: simple wireframes]
N --> O[Move to IDE Environment]
C -.-> C1[Optional: brainstorming]
C -.-> C2[Optional: market research]
F -.-> F1[Optional: user research]
G -.-> G1[Optional: technical research]
D -.-> D1[Optional: brainstorming]
style M fill:#90EE90
style D3 fill:#E6E6FA
style D4 fill:#E6E6FA
style L fill:#E6E6FA
style B fill:#FFE4B5
style O fill:#90EE90
style F3 fill:#E6E6FA
style F4 fill:#E6E6FA
style C fill:#FFE4B5
style D fill:#FFE4B5
style E fill:#FFE4B5
style F fill:#FFE4B5
style G fill:#FFE4B5
style D fill:#FFB6C1
style N fill:#FFB6C1
```
decision_guidance:
use_complex_sequence_when:
- Building production frontend applications
- Multiple views/pages with complex interactions
- Need comprehensive UI/UX design and testing
- Multiple team members will be involved
- Long-term maintenance expected
- Customer-facing applications
use_simple_sequence_when:
- Building simple interfaces or prototypes
- Few views with straightforward interactions
- Internal tools or admin interfaces
- Solo developer or small team
- Quick experiments or proof-of-concepts
- Learning or educational projects
handoff_prompts:
# Complex sequence prompts
analyst_to_pm: "Project brief is complete. Save it as docs/project-brief.md in your project, then create the PRD."
pm_to_ux: "PRD is ready. Save it as docs/prd.md in your project, then create the UI/UX specification."
ux_to_architect: "UI/UX spec complete. Save it as docs/front-end-spec.md in your project, then create the frontend architecture."
@@ -116,4 +165,8 @@ workflow:
architect_to_pm: "Please update the PRD with the suggested story changes, then re-export the complete prd.md to docs/."
updated_to_po: "All documents ready in docs/ folder. Please validate all artifacts for consistency."
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
workflow_complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
complex_complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
# Simple sequence prompts
simple_analyst_to_ux: "Focused project brief complete. Save it as docs/project-brief.md, then create simple wireframes for rapid development."
simple_complete: "Simple UI defined. Move to IDE environment to begin development."

1
agents/architect.yml
View File

@@ -14,6 +14,7 @@ dependencies:
templates:
- architecture-tmpl
- infrastructure-architecture-tmpl
- brownfield-architecture-tmpl
checklists:
- architect-checklist
data:

3
agents/pm.yml
View File

@@ -12,8 +12,11 @@ dependencies:
- create-doc-from-template
- correct-course
- create-deep-research-prompt
- brownfield-create-epic
- brownfield-create-story
templates:
- prd-tmpl
- brownfield-prd-tmpl
checklists:
- pm-checklist
- change-checklist

3
agents/po.yml
View File

@@ -12,11 +12,14 @@ dependencies:
- execute-checklist
- shard-doc
- correct-course
- brownfield-create-epic
- brownfield-create-story
templates:
- story-tmpl
checklists:
- po-master-checklist
- change-checklist
- brownfield-checklist
data: []
utils:
- template-format

2
agents/sm.yml
View File

@@ -10,6 +10,8 @@ dependencies:
- create-doc-from-template
- create-next-story
- index-docs
- brownfield-create-epic
- brownfield-create-story
templates:
- story-tmpl
checklists:

77
bmad-core/checklists/architect-checklist.md
View File

@@ -2,8 +2,36 @@
This checklist serves as a comprehensive framework for the Architect to validate the technical design and architecture before development execution. The Architect should systematically work through each item, ensuring the architecture is robust, scalable, secure, and aligned with the product requirements.
[[LLM: INITIALIZATION INSTRUCTIONS - REQUIRED ARTIFACTS
Before proceeding with this checklist, ensure you have access to:
1. architecture.md - The primary architecture document (check docs/architecture.md)
2. prd.md - Product Requirements Document for requirements alignment (check docs/prd.md)
3. Any system diagrams referenced in the architecture
4. API documentation if available
5. Technology stack details and version specifications
IMPORTANT: If any required documents are missing or inaccessible, immediately ask the user for their location or content before proceeding.
VALIDATION APPROACH:
For each section, you must:
1. Deep Analysis - Don't just check boxes, thoroughly analyze each item against the provided documentation
2. Evidence-Based - Cite specific sections or quotes from the documents when validating
3. Critical Thinking - Question assumptions and identify gaps, not just confirm what's present
4. Risk Assessment - Consider what could go wrong with each architectural decision
EXECUTION MODE:
Ask the user if they want to work through the checklist:
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
## 1. REQUIREMENTS ALIGNMENT
[[LLM: Before evaluating this section, take a moment to fully understand the product's purpose and goals from the PRD. What is the core problem being solved? Who are the users? What are the critical success factors? Keep these in mind as you validate alignment. For each item, don't just check if it's mentioned - verify that the architecture provides a concrete technical solution.]]
### 1.1 Functional Requirements Coverage
- [ ] Architecture supports all functional requirements in the PRD
@@ -30,6 +58,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 2. ARCHITECTURE FUNDAMENTALS
[[LLM: Architecture clarity is crucial for successful implementation. As you review this section, visualize the system as if you were explaining it to a new developer. Are there any ambiguities that could lead to misinterpretation? Would an AI agent be able to implement this architecture without confusion? Look for specific diagrams, component definitions, and clear interaction patterns.]]
### 2.1 Architecture Clarity
- [ ] Architecture is documented with clear diagrams
@@ -64,6 +94,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 3. TECHNICAL STACK & DECISIONS
[[LLM: Technology choices have long-term implications. For each technology decision, consider: Is this the simplest solution that could work? Are we over-engineering? Will this scale? What are the maintenance implications? Are there security vulnerabilities in the chosen versions? Verify that specific versions are defined, not ranges.]]
### 3.1 Technology Selection
- [ ] Selected technologies meet all requirements
@@ -98,6 +130,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 4. RESILIENCE & OPERATIONAL READINESS
[[LLM: Production systems fail in unexpected ways. As you review this section, think about Murphy's Law - what could go wrong? Consider real-world scenarios: What happens during peak load? How does the system behave when a critical service is down? Can the operations team diagnose issues at 3 AM? Look for specific resilience patterns, not just mentions of "error handling".]]
### 4.1 Error Handling & Resilience
- [ ] Error handling strategy is comprehensive
@@ -132,6 +166,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 5. SECURITY & COMPLIANCE
[[LLM: Security is not optional. Review this section with a hacker's mindset - how could someone exploit this system? Also consider compliance: Are there industry-specific regulations that apply? GDPR? HIPAA? PCI? Ensure the architecture addresses these proactively. Look for specific security controls, not just general statements.]]
### 5.1 Authentication & Authorization
- [ ] Authentication mechanism is clearly defined
@@ -166,6 +202,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 6. IMPLEMENTATION GUIDANCE
[[LLM: Clear implementation guidance prevents costly mistakes. As you review this section, imagine you're a developer starting on day one. Do they have everything they need to be productive? Are coding standards clear enough to maintain consistency across the team? Look for specific examples and patterns.]]
### 6.1 Coding Standards & Practices
- [ ] Coding standards are defined
@@ -200,6 +238,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 7. DEPENDENCY & INTEGRATION MANAGEMENT
[[LLM: Dependencies are often the source of production issues. For each dependency, consider: What happens if it's unavailable? Is there a newer version with security patches? Are we locked into a vendor? What's our contingency plan? Verify specific versions and fallback strategies.]]
### 7.1 External Dependencies
- [ ] All external dependencies are identified
@@ -226,6 +266,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 8. AI AGENT IMPLEMENTATION SUITABILITY
[[LLM: This architecture may be implemented by AI agents. Review with extreme clarity in mind. Are patterns consistent? Is complexity minimized? Would an AI agent make incorrect assumptions? Remember: explicit is better than implicit. Look for clear file structures, naming conventions, and implementation patterns.]]
### 8.1 Modularity for AI Agents
- [ ] Components are sized appropriately for AI agent implementation
@@ -257,3 +299,38 @@ This checklist serves as a comprehensive framework for the Architect to validate
- [ ] Self-healing mechanisms are incorporated where possible
- [ ] Testing patterns are clearly defined
- [ ] Debugging guidance is provided
[[LLM: FINAL VALIDATION REPORT GENERATION
Now that you've completed the checklist, generate a comprehensive validation report that includes:
1. Executive Summary
- Overall architecture readiness (High/Medium/Low)
- Critical risks identified
- Key strengths of the architecture
2. Section Analysis
- Pass rate for each major section (percentage of items passed)
- Most concerning failures or gaps
- Sections requiring immediate attention
3. Risk Assessment
- Top 5 risks by severity
- Mitigation recommendations for each
- Timeline impact of addressing issues
4. Recommendations
- Must-fix items before development
- Should-fix items for better quality
- Nice-to-have improvements
5. AI Implementation Readiness
- Specific concerns for AI agent implementation
- Areas needing additional clarification
- Complexity hotspots to address
After presenting the report, ask the user if they would like detailed analysis of any specific section, especially those with warnings or failures.]]

480
bmad-core/checklists/brownfield-checklist.md Normal file
View File

@@ -0,0 +1,480 @@
# Brownfield Enhancement Validation Checklist
This checklist serves as a comprehensive framework for Product Owners to validate brownfield enhancements before development execution. It ensures thorough analysis of existing systems, proper integration planning, and risk mitigation for working with existing codebases.
[[LLM: CRITICAL INITIALIZATION - BROWNFIELD CONTEXT
This checklist requires extensive access to the existing project. Before proceeding, ensure you have:
1. brownfield-prd.md - The brownfield product requirements (check docs/brownfield-prd.md)
2. brownfield-architecture.md - The enhancement architecture (check docs/brownfield-architecture.md)
3. Existing Project Access:
- Full source code repository access
- Current deployment configuration
- Database schemas and data models
- API documentation (internal and external)
- Infrastructure configuration
- CI/CD pipeline configuration
- Current monitoring/logging setup
4. Optional but Valuable:
- existing-project-docs.md
- tech-stack.md with version details
- source-tree.md or actual file structure
- Performance benchmarks
- Known issues/bug tracker access
- Team documentation/wikis
IMPORTANT: If you don't have access to the existing project codebase, STOP and request access. Brownfield validation cannot be properly completed without examining the actual system being enhanced.
CRITICAL MINDSET: You are validating changes to a LIVE SYSTEM. Every decision has the potential to break existing functionality. Approach this with:
1. Extreme Caution - Assume every change could have unintended consequences
2. Deep Investigation - Don't trust documentation alone, verify against actual code
3. Integration Focus - The seams between new and old are where failures occur
4. User Impact - Existing users depend on current functionality, preserve their workflows
5. Technical Debt Awareness - Understand what compromises exist and why
EXECUTION MODE:
Ask the user if they want to work through the checklist:
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
## 1. EXISTING PROJECT ANALYSIS VALIDATION
[[LLM: Begin by conducting a thorough investigation of the existing system. Don't just read documentation - examine actual code, configuration files, and deployment scripts. Look for:
- Undocumented behaviors that users might depend on
- Technical debt that could complicate integration
- Patterns and conventions that new code must follow
- Hidden dependencies not mentioned in documentation
As you validate each item below, cite specific files, code sections, or configuration details as evidence. For each check, provide specific examples from the codebase.]]
### 1.1 Project Documentation Completeness
- [ ] All required existing project documentation has been located and analyzed
- [ ] Tech stack documentation is current and accurate
- [ ] Source tree/architecture overview exists and is up-to-date
- [ ] Coding standards documentation reflects actual codebase practices
- [ ] API documentation exists and covers all active endpoints
- [ ] External API integrations are documented with current versions
- [ ] UX/UI guidelines exist and match current implementation
- [ ] Any missing documentation has been identified and creation planned
### 1.2 Existing System Understanding
- [ ] Current project purpose and core functionality clearly understood
- [ ] Existing technology stack versions accurately identified
- [ ] Current architecture patterns and conventions documented
- [ ] Existing deployment and infrastructure setup analyzed
- [ ] Performance characteristics and constraints identified
- [ ] Security measures and compliance requirements documented
- [ ] Known technical debt and limitation areas identified
- [ ] Active maintenance and support processes understood
### 1.3 Codebase Analysis Quality
- [ ] File structure and organization patterns documented
- [ ] Naming conventions and coding patterns identified
- [ ] Testing frameworks and patterns analyzed
- [ ] Build and deployment processes understood
- [ ] Dependency management approach documented
- [ ] Configuration management patterns identified
- [ ] Error handling and logging patterns documented
- [ ] Integration points with external systems mapped
## 2. ENHANCEMENT SCOPE VALIDATION
[[LLM: The scope determines everything. Before validating, answer: Is this enhancement truly significant enough to warrant this comprehensive process, or would a simpler approach suffice? Consider:
- Could this be done as a simple feature addition?
- Are we over-engineering the solution?
- What's the minimum viable change that delivers value?
- Are we addressing the root cause or just symptoms?
Be prepared to recommend a simpler approach if the current plan is overkill. If the enhancement could be done in 1-2 stories, suggest using brownfield-create-epic or brownfield-create-story instead.]]
### 2.1 Complexity Assessment
- [ ] Enhancement complexity properly assessed (significant vs. simple)
- [ ] Scope justifies full PRD/Architecture process vs. simple epic/story creation
- [ ] Enhancement type clearly categorized (new feature, modification, integration, etc.)
- [ ] Impact assessment on existing codebase accurately evaluated
- [ ] Resource requirements appropriate for enhancement scope
- [ ] Timeline expectations realistic given existing system constraints
- [ ] Success criteria defined and measurable
- [ ] Rollback criteria and thresholds established
### 2.2 Integration Points Analysis
- [ ] All integration points with existing system identified
- [ ] Data flow between new and existing components mapped
- [ ] API integration requirements clearly defined
- [ ] Database schema integration approach specified
- [ ] UI/UX integration requirements documented
- [ ] Authentication/authorization integration planned
- [ ] External service integration impacts assessed
- [ ] Performance impact on existing system evaluated
### 2.3 Compatibility Requirements
- [ ] Existing API compatibility requirements defined
- [ ] Database schema backward compatibility ensured
- [ ] UI/UX consistency requirements specified
- [ ] Integration compatibility with existing workflows maintained
- [ ] Third-party service compatibility verified
- [ ] Browser/platform compatibility requirements unchanged
- [ ] Performance compatibility maintained or improved
- [ ] Security posture maintained or enhanced
## 3. RISK ASSESSMENT AND MITIGATION
[[LLM: This is the most critical section. Think like a pessimist - what's the worst that could happen? For each risk:
1. Identify specific code/configuration that could break
2. Trace the potential cascade of failures
3. Quantify the user impact (how many affected, how severely)
4. Validate that mitigation strategies are concrete, not theoretical
Remember: In production, Murphy's Law is gospel. If it can fail, it will fail. For each risk identified, cite specific code locations and estimate blast radius.]]
### 3.1 Technical Risk Evaluation
- [ ] Risk of breaking existing functionality assessed
- [ ] Database migration risks identified and mitigated
- [ ] API breaking change risks evaluated
- [ ] Deployment risks to existing system assessed
- [ ] Performance degradation risks identified
- [ ] Security vulnerability risks evaluated
- [ ] Third-party service integration risks assessed
- [ ] Data loss or corruption risks mitigated
### 3.2 Mitigation Strategy Completeness
- [ ] Rollback procedures clearly defined and tested
- [ ] Feature flag strategy implemented for gradual rollout
- [ ] Backup and recovery procedures updated
- [ ] Monitoring and alerting enhanced for new components
- [ ] Performance testing strategy includes existing functionality
- [ ] Security testing covers integration points
- [ ] User communication plan for changes prepared
- [ ] Support team training plan developed
### 3.3 Testing Strategy Validation
- [ ] Regression testing strategy covers all existing functionality
- [ ] Integration testing plan validates new-to-existing connections
- [ ] Performance testing includes existing system baseline
- [ ] Security testing covers enhanced attack surface
- [ ] User acceptance testing includes existing workflows
- [ ] Load testing validates system under enhanced load
- [ ] Disaster recovery testing updated for new components
- [ ] Automated test suite extended appropriately
## 4. ARCHITECTURE INTEGRATION VALIDATION
[[LLM: Architecture mismatches are subtle but deadly. As you review integration points:
1. Compare actual code patterns with proposed patterns - do they clash?
2. Check version compatibility down to patch levels
3. Verify assumptions about existing system behavior
4. Look for impedance mismatches in data models, API styles, error handling
5. Consider performance implications of integration overhead
If you find architectural incompatibilities, flag them as CRITICAL issues. Provide specific examples of pattern conflicts.]]
### 4.1 Technology Stack Alignment
- [ ] New technologies justified and compatible with existing stack
- [ ] Version compatibility verified across all dependencies
- [ ] Build process integration validated
- [ ] Deployment pipeline integration planned
- [ ] Configuration management approach consistent
- [ ] Monitoring and logging integration maintained
- [ ] Security tools and processes integration verified
- [ ] Development environment setup updated appropriately
### 4.2 Component Integration Design
- [ ] New components follow existing architectural patterns
- [ ] Component boundaries respect existing system design
- [ ] Data models integrate properly with existing schema
- [ ] API design consistent with existing endpoints
- [ ] Error handling consistent with existing patterns
- [ ] Authentication/authorization integration seamless
- [ ] Caching strategy compatible with existing approach
- [ ] Service communication patterns maintained
### 4.3 Code Organization Validation
- [ ] New code follows existing project structure conventions
- [ ] File naming patterns consistent with existing codebase
- [ ] Import/export patterns match existing conventions
- [ ] Testing file organization follows existing patterns
- [ ] Documentation approach consistent with existing standards
- [ ] Configuration file patterns maintained
- [ ] Asset organization follows existing conventions
- [ ] Build output organization unchanged
## 5. IMPLEMENTATION PLANNING VALIDATION
[[LLM: Implementation sequence can make or break a brownfield project. Review the plan with these questions:
- Can each story be deployed without breaking existing functionality?
- Are there hidden dependencies between stories?
- Is there a clear rollback point for each story?
- Will users experience degraded service during any phase?
- Are we testing the integration points sufficiently at each step?
Pay special attention to data migrations - they're often the source of catastrophic failures. For each story, verify it maintains system integrity.]]
### 5.1 Story Sequencing Validation
- [ ] Stories properly sequenced to minimize risk to existing system
- [ ] Each story maintains existing functionality integrity
- [ ] Story dependencies clearly identified and logical
- [ ] Rollback points defined for each story
- [ ] Integration verification included in each story
- [ ] Performance impact assessment included per story
- [ ] User impact minimized through story sequencing
- [ ] Value delivery incremental and testable
### 5.2 Development Approach Validation
- [ ] Development environment setup preserves existing functionality
- [ ] Local testing approach validated for existing features
- [ ] Code review process updated for integration considerations
- [ ] Pair programming approach planned for critical integration points
- [ ] Knowledge transfer plan for existing system context
- [ ] Documentation update process defined
- [ ] Communication plan for development team coordination
- [ ] Timeline buffer included for integration complexity
### 5.3 Deployment Strategy Validation
- [ ] Deployment approach minimizes downtime
- [ ] Blue-green or canary deployment strategy implemented
- [ ] Database migration strategy tested and validated
- [ ] Configuration management updated appropriately
- [ ] Environment-specific considerations addressed
- [ ] Health checks updated for new components
- [ ] Monitoring dashboards updated for new metrics
- [ ] Incident response procedures updated
## 6. STAKEHOLDER ALIGNMENT VALIDATION
[[LLM: Stakeholder surprises kill brownfield projects. Validate that:
1. ALL affected users have been identified (not just the obvious ones)
2. Impact on each user group is documented and communicated
3. Training needs are realistic (users resist change)
4. Support team is genuinely prepared (not just informed)
5. Business continuity isn't just assumed - it's planned
Look for hidden stakeholders - that batch job that runs at 2 AM, the partner API that depends on current behavior, the report that expects specific data formats. Check cron jobs, scheduled tasks, and external integrations.]]
### 6.1 User Impact Assessment
- [ ] Existing user workflows analyzed for impact
- [ ] User communication plan developed for changes
- [ ] Training materials updated for new functionality
- [ ] Support documentation updated comprehensively
- [ ] User feedback collection plan implemented
- [ ] Accessibility requirements maintained or improved
- [ ] Performance expectations managed appropriately
- [ ] Migration path for existing user data validated
### 6.2 Team Readiness Validation
- [ ] Development team familiar with existing codebase
- [ ] QA team understands existing test coverage
- [ ] DevOps team prepared for enhanced deployment complexity
- [ ] Support team trained on new functionality
- [ ] Product team aligned on success metrics
- [ ] Stakeholders informed of timeline and scope
- [ ] Resource allocation appropriate for enhanced complexity
- [ ] Escalation procedures defined for integration issues
### 6.3 Business Continuity Validation
- [ ] Critical business processes remain uninterrupted
- [ ] SLA requirements maintained throughout enhancement
- [ ] Customer impact minimized and communicated
- [ ] Revenue-generating features protected during enhancement
- [ ] Compliance requirements maintained throughout process
- [ ] Audit trail requirements preserved
- [ ] Data retention policies unaffected
- [ ] Business intelligence and reporting continuity maintained
## 7. DOCUMENTATION AND COMMUNICATION VALIDATION
[[LLM: In brownfield projects, documentation gaps cause integration failures. Verify that:
1. Documentation accurately reflects the current state (not the ideal state)
2. Integration points are documented with excessive detail
3. "Tribal knowledge" has been captured in writing
4. Change impacts are documented for every affected component
5. Runbooks are updated for new failure modes
If existing documentation is poor, this enhancement must improve it - technical debt compounds. Check actual code vs documentation for discrepancies.]]
### 7.1 Documentation Standards
- [ ] Enhancement documentation follows existing project standards
- [ ] Architecture documentation updated to reflect integration
- [ ] API documentation updated for new/changed endpoints
- [ ] User documentation updated for new functionality
- [ ] Developer documentation includes integration guidance
- [ ] Deployment documentation updated for enhanced process
- [ ] Troubleshooting guides updated for new components
- [ ] Change log properly maintained with detailed entries
### 7.2 Communication Plan Validation
- [ ] Stakeholder communication plan covers all affected parties
- [ ] Technical communication includes integration considerations
- [ ] User communication addresses workflow changes
- [ ] Timeline communication includes integration complexity buffers
- [ ] Risk communication includes mitigation strategies
- [ ] Success criteria communication aligned with measurements
- [ ] Feedback collection mechanisms established
- [ ] Escalation communication procedures defined
### 7.3 Knowledge Transfer Planning
- [ ] Existing system knowledge captured and accessible
- [ ] New functionality knowledge transfer plan developed
- [ ] Integration points knowledge documented comprehensively
- [ ] Troubleshooting knowledge base updated
- [ ] Code review knowledge shared across team
- [ ] Deployment knowledge transferred to operations team
- [ ] Monitoring and alerting knowledge documented
- [ ] Historical context preserved for future enhancements
## 8. SUCCESS METRICS AND MONITORING VALIDATION
[[LLM: Success in brownfield isn't just about new features working - it's about everything still working. Ensure:
1. Baseline metrics for existing functionality are captured
2. Degradation thresholds are defined (when do we rollback?)
3. New monitoring covers integration points, not just new components
4. Success criteria include "no regression" metrics
5. Long-term metrics capture gradual degradation
Without proper baselines, you can't prove the enhancement didn't break anything. Verify specific metrics and thresholds.]]
### 8.1 Success Criteria Definition
- [ ] Enhancement success metrics clearly defined and measurable
- [ ] Existing system performance baselines established
- [ ] User satisfaction metrics include existing functionality
- [ ] Business impact metrics account for integration complexity
- [ ] Technical health metrics cover enhanced system
- [ ] Quality metrics include regression prevention
- [ ] Timeline success criteria realistic for brownfield complexity
- [ ] Resource utilization metrics appropriate for enhanced system
### 8.2 Monitoring Strategy Validation
- [ ] Existing monitoring capabilities preserved and enhanced
- [ ] New component monitoring integrated with existing dashboards
- [ ] Alert thresholds updated for enhanced system complexity
- [ ] Log aggregation includes new components appropriately
- [ ] Performance monitoring covers integration points
- [ ] Security monitoring enhanced for new attack surfaces
- [ ] User experience monitoring includes existing workflows
- [ ] Business metrics monitoring updated for enhanced functionality
### 8.3 Feedback and Iteration Planning
- [ ] User feedback collection includes existing functionality assessment
- [ ] Technical feedback loops established for integration health
- [ ] Performance feedback includes existing system impact
- [ ] Business feedback loops capture integration value
- [ ] Iteration planning includes integration refinement
- [ ] Continuous improvement process updated for enhanced complexity
- [ ] Learning capture process includes integration lessons
- [ ] Future enhancement planning considers established integration patterns
---
## CHECKLIST COMPLETION VALIDATION
### Final Validation Steps
- [ ] All sections completed with evidence and documentation
- [ ] Critical risks identified and mitigation strategies implemented
- [ ] Stakeholder sign-off obtained for high-risk integration decisions
- [ ] Go/no-go decision criteria established with clear thresholds
- [ ] Rollback triggers and procedures tested and validated
- [ ] Success metrics baseline established and monitoring confirmed
- [ ] Team readiness confirmed through final review and sign-off
- [ ] Communication plan activated and stakeholders informed
### Documentation Artifacts
- [ ] Completed brownfield PRD with validated existing system analysis
- [ ] Completed brownfield architecture with integration specifications
- [ ] Risk assessment document with mitigation strategies
- [ ] Integration testing plan with existing system coverage
- [ ] Deployment plan with rollback procedures
- [ ] Monitoring and alerting configuration updates
- [ ] Team readiness assessment with training completion
- [ ] Stakeholder communication plan with timeline and milestones
---
**Checklist Completion Date:** **\*\***\_\_\_**\*\***
**Product Owner Signature:** **\*\***\_\_\_**\*\***
**Technical Lead Approval:** **\*\***\_\_\_**\*\***
**Stakeholder Sign-off:** **\*\***\_\_\_**\*\***
[[LLM: FINAL BROWNFIELD VALIDATION REPORT GENERATION
Generate a comprehensive brownfield validation report with special attention to integration risks:
1. Executive Summary
- Enhancement readiness: GO / NO-GO / CONDITIONAL
- Critical integration risks identified
- Estimated risk to existing functionality (High/Medium/Low)
- Confidence level in success (percentage with justification)
2. Integration Risk Analysis
- Top 5 integration risks by severity
- Specific code/components at risk
- User impact if risks materialize
- Mitigation effectiveness assessment
3. Existing System Impact
- Features/workflows that could be affected
- Performance impact predictions
- Security posture changes
- Technical debt introduced vs. resolved
4. Go/No-Go Recommendation
- Must-fix items before proceeding
- Acceptable risks with mitigation
- Success probability assessment
- Alternative approaches if No-Go
5. Rollback Readiness
- Rollback procedure completeness
- Time to rollback estimate
- Data recovery considerations
- User communication plan
6. 30-60-90 Day Outlook
- Expected issues in first 30 days
- Monitoring focus areas
- Success validation milestones
- Long-term integration health indicators
After presenting this report, offer to deep-dive into any section, especially high-risk areas or failed validations. Ask if the user wants specific recommendations for reducing integration risks.]]

90
bmad-core/checklists/change-checklist.md
View File

@@ -4,10 +4,42 @@
**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
[[LLM: INITIALIZATION INSTRUCTIONS - CHANGE NAVIGATION
Changes during development are inevitable, but how we handle them determines project success or failure.
Before proceeding, understand:
1. This checklist is for SIGNIFICANT changes that affect the project direction
2. Minor adjustments within a story don't require this process
3. The goal is to minimize wasted work while adapting to new realities
4. User buy-in is critical - they must understand and approve changes
Required context:
- The triggering story or issue
- Current project state (completed stories, current epic)
- Access to PRD, architecture, and other key documents
- Understanding of remaining work planned
APPROACH:
This is an interactive process with the user. Work through each section together, discussing implications and options. The user makes final decisions, but provide expert guidance on technical feasibility and impact.
REMEMBER: Changes are opportunities to improve, not failures. Handle them professionally and constructively.]]
---
## 1. Understand the Trigger & Context
[[LLM: Start by fully understanding what went wrong and why. Don't jump to solutions yet. Ask probing questions:
- What exactly happened that triggered this review?
- Is this a one-time issue or symptomatic of a larger problem?
- Could this have been anticipated earlier?
- What assumptions were incorrect?
Be specific and factual, not blame-oriented.]]
- [ ] **Identify Triggering Story:** Clearly identify the story (or stories) that revealed the issue.
- [ ] **Define the Issue:** Articulate the core problem precisely.
- [ ] Is it a technical limitation/dead-end?
@@ -20,6 +52,15 @@
## 2. Epic Impact Assessment
[[LLM: Changes ripple through the project structure. Systematically evaluate:
1. Can we salvage the current epic with modifications?
2. Do future epics still make sense given this change?
3. Are we creating or eliminating dependencies?
4. Does the epic sequence need reordering?
Think about both immediate and downstream effects.]]
- [ ] **Analyze Current Epic:**
- [ ] Can the current epic containing the trigger story still be completed?
- [ ] Does the current epic need modification (story changes, additions, removals)?
@@ -34,6 +75,15 @@
## 3. Artifact Conflict & Impact Analysis
[[LLM: Documentation drives development in BMAD. Check each artifact:
1. Does this change invalidate documented decisions?
2. Are architectural assumptions still valid?
3. Do user flows need rethinking?
4. Are technical constraints different than documented?
Be thorough - missed conflicts cause future problems.]]
- [ ] **Review PRD:**
- [ ] Does the issue conflict with the core goals or requirements stated in the PRD?
- [ ] Does the PRD need clarification or updates based on the new understanding?
@@ -52,6 +102,16 @@
## 4. Path Forward Evaluation
[[LLM: Present options clearly with pros/cons. For each path:
1. What's the effort required?
2. What work gets thrown away?
3. What risks are we taking?
4. How does this affect timeline?
5. Is this sustainable long-term?
Be honest about trade-offs. There's rarely a perfect solution.]]
- [ ] **Option 1: Direct Adjustment / Integration:**
- [ ] Can the issue be addressed by modifying/adding future stories within the existing plan?
- [ ] Define the scope and nature of these adjustments.
@@ -72,6 +132,16 @@
## 5. Sprint Change Proposal Components
[[LLM: The proposal must be actionable and clear. Ensure:
1. The issue is explained in plain language
2. Impacts are quantified where possible
3. The recommended path has clear rationale
4. Next steps are specific and assigned
5. Success criteria for the change are defined
This proposal guides all subsequent work.]]
(Ensure all agreed-upon points from previous sections are captured in the proposal)
- [ ] **Identified Issue Summary:** Clear, concise problem statement.
@@ -84,6 +154,26 @@
## 6. Final Review & Handoff
[[LLM: Changes require coordination. Before concluding:
1. Is the user fully aligned with the plan?
2. Do all stakeholders understand the impacts?
3. Are handoffs to other agents clear?
4. Is there a rollback plan if the change fails?
5. How will we validate the change worked?
Get explicit approval - implicit agreement causes problems.
FINAL REPORT:
After completing the checklist, provide a concise summary:
- What changed and why
- What we're doing about it
- Who needs to do what
- When we'll know if it worked
Keep it action-oriented and forward-looking.]]
- [ ] **Review Checklist:** Confirm all relevant items were discussed.
- [ ] **Review Sprint Change Proposal:** Ensure it accurately reflects the discussion and decisions.
- [ ] **User Approval:** Obtain explicit user approval for the proposal.

55
bmad-core/checklists/checklist-mappings.yml
View File

@@ -1,55 +0,0 @@
architect-checklist:
checklist_file: docs/checklists/architect-checklist.md
required_docs:
- architecture.md
default_locations:
- docs/architecture.md
platform-engineer-checklist:
checklist_file: docs/checklists/infrastructure-checklist.md
required_docs:
- platform-architecture.md
default_locations:
- docs/platform-architecture.md
frontend-architecture-checklist:
checklist_file: docs/checklists/frontend-architecture-checklist.md
required_docs:
- frontend-architecture.md
default_locations:
- docs/frontend-architecture.md
- docs/fe-architecture.md
pm-checklist:
checklist_file: docs/checklists/pm-checklist.md
required_docs:
- prd.md
default_locations:
- docs/prd.md
po-master-checklist:
checklist_file: docs/checklists/po-master-checklist.md
required_docs:
- prd.md
- architecture.md
optional_docs:
- frontend-architecture.md
default_locations:
- docs/prd.md
- docs/frontend-architecture.md
- docs/architecture.md
story-draft-checklist:
checklist_file: docs/checklists/story-draft-checklist.md
required_docs:
- story.md
default_locations:
- docs/stories/*.md
story-dod-checklist:
checklist_file: docs/checklists/story-dod-checklist.md
required_docs:
- story.md
default_locations:
- docs/stories/*.md

162
bmad-core/checklists/frontend-architecture-checklist.md
View File

@@ -4,10 +4,38 @@
This checklist is for the Design Architect to use after completing the "Frontend Architecture Mode" and populating the `front-end-architecture-tmpl.txt` (or `.md`) document. It ensures all sections are comprehensively covered and meet quality standards before finalization.
[[LLM: INITIALIZATION INSTRUCTIONS - FRONTEND ARCHITECTURE VALIDATION
Before proceeding with this checklist, ensure you have access to:
1. frontend-architecture.md or fe-architecture.md - The frontend architecture document (check docs/frontend-architecture.md or docs/fe-architecture.md)
2. architecture.md - Main architecture document for alignment verification
3. UI/UX specifications or design files (Figma, Sketch, etc.)
4. Any component library documentation or design system references
5. Technology stack specifications from main architecture
IMPORTANT: If the frontend architecture document is missing, immediately ask the user for its location. This checklist cannot proceed without it.
VALIDATION APPROACH:
1. Cross-Reference - Verify alignment with main architecture document
2. Completeness - Ensure all template sections are properly filled
3. Consistency - Check that patterns and conventions are uniform
4. Implementability - Verify an AI agent could implement from these specs
5. Best Practices - Ensure modern frontend practices are followed
EXECUTION MODE:
Ask the user if they want to work through the checklist:
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
---
## I. Introduction
[[LLM: Verify all links and references are present and functional. If any links are broken or missing, note them as failures. The introduction sets the context for the entire document.]]
- [ ] Is the `{Project Name}` correctly filled in throughout the Introduction?
- [ ] Is the link to the Main Architecture Document present and correct?
- [ ] Is the link to the UI/UX Specification present and correct?
@@ -16,6 +44,15 @@ This checklist is for the Design Architect to use after completing the "Frontend
## II. Overall Frontend Philosophy & Patterns
[[LLM: This section is critical for consistency. Verify that:
1. The chosen patterns align with the tech stack in the main architecture
2. The philosophy is clear enough for consistent implementation
3. State management approach matches the application's complexity
4. No conflicting patterns are specified
Pay special attention to alignment with the main architecture document - any mismatches here will cause implementation problems.]]
- [ ] Are the chosen Framework & Core Libraries clearly stated and aligned with the main architecture document?
- [ ] Is the Component Architecture (e.g., Atomic Design, Presentational/Container) clearly described?
- [ ] Is the State Management Strategy (e.g., Redux Toolkit, Zustand) clearly described at a high level?
@@ -27,6 +64,15 @@ This checklist is for the Design Architect to use after completing the "Frontend
## III. Detailed Frontend Directory Structure
[[LLM: The directory structure is the blueprint for code organization. Verify:
1. The ASCII diagram is clear and complete
2. Structure follows the stated patterns from Section II
3. Conventions are explicit (where do new components go?)
4. Structure supports the chosen framework's best practices
An AI agent should be able to know exactly where to place any new file based on this structure.]]
- [ ] Is an ASCII diagram representing the frontend application's folder structure provided?
- [ ] Is the diagram clear, accurate, and reflective of the chosen framework/patterns?
- [ ] Are conventions for organizing components, pages, services, state, styles, etc., highlighted?
@@ -34,6 +80,15 @@ This checklist is for the Design Architect to use after completing the "Frontend
## IV. Component Breakdown & Implementation Details
[[LLM: Component specifications are crucial for consistent implementation. For this section:
1. Verify the template itself is complete with all required fields
2. Check that any example components follow the template exactly
3. Ensure naming conventions are clear and followable
4. Validate that the level of detail is sufficient for implementation
The component template should be so clear that every component built follows the same pattern.]]
### Component Naming & Organization
- [ ] Are conventions for naming components (e.g., PascalCase) described?
@@ -59,6 +114,16 @@ This checklist is for the Design Architect to use after completing the "Frontend
## V. State Management In-Depth
[[LLM: State management is often where frontend apps become complex. Validate:
1. The chosen solution matches the app's needs (not over/under-engineered)
2. Store structure is clearly defined with examples
3. Patterns for async operations are specified
4. Selector patterns promote performance
5. The approach scales with application growth
Look for specific examples and templates, not just high-level descriptions.]]
- [ ] Is the chosen State Management Solution reiterated and rationale briefly provided (if not fully covered in main arch doc)?
- [ ] Are conventions for Store Structure / Slices clearly defined (e.g., location, feature-based slices)?
- [ ] If a Core Slice Example (e.g., `sessionSlice`) is provided:
@@ -74,6 +139,16 @@ This checklist is for the Design Architect to use after completing the "Frontend
## VI. API Interaction Layer
[[LLM: API integration is where frontend meets backend. Verify:
1. HTTP client setup is complete with all configurations
2. Error handling is comprehensive (network, timeout, 4xx, 5xx)
3. Service definitions follow a consistent pattern
4. Authentication/authorization integration is clear
5. Retry logic doesn't create cascading failures
This section should prevent any ambiguity in how the frontend communicates with backends.]]
- [ ] Is the HTTP Client Setup detailed (e.g., Axios instance, Fetch wrapper, base URL, default headers, interceptors)?
- [ ] Are Service Definitions conventions explained?
- [ ] Is an example of a service (e.g., `userService.ts`) provided, including its purpose and example functions?
@@ -83,6 +158,16 @@ This checklist is for the Design Architect to use after completing the "Frontend
## VII. Routing Strategy
[[LLM: Routing defines the application's navigation structure. Check:
1. All major application routes are defined
2. Protection mechanisms are clearly specified
3. Route patterns are consistent and predictable
4. Deep linking considerations are addressed
5. Route guards integrate with authentication properly
The routing table should be comprehensive enough to understand the entire app structure.]]
- [ ] Is the chosen Routing Library stated?
- [ ] Is a table of Route Definitions provided?
- [ ] Does it include Path Pattern, Component/Page, Protection status, and Notes for each route?
@@ -92,6 +177,16 @@ This checklist is for the Design Architect to use after completing the "Frontend
## VIII. Build, Bundling, and Deployment
[[LLM: Build and deployment directly impact performance and reliability. Validate:
1. Build scripts are clearly documented
2. Environment variable handling is secure and clear
3. Optimization strategies are appropriate for the app size
4. Deployment platform is compatible with the build output
5. Caching strategies won't cause stale content issues
Look for specific commands and configurations, not general statements.]]
- [ ] Are Key Build Scripts (e.g., `npm run build`) listed and their purpose explained?
- [ ] Is the handling of Environment Variables during the build process described for different environments?
- [ ] Is Code Splitting strategy detailed (e.g., route-based, component-based)?
@@ -104,6 +199,16 @@ This checklist is for the Design Architect to use after completing the "Frontend
## IX. Frontend Testing Strategy
[[LLM: Testing ensures quality and prevents regressions. Verify:
1. Testing layers are appropriate (unit, integration, e2e)
2. Tools are specified and compatible with the tech stack
3. Test file locations follow a clear pattern
4. Testing scope is realistic and valuable
5. Test data management is addressed
The strategy should be specific enough to start writing tests immediately.]]
- [ ] Is there a link to the Main Testing Strategy document/section, and is it correct?
- [ ] For Component Testing:
- [ ] Is the Scope clearly defined?
@@ -121,6 +226,16 @@ This checklist is for the Design Architect to use after completing the "Frontend
## X. Accessibility (AX) Implementation Details
[[LLM: Accessibility is not optional - it's a core requirement. Check:
1. Semantic HTML usage is emphasized
2. ARIA guidance is practical and specific
3. Keyboard navigation is comprehensively addressed
4. Testing tools and processes are defined
5. Accessibility is integrated into the development workflow
This section should prevent accessibility from being an afterthought.]]
- [ ] Is there an emphasis on using Semantic HTML?
- [ ] Are guidelines for ARIA Implementation (roles, states, properties for custom components) provided?
- [ ] Are requirements for Keyboard Navigation (all interactive elements focusable/operable) stated?
@@ -130,6 +245,16 @@ This checklist is for the Design Architect to use after completing the "Frontend
## XI. Performance Considerations
[[LLM: Performance directly impacts user experience. Validate:
1. Image optimization strategies are concrete
2. Code splitting approach matches app architecture
3. Re-render optimization techniques are specified
4. Performance monitoring is built-in from the start
5. Performance budgets or targets are defined
Look for specific techniques and tools, not just aspirational statements.]]
- [ ] Is Image Optimization (formats, responsive images, lazy loading) discussed?
- [ ] Is Code Splitting & Lazy Loading (impact on perceived performance) reiterated if necessary?
- [ ] Are techniques for Minimizing Re-renders (e.g., `React.memo`) mentioned?
@@ -147,6 +272,43 @@ This checklist is for the Design Architect to use after completing the "Frontend
## Final Review Sign-off
[[LLM: FINAL VALIDATION REPORT GENERATION
Generate a comprehensive frontend architecture validation report:
1. Executive Summary
- Document completeness (percentage of sections properly filled)
- Alignment with main architecture (High/Medium/Low)
- Implementation readiness (Ready/Needs Work/Not Ready)
- Critical gaps identified
2. Section Analysis
- Pass rate for each major section
- Most critical failures or gaps
- Sections requiring immediate attention
3. Technical Concerns
- Potential implementation challenges
- Inconsistencies between sections
- Missing critical information
- Over-engineering concerns
4. Recommendations
- Must-fix items before development
- Should-fix items for better quality
- Nice-to-have improvements
5. AI Implementation Assessment
- Clarity score for AI implementation (1-10)
- Ambiguous areas needing clarification
- Missing examples or templates
After presenting the report, ask if the user wants detailed analysis of any specific section, especially those with failures or concerns.]]
- [ ] Have all placeholders (e.g., `{Project Name}`, `{e.g., ...}`) been filled in or removed where appropriate?
- [ ] Has the document been reviewed for clarity, consistency, and completeness by the Design Architect?
- [ ] Are all linked documents (Main Architecture, UI/UX Spec) finalized or stable enough for this document to rely on?

219
bmad-core/checklists/infrastructure-checklist.md
View File

@@ -2,8 +2,45 @@
This checklist serves as a comprehensive framework for validating infrastructure changes before deployment to production. The DevOps/Platform Engineer should systematically work through each item, ensuring the infrastructure is secure, compliant, resilient, and properly implemented according to organizational standards.
[[LLM: INITIALIZATION INSTRUCTIONS - INFRASTRUCTURE VALIDATION
Before proceeding with this checklist, ensure you have access to:
1. platform-architecture.md or infrastructure-architecture.md (check docs/platform-architecture.md)
2. Infrastructure as Code files (Terraform, CloudFormation, Bicep, etc.)
3. CI/CD pipeline configurations
4. Security and compliance requirements
5. Network diagrams and configurations
6. Monitoring and alerting specifications
IMPORTANT: Infrastructure failures can cause complete outages. This checklist must be thorough.
VALIDATION PRINCIPLES:
1. Security First - Every decision should consider security implications
2. Automation - Manual processes are error-prone and don't scale
3. Resilience - Assume everything will fail and plan accordingly
4. Compliance - Regulatory requirements are non-negotiable
5. Cost Awareness - Over-provisioning wastes money, under-provisioning causes outages
EXECUTION MODE:
Ask the user if they want to work through the checklist:
- Section by section (interactive mode) - Deep dive into each area
- All at once (comprehensive mode) - Complete analysis with summary report
REMEMBER: Production infrastructure supports real users and business operations. Mistakes here have immediate, visible impact.]]
## 1. SECURITY & COMPLIANCE
[[LLM: Security breaches destroy trust and businesses. For each item:
1. Verify implementation, not just documentation
2. Check for common vulnerabilities (default passwords, open ports, etc.)
3. Ensure compliance requirements are actually met, not just considered
4. Look for defense in depth - multiple layers of security
5. Consider the blast radius if this security control fails]]
### 1.1 Access Management
- [ ] RBAC principles applied with least privilege access
@@ -38,6 +75,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 2. INFRASTRUCTURE AS CODE
[[LLM: IaC prevents configuration drift and enables disaster recovery. Verify:
1. EVERYTHING is in code - no "just this once" manual changes
2. Code quality matches application code standards
3. State management won't cause conflicts or data loss
4. Changes can be rolled back safely
5. New team members can understand and modify the infrastructure]]
### 2.1 IaC Implementation
- [ ] All resources defined in IaC (Terraform/Bicep/ARM)
@@ -64,6 +109,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 3. RESILIENCE & AVAILABILITY
[[LLM: Downtime costs money and reputation. Check:
1. What happens when each component fails?
2. Are we meeting our SLA commitments?
3. Has resilience been tested, not just designed?
4. Can the system handle expected peak load?
5. Are failure modes graceful or catastrophic?]]
### 3.1 High Availability
- [ ] Resources deployed across appropriate availability zones
@@ -90,6 +143,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 4. BACKUP & DISASTER RECOVERY
[[LLM: Backups are worthless if they don't restore. Validate:
1. Have restores been tested recently?
2. Do backup windows meet business needs?
3. Are backups stored in a different failure domain?
4. Can we meet our RTO/RPO commitments?
5. Who has tested the disaster recovery runbook?]]
### 4.1 Backup Strategy
- [ ] Backup strategy defined and implemented
@@ -116,6 +177,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 5. MONITORING & OBSERVABILITY
[[LLM: You can't fix what you can't see. Ensure:
1. Every critical metric has monitoring
2. Alerts fire BEFORE users complain
3. Logs are searchable and retained appropriately
4. Dashboards show what actually matters
5. Someone knows how to interpret the data]]
### 5.1 Monitoring Implementation
- [ ] Monitoring coverage for all critical components
@@ -142,6 +211,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 6. PERFORMANCE & OPTIMIZATION
[[LLM: Performance impacts user experience and costs. Check:
1. Has performance been tested under realistic load?
2. Are we over-provisioned (wasting money)?
3. Are we under-provisioned (risking outages)?
4. Do we know our breaking point?
5. Is autoscaling configured correctly?]]
### 6.1 Performance Testing
- [ ] Performance testing completed and baseline established
@@ -168,6 +245,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 7. OPERATIONS & GOVERNANCE
[[LLM: Good operations prevent 3am emergencies. Verify:
1. Can a new team member understand the system?
2. Are runbooks tested and current?
3. Do we know who owns what?
4. Are costs tracked and controlled?
5. Will auditors be satisfied?]]
### 7.1 Documentation
- [ ] Change documentation updated
@@ -194,6 +279,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 8. CI/CD & DEPLOYMENT
[[LLM: Deployment failures impact everyone. Ensure:
1. Can we deploy without downtime?
2. Can we rollback quickly if needed?
3. Are deployments repeatable and reliable?
4. Do we test infrastructure changes?
5. Is the pipeline itself secure?]]
### 8.1 Pipeline Configuration
- [ ] CI/CD pipelines configured and tested
@@ -220,6 +313,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 9. NETWORKING & CONNECTIVITY
[[LLM: Network issues are hard to debug. Validate:
1. Is network segmentation appropriate?
2. Are we exposing more than necessary?
3. Can traffic flow where it needs to?
4. Are we protected from common attacks?
5. Do we have visibility into network issues?]]
### 9.1 Network Design
- [ ] VNet/subnet design follows least-privilege principles
@@ -246,6 +347,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 10. COMPLIANCE & DOCUMENTATION
[[LLM: Compliance failures can shut down operations. Ensure:
1. Are we meeting all regulatory requirements?
2. Can we prove compliance to auditors?
3. Is our documentation actually useful?
4. Do teams know about these changes?
5. Will future engineers understand our decisions?]]
### 10.1 Compliance Verification
- [ ] Required compliance evidence collected
@@ -272,6 +381,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 11. BMAD WORKFLOW INTEGRATION
[[LLM: Infrastructure must support the BMAD development workflow. Check:
1. Can all dev agents work with this infrastructure?
2. Does it align with architecture decisions?
3. Are product requirements actually met?
4. Can developers be productive?
5. Are we creating or removing blockers?]]
### 11.1 Development Agent Alignment
- [ ] Infrastructure changes support Frontend Dev (Mira) and Fullstack Dev (Enrique) requirements
@@ -298,6 +415,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 12. ARCHITECTURE DOCUMENTATION VALIDATION
[[LLM: Good architecture docs prevent repeated mistakes. Verify:
1. Is the documentation complete and current?
2. Can someone new understand the system?
3. Are decisions explained with rationale?
4. Do diagrams match reality?
5. Is evolution possible without major rewrites?]]
### 12.1 Completeness Assessment
- [ ] All required sections of architecture template completed
@@ -324,6 +449,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 13. CONTAINER PLATFORM VALIDATION
[[LLM: Container platforms are complex with many failure modes. Ensure:
1. Is the cluster secure by default?
2. Can it handle expected workload?
3. Are workloads isolated appropriately?
4. Do we have visibility into container health?
5. Can we recover from node failures?]]
### 13.1 Cluster Configuration & Security
- [ ] Container orchestration platform properly installed and configured
@@ -358,6 +491,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 14. GITOPS WORKFLOWS VALIDATION
[[LLM: GitOps enables reliable deployments. Validate:
1. Is everything truly declarative?
2. Can we audit all changes?
3. Are environments properly isolated?
4. Can we rollback quickly?
5. Is drift detected and corrected?]]
### 14.1 GitOps Operator & Configuration
- [ ] GitOps operators properly installed and configured
@@ -392,6 +533,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 15. SERVICE MESH VALIDATION
[[LLM: Service meshes add complexity but enable advanced patterns. Check:
1. Is the overhead justified by benefits?
2. Is service communication secure?
3. Can we debug service issues?
4. Are failure modes handled gracefully?
5. Do developers understand the mesh?]]
### 15.1 Service Mesh Architecture & Installation
- [ ] Service mesh control plane properly installed and configured
@@ -426,6 +575,14 @@ This checklist serves as a comprehensive framework for validating infrastructure
## 16. DEVELOPER EXPERIENCE PLATFORM VALIDATION
[[LLM: Developer productivity depends on platform usability. Ensure:
1. Can developers self-serve effectively?
2. Are golden paths actually helpful?
3. Is onboarding smooth and quick?
4. Do developers have the tools they need?
5. Are we measuring developer satisfaction?]]
### 16.1 Self-Service Infrastructure
- [ ] Self-service provisioning for development environments operational
@@ -468,6 +625,68 @@ This checklist serves as a comprehensive framework for validating infrastructure
---
## FINAL INFRASTRUCTURE VALIDATION
[[LLM: COMPREHENSIVE INFRASTRUCTURE REPORT GENERATION
Generate a detailed infrastructure validation report:
1. Executive Summary
- Overall readiness for production (GO/NO-GO)
- Critical risks identified
- Security posture assessment
- Compliance status
- Estimated reliability (9s of uptime)
2. Risk Analysis by Category
- CRITICAL: Production blockers
- HIGH: Should fix before production
- MEDIUM: Fix within 30 days
- LOW: Consider for future improvements
3. Technical Debt Assessment
- Shortcuts taken and their impact
- Future scaling concerns
- Maintenance burden created
- Cost implications
4. Operational Readiness
- Can the ops team support this?
- Are runbooks complete?
- Is monitoring sufficient?
- Can we meet SLAs?
5. Security & Compliance Summary
- Security controls effectiveness
- Compliance gaps
- Attack surface analysis
- Data protection status
6. Platform-Specific Findings
- Container platform readiness
- GitOps maturity
- Service mesh complexity
- Developer experience gaps
7. Recommendations
- Must-fix before production
- Should-fix for stability
- Consider for optimization
- Future roadmap items
After presenting the report, ask if the user wants:
- Deep dive into any failed sections
- Risk mitigation strategies
- Implementation prioritization help
- Specific remediation guidance]]
### Prerequisites Verified
- [ ] All checklist sections reviewed (1-16)

131
bmad-core/checklists/pm-checklist.md
View File

@@ -2,8 +2,41 @@
This checklist serves as a comprehensive framework to ensure the Product Requirements Document (PRD) and Epic definitions are complete, well-structured, and appropriately scoped for MVP development. The PM should systematically work through each item during the product definition process.
[[LLM: INITIALIZATION INSTRUCTIONS - PM CHECKLIST
Before proceeding with this checklist, ensure you have access to:
1. prd.md - The Product Requirements Document (check docs/prd.md)
2. Any user research, market analysis, or competitive analysis documents
3. Business goals and strategy documents
4. Any existing epic definitions or user stories
IMPORTANT: If the PRD is missing, immediately ask the user for its location or content before proceeding.
VALIDATION APPROACH:
1. User-Centric - Every requirement should tie back to user value
2. MVP Focus - Ensure scope is truly minimal while viable
3. Clarity - Requirements should be unambiguous and testable
4. Completeness - All aspects of the product vision are covered
5. Feasibility - Requirements are technically achievable
EXECUTION MODE:
Ask the user if they want to work through the checklist:
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
## 1. PROBLEM DEFINITION & CONTEXT
[[LLM: The foundation of any product is a clear problem statement. As you review this section:
1. Verify the problem is real and worth solving
2. Check that the target audience is specific, not "everyone"
3. Ensure success metrics are measurable, not vague aspirations
4. Look for evidence of user research, not just assumptions
5. Confirm the problem-solution fit is logical]]
### 1.1 Problem Statement
- [ ] Clear articulation of the problem being solved
@@ -30,6 +63,14 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 2. MVP SCOPE DEFINITION
[[LLM: MVP scope is critical - too much and you waste resources, too little and you can't validate. Check:
1. Is this truly minimal? Challenge every feature
2. Does each feature directly address the core problem?
3. Are "nice-to-haves" clearly separated from "must-haves"?
4. Is the rationale for inclusion/exclusion documented?
5. Can you ship this in the target timeframe?]]
### 2.1 Core Functionality
- [ ] Essential features clearly distinguished from nice-to-haves
@@ -56,6 +97,14 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 3. USER EXPERIENCE REQUIREMENTS
[[LLM: UX requirements bridge user needs and technical implementation. Validate:
1. User flows cover the primary use cases completely
2. Edge cases are identified (even if deferred)
3. Accessibility isn't an afterthought
4. Performance expectations are realistic
5. Error states and recovery are planned]]
### 3.1 User Journeys & Flows
- [ ] Primary user flows documented
@@ -82,6 +131,14 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 4. FUNCTIONAL REQUIREMENTS
[[LLM: Functional requirements must be clear enough for implementation. Check:
1. Requirements focus on WHAT not HOW (no implementation details)
2. Each requirement is testable (how would QA verify it?)
3. Dependencies are explicit (what needs to be built first?)
4. Requirements use consistent terminology
5. Complex features are broken into manageable pieces]]
### 4.1 Feature Completeness
- [ ] All required features for MVP documented
@@ -242,27 +299,75 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## PRD & EPIC VALIDATION SUMMARY
[[LLM: FINAL PM CHECKLIST REPORT GENERATION
Create a comprehensive validation report that includes:
1. Executive Summary
- Overall PRD completeness (percentage)
- MVP scope appropriateness (Too Large/Just Right/Too Small)
- Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
- Most critical gaps or concerns
2. Category Analysis Table
Fill in the actual table with:
- Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
- Critical Issues: Specific problems that block progress
3. Top Issues by Priority
- BLOCKERS: Must fix before architect can proceed
- HIGH: Should fix for quality
- MEDIUM: Would improve clarity
- LOW: Nice to have
4. MVP Scope Assessment
- Features that might be cut for true MVP
- Missing features that are essential
- Complexity concerns
- Timeline realism
5. Technical Readiness
- Clarity of technical constraints
- Identified technical risks
- Areas needing architect investigation
6. Recommendations
- Specific actions to address each blocker
- Suggested improvements
- Next steps
After presenting the report, ask if the user wants:
- Detailed analysis of any failed sections
- Suggestions for improving specific areas
- Help with refining MVP scope]]
### Category Statuses
| Category | Status | Critical Issues |
|----------|--------|----------------|
| 1. Problem Definition & Context | PASS/FAIL/PARTIAL | |
| 2. MVP Scope Definition | PASS/FAIL/PARTIAL | |
| 3. User Experience Requirements | PASS/FAIL/PARTIAL | |
| 4. Functional Requirements | PASS/FAIL/PARTIAL | |
| 5. Non-Functional Requirements | PASS/FAIL/PARTIAL | |
| 6. Epic & Story Structure | PASS/FAIL/PARTIAL | |
| 7. Technical Guidance | PASS/FAIL/PARTIAL | |
| 8. Cross-Functional Requirements | PASS/FAIL/PARTIAL | |
| 9. Clarity & Communication | PASS/FAIL/PARTIAL | |
| Category | Status | Critical Issues |
| -------------------------------- | ------ | --------------- |
| 1. Problem Definition & Context | _TBD_ | |
| 2. MVP Scope Definition | _TBD_ | |
| 3. User Experience Requirements | _TBD_ | |
| 4. Functional Requirements | _TBD_ | |
| 5. Non-Functional Requirements | _TBD_ | |
| 6. Epic & Story Structure | _TBD_ | |
| 7. Technical Guidance | _TBD_ | |
| 8. Cross-Functional Requirements | _TBD_ | |
| 9. Clarity & Communication | _TBD_ | |
### Critical Deficiencies
- List all critical issues that must be addressed before handoff to Architect
_To be populated during validation_
### Recommendations
- Provide specific recommendations for addressing each deficiency
_To be populated during validation_
### Final Decision

176
bmad-core/checklists/po-master-checklist.md
View File

@@ -2,8 +2,42 @@
This checklist serves as a comprehensive framework for the Product Owner to validate the complete MVP plan before development execution. The PO should systematically work through each item, documenting compliance status and noting any deficiencies.
[[LLM: INITIALIZATION INSTRUCTIONS - PO MASTER CHECKLIST
Before proceeding with this checklist, ensure you have access to:
1. prd.md - The Product Requirements Document (check docs/prd.md)
2. architecture.md - The system architecture (check docs/architecture.md)
3. frontend-architecture.md - If applicable (check docs/frontend-architecture.md or docs/fe-architecture.md)
4. All epic and story definitions
5. Any technical specifications or constraints
IMPORTANT: This checklist validates the COMPLETE MVP plan. All documents should be finalized before running this validation.
VALIDATION FOCUS:
1. Sequencing - Are things built in the right order?
2. Dependencies - Are all prerequisites in place before they're needed?
3. Completeness - Is everything needed for MVP included?
4. Clarity - Can developers implement without confusion?
5. Feasibility - Is the plan realistic and achievable?
EXECUTION MODE:
Ask the user if they want to work through the checklist:
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
## 1. PROJECT SETUP & INITIALIZATION
[[LLM: Project setup is the foundation - if this is wrong, everything else fails. Verify:
1. The VERY FIRST epic/story creates the project structure
2. No code is written before the project exists
3. Development environment is ready before any development
4. Dependencies are installed before they're imported
5. Configuration happens before it's needed]]
### 1.1 Project Scaffolding
- [ ] Epic 1 includes explicit steps for project creation/initialization
@@ -29,6 +63,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
## 2. INFRASTRUCTURE & DEPLOYMENT SEQUENCING
[[LLM: Infrastructure must exist before it's used. Check sequencing carefully:
1. Databases exist before tables/collections
2. Tables/collections exist before data operations
3. APIs are configured before endpoints are added
4. Auth is set up before protected routes
5. Deployment pipeline exists before deployment stories]]
### 2.1 Database & Data Store Setup
- [ ] Database selection/setup occurs before any database operations
@@ -61,6 +103,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
[[LLM: External dependencies often block progress. Ensure:
1. All external accounts are created early
2. API keys are obtained before integration stories
3. User actions (like purchasing) are clearly marked
4. Fallback options exist for external service issues
5. Integration prerequisites are met before integration]]
### 3.1 Third-Party Services
- [ ] Account creation steps are identified for required services
@@ -84,6 +134,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
## 4. USER/AGENT RESPONSIBILITY DELINEATION
[[LLM: Clear ownership prevents confusion and delays. Verify:
1. User tasks are truly things only humans can do
2. No coding tasks are assigned to users
3. Account creation and payments are user tasks
4. Everything else is assigned to appropriate agents
5. Handoffs between user and agent are clear]]
### 4.1 User Actions
- [ ] User responsibilities are limited to only what requires human intervention
@@ -100,6 +158,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
## 5. FEATURE SEQUENCING & DEPENDENCIES
[[LLM: Dependencies create the critical path. Check rigorously:
1. Nothing is used before it exists
2. Shared components are built once, used many times
3. The user can complete a meaningful flow early
4. Each epic delivers value, not just infrastructure
5. Dependencies don't create circular references]]
### 5.1 Functional Dependencies
- [ ] Features that depend on other features are sequenced correctly
@@ -123,6 +189,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
## 6. MVP SCOPE ALIGNMENT
[[LLM: MVP means MINIMUM viable product. Validate:
1. Every feature directly supports core MVP goals
2. "Nice to haves" are clearly marked for post-MVP
3. The user can achieve primary goals with included features
4. Technical requirements don't add unnecessary scope
5. The product is truly viable with just these features]]
### 6.1 PRD Goals Alignment
- [ ] All core goals defined in the PRD are addressed in epics/stories
@@ -146,6 +220,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
## 7. RISK MANAGEMENT & PRACTICALITY
[[LLM: Risks can derail the entire project. Ensure:
1. Technical unknowns have research/spike stories
2. External dependencies have fallback plans
3. Complex features have validation milestones
4. The timeline accounts for discovered complexity
5. Critical risks are addressed early, not late]]
### 7.1 Technical Risk Mitigation
- [ ] Complex or unfamiliar technologies have appropriate learning/prototyping stories
@@ -169,6 +251,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
## 8. DOCUMENTATION & HANDOFF
[[LLM: Good documentation enables smooth development. Check:
1. Developers can start without extensive onboarding
2. Deployment steps are clear and complete
3. Handoff points between roles are documented
4. Future maintenance is considered
5. Knowledge isn't trapped in one person's head]]
### 8.1 Developer Documentation
- [ ] API documentation is created alongside implementation
@@ -185,6 +275,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
## 9. POST-MVP CONSIDERATIONS
[[LLM: Planning for success prevents technical debt. Verify:
1. MVP doesn't paint the product into a corner
2. Future features won't require major refactoring
3. Monitoring exists to validate MVP success
4. Feedback loops inform post-MVP priorities
5. The architecture can grow with the product]]
### 9.1 Future Enhancements
- [ ] Clear separation between MVP and future features
@@ -201,27 +299,79 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
## VALIDATION SUMMARY
[[LLM: FINAL PO VALIDATION REPORT GENERATION
Generate a comprehensive validation report for the complete MVP plan:
1. Executive Summary
- Overall plan readiness (percentage)
- Go/No-Go recommendation
- Critical blocking issues count
- Estimated development timeline feasibility
2. Sequencing Analysis
- Dependency violations found
- Circular dependencies identified
- Missing prerequisites
- Optimal vs actual sequencing
3. Risk Assessment
- High-risk areas without mitigation
- External dependency risks
- Technical complexity hotspots
- Timeline risks
4. MVP Completeness
- Core features coverage
- Missing essential functionality
- Scope creep identified
- True MVP vs "MLP" (Most Lovable Product)
5. Implementation Readiness
- Developer clarity score (1-10)
- Ambiguous requirements count
- Missing technical details
- Handoff completeness
6. Recommendations
- Must-fix before development
- Should-fix for quality
- Consider for improvement
- Post-MVP deferrals
After presenting the report, ask if the user wants:
- Detailed analysis of any failed sections
- Specific story resequencing suggestions
- Risk mitigation strategies
- MVP scope refinement help]]
### Category Statuses
| Category | Status | Critical Issues |
|----------|--------|----------------|
| 1. Project Setup & Initialization | PASS/FAIL/PARTIAL | |
| 2. Infrastructure & Deployment Sequencing | PASS/FAIL/PARTIAL | |
| 3. External Dependencies & Integrations | PASS/FAIL/PARTIAL | |
| 4. User/Agent Responsibility Delineation | PASS/FAIL/PARTIAL | |
| 5. Feature Sequencing & Dependencies | PASS/FAIL/PARTIAL | |
| 6. MVP Scope Alignment | PASS/FAIL/PARTIAL | |
| 7. Risk Management & Practicality | PASS/FAIL/PARTIAL | |
| 8. Documentation & Handoff | PASS/FAIL/PARTIAL | |
| 9. Post-MVP Considerations | PASS/FAIL/PARTIAL | |
| Category | Status | Critical Issues |
| ----------------------------------------- | ------ | --------------- |
| 1. Project Setup & Initialization | _TBD_ | |
| 2. Infrastructure & Deployment Sequencing | _TBD_ | |
| 3. External Dependencies & Integrations | _TBD_ | |
| 4. User/Agent Responsibility Delineation | _TBD_ | |
| 5. Feature Sequencing & Dependencies | _TBD_ | |
| 6. MVP Scope Alignment | _TBD_ | |
| 7. Risk Management & Practicality | _TBD_ | |
| 8. Documentation & Handoff | _TBD_ | |
| 9. Post-MVP Considerations | _TBD_ | |
### Critical Deficiencies
- List all critical issues that must be addressed before approval
_To be populated during validation_
### Recommendations
- Provide specific recommendations for addressing each deficiency
_To be populated during validation_
### Final Decision

99
bmad-core/checklists/story-dod-checklist.md
View File

@@ -4,53 +4,98 @@
Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
[[LLM: INITIALIZATION INSTRUCTIONS - STORY DOD VALIDATION
This checklist is for DEVELOPER AGENTS to self-validate their work before marking a story complete.
IMPORTANT: This is a self-assessment. Be honest about what's actually done vs what should be done. It's better to identify issues now than have them found in review.
EXECUTION APPROACH:
1. Go through each section systematically
2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
3. Add brief comments explaining any [ ] or [N/A] items
4. Be specific about what was actually implemented
5. Flag any concerns or technical debt created
The goal is quality delivery, not just checking boxes.]]
## Checklist Items
1. **Requirements Met:**
- [ ] All functional requirements specified in the story are implemented.
- [ ] All acceptance criteria defined in the story are met.
[[LLM: Be specific - list each requirement and whether it's complete]]
- [ ] All functional requirements specified in the story are implemented.
- [ ] All acceptance criteria defined in the story are met.
2. **Coding Standards & Project Structure:**
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
- [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
- [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
- [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
- [ ] Basic security best practices (e.g., input validation, proper error handling, no hardcoded secrets) applied for new/modified code.
- [ ] No new linter errors or warnings introduced.
- [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
[[LLM: Code quality matters for maintainability. Check each item carefully]]
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
- [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
- [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
- [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
- [ ] Basic security best practices (e.g., input validation, proper error handling, no hardcoded secrets) applied for new/modified code.
- [ ] No new linter errors or warnings introduced.
- [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
3. **Testing:**
- [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
- [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
- [ ] All tests (unit, integration, E2E if applicable) pass successfully.
- [ ] Test coverage meets project standards (if defined).
[[LLM: Testing proves your code works. Be honest about test coverage]]
- [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
- [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
- [ ] All tests (unit, integration, E2E if applicable) pass successfully.
- [ ] Test coverage meets project standards (if defined).
4. **Functionality & Verification:**
- [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
- [ ] Edge cases and potential error conditions considered and handled gracefully.
[[LLM: Did you actually run and test your code? Be specific about what you tested]]
- [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
- [ ] Edge cases and potential error conditions considered and handled gracefully.
5. **Story Administration:**
- [ ] All tasks within the story file are marked as complete.
- [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
- [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
[[LLM: Documentation helps the next developer. What should they know?]]
- [ ] All tasks within the story file are marked as complete.
- [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
- [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
6. **Dependencies, Build & Configuration:**
- [ ] Project builds successfully without errors.
- [ ] Project linting passes
- [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
- [ ] If new dependencies were added, they are recorded in the appropriate project files (e.g., `package.json`, `requirements.txt`) with justification.
- [ ] No known security vulnerabilities introduced by newly added and approved dependencies.
- [ ] If new environment variables or configurations were introduced by the story, they are documented and handled securely.
[[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
- [ ] Project builds successfully without errors.
- [ ] Project linting passes
- [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
- [ ] If new dependencies were added, they are recorded in the appropriate project files (e.g., `package.json`, `requirements.txt`) with justification.
- [ ] No known security vulnerabilities introduced by newly added and approved dependencies.
- [ ] If new environment variables or configurations were introduced by the story, they are documented and handled securely.
7. **Documentation (If Applicable):**
- [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
- [ ] User-facing documentation updated, if changes impact users.
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
[[LLM: Good documentation prevents future confusion. What needs explaining?]]
- [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
- [ ] User-facing documentation updated, if changes impact users.
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
## Final Confirmation
[[LLM: FINAL DOD SUMMARY
After completing the checklist:
1. Summarize what was accomplished in this story
2. List any items marked as [ ] Not Done with explanations
3. Identify any technical debt or follow-up work needed
4. Note any challenges or learnings for future stories
5. Confirm whether the story is truly ready for review
Be honest - it's better to flag issues now than have them discovered later.]]
- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.

113
bmad-core/checklists/story-draft-checklist.md
View File

@@ -2,8 +2,44 @@
The Scrum Master should use this checklist to validate that each story contains sufficient context for a developer agent to implement it successfully, while assuming the dev agent has reasonable capabilities to figure things out.
[[LLM: INITIALIZATION INSTRUCTIONS - STORY DRAFT VALIDATION
Before proceeding with this checklist, ensure you have access to:
1. The story document being validated (usually in docs/stories/ or provided directly)
2. The parent epic context
3. Any referenced architecture or design documents
4. Previous related stories if this builds on prior work
IMPORTANT: This checklist validates individual stories BEFORE implementation begins.
VALIDATION PRINCIPLES:
1. Clarity - A developer should understand WHAT to build
2. Context - WHY this is being built and how it fits
3. Guidance - Key technical decisions and patterns to follow
4. Testability - How to verify the implementation works
5. Self-Contained - Most info needed is in the story itself
REMEMBER: We assume competent developer agents who can:
- Research documentation and codebases
- Make reasonable technical decisions
- Follow established patterns
- Ask for clarification when truly stuck
We're checking for SUFFICIENT guidance, not exhaustive detail.]]
## 1. GOAL & CONTEXT CLARITY
[[LLM: Without clear goals, developers build the wrong thing. Verify:
1. The story states WHAT functionality to implement
2. The business value or user benefit is clear
3. How this fits into the larger epic/product is explained
4. Dependencies are explicit ("requires Story X to be complete")
5. Success looks like something specific, not vague]]
- [ ] Story goal/purpose is clearly stated
- [ ] Relationship to epic goals is evident
- [ ] How the story fits into overall system flow is explained
@@ -12,6 +48,16 @@ The Scrum Master should use this checklist to validate that each story contains
## 2. TECHNICAL IMPLEMENTATION GUIDANCE
[[LLM: Developers need enough technical context to start coding. Check:
1. Key files/components to create or modify are mentioned
2. Technology choices are specified where non-obvious
3. Integration points with existing code are identified
4. Data models or API contracts are defined or referenced
5. Non-standard patterns or exceptions are called out
Note: We don't need every file listed - just the important ones.]]
- [ ] Key files to create/modify are identified (not necessarily exhaustive)
- [ ] Technologies specifically needed for this story are mentioned
- [ ] Critical APIs or interfaces are sufficiently described
@@ -21,6 +67,14 @@ The Scrum Master should use this checklist to validate that each story contains
## 3. REFERENCE EFFECTIVENESS
[[LLM: References should help, not create a treasure hunt. Ensure:
1. References point to specific sections, not whole documents
2. The relevance of each reference is explained
3. Critical information is summarized in the story
4. References are accessible (not broken links)
5. Previous story context is summarized if needed]]
- [ ] References to external documents point to specific relevant sections
- [ ] Critical information from previous stories is summarized (not just referenced)
- [ ] Context is provided for why references are relevant
@@ -28,6 +82,14 @@ The Scrum Master should use this checklist to validate that each story contains
## 4. SELF-CONTAINMENT ASSESSMENT
[[LLM: Stories should be mostly self-contained to avoid context switching. Verify:
1. Core requirements are in the story, not just in references
2. Domain terms are explained or obvious from context
3. Assumptions are stated explicitly
4. Edge cases are mentioned (even if deferred)
5. The story could be understood without reading 10 other documents]]
- [ ] Core information needed is included (not overly reliant on external docs)
- [ ] Implicit assumptions are made explicit
- [ ] Domain-specific terms or concepts are explained
@@ -35,6 +97,14 @@ The Scrum Master should use this checklist to validate that each story contains
## 5. TESTING GUIDANCE
[[LLM: Testing ensures the implementation actually works. Check:
1. Test approach is specified (unit, integration, e2e)
2. Key test scenarios are listed
3. Success criteria are measurable
4. Special test considerations are noted
5. Acceptance criteria in the story are testable]]
- [ ] Required testing approach is outlined
- [ ] Key test scenarios are identified
- [ ] Success criteria are defined
@@ -42,13 +112,42 @@ The Scrum Master should use this checklist to validate that each story contains
## VALIDATION RESULT
| Category | Status | Issues |
| ------------------------------------ | ----------------- | ------ |
| 1. Goal & Context Clarity | PASS/FAIL/PARTIAL | |
| 2. Technical Implementation Guidance | PASS/FAIL/PARTIAL | |
| 3. Reference Effectiveness | PASS/FAIL/PARTIAL | |
| 4. Self-Containment Assessment | PASS/FAIL/PARTIAL | |
| 5. Testing Guidance | PASS/FAIL/PARTIAL | |
[[LLM: FINAL STORY VALIDATION REPORT
Generate a concise validation report:
1. Quick Summary
- Story readiness: READY / NEEDS REVISION / BLOCKED
- Clarity score (1-10)
- Major gaps identified
2. Fill in the validation table with:
- PASS: Requirements clearly met
- PARTIAL: Some gaps but workable
- FAIL: Critical information missing
3. Specific Issues (if any)
- List concrete problems to fix
- Suggest specific improvements
- Identify any blocking dependencies
4. Developer Perspective
- Could YOU implement this story as written?
- What questions would you have?
- What might cause delays or rework?
Be pragmatic - perfect documentation doesn't exist. Focus on whether a competent developer can succeed with this story.]]
| Category | Status | Issues |
| ------------------------------------ | ------ | ------ |
| 1. Goal & Context Clarity | _TBD_ | |
| 2. Technical Implementation Guidance | _TBD_ | |
| 3. Reference Effectiveness | _TBD_ | |
| 4. Self-Containment Assessment | _TBD_ | |
| 5. Testing Guidance | _TBD_ | |
**Final Assessment:**

160
bmad-core/tasks/brownfield-create-epic.md Normal file
View File

@@ -0,0 +1,160 @@
# Create Brownfield Epic Task
## Purpose
Create a single epic for smaller brownfield enhancements that don't require the full PRD and Architecture documentation process. This task is for isolated features or modifications that can be completed within a focused scope.
## When to Use This Task
**Use this task when:**
- The enhancement can be completed in 1-3 stories
- No significant architectural changes are required
- The enhancement follows existing project patterns
- Integration complexity is minimal
- Risk to existing system is low
**Use the full brownfield PRD/Architecture process when:**
- The enhancement requires multiple coordinated stories
- Architectural planning is needed
- Significant integration work is required
- Risk assessment and mitigation planning is necessary
## Instructions
### 1. Project Analysis (Required)
Before creating the epic, gather essential information about the existing project:
**Existing Project Context:**
- [ ] Project purpose and current functionality understood
- [ ] Existing technology stack identified
- [ ] Current architecture patterns noted
- [ ] Integration points with existing system identified
**Enhancement Scope:**
- [ ] Enhancement clearly defined and scoped
- [ ] Impact on existing functionality assessed
- [ ] Required integration points identified
- [ ] Success criteria established
### 2. Epic Creation
Create a focused epic following this structure:
#### Epic Title
{{Enhancement Name}} - Brownfield Enhancement
#### Epic Goal
{{1-2 sentences describing what the epic will accomplish and why it adds value}}
#### Epic Description
**Existing System Context:**
- Current relevant functionality: {{brief description}}
- Technology stack: {{relevant existing technologies}}
- Integration points: {{where new work connects to existing system}}
**Enhancement Details:**
- What's being added/changed: {{clear description}}
- How it integrates: {{integration approach}}
- Success criteria: {{measurable outcomes}}
#### Stories
List 1-3 focused stories that complete the epic:
1. **Story 1:** {{Story title and brief description}}
2. **Story 2:** {{Story title and brief description}}
3. **Story 3:** {{Story title and brief description}}
#### Compatibility Requirements
- [ ] Existing APIs remain unchanged
- [ ] Database schema changes are backward compatible
- [ ] UI changes follow existing patterns
- [ ] Performance impact is minimal
#### Risk Mitigation
- **Primary Risk:** {{main risk to existing system}}
- **Mitigation:** {{how risk will be addressed}}
- **Rollback Plan:** {{how to undo changes if needed}}
#### Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Existing functionality verified through testing
- [ ] Integration points working correctly
- [ ] Documentation updated appropriately
- [ ] No regression in existing features
### 3. Validation Checklist
Before finalizing the epic, ensure:
**Scope Validation:**
- [ ] Epic can be completed in 1-3 stories maximum
- [ ] No architectural documentation is required
- [ ] Enhancement follows existing patterns
- [ ] Integration complexity is manageable
**Risk Assessment:**
- [ ] Risk to existing system is low
- [ ] Rollback plan is feasible
- [ ] Testing approach covers existing functionality
- [ ] Team has sufficient knowledge of integration points
**Completeness Check:**
- [ ] Epic goal is clear and achievable
- [ ] Stories are properly scoped
- [ ] Success criteria are measurable
- [ ] Dependencies are identified
### 4. Handoff to Story Manager
Once the epic is validated, provide this handoff to the Story Manager:
---
**Story Manager Handoff:**
"Please develop detailed user stories for this brownfield epic. Key considerations:
- This is an enhancement to an existing system running {{technology stack}}
- Integration points: {{list key integration points}}
- Existing patterns to follow: {{relevant existing patterns}}
- Critical compatibility requirements: {{key requirements}}
- Each story must include verification that existing functionality remains intact
The epic should maintain system integrity while delivering {{epic goal}}."
---
## Success Criteria
The epic creation is successful when:
1. Enhancement scope is clearly defined and appropriately sized
2. Integration approach respects existing system architecture
3. Risk to existing functionality is minimized
4. Stories are logically sequenced for safe implementation
5. Compatibility requirements are clearly specified
6. Rollback plan is feasible and documented
## Important Notes
- This task is specifically for SMALL brownfield enhancements
- If the scope grows beyond 3 stories, consider the full brownfield PRD process
- Always prioritize existing system integrity over new functionality
- When in doubt about scope or complexity, escalate to full brownfield planning

174
bmad-core/tasks/brownfield-create-story.md Normal file
View File

@@ -0,0 +1,174 @@
# Create Brownfield Story Task
## Purpose
Create a single user story for very small brownfield enhancements that can be completed in one focused development session. This task is for minimal additions or bug fixes that require existing system integration awareness.
## When to Use This Task
**Use this task when:**
- The enhancement can be completed in a single story (2-4 hours of focused work)
- No new architecture or significant design is required
- The change follows existing patterns exactly
- Integration is straightforward with minimal risk
- Change is isolated with clear boundaries
**Use brownfield-create-epic when:**
- The enhancement requires 2-3 coordinated stories
- Some design work is needed
- Multiple integration points are involved
**Use the full brownfield PRD/Architecture process when:**
- The enhancement requires multiple coordinated stories
- Architectural planning is needed
- Significant integration work is required
## Instructions
### 1. Quick Project Assessment
Gather minimal but essential context about the existing project:
**Current System Context:**
- [ ] Relevant existing functionality identified
- [ ] Technology stack for this area noted
- [ ] Integration point(s) clearly understood
- [ ] Existing patterns for similar work identified
**Change Scope:**
- [ ] Specific change clearly defined
- [ ] Impact boundaries identified
- [ ] Success criteria established
### 2. Story Creation
Create a single focused story following this structure:
#### Story Title
{{Specific Enhancement}} - Brownfield Addition
#### User Story
As a {{user type}},
I want {{specific action/capability}},
So that {{clear benefit/value}}.
#### Story Context
**Existing System Integration:**
- Integrates with: {{existing component/system}}
- Technology: {{relevant tech stack}}
- Follows pattern: {{existing pattern to follow}}
- Touch points: {{specific integration points}}
#### Acceptance Criteria
**Functional Requirements:**
1. {{Primary functional requirement}}
2. {{Secondary functional requirement (if any)}}
3. {{Integration requirement}}
**Integration Requirements:** 4. Existing {{relevant functionality}} continues to work unchanged 5. New functionality follows existing {{pattern}} pattern 6. Integration with {{system/component}} maintains current behavior
**Quality Requirements:** 7. Change is covered by appropriate tests 8. Documentation is updated if needed 9. No regression in existing functionality verified
#### Technical Notes
- **Integration Approach:** {{how it connects to existing system}}
- **Existing Pattern Reference:** {{link or description of pattern to follow}}
- **Key Constraints:** {{any important limitations or requirements}}
#### Definition of Done
- [ ] Functional requirements met
- [ ] Integration requirements verified
- [ ] Existing functionality regression tested
- [ ] Code follows existing patterns and standards
- [ ] Tests pass (existing and new)
- [ ] Documentation updated if applicable
### 3. Risk and Compatibility Check
**Minimal Risk Assessment:**
- **Primary Risk:** {{main risk to existing system}}
- **Mitigation:** {{simple mitigation approach}}
- **Rollback:** {{how to undo if needed}}
**Compatibility Verification:**
- [ ] No breaking changes to existing APIs
- [ ] Database changes (if any) are additive only
- [ ] UI changes follow existing design patterns
- [ ] Performance impact is negligible
### 4. Validation Checklist
Before finalizing the story, confirm:
**Scope Validation:**
- [ ] Story can be completed in one development session
- [ ] Integration approach is straightforward
- [ ] Follows existing patterns exactly
- [ ] No design or architecture work required
**Clarity Check:**
- [ ] Story requirements are unambiguous
- [ ] Integration points are clearly specified
- [ ] Success criteria are testable
- [ ] Rollback approach is simple
### 5. Handoff to Developer
Once the story is validated, provide this handoff to the Developer:
---
**Developer Handoff:**
"This is a focused brownfield story for an existing {{technology}} system.
**Integration Context:**
- Existing component: {{component/system}}
- Pattern to follow: {{existing pattern}}
- Key constraint: {{main constraint}}
**Critical Requirements:**
- Follow the existing {{pattern}} pattern exactly
- Ensure {{existing functionality}} continues working
- Test integration with {{specific component}}
**Verification:**
Please verify existing {{relevant functionality}} remains unchanged after implementation."
---
## Success Criteria
The story creation is successful when:
1. Enhancement is clearly defined and appropriately scoped for single session
2. Integration approach is straightforward and low-risk
3. Existing system patterns are identified and will be followed
4. Rollback plan is simple and feasible
5. Acceptance criteria include existing functionality verification
## Important Notes
- This task is for VERY SMALL brownfield changes only
- If complexity grows during analysis, escalate to brownfield-create-epic
- Always prioritize existing system integrity
- When in doubt about integration complexity, use brownfield-create-epic instead
- Stories should take no more than 4 hours of focused development work

100
bmad-core/tasks/execute-checklist.md
View File

@@ -1,35 +1,34 @@
# Checklist Validation Task
This task provides instructions for validating documentation against checklists. The agent should follow these instructions to ensure thorough and systematic validation of documents.
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
## Context
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. The mapping between checklists and their required documents is defined in `checklist-mappings`. This allows for easy addition of new checklists without modifying this task.
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
## Available Checklists
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
## Instructions
1. **Initial Assessment**
- Check `checklist-mappings` for available checklists
- If user provides a checklist name:
- Look for exact match in checklist-mappings.yml
- If no exact match, try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
- Once matched, use the checklist_file path from the mapping
- Load the appropriate checklist from bmad-core/checklists/
- If no checklist specified:
- Ask the user which checklist they want to use
- Present available options from checklist-mappings.yml
- Present the available options from the files in the checklists folder
- Confirm if they want to work through the checklist:
- Section by section (interactive mode)
- All at once (YOLO mode)
- Section by section (interactive mode - very time consuming)
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document Location**
2. **Document and Artifact Gathering**
- Look up the required documents and default locations in `checklist-mappings`
- For each required document:
- Check all default locations specified in the mapping
- If not found, ask the user for the document location
- Verify all required documents are accessible
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
@@ -37,10 +36,10 @@ The BMAD Method uses various checklists to ensure quality and completeness of di
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section
- Check each item against the relevant documentation
- Present findings for that section
- Get user confirmation before proceeding to next section
- Review all items in the section following instructions for that section embedded in the checklist
- Check each item against the relevant documentation or artifacts as appropriate
- Present summary of findings for that section, highlighting warnings, errors and non applicable items (rationale for non-applicability).
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
@@ -55,6 +54,7 @@ The BMAD Method uses various checklists to ensure quality and completeness of di
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
- Aside from this, follow all checklist llm instructions
- Mark items as:
- ✅ PASS: Requirement clearly met
- ❌ FAIL: Requirement not met or insufficient coverage
@@ -65,7 +65,7 @@ The BMAD Method uses various checklists to ensure quality and completeness of di
For each section:
- Calculate pass rate
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
- In interactive mode, discuss findings with user
@@ -81,55 +81,17 @@ The BMAD Method uses various checklists to ensure quality and completeness of di
- Specific recommendations for improvement
- Any sections or items marked as N/A with justification
## Special Considerations
## Checklist Execution Methodology
1. **Architecture Checklist**
Each checklist now contains embedded LLM prompts and instructions that will:
- Focus on technical completeness and clarity
- Verify all system components are addressed
- Check for security and scalability considerations
- Ensure deployment and operational aspects are covered
1. **Guide thorough thinking** - Prompts ensure deep analysis of each section
2. **Request specific artifacts** - Clear instructions on what documents/access is needed
3. **Provide contextual guidance** - Section-specific prompts for better validation
4. **Generate comprehensive reports** - Final summary with detailed findings
2. **Frontend Architecture Checklist**
The LLM will:
- Validate UI/UX specifications
- Check component structure and organization
- Verify state management approach
- Ensure responsive design considerations
3. **PM Checklist**
- Focus on product requirements clarity
- Verify user stories and acceptance criteria
- Check market and user research coverage
- Ensure technical feasibility is addressed
4. **Story Checklists**
- Verify clear acceptance criteria
- Check for technical context and dependencies
- Ensure testability is addressed
- Validate user value is clearly stated
## Success Criteria
The checklist validation is complete when:
1. All applicable items have been assessed
2. Clear pass/fail status for each item
3. Specific recommendations provided for failed items
4. User has reviewed and acknowledged findings
5. Final report documents all decisions and rationales
## Example Interaction
Agent: "Let me check the available checklists... According to checklist-mappings.yml, we have several options. Which would you like to use?"
User: "The architect checklist"
Agent: "Would you like to work through it section by section (interactive) or get a complete analysis all at once (YOLO mode)?"
User: "Interactive please"
Agent: "According to the mappings, I need to check for architecture.md. The default location is docs/architecture.md. Should I look there?"
[Continue interaction based on user responses...]
- Execute the complete checklist validation
- Present a final report with pass/fail rates and key findings
- Offer to provide detailed analysis of any section, especially those with warnings or failures

22
bmad-core/templates/brownfield-prd-tmpl.md
View File

@@ -10,7 +10,7 @@ This PRD is for SIGNIFICANT enhancements to existing projects that require compr
3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions.]]
## Project Analysis and Context
## Intro Project Analysis and Context
[[LLM: Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements.
@@ -73,21 +73,21 @@ Do not proceed with any recommendations until the user has validated your unders
- [ ] Significant Impact (substantial existing code changes)
- [ ] Major Impact (architectural changes required)
### Goals and Background Context
#### Goals
[[LLM: Bullet list of 1-line desired outcomes this enhancement will deliver if successful]]
#### Background Context
[[LLM: 1-2 short paragraphs explaining why this enhancement is needed, what problem it solves, and how it fits with the existing project]]
### Change Log
| Change | Date | Version | Description | Author |
| ------ | ---- | ------- | ----------- | ------ |
## Goals and Background Context
### Goals
[[LLM: Bullet list of 1-line desired outcomes this enhancement will deliver if successful]]
### Background Context
[[LLM: 1-2 short paragraphs explaining why this enhancement is needed, what problem it solves, and how it fits with the existing project]]
## Requirements
[[LLM: Draft functional and non-functional requirements based on your validated understanding of the existing project. Before presenting requirements, confirm: "These requirements are based on my understanding of your existing system. Please review carefully and confirm they align with your project's reality." Then immediately execute tasks#advanced-elicitation display]]