Compare commits

...

22 Commits

Author SHA1 Message Date
semantic-release-bot
8cf9e5d916 chore(release): 4.14.0 [skip ci]
# [4.14.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.13.0...v4.14.0) (2025-06-25)

### Features

* enhance QA agent as senior developer with code review capabilities and major brownfield improvements ([3af3d33](3af3d33d4a))
2025-06-25 04:57:50 +00:00
Brian Madison
3af3d33d4a feat: enhance QA agent as senior developer with code review capabilities and major brownfield improvements
This release introduces significant enhancements across multiple areas:

QA Agent Transformation:
- Transform QA agent into senior developer role with active code refactoring abilities
- Add review-story task enabling QA to review, refactor, and improve code directly
- Integrate QA review step into standard development workflow (SM → Dev → QA)
- QA can fix small issues directly and leave checklist for remaining items
- Updated dev agent to maintain File List for QA review focus

Knowledge Base Improvements:
- Add extensive brownfield development documentation and best practices
- Clarify Web UI vs IDE usage with cost optimization strategies
- Document PRD-first approach for large codebases/monorepos
- Add comprehensive expansion packs explanation
- Update IDE workflow to include QA review step
- Clarify agent usage (bmad-master vs specialized agents)

Brownfield Enhancements:
- Create comprehensive Working in the Brownfield guide
- Add document-project task to analyst agent capabilities
- Implement PRD-first workflow option for focused documentation
- Transform document-project to create practical brownfield architecture docs
- Document technical debt, workarounds, and real-world constraints
- Reference actual files instead of duplicating content
- Add impact analysis when PRD is provided

Documentation Task Improvements:
- Simplify to always create ONE unified architecture document
- Add deep codebase analysis phase with targeted questions
- Focus on documenting reality including technical debt
- Include Quick Reference section with key file paths
- Add practical sections: useful commands, debugging tips, known issues

Workflow Updates:
- Update all 6 workflow files with detailed IDE transition instructions
- Add clear SM → Dev → QA → Dev cycle explanation
- Emphasize Gemini Web for brownfield analysis (1M+ context advantage)
- Support both PRD-first and document-first approaches

This release significantly improves the brownfield development experience and introduces a powerful shift-left QA approach with senior developer mentoring.
2025-06-24 23:56:57 -05:00
semantic-release-bot
fb0be544ad chore(release): 4.13.0 [skip ci]
# [4.13.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.12.0...v4.13.0) (2025-06-24)

### Features

* **ide-setup:** add support for Cline IDE and configuration rules ([#262](https://github.com/bmadcode/BMAD-METHOD/issues/262)) ([913dbec](913dbeced6))
2025-06-24 02:47:45 +00:00
Reider Olivér
913dbeced6 feat(ide-setup): add support for Cline IDE and configuration rules (#262) 2025-06-23 21:47:21 -05:00
Brian Madison
00a9891793 Merge branch 'main' of github.com:bmadcode/BMAD-METHOD 2025-06-22 22:11:33 -05:00
Brian Madison
47c33d6482 clarify contributing 2025-06-22 22:10:15 -05:00
Brian Madison
febe7e149d doc: clarified contributions and guiding principles to align ideals for contribution to BMad Method 2025-06-22 22:08:21 -05:00
semantic-release-bot
730d51eb95 chore(release): 4.12.0 [skip ci]
# [4.12.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.11.0...v4.12.0) (2025-06-23)

### Features

* **dev-agent:** add quality gates to prevent task completion with failing validations ([#261](https://github.com/bmadcode/BMAD-METHOD/issues/261)) ([45110ff](45110ffffe))
2025-06-23 02:49:40 +00:00
gabadi
45110ffffe feat(dev-agent): add quality gates to prevent task completion with failing validations (#261)
Issue Being Solved:
Dev agent was marking tasks as complete even when tests/lint/typecheck failed,
causing broken code to reach merge and creating technical debt.

Gap in System:
Missing explicit quality gates in dev agent configuration to block task completion
until all automated validations pass.

Solution:
- Add "Quality Gate Discipline" core principle
- Update task execution flow: Execute validations→Only if ALL pass→Update [x]
- Add "Failing validations" to blocking conditions
- Simplify completion criteria to focus on validation success

Alignment with BMAD Core Principles:
- Quality-First: Prevents defective code progression through workflow
- Agent Excellence: Ensures dev agent maintains high standards
- Technology Agnostic: Uses generic "validations" concept vs specific tools

Small, focused change that strengthens existing dev agent without architectural changes.

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

Co-authored-by: Claude <noreply@anthropic.com>
2025-06-22 21:49:18 -05:00
semantic-release-bot
c19772498a chore(release): 4.11.0 [skip ci]
# [4.11.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.3...v4.11.0) (2025-06-21)

### Bug Fixes

* resolve web bundles directory path when using relative paths in NPX installer ([5c8485d](5c8485d09f))

### Features

* add markdown-tree integration for document sharding ([540578b](540578b39d))
2025-06-21 20:26:47 +00:00
Brian Madison
540578b39d feat: add markdown-tree integration for document sharding
- Add markdownExploder setting to core-config.yml
- Update shard-doc task to use md-tree command when enabled
- Implement proper fallback handling when tool is unavailable
- Update core-config structure to remove nested wrapper
- Fix field naming to use camelCase throughout
2025-06-21 15:26:09 -05:00
Brian Madison
5c8485d09f fix: resolve web bundles directory path when using relative paths in NPX installer
When users enter "." as the installation directory, the web bundles directory
path was not being resolved correctly, causing the bundles to not be copied.
This fix ensures the web bundles directory is resolved using the same logic
as the main installation directory, resolving relative paths from the original
working directory where npx was executed.
2025-06-21 14:55:44 -05:00
Brian Madison
cd058ee7ed correct config name to source-tree in dev agent loader 2025-06-20 16:21:27 -05:00
semantic-release-bot
835075e992 chore(release): 4.10.3 [skip ci]
## [4.10.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.2...v4.10.3) (2025-06-20)

### Bug Fixes

* bundle update ([2cf3ba1](2cf3ba1ab8))
2025-06-20 04:50:24 +00:00
Brian Madison
2cf3ba1ab8 fix: bundle update 2025-06-19 23:49:57 -05:00
semantic-release-bot
f217bdf07e chore(release): 4.10.2 [skip ci]
## [4.10.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.1...v4.10.2) (2025-06-20)

### Bug Fixes

* file formatting ([c78a35f](c78a35f547))
2025-06-20 03:48:25 +00:00
Brian Madison
c78a35f547 fix: file formatting 2025-06-19 22:47:57 -05:00
Brian Madison
d619068ccc more explicity to not skip stories without asking first 2025-06-19 22:46:46 -05:00
semantic-release-bot
1e5c0b5351 chore(release): 4.10.1 [skip ci]
## [4.10.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.0...v4.10.1) (2025-06-20)

### Bug Fixes

* SM sometimes would skip the rest of the epic stories, fixed ([1148b32](1148b32fa9))
2025-06-20 03:30:30 +00:00
Brian Madison
1148b32fa9 fix: SM sometimes would skip the rest of the epic stories, fixed 2025-06-19 22:27:11 -05:00
semantic-release-bot
b07a8b367d chore(release): 4.10.0 [skip ci]
# [4.10.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.9.2...v4.10.0) (2025-06-19)

### Features

* Core Config and doc sharding is now optional in v4 ([ff6112d](ff6112d6c2))
2025-06-19 23:57:45 +00:00
Brian Madison
ff6112d6c2 feat: Core Config and doc sharding is now optional in v4 2025-06-19 18:57:19 -05:00
51 changed files with 6457 additions and 767 deletions

View File

@@ -24,6 +24,7 @@
"Immer",
"implementability",
"Inclusivity",
"kayvan",
"Luxon",
"MERN",
"mgmt",

View File

@@ -1,3 +1,64 @@
# [4.14.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.13.0...v4.14.0) (2025-06-25)
### Features
* enhance QA agent as senior developer with code review capabilities and major brownfield improvements ([3af3d33](https://github.com/bmadcode/BMAD-METHOD/commit/3af3d33d4a40586479a382620687fa99a9f6a5f7))
# [4.13.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.12.0...v4.13.0) (2025-06-24)
### Features
* **ide-setup:** add support for Cline IDE and configuration rules ([#262](https://github.com/bmadcode/BMAD-METHOD/issues/262)) ([913dbec](https://github.com/bmadcode/BMAD-METHOD/commit/913dbeced60ad65086df6233086d83a51ead81a9))
# [4.12.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.11.0...v4.12.0) (2025-06-23)
### Features
* **dev-agent:** add quality gates to prevent task completion with failing validations ([#261](https://github.com/bmadcode/BMAD-METHOD/issues/261)) ([45110ff](https://github.com/bmadcode/BMAD-METHOD/commit/45110ffffe6d29cc08e227e22a901892185dfbd2))
# [4.11.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.3...v4.11.0) (2025-06-21)
### Bug Fixes
* resolve web bundles directory path when using relative paths in NPX installer ([5c8485d](https://github.com/bmadcode/BMAD-METHOD/commit/5c8485d09ffec60ad4965ced62f4595890cb7535))
### Features
* add markdown-tree integration for document sharding ([540578b](https://github.com/bmadcode/BMAD-METHOD/commit/540578b39d1815e41e11f0e87545de3f09ee54e1))
## [4.10.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.2...v4.10.3) (2025-06-20)
### Bug Fixes
* bundle update ([2cf3ba1](https://github.com/bmadcode/BMAD-METHOD/commit/2cf3ba1ab8dd7e52584bef16a96e65e7d2513c4f))
## [4.10.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.1...v4.10.2) (2025-06-20)
### Bug Fixes
* file formatting ([c78a35f](https://github.com/bmadcode/BMAD-METHOD/commit/c78a35f547459b07a15d94c827ec05921cd21571))
## [4.10.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.0...v4.10.1) (2025-06-20)
### Bug Fixes
* SM sometimes would skip the rest of the epic stories, fixed ([1148b32](https://github.com/bmadcode/BMAD-METHOD/commit/1148b32fa97586d2f86d07a70ffbf9bb8c327261))
# [4.10.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.9.2...v4.10.0) (2025-06-19)
### Features
* Core Config and doc sharding is now optional in v4 ([ff6112d](https://github.com/bmadcode/BMAD-METHOD/commit/ff6112d6c2f822ed22c75046f5a14f05e36041c2))
## [4.9.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.9.1...v4.9.2) (2025-06-19)

View File

@@ -4,6 +4,8 @@ Thank you for considering contributing to this project! This document outlines t
🆕 **New to GitHub or pull requests?** Check out our [beginner-friendly Pull Request Guide](docs/how-to-contribute-with-pull-requests.md) first!
📋 **Before contributing**, please read our [Guiding Principles](GUIDING-PRINCIPLES.md) to understand the BMAD Method's core philosophy and architectural decisions.
Also note, we use the discussions feature in GitHub to have a community to discuss potential ideas, uses, additions and enhancements.
## Code of Conduct
@@ -26,6 +28,65 @@ By participating in this project, you agree to abide by our Code of Conduct. Ple
Please only propose small granular commits! If its large or significant, please discuss in the discussions tab and open up an issue first. I do not want you to waste your time on a potentially very large PR to have it rejected because it is not aligned or deviates from other planned changes. Communicate and lets work together to build and improve this great community project!
**Important**: All contributions must align with our [Guiding Principles](GUIDING-PRINCIPLES.md). Key points:
- Keep dev agents lean - they need context for coding, not documentation
- Web/planning agents can be larger with more complex tasks
- Everything is natural language (markdown) - no code in core framework
- Use expansion packs for domain-specific features
#### Which Branch for Your PR?
**Submit to `next` branch** (most contributions):
- ✨ New features or agents
- 🎨 Enhancements to existing features
- 📚 Documentation updates
- ♻️ Code refactoring
- ⚡ Performance improvements
- 🧪 New tests
- 🎁 New expansion packs
**Submit to `main` branch** (critical only):
- 🚨 Critical bug fixes that break basic functionality
- 🔒 Security patches
- 📚 Fixing dangerously incorrect documentation
- 🐛 Bugs preventing installation or basic usage
**When in doubt, submit to `next`**. We'd rather test changes thoroughly before they hit stable.
#### PR Size Guidelines
- **Ideal PR size**: 200-400 lines of code changes
- **Maximum PR size**: 800 lines (excluding generated files)
- **One feature/fix per PR**: Each PR should address a single issue or add one feature
- **If your change is larger**: Break it into multiple smaller PRs that can be reviewed independently
- **Related changes**: Even related changes should be separate PRs if they deliver independent value
#### Breaking Down Large PRs
If your change exceeds 800 lines, use this checklist to split it:
- [ ] Can I separate the refactoring from the feature implementation?
- [ ] Can I introduce the new API/interface in one PR and implementation in another?
- [ ] Can I split by file or module?
- [ ] Can I create a base PR with shared utilities first?
- [ ] Can I separate test additions from implementation?
- [ ] Even if changes are related, can they deliver value independently?
- [ ] Can these changes be merged in any order without breaking things?
Example breakdown:
1. PR #1: Add utility functions and types (100 lines)
2. PR #2: Refactor existing code to use utilities (200 lines)
3. PR #3: Implement new feature using refactored code (300 lines)
4. PR #4: Add comprehensive tests (200 lines)
**Note**: PRs #1 and #4 could be submitted simultaneously since they deliver independent value and don't depend on each other's merge order.
#### Pull Request Steps
1. Fork the repository
2. Create a new branch (`git checkout -b feature/your-feature-name`)
3. Make your changes
@@ -34,9 +95,75 @@ Please only propose small granular commits! If its large or significant, please
6. Push to your branch (`git push origin feature/your-feature-name`)
7. Open a Pull Request against the main branch
## Pull Request Description Guidelines
Keep PR descriptions short and to the point following this template:
### PR Description Template
Keep your PR description concise and focused. Use this template:
```markdown
## What
[1-2 sentences describing WHAT changed]
## Why
[1-2 sentences explaining WHY this change is needed]
## How
[2-3 bullets listing HOW you implemented it]
-
-
-
## Testing
[1-2 sentences on how you tested this]
```
**Maximum PR description length: 200 words** (excluding code examples if needed)
### Good vs Bad PR Descriptions
**Bad Example:**
> This revolutionary PR introduces a paradigm-shifting enhancement to the system's architecture by implementing a state-of-the-art solution that leverages cutting-edge methodologies to optimize performance metrics and deliver unprecedented value to stakeholders through innovative approaches...
**Good Example:**
> **What:** Added validation for agent dependency resolution
> **Why:** Build was failing silently when agents had circular dependencies
> **How:**
>
> - Added cycle detection in dependency-resolver.js
> - Throws clear error with dependency chain
> **Testing:** Tested with circular deps between 3 agents
## Commit Message Convention
PRs with a wall of AI Generated marketing hype that is unclear in what is being proposed will be closed and rejected. Your best change to contribute is with a small clear PR description explaining, what is the issue being solved or gap in the system being filled. Also explain how it leads to the core guiding principles of the project.
Use conventional commits format:
- `feat:` New feature
- `fix:` Bug fix
- `docs:` Documentation only
- `refactor:` Code change that neither fixes a bug nor adds a feature
- `test:` Adding missing tests
- `chore:` Changes to build process or auxiliary tools
Keep commit messages under 72 characters.
### Atomic Commits
Each commit should represent one logical change:
- **Do:** One bug fix per commit
- **Do:** One feature addition per commit
- **Don't:** Mix refactoring with bug fixes
- **Don't:** Combine unrelated changes
## Code Style

85
GUIDING-PRINCIPLES.md Normal file
View File

@@ -0,0 +1,85 @@
# BMAD Method Guiding Principles
The BMAD Method is a natural language framework for AI-assisted software development. These principles ensure contributions maintain the method's effectiveness.
## Core Principles
### 1. Dev Agents Must Be Lean
- **Minimize dev agent dependencies**: Development agents that work in IDEs must have minimal context overhead
- **Save context for code**: Every line counts - dev agents should focus on coding, not documentation
- **Web agents can be larger**: Planning agents (PRD Writer, Architect) used in web UI can have more complex tasks and dependencies
- **Small files, loaded on demand**: Multiple small, focused files are better than large files with many branches
### 2. Natural Language First
- **Everything is markdown**: Agents, tasks, templates - all written in plain English
- **No code in core**: The framework itself contains no programming code, only natural language instructions
- **Self-contained templates**: Templates include their own generation instructions using `[[LLM: ...]]` markup
### 3. Agent and Task Design
- **Agents define roles**: Each agent is a persona with specific expertise (e.g., Frontend Developer, API Developer)
- **Tasks are procedures**: Step-by-step instructions an agent follows to complete work
- **Templates are outputs**: Structured documents with embedded instructions for generation
- **Dependencies matter**: Explicitly declare only what's needed
## Practical Guidelines
### When to Add to Core
- Universal software development needs only
- Doesn't bloat dev agent contexts
- Follows existing agent/task/template patterns
### When to Create Expansion Packs
- Domain-specific needs beyond software development
- Non-technical domains (business, wellness, education, creative)
- Specialized technical domains (games, infrastructure, mobile)
- Heavy documentation or knowledge bases
- Anything that would bloat core agents
See [Expansion Packs Guide](../docs/expansion-packs.md) for detailed examples and ideas.
### Agent Design Rules
1. **Web/Planning Agents**: Can have richer context, multiple tasks, extensive templates
2. **Dev Agents**: Minimal dependencies, focused on code generation, lean task sets
3. **All Agents**: Clear persona, specific expertise, well-defined capabilities
### Task Writing Rules
1. Write clear step-by-step procedures
2. Use markdown formatting for readability
3. Keep dev agent tasks focused and concise
4. Planning tasks can be more elaborate
5. **Prefer multiple small tasks over one large branching task**
- Instead of one task with many conditional paths
- Create multiple focused tasks the agent can choose from
- This keeps context overhead minimal
6. **Reuse common tasks** - Don't create new document creation tasks
- Use the existing `create-doc` task
- Pass the appropriate template with embedded LLM instructions
- This maintains consistency and reduces duplication
### Template Rules
1. Include generation instructions with `[[LLM: ...]]` markup
2. Provide clear structure for output
3. Make templates reusable across agents
4. Use standardized markup elements:
- `{{placeholders}}` for variables to be replaced
- `[[LLM: instructions]]` for AI-only processing (never shown to users)
- `REPEAT` sections for repeatable content blocks
- `^^CONDITION^^` blocks for conditional content
- `@{examples}` for guidance examples (never output to users)
5. NEVER display template markup or LLM instructions to users
6. Focus on clean output - all processing instructions stay internal
## Remember
- The power is in natural language orchestration, not code
- Dev agents code, planning agents plan
- Keep dev agents lean for maximum coding efficiency
- Expansion packs handle specialized domains

View File

@@ -172,11 +172,37 @@ The upgrade process will:
After upgrading:
1. Review your documents in the `docs/` folder
2. Use `@bmad-master` agent to run the `doc-migration-task` to align your documents with V4 templates
3. If you have separate front-end and backend architecture docs, the migration task will help merge them into a unified `full-stack-architecture.md`
1. Review your documents in the `docs/` folder - if you had a PRD or architecture in your old project, copy it from the backup to the docs folder if they are not there.
2. Optionally run the `doc-migration-task` to align your documents with V4 templates - you can do this with your agent my saying something like: 'run {drag in task} against {drag prd or arch file from docs} to align with {drag the template from .bmad-core/templates/full-stack-architecture.md}
3. If you have separate front-end and backend architecture docs you can modify step 2 to merge both into a single full stack architecture or separate Front and Back end.
**Note**: The agents in `.bmad-core/` fully replace the items in `bmad-agent/`.
The reason #2 and 3 are optional is because now BMad V4 makes sharding optional for the SM. See [Core Configuration](#-core-configuration-new-in-v4)
**Note**: The agents in `.bmad-core/` fully replace the items in `bmad-agent/` - you can remove the backup folder versions.
### 🔧 Core Configuration (NEW in V4)
**Critical**: V4 introduces `bmad-core/core-config.yml` - a powerful configuration file that enables BMAD to work seamlessly with any project structure, whether it's V4-optimized or legacy. You can even now use non-standard PRDs and architectures!
#### What is core-config.yml?
This configuration file tells BMAD agents exactly where to find your project documents and how they're structured. It's the key to V4's flexibility and backwards compatibility.
#### Key Features
- **Version Awareness**: Agents understand if your PRD/Architecture follows V4 conventions or earlier versions
- **Flexible Document Locations**: Works whether your epics are embedded in PRD or properly sharded
- **Developer Context**: Define which files the dev agent should always load
- **Debug Support**: Built-in logging for troubleshooting story implementation
#### Why It Matters
- **Use BMAD with ANY project structure** - V3, V4, or custom layouts
- **No forced migrations** - Keep your existing document organization
- **Customize developer workflow** - Specify exactly which files provide context
- **Seamless upgrades** - Start with V3 docs and gradually adopt V4 patterns
See the [detailed core-config.yml guide](docs/user-guide.md#core-configuration-coreconfigyml) for configuration examples and best practices.
## Teams & Workflows
@@ -215,7 +241,7 @@ tools/
├── installer/ # NPX installer
└── lib/ # Build utilities
expansion-packs/ # Optional add-ons (DevOps, Mobile, etc.)
expansion-packs/ # Domain-specific add-ons (Technical & Non-Technical)
dist/ # 📦 PRE-BUILT BUNDLES (Ready to use!)
├── agents/ # Individual agent bundles (.txt files)
@@ -263,12 +289,60 @@ Rich templates for all document types:
Ask the agent you are using for help with /help (in the web) or \*help in the ide to see what commands are available!
## Expansion Packs - Beyond Software Development
BMAD Method's natural language framework isn't limited to software development. Create specialized agents for ANY domain:
### Technical Expansion Packs
- 🎮 **Game Development** - Game designers, level creators, narrative writers
- 🏗️ **Infrastructure/DevOps** - Cloud architects, security specialists, SRE agents
- 📱 **Mobile Development** - iOS/Android specialists, UX designers
- 🔗 **Blockchain/Web3** - Smart contract developers, DeFi architects
### Non-Technical Expansion Packs
- 💼 **Business Strategy** - Strategic planners, market analysts, business coaches
- 💪 **Health & Wellness** - Fitness coaches, nutrition advisors, meditation guides
- 🎨 **Creative Arts** - Story writers, world builders, character developers
- 📚 **Education** - Curriculum designers, tutors, learning coaches
- 🧠 **Personal Development** - Life coaches, goal setters, habit builders
- 🏢 **Professional Services** - Legal advisors, medical protocols, research assistants
### Creating Your Own Expansion Pack
The BMAD framework can support any domain where structured AI assistance is valuable:
1. Define specialized agents with domain expertise
2. Create task procedures for common workflows
3. Build templates for domain-specific outputs
4. Package as an expansion pack for others to use
📖 **[Read the full Expansion Packs Guide](docs/expansion-packs.md)** for detailed examples and inspiration!
🛠️ **[Use the Expansion Pack Creator](expansion-packs/expansion-creator/README.md)** to build your own!
## Contributing
We welcome contributions!
**We're excited about contributions and welcome your ideas, improvements, and expansion packs!** 🎉
- 🆕 **New to GitHub?** Start with our [Pull Request Guide](docs/how-to-contribute-with-pull-requests.md)
- See [CONTRIBUTING.md](CONTRIBUTING.md) for detailed guidelines
### Before Contributing - MUST READ
To ensure your contribution aligns with the BMAD Method and gets merged smoothly:
1. 📋 **Read [CONTRIBUTING.md](CONTRIBUTING.md)** - Our contribution guidelines, PR requirements, and process
2. 🎯 **Read [GUIDING-PRINCIPLES.md](GUIDING-PRINCIPLES.md)** - Core principles that keep BMAD powerful through simplicity
3. 🆕 **New to GitHub?** Start with our [Pull Request Guide](docs/how-to-contribute-with-pull-requests.md)
### Key Points to Remember
- Keep dev agents lean (save context for coding!)
- Use small, focused files over large branching ones
- Reuse existing tasks (like `create-doc`) instead of creating duplicates
- Consider expansion packs for domain-specific features
- All contributions must follow our natural language, markdown-based approach
We're building something amazing together - let's keep it simple, powerful, and focused! 💪
### Development Setup
@@ -284,10 +358,12 @@ npm install
- 🏗️ [Core Architecture](docs/core-architecture.md) - Complete technical architecture and system design
- 📖 [User Guide](docs/user-guide.md) - Comprehensive guide to using BMAD-METHOD effectively
- 🚀 [Expansion Packs Guide](docs/expansion-packs.md) - Extend BMAD to any domain beyond software development
### Workflow Guides
- 📚 [Universal BMAD Workflow Guide](docs/bmad-workflow-guide.md) - Core workflow that applies to all IDEs
- 🏗️ [Working in the Brownfield Guide](docs/working-in-the-brownfield.md) - Complete guide for enhancing existing projects
- 🎯 [Cursor Guide](docs/cursor-guide.md) - Complete workflow for Cursor users
- 🤖 [Claude Code Guide](docs/claude-code-guide.md) - Complete workflow for Claude Code users
- 🌊 [Windsurf Guide](docs/windsurf-guide.md) - Complete workflow for Windsurf users

View File

@@ -16,7 +16,7 @@ agent:
id: analyst
title: Business Analyst
icon: 📊
whenToUse: Use for market research, brainstorming, competitive analysis, creating project briefs, and initial project discovery
whenToUse: Use for market research, brainstorming, competitive analysis, creating project briefs, initial project discovery, and documenting existing projects (brownfield)
customization: null
persona:
role: Insightful Analyst & Strategic Ideation Partner
@@ -44,6 +44,7 @@ commands: # All commands require * prefix when used (e.g., *help)
- brainstorm {topic}: Facilitate structured brainstorming session
- research {topic}: Generate deep research prompt for investigation
- elicit: Run advanced elicitation to clarify requirements
- document-project: Analyze and document existing project structure comprehensively
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
dependencies:
tasks:
@@ -51,6 +52,7 @@ dependencies:
- create-deep-research-prompt
- create-doc
- advanced-elicitation
- document-project
templates:
- project-brief-tmpl
- market-research-tmpl

View File

@@ -99,6 +99,11 @@ loading:
- Agents: Only when transforming
- Templates/Tasks: Only when executing
- Always indicate loading
kb-mode-behavior:
- When *kb-mode is invoked, use kb-mode-interaction task
- Don't dump all KB content immediately
- Present topic areas and wait for user selection
- Provide focused, contextual responses
workflow-guidance:
- Discover available workflows in the bundle at runtime
- Understand each workflow's purpose, options, and decision points
@@ -112,6 +117,7 @@ dependencies:
tasks:
- advanced-elicitation
- create-doc
- kb-mode-interaction
data:
- bmad-kb
utils:

View File

@@ -32,6 +32,7 @@ core_principles:
- CRITICAL: Dev Record Only - ONLY update story file Dev Agent Record sections (checkboxes/Debug Log/Completion Notes/Change Log)
- Strive for Sequential Task Execution - Complete tasks 1-by-1 and mark [x] as completed
- Test-Driven Quality - Write tests alongside code. Task incomplete without passing tests
- Quality Gate Discipline - NEVER complete tasks with failing automated validations
- Debug Log Discipline - Log temp changes to md table in devDebugLog. Revert after fix.
- Block Only When Critical - HALT for: missing approval/ambiguous reqs/3 failures/missing config
- Code Excellence - Clean, secure, maintainable code per loaded standards
@@ -45,15 +46,16 @@ commands: # All commands require * prefix when used (e.g., *help)
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
task-execution:
flow: "Read task→Implement→Write tests→Pass tests→Update [x]→Next task"
flow: "Read task→Implement→Write tests→Execute validations→Only if ALL pass→Update [x]→Next task"
updates-ONLY:
- "Checkboxes: [ ] not started | [-] in progress | [x] complete"
- "Debug Log: | Task | File | Change | Reverted? |"
- "Completion Notes: Deviations only, <50 words"
- "Change Log: Requirement changes only"
blocking: "Unapproved deps | Ambiguous after story check | 3 failures | Missing config"
done: "Code matches reqs + Tests pass + Follows standards + No lint errors"
completion: "All [x]→Lint→Tests(100%)→Integration(if noted)→Coverage(80%+)→E2E(if noted)→DoD→Summary→HALT"
- "File List: CRITICAL - Maintain complete list of ALL files created/modified during implementation"
blocking: "Unapproved deps | Ambiguous after story check | 3 failures | Missing config | Failing validations"
done: "Code matches reqs + All validations pass + Follows standards + File List complete"
completion: "All [x]→Validations pass→Integration(if noted)→E2E(if noted)→DoD→Update File List→Mark Ready for Review→HALT"
dependencies:
tasks:

View File

@@ -14,34 +14,35 @@ activation-instructions:
agent:
name: Quinn
id: qa
title: Quality Assurance Test Architect
title: Senior Developer & QA Architect
icon: 🧪
whenToUse: Use for test planning, test case creation, quality assurance, bug reporting, and testing strategy
whenToUse: Use for senior code review, refactoring, test planning, quality assurance, and mentoring through code improvements
customization: null
persona:
role: Test Architect & Automation Expert
style: Methodical, detail-oriented, quality-focused, strategic
identity: Senior quality advocate with expertise in test architecture and automation
focus: Comprehensive testing strategies, automation frameworks, quality assurance at every phase
role: Senior Developer & Test Architect
style: Methodical, detail-oriented, quality-focused, mentoring, strategic
identity: Senior developer with deep expertise in code quality, architecture, and test automation
focus: Code excellence through review, refactoring, and comprehensive testing strategies
core_principles:
- Senior Developer Mindset - Review and improve code as a senior mentoring juniors
- Active Refactoring - Don't just identify issues, fix them with clear explanations
- Test Strategy & Architecture - Design holistic testing strategies across all levels
- Automation Excellence - Build maintainable and efficient test automation frameworks
- Code Quality Excellence - Enforce best practices, patterns, and clean code principles
- Shift-Left Testing - Integrate testing early in development lifecycle
- Performance & Security - Proactively identify and fix performance/security issues
- Mentorship Through Action - Explain WHY and HOW when making improvements
- Risk-Based Testing - Prioritize testing based on risk and critical areas
- Performance & Load Testing - Ensure systems meet performance requirements
- Security Testing Integration - Incorporate security testing into QA process
- Test Data Management - Design strategies for realistic and compliant test data
- Continuous Testing & CI/CD - Integrate tests seamlessly into pipelines
- Quality Metrics & Reporting - Track meaningful metrics and provide insights
- Cross-Browser & Cross-Platform Testing - Ensure comprehensive compatibility
- Continuous Improvement - Balance perfection with pragmatism
- Architecture & Design Patterns - Ensure proper patterns and maintainable code structure
startup:
- Greet the user with your name and role, and inform of the *help command.
commands: # All commands require * prefix when used (e.g., *help)
- help: Show numbered list of the following commands to allow selection
- chat-mode: (Default) QA consultation with advanced-elicitation for test strategy
- create-doc {template}: Create doc (no template = show available templates)
- exit: Say goodbye as the QA Test Architect, and then abandon inhabiting this persona
dependencies:
tasks:
- review-story
data:
- technical-preferences
utils:

View File

@@ -1,26 +1,20 @@
core-project-information:
dev-story-location: docs/stories # alternate could be .ai/stories if preferred for example
prd:
prd-file: docs/prd.md
prdVersion: v4
prdSharded: true
prdShardedLocation: docs/prd
epicFilePattern: epic-{n}*.md
architecture:
architecture-file: docs/architecture.md
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
# if you have a front-end architecture document, uncomment the following and validate the file path
# front-end-architecture:
# front-end-architecture-file: docs/front-end-architecture.md
# architectureVersion: v4
# architectureSharded: true
# architectureShardedLocation: docs/architecture
customTechnicalDocuments: null # list other documents only if you want the SM to read them when creating stories
devLoadAlwaysFiles:
- docs/architecture/coding-standards.md
- docs/architecture/tech-stack.md
- docs/architecture/project-structure.md
devDebugLog: .ai/debug-log.md
agentCoreDump: .ai/core-dump{n}.md
markdownExploder: true
prd:
prdFile: docs/prd.md
prdVersion: v4
prdSharded: true
prdShardedLocation: docs/prd
epicFilePattern: epic-{n}*.md
architecture:
architectureFile: docs/architecture.md
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
customTechnicalDocuments: null
devLoadAlwaysFiles:
- docs/architecture/coding-standards.md
- docs/architecture/tech-stack.md
- docs/architecture/source-tree.md
devDebugLog: .ai/debug-log.md
devStoryLocation: docs/stories
agentCoreDump: .ai/core-dump{n}.md

View File

@@ -20,6 +20,50 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
- **Quality Assurance**: Structured testing and validation
- **Documentation**: Professional PRDs, architecture docs, user stories
## How BMAD Works
### The Core Method
BMAD transforms you into a "Vibe CEO" - directing a team of specialized AI agents through structured workflows. Here's how:
1. **You Direct, AI Executes**: You provide vision and decisions; agents handle implementation details
2. **Specialized Agents**: Each agent masters one role (PM, Developer, Architect, etc.)
3. **Structured Workflows**: Proven patterns guide you from idea to deployed code
4. **Clean Handoffs**: Fresh context windows ensure agents stay focused and effective
### The Two-Phase Approach
**Phase 1: Planning (Web UI - Cost Effective)**
- Use large context windows (Gemini's 1M tokens)
- Generate comprehensive documents (PRD, Architecture)
- Leverage multiple agents for brainstorming
- Create once, use throughout development
**Phase 2: Development (IDE - Implementation)**
- Shard documents into manageable pieces
- Execute focused SM → Dev cycles
- One story at a time, sequential progress
- Real-time file operations and testing
### The Development Loop
```text
1. SM Agent (New Chat) → Creates next story from sharded docs
2. You → Review and approve story
3. Dev Agent (New Chat) → Implements approved story
4. QA Agent (New Chat) → Reviews and refactors code
5. You → Verify completion
6. Repeat until epic complete
```
### Why This Works
- **Context Optimization**: Clean chats = better AI performance
- **Role Clarity**: Agents don't context-switch = higher quality
- **Incremental Progress**: Small stories = manageable complexity
- **Human Oversight**: You validate each step = quality control
- **Document-Driven**: Specs guide everything = consistency
## Getting Started
### Quick Start Options
@@ -34,7 +78,7 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
5. Type `/help` to see available commands
#### Option 2: IDE Integration
**Best for**: Cursor, Claude Code, Windsurf, VS Code users
**Best for**: Cursor, Claude Code, Windsurf, Cline, Roo Code users
```bash
# Interactive installation (recommended)
@@ -43,13 +87,22 @@ npx bmad-method install
**Installation Steps**:
- Choose "Complete installation"
- Select your IDE (Cursor, Claude Code, Windsurf, or Roo Code)
- Select your IDE from supported options:
- **Cursor**: Native AI integration
- **Claude Code**: Anthropic's official IDE
- **Windsurf**: Built-in AI capabilities
- **Cline**: VS Code extension with AI features
- **Roo Code**: Web-based IDE with agent support
**Note for VS Code Users**: BMAD-METHOD assumes when you mention "VS Code" that you're using it with an AI-powered extension like GitHub Copilot, Cline, or Roo. Standard VS Code without AI capabilities cannot run BMAD agents. The installer includes built-in support for Cline and Roo.
**Verify Installation**:
- `.bmad-core/` folder created with all agents
- IDE-specific integration files created
- All agent commands/rules/modes available
**Remember**: At its core, BMAD-METHOD is about mastering and harnessing prompt engineering. Any IDE with AI agent support can use BMAD - the framework provides the structured prompts and workflows that make AI development effective
### Environment Selection Guide
**Use Web UI for**:
@@ -66,6 +119,105 @@ npx bmad-method install
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
### IDE-Only Workflow Considerations
**Can you do everything in IDE?** Yes, but understand the tradeoffs:
**Pros of IDE-Only**:
- Single environment workflow
- Direct file operations from start
- No copy/paste between environments
- Immediate project integration
**Cons of IDE-Only**:
- Higher token costs for large document creation
- Smaller context windows (varies by IDE/model)
- May hit limits during planning phases
- Less cost-effective for brainstorming
**Using Web Agents in IDE**:
- **NOT RECOMMENDED**: Web agents (PM, Architect) have rich dependencies designed for large contexts
- **Why it matters**: Dev agents are kept lean to maximize coding context
- **The principle**: "Dev agents code, planning agents plan" - mixing breaks this optimization
**About bmad-master and bmad-orchestrator**:
- **bmad-master**: CAN do any task without switching agents, BUT...
- **Still use specialized agents for planning**: PM, Architect, and UX Expert have tuned personas that produce better results
- **Why specialization matters**: Each agent's personality and focus creates higher quality outputs
- **If using bmad-master/orchestrator**: Fine for planning phases, but...
**CRITICAL RULE for Development**:
- **ALWAYS use SM agent for story creation** - Never use bmad-master/orchestrator
- **ALWAYS use Dev agent for implementation** - Never use bmad-master/orchestrator
- **Why this matters**: SM and Dev agents are specifically optimized for the development workflow
- **No exceptions**: Even if using bmad-master for everything else, switch to SM → Dev for implementation
**Best Practice for IDE-Only**:
1. Use PM/Architect/UX agents for planning (better than bmad-master)
2. Create documents directly in project
3. Shard immediately after creation
4. **MUST switch to SM agent** for story creation
5. **MUST switch to Dev agent** for implementation
6. Keep planning and coding in separate chat sessions
## Core Configuration (core-config.yml)
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
### What is core-config.yml?
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
- **Version Flexibility**: Work with V3, V4, or custom document structures
- **Custom Locations**: Define where your documents and shards live
- **Developer Context**: Specify which files the dev agent should always load
- **Debug Support**: Built-in logging for troubleshooting
### Key Configuration Areas
#### PRD Configuration
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
- **prdShardedLocation**: Where to find sharded epic files
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
#### Architecture Configuration
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
- **architectureSharded**: Whether architecture is split into components
- **architectureShardedLocation**: Where sharded architecture files live
#### Developer Files
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
- **devDebugLog**: Where dev agent logs repeated failures
- **agentCoreDump**: Export location for chat conversations
### Why It Matters
1. **No Forced Migrations**: Keep your existing document structure
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
3. **Custom Workflows**: Configure BMAD to match your team's process
4. **Intelligent Agents**: Agents automatically adapt to your configuration
### Common Configurations
**Legacy V3 Project**:
```yaml
prdVersion: v3
prdSharded: false
architectureVersion: v3
architectureSharded: false
```
**V4 Optimized Project**:
```yaml
prdVersion: v4
prdSharded: true
prdShardedLocation: docs/prd
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
```
## Core Philosophy
### Vibe CEO'ing
@@ -248,10 +400,16 @@ This architecture enables seamless operation across environments while maintaini
## Complete Development Workflow
### Planning Phase (Web UI Recommended)
### Planning Phase (Web UI Recommended - Especially Gemini!)
**Ideal for cost efficiency, especially with Gemini:**
**Ideal for cost efficiency with Gemini's massive context:**
**For Brownfield Projects - Start Here!**:
1. **Upload entire project to Gemini Web** (GitHub URL, files, or zip)
2. **Document existing system**: `/analyst``*document-project`
3. **Creates comprehensive docs** from entire codebase analysis
**For All Projects**:
1. **Optional Analysis**: `/analyst` - Market research, competitive analysis
2. **Project Brief**: Create foundation document (Analyst or user)
3. **PRD Creation**: `/pm create-doc prd` - Comprehensive product requirements
@@ -285,10 +443,14 @@ that can handle [specific requirements]."
**Prerequisites**: Planning documents must exist in `docs/` folder
1. **Document Sharding**:
- `@bmad-master` or `@po` shard `docs/prd.md` to `docs/prd/` folder
- If architecture exists, shard to `docs/architecture/` folder
- Results in multiple manageable documents and epic files
1. **Document Sharding** (CRITICAL STEP):
- Documents created by PM/Architect (in Web or IDE) MUST be sharded for development
- Two methods to shard:
a) **Manual**: Drag `shard-doc` task + document file into chat
b) **Agent**: Ask `@bmad-master` or `@po` to shard documents
- Shards `docs/prd.md``docs/prd/` folder
- Shards `docs/architecture.md``docs/architecture/` folder
- **WARNING**: Do NOT shard in Web UI - copying many small files is painful!
2. **Verify Sharded Content**:
- At least one `epic-n.md` file in `docs/prd/` with stories in development order
@@ -302,19 +464,34 @@ that can handle [specific requirements]."
3. **Development Cycle** (Sequential, one story at a time):
**Step 1 - Story Creation**: New chat window → `@sm``*create`
**CRITICAL CONTEXT MANAGEMENT**:
- **Context windows matter!** Always use fresh, clean context windows
- **Model selection matters!** Use most powerful thinking model for SM story creation
- **ALWAYS start new chat between SM, Dev, and QA work**
**Step 1 - Story Creation**:
- **NEW CLEAN CHAT** → Select powerful model → `@sm``*create`
- SM executes create-next-story task
- Review generated story in `docs/stories/`
- Update status from "Draft" to "Approved"
**Step 2 - Story Implementation**: New chat window → `@dev`
**Step 2 - Story Implementation**:
- **NEW CLEAN CHAT** → `@dev`
- Agent asks which story to implement
- Include story file content to save dev agent lookup time
- Dev follows tasks/subtasks, marking completion
- Dev leaves notes for SM about any deviations
- Update status to "Done"
- Dev maintains File List of all changes
- Dev marks story as "Review" when complete with all tests passing
**Step 3 - Repeat**: Continue SM → Dev cycle until all epic stories complete
**Step 3 - Senior QA Review**:
- **NEW CLEAN CHAT** → `@qa` → execute review-story task
- QA performs senior developer code review
- QA can refactor and improve code directly
- QA appends results to story's QA Results section
- If approved: Status → "Done"
- If changes needed: Status stays "Review" with unchecked items for dev
**Step 4 - Repeat**: Continue SM → Dev → QA cycle until all epic stories complete
**Important**: Only 1 story in progress at a time, worked sequentially until all epic stories complete.
@@ -334,12 +511,72 @@ Each status change requires user verification and approval before proceeding.
- Development execution
- Testing and deployment
#### Brownfield Enhancement
- Current system analysis
- Enhancement planning
- Impact assessment
- Incremental development
- Integration testing
#### Brownfield Enhancement (Existing Projects)
**Key Concept**: Brownfield development requires comprehensive documentation of your existing project for AI agents to understand context, patterns, and constraints.
**Complete Brownfield Workflow Options**:
**Option 1: PRD-First (Recommended for Large Codebases/Monorepos)**:
1. **Upload project to Gemini Web** (GitHub URL, files, or zip)
2. **Create PRD first**: `@pm``*create-doc brownfield-prd`
3. **Focused documentation**: `@analyst``*document-project`
- Analyst asks for focus if no PRD provided
- Choose "single document" format for Web UI
- Uses PRD to document ONLY relevant areas
- Creates one comprehensive markdown file
- Avoids bloating docs with unused code
**Option 2: Document-First (Good for Smaller Projects)**:
1. **Upload project to Gemini Web**
2. **Document everything**: `@analyst``*document-project`
3. **Then create PRD**: `@pm``*create-doc brownfield-prd`
- More thorough but can create excessive documentation
2. **Requirements Gathering**:
- **Brownfield PRD**: Use PM agent with `brownfield-prd-tmpl`
- **Analyzes**: Existing system, constraints, integration points
- **Defines**: Enhancement scope, compatibility requirements, risk assessment
- **Creates**: Epic and story structure for changes
3. **Architecture Planning**:
- **Brownfield Architecture**: Use Architect agent with `brownfield-architecture-tmpl`
- **Integration Strategy**: How new features integrate with existing system
- **Migration Planning**: Gradual rollout and backwards compatibility
- **Risk Mitigation**: Addressing potential breaking changes
**Brownfield-Specific Resources**:
**Templates**:
- `brownfield-prd-tmpl.md`: Comprehensive enhancement planning with existing system analysis
- `brownfield-architecture-tmpl.md`: Integration-focused architecture for existing systems
**Tasks**:
- `document-project`: Generates comprehensive documentation from existing codebase
- `brownfield-create-epic`: Creates single epic for focused enhancements (when full PRD is overkill)
- `brownfield-create-story`: Creates individual story for small, isolated changes
**When to Use Each Approach**:
**Full Brownfield Workflow** (Recommended for):
- Major feature additions
- System modernization
- Complex integrations
- Multiple related changes
**Quick Epic/Story Creation** (Use when):
- Single, focused enhancement
- Isolated bug fixes
- Small feature additions
- Well-documented existing system
**Critical Success Factors**:
1. **Documentation First**: Always run `document-project` if docs are outdated/missing
2. **Context Matters**: Provide agents access to relevant code sections
3. **Integration Focus**: Emphasize compatibility and non-breaking changes
4. **Incremental Approach**: Plan for gradual rollout and testing
**For detailed guide**: See `docs/working-in-the-brownfield.md`
## Document Creation Best Practices
@@ -420,9 +657,91 @@ Use the `shard-doc` task or `@kayvan/markdown-tree-parser` tool for automatic sh
- **Keep conversations focused** - One agent, one task per conversation
- **Review everything** - Always review and approve before marking complete
## Contributing to BMAD-METHOD
### Quick Contribution Guidelines
For full details, see `CONTRIBUTING.md`. Key points:
**Fork Workflow**:
1. Fork the repository
2. Create feature branches
3. Submit PRs to `next` branch (default) or `main` for critical fixes only
4. Keep PRs small: 200-400 lines ideal, 800 lines maximum
5. One feature/fix per PR
**PR Requirements**:
- Clear descriptions (max 200 words) with What/Why/How/Testing
- Use conventional commits (feat:, fix:, docs:)
- Atomic commits - one logical change per commit
- Must align with guiding principles
**Core Principles** (from GUIDING-PRINCIPLES.md):
- **Dev Agents Must Be Lean**: Minimize dependencies, save context for code
- **Natural Language First**: Everything in markdown, no code in core
- **Core vs Expansion Packs**: Core for universal needs, packs for specialized domains
- **Design Philosophy**: "Dev agents code, planning agents plan"
## Expansion Packs
### What Are Expansion Packs?
Expansion packs extend BMAD-METHOD beyond traditional software development into ANY domain. They provide specialized agent teams, templates, and workflows while keeping the core framework lean and focused on development.
### Why Use Expansion Packs?
1. **Keep Core Lean**: Dev agents maintain maximum context for coding
2. **Domain Expertise**: Deep, specialized knowledge without bloating core
3. **Community Innovation**: Anyone can create and share packs
4. **Modular Design**: Install only what you need
### Available Expansion Packs
**Technical Packs**:
- **Infrastructure/DevOps**: Cloud architects, SRE experts, security specialists
- **Game Development**: Game designers, level designers, narrative writers
- **Mobile Development**: iOS/Android specialists, mobile UX experts
- **Data Science**: ML engineers, data scientists, visualization experts
**Non-Technical Packs**:
- **Business Strategy**: Consultants, financial analysts, marketing strategists
- **Creative Writing**: Plot architects, character developers, world builders
- **Health & Wellness**: Fitness trainers, nutritionists, habit engineers
- **Education**: Curriculum designers, assessment specialists
- **Legal Support**: Contract analysts, compliance checkers
**Specialty Packs**:
- **Expansion Creator**: Tools to build your own expansion packs
- **RPG Game Master**: Tabletop gaming assistance
- **Life Event Planning**: Wedding planners, event coordinators
- **Scientific Research**: Literature reviewers, methodology designers
### Using Expansion Packs
1. **Browse Available Packs**: Check `expansion-packs/` directory
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
3. **Install via CLI**:
```bash
npx bmad-method install
# Select "Install expansion pack" option
```
4. **Use in Your Workflow**: Installed packs integrate seamlessly with existing agents
### Creating Custom Expansion Packs
Use the **expansion-creator** pack to build your own:
1. **Define Domain**: What expertise are you capturing?
2. **Design Agents**: Create specialized roles with clear boundaries
3. **Build Resources**: Tasks, templates, checklists for your domain
4. **Test & Share**: Validate with real use cases, share with community
**Key Principle**: Expansion packs democratize expertise by making specialized knowledge accessible through AI agents.
## Getting Help
- **Commands**: Use `/help` in any environment to see available commands
- **Agent Switching**: Use `/switch agent-name` with orchestrator for role changes
- **Documentation**: Check `docs/` folder for project-specific context
- **Community**: Discord and GitHub resources available for support
- **Contributing**: See `CONTRIBUTING.md` for full guidelines

View File

@@ -17,14 +17,14 @@ To identify the next logical story based on project progress and epic definition
2. Run the BMAD installer against your project to upgrade and add the file automatically
Please add and configure core-config.yml before proceeding."
- Extract the following key configurations:
- `dev-story-location`: Where to save story files
- `devStoryLocation`: Where to save story files
- `prd.prdSharded`: Whether PRD is sharded or monolithic
- `prd.prd-file`: Location of monolithic PRD (if not sharded)
- `prd.prdFile`: Location of monolithic PRD (if not sharded)
- `prd.prdShardedLocation`: Location of sharded epic files
- `prd.epicFilePattern`: Pattern for epic files (e.g., `epic-{n}*.md`)
- `architecture.architectureVersion`: Architecture document version
- `architecture.architectureSharded`: Whether architecture is sharded
- `architecture.architecture-file`: Location of monolithic architecture
- `architecture.architectureFile`: Location of monolithic architecture
- `architecture.architectureShardedLocation`: Location of sharded architecture files
### 1. Identify Next Story for Preparation
@@ -33,11 +33,11 @@ To identify the next logical story based on project progress and epic definition
- Based on `prdSharded` from config:
- **If `prdSharded: true`**: Look for epic files in `prdShardedLocation` using `epicFilePattern`
- **If `prdSharded: false`**: Load the full PRD from `prd-file` and extract epics from section headings (## Epic N or ### Epic N)
- **If `prdSharded: false`**: Load the full PRD from `prdFile` and extract epics from section headings (## Epic N or ### Epic N)
#### 1.2 Review Existing Stories
- Check `dev-story-location` from config (e.g., `docs/stories/`) for existing story files
- Check `devStoryLocation` from config (e.g., `docs/stories/`) for existing story files
- If the directory exists and has at least 1 file, find the highest-numbered story file.
- **If a highest story file exists (`{lastEpicNum}.{lastStoryNum}.story.md`):**
- Verify its `Status` is 'Done' (or equivalent).
@@ -57,12 +57,40 @@ To identify the next logical story based on project progress and epic definition
```
- Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and check for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
- Else (story not found or prerequisites not met): The next story is the first story in the next Epic File (e.g., look for `epic-{lastEpicNum + 1}*.md`, then `epic-{lastEpicNum + 2}*.md`, etc.) whose prerequisites are met.
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and parse it to find ALL stories in that epic. **ALWAYS select the next sequential story** (e.g., if last was 2.2, next MUST be 2.3).
- If the next sequential story has unmet prerequisites, present this to the user:
```plaintext
ALERT: Next story has unmet prerequisites:
Story: {epicNum}.{storyNum} - {Story Title}
Prerequisites not met: [list specific prerequisites]
Would you like to:
1. Create the story anyway (mark prerequisites as pending)
2. Skip to a different story (requires your specific instruction)
3. Cancel story creation
Please choose an option (1/2/3):
```
- If there are no more stories in the current epic (e.g., 2.9 was done and there is no 2.10):
```plaintext
Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed.
Would you like to:
1. Begin Epic {epicNum + 1} with story {epicNum + 1}.1
2. Select a specific story to work on
3. Cancel story creation
Please choose an option (1/2/3):
```
- **CRITICAL**: NEVER automatically skip to another epic or non-sequential story. The user MUST explicitly instruct which story to create if skipping the sequential order.
- **If no story files exist in `docs/stories/`:**
- The next story is the first story in the first epic file (look for `epic-1-*.md`, then `epic-2-*.md`, etc.) whose prerequisites are met.
- If no suitable story with met prerequisites is found, report to the user that story creation is blocked, specifying what prerequisites are pending. HALT task.
- The next story is ALWAYS 1.1 (the first story of the first epic).
- If story 1.1 has unmet prerequisites, follow the same alert process as above.
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}".
### 2. Gather Core Story Requirements (from Epic)
@@ -98,13 +126,13 @@ Based on configuration loaded in Step 0:
- Follow the structured reading order in section 4.2 below
- **If `architectureVersion: v4` and `architectureSharded: false`**:
- Load the monolithic architecture from `architecture-file`
- Load the monolithic architecture from `architectureFile`
- Extract relevant sections based on v4 structure (tech stack, project structure, etc.)
- **If `architectureVersion` is NOT v4**:
- Inform user: "Architecture document is not v4 format. Will use best judgment to find relevant information."
- If `architectureSharded: true`: Search sharded files by filename relevance
- If `architectureSharded: false`: Search within monolithic `architecture-file` for relevant sections
- If `architectureSharded: false`: Search within monolithic `architectureFile` for relevant sections
#### 4.2 Recommended Reading Order Based on Story Type (v4 Sharded Only)
@@ -161,7 +189,7 @@ Format references as: `[Source: architecture/{filename}.md#{section}]`
### 6. Populate Story Template with Full Context
- Create a new story file: `{dev-story-location}/{epicNum}.{storyNum}.story.md` (using location from config).
- Create a new story file: `{devStoryLocation}/{epicNum}.{storyNum}.story.md` (using location from config).
- Use the Story Template to structure the file.
- Fill in:
- Story `{EpicNum}.{StoryNum}: {Short Title Copied from Epic File}`
@@ -208,7 +236,7 @@ Format references as: `[Source: architecture/{filename}.md#{section}]`
- Verify all source references are included for technical details
- Ensure tasks align with both epic requirements and architecture constraints
- Update status to "Draft"
- Save the story file to `{dev-story-location}/{epicNum}.{storyNum}.story.md` (using location from config)
- Save the story file to `{devStoryLocation}/{epicNum}.{storyNum}.story.md` (using location from config)
### 9. Report Completion

View File

@@ -8,7 +8,39 @@ Generate comprehensive documentation for existing projects optimized for AI deve
### 1. Initial Project Analysis
[[LLM: Begin by conducting a comprehensive analysis of the existing project. Use available tools to:
[[LLM: First, check if a PRD or requirements document exists in context. If yes, use it to focus your documentation efforts on relevant areas only.
**IF PRD EXISTS**:
- Review the PRD to understand what enhancement/feature is planned
- Identify which modules, services, or areas will be affected
- Focus documentation ONLY on these relevant areas
- Skip unrelated parts of the codebase to keep docs lean
**IF NO PRD EXISTS**:
Ask the user:
"I notice you haven't provided a PRD or requirements document. To create more focused and useful documentation, I recommend one of these options:
1. **Create a PRD first** - Would you like me to help create a brownfield PRD before documenting? This helps focus documentation on relevant areas.
2. **Provide existing requirements** - Do you have a requirements document, epic, or feature description you can share?
3. **Describe the focus** - Can you briefly describe what enhancement or feature you're planning? For example:
- 'Adding payment processing to the user service'
- 'Refactoring the authentication module'
- 'Integrating with a new third-party API'
4. **Document everything** - Or should I proceed with comprehensive documentation of the entire codebase? (Note: This may create excessive documentation for large projects)
Please let me know your preference, or I can proceed with full documentation if you prefer."
Based on their response:
- If they choose option 1-3: Use that context to focus documentation
- If they choose option 4 or decline: Proceed with comprehensive analysis below
Begin by conducting analysis of the existing project. Use available tools to:
1. **Project Structure Discovery**: Examine the root directory structure, identify main folders, and understand the overall organization
2. **Technology Stack Identification**: Look for package.json, requirements.txt, Cargo.toml, pom.xml, etc. to identify languages, frameworks, and dependencies
@@ -23,367 +55,263 @@ Ask the user these elicitation questions to better understand their needs:
- What types of tasks do you expect AI agents to perform on this project? (e.g., bug fixes, feature additions, refactoring, testing)
- Are there any existing documentation standards or formats you prefer?
- What level of technical detail should the documentation target? (junior developers, senior developers, mixed team)
- Is there a specific feature or enhancement you're planning? (This helps focus documentation)
]]
### 2. Core Documentation Generation
### 2. Deep Codebase Analysis
[[LLM: Based on your analysis, generate the following core documentation files. Adapt the content and structure to match the specific project type and context you discovered:
[[LLM: Before generating documentation, conduct extensive analysis of the existing codebase:
**Core Documents (always generate):**
1. **Explore Key Areas**:
- Entry points (main files, index files, app initializers)
- Configuration files and environment setup
- Package dependencies and versions
- Build and deployment configurations
- Test suites and coverage
1. **docs/index.md** - Master documentation index
2. **docs/architecture/index.md** - Architecture documentation index
3. **docs/architecture/coding-standards.md** - Coding conventions and style guidelines
4. **docs/architecture/tech-stack.md** - Technology stack and version constraints
5. **docs/architecture/unified-project-structure.md** - Project structure and organization
6. **docs/architecture/testing-strategy.md** - Testing approaches and requirements
2. **Ask Clarifying Questions**:
- "I see you're using [technology X]. Are there any custom patterns or conventions I should document?"
- "What are the most critical/complex parts of this system that developers struggle with?"
- "Are there any undocumented 'tribal knowledge' areas I should capture?"
- "What technical debt or known issues should I document?"
- "Which parts of the codebase change most frequently?"
**Backend Documents (generate for backend/full-stack projects):**
3. **Map the Reality**:
- Identify ACTUAL patterns used (not theoretical best practices)
- Find where key business logic lives
- Locate integration points and external dependencies
- Document workarounds and technical debt
- Note areas that differ from standard patterns
7. **docs/architecture/backend-architecture.md** - Backend service patterns and structure
8. **docs/architecture/rest-api-spec.md** - API endpoint specifications
9. **docs/architecture/data-models.md** - Data structures and validation rules
10. **docs/architecture/database-schema.md** - Database design and relationships
11. **docs/architecture/external-apis.md** - Third-party integrations
**IF PRD PROVIDED**: Also analyze what would need to change for the enhancement]]
**Frontend Documents (generate for frontend/full-stack projects):**
### 3. Core Documentation Generation
12. **docs/architecture/frontend-architecture.md** - Frontend patterns and structure
13. **docs/architecture/components.md** - UI component specifications
14. **docs/architecture/core-workflows.md** - User interaction flows
15. **docs/architecture/ui-ux-spec.md** - UI/UX specifications and guidelines
[[LLM: Generate a comprehensive BROWNFIELD architecture document that reflects the ACTUAL state of the codebase.
**Additional Documents (generate if applicable):**
**CRITICAL**: This is NOT an aspirational architecture document. Document what EXISTS, including:
- Technical debt and workarounds
- Inconsistent patterns between different parts
- Legacy code that can't be changed
- Integration constraints
- Performance bottlenecks
16. **docs/prd.md** - Product requirements document (if not exists)
17. **docs/architecture/deployment-guide.md** - Deployment and operations info
18. **docs/architecture/security-considerations.md** - Security patterns and requirements
19. **docs/architecture/performance-guidelines.md** - Performance optimization patterns
**Document Structure**:
**Optional Enhancement Documents:**
# [Project Name] Brownfield Architecture Document
20. **docs/architecture/troubleshooting-guide.md** - Common issues and solutions
21. **docs/architecture/changelog-conventions.md** - Change management practices
22. **docs/architecture/code-review-checklist.md** - Review standards and practices
## Introduction
This document captures the CURRENT STATE of the [Project Name] codebase, including technical debt, workarounds, and real-world patterns. It serves as a reference for AI agents working on enhancements.
Present each document section by section, using the advanced elicitation task after each major section.]]
### Document Scope
[If PRD provided: "Focused on areas relevant to: {enhancement description}"]
[If no PRD: "Comprehensive documentation of entire system"]
### 3. Document Structure Template
### Change Log
| Date | Version | Description | Author |
|------|---------|-------------|--------|
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
[[LLM: Use this standardized structure for each documentation file, adapting content as needed:
## Quick Reference - Key Files and Entry Points
```markdown
# {{Document Title}}
### Critical Files for Understanding the System
- **Main Entry**: `src/index.js` (or actual entry point)
- **Configuration**: `config/app.config.js`, `.env.example`
- **Core Business Logic**: `src/services/`, `src/domain/`
- **API Definitions**: `src/routes/` or link to OpenAPI spec
- **Database Models**: `src/models/` or link to schema files
- **Key Algorithms**: [List specific files with complex logic]
## Overview
### If PRD Provided - Enhancement Impact Areas
[Highlight which files/modules will be affected by the planned enhancement]
{{Brief description of what this document covers and why it's important for AI agents}}
## High Level Architecture
## Quick Reference
### Technical Summary
[Real assessment of architecture - mention if it's well-structured or has issues]
{{Key points, commands, or patterns that agents need most frequently}}
### 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] |
| [etc...] |
## Detailed Information
### Repository Structure Reality Check
- Type: [Monorepo/Polyrepo/Hybrid]
- Package Manager: [npm/yarn/pnpm]
- Notable: [Any unusual structure decisions]
{{Comprehensive information organized into logical sections}}
## Source Tree and Module Organization
## Examples
{{Concrete examples showing proper usage or implementation}}
## Common Patterns
{{Recurring patterns agents should recognize and follow}}
## Things to Avoid
{{Anti-patterns, deprecated approaches, or common mistakes}}
## Related Resources
{{Links to other relevant documentation or external resources}}
### Project Structure (Actual)
```
project-root/
├── src/
│ ├── controllers/ # HTTP request handlers
│ ├── services/ # Business logic (NOTE: inconsistent patterns between user and payment services)
│ ├── models/ # Database models (Sequelize)
│ ├── utils/ # Mixed bag - needs refactoring
│ └── legacy/ # DO NOT MODIFY - old payment system still in use
├── tests/ # Jest tests (60% coverage)
├── scripts/ # Build and deployment scripts
└── config/ # Environment configs
```
Each document should be:
- **Concrete and actionable** - Focus on what agents need to do, not just concepts
- **Pattern-focused** - Highlight recurring patterns agents can recognize and replicate
- **Example-rich** - Include specific code examples and real file references
- **Context-aware** - Reference actual project files, folders, and conventions
- **Assumption-free** - Don't assume agents know project history or implicit knowledge
]]
### 4. Content Guidelines for Each Document Type
#### Core Architecture Documents
##### docs/architecture/index.md
[[LLM: Create a comprehensive index of all architecture documentation:
- List all architecture documents with brief descriptions
- Group documents by category (backend, frontend, shared)
- Include quick links to key sections
- Provide reading order recommendations for different use cases]]
##### docs/architecture/unified-project-structure.md
[[LLM: Document the complete project structure:
- Root-level directory structure with explanations
- Where each type of code belongs (backend, frontend, tests, etc.)
- File naming conventions and patterns
- Module/package organization
- Generated vs. source file locations
- Build output locations]]
##### docs/architecture/coding-standards.md
[[LLM: Capture project-wide coding conventions:
- Language-specific style guidelines
- Naming conventions (variables, functions, classes, files)
- Code organization within files
- Import/export patterns
- Comment and documentation standards
- Linting and formatting tool configurations
- Git commit message conventions]]
##### docs/architecture/tech-stack.md
[[LLM: Document all technologies and versions:
- Primary languages and versions
- Frameworks and major libraries with versions
- Development tools and their versions
- Database systems and versions
- External services and APIs used
- Browser/runtime requirements]]
##### docs/architecture/testing-strategy.md
[[LLM: Define testing approaches and requirements:
- Test file locations and naming conventions
- Unit testing patterns and frameworks
- Integration testing approaches
- E2E testing setup (if applicable)
- Test coverage requirements
- Mocking strategies
- Test data management]]
#### Backend Architecture Documents
##### docs/architecture/backend-architecture.md
[[LLM: Document backend service structure:
- Service layer organization
- Controller/route patterns
- Middleware architecture
- Authentication/authorization patterns
- Request/response flow
- Background job processing
- Service communication patterns]]
##### docs/architecture/rest-api-spec.md
[[LLM: Specify all API endpoints:
- Base URL and versioning strategy
- Authentication methods
- Common headers and parameters
- Each endpoint with:
- HTTP method and path
- Request parameters/body
- Response format and status codes
- Error responses
- Rate limiting and quotas]]
##### docs/architecture/data-models.md
[[LLM: Define data structures and validation:
- Core business entities
- Data validation rules
- Relationships between entities
- Computed fields and derivations
- Data transformation patterns
- Serialization formats]]
##### docs/architecture/database-schema.md
[[LLM: Document database design:
- Database type and version
- Table/collection structures
- Indexes and constraints
- Relationships and foreign keys
- Migration patterns
- Seed data requirements
- Backup and recovery procedures]]
##### docs/architecture/external-apis.md
[[LLM: Document third-party integrations:
- List of external services used
- Authentication methods for each
- API endpoints and usage patterns
- Rate limits and quotas
- Error handling strategies
- Webhook configurations
- Data synchronization patterns]]
#### Frontend Architecture Documents
##### docs/architecture/frontend-architecture.md
[[LLM: Document frontend application structure:
- Component hierarchy and organization
- State management patterns
- Routing architecture
- Data fetching patterns
- Authentication flow
- Error boundary strategies
- Performance optimization patterns]]
##### docs/architecture/components.md
[[LLM: Specify UI components:
- Component library/design system used
- Custom component specifications
- Props and state for each component
- Component composition patterns
- Styling approaches
- Accessibility requirements
- Component testing patterns]]
##### docs/architecture/core-workflows.md
[[LLM: Document user interaction flows:
- Major user journeys
- Screen flow diagrams
- Form handling patterns
- Navigation patterns
- Data flow through workflows
- Error states and recovery
- Loading and transition states]]
##### docs/architecture/ui-ux-spec.md
[[LLM: Define UI/UX guidelines:
- Design system specifications
- Color palette and typography
- Spacing and layout grids
- Responsive breakpoints
- Animation and transition guidelines
- Accessibility standards
- Browser compatibility requirements]]
### 5. Adaptive Content Strategy
[[LLM: Adapt your documentation approach based on project characteristics:
**For Web Applications:**
- Focus on component patterns, routing, state management
- Include build processes, asset handling, and deployment
- Cover API integration patterns and data fetching
**For Backend Services:**
- Emphasize service architecture, data models, and API design
- Include database interaction patterns and migration strategies
- Cover authentication, authorization, and security patterns
**For CLI Tools:**
- Focus on command structure, argument parsing, and output formatting
- Include plugin/extension patterns if applicable
- Cover configuration file handling and user interaction patterns
**For Libraries/Frameworks:**
- Emphasize public API design and usage patterns
- Include extension points and customization approaches
- Cover versioning, compatibility, and migration strategies
**For Mobile Applications:**
- Focus on platform-specific patterns and navigation
- Include state management and data persistence approaches
- Cover platform integration and native feature usage
**For Data Science/ML Projects:**
- Emphasize data pipeline patterns and model organization
- Include experiment tracking and reproducibility approaches
- Cover data validation and model deployment patterns
]]
### 6. Quality Assurance
[[LLM: Before completing each document:
1. **Accuracy Check**: Verify all file paths, commands, and code examples work
2. **Completeness Review**: Ensure the document covers the most important patterns an agent would encounter
3. **Clarity Assessment**: Check that explanations are clear and actionable
4. **Consistency Verification**: Ensure terminology and patterns align across all documents
5. **Agent Perspective**: Review from the viewpoint of an AI agent that needs to contribute to this project
Ask the user to review each completed document and use the advanced elicitation task to refine based on their feedback.]]
### 7. Final Integration
[[LLM: After all documents are completed:
1. Ensure all documents are created in the proper BMAD-expected locations:
- Core docs in `docs/` (index.md, prd.md)
- Architecture shards in `docs/architecture/` subdirectory
- Create the `docs/architecture/` directory if it doesn't exist
2. Create/update the master index documents:
- Update `docs/index.md` to reference all documentation
- Create `docs/architecture/index.md` listing all architecture shards
3. Verify document cross-references:
- Ensure all documents link to related documentation
- Check that file paths match the actual project structure
- Validate that examples reference real files in the project
4. Provide maintenance guidance:
- Document update triggers (when to update each doc)
- Create a simple checklist for keeping docs current
- Suggest automated validation approaches
5. Summary report including:
- List of all documents created with their paths
- Any gaps or areas needing human review
- Recommendations for project-specific additions
- Next steps for maintaining documentation accuracy
Present a summary of what was created and ask if any additional documentation would be helpful for AI agents working on this specific project.]]
### Key Modules and Their Purpose
- **User Management**: `src/services/userService.js` - Handles all user operations
- **Authentication**: `src/middleware/auth.js` - JWT-based, custom implementation
- **Payment Processing**: `src/legacy/payment.js` - CRITICAL: Do not refactor, tightly coupled
- **[List other key modules with their actual files]**
## Data Models and APIs
### Data Models
Instead of duplicating, reference actual model files:
- **User Model**: See `src/models/User.js`
- **Order Model**: See `src/models/Order.js`
- **Related Types**: TypeScript definitions in `src/types/`
### API Specifications
- **OpenAPI Spec**: `docs/api/openapi.yaml` (if exists)
- **Postman Collection**: `docs/api/postman-collection.json`
- **Manual Endpoints**: [List any undocumented endpoints discovered]
## Technical Debt and Known Issues
### Critical Technical Debt
1. **Payment Service**: Legacy code in `src/legacy/payment.js` - tightly coupled, no tests
2. **User Service**: Different pattern than other services, uses callbacks instead of promises
3. **Database Migrations**: Manually tracked, no proper migration tool
4. **[Other significant debt]**
### Workarounds and Gotchas
- **Environment Variables**: Must set `NODE_ENV=production` even for staging (historical reason)
- **Database Connections**: Connection pool hardcoded to 10, changing breaks payment service
- **[Other workarounds developers need to know]**
## Integration Points and External Dependencies
### External Services
| Service | Purpose | Integration Type | Key Files |
|---------|---------|------------------|-----------|
| Stripe | Payments | REST API | `src/integrations/stripe/` |
| SendGrid | Emails | SDK | `src/services/emailService.js` |
| [etc...] |
### Internal Integration Points
- **Frontend Communication**: REST API on port 3000, expects specific headers
- **Background Jobs**: Redis queue, see `src/workers/`
- **[Other integrations]**
## Development and Deployment
### Local Development Setup
1. Actual steps that work (not ideal steps)
2. Known issues with setup
3. Required environment variables (see `.env.example`)
### Build and Deployment Process
- **Build Command**: `npm run build` (webpack config in `webpack.config.js`)
- **Deployment**: Manual deployment via `scripts/deploy.sh`
- **Environments**: Dev, Staging, Prod (see `config/environments/`)
## Testing Reality
### Current Test Coverage
- Unit Tests: 60% coverage (Jest)
- Integration Tests: Minimal, in `tests/integration/`
- E2E Tests: None
- Manual Testing: Primary QA method
### Running Tests
```bash
npm test # Runs unit tests
npm run test:integration # Runs integration tests (requires local DB)
```
## If Enhancement PRD Provided - Impact Analysis
### Files That Will Need Modification
Based on the enhancement requirements, these files will be affected:
- `src/services/userService.js` - Add new user fields
- `src/models/User.js` - Update schema
- `src/routes/userRoutes.js` - New endpoints
- [etc...]
### New Files/Modules Needed
- `src/services/newFeatureService.js` - New business logic
- `src/models/NewFeature.js` - New data model
- [etc...]
### Integration Considerations
- Will need to integrate with existing auth middleware
- Must follow existing response format in `src/utils/responseFormatter.js`
- [Other integration points]
## Appendix - Useful Commands and Scripts
### Frequently Used Commands
```bash
npm run dev # Start development server
npm run build # Production build
npm run migrate # Run database migrations
npm run seed # Seed test data
```
### Debugging and Troubleshooting
- **Logs**: Check `logs/app.log` for application logs
- **Debug Mode**: Set `DEBUG=app:*` for verbose logging
- **Common Issues**: See `docs/troubleshooting.md`]]
### 4. Document Delivery
[[LLM: After generating the complete architecture document:
1. **In Web UI (Gemini, ChatGPT, Claude)**:
- Present the entire document in one response (or multiple if too long)
- Tell user to copy and save as `docs/brownfield-architecture.md` or `docs/project-architecture.md`
- Mention it can be sharded later in IDE if needed
2. **In IDE Environment**:
- Create the document as `docs/brownfield-architecture.md`
- Inform user this single document contains all architectural information
- Can be sharded later using PO agent if desired
The document should be comprehensive enough that future agents can understand:
- The actual state of the system (not idealized)
- Where to find key files and logic
- What technical debt exists
- What constraints must be respected
- If PRD provided: What needs to change for the enhancement]]
### 5. Quality Assurance
[[LLM: Before finalizing the document:
1. **Accuracy Check**: Verify all technical details match the actual codebase
2. **Completeness Review**: Ensure all major system components are documented
3. **Focus Validation**: If user provided scope, verify relevant areas are emphasized
4. **Clarity Assessment**: Check that explanations are clear for AI agents
5. **Navigation**: Ensure document has clear section structure for easy reference
Apply the advanced elicitation task after major sections to refine based on user feedback.]]
## Success Criteria
- Documentation enables AI agents to understand project context without additional explanation
- All major architectural patterns and coding conventions are captured
- Examples reference actual project files and demonstrate real usage
- Documentation is structured consistently and easy to navigate
- Content is actionable and focuses on what agents need to do, not just understand
- Single comprehensive brownfield architecture document created
- Document reflects REALITY including technical debt and workarounds
- Key files and modules are referenced with actual paths
- Models/APIs reference source files rather than duplicating content
- If PRD provided: Clear impact analysis showing what needs to change
- Document enables AI agents to navigate and understand the actual codebase
- Technical constraints and "gotchas" are clearly documented
## Notes
- This task is designed to work with any project type, language, or framework
- The documentation should reflect the project as it actually is, not as it should be
- Focus on patterns that agents can recognize and replicate consistently
- Include both positive examples (what to do) and negative examples (what to avoid)
- This task creates ONE document that captures the TRUE state of the system
- References actual files rather than duplicating content when possible
- Documents technical debt, workarounds, and constraints honestly
- For brownfield projects with PRD: Provides clear enhancement impact analysis
- The goal is PRACTICAL documentation for AI agents doing real work

View File

@@ -0,0 +1,70 @@
# KB Mode Interaction Task
## Purpose
Provide a user-friendly interface to the BMAD knowledge base without overwhelming users with information upfront.
## Instructions
When entering KB mode (*kb-mode), follow these steps:
### 1. Welcome and Guide
Announce entering KB mode with a brief, friendly introduction:
"I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD."
### 2. Present Topic Areas
Offer a concise list of main topic areas the user might want to explore:
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
### 3. Respond Contextually
- Wait for user's specific question or topic selection
- Provide focused, relevant information from the knowledge base
- Offer to dive deeper or explore related topics
- Keep responses concise unless user asks for detailed explanations
### 4. Interactive Exploration
- After answering, suggest related topics they might find helpful
- Maintain conversational flow rather than data dumping
- Use examples when appropriate
- Reference specific documentation sections when relevant
### 5. Exit Gracefully
When user is done or wants to exit KB mode:
- Summarize key points discussed if helpful
- Remind them they can return to KB mode anytime with *kb-mode
- Suggest next steps based on what was discussed
## Example Interaction
**User**: *kb-mode
**Assistant**: I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD.
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
**User**: Tell me about workflows
**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]

View File

@@ -0,0 +1,135 @@
# review-story
When a developer marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
[[LLM: QA Agent executing review-story task as Senior Developer]]
## Prerequisites
- Story status must be "Review"
- Developer has completed all tasks and updated the File List
- All automated tests are passing
## Review Process
1. **Read the Complete Story**
- Review all acceptance criteria
- Understand the dev notes and requirements
- Note any completion notes from the developer
2. **Focus on the File List**
- Verify all files listed were actually created/modified
- Check for any missing files that should have been updated
3. **Senior Developer Code Review**
- Review code with the eye of a senior developer
- If changes form a cohesive whole, review them together
- If changes are independent, review incrementally file by file
- Focus on:
- Code architecture and design patterns
- Refactoring opportunities
- Code duplication or inefficiencies
- Performance optimizations
- Security concerns
- Best practices and patterns
4. **Active Refactoring**
- As a senior developer, you CAN and SHOULD refactor code where improvements are needed
- When refactoring:
- Make the changes directly in the files
- Explain WHY you're making the change
- Describe HOW the change improves the code
- Ensure all tests still pass after refactoring
- Update the File List if you modify additional files
5. **Standards Compliance Check**
- Verify adherence to `docs/coding-standards.md`
- Check compliance with `docs/unified-project-structure.md`
- Validate testing approach against `docs/testing-strategy.md`
- Ensure all guidelines mentioned in the story are followed
6. **Acceptance Criteria Validation**
- Verify each AC is fully implemented
- Check for any missing functionality
- Validate edge cases are handled
7. **Test Coverage Review**
- Ensure unit tests cover edge cases
- Add missing tests if critical coverage is lacking
- Verify integration tests (if required) are comprehensive
- Check that test assertions are meaningful
- Look for missing test scenarios
8. **Documentation and Comments**
- Verify code is self-documenting where possible
- Add comments for complex logic if missing
- Ensure any API changes are documented
## Append Results to Story File
After review and any refactoring, append your results to the story file in the QA Results section:
```markdown
## QA Results
### Review Date: [Date]
### Reviewed By: Quinn (Senior Developer QA)
### Code Quality Assessment
[Overall assessment of implementation quality]
### Refactoring Performed
[List any refactoring you performed with explanations]
- **File**: [filename]
- **Change**: [what was changed]
- **Why**: [reason for change]
- **How**: [how it improves the code]
### Compliance Check
- Coding Standards: [✓/✗] [notes if any]
- Project Structure: [✓/✗] [notes if any]
- Testing Strategy: [✓/✗] [notes if any]
- All ACs Met: [✓/✗] [notes if any]
### Improvements Checklist
[Check off items you handled yourself, leave unchecked for dev to address]
- [x] Refactored user service for better error handling (services/user.service.ts)
- [x] Added missing edge case tests (services/user.service.test.ts)
- [ ] Consider extracting validation logic to separate validator class
- [ ] Add integration test for error scenarios
- [ ] Update API documentation for new error codes
### Security Review
[Any security concerns found and whether addressed]
### Performance Considerations
[Any performance issues found and whether addressed]
### Final Status
[✓ Approved - Ready for Done] / [✗ Changes Required - See unchecked items above]
```
## Key Principles
- You are a SENIOR developer reviewing junior/mid-level work
- You have the authority and responsibility to improve code directly
- Always explain your changes for learning purposes
- Balance between perfection and pragmatism
- Focus on significant improvements, not nitpicks
## Blocking Conditions
Stop the review and request clarification if:
- Story file is incomplete or missing critical sections
- File List is empty or clearly incomplete
- No tests exist when they were required
- Code changes don't align with story requirements
- Critical architectural issues that require discussion
## Completion
After review:
1. If all items are checked and approved: Update story status to "Done"
2. If unchecked items remain: Keep status as "Review" for dev to address
3. Always provide constructive feedback and explanations for learning

View File

@@ -6,9 +6,27 @@
- Create a folder structure to organize the sharded documents
- Maintain all content integrity including code blocks, diagrams, and markdown formatting
## Recommended Method: @kayvan/markdown-tree-parser
## Primary Method: Automatic with markdown-tree
[[LLM: First, suggest the user install and use the @kayvan/markdown-tree-parser tool if the md-tree command is unavailable so we can have the best performance and reliable document sharding. Let the user know this will save cost of having the LLM to the expensive sharding operation. Give instructions for MPV NPX and PNPM global installs.]]
[[LLM: First, check if markdownExploder is set to true in bmad-core/core-config.yml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
2. Or set markdownExploder to false in bmad-core/core-config.yml
**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
1. Set markdownExploder to true in bmad-core/core-config.yml
2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
I will now proceed with the manual sharding process."
Then proceed with the manual method below ONLY if markdownExploder is false.]]
### Installation and Usage
@@ -41,19 +59,19 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
---
## Manual Method (if @kayvan/markdown-tree-parser is not available)
## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
[[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
### Task Instructions
### 1. Identify Document and Target Location
1. Identify Document and Target Location
- Determine which document to shard (user-provided path)
- Create a new folder under `docs/` with the same name as the document (without extension)
- Example: `docs/prd.md` → create folder `docs/prd/`
### 2. Parse and Extract Sections
2. Parse and Extract Sections
[[LLM: When sharding the document:
@@ -63,7 +81,7 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
- Extract the section heading and ALL content until the next level 2 section
- Include all subsections, code blocks, diagrams, lists, tables, etc.
- Be extremely careful with:
- Fenced code blocks (```) - ensure you capture the full block including closing backticks
- Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
- Mermaid diagrams - preserve the complete diagram syntax
- Nested markdown elements
- Multi-line content that might contain ## inside code blocks
@@ -82,7 +100,7 @@ For each extracted section:
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##)
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:
```txt

View File

@@ -52,6 +52,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update - remove this line to the SM]]
[[LLM: (Dev Agent) Anything the SM needs to know that deviated from the story that might impact drafting the next story.]]
### File List
[[LLM: (Dev Agent) List every new file created, or existing file modified in a bullet list.]]
### Change Log
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update- remove this line to the SM]]
@@ -59,3 +63,7 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
## QA Results
[[LLM: QA Agent Results]]

View File

@@ -42,7 +42,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid

View File

@@ -43,7 +43,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid

View File

@@ -50,7 +50,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid

View File

@@ -75,7 +75,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid

View File

@@ -51,7 +51,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid

View File

@@ -70,7 +70,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid

View File

@@ -1633,6 +1633,50 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
- **Quality Assurance**: Structured testing and validation
- **Documentation**: Professional PRDs, architecture docs, user stories
## How BMAD Works
### The Core Method
BMAD transforms you into a "Vibe CEO" - directing a team of specialized AI agents through structured workflows. Here's how:
1. **You Direct, AI Executes**: You provide vision and decisions; agents handle implementation details
2. **Specialized Agents**: Each agent masters one role (PM, Developer, Architect, etc.)
3. **Structured Workflows**: Proven patterns guide you from idea to deployed code
4. **Clean Handoffs**: Fresh context windows ensure agents stay focused and effective
### The Two-Phase Approach
**Phase 1: Planning (Web UI - Cost Effective)**
- Use large context windows (Gemini's 1M tokens)
- Generate comprehensive documents (PRD, Architecture)
- Leverage multiple agents for brainstorming
- Create once, use throughout development
**Phase 2: Development (IDE - Implementation)**
- Shard documents into manageable pieces
- Execute focused SM → Dev cycles
- One story at a time, sequential progress
- Real-time file operations and testing
### The Development Loop
```text
1. SM Agent (New Chat) → Creates next story from sharded docs
2. You → Review and approve story
3. Dev Agent (New Chat) → Implements approved story
4. QA Agent (New Chat) → Reviews and refactors code
5. You → Verify completion
6. Repeat until epic complete
```
### Why This Works
- **Context Optimization**: Clean chats = better AI performance
- **Role Clarity**: Agents don't context-switch = higher quality
- **Incremental Progress**: Small stories = manageable complexity
- **Human Oversight**: You validate each step = quality control
- **Document-Driven**: Specs guide everything = consistency
## Getting Started
### Quick Start Options
@@ -1647,7 +1691,7 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
5. Type `/help` to see available commands
#### Option 2: IDE Integration
**Best for**: Cursor, Claude Code, Windsurf, VS Code users
**Best for**: Cursor, Claude Code, Windsurf, Cline, Roo Code users
```bash
# Interactive installation (recommended)
@@ -1656,13 +1700,22 @@ npx bmad-method install
**Installation Steps**:
- Choose "Complete installation"
- Select your IDE (Cursor, Claude Code, Windsurf, or Roo Code)
- Select your IDE from supported options:
- **Cursor**: Native AI integration
- **Claude Code**: Anthropic's official IDE
- **Windsurf**: Built-in AI capabilities
- **Cline**: VS Code extension with AI features
- **Roo Code**: Web-based IDE with agent support
**Note for VS Code Users**: BMAD-METHOD assumes when you mention "VS Code" that you're using it with an AI-powered extension like GitHub Copilot, Cline, or Roo. Standard VS Code without AI capabilities cannot run BMAD agents. The installer includes built-in support for Cline and Roo.
**Verify Installation**:
- `.bmad-core/` folder created with all agents
- IDE-specific integration files created
- All agent commands/rules/modes available
**Remember**: At its core, BMAD-METHOD is about mastering and harnessing prompt engineering. Any IDE with AI agent support can use BMAD - the framework provides the structured prompts and workflows that make AI development effective
### Environment Selection Guide
**Use Web UI for**:
@@ -1679,6 +1732,105 @@ npx bmad-method install
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
### IDE-Only Workflow Considerations
**Can you do everything in IDE?** Yes, but understand the tradeoffs:
**Pros of IDE-Only**:
- Single environment workflow
- Direct file operations from start
- No copy/paste between environments
- Immediate project integration
**Cons of IDE-Only**:
- Higher token costs for large document creation
- Smaller context windows (varies by IDE/model)
- May hit limits during planning phases
- Less cost-effective for brainstorming
**Using Web Agents in IDE**:
- **NOT RECOMMENDED**: Web agents (PM, Architect) have rich dependencies designed for large contexts
- **Why it matters**: Dev agents are kept lean to maximize coding context
- **The principle**: "Dev agents code, planning agents plan" - mixing breaks this optimization
**About bmad-master and bmad-orchestrator**:
- **bmad-master**: CAN do any task without switching agents, BUT...
- **Still use specialized agents for planning**: PM, Architect, and UX Expert have tuned personas that produce better results
- **Why specialization matters**: Each agent's personality and focus creates higher quality outputs
- **If using bmad-master/orchestrator**: Fine for planning phases, but...
**CRITICAL RULE for Development**:
- **ALWAYS use SM agent for story creation** - Never use bmad-master/orchestrator
- **ALWAYS use Dev agent for implementation** - Never use bmad-master/orchestrator
- **Why this matters**: SM and Dev agents are specifically optimized for the development workflow
- **No exceptions**: Even if using bmad-master for everything else, switch to SM → Dev for implementation
**Best Practice for IDE-Only**:
1. Use PM/Architect/UX agents for planning (better than bmad-master)
2. Create documents directly in project
3. Shard immediately after creation
4. **MUST switch to SM agent** for story creation
5. **MUST switch to Dev agent** for implementation
6. Keep planning and coding in separate chat sessions
## Core Configuration (core-config.yml)
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
### What is core-config.yml?
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
- **Version Flexibility**: Work with V3, V4, or custom document structures
- **Custom Locations**: Define where your documents and shards live
- **Developer Context**: Specify which files the dev agent should always load
- **Debug Support**: Built-in logging for troubleshooting
### Key Configuration Areas
#### PRD Configuration
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
- **prdShardedLocation**: Where to find sharded epic files
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
#### Architecture Configuration
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
- **architectureSharded**: Whether architecture is split into components
- **architectureShardedLocation**: Where sharded architecture files live
#### Developer Files
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
- **devDebugLog**: Where dev agent logs repeated failures
- **agentCoreDump**: Export location for chat conversations
### Why It Matters
1. **No Forced Migrations**: Keep your existing document structure
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
3. **Custom Workflows**: Configure BMAD to match your team's process
4. **Intelligent Agents**: Agents automatically adapt to your configuration
### Common Configurations
**Legacy V3 Project**:
```yaml
prdVersion: v3
prdSharded: false
architectureVersion: v3
architectureSharded: false
```
**V4 Optimized Project**:
```yaml
prdVersion: v4
prdSharded: true
prdShardedLocation: docs/prd
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
```
## Core Philosophy
### Vibe CEO'ing
@@ -1898,10 +2050,14 @@ that can handle [specific requirements]."
**Prerequisites**: Planning documents must exist in `docs/` folder
1. **Document Sharding**:
- `@bmad-master` or `@po` shard `docs/prd.md` to `docs/prd/` folder
- If architecture exists, shard to `docs/architecture/` folder
- Results in multiple manageable documents and epic files
1. **Document Sharding** (CRITICAL STEP):
- Documents created by PM/Architect (in Web or IDE) MUST be sharded for development
- Two methods to shard:
a) **Manual**: Drag `shard-doc` task + document file into chat
b) **Agent**: Ask `@bmad-master` or `@po` to shard documents
- Shards `docs/prd.md` → `docs/prd/` folder
- Shards `docs/architecture.md` → `docs/architecture/` folder
- **WARNING**: Do NOT shard in Web UI - copying many small files is painful!
2. **Verify Sharded Content**:
- At least one `epic-n.md` file in `docs/prd/` with stories in development order
@@ -1915,19 +2071,34 @@ that can handle [specific requirements]."
3. **Development Cycle** (Sequential, one story at a time):
**Step 1 - Story Creation**: New chat window → `@sm` → `*create`
**CRITICAL CONTEXT MANAGEMENT**:
- **Context windows matter!** Always use fresh, clean context windows
- **Model selection matters!** Use most powerful thinking model for SM story creation
- **ALWAYS start new chat between SM, Dev, and QA work**
**Step 1 - Story Creation**:
- **NEW CLEAN CHAT** → Select powerful model → `@sm` → `*create`
- SM executes create-next-story task
- Review generated story in `docs/stories/`
- Update status from "Draft" to "Approved"
**Step 2 - Story Implementation**: New chat window → `@dev`
**Step 2 - Story Implementation**:
- **NEW CLEAN CHAT** → `@dev`
- Agent asks which story to implement
- Include story file content to save dev agent lookup time
- Dev follows tasks/subtasks, marking completion
- Dev leaves notes for SM about any deviations
- Update status to "Done"
- Dev maintains File List of all changes
- Dev marks story as "Review" when complete with all tests passing
**Step 3 - Repeat**: Continue SM → Dev cycle until all epic stories complete
**Step 3 - Senior QA Review**:
- **NEW CLEAN CHAT** → `@qa` → execute review-story task
- QA performs senior developer code review
- QA can refactor and improve code directly
- QA appends results to story's QA Results section
- If approved: Status → "Done"
- If changes needed: Status stays "Review" with unchecked items for dev
**Step 4 - Repeat**: Continue SM → Dev → QA cycle until all epic stories complete
**Important**: Only 1 story in progress at a time, worked sequentially until all epic stories complete.
@@ -1947,12 +2118,27 @@ Each status change requires user verification and approval before proceeding.
- Development execution
- Testing and deployment
#### Brownfield Enhancement
- Current system analysis
- Enhancement planning
- Impact assessment
- Incremental development
- Integration testing
#### Brownfield Enhancement (Existing Projects)
**Key Concept**: Brownfield development requires generating good documentation for agents to understand your existing project.
**Recommended Approach**:
1. **Analysis Phase**: Use Gemini Web or AI Studio with their 1M+ context windows
2. **Document Generation**: Ask Architect agent to analyze your project and run `document-project` task
3. **PRD Creation**: Even brownfield projects typically need a PRD unless:
- Very small, focused changes
- Using `brownfield-create-epic` for single epic without full PRD
4. **Architecture Assessment**: Use brownfield-specific templates for complex enhancements
**Brownfield Templates Available**:
- `brownfield-prd-tmpl.md`: For substantial enhancements requiring multiple stories
- `brownfield-architecture-tmpl.md`: For complex changes impacting system architecture
- Both templates emphasize compatibility and integration with existing systems
**When to Skip PRD**:
- For focused, single-epic work, use `brownfield-create-epic` task with detailed guidance
- For one-off stories without larger context
- Note: These tasks will evolve to require some documentation (potentially from `document-project`)
## Document Creation Best Practices
@@ -2033,12 +2219,94 @@ Use the `shard-doc` task or `@kayvan/markdown-tree-parser` tool for automatic sh
- **Keep conversations focused** - One agent, one task per conversation
- **Review everything** - Always review and approve before marking complete
## Contributing to BMAD-METHOD
### Quick Contribution Guidelines
For full details, see `CONTRIBUTING.md`. Key points:
**Fork Workflow**:
1. Fork the repository
2. Create feature branches
3. Submit PRs to `next` branch (default) or `main` for critical fixes only
4. Keep PRs small: 200-400 lines ideal, 800 lines maximum
5. One feature/fix per PR
**PR Requirements**:
- Clear descriptions (max 200 words) with What/Why/How/Testing
- Use conventional commits (feat:, fix:, docs:)
- Atomic commits - one logical change per commit
- Must align with guiding principles
**Core Principles** (from GUIDING-PRINCIPLES.md):
- **Dev Agents Must Be Lean**: Minimize dependencies, save context for code
- **Natural Language First**: Everything in markdown, no code in core
- **Core vs Expansion Packs**: Core for universal needs, packs for specialized domains
- **Design Philosophy**: "Dev agents code, planning agents plan"
## Expansion Packs
### What Are Expansion Packs?
Expansion packs extend BMAD-METHOD beyond traditional software development into ANY domain. They provide specialized agent teams, templates, and workflows while keeping the core framework lean and focused on development.
### Why Use Expansion Packs?
1. **Keep Core Lean**: Dev agents maintain maximum context for coding
2. **Domain Expertise**: Deep, specialized knowledge without bloating core
3. **Community Innovation**: Anyone can create and share packs
4. **Modular Design**: Install only what you need
### Available Expansion Packs
**Technical Packs**:
- **Infrastructure/DevOps**: Cloud architects, SRE experts, security specialists
- **Game Development**: Game designers, level designers, narrative writers
- **Mobile Development**: iOS/Android specialists, mobile UX experts
- **Data Science**: ML engineers, data scientists, visualization experts
**Non-Technical Packs**:
- **Business Strategy**: Consultants, financial analysts, marketing strategists
- **Creative Writing**: Plot architects, character developers, world builders
- **Health & Wellness**: Fitness trainers, nutritionists, habit engineers
- **Education**: Curriculum designers, assessment specialists
- **Legal Support**: Contract analysts, compliance checkers
**Specialty Packs**:
- **Expansion Creator**: Tools to build your own expansion packs
- **RPG Game Master**: Tabletop gaming assistance
- **Life Event Planning**: Wedding planners, event coordinators
- **Scientific Research**: Literature reviewers, methodology designers
### Using Expansion Packs
1. **Browse Available Packs**: Check `expansion-packs/` directory
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
3. **Install via CLI**:
```bash
npx bmad-method install
# Select "Install expansion pack" option
```
4. **Use in Your Workflow**: Installed packs integrate seamlessly with existing agents
### Creating Custom Expansion Packs
Use the **expansion-creator** pack to build your own:
1. **Define Domain**: What expertise are you capturing?
2. **Design Agents**: Create specialized roles with clear boundaries
3. **Build Resources**: Tasks, templates, checklists for your domain
4. **Test & Share**: Validate with real use cases, share with community
**Key Principle**: Expansion packs democratize expertise by making specialized knowledge accessible through AI agents.
## Getting Help
- **Commands**: Use `/help` in any environment to see available commands
- **Agent Switching**: Use `/switch agent-name` with orchestrator for role changes
- **Documentation**: Check `docs/` folder for project-specific context
- **Community**: Discord and GitHub resources available for support
- **Contributing**: See `CONTRIBUTING.md` for full guidelines
==================== END: data#bmad-kb ====================
==================== START: utils#template-format ====================

View File

@@ -1734,14 +1734,14 @@ To identify the next logical story based on project progress and epic definition
2. Run the BMAD installer against your project to upgrade and add the file automatically
Please add and configure core-config.yml before proceeding."
- Extract the following key configurations:
- `dev-story-location`: Where to save story files
- `devStoryLocation`: Where to save story files
- `prd.prdSharded`: Whether PRD is sharded or monolithic
- `prd.prd-file`: Location of monolithic PRD (if not sharded)
- `prd.prdFile`: Location of monolithic PRD (if not sharded)
- `prd.prdShardedLocation`: Location of sharded epic files
- `prd.epicFilePattern`: Pattern for epic files (e.g., `epic-{n}*.md`)
- `architecture.architectureVersion`: Architecture document version
- `architecture.architectureSharded`: Whether architecture is sharded
- `architecture.architecture-file`: Location of monolithic architecture
- `architecture.architectureFile`: Location of monolithic architecture
- `architecture.architectureShardedLocation`: Location of sharded architecture files
### 1. Identify Next Story for Preparation
@@ -1750,11 +1750,11 @@ To identify the next logical story based on project progress and epic definition
- Based on `prdSharded` from config:
- **If `prdSharded: true`**: Look for epic files in `prdShardedLocation` using `epicFilePattern`
- **If `prdSharded: false`**: Load the full PRD from `prd-file` and extract epics from section headings (## Epic N or ### Epic N)
- **If `prdSharded: false`**: Load the full PRD from `prdFile` and extract epics from section headings (## Epic N or ### Epic N)
#### 1.2 Review Existing Stories
- Check `dev-story-location` from config (e.g., `docs/stories/`) for existing story files
- Check `devStoryLocation` from config (e.g., `docs/stories/`) for existing story files
- If the directory exists and has at least 1 file, find the highest-numbered story file.
- **If a highest story file exists (`{lastEpicNum}.{lastStoryNum}.story.md`):**
- Verify its `Status` is 'Done' (or equivalent).
@@ -1774,12 +1774,40 @@ To identify the next logical story based on project progress and epic definition
```
- Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and check for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
- Else (story not found or prerequisites not met): The next story is the first story in the next Epic File (e.g., look for `epic-{lastEpicNum + 1}*.md`, then `epic-{lastEpicNum + 2}*.md`, etc.) whose prerequisites are met.
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and parse it to find ALL stories in that epic. **ALWAYS select the next sequential story** (e.g., if last was 2.2, next MUST be 2.3).
- If the next sequential story has unmet prerequisites, present this to the user:
```plaintext
ALERT: Next story has unmet prerequisites:
Story: {epicNum}.{storyNum} - {Story Title}
Prerequisites not met: [list specific prerequisites]
Would you like to:
1. Create the story anyway (mark prerequisites as pending)
2. Skip to a different story (requires your specific instruction)
3. Cancel story creation
Please choose an option (1/2/3):
```
- If there are no more stories in the current epic (e.g., 2.9 was done and there is no 2.10):
```plaintext
Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed.
Would you like to:
1. Begin Epic {epicNum + 1} with story {epicNum + 1}.1
2. Select a specific story to work on
3. Cancel story creation
Please choose an option (1/2/3):
```
- **CRITICAL**: NEVER automatically skip to another epic or non-sequential story. The user MUST explicitly instruct which story to create if skipping the sequential order.
- **If no story files exist in `docs/stories/`:**
- The next story is the first story in the first epic file (look for `epic-1-*.md`, then `epic-2-*.md`, etc.) whose prerequisites are met.
- If no suitable story with met prerequisites is found, report to the user that story creation is blocked, specifying what prerequisites are pending. HALT task.
- The next story is ALWAYS 1.1 (the first story of the first epic).
- If story 1.1 has unmet prerequisites, follow the same alert process as above.
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}".
### 2. Gather Core Story Requirements (from Epic)
@@ -1815,13 +1843,13 @@ Based on configuration loaded in Step 0:
- Follow the structured reading order in section 4.2 below
- **If `architectureVersion: v4` and `architectureSharded: false`**:
- Load the monolithic architecture from `architecture-file`
- Load the monolithic architecture from `architectureFile`
- Extract relevant sections based on v4 structure (tech stack, project structure, etc.)
- **If `architectureVersion` is NOT v4**:
- Inform user: "Architecture document is not v4 format. Will use best judgment to find relevant information."
- If `architectureSharded: true`: Search sharded files by filename relevance
- If `architectureSharded: false`: Search within monolithic `architecture-file` for relevant sections
- If `architectureSharded: false`: Search within monolithic `architectureFile` for relevant sections
#### 4.2 Recommended Reading Order Based on Story Type (v4 Sharded Only)
@@ -1878,7 +1906,7 @@ Format references as: `[Source: architecture/{filename}.md#{section}]`
### 6. Populate Story Template with Full Context
- Create a new story file: `{dev-story-location}/{epicNum}.{storyNum}.story.md` (using location from config).
- Create a new story file: `{devStoryLocation}/{epicNum}.{storyNum}.story.md` (using location from config).
- Use the Story Template to structure the file.
- Fill in:
- Story `{EpicNum}.{StoryNum}: {Short Title Copied from Epic File}`
@@ -1925,7 +1953,7 @@ Format references as: `[Source: architecture/{filename}.md#{section}]`
- Verify all source references are included for technical details
- Ensure tasks align with both epic requirements and architecture constraints
- Update status to "Draft"
- Save the story file to `{dev-story-location}/{epicNum}.{storyNum}.story.md` (using location from config)
- Save the story file to `{devStoryLocation}/{epicNum}.{storyNum}.story.md` (using location from config)
### 9. Report Completion
@@ -2286,9 +2314,27 @@ Would you like to proceed with documentation indexing? Please provide the requir
- Create a folder structure to organize the sharded documents
- Maintain all content integrity including code blocks, diagrams, and markdown formatting
## Recommended Method: @kayvan/markdown-tree-parser
## Primary Method: Automatic with markdown-tree
[[LLM: First, suggest the user install and use the @kayvan/markdown-tree-parser tool if the md-tree command is unavailable so we can have the best performance and reliable document sharding. Let the user know this will save cost of having the LLM to the expensive sharding operation. Give instructions for MPV NPX and PNPM global installs.]]
[[LLM: First, check if markdownExploder is set to true in bmad-core/core-config.yml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
2. Or set markdownExploder to false in bmad-core/core-config.yml
**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
1. Set markdownExploder to true in bmad-core/core-config.yml
2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
I will now proceed with the manual sharding process."
Then proceed with the manual method below ONLY if markdownExploder is false.]]
### Installation and Usage
@@ -2321,19 +2367,19 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
---
## Manual Method (if @kayvan/markdown-tree-parser is not available)
## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
[[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
### Task Instructions
### 1. Identify Document and Target Location
1. Identify Document and Target Location
- Determine which document to shard (user-provided path)
- Create a new folder under `docs/` with the same name as the document (without extension)
- Example: `docs/prd.md` → create folder `docs/prd/`
### 2. Parse and Extract Sections
2. Parse and Extract Sections
[[LLM: When sharding the document:
@@ -2343,7 +2389,7 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
- Extract the section heading and ALL content until the next level 2 section
- Include all subsections, code blocks, diagrams, lists, tables, etc.
- Be extremely careful with:
- Fenced code blocks (```) - ensure you capture the full block including closing backticks
- Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
- Mermaid diagrams - preserve the complete diagram syntax
- Nested markdown elements
- Multi-line content that might contain ## inside code blocks
@@ -2362,7 +2408,7 @@ For each extracted section:
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##)
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:
```txt
@@ -6692,6 +6738,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update - remove this line to the SM]]
[[LLM: (Dev Agent) Anything the SM needs to know that deviated from the story that might impact drafting the next story.]]
### File List
[[LLM: (Dev Agent) List every new file created, or existing file modified in a bullet list.]]
### Change Log
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update- remove this line to the SM]]
@@ -6699,6 +6749,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
## QA Results
[[LLM: QA Agent Results]]
==================== END: templates#story-tmpl ====================
==================== START: checklists#architect-checklist ====================
@@ -8440,6 +8494,50 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
- **Quality Assurance**: Structured testing and validation
- **Documentation**: Professional PRDs, architecture docs, user stories
## How BMAD Works
### The Core Method
BMAD transforms you into a "Vibe CEO" - directing a team of specialized AI agents through structured workflows. Here's how:
1. **You Direct, AI Executes**: You provide vision and decisions; agents handle implementation details
2. **Specialized Agents**: Each agent masters one role (PM, Developer, Architect, etc.)
3. **Structured Workflows**: Proven patterns guide you from idea to deployed code
4. **Clean Handoffs**: Fresh context windows ensure agents stay focused and effective
### The Two-Phase Approach
**Phase 1: Planning (Web UI - Cost Effective)**
- Use large context windows (Gemini's 1M tokens)
- Generate comprehensive documents (PRD, Architecture)
- Leverage multiple agents for brainstorming
- Create once, use throughout development
**Phase 2: Development (IDE - Implementation)**
- Shard documents into manageable pieces
- Execute focused SM → Dev cycles
- One story at a time, sequential progress
- Real-time file operations and testing
### The Development Loop
```text
1. SM Agent (New Chat) → Creates next story from sharded docs
2. You → Review and approve story
3. Dev Agent (New Chat) → Implements approved story
4. QA Agent (New Chat) → Reviews and refactors code
5. You → Verify completion
6. Repeat until epic complete
```
### Why This Works
- **Context Optimization**: Clean chats = better AI performance
- **Role Clarity**: Agents don't context-switch = higher quality
- **Incremental Progress**: Small stories = manageable complexity
- **Human Oversight**: You validate each step = quality control
- **Document-Driven**: Specs guide everything = consistency
## Getting Started
### Quick Start Options
@@ -8454,7 +8552,7 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
5. Type `/help` to see available commands
#### Option 2: IDE Integration
**Best for**: Cursor, Claude Code, Windsurf, VS Code users
**Best for**: Cursor, Claude Code, Windsurf, Cline, Roo Code users
```bash
# Interactive installation (recommended)
@@ -8463,13 +8561,22 @@ npx bmad-method install
**Installation Steps**:
- Choose "Complete installation"
- Select your IDE (Cursor, Claude Code, Windsurf, or Roo Code)
- Select your IDE from supported options:
- **Cursor**: Native AI integration
- **Claude Code**: Anthropic's official IDE
- **Windsurf**: Built-in AI capabilities
- **Cline**: VS Code extension with AI features
- **Roo Code**: Web-based IDE with agent support
**Note for VS Code Users**: BMAD-METHOD assumes when you mention "VS Code" that you're using it with an AI-powered extension like GitHub Copilot, Cline, or Roo. Standard VS Code without AI capabilities cannot run BMAD agents. The installer includes built-in support for Cline and Roo.
**Verify Installation**:
- `.bmad-core/` folder created with all agents
- IDE-specific integration files created
- All agent commands/rules/modes available
**Remember**: At its core, BMAD-METHOD is about mastering and harnessing prompt engineering. Any IDE with AI agent support can use BMAD - the framework provides the structured prompts and workflows that make AI development effective
### Environment Selection Guide
**Use Web UI for**:
@@ -8486,6 +8593,105 @@ npx bmad-method install
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
### IDE-Only Workflow Considerations
**Can you do everything in IDE?** Yes, but understand the tradeoffs:
**Pros of IDE-Only**:
- Single environment workflow
- Direct file operations from start
- No copy/paste between environments
- Immediate project integration
**Cons of IDE-Only**:
- Higher token costs for large document creation
- Smaller context windows (varies by IDE/model)
- May hit limits during planning phases
- Less cost-effective for brainstorming
**Using Web Agents in IDE**:
- **NOT RECOMMENDED**: Web agents (PM, Architect) have rich dependencies designed for large contexts
- **Why it matters**: Dev agents are kept lean to maximize coding context
- **The principle**: "Dev agents code, planning agents plan" - mixing breaks this optimization
**About bmad-master and bmad-orchestrator**:
- **bmad-master**: CAN do any task without switching agents, BUT...
- **Still use specialized agents for planning**: PM, Architect, and UX Expert have tuned personas that produce better results
- **Why specialization matters**: Each agent's personality and focus creates higher quality outputs
- **If using bmad-master/orchestrator**: Fine for planning phases, but...
**CRITICAL RULE for Development**:
- **ALWAYS use SM agent for story creation** - Never use bmad-master/orchestrator
- **ALWAYS use Dev agent for implementation** - Never use bmad-master/orchestrator
- **Why this matters**: SM and Dev agents are specifically optimized for the development workflow
- **No exceptions**: Even if using bmad-master for everything else, switch to SM → Dev for implementation
**Best Practice for IDE-Only**:
1. Use PM/Architect/UX agents for planning (better than bmad-master)
2. Create documents directly in project
3. Shard immediately after creation
4. **MUST switch to SM agent** for story creation
5. **MUST switch to Dev agent** for implementation
6. Keep planning and coding in separate chat sessions
## Core Configuration (core-config.yml)
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
### What is core-config.yml?
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
- **Version Flexibility**: Work with V3, V4, or custom document structures
- **Custom Locations**: Define where your documents and shards live
- **Developer Context**: Specify which files the dev agent should always load
- **Debug Support**: Built-in logging for troubleshooting
### Key Configuration Areas
#### PRD Configuration
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
- **prdShardedLocation**: Where to find sharded epic files
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
#### Architecture Configuration
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
- **architectureSharded**: Whether architecture is split into components
- **architectureShardedLocation**: Where sharded architecture files live
#### Developer Files
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
- **devDebugLog**: Where dev agent logs repeated failures
- **agentCoreDump**: Export location for chat conversations
### Why It Matters
1. **No Forced Migrations**: Keep your existing document structure
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
3. **Custom Workflows**: Configure BMAD to match your team's process
4. **Intelligent Agents**: Agents automatically adapt to your configuration
### Common Configurations
**Legacy V3 Project**:
```yaml
prdVersion: v3
prdSharded: false
architectureVersion: v3
architectureSharded: false
```
**V4 Optimized Project**:
```yaml
prdVersion: v4
prdSharded: true
prdShardedLocation: docs/prd
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
```
## Core Philosophy
### Vibe CEO'ing
@@ -8705,10 +8911,14 @@ that can handle [specific requirements]."
**Prerequisites**: Planning documents must exist in `docs/` folder
1. **Document Sharding**:
- `@bmad-master` or `@po` shard `docs/prd.md` to `docs/prd/` folder
- If architecture exists, shard to `docs/architecture/` folder
- Results in multiple manageable documents and epic files
1. **Document Sharding** (CRITICAL STEP):
- Documents created by PM/Architect (in Web or IDE) MUST be sharded for development
- Two methods to shard:
a) **Manual**: Drag `shard-doc` task + document file into chat
b) **Agent**: Ask `@bmad-master` or `@po` to shard documents
- Shards `docs/prd.md` → `docs/prd/` folder
- Shards `docs/architecture.md` → `docs/architecture/` folder
- **WARNING**: Do NOT shard in Web UI - copying many small files is painful!
2. **Verify Sharded Content**:
- At least one `epic-n.md` file in `docs/prd/` with stories in development order
@@ -8722,19 +8932,34 @@ that can handle [specific requirements]."
3. **Development Cycle** (Sequential, one story at a time):
**Step 1 - Story Creation**: New chat window → `@sm` → `*create`
**CRITICAL CONTEXT MANAGEMENT**:
- **Context windows matter!** Always use fresh, clean context windows
- **Model selection matters!** Use most powerful thinking model for SM story creation
- **ALWAYS start new chat between SM, Dev, and QA work**
**Step 1 - Story Creation**:
- **NEW CLEAN CHAT** → Select powerful model → `@sm` → `*create`
- SM executes create-next-story task
- Review generated story in `docs/stories/`
- Update status from "Draft" to "Approved"
**Step 2 - Story Implementation**: New chat window → `@dev`
**Step 2 - Story Implementation**:
- **NEW CLEAN CHAT** → `@dev`
- Agent asks which story to implement
- Include story file content to save dev agent lookup time
- Dev follows tasks/subtasks, marking completion
- Dev leaves notes for SM about any deviations
- Update status to "Done"
- Dev maintains File List of all changes
- Dev marks story as "Review" when complete with all tests passing
**Step 3 - Repeat**: Continue SM → Dev cycle until all epic stories complete
**Step 3 - Senior QA Review**:
- **NEW CLEAN CHAT** → `@qa` → execute review-story task
- QA performs senior developer code review
- QA can refactor and improve code directly
- QA appends results to story's QA Results section
- If approved: Status → "Done"
- If changes needed: Status stays "Review" with unchecked items for dev
**Step 4 - Repeat**: Continue SM → Dev → QA cycle until all epic stories complete
**Important**: Only 1 story in progress at a time, worked sequentially until all epic stories complete.
@@ -8754,12 +8979,27 @@ Each status change requires user verification and approval before proceeding.
- Development execution
- Testing and deployment
#### Brownfield Enhancement
- Current system analysis
- Enhancement planning
- Impact assessment
- Incremental development
- Integration testing
#### Brownfield Enhancement (Existing Projects)
**Key Concept**: Brownfield development requires generating good documentation for agents to understand your existing project.
**Recommended Approach**:
1. **Analysis Phase**: Use Gemini Web or AI Studio with their 1M+ context windows
2. **Document Generation**: Ask Architect agent to analyze your project and run `document-project` task
3. **PRD Creation**: Even brownfield projects typically need a PRD unless:
- Very small, focused changes
- Using `brownfield-create-epic` for single epic without full PRD
4. **Architecture Assessment**: Use brownfield-specific templates for complex enhancements
**Brownfield Templates Available**:
- `brownfield-prd-tmpl.md`: For substantial enhancements requiring multiple stories
- `brownfield-architecture-tmpl.md`: For complex changes impacting system architecture
- Both templates emphasize compatibility and integration with existing systems
**When to Skip PRD**:
- For focused, single-epic work, use `brownfield-create-epic` task with detailed guidance
- For one-off stories without larger context
- Note: These tasks will evolve to require some documentation (potentially from `document-project`)
## Document Creation Best Practices
@@ -8840,12 +9080,94 @@ Use the `shard-doc` task or `@kayvan/markdown-tree-parser` tool for automatic sh
- **Keep conversations focused** - One agent, one task per conversation
- **Review everything** - Always review and approve before marking complete
## Contributing to BMAD-METHOD
### Quick Contribution Guidelines
For full details, see `CONTRIBUTING.md`. Key points:
**Fork Workflow**:
1. Fork the repository
2. Create feature branches
3. Submit PRs to `next` branch (default) or `main` for critical fixes only
4. Keep PRs small: 200-400 lines ideal, 800 lines maximum
5. One feature/fix per PR
**PR Requirements**:
- Clear descriptions (max 200 words) with What/Why/How/Testing
- Use conventional commits (feat:, fix:, docs:)
- Atomic commits - one logical change per commit
- Must align with guiding principles
**Core Principles** (from GUIDING-PRINCIPLES.md):
- **Dev Agents Must Be Lean**: Minimize dependencies, save context for code
- **Natural Language First**: Everything in markdown, no code in core
- **Core vs Expansion Packs**: Core for universal needs, packs for specialized domains
- **Design Philosophy**: "Dev agents code, planning agents plan"
## Expansion Packs
### What Are Expansion Packs?
Expansion packs extend BMAD-METHOD beyond traditional software development into ANY domain. They provide specialized agent teams, templates, and workflows while keeping the core framework lean and focused on development.
### Why Use Expansion Packs?
1. **Keep Core Lean**: Dev agents maintain maximum context for coding
2. **Domain Expertise**: Deep, specialized knowledge without bloating core
3. **Community Innovation**: Anyone can create and share packs
4. **Modular Design**: Install only what you need
### Available Expansion Packs
**Technical Packs**:
- **Infrastructure/DevOps**: Cloud architects, SRE experts, security specialists
- **Game Development**: Game designers, level designers, narrative writers
- **Mobile Development**: iOS/Android specialists, mobile UX experts
- **Data Science**: ML engineers, data scientists, visualization experts
**Non-Technical Packs**:
- **Business Strategy**: Consultants, financial analysts, marketing strategists
- **Creative Writing**: Plot architects, character developers, world builders
- **Health & Wellness**: Fitness trainers, nutritionists, habit engineers
- **Education**: Curriculum designers, assessment specialists
- **Legal Support**: Contract analysts, compliance checkers
**Specialty Packs**:
- **Expansion Creator**: Tools to build your own expansion packs
- **RPG Game Master**: Tabletop gaming assistance
- **Life Event Planning**: Wedding planners, event coordinators
- **Scientific Research**: Literature reviewers, methodology designers
### Using Expansion Packs
1. **Browse Available Packs**: Check `expansion-packs/` directory
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
3. **Install via CLI**:
```bash
npx bmad-method install
# Select "Install expansion pack" option
```
4. **Use in Your Workflow**: Installed packs integrate seamlessly with existing agents
### Creating Custom Expansion Packs
Use the **expansion-creator** pack to build your own:
1. **Define Domain**: What expertise are you capturing?
2. **Design Agents**: Create specialized roles with clear boundaries
3. **Build Resources**: Tasks, templates, checklists for your domain
4. **Test & Share**: Validate with real use cases, share with community
**Key Principle**: Expansion packs democratize expertise by making specialized knowledge accessible through AI agents.
## Getting Help
- **Commands**: Use `/help` in any environment to see available commands
- **Agent Switching**: Use `/switch agent-name` with orchestrator for role changes
- **Documentation**: Check `docs/` folder for project-specific context
- **Community**: Discord and GitHub resources available for support
- **Contributing**: See `CONTRIBUTING.md` for full guidelines
==================== END: data#bmad-kb ====================
==================== START: data#technical-preferences ====================

View File

@@ -136,6 +136,11 @@ loading:
- Agents: Only when transforming
- Templates/Tasks: Only when executing
- Always indicate loading
kb-mode-behavior:
- When *kb-mode is invoked, use kb-mode-interaction task
- Don't dump all KB content immediately
- Present topic areas and wait for user selection
- Provide focused, contextual responses
workflow-guidance:
- Discover available workflows in the bundle at runtime
- Understand each workflow's purpose, options, and decision points
@@ -149,6 +154,7 @@ dependencies:
tasks:
- advanced-elicitation
- create-doc
- kb-mode-interaction
data:
- bmad-kb
utils:
@@ -329,6 +335,79 @@ If template specifies a checklist:
- Template markup is for AI processing only - never expose to users
==================== END: tasks#create-doc ====================
==================== START: tasks#kb-mode-interaction ====================
# KB Mode Interaction Task
## Purpose
Provide a user-friendly interface to the BMAD knowledge base without overwhelming users with information upfront.
## Instructions
When entering KB mode (*kb-mode), follow these steps:
### 1. Welcome and Guide
Announce entering KB mode with a brief, friendly introduction:
"I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD."
### 2. Present Topic Areas
Offer a concise list of main topic areas the user might want to explore:
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
### 3. Respond Contextually
- Wait for user's specific question or topic selection
- Provide focused, relevant information from the knowledge base
- Offer to dive deeper or explore related topics
- Keep responses concise unless user asks for detailed explanations
### 4. Interactive Exploration
- After answering, suggest related topics they might find helpful
- Maintain conversational flow rather than data dumping
- Use examples when appropriate
- Reference specific documentation sections when relevant
### 5. Exit Gracefully
When user is done or wants to exit KB mode:
- Summarize key points discussed if helpful
- Remind them they can return to KB mode anytime with *kb-mode
- Suggest next steps based on what was discussed
## Example Interaction
**User**: *kb-mode
**Assistant**: I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD.
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
**User**: Tell me about workflows
**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]
==================== END: tasks#kb-mode-interaction ====================
==================== START: data#bmad-kb ====================
# BMAD Knowledge Base
@@ -352,6 +431,50 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
- **Quality Assurance**: Structured testing and validation
- **Documentation**: Professional PRDs, architecture docs, user stories
## How BMAD Works
### The Core Method
BMAD transforms you into a "Vibe CEO" - directing a team of specialized AI agents through structured workflows. Here's how:
1. **You Direct, AI Executes**: You provide vision and decisions; agents handle implementation details
2. **Specialized Agents**: Each agent masters one role (PM, Developer, Architect, etc.)
3. **Structured Workflows**: Proven patterns guide you from idea to deployed code
4. **Clean Handoffs**: Fresh context windows ensure agents stay focused and effective
### The Two-Phase Approach
**Phase 1: Planning (Web UI - Cost Effective)**
- Use large context windows (Gemini's 1M tokens)
- Generate comprehensive documents (PRD, Architecture)
- Leverage multiple agents for brainstorming
- Create once, use throughout development
**Phase 2: Development (IDE - Implementation)**
- Shard documents into manageable pieces
- Execute focused SM → Dev cycles
- One story at a time, sequential progress
- Real-time file operations and testing
### The Development Loop
```text
1. SM Agent (New Chat) → Creates next story from sharded docs
2. You → Review and approve story
3. Dev Agent (New Chat) → Implements approved story
4. QA Agent (New Chat) → Reviews and refactors code
5. You → Verify completion
6. Repeat until epic complete
```
### Why This Works
- **Context Optimization**: Clean chats = better AI performance
- **Role Clarity**: Agents don't context-switch = higher quality
- **Incremental Progress**: Small stories = manageable complexity
- **Human Oversight**: You validate each step = quality control
- **Document-Driven**: Specs guide everything = consistency
## Getting Started
### Quick Start Options
@@ -366,7 +489,7 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
5. Type `/help` to see available commands
#### Option 2: IDE Integration
**Best for**: Cursor, Claude Code, Windsurf, VS Code users
**Best for**: Cursor, Claude Code, Windsurf, Cline, Roo Code users
```bash
# Interactive installation (recommended)
@@ -375,13 +498,22 @@ npx bmad-method install
**Installation Steps**:
- Choose "Complete installation"
- Select your IDE (Cursor, Claude Code, Windsurf, or Roo Code)
- Select your IDE from supported options:
- **Cursor**: Native AI integration
- **Claude Code**: Anthropic's official IDE
- **Windsurf**: Built-in AI capabilities
- **Cline**: VS Code extension with AI features
- **Roo Code**: Web-based IDE with agent support
**Note for VS Code Users**: BMAD-METHOD assumes when you mention "VS Code" that you're using it with an AI-powered extension like GitHub Copilot, Cline, or Roo. Standard VS Code without AI capabilities cannot run BMAD agents. The installer includes built-in support for Cline and Roo.
**Verify Installation**:
- `.bmad-core/` folder created with all agents
- IDE-specific integration files created
- All agent commands/rules/modes available
**Remember**: At its core, BMAD-METHOD is about mastering and harnessing prompt engineering. Any IDE with AI agent support can use BMAD - the framework provides the structured prompts and workflows that make AI development effective
### Environment Selection Guide
**Use Web UI for**:
@@ -398,6 +530,105 @@ npx bmad-method install
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
### IDE-Only Workflow Considerations
**Can you do everything in IDE?** Yes, but understand the tradeoffs:
**Pros of IDE-Only**:
- Single environment workflow
- Direct file operations from start
- No copy/paste between environments
- Immediate project integration
**Cons of IDE-Only**:
- Higher token costs for large document creation
- Smaller context windows (varies by IDE/model)
- May hit limits during planning phases
- Less cost-effective for brainstorming
**Using Web Agents in IDE**:
- **NOT RECOMMENDED**: Web agents (PM, Architect) have rich dependencies designed for large contexts
- **Why it matters**: Dev agents are kept lean to maximize coding context
- **The principle**: "Dev agents code, planning agents plan" - mixing breaks this optimization
**About bmad-master and bmad-orchestrator**:
- **bmad-master**: CAN do any task without switching agents, BUT...
- **Still use specialized agents for planning**: PM, Architect, and UX Expert have tuned personas that produce better results
- **Why specialization matters**: Each agent's personality and focus creates higher quality outputs
- **If using bmad-master/orchestrator**: Fine for planning phases, but...
**CRITICAL RULE for Development**:
- **ALWAYS use SM agent for story creation** - Never use bmad-master/orchestrator
- **ALWAYS use Dev agent for implementation** - Never use bmad-master/orchestrator
- **Why this matters**: SM and Dev agents are specifically optimized for the development workflow
- **No exceptions**: Even if using bmad-master for everything else, switch to SM → Dev for implementation
**Best Practice for IDE-Only**:
1. Use PM/Architect/UX agents for planning (better than bmad-master)
2. Create documents directly in project
3. Shard immediately after creation
4. **MUST switch to SM agent** for story creation
5. **MUST switch to Dev agent** for implementation
6. Keep planning and coding in separate chat sessions
## Core Configuration (core-config.yml)
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
### What is core-config.yml?
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
- **Version Flexibility**: Work with V3, V4, or custom document structures
- **Custom Locations**: Define where your documents and shards live
- **Developer Context**: Specify which files the dev agent should always load
- **Debug Support**: Built-in logging for troubleshooting
### Key Configuration Areas
#### PRD Configuration
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
- **prdShardedLocation**: Where to find sharded epic files
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
#### Architecture Configuration
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
- **architectureSharded**: Whether architecture is split into components
- **architectureShardedLocation**: Where sharded architecture files live
#### Developer Files
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
- **devDebugLog**: Where dev agent logs repeated failures
- **agentCoreDump**: Export location for chat conversations
### Why It Matters
1. **No Forced Migrations**: Keep your existing document structure
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
3. **Custom Workflows**: Configure BMAD to match your team's process
4. **Intelligent Agents**: Agents automatically adapt to your configuration
### Common Configurations
**Legacy V3 Project**:
```yaml
prdVersion: v3
prdSharded: false
architectureVersion: v3
architectureSharded: false
```
**V4 Optimized Project**:
```yaml
prdVersion: v4
prdSharded: true
prdShardedLocation: docs/prd
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
```
## Core Philosophy
### Vibe CEO'ing
@@ -617,10 +848,14 @@ that can handle [specific requirements]."
**Prerequisites**: Planning documents must exist in `docs/` folder
1. **Document Sharding**:
- `@bmad-master` or `@po` shard `docs/prd.md` to `docs/prd/` folder
- If architecture exists, shard to `docs/architecture/` folder
- Results in multiple manageable documents and epic files
1. **Document Sharding** (CRITICAL STEP):
- Documents created by PM/Architect (in Web or IDE) MUST be sharded for development
- Two methods to shard:
a) **Manual**: Drag `shard-doc` task + document file into chat
b) **Agent**: Ask `@bmad-master` or `@po` to shard documents
- Shards `docs/prd.md` → `docs/prd/` folder
- Shards `docs/architecture.md` → `docs/architecture/` folder
- **WARNING**: Do NOT shard in Web UI - copying many small files is painful!
2. **Verify Sharded Content**:
- At least one `epic-n.md` file in `docs/prd/` with stories in development order
@@ -634,19 +869,34 @@ that can handle [specific requirements]."
3. **Development Cycle** (Sequential, one story at a time):
**Step 1 - Story Creation**: New chat window → `@sm` → `*create`
**CRITICAL CONTEXT MANAGEMENT**:
- **Context windows matter!** Always use fresh, clean context windows
- **Model selection matters!** Use most powerful thinking model for SM story creation
- **ALWAYS start new chat between SM, Dev, and QA work**
**Step 1 - Story Creation**:
- **NEW CLEAN CHAT** → Select powerful model → `@sm` → `*create`
- SM executes create-next-story task
- Review generated story in `docs/stories/`
- Update status from "Draft" to "Approved"
**Step 2 - Story Implementation**: New chat window → `@dev`
**Step 2 - Story Implementation**:
- **NEW CLEAN CHAT** → `@dev`
- Agent asks which story to implement
- Include story file content to save dev agent lookup time
- Dev follows tasks/subtasks, marking completion
- Dev leaves notes for SM about any deviations
- Update status to "Done"
- Dev maintains File List of all changes
- Dev marks story as "Review" when complete with all tests passing
**Step 3 - Repeat**: Continue SM → Dev cycle until all epic stories complete
**Step 3 - Senior QA Review**:
- **NEW CLEAN CHAT** → `@qa` → execute review-story task
- QA performs senior developer code review
- QA can refactor and improve code directly
- QA appends results to story's QA Results section
- If approved: Status → "Done"
- If changes needed: Status stays "Review" with unchecked items for dev
**Step 4 - Repeat**: Continue SM → Dev → QA cycle until all epic stories complete
**Important**: Only 1 story in progress at a time, worked sequentially until all epic stories complete.
@@ -666,12 +916,27 @@ Each status change requires user verification and approval before proceeding.
- Development execution
- Testing and deployment
#### Brownfield Enhancement
- Current system analysis
- Enhancement planning
- Impact assessment
- Incremental development
- Integration testing
#### Brownfield Enhancement (Existing Projects)
**Key Concept**: Brownfield development requires generating good documentation for agents to understand your existing project.
**Recommended Approach**:
1. **Analysis Phase**: Use Gemini Web or AI Studio with their 1M+ context windows
2. **Document Generation**: Ask Architect agent to analyze your project and run `document-project` task
3. **PRD Creation**: Even brownfield projects typically need a PRD unless:
- Very small, focused changes
- Using `brownfield-create-epic` for single epic without full PRD
4. **Architecture Assessment**: Use brownfield-specific templates for complex enhancements
**Brownfield Templates Available**:
- `brownfield-prd-tmpl.md`: For substantial enhancements requiring multiple stories
- `brownfield-architecture-tmpl.md`: For complex changes impacting system architecture
- Both templates emphasize compatibility and integration with existing systems
**When to Skip PRD**:
- For focused, single-epic work, use `brownfield-create-epic` task with detailed guidance
- For one-off stories without larger context
- Note: These tasks will evolve to require some documentation (potentially from `document-project`)
## Document Creation Best Practices
@@ -752,12 +1017,94 @@ Use the `shard-doc` task or `@kayvan/markdown-tree-parser` tool for automatic sh
- **Keep conversations focused** - One agent, one task per conversation
- **Review everything** - Always review and approve before marking complete
## Contributing to BMAD-METHOD
### Quick Contribution Guidelines
For full details, see `CONTRIBUTING.md`. Key points:
**Fork Workflow**:
1. Fork the repository
2. Create feature branches
3. Submit PRs to `next` branch (default) or `main` for critical fixes only
4. Keep PRs small: 200-400 lines ideal, 800 lines maximum
5. One feature/fix per PR
**PR Requirements**:
- Clear descriptions (max 200 words) with What/Why/How/Testing
- Use conventional commits (feat:, fix:, docs:)
- Atomic commits - one logical change per commit
- Must align with guiding principles
**Core Principles** (from GUIDING-PRINCIPLES.md):
- **Dev Agents Must Be Lean**: Minimize dependencies, save context for code
- **Natural Language First**: Everything in markdown, no code in core
- **Core vs Expansion Packs**: Core for universal needs, packs for specialized domains
- **Design Philosophy**: "Dev agents code, planning agents plan"
## Expansion Packs
### What Are Expansion Packs?
Expansion packs extend BMAD-METHOD beyond traditional software development into ANY domain. They provide specialized agent teams, templates, and workflows while keeping the core framework lean and focused on development.
### Why Use Expansion Packs?
1. **Keep Core Lean**: Dev agents maintain maximum context for coding
2. **Domain Expertise**: Deep, specialized knowledge without bloating core
3. **Community Innovation**: Anyone can create and share packs
4. **Modular Design**: Install only what you need
### Available Expansion Packs
**Technical Packs**:
- **Infrastructure/DevOps**: Cloud architects, SRE experts, security specialists
- **Game Development**: Game designers, level designers, narrative writers
- **Mobile Development**: iOS/Android specialists, mobile UX experts
- **Data Science**: ML engineers, data scientists, visualization experts
**Non-Technical Packs**:
- **Business Strategy**: Consultants, financial analysts, marketing strategists
- **Creative Writing**: Plot architects, character developers, world builders
- **Health & Wellness**: Fitness trainers, nutritionists, habit engineers
- **Education**: Curriculum designers, assessment specialists
- **Legal Support**: Contract analysts, compliance checkers
**Specialty Packs**:
- **Expansion Creator**: Tools to build your own expansion packs
- **RPG Game Master**: Tabletop gaming assistance
- **Life Event Planning**: Wedding planners, event coordinators
- **Scientific Research**: Literature reviewers, methodology designers
### Using Expansion Packs
1. **Browse Available Packs**: Check `expansion-packs/` directory
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
3. **Install via CLI**:
```bash
npx bmad-method install
# Select "Install expansion pack" option
```
4. **Use in Your Workflow**: Installed packs integrate seamlessly with existing agents
### Creating Custom Expansion Packs
Use the **expansion-creator** pack to build your own:
1. **Define Domain**: What expertise are you capturing?
2. **Design Agents**: Create specialized roles with clear boundaries
3. **Build Resources**: Tasks, templates, checklists for your domain
4. **Test & Share**: Validate with real use cases, share with community
**Key Principle**: Expansion packs democratize expertise by making specialized knowledge accessible through AI agents.
## Getting Help
- **Commands**: Use `/help` in any environment to see available commands
- **Agent Switching**: Use `/switch agent-name` with orchestrator for role changes
- **Documentation**: Check `docs/` folder for project-specific context
- **Community**: Discord and GitHub resources available for support
- **Contributing**: See `CONTRIBUTING.md` for full guidelines
==================== END: data#bmad-kb ====================
==================== START: utils#workflow-management ====================

10
dist/agents/dev.txt vendored
View File

@@ -67,6 +67,7 @@ core_principles:
- CRITICAL: Dev Record Only - ONLY update story file Dev Agent Record sections (checkboxes/Debug Log/Completion Notes/Change Log)
- Strive for Sequential Task Execution - Complete tasks 1-by-1 and mark [x] as completed
- Test-Driven Quality - Write tests alongside code. Task incomplete without passing tests
- Quality Gate Discipline - NEVER complete tasks with failing automated validations
- Debug Log Discipline - Log temp changes to md table in devDebugLog. Revert after fix.
- Block Only When Critical - HALT for: missing approval/ambiguous reqs/3 failures/missing config
- Code Excellence - Clean, secure, maintainable code per loaded standards
@@ -78,15 +79,16 @@ commands:
- complete-story: Finalize to "Review"
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
task-execution:
flow: Read task→Implement→Write tests→Pass tests→Update [x]→Next task
flow: Read task→Implement→Write tests→Execute validations→Only if ALL pass→Update [x]→Next task
updates-ONLY:
- 'Checkboxes: [ ] not started | [-] in progress | [x] complete'
- 'Debug Log: | Task | File | Change | Reverted? |'
- 'Completion Notes: Deviations only, <50 words'
- 'Change Log: Requirement changes only'
blocking: Unapproved deps | Ambiguous after story check | 3 failures | Missing config
done: Code matches reqs + Tests pass + Follows standards + No lint errors
completion: All [x]→Lint→Tests(100%)→Integration(if noted)→Coverage(80%+)→E2E(if noted)→DoD→Summary→HALT
- 'File List: CRITICAL - Maintain complete list of ALL files created/modified during implementation'
blocking: Unapproved deps | Ambiguous after story check | 3 failures | Missing config | Failing validations
done: Code matches reqs + All validations pass + Follows standards + File List complete
completion: All [x]→Validations pass→Integration(if noted)→E2E(if noted)→DoD→Update File List→Mark Ready for Review→HALT
dependencies:
tasks:
- execute-checklist

32
dist/agents/pm.txt vendored
View File

@@ -978,9 +978,27 @@ The LLM will:
- Create a folder structure to organize the sharded documents
- Maintain all content integrity including code blocks, diagrams, and markdown formatting
## Recommended Method: @kayvan/markdown-tree-parser
## Primary Method: Automatic with markdown-tree
[[LLM: First, suggest the user install and use the @kayvan/markdown-tree-parser tool if the md-tree command is unavailable so we can have the best performance and reliable document sharding. Let the user know this will save cost of having the LLM to the expensive sharding operation. Give instructions for MPV NPX and PNPM global installs.]]
[[LLM: First, check if markdownExploder is set to true in bmad-core/core-config.yml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
2. Or set markdownExploder to false in bmad-core/core-config.yml
**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
1. Set markdownExploder to true in bmad-core/core-config.yml
2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
I will now proceed with the manual sharding process."
Then proceed with the manual method below ONLY if markdownExploder is false.]]
### Installation and Usage
@@ -1013,19 +1031,19 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
---
## Manual Method (if @kayvan/markdown-tree-parser is not available)
## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
[[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
### Task Instructions
### 1. Identify Document and Target Location
1. Identify Document and Target Location
- Determine which document to shard (user-provided path)
- Create a new folder under `docs/` with the same name as the document (without extension)
- Example: `docs/prd.md` → create folder `docs/prd/`
### 2. Parse and Extract Sections
2. Parse and Extract Sections
[[LLM: When sharding the document:
@@ -1035,7 +1053,7 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
- Extract the section heading and ALL content until the next level 2 section
- Include all subsections, code blocks, diagrams, lists, tables, etc.
- Be extremely careful with:
- Fenced code blocks (```) - ensure you capture the full block including closing backticks
- Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
- Mermaid diagrams - preserve the complete diagram syntax
- Nested markdown elements
- Multi-line content that might contain ## inside code blocks
@@ -1054,7 +1072,7 @@ For each extracted section:
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##)
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:
```txt

40
dist/agents/po.txt vendored
View File

@@ -210,9 +210,27 @@ The LLM will:
- Create a folder structure to organize the sharded documents
- Maintain all content integrity including code blocks, diagrams, and markdown formatting
## Recommended Method: @kayvan/markdown-tree-parser
## Primary Method: Automatic with markdown-tree
[[LLM: First, suggest the user install and use the @kayvan/markdown-tree-parser tool if the md-tree command is unavailable so we can have the best performance and reliable document sharding. Let the user know this will save cost of having the LLM to the expensive sharding operation. Give instructions for MPV NPX and PNPM global installs.]]
[[LLM: First, check if markdownExploder is set to true in bmad-core/core-config.yml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
2. Or set markdownExploder to false in bmad-core/core-config.yml
**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
1. Set markdownExploder to true in bmad-core/core-config.yml
2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
I will now proceed with the manual sharding process."
Then proceed with the manual method below ONLY if markdownExploder is false.]]
### Installation and Usage
@@ -245,19 +263,19 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
---
## Manual Method (if @kayvan/markdown-tree-parser is not available)
## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
[[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
### Task Instructions
### 1. Identify Document and Target Location
1. Identify Document and Target Location
- Determine which document to shard (user-provided path)
- Create a new folder under `docs/` with the same name as the document (without extension)
- Example: `docs/prd.md` → create folder `docs/prd/`
### 2. Parse and Extract Sections
2. Parse and Extract Sections
[[LLM: When sharding the document:
@@ -267,7 +285,7 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
- Extract the section heading and ALL content until the next level 2 section
- Include all subsections, code blocks, diagrams, lists, tables, etc.
- Be extremely careful with:
- Fenced code blocks (```) - ensure you capture the full block including closing backticks
- Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
- Mermaid diagrams - preserve the complete diagram syntax
- Nested markdown elements
- Multi-line content that might contain ## inside code blocks
@@ -286,7 +304,7 @@ For each extracted section:
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##)
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:
```txt
@@ -821,6 +839,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update - remove this line to the SM]]
[[LLM: (Dev Agent) Anything the SM needs to know that deviated from the story that might impact drafting the next story.]]
### File List
[[LLM: (Dev Agent) List every new file created, or existing file modified in a bullet list.]]
### Change Log
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update- remove this line to the SM]]
@@ -828,6 +850,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
## QA Results
[[LLM: QA Agent Results]]
==================== END: templates#story-tmpl ====================
==================== START: checklists#po-master-checklist ====================

167
dist/agents/qa.txt vendored
View File

@@ -52,34 +52,35 @@ activation-instructions:
agent:
name: Quinn
id: qa
title: Quality Assurance Test Architect
title: Senior Developer & QA Architect
icon: 🧪
whenToUse: Use for test planning, test case creation, quality assurance, bug reporting, and testing strategy
whenToUse: Use for senior code review, refactoring, test planning, quality assurance, and mentoring through code improvements
customization: null
persona:
role: Test Architect & Automation Expert
style: Methodical, detail-oriented, quality-focused, strategic
identity: Senior quality advocate with expertise in test architecture and automation
focus: Comprehensive testing strategies, automation frameworks, quality assurance at every phase
role: Senior Developer & Test Architect
style: Methodical, detail-oriented, quality-focused, mentoring, strategic
identity: Senior developer with deep expertise in code quality, architecture, and test automation
focus: Code excellence through review, refactoring, and comprehensive testing strategies
core_principles:
- Senior Developer Mindset - Review and improve code as a senior mentoring juniors
- Active Refactoring - Don't just identify issues, fix them with clear explanations
- Test Strategy & Architecture - Design holistic testing strategies across all levels
- Automation Excellence - Build maintainable and efficient test automation frameworks
- Code Quality Excellence - Enforce best practices, patterns, and clean code principles
- Shift-Left Testing - Integrate testing early in development lifecycle
- Performance & Security - Proactively identify and fix performance/security issues
- Mentorship Through Action - Explain WHY and HOW when making improvements
- Risk-Based Testing - Prioritize testing based on risk and critical areas
- Performance & Load Testing - Ensure systems meet performance requirements
- Security Testing Integration - Incorporate security testing into QA process
- Test Data Management - Design strategies for realistic and compliant test data
- Continuous Testing & CI/CD - Integrate tests seamlessly into pipelines
- Quality Metrics & Reporting - Track meaningful metrics and provide insights
- Cross-Browser & Cross-Platform Testing - Ensure comprehensive compatibility
- Continuous Improvement - Balance perfection with pragmatism
- Architecture & Design Patterns - Ensure proper patterns and maintainable code structure
startup:
- Greet the user with your name and role, and inform of the *help command.
commands:
- help: Show numbered list of the following commands to allow selection
- chat-mode: (Default) QA consultation with advanced-elicitation for test strategy
- create-doc {template}: Create doc (no template = show available templates)
- exit: Say goodbye as the QA Test Architect, and then abandon inhabiting this persona
dependencies:
tasks:
- review-story
data:
- technical-preferences
utils:
@@ -87,6 +88,144 @@ dependencies:
```
==================== END: agents#qa ====================
==================== START: tasks#review-story ====================
# review-story
When a developer marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
[[LLM: QA Agent executing review-story task as Senior Developer]]
## Prerequisites
- Story status must be "Review"
- Developer has completed all tasks and updated the File List
- All automated tests are passing
## Review Process
1. **Read the Complete Story**
- Review all acceptance criteria
- Understand the dev notes and requirements
- Note any completion notes from the developer
2. **Focus on the File List**
- Verify all files listed were actually created/modified
- Check for any missing files that should have been updated
3. **Senior Developer Code Review**
- Review code with the eye of a senior developer
- If changes form a cohesive whole, review them together
- If changes are independent, review incrementally file by file
- Focus on:
- Code architecture and design patterns
- Refactoring opportunities
- Code duplication or inefficiencies
- Performance optimizations
- Security concerns
- Best practices and patterns
4. **Active Refactoring**
- As a senior developer, you CAN and SHOULD refactor code where improvements are needed
- When refactoring:
- Make the changes directly in the files
- Explain WHY you're making the change
- Describe HOW the change improves the code
- Ensure all tests still pass after refactoring
- Update the File List if you modify additional files
5. **Standards Compliance Check**
- Verify adherence to `docs/coding-standards.md`
- Check compliance with `docs/unified-project-structure.md`
- Validate testing approach against `docs/testing-strategy.md`
- Ensure all guidelines mentioned in the story are followed
6. **Acceptance Criteria Validation**
- Verify each AC is fully implemented
- Check for any missing functionality
- Validate edge cases are handled
7. **Test Coverage Review**
- Ensure unit tests cover edge cases
- Add missing tests if critical coverage is lacking
- Verify integration tests (if required) are comprehensive
- Check that test assertions are meaningful
- Look for missing test scenarios
8. **Documentation and Comments**
- Verify code is self-documenting where possible
- Add comments for complex logic if missing
- Ensure any API changes are documented
## Append Results to Story File
After review and any refactoring, append your results to the story file in the QA Results section:
```markdown
## QA Results
### Review Date: [Date]
### Reviewed By: Quinn (Senior Developer QA)
### Code Quality Assessment
[Overall assessment of implementation quality]
### Refactoring Performed
[List any refactoring you performed with explanations]
- **File**: [filename]
- **Change**: [what was changed]
- **Why**: [reason for change]
- **How**: [how it improves the code]
### Compliance Check
- Coding Standards: [✓/✗] [notes if any]
- Project Structure: [✓/✗] [notes if any]
- Testing Strategy: [✓/✗] [notes if any]
- All ACs Met: [✓/✗] [notes if any]
### Improvements Checklist
[Check off items you handled yourself, leave unchecked for dev to address]
- [x] Refactored user service for better error handling (services/user.service.ts)
- [x] Added missing edge case tests (services/user.service.test.ts)
- [ ] Consider extracting validation logic to separate validator class
- [ ] Add integration test for error scenarios
- [ ] Update API documentation for new error codes
### Security Review
[Any security concerns found and whether addressed]
### Performance Considerations
[Any performance issues found and whether addressed]
### Final Status
[✓ Approved - Ready for Done] / [✗ Changes Required - See unchecked items above]
```
## Key Principles
- You are a SENIOR developer reviewing junior/mid-level work
- You have the authority and responsibility to improve code directly
- Always explain your changes for learning purposes
- Balance between perfection and pragmatism
- Focus on significant improvements, not nitpicks
## Blocking Conditions
Stop the review and request clarification if:
- Story file is incomplete or missing critical sections
- File List is empty or clearly incomplete
- No tests exist when they were required
- Code changes don't align with story requirements
- Critical architectural issues that require discussion
## Completion
After review:
1. If all items are checked and approved: Update story status to "Done"
2. If unchecked items remain: Keep status as "Review" for dev to address
3. Always provide constructive feedback and explanations for learning
==================== END: tasks#review-story ====================
==================== START: data#technical-preferences ====================
# User-Defined Preferred Patterns and Preferences

62
dist/agents/sm.txt vendored
View File

@@ -109,14 +109,14 @@ To identify the next logical story based on project progress and epic definition
2. Run the BMAD installer against your project to upgrade and add the file automatically
Please add and configure core-config.yml before proceeding."
- Extract the following key configurations:
- `dev-story-location`: Where to save story files
- `devStoryLocation`: Where to save story files
- `prd.prdSharded`: Whether PRD is sharded or monolithic
- `prd.prd-file`: Location of monolithic PRD (if not sharded)
- `prd.prdFile`: Location of monolithic PRD (if not sharded)
- `prd.prdShardedLocation`: Location of sharded epic files
- `prd.epicFilePattern`: Pattern for epic files (e.g., `epic-{n}*.md`)
- `architecture.architectureVersion`: Architecture document version
- `architecture.architectureSharded`: Whether architecture is sharded
- `architecture.architecture-file`: Location of monolithic architecture
- `architecture.architectureFile`: Location of monolithic architecture
- `architecture.architectureShardedLocation`: Location of sharded architecture files
### 1. Identify Next Story for Preparation
@@ -125,11 +125,11 @@ To identify the next logical story based on project progress and epic definition
- Based on `prdSharded` from config:
- **If `prdSharded: true`**: Look for epic files in `prdShardedLocation` using `epicFilePattern`
- **If `prdSharded: false`**: Load the full PRD from `prd-file` and extract epics from section headings (## Epic N or ### Epic N)
- **If `prdSharded: false`**: Load the full PRD from `prdFile` and extract epics from section headings (## Epic N or ### Epic N)
#### 1.2 Review Existing Stories
- Check `dev-story-location` from config (e.g., `docs/stories/`) for existing story files
- Check `devStoryLocation` from config (e.g., `docs/stories/`) for existing story files
- If the directory exists and has at least 1 file, find the highest-numbered story file.
- **If a highest story file exists (`{lastEpicNum}.{lastStoryNum}.story.md`):**
- Verify its `Status` is 'Done' (or equivalent).
@@ -149,12 +149,40 @@ To identify the next logical story based on project progress and epic definition
```
- Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and check for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
- Else (story not found or prerequisites not met): The next story is the first story in the next Epic File (e.g., look for `epic-{lastEpicNum + 1}*.md`, then `epic-{lastEpicNum + 2}*.md`, etc.) whose prerequisites are met.
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and parse it to find ALL stories in that epic. **ALWAYS select the next sequential story** (e.g., if last was 2.2, next MUST be 2.3).
- If the next sequential story has unmet prerequisites, present this to the user:
```plaintext
ALERT: Next story has unmet prerequisites:
Story: {epicNum}.{storyNum} - {Story Title}
Prerequisites not met: [list specific prerequisites]
Would you like to:
1. Create the story anyway (mark prerequisites as pending)
2. Skip to a different story (requires your specific instruction)
3. Cancel story creation
Please choose an option (1/2/3):
```
- If there are no more stories in the current epic (e.g., 2.9 was done and there is no 2.10):
```plaintext
Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed.
Would you like to:
1. Begin Epic {epicNum + 1} with story {epicNum + 1}.1
2. Select a specific story to work on
3. Cancel story creation
Please choose an option (1/2/3):
```
- **CRITICAL**: NEVER automatically skip to another epic or non-sequential story. The user MUST explicitly instruct which story to create if skipping the sequential order.
- **If no story files exist in `docs/stories/`:**
- The next story is the first story in the first epic file (look for `epic-1-*.md`, then `epic-2-*.md`, etc.) whose prerequisites are met.
- If no suitable story with met prerequisites is found, report to the user that story creation is blocked, specifying what prerequisites are pending. HALT task.
- The next story is ALWAYS 1.1 (the first story of the first epic).
- If story 1.1 has unmet prerequisites, follow the same alert process as above.
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}".
### 2. Gather Core Story Requirements (from Epic)
@@ -190,13 +218,13 @@ Based on configuration loaded in Step 0:
- Follow the structured reading order in section 4.2 below
- **If `architectureVersion: v4` and `architectureSharded: false`**:
- Load the monolithic architecture from `architecture-file`
- Load the monolithic architecture from `architectureFile`
- Extract relevant sections based on v4 structure (tech stack, project structure, etc.)
- **If `architectureVersion` is NOT v4**:
- Inform user: "Architecture document is not v4 format. Will use best judgment to find relevant information."
- If `architectureSharded: true`: Search sharded files by filename relevance
- If `architectureSharded: false`: Search within monolithic `architecture-file` for relevant sections
- If `architectureSharded: false`: Search within monolithic `architectureFile` for relevant sections
#### 4.2 Recommended Reading Order Based on Story Type (v4 Sharded Only)
@@ -253,7 +281,7 @@ Format references as: `[Source: architecture/{filename}.md#{section}]`
### 6. Populate Story Template with Full Context
- Create a new story file: `{dev-story-location}/{epicNum}.{storyNum}.story.md` (using location from config).
- Create a new story file: `{devStoryLocation}/{epicNum}.{storyNum}.story.md` (using location from config).
- Use the Story Template to structure the file.
- Fill in:
- Story `{EpicNum}.{StoryNum}: {Short Title Copied from Epic File}`
@@ -300,7 +328,7 @@ Format references as: `[Source: architecture/{filename}.md#{section}]`
- Verify all source references are included for technical details
- Ensure tasks align with both epic requirements and architecture constraints
- Update status to "Draft"
- Save the story file to `{dev-story-location}/{epicNum}.{storyNum}.story.md` (using location from config)
- Save the story file to `{devStoryLocation}/{epicNum}.{storyNum}.story.md` (using location from config)
### 9. Report Completion
@@ -471,6 +499,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update - remove this line to the SM]]
[[LLM: (Dev Agent) Anything the SM needs to know that deviated from the story that might impact drafting the next story.]]
### File List
[[LLM: (Dev Agent) List every new file created, or existing file modified in a bullet list.]]
### Change Log
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update- remove this line to the SM]]
@@ -478,6 +510,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
## QA Results
[[LLM: QA Agent Results]]
==================== END: templates#story-tmpl ====================
==================== START: checklists#story-draft-checklist ====================

View File

@@ -214,6 +214,11 @@ loading:
- Agents: Only when transforming
- Templates/Tasks: Only when executing
- Always indicate loading
kb-mode-behavior:
- When *kb-mode is invoked, use kb-mode-interaction task
- Don't dump all KB content immediately
- Present topic areas and wait for user selection
- Provide focused, contextual responses
workflow-guidance:
- Discover available workflows in the bundle at runtime
- Understand each workflow's purpose, options, and decision points
@@ -227,6 +232,7 @@ dependencies:
tasks:
- advanced-elicitation
- create-doc
- kb-mode-interaction
data:
- bmad-kb
utils:
@@ -2234,6 +2240,79 @@ Templates in the BMAD method use standardized markup for AI processing. These co
- All template-specific instructions are embedded within templates
==================== END: utils#template-format ====================
==================== START: tasks#kb-mode-interaction ====================
# KB Mode Interaction Task
## Purpose
Provide a user-friendly interface to the BMAD knowledge base without overwhelming users with information upfront.
## Instructions
When entering KB mode (*kb-mode), follow these steps:
### 1. Welcome and Guide
Announce entering KB mode with a brief, friendly introduction:
"I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD."
### 2. Present Topic Areas
Offer a concise list of main topic areas the user might want to explore:
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
### 3. Respond Contextually
- Wait for user's specific question or topic selection
- Provide focused, relevant information from the knowledge base
- Offer to dive deeper or explore related topics
- Keep responses concise unless user asks for detailed explanations
### 4. Interactive Exploration
- After answering, suggest related topics they might find helpful
- Maintain conversational flow rather than data dumping
- Use examples when appropriate
- Reference specific documentation sections when relevant
### 5. Exit Gracefully
When user is done or wants to exit KB mode:
- Summarize key points discussed if helpful
- Remind them they can return to KB mode anytime with *kb-mode
- Suggest next steps based on what was discussed
## Example Interaction
**User**: *kb-mode
**Assistant**: I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD.
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
**User**: Tell me about workflows
**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]
==================== END: tasks#kb-mode-interaction ====================
==================== START: utils#workflow-management ====================
# Workflow Management

View File

@@ -101,7 +101,7 @@ This task guides you through creating a new BMAD agent following the standard te
## Prerequisites
- Agent template: `.bmad-core/templates/agent-tmpl.md`
- Agent template: `../templates/agent-tmpl.md`
- Target directory: `.bmad-core/agents/`
## Steps
@@ -318,7 +318,7 @@ Every expansion pack MUST include a custom BMAD orchestrator agent with sophisti
1. **Create Planning Document First**: Before any implementation, create a comprehensive plan for user approval
2. **Agent Architecture Standards**: Use YAML-in-Markdown structure with activation instructions, personas, and command systems
3. **Character Consistency**: Every agent must have a persistent persona with name, communication style, and numbered options protocol
3. **Character Consistency**: Every agent must have a persistent persona with name, communication style, and numbered options protocol similar to `expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.md`
4. **Custom Themed Orchestrator**: The orchestrator should embody the domain theme (e.g., Office Manager for medical, Project Lead for tech) for better user experience
5. **Core Utilities Required**: ALWAYS include these core files in every expansion pack:
- `tasks/create-doc.md` - Document creation from templates
@@ -326,8 +326,8 @@ Every expansion pack MUST include a custom BMAD orchestrator agent with sophisti
- `utils/template-format.md` - Template markup conventions
- `utils/workflow-management.md` - Workflow orchestration
6. **Team and Workflow Requirements**: If pack has >1 agent, MUST include:
- At least one team configuration in `agent-teams/`
- At least one workflow in `workflows/`
- At least one team configuration in `expansion-packs/{new-expansion}/agent-teams/`
- At least one workflow in `expansion-packs/{new-expansion}workflows/`
7. **Template Sophistication**: Implement LLM instruction embedding with `[[LLM: guidance]]`, conditional content, and variable systems
8. **Workflow Orchestration**: Include decision trees, handoff protocols, and validation loops
9. **Quality Assurance Integration**: Multi-level checklists with star ratings and ready/not-ready frameworks
@@ -1318,14 +1318,6 @@ Embedded knowledge (automatic):
- [ ] Template conditional content tested with different scenarios
- [ ] Workflow decision trees validated with sample use cases
- [ ] Character interactions tested for consistency and professional authenticity
```
```
```
```
==================== END: tasks#generate-expansion-pack ====================
==================== START: tasks#advanced-elicitation ====================

File diff suppressed because it is too large Load Diff

View File

@@ -157,6 +157,11 @@ loading:
- Agents: Only when transforming
- Templates/Tasks: Only when executing
- Always indicate loading
kb-mode-behavior:
- When *kb-mode is invoked, use kb-mode-interaction task
- Don't dump all KB content immediately
- Present topic areas and wait for user selection
- Provide focused, contextual responses
workflow-guidance:
- Discover available workflows in the bundle at runtime
- Understand each workflow's purpose, options, and decision points
@@ -170,6 +175,7 @@ dependencies:
tasks:
- advanced-elicitation
- create-doc
- kb-mode-interaction
data:
- bmad-kb
utils:
@@ -663,6 +669,79 @@ If template specifies a checklist:
- Template markup is for AI processing only - never expose to users
==================== END: tasks#create-doc ====================
==================== START: tasks#kb-mode-interaction ====================
# KB Mode Interaction Task
## Purpose
Provide a user-friendly interface to the BMAD knowledge base without overwhelming users with information upfront.
## Instructions
When entering KB mode (*kb-mode), follow these steps:
### 1. Welcome and Guide
Announce entering KB mode with a brief, friendly introduction:
"I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD."
### 2. Present Topic Areas
Offer a concise list of main topic areas the user might want to explore:
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
### 3. Respond Contextually
- Wait for user's specific question or topic selection
- Provide focused, relevant information from the knowledge base
- Offer to dive deeper or explore related topics
- Keep responses concise unless user asks for detailed explanations
### 4. Interactive Exploration
- After answering, suggest related topics they might find helpful
- Maintain conversational flow rather than data dumping
- Use examples when appropriate
- Reference specific documentation sections when relevant
### 5. Exit Gracefully
When user is done or wants to exit KB mode:
- Summarize key points discussed if helpful
- Remind them they can return to KB mode anytime with *kb-mode
- Suggest next steps based on what was discussed
## Example Interaction
**User**: *kb-mode
**Assistant**: I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD.
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
**User**: Tell me about workflows
**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]
==================== END: tasks#kb-mode-interaction ====================
==================== START: data#bmad-kb ====================
# BMAD Knowledge Base
@@ -686,6 +765,50 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
- **Quality Assurance**: Structured testing and validation
- **Documentation**: Professional PRDs, architecture docs, user stories
## How BMAD Works
### The Core Method
BMAD transforms you into a "Vibe CEO" - directing a team of specialized AI agents through structured workflows. Here's how:
1. **You Direct, AI Executes**: You provide vision and decisions; agents handle implementation details
2. **Specialized Agents**: Each agent masters one role (PM, Developer, Architect, etc.)
3. **Structured Workflows**: Proven patterns guide you from idea to deployed code
4. **Clean Handoffs**: Fresh context windows ensure agents stay focused and effective
### The Two-Phase Approach
**Phase 1: Planning (Web UI - Cost Effective)**
- Use large context windows (Gemini's 1M tokens)
- Generate comprehensive documents (PRD, Architecture)
- Leverage multiple agents for brainstorming
- Create once, use throughout development
**Phase 2: Development (IDE - Implementation)**
- Shard documents into manageable pieces
- Execute focused SM → Dev cycles
- One story at a time, sequential progress
- Real-time file operations and testing
### The Development Loop
```text
1. SM Agent (New Chat) → Creates next story from sharded docs
2. You → Review and approve story
3. Dev Agent (New Chat) → Implements approved story
4. QA Agent (New Chat) → Reviews and refactors code
5. You → Verify completion
6. Repeat until epic complete
```
### Why This Works
- **Context Optimization**: Clean chats = better AI performance
- **Role Clarity**: Agents don't context-switch = higher quality
- **Incremental Progress**: Small stories = manageable complexity
- **Human Oversight**: You validate each step = quality control
- **Document-Driven**: Specs guide everything = consistency
## Getting Started
### Quick Start Options
@@ -700,7 +823,7 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
5. Type `/help` to see available commands
#### Option 2: IDE Integration
**Best for**: Cursor, Claude Code, Windsurf, VS Code users
**Best for**: Cursor, Claude Code, Windsurf, Cline, Roo Code users
```bash
# Interactive installation (recommended)
@@ -709,13 +832,22 @@ npx bmad-method install
**Installation Steps**:
- Choose "Complete installation"
- Select your IDE (Cursor, Claude Code, Windsurf, or Roo Code)
- Select your IDE from supported options:
- **Cursor**: Native AI integration
- **Claude Code**: Anthropic's official IDE
- **Windsurf**: Built-in AI capabilities
- **Cline**: VS Code extension with AI features
- **Roo Code**: Web-based IDE with agent support
**Note for VS Code Users**: BMAD-METHOD assumes when you mention "VS Code" that you're using it with an AI-powered extension like GitHub Copilot, Cline, or Roo. Standard VS Code without AI capabilities cannot run BMAD agents. The installer includes built-in support for Cline and Roo.
**Verify Installation**:
- `.bmad-core/` folder created with all agents
- IDE-specific integration files created
- All agent commands/rules/modes available
**Remember**: At its core, BMAD-METHOD is about mastering and harnessing prompt engineering. Any IDE with AI agent support can use BMAD - the framework provides the structured prompts and workflows that make AI development effective
### Environment Selection Guide
**Use Web UI for**:
@@ -732,6 +864,105 @@ npx bmad-method install
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
### IDE-Only Workflow Considerations
**Can you do everything in IDE?** Yes, but understand the tradeoffs:
**Pros of IDE-Only**:
- Single environment workflow
- Direct file operations from start
- No copy/paste between environments
- Immediate project integration
**Cons of IDE-Only**:
- Higher token costs for large document creation
- Smaller context windows (varies by IDE/model)
- May hit limits during planning phases
- Less cost-effective for brainstorming
**Using Web Agents in IDE**:
- **NOT RECOMMENDED**: Web agents (PM, Architect) have rich dependencies designed for large contexts
- **Why it matters**: Dev agents are kept lean to maximize coding context
- **The principle**: "Dev agents code, planning agents plan" - mixing breaks this optimization
**About bmad-master and bmad-orchestrator**:
- **bmad-master**: CAN do any task without switching agents, BUT...
- **Still use specialized agents for planning**: PM, Architect, and UX Expert have tuned personas that produce better results
- **Why specialization matters**: Each agent's personality and focus creates higher quality outputs
- **If using bmad-master/orchestrator**: Fine for planning phases, but...
**CRITICAL RULE for Development**:
- **ALWAYS use SM agent for story creation** - Never use bmad-master/orchestrator
- **ALWAYS use Dev agent for implementation** - Never use bmad-master/orchestrator
- **Why this matters**: SM and Dev agents are specifically optimized for the development workflow
- **No exceptions**: Even if using bmad-master for everything else, switch to SM → Dev for implementation
**Best Practice for IDE-Only**:
1. Use PM/Architect/UX agents for planning (better than bmad-master)
2. Create documents directly in project
3. Shard immediately after creation
4. **MUST switch to SM agent** for story creation
5. **MUST switch to Dev agent** for implementation
6. Keep planning and coding in separate chat sessions
## Core Configuration (core-config.yml)
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
### What is core-config.yml?
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
- **Version Flexibility**: Work with V3, V4, or custom document structures
- **Custom Locations**: Define where your documents and shards live
- **Developer Context**: Specify which files the dev agent should always load
- **Debug Support**: Built-in logging for troubleshooting
### Key Configuration Areas
#### PRD Configuration
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
- **prdShardedLocation**: Where to find sharded epic files
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
#### Architecture Configuration
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
- **architectureSharded**: Whether architecture is split into components
- **architectureShardedLocation**: Where sharded architecture files live
#### Developer Files
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
- **devDebugLog**: Where dev agent logs repeated failures
- **agentCoreDump**: Export location for chat conversations
### Why It Matters
1. **No Forced Migrations**: Keep your existing document structure
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
3. **Custom Workflows**: Configure BMAD to match your team's process
4. **Intelligent Agents**: Agents automatically adapt to your configuration
### Common Configurations
**Legacy V3 Project**:
```yaml
prdVersion: v3
prdSharded: false
architectureVersion: v3
architectureSharded: false
```
**V4 Optimized Project**:
```yaml
prdVersion: v4
prdSharded: true
prdShardedLocation: docs/prd
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
```
## Core Philosophy
### Vibe CEO'ing
@@ -951,10 +1182,14 @@ that can handle [specific requirements]."
**Prerequisites**: Planning documents must exist in `docs/` folder
1. **Document Sharding**:
- `@bmad-master` or `@po` shard `docs/prd.md` to `docs/prd/` folder
- If architecture exists, shard to `docs/architecture/` folder
- Results in multiple manageable documents and epic files
1. **Document Sharding** (CRITICAL STEP):
- Documents created by PM/Architect (in Web or IDE) MUST be sharded for development
- Two methods to shard:
a) **Manual**: Drag `shard-doc` task + document file into chat
b) **Agent**: Ask `@bmad-master` or `@po` to shard documents
- Shards `docs/prd.md` → `docs/prd/` folder
- Shards `docs/architecture.md` → `docs/architecture/` folder
- **WARNING**: Do NOT shard in Web UI - copying many small files is painful!
2. **Verify Sharded Content**:
- At least one `epic-n.md` file in `docs/prd/` with stories in development order
@@ -968,19 +1203,34 @@ that can handle [specific requirements]."
3. **Development Cycle** (Sequential, one story at a time):
**Step 1 - Story Creation**: New chat window → `@sm` → `*create`
**CRITICAL CONTEXT MANAGEMENT**:
- **Context windows matter!** Always use fresh, clean context windows
- **Model selection matters!** Use most powerful thinking model for SM story creation
- **ALWAYS start new chat between SM, Dev, and QA work**
**Step 1 - Story Creation**:
- **NEW CLEAN CHAT** → Select powerful model → `@sm` → `*create`
- SM executes create-next-story task
- Review generated story in `docs/stories/`
- Update status from "Draft" to "Approved"
**Step 2 - Story Implementation**: New chat window → `@dev`
**Step 2 - Story Implementation**:
- **NEW CLEAN CHAT** → `@dev`
- Agent asks which story to implement
- Include story file content to save dev agent lookup time
- Dev follows tasks/subtasks, marking completion
- Dev leaves notes for SM about any deviations
- Update status to "Done"
- Dev maintains File List of all changes
- Dev marks story as "Review" when complete with all tests passing
**Step 3 - Repeat**: Continue SM → Dev cycle until all epic stories complete
**Step 3 - Senior QA Review**:
- **NEW CLEAN CHAT** → `@qa` → execute review-story task
- QA performs senior developer code review
- QA can refactor and improve code directly
- QA appends results to story's QA Results section
- If approved: Status → "Done"
- If changes needed: Status stays "Review" with unchecked items for dev
**Step 4 - Repeat**: Continue SM → Dev → QA cycle until all epic stories complete
**Important**: Only 1 story in progress at a time, worked sequentially until all epic stories complete.
@@ -1000,12 +1250,27 @@ Each status change requires user verification and approval before proceeding.
- Development execution
- Testing and deployment
#### Brownfield Enhancement
- Current system analysis
- Enhancement planning
- Impact assessment
- Incremental development
- Integration testing
#### Brownfield Enhancement (Existing Projects)
**Key Concept**: Brownfield development requires generating good documentation for agents to understand your existing project.
**Recommended Approach**:
1. **Analysis Phase**: Use Gemini Web or AI Studio with their 1M+ context windows
2. **Document Generation**: Ask Architect agent to analyze your project and run `document-project` task
3. **PRD Creation**: Even brownfield projects typically need a PRD unless:
- Very small, focused changes
- Using `brownfield-create-epic` for single epic without full PRD
4. **Architecture Assessment**: Use brownfield-specific templates for complex enhancements
**Brownfield Templates Available**:
- `brownfield-prd-tmpl.md`: For substantial enhancements requiring multiple stories
- `brownfield-architecture-tmpl.md`: For complex changes impacting system architecture
- Both templates emphasize compatibility and integration with existing systems
**When to Skip PRD**:
- For focused, single-epic work, use `brownfield-create-epic` task with detailed guidance
- For one-off stories without larger context
- Note: These tasks will evolve to require some documentation (potentially from `document-project`)
## Document Creation Best Practices
@@ -1086,12 +1351,94 @@ Use the `shard-doc` task or `@kayvan/markdown-tree-parser` tool for automatic sh
- **Keep conversations focused** - One agent, one task per conversation
- **Review everything** - Always review and approve before marking complete
## Contributing to BMAD-METHOD
### Quick Contribution Guidelines
For full details, see `CONTRIBUTING.md`. Key points:
**Fork Workflow**:
1. Fork the repository
2. Create feature branches
3. Submit PRs to `next` branch (default) or `main` for critical fixes only
4. Keep PRs small: 200-400 lines ideal, 800 lines maximum
5. One feature/fix per PR
**PR Requirements**:
- Clear descriptions (max 200 words) with What/Why/How/Testing
- Use conventional commits (feat:, fix:, docs:)
- Atomic commits - one logical change per commit
- Must align with guiding principles
**Core Principles** (from GUIDING-PRINCIPLES.md):
- **Dev Agents Must Be Lean**: Minimize dependencies, save context for code
- **Natural Language First**: Everything in markdown, no code in core
- **Core vs Expansion Packs**: Core for universal needs, packs for specialized domains
- **Design Philosophy**: "Dev agents code, planning agents plan"
## Expansion Packs
### What Are Expansion Packs?
Expansion packs extend BMAD-METHOD beyond traditional software development into ANY domain. They provide specialized agent teams, templates, and workflows while keeping the core framework lean and focused on development.
### Why Use Expansion Packs?
1. **Keep Core Lean**: Dev agents maintain maximum context for coding
2. **Domain Expertise**: Deep, specialized knowledge without bloating core
3. **Community Innovation**: Anyone can create and share packs
4. **Modular Design**: Install only what you need
### Available Expansion Packs
**Technical Packs**:
- **Infrastructure/DevOps**: Cloud architects, SRE experts, security specialists
- **Game Development**: Game designers, level designers, narrative writers
- **Mobile Development**: iOS/Android specialists, mobile UX experts
- **Data Science**: ML engineers, data scientists, visualization experts
**Non-Technical Packs**:
- **Business Strategy**: Consultants, financial analysts, marketing strategists
- **Creative Writing**: Plot architects, character developers, world builders
- **Health & Wellness**: Fitness trainers, nutritionists, habit engineers
- **Education**: Curriculum designers, assessment specialists
- **Legal Support**: Contract analysts, compliance checkers
**Specialty Packs**:
- **Expansion Creator**: Tools to build your own expansion packs
- **RPG Game Master**: Tabletop gaming assistance
- **Life Event Planning**: Wedding planners, event coordinators
- **Scientific Research**: Literature reviewers, methodology designers
### Using Expansion Packs
1. **Browse Available Packs**: Check `expansion-packs/` directory
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
3. **Install via CLI**:
```bash
npx bmad-method install
# Select "Install expansion pack" option
```
4. **Use in Your Workflow**: Installed packs integrate seamlessly with existing agents
### Creating Custom Expansion Packs
Use the **expansion-creator** pack to build your own:
1. **Define Domain**: What expertise are you capturing?
2. **Design Agents**: Create specialized roles with clear boundaries
3. **Build Resources**: Tasks, templates, checklists for your domain
4. **Test & Share**: Validate with real use cases, share with community
**Key Principle**: Expansion packs democratize expertise by making specialized knowledge accessible through AI agents.
## Getting Help
- **Commands**: Use `/help` in any environment to see available commands
- **Agent Switching**: Use `/switch agent-name` with orchestrator for role changes
- **Documentation**: Check `docs/` folder for project-specific context
- **Community**: Discord and GitHub resources available for support
- **Contributing**: See `CONTRIBUTING.md` for full guidelines
==================== END: data#bmad-kb ====================
==================== START: utils#workflow-management ====================
@@ -3185,9 +3532,27 @@ The LLM will:
- Create a folder structure to organize the sharded documents
- Maintain all content integrity including code blocks, diagrams, and markdown formatting
## Recommended Method: @kayvan/markdown-tree-parser
## Primary Method: Automatic with markdown-tree
[[LLM: First, suggest the user install and use the @kayvan/markdown-tree-parser tool if the md-tree command is unavailable so we can have the best performance and reliable document sharding. Let the user know this will save cost of having the LLM to the expensive sharding operation. Give instructions for MPV NPX and PNPM global installs.]]
[[LLM: First, check if markdownExploder is set to true in bmad-core/core-config.yml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
2. Or set markdownExploder to false in bmad-core/core-config.yml
**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
1. Set markdownExploder to true in bmad-core/core-config.yml
2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
I will now proceed with the manual sharding process."
Then proceed with the manual method below ONLY if markdownExploder is false.]]
### Installation and Usage
@@ -3220,19 +3585,19 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
---
## Manual Method (if @kayvan/markdown-tree-parser is not available)
## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
[[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
### Task Instructions
### 1. Identify Document and Target Location
1. Identify Document and Target Location
- Determine which document to shard (user-provided path)
- Create a new folder under `docs/` with the same name as the document (without extension)
- Example: `docs/prd.md` → create folder `docs/prd/`
### 2. Parse and Extract Sections
2. Parse and Extract Sections
[[LLM: When sharding the document:
@@ -3242,7 +3607,7 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
- Extract the section heading and ALL content until the next level 2 section
- Include all subsections, code blocks, diagrams, lists, tables, etc.
- Be extremely careful with:
- Fenced code blocks (```) - ensure you capture the full block including closing backticks
- Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
- Mermaid diagrams - preserve the complete diagram syntax
- Nested markdown elements
- Multi-line content that might contain ## inside code blocks
@@ -3261,7 +3626,7 @@ For each extracted section:
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##)
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:
```txt
@@ -8259,6 +8624,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update - remove this line to the SM]]
[[LLM: (Dev Agent) Anything the SM needs to know that deviated from the story that might impact drafting the next story.]]
### File List
[[LLM: (Dev Agent) List every new file created, or existing file modified in a bullet list.]]
### Change Log
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update- remove this line to the SM]]
@@ -8266,6 +8635,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
## QA Results
[[LLM: QA Agent Results]]
==================== END: templates#story-tmpl ====================
==================== START: checklists#po-master-checklist ====================
@@ -8757,7 +9130,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid
@@ -8809,7 +9217,7 @@ workflow:
sequence:
- step: service_analysis
agent: architect
agent: architect
action: analyze existing project and use task document-project
creates: multiple documents per the document-project template
notes: "Review existing service documentation, codebase, performance metrics, and identify integration dependencies."
@@ -8838,7 +9246,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid
@@ -8926,7 +9369,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid
@@ -9042,7 +9520,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid
@@ -9152,7 +9665,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid
@@ -9271,7 +9819,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid

View File

@@ -149,6 +149,11 @@ loading:
- Agents: Only when transforming
- Templates/Tasks: Only when executing
- Always indicate loading
kb-mode-behavior:
- When *kb-mode is invoked, use kb-mode-interaction task
- Don't dump all KB content immediately
- Present topic areas and wait for user selection
- Provide focused, contextual responses
workflow-guidance:
- Discover available workflows in the bundle at runtime
- Understand each workflow's purpose, options, and decision points
@@ -162,6 +167,7 @@ dependencies:
tasks:
- advanced-elicitation
- create-doc
- kb-mode-interaction
data:
- bmad-kb
utils:
@@ -313,6 +319,7 @@ core_principles:
- CRITICAL: Dev Record Only - ONLY update story file Dev Agent Record sections (checkboxes/Debug Log/Completion Notes/Change Log)
- Strive for Sequential Task Execution - Complete tasks 1-by-1 and mark [x] as completed
- Test-Driven Quality - Write tests alongside code. Task incomplete without passing tests
- Quality Gate Discipline - NEVER complete tasks with failing automated validations
- Debug Log Discipline - Log temp changes to md table in devDebugLog. Revert after fix.
- Block Only When Critical - HALT for: missing approval/ambiguous reqs/3 failures/missing config
- Code Excellence - Clean, secure, maintainable code per loaded standards
@@ -324,15 +331,16 @@ commands:
- complete-story: Finalize to "Review"
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
task-execution:
flow: Read task→Implement→Write tests→Pass tests→Update [x]→Next task
flow: Read task→Implement→Write tests→Execute validations→Only if ALL pass→Update [x]→Next task
updates-ONLY:
- 'Checkboxes: [ ] not started | [-] in progress | [x] complete'
- 'Debug Log: | Task | File | Change | Reverted? |'
- 'Completion Notes: Deviations only, <50 words'
- 'Change Log: Requirement changes only'
blocking: Unapproved deps | Ambiguous after story check | 3 failures | Missing config
done: Code matches reqs + Tests pass + Follows standards + No lint errors
completion: All [x]→Lint→Tests(100%)→Integration(if noted)→Coverage(80%+)→E2E(if noted)→DoD→Summary→HALT
- 'File List: CRITICAL - Maintain complete list of ALL files created/modified during implementation'
blocking: Unapproved deps | Ambiguous after story check | 3 failures | Missing config | Failing validations
done: Code matches reqs + All validations pass + Follows standards + File List complete
completion: All [x]→Validations pass→Integration(if noted)→E2E(if noted)→DoD→Update File List→Mark Ready for Review→HALT
dependencies:
tasks:
- execute-checklist
@@ -355,34 +363,35 @@ activation-instructions:
agent:
name: Quinn
id: qa
title: Quality Assurance Test Architect
title: Senior Developer & QA Architect
icon: 🧪
whenToUse: Use for test planning, test case creation, quality assurance, bug reporting, and testing strategy
whenToUse: Use for senior code review, refactoring, test planning, quality assurance, and mentoring through code improvements
customization: null
persona:
role: Test Architect & Automation Expert
style: Methodical, detail-oriented, quality-focused, strategic
identity: Senior quality advocate with expertise in test architecture and automation
focus: Comprehensive testing strategies, automation frameworks, quality assurance at every phase
role: Senior Developer & Test Architect
style: Methodical, detail-oriented, quality-focused, mentoring, strategic
identity: Senior developer with deep expertise in code quality, architecture, and test automation
focus: Code excellence through review, refactoring, and comprehensive testing strategies
core_principles:
- Senior Developer Mindset - Review and improve code as a senior mentoring juniors
- Active Refactoring - Don't just identify issues, fix them with clear explanations
- Test Strategy & Architecture - Design holistic testing strategies across all levels
- Automation Excellence - Build maintainable and efficient test automation frameworks
- Code Quality Excellence - Enforce best practices, patterns, and clean code principles
- Shift-Left Testing - Integrate testing early in development lifecycle
- Performance & Security - Proactively identify and fix performance/security issues
- Mentorship Through Action - Explain WHY and HOW when making improvements
- Risk-Based Testing - Prioritize testing based on risk and critical areas
- Performance & Load Testing - Ensure systems meet performance requirements
- Security Testing Integration - Incorporate security testing into QA process
- Test Data Management - Design strategies for realistic and compliant test data
- Continuous Testing & CI/CD - Integrate tests seamlessly into pipelines
- Quality Metrics & Reporting - Track meaningful metrics and provide insights
- Cross-Browser & Cross-Platform Testing - Ensure comprehensive compatibility
- Continuous Improvement - Balance perfection with pragmatism
- Architecture & Design Patterns - Ensure proper patterns and maintainable code structure
startup:
- Greet the user with your name and role, and inform of the *help command.
commands:
- help: Show numbered list of the following commands to allow selection
- chat-mode: (Default) QA consultation with advanced-elicitation for test strategy
- create-doc {template}: Create doc (no template = show available templates)
- exit: Say goodbye as the QA Test Architect, and then abandon inhabiting this persona
dependencies:
tasks:
- review-story
data:
- technical-preferences
utils:
@@ -562,6 +571,79 @@ If template specifies a checklist:
- Template markup is for AI processing only - never expose to users
==================== END: tasks#create-doc ====================
==================== START: tasks#kb-mode-interaction ====================
# KB Mode Interaction Task
## Purpose
Provide a user-friendly interface to the BMAD knowledge base without overwhelming users with information upfront.
## Instructions
When entering KB mode (*kb-mode), follow these steps:
### 1. Welcome and Guide
Announce entering KB mode with a brief, friendly introduction:
"I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD."
### 2. Present Topic Areas
Offer a concise list of main topic areas the user might want to explore:
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
### 3. Respond Contextually
- Wait for user's specific question or topic selection
- Provide focused, relevant information from the knowledge base
- Offer to dive deeper or explore related topics
- Keep responses concise unless user asks for detailed explanations
### 4. Interactive Exploration
- After answering, suggest related topics they might find helpful
- Maintain conversational flow rather than data dumping
- Use examples when appropriate
- Reference specific documentation sections when relevant
### 5. Exit Gracefully
When user is done or wants to exit KB mode:
- Summarize key points discussed if helpful
- Remind them they can return to KB mode anytime with *kb-mode
- Suggest next steps based on what was discussed
## Example Interaction
**User**: *kb-mode
**Assistant**: I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD.
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
**User**: Tell me about workflows
**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]
==================== END: tasks#kb-mode-interaction ====================
==================== START: data#bmad-kb ====================
# BMAD Knowledge Base
@@ -585,6 +667,50 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
- **Quality Assurance**: Structured testing and validation
- **Documentation**: Professional PRDs, architecture docs, user stories
## How BMAD Works
### The Core Method
BMAD transforms you into a "Vibe CEO" - directing a team of specialized AI agents through structured workflows. Here's how:
1. **You Direct, AI Executes**: You provide vision and decisions; agents handle implementation details
2. **Specialized Agents**: Each agent masters one role (PM, Developer, Architect, etc.)
3. **Structured Workflows**: Proven patterns guide you from idea to deployed code
4. **Clean Handoffs**: Fresh context windows ensure agents stay focused and effective
### The Two-Phase Approach
**Phase 1: Planning (Web UI - Cost Effective)**
- Use large context windows (Gemini's 1M tokens)
- Generate comprehensive documents (PRD, Architecture)
- Leverage multiple agents for brainstorming
- Create once, use throughout development
**Phase 2: Development (IDE - Implementation)**
- Shard documents into manageable pieces
- Execute focused SM → Dev cycles
- One story at a time, sequential progress
- Real-time file operations and testing
### The Development Loop
```text
1. SM Agent (New Chat) → Creates next story from sharded docs
2. You → Review and approve story
3. Dev Agent (New Chat) → Implements approved story
4. QA Agent (New Chat) → Reviews and refactors code
5. You → Verify completion
6. Repeat until epic complete
```
### Why This Works
- **Context Optimization**: Clean chats = better AI performance
- **Role Clarity**: Agents don't context-switch = higher quality
- **Incremental Progress**: Small stories = manageable complexity
- **Human Oversight**: You validate each step = quality control
- **Document-Driven**: Specs guide everything = consistency
## Getting Started
### Quick Start Options
@@ -599,7 +725,7 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
5. Type `/help` to see available commands
#### Option 2: IDE Integration
**Best for**: Cursor, Claude Code, Windsurf, VS Code users
**Best for**: Cursor, Claude Code, Windsurf, Cline, Roo Code users
```bash
# Interactive installation (recommended)
@@ -608,13 +734,22 @@ npx bmad-method install
**Installation Steps**:
- Choose "Complete installation"
- Select your IDE (Cursor, Claude Code, Windsurf, or Roo Code)
- Select your IDE from supported options:
- **Cursor**: Native AI integration
- **Claude Code**: Anthropic's official IDE
- **Windsurf**: Built-in AI capabilities
- **Cline**: VS Code extension with AI features
- **Roo Code**: Web-based IDE with agent support
**Note for VS Code Users**: BMAD-METHOD assumes when you mention "VS Code" that you're using it with an AI-powered extension like GitHub Copilot, Cline, or Roo. Standard VS Code without AI capabilities cannot run BMAD agents. The installer includes built-in support for Cline and Roo.
**Verify Installation**:
- `.bmad-core/` folder created with all agents
- IDE-specific integration files created
- All agent commands/rules/modes available
**Remember**: At its core, BMAD-METHOD is about mastering and harnessing prompt engineering. Any IDE with AI agent support can use BMAD - the framework provides the structured prompts and workflows that make AI development effective
### Environment Selection Guide
**Use Web UI for**:
@@ -631,6 +766,105 @@ npx bmad-method install
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
### IDE-Only Workflow Considerations
**Can you do everything in IDE?** Yes, but understand the tradeoffs:
**Pros of IDE-Only**:
- Single environment workflow
- Direct file operations from start
- No copy/paste between environments
- Immediate project integration
**Cons of IDE-Only**:
- Higher token costs for large document creation
- Smaller context windows (varies by IDE/model)
- May hit limits during planning phases
- Less cost-effective for brainstorming
**Using Web Agents in IDE**:
- **NOT RECOMMENDED**: Web agents (PM, Architect) have rich dependencies designed for large contexts
- **Why it matters**: Dev agents are kept lean to maximize coding context
- **The principle**: "Dev agents code, planning agents plan" - mixing breaks this optimization
**About bmad-master and bmad-orchestrator**:
- **bmad-master**: CAN do any task without switching agents, BUT...
- **Still use specialized agents for planning**: PM, Architect, and UX Expert have tuned personas that produce better results
- **Why specialization matters**: Each agent's personality and focus creates higher quality outputs
- **If using bmad-master/orchestrator**: Fine for planning phases, but...
**CRITICAL RULE for Development**:
- **ALWAYS use SM agent for story creation** - Never use bmad-master/orchestrator
- **ALWAYS use Dev agent for implementation** - Never use bmad-master/orchestrator
- **Why this matters**: SM and Dev agents are specifically optimized for the development workflow
- **No exceptions**: Even if using bmad-master for everything else, switch to SM → Dev for implementation
**Best Practice for IDE-Only**:
1. Use PM/Architect/UX agents for planning (better than bmad-master)
2. Create documents directly in project
3. Shard immediately after creation
4. **MUST switch to SM agent** for story creation
5. **MUST switch to Dev agent** for implementation
6. Keep planning and coding in separate chat sessions
## Core Configuration (core-config.yml)
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
### What is core-config.yml?
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
- **Version Flexibility**: Work with V3, V4, or custom document structures
- **Custom Locations**: Define where your documents and shards live
- **Developer Context**: Specify which files the dev agent should always load
- **Debug Support**: Built-in logging for troubleshooting
### Key Configuration Areas
#### PRD Configuration
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
- **prdShardedLocation**: Where to find sharded epic files
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
#### Architecture Configuration
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
- **architectureSharded**: Whether architecture is split into components
- **architectureShardedLocation**: Where sharded architecture files live
#### Developer Files
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
- **devDebugLog**: Where dev agent logs repeated failures
- **agentCoreDump**: Export location for chat conversations
### Why It Matters
1. **No Forced Migrations**: Keep your existing document structure
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
3. **Custom Workflows**: Configure BMAD to match your team's process
4. **Intelligent Agents**: Agents automatically adapt to your configuration
### Common Configurations
**Legacy V3 Project**:
```yaml
prdVersion: v3
prdSharded: false
architectureVersion: v3
architectureSharded: false
```
**V4 Optimized Project**:
```yaml
prdVersion: v4
prdSharded: true
prdShardedLocation: docs/prd
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
```
## Core Philosophy
### Vibe CEO'ing
@@ -850,10 +1084,14 @@ that can handle [specific requirements]."
**Prerequisites**: Planning documents must exist in `docs/` folder
1. **Document Sharding**:
- `@bmad-master` or `@po` shard `docs/prd.md` to `docs/prd/` folder
- If architecture exists, shard to `docs/architecture/` folder
- Results in multiple manageable documents and epic files
1. **Document Sharding** (CRITICAL STEP):
- Documents created by PM/Architect (in Web or IDE) MUST be sharded for development
- Two methods to shard:
a) **Manual**: Drag `shard-doc` task + document file into chat
b) **Agent**: Ask `@bmad-master` or `@po` to shard documents
- Shards `docs/prd.md` → `docs/prd/` folder
- Shards `docs/architecture.md` → `docs/architecture/` folder
- **WARNING**: Do NOT shard in Web UI - copying many small files is painful!
2. **Verify Sharded Content**:
- At least one `epic-n.md` file in `docs/prd/` with stories in development order
@@ -867,19 +1105,34 @@ that can handle [specific requirements]."
3. **Development Cycle** (Sequential, one story at a time):
**Step 1 - Story Creation**: New chat window → `@sm` → `*create`
**CRITICAL CONTEXT MANAGEMENT**:
- **Context windows matter!** Always use fresh, clean context windows
- **Model selection matters!** Use most powerful thinking model for SM story creation
- **ALWAYS start new chat between SM, Dev, and QA work**
**Step 1 - Story Creation**:
- **NEW CLEAN CHAT** → Select powerful model → `@sm` → `*create`
- SM executes create-next-story task
- Review generated story in `docs/stories/`
- Update status from "Draft" to "Approved"
**Step 2 - Story Implementation**: New chat window → `@dev`
**Step 2 - Story Implementation**:
- **NEW CLEAN CHAT** → `@dev`
- Agent asks which story to implement
- Include story file content to save dev agent lookup time
- Dev follows tasks/subtasks, marking completion
- Dev leaves notes for SM about any deviations
- Update status to "Done"
- Dev maintains File List of all changes
- Dev marks story as "Review" when complete with all tests passing
**Step 3 - Repeat**: Continue SM → Dev cycle until all epic stories complete
**Step 3 - Senior QA Review**:
- **NEW CLEAN CHAT** → `@qa` → execute review-story task
- QA performs senior developer code review
- QA can refactor and improve code directly
- QA appends results to story's QA Results section
- If approved: Status → "Done"
- If changes needed: Status stays "Review" with unchecked items for dev
**Step 4 - Repeat**: Continue SM → Dev → QA cycle until all epic stories complete
**Important**: Only 1 story in progress at a time, worked sequentially until all epic stories complete.
@@ -899,12 +1152,27 @@ Each status change requires user verification and approval before proceeding.
- Development execution
- Testing and deployment
#### Brownfield Enhancement
- Current system analysis
- Enhancement planning
- Impact assessment
- Incremental development
- Integration testing
#### Brownfield Enhancement (Existing Projects)
**Key Concept**: Brownfield development requires generating good documentation for agents to understand your existing project.
**Recommended Approach**:
1. **Analysis Phase**: Use Gemini Web or AI Studio with their 1M+ context windows
2. **Document Generation**: Ask Architect agent to analyze your project and run `document-project` task
3. **PRD Creation**: Even brownfield projects typically need a PRD unless:
- Very small, focused changes
- Using `brownfield-create-epic` for single epic without full PRD
4. **Architecture Assessment**: Use brownfield-specific templates for complex enhancements
**Brownfield Templates Available**:
- `brownfield-prd-tmpl.md`: For substantial enhancements requiring multiple stories
- `brownfield-architecture-tmpl.md`: For complex changes impacting system architecture
- Both templates emphasize compatibility and integration with existing systems
**When to Skip PRD**:
- For focused, single-epic work, use `brownfield-create-epic` task with detailed guidance
- For one-off stories without larger context
- Note: These tasks will evolve to require some documentation (potentially from `document-project`)
## Document Creation Best Practices
@@ -985,12 +1253,94 @@ Use the `shard-doc` task or `@kayvan/markdown-tree-parser` tool for automatic sh
- **Keep conversations focused** - One agent, one task per conversation
- **Review everything** - Always review and approve before marking complete
## Contributing to BMAD-METHOD
### Quick Contribution Guidelines
For full details, see `CONTRIBUTING.md`. Key points:
**Fork Workflow**:
1. Fork the repository
2. Create feature branches
3. Submit PRs to `next` branch (default) or `main` for critical fixes only
4. Keep PRs small: 200-400 lines ideal, 800 lines maximum
5. One feature/fix per PR
**PR Requirements**:
- Clear descriptions (max 200 words) with What/Why/How/Testing
- Use conventional commits (feat:, fix:, docs:)
- Atomic commits - one logical change per commit
- Must align with guiding principles
**Core Principles** (from GUIDING-PRINCIPLES.md):
- **Dev Agents Must Be Lean**: Minimize dependencies, save context for code
- **Natural Language First**: Everything in markdown, no code in core
- **Core vs Expansion Packs**: Core for universal needs, packs for specialized domains
- **Design Philosophy**: "Dev agents code, planning agents plan"
## Expansion Packs
### What Are Expansion Packs?
Expansion packs extend BMAD-METHOD beyond traditional software development into ANY domain. They provide specialized agent teams, templates, and workflows while keeping the core framework lean and focused on development.
### Why Use Expansion Packs?
1. **Keep Core Lean**: Dev agents maintain maximum context for coding
2. **Domain Expertise**: Deep, specialized knowledge without bloating core
3. **Community Innovation**: Anyone can create and share packs
4. **Modular Design**: Install only what you need
### Available Expansion Packs
**Technical Packs**:
- **Infrastructure/DevOps**: Cloud architects, SRE experts, security specialists
- **Game Development**: Game designers, level designers, narrative writers
- **Mobile Development**: iOS/Android specialists, mobile UX experts
- **Data Science**: ML engineers, data scientists, visualization experts
**Non-Technical Packs**:
- **Business Strategy**: Consultants, financial analysts, marketing strategists
- **Creative Writing**: Plot architects, character developers, world builders
- **Health & Wellness**: Fitness trainers, nutritionists, habit engineers
- **Education**: Curriculum designers, assessment specialists
- **Legal Support**: Contract analysts, compliance checkers
**Specialty Packs**:
- **Expansion Creator**: Tools to build your own expansion packs
- **RPG Game Master**: Tabletop gaming assistance
- **Life Event Planning**: Wedding planners, event coordinators
- **Scientific Research**: Literature reviewers, methodology designers
### Using Expansion Packs
1. **Browse Available Packs**: Check `expansion-packs/` directory
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
3. **Install via CLI**:
```bash
npx bmad-method install
# Select "Install expansion pack" option
```
4. **Use in Your Workflow**: Installed packs integrate seamlessly with existing agents
### Creating Custom Expansion Packs
Use the **expansion-creator** pack to build your own:
1. **Define Domain**: What expertise are you capturing?
2. **Design Agents**: Create specialized roles with clear boundaries
3. **Build Resources**: Tasks, templates, checklists for your domain
4. **Test & Share**: Validate with real use cases, share with community
**Key Principle**: Expansion packs democratize expertise by making specialized knowledge accessible through AI agents.
## Getting Help
- **Commands**: Use `/help` in any environment to see available commands
- **Agent Switching**: Use `/switch agent-name` with orchestrator for role changes
- **Documentation**: Check `docs/` folder for project-specific context
- **Community**: Discord and GitHub resources available for support
- **Contributing**: See `CONTRIBUTING.md` for full guidelines
==================== END: data#bmad-kb ====================
==================== START: utils#workflow-management ====================
@@ -1357,9 +1707,27 @@ The LLM will:
- Create a folder structure to organize the sharded documents
- Maintain all content integrity including code blocks, diagrams, and markdown formatting
## Recommended Method: @kayvan/markdown-tree-parser
## Primary Method: Automatic with markdown-tree
[[LLM: First, suggest the user install and use the @kayvan/markdown-tree-parser tool if the md-tree command is unavailable so we can have the best performance and reliable document sharding. Let the user know this will save cost of having the LLM to the expensive sharding operation. Give instructions for MPV NPX and PNPM global installs.]]
[[LLM: First, check if markdownExploder is set to true in bmad-core/core-config.yml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
2. Or set markdownExploder to false in bmad-core/core-config.yml
**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
1. Set markdownExploder to true in bmad-core/core-config.yml
2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
I will now proceed with the manual sharding process."
Then proceed with the manual method below ONLY if markdownExploder is false.]]
### Installation and Usage
@@ -1392,19 +1760,19 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
---
## Manual Method (if @kayvan/markdown-tree-parser is not available)
## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
[[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
### Task Instructions
### 1. Identify Document and Target Location
1. Identify Document and Target Location
- Determine which document to shard (user-provided path)
- Create a new folder under `docs/` with the same name as the document (without extension)
- Example: `docs/prd.md` → create folder `docs/prd/`
### 2. Parse and Extract Sections
2. Parse and Extract Sections
[[LLM: When sharding the document:
@@ -1414,7 +1782,7 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
- Extract the section heading and ALL content until the next level 2 section
- Include all subsections, code blocks, diagrams, lists, tables, etc.
- Be extremely careful with:
- Fenced code blocks (```) - ensure you capture the full block including closing backticks
- Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
- Mermaid diagrams - preserve the complete diagram syntax
- Nested markdown elements
- Multi-line content that might contain ## inside code blocks
@@ -1433,7 +1801,7 @@ For each extracted section:
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##)
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:
```txt
@@ -1968,6 +2336,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update - remove this line to the SM]]
[[LLM: (Dev Agent) Anything the SM needs to know that deviated from the story that might impact drafting the next story.]]
### File List
[[LLM: (Dev Agent) List every new file created, or existing file modified in a bullet list.]]
### Change Log
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update- remove this line to the SM]]
@@ -1975,6 +2347,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
## QA Results
[[LLM: QA Agent Results]]
==================== END: templates#story-tmpl ====================
==================== START: checklists#po-master-checklist ====================
@@ -2626,14 +3002,14 @@ To identify the next logical story based on project progress and epic definition
2. Run the BMAD installer against your project to upgrade and add the file automatically
Please add and configure core-config.yml before proceeding."
- Extract the following key configurations:
- `dev-story-location`: Where to save story files
- `devStoryLocation`: Where to save story files
- `prd.prdSharded`: Whether PRD is sharded or monolithic
- `prd.prd-file`: Location of monolithic PRD (if not sharded)
- `prd.prdFile`: Location of monolithic PRD (if not sharded)
- `prd.prdShardedLocation`: Location of sharded epic files
- `prd.epicFilePattern`: Pattern for epic files (e.g., `epic-{n}*.md`)
- `architecture.architectureVersion`: Architecture document version
- `architecture.architectureSharded`: Whether architecture is sharded
- `architecture.architecture-file`: Location of monolithic architecture
- `architecture.architectureFile`: Location of monolithic architecture
- `architecture.architectureShardedLocation`: Location of sharded architecture files
### 1. Identify Next Story for Preparation
@@ -2642,11 +3018,11 @@ To identify the next logical story based on project progress and epic definition
- Based on `prdSharded` from config:
- **If `prdSharded: true`**: Look for epic files in `prdShardedLocation` using `epicFilePattern`
- **If `prdSharded: false`**: Load the full PRD from `prd-file` and extract epics from section headings (## Epic N or ### Epic N)
- **If `prdSharded: false`**: Load the full PRD from `prdFile` and extract epics from section headings (## Epic N or ### Epic N)
#### 1.2 Review Existing Stories
- Check `dev-story-location` from config (e.g., `docs/stories/`) for existing story files
- Check `devStoryLocation` from config (e.g., `docs/stories/`) for existing story files
- If the directory exists and has at least 1 file, find the highest-numbered story file.
- **If a highest story file exists (`{lastEpicNum}.{lastStoryNum}.story.md`):**
- Verify its `Status` is 'Done' (or equivalent).
@@ -2666,12 +3042,40 @@ To identify the next logical story based on project progress and epic definition
```
- Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and check for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
- Else (story not found or prerequisites not met): The next story is the first story in the next Epic File (e.g., look for `epic-{lastEpicNum + 1}*.md`, then `epic-{lastEpicNum + 2}*.md`, etc.) whose prerequisites are met.
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and parse it to find ALL stories in that epic. **ALWAYS select the next sequential story** (e.g., if last was 2.2, next MUST be 2.3).
- If the next sequential story has unmet prerequisites, present this to the user:
```plaintext
ALERT: Next story has unmet prerequisites:
Story: {epicNum}.{storyNum} - {Story Title}
Prerequisites not met: [list specific prerequisites]
Would you like to:
1. Create the story anyway (mark prerequisites as pending)
2. Skip to a different story (requires your specific instruction)
3. Cancel story creation
Please choose an option (1/2/3):
```
- If there are no more stories in the current epic (e.g., 2.9 was done and there is no 2.10):
```plaintext
Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed.
Would you like to:
1. Begin Epic {epicNum + 1} with story {epicNum + 1}.1
2. Select a specific story to work on
3. Cancel story creation
Please choose an option (1/2/3):
```
- **CRITICAL**: NEVER automatically skip to another epic or non-sequential story. The user MUST explicitly instruct which story to create if skipping the sequential order.
- **If no story files exist in `docs/stories/`:**
- The next story is the first story in the first epic file (look for `epic-1-*.md`, then `epic-2-*.md`, etc.) whose prerequisites are met.
- If no suitable story with met prerequisites is found, report to the user that story creation is blocked, specifying what prerequisites are pending. HALT task.
- The next story is ALWAYS 1.1 (the first story of the first epic).
- If story 1.1 has unmet prerequisites, follow the same alert process as above.
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}".
### 2. Gather Core Story Requirements (from Epic)
@@ -2707,13 +3111,13 @@ Based on configuration loaded in Step 0:
- Follow the structured reading order in section 4.2 below
- **If `architectureVersion: v4` and `architectureSharded: false`**:
- Load the monolithic architecture from `architecture-file`
- Load the monolithic architecture from `architectureFile`
- Extract relevant sections based on v4 structure (tech stack, project structure, etc.)
- **If `architectureVersion` is NOT v4**:
- Inform user: "Architecture document is not v4 format. Will use best judgment to find relevant information."
- If `architectureSharded: true`: Search sharded files by filename relevance
- If `architectureSharded: false`: Search within monolithic `architecture-file` for relevant sections
- If `architectureSharded: false`: Search within monolithic `architectureFile` for relevant sections
#### 4.2 Recommended Reading Order Based on Story Type (v4 Sharded Only)
@@ -2770,7 +3174,7 @@ Format references as: `[Source: architecture/{filename}.md#{section}]`
### 6. Populate Story Template with Full Context
- Create a new story file: `{dev-story-location}/{epicNum}.{storyNum}.story.md` (using location from config).
- Create a new story file: `{devStoryLocation}/{epicNum}.{storyNum}.story.md` (using location from config).
- Use the Story Template to structure the file.
- Fill in:
- Story `{EpicNum}.{StoryNum}: {Short Title Copied from Epic File}`
@@ -2817,7 +3221,7 @@ Format references as: `[Source: architecture/{filename}.md#{section}]`
- Verify all source references are included for technical details
- Ensure tasks align with both epic requirements and architecture constraints
- Update status to "Draft"
- Save the story file to `{dev-story-location}/{epicNum}.{storyNum}.story.md` (using location from config)
- Save the story file to `{devStoryLocation}/{epicNum}.{storyNum}.story.md` (using location from config)
### 9. Report Completion
@@ -3096,6 +3500,144 @@ Be honest - it's better to flag issues now than have them discovered later.]]
- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.
==================== END: checklists#story-dod-checklist ====================
==================== START: tasks#review-story ====================
# review-story
When a developer marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
[[LLM: QA Agent executing review-story task as Senior Developer]]
## Prerequisites
- Story status must be "Review"
- Developer has completed all tasks and updated the File List
- All automated tests are passing
## Review Process
1. **Read the Complete Story**
- Review all acceptance criteria
- Understand the dev notes and requirements
- Note any completion notes from the developer
2. **Focus on the File List**
- Verify all files listed were actually created/modified
- Check for any missing files that should have been updated
3. **Senior Developer Code Review**
- Review code with the eye of a senior developer
- If changes form a cohesive whole, review them together
- If changes are independent, review incrementally file by file
- Focus on:
- Code architecture and design patterns
- Refactoring opportunities
- Code duplication or inefficiencies
- Performance optimizations
- Security concerns
- Best practices and patterns
4. **Active Refactoring**
- As a senior developer, you CAN and SHOULD refactor code where improvements are needed
- When refactoring:
- Make the changes directly in the files
- Explain WHY you're making the change
- Describe HOW the change improves the code
- Ensure all tests still pass after refactoring
- Update the File List if you modify additional files
5. **Standards Compliance Check**
- Verify adherence to `docs/coding-standards.md`
- Check compliance with `docs/unified-project-structure.md`
- Validate testing approach against `docs/testing-strategy.md`
- Ensure all guidelines mentioned in the story are followed
6. **Acceptance Criteria Validation**
- Verify each AC is fully implemented
- Check for any missing functionality
- Validate edge cases are handled
7. **Test Coverage Review**
- Ensure unit tests cover edge cases
- Add missing tests if critical coverage is lacking
- Verify integration tests (if required) are comprehensive
- Check that test assertions are meaningful
- Look for missing test scenarios
8. **Documentation and Comments**
- Verify code is self-documenting where possible
- Add comments for complex logic if missing
- Ensure any API changes are documented
## Append Results to Story File
After review and any refactoring, append your results to the story file in the QA Results section:
```markdown
## QA Results
### Review Date: [Date]
### Reviewed By: Quinn (Senior Developer QA)
### Code Quality Assessment
[Overall assessment of implementation quality]
### Refactoring Performed
[List any refactoring you performed with explanations]
- **File**: [filename]
- **Change**: [what was changed]
- **Why**: [reason for change]
- **How**: [how it improves the code]
### Compliance Check
- Coding Standards: [✓/✗] [notes if any]
- Project Structure: [✓/✗] [notes if any]
- Testing Strategy: [✓/✗] [notes if any]
- All ACs Met: [✓/✗] [notes if any]
### Improvements Checklist
[Check off items you handled yourself, leave unchecked for dev to address]
- [x] Refactored user service for better error handling (services/user.service.ts)
- [x] Added missing edge case tests (services/user.service.test.ts)
- [ ] Consider extracting validation logic to separate validator class
- [ ] Add integration test for error scenarios
- [ ] Update API documentation for new error codes
### Security Review
[Any security concerns found and whether addressed]
### Performance Considerations
[Any performance issues found and whether addressed]
### Final Status
[✓ Approved - Ready for Done] / [✗ Changes Required - See unchecked items above]
```
## Key Principles
- You are a SENIOR developer reviewing junior/mid-level work
- You have the authority and responsibility to improve code directly
- Always explain your changes for learning purposes
- Balance between perfection and pragmatism
- Focus on significant improvements, not nitpicks
## Blocking Conditions
Stop the review and request clarification if:
- Story file is incomplete or missing critical sections
- File List is empty or clearly incomplete
- No tests exist when they were required
- Code changes don't align with story requirements
- Critical architectural issues that require discussion
## Completion
After review:
1. If all items are checked and approved: Update story status to "Done"
2. If unchecked items remain: Keep status as "Review" for dev to address
3. Always provide constructive feedback and explanations for learning
==================== END: tasks#review-story ====================
==================== START: data#technical-preferences ====================
# User-Defined Preferred Patterns and Preferences

View File

@@ -152,6 +152,11 @@ loading:
- Agents: Only when transforming
- Templates/Tasks: Only when executing
- Always indicate loading
kb-mode-behavior:
- When *kb-mode is invoked, use kb-mode-interaction task
- Don't dump all KB content immediately
- Present topic areas and wait for user selection
- Provide focused, contextual responses
workflow-guidance:
- Discover available workflows in the bundle at runtime
- Understand each workflow's purpose, options, and decision points
@@ -165,6 +170,7 @@ dependencies:
tasks:
- advanced-elicitation
- create-doc
- kb-mode-interaction
data:
- bmad-kb
utils:
@@ -595,6 +601,79 @@ If template specifies a checklist:
- Template markup is for AI processing only - never expose to users
==================== END: tasks#create-doc ====================
==================== START: tasks#kb-mode-interaction ====================
# KB Mode Interaction Task
## Purpose
Provide a user-friendly interface to the BMAD knowledge base without overwhelming users with information upfront.
## Instructions
When entering KB mode (*kb-mode), follow these steps:
### 1. Welcome and Guide
Announce entering KB mode with a brief, friendly introduction:
"I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD."
### 2. Present Topic Areas
Offer a concise list of main topic areas the user might want to explore:
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
### 3. Respond Contextually
- Wait for user's specific question or topic selection
- Provide focused, relevant information from the knowledge base
- Offer to dive deeper or explore related topics
- Keep responses concise unless user asks for detailed explanations
### 4. Interactive Exploration
- After answering, suggest related topics they might find helpful
- Maintain conversational flow rather than data dumping
- Use examples when appropriate
- Reference specific documentation sections when relevant
### 5. Exit Gracefully
When user is done or wants to exit KB mode:
- Summarize key points discussed if helpful
- Remind them they can return to KB mode anytime with *kb-mode
- Suggest next steps based on what was discussed
## Example Interaction
**User**: *kb-mode
**Assistant**: I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD.
**What would you like to know more about?**
1. **Setup & Installation** - Getting started with BMAD
2. **Workflows** - Choosing the right workflow for your project
3. **Web vs IDE** - When to use each environment
4. **Agents** - Understanding specialized agents and their roles
5. **Documents** - PRDs, Architecture, Stories, and more
6. **Agile Process** - How BMAD implements Agile methodologies
7. **Configuration** - Customizing BMAD for your needs
8. **Best Practices** - Tips for effective BMAD usage
Or ask me about anything else related to BMAD-METHOD!
**User**: Tell me about workflows
**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]
==================== END: tasks#kb-mode-interaction ====================
==================== START: data#bmad-kb ====================
# BMAD Knowledge Base
@@ -618,6 +697,50 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
- **Quality Assurance**: Structured testing and validation
- **Documentation**: Professional PRDs, architecture docs, user stories
## How BMAD Works
### The Core Method
BMAD transforms you into a "Vibe CEO" - directing a team of specialized AI agents through structured workflows. Here's how:
1. **You Direct, AI Executes**: You provide vision and decisions; agents handle implementation details
2. **Specialized Agents**: Each agent masters one role (PM, Developer, Architect, etc.)
3. **Structured Workflows**: Proven patterns guide you from idea to deployed code
4. **Clean Handoffs**: Fresh context windows ensure agents stay focused and effective
### The Two-Phase Approach
**Phase 1: Planning (Web UI - Cost Effective)**
- Use large context windows (Gemini's 1M tokens)
- Generate comprehensive documents (PRD, Architecture)
- Leverage multiple agents for brainstorming
- Create once, use throughout development
**Phase 2: Development (IDE - Implementation)**
- Shard documents into manageable pieces
- Execute focused SM → Dev cycles
- One story at a time, sequential progress
- Real-time file operations and testing
### The Development Loop
```text
1. SM Agent (New Chat) → Creates next story from sharded docs
2. You → Review and approve story
3. Dev Agent (New Chat) → Implements approved story
4. QA Agent (New Chat) → Reviews and refactors code
5. You → Verify completion
6. Repeat until epic complete
```
### Why This Works
- **Context Optimization**: Clean chats = better AI performance
- **Role Clarity**: Agents don't context-switch = higher quality
- **Incremental Progress**: Small stories = manageable complexity
- **Human Oversight**: You validate each step = quality control
- **Document-Driven**: Specs guide everything = consistency
## Getting Started
### Quick Start Options
@@ -632,7 +755,7 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
5. Type `/help` to see available commands
#### Option 2: IDE Integration
**Best for**: Cursor, Claude Code, Windsurf, VS Code users
**Best for**: Cursor, Claude Code, Windsurf, Cline, Roo Code users
```bash
# Interactive installation (recommended)
@@ -641,13 +764,22 @@ npx bmad-method install
**Installation Steps**:
- Choose "Complete installation"
- Select your IDE (Cursor, Claude Code, Windsurf, or Roo Code)
- Select your IDE from supported options:
- **Cursor**: Native AI integration
- **Claude Code**: Anthropic's official IDE
- **Windsurf**: Built-in AI capabilities
- **Cline**: VS Code extension with AI features
- **Roo Code**: Web-based IDE with agent support
**Note for VS Code Users**: BMAD-METHOD assumes when you mention "VS Code" that you're using it with an AI-powered extension like GitHub Copilot, Cline, or Roo. Standard VS Code without AI capabilities cannot run BMAD agents. The installer includes built-in support for Cline and Roo.
**Verify Installation**:
- `.bmad-core/` folder created with all agents
- IDE-specific integration files created
- All agent commands/rules/modes available
**Remember**: At its core, BMAD-METHOD is about mastering and harnessing prompt engineering. Any IDE with AI agent support can use BMAD - the framework provides the structured prompts and workflows that make AI development effective
### Environment Selection Guide
**Use Web UI for**:
@@ -664,6 +796,105 @@ npx bmad-method install
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
### IDE-Only Workflow Considerations
**Can you do everything in IDE?** Yes, but understand the tradeoffs:
**Pros of IDE-Only**:
- Single environment workflow
- Direct file operations from start
- No copy/paste between environments
- Immediate project integration
**Cons of IDE-Only**:
- Higher token costs for large document creation
- Smaller context windows (varies by IDE/model)
- May hit limits during planning phases
- Less cost-effective for brainstorming
**Using Web Agents in IDE**:
- **NOT RECOMMENDED**: Web agents (PM, Architect) have rich dependencies designed for large contexts
- **Why it matters**: Dev agents are kept lean to maximize coding context
- **The principle**: "Dev agents code, planning agents plan" - mixing breaks this optimization
**About bmad-master and bmad-orchestrator**:
- **bmad-master**: CAN do any task without switching agents, BUT...
- **Still use specialized agents for planning**: PM, Architect, and UX Expert have tuned personas that produce better results
- **Why specialization matters**: Each agent's personality and focus creates higher quality outputs
- **If using bmad-master/orchestrator**: Fine for planning phases, but...
**CRITICAL RULE for Development**:
- **ALWAYS use SM agent for story creation** - Never use bmad-master/orchestrator
- **ALWAYS use Dev agent for implementation** - Never use bmad-master/orchestrator
- **Why this matters**: SM and Dev agents are specifically optimized for the development workflow
- **No exceptions**: Even if using bmad-master for everything else, switch to SM → Dev for implementation
**Best Practice for IDE-Only**:
1. Use PM/Architect/UX agents for planning (better than bmad-master)
2. Create documents directly in project
3. Shard immediately after creation
4. **MUST switch to SM agent** for story creation
5. **MUST switch to Dev agent** for implementation
6. Keep planning and coding in separate chat sessions
## Core Configuration (core-config.yml)
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
### What is core-config.yml?
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
- **Version Flexibility**: Work with V3, V4, or custom document structures
- **Custom Locations**: Define where your documents and shards live
- **Developer Context**: Specify which files the dev agent should always load
- **Debug Support**: Built-in logging for troubleshooting
### Key Configuration Areas
#### PRD Configuration
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
- **prdShardedLocation**: Where to find sharded epic files
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
#### Architecture Configuration
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
- **architectureSharded**: Whether architecture is split into components
- **architectureShardedLocation**: Where sharded architecture files live
#### Developer Files
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
- **devDebugLog**: Where dev agent logs repeated failures
- **agentCoreDump**: Export location for chat conversations
### Why It Matters
1. **No Forced Migrations**: Keep your existing document structure
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
3. **Custom Workflows**: Configure BMAD to match your team's process
4. **Intelligent Agents**: Agents automatically adapt to your configuration
### Common Configurations
**Legacy V3 Project**:
```yaml
prdVersion: v3
prdSharded: false
architectureVersion: v3
architectureSharded: false
```
**V4 Optimized Project**:
```yaml
prdVersion: v4
prdSharded: true
prdShardedLocation: docs/prd
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
```
## Core Philosophy
### Vibe CEO'ing
@@ -883,10 +1114,14 @@ that can handle [specific requirements]."
**Prerequisites**: Planning documents must exist in `docs/` folder
1. **Document Sharding**:
- `@bmad-master` or `@po` shard `docs/prd.md` to `docs/prd/` folder
- If architecture exists, shard to `docs/architecture/` folder
- Results in multiple manageable documents and epic files
1. **Document Sharding** (CRITICAL STEP):
- Documents created by PM/Architect (in Web or IDE) MUST be sharded for development
- Two methods to shard:
a) **Manual**: Drag `shard-doc` task + document file into chat
b) **Agent**: Ask `@bmad-master` or `@po` to shard documents
- Shards `docs/prd.md` → `docs/prd/` folder
- Shards `docs/architecture.md` → `docs/architecture/` folder
- **WARNING**: Do NOT shard in Web UI - copying many small files is painful!
2. **Verify Sharded Content**:
- At least one `epic-n.md` file in `docs/prd/` with stories in development order
@@ -900,19 +1135,34 @@ that can handle [specific requirements]."
3. **Development Cycle** (Sequential, one story at a time):
**Step 1 - Story Creation**: New chat window → `@sm` → `*create`
**CRITICAL CONTEXT MANAGEMENT**:
- **Context windows matter!** Always use fresh, clean context windows
- **Model selection matters!** Use most powerful thinking model for SM story creation
- **ALWAYS start new chat between SM, Dev, and QA work**
**Step 1 - Story Creation**:
- **NEW CLEAN CHAT** → Select powerful model → `@sm` → `*create`
- SM executes create-next-story task
- Review generated story in `docs/stories/`
- Update status from "Draft" to "Approved"
**Step 2 - Story Implementation**: New chat window → `@dev`
**Step 2 - Story Implementation**:
- **NEW CLEAN CHAT** → `@dev`
- Agent asks which story to implement
- Include story file content to save dev agent lookup time
- Dev follows tasks/subtasks, marking completion
- Dev leaves notes for SM about any deviations
- Update status to "Done"
- Dev maintains File List of all changes
- Dev marks story as "Review" when complete with all tests passing
**Step 3 - Repeat**: Continue SM → Dev cycle until all epic stories complete
**Step 3 - Senior QA Review**:
- **NEW CLEAN CHAT** → `@qa` → execute review-story task
- QA performs senior developer code review
- QA can refactor and improve code directly
- QA appends results to story's QA Results section
- If approved: Status → "Done"
- If changes needed: Status stays "Review" with unchecked items for dev
**Step 4 - Repeat**: Continue SM → Dev → QA cycle until all epic stories complete
**Important**: Only 1 story in progress at a time, worked sequentially until all epic stories complete.
@@ -932,12 +1182,27 @@ Each status change requires user verification and approval before proceeding.
- Development execution
- Testing and deployment
#### Brownfield Enhancement
- Current system analysis
- Enhancement planning
- Impact assessment
- Incremental development
- Integration testing
#### Brownfield Enhancement (Existing Projects)
**Key Concept**: Brownfield development requires generating good documentation for agents to understand your existing project.
**Recommended Approach**:
1. **Analysis Phase**: Use Gemini Web or AI Studio with their 1M+ context windows
2. **Document Generation**: Ask Architect agent to analyze your project and run `document-project` task
3. **PRD Creation**: Even brownfield projects typically need a PRD unless:
- Very small, focused changes
- Using `brownfield-create-epic` for single epic without full PRD
4. **Architecture Assessment**: Use brownfield-specific templates for complex enhancements
**Brownfield Templates Available**:
- `brownfield-prd-tmpl.md`: For substantial enhancements requiring multiple stories
- `brownfield-architecture-tmpl.md`: For complex changes impacting system architecture
- Both templates emphasize compatibility and integration with existing systems
**When to Skip PRD**:
- For focused, single-epic work, use `brownfield-create-epic` task with detailed guidance
- For one-off stories without larger context
- Note: These tasks will evolve to require some documentation (potentially from `document-project`)
## Document Creation Best Practices
@@ -1018,12 +1283,94 @@ Use the `shard-doc` task or `@kayvan/markdown-tree-parser` tool for automatic sh
- **Keep conversations focused** - One agent, one task per conversation
- **Review everything** - Always review and approve before marking complete
## Contributing to BMAD-METHOD
### Quick Contribution Guidelines
For full details, see `CONTRIBUTING.md`. Key points:
**Fork Workflow**:
1. Fork the repository
2. Create feature branches
3. Submit PRs to `next` branch (default) or `main` for critical fixes only
4. Keep PRs small: 200-400 lines ideal, 800 lines maximum
5. One feature/fix per PR
**PR Requirements**:
- Clear descriptions (max 200 words) with What/Why/How/Testing
- Use conventional commits (feat:, fix:, docs:)
- Atomic commits - one logical change per commit
- Must align with guiding principles
**Core Principles** (from GUIDING-PRINCIPLES.md):
- **Dev Agents Must Be Lean**: Minimize dependencies, save context for code
- **Natural Language First**: Everything in markdown, no code in core
- **Core vs Expansion Packs**: Core for universal needs, packs for specialized domains
- **Design Philosophy**: "Dev agents code, planning agents plan"
## Expansion Packs
### What Are Expansion Packs?
Expansion packs extend BMAD-METHOD beyond traditional software development into ANY domain. They provide specialized agent teams, templates, and workflows while keeping the core framework lean and focused on development.
### Why Use Expansion Packs?
1. **Keep Core Lean**: Dev agents maintain maximum context for coding
2. **Domain Expertise**: Deep, specialized knowledge without bloating core
3. **Community Innovation**: Anyone can create and share packs
4. **Modular Design**: Install only what you need
### Available Expansion Packs
**Technical Packs**:
- **Infrastructure/DevOps**: Cloud architects, SRE experts, security specialists
- **Game Development**: Game designers, level designers, narrative writers
- **Mobile Development**: iOS/Android specialists, mobile UX experts
- **Data Science**: ML engineers, data scientists, visualization experts
**Non-Technical Packs**:
- **Business Strategy**: Consultants, financial analysts, marketing strategists
- **Creative Writing**: Plot architects, character developers, world builders
- **Health & Wellness**: Fitness trainers, nutritionists, habit engineers
- **Education**: Curriculum designers, assessment specialists
- **Legal Support**: Contract analysts, compliance checkers
**Specialty Packs**:
- **Expansion Creator**: Tools to build your own expansion packs
- **RPG Game Master**: Tabletop gaming assistance
- **Life Event Planning**: Wedding planners, event coordinators
- **Scientific Research**: Literature reviewers, methodology designers
### Using Expansion Packs
1. **Browse Available Packs**: Check `expansion-packs/` directory
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
3. **Install via CLI**:
```bash
npx bmad-method install
# Select "Install expansion pack" option
```
4. **Use in Your Workflow**: Installed packs integrate seamlessly with existing agents
### Creating Custom Expansion Packs
Use the **expansion-creator** pack to build your own:
1. **Define Domain**: What expertise are you capturing?
2. **Design Agents**: Create specialized roles with clear boundaries
3. **Build Resources**: Tasks, templates, checklists for your domain
4. **Test & Share**: Validate with real use cases, share with community
**Key Principle**: Expansion packs democratize expertise by making specialized knowledge accessible through AI agents.
## Getting Help
- **Commands**: Use `/help` in any environment to see available commands
- **Agent Switching**: Use `/switch agent-name` with orchestrator for role changes
- **Documentation**: Check `docs/` folder for project-specific context
- **Community**: Discord and GitHub resources available for support
- **Contributing**: See `CONTRIBUTING.md` for full guidelines
==================== END: data#bmad-kb ====================
==================== START: utils#workflow-management ====================
@@ -3117,9 +3464,27 @@ The LLM will:
- Create a folder structure to organize the sharded documents
- Maintain all content integrity including code blocks, diagrams, and markdown formatting
## Recommended Method: @kayvan/markdown-tree-parser
## Primary Method: Automatic with markdown-tree
[[LLM: First, suggest the user install and use the @kayvan/markdown-tree-parser tool if the md-tree command is unavailable so we can have the best performance and reliable document sharding. Let the user know this will save cost of having the LLM to the expensive sharding operation. Give instructions for MPV NPX and PNPM global installs.]]
[[LLM: First, check if markdownExploder is set to true in bmad-core/core-config.yml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
2. Or set markdownExploder to false in bmad-core/core-config.yml
**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
1. Set markdownExploder to true in bmad-core/core-config.yml
2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
I will now proceed with the manual sharding process."
Then proceed with the manual method below ONLY if markdownExploder is false.]]
### Installation and Usage
@@ -3152,19 +3517,19 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
---
## Manual Method (if @kayvan/markdown-tree-parser is not available)
## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
[[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
### Task Instructions
### 1. Identify Document and Target Location
1. Identify Document and Target Location
- Determine which document to shard (user-provided path)
- Create a new folder under `docs/` with the same name as the document (without extension)
- Example: `docs/prd.md` → create folder `docs/prd/`
### 2. Parse and Extract Sections
2. Parse and Extract Sections
[[LLM: When sharding the document:
@@ -3174,7 +3539,7 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
- Extract the section heading and ALL content until the next level 2 section
- Include all subsections, code blocks, diagrams, lists, tables, etc.
- Be extremely careful with:
- Fenced code blocks (```) - ensure you capture the full block including closing backticks
- Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
- Mermaid diagrams - preserve the complete diagram syntax
- Nested markdown elements
- Multi-line content that might contain ## inside code blocks
@@ -3193,7 +3558,7 @@ For each extracted section:
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##)
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:
```txt
@@ -7721,6 +8086,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update - remove this line to the SM]]
[[LLM: (Dev Agent) Anything the SM needs to know that deviated from the story that might impact drafting the next story.]]
### File List
[[LLM: (Dev Agent) List every new file created, or existing file modified in a bullet list.]]
### Change Log
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update- remove this line to the SM]]
@@ -7728,6 +8097,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
## QA Results
[[LLM: QA Agent Results]]
==================== END: templates#story-tmpl ====================
==================== START: checklists#po-master-checklist ====================
@@ -8228,7 +8601,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid
@@ -8291,7 +8699,7 @@ workflow:
sequence:
- step: service_analysis
agent: architect
agent: architect
action: analyze existing project and use task document-project
creates: multiple documents per the document-project template
notes: "Review existing service documentation, codebase, performance metrics, and identify integration dependencies."
@@ -8320,7 +8728,42 @@ workflow:
- workflow_end:
action: move_to_ide
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
notes: |
Planning phase complete! Now transition to IDE Development:
1. ENSURE DOCUMENTS ARE IN PROJECT:
- Copy final prd.md to project's docs/prd.md
- Copy final architecture.md to project's docs/architecture.md
- All documents must be in the project before proceeding
2. SHARD DOCUMENTS (in IDE):
- Option A: Use PO agent to shard: @po then ask to shard docs/prd.md
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
- This creates docs/prd/ and docs/architecture/ folders with sharded content
3. START DEVELOPMENT CYCLE:
a. SM Agent (New Chat): @sm → *create
- Creates next story from sharded docs
- Review and approve story (Draft → Approved)
b. Dev Agent (New Chat): @dev
- Implements approved story
- Updates File List with all changes
- Marks story as "Review" when complete
c. QA Agent (New Chat): @qa → review-story
- Senior dev review with refactoring ability
- Fixes small issues directly
- Leaves checklist for remaining items
- Updates story status (Review → Done or stays Review)
d. If QA left unchecked items:
- Dev Agent (New Chat): Address remaining items
- Return to QA for final approval
4. REPEAT: Continue cycle for all epic stories
Reference: data#bmad-kb:IDE Development Workflow
flow_diagram: |
```mermaid

View File

@@ -0,0 +1,121 @@
# Expansion Pack Ideas
The BMAD Method's natural language framework can be applied to any domain. Here are ideas to inspire your own expansion packs:
## Health & Wellness Pack
### Agents
- **Fitness Coach** - Creates personalized workout plans
- **Nutrition Advisor** - Designs meal plans and tracks nutrition
- **Meditation Guide** - Leads mindfulness sessions
- **Sleep Optimizer** - Improves sleep habits
### Tasks
- `create-workout-plan` - Generates weekly exercise routines
- `analyze-nutrition` - Reviews dietary habits
- `design-meditation` - Creates guided meditation scripts
### Templates
- `workout-plan-tmpl` - Structured exercise program
- `meal-plan-tmpl` - Weekly nutrition guide
- `wellness-journal-tmpl` - Progress tracking
## Creative Writing Pack
### Agents
- **Story Architect** - Plots narratives and story structures
- **Character Developer** - Creates deep, complex characters
- **World Builder** - Designs fictional universes
- **Dialog Master** - Crafts authentic conversations
### Tasks
- `develop-plot` - Creates story outlines
- `build-character` - Develops character profiles
- `create-world` - Designs settings and cultures
### Templates
- `story-outline-tmpl` - Three-act structure
- `character-sheet-tmpl` - Detailed character profile
- `world-bible-tmpl` - Universe documentation
## Business Strategy Pack
### Agents
- **Strategy Consultant** - Develops business strategies
- **Market Analyst** - Researches market opportunities
- **Financial Advisor** - Creates financial projections
- **Operations Expert** - Optimizes business processes
### Tasks
- `swot-analysis` - Conducts SWOT analysis
- `market-research` - Analyzes market conditions
- `financial-forecast` - Projects revenue/costs
### Templates
- `business-plan-tmpl` - Complete business plan
- `market-analysis-tmpl` - Market research report
- `pitch-deck-tmpl` - Investor presentation
## Education Pack
### Agents
- **Curriculum Designer** - Creates learning pathways
- **Lesson Planner** - Develops engaging lessons
- **Assessment Creator** - Designs fair evaluations
- **Learning Coach** - Provides personalized guidance
### Tasks
- `design-curriculum` - Creates course structure
- `plan-lesson` - Develops lesson content
- `create-assessment` - Builds tests/quizzes
### Templates
- `course-outline-tmpl` - Semester plan
- `lesson-plan-tmpl` - Daily lesson structure
- `rubric-tmpl` - Assessment criteria
## Personal Development Pack
### Agents
- **Life Coach** - Guides personal growth
- **Goal Strategist** - Helps achieve objectives
- **Habit Builder** - Creates lasting habits
- **Mindset Mentor** - Develops positive thinking
### Tasks
- `goal-setting` - Defines SMART goals
- `habit-tracking` - Monitors habit formation
- `reflection-exercise` - Facilitates self-reflection
### Templates
- `goal-plan-tmpl` - Goal achievement roadmap
- `habit-tracker-tmpl` - Daily habit log
- `journal-prompts-tmpl` - Reflection questions
## Creating Your Own
To create an expansion pack:
1. **Identify the domain** - What area of expertise?
2. **Define agent roles** - Who are the experts?
3. **Create tasks** - What procedures do they follow?
4. **Design templates** - What outputs do they produce?
5. **Test with users** - Does it provide value?
6. **Share with community** - Help others benefit!
Remember: The BMAD Method works anywhere natural language instructions can guide AI assistance!

265
docs/expansion-packs.md Normal file
View File

@@ -0,0 +1,265 @@
# The Power of BMAD Expansion Packs
## Overview
BMAD Method's expansion packs unlock the framework's true potential by extending its natural language AI orchestration to ANY domain. While the core framework focuses on software development, expansion packs transform BMAD into a universal AI agent system.
## Why Expansion Packs?
### Keep Core Lean
The core BMAD framework maintains its focus on software development, ensuring dev agents have maximum context for coding. Expansion packs handle everything else.
### Domain Expertise
Each expansion pack provides deep, specialized knowledge without bloating the core system. Install only what you need.
### Community Innovation
Anyone can create and share expansion packs, fostering a ecosystem of AI-powered solutions across all industries and interests.
## Technical Expansion Packs
### Game Development Pack
Transform your AI into a complete game development studio:
- **Game Designer**: Mechanics, balance, progression systems
- **Level Designer**: Map layouts, puzzle design, difficulty curves
- **Narrative Designer**: Story arcs, dialog trees, lore creation
- **Art Director**: Visual style guides, asset specifications
- **Sound Designer**: Audio direction, music themes, SFX planning
### Mobile Development Pack
Specialized agents for mobile app creation:
- **iOS Specialist**: Swift/SwiftUI patterns, Apple guidelines
- **Android Expert**: Kotlin best practices, Material Design
- **Mobile UX Designer**: Touch interfaces, gesture patterns
- **App Store Optimizer**: ASO strategies, listing optimization
- **Performance Tuner**: Battery optimization, network efficiency
### DevOps/Infrastructure Pack
Complete infrastructure automation team:
- **Cloud Architect**: AWS/Azure/GCP design patterns
- **Security Specialist**: Zero-trust implementation, compliance
- **SRE Expert**: Monitoring, alerting, incident response
- **Container Orchestrator**: Kubernetes, Docker optimization
- **Cost Optimizer**: Cloud spend analysis, resource right-sizing
### Data Science Pack
AI-powered data analysis team:
- **Data Scientist**: Statistical analysis, ML model selection
- **Data Engineer**: Pipeline design, ETL processes
- **ML Engineer**: Model deployment, A/B testing
- **Visualization Expert**: Dashboard design, insight communication
- **Ethics Advisor**: Bias detection, fairness assessment
## Non-Technical Expansion Packs
### Business Strategy Pack
Complete business advisory team:
- **Strategy Consultant**: Market positioning, competitive analysis
- **Financial Analyst**: Projections, unit economics, funding strategies
- **Operations Manager**: Process optimization, efficiency improvements
- **Marketing Strategist**: Go-to-market plans, growth hacking
- **HR Advisor**: Talent strategies, culture building
### Creative Writing Pack
Your personal writing team:
- **Plot Architect**: Three-act structure, story beats, pacing
- **Character Psychologist**: Deep motivations, authentic dialog
- **World Builder**: Consistent universes, cultural systems
- **Editor**: Style consistency, grammar, flow
- **Beta Reader**: Feedback simulation, plot hole detection
### Health & Wellness Pack
Personal wellness coaching system:
- **Fitness Trainer**: Progressive overload, form correction
- **Nutritionist**: Macro planning, supplement guidance
- **Sleep Coach**: Circadian optimization, sleep hygiene
- **Stress Manager**: Coping strategies, work-life balance
- **Habit Engineer**: Behavior change, accountability systems
### Education Pack
Complete learning design system:
- **Curriculum Architect**: Learning objectives, scope & sequence
- **Instructional Designer**: Engagement strategies, multimedia learning
- **Assessment Specialist**: Rubrics, formative/summative evaluation
- **Differentiation Expert**: Adaptive learning, special needs
- **EdTech Integrator**: Tool selection, digital pedagogy
### Mental Health Support Pack
Therapeutic support system:
- **CBT Guide**: Cognitive restructuring, thought challenging
- **Mindfulness Teacher**: Meditation scripts, awareness exercises
- **Journal Therapist**: Reflective prompts, emotional processing
- **Crisis Support**: Coping strategies, safety planning
- **Habit Tracker**: Mood monitoring, trigger identification
### Legal Assistant Pack
Legal document and research support:
- **Contract Analyst**: Term review, risk assessment
- **Legal Researcher**: Case law, precedent analysis
- **Document Drafter**: Template customization, clause libraries
- **Compliance Checker**: Regulatory alignment, audit prep
- **IP Advisor**: Patent strategies, trademark guidance
### Real Estate Pack
Property investment and management:
- **Market Analyst**: Comparable analysis, trend prediction
- **Investment Calculator**: ROI modeling, cash flow analysis
- **Property Manager**: Tenant screening, maintenance scheduling
- **Flip Strategist**: Renovation ROI, project planning
- **Agent Assistant**: Listing optimization, showing prep
## Unique & Innovative Packs
### Role-Playing Game Master Pack
AI-powered tabletop RPG assistance:
- **World Master**: Dynamic world generation, NPC creation
- **Combat Referee**: Initiative tracking, rule clarification
- **Story Weaver**: Plot hooks, side quests, consequences
- **Character Builder**: Backstory generation, stat optimization
- **Loot Master**: Treasure generation, magic item creation
### Life Event Planning Pack
Major life event coordination:
- **Wedding Planner**: Vendor coordination, timeline creation
- **Event Designer**: Theme development, decoration plans
- **Budget Manager**: Cost tracking, vendor negotiation
- **Guest Coordinator**: RSVP tracking, seating arrangements
- **Timeline Keeper**: Day-of scheduling, contingency planning
### Hobby Mastery Pack
Deep dive into specific hobbies:
- **Garden Designer**: Plant selection, seasonal planning
- **Brew Master**: Recipe formulation, process optimization
- **Maker Assistant**: 3D printing, woodworking, crafts
- **Collection Curator**: Organization, valuation, trading
- **Photography Coach**: Composition, lighting, post-processing
### Scientific Research Pack
Research acceleration tools:
- **Literature Reviewer**: Paper summarization, gap analysis
- **Hypothesis Generator**: Research question formulation
- **Methodology Designer**: Experiment planning, control design
- **Statistical Advisor**: Test selection, power analysis
- **Grant Writer**: Proposal structure, impact statements
## Creating Your Own Expansion Pack
### Step 1: Define Your Domain
What expertise are you capturing? What problems will it solve?
### Step 2: Design Your Agents
Each agent should have:
- Clear expertise area
- Specific personality traits
- Defined capabilities
- Knowledge boundaries
### Step 3: Create Tasks
Tasks should be:
- Step-by-step procedures
- Reusable across scenarios
- Clear and actionable
- Domain-specific
### Step 4: Build Templates
Templates need:
- Structured output format
- Embedded LLM instructions
- Placeholders for customization
- Professional formatting
### Step 5: Test & Iterate
- Use with real scenarios
- Gather user feedback
- Refine agent responses
- Improve task clarity
### Step 6: Package & Share
- Create clear documentation
- Include usage examples
- Add to expansion-packs directory
- Share with community
## The Future of Expansion Packs
### Marketplace Potential
Imagine a future where:
- Professional expansion packs are sold
- Certified packs for regulated industries
- Community ratings and reviews
- Automatic updates and improvements
### AI Agent Ecosystems
Expansion packs could enable:
- Cross-pack agent collaboration
- Industry-standard agent protocols
- Interoperable AI workflows
- Universal agent languages
### Democratizing Expertise
Every expansion pack:
- Makes expert knowledge accessible
- Reduces barriers to entry
- Enables solo entrepreneurs
- Empowers small teams
## Getting Started
1. **Browse existing packs**: Check `expansion-packs/` directory
2. **Install what you need**: Use the installer's expansion pack option
3. **Create your own**: Use the expansion-creator pack
4. **Share with others**: Submit PRs with new packs
5. **Build the future**: Help shape AI-assisted work
## Remember
The BMAD Method is more than a development framework - it's a platform for structuring human expertise into AI-accessible formats. Every expansion pack you create makes specialized knowledge more accessible to everyone.
**What expertise will you share with the world?**

View File

@@ -884,6 +884,248 @@ This file allows you to define your preferred technologies, patterns, and standa
When creating custom web bundles or uploading to AI platforms, include your `technical-preferences.md` content to ensure agents have your preferences from the start of any conversation.
### Core Configuration (core-config.yml)
The `bmad-core/core-config.yml` file is a critical V4 innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
#### Understanding core-config.yml
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It's what makes V4 agents intelligent enough to work with V3 projects, custom layouts, or any document organization you prefer.
#### Configuration Structure
```yaml
coreProjectLocation:
devStoryLocation: docs/stories # Where completed stories are saved
prd:
prdFile: docs/prd.md
prdVersion: v4 # v3 or v4
prdSharded: true # false if epics are embedded in PRD
prdShardedLocation: docs/prd # Where sharded epics live
epicFilePattern: epic-{n}*.md # Pattern for epic files
architecture:
architectureFile: docs/architecture.md
architectureVersion: v4 # v3 or v4
architectureSharded: true # false if monolithic
architectureShardedLocation: docs/architecture
customTechnicalDocuments: null # Additional docs for SM
devLoadAlwaysFiles: # Files dev agent always loads
- docs/architecture/coding-standards.md
- docs/architecture/tech-stack.md
- docs/architecture/project-structure.md
devDebugLog: .ai/debug-log.md # Dev agent debug tracking
agentCoreDump: .ai/core-dump{n}.md # Export chat contents
```
#### Key Configuration Options
##### PRD Configuration
The Scrum Master agent uses these settings to locate epics:
**V4 Sharded Structure:**
```yaml
prd:
prdFile: docs/prd.md
prdVersion: v4
prdSharded: true
prdShardedLocation: docs/prd
epicFilePattern: epic-{n}*.md
```
**V3 Embedded Epics:**
```yaml
prd:
prdFile: docs/prd.md
prdVersion: v3
prdSharded: false # Epics are inside PRD
```
**Custom Sharded Location:**
```yaml
prd:
prdFile: docs/product-requirements.md
prdVersion: v4
prdSharded: true
prdShardedLocation: docs # Epics in docs/ not docs/prd/
epicFilePattern: epic-*.md
```
##### Architecture Configuration
Similar flexibility for architecture documents:
**V4 Sharded Architecture:**
```yaml
architecture:
architectureFile: docs/architecture.md
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
```
**V3 Monolithic Architecture:**
```yaml
architecture:
architectureFile: docs/technical-architecture.md
architectureVersion: v3
architectureSharded: false # All in one file
```
##### Developer Context Files
Define which files the dev agent should always load:
```yaml
devLoadAlwaysFiles:
- docs/architecture/coding-standards.md
- docs/architecture/tech-stack.md
- docs/architecture/project-structure.md
- docs/api-contracts.yaml
- docs/database-schema.md
- .env.example
```
This ensures the dev agent always has critical context without needing to search for it.
##### Debug and Export Options
**Debug Log:**
```yaml
devDebugLog: .ai/debug-log.md
```
When the dev agent encounters repeated failures implementing a story, it logs issues here to avoid repeating the same mistakes.
**Core Dump:**
```yaml
agentCoreDump: .ai/core-dump{n}.md
```
Export entire chat conversations for preservation or analysis. The `{n}` is replaced with a number.
#### Common Configurations
##### Legacy V3 Project
```yaml
coreProjectLocation:
devStoryLocation: docs/stories
prd:
prdFile: docs/prd.md
prdVersion: v3
prdSharded: false
architecture:
architectureFile: docs/architecture.md
architectureVersion: v3
architectureSharded: false
devLoadAlwaysFiles: []
```
##### Hybrid Project (V3 PRD, V4 Architecture)
```yaml
coreProjectLocation:
devStoryLocation: .ai/stories
prd:
prdFile: docs/product-requirements.md
prdVersion: v3
prdSharded: false
architecture:
architectureFile: docs/architecture.md
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: docs/architecture
devLoadAlwaysFiles:
- docs/architecture/tech-stack.md
```
##### Custom Organization
```yaml
coreProjectLocation:
devStoryLocation: development/completed-stories
prd:
prdFile: planning/requirements.md
prdVersion: v4
prdSharded: true
prdShardedLocation: planning/epics
epicFilePattern: requirement-{n}.md
architecture:
architectureFile: technical/system-design.md
architectureVersion: v4
architectureSharded: true
architectureShardedLocation: technical/components
customTechnicalDocuments:
- technical/api-guide.md
- technical/deployment.md
devLoadAlwaysFiles:
- technical/coding-guidelines.md
- technical/git-workflow.md
```
#### Migration Strategies
##### Gradual V3 to V4 Migration
Start with V3 documents and gradually adopt V4 patterns:
1. **Initial State**: Set `prdVersion: v3` and `prdSharded: false`
2. **Shard PRD**: Use PO agent to shard, then update to `prdSharded: true`
3. **Update Version**: Change to `prdVersion: v4` after using V4 templates
4. **Repeat for Architecture**: Same process for architecture documents
##### Working with Mixed Teams
If some team members use V3 and others use V4:
```yaml
# Support both patterns
customTechnicalDocuments:
- docs/legacy-requirements.md # V3 format
- docs/prd.md # V4 format
```
#### Best Practices
1. **Always Configure for Your Structure**: Don't force your project to match BMAD defaults
2. **Keep devLoadAlwaysFiles Focused**: Only include files needed for every dev task
3. **Use Debug Log**: Enable when troubleshooting story implementation issues
4. **Version Control core-config.yml**: Track changes to understand project evolution
5. **Document Custom Patterns**: If using custom epicFilePattern, document it
#### Troubleshooting
**Scrum Master Can't Find Epics:**
- Check `prdSharded` matches your structure
- Verify `prdShardedLocation` path exists
- Confirm `epicFilePattern` matches your files
**Dev Agent Missing Context:**
- Add critical files to `devLoadAlwaysFiles`
- Ensure file paths are correct
- Check files exist and are readable
**Architecture Not Loading:**
- Verify `architectureFile` path
- Check `architectureVersion` setting
- Confirm sharding configuration matches reality
### Extension Packs
Add specialized capabilities:

View File

@@ -0,0 +1,362 @@
# Working in the Brownfield: A Complete Guide
> 🚀 **HIGHLY RECOMMENDED: Use Gemini Web for Brownfield Documentation!**
>
> Gemini Web's 1M+ token context window can analyze your ENTIRE codebase at once:
>
> - Upload via GitHub URL
> - Upload up to 1000 files
> - Upload zipped project
>
> This is MUCH more cost-effective than IDE analysis which reads files one by one!
## What is Brownfield Development?
Brownfield development refers to adding features, fixing bugs, or modernizing existing software projects. Unlike greenfield (new) projects, brownfield work requires understanding existing code, respecting constraints, and ensuring new changes integrate seamlessly without breaking existing functionality.
## When to Use BMAD for Brownfield
BMAD-METHOD excels at brownfield development when you need to:
- Add significant new features to existing applications
- Modernize legacy codebases
- Integrate new technologies or services
- Refactor complex systems
- Fix bugs that require architectural understanding
- Document undocumented systems
## The Complete Brownfield Workflow
### Choose Your Approach
#### Approach A: PRD-First (Recommended for Large Codebases/Monorepos)
**Best for**: Large codebases, monorepos, or when you know exactly what you want to build
1. **Create PRD First** to define requirements
2. **Document only relevant areas** based on PRD needs
3. **More efficient** - avoids documenting unused code
#### Approach B: Document-First (Good for Smaller Projects)
**Best for**: Smaller codebases, unknown systems, or exploratory changes
1. **Document entire system** first
2. **Create PRD** with full context
3. **More thorough** - captures everything
### Approach A: PRD-First Workflow (Recommended)
#### Phase 1: Define Requirements First
**In Gemini Web (with your codebase uploaded):**
```bash
@pm
*create-doc brownfield-prd
```
The PM will:
- **Ask about your enhancement** requirements
- **Explore the codebase** to understand current state
- **Identify affected areas** that need documentation
- **Create focused PRD** with clear scope
**Key Advantage**: The PRD identifies which parts of your monorepo/large codebase actually need documentation!
#### Phase 2: Focused Documentation
**Still in Gemini Web, now with PRD context:**
```bash
@analyst
*document-project
```
The analyst will:
- **Ask about your focus** if no PRD was provided
- **Offer options**: Create PRD, provide requirements, or describe the enhancement
- **Reference the PRD/description** to understand scope
- **Focus on relevant modules** identified in PRD or your description
- **Skip unrelated areas** to keep docs lean
- **Generate ONE architecture document** for all environments
The analyst creates:
- **One comprehensive architecture document** following fullstack-architecture template
- **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
For example, if you say "Add payment processing to user service":
- Documents only: user service, API endpoints, database schemas, payment integrations
- Creates focused source tree showing only payment-related code paths
- Skips: admin panels, reporting modules, unrelated microservices
### Approach B: Document-First Workflow
#### Phase 1: Document the Existing System
**Best Approach - Gemini Web with 1M+ Context**:
1. **Go to Gemini Web** (gemini.google.com)
2. **Upload your project**:
- **Option A**: Paste your GitHub repository URL directly
- **Option B**: Upload up to 1000 files from your src/project folder
- **Option C**: Zip your project and upload the archive
3. **Load the analyst agent**: Upload `dist/agents/analyst.txt`
4. **Run documentation**: Type `*document-project`
The analyst will generate comprehensive documentation of everything.
#### Phase 2: Plan Your Enhancement
#### Option A: Full Brownfield Workflow (Recommended for Major Changes)
**1. Create Brownfield PRD**
```bash
@pm
*create-doc brownfield-prd
```
The PM agent will:
- **Analyze existing documentation** from Phase 1
- **Request specific enhancement details** from you
- **Assess complexity** and recommend approach
- **Create epic/story structure** for the enhancement
- **Identify risks and integration points**
**How PM Agent Gets Project Context**:
- In Gemini Web: Already has full project context from Phase 1 documentation
- In IDE: Will ask "Please provide the path to your existing project documentation"
**Key Prompts You'll Encounter**:
- "What specific enhancement or feature do you want to add?"
- "Are there any existing systems or APIs this needs to integrate with?"
- "What are the critical constraints we must respect?"
- "What is your timeline and team size?"
**2. Create Brownfield Architecture**
```bash
@architect
*create-doc brownfield-architecture
```
The architect will:
- **Review the brownfield PRD**
- **Design integration strategy**
- **Plan migration approach** if needed
- **Identify technical risks**
- **Define compatibility requirements**
#### Option B: Quick Enhancement (For Focused Changes)
**For Single Epic Without Full PRD**:
```bash
@pm
*brownfield-create-epic
```
Use when:
- Enhancement is well-defined and isolated
- Existing documentation is comprehensive
- Changes don't impact multiple systems
- You need quick turnaround
**For Single Story**:
```bash
@pm
*brownfield-create-story
```
Use when:
- Bug fix or tiny feature
- Very isolated change
- No architectural impact
- Clear implementation path
### Phase 3: Validate Planning Artifacts
```bash
@po
*execute-checklist po-master-checklist
```
The PO ensures:
- Compatibility with existing system
- No breaking changes planned
- Risk mitigation strategies in place
- Clear integration approach
### Phase 4: Transition to Development
Follow the enhanced IDE Development Workflow:
1. **Ensure documents are in project**:
- Copy `docs/prd.md` (or brownfield-prd.md)
- Copy `docs/architecture.md` (or brownfield-architecture.md)
2. **Shard documents**:
```bash
@po
# Ask to shard docs/prd.md
```
3. **Development cycle**:
- **SM** creates stories with integration awareness
- **Dev** implements with existing code respect
- **QA** reviews for compatibility and improvements
## Brownfield Best Practices
### 1. Always Document First
Even if you think you know the codebase:
- Run `document-project` to capture current state
- AI agents need this context
- Discovers undocumented patterns
### 2. Respect Existing Patterns
The brownfield templates specifically look for:
- Current coding conventions
- Existing architectural patterns
- Technology constraints
- Team preferences
### 3. Plan for Gradual Rollout
Brownfield changes should:
- Support feature flags
- Plan rollback strategies
- Include migration scripts
- Maintain backwards compatibility
### 4. Test Integration Thoroughly
Focus testing on:
- Integration points
- Existing functionality (regression)
- Performance impact
- Data migrations
### 5. Communicate Changes
Document:
- What changed and why
- Migration instructions
- New patterns introduced
- Deprecation notices
## Common Brownfield Scenarios
### Scenario 1: Adding a New Feature
1. Document existing system
2. Create brownfield PRD focusing on integration
3. Architecture emphasizes compatibility
4. Stories include integration tasks
### Scenario 2: Modernizing Legacy Code
1. Extensive documentation phase
2. PRD includes migration strategy
3. Architecture plans gradual transition
4. Stories follow strangler fig pattern
### Scenario 3: Bug Fix in Complex System
1. Document relevant subsystems
2. Use `brownfield-create-story` for focused fix
3. Include regression test requirements
4. QA validates no side effects
### Scenario 4: API Integration
1. Document existing API patterns
2. PRD defines integration requirements
3. Architecture ensures consistent patterns
4. Stories include API documentation updates
## Troubleshooting
### "The AI doesn't understand my codebase"
**Solution**: Re-run `document-project` with more specific paths to critical files
### "Generated plans don't fit our patterns"
**Solution**: Update generated documentation with your specific conventions before planning phase
### "Too much boilerplate for small changes"
**Solution**: Use `brownfield-create-story` instead of full workflow
### "Integration points unclear"
**Solution**: Provide more context during PRD creation, specifically highlighting integration systems
## Quick Reference
### Brownfield-Specific Commands
```bash
# Document existing project
@analyst → *document-project
# Create enhancement PRD
@pm → *create-doc brownfield-prd
# Create architecture with integration focus
@architect → *create-doc brownfield-architecture
# Quick epic creation
@pm → *brownfield-create-epic
# Single story creation
@pm → *brownfield-create-story
```
### Decision Tree
```text
Do you have a large codebase or monorepo?
├─ Yes → PRD-First Approach
│ └─ Create PRD → Document only affected areas
└─ No → Is the codebase well-known to you?
├─ Yes → PRD-First Approach
└─ No → Document-First Approach
Is this a major enhancement affecting multiple systems?
├─ Yes → Full Brownfield Workflow
└─ No → Is this more than a simple bug fix?
├─ Yes → brownfield-create-epic
└─ No → brownfield-create-story
```
## Conclusion
Brownfield development with BMAD-METHOD provides structure and safety when modifying existing systems. The key is providing comprehensive context through documentation, using specialized templates that consider integration requirements, and following workflows that respect existing constraints while enabling progress.
Remember: **Document First, Plan Carefully, Integrate Safely**

View File

@@ -4,7 +4,7 @@ This task guides you through creating a new BMAD agent following the standard te
## Prerequisites
- Agent template: `.bmad-core/templates/agent-tmpl.md`
- Agent template: `../templates/agent-tmpl.md`
- Target directory: `.bmad-core/agents/`
## Steps

View File

@@ -18,7 +18,7 @@ Every expansion pack MUST include a custom BMAD orchestrator agent with sophisti
1. **Create Planning Document First**: Before any implementation, create a comprehensive plan for user approval
2. **Agent Architecture Standards**: Use YAML-in-Markdown structure with activation instructions, personas, and command systems
3. **Character Consistency**: Every agent must have a persistent persona with name, communication style, and numbered options protocol
3. **Character Consistency**: Every agent must have a persistent persona with name, communication style, and numbered options protocol similar to `expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.md`
4. **Custom Themed Orchestrator**: The orchestrator should embody the domain theme (e.g., Office Manager for medical, Project Lead for tech) for better user experience
5. **Core Utilities Required**: ALWAYS include these core files in every expansion pack:
- `tasks/create-doc.md` - Document creation from templates
@@ -26,8 +26,8 @@ Every expansion pack MUST include a custom BMAD orchestrator agent with sophisti
- `utils/template-format.md` - Template markup conventions
- `utils/workflow-management.md` - Workflow orchestration
6. **Team and Workflow Requirements**: If pack has >1 agent, MUST include:
- At least one team configuration in `agent-teams/`
- At least one workflow in `workflows/`
- At least one team configuration in `expansion-packs/{new-expansion}/agent-teams/`
- At least one workflow in `expansion-packs/{new-expansion}workflows/`
7. **Template Sophistication**: Implement LLM instruction embedding with `[[LLM: guidance]]`, conditional content, and variable systems
8. **Workflow Orchestration**: Include decision trees, handoff protocols, and validation loops
9. **Quality Assurance Integration**: Multi-level checklists with star ratings and ready/not-ready frameworks
@@ -1018,11 +1018,3 @@ Embedded knowledge (automatic):
- [ ] Template conditional content tested with different scenarios
- [ ] Workflow decision trees validated with sample use cases
- [ ] Character interactions tested for consistency and professional authenticity
```
```
```
```

4
package-lock.json generated
View File

@@ -1,12 +1,12 @@
{
"name": "bmad-method",
"version": "4.9.2",
"version": "4.14.0",
"lockfileVersion": 3,
"requires": true,
"packages": {
"": {
"name": "bmad-method",
"version": "4.9.2",
"version": "4.14.0",
"license": "MIT",
"dependencies": {
"@kayvan/markdown-tree-parser": "^1.5.0",

View File

@@ -1,6 +1,6 @@
{
"name": "bmad-method",
"version": "4.9.2",
"version": "4.14.0",
"description": "Breakthrough Method of Agile AI-driven Development",
"main": "tools/cli.js",
"bin": {

View File

@@ -50,7 +50,7 @@ program
.option('-t, --team <team>', 'Install specific team with required agents and dependencies')
.option('-x, --expansion-only', 'Install only expansion packs (no bmad-core)')
.option('-d, --directory <path>', 'Installation directory (default: .bmad-core)')
.option('-i, --ide <ide...>', 'Configure for specific IDE(s) - can specify multiple (cursor, claude-code, windsurf, roo, other)')
.option('-i, --ide <ide...>', 'Configure for specific IDE(s) - can specify multiple (cursor, claude-code, windsurf, roo, cline, other)')
.option('-e, --expansion-packs <packs...>', 'Install specific expansion packs (can specify multiple)')
.action(async (options) => {
try {
@@ -67,7 +67,7 @@ program
if (options.agent) installType = 'single-agent';
else if (options.team) installType = 'team';
else if (options.expansionOnly) installType = 'expansion-only';
const config = {
installType,
agent: options.agent,
@@ -164,13 +164,13 @@ async function promptInstallation() {
// Check if this is an existing v4 installation
const installDir = path.resolve(answers.directory);
const state = await installer.detectInstallationState(installDir);
if (state.type === 'v4_existing') {
console.log(chalk.yellow('\n🔍 Found existing BMAD v4 installation'));
console.log(` Directory: ${installDir}`);
console.log(` Version: ${state.manifest?.version || 'Unknown'}`);
console.log(` Installed: ${state.manifest?.installed_at ? new Date(state.manifest.installed_at).toLocaleDateString() : 'Unknown'}`);
const { shouldUpdate } = await inquirer.prompt([
{
type: 'confirm',
@@ -179,7 +179,7 @@ async function promptInstallation() {
default: true
}
]);
if (shouldUpdate) {
// Skip other prompts and go directly to update
answers.installType = 'update';
@@ -256,11 +256,11 @@ async function promptInstallation() {
if (installType === 'full' || installType === 'team' || installType === 'expansion-only') {
try {
const availableExpansionPacks = await installer.getAvailableExpansionPacks();
if (availableExpansionPacks.length > 0) {
let choices;
let message;
if (installType === 'expansion-only') {
message = 'Select expansion packs to install (required):'
choices = availableExpansionPacks.map(pack => ({
@@ -274,7 +274,7 @@ async function promptInstallation() {
value: pack.id
}));
}
const { expansionPacks } = await inquirer.prompt([
{
type: 'checkbox',
@@ -289,7 +289,7 @@ async function promptInstallation() {
} : undefined
}
]);
// Use selected expansion packs directly
answers.expansionPacks = expansionPacks;
} else {
@@ -313,11 +313,12 @@ async function promptInstallation() {
{ name: 'Cursor', value: 'cursor' },
{ name: 'Claude Code', value: 'claude-code' },
{ name: 'Windsurf', value: 'windsurf' },
{ name: 'Roo Code', value: 'roo' }
{ name: 'Roo Code', value: 'roo' },
{ name: 'Cline', value: 'cline' }
]
}
]);
// Use selected IDEs directly
answers.ides = ides;

View File

@@ -92,10 +92,15 @@ ide-configurations:
# 3. The AI will adopt that agent's full personality and capabilities
cline:
name: Cline
format: unknown
rule-dir: .clinerules/
format: multi-file
command-suffix: .md
instructions: |
# Cline configuration coming soon
# Manual setup: Copy IDE agent files to your Cline configuration
# To use BMAD agents in Cline:
# 1. Open the Cline chat panel in VS Code
# 2. Type @agent-name (e.g., "@dev", "@pm", "@architect")
# 3. The agent will adopt that persona for the conversation
# 4. Rules are stored in .clinerules/ directory in your project
available-agents:
- id: analyst
name: Business Analyst

View File

@@ -31,6 +31,8 @@ class IdeSetup {
return this.setupWindsurf(installDir, selectedAgent);
case "roo":
return this.setupRoo(installDir, selectedAgent);
case "cline":
return this.setupCline(installDir, selectedAgent);
default:
console.log(chalk.yellow(`\nIDE ${ide} not yet supported`));
return false;
@@ -340,6 +342,75 @@ class IdeSetup {
return true;
}
async setupCline(installDir, selectedAgent) {
const clineRulesDir = path.join(installDir, ".clinerules");
const agents = selectedAgent ? [selectedAgent] : await this.getAllAgentIds(installDir);
await fileManager.ensureDirectory(clineRulesDir);
// Define agent order for numeric prefixes
const agentOrder = {
'bmad-master': 1,
'bmad-orchestrator': 2,
'pm': 3,
'analyst': 4,
'architect': 5,
'po': 6,
'sm': 7,
'dev': 8,
'qa': 9,
'ux-expert': 10
};
for (const agentId of agents) {
// Check if .bmad-core is a subdirectory (full install) or if agents are in root (single agent install)
let agentPath = path.join(installDir, ".bmad-core", "agents", `${agentId}.md`);
if (!(await fileManager.pathExists(agentPath))) {
agentPath = path.join(installDir, "agents", `${agentId}.md`);
}
if (await fileManager.pathExists(agentPath)) {
const agentContent = await fileManager.readFile(agentPath);
// Get numeric prefix for ordering
const order = agentOrder[agentId] || 99;
const prefix = order.toString().padStart(2, '0');
const mdPath = path.join(clineRulesDir, `${prefix}-${agentId}.md`);
// Create MD content for Cline (focused on project standards and role)
let mdContent = `# ${this.getAgentTitle(agentId)} Agent\n\n`;
mdContent += `This rule defines the ${this.getAgentTitle(agentId)} persona and project standards.\n\n`;
mdContent += "## Role Definition\n\n";
mdContent +=
"When the user types `@" + agentId + "`, adopt this persona and follow these guidelines:\n\n";
mdContent += "```yml\n";
// Extract just the YAML content from the agent file
const yamlMatch = agentContent.match(/```ya?ml\n([\s\S]*?)```/);
if (yamlMatch) {
mdContent += yamlMatch[1].trim();
} else {
// If no YAML found, include the whole content minus the header
mdContent += agentContent.replace(/^#.*$/m, "").trim();
}
mdContent += "\n```\n\n";
mdContent += "## Project Standards\n\n";
mdContent += `- Always maintain consistency with project documentation in .bmad-core/\n`;
mdContent += `- Follow the agent's specific guidelines and constraints\n`;
mdContent += `- Update relevant project files when making changes\n`;
mdContent += `- Reference the complete agent definition in [.bmad-core/agents/${agentId}.md](.bmad-core/agents/${agentId}.md)\n\n`;
mdContent += "## Usage\n\n";
mdContent += `Type \`@${agentId}\` to activate this ${this.getAgentTitle(agentId)} persona.\n`;
await fileManager.writeFile(mdPath, mdContent);
console.log(chalk.green(`✓ Created rule: ${prefix}-${agentId}.md`));
}
}
console.log(chalk.green(`\n✓ Created Cline rules in ${clineRulesDir}`));
return true;
}
}
module.exports = new IdeSetup();

View File

@@ -350,7 +350,12 @@ class Installer {
// Install web bundles if requested
if (config.includeWebBundles && config.webBundlesDirectory) {
spinner.text = "Installing web bundles...";
await this.installWebBundles(config.webBundlesDirectory, config, spinner);
// Resolve web bundles directory using the same logic as the main installation directory
const originalCwd = process.env.INIT_CWD || process.env.PWD || process.cwd();
let resolvedWebBundlesDir = path.isAbsolute(config.webBundlesDirectory)
? config.webBundlesDirectory
: path.resolve(originalCwd, config.webBundlesDirectory);
await this.installWebBundles(resolvedWebBundlesDir, config, spinner);
}
// Set up IDE integration if requested
@@ -608,7 +613,12 @@ class Installer {
if (config.includeWebBundles && config.webBundlesDirectory) {
const bundleInfo = this.getWebBundleInfo(config);
console.log(chalk.green(`✓ Web bundles (${bundleInfo}) installed to: ${config.webBundlesDirectory}`));
// Resolve the web bundles directory for display
const originalCwd = process.env.INIT_CWD || process.env.PWD || process.cwd();
const resolvedWebBundlesDir = path.isAbsolute(config.webBundlesDirectory)
? config.webBundlesDirectory
: path.resolve(originalCwd, config.webBundlesDirectory);
console.log(chalk.green(`✓ Web bundles (${bundleInfo}) installed to: ${resolvedWebBundlesDir}`));
}
if (ides.length > 0) {

View File

@@ -1,6 +1,6 @@
{
"name": "bmad-method",
"version": "4.9.2",
"version": "4.14.0",
"description": "BMAD Method installer - AI-powered Agile development framework",
"main": "lib/installer.js",
"bin": {

View File

@@ -561,6 +561,7 @@ class V3ToV4Upgrader {
"claude-code": "Commands created in .claude/commands/",
windsurf: "Rules created in .windsurf/rules/",
roo: "Custom modes created in .roomodes",
cline: "Rules created in .clinerules/",
};
// Setup each selected IDE