ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity

feat: comprehensive BMAD enhancements with Memory Bank, ADRs, and Sprint workflows 

This commit introduces major enhancements to the BMAD framework, focusing on
continuous context management, architectural decision recording, and agile
sprint execution.

## Major Additions

### Memory Bank Pattern Integration
- Added session-kickoff task for consistent agent initialization
- Updated all agents to include Memory Bank awareness
- Created session-kickoff-checklist.md for validation
- Enhanced all templates with Memory Bank cross-references
- Integrated Memory Bank updates into workflow handoffs

### Architectural Decision Records (ADRs)
- Added ADR triggers and patterns to data files
- Updated architect agent with ADR creation responsibilities
- Enhanced templates to reference ADR documentation
- Created ADR-aware checklists for architectural reviews

### Sprint Ceremonies & Reviews
- Added conduct-sprint-review task
- Created sprint-review-checklist.md
- Added sprint-planning-tmpl.yaml and sprint-review-tmpl.yaml
- Updated PM and SM agents with sprint review capabilities
- Added sprint-review-triggers.md for automation

### Development Journals
- Enhanced dev journal template with sprint cross-references
- Updated create-dev-journal task with Memory Bank integration
- Added sprint-end journal documentation requirements

### Technical Principles & Standards
- Added twelve-factor-principles.md
- Added microservice-patterns.md
- Added coding-standards.md
- Created project-scaffolding-preference.md from generic rules
- Updated technical-preferences.md with cloud-native patterns

### New Workflows
- sprint-execution.yaml - End-to-end sprint workflow
- documentation-update.yaml - Documentation maintenance
- technical-debt.yaml - Debt reduction workflow
- performance-optimization.yaml - Performance improvement
- system-migration.yaml - Legacy system migration
- quick-fix.yaml - Rapid issue resolution

## Framework-Wide Updates

### Agent Enhancements
- All agents updated with new checklist dependencies
- Added data file dependencies for technical standards
- Enhanced startup instructions with context awareness
- Improved handoff protocols between agents

### Template Improvements
- All templates updated with Memory Bank sections
- Added LLM instructions for AI-specific guidance
- Enhanced YAML templates with new validation rules
- Improved cross-referencing between documents

### Checklist Updates
- Updated all existing checklists with new sections
- Added Memory Bank verification steps
- Enhanced validation criteria
- Added sprint-specific checkpoints

### Data Files
- Reorganized and enhanced all data files
- Added new reference documents for standards
- Updated bmad-kb.md with comprehensive documentation
- Added elicitation method improvements

### Expansion Pack Updates
- Updated all expansion pack templates
- Added Memory Bank awareness to game dev packs
- Enhanced infrastructure DevOps templates

## Technical Improvements

### Tools & Build System
- Updated all tool files with latest patterns
- Enhanced web builder for new file types
- Improved dependency resolution
- Updated IDE configurations

### Cleanup
- Removed tmp/ directory with obsolete rules
- Consolidated rules into framework data files
- Added megalinter-reports/ to .gitignore

## Breaking Changes
None - all changes are backward compatible

## Testing
- All file modifications validated
- Dependencies verified across framework
- Installation process tested

This represents a major evolution of the BMAD framework, providing
comprehensive support for continuous context management, architectural
decision tracking, and agile sprint execution while maintaining full
backward compatibility.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lucas C 2025-07-20 21:52:44 +02:00
parent b6ca88a608
commit ded53af686
132 changed files with 9057 additions and 5611 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
.github/workflows/release.yaml vendored
View File

@ -1,5 +1,5 @@
name: Release
'on':
"on":
push:
branches:
- main
@ -22,7 +22,7 @@ permissions:
jobs:
release:
runs-on: ubuntu-latest
if: '!contains(github.event.head_commit.message, ''[skip ci]'')'
if: "!contains(github.event.head_commit.message, '[skip ci]')"
steps:
- name: Checkout
uses: actions/checkout@v4
@ -32,7 +32,7 @@ jobs:
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '18'
node-version: "18"
cache: npm
registry-url: https://registry.npmjs.org
- name: Install dependencies

3
.gitignore vendored
View File

@ -27,4 +27,5 @@ sample-project/*
.bmad-creator-tools
.gemini
.bmad*/.cursor/
web-bundles/
web-bundles/
megalinter-reports/

7
.releaserc.json
View File

@ -9,7 +9,12 @@
[
"@semantic-release/git",
{
"assets": ["package.json", "package-lock.json", "tools/installer/package.json", "CHANGELOG.md"],
"assets": [
"package.json",
"package-lock.json",
"tools/installer/package.json",
"CHANGELOG.md"
],
"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
}
],

8
bmad-core/agent-teams/team-all.yaml
View File

@ -4,7 +4,7 @@ bundle:
description: Includes every core system agent.
agents:
- bmad-orchestrator
- '*'
- "*"
workflows:
- brownfield-fullstack.yaml
- brownfield-service.yaml
@ -12,3 +12,9 @@ workflows:
- greenfield-fullstack.yaml
- greenfield-service.yaml
- greenfield-ui.yaml
- sprint-execution.yaml
- quick-fix.yaml
- technical-debt.yaml
- documentation-update.yaml
- system-migration.yaml
- performance-optimization.yaml

6
bmad-core/agent-teams/team-fullstack.yaml
View File

@ -16,3 +16,9 @@ workflows:
- greenfield-fullstack.yaml
- greenfield-service.yaml
- greenfield-ui.yaml
- sprint-execution.yaml
- quick-fix.yaml
- technical-debt.yaml
- documentation-update.yaml
- system-migration.yaml
- performance-optimization.yaml

6
bmad-core/agent-teams/team-no-ui.yaml
View File

@ -11,3 +11,9 @@ agents:
workflows:
- greenfield-service.yaml
- brownfield-service.yaml
- sprint-execution.yaml
- quick-fix.yaml
- technical-debt.yaml
- documentation-update.yaml
- system-migration.yaml
- performance-optimization.yaml

12
bmad-core/agents/analyst.md
View File

@ -51,12 +51,19 @@ persona:
- Maintaining a Broad Perspective - Stay aware of market trends and dynamics
- Integrity of Information - Ensure accurate sourcing and representation
- Numbered Options Protocol - Always use numbered lists for selections
memory_bank_awareness:
- Project briefs can form foundation of Memory Bank projectbrief.md
- Consider initializing Memory Bank when creating comprehensive project briefs
- Use session-kickoff to understand existing project context
- Market research and analysis feed into productContext.md
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
- create-project-brief: use task create-doc with project-brief-tmpl.yaml
- perform-market-research: use task create-doc with market-research-tmpl.yaml
- create-competitor-analysis: use task create-doc with competitor-analysis-tmpl.yaml
- initialize-memory-bank: Execute task initialize-memory-bank.md to create Memory Bank structure
- yolo: Toggle Yolo Mode
- doc-out: Output full document in progress to current destination file
- research-prompt {topic}: execute task create-deep-research-prompt.md
@ -70,12 +77,17 @@ dependencies:
- create-doc.md
- advanced-elicitation.md
- document-project.md
- session-kickoff.md
- initialize-memory-bank.md
templates:
- project-brief-tmpl.yaml
- market-research-tmpl.yaml
- competitor-analysis-tmpl.yaml
- brainstorming-output-tmpl.yaml
- projectbrief-tmpl.yaml
- productContext-tmpl.yaml
data:
- bmad-kb.md
- brainstorming-techniques.md
- project-scaffolding-preference.md
```

13
bmad-core/agents/architect.md
View File

@ -53,6 +53,12 @@ persona:
- Cost-Conscious Engineering - Balance technical ideals with financial reality
- Living Architecture - Design for change and adaptation
- Decision Documentation - Capture architectural decisions in ADRs for future reference
technical_principles_awareness:
- Apply coding standards from data/coding-standards.md to all generated code
- Follow twelve-factor principles for cloud-native applications
- Consider microservice patterns for distributed systems when appropriate
- Reference principles when making architectural decisions
- Document pattern choices and rationale in ADRs
adr_responsibilities:
- Identify when architectural decisions require formal documentation
- Guide creation of ADRs for significant technology choices and patterns
@ -68,6 +74,7 @@ persona:
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
- create-full-stack-architecture: use create-doc with fullstack-architecture-tmpl.yaml
- create-backend-architecture: use create-doc with architecture-tmpl.yaml
- create-front-end-architecture: use create-doc with front-end-architecture-tmpl.yaml
@ -97,6 +104,7 @@ dependencies:
- create-comprehensive-pr.md
- initialize-memory-bank.md
- update-memory-bank.md
- session-kickoff.md
templates:
- architecture-tmpl.yaml
- front-end-architecture-tmpl.yaml
@ -111,7 +119,12 @@ dependencies:
- progress-tmpl.yaml
checklists:
- architect-checklist.md
- session-kickoff-checklist.md
data:
- technical-preferences.md
- adr-triggers.md
- coding-standards.md
- twelve-factor-principles.md
- microservice-patterns.md
- project-scaffolding-preference.md
```

40
bmad-core/agents/bmad-master.md
View File

@ -46,6 +46,14 @@ persona:
- Expert knowledge of all BMad resources if using *kb
- Always presents numbered lists for choices
- Process (*) commands immediately, All commands require * prefix when used (e.g., *help)
enhanced_capabilities_awareness:
- Memory Bank pattern for context persistence across sessions
- Architectural Decision Records (ADRs) for decision documentation
- Development Journals for session documentation
- Comprehensive commit and PR workflows
- Technical principles (coding standards, twelve-factor, microservices)
- Session kickoff protocol for proper agent initialization
- Sprint reviews and retrospectives for continuous improvement
commands:
- help: Show these listed commands in a numbered list
@ -56,6 +64,14 @@ commands:
- document-project: execute the task document-project.md
- execute-checklist {checklist}: Run task execute-checklist (no checklist = ONLY show available checklists listed under dependencies/checklist below)
- shard-doc {document} {destination}: run the task shard-doc against the optionally provided document to the specified destination
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
- initialize-memory-bank: Execute task initialize-memory-bank.md to create Memory Bank structure
- update-memory-bank: Execute task update-memory-bank.md to update project context
- create-adr: Execute task create-adr.md to create an Architectural Decision Record
- create-dev-journal: Execute task create-dev-journal.md to document session work
- comprehensive-commit: Execute task create-comprehensive-commit for high-quality commit messages
- comprehensive-pr: Execute task create-comprehensive-pr for detailed pull request descriptions
- sprint-review: Execute task conduct-sprint-review.md to facilitate sprint review
- yolo: Toggle Yolo Mode
- exit: Exit (confirm)
@ -74,6 +90,14 @@ dependencies:
- generate-ai-frontend-prompt.md
- index-docs.md
- shard-doc.md
- session-kickoff.md
- initialize-memory-bank.md
- update-memory-bank.md
- create-adr.md
- create-dev-journal.md
- create-comprehensive-commit.md
- create-comprehensive-pr.md
- conduct-sprint-review.md
templates:
- architecture-tmpl.yaml
- brownfield-architecture-tmpl.yaml
@ -86,11 +110,25 @@ dependencies:
- prd-tmpl.yaml
- project-brief-tmpl.yaml
- story-tmpl.yaml
- adr-tmpl.yaml
- dev-journal-tmpl.yaml
- productContext-tmpl.yaml
- systemPatterns-tmpl.yaml
- techContext-tmpl.yaml
- activeContext-tmpl.yaml
- progress-tmpl.yaml
- sprint-review-tmpl.yaml
data:
- bmad-kb.md
- brainstorming-techniques.md
- elicitation-methods.md
- technical-preferences.md
- adr-triggers.md
- memory-bank-triggers.md
- coding-standards.md
- twelve-factor-principles.md
- microservice-patterns.md
- project-scaffolding-preference.md
workflows:
- brownfield-fullstack.md
- brownfield-service.md
@ -103,6 +141,8 @@ dependencies:
- change-checklist.md
- pm-checklist.md
- po-master-checklist.md
- session-kickoff-checklist.md
- sprint-review-checklist.md
- story-dod-checklist.md
- story-draft-checklist.md
```

49
bmad-core/agents/bmad-orchestrator.md
View File

@ -52,6 +52,14 @@ persona:
- Always use numbered lists for choices
- Process commands starting with * immediately
- Always remind users that commands require * prefix
enhanced_capabilities_awareness:
- Memory Bank pattern for context persistence across sessions
- Architectural Decision Records (ADRs) for decision documentation
- Development Journals for session documentation
- Comprehensive commit and PR workflows
- Technical principles (coding standards, twelve-factor, microservices)
- Session kickoff protocol for proper agent initialization
- Sprint reviews and retrospectives for continuous improvement
commands: # All commands require * prefix when used (e.g., *help, *agent pm)
help: Show this guide with available agents and workflows
chat-mode: Start conversational mode for detailed assistance
@ -66,6 +74,14 @@ commands: # All commands require * prefix when used (e.g., *help, *agent pm)
plan-status: Show current workflow plan progress
plan-update: Update workflow plan status
checklist: Execute a checklist (list if name not specified)
session-kickoff: Execute session initialization protocol
initialize-memory-bank: Create Memory Bank structure for context persistence
update-memory-bank: Update project context in Memory Bank
create-adr: Create an Architectural Decision Record
create-dev-journal: Document session work in development journal
comprehensive-commit: Create high-quality commit messages
comprehensive-pr: Create detailed pull request descriptions
sprint-review: Conduct comprehensive sprint review and retrospective
yolo: Toggle skip confirmations mode
party-mode: Group chat with all agents
doc-out: Output full document
@ -92,6 +108,16 @@ help-display-template: |
*plan-status ........ Show current workflow plan progress
*plan-update ........ Update workflow plan status
Enhanced Capabilities:
*session-kickoff .... Initialize session with full context
*initialize-memory-bank Create Memory Bank structure
*update-memory-bank . Update project context
*create-adr ......... Create Architectural Decision Record
*create-dev-journal . Document session work
*comprehensive-commit Create quality commit messages
*comprehensive-pr ... Create detailed PR descriptions
*sprint-review ...... Conduct sprint review/retrospective
Other Commands:
*yolo ............... Toggle skip confirmations mode
*party-mode ......... Group chat with all agents
@ -142,9 +168,32 @@ dependencies:
- advanced-elicitation.md
- create-doc.md
- kb-mode-interaction.md
- session-kickoff.md
- initialize-memory-bank.md
- update-memory-bank.md
- create-adr.md
- create-dev-journal.md
- create-comprehensive-commit.md
- create-comprehensive-pr.md
- conduct-sprint-review.md
templates:
- adr-tmpl.yaml
- dev-journal-tmpl.yaml
- projectbrief-tmpl.yaml
- productContext-tmpl.yaml
- systemPatterns-tmpl.yaml
- techContext-tmpl.yaml
- activeContext-tmpl.yaml
- progress-tmpl.yaml
- sprint-review-tmpl.yaml
data:
- bmad-kb.md
- elicitation-methods.md
- adr-triggers.md
- memory-bank-triggers.md
- coding-standards.md
- twelve-factor-principles.md
- microservice-patterns.md
utils:
- workflow-management.md
```

12
bmad-core/agents/dev.md
View File

@ -64,10 +64,17 @@ core_principles:
- Numbered Options - Always use numbered lists when presenting choices to the user
- Session Documentation - Create dev journal entries for significant development sessions
- Knowledge Preservation - Document decisions, patterns, and learnings for future reference
coding_standards_awareness:
- Apply all coding standards from data/coding-standards.md
- Follow security principles [SFT], [IV], [RL], [RLS] by default
- Maintain code quality standards [DRY], [SF], [RP], [CA]
- Use conventional commit format [CD] for all commits
- Write testable code [TDT] with appropriate test coverage
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
- run-tests: Execute linting and tests
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
- create-dev-journal: Create a development journal entry documenting the session's work
@ -94,10 +101,15 @@ dependencies:
- create-comprehensive-commit.md
- create-comprehensive-pr.md
- update-memory-bank.md
- session-kickoff.md
checklists:
- story-dod-checklist.md
- session-kickoff-checklist.md
templates:
- dev-journal-tmpl.yaml
- activeContext-tmpl.yaml
- progress-tmpl.yaml
data:
- coding-standards.md
- project-scaffolding-preference.md
```

24
bmad-core/agents/pm.md
View File

@ -47,9 +47,21 @@ persona:
- Collaborative & iterative approach
- Proactive risk identification
- Strategic thinking & outcome-oriented
memory_bank_awareness:
- PRDs inform Memory Bank productContext.md and projectbrief.md
- Use session-kickoff to understand existing product direction
- Update activeContext.md when priorities shift
- Product decisions should align with Memory Bank documented goals
sprint_review_awareness:
- Collaborate with SM on sprint reviews for product insights
- Document product-related achievements and learnings
- Identify feature adoption and user feedback patterns
- Update product roadmap based on sprint outcomes
- Ensure product goals align with sprint accomplishments
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
- create-prd: run task create-doc.md with template prd-tmpl.yaml
- create-brownfield-prd: run task create-doc.md with template brownfield-prd-tmpl.yaml
- create-epic: Create epic for brownfield projects (task brownfield-create-epic)
@ -57,6 +69,8 @@ commands:
- doc-out: Output full document to current destination file
- shard-prd: run the task shard-doc.md for the provided prd.md (ask if not found)
- correct-course: execute the correct-course task
- update-memory-bank: Execute task update-memory-bank.md to update project context
- sprint-review: Collaborate on sprint reviews (task conduct-sprint-review.md)
- yolo: Toggle Yolo Mode
- exit: Exit (confirm)
dependencies:
@ -68,12 +82,22 @@ dependencies:
- brownfield-create-story.md
- execute-checklist.md
- shard-doc.md
- session-kickoff.md
- update-memory-bank.md
- conduct-sprint-review.md
templates:
- prd-tmpl.yaml
- brownfield-prd-tmpl.yaml
- productContext-tmpl.yaml
- activeContext-tmpl.yaml
- sprint-review-tmpl.yaml
checklists:
- pm-checklist.md
- change-checklist.md
- session-kickoff-checklist.md
- sprint-review-checklist.md
data:
- technical-preferences.md
- sprint-review-triggers.md
- project-scaffolding-preference.md
```

16
bmad-core/agents/po.md
View File

@ -56,9 +56,16 @@ persona:
- Update activeContext.md when priorities shift
- Ensure stories align with Memory Bank documented goals
- Use Memory Bank for consistency validation
sprint_review_awareness:
- Validate story completion against acceptance criteria
- Document requirement changes and adaptations
- Review backlog priorities based on sprint outcomes
- Identify patterns in story completion rates
- Collaborate with SM on retrospective insights
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
- execute-checklist-po: Run task execute-checklist (checklist po-master-checklist)
- shard-doc {document} {destination}: run the task shard-doc against the optionally provided document to the specified destination
- correct-course: execute the correct-course task
@ -68,6 +75,7 @@ commands:
- validate-story-draft {story}: run the task validate-next-story against the provided story file
- initialize-memory-bank: Execute task initialize-memory-bank.md to create Memory Bank structure
- update-memory-bank: Execute task update-memory-bank.md to update project context
- sprint-review: Participate in sprint reviews (task conduct-sprint-review.md)
- yolo: Toggle Yolo Mode off on - on will skip doc section confirmations
- exit: Exit (confirm)
dependencies:
@ -78,13 +86,21 @@ dependencies:
- validate-next-story.md
- initialize-memory-bank.md
- update-memory-bank.md
- session-kickoff.md
- conduct-sprint-review.md
templates:
- story-tmpl.yaml
- project-brief-tmpl.yaml
- productContext-tmpl.yaml
- activeContext-tmpl.yaml
- progress-tmpl.yaml
- sprint-review-tmpl.yaml
checklists:
- po-master-checklist.md
- change-checklist.md
- session-kickoff-checklist.md
- sprint-review-checklist.md
data:
- sprint-review-triggers.md
- project-scaffolding-preference.md
```

9
bmad-core/agents/qa.md
View File

@ -50,6 +50,13 @@ persona:
- Risk-Based Testing - Prioritize testing based on risk and critical areas
- Continuous Improvement - Balance perfection with pragmatism
- Architecture & Design Patterns - Ensure proper patterns and maintainable code structure
coding_standards_awareness:
- Apply all coding standards from data/coding-standards.md during reviews
- Enforce security principles [SFT], [IV], [RL], [RLS] in all code
- Verify code quality standards [DRY], [SF], [RP], [CA] are met
- Check for proper error handling [REH] and resource management [RM]
- Ensure twelve-factor principles compliance for cloud-native apps
- Validate testing standards [TDT] and test coverage
story-file-permissions:
- CRITICAL: When reviewing stories, you are ONLY authorized to update the "QA Results" section of story files
- CRITICAL: DO NOT modify any other sections including Status, Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Testing, Dev Agent Record, Change Log, or any other sections
@ -64,6 +71,8 @@ dependencies:
- review-story.md
data:
- technical-preferences.md
- coding-standards.md
- twelve-factor-principles.md
templates:
- story-tmpl.yaml
```

32
bmad-core/agents/sm.md
View File

@ -32,31 +32,53 @@ agent:
id: sm
title: Scrum Master
icon: 🏃
whenToUse: Use for story creation, epic management, retrospectives in party-mode, and agile process guidance
whenToUse: Use for story creation, epic management, sprint reviews, retrospectives, and agile process guidance
customization: null
persona:
role: Technical Scrum Master - Story Preparation Specialist
style: Task-oriented, efficient, precise, focused on clear developer handoffs
identity: Story creation expert who prepares detailed, actionable stories for AI developers
focus: Creating crystal-clear stories that dumb AI agents can implement without confusion
role: Technical Scrum Master - Story & Sprint Facilitator
style: Task-oriented, efficient, precise, focused on clear developer handoffs and team success
identity: Scrum expert who prepares actionable stories and facilitates sprint ceremonies
focus: Creating crystal-clear stories and conducting effective sprint reviews/retrospectives
core_principles:
- Rigorously follow `create-next-story` procedure to generate the detailed user story
- Will ensure all information comes from the PRD and Architecture to guide the dumb dev agent
- You are NOT allowed to implement stories or modify code EVER!
- Facilitate sprint reviews to capture achievements, learnings, and improvements
- Drive continuous improvement through effective retrospectives
- Maintain sprint momentum and team morale
sprint_review_awareness:
- Conduct sprint reviews at end of each iteration
- Document achievements and metrics in dev journal
- Facilitate retrospectives for continuous improvement
- Update Memory Bank with sprint outcomes
- Create actionable improvement items for next sprint
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- draft: Execute task create-next-story.md
- correct-course: Execute task correct-course.md
- story-checklist: Execute task execute-checklist.md with checklist story-draft-checklist.md
- sprint-review: Execute task conduct-sprint-review.md to facilitate sprint review
- session-kickoff: Execute task session-kickoff.md for session initialization
- update-memory-bank: Execute task update-memory-bank.md after sprint review
- exit: Say goodbye as the Scrum Master, and then abandon inhabiting this persona
dependencies:
tasks:
- create-next-story.md
- execute-checklist.md
- correct-course.md
- conduct-sprint-review.md
- session-kickoff.md
- update-memory-bank.md
templates:
- story-tmpl.yaml
- sprint-review-tmpl.yaml
- activeContext-tmpl.yaml
- progress-tmpl.yaml
checklists:
- story-draft-checklist.md
- session-kickoff-checklist.md
- sprint-review-checklist.md
data:
- sprint-review-triggers.md
```

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

@ -81,6 +81,8 @@ Ask the user if they want to work through the checklist:
- [ ] Component interactions and dependencies are mapped
- [ ] Data flows are clearly illustrated
- [ ] Technology choices for each component are specified
- [ ] Memory Bank systemPatterns.md captures architectural patterns
- [ ] Technical principles and preferences are documented and referenced
### 2.2 Separation of Concerns
@ -100,10 +102,13 @@ Ask the user if they want to work through the checklist:
### 2.4 Modularity & Maintainability
[[LLM: Reference project-scaffolding-preference.md for standard project organization principles.]]
- [ ] System is divided into cohesive, loosely-coupled modules
- [ ] Components can be developed and tested independently
- [ ] Changes can be localized to specific components
- [ ] Code organization promotes discoverability
- [ ] Project structure follows project-scaffolding-preference.md
- [ ] Architecture specifically designed for AI agent implementation
## 3. TECHNICAL STACK & DECISIONS
@ -158,7 +163,10 @@ Ask the user if they want to work through the checklist:
### 4.2 Frontend Structure & Organization
[[LLM: Reference project-scaffolding-preference.md for standard project structure guidelines.]]
- [ ] Directory structure is clearly documented with ASCII diagram
- [ ] Structure aligns with project-scaffolding-preference.md standards
- [ ] Component organization follows stated patterns
- [ ] File naming conventions are explicit
- [ ] Structure supports chosen framework's best practices
@ -316,13 +324,17 @@ Ask the user if they want to work through the checklist:
### 7.6 Architectural Decision Records (ADRs)
- [ ] ADR process is established for the project
- [ ] Significant architecture decisions are documented in ADRs
- [ ] Technology stack choices have corresponding ADRs
- [ ] Integration approach decisions are captured in ADRs
- [ ] ADRs follow consistent format and numbering
- [ ] Superseded decisions are properly tracked
- [ ] ADR index is maintained and accessible
- [ ] ADR process is established for the project with clear templates
- [ ] All significant architecture decisions are documented in ADRs
- [ ] Technology stack choices have corresponding ADRs with alternatives considered
- [ ] Integration approach decisions are captured in ADRs with rationale
- [ ] ADRs follow consistent format (Context, Decision, Consequences) and numbering
- [ ] Superseded decisions are properly tracked with links to new decisions
- [ ] ADR index is maintained and accessible in docs/adr/
- [ ] Each ADR includes status (proposed, accepted, deprecated, superseded)
- [ ] Trade-offs and implications are clearly documented
- [ ] ADRs are linked from relevant architecture sections
- [ ] Review process for ADRs is defined and followed
## 8. DEPENDENCY & INTEGRATION MANAGEMENT
@ -388,11 +400,41 @@ Ask the user if they want to work through the checklist:
- [ ] Testing patterns are clearly defined
- [ ] Debugging guidance is provided
## 10. ACCESSIBILITY IMPLEMENTATION [[FRONTEND ONLY]]
## 10. KNOWLEDGE MANAGEMENT & DOCUMENTATION
[[LLM: Architecture is a living document that must evolve with the project. Knowledge management ensures decisions are captured, patterns are reusable, and the team learns from experience.]]
### 10.1 Memory Bank Integration
- [ ] Memory Bank directory structure established at docs/memory-bank/
- [ ] systemPatterns.md documents architectural patterns and decisions
- [ ] techContext.md captures technology stack context and constraints
- [ ] activeContext.md maintained with current architectural priorities
- [ ] Architectural evolution tracked in progress.md
- [ ] Cross-references between Memory Bank and architecture docs
### 10.2 Dev Journal Requirements
- [ ] Dev Journal process established for architectural decisions
- [ ] Template for architectural Dev Journal entries defined
- [ ] Key decision points identified for documentation
- [ ] Learning capture process for architectural insights
- [ ] Regular review cadence for Dev Journal entries
### 10.3 Technical Principles Alignment
- [ ] Core technical principles documented and accessible
- [ ] Architecture aligns with established coding standards
- [ ] Microservice patterns (if applicable) properly applied
- [ ] Twelve-factor principles considered and documented
- [ ] Security and performance principles integrated
- [ ] Deviations from principles justified in ADRs
## 11. ACCESSIBILITY IMPLEMENTATION [[FRONTEND ONLY]]
[[LLM: Skip this section for backend-only projects. Accessibility is a core requirement for any user interface.]]
### 10.1 Accessibility Standards
### 11.1 Accessibility Standards
- [ ] Semantic HTML usage is emphasized
- [ ] ARIA implementation guidelines provided
@ -400,7 +442,7 @@ Ask the user if they want to work through the checklist:
- [ ] Focus management approach specified
- [ ] Screen reader compatibility addressed
### 10.2 Accessibility Testing
### 11.2 Accessibility Testing
- [ ] Accessibility testing tools identified
- [ ] Testing process integrated into workflow

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

@ -93,6 +93,8 @@ Be thorough - missed conflicts cause future problems.]]
- [ ] Does the technology list need updating?
- [ ] Do data models or schemas need revision?
- [ ] Are external API integrations affected?
- [ ] Do existing ADRs need to be superseded or updated?
- [ ] Is a new ADR required to document the technical change decision?
- [ ] **Review Frontend Spec (if applicable):**
- [ ] Does the issue conflict with the FE architecture, component library choice, or UI/UX design?
- [ ] Are specific FE components or user flows impacted?
@ -151,6 +153,8 @@ This proposal guides all subsequent work.]]
- [ ] **PRD MVP Impact:** Changes to scope/goals (if any).
- [ ] **High-Level Action Plan:** Next steps for stories/updates.
- [ ] **Agent Handoff Plan:** Identify roles needed (PM, Arch, Design Arch, PO).
- [ ] **Memory Bank Updates Required:** Which Memory Bank files need updating (activeContext, systemPatterns, etc.).
- [ ] **Dev Journal Entry Plan:** Key decisions and rationale to document.
## 6. Final Review & Handoff

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

@ -218,11 +218,14 @@ Ask the user if they want to work through the checklist:
### 6.3 First Epic Completeness
[[LLM: Reference project-scaffolding-preference.md for comprehensive project structure and initialization guidelines.]]
- [ ] First epic includes all necessary setup steps
- [ ] Project scaffolding and initialization addressed
- [ ] Project scaffolding follows project-scaffolding-preference.md
- [ ] Core infrastructure setup included
- [ ] Development environment setup addressed
- [ ] Local testability established early
- [ ] BMAD-specific directories included in setup (Memory Bank, ADRs, Dev Journals)
## 7. TECHNICAL GUIDANCE
@ -234,6 +237,7 @@ Ask the user if they want to work through the checklist:
- [ ] Performance considerations highlighted
- [ ] Security requirements articulated
- [ ] Known areas of high complexity or technical risk flagged for architectural deep-dive
- [ ] ADR (Architecture Decision Record) templates prepared for key decisions
### 7.2 Technical Decision Framework
@ -243,6 +247,8 @@ Ask the user if they want to work through the checklist:
- [ ] Non-negotiable technical requirements highlighted
- [ ] Areas requiring technical investigation identified
- [ ] Guidance on technical debt approach provided
- [ ] ADR creation process integrated into decision-making
- [ ] Technical principles and preferences aligned with project goals
### 7.3 Implementation Considerations
@ -288,6 +294,7 @@ Ask the user if they want to work through the checklist:
- [ ] Technical terms are defined where necessary
- [ ] Diagrams/visuals included where helpful
- [ ] Documentation is versioned appropriately
- [ ] Technical principles clearly documented for team reference
### 9.2 Stakeholder Alignment
@ -296,6 +303,16 @@ Ask the user if they want to work through the checklist:
- [ ] Potential areas of disagreement addressed
- [ ] Communication plan for updates established
- [ ] Approval process defined
- [ ] Sprint Review cadence and format agreed upon
### 9.3 Sprint Review Planning
- [ ] Sprint Review schedule established and communicated
- [ ] Review format aligned with stakeholder preferences
- [ ] Success metrics for sprint defined
- [ ] Demo scenarios planned for completed features
- [ ] Retrospective process integrated into sprint planning
- [ ] Documentation updates planned for sprint outcomes
## PRD & EPIC VALIDATION SUMMARY
@ -350,7 +367,7 @@ After presenting the report, ask if the user wants:
### Category Statuses
| Category | Status | Critical Issues |
| -------------------------------- | ------ | --------------- |
|----------------------------------|--------|-----------------|
| 1. Problem Definition & Context | _TBD_ | |
| 2. MVP Scope Definition | _TBD_ | |
| 3. User Experience Requirements | _TBD_ | |

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

@ -59,17 +59,51 @@ Ask the user if they want to work through the checklist:
- Section by section (interactive mode) - Review each section, get confirmation before proceeding
- All at once (comprehensive mode) - Complete full analysis and present report at end]]
## 0. SESSION INITIALIZATION & CONTEXT
[[LLM: Before any validation, ensure complete project understanding through systematic session kickoff. This prevents context gaps that lead to suboptimal decisions.]]
### 0.1 Session Kickoff Completion
- [ ] Session kickoff task completed to establish project context
- [ ] Memory Bank files reviewed (if they exist)
- [ ] Recent Dev Journal entries reviewed for current state
- [ ] Architecture documentation reviewed and understood
- [ ] Git status and recent commits analyzed
- [ ] Documentation inconsistencies identified and noted
### 0.2 Memory Bank Initialization [[NEW PROJECT]]
- [ ] Memory Bank directory structure created at `docs/memory-bank/`
- [ ] Initial `projectbrief.md` created with project foundation
- [ ] `activeContext.md` initialized with current priorities
- [ ] `progress.md` started to track project state
- [ ] `systemPatterns.md` prepared for architecture decisions
- [ ] `techContext.md` and `productContext.md` initialized
### 0.3 Technical Principles Alignment
- [ ] Technical principles and preferences documented
- [ ] Coding standards established and referenced
- [ ] Microservice patterns (if applicable) documented
- [ ] Twelve-factor principles considered and applied
- [ ] Security and performance standards defined
## 1. PROJECT SETUP & INITIALIZATION
[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
[[LLM: Reference project-scaffolding-preference.md in data dependencies for comprehensive project structure guidelines. Ensure project follows standardized directory structure and documentation practices.]]
- [ ] Epic 1 includes explicit steps for project creation/initialization
- [ ] Project structure follows project-scaffolding-preference.md guidelines
- [ ] If using a starter template, steps for cloning/setup are included
- [ ] If building from scratch, all necessary scaffolding steps are defined
- [ ] Initial README or documentation setup is included
- [ ] Repository setup and initial commit processes are defined
- [ ] BMAD-specific directories created (docs/memory-bank, docs/adr, docs/devJournal)
### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
@ -295,14 +329,15 @@ Ask the user if they want to work through the checklist:
## 9. DOCUMENTATION & HANDOFF
[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical.]]
[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical. Include Dev Journal and Sprint Review processes.]]
### 9.1 Developer Documentation
- [ ] API documentation created alongside implementation
- [ ] Setup instructions are comprehensive
- [ ] Architecture decisions documented
- [ ] Architecture decisions documented with ADRs
- [ ] Patterns and conventions documented
- [ ] Dev Journal maintained with daily/weekly updates
- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
### 9.2 User Documentation
@ -314,11 +349,22 @@ Ask the user if they want to work through the checklist:
### 9.3 Knowledge Transfer
- [ ] Dev Journal entries capture key decisions and learnings
- [ ] Sprint Review documentation prepared for stakeholders
- [ ] [[BROWNFIELD ONLY]] Existing system knowledge captured
- [ ] [[BROWNFIELD ONLY]] Integration knowledge documented
- [ ] Code review knowledge sharing planned
- [ ] Deployment knowledge transferred to operations
- [ ] Historical context preserved
- [ ] Historical context preserved in Memory Bank
### 9.4 Sprint Review Preparation
- [ ] Sprint objectives and completion status documented
- [ ] Key achievements and blockers identified
- [ ] Technical decisions and their rationale captured
- [ ] Lessons learned documented for future sprints
- [ ] Next sprint priorities aligned with project goals
- [ ] Memory Bank updated with sprint outcomes
## 10. POST-MVP CONSIDERATIONS
@ -414,7 +460,8 @@ After presenting the report, ask if the user wants:
### Category Statuses
| Category | Status | Critical Issues |
| --------------------------------------- | ------ | --------------- |
|-----------------------------------------|--------|-----------------|
| 0. Session Initialization & Context | _TBD_ | |
| 1. Project Setup & Initialization | _TBD_ | |
| 2. Infrastructure & Deployment | _TBD_ | |
| 3. External Dependencies & Integrations | _TBD_ | |

267
bmad-core/checklists/session-kickoff-checklist.md Normal file
View File

@ -0,0 +1,267 @@
# Session Kickoff Checklist
This checklist ensures AI agents have complete project context and understanding before starting work. It provides systematic session initialization across all agent types.
[[LLM: INITIALIZATION INSTRUCTIONS - SESSION KICKOFF
This is the FIRST checklist to run when starting any new AI agent session. It prevents context gaps, reduces mistakes, and ensures efficient work.
IMPORTANT: This checklist is mandatory for:
- New AI sessions on existing projects
- After significant time gaps (>24 hours)
- When switching between major project areas
- After major changes or pivots
- When onboarding new team members
The goal is to establish complete context BEFORE any work begins.]]
## 1. MEMORY BANK REVIEW
[[LLM: Memory Bank is the primary source of project truth. Review systematically, noting dates and potential staleness.]]
### 1.1 Core Memory Bank Files
- [ ] **projectbrief.md** reviewed - Project foundation, goals, and scope understood
- [ ] **activeContext.md** reviewed - Current priorities and immediate work identified
- [ ] **progress.md** reviewed - Project state and completed features understood
- [ ] **systemPatterns.md** reviewed - Architecture patterns and decisions noted
- [ ] **techContext.md** reviewed - Technology stack and constraints clear
- [ ] **productContext.md** reviewed - Problem space and user needs understood
- [ ] Last update timestamps noted for each file
- [ ] Potential inconsistencies between files identified
### 1.2 Memory Bank Health Assessment
- [ ] Files exist and are accessible
- [ ] Information appears current (updated within last sprint)
- [ ] No major gaps in documentation identified
- [ ] Cross-references between files are consistent
- [ ] Action items for updates noted if needed
### 1.3 Project Structure Verification
[[LLM: Reference project-scaffolding-preference.md for standard project structure. Verify actual structure aligns with BMAD conventions.]]
- [ ] Project follows standard directory structure
- [ ] BMAD-specific directories exist (docs/memory-bank, docs/adr, docs/devJournal)
- [ ] Documentation directories properly organized
- [ ] Source code organization follows conventions
- [ ] Test structure aligns with project type
## 2. ARCHITECTURE DOCUMENTATION
[[LLM: Architecture drives implementation. Understand the system design thoroughly.]]
### 2.1 Architecture Documents
- [ ] Primary architecture document located and reviewed
- [ ] Document type identified (greenfield, brownfield, frontend, fullstack)
- [ ] Core architectural decisions understood
- [ ] System components and relationships clear
- [ ] Technology choices and versions noted
- [ ] API documentation reviewed if exists
- [ ] Database schemas understood if applicable
### 2.2 Architecture Alignment
- [ ] Architecture aligns with Memory Bank information
- [ ] Recent changes or updates identified
- [ ] ADRs reviewed for architectural decisions
- [ ] Integration points clearly understood
- [ ] Deployment architecture reviewed
## 3. DEVELOPMENT HISTORY
[[LLM: Recent history provides context for current work and challenges.]]
### 3.1 Dev Journal Review
- [ ] Located Dev Journal entries (last 3-5)
- [ ] Recent work and decisions understood
- [ ] Challenges and blockers identified
- [ ] Technical debt or issues noted
- [ ] Patterns in development identified
- [ ] Key learnings extracted
### 3.2 ADR Review
- [ ] Recent ADRs reviewed (last 3-5)
- [ ] Current architectural decisions understood
- [ ] Superseded decisions noted
- [ ] Pending decisions identified
- [ ] ADR alignment with architecture verified
## 4. CURRENT PROJECT STATE
[[LLM: Understanding the current state prevents duplicate work and conflicts.]]
### 4.1 Git Status Check
- [ ] Current branch identified
- [ ] Clean working directory confirmed
- [ ] Recent commits reviewed (last 10)
- [ ] Outstanding changes understood
- [ ] Merge conflicts checked
- [ ] Remote synchronization status
### 4.2 Project Health
- [ ] Build status checked
- [ ] Test suite status verified
- [ ] Known failing tests documented
- [ ] Blocking issues identified
- [ ] Dependencies up to date
- [ ] Security vulnerabilities checked
## 5. SPRINT/ITERATION CONTEXT
[[LLM: Align work with current sprint goals and priorities.]]
### 5.1 Sprint Status
- [ ] Current sprint identified
- [ ] Sprint goals understood
- [ ] User stories in progress identified
- [ ] Completed stories this sprint noted
- [ ] Sprint timeline clear
- [ ] Team velocity understood
### 5.2 Priority Alignment
- [ ] Immediate priorities identified
- [ ] Blockers and dependencies clear
- [ ] Next planned work understood
- [ ] Risk areas identified
- [ ] Resource constraints noted
## 6. CONSISTENCY VALIDATION
[[LLM: Inconsistencies cause confusion and errors. Identify and flag them.]]
### 6.1 Cross-Reference Check
- [ ] Memory Bank aligns with codebase reality
- [ ] Architecture matches implementation
- [ ] ADRs reflected in current code
- [ ] Dev Journal matches git history
- [ ] Documentation current with changes
### 6.2 Gap Identification
- [ ] Missing documentation identified
- [ ] Outdated sections flagged
- [ ] Undocumented decisions noted
- [ ] Knowledge gaps listed
- [ ] Update requirements documented
## 7. AGENT-SPECIFIC CONTEXT
[[LLM: Different agents need different context emphasis.]]
### 7.1 Role-Based Focus
**For Architect:**
- [ ] Architectural decisions and rationale clear
- [ ] Technical debt understood
- [ ] Scalability considerations reviewed
- [ ] System boundaries defined
**For Developer:**
- [ ] Current implementation tasks clear
- [ ] Coding patterns understood
- [ ] Testing requirements known
- [ ] Local setup verified
**For PM/PO:**
- [ ] Requirements alignment verified
- [ ] User stories prioritized
- [ ] Stakeholder needs understood
- [ ] Timeline constraints clear
**For QA:**
- [ ] Test coverage understood
- [ ] Quality gates defined
- [ ] Known issues documented
- [ ] Testing strategy clear
### 7.2 Handoff Context
- [ ] Previous agent's work understood
- [ ] Pending decisions identified
- [ ] Open questions documented
- [ ] Next steps clear
## 8. RECOMMENDED ACTIONS
[[LLM: Based on the review, what should happen next?]]
### 8.1 Immediate Actions
- [ ] Most urgent task identified
- [ ] Blockers that need resolution listed
- [ ] Quick wins available noted
- [ ] Risk mitigation needed specified
### 8.2 Documentation Updates
- [ ] Memory Bank updates needed listed
- [ ] Architecture updates required noted
- [ ] ADRs to be created identified
- [ ] Dev Journal entries planned
### 8.3 Strategic Considerations
- [ ] Technical debt to address
- [ ] Architectural improvements needed
- [ ] Process improvements suggested
- [ ] Knowledge gaps to fill
## SESSION KICKOFF SUMMARY
[[LLM: Generate a concise summary report with:
1. **Project Context**
- Project name and purpose
- Current phase/sprint
- Key technologies
2. **Documentation Health**
- Memory Bank status (Current/Outdated/Missing)
- Architecture status
- Overall documentation quality
3. **Current State**
- Active work items
- Recent completions
- Immediate blockers
4. **Inconsistencies Found**
- List any misalignments
- Documentation gaps
- Update requirements
5. **Recommended Next Steps**
- Priority order
- Estimated effort
- Dependencies
Keep it action-oriented and concise.]]
### Summary Report
**Status:** [Complete/Partial/Blocked]
**Key Findings:**
- Documentation Health: [Good/Fair/Poor]
- Project State: [On Track/At Risk/Blocked]
- Context Quality: [Complete/Adequate/Insufficient]
**Priority Actions:**
1. [Most urgent action]
2. [Second priority]
3. [Third priority]
**Blockers:**
- [List any blocking issues]
**Agent Ready:** [Yes/No - with reason if No]

363
bmad-core/checklists/sprint-review-checklist.md Normal file
View File

@ -0,0 +1,363 @@
# Sprint Review Checklist
This checklist guides teams through conducting effective sprint reviews that capture achievements, learnings, and set up the next sprint for success.
[[LLM: INITIALIZATION INSTRUCTIONS - SPRINT REVIEW
Sprint Reviews are critical ceremonies for:
- Demonstrating completed work to stakeholders
- Capturing lessons learned
- Adjusting project direction based on feedback
- Planning upcoming work
- Updating project documentation
This checklist should be used:
- At the end of each sprint/iteration
- Before major milestone reviews
- When significant changes occur
- For handoffs between teams
The goal is to create a comprehensive record of progress and decisions.]]
## 1. PRE-REVIEW PREPARATION
[[LLM: Good preparation ensures productive reviews. Complete these items 1-2 days before the review.]]
### 1.1 Sprint Metrics Collection
- [ ] Sprint goals documented and assessed
- [ ] User stories completed vs planned tallied
- [ ] Story points delivered calculated
- [ ] Velocity compared to previous sprints
- [ ] Burndown/burnup charts prepared
- [ ] Blockers and impediments listed
### 1.2 Demo Preparation
- [ ] Completed features identified for demo
- [ ] Demo environment prepared and tested
- [ ] Demo scripts/scenarios written
- [ ] Demo order determined (highest value first)
- [ ] Presenters assigned for each feature
- [ ] Backup plans for demo failures prepared
### 1.3 Documentation Review
- [ ] Dev Journal entries for sprint compiled
- [ ] ADRs created during sprint listed
- [ ] Memory Bank updates identified
- [ ] Architecture changes documented
- [ ] Technical debt items logged
## 2. STAKEHOLDER COORDINATION
[[LLM: Effective reviews require the right people with the right information.]]
### 2.1 Attendee Management
- [ ] Required stakeholders identified and invited
- [ ] Product Owner availability confirmed
- [ ] Technical team members scheduled
- [ ] Optional attendees invited
- [ ] Meeting logistics communicated
- [ ] Pre-read materials distributed
### 2.2 Agenda Creation
- [ ] Review objectives defined
- [ ] Time allocated per demo/topic
- [ ] Q&A time built in
- [ ] Feedback collection method determined
- [ ] Next steps discussion included
- [ ] Time for retrospective insights
## 3. SPRINT ACCOMPLISHMENTS
[[LLM: Focus on value delivered and outcomes achieved, not just features built.]]
### 3.1 Completed Work
- [ ] All completed user stories listed
- [ ] Business value of each story articulated
- [ ] Technical achievements highlighted
- [ ] Infrastructure improvements noted
- [ ] Bug fixes and issues resolved documented
- [ ] Performance improvements quantified
### 3.2 Partial/Incomplete Work
- [ ] In-progress stories status documented
- [ ] Reasons for incompletion analyzed
- [ ] Carry-over plan determined
- [ ] Re-estimation completed if needed
- [ ] Dependencies identified
- [ ] Risk mitigation planned
### 3.3 Unplanned Work
- [ ] Emergency fixes documented
- [ ] Scope changes captured
- [ ] Technical discoveries noted
- [ ] Time impact assessed
- [ ] Process improvements identified
- [ ] Prevention strategies discussed
## 4. TECHNICAL DECISIONS & LEARNINGS
[[LLM: Capture the "why" behind decisions for future reference.]]
### 4.1 Architectural Decisions
- [ ] Key technical decisions documented
- [ ] ADRs created or referenced
- [ ] Trade-offs explained
- [ ] Alternative approaches noted
- [ ] Impact on future work assessed
- [ ] Technical debt created/resolved
### 4.2 Process Learnings
- [ ] What worked well identified
- [ ] What didn't work documented
- [ ] Process improvements suggested
- [ ] Tool effectiveness evaluated
- [ ] Communication gaps noted
- [ ] Team dynamics assessed
### 4.3 Technical Learnings
- [ ] New technologies evaluated
- [ ] Performance insights gained
- [ ] Security findings documented
- [ ] Integration challenges noted
- [ ] Best practices identified
- [ ] Anti-patterns discovered
## 5. STAKEHOLDER FEEDBACK
[[LLM: Stakeholder input shapes future direction. Capture it systematically.]]
### 5.1 Feature Feedback
- [ ] User reactions to demos captured
- [ ] Feature requests documented
- [ ] Priority changes noted
- [ ] Usability concerns raised
- [ ] Performance feedback received
- [ ] Gap analysis completed
### 5.2 Strategic Feedback
- [ ] Alignment with business goals verified
- [ ] Market changes discussed
- [ ] Competitive insights shared
- [ ] Resource concerns raised
- [ ] Timeline adjustments proposed
- [ ] Success metrics validated
## 6. NEXT SPRINT PLANNING
[[LLM: Use review insights to plan effectively for the next sprint.]]
### 6.1 Backlog Refinement
- [ ] Backlog prioritization updated
- [ ] New stories created from feedback
- [ ] Technical debt items prioritized
- [ ] Dependencies identified
- [ ] Estimation needs noted
- [ ] Spike stories defined
### 6.2 Sprint Goal Setting
- [ ] Next sprint theme determined
- [ ] Specific goals articulated
- [ ] Success criteria defined
- [ ] Risks identified
- [ ] Capacity confirmed
- [ ] Commitment level agreed
### 6.3 Process Adjustments
- [ ] Retrospective actions incorporated
- [ ] Process improvements planned
- [ ] Tool changes identified
- [ ] Communication plans updated
- [ ] Meeting cadence adjusted
- [ ] Team agreements updated
## 7. DOCUMENTATION UPDATES
[[LLM: Keep project documentation current with sprint outcomes.]]
### 7.1 Memory Bank Updates
- [ ] progress.md updated with completions
- [ ] activeContext.md refreshed for next sprint
- [ ] systemPatterns.md updated with new patterns
- [ ] techContext.md updated if stack changed
- [ ] productContext.md adjusted based on feedback
- [ ] All updates committed and pushed
### 7.2 Project Documentation
- [ ] README updated if needed
- [ ] CHANGELOG updated with sprint changes
- [ ] Architecture docs updated
- [ ] API documentation current
- [ ] Deployment guides updated
- [ ] User documentation refreshed
### 7.3 Knowledge Sharing
- [ ] Dev Journal entries completed
- [ ] Key decisions documented in ADRs
- [ ] Lessons learned captured
- [ ] Best practices documented
- [ ] Team wiki updated
- [ ] Knowledge gaps identified
## 8. METRICS & REPORTING
[[LLM: Data-driven insights improve future performance.]]
### 8.1 Sprint Metrics
- [ ] Velocity calculated and tracked
- [ ] Cycle time measured
- [ ] Defect rates analyzed
- [ ] Test coverage reported
- [ ] Performance metrics captured
- [ ] Technical debt quantified
### 8.2 Quality Metrics
- [ ] Code review effectiveness assessed
- [ ] Test automation coverage measured
- [ ] Security scan results reviewed
- [ ] Performance benchmarks compared
- [ ] User satisfaction gathered
- [ ] Stability metrics tracked
### 8.3 Trend Analysis
- [ ] Velocity trends analyzed
- [ ] Quality trends identified
- [ ] Estimation accuracy reviewed
- [ ] Bottlenecks identified
- [ ] Improvement areas prioritized
- [ ] Predictions for next sprint
## 9. ACTION ITEMS
[[LLM: Reviews without follow-through waste time. Ensure actions are specific and assigned.]]
### 9.1 Immediate Actions
- [ ] Critical fixes identified and assigned
- [ ] Blocker resolution planned
- [ ] Documentation updates assigned
- [ ] Communication tasks defined
- [ ] Tool/access issues addressed
- [ ] Quick wins identified
### 9.2 Short-term Actions (Next Sprint)
- [ ] Process improvements scheduled
- [ ] Technical debt items planned
- [ ] Training needs addressed
- [ ] Tool implementations planned
- [ ] Architecture updates scheduled
- [ ] Team changes coordinated
### 9.3 Long-term Actions
- [ ] Strategic changes documented
- [ ] Major refactoring planned
- [ ] Platform migrations scheduled
- [ ] Team scaling addressed
- [ ] Skill development planned
- [ ] Innovation initiatives defined
## SPRINT REVIEW SUMMARY
[[LLM: Generate a comprehensive but concise summary for stakeholders and team records.
Include:
1. **Sprint Overview**
- Sprint number/name
- Duration
- Team composition
- Overall outcome (successful/challenged/failed)
2. **Achievements**
- Stories completed vs planned
- Value delivered
- Technical accomplishments
- Quality improvements
3. **Challenges**
- Major blockers faced
- Incomplete work
- Technical difficulties
- Process issues
4. **Key Decisions**
- Technical choices made
- Priority changes
- Process adjustments
- Resource changes
5. **Stakeholder Feedback**
- Satisfaction level
- Major concerns
- Feature requests
- Priority shifts
6. **Next Sprint Focus**
- Primary goals
- Key risks
- Dependencies
- Success metrics
7. **Action Items**
- Owner, action, due date
- Priority level
- Dependencies
Keep it scannable and action-oriented.]]
### Review Summary Template
**Sprint:** [Number/Name]
**Date:** [Review Date]
**Duration:** [Sprint Length]
**Attendees:** [List Key Attendees]
**Overall Assessment:** [Green/Yellow/Red]
**Completed:**
- X of Y stories (Z story points)
- Key features: [List]
- Technical achievements: [List]
**Incomplete:**
- X stories carried over
- Reasons: [Brief explanation]
**Key Feedback:**
**Next Sprint Focus:**
1. [Primary goal]
2. [Secondary goal]
3. [Technical focus]
**Critical Actions:**
| Action | Owner | Due Date |
|----------|--------|----------|
| [Action] | [Name] | [Date] |
**Review Completed By:** [Name]
**Documentation Updated:** [Yes/No]

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

@ -59,11 +59,15 @@ The goal is quality delivery, not just checking boxes.]]
5. **Story Administration:**
[[LLM: Documentation helps the next developer. What should they know?]]
[[LLM: Documentation helps the next developer. What should they know? Update Memory Bank and Dev Journal]]
- [ ] 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.
- [ ] Dev Journal entry created documenting implementation decisions and challenges
- [ ] Memory Bank updated with new patterns, decisions, or technical context
- [ ] ADR created if significant architectural decisions were made
- [ ] Comprehensive commit workflow followed with descriptive commit messages
6. **Dependencies, Build & Configuration:**

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

@ -38,13 +38,17 @@ We're checking for SUFFICIENT guidance, not exhaustive detail.]]
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]]
5. Success looks like something specific, not vague
6. Memory Bank context has been considered
7. Technical principles alignment is clear]]
- [ ] Story goal/purpose is clearly stated
- [ ] Relationship to epic goals is evident
- [ ] How the story fits into overall system flow is explained
- [ ] Dependencies on previous stories are identified (if applicable)
- [ ] Business context and value are clear
- [ ] Memory Bank context referenced where relevant
- [ ] Technical principles and preferences considered
## 2. TECHNICAL IMPLEMENTATION GUIDANCE
@ -79,6 +83,8 @@ Note: We don't need every file listed - just the important ones.]]
- [ ] Critical information from previous stories is summarized (not just referenced)
- [ ] Context is provided for why references are relevant
- [ ] References use consistent format (e.g., `docs/filename.md#section`)
- [ ] ADR references included where architectural decisions apply
- [ ] Memory Bank files referenced appropriately (activeContext, systemPatterns, etc.)
## 4. SELF-CONTAINMENT ASSESSMENT
@ -142,7 +148,7 @@ Generate a concise validation report:
Be pragmatic - perfect documentation doesn't exist, but it must be enough to provide the extreme context a dev agent needs to get the work down and not create a mess.]]
| Category | Status | Issues |
| ------------------------------------ | ------ | ------ |
|--------------------------------------|--------|--------|
| 1. Goal & Context Clarity | _TBD_ | |
| 2. Technical Implementation Guidance | _TBD_ | |
| 3. Reference Effectiveness | _TBD_ | |

29
bmad-core/core-config.yaml
View File

@ -18,3 +18,32 @@ devLoadAlwaysFiles:
devDebugLog: .ai/debug-log.md
devStoryLocation: docs/stories
slashPrefix: BMad
# Memory Bank configuration
memoryBank:
location: docs/memory-bank
autoLoadOnSessionStart: true
files:
- projectbrief.md
- productContext.md
- systemPatterns.md
- techContext.md
- activeContext.md
- progress.md
# Development Journal configuration
devJournal:
location: docs/devJournal
namePattern: YYYYMMDD-NN.md
autoCreateAfterSession: true
includeInMemoryBank: true
# Architectural Decision Records configuration
adr:
location: docs/adr
namePattern: adr-NNNN.md
templateFile: templates/adr-tmpl.md
autoLinkToMemoryBank: true
# Sprint Management configuration
sprint:
reviewChecklistPath: checklists/sprint-review-checklist.md
sessionKickoffChecklistPath: checklists/session-kickoff-checklist.md
enableSprintPlanning: true
sprintPlanningTemplate: templates/sprint-planning-tmpl.yaml

6
bmad-core/data/adr-triggers.md
View File

@ -65,7 +65,7 @@
- **Feature Flags**: Implementation approach
- **Backward Compatibility**: Version strategy
## Red Flags - Always Create an ADR When:
## Red Flags - Always Create an ADR When
1. **Multiple Valid Options Exist**: The team is debating between approaches
2. **Significant Cost Implications**: The decision impacts budget substantially
@ -76,7 +76,7 @@
7. **Performance Critical**: Decision significantly impacts system performance
8. **Security Implications**: Decision affects system security posture
## When NOT to Create an ADR:
## When NOT to Create an ADR
1. **Implementation Details**: How to name a variable or structure a small module
2. **Temporary Solutions**: Quick fixes that will be replaced soon
@ -84,5 +84,5 @@
4. **Tool Configuration**: Minor tool settings that are easily changeable
5. **Obvious Choices**: When there's only one reasonable option
## Remember:
## Remember
> "If someone might ask 'Why did we do it this way?' in 6 months, you need an ADR."

113
bmad-core/data/bmad-kb.md
View File

@ -273,7 +273,7 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
### Core Development Team
| Agent | Role | Primary Functions | When to Use |
| ----------- | ------------------ | --------------------------------------- | -------------------------------------- |
|-------------|--------------------|-----------------------------------------|----------------------------------------|
| `analyst` | Business Analyst | Market research, requirements gathering | Project planning, competitive analysis |
| `pm` | Product Manager | PRD creation, feature prioritization | Strategic planning, roadmaps |
| `architect` | Solution Architect | System design, technical architecture | Complex systems, scalability planning |
@ -286,7 +286,7 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
### Meta Agents
| Agent | Role | Primary Functions | When to Use |
| ------------------- | ---------------- | ------------------------------------- | --------------------------------- |
|---------------------|------------------|---------------------------------------|-----------------------------------|
| `bmad-orchestrator` | Team Coordinator | Multi-agent workflows, role switching | Complex multi-role tasks |
| `bmad-master` | Universal Expert | All capabilities without switching | Single-session comprehensive work |
@ -349,6 +349,104 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
- **Use Case**: Backend services, APIs, system development
- **Bundle**: `team-no-ui.txt`
## Recent Enhancements (Quad Damage)
### Memory Bank Pattern
The Memory Bank provides persistent context across AI sessions, ensuring continuity when AI memory resets:
**Core Files** (in `docs/memory-bank/`):
- `projectbrief.md` - Project foundation and goals
- `productContext.md` - Problem space and user needs
- `systemPatterns.md` - Architecture and technical decisions
- `techContext.md` - Technology stack and constraints
- `activeContext.md` - Current work and priorities
- `progress.md` - Features completed and status
**Key Features**:
- Session initialization with `session-kickoff` task
- Automatic updates through `update-memory-bank` task
- Integration with dev journals and ADRs
- All agents have Memory Bank awareness
### Architectural Decision Records (ADRs)
Formal documentation of significant architectural decisions:
**Features**:
- Michael Nygard format in `docs/adr/`
- Numbered sequence (0001, 0002, etc.)
- Comprehensive template with alternatives analysis
- Integration with architect agent
- Triggers documented for when to create ADRs
### Development Journals
Session documentation for knowledge sharing:
**Features**:
- Daily entries in `docs/devJournal/`
- Comprehensive session narratives
- Work stream tracking
- Technical decision documentation
- Anti-tunnel vision mechanisms
### Enhanced Commit and PR Workflows
Professional git workflows with comprehensive context:
**Features**:
- Multi-stream commit synthesis
- Conventional Commits 1.0 standard
- Anti-tunnel vision checks
- Comprehensive PR descriptions
- Cross-reference integration
### Technical Principles Integration
Three sets of architectural and coding principles:
**1. Coding Standards** (`data/coding-standards.md`):
- Core principles with tags ([SF], [DRY], etc.)
- Security best practices
- Testing standards
- Commit conventions
**2. Twelve-Factor Principles** (`data/twelve-factor-principles.md`):
- Cloud-native application design
- Environment parity
- Stateless processes
- Configuration management
**3. Microservice Patterns** (`data/microservice-patterns.md`):
- Service decomposition strategies
- Communication patterns
- Data management approaches
- Testing and deployment patterns
### Session Kickoff Protocol
Universal initialization for all agents:
**Process**:
1. Memory Bank review
2. Architecture documentation scan
3. Dev journal history check
4. ADR review
5. Current state assessment
6. Consistency validation
7. Next steps recommendation
**Usage**: Run `*session-kickoff` at start of any agent session
### Integration Points
All enhancements work together:
- Memory Bank ← Dev Journals ← ADRs ← Code Changes
- Session Kickoff → Memory Bank → Agent Context
- Technical Principles → Architecture Decisions → ADRs
- Commit/PR Workflows → Dev Journals → Memory Bank
## Core Architecture
### System Overview
@ -381,7 +479,7 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor
- **Templates** (`bmad-core/templates/`): Markdown templates for PRDs, architecture specs, user stories
- **Tasks** (`bmad-core/tasks/`): Instructions for specific repeatable actions like "shard-doc" or "create-next-story"
- **Checklists** (`bmad-core/checklists/`): Quality assurance checklists for validation and review
- **Data** (`bmad-core/data/`): Core knowledge base and technical preferences
- **Data** (`bmad-core/data/`): Core knowledge base, technical preferences, and project scaffolding guidelines
### Dual Environment Architecture
@ -409,13 +507,20 @@ BMad employs a sophisticated template system with three key components:
### Technical Preferences Integration
The `technical-preferences.md` file serves as a persistent technical profile that:
The framework includes two key preference files:
**`technical-preferences.md`** - Technology choices and patterns:
- Ensures consistency across all agents and projects
- Eliminates repetitive technology specification
- Provides personalized recommendations aligned with user preferences
- Evolves over time with lessons learned
**`project-scaffolding-preference.md`** - Project structure and organization:
- Defines standard directory structure for all projects
- Provides technology-agnostic scaffolding guidelines
- Ensures consistency in documentation organization
- Supports BMAD-specific structures (Memory Bank, ADRs, Dev Journals)
### Build and Delivery Process
The `web-builder.js` tool creates web-ready bundles by:

88
bmad-core/data/coding-standards.md Normal file
View File

@ -0,0 +1,88 @@
# Coding Standards and Principles
> **Purpose:** This document defines the core coding standards and principles that apply to all development work in BMAD projects. These are fundamental rules of software craftsmanship that ensure consistency, quality, and maintainability.
## Core Coding Principles
### Simplicity and Readability
- **[SF] Simplicity First:** Always choose the simplest viable solution. Complex patterns require explicit justification.
- **[RP] Readability Priority:** Code must be immediately understandable by both humans and AI.
- **[CA] Clean Architecture:** Generate cleanly formatted, logically structured code with consistent patterns.
### Dependency Management
- **[DM] Dependency Minimalism:** No new libraries without explicit request or compelling justification.
- **[DM-1] Security Reviews:** Review third-party dependencies for vulnerabilities quarterly.
- **[DM-2] Package Verification:** Prefer signed or verified packages.
- **[DM-3] Cleanup:** Remove unused or outdated dependencies promptly.
- **[DM-4] Documentation:** Document dependency updates in changelog.
### Development Workflow
- **[WF-FOCUS] Task Focus:** Focus on areas of code relevant to the task.
- **[WF-SCOPE] Scope Control:** Do not touch code unrelated to the task.
- **[WF-TEST] Testing:** Write thorough tests for all major functionality.
- **[WF-ARCH] Architecture Stability:** Avoid major changes to working patterns unless explicitly requested.
- **[WF-IMPACT] Impact Analysis:** Consider effects on other methods and code areas.
### Code Quality Standards
- **[DRY] DRY Principle:** No duplicate code. Reuse or extend existing functionality.
- **[REH] Error Handling:** Robust error handling for all edge cases and external interactions.
- **[CSD] Code Smell Detection:** Proactively identify and refactor:
- Functions exceeding 30 lines
- Files exceeding 300 lines
- Nested conditionals beyond 2 levels
- Classes with more than 5 public methods
### Security Principles
- **[IV] Input Validation:** All external data must be validated before processing.
- **[SFT] Security-First:** Implement proper authentication, authorization, and data protection.
- **[RL] Rate Limiting:** Rate limit all API endpoints.
- **[RLS] Row-Level Security:** Use row-level security always.
- **[CAP] Captcha Protection:** Captcha on all auth routes/signup pages.
- **[WAF] WAF Protection:** Enable attack challenge on hosting WAF when available.
- **[SEC-1] Sensitive Files:** DO NOT read or modify without prior approval:
- .env files
- */config/secrets.*
- Any file containing API keys or credentials
### Performance and Resources
- **[PA] Performance Awareness:** Consider computational complexity and resource usage.
- **[RM] Resource Management:** Close connections and free resources appropriately.
- **[CMV] Constants Over Magic Values:** No magic strings or numbers. Use named constants.
### Commit Standards
- **[AC] Atomic Changes:** Make small, self-contained modifications.
- **[CD] Commit Discipline:** Use conventional commit format:
```
type(scope): concise description
[optional body with details]
[optional footer with breaking changes/issue references]
```
Types: feat, fix, docs, style, refactor, perf, test, chore
### Testing Standards
- **[TDT] Test-Driven Thinking:** Design all code to be easily testable from inception.
- **[ISA] Industry Standards:** Follow established conventions for the language and tech stack.
## Application to AI Development
### Communication Guidelines
- **[RAT] Rule Application Tracking:** Tag rule applications with abbreviations (e.g., [SF], [DRY]).
- **[EDC] Explanation Depth Control:** Scale explanation detail based on complexity.
- **[AS] Alternative Suggestions:** Offer alternative approaches with pros/cons when relevant.
- **[KBT] Knowledge Boundary Transparency:** Clearly communicate capability limits.
### Context Management
- **[TR] Transparent Reasoning:** Explicitly reference which rules influenced decisions.
- **[CWM] Context Window Management:** Be mindful of AI context limitations.
- **[SD] Strategic Documentation:** Comment only complex logic or critical functions.
## Integration with BMAD Workflows
These coding standards should be:
1. Referenced during architecture design decisions
2. Applied during story implementation
3. Validated during code reviews
4. Enforced through automated tooling where possible
5. Updated based on team learnings and retrospectives

50
bmad-core/data/elicitation-methods.md
View File

@ -1,5 +1,20 @@
# Elicitation Methods Data
## Context-Aware Elicitation
**Memory Bank Integration**
- Begin elicitation with Memory Bank context review
- Reference `activeContext.md` for current state understanding
- Check `systemPatterns.md` for established conventions
- Validate against `progress.md` for completed work
- Ensure consistency with historical decisions in ADRs
**Session Kickoff Prerequisite**
- Ensure `*session-kickoff` completed before deep elicitation
- Load relevant Dev Journal entries for recent context
- Review technical principles and coding standards
- Establish shared understanding of project state
## Core Reflective Methods
**Expand or Contract for Audience**
@ -24,12 +39,20 @@
- Check internal consistency and coherence
- Identify and validate dependencies between elements
- Confirm effective ordering and sequencing
- Cross-reference with Memory Bank patterns for consistency
**Assess Alignment with Overall Goals**
- Evaluate content contribution to stated objectives
- Identify any misalignments or gaps
- Interpret alignment from specific role's perspective
- Suggest adjustments to better serve goals
- Validate against `projectbrief.md` for mission alignment
**Memory Bank Pattern Validation**
- Compare proposed approaches with documented patterns
- Identify deviations from established conventions
- Assess if new patterns should be documented
- Update `systemPatterns.md` with validated approaches
## Risk and Challenge Methods
@ -126,9 +149,36 @@
- Identify minimum viable approach
- Discover innovative workarounds and optimizations
## Memory Bank Elicitation Methods
**Historical Context Mining**
- Extract insights from Dev Journal entries
- Identify recurring patterns across sessions
- Discover implicit knowledge in past decisions
- Build on previous architectural choices
**Progressive Context Building**
- Start with `projectbrief.md` for foundation
- Layer in `techContext.md` for technical constraints
- Add `systemPatterns.md` for design conventions
- Integrate `activeContext.md` for current state
**ADR-Driven Discovery**
- Review ADRs for decision rationale
- Identify constraints from past choices
- Understand trade-offs already considered
- Build on established architectural principles
**Sprint Context Elicitation**
- Review sprint goals from planning documents
- Check progress against sprint commitments
- Identify blockers from Dev Journals
- Align new work with sprint objectives
## Process Control
**Proceed / No Further Actions**
- Acknowledge choice to finalize current work
- Accept output as-is or move to next step
- Prepare to continue without additional elicitation
- Update Memory Bank with elicitation outcomes

125
bmad-core/data/microservice-patterns.md Normal file
View File

@ -0,0 +1,125 @@
# Microservice Architecture Patterns
> **Purpose:** This document outlines specific patterns and strategies for implementing Microservice-Oriented Architecture, based on Chris Richardson's "Microservices Patterns". It provides detailed guidance for service design, decomposition, communication, and data management.
## Core Architecture Patterns
### Foundation Patterns
- **[MON] Monolithic Architecture:** Single deployable unit. Good for simple applications, becomes "monolithic hell" as complexity grows.
- **[MSA] Microservice Architecture:** Collection of small, autonomous, loosely coupled services. Core pattern for complex systems.
### Service Decomposition
- **[DBC] Decompose by Business Capability:** Define services based on business capabilities (e.g., Order Management, Inventory).
- **[DSD] Decompose by Subdomain:** Use Domain-Driven Design to define services around problem subdomains.
## Communication Patterns
### Synchronous Communication
- **[RPI] Remote Procedure Invocation:** Synchronous request/response (REST, gRPC). Simple but creates coupling.
- **[CBR] Circuit Breaker:** Prevent cascading failures. Trip after consecutive failures, fail fast.
### Asynchronous Communication
- **[MSG] Messaging:** Services communicate via message broker. Promotes loose coupling and resilience.
- **[DME] Domain Events:** Aggregates publish events when state changes. Foundation for event-driven architecture.
### Service Discovery
- **[SDC] Service Discovery:** Patterns for finding service instances in dynamic cloud environments:
- Client-side discovery
- Server-side discovery
- Service registry patterns
## Data Management Patterns
### Data Architecture
- **[DPS] Database per Service:** Each service owns its data. Fundamental to loose coupling.
- **[AGG] Aggregate:** Cluster of domain objects as single unit. Transactions only create/update single aggregate.
### Data Consistency
- **[SAG] Saga:** Manage data consistency across services without distributed transactions:
- Sequence of local transactions
- Event/message triggered
- Compensating transactions on failure
### Event Patterns
- **[EVS] Event Sourcing:** Store state-changing events rather than current state. Provides audit log.
- **[OUT] Transactional Outbox:** Reliably publish messages as part of local database transaction.
### Query Patterns
- **[APC] API Composition:** Client retrieves and joins data from multiple services. Simple but inefficient for complex queries.
- **[CQR] CQRS:** Separate command (write) and query (read) models. Maintain denormalized read views.
## API Patterns
### Gateway Patterns
- **[APG] API Gateway:** Single entry point for all clients. Routes requests, handles cross-cutting concerns.
- **[BFF] Backends for Frontends:** Separate API gateway for each client type (mobile, web).
## Domain Modeling
### Design Approaches
- **[DOM] Domain Model:** Object-oriented with state and behavior. Preferred for complex logic.
- **[TSF] Transaction Script:** Procedural approach. Simpler but unmanageable for complex logic.
## Testing Patterns
### Service Testing
- **[CDC] Consumer-Driven Contract Test:** Consumer writes tests to verify provider meets expectations.
- **[SCT] Service Component Test:** Acceptance test for single service with stubbed dependencies.
## Deployment Patterns
### Container Patterns
- **[SVC] Service as Container:** Package service as container image to encapsulate technology stack.
- **[SRL] Serverless Deployment:** Deploy using serverless platform (e.g., AWS Lambda).
### Infrastructure Patterns
- **[MSC] Microservice Chassis:** Framework handling cross-cutting concerns (config, health, metrics).
- **[SMH] Service Mesh:** Infrastructure layer for inter-service communication (Istio, Linkerd).
## Migration Patterns
### Legacy Modernization
- **[STR] Strangler Application:** Incrementally build microservices around monolith. Gradual replacement.
## Best Practices
### Service Design
1. Services should be loosely coupled and highly cohesive
2. Own their data and business logic
3. Communicate through well-defined interfaces
4. Be independently deployable
### Transaction Management
1. Avoid distributed transactions
2. Use saga pattern for cross-service consistency
3. Design for eventual consistency
4. Implement idempotency
### Resilience
1. Implement circuit breakers
2. Use timeouts and retries wisely
3. Design for failure
4. Implement health checks
### Observability
1. Distributed tracing across services
2. Centralized logging
3. Service-level metrics
4. Business metrics
## Anti-Patterns to Avoid
1. **Distributed Monolith:** Microservices that must be deployed together
2. **Chatty Services:** Excessive inter-service communication
3. **Shared Database:** Multiple services accessing same database
4. **Synchronous Communication Everywhere:** Over-reliance on RPI
5. **Missing Service Boundaries:** Services that don't align with business capabilities
## Integration with BMAD
These patterns should be:
1. Considered during architecture design phase
2. Documented in Architecture Decision Records (ADRs)
3. Applied based on specific project requirements
4. Validated against twelve-factor principles
5. Reviewed for applicability to project scale and complexity

264
bmad-core/data/project-scaffolding-preference.md Normal file
View File

@ -0,0 +1,264 @@
# Project Scaffolding Preferences
This document defines generic, technology-agnostic project scaffolding preferences that can be applied to any software project. These preferences promote consistency, maintainability, and best practices across different technology stacks.
## Documentation Structure
### Core Documentation
- **README**: Primary project documentation with setup instructions, architecture overview, and contribution guidelines
- **CHANGELOG**: Maintain detailed changelog following semantic versioning principles
- **LICENSE**: Clear licensing information for the project
- **Contributing Guidelines**: How to contribute, code standards, and review process
### BMAD Documentation Structure
- **Product Requirements Document (PRD)**:
- Single source file: `docs/prd.md`
- Can be sharded into `docs/prd/` directory by level 2 sections
- Contains epics, stories, requirements
- **Architecture Documentation**:
- Single source file: `docs/architecture.md` or `docs/brownfield-architecture.md`
- Can be sharded into `docs/architecture/` directory
- For brownfield: Document actual state including technical debt
- **Memory Bank** (AI Context Persistence):
- Location: `docs/memory-bank/`
- Core files: projectbrief.md, productContext.md, systemPatterns.md, techContext.md, activeContext.md, progress.md
- Provides persistent context across AI sessions
### Architectural Documentation
- **Architecture Decision Records (ADRs)**: Document significant architectural decisions
- Location: `docs/adr/`
- When to create: Major dependency changes, pattern changes, integration approaches, schema modifications
- Follow consistent ADR template (e.g., Michael Nygard format)
- Number sequentially (e.g., adr-0001.md)
- Maintain an index
### Development Documentation
- **Development Journals**: Track daily/session work, decisions, and challenges
- Location: `docs/devJournal/`
- Named with date format: `YYYYMMDD-NN.md`
- Include work completed, decisions made, blockers encountered
- Reference relevant ADRs and feature documentation
- Create after significant work sessions
### Feature Documentation
- **Roadmap**: High-level project direction and planned features
- Location: `docs/roadmap/`
- Feature details in `docs/roadmap/features/`
- **Epics and Stories**:
- Epics extracted from PRD to `docs/epics/`
- Stories created from epics to `docs/stories/`
- Follow naming: `epic-N-story-M.md`
## Source Code Organization
### Separation of Concerns
- **Frontend/UI**: Dedicated location for user interface components
- **Backend/API**: Separate backend logic and API implementations
- **Shared Utilities**: Common functionality used across layers
- **Configuration**: Centralized configuration management
- **Scripts**: Automation and utility scripts
### Testing Structure
- **Unit Tests**: Close to source code or in dedicated test directories
- **Integration Tests**: Test component interactions
- **End-to-End Tests**: Full workflow testing
- **Test Utilities**: Shared test helpers and fixtures
- **Test Documentation**: How to run tests, test strategies
## Project Root Structure
### Essential Files
- Version control ignore files (e.g., .gitignore)
- Editor/IDE configuration files
- Dependency management files
- Build/deployment configuration
- Environment configuration templates (never commit actual secrets)
### Standard Directories
```
/docs
/adr # Architecture Decision Records
/devJournal # Development journals
/memory-bank # Persistent AI context (BMAD-specific)
/prd # Sharded Product Requirements Documents
/architecture # Sharded Architecture Documents
/stories # User stories (from epics)
/epics # Epic documents
/api # API documentation
/roadmap # Project roadmap and features
/src
/[frontend] # UI/frontend code
/[backend] # Backend/API code
/[shared] # Shared utilities
/[config] # Configuration
/tests
/unit # Unit tests
/integration # Integration tests
/e2e # End-to-end tests
/scripts # Build, deployment, utility scripts
/tools # Development tools and utilities
/.bmad # BMAD-specific configuration and overrides
```
## Development Practices
### Code Organization
- Keep files focused and manageable (typically under 300 lines)
- Prefer composition over inheritance
- Avoid code duplication - check for existing implementations
- Use clear, consistent naming conventions throughout
- Document complex logic and non-obvious decisions
### Documentation Discipline
- Update documentation alongside code changes
- Document the "why" not just the "what"
- Keep examples current and working
- Review documentation in code reviews
- Maintain templates for consistency
### Security Considerations
- Never commit secrets or credentials
- Use environment variables for configuration
- Implement proper input validation
- Manage resources appropriately (close connections, free memory)
- Follow principle of least privilege
- Document security considerations
### Quality Standards
- All code must pass linting and formatting checks
- Automated testing at multiple levels
- Code review required before merging
- Continuous integration for all changes
- Regular dependency updates
## Accessibility & Inclusion
### Universal Design
- Consider accessibility from the start
- Follow established accessibility standards (e.g., WCAG)
- Ensure keyboard navigation support
- Provide appropriate text alternatives
- Test with assistive technologies
### Inclusive Practices
- Use clear, inclusive language in documentation
- Consider diverse user needs and contexts
- Document accessibility requirements
- Include accessibility in testing
## Database/Data Management
### Schema Management
- Version control all schema changes
- Use migration tools for consistency
- Document schema decisions in ADRs
- Maintain data dictionary
- Never make manual production changes
### Data Documentation
- Maintain current entity relationship diagrams
- Document data flows and dependencies
- Explain business rules and constraints
- Keep sample data separate from production
## Environment Management
### Environment Parity
- Development, test, and production should be as similar as possible
- Use same deployment process across environments
- Configuration through environment variables
- Document environment-specific settings
- Automate environment setup
### Local Development
- Provide scripted setup process
- Document all prerequisites
- Include reset/cleanup scripts
- Maintain environment templates
- Support multiple development environments
## Branching & Release Strategy
### Version Control
- Define clear branching strategy
- Use semantic versioning
- Tag all releases
- Maintain release notes
- Document hotfix procedures
### Release Process
- Automated build and deployment
- Staged rollout capabilities
- Rollback procedures documented
- Release communication plan
- Post-release verification
## Incident Management
### Incident Response
- Maintain incident log
- Document root cause analyses
- Update runbooks based on incidents
- Conduct retrospectives
- Share learnings across team
### Monitoring & Observability
- Define key metrics
- Implement appropriate logging
- Set up alerting thresholds
- Document troubleshooting guides
- Regular review of metrics
## Compliance & Governance
### Data Privacy
- Document data handling practices
- Implement privacy by design
- Regular compliance reviews
- Clear data retention policies
- User consent management
### Audit Trail
- Maintain change history
- Document decision rationale
- Track access and modifications
- Regular security reviews
- Compliance documentation
## BMAD-Specific Considerations
### Session Management
- **Session Kickoff**: Always start new AI sessions with proper context initialization
- **Memory Bank Maintenance**: Keep context files current throughout development
- **Dev Journal Creation**: Document significant work sessions
- **Sprint Reviews**: Regular quality and progress assessments
### Document Sharding
- **When to Shard**: Large PRDs and architecture documents (>1000 lines)
- **How to Shard**: By level 2 sections, maintaining index.md
- **Naming Convention**: Convert section headings to lowercase-dash-case
- **Tool Support**: Use markdown-tree-parser when available
### Brownfield vs Greenfield
- **Greenfield**: Start with PRD → Architecture → Implementation
- **Brownfield**: Document existing → Create focused PRD → Enhance
- **Documentation Focus**: Brownfield docs capture actual state, not ideal
- **Technical Debt**: Always document workarounds and constraints
## Best Practices Summary
1. **Simplicity First**: Choose the simplest solution that works
2. **Documentation as Code**: Treat documentation with same rigor as code
3. **Automate Everything**: If it's done twice, automate it
4. **Security by Default**: Consider security implications in every decision
5. **Test Early and Often**: Multiple levels of testing for confidence
6. **Continuous Improvement**: Regular retrospectives and improvements
7. **Accessibility Always**: Build inclusive solutions from the start
8. **Clean as You Go**: Maintain code quality continuously
9. **Context Persistence**: Maintain Memory Bank for AI continuity
10. **Reality Over Ideals**: Document what exists, not what should be

128
bmad-core/data/sprint-review-triggers.md Normal file
View File

@ -0,0 +1,128 @@
# Sprint Review Triggers
This document outlines when and how to conduct sprint reviews within the BMAD framework.
## When to Conduct Sprint Reviews
### Regular Cadence
- **End of Sprint**: Always conduct at the conclusion of each defined sprint period
- **Weekly/Bi-weekly**: Based on your sprint duration
- **After Major Milestones**: When significant features or phases complete
### Event-Based Triggers
- **Epic Completion**: When all stories in an epic are done
- **Release Preparation**: Before any production release
- **Team Changes**: When team composition changes significantly
- **Process Issues**: When recurring blockers or challenges arise
- **Client Reviews**: Before or after stakeholder demonstrations
## Sprint Review Components
### 1. **Metrics Gathering** (Automated)
- Git commit analysis
- PR merge tracking
- Issue closure rates
- Test coverage changes
- Build/deployment success rates
### 2. **Achievement Documentation**
- Feature completions with evidence
- Technical improvements made
- Documentation updates
- Bug fixes and resolutions
### 3. **Retrospective Elements**
- What went well (celebrate successes)
- What didn't go well (identify issues)
- What we learned (capture insights)
- What we'll try next (action items)
### 4. **Memory Bank Updates**
- Update progress.md with completed features
- Update activeContext.md with current state
- Document new patterns in systemPatterns.md
- Reflect on technical decisions
## Sprint Review Best Practices
### Preparation
- Schedule review 1-2 days before sprint end
- Gather metrics using git commands beforehand
- Review dev journals from the sprint
- Prepare demo materials if applicable
### Facilitation
- Keep to 60-90 minutes maximum
- Encourage all team members to contribute
- Focus on facts and evidence
- Balance positive and improvement areas
- Make action items specific and assignable
### Documentation
- Use consistent naming: `YYYYMMDD-sprint-review.md`
- Place in `docs/devJournal/` directory
- Link to relevant PRs, issues, and commits
- Include screenshots or recordings when helpful
### Follow-up
- Assign owners to all action items
- Set deadlines for improvements
- Review previous sprint's action items
- Update project Memory Bank
- Share outcomes with stakeholders
## Integration with BMAD Workflow
### Before Sprint Review
1. Complete all story reviews
2. Update CHANGELOG.md
3. Ensure dev journals are current
4. Close completed issues/PRs
### During Sprint Review
1. Use `*sprint-review` command as Scrum Master
2. Follow the guided template
3. Gather team input actively
4. Document honestly and thoroughly
### After Sprint Review
1. Update Memory Bank (`*update-memory-bank`)
2. Create next sprint's initial backlog
3. Communicate outcomes to stakeholders
4. Schedule action item check-ins
5. Archive sprint artifacts
## Anti-Patterns to Avoid
- **Skipping Reviews**: Even failed sprints need reviews
- **Solo Reviews**: Include the whole team when possible
- **Blame Sessions**: Focus on process, not people
- **No Action Items**: Every review should produce improvements
- **Lost Knowledge**: Always document in standard location
- **Metrics Without Context**: Numbers need interpretation
## Quick Reference
### Git Commands for Metrics
```bash
# Commits in sprint
git log --since="2024-01-01" --until="2024-01-14" --oneline | wc -l
# PRs merged
git log --merges --since="2024-01-01" --until="2024-01-14" --oneline
# Issues closed
git log --since="2024-01-01" --until="2024-01-14" --grep="close[sd]\|fixe[sd]" --oneline
# Active branches
git branch --format='%(refname:short) %(creatordate:short)' | grep '2024-01'
```
### Review Checklist
- [ ] Sprint dates and goal documented
- [ ] All metrics gathered
- [ ] Features linked to PRs
- [ ] Retrospective completed
- [ ] Action items assigned
- [ ] Memory Bank updated
- [ ] Next sprint prepared

42
bmad-core/data/technical-preferences.md
View File

@ -1,3 +1,43 @@
# User-Defined Preferred Patterns and Preferences
# Technical Preferences and Architectural Principles
## Core Principles References
The following technical principles and standards apply to all BMAD projects:
### 1. Coding Standards
- **Reference:** `coding-standards.md`
- **Purpose:** Fundamental coding principles, security practices, and quality standards
- **Key Areas:** Code simplicity, dependency management, security, testing, commit standards
### 2. Twelve-Factor App Principles
- **Reference:** `twelve-factor-principles.md`
- **Purpose:** Cloud-native application development principles
- **Key Areas:** Codebase management, dependencies, config, backing services, build/release/run
### 3. Microservice Patterns
- **Reference:** `microservice-patterns.md`
- **Purpose:** Patterns for distributed system architecture
- **Key Areas:** Service decomposition, communication patterns, data management, resilience
## Application Guidelines
1. **During Architecture Design:**
- Apply twelve-factor principles for cloud-native applications
- Consider microservice patterns for complex distributed systems
- Document pattern choices in Architecture Decision Records (ADRs)
2. **During Implementation:**
- Follow coding standards for all code generation
- Apply security principles by default
- Ensure testability and maintainability
3. **Technology Selection:**
- Prefer simple, proven solutions over complex ones
- Minimize dependencies unless explicitly justified
- Consider operational complexity alongside technical capabilities
## User-Defined Preferences
_Add project-specific technical preferences below:_
None Listed

123
bmad-core/data/twelve-factor-principles.md Normal file
View File

@ -0,0 +1,123 @@
# Twelve-Factor App Principles
> **Purpose:** This document provides the definitive set of rules based on the Twelve-Factor App methodology. These principles are mandatory for ensuring applications are built as scalable, resilient, and maintainable cloud-native services.
## The Twelve Factors
### I. Codebase
- A single, version-controlled codebase must represent one application
- All code for a specific application belongs to this single codebase
- Shared functionality must be factored into versioned libraries
- One codebase produces multiple deploys (development, staging, production)
### II. Dependencies
- Explicitly declare all dependencies via manifest files (e.g., package.json, requirements.txt)
- Never rely on implicit existence of system-wide packages
- Application must run in isolated environment with only declared dependencies
### III. Config
- Strict separation between code and configuration
- All deploy-varying config must be read from environment variables
- Never hardcode environment-specific values in source code
- Codebase must be runnable anywhere with correct environment variables
### IV. Backing Services
- Treat all backing services as attached, swappable resources
- Connect via locators/credentials stored in environment variables
- Code must be agnostic to whether service is local or third-party
- Examples: databases, message queues, caches, external APIs
### V. Build, Release, Run
Maintain strict three-stage separation:
- **Build:** Convert code repo into executable bundle
- **Release:** Combine build with environment-specific config
- **Run:** Execute release in target environment
- Releases must be immutable with unique IDs
- Any change requires new release
### VI. Processes
- Execute as stateless, share-nothing processes
- Persistent data must be stored in stateful backing service
- Never assume local memory/disk state available across requests
- Process state is ephemeral
### VII. Port Binding
- Application must be self-contained
- Export services by binding to port specified via configuration
- Do not rely on runtime injection of webserver
- Application brings its own webserver library
### VIII. Concurrency
- Scale out horizontally by adding concurrent processes
- Assign different workload types to different process types
- Use process manager for lifecycle management
- Design for horizontal scaling from the start
### IX. Disposability
- Processes must be disposable (start/stop quickly)
- Minimize startup time for fast elastic scaling
- Graceful shutdown on SIGTERM
- Robust against sudden death (crash-only design)
### X. Dev/Prod Parity
Keep environments as similar as possible:
- Same programming language versions
- Same system tooling
- Same backing service types and versions
- Minimize time, personnel, and tool gaps
### XI. Logs
- Treat logs as event streams
- Never write to or manage log files directly
- Write unbuffered to stdout
- Execution environment handles collection and routing
### XII. Admin Processes
- Run admin tasks as one-off processes
- Use identical environment as long-running processes
- Ship admin scripts with application code
- Use same dependency and config management
## Additional Cloud-Native Principles
### Containerization
- **[SVC] Service as Container:** Package services as container images
- Encapsulate technology stack in containers
- Ensure consistent deployment across environments
### Serverless Options
- **[SRL] Serverless Deployment:** Consider serverless platforms when appropriate
- Abstract away infrastructure management
- Focus on business logic over infrastructure
### Observability
- Implement comprehensive monitoring and metrics
- Use distributed tracing for microservices
- Ensure all services are observable by default
### Security
- Security must be built-in, not bolted-on
- Use principle of least privilege
- Implement defense in depth
- Regular security audits and updates
## AI/Agent Safeguards
- All AI-generated code must be reviewed before production
- Escalate ambiguous or risky decisions for approval
- Log all significant AI-suggested changes
- Never overwrite .env files without confirmation
## Environmental Sustainability
- Optimize compute resources
- Minimize infrastructure waste
- Prefer energy-efficient solutions
- Consider environmental impact in technical decisions
## Integration with BMAD
These principles should be:
1. Applied during architecture design
2. Validated during implementation
3. Enforced through CI/CD pipelines
4. Reviewed during architectural decision records (ADRs)
5. Considered in all technical decisions

170
bmad-core/tasks/conduct-sprint-review.md Normal file
View File

@ -0,0 +1,170 @@
# Conduct Sprint Review
This task guides the Scrum Master through conducting a comprehensive sprint review and retrospective at the end of each sprint or major iteration.
## Purpose
- Document sprint achievements and deliverables
- Analyze sprint metrics and goal completion
- Facilitate team retrospective
- Capture learnings and action items
- Update Memory Bank with sprint outcomes
## Process
### 1. Gather Sprint Context
Before starting the review, collect:
**Sprint Information**:
- Sprint dates (start and end)
- Sprint goal/theme
- Team participants
- Active branches/releases
**Metrics** (use git commands):
```bash
# Commits during sprint
git log --since="YYYY-MM-DD" --until="YYYY-MM-DD" --oneline | wc -l
# PRs merged
git log --merges --since="YYYY-MM-DD" --until="YYYY-MM-DD" --oneline | wc -l
# Issues closed
git log --since="YYYY-MM-DD" --until="YYYY-MM-DD" --grep="close[sd]\|fixe[sd]" --oneline | wc -l
# Branches created
git branch --format='%(refname:short) %(creatordate:short)' | grep 'YYYY-MM'
```
### 2. Review Dev Journals
Scan recent dev journal entries to identify:
- Major features completed
- Technical challenges overcome
- Patterns established
- Decisions made
```bash
ls -la docs/devJournal/*.md | tail -10
```
### 3. Review ADRs
Check for new architectural decisions:
```bash
ls -la docs/adr/*.md | tail -5
```
### 4. Create Sprint Review Document
Create file: `docs/devJournal/YYYYMMDD-sprint-review.md`
Use the sprint-review-tmpl.yaml template (or create manually) covering:
#### Essential Sections
**1. Sprint Overview**
- Sprint dates and goal
- Participants and roles
- Branch/release information
**2. Achievements & Deliverables**
- Major features completed (with PR links)
- Technical milestones reached
- Documentation updates
- Testing improvements
**3. Sprint Metrics**
- Commit count
- PRs merged (with details)
- Issues closed
- Test coverage changes
**4. Goal Review**
- What was planned vs achieved
- Items not completed (with reasons)
- Goal completion percentage
**5. Demo & Walkthrough**
- Screenshots/videos if available
- Instructions for reviewing features
**6. Retrospective**
- **What Went Well**: Successes and effective practices
- **What Didn't Go Well**: Blockers and pain points
- **What We Learned**: Technical and process insights
- **What We'll Try Next**: Improvement experiments
**7. Action Items**
- Concrete actions with owners
- Deadlines for next sprint
- Process improvements to implement
**8. References**
- Dev journal entries from sprint
- New/updated ADRs
- CHANGELOG updates
- Memory Bank updates
### 5. Update Memory Bank
After sprint review, update:
**activeContext.md**:
- Current sprint outcomes
- Next sprint priorities
- Active action items
**progress.md**:
- Features completed this sprint
- Overall project progress
- Velocity trends
**systemPatterns.md** (if applicable):
- New patterns adopted
- Technical decisions from retrospective
### 6. Facilitate Team Discussion
If in party-mode or team setting:
- Share sprint review with team
- Gather additional feedback
- Refine action items collaboratively
- Celebrate achievements
### 7. Prepare for Next Sprint
Based on review outcomes:
- Update backlog priorities
- Create next sprint goal
- Schedule action item follow-ups
- Communicate decisions to stakeholders
## Quality Checklist
- [ ] All sprint metrics gathered and documented
- [ ] Achievements clearly linked to sprint goal
- [ ] Honest assessment of what wasn't completed
- [ ] Retrospective captures diverse perspectives
- [ ] Action items are specific and assigned
- [ ] Memory Bank updated with outcomes
- [ ] Document follows naming convention
- [ ] References to related documentation included
## Output
The sprint review document serves as:
- Historical record of sprint progress
- Input for project reporting
- Source for continuous improvement
- Knowledge transfer for future sprints
- Update source for Memory Bank
## Notes
- Conduct reviews even for partial sprints
- Include both technical and process perspectives
- Be honest about challenges and failures
- Focus on actionable improvements
- Link to specific evidence (PRs, commits, journals)

2
bmad-core/tasks/create-adr.md
View File

@ -4,6 +4,8 @@ This task guides the creation of an ADR to document significant architectural de
## Initial Setup (if needed)
[[LLM: The ADR location follows the standard defined in project-scaffolding-preference.md]]
If the /docs/adr directory doesn't exist in the project:
1. Create the directory: `mkdir -p docs/adr`
2. Create a README.md explaining ADR purpose and structure

10
bmad-core/tasks/create-dev-journal.md
View File

@ -6,6 +6,9 @@ This task guides the creation of a development journal entry to document the ses
- Have git access to review commits and changes
## Initial Setup (if needed)
[[LLM: The Dev Journal location follows the standard defined in project-scaffolding-preference.md]]
If the /docs/devJournal directory doesn't exist in the project:
1. Create the directory: `mkdir -p docs/devJournal`
2. Create a README.md in that directory explaining its purpose
@ -33,14 +36,16 @@ Check existing entries: `ls docs/devJournal/YYYYMMDD-*.md`
Use the dev-journal-tmpl.yaml template to create a comprehensive entry covering:
#### Essential Sections:
#### Essential Sections
1. **Session Overview** - Brief summary of accomplishments
2. **Work Streams** - Detailed breakdown of each area of work
3. **Implementation Details** - Key code changes and decisions
4. **Validation & Testing** - What was tested and verified
5. **Current State & Next Steps** - Where we are and what's next
#### Evidence Gathering:
**Sprint Journal Entries**: For end-of-sprint dev journal entries, cross-reference with `sprint-review-checklist.md` to ensure all sprint accomplishments and learnings are captured.
#### Evidence Gathering
- Review all commits made during session
- Check modified files by functional area
- Note any new patterns or architectural decisions
@ -68,6 +73,7 @@ Before finalizing, ensure:
- Include enough detail for context without overwhelming
- Cross-reference related stories, ADRs, or PRs
- Use British English for consistency
- For sprint-end entries, ensure alignment with sprint review documentation using `sprint-review-checklist.md`
## Memory Bank Integration

6
bmad-core/tasks/create-next-story.md
View File

@ -4,6 +4,12 @@
To identify the next logical story based on project progress and epic definitions, and then to prepare a comprehensive, self-contained, and actionable story file using the `Story Template`. This task ensures the story is enriched with all necessary technical context, requirements, and acceptance criteria, making it ready for efficient implementation by a Developer Agent with minimal need for additional research or finding its own context.
## Prerequisites
Before creating stories, ensure proper session context:
- **Session Kickoff**: If this is a new session or after significant time gap (>24 hours), first run the `session-kickoff` task to establish complete project context
- **Memory Bank**: Verify Memory Bank files are current for accurate story creation
## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
### 0. Load Core Configuration and Check Workflow

37
bmad-core/tasks/document-project.md
View File

@ -4,6 +4,12 @@
Generate comprehensive documentation for existing projects optimized for AI development agents. This task creates structured reference materials that enable AI agents to understand project context, conventions, and patterns for effective contribution to any codebase.
## Prerequisites
Before documenting a project, ensure proper session context:
- **Session Kickoff**: If this is a new session or after significant time gap (>24 hours), first run the `session-kickoff` task to establish complete project context
- **Memory Bank Review**: Check if Memory Bank exists to understand project history and context
## Task Instructions
### 1. Initial Project Analysis
@ -111,9 +117,9 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
### Change Log
| Date | Version | Description | Author |
|------|---------|-------------|--------|
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
| Date | Version | Description | Author |
|--------|---------|-----------------------------|-----------|
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
## Quick Reference - Key Files and Entry Points
@ -136,11 +142,11 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
### Actual Tech Stack (from package.json/requirements.txt)
| Category | Technology | Version | Notes |
|----------|------------|---------|--------|
| Runtime | Node.js | 16.x | [Any constraints] |
| Framework | Express | 4.18.2 | [Custom middleware?] |
| Database | PostgreSQL | 13 | [Connection pooling setup] |
| Category | Technology | Version | Notes |
|-----------|------------|---------|----------------------------|
| Runtime | Node.js | 16.x | [Any constraints] |
| Framework | Express | 4.18.2 | [Custom middleware?] |
| Database | PostgreSQL | 13 | [Connection pooling setup] |
etc...
@ -208,10 +214,10 @@ Instead of duplicating, reference actual model files:
### External Services
| Service | Purpose | Integration Type | Key Files |
|---------|---------|------------------|-----------|
| Stripe | Payments | REST API | `src/integrations/stripe/` |
| SendGrid | Emails | SDK | `src/services/emailService.js` |
| Service | Purpose | Integration Type | Key Files |
|----------|----------|------------------|--------------------------------|
| Stripe | Payments | REST API | `src/integrations/stripe/` |
| SendGrid | Emails | SDK | `src/services/emailService.js` |
etc...
@ -335,13 +341,14 @@ Apply the advanced elicitation task after major sections to refine based on user
## Memory Bank Integration
After documenting a project:
1. Consider initializing Memory Bank if not exists (`initialize-memory-bank` task)
2. Use the brownfield architecture document to populate:
1. Ensure proper session context via `session-kickoff` task (references `session-kickoff-checklist.md`)
2. Consider initializing Memory Bank if not exists (`initialize-memory-bank` task)
3. Use the brownfield architecture document to populate:
- `projectbrief.md` - Extract project goals and constraints
- `systemPatterns.md` - Document architecture and patterns
- `techContext.md` - Capture technology stack and environment
- `progress.md` - Note current state and technical debt
3. This provides AI agents with both detailed architecture docs and quick-reference Memory Bank
4. This provides AI agents with both detailed architecture docs and quick-reference Memory Bank
## Notes

8
bmad-core/tasks/initialize-memory-bank.md
View File

@ -15,6 +15,8 @@ The Memory Bank serves as persistent memory for AI agents, containing:
### 1. Create Directory Structure
[[LLM: The Memory Bank location follows the standard defined in project-scaffolding-preference.md]]
```bash
mkdir -p docs/memory-bank
```
@ -157,11 +159,13 @@ The Memory Bank integrates with:
- [ ] Next steps clearly defined
- [ ] Technical decisions documented
- [ ] Progress accurately reflected
- [ ] Verified against session-kickoff-checklist.md requirements
## Notes
- Memory Bank is the foundation for AI continuity
- Must be updated regularly to maintain value
- All agents should read before starting work
- All agents should read before starting work (via session-kickoff task)
- Updates should be comprehensive but concise
- British English for consistency
- British English for consistency
- Use session-kickoff-checklist.md to verify proper initialization

219
bmad-core/tasks/session-kickoff.md Normal file
View File

@ -0,0 +1,219 @@
# Session Kickoff
This task ensures AI agents have complete project context and understanding before starting work. It provides systematic session initialization across all agent types.
## Purpose
- Establish comprehensive project understanding
- Validate documentation consistency
- Identify current project state and priorities
- Recommend next steps based on evidence
- Prevent context gaps that lead to suboptimal decisions
## Process
### 1. Memory Bank Review (Primary Context)
**Priority Order**:
1. **Memory Bank Files** (if they exist): `docs/memory-bank/`
- `projectbrief.md` - Project foundation and scope
- `activeContext.md` - Current work and immediate priorities
- `progress.md` - Project state and completed features
- `systemPatterns.md` - Architecture and technical decisions
- `techContext.md` - Technology stack and constraints
- `productContext.md` - Problem space and user needs
**Analysis Required**:
- When were these last updated?
- Is information current and accurate?
- Any apparent inconsistencies between files?
### 2. Architecture Documentation Review
**Primary References** (check which exists):
- `/docs/architecture.md` - General backend/system architecture (greenfield)
- `/docs/brownfield-architecture.md` - Enhancement architecture for existing systems
- `/docs/frontend-architecture.md` - Frontend-specific architecture
- `/docs/fullstack-architecture.md` - Complete full-stack architecture
**Key Elements to Review**:
- Core architectural decisions and patterns
- System design and component relationships
- Technology choices and constraints
- Integration points and data flows
- API documentation
- Database schemas
### 3. Development History Review
**Recent Dev Journals**: `docs/devJournal/`
- Read last 3-5 entries to understand recent work
- Identify patterns in challenges and decisions
- Note any unresolved issues or technical debt
- Understand development velocity and blockers
**Current ADRs**: `docs/adr/`
- Review recent architectural decisions
- Check for pending or superseded decisions
- Validate alignment with current architecture
- Skip archived ADRs (consolidated in architecture docs)
### 4. Project Documentation Scan
**Core Documentation**:
- `README.md` - Project overview and setup
- `CHANGELOG.md` - Recent changes and releases
- Package manifests (`package.json`, `requirements.txt`, etc.)
- Configuration files
**Additional Context**:
- Issue trackers or project boards
- Recent commits and branches
- Test results and coverage reports
### 5. Current State Assessment
**Development Environment**:
```bash
# Check git status
git status
git log --oneline -10
# Check current branch and commits
git branch -v
# Review recent changes
git diff --name-status HEAD~5
```
**Project Health**:
- Are there failing tests or builds?
- Any urgent issues or blockers?
- Current sprint/iteration status
- Outstanding pull requests
### 6. Consistency Validation
**Cross-Reference Checks**:
- Does Memory Bank align with actual codebase?
- Are ADRs reflected in current architecture?
- Do dev journals match git history?
- Is documentation current with recent changes?
**Identify Gaps**:
- Missing or outdated documentation
- Undocumented architectural decisions
- Inconsistencies between sources
- Knowledge gaps requiring clarification
### 7. Agent-Specific Context
**For Architect Agent**:
- Focus on architectural decisions and system design
- Review technical debt and improvement opportunities
- Assess scalability and performance considerations
**For Developer Agent**:
- Focus on current work items and immediate tasks
- Review recent implementation patterns
- Understand testing and deployment processes
**For Product Owner Agent**:
- Focus on requirements and user stories
- Review product roadmap and priorities
- Assess feature completion and user feedback
### 8. Next Steps Recommendation
**Based on Evidence**:
- What are the most urgent priorities?
- Are there any blockers or dependencies?
- What documentation needs updating?
- What architectural decisions are pending?
**Recommended Actions**:
1. **Immediate Tasks** - Ready to start now
2. **Dependency Resolution** - What needs clarification
3. **Documentation Updates** - What needs to be updated
4. **Strategic Items** - Longer-term considerations
## Quality Checklist
- [ ] Memory Bank reviewed (or noted if missing)
- [ ] Architecture documentation understood
- [ ] Recent development history reviewed
- [ ] Current project state assessed
- [ ] Documentation inconsistencies identified
- [ ] Agent-specific context established
- [ ] Next steps clearly recommended
- [ ] Any urgent issues flagged
## Output Template
```markdown
# Session Kickoff Summary
## Project Understanding
- **Project**: [Name and core purpose]
- **Current Phase**: [Development stage]
- **Last Updated**: [When Memory Bank was last updated]
## Documentation Health
- **Memory Bank**: [Exists/Missing/Outdated]
- **Architecture Docs**: [Current/Needs Update]
- **Dev Journals**: [Last entry date]
- **ADRs**: [Recent decisions noted]
## Current State
- **Active Branch**: [Git branch]
- **Recent Work**: [Summary from dev journals]
- **Project Health**: [Green/Yellow/Red with reasons]
- **Immediate Blockers**: [Any urgent issues]
## Inconsistencies Found
[List any documentation inconsistencies or gaps]
## Agent-Specific Context
[Relevant context for current agent role]
## Recommended Next Steps
1. [Most urgent priority]
2. [Secondary priority]
3. [Documentation updates needed]
```
## Integration Points
This task integrates with:
- **Memory Bank**: Primary source of project context
- **All Agents**: Universal session initialization
- **Document Project**: Can trigger if documentation missing
- **Update Memory Bank**: Can trigger if information outdated
- **Agent Activation**: Called at start of agent sessions
## Usage Patterns
**New Agent Session**:
1. Agent activates
2. Runs `session-kickoff` task
3. Reviews output and confirms understanding
4. Proceeds with informed context
**Project Handoff**:
1. New team member or AI session
2. Runs comprehensive kickoff
3. Identifies knowledge gaps
4. Updates documentation as needed
**Quality Gate**:
1. Before major feature work
2. After significant time gap
3. When context seems incomplete
4. As part of regular project health checks
## Notes
- This task should be lightweight for daily use but comprehensive for major handoffs
- Adapt depth based on project complexity and available time
- Can be automated as part of agent startup routines
- Helps prevent tunnel vision and context loss

5
bmad-core/tasks/update-memory-bank.md
View File

@ -134,6 +134,8 @@ Triggered by:
- Significant project pivot
- Before major feature work
**Sprint Review Integration**: For sprint-end updates, use the `sprint-review-checklist.md` to ensure all sprint accomplishments, learnings, and technical decisions are captured in the Memory Bank.
## Quality Checklist
- [ ] All recent dev journals reviewed
@ -151,8 +153,9 @@ This task integrates with:
- **Dev Journal Creation**: Triggers selective activeContext update
- **ADR Creation**: Triggers systemPatterns update
- **Story Completion**: Triggers progress update
- **Sprint End**: Triggers comprehensive update
- **Sprint End**: Triggers comprehensive update (use `sprint-review-checklist.md`)
- **Architecture Changes**: Triggers multiple file updates
- **Sprint Reviews**: Reference `sprint-review-checklist.md` to ensure comprehensive capture of sprint outcomes
## Example Update Flow

4
bmad-core/templates/activeContext-tmpl.yaml
View File

@ -102,7 +102,7 @@ sections:
- Example: {{this.example}}
{{/if}}
- When to use: {{this.usage_guidance}}
{{/each}}
### Team Preferences
@ -263,4 +263,4 @@ prompts:
gotchas: "Things to remember/watch out for"
dependencies_check: "What to verify first"
recent_messages: "Important recent communications"
pending_communications: "Who needs to be informed about what"
pending_communications: "Who needs to be informed about what"

18
bmad-core/templates/adr-tmpl.yaml
View File

@ -24,11 +24,11 @@ sections:
# {{adr_number}}. {{adr_title}}
**Date**: {{decision_date}}
**Status**: {{status}}
**Deciders**: {{deciders}}
**Technical Story**: {{technical_story}}
- id: context
@ -60,23 +60,23 @@ sections:
{{#each alternatives}}
### {{this.name}}
**Description**: {{this.description}}
**Pros**:
{{#each this.pros}}
- {{this}}
{{/each}}
**Cons**:
{{#each this.cons}}
- {{this}}
{{/each}}
{{#if this.cost}}
**Cost**: {{this.cost}}
{{/if}}
{{#if this.complexity}}
**Complexity**: {{this.complexity}}
{{/if}}
@ -242,4 +242,4 @@ prompts:
related_adrs: "Links to related ADRs"
references: "Links to supporting documentation"
superseded_by: "If superseded, link to newer ADR"
supersedes: "If this supersedes others, list them"
supersedes: "If this supersedes others, list them"

100
bmad-core/templates/architecture-tmpl.yaml
View File

@ -20,20 +20,22 @@ sections:
- id: intro-content
content: |
This document outlines the overall project architecture for {{project_name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies.
**Relationship to Frontend Architecture:**
If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components.
- id: starter-template
title: Starter Template or Existing Project
instruction: |
Before proceeding further with architecture design, check if the project is based on a starter template or existing codebase:
1. Review the PRD and brainstorming brief for any mentions of:
- Starter templates (e.g., Create React App, Next.js, Vue CLI, Angular CLI, etc.)
- Existing projects or codebases being used as a foundation
- Boilerplate projects or scaffolding tools
- Previous projects to be cloned or adapted
NOTE: Reference project-scaffolding-preference.md for standard project structure guidelines regardless of starter template choice.
2. If a starter template or existing project is mentioned:
- Ask the user to provide access via one of these methods:
- Link to the starter template documentation
@ -46,16 +48,16 @@ sections:
- Existing architectural patterns and conventions
- Any limitations or constraints imposed by the starter
- Use this analysis to inform and align your architecture decisions
3. If no starter template is mentioned but this is a greenfield project:
- Suggest appropriate starter templates based on the tech stack preferences
- Explain the benefits (faster setup, best practices, community support)
- Let the user decide whether to use one
4. If the user confirms no starter template will be used:
- Proceed with architecture design from scratch
- Note that manual setup will be required for all tooling and configuration
Document the decision here before proceeding with the architecture design. If none, just say N/A
elicit: true
- id: changelog
@ -83,7 +85,7 @@ sections:
title: High Level Overview
instruction: |
Based on the PRD's Technical Assumptions section, describe:
1. The main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven)
2. Repository structure decision from PRD (Monorepo/Polyrepo)
3. Service architecture decision from PRD
@ -100,17 +102,17 @@ sections:
- Data flow directions
- External integrations
- User entry points
- id: architectural-patterns
title: Architectural and Design Patterns
instruction: |
List the key high-level patterns that will guide the architecture. For each pattern:
1. Present 2-3 viable options if multiple exist
2. Provide your recommendation with clear rationale
3. Get user confirmation before finalizing
4. These patterns should align with the PRD's technical assumptions and project goals
Common patterns to consider:
- Architectural style patterns (Serverless, Event-Driven, Microservices, CQRS, Hexagonal)
- Code organization patterns (Dependency Injection, Repository, Module, Factory)
@ -126,23 +128,23 @@ sections:
title: Tech Stack
instruction: |
This is the DEFINITIVE technology selection section. Work with the user to make specific choices:
1. Review PRD technical assumptions and any preferences from {root}/data/technical-preferences.yaml or an attached technical-preferences
2. For each category, present 2-3 viable options with pros/cons
3. Make a clear recommendation based on project needs
4. Get explicit user approval for each selection
5. Document exact versions (avoid "latest" - pin specific versions)
6. This table is the single source of truth - all other docs must reference these choices
Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about - let the user know if they are not sure on any that you can also provide suggestions with rationale:
- Starter templates (if any)
- Languages and runtimes with exact versions
- Frameworks and libraries / packages
- Cloud provider and key services choices
- Database and storage solutions - if unclear suggest sql or nosql or other types depending on the project and depending on cloud provider offer a suggestion
- Development tools
Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback - this statement and the options should be rendered and then prompt right all before allowing user input.
elicit: true
sections:
@ -166,13 +168,13 @@ sections:
title: Data Models
instruction: |
Define the core data models/entities:
1. Review PRD requirements and identify key business entities
2. For each model, explain its purpose and relationships
3. Include key attributes and data types
4. Show relationships between models
5. Discuss design decisions with user
Create a clear conceptual model before moving to database schema.
elicit: true
repeatable: true
@ -181,11 +183,11 @@ sections:
title: "{{model_name}}"
template: |
**Purpose:** {{model_purpose}}
**Key Attributes:**
- {{attribute_1}}: {{type_1}} - {{description_1}}
- {{attribute_2}}: {{type_2}} - {{description_2}}
**Relationships:**
- {{relationship_1}}
- {{relationship_2}}
@ -194,7 +196,7 @@ sections:
title: Components
instruction: |
Based on the architectural patterns, tech stack, and data models from above:
1. Identify major logical components/services and their responsibilities
2. Consider the repository structure (monorepo/polyrepo) from PRD
3. Define clear boundaries and interfaces between components
@ -203,7 +205,7 @@ sections:
- Key interfaces/APIs exposed
- Dependencies on other components
- Technology specifics based on tech stack choices
5. Create component diagrams where helpful
elicit: true
sections:
@ -212,13 +214,13 @@ sections:
title: "{{component_name}}"
template: |
**Responsibility:** {{component_description}}
**Key Interfaces:**
- {{interface_1}}
- {{interface_2}}
**Dependencies:** {{dependencies}}
**Technology Stack:** {{component_tech_details}}
- id: component-diagrams
title: Component Diagrams
@ -235,13 +237,13 @@ sections:
condition: Project requires external API integrations
instruction: |
For each external service integration:
1. Identify APIs needed based on PRD requirements and component design
2. If documentation URLs are unknown, ask user for specifics
3. Document authentication methods and security considerations
4. List specific endpoints that will be used
5. Note any rate limits or usage constraints
If no external APIs are needed, state this explicitly and skip to next section.
elicit: true
repeatable: true
@ -254,10 +256,10 @@ sections:
- **Base URL(s):** {{api_base_url}}
- **Authentication:** {{auth_method}}
- **Rate Limits:** {{rate_limits}}
**Key Endpoints Used:**
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
**Integration Notes:** {{integration_considerations}}
- id: core-workflows
@ -266,13 +268,13 @@ sections:
mermaid_type: sequence
instruction: |
Illustrate key system workflows using sequence diagrams:
1. Identify critical user journeys from PRD
2. Show component interactions including external APIs
3. Include error handling paths
4. Document async operations
5. Create both high-level and detailed diagrams as needed
Focus on workflows that clarify architecture decisions or complex interactions.
elicit: true
@ -283,13 +285,13 @@ sections:
language: yaml
instruction: |
If the project includes a REST API:
1. Create an OpenAPI 3.0 specification
2. Include all endpoints from epics/stories
3. Define request/response schemas based on data models
4. Document authentication requirements
5. Include example requests/responses
Use YAML format for better readability. If no REST API, skip this section.
elicit: true
template: |
@ -306,13 +308,13 @@ sections:
title: Database Schema
instruction: |
Transform the conceptual data models into concrete database schemas:
1. Use the database type(s) selected in Tech Stack
2. Create schema definitions using appropriate notation
3. Include indexes, constraints, and relationships
4. Consider performance and scalability
5. For NoSQL, show document structures
Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.)
elicit: true
@ -322,14 +324,14 @@ sections:
language: plaintext
instruction: |
Create a project folder structure that reflects:
1. The chosen repository structure (monorepo/polyrepo)
2. The service architecture (monolith/microservices/serverless)
3. The selected tech stack and languages
4. Component organization from above
5. Best practices for the chosen frameworks
6. Clear separation of concerns
Adapt the structure based on project needs. For monorepos, show service separation. For serverless, show function organization. Include language-specific conventions.
elicit: true
examples:
@ -347,13 +349,13 @@ sections:
title: Infrastructure and Deployment
instruction: |
Define the deployment architecture and practices:
1. Use IaC tool selected in Tech Stack
2. Choose deployment strategy appropriate for the architecture
3. Define environments and promotion flow
4. Establish rollback procedures
5. Consider security, monitoring, and cost optimization
Get user input on deployment preferences and CI/CD tool choices.
elicit: true
sections:
@ -389,13 +391,13 @@ sections:
title: Error Handling Strategy
instruction: |
Define comprehensive error handling approach:
1. Choose appropriate patterns for the language/framework from Tech Stack
2. Define logging standards and tools
3. Establish error categories and handling rules
4. Consider observability and debugging needs
5. Ensure security (no sensitive data in logs)
This section guides both AI and human developers in consistent error handling.
elicit: true
sections:
@ -442,13 +444,13 @@ sections:
title: Coding Standards
instruction: |
These standards are MANDATORY for AI agents. Work with user to define ONLY the critical rules needed to prevent bad code. Explain that:
1. This section directly controls AI developer behavior
2. Keep it minimal - assume AI knows general best practices
3. Focus on project-specific conventions and gotchas
4. Overly detailed standards bloat context and slow development
5. Standards will be extracted to separate file for dev agent use
For each standard, get explicit user confirmation it's necessary.
elicit: true
sections:
@ -470,7 +472,7 @@ sections:
- "Never use console.log in production code - use logger"
- "All API responses must use ApiResponse wrapper type"
- "Database queries must use repository pattern, never direct ORM"
Avoid obvious rules like "use SOLID principles" or "write clean code"
repeatable: true
template: "- **{{rule_name}}:** {{rule_description}}"
@ -488,14 +490,14 @@ sections:
title: Test Strategy and Standards
instruction: |
Work with user to define comprehensive test strategy:
1. Use test frameworks from Tech Stack
2. Decide on TDD vs test-after approach
3. Define test organization and naming
4. Establish coverage goals
5. Determine integration test infrastructure
6. Plan for test data and external dependencies
Note: Basic info goes in Coding Standards for dev agent. This detailed section is for QA agent and team reference.
elicit: true
sections:
@ -516,7 +518,7 @@ sections:
- **Location:** {{unit_test_location}}
- **Mocking Library:** {{mocking_library}}
- **Coverage Requirement:** {{unit_coverage}}
**AI Agent Requirements:**
- Generate tests for all public methods
- Cover edge cases and error conditions
@ -558,7 +560,7 @@ sections:
title: Security
instruction: |
Define MANDATORY security requirements for AI and human developers:
1. Focus on implementation-specific rules
2. Reference security tools from Tech Stack
3. Define clear patterns for common scenarios
@ -627,16 +629,16 @@ sections:
title: Next Steps
instruction: |
After completing the architecture:
1. If project has UI components:
- Use "Frontend Architecture Mode"
- Provide this document as input
2. For all projects:
- Review with Product Owner
- Begin story implementation with Dev agent
- Set up infrastructure with DevOps agent
3. Include specific prompts for next agents if needed
sections:
- id: architect-prompt

10
bmad-core/templates/brainstorming-output-tmpl.yaml
View File

@ -23,11 +23,11 @@ sections:
- id: summary-details
template: |
**Topic:** {{session_topic}}
**Session Goals:** {{stated_goals}}
**Techniques Used:** {{techniques_list}}
**Total Ideas Generated:** {{total_ideas}}
- id: key-themes
title: "Key Themes Identified:"
@ -152,5 +152,5 @@ sections:
- id: footer
content: |
---
*Session facilitated using the BMAD-METHOD brainstorming framework*
*Session facilitated using the BMAD-METHOD brainstorming framework*

62
bmad-core/templates/brownfield-architecture-tmpl.yaml
View File

@ -16,40 +16,40 @@ sections:
title: Introduction
instruction: |
IMPORTANT - SCOPE AND ASSESSMENT REQUIRED:
This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding:
1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead."
2. **REQUIRED INPUTS**:
- Completed brownfield-prd.md
- Existing project technical documentation (from docs folder or user-provided)
- Access to existing project structure (IDE or uploaded files)
3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions.
4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?"
If any required inputs are missing, request them before proceeding.
elicit: true
sections:
- id: intro-content
content: |
This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system.
**Relationship to Existing Architecture:**
This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements.
- id: existing-project-analysis
title: Existing Project Analysis
instruction: |
Analyze the existing project structure and architecture:
1. Review existing documentation in docs folder
2. Examine current technology stack and versions
3. Identify existing architectural patterns and conventions
4. Note current deployment and infrastructure setup
5. Document any constraints or limitations
CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations."
elicit: true
sections:
@ -78,12 +78,12 @@ sections:
title: Enhancement Scope and Integration Strategy
instruction: |
Define how the enhancement will integrate with the existing system:
1. Review the brownfield PRD enhancement scope
2. Identify integration points with existing code
3. Define boundaries between new and existing functionality
4. Establish compatibility requirements
VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?"
elicit: true
sections:
@ -112,7 +112,7 @@ sections:
title: Tech Stack Alignment
instruction: |
Ensure new components align with existing technology choices:
1. Use existing technology stack as the foundation
2. Only introduce new technologies if absolutely necessary
3. Justify any new additions with clear rationale
@ -135,7 +135,7 @@ sections:
title: Data Models and Schema Changes
instruction: |
Define new data models and how they integrate with existing schema:
1. Identify new entities required for the enhancement
2. Define relationships with existing data models
3. Plan database schema changes (additions, modifications)
@ -151,11 +151,11 @@ sections:
template: |
**Purpose:** {{model_purpose}}
**Integration:** {{integration_with_existing}}
**Key Attributes:**
- {{attribute_1}}: {{type_1}} - {{description_1}}
- {{attribute_2}}: {{type_2}} - {{description_2}}
**Relationships:**
- **With Existing:** {{existing_relationships}}
- **With New:** {{new_relationships}}
@ -167,7 +167,7 @@ sections:
- **Modified Tables:** {{modified_tables_list}}
- **New Indexes:** {{new_indexes_list}}
- **Migration Strategy:** {{migration_approach}}
**Backward Compatibility:**
- {{compatibility_measure_1}}
- {{compatibility_measure_2}}
@ -176,12 +176,12 @@ sections:
title: Component Architecture
instruction: |
Define new components and their integration with existing architecture:
1. Identify new components required for the enhancement
2. Define interfaces with existing components
3. Establish clear boundaries and responsibilities
4. Plan integration points and data flow
MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?"
elicit: true
sections:
@ -194,15 +194,15 @@ sections:
template: |
**Responsibility:** {{component_description}}
**Integration Points:** {{integration_points}}
**Key Interfaces:**
- {{interface_1}}
- {{interface_2}}
**Dependencies:**
- **Existing Components:** {{existing_dependencies}}
- **New Components:** {{new_dependencies}}
**Technology Stack:** {{component_tech_details}}
- id: interaction-diagram
title: Component Interaction Diagram
@ -215,7 +215,7 @@ sections:
condition: Enhancement requires API changes
instruction: |
Define new API endpoints and integration with existing APIs:
1. Plan new API endpoints required for the enhancement
2. Ensure consistency with existing API patterns
3. Define authentication and authorization integration
@ -265,17 +265,17 @@ sections:
- **Base URL:** {{api_base_url}}
- **Authentication:** {{auth_method}}
- **Integration Method:** {{integration_approach}}
**Key Endpoints Used:**
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
**Error Handling:** {{error_handling_strategy}}
- id: source-tree-integration
title: Source Tree Integration
instruction: |
Define how new code will integrate with existing project structure:
1. Follow existing project organization patterns
2. Identify where new files/folders will be placed
3. Ensure consistency with existing naming conventions
@ -314,7 +314,7 @@ sections:
title: Infrastructure and Deployment Integration
instruction: |
Define how the enhancement will be deployed alongside existing infrastructure:
1. Use existing deployment pipeline and infrastructure
2. Identify any infrastructure changes needed
3. Plan deployment strategy to minimize risk
@ -344,7 +344,7 @@ sections:
title: Coding Standards and Conventions
instruction: |
Ensure new code follows existing project conventions:
1. Document existing coding standards from project analysis
2. Identify any enhancement-specific requirements
3. Ensure consistency with existing codebase patterns
@ -375,7 +375,7 @@ sections:
title: Testing Strategy
instruction: |
Define testing approach for the enhancement:
1. Integrate with existing test suite
2. Ensure existing functionality remains intact
3. Plan for testing new features
@ -415,7 +415,7 @@ sections:
title: Security Integration
instruction: |
Ensure security consistency with existing system:
1. Follow existing security patterns and tools
2. Ensure new features don't introduce vulnerabilities
3. Maintain existing security posture
@ -450,7 +450,7 @@ sections:
title: Next Steps
instruction: |
After completing the brownfield architecture:
1. Review integration points with existing system
2. Begin story implementation with Dev agent
3. Set up deployment pipeline integration
@ -473,4 +473,4 @@ sections:
- Integration requirements with existing codebase validated with user
- Key technical decisions based on real project constraints
- Existing system compatibility requirements with specific verification steps
- Clear sequencing of implementation to minimize risk to existing functionality
- Clear sequencing of implementation to minimize risk to existing functionality

26
bmad-core/templates/brownfield-prd-tmpl.yaml
View File

@ -16,19 +16,19 @@ sections:
title: Intro Project Analysis and Context
instruction: |
IMPORTANT - SCOPE ASSESSMENT REQUIRED:
This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding:
1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories."
2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first.
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.
Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements.
CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?"
Do not proceed with any recommendations until the user has validated your understanding of the existing system.
sections:
- id: existing-project-overview
@ -54,7 +54,7 @@ sections:
- Note: "Document-project analysis available - using existing technical documentation"
- List key documents created by document-project
- Skip the missing documentation check below
Otherwise, check for existing documentation:
sections:
- id: available-docs
@ -178,7 +178,7 @@ sections:
If document-project output available:
- Extract from "Actual Tech Stack" table in High Level Architecture section
- Include version numbers and any noted constraints
Otherwise, document the current technology stack:
template: |
**Languages**: {{languages}}
@ -217,7 +217,7 @@ sections:
- Reference "Technical Debt and Known Issues" section
- Include "Workarounds and Gotchas" that might impact enhancement
- Note any identified constraints from "Critical Technical Debt"
Build risk assessment incorporating existing known issues:
template: |
**Technical Risks**: {{technical_risks}}
@ -240,7 +240,7 @@ sections:
title: "Epic 1: {{enhancement_title}}"
instruction: |
Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
CRITICAL STORY SEQUENCING FOR BROWNFIELD:
- Stories must ensure existing functionality remains intact
- Each story should include verification that existing features still work
@ -253,7 +253,7 @@ sections:
- Each story must deliver value while maintaining system integrity
template: |
**Epic Goal**: {{epic_goal}}
**Integration Requirements**: {{integration_requirements}}
sections:
- id: story
@ -277,4 +277,4 @@ sections:
items:
- template: "IV1: {{existing_functionality_verification}}"
- template: "IV2: {{integration_point_verification}}"
- template: "IV3: {{performance_impact_verification}}"
- template: "IV3: {{performance_impact_verification}}"

25
bmad-core/templates/competitor-analysis-tmpl.yaml
View File

@ -76,7 +76,7 @@ sections:
title: Competitor Prioritization Matrix
instruction: |
Help categorize competitors by market share and strategic threat level
Create a 2x2 matrix:
- Priority 1 (Core Competitors): High Market Share + High Threat
- Priority 2 (Emerging Threats): Low Market Share + High Threat
@ -141,7 +141,14 @@ sections:
title: Feature Comparison Matrix
instruction: Create a detailed comparison table of key features across competitors
type: table
columns: ["Feature Category", "{{your_company}}", "{{competitor_1}}", "{{competitor_2}}", "{{competitor_3}}"]
columns:
[
"Feature Category",
"{{your_company}}",
"{{competitor_1}}",
"{{competitor_2}}",
"{{competitor_3}}",
]
rows:
- category: "Core Functionality"
items:
@ -153,7 +160,13 @@ sections:
- ["Onboarding Time", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
- category: "Integration & Ecosystem"
items:
- ["API Availability", "{{availability}}", "{{availability}}", "{{availability}}", "{{availability}}"]
- [
"API Availability",
"{{availability}}",
"{{availability}}",
"{{availability}}",
"{{availability}}",
]
- ["Third-party Integrations", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
- category: "Pricing & Plans"
items:
@ -180,7 +193,7 @@ sections:
title: Positioning Map
instruction: |
Describe competitor positions on key dimensions
Create a positioning description using 2 key dimensions relevant to the market, such as:
- Price vs. Features
- Ease of Use vs. Power
@ -215,7 +228,7 @@ sections:
title: Blue Ocean Opportunities
instruction: |
Identify uncontested market spaces
List opportunities to create new market space:
- Underserved segments
- Unaddressed use cases
@ -290,4 +303,4 @@ sections:
Recommended review schedule:
- Weekly: {{weekly_items}}
- Monthly: {{monthly_items}}
- Quarterly: {{quarterly_analysis}}
- Quarterly: {{quarterly_analysis}}

22
bmad-core/templates/dev-journal-tmpl.yaml
View File

@ -305,62 +305,62 @@ prompts:
git_branch: "Git branch worked on"
developer_name: "Developer name (agent or human)"
session_type: "Session type (Implementation, Bug Fix, Refactoring, Feature Development, Investigation)"
# Session overview
session_summary: "Brief 2-3 sentence summary of session accomplishments"
starting_state: "State of the project at session start"
session_goals: "List session objectives"
previous_entry: "Link to previous journal entry (if applicable)"
# Work details
initial_problem: "Initial request, problem, or task description"
investigation_process: "Detail exploration process, tools used, dead ends"
work_streams: "List work streams with details (name, type, files, changes, rationale, impact)"
breakthroughs: "Key discoveries and decisions with context and resolution"
# Implementation
code_changes_summary: "Summary of significant code changes"
architecture_changes: "New patterns or architectural decisions"
config_updates: "Environment variables, build configs, dependencies"
# Testing
tests_modified: "List test files created or updated"
manual_testing: "User flows and edge cases tested"
validation_working: "What was confirmed working"
remaining_issues: "Any remaining issues"
# Documentation
code_documentation: "Inline comments, JSDoc updates"
project_documentation: "README, Wiki, API docs updated"
adr_updates: "ADRs created or updated"
# Git activity
commits: "List commits with hash and message"
files_added: "Number of files added"
files_modified: "Number of files modified"
files_deleted: "Number of files deleted"
# Learning
challenges: "List challenges and how overcome"
learnings: "Technical insights or patterns discovered"
patterns_established: "New coding patterns or conventions"
# State and next steps
working_features: "Completed features or fixes that are functional"
known_issues: "Bugs or limitations discovered but not resolved"
technical_debt: "Shortcuts taken that need future attention"
immediate_next_steps: "Most urgent tasks for next session"
future_considerations: "Longer-term improvements or refactoring needs"
# Metrics
story_tasks_completed: "Number of story tasks completed (X of Y)"
tests_written: "Number of tests written"
code_coverage: "Code coverage percentage (if measured)"
performance_impact: "Performance impact (if relevant)"
# References
future_session_notes: "Important context, gotchas, or reminders"
related_stories: "Story IDs or links"
related_adrs: "ADR numbers if applicable"
related_prs: "Pull request references"
external_resources: "Helpful links or documentation consulted"
external_resources: "Helpful links or documentation consulted"

35
bmad-core/templates/front-end-architecture-tmpl.yaml
View File

@ -16,16 +16,16 @@ sections:
title: Template and Framework Selection
instruction: |
Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided.
Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase:
1. Review the PRD, main architecture document, and brainstorming brief for mentions of:
- Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.)
- UI kit or component library starters
- Existing frontend projects being used as a foundation
- Admin dashboard templates or other specialized starters
- Design system implementations
2. If a frontend starter template or existing project is mentioned:
- Ask the user to provide access via one of these methods:
- Link to the starter template documentation
@ -41,7 +41,7 @@ sections:
- Testing setup and patterns
- Build and development scripts
- Use this analysis to ensure your frontend architecture aligns with the starter's patterns
3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is:
- Based on the framework choice, suggest appropriate starters:
- React: Create React App, Next.js, Vite + React
@ -49,11 +49,11 @@ sections:
- Angular: Angular CLI
- Or suggest popular UI templates if applicable
- Explain benefits specific to frontend development
4. If the user confirms no starter template will be used:
- Note that all tooling, bundling, and configuration will need manual setup
- Proceed with frontend architecture from scratch
Document the starter template decision and any constraints it imposes before proceeding.
sections:
- id: changelog
@ -75,19 +75,34 @@ sections:
rows:
- ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["UI Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["State Management", "{{state_management}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- [
"State Management",
"{{state_management}}",
"{{version}}",
"{{purpose}}",
"{{why_chosen}}",
]
- ["Routing", "{{routing_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Styling", "{{styling_solution}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Testing", "{{test_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Component Library", "{{component_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- [
"Component Library",
"{{component_lib}}",
"{{version}}",
"{{purpose}}",
"{{why_chosen}}",
]
- ["Form Handling", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Animation", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- id: project-structure
title: Project Structure
instruction: Define exact directory structure for AI tools based on the chosen framework. Be specific about where each type of file goes. Generate a structure that follows the framework's best practices and conventions.
instruction: |
Define exact directory structure for AI tools based on the chosen framework. Be specific about where each type of file goes. Generate a structure that follows the framework's best practices and conventions.
NOTE: Reference project-scaffolding-preference.md for standard project structure guidelines. Ensure to include BMAD-specific directories (docs/memory-bank, docs/adr, docs/devJournal) in addition to frontend-specific structure.
elicit: true
type: code
language: plaintext
@ -203,4 +218,4 @@ sections:
- Common commands (dev server, build, test)
- Key import patterns
- File naming conventions
- Project-specific patterns and utilities
- Project-specific patterns and utilities

48
bmad-core/templates/front-end-spec-tmpl.yaml
View File

@ -16,7 +16,7 @@ sections:
title: Introduction
instruction: |
Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification.
Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.
content: |
This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience.
@ -25,7 +25,7 @@ sections:
title: Overall UX Goals & Principles
instruction: |
Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine:
1. Target User Personas - elicit details or confirm existing ones from PRD
2. Key Usability Goals - understand what success looks like for users
3. Core Design Principles - establish 3-5 guiding principles
@ -66,7 +66,7 @@ sections:
title: Information Architecture (IA)
instruction: |
Collaborate with the user to create a comprehensive information architecture:
1. Build a Site Map or Screen Inventory showing all major areas
2. Define the Navigation Structure (primary, secondary, breadcrumbs)
3. Use Mermaid diagrams for visual representation
@ -96,22 +96,22 @@ sections:
title: Navigation Structure
template: |
**Primary Navigation:** {{primary_nav_description}}
**Secondary Navigation:** {{secondary_nav_description}}
**Breadcrumb Strategy:** {{breadcrumb_strategy}}
- id: user-flows
title: User Flows
instruction: |
For each critical user task identified in the PRD:
1. Define the user's goal clearly
2. Map out all steps including decision points
3. Consider edge cases and error states
4. Use Mermaid flow diagrams for clarity
5. Link to external tools (Figma/Miro) if detailed flows exist there
Create subsections for each major flow.
elicit: true
repeatable: true
@ -120,9 +120,9 @@ sections:
title: "{{flow_name}}"
template: |
**User Goal:** {{flow_goal}}
**Entry Points:** {{entry_points}}
**Success Criteria:** {{success_criteria}}
sections:
- id: flow-diagram
@ -153,14 +153,14 @@ sections:
title: "{{screen_name}}"
template: |
**Purpose:** {{screen_purpose}}
**Key Elements:**
- {{element_1}}
- {{element_2}}
- {{element_3}}
**Interaction Notes:** {{interaction_notes}}
**Design File Reference:** {{specific_frame_link}}
- id: component-library
@ -179,11 +179,11 @@ sections:
title: "{{component_name}}"
template: |
**Purpose:** {{component_purpose}}
**Variants:** {{component_variants}}
**States:** {{component_states}}
**Usage Guidelines:** {{usage_guidelines}}
- id: branding-style
@ -229,13 +229,13 @@ sections:
title: Iconography
template: |
**Icon Library:** {{icon_library}}
**Usage Guidelines:** {{icon_guidelines}}
- id: spacing-layout
title: Spacing & Layout
template: |
**Grid System:** {{grid_system}}
**Spacing Scale:** {{spacing_scale}}
- id: accessibility
@ -253,12 +253,12 @@ sections:
- Color contrast ratios: {{contrast_requirements}}
- Focus indicators: {{focus_requirements}}
- Text sizing: {{text_requirements}}
**Interaction:**
- Keyboard navigation: {{keyboard_requirements}}
- Screen reader support: {{screen_reader_requirements}}
- Touch targets: {{touch_requirements}}
**Content:**
- Alternative text: {{alt_text_requirements}}
- Heading structure: {{heading_requirements}}
@ -285,11 +285,11 @@ sections:
title: Adaptation Patterns
template: |
**Layout Changes:** {{layout_adaptations}}
**Navigation Changes:** {{nav_adaptations}}
**Content Priority:** {{content_adaptations}}
**Interaction Changes:** {{interaction_adaptations}}
- id: animation
@ -323,7 +323,7 @@ sections:
title: Next Steps
instruction: |
After completing the UI/UX specification:
1. Recommend review with stakeholders
2. Suggest creating/updating visual designs in design tool
3. Prepare for handoff to Design Architect for frontend architecture
@ -346,4 +346,4 @@ sections:
- id: checklist-results
title: Checklist Results
instruction: If a UI/UX checklist exists, run it against this document and report results here.
instruction: If a UI/UX checklist exists, run it against this document and report results here.

5
bmad-core/templates/fullstack-architecture-tmpl.yaml
View File

@ -483,7 +483,10 @@ sections:
- id: unified-project-structure
title: Unified Project Structure
instruction: Create a monorepo structure that accommodates both frontend and backend. Adapt based on chosen tools and frameworks.
instruction: |
Create a monorepo structure that accommodates both frontend and backend. Adapt based on chosen tools and frameworks.
NOTE: Reference project-scaffolding-preference.md for standard project structure guidelines and ensure alignment with BMAD conventions including docs/memory-bank, docs/adr, and docs/devJournal directories.
elicit: true
type: code
language: plaintext

4
bmad-core/templates/market-research-tmpl.yaml
View File

@ -130,7 +130,7 @@ sections:
instruction: Map the end-to-end customer experience for primary segments
template: |
For primary customer segment:
1. **Awareness:** {{discovery_process}}
2. **Consideration:** {{evaluation_criteria}}
3. **Purchase:** {{decision_triggers}}
@ -249,4 +249,4 @@ sections:
instruction: Include any complex calculations or models
- id: additional-analysis
title: C. Additional Analysis
instruction: Any supplementary analysis not included in main body
instruction: Any supplementary analysis not included in main body

18
bmad-core/templates/prd-tmpl.yaml
View File

@ -56,7 +56,7 @@ sections:
condition: PRD has UX/UI requirements
instruction: |
Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps:
1. Pre-fill all subsections with educated guesses based on project context
2. Present the complete rendered section to user
3. Clearly let the user know where assumptions were made
@ -98,7 +98,7 @@ sections:
title: Technical Assumptions
instruction: |
Gather technical decisions that will guide the Architect. Steps:
1. Check if {root}/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices
2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets
3. For unknowns, offer guidance based on project goals and MVP scope
@ -126,9 +126,9 @@ sections:
title: Epic List
instruction: |
Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
CRITICAL: Epics MUST be logically sequential following agile best practices:
- Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
- Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic!
- Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
@ -147,11 +147,11 @@ sections:
repeatable: true
instruction: |
After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit.
For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve).
CRITICAL STORY SEQUENCING REQUIREMENTS:
- Stories within each epic MUST be logically sequential
- Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation
- No story should depend on work from a later story or epic
@ -179,7 +179,7 @@ sections:
repeatable: true
instruction: |
Define clear, comprehensive, and testable acceptance criteria that:
- Precisely define what "done" means from a functional perspective
- Are unambiguous and serve as basis for verification
- Include any critical non-functional requirements from the PRD
@ -199,4 +199,4 @@ sections:
instruction: This section will contain the prompt for the UX Expert, keep it short and to the point to initiate create architecture mode using this document as input.
- id: architect-prompt
title: Architect Prompt
instruction: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.
instruction: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.

2
bmad-core/templates/productContext-tmpl.yaml
View File

@ -189,4 +189,4 @@ prompts:
validation_plans: "How will each assumption be tested?"
upstream_dependencies: "What systems/processes feed into ours?"
downstream_impacts: "What systems/processes are affected by our solution?"
partner_integrations: "What third-party services/APIs are needed?"
partner_integrations: "What third-party services/APIs are needed?"

2
bmad-core/templates/progress-tmpl.yaml
View File

@ -238,4 +238,4 @@ prompts:
successes: "What practices/decisions are working well?"
improvements_needed: "What challenges need to be addressed?"
mitigated_risks: "Risks that have been successfully mitigated"
active_risks: "Current risks being tracked"
active_risks: "Current risks being tracked"

20
bmad-core/templates/project-brief-tmpl.yaml
View File

@ -16,7 +16,7 @@ workflow:
mode_selection:
instruction: |
Choose the workflow mode that best fits your needs:
1. **Comprehensive Mode** - Full product development brief with guided elicitation
Output: docs/brief.md
@ -25,7 +25,7 @@ workflow:
3. **Rapid Mode** - Quick project documentation with structured prompts
Output: docs/brief.md
elicitation: advanced-elicitation
custom_elicitation:
title: "Project Brief Enhancement Actions"
@ -314,7 +314,7 @@ prompts:
success_criteria: "Define 3-5 measurable success criteria"
in_scope: "What is IN scope for this project?"
out_scope: "What is explicitly OUT of scope?"
# User-related prompts
primary_user_type: "Describe the primary user type"
primary_user_needs: "What do primary users need from this system?"
@ -323,14 +323,14 @@ prompts:
secondary_user_type: "Describe secondary user types (if any)"
secondary_user_needs: "What do secondary users need?"
secondary_user_description: "Detailed description of secondary users"
# Comprehensive mode prompts
executive_summary_content: "Create executive summary (product concept, problem, target market, value proposition)"
detailed_problem_description: "Detailed problem statement with evidence and impact"
solution_description: "Describe the solution approach and key differentiators"
mvp_scope: "Define MVP scope - what's the minimum viable product?"
kpis: "List key performance indicators"
# Technical prompts
technical_constraints: "List technical constraints"
business_constraints: "List business constraints"
@ -340,13 +340,13 @@ prompts:
security_requirements: "Define security requirements"
scalability_requirements: "Define scalability expectations"
reliability_requirements: "Define reliability/uptime requirements"
# Stakeholder prompts (memory bank mode)
stakeholders: "List primary stakeholders with roles and interests"
decision_makers: "List key decision makers and what they decide"
milestones: "Define major milestones with dates and descriptions"
current_phase_description: "Describe the current project phase"
# Risk and planning prompts (comprehensive mode)
assumptions: "List key assumptions"
risks: "List primary risks with impact and mitigation"
@ -354,12 +354,12 @@ prompts:
technical_architecture_notes: "Technical architecture considerations"
phase2_features: "Features planned for Phase 2"
long_term_vision: "Long-term vision for the product"
# Support prompts
references: "List links to supporting documentation"
research_summary: "Summary of research conducted"
competitive_analysis: "Competitive analysis findings"
# Mode selection
workflow_mode: "Choose workflow mode: comprehensive, memory_bank, or rapid"
output_path: "Output file path (auto-set based on mode if not specified)"
output_path: "Output file path (auto-set based on mode if not specified)"

240
bmad-core/templates/sprint-planning-tmpl.yaml Normal file
View File

@ -0,0 +1,240 @@
template:
type: document
id: sprint-planning-tmpl
name: Sprint Planning Template
version: 1.0.0
description: >-
Template for sprint planning sessions. Documents sprint goals, selected stories,
capacity planning, risk assessment, and success criteria. Integrates with Memory Bank
for context and creates Dev Journal entries for tracking.
category: planning
sections:
- id: sprint-overview
name: Sprint Overview
content: |
# Sprint [Number] Planning
## Sprint Information
- **Sprint Number**: [X]
- **Sprint Name**: [Descriptive name]
- **Start Date**: [YYYY-MM-DD]
- **End Date**: [YYYY-MM-DD]
- **Duration**: [X weeks]
- **Team**: [Team name/composition]
## Sprint Theme
[Brief description of the sprint's primary focus or theme]
- id: context-review
name: Context Review
content: |
## Context from Previous Sprint
### Previous Sprint Outcomes
[Summary of what was completed in the previous sprint]
### Carried Over Items
- [ ] [Story/task carried from previous sprint]
- [ ] [Technical debt item]
### Memory Bank Context
- **Active Context**: [Key points from activeContext.md]
- **Recent Patterns**: [Relevant patterns from systemPatterns.md]
- **Progress Status**: [Current state from progress.md]
### Recent Dev Journal Insights
[Key learnings or decisions from recent dev journals]
- id: sprint-goals
name: Sprint Goals
content: |
## Sprint Goals
### Primary Goal
[Main objective for this sprint - should be achievable and measurable]
### Secondary Goals
1. [Secondary objective 1]
2. [Secondary objective 2]
3. [Secondary objective 3]
### Success Criteria
- [ ] [Specific measurable outcome 1]
- [ ] [Specific measurable outcome 2]
- [ ] [Specific measurable outcome 3]
### Definition of Done
- [ ] All code reviewed and approved
- [ ] All tests passing (unit, integration, E2E)
- [ ] Documentation updated
- [ ] Memory Bank updated with progress
- [ ] Dev Journal entry created
- id: capacity-planning
name: Capacity Planning
content: |
## Team Capacity
### Available Hours
| Team Member | Role | Available Hours | Planned Time Off |
|-------------|------|-----------------|------------------|
| [Name] | [Role] | [Hours] | [Dates if any] |
### Velocity Reference
- **Previous Sprint Velocity**: [Story points]
- **3-Sprint Average**: [Story points]
- **Target Velocity**: [Story points]
### Capacity Allocation
- **Feature Development**: [X]%
- **Bug Fixes**: [X]%
- **Technical Debt**: [X]%
- **Meetings/Ceremonies**: [X]%
- **Buffer**: [X]%
- id: selected-stories
name: Selected Stories
content: |
## Selected User Stories
### Committed Stories
| Story ID | Title | Points | Assignee | Dependencies |
|----------|-------|--------|----------|--------------|
| [ID] | [Title] | [Points] | [Name] | [Dependencies] |
### Total Story Points: [X]
### Story Details
#### [Story ID]: [Story Title]
- **Acceptance Criteria**:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- **Technical Considerations**: [Notes]
- **Integration Points**: [Systems/APIs]
- **Testing Strategy**: [Approach]
- id: technical-planning
name: Technical Planning
content: |
## Technical Considerations
### Architecture Impacts
- [ ] [Component/system that will be modified]
- [ ] [New integrations required]
- [ ] [Database changes needed]
### Technical Dependencies
| Dependency | Status | Owner | Due Date |
|------------|--------|-------|----------|
| [Item] | [Status] | [Name] | [Date] |
### Technical Debt Items
- [ ] [Debt item to address this sprint]
- [ ] [Refactoring opportunity]
### Performance Considerations
- [Performance impacts to monitor]
- [Optimization opportunities]
- id: risk-assessment
name: Risk Assessment
content: |
## Risk Assessment
### Identified Risks
| Risk | Probability | Impact | Mitigation Strategy | Owner |
|------|-------------|--------|---------------------|-------|
| [Risk description] | High/Med/Low | High/Med/Low | [Strategy] | [Name] |
### Dependencies on External Teams
- **Team**: [External team name]
- **Dependency**: [What we need]
- **Status**: [Current status]
- **Fallback**: [Plan B if blocked]
### Technical Risks
- [ ] [Complex integration risk]
- [ ] [Performance risk]
- [ ] [Security consideration]
- id: communication-plan
name: Communication Plan
content: |
## Communication Plan
### Sprint Ceremonies
- **Daily Standup**: [Time] @ [Location/Link]
- **Sprint Review**: [Date/Time] @ [Location/Link]
- **Retrospective**: [Date/Time] @ [Location/Link]
### Stakeholder Updates
- **Format**: [Email/Slack/Meeting]
- **Frequency**: [Daily/Weekly]
- **Recipients**: [List of stakeholders]
### Escalation Path
1. [First level - e.g., Scrum Master]
2. [Second level - e.g., Product Owner]
3. [Third level - e.g., Engineering Manager]
- id: sprint-backlog
name: Sprint Backlog
content: |
## Sprint Backlog
### Ready for Development
- [ ] [Task ready to start]
- [ ] [Another task]
### In Progress
- [ ] [Task being worked on]
### Stretch Goals
- [ ] [Additional story if capacity allows]
- [ ] [Nice-to-have feature]
### Not Selected (Documented for Next Sprint)
- [Story/task deferred with reason]
- [Another deferred item]
- id: acceptance-criteria
name: Sprint Acceptance Criteria
content: |
## Sprint Acceptance Criteria
### Must Complete
- [ ] All committed stories meet Definition of Done
- [ ] No critical bugs in production
- [ ] Memory Bank updated with sprint progress
- [ ] Dev Journals document key decisions
- [ ] All integration tests passing
### Should Complete
- [ ] Technical debt items addressed
- [ ] Documentation updated
- [ ] Performance benchmarks met
### Sprint Review Preparation
- [ ] Demo environment ready
- [ ] Demo script prepared
- [ ] Metrics collected
- [ ] Stakeholder invites sent
usage:
instructions: |
This template should be used at the beginning of each sprint during sprint planning.
1. Review previous sprint outcomes and Memory Bank context
2. Define clear, measurable sprint goals
3. Assess team capacity realistically
4. Select stories that align with goals and capacity
5. Identify and plan for risks
6. Establish clear communication plans
7. Document all decisions in Dev Journal
integration:
- memory-bank: Update activeContext.md with sprint goals
- dev-journal: Create sprint planning entry
- workflows: Referenced by sprint-execution workflow
- checklists: Links to sprint-review-checklist for end of sprint

256
bmad-core/templates/sprint-review-tmpl.yaml Normal file
View File

@ -0,0 +1,256 @@
template:
id: sprint-review-template-v1
name: Sprint Review & Retrospective
version: 1.0
output:
format: markdown
filename: docs/devJournal/{{sprint_end_date}}-sprint-review.md
title: "Sprint Review: {{sprint_start_date}} - {{sprint_end_date}}"
description: |
Template for conducting comprehensive sprint reviews and retrospectives,
capturing achievements, learnings, and action items for continuous improvement.
workflow:
mode: guided
instruction: |
Conduct a thorough sprint review by gathering metrics, reviewing achievements,
facilitating retrospective, and planning improvements. Use git commands to
gather accurate metrics before starting.
sections:
- id: header
title: Sprint Review Header
instruction: Capture sprint metadata
template: |
# Sprint Review: {{sprint_start_date}} - {{sprint_end_date}}
**Sprint Name:** {{sprint_name}}
**Sprint Goal:** {{sprint_goal}}
**Duration:** {{sprint_duration}} weeks
**Date of Review:** {{review_date}}
- id: overview
title: Sprint Overview
instruction: Summarize the sprint context
template: |
## 1. Sprint Overview
- **Sprint Dates:** {{sprint_start_date}} – {{sprint_end_date}}
- **Sprint Goal:** {{sprint_goal_detailed}}
- **Participants:** {{participants}}
- **Branch/Release:** {{branch_release}}
- id: achievements
title: Achievements & Deliverables
instruction: Document what was accomplished
template: |
## 2. Achievements & Deliverables
### Major Features Completed
{{#each features_completed}}
- {{this.feature}} ({{this.pr_link}})
{{/each}}
### Technical Milestones
{{#each technical_milestones}}
- {{this}}
{{/each}}
### Documentation Updates
{{#each documentation_updates}}
- {{this}}
{{/each}}
### Testing & Quality
- **Tests Added:** {{tests_added}}
- **Coverage Change:** {{coverage_change}}
- **Bugs Fixed:** {{bugs_fixed}}
- id: metrics
title: Sprint Metrics
instruction: Present quantitative sprint data
template: |
## 3. Sprint Metrics
| Metric | Count | Details |
|--------|-------|---------|
| Commits | {{commit_count}} | {{commit_details}} |
| PRs Merged | {{pr_count}} | {{pr_details}} |
| Issues Closed | {{issues_closed}} | {{issue_details}} |
| Story Points Completed | {{story_points}} | {{velocity_trend}} |
### Git Activity Summary
```
{{git_summary}}
```
- id: goal-review
title: Review of Sprint Goals
instruction: Assess goal completion honestly
template: |
## 4. Review of Sprint Goals
### What Was Planned
{{sprint_planned}}
### What Was Achieved
{{sprint_achieved}}
### What Was Not Completed
{{#each incomplete_items}}
- **{{this.item}}**: {{this.reason}}
{{/each}}
**Goal Completion:** {{completion_percentage}}%
- id: demo
title: Demo & Walkthrough
instruction: Provide demonstration materials if available
template: |
## 5. Demo & Walkthrough
{{#if has_screenshots}}
### Screenshots/Videos
{{demo_links}}
{{/if}}
### How to Review Features
{{review_instructions}}
- id: retrospective
title: Retrospective
instruction: Facilitate honest team reflection
template: |
## 6. Retrospective
### What Went Well 🎉
{{#each went_well}}
- {{this}}
{{/each}}
### What Didn't Go Well 😔
{{#each didnt_go_well}}
- {{this}}
{{/each}}
### What We Learned 💡
{{#each learnings}}
- {{this}}
{{/each}}
### What We'll Try Next 🚀
{{#each improvements}}
- {{this}}
{{/each}}
- id: action-items
title: Action Items & Next Steps
instruction: Define concrete improvements
template: |
## 7. Action Items & Next Steps
| Action | Owner | Deadline | Priority |
|--------|-------|----------|----------|
{{#each action_items}}
| {{this.action}} | {{this.owner}} | {{this.deadline}} | {{this.priority}} |
{{/each}}
### Next Sprint Preparation
- **Next Sprint Goal:** {{next_sprint_goal}}
- **Key Focus Areas:** {{next_focus_areas}}
- id: references
title: References
instruction: Link to supporting documentation
template: |
## 8. References
### Dev Journal Entries
{{#each dev_journals}}
- [{{this.date}}]({{this.path}}) - {{this.summary}}
{{/each}}
### ADRs Created/Updated
{{#each adrs}}
- [{{this.number}} - {{this.title}}]({{this.path}})
{{/each}}
### Other Documentation
- [CHANGELOG.md](../../CHANGELOG.md) - {{changelog_summary}}
- [Memory Bank - Progress](../memory-bank/progress.md) - Updated with sprint outcomes
- [Memory Bank - Active Context](../memory-bank/activeContext.md) - Updated with current state
---
*Sprint review conducted by {{facilitator}} on {{review_date}}*
validation:
required_fields:
- sprint_start_date
- sprint_end_date
- sprint_goal
- participants
- features_completed
- went_well
- didnt_go_well
- learnings
- action_items
prompts:
# Sprint metadata
sprint_start_date: "Sprint start date (YYYY-MM-DD)"
sprint_end_date: "Sprint end date (YYYY-MM-DD)"
sprint_name: "Sprint name or number"
sprint_goal: "Brief sprint goal"
sprint_goal_detailed: "Detailed sprint goal description"
sprint_duration: "Sprint duration in weeks"
review_date: "Date of this review"
participants: "List of sprint participants"
branch_release: "Active branches or release tags"
# Achievements
features_completed: "List major features completed with PR links"
technical_milestones: "List technical achievements"
documentation_updates: "List documentation improvements"
tests_added: "Number of tests added"
coverage_change: "Test coverage change (e.g., +5%)"
bugs_fixed: "Number of bugs fixed"
# Metrics
commit_count: "Total commits in sprint"
commit_details: "Brief summary of commit types"
pr_count: "Number of PRs merged"
pr_details: "Notable PRs"
issues_closed: "Number of issues closed"
issue_details: "Types of issues resolved"
story_points: "Story points completed"
velocity_trend: "Velocity compared to previous sprints"
git_summary: "Git log summary or statistics"
# Goal review
sprint_planned: "What was originally planned for the sprint"
sprint_achieved: "Summary of what was actually achieved"
incomplete_items: "List items not completed with reasons"
completion_percentage: "Estimated percentage of goal completion"
# Demo
has_screenshots: "Are there screenshots or videos? (true/false)"
demo_links: "Links to demo materials"
review_instructions: "How to test or review the new features"
# Retrospective
went_well: "List what went well during the sprint"
didnt_go_well: "List challenges and issues"
learnings: "List key learnings and insights"
improvements: "List experiments for next sprint"
# Action items
action_items: "List action items with owner, deadline, priority"
next_sprint_goal: "Proposed goal for next sprint"
next_focus_areas: "Key areas to focus on"
# References
dev_journals: "List relevant dev journal entries"
adrs: "List ADRs created or updated"
changelog_summary: "Brief summary of CHANGELOG updates"
facilitator: "Person facilitating this review"

24
bmad-core/templates/story-tmpl.yaml
View File

@ -12,7 +12,7 @@ workflow:
elicitation: advanced-elicitation
agent_config:
editable_sections:
editable_sections:
- Status
- Story
- Acceptance Criteria
@ -29,7 +29,7 @@ sections:
instruction: Select the current status of the story
owner: scrum-master
editors: [scrum-master, dev-agent]
- id: story
title: Story
type: template-text
@ -41,7 +41,7 @@ sections:
elicit: true
owner: scrum-master
editors: [scrum-master]
- id: acceptance-criteria
title: Acceptance Criteria
type: numbered-list
@ -49,7 +49,7 @@ sections:
elicit: true
owner: scrum-master
editors: [scrum-master]
- id: tasks-subtasks
title: Tasks / Subtasks
type: bullet-list
@ -66,7 +66,7 @@ sections:
elicit: true
owner: scrum-master
editors: [scrum-master, dev-agent]
- id: dev-notes
title: Dev Notes
instruction: |
@ -90,7 +90,7 @@ sections:
elicit: true
owner: scrum-master
editors: [scrum-master]
- id: change-log
title: Change Log
type: table
@ -98,7 +98,7 @@ sections:
instruction: Track changes made to this story document
owner: scrum-master
editors: [scrum-master, dev-agent, qa-agent]
- id: dev-agent-record
title: Dev Agent Record
instruction: This section is populated by the development agent during implementation
@ -111,27 +111,27 @@ sections:
instruction: Record the specific AI agent model and version used for development
owner: dev-agent
editors: [dev-agent]
- id: debug-log-references
title: Debug Log References
instruction: Reference any debug logs or traces generated during development
owner: dev-agent
editors: [dev-agent]
- id: completion-notes
title: Completion Notes List
instruction: Notes about the completion of tasks and any issues encountered
owner: dev-agent
editors: [dev-agent]
- id: file-list
title: File List
instruction: List all files created, modified, or affected during story implementation
owner: dev-agent
editors: [dev-agent]
- id: qa-results
title: QA Results
instruction: Results from QA Agent QA review of the completed story implementation
owner: qa-agent
editors: [qa-agent]
editors: [qa-agent]

2
bmad-core/templates/systemPatterns-tmpl.yaml
View File

@ -242,4 +242,4 @@ prompts:
sli_slo: "Service level indicators and objectives"
log_levels: "When to use each log level"
structured_logging_format: "Log format and fields"
log_retention: "How long are logs kept?"
log_retention: "How long are logs kept?"

2
bmad-core/templates/techContext-tmpl.yaml
View File

@ -261,4 +261,4 @@ prompts:
db_maintenance_tasks: "Database maintenance tasks"
log_rotation_policy: "Log rotation policy"
monitoring_alerts: "List monitoring alerts with thresholds"
limitations: "List known limitations and workarounds"
limitations: "List known limitations and workarounds"

92
bmad-core/user-guide.md
View File

@ -238,6 +238,98 @@ You will want to verify from sharding your architecture that these documents exi
As your project grows and the code starts to build consistent patterns, coding standards should be reduced to just the items that the agent makes mistakes at still - must with the better models, they will look at surrounding code in files and not need a rule from that file to guide them.
## Enhanced BMad Features
### Session Kickoff Protocol
Every new AI session should begin with proper context initialization:
```mermaid
graph TD
A[New Session Start] --> B[bmad-master: session-kickoff]
B --> C[Review Memory Bank]
C --> D[Check Dev Journals]
D --> E[Review Recent ADRs]
E --> F[Load Technical Principles]
F --> G[Session Ready]
style A fill:#f5f5f5
style B fill:#FF6B6B
style C fill:#DDA0DD
style D fill:#FFE4B5
style E fill:#ADD8E6
style F fill:#98FB98
style G fill:#90EE90
```
**When to use**: Start of any new session, after 24+ hour gaps, or when switching contexts.
### Memory Bank Pattern
The Memory Bank provides persistent context across AI sessions:
- **Location**: `docs/memory-bank/`
- **Core Files**:
- `projectbrief.md` - Project foundation and goals
- `productContext.md` - User needs and problems
- `systemPatterns.md` - Architecture and patterns
- `techContext.md` - Technology stack
- `activeContext.md` - Current work state
- `progress.md` - Completed features and status
**Integration**: All agents automatically reference Memory Bank during session kickoff.
### Development Journals
Track session work and decisions:
- **Location**: `docs/devJournal/`
- **Format**: `YYYYMMDD-NN.md` (e.g., `20240115-01.md`)
- **Created**: After significant work sessions
- **Contents**: Work completed, decisions made, challenges faced
### Architectural Decision Records (ADRs)
Document significant technical decisions:
- **Location**: `docs/adr/`
- **Format**: Michael Nygard ADR format
- **Triggers**: Major architecture changes, new patterns, technology choices
- **Integration**: Automatically referenced in Memory Bank
### Sprint Ceremonies
BMad now includes full sprint support:
1. **Sprint Planning**: Integrated into all workflows after validation
2. **Daily Development**: Tracked through dev journals
3. **Sprint Review**: Comprehensive review using `sprint-review-checklist.md`
4. **Retrospectives**: Optional but recommended for continuous improvement
### New Specialized Workflows
Beyond the standard development workflows, BMad now includes:
- **sprint-execution.yaml**: Full sprint-based agile development
- **quick-fix.yaml**: Streamlined hotfix process
- **technical-debt.yaml**: Systematic debt reduction
- **documentation-update.yaml**: Documentation maintenance
- **system-migration.yaml**: Platform and technology migrations
- **performance-optimization.yaml**: Performance improvement cycles
### Quality Gates
All workflows now include 8-step validation:
1. Syntax validation
2. Type checking
3. Linting
4. Security scanning
5. Test execution
6. Performance validation
7. Documentation checks
8. Integration testing
## Getting Help
- **Discord Community**: [Join Discord](https://discord.gg/gk8jAdXWmj)

83
bmad-core/workflows/brownfield-fullstack.yaml
View File

@ -12,6 +12,18 @@ workflow:
- integration-enhancement
sequence:
- step: session_initialization
agent: bmad-master
action: session_kickoff
uses: session-kickoff
notes: |
Initialize AI session context:
- Review Memory Bank if exists
- Understand project state and technical principles
- Check recent dev journals and ADRs
- Review sprint context if applicable
Required for new sessions or after 24+ hour gaps
- step: enhancement_classification
agent: analyst
action: classify enhancement scope
@ -20,7 +32,7 @@ workflow:
- Single story (< 4 hours) → Use brownfield-create-story task
- Small feature (1-3 stories) → Use brownfield-create-epic task
- Major enhancement (multiple epics) → Continue with full workflow
Ask user: "Can you describe the enhancement scope? Is this a small fix, a feature addition, or a major enhancement requiring architectural changes?"
- step: routing_decision
@ -93,6 +105,17 @@ workflow:
condition: po_checklist_issues
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
- step: sprint_planning_check
agent: sm
action: verify_sprint_context
condition: development_ready
notes: |
If part of sprint:
- Align with sprint goals
- Update sprint backlog
- Plan for sprint review
- Create ADRs for significant decisions
- agent: po
action: shard_documents
creates: sharded_docs
@ -159,6 +182,19 @@ workflow:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
- agent: dev
creates: dev_journal_entry
action: document_session_work
uses: create-dev-journal
condition: significant_work_completed
notes: |
Create dev journal for:
- Major feature completion
- Complex problem solutions
- Architectural decisions (trigger ADR creation)
- End of work session
Updates Memory Bank activeContext
- repeat_development_cycle:
action: continue_for_all_stories
notes: |
@ -176,18 +212,32 @@ workflow:
- Validate epic was completed correctly
- Document learnings and improvements
- agent: sm
action: conduct_sprint_review
uses: conduct-sprint-review
condition: sprint_boundary
notes: |
At sprint end:
- Review accomplishments using sprint-review-checklist
- Document learnings and technical decisions
- Update Memory Bank comprehensively
- Create sprint summary documentation
- Plan next sprint priorities
- workflow_end:
action: project_complete
notes: |
All stories implemented and reviewed!
Project development phase complete.
Memory Bank and documentation updated.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |
```mermaid
graph TD
A[Start: Brownfield Enhancement] --> B[analyst: classify enhancement scope]
A[Start: Brownfield Enhancement] --> A1[bmad-master: session kickoff]
A1 --> B[analyst: classify enhancement scope]
B --> C{Enhancement Size?}
C -->|Single Story| D[pm: brownfield-create-story]
@ -209,8 +259,9 @@ workflow:
L --> M{PO finds issues?}
M -->|Yes| N[Fix issues]
M -->|No| O[po: shard documents]
M -->|No| SP[sm: sprint planning]
N --> L
SP --> O[po: shard documents]
O --> P[sm: create story]
P --> Q{Story Type?}
@ -231,10 +282,14 @@ workflow:
Z -->|No| Y
AA --> X
Y -->|Yes| P
Y -->|No| AB{Retrospective?}
Y -->|No| DJ[dev: dev journal]
DJ --> AB{Retrospective?}
AB -->|Yes| AC[po: retrospective]
AB -->|No| AD[Complete]
AC --> AD
AB -->|No| SR{Sprint boundary?}
AC --> SR
SR -->|Yes| SRV[sm: sprint review]
SR -->|No| AD[Complete]
SRV --> AD
style AD fill:#90EE90
style END1 fill:#90EE90
@ -265,33 +320,33 @@ workflow:
{{if single_story}}: Proceeding with brownfield-create-story task for immediate implementation.
{{if small_feature}}: Creating focused epic with brownfield-create-epic task.
{{if major_enhancement}}: Continuing with comprehensive planning workflow.
documentation_assessment: |
Documentation assessment complete:
{{if adequate}}: Existing documentation is sufficient. Proceeding directly to PRD creation.
{{if inadequate}}: Running document-project to capture current system state before PRD.
document_project_to_pm: |
Project analysis complete. Key findings documented in:
- {{document_list}}
Use these findings to inform PRD creation and avoid re-analyzing the same aspects.
pm_to_architect_decision: |
PRD complete and saved as docs/prd.md.
Architectural changes identified: {{yes/no}}
{{if yes}}: Proceeding to create architecture document for: {{specific_changes}}
{{if no}}: No architectural changes needed. Proceeding to validation.
architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for integration safety."
po_to_sm: |
All artifacts validated.
Documentation type available: {{sharded_prd / brownfield_docs}}
{{if sharded}}: Use standard create-next-story task.
{{if brownfield}}: Use create-brownfield-story task to handle varied documentation formats.
sm_story_creation: |
Creating story from {{documentation_type}}.
{{if missing_context}}: May need to gather additional context from user during story creation.
complete: "All planning artifacts validated and development can begin. Stories will be created based on available documentation format."

69
bmad-core/workflows/brownfield-service.yaml
View File

@ -13,6 +13,18 @@ workflow:
- integration-enhancement
sequence:
- step: session_initialization
agent: bmad-master
action: session_kickoff
uses: session-kickoff
notes: |
Initialize AI session context:
- Review Memory Bank if exists
- Understand service architecture and dependencies
- Check recent dev journals and ADRs
- Review technical principles and patterns
Required for new sessions or after 24+ hour gaps
- step: service_analysis
agent: architect
action: analyze existing project and use task document-project
@ -41,6 +53,17 @@ workflow:
condition: po_checklist_issues
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
- step: sprint_planning_check
agent: sm
action: verify_sprint_context
condition: development_ready
notes: |
If part of sprint:
- Align service enhancements with sprint goals
- Update sprint backlog
- Plan for sprint review
- Create ADRs for API changes
- agent: po
action: shard_documents
creates: sharded_docs
@ -105,6 +128,19 @@ workflow:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
- agent: dev
creates: dev_journal_entry
action: document_session_work
uses: create-dev-journal
condition: significant_work_completed
notes: |
Create dev journal for:
- API changes and integration updates
- Performance improvements
- Service architecture decisions (trigger ADR)
- End of work session
Updates Memory Bank systemPatterns
- repeat_development_cycle:
action: continue_for_all_stories
notes: |
@ -122,25 +158,40 @@ workflow:
- Validate epic was completed correctly
- Document learnings and improvements
- agent: sm
action: conduct_sprint_review
uses: conduct-sprint-review
condition: sprint_boundary
notes: |
At sprint end:
- Review service enhancements and API changes
- Document performance improvements
- Update Memory Bank with architectural decisions
- Create sprint summary with metrics
- Plan next sprint priorities
- workflow_end:
action: project_complete
notes: |
All stories implemented and reviewed!
Project development phase complete.
Service development phase complete.
Memory Bank and API documentation updated.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |
```mermaid
graph TD
A[Start: Service Enhancement] --> B[analyst: analyze existing service]
A[Start: Service Enhancement] --> A1[bmad-master: session kickoff]
A1 --> B[architect: analyze existing service]
B --> C[pm: prd.md]
C --> D[architect: architecture.md]
D --> E[po: validate with po-master-checklist]
E --> F{PO finds issues?}
F -->|Yes| G[Return to relevant agent for fixes]
F -->|No| H[po: shard documents]
F -->|No| SP[sm: sprint planning]
G --> E
SP --> H[po: shard documents]
H --> I[sm: create story]
I --> J{Review draft story?}
@ -155,10 +206,14 @@ workflow:
P -->|No| O
Q --> N
O -->|Yes| I
O -->|No| R{Epic retrospective?}
O -->|No| DJ[dev: dev journal]
DJ --> R{Epic retrospective?}
R -->|Yes| S[po: epic retrospective]
R -->|No| T[Project Complete]
S --> T
R -->|No| SR{Sprint boundary?}
S --> SR
SR -->|Yes| SRV[sm: sprint review]
SR -->|No| T[Project Complete]
SRV --> T
style T fill:#90EE90
style H fill:#ADD8E6

72
bmad-core/workflows/brownfield-ui.yaml
View File

@ -12,6 +12,18 @@ workflow:
- frontend-enhancement
sequence:
- step: session_initialization
agent: bmad-master
action: session_kickoff
uses: session-kickoff
notes: |
Initialize AI session context:
- Review Memory Bank if exists
- Understand project state and technical principles
- Check recent dev journals and ADRs
- Review sprint context if applicable
Required for new sessions or after 24+ hour gaps
- step: ui_analysis
agent: architect
action: analyze existing project and use task document-project
@ -48,6 +60,17 @@ workflow:
condition: po_checklist_issues
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
- step: sprint_planning_check
agent: sm
action: verify_sprint_context
condition: development_ready
notes: |
If part of sprint:
- Align with sprint goals
- Update sprint backlog
- Plan for sprint review
- Create ADRs for significant UI/UX decisions
- agent: po
action: shard_documents
creates: sharded_docs
@ -112,6 +135,19 @@ workflow:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
- agent: dev
creates: dev_journal_entry
action: document_session_work
uses: create-dev-journal
condition: significant_work_completed
notes: |
Create dev journal for:
- Major UI component completion
- Complex frontend problem solutions
- UI/UX architectural decisions (trigger ADR creation)
- End of work session
Updates Memory Bank activeContext
- repeat_development_cycle:
action: continue_for_all_stories
notes: |
@ -129,26 +165,40 @@ workflow:
- Validate epic was completed correctly
- Document learnings and improvements
- agent: sm
action: conduct_sprint_review
uses: conduct-sprint-review
condition: sprint_boundary
notes: |
At sprint end:
- Review UI enhancement accomplishments using sprint-review-checklist
- Document UI/UX learnings and design decisions
- Update Memory Bank comprehensively
- Create sprint summary documentation
- Plan next sprint UI priorities
- workflow_end:
action: project_complete
notes: |
All stories implemented and reviewed!
Project development phase complete.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |
```mermaid
graph TD
A[Start: UI Enhancement] --> B[analyst: analyze existing UI]
A[Start: UI Enhancement] --> A1[bmad-master: session kickoff]
A1 --> B[analyst: analyze existing UI]
B --> C[pm: prd.md]
C --> D[ux-expert: front-end-spec.md]
D --> E[architect: architecture.md]
E --> F[po: validate with po-master-checklist]
F --> G{PO finds issues?}
G -->|Yes| H[Return to relevant agent for fixes]
G -->|No| I[po: shard documents]
G -->|No| SP[sm: sprint planning]
H --> F
SP --> I[po: shard documents]
I --> J[sm: create story]
J --> K{Review draft story?}
@ -157,16 +207,20 @@ workflow:
L --> M
M --> N{QA review?}
N -->|Yes| O[qa: review implementation]
N -->|No| P{More stories?}
N -->|No| DJ[dev: dev journal]
O --> Q{QA found issues?}
Q -->|Yes| R[dev: address QA feedback]
Q -->|No| P
Q -->|No| DJ
R --> O
DJ --> P{More stories?}
P -->|Yes| J
P -->|No| S{Epic retrospective?}
S -->|Yes| T[po: epic retrospective]
S -->|No| U[Project Complete]
T --> U
S -->|No| SR{Sprint boundary?}
T --> SR
SR -->|Yes| SRV[sm: sprint review]
SR -->|No| U[Project Complete]
SRV --> U
style U fill:#90EE90
style I fill:#ADD8E6
@ -178,6 +232,10 @@ workflow:
style L fill:#F0E68C
style O fill:#F0E68C
style T fill:#F0E68C
style A1 fill:#E6E6FA
style SP fill:#E6E6FA
style DJ fill:#E6E6FA
style SRV fill:#E6E6FA
```
decision_guidance:

287
bmad-core/workflows/documentation-update.yaml Normal file
View File

@ -0,0 +1,287 @@
workflow:
id: documentation-update
name: Documentation Update Workflow
description: >-
Agent workflow for systematic documentation creation and updates. Handles
API documentation, user guides, architectural documentation, and knowledge
base maintenance with focus on accuracy and completeness.
type: documentation
project_types:
- api-documentation
- user-guides
- developer-docs
- architecture-docs
- knowledge-base
sequence:
- step: session_initialization
agent: bmad-master
action: session_kickoff
uses: session-kickoff
notes: |
Documentation context initialization:
- Review Memory Bank for current state
- Check existing documentation
- Understand system architecture
- Review recent changes
- Identify documentation standards
- agent: analyst
action: documentation_audit
creates: doc-audit-report.md
notes: |
Comprehensive documentation audit:
- Inventory existing documentation
- Identify gaps and outdated content
- Check accuracy against current code
- Review user feedback on docs
- Assess documentation coverage
- List priority areas
- agent: pm
action: documentation_planning
creates: doc-update-plan.md
requires: doc-audit-report.md
notes: |
Create documentation plan:
- Prioritize documentation needs
- Define target audiences
- Set documentation standards
- Create content outline
- Estimate effort required
- Plan review cycles
- agent: architect
action: technical_content_planning
creates: technical-doc-outline.md
condition: technical_documentation
notes: |
Technical documentation planning:
- Architecture diagrams needed
- API specifications to document
- Integration guides required
- Performance documentation
- Security documentation
- Deployment guides
- agent: ux-expert
action: user_documentation_planning
creates: user-doc-outline.md
condition: user_documentation
notes: |
User documentation planning:
- User journey mapping
- Tutorial structure
- FAQ compilation
- Troubleshooting guides
- Quick start guides
- Video script outlines
- agent: po
validates: documentation_plan
notes: |
Validate documentation approach:
- Confirm priorities align
- Approve resource allocation
- Sign off on timelines
- Verify compliance needs
- documentation_cycle:
repeats: for_each_doc_section
sequence:
- agent: scribe
action: create_documentation
creates: documentation_files
notes: |
Content creation:
- Write clear, concise content
- Follow style guide
- Include code examples
- Add diagrams where helpful
- Ensure accuracy
- Consider localization
- agent: architect
action: technical_review
validates: technical_accuracy
condition: technical_content
notes: |
Technical validation:
- Verify code examples work
- Check API accuracy
- Validate architecture diagrams
- Ensure version compatibility
- Review security implications
- agent: qa
action: documentation_testing
validates: documentation_usability
notes: |
Documentation QA:
- Test all code examples
- Verify links work
- Check formatting
- Validate screenshots
- Test tutorials end-to-end
- Accessibility review
- agent: mentor
action: educational_review
validates: learning_effectiveness
optional: true
notes: |
Educational quality:
- Check clarity for beginners
- Verify learning progression
- Assess completeness
- Review examples
- Suggest improvements
- agent: scribe
action: create_documentation_index
creates: documentation-index.md
notes: |
Create navigation aids:
- Table of contents
- Cross-references
- Search keywords
- Category tags
- Version mapping
- Related resources
- agent: dev
action: integrate_documentation
updates: project_documentation
notes: |
Documentation integration:
- Update README files
- Link from code comments
- Update help systems
- Deploy to doc sites
- Configure search
- Set up redirects
- agent: scribe
creates: dev_journal_entry
action: document_doc_updates
uses: create-dev-journal
notes: |
Document the documentation:
- What was updated and why
- Major changes made
- Known gaps remaining
- Feedback incorporated
- Update Memory Bank
- agent: po
action: documentation_acceptance
validates: final_documentation
notes: |
Final documentation review:
- Verify completeness
- Check quality standards
- Approve for publication
- Sign off on release
- agent: sm
action: documentation_release
creates: doc-release-notes.md
notes: |
Documentation release:
- Publish updates
- Notify stakeholders
- Update version notes
- Plan maintenance cycle
- Schedule next review
- workflow_end:
action: documentation_complete
notes: |
Documentation updated!
- All sections complete
- Quality validated
- Published and indexed
- Memory Bank updated
- Maintenance scheduled
flow_diagram: |
```mermaid
graph TD
A[Start: Documentation] --> B[bmad-master: session init]
B --> C[analyst: audit docs]
C --> D[pm: create plan]
D --> E{Technical docs?}
E -->|Yes| F[architect: tech outline]
E -->|No| G{User docs?}
F --> G
G -->|Yes| H[ux-expert: user outline]
G -->|No| I[po: validate plan]
H --> I
I --> J[Documentation Cycle]
J --> K[scribe: create content]
K --> L{Technical content?}
L -->|Yes| M[architect: tech review]
L -->|No| N[qa: test docs]
M --> N
N --> O{Educational review?}
O -->|Yes| P[mentor: review]
O -->|No| Q{More sections?}
P --> Q
Q -->|Yes| J
Q -->|No| R[scribe: create index]
R --> S[dev: integrate docs]
S --> T[scribe: document updates]
T --> U[po: final acceptance]
U --> V[sm: release docs]
V --> W[Documentation Complete]
style W fill:#90EE90
style B fill:#DDA0DD
style K fill:#FFE4B5
style M fill:#ADD8E6
style N fill:#ADD8E6
style T fill:#FFE4B5
style V fill:#98FB98
```
decision_guidance:
when_to_use:
- Major feature releases
- API changes
- User complaints about docs
- Onboarding difficulties
- Compliance requirements
- Regular documentation maintenance
handoff_prompts:
audit_complete: |
Documentation audit complete:
- Total pages: {{page_count}}
- Outdated sections: {{outdated_count}}
- Missing topics: {{gap_count}}
- Priority updates: {{priority_count}}
plan_ready: |
Documentation plan created:
- Sections to update: {{section_count}}
- New content needed: {{new_count}} pages
- Estimated effort: {{effort_hours}} hours
- Target completion: {{target_date}}
section_complete: |
Documentation section "{{section_name}}" complete:
- Pages created/updated: {{page_count}}
- Code examples: {{example_count}}
- Diagrams added: {{diagram_count}}
- Review status: {{review_status}}
release_ready: |
Documentation release ready:
- Total updates: {{update_count}}
- Quality score: {{quality_score}}/100
- Coverage improvement: {{coverage_increase}}%
- Ready for publication
complete: "Documentation update complete. {{total_pages}} pages updated. Next review scheduled for {{next_review_date}}."

72
bmad-core/workflows/greenfield-fullstack.yaml
View File

@ -13,6 +13,18 @@ workflow:
- mvp
sequence:
- step: session_initialization
agent: bmad-master
action: session_kickoff
uses: session-kickoff
notes: |
Initialize AI session context:
- Review Memory Bank if exists
- Understand project state and technical principles
- Check recent dev journals and ADRs
- Review sprint context if applicable
Required for new sessions or after 24+ hour gaps
- agent: analyst
creates: project-brief.md
optional_steps:
@ -64,6 +76,17 @@ workflow:
condition: po_checklist_issues
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
- step: sprint_planning_check
agent: sm
action: verify_sprint_context
condition: development_ready
notes: |
If part of sprint:
- Align with sprint goals
- Update sprint backlog
- Plan for sprint review
- Create ADRs for significant architectural decisions
- project_setup_guidance:
action: guide_project_structure
condition: user_has_generated_ui
@ -137,6 +160,19 @@ workflow:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
- agent: dev
creates: dev_journal_entry
action: document_session_work
uses: create-dev-journal
condition: significant_work_completed
notes: |
Create dev journal for:
- Major full-stack feature completion
- Complex integration solutions
- Architectural decisions (trigger ADR creation)
- End of work session
Updates Memory Bank activeContext
- repeat_development_cycle:
action: continue_for_all_stories
notes: |
@ -154,18 +190,31 @@ workflow:
- Validate epic was completed correctly
- Document learnings and improvements
- agent: sm
action: conduct_sprint_review
uses: conduct-sprint-review
condition: sprint_boundary
notes: |
At sprint end:
- Review full-stack accomplishments using sprint-review-checklist
- Document integration learnings and technical decisions
- Update Memory Bank comprehensively
- Create sprint summary documentation
- Plan next sprint priorities
- workflow_end:
action: project_complete
notes: |
All stories implemented and reviewed!
Project development phase complete.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |
```mermaid
graph TD
A[Start: Greenfield Project] --> B[analyst: project-brief.md]
A[Start: Greenfield Project] --> A1[bmad-master: session kickoff]
A1 --> B[analyst: project-brief.md]
B --> C[pm: prd.md]
C --> D[ux-expert: front-end-spec.md]
D --> D2{Generate v0 prompt?}
@ -179,8 +228,9 @@ workflow:
G --> H
H --> I{PO finds issues?}
I -->|Yes| J[Return to relevant agent for fixes]
I -->|No| K[po: shard documents]
I -->|No| SP[sm: sprint planning]
J --> H
SP --> K[po: shard documents]
K --> L[sm: create story]
L --> M{Review draft story?}
@ -189,16 +239,20 @@ workflow:
N --> O
O --> P{QA review?}
P -->|Yes| Q[qa: review implementation]
P -->|No| R{More stories?}
P -->|No| DJ[dev: dev journal]
Q --> S{QA found issues?}
S -->|Yes| T[dev: address QA feedback]
S -->|No| R
S -->|No| DJ
T --> Q
DJ --> R{More stories?}
R -->|Yes| L
R -->|No| U{Epic retrospective?}
U -->|Yes| V[po: epic retrospective]
U -->|No| W[Project Complete]
V --> W
U -->|No| SR{Sprint boundary?}
V --> SR
SR -->|Yes| SRV[sm: sprint review]
SR -->|No| W[Project Complete]
SRV --> W
B -.-> B1[Optional: brainstorming]
B -.-> B2[Optional: market research]
@ -218,6 +272,10 @@ workflow:
style N fill:#F0E68C
style Q fill:#F0E68C
style V fill:#F0E68C
style A1 fill:#E6E6FA
style SP fill:#E6E6FA
style DJ fill:#E6E6FA
style SRV fill:#E6E6FA
```
decision_guidance:

50
bmad-core/workflows/greenfield-service.yaml
View File

@ -14,6 +14,18 @@ workflow:
- simple-service
sequence:
- step: session_initialization
agent: bmad-master
action: session_kickoff
uses: session-kickoff
notes: |
Initialize AI session context:
- Review Memory Bank if exists
- Understand project state and technical principles
- Check recent dev journals and ADRs
- Review sprint context if applicable
Required for new sessions or after 24+ hour gaps
- agent: analyst
creates: project-brief.md
optional_steps:
@ -49,6 +61,17 @@ workflow:
condition: po_checklist_issues
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
- step: sprint_planning_check
agent: sm
action: verify_sprint_context
condition: development_ready
notes: |
If part of sprint:
- Align with sprint goals
- Update sprint backlog
- Plan for sprint review
- Create ADRs for significant API/service decisions
- agent: po
action: shard_documents
creates: sharded_docs
@ -113,6 +136,19 @@ workflow:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
- agent: dev
creates: dev_journal_entry
action: document_session_work
uses: create-dev-journal
condition: significant_work_completed
notes: |
Create dev journal for:
- Major API/service endpoint completion
- Complex backend problem solutions
- Service architectural decisions (trigger ADR creation)
- End of work session
Updates Memory Bank activeContext
- repeat_development_cycle:
action: continue_for_all_stories
notes: |
@ -130,12 +166,24 @@ workflow:
- Validate epic was completed correctly
- Document learnings and improvements
- agent: sm
action: conduct_sprint_review
uses: conduct-sprint-review
condition: sprint_boundary
notes: |
At sprint end:
- Review service/API accomplishments using sprint-review-checklist
- Document backend learnings and technical decisions
- Update Memory Bank comprehensively
- Create sprint summary documentation
- Plan next sprint service priorities
- workflow_end:
action: project_complete
notes: |
All stories implemented and reviewed!
Service development phase complete.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |

69
bmad-core/workflows/greenfield-ui.yaml
View File

@ -14,6 +14,18 @@ workflow:
- simple-interface
sequence:
- step: session_initialization
agent: bmad-master
action: session_kickoff
uses: session-kickoff
notes: |
Initialize AI session context:
- Review Memory Bank if exists
- Understand project state and technical principles
- Check recent dev journals and ADRs
- Review sprint context if applicable
Required for new sessions or after 24+ hour gaps
- agent: analyst
creates: project-brief.md
optional_steps:
@ -68,6 +80,17 @@ workflow:
condition: user_has_generated_ui
notes: "If user generated UI with v0/Lovable: For polyrepo setup, place downloaded project in separate frontend repo. For monorepo, place in apps/web or frontend/ directory. Review architecture document for specific guidance."
- step: sprint_planning_check
agent: sm
action: verify_sprint_context
condition: development_ready
notes: |
If part of sprint:
- Align UI development with sprint goals
- Update sprint backlog
- Plan for sprint review
- Create ADRs for significant UI decisions
- agent: po
action: shard_documents
creates: sharded_docs
@ -132,6 +155,19 @@ workflow:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
- agent: dev
creates: dev_journal_entry
action: document_session_work
uses: create-dev-journal
condition: significant_work_completed
notes: |
Create dev journal for:
- UI component completion
- Complex frontend solutions
- Design pattern decisions (trigger ADR)
- End of work session
Updates Memory Bank activeContext
- repeat_development_cycle:
action: continue_for_all_stories
notes: |
@ -149,18 +185,32 @@ workflow:
- Validate epic was completed correctly
- Document learnings and improvements
- agent: sm
action: conduct_sprint_review
uses: conduct-sprint-review
condition: sprint_boundary
notes: |
At sprint end:
- Review UI components and features delivered
- Document design decisions and patterns
- Update Memory Bank with UI patterns
- Create sprint summary with visual samples
- Plan next sprint UI priorities
- workflow_end:
action: project_complete
notes: |
All stories implemented and reviewed!
Project development phase complete.
UI development phase complete.
Memory Bank and design documentation updated.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |
```mermaid
graph TD
A[Start: UI Development] --> B[analyst: project-brief.md]
A[Start: UI Development] --> A1[bmad-master: session kickoff]
A1 --> B[analyst: project-brief.md]
B --> C[pm: prd.md]
C --> D[ux-expert: front-end-spec.md]
D --> D2{Generate v0 prompt?}
@ -174,8 +224,9 @@ workflow:
G --> H
H --> I{PO finds issues?}
I -->|Yes| J[Return to relevant agent for fixes]
I -->|No| K[po: shard documents]
I -->|No| SP[sm: sprint planning]
J --> H
SP --> K[po: shard documents]
K --> L[sm: create story]
L --> M{Review draft story?}
@ -190,10 +241,14 @@ workflow:
S -->|No| R
T --> Q
R -->|Yes| L
R -->|No| U{Epic retrospective?}
R -->|No| DJ[dev: dev journal]
DJ --> U{Epic retrospective?}
U -->|Yes| V[po: epic retrospective]
U -->|No| W[Project Complete]
V --> W
U -->|No| SR{Sprint boundary?}
V --> SR
SR -->|Yes| SRV[sm: sprint review]
SR -->|No| W[Project Complete]
SRV --> W
B -.-> B1[Optional: brainstorming]
B -.-> B2[Optional: market research]

300
bmad-core/workflows/performance-optimization.yaml Normal file
View File

@ -0,0 +1,300 @@
workflow:
id: performance-optimization
name: Performance Optimization Workflow
description: >-
Agent workflow for systematic performance improvements. Focuses on identifying
bottlenecks, implementing optimizations, and validating improvements through
benchmarking and monitoring.
type: optimization
project_types:
- performance-tuning
- scalability-improvement
- response-time-optimization
- resource-optimization
- throughput-enhancement
sequence:
- step: session_initialization
agent: bmad-master
action: session_kickoff
uses: session-kickoff
notes: |
Performance-focused initialization:
- Review Memory Bank for known issues
- Check previous optimization efforts
- Review performance requirements
- Understand system architecture
- Check monitoring setup
- agent: architect
action: performance_assessment
creates: performance-baseline.md
notes: |
Establish performance baseline:
- Current performance metrics
- Resource utilization patterns
- Response time distribution
- Throughput measurements
- Error rates
- User experience metrics
- agent: analyst
action: bottleneck_analysis
creates: bottleneck-analysis.md
requires: performance-baseline.md
notes: |
Identify performance bottlenecks:
- Profile application code
- Analyze database queries
- Review network latency
- Check resource constraints
- Identify hot paths
- Memory leak detection
- agent: architect
action: optimization_strategy
creates: optimization-strategy.md
requires: bottleneck-analysis.md
notes: |
Design optimization approach:
- Quick wins identification
- Architectural improvements
- Caching strategies
- Query optimization plans
- Resource scaling options
- Code optimization targets
- agent: pm
creates: optimization-plan.md
action: prioritize_optimizations
requires: optimization-strategy.md
notes: |
Create optimization plan:
- Impact vs effort matrix
- Implementation sequence
- Performance targets
- Risk assessment
- Testing requirements
- Rollback procedures
- agent: po
validates: optimization_plan
notes: |
Validate approach:
- Confirm performance goals
- Approve resource usage
- Accept risk levels
- Sign off on timeline
- agent: dev
action: setup_benchmarks
creates: benchmark-suite/
notes: |
Create benchmark suite:
- Micro-benchmarks for hot paths
- Load testing scenarios
- Real-world usage patterns
- Stress test configurations
- Monitoring dashboards
- Automated performance tests
- optimization_cycle:
repeats: for_each_optimization
sequence:
- agent: dev
action: implement_optimization
updates: optimized_code
notes: |
Careful implementation:
- Apply optimization
- Maintain functionality
- Add performance tests
- Document changes
- Update monitoring
- agent: qa
action: performance_testing
validates: optimization_impact
notes: |
Comprehensive testing:
- Run benchmark suite
- Load testing
- Stress testing
- Regression testing
- Real-world scenarios
- Monitor resource usage
- agent: analyst
action: measure_improvement
creates: improvement-metrics.md
notes: |
Quantify improvements:
- Before/after comparison
- Statistical significance
- Resource usage delta
- Cost analysis
- User impact assessment
- agent: architect
creates: adr.md
action: document_optimization
condition: significant_change
notes: |
Document decisions:
- Optimization rationale
- Trade-offs made
- Implementation details
- Performance gains
- Side effects
- agent: dev
action: production_monitoring
updates: monitoring_configuration
notes: |
Enhanced monitoring:
- Add performance metrics
- Set up alerts
- Create dashboards
- Configure profiling
- Enable tracing
- Set SLO targets
- agent: dev
creates: dev_journal_entry
action: document_optimizations
uses: create-dev-journal
notes: |
Document optimization work:
- Optimizations applied
- Performance improvements
- Lessons learned
- Monitoring setup
- Update Memory Bank
- agent: analyst
action: final_performance_report
creates: performance-report.md
notes: |
Comprehensive performance report:
- Overall improvements
- Individual optimization impacts
- Resource usage changes
- Cost implications
- User experience improvements
- Recommendations
- agent: sm
action: optimization_review
uses: conduct-sprint-review
creates: optimization-review.md
notes: |
Review optimization results:
- Present improvements
- Demonstrate benchmarks
- Show monitoring dashboards
- Discuss next steps
- Plan maintenance
- agent: architect
action: update_performance_docs
updates: architecture_documentation
notes: |
Update documentation:
- Performance characteristics
- Scaling guidelines
- Optimization patterns
- Monitoring requirements
- Troubleshooting guides
- workflow_end:
action: optimization_complete
notes: |
Performance optimization complete!
- Targets achieved
- Monitoring active
- Documentation updated
- Team trained
- Maintenance planned
flow_diagram: |
```mermaid
graph TD
A[Start: Performance] --> B[bmad-master: session init]
B --> C[architect: baseline assessment]
C --> D[analyst: bottleneck analysis]
D --> E[architect: optimization strategy]
E --> F[pm: prioritize optimizations]
F --> G[po: validate plan]
G --> H[dev: setup benchmarks]
H --> I[Optimization Cycle]
I --> J[dev: implement optimization]
J --> K[qa: performance testing]
K --> L[analyst: measure improvement]
L --> M{Significant change?}
M -->|Yes| N[architect: create ADR]
M -->|No| O{More optimizations?}
N --> O
O -->|Yes| I
O -->|No| P[dev: production monitoring]
P --> Q[dev: document work]
Q --> R[analyst: final report]
R --> S[sm: optimization review]
S --> T[architect: update docs]
T --> U[Optimization Complete]
style U fill:#90EE90
style B fill:#DDA0DD
style C fill:#FFB6C1
style D fill:#FFB6C1
style L fill:#98FB98
style K fill:#FFA500
style R fill:#98FB98
style S fill:#ADD8E6
```
decision_guidance:
when_to_use:
- User complaints about speed
- System not meeting SLOs
- Scaling issues
- High infrastructure costs
- Before major traffic events
- Regular performance maintenance
handoff_prompts:
baseline_complete: |
Performance baseline established:
- P95 response time: {{p95_response}}ms
- Throughput: {{throughput}} req/s
- Error rate: {{error_rate}}%
- Resource usage: CPU {{cpu}}%, Memory {{memory}}%
bottlenecks_found: |
Top bottlenecks identified:
1. {{bottleneck_1}}: {{impact_1}}% impact
2. {{bottleneck_2}}: {{impact_2}}% impact
3. {{bottleneck_3}}: {{impact_3}}% impact
Total optimization potential: {{total_potential}}%
optimization_complete: |
Optimization "{{optimization_name}}" complete:
- Performance gain: {{improvement}}%
- Response time: {{old_time}}ms → {{new_time}}ms
- Resource reduction: {{resource_saving}}%
- Tests passing: {{test_status}}
final_report: |
Performance optimization summary:
- Overall improvement: {{total_improvement}}%
- P95 reduced by: {{p95_reduction}}ms
- Throughput increased: {{throughput_increase}}%
- Cost savings: ${{monthly_savings}}/month
complete: |
Performance optimization complete!
- All targets met: {{targets_met}}
- SLO compliance: {{slo_compliance}}%
- Monitoring active: {{monitoring_status}}
- Next review: {{next_review_date}}

220
bmad-core/workflows/quick-fix.yaml Normal file
View File

@ -0,0 +1,220 @@
workflow:
id: quick-fix
name: Quick Fix / Hotfix Workflow
description: >-
Agent workflow for urgent production fixes and hotfixes. Streamlined process
for critical issues that need immediate attention with minimal overhead
while maintaining quality and documentation standards.
type: hotfix
project_types:
- production-fix
- security-patch
- critical-bug
- emergency-update
- hotfix
sequence:
- step: abbreviated_session_init
agent: bmad-master
action: quick_context_load
uses: session-kickoff
notes: |
Abbreviated initialization:
- Quick Memory Bank scan
- Focus on affected system areas
- Review recent deployments
- Check related ADRs
Priority: Speed over comprehensive review
- step: issue_triage
agent: analyst
action: analyze_issue
creates: issue-analysis.md
notes: |
Rapid issue analysis:
- Reproduce the issue
- Identify root cause
- Assess impact severity
- Determine affected components
- Estimate fix complexity
Time box: 30 minutes max
- agent: architect
action: quick_solution_design
creates: fix-approach.md
condition: complex_fix
optional: true
notes: |
For complex fixes only:
- Design minimal viable fix
- Consider rollback strategy
- Identify testing requirements
- Note any technical debt incurred
- agent: dev
action: implement_fix
creates: fix_implementation
notes: |
Rapid implementation:
- Minimal code changes
- Focus on fixing issue only
- Add regression test
- Comment code thoroughly
- Update affected documentation
- agent: qa
action: targeted_testing
validates: fix_implementation
notes: |
Focused testing:
- Test the specific fix
- Verify no regressions
- Check edge cases
- Performance impact check
- Security implications review
- agent: dev
action: address_test_issues
updates: fix_implementation
condition: qa_finds_issues
notes: |
Quick iteration:
- Fix identified issues
- Re-test specific areas
- Update fix if needed
- agent: architect
creates: adr-hotfix.md
action: document_emergency_decision
notes: |
Document fix decision:
- Why this approach was chosen
- Trade-offs accepted
- Technical debt created
- Future improvement notes
Quick ADR format acceptable
- agent: dev
creates: deployment-notes.md
action: prepare_deployment
notes: |
Deployment preparation:
- Create deployment checklist
- Document rollback procedure
- List configuration changes
- Note monitoring requirements
- agent: dev
creates: dev_journal_entry
action: document_hotfix
uses: create-dev-journal
notes: |
Quick documentation:
- Issue description and impact
- Fix approach and rationale
- Deployment details
- Lessons learned
Updates Memory Bank activeContext
- agent: po
action: approve_emergency_release
validates: fix_and_documentation
notes: |
Emergency approval:
- Verify fix addresses issue
- Accept documentation level
- Approve for deployment
- Sign off on risk acceptance
- agent: sm
action: post_mortem_planning
creates: post-mortem-plan.md
optional: true
notes: |
Schedule follow-up:
- Plan full post-mortem
- Schedule debt paydown
- Identify process improvements
- Add to next sprint backlog
- workflow_end:
action: hotfix_complete
notes: |
Hotfix deployed!
- Issue resolved
- Basic documentation complete
- Post-mortem scheduled
- Technical debt logged
flow_diagram: |
```mermaid
graph TD
A[Start: Critical Issue] --> B[bmad-master: quick init]
B --> C[analyst: triage issue]
C --> D{Complex fix?}
D -->|Yes| E[architect: design approach]
D -->|No| F[dev: implement fix]
E --> F
F --> G[qa: targeted testing]
G --> H{Issues found?}
H -->|Yes| I[dev: fix issues]
H -->|No| J[architect: quick ADR]
I --> G
J --> K[dev: deployment prep]
K --> L[dev: document hotfix]
L --> M[po: emergency approval]
M --> N{Post-mortem needed?}
N -->|Yes| O[sm: schedule post-mortem]
N -->|No| P[Hotfix Complete]
O --> P
style P fill:#90EE90
style B fill:#FF6B6B
style C fill:#FF6B6B
style F fill:#FFA500
style G fill:#FFA500
style M fill:#FFD700
```
decision_guidance:
when_to_use:
- Production system is down
- Security vulnerability discovered
- Critical bug affecting users
- Regulatory compliance issue
- Revenue-impacting problem
when_not_to_use:
- Non-critical improvements
- Feature requests
- Technical debt cleanup
- Performance optimizations (non-critical)
handoff_prompts:
triage_complete: |
Issue analysis complete:
- Severity: {{severity_level}}
- Impact: {{affected_users}} users affected
- Root cause: {{root_cause}}
- Fix complexity: {{complexity_estimate}}
fix_ready: "Fix implemented in {{time_taken}}. Ready for emergency testing."
testing_complete: "Fix verified. {{test_count}} tests passed. No regressions found."
approval_request: |
Emergency release request:
- Issue: {{issue_description}}
- Fix: {{fix_summary}}
- Risk: {{risk_level}}
- Rollback available: {{yes/no}}
complete: |
Hotfix deployed successfully.
- Deployment time: {{deployment_time}}
- Issue resolved: {{confirmation}}
- Post-mortem scheduled: {{date/time or N/A}}
- Technical debt ticket: {{ticket_id}}

249
bmad-core/workflows/sprint-execution.yaml Normal file
View File

@ -0,0 +1,249 @@
workflow:
id: sprint-execution
name: Sprint-Based Development Workflow
description: >-
Agent workflow for sprint-based agile development. Handles sprint planning,
daily development cycles, mid-sprint adjustments, sprint reviews, and retrospectives.
Integrates Memory Bank updates and continuous documentation.
type: sprint
project_types:
- agile-development
- scrum-sprint
- iterative-delivery
- continuous-improvement
sequence:
- step: sprint_kickoff
agent: bmad-master
action: initialize_sprint_context
uses: session-kickoff
notes: |
Sprint initialization:
- Review Memory Bank for project state
- Check previous sprint outcomes
- Review product backlog
- Understand technical context
- Review team velocity and capacity
- agent: sm
action: sprint_planning
creates: sprint-plan.md
uses: sprint-planning-tmpl
notes: |
Sprint planning session:
- Define sprint goals
- Select stories from backlog
- Estimate story points
- Assign initial priorities
- Create sprint backlog
- Document in sprint-plan.md
- agent: po
validates: sprint_plan
action: approve_sprint_scope
notes: |
Validate sprint plan:
- Confirm goals align with product vision
- Verify story selection
- Approve priorities
- Sign off on sprint commitment
- daily_development_cycle:
repeats: for_each_sprint_day
sequence:
- agent: sm
action: daily_standup
creates: daily-status.md
notes: |
Daily coordination:
- Review yesterday's progress
- Plan today's work
- Identify blockers
- Update sprint burndown
- agent: dev
action: implement_daily_work
updates: implementation_files
notes: |
Development work:
- Work on assigned stories
- Follow coding standards
- Create unit tests
- Update story status
- agent: dev
creates: dev_journal_entry
action: document_daily_progress
uses: create-dev-journal
condition: end_of_day
notes: |
Daily documentation:
- Document work completed
- Note challenges faced
- Record decisions made
- Update Memory Bank activeContext
- step: mid_sprint_check
agent: sm
action: assess_sprint_health
condition: sprint_midpoint
notes: |
Mid-sprint assessment:
- Review burndown chart
- Assess story completion rate
- Identify at-risk items
- Plan adjustments if needed
- agent: po
action: mid_sprint_adjustment
condition: scope_change_needed
optional: true
notes: |
Sprint adjustment:
- Review proposed changes
- Approve scope modifications
- Update sprint goals if needed
- Communicate changes
- agent: qa
action: continuous_testing
updates: test_results
repeats: as_stories_complete
notes: |
Ongoing quality assurance:
- Test completed stories
- Report issues immediately
- Verify acceptance criteria
- Update story status
- agent: architect
creates: adr.md
action: document_decisions
condition: architectural_decision_made
notes: |
ADR creation:
- Document significant decisions
- Record context and rationale
- Update Memory Bank systemPatterns
- Link to related stories
- step: sprint_review_preparation
agent: sm
action: prepare_review_materials
creates: sprint-review-prep.md
condition: sprint_final_day
notes: |
Review preparation:
- Compile completed stories
- Prepare demonstration materials
- Document impediments
- Calculate velocity metrics
- agent: sm
action: conduct_sprint_review
uses: conduct-sprint-review
creates: sprint-review-summary.md
notes: |
Sprint review meeting:
- Demonstrate completed work
- Gather stakeholder feedback
- Document acceptance status
- Update product backlog
- Use sprint-review-checklist.md
- agent: po
action: accept_sprint_deliverables
validates: completed_stories
notes: |
Sprint acceptance:
- Review demonstrated features
- Confirm acceptance criteria met
- Sign off on completed work
- Update story status to Done
- agent: sm
action: sprint_retrospective
creates: sprint-retrospective.md
notes: |
Sprint retrospective:
- What went well
- What could improve
- Action items for next sprint
- Team velocity analysis
- Process improvements
- agent: bmad-master
action: update_memory_bank
uses: update-memory-bank
notes: |
Comprehensive Memory Bank update:
- Sprint outcomes to progress.md
- Technical decisions to systemPatterns.md
- Learnings to activeContext.md
- Update project velocity metrics
- workflow_end:
action: sprint_complete
notes: |
Sprint completed!
- All deliverables accepted
- Memory Bank updated
- Retrospective documented
- Ready for next sprint planning
flow_diagram: |
```mermaid
graph TD
A[Start: Sprint] --> B[bmad-master: sprint kickoff]
B --> C[sm: sprint planning]
C --> D[po: approve sprint scope]
D --> E[Daily Cycle Start]
E --> F[sm: daily standup]
F --> G[dev: implement work]
G --> H[dev: daily journal]
H --> I{More days?}
I -->|Yes| E
I -->|No| J[sm: mid-sprint check]
J --> K{Adjustment needed?}
K -->|Yes| L[po: scope adjustment]
K -->|No| M[Continue development]
L --> M
M --> N[qa: continuous testing]
N --> O{Architecture decision?}
O -->|Yes| P[architect: create ADR]
O -->|No| Q[sm: prepare review]
P --> Q
Q --> R[sm: sprint review]
R --> S[po: accept deliverables]
S --> T[sm: retrospective]
T --> U[bmad-master: update Memory Bank]
U --> V[Sprint Complete]
style V fill:#90EE90
style B fill:#FFE4B5
style C fill:#FFE4B5
style R fill:#ADD8E6
style T fill:#F0E68C
style U fill:#DDA0DD
```
decision_guidance:
when_to_use:
- Team follows agile/scrum methodology
- Fixed-length iterations preferred
- Regular stakeholder reviews needed
- Continuous improvement focus
- Multiple stories per iteration
handoff_prompts:
kickoff_to_planning: "Sprint context initialized. Ready for sprint planning with backlog items."
planning_to_po: "Sprint plan created with {{story_count}} stories totaling {{story_points}} points. Please review and approve."
daily_standup: "Yesterday: {{completed_tasks}}. Today: {{planned_tasks}}. Blockers: {{blockers}}."
mid_sprint_alert: "Sprint health check: {{completion_percentage}}% complete. {{at_risk_count}} stories at risk."
review_ready: "Sprint review prepared. {{completed_stories}} stories ready for demonstration."
retrospective_complete: "Sprint retrospective complete. {{improvement_actions}} action items for next sprint."
complete: "Sprint {{sprint_number}} complete. Velocity: {{velocity}} points. Ready for next sprint planning."

340
bmad-core/workflows/system-migration.yaml Normal file
View File

@ -0,0 +1,340 @@
workflow:
id: system-migration
name: System Migration Workflow
description: >-
Agent workflow for technology migrations, platform upgrades, and system
modernization. Handles careful planning, phased implementation, rollback
procedures, and validation to ensure safe transitions.
type: migration
project_types:
- platform-migration
- framework-upgrade
- database-migration
- cloud-migration
- technology-modernization
sequence:
- step: session_initialization
agent: bmad-master
action: comprehensive_context_load
uses: session-kickoff
notes: |
Comprehensive initialization:
- Full Memory Bank review
- Current architecture understanding
- Dependency analysis
- Integration points mapping
- Risk assessment preparation
- agent: architect
action: current_state_analysis
creates: current-state-analysis.md
uses: document-project
notes: |
Document current state:
- Complete system architecture
- Technology stack details
- Dependencies and versions
- Integration points
- Performance baselines
- Known issues and constraints
- agent: architect
action: target_state_design
creates: target-state-design.md
notes: |
Design target architecture:
- New technology stack
- Migration architecture
- Compatibility layers needed
- Performance targets
- Security improvements
- Scalability goals
- agent: analyst
action: gap_analysis
creates: migration-gap-analysis.md
requires:
- current-state-analysis.md
- target-state-design.md
notes: |
Analyze migration gaps:
- Technical gaps to bridge
- Feature parity assessment
- Data migration needs
- Training requirements
- Tool changes
- Process updates needed
- agent: pm
action: migration_planning
creates: migration-plan.md
requires: migration-gap-analysis.md
notes: |
Create migration plan:
- Phased approach design
- Timeline with milestones
- Resource requirements
- Risk mitigation strategies
- Rollback procedures
- Success criteria
- agent: architect
action: migration_architecture
creates: migration-architecture.md
notes: |
Technical migration design:
- Parallel run strategy
- Data migration approach
- API compatibility layers
- Feature flags design
- Monitoring strategy
- Cutover procedures
- agent: po
validates: migration_plan
uses: po-master-checklist
notes: |
Validate migration approach:
- Business continuity assured
- Risk acceptable
- Timeline realistic
- Resources available
- Rollback viable
- agent: dev
action: create_migration_tools
creates: migration-tools/
notes: |
Build migration utilities:
- Data migration scripts
- Compatibility adapters
- Validation tools
- Performance benchmarks
- Rollback scripts
- Monitoring setup
- migration_phases:
repeats: for_each_phase
sequence:
- agent: sm
action: phase_planning
creates: phase-plan.md
notes: |
Plan migration phase:
- Define phase scope
- Create detailed tasks
- Set success criteria
- Plan validation steps
- Schedule activities
- agent: dev
action: implement_phase
updates: system_components
notes: |
Phase implementation:
- Migrate components
- Update configurations
- Modify integrations
- Apply compatibility layers
- Enable feature flags
- agent: qa
action: phase_validation
validates: migrated_components
notes: |
Comprehensive testing:
- Functional validation
- Performance testing
- Integration testing
- Security scanning
- Load testing
- Compatibility checks
- agent: dev
action: parallel_run_validation
validates: system_parity
condition: parallel_run_phase
notes: |
Parallel run checks:
- Compare outputs
- Verify data consistency
- Performance comparison
- Error rate analysis
- Resource utilization
- agent: architect
creates: adr-migration-phase.md
action: document_phase_decisions
notes: |
Document phase outcomes:
- Decisions made
- Issues encountered
- Workarounds applied
- Performance impacts
- Lessons learned
- agent: po
action: phase_signoff
validates: phase_completion
notes: |
Phase acceptance:
- Verify success criteria
- Review test results
- Approve continuation
- Update stakeholders
- agent: dev
action: cutover_preparation
creates: cutover-checklist.md
notes: |
Prepare for cutover:
- Final validation checklist
- Cutover procedures
- Communication plan
- Rollback procedures
- Monitoring alerts
- Support readiness
- agent: architect
action: final_validation
validates: system_readiness
notes: |
Pre-cutover validation:
- All components migrated
- Performance acceptable
- Security validated
- Integrations working
- Data integrity verified
- Rollback tested
- agent: po
action: cutover_approval
validates: go_live_readiness
notes: |
Final go-live approval:
- All criteria met
- Risks acceptable
- Team ready
- Communications sent
- Support prepared
- agent: dev
creates: dev_journal_entry
action: document_migration
uses: create-dev-journal
notes: |
Document migration:
- Migration summary
- Issues and resolutions
- Performance changes
- Lessons learned
- Update Memory Bank
- agent: sm
action: post_migration_review
creates: migration-review.md
notes: |
Post-migration review:
- Success metrics
- Issues encountered
- Performance analysis
- Cost analysis
- Team feedback
- Improvement recommendations
- workflow_end:
action: migration_complete
notes: |
Migration completed!
- System successfully migrated
- Performance validated
- Documentation updated
- Team trained
- Monitoring active
flow_diagram: |
```mermaid
graph TD
A[Start: Migration] --> B[bmad-master: comprehensive init]
B --> C[architect: current state]
C --> D[architect: target state]
D --> E[analyst: gap analysis]
E --> F[pm: migration plan]
F --> G[architect: migration architecture]
G --> H[po: validate plan]
H --> I[dev: build tools]
I --> J[Migration Phases]
J --> K[sm: phase planning]
K --> L[dev: implement phase]
L --> M[qa: validate phase]
M --> N{Parallel run?}
N -->|Yes| O[dev: validate parity]
N -->|No| P[architect: document phase]
O --> P
P --> Q[po: phase signoff]
Q --> R{More phases?}
R -->|Yes| J
R -->|No| S[dev: cutover prep]
S --> T[architect: final validation]
T --> U[po: cutover approval]
U --> V[dev: document migration]
V --> W[sm: post-migration review]
W --> X[Migration Complete]
style X fill:#90EE90
style B fill:#FF6B6B
style H fill:#FFD700
style Q fill:#FFD700
style U fill:#FFD700
style L fill:#FFA500
style M fill:#FFA500
style T fill:#98FB98
```
decision_guidance:
when_to_use:
- End-of-life technology
- Performance limitations
- Security vulnerabilities
- Scalability requirements
- Cost optimization needs
- Compliance requirements
handoff_prompts:
analysis_complete: |
Migration analysis complete:
- Current components: {{component_count}}
- Migration complexity: {{complexity_score}}/10
- Estimated phases: {{phase_count}}
- Risk level: {{risk_level}}
plan_ready: |
Migration plan created:
- Total phases: {{phase_count}}
- Timeline: {{timeline_weeks}} weeks
- Rollback points: {{rollback_count}}
- Success criteria defined
phase_complete: |
Phase {{phase_number}} complete:
- Components migrated: {{component_count}}
- Tests passed: {{test_pass_rate}}%
- Performance delta: {{performance_change}}%
- Issues resolved: {{issue_count}}
cutover_ready: |
System ready for cutover:
- All phases complete
- Validation passed: {{validation_score}}/100
- Rollback tested: Yes
- Team prepared: Yes
complete: |
Migration successful!
- Cutover completed: {{cutover_duration}}
- System stability: {{stability_metric}}
- Performance improvement: {{perf_improvement}}%
- Zero data loss confirmed

268
bmad-core/workflows/technical-debt.yaml Normal file
View File

@ -0,0 +1,268 @@
workflow:
id: technical-debt
name: Technical Debt Reduction Workflow
description: >-
Agent workflow for systematic technical debt reduction. Focuses on identifying,
prioritizing, and safely eliminating technical debt while maintaining system
stability and documenting improvements.
type: maintenance
project_types:
- debt-reduction
- code-cleanup
- refactoring
- modernization
- system-health
sequence:
- step: session_initialization
agent: bmad-master
action: session_kickoff
uses: session-kickoff
notes: |
Initialize with debt focus:
- Review Memory Bank for known debt
- Check previous debt reduction efforts
- Review system patterns and pain points
- Understand current technical principles
- Check ADRs for debt-inducing decisions
- agent: architect
action: debt_assessment
creates: debt-assessment.md
uses: document-project
notes: |
Comprehensive debt analysis:
- Code quality metrics analysis
- Dependency audit (outdated/vulnerable)
- Architecture anti-patterns
- Performance bottlenecks
- Security vulnerabilities
- Testing gaps
- Documentation debt
- agent: analyst
action: debt_prioritization
creates: debt-priorities.md
requires: debt-assessment.md
notes: |
Prioritize debt items:
- Risk assessment (security, stability)
- Business impact analysis
- Effort estimation
- Dependency mapping
- Quick wins identification
- Create debt backlog
- agent: pm
creates: debt-reduction-plan.md
action: create_debt_sprint_plan
requires: debt-priorities.md
notes: |
Plan debt reduction:
- Group related debt items
- Create epic for major debt areas
- Define success metrics
- Set realistic timelines
- Plan incremental improvements
- Balance with feature work
- agent: architect
creates: refactoring-strategy.md
action: design_refactoring_approach
requires: debt-reduction-plan.md
notes: |
Technical approach:
- Define refactoring patterns
- Plan migration strategies
- Design new architecture
- Create rollback plans
- Define testing strategy
- Document constraints
- agent: po
validates: debt_reduction_plan
uses: po-master-checklist
notes: |
Validate approach:
- Confirm business value
- Verify risk mitigation
- Approve timeline
- Sign off on approach
- agent: sm
action: create_debt_stories
creates: debt-stories/
uses: create-next-story
notes: |
Story creation:
- Break down into manageable stories
- Include refactoring in each story
- Add comprehensive test requirements
- Define clear acceptance criteria
- Include documentation updates
- development_cycle:
repeats: for_each_debt_story
sequence:
- agent: dev
action: implement_refactoring
updates: codebase
notes: |
Careful implementation:
- Follow Boy Scout Rule
- Maintain backward compatibility
- Add missing tests first
- Refactor incrementally
- Update documentation
- agent: qa
action: regression_testing
validates: refactored_code
notes: |
Thorough testing:
- Full regression suite
- Performance benchmarks
- Security scanning
- Integration tests
- Load testing if needed
- agent: architect
creates: adr.md
action: document_improvements
condition: significant_change
notes: |
Document decisions:
- Why refactoring was needed
- Approach taken
- Trade-offs made
- Patterns introduced
- Update Memory Bank
- agent: dev
creates: dev_journal_entry
action: document_debt_reduction
uses: create-dev-journal
condition: milestone_reached
notes: |
Document progress:
- Debt eliminated
- Patterns improved
- Metrics before/after
- Lessons learned
- Update Memory Bank
- agent: analyst
action: measure_improvement
creates: improvement-metrics.md
notes: |
Quantify improvements:
- Code quality metrics
- Performance improvements
- Test coverage increase
- Build time reduction
- Reduced vulnerabilities
- Developer productivity
- agent: sm
action: debt_sprint_review
uses: conduct-sprint-review
creates: debt-review-summary.md
notes: |
Review improvements:
- Present metrics
- Demonstrate improvements
- Show risk reduction
- Document remaining debt
- Plan next iteration
- agent: bmad-master
action: comprehensive_update
uses: update-memory-bank
notes: |
Update all documentation:
- New patterns to systemPatterns.md
- Progress to progress.md
- Remaining debt to activeContext.md
- Update technical context
- workflow_end:
action: debt_reduction_complete
notes: |
Debt reduction cycle complete!
- Metrics improved
- Documentation updated
- System more maintainable
- Team knowledge increased
flow_diagram: |
```mermaid
graph TD
A[Start: Debt Reduction] --> B[bmad-master: session init]
B --> C[architect: assess debt]
C --> D[analyst: prioritize debt]
D --> E[pm: create plan]
E --> F[architect: refactoring strategy]
F --> G[po: validate approach]
G --> H[sm: create stories]
H --> I[Development Cycle]
I --> J[dev: implement refactoring]
J --> K[qa: regression testing]
K --> L{Significant change?}
L -->|Yes| M[architect: create ADR]
L -->|No| N{More stories?}
M --> N
N -->|Yes| I
N -->|No| O[dev: document progress]
O --> P[analyst: measure improvement]
P --> Q[sm: debt sprint review]
Q --> R[bmad-master: update Memory Bank]
R --> S[Debt Reduction Complete]
style S fill:#90EE90
style B fill:#DDA0DD
style C fill:#FFB6C1
style D fill:#FFB6C1
style P fill:#98FB98
style Q fill:#ADD8E6
style R fill:#DDA0DD
```
decision_guidance:
when_to_use:
- System becoming hard to maintain
- Frequent bugs in certain areas
- Performance degradation
- Security vulnerabilities accumulating
- Developer velocity decreasing
- Before major feature additions
handoff_prompts:
assessment_complete: |
Debt assessment complete:
- Critical items: {{critical_count}}
- High priority: {{high_count}}
- Total debt items: {{total_count}}
- Estimated effort: {{total_effort}} hours
plan_ready: |
Debt reduction plan created:
- Sprint 1 focus: {{sprint1_focus}}
- Quick wins: {{quick_wins_count}}
- Risk reduction: {{risk_reduction_percentage}}%
story_complete: |
Debt story {{story_id}} complete:
- Code quality: {{before_score}} → {{after_score}}
- Test coverage: {{before_coverage}}% → {{after_coverage}}%
- Performance: {{improvement_percentage}}% faster
review_summary: |
Debt reduction sprint complete:
- Stories completed: {{completed_count}}
- Debt eliminated: {{debt_points}} points
- System health: {{health_improvement}}% better
- Remaining debt: {{remaining_debt}} items
complete: "Technical debt reduction cycle complete. System health improved by {{overall_improvement}}%."

58
bmad-core/working-in-the-brownfield.md
View File

@ -26,6 +26,27 @@ If you have just completed an MVP with BMad, and you want to continue with post-
## The Complete Brownfield Workflow
### Session Initialization (NEW - Critical First Step)
Before starting any brownfield work, proper context initialization is essential:
```bash
@bmad-master
*session-kickoff
```
This will:
- Review existing Memory Bank files if available
- Check recent Dev Journal entries for current state
- Load relevant ADRs for architectural decisions
- Establish proper context for brownfield work
**Why This Matters for Brownfield**:
- Prevents duplicate work or conflicting decisions
- Ensures awareness of recent changes and patterns
- Maintains consistency with established practices
- Provides AI agents with critical historical context
### Choose Your Approach
#### Approach A: PRD-First (Recommended if adding very large and complex new features, single or multiple epics or massive changes)
@ -81,6 +102,7 @@ The analyst will:
- **Focus on relevant modules** identified in PRD or your description
- **Skip unrelated areas** to keep docs lean
- **Generate ONE architecture document** for all environments
- **Initialize Memory Bank** for the project if not exists
The analyst creates:
@ -88,6 +110,13 @@ The analyst creates:
- **Covers all system aspects** in a single file
- **Easy to copy and save** as `docs/project-architecture.md`
- **Can be sharded later** in IDE if desired
- **Memory Bank initialization** with project context and patterns
**Memory Bank Integration**:
- Creates `docs/memory-bank/projectbrief.md` with project overview
- Populates `docs/memory-bank/techContext.md` with discovered stack
- Documents patterns in `docs/memory-bank/systemPatterns.md`
- Sets up `docs/memory-bank/activeContext.md` for ongoing work
For example, if you say "Add payment processing to user service":
@ -221,6 +250,14 @@ Follow the enhanced IDE Development Workflow:
- **SM** creates stories with integration awareness
- **Dev** implements with existing code respect
- **QA** reviews for compatibility and improvements
- **Dev Journals** track daily progress and decisions
- **Sprint Reviews** ensure alignment and quality
4. **Continuous Documentation**:
- Create Dev Journal entries after significant work
- Update Memory Bank's `activeContext.md` with progress
- Document decisions in ADRs when making architectural changes
- Run sprint reviews to validate progress against goals
## Brownfield Best Practices
@ -268,6 +305,17 @@ Document:
- New patterns introduced
- Deprecation notices
### 6. Maintain Memory Bank (NEW)
Keep project context current:
- **Session Start**: Always run `*session-kickoff` to load context
- **During Work**: Update `activeContext.md` with current state
- **Pattern Discovery**: Document new patterns in `systemPatterns.md`
- **Progress Tracking**: Update `progress.md` with completed features
- **Tech Changes**: Keep `techContext.md` current with stack updates
- **Decision Records**: Create ADRs for significant architectural decisions
## Common Brownfield Scenarios
### Scenario 1: Adding a New Feature
@ -321,6 +369,9 @@ Document:
### Brownfield-Specific Commands
```bash
# Initialize session with context (ALWAYS DO FIRST)
@bmad-master → *session-kickoff
# Document existing project
@analyst → *document-project
@ -335,6 +386,13 @@ Document:
# Single story creation
@pm → *brownfield-create-story
# Memory Bank operations
@bmad-master → *initialize-memory-bank
@bmad-master → *update-memory-bank
# Sprint ceremonies
@bmad-master → *conduct-sprint-review
```
### Decision Tree

100
expansion-packs/bmad-2d-phaser-game-dev/templates/game-architecture-tmpl.yaml
View File

@ -14,7 +14,7 @@ sections:
- id: initial-setup
instruction: |
This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics.
If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD.
- id: introduction
@ -22,7 +22,7 @@ sections:
instruction: Establish the document's purpose and scope for game development
content: |
This document outlines the complete technical architecture for {{game_title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems.
This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility.
sections:
- id: change-log
@ -41,7 +41,7 @@ sections:
title: Architecture Summary
instruction: |
Provide a comprehensive overview covering:
- Game engine choice and configuration
- Project structure and organization
- Key systems and their interactions
@ -129,23 +129,23 @@ sections:
title: Scene Management System
template: |
**Purpose:** Handle game flow and scene transitions
**Key Components:**
- Scene loading and unloading
- Data passing between scenes
- Transition effects
- Memory management
**Implementation Requirements:**
- Preload scene for asset loading
- Menu system with navigation
- Gameplay scenes with state management
- Pause/resume functionality
**Files to Create:**
- `src/scenes/BootScene.ts`
- `src/scenes/PreloadScene.ts`
- `src/scenes/MenuScene.ts`
@ -155,23 +155,23 @@ sections:
title: Game State Management
template: |
**Purpose:** Track player progress and game status
**State Categories:**
- Player progress (levels, unlocks)
- Game settings (audio, controls)
- Session data (current level, score)
- Persistent data (achievements, statistics)
**Implementation Requirements:**
- Save/load system with localStorage
- State validation and error recovery
- Cross-session data persistence
- Settings management
**Files to Create:**
- `src/systems/GameState.ts`
- `src/systems/SaveManager.ts`
- `src/types/GameData.ts`
@ -179,23 +179,23 @@ sections:
title: Asset Management System
template: |
**Purpose:** Efficient loading and management of game assets
**Asset Categories:**
- Sprite sheets and animations
- Audio files and music
- Level data and configurations
- UI assets and fonts
**Implementation Requirements:**
- Progressive loading strategy
- Asset caching and optimization
- Error handling for failed loads
- Memory management for large assets
**Files to Create:**
- `src/systems/AssetManager.ts`
- `src/config/AssetConfig.ts`
- `src/utils/AssetLoader.ts`
@ -203,23 +203,23 @@ sections:
title: Input Management System
template: |
**Purpose:** Handle all player input across platforms
**Input Types:**
- Keyboard controls
- Mouse/pointer interaction
- Touch gestures (mobile)
- Gamepad support (optional)
**Implementation Requirements:**
- Input mapping and configuration
- Touch-friendly mobile controls
- Input buffering for responsive gameplay
- Customizable control schemes
**Files to Create:**
- `src/systems/InputManager.ts`
- `src/utils/TouchControls.ts`
- `src/types/InputTypes.ts`
@ -232,19 +232,19 @@ sections:
title: "{{mechanic_name}} System"
template: |
**Purpose:** {{system_purpose}}
**Core Functionality:**
- {{feature_1}}
- {{feature_2}}
- {{feature_3}}
**Dependencies:** {{required_systems}}
**Performance Considerations:** {{optimization_notes}}
**Files to Create:**
- `src/systems/{{system_name}}.ts`
- `src/gameObjects/{{related_object}}.ts`
- `src/types/{{system_types}}.ts`
@ -252,65 +252,65 @@ sections:
title: Physics & Collision System
template: |
**Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js)
**Collision Categories:**
- Player collision
- Enemy interactions
- Environmental objects
- Collectibles and items
**Implementation Requirements:**
- Optimized collision detection
- Physics body management
- Collision callbacks and events
- Performance monitoring
**Files to Create:**
- `src/systems/PhysicsManager.ts`
- `src/utils/CollisionGroups.ts`
- id: audio-system
title: Audio System
template: |
**Audio Requirements:**
- Background music with looping
- Sound effects for actions
- Audio settings and volume control
- Mobile audio optimization
**Implementation Features:**
- Audio sprite management
- Dynamic music system
- Spatial audio (if applicable)
- Audio pooling for performance
**Files to Create:**
- `src/systems/AudioManager.ts`
- `src/config/AudioConfig.ts`
- id: ui-system
title: UI System
template: |
**UI Components:**
- HUD elements (score, health, etc.)
- Menu navigation
- Modal dialogs
- Settings screens
**Implementation Requirements:**
- Responsive layout system
- Touch-friendly interface
- Keyboard navigation support
- Animation and transitions
**Files to Create:**
- `src/systems/UIManager.ts`
- `src/gameObjects/UI/`
- `src/types/UITypes.ts`
@ -610,4 +610,4 @@ sections:
- 90%+ test coverage on game logic
- Zero TypeScript errors in strict mode
- Consistent adherence to coding standards
- Comprehensive documentation coverage
- Comprehensive documentation coverage

46
expansion-packs/bmad-2d-phaser-game-dev/templates/game-brief-tmpl.yaml
View File

@ -14,7 +14,7 @@ sections:
- id: initial-setup
instruction: |
This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document.
This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design.
- id: game-vision
@ -71,7 +71,7 @@ sections:
repeatable: true
template: |
**Core Mechanic: {{mechanic_name}}**
- **Description:** {{how_it_works}}
- **Player Value:** {{why_its_fun}}
- **Implementation Scope:** {{complexity_estimate}}
@ -98,12 +98,12 @@ sections:
title: Technical Constraints
template: |
**Platform Requirements:**
- Primary: {{platform_1}} - {{requirements}}
- Secondary: {{platform_2}} - {{requirements}}
**Technical Specifications:**
- Engine: Phaser 3 + TypeScript
- Performance Target: {{fps_target}} FPS on {{target_device}}
- Memory Budget: <{{memory_limit}}MB
@ -141,10 +141,10 @@ sections:
title: Competitive Analysis
template: |
**Direct Competitors:**
- {{competitor_1}}: {{strengths_and_weaknesses}}
- {{competitor_2}}: {{strengths_and_weaknesses}}
**Differentiation Strategy:**
{{how_we_differ_and_why_thats_valuable}}
- id: market-opportunity
@ -168,16 +168,16 @@ sections:
title: Content Categories
template: |
**Core Content:**
- {{content_type_1}}: {{quantity_and_description}}
- {{content_type_2}}: {{quantity_and_description}}
**Optional Content:**
- {{optional_content_type}}: {{quantity_and_description}}
**Replay Elements:**
- {{replayability_features}}
- id: difficulty-accessibility
title: Difficulty and Accessibility
@ -244,13 +244,13 @@ sections:
title: Player Experience Metrics
template: |
**Engagement Goals:**
- Tutorial completion rate: >{{percentage}}%
- Average session length: {{duration}} minutes
- Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}%
**Quality Benchmarks:**
- Player satisfaction: >{{rating}}/10
- Completion rate: >{{percentage}}%
- Technical performance: {{fps_target}} FPS consistent
@ -258,13 +258,13 @@ sections:
title: Development Metrics
template: |
**Technical Targets:**
- Zero critical bugs at launch
- Performance targets met on all platforms
- Load times under {{seconds}}s
**Process Goals:**
- Development timeline adherence
- Feature scope completion
- Quality assurance standards
@ -273,7 +273,7 @@ sections:
condition: has_business_goals
template: |
**Commercial Goals:**
- {{revenue_target}} in first {{time_period}}
- {{user_acquisition_target}} players in first {{time_period}}
- {{retention_target}} monthly active users
@ -326,12 +326,12 @@ sections:
title: Validation Plan
template: |
**Concept Testing:**
- {{validation_method_1}} - {{timeline}}
- {{validation_method_2}} - {{timeline}}
**Prototype Testing:**
- {{testing_approach}} - {{timeline}}
- {{feedback_collection_method}} - {{timeline}}
@ -353,4 +353,4 @@ sections:
type: table
template: |
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
| :--- | :------ | :---------- | :----- |

48
expansion-packs/bmad-2d-phaser-game-dev/templates/game-design-doc-tmpl.yaml
View File

@ -14,7 +14,7 @@ sections:
- id: initial-setup
instruction: |
This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features.
If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis
- id: executive-summary
@ -59,7 +59,7 @@ sections:
instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions.
template: |
**Primary Loop ({{duration}} seconds):**
1. {{action_1}} ({{time_1}}s)
2. {{action_2}} ({{time_2}}s)
3. {{action_3}} ({{time_3}}s)
@ -69,12 +69,12 @@ sections:
instruction: Clearly define success and failure states
template: |
**Victory Conditions:**
- {{win_condition_1}}
- {{win_condition_2}}
**Failure States:**
- {{loss_condition_1}}
- {{loss_condition_2}}
@ -90,17 +90,17 @@ sections:
title: "{{mechanic_name}}"
template: |
**Description:** {{detailed_description}}
**Player Input:** {{input_method}}
**System Response:** {{game_response}}
**Implementation Notes:**
- {{tech_requirement_1}}
- {{tech_requirement_2}}
- {{performance_consideration}}
**Dependencies:** {{other_mechanics_needed}}
- id: controls
title: Controls
@ -119,9 +119,9 @@ sections:
title: Player Progression
template: |
**Progression Type:** {{linear|branching|metroidvania}}
**Key Milestones:**
1. **{{milestone_1}}** - {{unlock_description}}
2. **{{milestone_2}}** - {{unlock_description}}
3. **{{milestone_3}}** - {{unlock_description}}
@ -158,9 +158,9 @@ sections:
**Duration:** {{target_time}}
**Key Elements:** {{required_mechanics}}
**Difficulty:** {{relative_difficulty}}
**Structure Template:**
- Introduction: {{intro_description}}
- Challenge: {{main_challenge}}
- Resolution: {{completion_requirement}}
@ -186,13 +186,13 @@ sections:
title: Platform Specific
template: |
**Desktop:**
- Resolution: {{min_resolution}} - {{max_resolution}}
- Input: Keyboard, Mouse, Gamepad
- Browser: Chrome 80+, Firefox 75+, Safari 13+
**Mobile:**
- Resolution: {{mobile_min}} - {{mobile_max}}
- Input: Touch, Tilt (optional)
- OS: iOS 13+, Android 8+
@ -201,14 +201,14 @@ sections:
instruction: Define asset specifications for the art and audio teams
template: |
**Visual Assets:**
- Art Style: {{style_description}}
- Color Palette: {{color_specification}}
- Animation: {{animation_requirements}}
- UI Resolution: {{ui_specs}}
**Audio Assets:**
- Music Style: {{music_genre}}
- Sound Effects: {{sfx_requirements}}
- Voice Acting: {{voice_needs}}
@ -221,7 +221,7 @@ sections:
title: Engine Configuration
template: |
**Phaser 3 Setup:**
- TypeScript: Strict mode enabled
- Physics: {{physics_system}} (Arcade/Matter)
- Renderer: WebGL with Canvas fallback
@ -230,7 +230,7 @@ sections:
title: Code Architecture
template: |
**Required Systems:**
- Scene Management
- State Management
- Asset Loading
@ -242,7 +242,7 @@ sections:
title: Data Management
template: |
**Save Data:**
- Progress tracking
- Settings persistence
- Statistics collection
@ -340,4 +340,4 @@ sections:
title: References
instruction: List any competitive analysis, inspiration, or research sources
type: bullet-list
template: "{{reference}}"
template: "{{reference}}"

84
expansion-packs/bmad-2d-phaser-game-dev/templates/game-story-tmpl.yaml
View File

@ -14,13 +14,13 @@ sections:
- id: initial-setup
instruction: |
This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality.
Before starting, ensure you have access to:
- Game Design Document (GDD)
- Game Architecture Document
- Any existing stories in this epic
The story should be specific enough that a developer can implement it without requiring additional design decisions.
- id: story-header
@ -69,12 +69,12 @@ sections:
title: Files to Create/Modify
template: |
**New Files:**
- `{{file_path_1}}` - {{purpose}}
- `{{file_path_2}}` - {{purpose}}
**Modified Files:**
- `{{existing_file_1}}` - {{changes_needed}}
- `{{existing_file_2}}` - {{changes_needed}}
- id: class-interface-definitions
@ -89,15 +89,15 @@ sections:
{{property_2}}: {{type}};
{{method_1}}({{params}}): {{return_type}};
}
// {{class_name}}
class {{class_name}} extends {{phaser_class}} {
private {{property}}: {{type}};
constructor({{params}}) {
// Implementation requirements
}
public {{method}}({{params}}): {{return_type}} {
// Method requirements
}
@ -107,15 +107,15 @@ sections:
instruction: Specify how this feature integrates with existing systems
template: |
**Scene Integration:**
- {{scene_name}}: {{integration_details}}
**System Dependencies:**
- {{system_name}}: {{dependency_description}}
**Event Communication:**
- Emits: `{{event_name}}` when {{condition}}
- Listens: `{{event_name}}` to {{response}}
@ -127,7 +127,7 @@ sections:
title: Dev Agent Record
template: |
**Tasks:**
- [ ] {{task_1_description}}
- [ ] {{task_2_description}}
- [ ] {{task_3_description}}
@ -135,18 +135,18 @@ sections:
- [ ] Write unit tests for {{component}}
- [ ] Integration testing with {{related_system}}
- [ ] Performance testing and optimization
**Debug Log:**
| Task | File | Change | Reverted? |
|------|------|--------|-----------|
| | | | |
**Completion Notes:**
<!-- Only note deviations from requirements, keep under 50 words -->
**Change Log:**
<!-- Only requirement changes during implementation -->
- id: game-design-context
@ -154,13 +154,13 @@ sections:
instruction: Reference the specific sections of the GDD that this story implements
template: |
**GDD Reference:** {{section_name}} ({{page_or_section_number}})
**Game Mechanic:** {{mechanic_name}}
**Player Experience Goal:** {{experience_description}}
**Balance Parameters:**
- {{parameter_1}}: {{value_or_range}}
- {{parameter_2}}: {{value_or_range}}
@ -172,11 +172,11 @@ sections:
title: Unit Tests
template: |
**Test Files:**
- `tests/{{component_name}}.test.ts`
**Test Scenarios:**
- {{test_scenario_1}}
- {{test_scenario_2}}
- {{edge_case_test}}
@ -184,12 +184,12 @@ sections:
title: Game Testing
template: |
**Manual Test Cases:**
1. {{test_case_1_description}}
- Expected: {{expected_behavior}}
- Performance: {{performance_expectation}}
2. {{test_case_2_description}}
- Expected: {{expected_behavior}}
- Edge Case: {{edge_case_handling}}
@ -197,7 +197,7 @@ sections:
title: Performance Tests
template: |
**Metrics to Verify:**
- Frame rate maintains {{fps_target}} FPS
- Memory usage stays under {{memory_limit}}MB
- {{feature_specific_performance_metric}}
@ -207,15 +207,15 @@ sections:
instruction: List any dependencies that must be completed before this story can be implemented
template: |
**Story Dependencies:**
- {{story_id}}: {{dependency_description}}
**Technical Dependencies:**
- {{system_or_file}}: {{requirement}}
**Asset Dependencies:**
- {{asset_type}}: {{asset_description}}
- Location: `{{asset_path}}`
@ -238,16 +238,16 @@ sections:
instruction: Any additional context, design decisions, or implementation notes
template: |
**Implementation Notes:**
- {{note_1}}
- {{note_2}}
**Design Decisions:**
- {{decision_1}}: {{rationale}}
- {{decision_2}}: {{rationale}}
**Future Considerations:**
- {{future_enhancement_1}}
- {{future_optimization_1}}
- {{future_optimization_1}}

130
expansion-packs/bmad-2d-phaser-game-dev/templates/level-design-doc-tmpl.yaml
View File

@ -14,7 +14,7 @@ sections:
- id: initial-setup
instruction: |
This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels.
If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents.
- id: introduction
@ -22,7 +22,7 @@ sections:
instruction: Establish the purpose and scope of level design for this game
content: |
This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document.
This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints.
sections:
- id: change-log
@ -69,29 +69,29 @@ sections:
title: "{{category_name}} Levels"
template: |
**Purpose:** {{gameplay_purpose}}
**Target Duration:** {{min_time}} - {{max_time}} minutes
**Difficulty Range:** {{difficulty_scale}}
**Key Mechanics Featured:**
- {{mechanic_1}} - {{usage_description}}
- {{mechanic_2}} - {{usage_description}}
**Player Objectives:**
- Primary: {{primary_objective}}
- Secondary: {{secondary_objective}}
- Hidden: {{secret_objective}}
**Success Criteria:**
- {{completion_requirement_1}}
- {{completion_requirement_2}}
**Technical Requirements:**
- Maximum entities: {{entity_limit}}
- Performance target: {{fps_target}} FPS
- Memory budget: {{memory_limit}}MB
@ -106,11 +106,11 @@ sections:
instruction: Based on GDD requirements, define the overall level organization
template: |
**Organization Type:** {{linear|hub_world|open_world}}
**Total Level Count:** {{number}}
**World Breakdown:**
- World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}}
- World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}}
- World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}}
@ -145,7 +145,7 @@ sections:
instruction: Define how players access new levels
template: |
**Progression Gates:**
- Linear progression: Complete previous level
- Star requirements: {{star_count}} stars to unlock
- Skill gates: Demonstrate {{skill_requirement}}
@ -160,17 +160,17 @@ sections:
instruction: Define all environmental components that can be used in levels
template: |
**Terrain Types:**
- {{terrain_1}}: {{properties_and_usage}}
- {{terrain_2}}: {{properties_and_usage}}
**Interactive Objects:**
- {{object_1}}: {{behavior_and_purpose}}
- {{object_2}}: {{behavior_and_purpose}}
**Hazards and Obstacles:**
- {{hazard_1}}: {{damage_and_behavior}}
- {{hazard_2}}: {{damage_and_behavior}}
- id: collectibles-rewards
@ -178,18 +178,18 @@ sections:
instruction: Define all collectible items and their placement rules
template: |
**Collectible Types:**
- {{collectible_1}}: {{value_and_purpose}}
- {{collectible_2}}: {{value_and_purpose}}
**Placement Guidelines:**
- Mandatory collectibles: {{placement_rules}}
- Optional collectibles: {{placement_rules}}
- Secret collectibles: {{placement_rules}}
**Reward Distribution:**
- Easy to find: {{percentage}}%
- Moderate challenge: {{percentage}}%
- High skill required: {{percentage}}%
@ -198,18 +198,18 @@ sections:
instruction: Define how enemies should be placed and balanced in levels
template: |
**Enemy Categories:**
- {{enemy_type_1}}: {{behavior_and_usage}}
- {{enemy_type_2}}: {{behavior_and_usage}}
**Placement Principles:**
- Introduction encounters: {{guideline}}
- Standard encounters: {{guideline}}
- Challenge encounters: {{guideline}}
**Difficulty Scaling:**
- Enemy count progression: {{scaling_rule}}
- Enemy type introduction: {{pacing_rule}}
- Encounter complexity: {{complexity_rule}}
@ -222,14 +222,14 @@ sections:
title: Level Layout Principles
template: |
**Spatial Design:**
- Grid size: {{grid_dimensions}}
- Minimum path width: {{width_units}}
- Maximum vertical distance: {{height_units}}
- Safe zones placement: {{safety_guidelines}}
**Navigation Design:**
- Clear path indication: {{visual_cues}}
- Landmark placement: {{landmark_rules}}
- Dead end avoidance: {{dead_end_policy}}
@ -239,13 +239,13 @@ sections:
instruction: Define how to control the rhythm and pace of gameplay within levels
template: |
**Action Sequences:**
- High intensity duration: {{max_duration}}
- Rest period requirement: {{min_rest_time}}
- Intensity variation: {{pacing_pattern}}
**Learning Sequences:**
- New mechanic introduction: {{teaching_method}}
- Practice opportunity: {{practice_duration}}
- Skill application: {{application_context}}
@ -254,14 +254,14 @@ sections:
instruction: Define how to create appropriate challenges for each level type
template: |
**Challenge Types:**
- Execution challenges: {{skill_requirements}}
- Puzzle challenges: {{complexity_guidelines}}
- Time challenges: {{time_pressure_rules}}
- Resource challenges: {{resource_management}}
**Difficulty Calibration:**
- Skill check frequency: {{frequency_guidelines}}
- Failure recovery: {{retry_mechanics}}
- Hint system integration: {{help_system}}
@ -275,7 +275,7 @@ sections:
instruction: Define how level data should be structured for implementation
template: |
**Level File Format:**
- Data format: {{json|yaml|custom}}
- File naming: `level_{{world}}_{{number}}.{{extension}}`
- Data organization: {{structure_description}}
@ -313,14 +313,14 @@ sections:
instruction: Define how level assets are organized and loaded
template: |
**Tilemap Requirements:**
- Tile size: {{tile_dimensions}}px
- Tileset organization: {{tileset_structure}}
- Layer organization: {{layer_system}}
- Collision data: {{collision_format}}
**Audio Integration:**
- Background music: {{music_requirements}}
- Ambient sounds: {{ambient_system}}
- Dynamic audio: {{dynamic_audio_rules}}
@ -329,19 +329,19 @@ sections:
instruction: Define performance requirements for level systems
template: |
**Entity Limits:**
- Maximum active entities: {{entity_limit}}
- Maximum particles: {{particle_limit}}
- Maximum audio sources: {{audio_limit}}
**Memory Management:**
- Texture memory budget: {{texture_memory}}MB
- Audio memory budget: {{audio_memory}}MB
- Level loading time: <{{load_time}}s
**Culling and LOD:**
- Off-screen culling: {{culling_distance}}
- Level-of-detail rules: {{lod_system}}
- Asset streaming: {{streaming_requirements}}
@ -354,13 +354,13 @@ sections:
title: Automated Testing
template: |
**Performance Testing:**
- Frame rate validation: Maintain {{fps_target}} FPS
- Memory usage monitoring: Stay under {{memory_limit}}MB
- Loading time verification: Complete in <{{load_time}}s
**Gameplay Testing:**
- Completion path validation: All objectives achievable
- Collectible accessibility: All items reachable
- Softlock prevention: No unwinnable states
@ -388,14 +388,14 @@ sections:
title: Balance Validation
template: |
**Metrics Collection:**
- Completion rate: Target {{completion_percentage}}%
- Average completion time: {{target_time}} ± {{variance}}
- Death count per level: <{{max_deaths}}
- Collectible discovery rate: {{discovery_percentage}}%
**Iteration Guidelines:**
- Adjustment criteria: {{criteria_for_changes}}
- Testing sample size: {{minimum_testers}}
- Validation period: {{testing_duration}}
@ -408,14 +408,14 @@ sections:
title: Design Phase
template: |
**Concept Development:**
1. Define level purpose and goals
2. Create rough layout sketch
3. Identify key mechanics and challenges
4. Estimate difficulty and duration
**Documentation Requirements:**
- Level design brief
- Layout diagrams
- Mechanic integration notes
@ -424,15 +424,15 @@ sections:
title: Implementation Phase
template: |
**Technical Implementation:**
1. Create level data file
2. Build tilemap and layout
3. Place entities and objects
4. Configure level logic and triggers
5. Integrate audio and visual effects
**Quality Assurance:**
1. Automated testing execution
2. Internal playtesting
3. Performance validation
@ -441,14 +441,14 @@ sections:
title: Integration Phase
template: |
**Game Integration:**
1. Level progression integration
2. Save system compatibility
3. Analytics integration
4. Achievement system integration
**Final Validation:**
1. Full game context testing
2. Performance regression testing
3. Platform compatibility verification
@ -481,4 +481,4 @@ sections:
- Difficulty curve adherence: {{curve_accuracy}}
- Mechanic integration effectiveness: {{integration_score}}
- Player guidance clarity: {{guidance_score}}
- Content accessibility: {{accessibility_rate}}%
- Content accessibility: {{accessibility_rate}}%

10
expansion-packs/bmad-2d-phaser-game-dev/workflows/game-dev-greenfield.yaml
View File

@ -17,21 +17,21 @@ workflow:
- brainstorming_session
- game_research_prompt
- player_research
notes: 'Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/design/ folder.'
notes: "Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project's docs/design/ folder."
- agent: game-designer
creates: game-design-doc.md
requires: game-brief.md
optional_steps:
- competitive_analysis
- technical_research
notes: 'Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project''s docs/design/ folder.'
notes: "Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project's docs/design/ folder."
- agent: game-designer
creates: level-design-doc.md
requires: game-design-doc.md
optional_steps:
- level_prototyping
- difficulty_analysis
notes: 'Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project''s docs/design/ folder.'
notes: "Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project's docs/design/ folder."
- agent: solution-architect
creates: game-architecture.md
requires:
@ -41,7 +41,7 @@ workflow:
- technical_research_prompt
- performance_analysis
- platform_research
notes: 'Create comprehensive technical architecture using game-architecture-tmpl. Defines Phaser 3 systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project''s docs/architecture/ folder.'
notes: "Create comprehensive technical architecture using game-architecture-tmpl. Defines Phaser 3 systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project's docs/architecture/ folder."
- agent: game-designer
validates: design_consistency
requires: all_design_documents
@ -66,7 +66,7 @@ workflow:
optional_steps:
- quick_brainstorming
- concept_validation
notes: 'Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/ folder.'
notes: "Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project's docs/ folder."
- agent: game-designer
creates: prototype-design.md
uses: create-doc prototype-design OR create-game-story

2
expansion-packs/bmad-2d-phaser-game-dev/workflows/game-prototype.yaml
View File

@ -44,7 +44,7 @@ workflow:
notes: Implement stories in priority order. Test frequently and adjust design based on what feels fun. Document discoveries.
workflow_end:
action: prototype_evaluation
notes: 'Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive.'
notes: "Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive."
game_jam_sequence:
- step: jam_concept
agent: game-designer

46
expansion-packs/bmad-2d-unity-game-dev/templates/game-brief-tmpl.yaml
View File

@ -14,7 +14,7 @@ sections:
- id: initial-setup
instruction: |
This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document.
This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design.
- id: game-vision
@ -71,7 +71,7 @@ sections:
repeatable: true
template: |
**Core Mechanic: {{mechanic_name}}**
- **Description:** {{how_it_works}}
- **Player Value:** {{why_its_fun}}
- **Implementation Scope:** {{complexity_estimate}}
@ -98,12 +98,12 @@ sections:
title: Technical Constraints
template: |
**Platform Requirements:**
- Primary: {{platform_1}} - {{requirements}}
- Secondary: {{platform_2}} - {{requirements}}
**Technical Specifications:**
- Engine: Unity & C#
- Performance Target: {{fps_target}} FPS on {{target_device}}
- Memory Budget: <{{memory_limit}}MB
@ -141,10 +141,10 @@ sections:
title: Competitive Analysis
template: |
**Direct Competitors:**
- {{competitor_1}}: {{strengths_and_weaknesses}}
- {{competitor_2}}: {{strengths_and_weaknesses}}
**Differentiation Strategy:**
{{how_we_differ_and_why_thats_valuable}}
- id: market-opportunity
@ -168,16 +168,16 @@ sections:
title: Content Categories
template: |
**Core Content:**
- {{content_type_1}}: {{quantity_and_description}}
- {{content_type_2}}: {{quantity_and_description}}
**Optional Content:**
- {{optional_content_type}}: {{quantity_and_description}}
**Replay Elements:**
- {{replayability_features}}
- id: difficulty-accessibility
title: Difficulty and Accessibility
@ -244,13 +244,13 @@ sections:
title: Player Experience Metrics
template: |
**Engagement Goals:**
- Tutorial completion rate: >{{percentage}}%
- Average session length: {{duration}} minutes
- Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}%
**Quality Benchmarks:**
- Player satisfaction: >{{rating}}/10
- Completion rate: >{{percentage}}%
- Technical performance: {{fps_target}} FPS consistent
@ -258,13 +258,13 @@ sections:
title: Development Metrics
template: |
**Technical Targets:**
- Zero critical bugs at launch
- Performance targets met on all platforms
- Load times under {{seconds}}s
**Process Goals:**
- Development timeline adherence
- Feature scope completion
- Quality assurance standards
@ -273,7 +273,7 @@ sections:
condition: has_business_goals
template: |
**Commercial Goals:**
- {{revenue_target}} in first {{time_period}}
- {{user_acquisition_target}} players in first {{time_period}}
- {{retention_target}} monthly active users
@ -326,12 +326,12 @@ sections:
title: Validation Plan
template: |
**Concept Testing:**
- {{validation_method_1}} - {{timeline}}
- {{validation_method_2}} - {{timeline}}
**Prototype Testing:**
- {{testing_approach}} - {{timeline}}
- {{feedback_collection_method}} - {{timeline}}
@ -353,4 +353,4 @@ sections:
type: table
template: |
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
| :--- | :------ | :---------- | :----- |

46
expansion-packs/bmad-2d-unity-game-dev/templates/game-design-doc-tmpl.yaml
View File

@ -14,7 +14,7 @@ sections:
- id: initial-setup
instruction: |
This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features.
If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis
- id: executive-summary
@ -59,7 +59,7 @@ sections:
instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions.
template: |
**Primary Loop ({{duration}} seconds):**
1. {{action_1}} ({{time_1}}s)
2. {{action_2}} ({{time_2}}s)
3. {{action_3}} ({{time_3}}s)
@ -69,12 +69,12 @@ sections:
instruction: Clearly define success and failure states
template: |
**Victory Conditions:**
- {{win_condition_1}}
- {{win_condition_2}}
**Failure States:**
- {{loss_condition_1}}
- {{loss_condition_2}}
@ -90,17 +90,17 @@ sections:
title: "{{mechanic_name}}"
template: |
**Description:** {{detailed_description}}
**Player Input:** {{input_method}}
**System Response:** {{game_response}}
**Implementation Notes:**
- {{tech_requirement_1}}
- {{tech_requirement_2}}
- {{performance_consideration}}
**Dependencies:** {{other_mechanics_needed}}
- id: controls
title: Controls
@ -119,9 +119,9 @@ sections:
title: Player Progression
template: |
**Progression Type:** {{linear|branching|metroidvania}}
**Key Milestones:**
1. **{{milestone_1}}** - {{unlock_description}}
2. **{{milestone_2}}** - {{unlock_description}}
3. **{{milestone_3}}** - {{unlock_description}}
@ -158,9 +158,9 @@ sections:
**Duration:** {{target_time}}
**Key Elements:** {{required_mechanics}}
**Difficulty:** {{relative_difficulty}}
**Structure Template:**
- Introduction: {{intro_description}}
- Challenge: {{main_challenge}}
- Resolution: {{completion_requirement}}
@ -186,13 +186,13 @@ sections:
title: Platform Specific
template: |
**Desktop:**
- Resolution: {{min_resolution}} - {{max_resolution}}
- Input: Keyboard, Mouse, Gamepad
- Browser: Chrome 80+, Firefox 75+, Safari 13+
**Mobile:**
- Resolution: {{mobile_min}} - {{mobile_max}}
- Input: Touch, Tilt (optional)
- OS: iOS 13+, Android 8+
@ -201,14 +201,14 @@ sections:
instruction: Define asset specifications for the art and audio teams
template: |
**Visual Assets:**
- Art Style: {{style_description}}
- Color Palette: {{color_specification}}
- Animation: {{animation_requirements}}
- UI Resolution: {{ui_specs}}
**Audio Assets:**
- Music Style: {{music_genre}}
- Sound Effects: {{sfx_requirements}}
- Voice Acting: {{voice_needs}}
@ -230,7 +230,7 @@ sections:
title: Code Architecture
template: |
**Required Systems:**
- Scene Management
- State Management
- Asset Loading
@ -242,7 +242,7 @@ sections:
title: Data Management
template: |
**Save Data:**
- Progress tracking
- Settings persistence
- Statistics collection
@ -340,4 +340,4 @@ sections:
title: References
instruction: List any competitive analysis, inspiration, or research sources
type: bullet-list
template: "{{reference}}"
template: "{{reference}}"

40
expansion-packs/bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml
View File

@ -14,13 +14,13 @@ sections:
- id: initial-setup
instruction: |
This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality.
Before starting, ensure you have access to:
- Game Design Document (GDD)
- Game Architecture Document
- Any existing stories in this epic
The story should be specific enough that a developer can implement it without requiring additional design decisions.
- id: story-header
@ -69,12 +69,12 @@ sections:
title: Files to Create/Modify
template: |
**New Files:**
- `{{file_path_1}}` - {{purpose}}
- `{{file_path_2}}` - {{purpose}}
**Modified Files:**
- `{{existing_file_1}}` - {{changes_needed}}
- `{{existing_file_2}}` - {{changes_needed}}
- id: class-interface-definitions
@ -157,13 +157,13 @@ sections:
instruction: Reference the specific sections of the GDD that this story implements
template: |
**GDD Reference:** {{section_name}} ({{page_or_section_number}})
**Game Mechanic:** {{mechanic_name}}
**Player Experience Goal:** {{experience_description}}
**Balance Parameters:**
- {{parameter_1}}: {{value_or_range}}
- {{parameter_2}}: {{value_or_range}}
@ -210,15 +210,15 @@ sections:
instruction: List any dependencies that must be completed before this story can be implemented
template: |
**Story Dependencies:**
- {{story_id}}: {{dependency_description}}
**Technical Dependencies:**
- {{system_or_file}}: {{requirement}}
**Asset Dependencies:**
- {{asset_type}}: {{asset_description}}
- Location: `{{asset_path}}`
@ -241,16 +241,16 @@ sections:
instruction: Any additional context, design decisions, or implementation notes
template: |
**Implementation Notes:**
- {{note_1}}
- {{note_2}}
**Design Decisions:**
- {{decision_1}}: {{rationale}}
- {{decision_2}}: {{rationale}}
**Future Considerations:**
- {{future_enhancement_1}}
- {{future_optimization_1}}

130
expansion-packs/bmad-2d-unity-game-dev/templates/level-design-doc-tmpl.yaml
View File

@ -14,7 +14,7 @@ sections:
- id: initial-setup
instruction: |
This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels.
If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents.
- id: introduction
@ -22,7 +22,7 @@ sections:
instruction: Establish the purpose and scope of level design for this game
content: |
This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document.
This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints.
sections:
- id: change-log
@ -69,29 +69,29 @@ sections:
title: "{{category_name}} Levels"
template: |
**Purpose:** {{gameplay_purpose}}
**Target Duration:** {{min_time}} - {{max_time}} minutes
**Difficulty Range:** {{difficulty_scale}}
**Key Mechanics Featured:**
- {{mechanic_1}} - {{usage_description}}
- {{mechanic_2}} - {{usage_description}}
**Player Objectives:**
- Primary: {{primary_objective}}
- Secondary: {{secondary_objective}}
- Hidden: {{secret_objective}}
**Success Criteria:**
- {{completion_requirement_1}}
- {{completion_requirement_2}}
**Technical Requirements:**
- Maximum entities: {{entity_limit}}
- Performance target: {{fps_target}} FPS
- Memory budget: {{memory_limit}}MB
@ -106,11 +106,11 @@ sections:
instruction: Based on GDD requirements, define the overall level organization
template: |
**Organization Type:** {{linear|hub_world|open_world}}
**Total Level Count:** {{number}}
**World Breakdown:**
- World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}}
- World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}}
- World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}}
@ -145,7 +145,7 @@ sections:
instruction: Define how players access new levels
template: |
**Progression Gates:**
- Linear progression: Complete previous level
- Star requirements: {{star_count}} stars to unlock
- Skill gates: Demonstrate {{skill_requirement}}
@ -160,17 +160,17 @@ sections:
instruction: Define all environmental components that can be used in levels
template: |
**Terrain Types:**
- {{terrain_1}}: {{properties_and_usage}}
- {{terrain_2}}: {{properties_and_usage}}
**Interactive Objects:**
- {{object_1}}: {{behavior_and_purpose}}
- {{object_2}}: {{behavior_and_purpose}}
**Hazards and Obstacles:**
- {{hazard_1}}: {{damage_and_behavior}}
- {{hazard_2}}: {{damage_and_behavior}}
- id: collectibles-rewards
@ -178,18 +178,18 @@ sections:
instruction: Define all collectible items and their placement rules
template: |
**Collectible Types:**
- {{collectible_1}}: {{value_and_purpose}}
- {{collectible_2}}: {{value_and_purpose}}
**Placement Guidelines:**
- Mandatory collectibles: {{placement_rules}}
- Optional collectibles: {{placement_rules}}
- Secret collectibles: {{placement_rules}}
**Reward Distribution:**
- Easy to find: {{percentage}}%
- Moderate challenge: {{percentage}}%
- High skill required: {{percentage}}%
@ -198,18 +198,18 @@ sections:
instruction: Define how enemies should be placed and balanced in levels
template: |
**Enemy Categories:**
- {{enemy_type_1}}: {{behavior_and_usage}}
- {{enemy_type_2}}: {{behavior_and_usage}}
**Placement Principles:**
- Introduction encounters: {{guideline}}
- Standard encounters: {{guideline}}
- Challenge encounters: {{guideline}}
**Difficulty Scaling:**
- Enemy count progression: {{scaling_rule}}
- Enemy type introduction: {{pacing_rule}}
- Encounter complexity: {{complexity_rule}}
@ -222,14 +222,14 @@ sections:
title: Level Layout Principles
template: |
**Spatial Design:**
- Grid size: {{grid_dimensions}}
- Minimum path width: {{width_units}}
- Maximum vertical distance: {{height_units}}
- Safe zones placement: {{safety_guidelines}}
**Navigation Design:**
- Clear path indication: {{visual_cues}}
- Landmark placement: {{landmark_rules}}
- Dead end avoidance: {{dead_end_policy}}
@ -239,13 +239,13 @@ sections:
instruction: Define how to control the rhythm and pace of gameplay within levels
template: |
**Action Sequences:**
- High intensity duration: {{max_duration}}
- Rest period requirement: {{min_rest_time}}
- Intensity variation: {{pacing_pattern}}
**Learning Sequences:**
- New mechanic introduction: {{teaching_method}}
- Practice opportunity: {{practice_duration}}
- Skill application: {{application_context}}
@ -254,14 +254,14 @@ sections:
instruction: Define how to create appropriate challenges for each level type
template: |
**Challenge Types:**
- Execution challenges: {{skill_requirements}}
- Puzzle challenges: {{complexity_guidelines}}
- Time challenges: {{time_pressure_rules}}
- Resource challenges: {{resource_management}}
**Difficulty Calibration:**
- Skill check frequency: {{frequency_guidelines}}
- Failure recovery: {{retry_mechanics}}
- Hint system integration: {{help_system}}
@ -275,7 +275,7 @@ sections:
instruction: Define how level data should be structured for implementation
template: |
**Level File Format:**
- Data format: {{json|yaml|custom}}
- File naming: `level_{{world}}_{{number}}.{{extension}}`
- Data organization: {{structure_description}}
@ -313,14 +313,14 @@ sections:
instruction: Define how level assets are organized and loaded
template: |
**Tilemap Requirements:**
- Tile size: {{tile_dimensions}}px
- Tileset organization: {{tileset_structure}}
- Layer organization: {{layer_system}}
- Collision data: {{collision_format}}
**Audio Integration:**
- Background music: {{music_requirements}}
- Ambient sounds: {{ambient_system}}
- Dynamic audio: {{dynamic_audio_rules}}
@ -329,19 +329,19 @@ sections:
instruction: Define performance requirements for level systems
template: |
**Entity Limits:**
- Maximum active entities: {{entity_limit}}
- Maximum particles: {{particle_limit}}
- Maximum audio sources: {{audio_limit}}
**Memory Management:**
- Texture memory budget: {{texture_memory}}MB
- Audio memory budget: {{audio_memory}}MB
- Level loading time: <{{load_time}}s
**Culling and LOD:**
- Off-screen culling: {{culling_distance}}
- Level-of-detail rules: {{lod_system}}
- Asset streaming: {{streaming_requirements}}
@ -354,13 +354,13 @@ sections:
title: Automated Testing
template: |
**Performance Testing:**
- Frame rate validation: Maintain {{fps_target}} FPS
- Memory usage monitoring: Stay under {{memory_limit}}MB
- Loading time verification: Complete in <{{load_time}}s
**Gameplay Testing:**
- Completion path validation: All objectives achievable
- Collectible accessibility: All items reachable
- Softlock prevention: No unwinnable states
@ -388,14 +388,14 @@ sections:
title: Balance Validation
template: |
**Metrics Collection:**
- Completion rate: Target {{completion_percentage}}%
- Average completion time: {{target_time}} ± {{variance}}
- Death count per level: <{{max_deaths}}
- Collectible discovery rate: {{discovery_percentage}}%
**Iteration Guidelines:**
- Adjustment criteria: {{criteria_for_changes}}
- Testing sample size: {{minimum_testers}}
- Validation period: {{testing_duration}}
@ -408,14 +408,14 @@ sections:
title: Design Phase
template: |
**Concept Development:**
1. Define level purpose and goals
2. Create rough layout sketch
3. Identify key mechanics and challenges
4. Estimate difficulty and duration
**Documentation Requirements:**
- Level design brief
- Layout diagrams
- Mechanic integration notes
@ -424,15 +424,15 @@ sections:
title: Implementation Phase
template: |
**Technical Implementation:**
1. Create level data file
2. Build tilemap and layout
3. Place entities and objects
4. Configure level logic and triggers
5. Integrate audio and visual effects
**Quality Assurance:**
1. Automated testing execution
2. Internal playtesting
3. Performance validation
@ -441,14 +441,14 @@ sections:
title: Integration Phase
template: |
**Game Integration:**
1. Level progression integration
2. Save system compatibility
3. Analytics integration
4. Achievement system integration
**Final Validation:**
1. Full game context testing
2. Performance regression testing
3. Platform compatibility verification
@ -481,4 +481,4 @@ sections:
- Difficulty curve adherence: {{curve_accuracy}}
- Mechanic integration effectiveness: {{integration_score}}
- Player guidance clarity: {{guidance_score}}
- Content accessibility: {{accessibility_rate}}%
- Content accessibility: {{accessibility_rate}}%

10
expansion-packs/bmad-2d-unity-game-dev/workflows/game-dev-greenfield.yaml
View File

@ -17,21 +17,21 @@ workflow:
- brainstorming_session
- game_research_prompt
- player_research
notes: 'Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/design/ folder.'
notes: "Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project's docs/design/ folder."
- agent: game-designer
creates: game-design-doc.md
requires: game-brief.md
optional_steps:
- competitive_analysis
- technical_research
notes: 'Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project''s docs/design/ folder.'
notes: "Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project's docs/design/ folder."
- agent: game-designer
creates: level-design-doc.md
requires: game-design-doc.md
optional_steps:
- level_prototyping
- difficulty_analysis
notes: 'Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project''s docs/design/ folder.'
notes: "Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project's docs/design/ folder."
- agent: solution-architect
creates: game-architecture.md
requires:
@ -41,7 +41,7 @@ workflow:
- technical_research_prompt
- performance_analysis
- platform_research
notes: 'Create comprehensive technical architecture using game-architecture-tmpl. Defines Unity systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project''s docs/architecture/ folder.'
notes: "Create comprehensive technical architecture using game-architecture-tmpl. Defines Unity systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project's docs/architecture/ folder."
- agent: game-designer
validates: design_consistency
requires: all_design_documents
@ -66,7 +66,7 @@ workflow:
optional_steps:
- quick_brainstorming
- concept_validation
notes: 'Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/ folder.'
notes: "Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project's docs/ folder."
- agent: game-designer
creates: prototype-design.md
uses: create-doc prototype-design OR create-game-story

2
expansion-packs/bmad-2d-unity-game-dev/workflows/game-prototype.yaml
View File

@ -44,7 +44,7 @@ workflow:
notes: Implement stories in priority order. Test frequently in the Unity Editor and adjust design based on what feels fun. Document discoveries.
workflow_end:
action: prototype_evaluation
notes: 'Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive.'
notes: "Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive."
game_jam_sequence:
- step: jam_concept
agent: game-designer

40
expansion-packs/bmad-infrastructure-devops/templates/infrastructure-architecture-tmpl.yaml
View File

@ -27,18 +27,18 @@ sections:
- id: initial-setup
instruction: |
Initial Setup
1. Replace {{project_name}} with the actual project name throughout the document
2. Gather and review required inputs:
- Product Requirements Document (PRD) - Required for business needs and scale requirements
- Main System Architecture - Required for infrastructure dependencies
- Technical Preferences/Tech Stack Document - Required for technology choices
- PRD Technical Assumptions - Required for cross-referencing repository and service architecture
If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
Output file location: `docs/infrastructure-architecture.md`
- id: infrastructure-overview
@ -67,7 +67,7 @@ sections:
- Repository Structure
- State Management
- Dependency Management
<critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
- id: environment-configuration
@ -103,7 +103,7 @@ sections:
title: Network Architecture
instruction: |
Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
Create Mermaid diagram showing:
- VPC/Network structure
- Security zones and boundaries
@ -166,7 +166,7 @@ sections:
title: Data Resources
instruction: |
Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
Create data flow diagram showing:
- Database topology
- Replication patterns
@ -187,7 +187,7 @@ sections:
- Data Encryption
- Compliance Controls
- Security Scanning & Monitoring
<critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
- id: shared-responsibility
@ -223,7 +223,7 @@ sections:
title: CI/CD Pipeline
instruction: |
Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
Create pipeline diagram showing:
- Build stages
- Test gates
@ -254,7 +254,7 @@ sections:
- Recovery Procedures
- RTO & RPO Targets
- DR Testing Approach
<critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
- id: cost-optimization
@ -296,15 +296,15 @@ sections:
title: DevOps/Platform Feasibility Review
instruction: |
CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
- **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
- **Security Implementation:** Are security patterns achievable with current security toolchain?
- **Operational Overhead:** Will the proposed architecture create excessive operational burden?
- **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
<critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>
sections:
- id: feasibility-results
@ -322,7 +322,7 @@ sections:
title: Validation Framework
content: |
This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
- Completeness of architecture documentation
- Consistency with broader system architecture
- Appropriate level of detail for different stakeholders
@ -332,12 +332,12 @@ sections:
title: Validation Process
content: |
The architecture documentation validation should be performed:
- After initial architecture development
- After significant architecture changes
- Before major implementation phases
- During periodic architecture reviews
The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
- id: implementation-handoff
@ -348,7 +348,7 @@ sections:
title: Architecture Decision Records (ADRs)
content: |
Create ADRs for key infrastructure decisions:
- Cloud provider selection rationale
- Container orchestration platform choice
- Networking architecture decisions
@ -358,7 +358,7 @@ sections:
title: Implementation Validation Criteria
content: |
Define specific criteria for validating correct implementation:
- Infrastructure as Code quality gates
- Security compliance checkpoints
- Performance benchmarks
@ -418,7 +418,7 @@ sections:
instruction: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.
content: |
---
_Document Version: 1.0_
_Last Updated: {{current_date}}_
_Next Review: {{review_date}}_
_Next Review: {{review_date}}_

14
expansion-packs/bmad-infrastructure-devops/templates/infrastructure-platform-from-arch-tmpl.yaml
View File

@ -28,7 +28,7 @@ sections:
- id: initial-setup
instruction: |
Initial Setup
1. Replace {{project_name}} with the actual project name throughout the document
2. Gather and review required inputs:
- **Infrastructure Architecture Document** (Primary input - REQUIRED)
@ -37,10 +37,10 @@ sections:
- Technology Stack Document
- Infrastructure Checklist
- NOTE: If Infrastructure Architecture Document is missing, HALT and request: "I need the Infrastructure Architecture Document to proceed with platform implementation. This document defines the infrastructure design that we'll be implementing."
3. Validate that the infrastructure architecture has been reviewed and approved
4. <critical_rule>All platform implementation must align with the approved infrastructure architecture. Any deviations require architect approval.</critical_rule>
Output file location: `docs/platform-infrastructure/platform-implementation.md`
- id: executive-summary
@ -113,7 +113,7 @@ sections:
# Example Terraform for VPC setup
module "vpc" {
source = "./modules/vpc"
cidr_block = "{{vpc_cidr}}"
availability_zones = {{availability_zones}}
public_subnets = {{public_subnets}}
@ -508,7 +508,7 @@ sections:
// K6 Load Test Example
import http from 'k6/http';
import { check } from 'k6';
export let options = {
stages: [
{ duration: '5m', target: {{target_users}} },
@ -622,8 +622,8 @@ sections:
instruction: Final Review - Ensure all platform layers are properly implemented, integrated, and documented. Verify that the implementation fully supports the BMAD methodology and all agent workflows. Confirm successful validation against the infrastructure checklist.
content: |
---
_Platform Version: 1.0_
_Implementation Date: {{implementation_date}}_
_Next Review: {{review_date}}_
_Approved by: {{architect_name}} (Architect), {{devops_name}} (DevOps/Platform Engineer)_
_Approved by: {{architect_name}} (Architect), {{devops_name}} (DevOps/Platform Engineer)_

134
tmp/rules/00-ClineMemoryBank.md
View File

@ -1,134 +0,0 @@
# Cline's Memory Bank
I am Cline, an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.
## Memory Bank Structure
The Memory Bank consists of core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
```mermaid
flowchart TD
PB[projectbrief.md] --> PC[productContext.md]
PB --> SP[systemPatterns.md]
PB --> TC[techContext.md]
PC --> AC[activeContext.md]
SP --> AC
TC --> AC
AC --> P[progress.md]
```
### Core Files (Required)
1. `projectbrief.md`
- Foundation document that shapes all other files
- Created at project start if it doesn't exist
- Defines core requirements and goals
- Source of truth for project scope
2. `productContext.md`
- Why this project exists
- Problems it solves
- How it should work
- User experience goals
3. `activeContext.md`
- Current work focus
- Recent changes
- Next steps
- Active decisions and considerations
- Important patterns and preferences
- Learnings and project insights
4. `systemPatterns.md`
- System architecture
- Key technical decisions
- Design patterns in use
- Component relationships
- Critical implementation paths
5. `techContext.md`
- Technologies used
- Development setup
- Technical constraints
- Dependencies
- Tool usage patterns
6. `progress.md`
- What works
- What's left to build
- Current status
- Known issues
- Evolution of project decisions
### Additional Context
Create additional files/folders within memory-bank/ when they help organize:
- Complex feature documentation
- Integration specifications
- API documentation
- Testing strategies
- Deployment procedures
## Core Workflows
### Plan Mode
```mermaid
flowchart TD
Start[Start] --> ReadFiles[Read Memory Bank]
ReadFiles --> CheckFiles{Files Complete?}
CheckFiles -->|No| Plan[Create Plan]
Plan --> Document[Document in Chat]
CheckFiles -->|Yes| Verify[Verify Context]
Verify --> Strategy[Develop Strategy]
Strategy --> Present[Present Approach]
```
### Act Mode
```mermaid
flowchart TD
Start[Start] --> Context[Check Memory Bank]
Context --> Update[Update Documentation]
Update --> Execute[Execute Task]
Execute --> Document[Document Changes]
```
## Documentation Updates
Memory Bank updates occur when:
1. Discovering new project patterns
2. After implementing significant changes
3. When user requests with **update memory bank** (MUST review ALL files)
4. When context needs clarification
```mermaid
flowchart TD
Start[Update Process]
subgraph Process
P1[Review ALL Files]
P2[Document Current State]
P3[Clarify Next Steps]
P4[Document Insights & Patterns]
P1 --> P2 --> P3 --> P4
end
Start --> Process
```
Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md and progress.md as they track current state.
REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.

163
tmp/rules/01-ProjectGuidelines.md
View File

@ -1,163 +0,0 @@
# Project Guidelines
> **Scope:** This document outlines high-level, project-specific guidelines, policies, and standards unique to this project. It serves as the primary entry point to the rule system, linking to more detailed principles in other files. For universal coding principles, see `02-CoreCodingPrinciples.md`. For mandatory file structure, see `03-ProjectScaffoldingRules.md`. For cloud-native development, see `04-TwelveFactorApp.md`. For our service architecture, see `05-MicroServiceOrientedArchitecture.md`.
## Documentation Requirements
- Update relevant documentation in /docs when modifying features
- Keep README.md in sync with new capabilities
- Maintain changelog entries in CHANGELOG.md
## Documentation Discipline
- All major changes must be reflected in README, ADRs, dev journals, and changelogs.
- Use and maintain templates for sprint reviews and journal entries.
- Document onboarding steps, environment requirements, and common pitfalls in README files.
## Accessibility & Inclusion
- All UI components must meet WCAG 2.1 AA accessibility standards.
- Ensure sufficient color contrast, keyboard navigation, and screen reader support.
- Use inclusive language in documentation and user-facing text.
- Accessibility must be tested as part of code review and release.
## Architecture
- This project follows a **Microservice-Oriented Architecture**.
- All development must adhere to the principles outlined in `04-TwelveFactorApp.md` for cloud-native compatibility and `05-MicroServiceOrientedArchitecture.md` for service design and implementation patterns.
## Architecture Decision Records
Create ADRs in /docs/adr for:
- Major dependency changes
- Architectural pattern changes
- New integration patterns
- Database schema changes
Follow template in /docs/adr/template.md
## Code Style & Patterns
- Generate API clients using OpenAPI Generator
- Use TypeScript axios template
- Place generated code in /src/generated
- Prefer composition over inheritance
- Use repository pattern for data access
- Follow error handling pattern in /src/utils/errors.ts
## REST API Implementation
- REST endpoints must follow the `CustomEndpointDelegate` pattern and reside in package-scoped Groovy files.
- Always declare the package at the top of each endpoint file.
- Configure REST script roots and packages via environment variables for auto-discovery.
## Testing Standards
- Unit tests required for business logic
- Integration tests for API endpoints
- E2E tests for critical user flows
## Testing & Data Utilities
- All critical endpoints and data utilities must have integration tests.
- Synthetic data scripts must be idempotent, robust, and never modify migration tracking tables.
- Document the behavior and safety of all data utility scripts.
## Security & Performance Considerations
- **Input Validation (IV):** All external data must be validated before processing.
- **Resource Management (RM):** Close connections and free resources appropriately.
- **Constants Over Magic Values (CMV):** No magic strings or numbers. Use named constants.
- **Security-First Thinking (SFT):** Implement proper authentication, authorization, and data protection.
- **Performance Awareness (PA):** Consider computational complexity and resource usage.
- Rate limit all api endpoints
- Use row level security always (RLS)
- Captcha on all auth routes/signup pages
- If using hosting solution like vercel, enable attack challenge on their WAF
- DO NOT read or modify, without prior approval by user:
- .env files
- \*_/config/secrets._
- Any file containing API keys or credentials
## Security & Quality Automation
- Integrate Semgrep for static analysis and security scanning in all projects.
- Use MegaLinter (or equivalent) for multi-language linting and formatting.
- Supplement with language/framework-specific linters (e.g., ESLint for JS/TS, flake8 for Python, RuboCop for Ruby).
- All linting and static analysis tools must be run in CI/CD pipelines; merges are blocked on failure.
- Linter and static analysis configurations must be version-controlled and documented at the project root.
- Regularly review and update linter/analysis rules to address new threats and maintain code quality.
- Document and version-control all ignore rules and linter configs.
- CI checks must pass before merging any code.
## Miscellaneous recommendations
- Always prefer simple solutions
- Avoid duplication of code whenever possible, which means checking for other areas of the codebase that might already have similar code and functionality
- Write code that takes into account the different environments: dev, test, and prod
- You are careful to only make changes that are requested or you are confident are well understood and related to the change being requested
- When fixing an issue or bug, do not introduce a new pattern or technology without first exhausting all options for the existing implementation. And if you finally do this, make sure to remove the old implementation afterwards so we don't have duplicate logic.
- Keep the codebase very clean and organized
- Avoid writing scripts in files if possible, especially if the script is likely only to be run once
- Avoid having files over 200-300 lines
## Project Structure
- Avoid unnecessary plugin or build complexity; prefer script-based, automatable deployment.
- Mocking data is only needed for tests, never mock data for dev or prod
- Never add stubbing or fake data patterns to code that affects the dev or prod environments
- Never overwrite my .env file without first asking and confirming
## Automation & CI/CD
- All code must pass linting and formatting checks in CI before merge.
- CI must run all tests (unit, integration, E2E) and block merges on failure.
- Add new linters or formatters only with team consensus.
## Local Development Environment
- Use Podman or Docker and Ansible for local environment setup.
- Provide wrapper scripts for starting, stopping, and resetting the environment; avoid direct Ansible or container CLI usage.
- Ensure all environment configuration is version-controlled.
## Branching & Release Policy
- Follow [your branching model, e.g. Git Flow or trunk-based] for all work.
- Use semantic versioning for releases.
- Release branches must be code-frozen and pass all CI checks before tagging.
## Incident Response
- Maintain an incident log documenting bugs, outages, and recovery actions.
- After any incident, hold a retrospective and update runbooks as needed.
- Critical incidents must be reviewed in the next team meeting.
## Data Privacy & Compliance
- All data handling must comply with applicable privacy laws (e.g., GDPR, CCPA).
- Never log or store sensitive data insecurely.
- Review and document data flows for compliance annually.
## Database Migration & Change Management
- Use a dedicated, automated migration tool (e.g., Liquibase, Flyway) for all schema changes.
- Store all migration scripts under version control, alongside application code.
- All environments (dev, test, prod) must be migrated using the same process and scripts.
- Manual, ad-hoc schema changes are prohibited.
- All migrations must be documented with rationale and expected outcomes.
## Database Management & Documentation
- Maintain an up-to-date Entity Relationship Diagram (ERD).
- Use templates for documenting schema changes, migrations, and rationale.
- Document all reference data and non-obvious constraints.
- Maintain a changelog for all database changes.
- Review and update database documentation as part of the development workflow.
## Database Naming Conventions
- Use clear, consistent, and project-wide naming conventions for tables, columns, indexes, and constraints.
- Prefer snake_case for all identifiers.
- Prefix/suffix conventions must be documented (e.g., `tbl_` for tables, `_fk` for foreign keys).
- Avoid reserved words and ambiguous abbreviations.
- Enforce naming conventions in code review and automated linting where possible.

82
tmp/rules/02-CoreCodingPrinciples.md
View File

@ -1,82 +0,0 @@
# Core Coding Principles
> **Scope:** This document defines the core, universal, and project-agnostic engineering principles that apply to all development work. These are the fundamental rules of good software craftsmanship, independent of any specific project.
## Core Coding Principles
- [SF] **Simplicity First:** Always choose the simplest viable solution. Complex patterns or architectures require explicit justification.
- [RP] **Readability Priority:** Code must be immediately understandable by both humans and AI during future modifications.
- [DM] **Dependency Minimalism:** No new libraries or frameworks without explicit request or compelling justification.
- [ISA] **Industry Standards Adherence:** Follow established conventions for the relevant language and tech stack.
- [SD] **Strategic Documentation:** Comment only complex logic or critical functions. Avoid documenting the obvious.
- [TDT] **Test-Driven Thinking:** Design all code to be easily testable from inception.
## Dependency Management
- [DM-1] Review third-party dependencies for vulnerabilities at least quarterly.
- [DM-2] Prefer signed or verified packages.
- [DM-3] Remove unused or outdated dependencies promptly.
- [DM-4] Document dependency updates in the changelog.
## Coding workflow preferences
- [WF-FOCUS] Focus on the areas of code relevant to the task
- [WF-SCOPE] Do not touch code that is unrelated to the task
- [WF-TEST] Write thorough tests for all major functionality
- [WF-ARCH] Avoid making major changes to the patterns and architecture of how a feature works, after it has shown to work well, unless explicitly structured
- [WF-IMPACT] Always think about what other methods and areas of code might be affected by code changes
## Workflow Standards
- [AC] **Atomic Changes:** Make small, self-contained modifications to improve traceability and rollback capability.
- [CD] **Commit Discipline:** Recommend regular commits with semantic messages using conventional commit format:
```
type(scope): concise description
[optional body with details]
[optional footer with breaking changes/issue references]
```
Types: feat, fix, docs, style, refactor, perf, test, chore
Adhere to the ConventionalCommit specification: <https://www.conventionalcommits.org/en/v1.0.0/#specification>
- [TR] **Transparent Reasoning:** When generating code, explicitly reference which global rules influenced decisions.
- [CWM] **Context Window Management:** Be mindful of AI context limitations. Suggest new sessions when necessary.
## Code Quality Guarantees
- [DRY] **DRY Principle:** No duplicate code. Reuse or extend existing functionality.
- [CA] **Clean Architecture:** Generate cleanly formatted, logically structured code with consistent patterns.
- [REH] **Robust Error Handling:** Integrate appropriate error handling for all edge cases and external interactions.
- [CSD] **Code Smell Detection:** Proactively identify and suggest refactoring for:
- Functions exceeding 30 lines
- Files exceeding 300 lines
- Nested conditionals beyond 2 levels
- Classes with more than 5 public methods
## Security & Performance Considerations
- [IV] **Input Validation:** All external data must be validated before processing.
- [RM] **Resource Management:** Close connections and free resources appropriately.
- [CMV] **Constants Over Magic Values:** No magic strings or numbers. Use named constants.
- [SFT] **Security-First Thinking:** Implement proper authentication, authorization, and data protection.
- [PA] **Performance Awareness:** Consider computational complexity and resource usage.
- [RL] Rate limit all API endpoints.
- [RLS] Use row-level security always (RLS).
- [CAP] Captcha on all auth routes/signup pages.
- [WAF] If using hosting solution like Vercel, enable attack challenge on their WAF.
- [SEC-1] **DO NOT** read or modify, without prior approval by user:
- .env files
- \*_/config/secrets._
- Any file containing API keys or credentials
## AI Communication Guidelines
- [RAT] **Rule Application Tracking:** When applying rules, tag with the abbreviation in brackets (e.g., [SF], [DRY]).
- [EDC] **Explanation Depth Control:** Scale explanation detail based on complexity, from brief to comprehensive.
- [AS] **Alternative Suggestions:** When relevant, offer alternative approaches with pros/cons.
- [KBT] **Knowledge Boundary Transparency:** Clearly communicate when a request exceeds AI capabilities or project context.

35
tmp/rules/03-ProjectScaffoldingRules.md
View File

@ -1,35 +0,0 @@
# Project Scaffolding Rules
> **Scope:** This document defines the mandatory file and folder structure for the project. Adherence to this structure is required to ensure consistency and support automated tooling.
## Project structure
The project should include the following files and folders:
- a .clineignore file
- a .gitignore file primed for a regular project managed with CLINE in Microsoft VSCode
- a generic readme.md file
- a blank .gitattributes file
- a license file
- /.clinerules/rules folder to include all project specific rules for the CLINE extension
- /.clinerules/workflows folder to include all project specific workflows for the CLINE extension
- /.windsurf/rules/ folder to include all project specific rules for the Windsurf extension
- /.windsurf/workflows/ folder to include all project specific workflows for the Windsurf extension
- a docs/adr folder to include all project specific Architectural Decisions Records (ADRs)
- a docs/devJournal folder to include all project specific development journals
- a docs/roadmap folder to include all project roadmap and features description
- a docs/roadmap/features folder to include all project specific features and their technical, functional and non-functional requirements (Including UX-UI)
- an src/app folder to include the frontend components of the solution
- an src/api folder to include the backend components of the solution
- an src/utils folder to include the share utilities components of the solution
- an src/tests folder to include the tests components of the solution
- an src/tests/e2e folder to include the end-to-end tests components of the solution
- an src/tests/postman folder to include the postman tests for the API components of the solution
- a db folder to include the database components of the solution
- a db/liquibase folder to include the liquibase components of the solution
- a local-dev-setup folder to include the local development setup components of the solution

99
tmp/rules/04-TwelveFactorApp.md
View File

@ -1,99 +0,0 @@
_Scope: This document provides the definitive, consolidated set of rules based on the Twelve-Factor App methodology. These principles are mandatory for ensuring our applications are built as scalable, resilient, and maintainable cloud-native services._
# The Consolidated Twelve-Factor App Rules for an AI Agent
**I. Codebase**
- A single, version-controlled codebase (e.g., in Git) must represent one and only one application.
- All code you generate, manage, or refactor for a specific application must belong to this single codebase.
- Shared functionality across applications must be factored into versioned libraries and managed via a dependency manager.
- This single codebase is used to produce multiple deploys (e.g., development, staging, production).
**II. Dependencies**
- You must explicitly declare all application dependencies via a manifest file (e.g., `requirements.txt`, `package.json`, `pom.xml`).
- Never rely on the implicit existence of system-wide packages or tools. The application must run in an isolated environment where only explicitly declared dependencies are available.
**III. Config**
- A strict separation between code and configuration must be enforced.
- All configuration that varies between deploys (credentials, resource handles, hostnames) must be read from environment variables.
- Never hardcode environment-specific values in the source code you generate. The codebase must be runnable anywhere provided the correct environment variables are set.
**IV. Backing Services**
- All backing services (databases, message queues, caches, external APIs, etc.) must be treated as attached, swappable resources.
- Connect to all backing services via locators/credentials stored in the configuration (environment variables). The code must be agnostic to whether a service is local or third-party.
**V. Build, Release, Run**
- Maintain a strict, three-stage separation:
- **Build:** Converts the code repo into an executable bundle.
- **Release:** Combines the build with environment-specific config.
- **Run:** Executes the release in the target environment.
- Releases must be immutable and have unique IDs. Any change to code or config must create a new release. You must not generate code that attempts to modify itself at runtime.
**VI. Processes**
- Design the application to execute as one or more stateless, share-nothing processes.
- Any data that needs to persist must be stored in a stateful backing service (e.g., a database). Never assume that local memory or disk state is available across requests or between process restarts.
**VII. Port Binding**
- The application must be self-contained and export its services (e.g., HTTP) by binding to a port specified via configuration. Do not rely on runtime injection of a webserver (e.g., as a module in Apache).
**VIII. Concurrency**
- Design the application to scale out horizontally by adding more concurrent processes.
- Assign different workload types to different process types (e.g., `web`, `worker`).
- Rely on a process manager (e.g., systemd, Foreman, Kubernetes) for process lifecycle management, logging, and crash recovery.
**IX. Disposability**
- Processes must be disposable, meaning they can be started or stopped at a moment's notice.
- Strive for minimal startup time to facilitate fast elastic scaling and deployments.
- Ensure graceful shutdown on `SIGTERM`, finishing any in-progress work before exiting.
- Design processes to be robust against sudden death (crash-only design).
**X. Dev/Prod Parity**
- Keep development, staging, and production environments as similar as possible.
- This applies to the type and version of the programming language, system tooling, and all backing services.
**XI. Logs**
- Treat logs as event streams. Never write to or manage log files directly from the application.
- Each process must write its event stream, unbuffered, to standard output (`stdout`).
- The execution environment is responsible for collecting, aggregating, and routing these log streams for storage and analysis.
**XII. Admin Processes**
- Run administrative and management tasks (e.g., database migrations, one-off scripts) as one-off processes in an environment identical to the main application's long-running processes.
- Admin scripts must be shipped with the application code and use the same dependency and configuration management to avoid synchronization issues.
# Additional Consolidated Project Rules
**Onboarding & Knowledge Transfer**
- Maintain up-to-date onboarding guides and “How To” docs for new contributors and AI agents.
- All major workflows must have step-by-step documentation.
- Encourage new team members to suggest improvements to onboarding materials.
**AI/Agent Safeguards**
- All AI-generated code must be reviewed by a human before deployment to production.
- Escalate ambiguous or risky decisions to a human for approval.
- Log all significant AI-suggested changes for auditability.
- Never overwrite an `.env` file without first asking and confirming.
**Continuous Improvement**
- Hold regular retrospectives to review rules, workflows, and documentation.
- Encourage all contributors to provide feedback and suggest improvements.
- Update rules and workflows based on lessons learned.
**Environmental Sustainability**
- Optimize compute resources and minimize waste in infrastructure choices.
- Prefer energy-efficient solutions where practical.
- Consider environmental impact in all major technical decisions.

35
tmp/rules/05-MicroServiceOrientedArchitecture.md
View File

@ -1,35 +0,0 @@
_Scope: This document outlines the specific patterns and strategies for implementing our Microservice-Oriented Architecture, based on Chris Richardson's "Microservices Patterns". It builds upon the foundational principles in `04-TwelveFactorApp.md` and provides a detailed guide for service design, decomposition, communication, and data management._
Observe the principles set by the book "Microservices Patterns" by Chris Richardson.
### Microservice Patterns & Principles (with Trigram Codes)
- [MON] **Monolithic Architecture:** Structures an application as a single, unified deployable unit. Good for simple applications, but becomes "monolithic hell" as complexity grows.
- [MSA] **Microservice Architecture:** Structures an application as a collection of small, autonomous, and loosely coupled services. This is the core pattern the rest of the book builds upon.
- [DBC] **Decompose by Business Capability:** Define services based on what a business _does_ (e.g., Order Management, Inventory Management) to create stable service boundaries.
- [DSD] **Decompose by Subdomain:** Use Domain-Driven Design (DDD) to define services around specific problem subdomains, aligning service boundaries with the business domain model.
- [RPI] **Remote Procedure Invocation:** A client invokes a service using a synchronous, request/response protocol like REST or gRPC. Simple and familiar but creates tight coupling and can reduce availability.
- [MSG] **Messaging:** Services communicate asynchronously by exchanging messages via a message broker. This promotes loose coupling and improves resilience.
- [CBR] **Circuit Breaker:** Prevents a network or service failure from cascading. After a number of consecutive failures, the breaker trips, and further calls fail immediately.
- [SDC] **Service Discovery:** Patterns for how a client service can find the network location of a service instance in a dynamic cloud environment (self/3rd party registration, client/server-side discovery).
- [DPS] **Database per Service:** Each microservice owns its own data and is solely responsible for it. Fundamental to loose coupling; requires new transaction management strategies.
- [SAG] **Saga:** Master pattern for managing data consistency across services without distributed transactions. Sequence of local transactions, each triggering the next via events/messages, with compensating transactions on failure.
- [OUT] **Transactional Outbox / Polling Publisher / Transaction Log Tailing:** Reliably publish messages/events as part of a local database transaction, ensuring no messages are lost if a service crashes after updating its database but before sending the message.
- [DOM] **Domain Model:** Classic object-oriented approach with classes containing both state and behaviour. Preferred for complex logic.
- [TSF] **Transaction Script:** Procedural approach where a single procedure handles a single request. Simpler, but unmanageable for complex logic.
- [AGG] **Aggregate:** A cluster of related domain objects treated as a single unit, with a root entity. Transactions only ever create or update a single aggregate.
- [DME] **Domain Events:** Aggregates publish events when their state changes. Foundation for event-driven architectures, sagas, and data replication.
- [EVS] **Event Sourcing:** Store the sequence of state-changing events rather than the current state. The current state is derived by replaying events, providing a reliable audit log and simplifying event publishing.
- [APC] **API Composition:** A client (or API Gateway) retrieves data from multiple services and joins it in memory. Simple for basic queries, inefficient for complex joins across large datasets.
- [CQR] **Command Query Responsibility Segregation (CQRS):** Maintain one or more denormalised, read-optimised "view" databases kept up-to-date by subscribing to events from the services that own the data. Separates the command-side (write) from the query-side (read) model.
- [APG] **API Gateway:** A single entry point for all external clients. Routes requests to backend services, can perform API composition, and handles cross-cutting concerns like authentication.
- [BFF] **Backends for Frontends:** A variation of the API Gateway pattern where you have a separate, tailored API gateway for each specific client (e.g., mobile app, web app).
- [CDC] **Consumer-Driven Contract Test:** A test written by the _consumer_ of a service to verify that the _provider_ meets its expectations, ensuring correct communication without slow, brittle end-to-end tests.
- [SCT] **Service Component Test:** Acceptance test for a single service in isolation, using stubs for external dependencies.
- [SVC] **Service as a Container:** Package a service as a container image (e.g., Docker) to encapsulate its technology stack.
- [SRL] **Serverless Deployment:** Deploy services using a platform like AWS Lambda that abstracts away the underlying infrastructure.
- [MSC] **Microservice Chassis:** A framework (e.g., Spring Boot + Spring Cloud) that handles cross-cutting concerns such as config, health checks, metrics, and distributed tracing.
- [SMH] **Service Mesh:** Infrastructure layer (e.g., Istio, Linkerd) that handles inter-service communication concerns like circuit breakers, distributed tracing, and load balancing outside of service code.
- [STR] **Strangler Application:** Strategy for migrating a monolith. Incrementally build new microservices around the monolith, gradually replacing it and avoiding a "big bang" rewrite.
More at <https://microservices.io/patterns/>

60
tmp/workflows/api-tests-specs-update.md
View File

@ -1,60 +0,0 @@
---
description: The definitive workflow for safely updating API specifications and generating Postman tests to ensure 100% consistency and prevent data loss.
---
# Workflow: API Spec & Test Generation
This workflow establishes `openapi.yaml` as the single source of truth for all API development. The Postman collection is **always generated** from this file. **NEVER edit the Postman JSON file directly.** This prevents inconsistencies and the kind of file corruption we have experienced.
## Guiding Principles
- **OpenAPI is the ONLY Source of Truth:** All API changes begin and end with `docs/api/openapi.yaml`.
- **Postman is a GENERATED ARTIFACT:** The collection file is treated as build output. It is never edited by hand.
- **Validate Before Generating:** Always validate the OpenAPI spec _before_ attempting to generate the Postman collection.
## Steps
### 1. Update the OpenAPI Specification (`docs/api/openapi.yaml`)
- **Identify API Changes:** Review the Groovy source code (e.g., `src/com/umig/api/v2/*.groovy`) to identify any new, modified, or removed endpoints.
- **Edit the Spec:** Carefully add, modify, or remove the corresponding endpoint definitions under `paths` and schemas under `components/schemas`.
- **Best Practice:** Use `allOf` to extend existing schemas non-destructively (e.g., adding audit fields to a base `User` schema).
- **Use an IDE with OpenAPI support** to get real-time linting and validation.
### 2. Validate the OpenAPI Specification
- **CRITICAL:** Before proceeding, validate your `openapi.yaml` file.
- Use your IDE's built-in OpenAPI preview or a dedicated linter.
- **DO NOT proceed if the file has errors.** Fix them first. This is the most important step to prevent downstream issues.
### 3. Generate the Postman Collection
- **Navigate to the correct directory** in your terminal. The command must be run from here:
```bash
cd docs/api/postman
```
- **Run the generation command:**
```bash
// turbo
npx openapi-to-postmanv2 -s ../openapi.yaml -o ./UMIG_API_V2_Collection.postman_collection.json -p -O folderStrategy=Tags
```
- **Note on `npx`:** The `npx` command runs the `openapi-to-postmanv2` package without requiring a global installation. If you see `command not found`, ensure you are using `npx`.
### 4. Verify the Changes
- **Review the Diff:** Use `git diff` to review the changes to `UMIG_API_V2_Collection.postman_collection.json`. Confirm that the new endpoint has been added and that no unexpected changes have occurred.
- **Test in Postman:** (Optional but recommended) Import the newly generated collection into Postman and run a few requests against a local dev environment to ensure correctness.
### 5. Document and Commit
- **Commit all changes:** Add the modified `openapi.yaml` and the generated `UMIG_API_V2_Collection.postman_collection.json` to your commit.
- **Update Changelog:** Add an entry to `CHANGELOG.md` detailing the API changes.
- **Update Dev Journal:** Create a developer journal entry summarizing the work done.scribe any removals or replacements and the rationale.
---
**Key Principles:**
- Never erase or overwrite existing tests/specs unless required by an API change.
- Every endpoint in the API must be present and tested in both Postman and OpenAPI.
- Consistency, completeness, and traceability are paramount.

44
tmp/workflows/api-work.md
View File

@ -1,44 +0,0 @@
---
description: The standard workflow for creating or modifying Groovy REST API endpoints in this project.
---
This workflow ensures all API development adheres to the project's established, stable patterns to prevent bugs and maintain consistency.
## Key Reference Documents
**PRIMARY REFERENCE**: `/docs/solution-architecture.md` — Comprehensive solution architecture and API design standards
**SUPPORTING REFERENCES**:
- Current ADRs in `/docs/adr/` (skip `/docs/adr/archive/` - consolidated in solution-architecture.md)
- Working examples: `src/com/umig/api/v2/TeamsApi.groovy`
1. **Analyze the Existing Pattern**:
- Before writing any code, thoroughly review a working, stable API file like `src/com/umig/api/v2/TeamsApi.groovy`.
- Pay close attention to the structure: separate endpoint definitions for each HTTP method, simple `try-catch` blocks for error handling, and standard `javax.ws.rs.core.Response` objects.
2. **Replicate the Pattern**:
- Create a new endpoint definition for each HTTP method (`GET`, `POST`, `PUT`, `DELETE`).
- Do NOT use a central dispatcher, custom exception classes, or complex helper methods for error handling. Keep all logic within the endpoint method.
3. **Implement Business Logic**:
- Write the core business logic inside a `try` block.
- Call the appropriate `UserRepository` or `TeamRepository` methods.
4. **Handle Success Cases**:
- For `GET`, `POST`, and `PUT`, return a `Response.ok()` or `Response.status(Response.Status.CREATED)` with a `JsonBuilder` payload.
- **CRITICAL**: For a successful `DELETE`, always return `Response.noContent().build()`. Do NOT attempt to return a body.
5. **Handle Error Cases**:
- Use `catch (SQLException e)` to handle specific database errors (e.g., foreign key violations `23503`, unique constraint violations `23505`).
- Use a generic `catch (Exception e)` for all other unexpected errors.
- In all `catch` blocks, log the error using `log.error()` or `log.warn()` and return an appropriate `Response.status(...)` with a simple JSON error message.
6. **Validate Inputs**:
- Strictly validate all incoming data (path parameters, request bodies) at the beginning of the endpoint method.
- Return a `400 Bad Request` for any invalid input.

162
tmp/workflows/commit.md
View File

@ -1,162 +0,0 @@
---
description: This is the basic workflow to gather last changes, prepare a relevant commit message and commit the staged code changes
---
This workflow guides the creation of a high-quality, comprehensive commit message that accurately reflects all staged changes, adhering strictly to the Conventional Commits 1.0 standard.
**1. Comprehensive Evidence Gathering (MANDATORY - Prevent tunnel vision):**
**1.1. Staged Changes Analysis:**
- **Detailed Diff Review:** Run `git diff --staged --stat` to get both summary and detailed view of all staged changes.
- **File-by-File Analysis:** Run `git diff --staged --name-status` to see the operation type (Modified, Added, Deleted) for each file.
- **Functional Area Classification:** Group staged files by functional area:
- **API Changes:** `src/groovy/umig/api/`, `src/groovy/umig/repository/`
- **UI Changes:** `src/groovy/umig/web/js/`, `src/groovy/umig/web/css/`, `src/groovy/umig/macros/`
- **Documentation:** `docs/`, `README.md`, `CHANGELOG.md`, `*.md` files
- **Tests:** `src/groovy/umig/tests/`, `local-dev-setup/__tests__/`
- **Configuration:** `local-dev-setup/liquibase/`, `*.json`, `*.yml`, `*.properties`
- **Database:** Migration files, schema changes
- **Change Type Analysis:** For each file, determine the type of change:
- New functionality added
- Existing functionality modified
- Bug fixes
- Refactoring or code cleanup
- Documentation updates
- Test additions or modifications
**1.2. Unstaged and Untracked Files Review:**
- **Related Files Check:** Run `git status --porcelain` to identify any untracked or unstaged files that might be related.
- **Completeness Verification:** Ensure all related changes are staged or deliberately excluded.
- **User Prompt:** If potentially related files are unstaged, prompt the user about inclusion.
**1.3. Work Stream Identification:**
- **Primary Work Stream:** Identify the main type of work being committed.
- **Secondary Work Streams:** Identify supporting changes (e.g., tests, documentation, configuration).
- **Cross-Functional Impact:** Note changes that span multiple functional areas.
- **Architecture Impact:** Identify any architectural or pattern changes.
**2. Multi-Context Rationale Analysis (MANDATORY - Address tunnel vision):**
**2.1. Session Context Review:**
- **Conversation Timeline:** Review the entire session conversation to understand the evolution of the work.
- **Initial Problem:** Identify the original problem or task that initiated the changes.
- **Decision Points:** Note key decisions made during the session that influenced the implementation.
- **Scope Evolution:** If the work expanded beyond the initial scope, understand how and why.
**2.2. Development Context:**
- **Dev Journal Review:** If a development journal entry was created during the session, review it for high-level narrative.
- **Related Work:** Check if this commit is part of a larger feature or bug fix spanning multiple commits.
- **Previous Commits:** Review recent commits to understand the progression of work.
**2.3. Business and Technical Context:**
- **Business Impact:** Understand what user-facing or system benefits this change provides.
- **Technical Motivation:** Identify the technical reasons for the changes (performance, maintainability, new features).
- **Problem-Solution Mapping:** For each work stream, clearly understand:
- What problem was being solved
- Why this particular solution was chosen
- What alternatives were considered
- What the outcome achieves
**2.4. Change Dependencies:**
- **Cross-Stream Dependencies:** How different work streams in this commit depend on each other.
- **External Dependencies:** Any external factors that influenced the changes.
- **Future Implications:** What this change enables or constrains for future development.
**3. Multi-Stream Commit Message Synthesis (MANDATORY - Address tunnel vision):**
The goal is to create a message that comprehensively explains all changes and their context for future developers.
**3.1. Type and Scope Selection:**
- **Primary Type:** Choose the most significant type from the allowed list (`feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`).
- **Multi-Stream Consideration:** If multiple significant work streams exist, choose the type that best represents the overall impact.
- **Scope Selection:** Identify the primary part of the codebase affected:
- **Specific Components:** `api`, `ui`, `db`, `auth`, `docs`, `tests`
- **Functional Areas:** `admin`, `migration`, `iteration`, `planning`
- **System-Wide:** Use broader scopes for cross-cutting changes
**3.2. Subject Line Construction:**
- **Imperative Mood:** Write a concise summary (under 50 characters) in imperative mood.
- **Multi-Stream Subject:** If multiple work streams are significant, write a subject that captures the overall achievement.
- **Specific vs General:** Balance specificity with comprehensiveness.
**3.3. Body Structure (Enhanced for Multi-Stream):**
- **Primary Change Description:** Start with the main change and its motivation.
- **Work Stream Breakdown:** For each significant work stream:
- **What Changed:** Specific files, components, or functionality
- **Why Changed:** Problem being solved or improvement being made
- **How Changed:** Technical approach or implementation details
- **Impact:** What this enables or improves
- **Cross-Stream Integration:** How different work streams work together.
- **Technical Decisions:** Explain significant design choices and why alternatives were rejected.
- **Context:** Provide enough context for future developers to understand the change.
**3.4. Footer Considerations:**
- **Breaking Changes:** Use `BREAKING CHANGE:` for any breaking changes with migration notes.
- **Issue References:** Reference related issues (e.g., `Closes #123`, `Relates to #456`).
- **Co-authorship:** Add `Co-Authored-By:` for pair programming or AI assistance.
**3.5. Message Assembly:**
- **Single Coherent Story:** Weave multiple work streams into a single, coherent narrative.
- **Logical Flow:** Organize information in a logical sequence that makes sense to readers.
- **Appropriate Detail:** Include enough detail to understand the change without overwhelming.
**4. Anti-Tunnel Vision Verification (MANDATORY - Use before finalizing):**
Before presenting the commit message, verify you have addressed ALL of the following:
**Content Coverage:**
- [ ] All staged files are explained in the commit message
- [ ] All functional areas touched are documented
- [ ] All work streams are identified and described
- [ ] Change types (feat/fix/docs/etc.) are accurately represented
- [ ] Cross-functional impacts are noted
**Technical Completeness:**
- [ ] Code changes include rationale for the approach taken
- [ ] API changes are summarized with impact
- [ ] UI changes are explained with user impact
- [ ] Database changes include migration details
- [ ] Configuration changes are noted
- [ ] Test changes are explained
**Context and Rationale:**
- [ ] Original problem or motivation is clearly stated
- [ ] Solution approach is justified
- [ ] Technical decisions are explained
- [ ] Alternative approaches are noted (if relevant)
- [ ] Future implications are considered
**Message Quality:**
- [ ] Subject line is under 50 characters and imperative mood
- [ ] Body explains "what" and "why" for each work stream
- [ ] Information is organized in logical flow
- [ ] Appropriate level of detail for future developers
- [ ] Conventional Commits format is followed
**Completeness Verification:**
- [ ] All evidence from steps 1-2 is reflected in the message
- [ ] No significant work is missing from the description
- [ ] Multi-stream nature is properly represented
- [ ] Session context is appropriately captured
**5. Await Confirmation and Commit:**
- Present the generated commit message to the user for review.
- After receiving confirmation, execute the `git commit` command.

Some files were not shown because too many files have changed in this diff Show More