Compare commits
33 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
0ec4ad26c2 | ||
|
|
c881dcc48f | ||
|
|
5aed8f7603 | ||
|
|
929461a2fe | ||
|
|
f5fa2559f0 | ||
|
|
ead2c04b5b | ||
|
|
b9970c9d73 | ||
|
|
8182a3f4bc | ||
|
|
2408068884 | ||
|
|
9cafbe7014 | ||
|
|
466bef4398 | ||
|
|
2ea806b3af | ||
|
|
60c147aa75 | ||
|
|
ba91cb17cf | ||
|
|
b82978fd38 | ||
|
|
50d17ed65d | ||
|
|
aa15b7a2ca | ||
|
|
c70f1a056b | ||
|
|
95e833beeb | ||
|
|
1ea367619a | ||
|
|
6cdecec61f | ||
|
|
a5915934fd | ||
|
|
b557570081 | ||
|
|
4bbb251730 | ||
|
|
3cb8c02747 | ||
|
|
b1c2de1fb5 | ||
|
|
263d9c7618 | ||
|
|
08f541195d | ||
|
|
ea945bb43f | ||
|
|
dd27531151 | ||
|
|
44b9d7bcb5 | ||
|
|
429a3d41e9 | ||
|
|
6dabbcb670 |
15
.github/FUNDING.yml
vendored
Normal file
15
.github/FUNDING.yml
vendored
Normal file
@@ -0,0 +1,15 @@
|
||||
# These are supported funding model platforms
|
||||
|
||||
github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
|
||||
patreon: # Replace with a single Patreon username
|
||||
open_collective: # Replace with a single Open Collective username
|
||||
ko_fi: # Replace with a single Ko-fi username
|
||||
tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
|
||||
community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
|
||||
liberapay: # Replace with a single Liberapay username
|
||||
issuehunt: # Replace with a single IssueHunt username
|
||||
lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
|
||||
polar: # Replace with a single Polar username
|
||||
buy_me_a_coffee: bmad
|
||||
thanks_dev: # Replace with a single thanks.dev username
|
||||
custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']
|
||||
32
.github/ISSUE_TEMPLATE/bug_report.md
vendored
Normal file
32
.github/ISSUE_TEMPLATE/bug_report.md
vendored
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: Bug report
|
||||
about: Create a report to help us improve
|
||||
title: ""
|
||||
labels: ""
|
||||
assignees: ""
|
||||
---
|
||||
|
||||
**Describe the bug**
|
||||
A clear and concise description of what the bug is.
|
||||
|
||||
**Steps to Reproduce**
|
||||
What lead to the bug and can it be reliable recreated - if so with what steps.
|
||||
|
||||
**PR**
|
||||
If you have an idea to fix and would like to contribute, please indicate here you are working on a fix, or link to a proposed PR to fix the issue. Please review the contribution.md - contributions are always welcome!
|
||||
|
||||
**Expected behavior**
|
||||
A clear and concise description of what you expected to happen.
|
||||
|
||||
**Please be Specific if relevant**
|
||||
Model(s) Used:
|
||||
Agentic IDE Used:
|
||||
WebSite Used:
|
||||
Project Language:
|
||||
BMad Method version:
|
||||
|
||||
**Screenshots or Links**
|
||||
If applicable, add screenshots or links (if web sharable record) to help explain your problem.
|
||||
|
||||
**Additional context**
|
||||
Add any other context about the problem here. The more information you can provide, the easier it will be to suggest a fix or resolve
|
||||
22
.github/ISSUE_TEMPLATE/feature_request.md
vendored
Normal file
22
.github/ISSUE_TEMPLATE/feature_request.md
vendored
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
name: Feature request
|
||||
about: Suggest an idea for this project
|
||||
title: ""
|
||||
labels: ""
|
||||
assignees: ""
|
||||
---
|
||||
|
||||
**Did you discuss the idea first in Discord Server (#general-dev)**
|
||||
Yes/No - Link to thread. If no, please after posting request also share the link in the channel so it can be easily discussed.
|
||||
|
||||
**Is your feature request related to a problem? Please describe.**
|
||||
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
|
||||
|
||||
**Describe the solution you'd like**
|
||||
A clear and concise description of what you want to happen.
|
||||
|
||||
**Describe alternatives you've considered**
|
||||
A clear and concise description of any alternative solutions or features you've considered.
|
||||
|
||||
**Additional context**
|
||||
Add any other context or screenshots about the feature request here.
|
||||
6
.vscode/extensions.json
vendored
6
.vscode/extensions.json
vendored
@@ -1,6 +0,0 @@
|
||||
{
|
||||
"recommendations": [
|
||||
"davidanson.vscode-markdownlint",
|
||||
"streetsidesoftware.code-spell-checker"
|
||||
]
|
||||
}
|
||||
82
.vscode/settings.json
vendored
82
.vscode/settings.json
vendored
@@ -1,77 +1,7 @@
|
||||
{
|
||||
"cSpell.words": [
|
||||
"agentic",
|
||||
"Axios",
|
||||
"biomimicry",
|
||||
"BMAD",
|
||||
"Brainwriting",
|
||||
"Centricity",
|
||||
"cicd",
|
||||
"dataclass",
|
||||
"docstrings",
|
||||
"emergently",
|
||||
"explorative",
|
||||
"fintech",
|
||||
"firmographic",
|
||||
"firmographics",
|
||||
"frontends",
|
||||
"gamedev",
|
||||
"golint",
|
||||
"Goroutines",
|
||||
"hotspots",
|
||||
"HSTS",
|
||||
"httpx",
|
||||
"Immer",
|
||||
"implementability",
|
||||
"Inclusivity",
|
||||
"kayvan",
|
||||
"Luxon",
|
||||
"MERN",
|
||||
"mgmt",
|
||||
"nodir",
|
||||
"Nuxt",
|
||||
"overcommitting",
|
||||
"pasteable",
|
||||
"pentest",
|
||||
"PESTEL",
|
||||
"Pino",
|
||||
"Polyrepo",
|
||||
"psychographics",
|
||||
"Pydantic",
|
||||
"pyproject",
|
||||
"reqs",
|
||||
"rescope",
|
||||
"roadmaps",
|
||||
"roleplay",
|
||||
"roomodes",
|
||||
"runbooks",
|
||||
"Serilog",
|
||||
"shadcn",
|
||||
"structlog",
|
||||
"subfolders",
|
||||
"Supabase",
|
||||
"Systemization",
|
||||
"taskroot",
|
||||
"Testcontainers",
|
||||
"tmpl",
|
||||
"tmplv",
|
||||
"touchpoints",
|
||||
"trpc",
|
||||
"Turborepo",
|
||||
"Underserved",
|
||||
"unredacted",
|
||||
"upgrader",
|
||||
"upgraders",
|
||||
"VARCHAR",
|
||||
"venv",
|
||||
"vercel",
|
||||
"Vite",
|
||||
"WCAG",
|
||||
"wireframes"
|
||||
],
|
||||
"markdownlint.config": {
|
||||
"MD033": {
|
||||
"allowed_elements": ["br", "div", "img", "rule", "sub"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"cSpell.words": [
|
||||
"Agentic",
|
||||
"elicitations",
|
||||
"Shardable"
|
||||
]
|
||||
}
|
||||
76
CHANGELOG.md
76
CHANGELOG.md
@@ -1,3 +1,79 @@
|
||||
# [4.20.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.19.2...v4.20.0) (2025-06-29)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* Massive documentation refactor, added explanation of the new expanded role of the QA agent that will make your code quality MUCH better. 2 new diagram clearly explain the role of the pre dev ideation cycle (prd and architecture) and the details of how the dev cycle works. ([c881dcc](https://github.com/bmadcode/BMAD-METHOD/commit/c881dcc48ff827ddfe8653aa364a021a66ce66eb))
|
||||
|
||||
## [4.19.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.19.1...v4.19.2) (2025-06-28)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* docs update and correction ([2408068](https://github.com/bmadcode/BMAD-METHOD/commit/240806888448bb3a42acfd2f209976d489157e21))
|
||||
|
||||
## [4.19.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.19.0...v4.19.1) (2025-06-28)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* discord link ([2ea806b](https://github.com/bmadcode/BMAD-METHOD/commit/2ea806b3af58ad37fcb695146883a9cd3003363d))
|
||||
|
||||
# [4.19.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.18.0...v4.19.0) (2025-06-28)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* expansion install config ([50d17ed](https://github.com/bmadcode/BMAD-METHOD/commit/50d17ed65d40f6688f3b6e62732fb2280b6b116e))
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* install for ide now sets up rules also for expansion agents! ([b82978f](https://github.com/bmadcode/BMAD-METHOD/commit/b82978fd38ea789a799ccc1373cfb61a2001c1e0))
|
||||
|
||||
# [4.18.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.17.0...v4.18.0) (2025-06-28)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* expansion teams can now include core agents and include their assets automatically ([c70f1a0](https://github.com/bmadcode/BMAD-METHOD/commit/c70f1a056b0f6e3c805096ee5d27f0a3640fb00c))
|
||||
* remove hardcoding from installer for agents, improve expansion pack installation to its own locations, common files moved to common folder ([95e833b](https://github.com/bmadcode/BMAD-METHOD/commit/95e833beebc3a60f73a7a1c67d534c8eb6bf48fd))
|
||||
|
||||
# [4.17.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.16.1...v4.17.0) (2025-06-27)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* add GEMINI.md to agent context files ([#272](https://github.com/bmadcode/BMAD-METHOD/issues/272)) ([b557570](https://github.com/bmadcode/BMAD-METHOD/commit/b557570081149352e4efbef8046935650f6ecea1))
|
||||
|
||||
## [4.16.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.16.0...v4.16.1) (2025-06-26)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* remove accidental folder add ([b1c2de1](https://github.com/bmadcode/BMAD-METHOD/commit/b1c2de1fb58029f68e021faa90cd5d5faf345198))
|
||||
|
||||
# [4.16.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.15.0...v4.16.0) (2025-06-26)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* repo builds all rules sets for supported ides for easy copy if desired ([ea945bb](https://github.com/bmadcode/BMAD-METHOD/commit/ea945bb43f6ea50594910b954c72e79f96a8504c))
|
||||
|
||||
# [4.15.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.14.1...v4.15.0) (2025-06-26)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* Add Gemini CLI Integration ([#271](https://github.com/bmadcode/BMAD-METHOD/issues/271)) ([44b9d7b](https://github.com/bmadcode/BMAD-METHOD/commit/44b9d7bcb5cbb6de5a15d8f2ec7918d186ac9576))
|
||||
|
||||
## [4.14.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.14.0...v4.14.1) (2025-06-26)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* add updated web builds ([6dabbcb](https://github.com/bmadcode/BMAD-METHOD/commit/6dabbcb670ef22708db6c01dac82069547ca79d6))
|
||||
|
||||
# [4.14.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.13.0...v4.14.0) (2025-06-25)
|
||||
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ 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.
|
||||
📋 **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.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# BMAD Method Guiding Principles
|
||||
# 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.
|
||||
The BMad Method is a natural language framework for AI-assisted software development. These principles ensure contributions maintain the method's effectiveness.
|
||||
|
||||
## Core Principles
|
||||
|
||||
|
||||
2
LICENSE
2
LICENSE
@@ -1,6 +1,6 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2025 Brian AKA BMad AKA Bmad Code
|
||||
Copyright (c) 2025 Brian AKA BMad AKA BMad Code
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
|
||||
440
README.md
440
README.md
@@ -1,32 +1,73 @@
|
||||
# BMAD-METHOD
|
||||
# BMad-METHOD: Universal AI Agent Framework
|
||||
|
||||
[](https://www.npmjs.com/package/bmad-method)
|
||||
[](LICENSE)
|
||||
[](https://nodejs.org)
|
||||
[](https://discord.gg/g6ypHytrCB)
|
||||
[](https://discord.gg/gk8jAdXWmj)
|
||||
|
||||
**AI-Powered Agile Development Framework** - Transform your software development with specialized AI agents that work as your complete Agile team.
|
||||
Foundations in Agentic Agile Driven Development, known as the Breakthrough Method of Agile AI-Driven Development, but it is so much more. Transform any domain with specialized AI expertise: software development, entertainment, creative writing, business strategy to personal wellness just to name a few.
|
||||
|
||||
📺 **[Subscribe to BMadCode on YouTube](https://www.youtube.com/@BMadCode?sub_confirmation=1)** - V4 walkthrough and comprehensive guide coming soon!
|
||||
**[Subscribe to BMadCode on YouTube](https://www.youtube.com/@BMadCode?sub_confirmation=1)**
|
||||
|
||||
⭐ **If you find this project helpful or useful, please give it a star!** It helps others discover BMAD-METHOD and you will be notified of updates!
|
||||
**[Join our Discord Community](https://discord.gg/gk8jAdXWmj)** - A growing community for AI enthusiasts! Get help, share ideas, explore AI agents & frameworks, collaborate on tech projects, enjoy hobbies, and help each other succeed. Whether you're stuck on BMad, building your own agents, or just want to chat about the latest in AI - we're here for you!
|
||||
|
||||
## 🔄 Important: Keeping Your BMAD Installation Updated
|
||||
⭐ **If you find this project helpful or useful, please give it a star in the upper right hand corner!** It helps others discover BMad-METHOD and you will be notified of updates!
|
||||
|
||||
**Stay up-to-date effortlessly!** If you already have BMAD-METHOD installed in your project, simply run:
|
||||
## 🧭 Quick Navigation - Find Your Path
|
||||
|
||||
### 🚨 MUST READ: Understanding the BMAD Workflow
|
||||
|
||||
**Before diving in, review these critical workflow diagrams that explain how BMAD works:**
|
||||
|
||||
1. **[Planning Workflow (Web UI)](docs/user-guide.md#the-planning-workflow-web-ui)** - How to create PRD and Architecture documents
|
||||
2. **[Core Development Cycle (IDE)](docs/user-guide.md#the-core-development-cycle-ide)** - How SM, Dev, and QA agents collaborate through story files
|
||||
|
||||
> ⚠️ **These diagrams explain 90% of BMad Method Agentic Agile flow confusion** - Understanding the PRD+Architecture creation and the SM/Dev/QA workflow and how agents pass notes through story files is essential - and also explains why this is NOT taskmaster or just a simple task runner!
|
||||
|
||||
### What would you like to do?
|
||||
|
||||
- **[Build software with Full Stack Agile AI Team](#-quick-start)** → Quick Start Instruction
|
||||
- **[Learn how to use BMAD](docs/user-guide.md)** → Complete user guide and walkthrough
|
||||
- **[See available AI agents](#available-agents)** → Specialized roles for your team
|
||||
- **[Explore non-technical uses](#-beyond-software-development---expansion-packs)** → Creative writing, business, wellness, education
|
||||
- **[Create my own AI agents](#creating-your-own-expansion-pack)** → Build agents for your domain
|
||||
- **[Browse ready-made expansion packs](expansion-packs/)** → Game dev, DevOps, infrastructure and get inspired with ideas and examples
|
||||
- **[Understand the architecture](docs/core-architecture.md)** → Technical deep dive
|
||||
- **[Join the community](https://discord.gg/g6ypHytrCB)** → Get help and share ideas
|
||||
|
||||
### Popular Use Cases
|
||||
|
||||
- **Software Development** - [Quick Start](#-quick-start) | [User Guide](docs/user-guide.md) | [Workflow Guides](#documentation--guides)
|
||||
- **Game Development** - [2D Phaser Pack](expansion-packs/bmad-2d-phaser-game-dev/)
|
||||
- **Business Strategy** - [Full Guide](docs/expansion-packs.md#business-strategy-pack)
|
||||
- **Creative Writing** - [Full Guide](docs/expansion-packs.md#creative-writing-pack)
|
||||
- **DevOps/Infrastructure** - [Infrastructure Pack](expansion-packs/bmad-infrastructure-devops/)
|
||||
|
||||
### Quick Links
|
||||
|
||||
- **[Installation](#installation)** → Get started in minutes
|
||||
- **[Documentation](#documentation--guides)** → All guides and references
|
||||
- **[Contributing](#contributing)** → Help improve BMAD
|
||||
- **[Support](#support)** → Get help and connect
|
||||
|
||||
## 🔄 Important: Keeping Your BMad Installation Updated
|
||||
|
||||
**Stay up-to-date effortlessly!** If you already have BMad-METHOD installed in your project, simply run:
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
# OR
|
||||
npm run install:bmad
|
||||
```
|
||||
|
||||
The installer will:
|
||||
This will:
|
||||
|
||||
- ✅ Automatically detect your existing v4 installation
|
||||
- ✅ Update only the files that have changed
|
||||
- ✅ Update only the files that have changed and add new files
|
||||
- ✅ Create `.bak` backup files for any custom modifications you've made
|
||||
- ✅ Preserve your project-specific configurations
|
||||
|
||||
This makes it easy to benefit from the latest improvements, bug fixes, and new agents without losing your customizations!
|
||||
This makes it easy to benefit from the latest improvements, bug fixes, and new agents without losing your customizations! If for some reason this fails, you can rename or remove your .bmad-code folder and run the install again. The main thing to look out for is if you have set up custom modes that are not file driven (Cursor is the only one at this time that is not done through project files lagging behind) - you will want to ensure your sm and dev custom modes especially are kept up to date.
|
||||
|
||||
## 🚀 Quick Start
|
||||
|
||||
@@ -45,28 +86,20 @@ This makes it easy to benefit from the latest improvements, bug fixes, and new a
|
||||
|
||||
Run `npx bmad-method install`
|
||||
|
||||
OR
|
||||
|
||||
```bash
|
||||
git clone https://github.com/bmadcode/bmad-method.git
|
||||
npm run install:bmad # build and install all to a destination folder
|
||||
```
|
||||
|
||||
This installs all agents and configures them for your IDE. If you have an existing v3 installation, it will offer to upgrade it automatically.
|
||||
|
||||
## 📋 Table of Contents
|
||||
|
||||
- [Overview](#overview)
|
||||
- [Installation](#installation)
|
||||
- [Available Agents](#available-agents)
|
||||
- [Usage](#usage)
|
||||
- [Project Structure](#project-structure)
|
||||
- [Contributing](#contributing)
|
||||
|
||||
## Overview
|
||||
|
||||
BMAD-METHOD (Breakthrough Method of Agile AI-Driven Development) revolutionizes software development by providing specialized AI agents for every role in an Agile team. Each agent has deep expertise in their domain and can collaborate to deliver complete software projects.
|
||||
The BMad Method (Breakthrough Method of Agile Agentic-Driven Development) elevates 'Vibe Coding' by providing specialized AI agents for every role in an Agile team. Each agent has deep expertise in their domain helping you really plan and execute on your vision while keeping the agents on the rails even through complex application plans.
|
||||
|
||||
### Why BMAD?
|
||||
|
||||
- **🎯 Specialized Expertise**: Each agent is an expert in their specific role
|
||||
- **🔄 True Agile Workflow**: Follows real Agile methodologies and best practices
|
||||
- **📦 Modular Design**: Use one agent or an entire team
|
||||
- **🛠️ IDE Integration**: Works seamlessly with Cursor, Claude Code, and Windsurf
|
||||
- **🌐 Platform Agnostic**: Use with ChatGPT, Claude, Gemini, or any AI platform
|
||||
Unlike systems like Task Master, or inbuilt Task tool, the BMad Methods agile flow does so much more. With most systems, you give your idea in a few sentences at most, and the system churns out a plan, task list, lets you review it and then starts executing. Where the BMad agile flow is different is you can choose to have more upfront planning and architecture specification to ensure the system is built in a sustainable way, not a vibe coded spaghetti mess. When producing the PRD and Architectures (full stack, front end and or backend), the Agents work with you back and forth using advanced proven LLM techniques and techniques also based in psychology to produce beyond the average slop LLMs and Task generators will on their own. This truly is a system of Human in the Loop produces markedly better results.
|
||||
|
||||
## Installation
|
||||
|
||||
@@ -91,39 +124,69 @@ Install directly into your project: `npx bmad-method install`
|
||||
|
||||
The BMad Method works with any IDE, but has built-in integration for:
|
||||
|
||||
- `cursor` - Cursor IDE with @agent commands
|
||||
- `cursor` - Cursor IDE with manual rule @agent commands
|
||||
- `claude-code` - Claude Code with /agent commands
|
||||
- `windsurf` - Windsurf with @agent commands
|
||||
- `cline` - Cline Rules integration
|
||||
- `gemini-cli` - Gemini with @agent commands
|
||||
- `windsurf` - Windsurf with manual rule @agent commands
|
||||
- `roo` - Roo Code with custom modes (see `.roomodes`)
|
||||
- More coming soon - BUT ITS easy to use with ANY IDE - just copy the bmad-code folder to your project, and rename it .bmad-code.
|
||||
- `windsurf` - Windsurf with @agent commands
|
||||
|
||||
## Available Agents
|
||||
|
||||
### Core Development Team
|
||||
|
||||
| Agent | Role | Specialty |
|
||||
| ----------- | ------------------ | --------------------------------------------- |
|
||||
| `analyst` | Business Analyst | market analysis, brainstorming, project brief |
|
||||
| `pm` | Product Manager | Product strategy, roadmaps, PRDs |
|
||||
| `architect` | Solution Architect | System design, technical architecture |
|
||||
| `dev` | Developer | Code implementation across all technologies |
|
||||
| `qa` | QA Specialist | Testing strategies, quality assurance |
|
||||
| `ux-expert` | UX Designer | User experience, UI design, prototypes |
|
||||
| `po` | Product Owner | Backlog management, story validation |
|
||||
| `sm` | Scrum Master | Sprint planning, story creation |
|
||||
| Agent | Role | Specialty |
|
||||
| ----------- | ------------------ | -------------------------------------------------------------------------------------------- |
|
||||
| `analyst` | Business Analyst | market analysis, brainstorming, project brief creation |
|
||||
| `pm` | Product Manager | Product strategy, MVP Decisioning, PRD creation with Epics |
|
||||
| `architect` | Solution Architect | System design, technical full stack, front end or backend architecture |
|
||||
| `ux-expert` | UX Designer | User experience, UI design, prompts for V0, Lovable, and others |
|
||||
| `po` | Product Owner | Ensure PRD and Architecture are aligned, and changes from architecture end up in PRD stories |
|
||||
| `sm` | Scrum Master | High level epics and stories transformed into detailed dev stories with tasks and subtasks |
|
||||
| `dev` | Developer | Code implementation across all technologies - follows the detailed SM created story |
|
||||
| `qa` | QA Specialist | Detailed review of the devs ready for review story, refactor and propose issues and changes |
|
||||
|
||||
### Meta Agents
|
||||
### BMad Agents
|
||||
|
||||
| Agent | Role | Specialty |
|
||||
| ------------------- | ---------------- | ------------------------------------------------------------------- |
|
||||
| `bmad-orchestrator` | Team Coordinator | Multi-agent workflows, role switching, is part of every team bundle |
|
||||
| `bmad-master` | Universal Expert | All capabilities without switching |
|
||||
| Agent | Role | Specialty |
|
||||
| ------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `bmad-orchestrator` | Team Coordinator | Helps guide you and answers your questions with its massive knowledge base, and guides you through Multi-agent workflows |
|
||||
| `bmad-master` | Universal Expert | All capabilities without switching (Except Dev) |
|
||||
|
||||
## Advanced Features
|
||||
|
||||
### Dynamic Dependencies
|
||||
|
||||
Each agent only loads the resources it needs, keeping context windows lean.
|
||||
|
||||
### Template System
|
||||
|
||||
Rich templates for all document types:
|
||||
|
||||
- Product Requirements (PRD)
|
||||
- Architecture Documents
|
||||
- User Stories
|
||||
- Test Plans
|
||||
- And more...
|
||||
|
||||
Templates are unique in that they are embedded with the LLM instructions also for further working with you to prompt and elicit the best from you and your agile agent team member - allowing for unique coaching and customization options. While there is a single create-doc task, the possibilities are endless when you expand the templates into more doc types, or customize with your own docs embedded with the templating markup and LLM instruction framework that is core to the BMad Method.
|
||||
|
||||
### Slash Star Commands
|
||||
|
||||
Ask the agent you are using for help with /help (in the web) or \*help in the ide to see what commands are available!
|
||||
|
||||
### Advanced Elicitation
|
||||
|
||||
Many of the Agents and Templates for docs, and some tasks, include Advanced Elicitation directives based on the latest in LLM interactions and pro level prompt engineering guidance. With this, you can push the Agents further than ever before. If an agent proposes an idea, or an architecture - you can push it further with optional elicitations where it will have to really expand on, defend, or produce other options and prove its suggestion was better. This is a necessary step if you want the absolute best beyond accepting the generated average responses the LLMs think you want to hear for their first response. Some of this is interactive, and some of this is baked into the core prompting engine that powers the LLM progression through various tasks and template flows.
|
||||
|
||||
## Usage
|
||||
|
||||
### With IDE Integration
|
||||
The BMAD Method follows a structured Agile workflow with specialized AI agents. For complete usage instructions and walkthroughs, see the **[User Guide](docs/user-guide.md)**.
|
||||
|
||||
After installation with `--ide` flag:
|
||||
### Quick Start Examples
|
||||
|
||||
#### With IDE Integration
|
||||
|
||||
```bash
|
||||
# In Cursor
|
||||
@@ -136,118 +199,29 @@ After installation with `--ide` flag:
|
||||
@dev Implement story 1.3
|
||||
```
|
||||
|
||||
### With Web UI (ChatGPT/Claude/Gemini)
|
||||
#### With Web UI
|
||||
|
||||
After uploading a bundle you can ask /help of the agent to learn what it can do
|
||||
After uploading a bundle, type `/help` to see available commands.
|
||||
|
||||
### CLI Commands
|
||||
### Key Resources
|
||||
|
||||
```bash
|
||||
# List all available agents
|
||||
npx bmad-method list
|
||||
|
||||
# Install or update (automatically detects existing installations)
|
||||
npx bmad-method install
|
||||
|
||||
# Check installation status
|
||||
npx bmad-method status
|
||||
```
|
||||
|
||||
### Upgrading from V3 to V4
|
||||
|
||||
If you have an existing BMAD-METHOD V3 project, simply run the installer in your project directory:
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
# The installer will automatically detect your V3 installation and offer to upgrade
|
||||
```
|
||||
|
||||
The upgrade process will:
|
||||
|
||||
1. Create a backup of your V3 files in `.bmad-v3-backup/`
|
||||
2. Install the new V4 `.bmad-core/` structure
|
||||
3. Migrate your documents (PRD, Architecture, Stories, Epics)
|
||||
4. Set up IDE integration for all V4 agents
|
||||
5. Create an install manifest for future updates
|
||||
|
||||
After upgrading:
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
### Pre-Configured Teams
|
||||
|
||||
Save context by using specialized teams:
|
||||
|
||||
- **Team All**: Complete Agile team with all 10 agents
|
||||
- **Team Fullstack**: Frontend + Backend development focus
|
||||
- **Team No-UI**: Backend/API development without UX
|
||||
|
||||
### Workflows
|
||||
|
||||
Structured approaches for different scenarios:
|
||||
|
||||
- **Greenfield**: Starting new projects (fullstack/service/UI)
|
||||
- **Brownfield**: Enhancing existing projects
|
||||
- **Simple**: Quick prototypes and MVPs
|
||||
- **Complex**: Enterprise and large-scale projects
|
||||
- **[Complete User Guide](docs/user-guide.md)** - Full walkthrough from project inception to completion
|
||||
- **[CLI Commands](docs/user-guide.md#cli-commands)** - Installation, updates, and management
|
||||
- **[Upgrading from V3](docs/user-guide.md#upgrading-from-v3-to-v4)** - Migration instructions
|
||||
- **[Core Configuration](docs/user-guide.md#core-configuration-coreconfigyml)** - V4's flexible project structure support
|
||||
- **[Teams & Workflows](docs/user-guide.md#team-configurations)** - Pre-configured agent teams
|
||||
|
||||
## Project Structure
|
||||
|
||||
```plaintext
|
||||
.bmad-core/
|
||||
├── agents/ # Individual agent definitions
|
||||
├── agent-teams/ # Team configurations
|
||||
├── workflows/ # Development workflows
|
||||
├── templates/ # Document templates (PRD, Architecture, etc.)
|
||||
├── tasks/ # Reusable task definitions
|
||||
├── checklists/ # Quality checklists
|
||||
├── data/ # Knowledge base
|
||||
└── web-bundles/ # Optional can be added if you use the install command and select this folder as a destination for the build bundle files
|
||||
See the **[Core Architecture](docs/core-architecture.md)** for the complete source tree and detailed explanations of each component.
|
||||
|
||||
tools/
|
||||
├── cli.js # Build tool
|
||||
├── installer/ # NPX installer
|
||||
└── lib/ # Build utilities
|
||||
### Key Directories
|
||||
|
||||
expansion-packs/ # Domain-specific add-ons (Technical & Non-Technical)
|
||||
|
||||
dist/ # 📦 PRE-BUILT BUNDLES (Ready to use!)
|
||||
├── agents/ # Individual agent bundles (.txt files)
|
||||
├── teams/ # Team bundles (.txt files)
|
||||
└── expansion-packs/ # Expansion pack bundles
|
||||
```
|
||||
- **`.bmad-core/`** - Heart of the framework (agents, templates, workflows)
|
||||
- **`dist/`** - Pre-built bundles ready for web UI use
|
||||
- **`expansion-packs/`** - Domain-specific extensions
|
||||
- **`tools/`** - Build and installation utilities
|
||||
- **`docs/`** - Your project documentation (PRD, architecture, stories)
|
||||
|
||||
### 📦 Pre-Built Bundles (dist/ folder)
|
||||
|
||||
@@ -269,89 +243,6 @@ dist/ # 📦 PRE-BUILT BUNDLES (Ready to use!)
|
||||
|
||||
**For Web UI usage**: Simply copy any `.txt` file from `dist/` and upload to your AI platform!`
|
||||
|
||||
## Advanced Features
|
||||
|
||||
### Dynamic Dependencies
|
||||
|
||||
Each agent only loads the resources it needs, keeping context windows lean.
|
||||
|
||||
### Template System
|
||||
|
||||
Rich templates for all document types:
|
||||
|
||||
- Product Requirements (PRD)
|
||||
- Architecture Documents
|
||||
- User Stories
|
||||
- Test Plans
|
||||
- And more...
|
||||
|
||||
### Slash Star Commands
|
||||
|
||||
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're excited about contributions and welcome your ideas, improvements, and expansion packs!** 🎉
|
||||
|
||||
### 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
|
||||
|
||||
```bash
|
||||
git clone https://github.com/bmadcode/bmad-method.git
|
||||
cd bmad-method
|
||||
npm install
|
||||
```
|
||||
|
||||
## Documentation & Guides
|
||||
|
||||
### Architecture & Technical
|
||||
@@ -364,10 +255,49 @@ npm install
|
||||
|
||||
- 📚 [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
|
||||
- 🦘 [Roo Code Guide](docs/roo-code-guide.md) - Complete workflow for Roo Code users
|
||||
|
||||
### IDE-Specific Guides
|
||||
|
||||
- 🎯 [Cursor Guide](docs/agentic-tools/cursor-guide.md) - Setup and usage for Cursor
|
||||
- 🤖 [Claude Code Guide](docs/agentic-tools/claude-code-guide.md) - Setup and usage for Claude Code
|
||||
- 🌊 [Windsurf Guide](docs/agentic-tools/windsurf-guide.md) - Setup and usage for Windsurf
|
||||
- 🦘 [Roo Code Guide](docs/agentic-tools/roo-code-guide.md) - Setup and usage for Roo Code
|
||||
- 🔧 [Cline Guide](docs/agentic-tools/cline-guide.md) - Setup and usage for Cline (VS Code)
|
||||
- ✨ [Gemini CLI Guide](docs/agentic-tools/gemini-cli-guide.md) - Setup and usage for Gemini CLI
|
||||
|
||||
## 🌟 Beyond Software Development - Expansion Packs
|
||||
|
||||
While BMAD excels at software development, its natural language framework can structure expertise in ANY domain. Expansion packs transform BMAD into a universal AI agent system for creative writing, business strategy, health & wellness, education, and much more.
|
||||
|
||||
### Available Expansion Packs
|
||||
|
||||
#### Technical Domains
|
||||
|
||||
- 🎮 **[Game Development](expansion-packs/bmad-2d-phaser-game-dev/)** - Complete game studio team with designers, developers, and narrative writers
|
||||
- 🏗️ **[Infrastructure/DevOps](expansion-packs/bmad-infrastructure-devops/)** - Cloud architects, security specialists, SRE experts
|
||||
- 📱 **Mobile Development** - iOS/Android specialists, mobile UX designers
|
||||
- 🔗 **Blockchain/Web3** - Smart contract developers, DeFi architects
|
||||
|
||||
#### Non-Technical Domains
|
||||
|
||||
- 💼 **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, content creators, research assistants
|
||||
|
||||
### Creating Your Own Expansion Pack
|
||||
|
||||
Transform your expertise into AI agents:
|
||||
|
||||
1. **Identify your domain** - What knowledge do you want to share?
|
||||
2. **Design specialized agents** - Each with unique expertise and personality
|
||||
3. **Create reusable tasks** - Standard procedures in your field
|
||||
4. **Build professional templates** - Structured outputs for consistency
|
||||
5. **Share with the community** - Help others benefit from your expertise
|
||||
|
||||
📖 **[Read the full Expansion Packs Guide](docs/expansion-packs.md)** - Detailed examples, inspiration, and technical details
|
||||
|
||||
## Support
|
||||
|
||||
@@ -394,7 +324,39 @@ See [versions.md](docs/versions.md) for detailed version history and migration g
|
||||
|
||||
Created by Brian (BMad) Madison
|
||||
|
||||
---
|
||||
## Contributing
|
||||
|
||||
**We're excited about contributions and welcome your ideas, improvements, and expansion packs!** 🎉
|
||||
|
||||
### 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 and not improvements to the core system (those belong in the core system)
|
||||
- All contributions must follow our natural language, markdown-based templating approach with template embedded LLM instructions and elicitations
|
||||
|
||||
We're building something amazing together - let's keep it simple, powerful, and focused! 💪
|
||||
|
||||
### Development Setup
|
||||
|
||||
Want to help improve the BMad Method. Fork n' Clone the repo
|
||||
|
||||
```bash
|
||||
git clone https://github.com/bmadcode/bmad-method.git
|
||||
cd bmad-method
|
||||
|
||||
npm run build # rebuild the dist folder
|
||||
npm run install:bmad # build and install all to a destination folder
|
||||
```
|
||||
|
||||
[](https://github.com/bmadcode/bmad-method/graphs/contributors)
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ task-execution:
|
||||
updates-ONLY:
|
||||
- "Checkboxes: [ ] not started | [-] in progress | [x] complete"
|
||||
- "Debug Log: | Task | File | Change | Reverted? |"
|
||||
- "Completion Notes: Deviations only, <50 words"
|
||||
- "Completion Notes: Deviations from AC or tasks during execution only, <50 words"
|
||||
- "Change Log: Requirement changes only"
|
||||
- "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"
|
||||
|
||||
@@ -17,4 +17,3 @@ devLoadAlwaysFiles:
|
||||
- docs/architecture/source-tree.md
|
||||
devDebugLog: .ai/debug-log.md
|
||||
devStoryLocation: docs/stories
|
||||
agentCoreDump: .ai/core-dump{n}.md
|
||||
|
||||
@@ -719,7 +719,7 @@ Expansion packs extend BMAD-METHOD beyond traditional software development into
|
||||
### Using Expansion Packs
|
||||
|
||||
1. **Browse Available Packs**: Check `expansion-packs/` directory
|
||||
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
|
||||
2. **Get Inspiration**: See `docs/expansion-packs.md` for detailed examples and ideas
|
||||
3. **Install via CLI**:
|
||||
```bash
|
||||
npx bmad-method install
|
||||
|
||||
@@ -1,74 +0,0 @@
|
||||
# Core Dump Task
|
||||
|
||||
## Purpose
|
||||
|
||||
To create a concise memory recording file (`.ai/core-dump-n.md`) that captures the essential context of the current agent session, enabling seamless continuation of work in future agent sessions. This task ensures persistent context across agent conversations while maintaining minimal token usage for efficient context loading.
|
||||
|
||||
## Inputs for this Task
|
||||
|
||||
- Current session conversation history and accomplishments
|
||||
- Files created, modified, or deleted during the session
|
||||
- Key decisions made and procedures followed
|
||||
- Current project state and next logical steps
|
||||
- User requests and agent responses that shaped the session
|
||||
|
||||
## Task Execution Instructions
|
||||
|
||||
### 0. Check Existing Core Dump
|
||||
|
||||
Before proceeding, check if `.ai/core-dump.md` already exists:
|
||||
|
||||
- If file exists, ask user: "Core dump file exists. Should I: 1. Overwrite, 2. Update, 3. Append or 4. Create new?"
|
||||
- **Overwrite**: Replace entire file with new content
|
||||
- **Update**: Merge new session info with existing content, updating relevant sections
|
||||
- **Append**: Add new session as a separate entry while preserving existing content
|
||||
- **Create New**: Create a new file, appending the next possible -# to the file, such as core-dump-3.md if 1 and 2 already exist.
|
||||
- If file doesn't exist, proceed with creation of `core-dump-1.md`
|
||||
|
||||
### 1. Analyze Session Context
|
||||
|
||||
- Review the entire conversation to identify key accomplishments
|
||||
- Note any specific tasks, procedures, or workflows that were executed
|
||||
- Identify important decisions made or problems solved
|
||||
- Capture the user's working style and preferences observed during the session
|
||||
|
||||
### 2. Document What Was Accomplished
|
||||
|
||||
- **Primary Actions**: List the main tasks completed concisely
|
||||
- **Story Progress**: For story work, use format "Tasks Complete: 1-6, 8. Next Task Pending: 7, 9"
|
||||
- **Problem Solving**: Document any challenges encountered and how they were resolved
|
||||
- **User Communications**: Summarize key user requests, preferences, and discussion points
|
||||
|
||||
### 3. Record File System Changes (Concise Format)
|
||||
|
||||
- **Files Created**: `filename.ext` (brief purpose/size)
|
||||
- **Files Modified**: `filename.ext` (what changed)
|
||||
- **Files Deleted**: `filename.ext` (why removed)
|
||||
- Focus on essential details, avoid verbose descriptions
|
||||
|
||||
### 4. Capture Current Project State
|
||||
|
||||
- **Project Progress**: Where the project stands after this session
|
||||
- **Current Issues**: Any blockers or problems that need resolution
|
||||
- **Next Logical Steps**: What would be the natural next actions to take
|
||||
|
||||
### 5. Create/Update Core Dump File
|
||||
|
||||
Based on user's choice from step 0, handle the file accordingly:
|
||||
|
||||
### 6. Optimize for Minimal Context
|
||||
|
||||
- Keep descriptions concise but informative
|
||||
- Use abbreviated formats where possible (file sizes, task numbers)
|
||||
- Focus on actionable information rather than detailed explanations
|
||||
- Avoid redundant information that can be found in project documentation
|
||||
- Prioritize information that would be lost without this recording
|
||||
- Ensure the file can be quickly scanned and understood
|
||||
|
||||
### 7. Validate Completeness
|
||||
|
||||
- Verify all significant session activities are captured
|
||||
- Ensure a future agent could understand the current state
|
||||
- Check that file changes are accurately recorded
|
||||
- Confirm next steps are clear and actionable
|
||||
- Verify user communication style and preferences are noted
|
||||
@@ -1,74 +0,0 @@
|
||||
# Create Document from Template Task
|
||||
|
||||
## Purpose
|
||||
|
||||
- Generate documents from any specified template following embedded instructions from the perspective of the selected agent persona
|
||||
|
||||
## Instructions
|
||||
|
||||
### 1. Identify Template and Context
|
||||
|
||||
- Determine which template to use (user-provided or list available for selection to user)
|
||||
|
||||
- Agent-specific templates are listed in the agent's dependencies under `templates`. For each template listed, consider it a document the agent can create. So if an agent has:
|
||||
|
||||
@{example}
|
||||
dependencies:
|
||||
templates: - prd-tmpl - architecture-tmpl
|
||||
@{/example}
|
||||
|
||||
You would offer to create "PRD" and "Architecture" documents when the user asks what you can help with.
|
||||
|
||||
- Gather all relevant inputs, or ask for them, or else rely on user providing necessary details to complete the document
|
||||
- Understand the document purpose and target audience
|
||||
|
||||
### 2. Determine Interaction Mode
|
||||
|
||||
Confirm with the user their preferred interaction style:
|
||||
|
||||
- **Incremental:** Work through chunks of the document.
|
||||
- **YOLO Mode:** Draft complete document making reasonable assumptions in one shot. (Can be entered also after starting incremental by just typing /yolo)
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
#### CRITICAL: Never display template markup, LLM instructions, or examples to users
|
||||
|
||||
- Replace all {{placeholders}} with actual content
|
||||
- Execute all [[LLM: instructions]] internally
|
||||
- Process `<<REPEAT>>` sections as needed
|
||||
- Evaluate ^^CONDITION^^ blocks and include only if applicable
|
||||
- Use @{examples} for guidance but never output them
|
||||
|
||||
### 5. Content Generation
|
||||
|
||||
- **Incremental Mode**: Present each major section for review before proceeding
|
||||
- **YOLO Mode**: Generate all sections, then review complete document with user
|
||||
- Apply any elicitation protocols specified in template
|
||||
- Incorporate user feedback and iterate as needed
|
||||
|
||||
### 6. Validation
|
||||
|
||||
If template specifies a checklist:
|
||||
|
||||
- Run the appropriate checklist against completed document
|
||||
- Document completion status for each item
|
||||
- Address any deficiencies found
|
||||
- Present validation summary to user
|
||||
|
||||
### 7. Final Presentation
|
||||
|
||||
- Present clean, formatted content only
|
||||
- Ensure all sections are complete
|
||||
- DO NOT truncate or summarize content
|
||||
- Begin directly with document content (no preamble)
|
||||
- Include any handoff prompts specified in template
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Template markup is for AI processing only - never expose to users
|
||||
@@ -1,97 +0,0 @@
|
||||
# Checklist Validation Task
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
- Confirm if they want to work through the checklist:
|
||||
- Section by section (interactive mode - very time consuming)
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
- Check each item against the relevant documentation or artifacts as appropriate
|
||||
- Present summary of findings for that section, highlighting warnings, errors and non applicable items (rationale for non-applicability).
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
- Aside from this, follow all checklist llm instructions
|
||||
- Mark items as:
|
||||
- ✅ PASS: Requirement clearly met
|
||||
- ❌ FAIL: Requirement not met or insufficient coverage
|
||||
- ⚠️ PARTIAL: Some aspects covered but needs improvement
|
||||
- N/A: Not applicable to this case
|
||||
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
- In interactive mode, discuss findings with user
|
||||
- Document any user decisions or explanations
|
||||
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
- Specific recommendations for improvement
|
||||
- Any sections or items marked as N/A with justification
|
||||
|
||||
## Checklist Execution Methodology
|
||||
|
||||
Each checklist now contains embedded LLM prompts and instructions that will:
|
||||
|
||||
1. **Guide thorough thinking** - Prompts ensure deep analysis of each section
|
||||
2. **Request specific artifacts** - Clear instructions on what documents/access is needed
|
||||
3. **Provide contextual guidance** - Section-specific prompts for better validation
|
||||
4. **Generate comprehensive reports** - Final summary with detailed findings
|
||||
|
||||
The LLM will:
|
||||
|
||||
- Execute the complete checklist validation
|
||||
- Present a final report with pass/fail rates and key findings
|
||||
- Offer to provide detailed analysis of any section, especially those with warnings or failures
|
||||
@@ -1,10 +0,0 @@
|
||||
# File Resolution Context
|
||||
|
||||
Update the installer/upgrader so that when agents are added to a project (under Add these two lines to any agent's `activation-instructions` for ide installation:
|
||||
|
||||
```yaml
|
||||
- IDE-FILE-RESOLUTION: Dependencies map to files as {root}/{type}/{name}.md where root=".bmad-core", type=folder (tasks/templates/checklists/utils), name=dependency name.
|
||||
- REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "draft story"→*create→create-next-story task, "make a new prd" would be dependencies->tasks->create-doc combined with the dependencies->templates->prd-tmpl.md), or ask for clarification if ambiguous.
|
||||
```
|
||||
|
||||
and add `root: .bmad-core` as the first root yml property.
|
||||
@@ -1,223 +0,0 @@
|
||||
# Workflow Management
|
||||
|
||||
This utility enables the BMAD orchestrator to manage and execute team workflows.
|
||||
|
||||
## Important: Dynamic Workflow Loading
|
||||
|
||||
The BMAD orchestrator MUST read the available workflows from the current team configuration's `workflows` field. Do not use hardcoded workflow lists. Each team bundle defines its own set of supported workflows based on the agents it includes.
|
||||
|
||||
**Critical Distinction**:
|
||||
|
||||
- When asked "what workflows are available?", show ONLY the workflows defined in the current team bundle's configuration
|
||||
- Use `/agent-list` to show agents in the current bundle
|
||||
- Use `/workflows` to show workflows in the current bundle, NOT any creation tasks
|
||||
|
||||
### Workflow Descriptions
|
||||
|
||||
When displaying workflows, use these descriptions based on the workflow ID:
|
||||
|
||||
- **greenfield-fullstack**: Build a new full-stack application from concept to development
|
||||
- **brownfield-fullstack**: Enhance an existing full-stack application with new features
|
||||
- **greenfield-service**: Build a new backend service or API from concept to development
|
||||
- **brownfield-service**: Enhance an existing backend service or API
|
||||
- **greenfield-ui**: Build a new frontend/UI application from concept to development
|
||||
- **brownfield-ui**: Enhance an existing frontend/UI application
|
||||
|
||||
## Workflow Commands
|
||||
|
||||
### /workflows
|
||||
|
||||
Lists all available workflows for the current team. The available workflows are determined by the team configuration and may include workflows such as:
|
||||
|
||||
- greenfield-fullstack
|
||||
- brownfield-fullstack
|
||||
- greenfield-service
|
||||
- brownfield-service
|
||||
- greenfield-ui
|
||||
- brownfield-ui
|
||||
|
||||
The actual list depends on which team bundle is loaded. When responding to this command, display the workflows that are configured in the current team's `workflows` field.
|
||||
|
||||
Example response format:
|
||||
|
||||
```text
|
||||
Available workflows for [Team Name]:
|
||||
1. [workflow-id] - [Brief description based on workflow type]
|
||||
2. [workflow-id] - [Brief description based on workflow type]
|
||||
[... etc. ...]
|
||||
|
||||
Use /workflow-start {number or id} to begin a workflow.
|
||||
```
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
|
||||
Starts a specific workflow and transitions to the first agent.
|
||||
|
||||
Example: `/workflow-start greenfield-fullstack`
|
||||
|
||||
### /workflow-status
|
||||
|
||||
Shows current workflow progress, completed artifacts, and next steps.
|
||||
|
||||
Example response:
|
||||
|
||||
```text
|
||||
Current Workflow: Greenfield Full-Stack Development
|
||||
Stage: Product Planning (2 of 6)
|
||||
Completed:
|
||||
✓ Discovery & Requirements
|
||||
- project-brief (completed by Mary)
|
||||
|
||||
In Progress:
|
||||
⚡ Product Planning
|
||||
- Create PRD (John) - awaiting input
|
||||
|
||||
Next: Technical Architecture
|
||||
```
|
||||
|
||||
### /workflow-resume
|
||||
|
||||
Resumes a workflow from where it left off, useful when starting a new chat.
|
||||
|
||||
User can provide completed artifacts:
|
||||
|
||||
```text
|
||||
User: /workflow-resume greenfield-fullstack
|
||||
I have completed: project-brief, PRD
|
||||
BMad: I see you've completed Discovery and part of Product Planning.
|
||||
Based on the greenfield-fullstack workflow, the next step is:
|
||||
- UX Strategy with Sally (ux-expert)
|
||||
|
||||
Would you like me to load Sally to continue?
|
||||
```
|
||||
|
||||
### /workflow-next
|
||||
|
||||
Shows the next recommended agent and action in the current workflow.
|
||||
|
||||
## Workflow Execution Flow
|
||||
|
||||
### 1. Starting a Workflow
|
||||
|
||||
When a workflow is started:
|
||||
|
||||
1. Load the workflow definition
|
||||
2. Identify the first stage and step
|
||||
3. Transition to the required agent
|
||||
4. Provide context about expected inputs/outputs
|
||||
5. Guide artifact creation
|
||||
|
||||
### 2. Stage Transitions
|
||||
|
||||
After each artifact is completed:
|
||||
|
||||
1. Mark the step as complete
|
||||
2. Check transition conditions
|
||||
3. If stage is complete, move to next stage
|
||||
4. Load the appropriate agent
|
||||
5. Pass relevant artifacts as context
|
||||
|
||||
### 3. Artifact Tracking
|
||||
|
||||
Track all created artifacts:
|
||||
|
||||
```yaml
|
||||
workflow_state:
|
||||
current_workflow: greenfield-fullstack
|
||||
current_stage: planning
|
||||
current_step: 2
|
||||
artifacts:
|
||||
project-brief:
|
||||
status: completed
|
||||
created_by: analyst
|
||||
timestamp: 2024-01-15T10:30:00.000Z
|
||||
prd:
|
||||
status: in-progress
|
||||
created_by: pm
|
||||
started: 2024-01-15T11:00:00.000Z
|
||||
```
|
||||
|
||||
### 4. Workflow Interruption Handling
|
||||
|
||||
When user returns after interruption:
|
||||
|
||||
1. Ask if continuing previous workflow
|
||||
2. Request any completed artifacts
|
||||
3. Analyze provided artifacts
|
||||
4. Determine workflow position
|
||||
5. Suggest next appropriate step
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
User: I'm working on a new app. Here's my PRD and architecture doc.
|
||||
BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||
it looks like you're following the greenfield-fullstack workflow and have completed
|
||||
stages 1-3. The next recommended step would be:
|
||||
|
||||
Stage 4: Validation & Refinement
|
||||
- Load Sarah (Product Owner) to validate all artifacts
|
||||
|
||||
Would you like to continue with this workflow?
|
||||
```
|
||||
|
||||
## Workflow Context Passing
|
||||
|
||||
When transitioning between agents, pass:
|
||||
|
||||
1. Previous artifacts created
|
||||
2. Current workflow stage
|
||||
3. Expected outputs
|
||||
4. Any decisions or constraints identified
|
||||
|
||||
Example transition:
|
||||
|
||||
```text
|
||||
BMad: Great! John has completed the PRD. According to the greenfield-fullstack workflow,
|
||||
the next step is UX Strategy with Sally.
|
||||
|
||||
/ux-expert
|
||||
|
||||
Sally: I see we're in the Product Planning stage of the greenfield-fullstack workflow.
|
||||
I have access to:
|
||||
- Project Brief from Mary
|
||||
- PRD from John
|
||||
|
||||
Let's create the UX strategy and UI specifications. First, let me review
|
||||
the PRD to understand the features we're designing for...
|
||||
```
|
||||
|
||||
## Multi-Path Workflows
|
||||
|
||||
Some workflows may have multiple paths:
|
||||
|
||||
```yaml
|
||||
conditional_paths:
|
||||
- condition: project_type == 'mobile'
|
||||
next_stage: mobile-specific-design
|
||||
- condition: project_type == 'web'
|
||||
next_stage: web-architecture
|
||||
- default: fullstack-architecture
|
||||
```
|
||||
|
||||
Handle these by asking clarifying questions when needed.
|
||||
|
||||
## Workflow Best Practices
|
||||
|
||||
1. **Always show progress** - Users should know where they are
|
||||
2. **Explain transitions** - Why moving to next agent
|
||||
3. **Preserve context** - Pass relevant information forward
|
||||
4. **Allow flexibility** - Users can skip or modify steps
|
||||
5. **Track everything** - Maintain complete workflow state
|
||||
|
||||
## Integration with Agents
|
||||
|
||||
Each agent should be workflow-aware:
|
||||
|
||||
- Know which workflow is active
|
||||
- Understand their role in the workflow
|
||||
- Access previous artifacts
|
||||
- Know expected outputs
|
||||
- Guide toward workflow goals
|
||||
|
||||
This creates a seamless experience where the entire team works together toward the workflow's objectives.
|
||||
@@ -19,21 +19,21 @@ workflow:
|
||||
notes: "Review existing documentation, codebase structure, and identify integration points. Document current system understanding before proceeding."
|
||||
|
||||
- agent: pm
|
||||
creates: brownfield-prd.md
|
||||
creates: prd.md
|
||||
uses: brownfield-prd-tmpl
|
||||
requires: existing_project_analysis
|
||||
notes: "Creates comprehensive brownfield PRD with existing system analysis and enhancement planning. SAVE OUTPUT: Copy final brownfield-prd.md to your project's docs/ folder."
|
||||
notes: "Creates comprehensive PRD with existing system analysis and enhancement planning. SAVE OUTPUT: Copy final prd.md to your project's docs/ folder."
|
||||
|
||||
- agent: architect
|
||||
creates: brownfield-architecture.md
|
||||
creates: architecture.md
|
||||
uses: brownfield-architecture-tmpl
|
||||
requires: brownfield-prd.md
|
||||
notes: "Creates brownfield architecture with integration strategy and existing system constraints. SAVE OUTPUT: Copy final brownfield-architecture.md to your project's docs/ folder."
|
||||
requires: prd.md
|
||||
notes: "Creates architecture with integration strategy and existing system constraints. SAVE OUTPUT: Copy final architecture.md to your project's docs/ folder."
|
||||
|
||||
- agent: po
|
||||
validates: all_artifacts
|
||||
uses: po-master-checklist
|
||||
notes: "Validates all brownfield documents for integration safety and completeness. May require updates to any document."
|
||||
notes: "Validates all documents for integration safety and completeness. May require updates to any document."
|
||||
|
||||
- agent: various
|
||||
updates: any_flagged_documents
|
||||
@@ -83,8 +83,8 @@ workflow:
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Start: Brownfield Enhancement] --> B[analyst: analyze existing project]
|
||||
B --> C[pm: brownfield-prd.md]
|
||||
C --> D[architect: brownfield-architecture.md]
|
||||
B --> C[pm: prd.md]
|
||||
C --> D[architect: architecture.md]
|
||||
D --> E[po: validate with po-master-checklist]
|
||||
E --> F{PO finds issues?}
|
||||
F -->|Yes| G[Return to relevant agent for fixes]
|
||||
@@ -105,8 +105,8 @@ workflow:
|
||||
- Multiple team members will work on related changes
|
||||
|
||||
handoff_prompts:
|
||||
analyst_to_pm: "Existing project analysis complete. Create comprehensive brownfield PRD with integration strategy."
|
||||
pm_to_architect: "Brownfield PRD ready. Save it as docs/brownfield-prd.md, then create the integration architecture."
|
||||
architect_to_po: "Architecture complete. Save it as docs/brownfield-architecture.md. Please validate all artifacts for integration safety."
|
||||
analyst_to_pm: "Existing project analysis complete. Create comprehensive PRD with integration strategy."
|
||||
pm_to_architect: "PRD ready. Save it as docs/prd.md, then create the integration architecture."
|
||||
architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for integration safety."
|
||||
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
|
||||
complete: "All brownfield planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
|
||||
complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
|
||||
|
||||
@@ -20,21 +20,21 @@ workflow:
|
||||
notes: "Review existing service documentation, codebase, performance metrics, and identify integration dependencies."
|
||||
|
||||
- agent: pm
|
||||
creates: brownfield-prd.md
|
||||
creates: prd.md
|
||||
uses: brownfield-prd-tmpl
|
||||
requires: existing_service_analysis
|
||||
notes: "Creates comprehensive brownfield PRD focused on service enhancement with existing system analysis. SAVE OUTPUT: Copy final brownfield-prd.md to your project's docs/ folder."
|
||||
notes: "Creates comprehensive PRD focused on service enhancement with existing system analysis. SAVE OUTPUT: Copy final prd.md to your project's docs/ folder."
|
||||
|
||||
- agent: architect
|
||||
creates: brownfield-architecture.md
|
||||
creates: architecture.md
|
||||
uses: brownfield-architecture-tmpl
|
||||
requires: brownfield-prd.md
|
||||
notes: "Creates brownfield architecture with service integration strategy and API evolution planning. SAVE OUTPUT: Copy final brownfield-architecture.md to your project's docs/ folder."
|
||||
requires: prd.md
|
||||
notes: "Creates architecture with service integration strategy and API evolution planning. SAVE OUTPUT: Copy final architecture.md to your project's docs/ folder."
|
||||
|
||||
- agent: po
|
||||
validates: all_artifacts
|
||||
uses: po-master-checklist
|
||||
notes: "Validates all brownfield documents for service integration safety and API compatibility. May require updates to any document."
|
||||
notes: "Validates all documents for service integration safety and API compatibility. May require updates to any document."
|
||||
|
||||
- agent: various
|
||||
updates: any_flagged_documents
|
||||
@@ -84,8 +84,8 @@ workflow:
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Start: Service Enhancement] --> B[analyst: analyze existing service]
|
||||
B --> C[pm: brownfield-prd.md]
|
||||
C --> D[architect: brownfield-architecture.md]
|
||||
B --> C[pm: prd.md]
|
||||
C --> D[architect: architecture.md]
|
||||
D --> E[po: validate with po-master-checklist]
|
||||
E --> F{PO finds issues?}
|
||||
F -->|Yes| G[Return to relevant agent for fixes]
|
||||
@@ -106,8 +106,8 @@ workflow:
|
||||
- Multiple integration points affected
|
||||
|
||||
handoff_prompts:
|
||||
analyst_to_pm: "Service analysis complete. Create comprehensive brownfield PRD with service integration strategy."
|
||||
pm_to_architect: "Brownfield PRD ready. Save it as docs/brownfield-prd.md, then create the service architecture."
|
||||
architect_to_po: "Architecture complete. Save it as docs/brownfield-architecture.md. Please validate all artifacts for service integration safety."
|
||||
analyst_to_pm: "Service analysis complete. Create comprehensive PRD with service integration strategy."
|
||||
pm_to_architect: "PRD ready. Save it as docs/prd.md, then create the service architecture."
|
||||
architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for service integration safety."
|
||||
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
|
||||
complete: "All brownfield planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
|
||||
complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
|
||||
|
||||
@@ -19,29 +19,29 @@ workflow:
|
||||
notes: "Review existing frontend application, user feedback, analytics data, and identify improvement areas."
|
||||
|
||||
- agent: pm
|
||||
creates: brownfield-prd.md
|
||||
creates: prd.md
|
||||
uses: brownfield-prd-tmpl
|
||||
requires: existing_ui_analysis
|
||||
notes: "Creates comprehensive brownfield PRD focused on UI enhancement with existing system analysis. SAVE OUTPUT: Copy final brownfield-prd.md to your project's docs/ folder."
|
||||
notes: "Creates comprehensive PRD focused on UI enhancement with existing system analysis. SAVE OUTPUT: Copy final prd.md to your project's docs/ folder."
|
||||
|
||||
- agent: ux-expert
|
||||
creates: front-end-spec.md
|
||||
uses: front-end-spec-tmpl
|
||||
requires: brownfield-prd.md
|
||||
notes: "Creates UI/UX specification for brownfield enhancement that integrates with existing design patterns. SAVE OUTPUT: Copy final front-end-spec.md to your project's docs/ folder."
|
||||
requires: prd.md
|
||||
notes: "Creates UI/UX specification that integrates with existing design patterns. SAVE OUTPUT: Copy final front-end-spec.md to your project's docs/ folder."
|
||||
|
||||
- agent: architect
|
||||
creates: brownfield-architecture.md
|
||||
creates: architecture.md
|
||||
uses: brownfield-architecture-tmpl
|
||||
requires:
|
||||
- brownfield-prd.md
|
||||
- prd.md
|
||||
- front-end-spec.md
|
||||
notes: "Creates brownfield frontend architecture with component integration strategy and migration planning. SAVE OUTPUT: Copy final brownfield-architecture.md to your project's docs/ folder."
|
||||
notes: "Creates frontend architecture with component integration strategy and migration planning. SAVE OUTPUT: Copy final architecture.md to your project's docs/ folder."
|
||||
|
||||
- agent: po
|
||||
validates: all_artifacts
|
||||
uses: po-master-checklist
|
||||
notes: "Validates all brownfield documents for UI integration safety and design consistency. May require updates to any document."
|
||||
notes: "Validates all documents for UI integration safety and design consistency. May require updates to any document."
|
||||
|
||||
- agent: various
|
||||
updates: any_flagged_documents
|
||||
@@ -91,9 +91,9 @@ workflow:
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Start: UI Enhancement] --> B[analyst: analyze existing UI]
|
||||
B --> C[pm: brownfield-prd.md]
|
||||
B --> C[pm: prd.md]
|
||||
C --> D[ux-expert: front-end-spec.md]
|
||||
D --> E[architect: brownfield-architecture.md]
|
||||
D --> E[architect: architecture.md]
|
||||
E --> F[po: validate with po-master-checklist]
|
||||
F --> G{PO finds issues?}
|
||||
G -->|Yes| H[Return to relevant agent for fixes]
|
||||
@@ -115,9 +115,9 @@ workflow:
|
||||
- Multiple team members will work on related changes
|
||||
|
||||
handoff_prompts:
|
||||
analyst_to_pm: "UI analysis complete. Create comprehensive brownfield PRD with UI integration strategy."
|
||||
pm_to_ux: "Brownfield PRD ready. Save it as docs/brownfield-prd.md, then create the UI/UX specification."
|
||||
analyst_to_pm: "UI analysis complete. Create comprehensive PRD with UI integration strategy."
|
||||
pm_to_ux: "PRD ready. Save it as docs/prd.md, then create the UI/UX specification."
|
||||
ux_to_architect: "UI/UX spec complete. Save it as docs/front-end-spec.md, then create the frontend architecture."
|
||||
architect_to_po: "Architecture complete. Save it as docs/brownfield-architecture.md. Please validate all artifacts for UI integration safety."
|
||||
architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for UI integration safety."
|
||||
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
|
||||
complete: "All brownfield planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
|
||||
complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
|
||||
|
||||
@@ -31,9 +31,9 @@ Confirm with the user their preferred interaction style:
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Load specified template from `templates#*` or the `{root}/templates directory`
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
- Process template markup according to `utils#template-format` or `{root}/utils/template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
@@ -2,13 +2,9 @@
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -17,7 +13,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
69
common/utils/workflow-management.md
Normal file
69
common/utils/workflow-management.md
Normal file
@@ -0,0 +1,69 @@
|
||||
# Workflow Management
|
||||
|
||||
Enables BMAD orchestrator to manage and execute team workflows.
|
||||
|
||||
## Dynamic Workflow Loading
|
||||
|
||||
Read available workflows from current team configuration's `workflows` field. Each team bundle defines its own supported workflows.
|
||||
|
||||
**Key Commands**:
|
||||
|
||||
- `/workflows` - List workflows in current bundle or workflows folder
|
||||
- `/agent-list` - Show agents in current bundle
|
||||
|
||||
## Workflow Commands
|
||||
|
||||
### /workflows
|
||||
|
||||
Lists available workflows with titles and descriptions.
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
|
||||
Starts workflow and transitions to first agent.
|
||||
|
||||
### /workflow-status
|
||||
|
||||
Shows current progress, completed artifacts, and next steps.
|
||||
|
||||
### /workflow-resume
|
||||
|
||||
Resumes workflow from last position. User can provide completed artifacts.
|
||||
|
||||
### /workflow-next
|
||||
|
||||
Shows next recommended agent and action.
|
||||
|
||||
## Execution Flow
|
||||
|
||||
1. **Starting**: Load definition → Identify first stage → Transition to agent → Guide artifact creation
|
||||
|
||||
2. **Stage Transitions**: Mark complete → Check conditions → Load next agent → Pass artifacts
|
||||
|
||||
3. **Artifact Tracking**: Track status, creator, timestamps in workflow_state
|
||||
|
||||
4. **Interruption Handling**: Analyze provided artifacts → Determine position → Suggest next step
|
||||
|
||||
## Context Passing
|
||||
|
||||
When transitioning, pass:
|
||||
|
||||
- Previous artifacts
|
||||
- Current workflow stage
|
||||
- Expected outputs
|
||||
- Decisions/constraints
|
||||
|
||||
## Multi-Path Workflows
|
||||
|
||||
Handle conditional paths by asking clarifying questions when needed.
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. Show progress
|
||||
2. Explain transitions
|
||||
3. Preserve context
|
||||
4. Allow flexibility
|
||||
5. Track state
|
||||
|
||||
## Agent Integration
|
||||
|
||||
Agents should be workflow-aware: know active workflow, their role, access artifacts, understand expected outputs.
|
||||
417
dist/agents/analyst.txt
vendored
417
dist/agents/analyst.txt
vendored
@@ -54,7 +54,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
|
||||
@@ -82,6 +82,7 @@ commands:
|
||||
- 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:
|
||||
@@ -89,6 +90,7 @@ dependencies:
|
||||
- create-deep-research-prompt
|
||||
- create-doc
|
||||
- advanced-elicitation
|
||||
- document-project
|
||||
templates:
|
||||
- project-brief-tmpl
|
||||
- market-research-tmpl
|
||||
@@ -679,9 +681,9 @@ Confirm with the user their preferred interaction style:
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Load specified template from `templates#*` or the `{root}/templates directory`
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
- Process template markup according to `utils#template-format` or `{root}/utils/template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
@@ -817,6 +819,326 @@ Choose an action (0-9 - 9 to bypass - HELP for explanation of these options):
|
||||
[[LLM: Acknowledge the user's choice to finalize the current work, accept the AI's last output as is, or move on to the next step without selecting another action from this list. Prepare to proceed accordingly.]]
|
||||
==================== END: tasks#advanced-elicitation ====================
|
||||
|
||||
==================== START: tasks#document-project ====================
|
||||
# Document an Existing Project
|
||||
|
||||
## Purpose
|
||||
|
||||
Generate comprehensive documentation for existing projects optimized for AI development agents. This task creates structured reference materials that enable AI agents to understand project context, conventions, and patterns for effective contribution to any codebase.
|
||||
|
||||
## Task Instructions
|
||||
|
||||
### 1. Initial Project Analysis
|
||||
|
||||
[[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
|
||||
3. **Build System Analysis**: Find build scripts, CI/CD configurations, and development commands
|
||||
4. **Existing Documentation Review**: Check for README files, docs folders, and any existing documentation
|
||||
5. **Code Pattern Analysis**: Sample key files to understand coding patterns, naming conventions, and architectural approaches
|
||||
|
||||
Ask the user these elicitation questions to better understand their needs:
|
||||
|
||||
- What is the primary purpose of this project?
|
||||
- Are there any specific areas of the codebase that are particularly complex or important for agents to understand?
|
||||
- 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. Deep Codebase Analysis
|
||||
|
||||
[[LLM: Before generating documentation, conduct extensive analysis of the existing codebase:
|
||||
|
||||
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
|
||||
|
||||
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?"
|
||||
|
||||
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
|
||||
|
||||
**IF PRD PROVIDED**: Also analyze what would need to change for the enhancement]]
|
||||
|
||||
### 3. Core Documentation Generation
|
||||
|
||||
[[LLM: Generate a comprehensive BROWNFIELD architecture document that reflects the ACTUAL state of the codebase.
|
||||
|
||||
**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
|
||||
|
||||
**Document Structure**:
|
||||
|
||||
# [Project Name] Brownfield Architecture Document
|
||||
|
||||
## 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.
|
||||
|
||||
### Document Scope
|
||||
[If PRD provided: "Focused on areas relevant to: {enhancement description}"]
|
||||
[If no PRD: "Comprehensive documentation of entire system"]
|
||||
|
||||
### Change Log
|
||||
| Date | Version | Description | Author |
|
||||
|------|---------|-------------|--------|
|
||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||
|
||||
## Quick Reference - Key Files and Entry Points
|
||||
|
||||
### 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]
|
||||
|
||||
### If PRD Provided - Enhancement Impact Areas
|
||||
[Highlight which files/modules will be affected by the planned enhancement]
|
||||
|
||||
## High Level Architecture
|
||||
|
||||
### Technical Summary
|
||||
[Real assessment of architecture - mention if it's well-structured or has issues]
|
||||
|
||||
### 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...] |
|
||||
|
||||
### Repository Structure Reality Check
|
||||
- Type: [Monorepo/Polyrepo/Hybrid]
|
||||
- Package Manager: [npm/yarn/pnpm]
|
||||
- Notable: [Any unusual structure decisions]
|
||||
|
||||
## Source Tree and Module Organization
|
||||
|
||||
### 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
|
||||
```
|
||||
|
||||
### 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
|
||||
|
||||
- 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 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
|
||||
==================== END: tasks#document-project ====================
|
||||
|
||||
==================== START: templates#project-brief-tmpl ====================
|
||||
# Project Brief: {{Project Name}}
|
||||
|
||||
@@ -2013,10 +2335,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
|
||||
@@ -2120,25 +2448,70 @@ Each status change requires user verification and approval before proceeding.
|
||||
|
||||
#### Brownfield Enhancement (Existing Projects)
|
||||
|
||||
**Key Concept**: Brownfield development requires generating good documentation for agents to understand your existing project.
|
||||
**Key Concept**: Brownfield development requires comprehensive documentation of your existing project for AI agents to understand context, patterns, and constraints.
|
||||
|
||||
**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
|
||||
**Complete Brownfield Workflow Options**:
|
||||
|
||||
**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
|
||||
**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
|
||||
|
||||
**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`)
|
||||
**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
|
||||
|
||||
@@ -2281,7 +2654,7 @@ Expansion packs extend BMAD-METHOD beyond traditional software development into
|
||||
### Using Expansion Packs
|
||||
|
||||
1. **Browse Available Packs**: Check `expansion-packs/` directory
|
||||
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
|
||||
2. **Get Inspiration**: See `docs/expansion-packs.md` for detailed examples and ideas
|
||||
3. **Install via CLI**:
|
||||
```bash
|
||||
npx bmad-method install
|
||||
|
||||
606
dist/agents/architect.txt
vendored
606
dist/agents/architect.txt
vendored
@@ -136,9 +136,9 @@ Confirm with the user their preferred interaction style:
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Load specified template from `templates#*` or the `{root}/templates directory`
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
- Process template markup according to `utils#template-format` or `{root}/utils/template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
@@ -494,7 +494,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
|
||||
@@ -509,370 +541,266 @@ 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
|
||||
==================== END: tasks#document-project ====================
|
||||
|
||||
==================== START: tasks#execute-checklist ====================
|
||||
@@ -880,13 +808,9 @@ Present a summary of what was created and ask if any additional documentation wo
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -895,7 +819,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
988
dist/agents/bmad-master.txt
vendored
988
dist/agents/bmad-master.txt
vendored
File diff suppressed because it is too large
Load Diff
309
dist/agents/bmad-orchestrator.txt
vendored
309
dist/agents/bmad-orchestrator.txt
vendored
@@ -292,9 +292,9 @@ Confirm with the user their preferred interaction style:
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Load specified template from `templates#*` or the `{root}/templates directory`
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
- Process template markup according to `utils#template-format` or `{root}/utils/template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
@@ -811,10 +811,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
|
||||
@@ -918,25 +924,70 @@ Each status change requires user verification and approval before proceeding.
|
||||
|
||||
#### Brownfield Enhancement (Existing Projects)
|
||||
|
||||
**Key Concept**: Brownfield development requires generating good documentation for agents to understand your existing project.
|
||||
**Key Concept**: Brownfield development requires comprehensive documentation of your existing project for AI agents to understand context, patterns, and constraints.
|
||||
|
||||
**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
|
||||
**Complete Brownfield Workflow Options**:
|
||||
|
||||
**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
|
||||
**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
|
||||
|
||||
**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`)
|
||||
**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
|
||||
|
||||
@@ -1079,7 +1130,7 @@ Expansion packs extend BMAD-METHOD beyond traditional software development into
|
||||
### Using Expansion Packs
|
||||
|
||||
1. **Browse Available Packs**: Check `expansion-packs/` directory
|
||||
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
|
||||
2. **Get Inspiration**: See `docs/expansion-packs.md` for detailed examples and ideas
|
||||
3. **Install via CLI**:
|
||||
```bash
|
||||
npx bmad-method install
|
||||
@@ -1110,227 +1161,73 @@ Use the **expansion-creator** pack to build your own:
|
||||
==================== START: utils#workflow-management ====================
|
||||
# Workflow Management
|
||||
|
||||
This utility enables the BMAD orchestrator to manage and execute team workflows.
|
||||
Enables BMAD orchestrator to manage and execute team workflows.
|
||||
|
||||
## Important: Dynamic Workflow Loading
|
||||
## Dynamic Workflow Loading
|
||||
|
||||
The BMAD orchestrator MUST read the available workflows from the current team configuration's `workflows` field. Do not use hardcoded workflow lists. Each team bundle defines its own set of supported workflows based on the agents it includes.
|
||||
Read available workflows from current team configuration's `workflows` field. Each team bundle defines its own supported workflows.
|
||||
|
||||
**Critical Distinction**:
|
||||
**Key Commands**:
|
||||
|
||||
- When asked "what workflows are available?", show ONLY the workflows defined in the current team bundle's configuration
|
||||
- Use `/agent-list` to show agents in the current bundle
|
||||
- Use `/workflows` to show workflows in the current bundle, NOT any creation tasks
|
||||
|
||||
### Workflow Descriptions
|
||||
|
||||
When displaying workflows, use these descriptions based on the workflow ID:
|
||||
|
||||
- **greenfield-fullstack**: Build a new full-stack application from concept to development
|
||||
- **brownfield-fullstack**: Enhance an existing full-stack application with new features
|
||||
- **greenfield-service**: Build a new backend service or API from concept to development
|
||||
- **brownfield-service**: Enhance an existing backend service or API
|
||||
- **greenfield-ui**: Build a new frontend/UI application from concept to development
|
||||
- **brownfield-ui**: Enhance an existing frontend/UI application
|
||||
- `/workflows` - List workflows in current bundle or workflows folder
|
||||
- `/agent-list` - Show agents in current bundle
|
||||
|
||||
## Workflow Commands
|
||||
|
||||
### /workflows
|
||||
|
||||
Lists all available workflows for the current team. The available workflows are determined by the team configuration and may include workflows such as:
|
||||
|
||||
- greenfield-fullstack
|
||||
- brownfield-fullstack
|
||||
- greenfield-service
|
||||
- brownfield-service
|
||||
- greenfield-ui
|
||||
- brownfield-ui
|
||||
|
||||
The actual list depends on which team bundle is loaded. When responding to this command, display the workflows that are configured in the current team's `workflows` field.
|
||||
|
||||
Example response format:
|
||||
|
||||
```text
|
||||
Available workflows for [Team Name]:
|
||||
1. [workflow-id] - [Brief description based on workflow type]
|
||||
2. [workflow-id] - [Brief description based on workflow type]
|
||||
[... etc. ...]
|
||||
|
||||
Use /workflow-start {number or id} to begin a workflow.
|
||||
```
|
||||
Lists available workflows with titles and descriptions.
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
|
||||
Starts a specific workflow and transitions to the first agent.
|
||||
|
||||
Example: `/workflow-start greenfield-fullstack`
|
||||
Starts workflow and transitions to first agent.
|
||||
|
||||
### /workflow-status
|
||||
|
||||
Shows current workflow progress, completed artifacts, and next steps.
|
||||
|
||||
Example response:
|
||||
|
||||
```text
|
||||
Current Workflow: Greenfield Full-Stack Development
|
||||
Stage: Product Planning (2 of 6)
|
||||
Completed:
|
||||
✓ Discovery & Requirements
|
||||
- project-brief (completed by Mary)
|
||||
|
||||
In Progress:
|
||||
⚡ Product Planning
|
||||
- Create PRD (John) - awaiting input
|
||||
|
||||
Next: Technical Architecture
|
||||
```
|
||||
Shows current progress, completed artifacts, and next steps.
|
||||
|
||||
### /workflow-resume
|
||||
|
||||
Resumes a workflow from where it left off, useful when starting a new chat.
|
||||
|
||||
User can provide completed artifacts:
|
||||
|
||||
```text
|
||||
User: /workflow-resume greenfield-fullstack
|
||||
I have completed: project-brief, PRD
|
||||
BMad: I see you've completed Discovery and part of Product Planning.
|
||||
Based on the greenfield-fullstack workflow, the next step is:
|
||||
- UX Strategy with Sally (ux-expert)
|
||||
|
||||
Would you like me to load Sally to continue?
|
||||
```
|
||||
Resumes workflow from last position. User can provide completed artifacts.
|
||||
|
||||
### /workflow-next
|
||||
|
||||
Shows the next recommended agent and action in the current workflow.
|
||||
Shows next recommended agent and action.
|
||||
|
||||
## Workflow Execution Flow
|
||||
## Execution Flow
|
||||
|
||||
### 1. Starting a Workflow
|
||||
1. **Starting**: Load definition → Identify first stage → Transition to agent → Guide artifact creation
|
||||
|
||||
When a workflow is started:
|
||||
2. **Stage Transitions**: Mark complete → Check conditions → Load next agent → Pass artifacts
|
||||
|
||||
1. Load the workflow definition
|
||||
2. Identify the first stage and step
|
||||
3. Transition to the required agent
|
||||
4. Provide context about expected inputs/outputs
|
||||
5. Guide artifact creation
|
||||
3. **Artifact Tracking**: Track status, creator, timestamps in workflow_state
|
||||
|
||||
### 2. Stage Transitions
|
||||
4. **Interruption Handling**: Analyze provided artifacts → Determine position → Suggest next step
|
||||
|
||||
After each artifact is completed:
|
||||
## Context Passing
|
||||
|
||||
1. Mark the step as complete
|
||||
2. Check transition conditions
|
||||
3. If stage is complete, move to next stage
|
||||
4. Load the appropriate agent
|
||||
5. Pass relevant artifacts as context
|
||||
When transitioning, pass:
|
||||
|
||||
### 3. Artifact Tracking
|
||||
|
||||
Track all created artifacts:
|
||||
|
||||
```yaml
|
||||
workflow_state:
|
||||
current_workflow: greenfield-fullstack
|
||||
current_stage: planning
|
||||
current_step: 2
|
||||
artifacts:
|
||||
project-brief:
|
||||
status: completed
|
||||
created_by: analyst
|
||||
timestamp: 2024-01-15T10:30:00.000Z
|
||||
prd:
|
||||
status: in-progress
|
||||
created_by: pm
|
||||
started: 2024-01-15T11:00:00.000Z
|
||||
```
|
||||
|
||||
### 4. Workflow Interruption Handling
|
||||
|
||||
When user returns after interruption:
|
||||
|
||||
1. Ask if continuing previous workflow
|
||||
2. Request any completed artifacts
|
||||
3. Analyze provided artifacts
|
||||
4. Determine workflow position
|
||||
5. Suggest next appropriate step
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
User: I'm working on a new app. Here's my PRD and architecture doc.
|
||||
BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||
it looks like you're following the greenfield-fullstack workflow and have completed
|
||||
stages 1-3. The next recommended step would be:
|
||||
|
||||
Stage 4: Validation & Refinement
|
||||
- Load Sarah (Product Owner) to validate all artifacts
|
||||
|
||||
Would you like to continue with this workflow?
|
||||
```
|
||||
|
||||
## Workflow Context Passing
|
||||
|
||||
When transitioning between agents, pass:
|
||||
|
||||
1. Previous artifacts created
|
||||
2. Current workflow stage
|
||||
3. Expected outputs
|
||||
4. Any decisions or constraints identified
|
||||
|
||||
Example transition:
|
||||
|
||||
```text
|
||||
BMad: Great! John has completed the PRD. According to the greenfield-fullstack workflow,
|
||||
the next step is UX Strategy with Sally.
|
||||
|
||||
/ux-expert
|
||||
|
||||
Sally: I see we're in the Product Planning stage of the greenfield-fullstack workflow.
|
||||
I have access to:
|
||||
- Project Brief from Mary
|
||||
- PRD from John
|
||||
|
||||
Let's create the UX strategy and UI specifications. First, let me review
|
||||
the PRD to understand the features we're designing for...
|
||||
```
|
||||
- Previous artifacts
|
||||
- Current workflow stage
|
||||
- Expected outputs
|
||||
- Decisions/constraints
|
||||
|
||||
## Multi-Path Workflows
|
||||
|
||||
Some workflows may have multiple paths:
|
||||
Handle conditional paths by asking clarifying questions when needed.
|
||||
|
||||
```yaml
|
||||
conditional_paths:
|
||||
- condition: project_type == 'mobile'
|
||||
next_stage: mobile-specific-design
|
||||
- condition: project_type == 'web'
|
||||
next_stage: web-architecture
|
||||
- default: fullstack-architecture
|
||||
```
|
||||
## Best Practices
|
||||
|
||||
Handle these by asking clarifying questions when needed.
|
||||
1. Show progress
|
||||
2. Explain transitions
|
||||
3. Preserve context
|
||||
4. Allow flexibility
|
||||
5. Track state
|
||||
|
||||
## Workflow Best Practices
|
||||
## Agent Integration
|
||||
|
||||
1. **Always show progress** - Users should know where they are
|
||||
2. **Explain transitions** - Why moving to next agent
|
||||
3. **Preserve context** - Pass relevant information forward
|
||||
4. **Allow flexibility** - Users can skip or modify steps
|
||||
5. **Track everything** - Maintain complete workflow state
|
||||
|
||||
## Integration with Agents
|
||||
|
||||
Each agent should be workflow-aware:
|
||||
|
||||
- Know which workflow is active
|
||||
- Understand their role in the workflow
|
||||
- Access previous artifacts
|
||||
- Know expected outputs
|
||||
- Guide toward workflow goals
|
||||
|
||||
This creates a seamless experience where the entire team works together toward the workflow's objectives.
|
||||
Agents should be workflow-aware: know active workflow, their role, access artifacts, understand expected outputs.
|
||||
==================== END: utils#workflow-management ====================
|
||||
|
||||
==================== START: utils#template-format ====================
|
||||
|
||||
8
dist/agents/dev.txt
vendored
8
dist/agents/dev.txt
vendored
@@ -102,13 +102,9 @@ dependencies:
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -117,7 +113,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
12
dist/agents/pm.txt
vendored
12
dist/agents/pm.txt
vendored
@@ -133,9 +133,9 @@ Confirm with the user their preferred interaction style:
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Load specified template from `templates#*` or the `{root}/templates directory`
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
- Process template markup according to `utils#template-format` or `{root}/utils/template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
@@ -874,13 +874,9 @@ The story creation is successful when:
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -889,7 +885,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
8
dist/agents/po.txt
vendored
8
dist/agents/po.txt
vendored
@@ -106,13 +106,9 @@ dependencies:
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -121,7 +117,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
8
dist/agents/sm.txt
vendored
8
dist/agents/sm.txt
vendored
@@ -349,13 +349,9 @@ Provide a summary to the user including:
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -364,7 +360,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
12
dist/agents/ux-expert.txt
vendored
12
dist/agents/ux-expert.txt
vendored
@@ -493,9 +493,9 @@ Confirm with the user their preferred interaction style:
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Load specified template from `templates#*` or the `{root}/templates directory`
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
- Process template markup according to `utils#template-format` or `{root}/utils/template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
@@ -541,13 +541,9 @@ If template specifies a checklist:
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -556,7 +552,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
@@ -133,9 +133,9 @@ Confirm with the user their preferred interaction style:
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Load specified template from `templates#*` or the `{root}/templates directory`
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
- Process template markup according to `utils#template-format` or `{root}/utils/template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
@@ -181,13 +181,9 @@ If template specifies a checklist:
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -196,7 +192,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
@@ -112,13 +112,9 @@ dependencies:
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -127,7 +123,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
@@ -316,13 +316,9 @@ This task ensures game development stories are immediately actionable and enable
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -331,7 +327,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
@@ -70,7 +70,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
|
||||
@@ -98,6 +98,7 @@ commands:
|
||||
- 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:
|
||||
@@ -105,6 +106,7 @@ dependencies:
|
||||
- create-deep-research-prompt
|
||||
- create-doc
|
||||
- advanced-elicitation
|
||||
- document-project
|
||||
templates:
|
||||
- project-brief-tmpl
|
||||
- market-research-tmpl
|
||||
@@ -1004,9 +1006,9 @@ Confirm with the user their preferred interaction style:
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Load specified template from `templates#*` or the `{root}/templates directory`
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
- Process template markup according to `utils#template-format` or `{root}/utils/template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
@@ -1161,6 +1163,326 @@ The questions and perspectives offered should always consider:
|
||||
- Game development best practices and common pitfalls
|
||||
==================== END: tasks#advanced-elicitation ====================
|
||||
|
||||
==================== START: tasks#document-project ====================
|
||||
# Document an Existing Project
|
||||
|
||||
## Purpose
|
||||
|
||||
Generate comprehensive documentation for existing projects optimized for AI development agents. This task creates structured reference materials that enable AI agents to understand project context, conventions, and patterns for effective contribution to any codebase.
|
||||
|
||||
## Task Instructions
|
||||
|
||||
### 1. Initial Project Analysis
|
||||
|
||||
[[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
|
||||
3. **Build System Analysis**: Find build scripts, CI/CD configurations, and development commands
|
||||
4. **Existing Documentation Review**: Check for README files, docs folders, and any existing documentation
|
||||
5. **Code Pattern Analysis**: Sample key files to understand coding patterns, naming conventions, and architectural approaches
|
||||
|
||||
Ask the user these elicitation questions to better understand their needs:
|
||||
|
||||
- What is the primary purpose of this project?
|
||||
- Are there any specific areas of the codebase that are particularly complex or important for agents to understand?
|
||||
- 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. Deep Codebase Analysis
|
||||
|
||||
[[LLM: Before generating documentation, conduct extensive analysis of the existing codebase:
|
||||
|
||||
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
|
||||
|
||||
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?"
|
||||
|
||||
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
|
||||
|
||||
**IF PRD PROVIDED**: Also analyze what would need to change for the enhancement]]
|
||||
|
||||
### 3. Core Documentation Generation
|
||||
|
||||
[[LLM: Generate a comprehensive BROWNFIELD architecture document that reflects the ACTUAL state of the codebase.
|
||||
|
||||
**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
|
||||
|
||||
**Document Structure**:
|
||||
|
||||
# [Project Name] Brownfield Architecture Document
|
||||
|
||||
## 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.
|
||||
|
||||
### Document Scope
|
||||
[If PRD provided: "Focused on areas relevant to: {enhancement description}"]
|
||||
[If no PRD: "Comprehensive documentation of entire system"]
|
||||
|
||||
### Change Log
|
||||
| Date | Version | Description | Author |
|
||||
|------|---------|-------------|--------|
|
||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||
|
||||
## Quick Reference - Key Files and Entry Points
|
||||
|
||||
### 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]
|
||||
|
||||
### If PRD Provided - Enhancement Impact Areas
|
||||
[Highlight which files/modules will be affected by the planned enhancement]
|
||||
|
||||
## High Level Architecture
|
||||
|
||||
### Technical Summary
|
||||
[Real assessment of architecture - mention if it's well-structured or has issues]
|
||||
|
||||
### 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...] |
|
||||
|
||||
### Repository Structure Reality Check
|
||||
- Type: [Monorepo/Polyrepo/Hybrid]
|
||||
- Package Manager: [npm/yarn/pnpm]
|
||||
- Notable: [Any unusual structure decisions]
|
||||
|
||||
## Source Tree and Module Organization
|
||||
|
||||
### 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
|
||||
```
|
||||
|
||||
### 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
|
||||
|
||||
- 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 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
|
||||
==================== END: tasks#document-project ====================
|
||||
|
||||
==================== START: templates#project-brief-tmpl ====================
|
||||
# Project Brief: {{Project Name}}
|
||||
|
||||
@@ -2316,227 +2638,73 @@ Or ask me about anything else related to BMAD-METHOD!
|
||||
==================== START: utils#workflow-management ====================
|
||||
# Workflow Management
|
||||
|
||||
This utility enables the BMAD orchestrator to manage and execute team workflows.
|
||||
Enables BMAD orchestrator to manage and execute team workflows.
|
||||
|
||||
## Important: Dynamic Workflow Loading
|
||||
## Dynamic Workflow Loading
|
||||
|
||||
The BMAD orchestrator MUST read the available workflows from the current team configuration's `workflows` field. Do not use hardcoded workflow lists. Each team bundle defines its own set of supported workflows based on the agents it includes.
|
||||
Read available workflows from current team configuration's `workflows` field. Each team bundle defines its own supported workflows.
|
||||
|
||||
**Critical Distinction**:
|
||||
**Key Commands**:
|
||||
|
||||
- When asked "what workflows are available?", show ONLY the workflows defined in the current team bundle's configuration
|
||||
- Use `/agent-list` to show agents in the current bundle
|
||||
- Use `/workflows` to show workflows in the current bundle, NOT any creation tasks
|
||||
|
||||
### Workflow Descriptions
|
||||
|
||||
When displaying workflows, use these descriptions based on the workflow ID:
|
||||
|
||||
- **greenfield-fullstack**: Build a new full-stack application from concept to development
|
||||
- **brownfield-fullstack**: Enhance an existing full-stack application with new features
|
||||
- **greenfield-service**: Build a new backend service or API from concept to development
|
||||
- **brownfield-service**: Enhance an existing backend service or API
|
||||
- **greenfield-ui**: Build a new frontend/UI application from concept to development
|
||||
- **brownfield-ui**: Enhance an existing frontend/UI application
|
||||
- `/workflows` - List workflows in current bundle or workflows folder
|
||||
- `/agent-list` - Show agents in current bundle
|
||||
|
||||
## Workflow Commands
|
||||
|
||||
### /workflows
|
||||
|
||||
Lists all available workflows for the current team. The available workflows are determined by the team configuration and may include workflows such as:
|
||||
|
||||
- greenfield-fullstack
|
||||
- brownfield-fullstack
|
||||
- greenfield-service
|
||||
- brownfield-service
|
||||
- greenfield-ui
|
||||
- brownfield-ui
|
||||
|
||||
The actual list depends on which team bundle is loaded. When responding to this command, display the workflows that are configured in the current team's `workflows` field.
|
||||
|
||||
Example response format:
|
||||
|
||||
```text
|
||||
Available workflows for [Team Name]:
|
||||
1. [workflow-id] - [Brief description based on workflow type]
|
||||
2. [workflow-id] - [Brief description based on workflow type]
|
||||
[... etc. ...]
|
||||
|
||||
Use /workflow-start {number or id} to begin a workflow.
|
||||
```
|
||||
Lists available workflows with titles and descriptions.
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
|
||||
Starts a specific workflow and transitions to the first agent.
|
||||
|
||||
Example: `/workflow-start greenfield-fullstack`
|
||||
Starts workflow and transitions to first agent.
|
||||
|
||||
### /workflow-status
|
||||
|
||||
Shows current workflow progress, completed artifacts, and next steps.
|
||||
|
||||
Example response:
|
||||
|
||||
```text
|
||||
Current Workflow: Greenfield Full-Stack Development
|
||||
Stage: Product Planning (2 of 6)
|
||||
Completed:
|
||||
✓ Discovery & Requirements
|
||||
- project-brief (completed by Mary)
|
||||
|
||||
In Progress:
|
||||
⚡ Product Planning
|
||||
- Create PRD (John) - awaiting input
|
||||
|
||||
Next: Technical Architecture
|
||||
```
|
||||
Shows current progress, completed artifacts, and next steps.
|
||||
|
||||
### /workflow-resume
|
||||
|
||||
Resumes a workflow from where it left off, useful when starting a new chat.
|
||||
|
||||
User can provide completed artifacts:
|
||||
|
||||
```text
|
||||
User: /workflow-resume greenfield-fullstack
|
||||
I have completed: project-brief, PRD
|
||||
BMad: I see you've completed Discovery and part of Product Planning.
|
||||
Based on the greenfield-fullstack workflow, the next step is:
|
||||
- UX Strategy with Sally (ux-expert)
|
||||
|
||||
Would you like me to load Sally to continue?
|
||||
```
|
||||
Resumes workflow from last position. User can provide completed artifacts.
|
||||
|
||||
### /workflow-next
|
||||
|
||||
Shows the next recommended agent and action in the current workflow.
|
||||
Shows next recommended agent and action.
|
||||
|
||||
## Workflow Execution Flow
|
||||
## Execution Flow
|
||||
|
||||
### 1. Starting a Workflow
|
||||
1. **Starting**: Load definition → Identify first stage → Transition to agent → Guide artifact creation
|
||||
|
||||
When a workflow is started:
|
||||
2. **Stage Transitions**: Mark complete → Check conditions → Load next agent → Pass artifacts
|
||||
|
||||
1. Load the workflow definition
|
||||
2. Identify the first stage and step
|
||||
3. Transition to the required agent
|
||||
4. Provide context about expected inputs/outputs
|
||||
5. Guide artifact creation
|
||||
3. **Artifact Tracking**: Track status, creator, timestamps in workflow_state
|
||||
|
||||
### 2. Stage Transitions
|
||||
4. **Interruption Handling**: Analyze provided artifacts → Determine position → Suggest next step
|
||||
|
||||
After each artifact is completed:
|
||||
## Context Passing
|
||||
|
||||
1. Mark the step as complete
|
||||
2. Check transition conditions
|
||||
3. If stage is complete, move to next stage
|
||||
4. Load the appropriate agent
|
||||
5. Pass relevant artifacts as context
|
||||
When transitioning, pass:
|
||||
|
||||
### 3. Artifact Tracking
|
||||
|
||||
Track all created artifacts:
|
||||
|
||||
```yaml
|
||||
workflow_state:
|
||||
current_workflow: greenfield-fullstack
|
||||
current_stage: planning
|
||||
current_step: 2
|
||||
artifacts:
|
||||
project-brief:
|
||||
status: completed
|
||||
created_by: analyst
|
||||
timestamp: 2024-01-15T10:30:00.000Z
|
||||
prd:
|
||||
status: in-progress
|
||||
created_by: pm
|
||||
started: 2024-01-15T11:00:00.000Z
|
||||
```
|
||||
|
||||
### 4. Workflow Interruption Handling
|
||||
|
||||
When user returns after interruption:
|
||||
|
||||
1. Ask if continuing previous workflow
|
||||
2. Request any completed artifacts
|
||||
3. Analyze provided artifacts
|
||||
4. Determine workflow position
|
||||
5. Suggest next appropriate step
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
User: I'm working on a new app. Here's my PRD and architecture doc.
|
||||
BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||
it looks like you're following the greenfield-fullstack workflow and have completed
|
||||
stages 1-3. The next recommended step would be:
|
||||
|
||||
Stage 4: Validation & Refinement
|
||||
- Load Sarah (Product Owner) to validate all artifacts
|
||||
|
||||
Would you like to continue with this workflow?
|
||||
```
|
||||
|
||||
## Workflow Context Passing
|
||||
|
||||
When transitioning between agents, pass:
|
||||
|
||||
1. Previous artifacts created
|
||||
2. Current workflow stage
|
||||
3. Expected outputs
|
||||
4. Any decisions or constraints identified
|
||||
|
||||
Example transition:
|
||||
|
||||
```text
|
||||
BMad: Great! John has completed the PRD. According to the greenfield-fullstack workflow,
|
||||
the next step is UX Strategy with Sally.
|
||||
|
||||
/ux-expert
|
||||
|
||||
Sally: I see we're in the Product Planning stage of the greenfield-fullstack workflow.
|
||||
I have access to:
|
||||
- Project Brief from Mary
|
||||
- PRD from John
|
||||
|
||||
Let's create the UX strategy and UI specifications. First, let me review
|
||||
the PRD to understand the features we're designing for...
|
||||
```
|
||||
- Previous artifacts
|
||||
- Current workflow stage
|
||||
- Expected outputs
|
||||
- Decisions/constraints
|
||||
|
||||
## Multi-Path Workflows
|
||||
|
||||
Some workflows may have multiple paths:
|
||||
Handle conditional paths by asking clarifying questions when needed.
|
||||
|
||||
```yaml
|
||||
conditional_paths:
|
||||
- condition: project_type == 'mobile'
|
||||
next_stage: mobile-specific-design
|
||||
- condition: project_type == 'web'
|
||||
next_stage: web-architecture
|
||||
- default: fullstack-architecture
|
||||
```
|
||||
## Best Practices
|
||||
|
||||
Handle these by asking clarifying questions when needed.
|
||||
1. Show progress
|
||||
2. Explain transitions
|
||||
3. Preserve context
|
||||
4. Allow flexibility
|
||||
5. Track state
|
||||
|
||||
## Workflow Best Practices
|
||||
## Agent Integration
|
||||
|
||||
1. **Always show progress** - Users should know where they are
|
||||
2. **Explain transitions** - Why moving to next agent
|
||||
3. **Preserve context** - Pass relevant information forward
|
||||
4. **Allow flexibility** - Users can skip or modify steps
|
||||
5. **Track everything** - Maintain complete workflow state
|
||||
|
||||
## Integration with Agents
|
||||
|
||||
Each agent should be workflow-aware:
|
||||
|
||||
- Know which workflow is active
|
||||
- Understand their role in the workflow
|
||||
- Access previous artifacts
|
||||
- Know expected outputs
|
||||
- Guide toward workflow goals
|
||||
|
||||
This creates a seamless experience where the entire team works together toward the workflow's objectives.
|
||||
Agents should be workflow-aware: know active workflow, their role, access artifacts, understand expected outputs.
|
||||
==================== END: utils#workflow-management ====================
|
||||
|
||||
==================== START: tasks#execute-checklist ====================
|
||||
@@ -2544,13 +2712,9 @@ This creates a seamless experience where the entire team works together toward t
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -2559,7 +2723,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
@@ -736,17 +736,17 @@ IMPORTANT: Work through plan.md checklist systematically!
|
||||
|
||||
**Step 2: Copy Core Utilities**
|
||||
|
||||
Before proceeding, copy these essential files from bmad-core:
|
||||
Before proceeding, copy these essential files from common:
|
||||
|
||||
```bash
|
||||
# Copy core task utilities
|
||||
cp bmad-core/tasks/create-doc.md expansion-packs/{pack-name}/tasks/
|
||||
cp bmad-core/tasks/execute-checklist.md expansion-packs/{pack-name}/tasks/
|
||||
cp common/tasks/create-doc.md expansion-packs/{pack-name}/tasks/
|
||||
cp common/tasks/execute-checklist.md expansion-packs/{pack-name}/tasks/
|
||||
|
||||
# Copy core utility files
|
||||
mkdir -p expansion-packs/{pack-name}/utils
|
||||
cp bmad-core/utils/template-format.md expansion-packs/{pack-name}/utils/
|
||||
cp bmad-core/utils/workflow-management.md expansion-packs/{pack-name}/utils/
|
||||
cp common/utils/template-format.md expansion-packs/{pack-name}/utils/
|
||||
cp common/utils/workflow-management.md expansion-packs/{pack-name}/utils/
|
||||
```
|
||||
|
||||
**Step 3: Technical Implementation**
|
||||
@@ -134,9 +134,9 @@ Confirm with the user their preferred interaction style:
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Load specified template from `templates#*` or the `{root}/templates directory`
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
- Process template markup according to `utils#template-format` or `{root}/utils/template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
|
||||
1109
dist/teams/team-all.txt
vendored
1109
dist/teams/team-all.txt
vendored
File diff suppressed because it is too large
Load Diff
1109
dist/teams/team-fullstack.txt
vendored
1109
dist/teams/team-fullstack.txt
vendored
File diff suppressed because it is too large
Load Diff
317
dist/teams/team-ide-minimal.txt
vendored
317
dist/teams/team-ide-minimal.txt
vendored
@@ -528,9 +528,9 @@ Confirm with the user their preferred interaction style:
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Load specified template from `templates#*` or the `{root}/templates directory`
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
- Process template markup according to `utils#template-format` or `{root}/utils/template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
@@ -1047,10 +1047,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
|
||||
@@ -1154,25 +1160,70 @@ Each status change requires user verification and approval before proceeding.
|
||||
|
||||
#### Brownfield Enhancement (Existing Projects)
|
||||
|
||||
**Key Concept**: Brownfield development requires generating good documentation for agents to understand your existing project.
|
||||
**Key Concept**: Brownfield development requires comprehensive documentation of your existing project for AI agents to understand context, patterns, and constraints.
|
||||
|
||||
**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
|
||||
**Complete Brownfield Workflow Options**:
|
||||
|
||||
**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
|
||||
**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
|
||||
|
||||
**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`)
|
||||
**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
|
||||
|
||||
@@ -1315,7 +1366,7 @@ Expansion packs extend BMAD-METHOD beyond traditional software development into
|
||||
### Using Expansion Packs
|
||||
|
||||
1. **Browse Available Packs**: Check `expansion-packs/` directory
|
||||
2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
|
||||
2. **Get Inspiration**: See `docs/expansion-packs.md` for detailed examples and ideas
|
||||
3. **Install via CLI**:
|
||||
```bash
|
||||
npx bmad-method install
|
||||
@@ -1346,227 +1397,73 @@ Use the **expansion-creator** pack to build your own:
|
||||
==================== START: utils#workflow-management ====================
|
||||
# Workflow Management
|
||||
|
||||
This utility enables the BMAD orchestrator to manage and execute team workflows.
|
||||
Enables BMAD orchestrator to manage and execute team workflows.
|
||||
|
||||
## Important: Dynamic Workflow Loading
|
||||
## Dynamic Workflow Loading
|
||||
|
||||
The BMAD orchestrator MUST read the available workflows from the current team configuration's `workflows` field. Do not use hardcoded workflow lists. Each team bundle defines its own set of supported workflows based on the agents it includes.
|
||||
Read available workflows from current team configuration's `workflows` field. Each team bundle defines its own supported workflows.
|
||||
|
||||
**Critical Distinction**:
|
||||
**Key Commands**:
|
||||
|
||||
- When asked "what workflows are available?", show ONLY the workflows defined in the current team bundle's configuration
|
||||
- Use `/agent-list` to show agents in the current bundle
|
||||
- Use `/workflows` to show workflows in the current bundle, NOT any creation tasks
|
||||
|
||||
### Workflow Descriptions
|
||||
|
||||
When displaying workflows, use these descriptions based on the workflow ID:
|
||||
|
||||
- **greenfield-fullstack**: Build a new full-stack application from concept to development
|
||||
- **brownfield-fullstack**: Enhance an existing full-stack application with new features
|
||||
- **greenfield-service**: Build a new backend service or API from concept to development
|
||||
- **brownfield-service**: Enhance an existing backend service or API
|
||||
- **greenfield-ui**: Build a new frontend/UI application from concept to development
|
||||
- **brownfield-ui**: Enhance an existing frontend/UI application
|
||||
- `/workflows` - List workflows in current bundle or workflows folder
|
||||
- `/agent-list` - Show agents in current bundle
|
||||
|
||||
## Workflow Commands
|
||||
|
||||
### /workflows
|
||||
|
||||
Lists all available workflows for the current team. The available workflows are determined by the team configuration and may include workflows such as:
|
||||
|
||||
- greenfield-fullstack
|
||||
- brownfield-fullstack
|
||||
- greenfield-service
|
||||
- brownfield-service
|
||||
- greenfield-ui
|
||||
- brownfield-ui
|
||||
|
||||
The actual list depends on which team bundle is loaded. When responding to this command, display the workflows that are configured in the current team's `workflows` field.
|
||||
|
||||
Example response format:
|
||||
|
||||
```text
|
||||
Available workflows for [Team Name]:
|
||||
1. [workflow-id] - [Brief description based on workflow type]
|
||||
2. [workflow-id] - [Brief description based on workflow type]
|
||||
[... etc. ...]
|
||||
|
||||
Use /workflow-start {number or id} to begin a workflow.
|
||||
```
|
||||
Lists available workflows with titles and descriptions.
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
|
||||
Starts a specific workflow and transitions to the first agent.
|
||||
|
||||
Example: `/workflow-start greenfield-fullstack`
|
||||
Starts workflow and transitions to first agent.
|
||||
|
||||
### /workflow-status
|
||||
|
||||
Shows current workflow progress, completed artifacts, and next steps.
|
||||
|
||||
Example response:
|
||||
|
||||
```text
|
||||
Current Workflow: Greenfield Full-Stack Development
|
||||
Stage: Product Planning (2 of 6)
|
||||
Completed:
|
||||
✓ Discovery & Requirements
|
||||
- project-brief (completed by Mary)
|
||||
|
||||
In Progress:
|
||||
⚡ Product Planning
|
||||
- Create PRD (John) - awaiting input
|
||||
|
||||
Next: Technical Architecture
|
||||
```
|
||||
Shows current progress, completed artifacts, and next steps.
|
||||
|
||||
### /workflow-resume
|
||||
|
||||
Resumes a workflow from where it left off, useful when starting a new chat.
|
||||
|
||||
User can provide completed artifacts:
|
||||
|
||||
```text
|
||||
User: /workflow-resume greenfield-fullstack
|
||||
I have completed: project-brief, PRD
|
||||
BMad: I see you've completed Discovery and part of Product Planning.
|
||||
Based on the greenfield-fullstack workflow, the next step is:
|
||||
- UX Strategy with Sally (ux-expert)
|
||||
|
||||
Would you like me to load Sally to continue?
|
||||
```
|
||||
Resumes workflow from last position. User can provide completed artifacts.
|
||||
|
||||
### /workflow-next
|
||||
|
||||
Shows the next recommended agent and action in the current workflow.
|
||||
Shows next recommended agent and action.
|
||||
|
||||
## Workflow Execution Flow
|
||||
## Execution Flow
|
||||
|
||||
### 1. Starting a Workflow
|
||||
1. **Starting**: Load definition → Identify first stage → Transition to agent → Guide artifact creation
|
||||
|
||||
When a workflow is started:
|
||||
2. **Stage Transitions**: Mark complete → Check conditions → Load next agent → Pass artifacts
|
||||
|
||||
1. Load the workflow definition
|
||||
2. Identify the first stage and step
|
||||
3. Transition to the required agent
|
||||
4. Provide context about expected inputs/outputs
|
||||
5. Guide artifact creation
|
||||
3. **Artifact Tracking**: Track status, creator, timestamps in workflow_state
|
||||
|
||||
### 2. Stage Transitions
|
||||
4. **Interruption Handling**: Analyze provided artifacts → Determine position → Suggest next step
|
||||
|
||||
After each artifact is completed:
|
||||
## Context Passing
|
||||
|
||||
1. Mark the step as complete
|
||||
2. Check transition conditions
|
||||
3. If stage is complete, move to next stage
|
||||
4. Load the appropriate agent
|
||||
5. Pass relevant artifacts as context
|
||||
When transitioning, pass:
|
||||
|
||||
### 3. Artifact Tracking
|
||||
|
||||
Track all created artifacts:
|
||||
|
||||
```yaml
|
||||
workflow_state:
|
||||
current_workflow: greenfield-fullstack
|
||||
current_stage: planning
|
||||
current_step: 2
|
||||
artifacts:
|
||||
project-brief:
|
||||
status: completed
|
||||
created_by: analyst
|
||||
timestamp: 2024-01-15T10:30:00.000Z
|
||||
prd:
|
||||
status: in-progress
|
||||
created_by: pm
|
||||
started: 2024-01-15T11:00:00.000Z
|
||||
```
|
||||
|
||||
### 4. Workflow Interruption Handling
|
||||
|
||||
When user returns after interruption:
|
||||
|
||||
1. Ask if continuing previous workflow
|
||||
2. Request any completed artifacts
|
||||
3. Analyze provided artifacts
|
||||
4. Determine workflow position
|
||||
5. Suggest next appropriate step
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
User: I'm working on a new app. Here's my PRD and architecture doc.
|
||||
BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||
it looks like you're following the greenfield-fullstack workflow and have completed
|
||||
stages 1-3. The next recommended step would be:
|
||||
|
||||
Stage 4: Validation & Refinement
|
||||
- Load Sarah (Product Owner) to validate all artifacts
|
||||
|
||||
Would you like to continue with this workflow?
|
||||
```
|
||||
|
||||
## Workflow Context Passing
|
||||
|
||||
When transitioning between agents, pass:
|
||||
|
||||
1. Previous artifacts created
|
||||
2. Current workflow stage
|
||||
3. Expected outputs
|
||||
4. Any decisions or constraints identified
|
||||
|
||||
Example transition:
|
||||
|
||||
```text
|
||||
BMad: Great! John has completed the PRD. According to the greenfield-fullstack workflow,
|
||||
the next step is UX Strategy with Sally.
|
||||
|
||||
/ux-expert
|
||||
|
||||
Sally: I see we're in the Product Planning stage of the greenfield-fullstack workflow.
|
||||
I have access to:
|
||||
- Project Brief from Mary
|
||||
- PRD from John
|
||||
|
||||
Let's create the UX strategy and UI specifications. First, let me review
|
||||
the PRD to understand the features we're designing for...
|
||||
```
|
||||
- Previous artifacts
|
||||
- Current workflow stage
|
||||
- Expected outputs
|
||||
- Decisions/constraints
|
||||
|
||||
## Multi-Path Workflows
|
||||
|
||||
Some workflows may have multiple paths:
|
||||
Handle conditional paths by asking clarifying questions when needed.
|
||||
|
||||
```yaml
|
||||
conditional_paths:
|
||||
- condition: project_type == 'mobile'
|
||||
next_stage: mobile-specific-design
|
||||
- condition: project_type == 'web'
|
||||
next_stage: web-architecture
|
||||
- default: fullstack-architecture
|
||||
```
|
||||
## Best Practices
|
||||
|
||||
Handle these by asking clarifying questions when needed.
|
||||
1. Show progress
|
||||
2. Explain transitions
|
||||
3. Preserve context
|
||||
4. Allow flexibility
|
||||
5. Track state
|
||||
|
||||
## Workflow Best Practices
|
||||
## Agent Integration
|
||||
|
||||
1. **Always show progress** - Users should know where they are
|
||||
2. **Explain transitions** - Why moving to next agent
|
||||
3. **Preserve context** - Pass relevant information forward
|
||||
4. **Allow flexibility** - Users can skip or modify steps
|
||||
5. **Track everything** - Maintain complete workflow state
|
||||
|
||||
## Integration with Agents
|
||||
|
||||
Each agent should be workflow-aware:
|
||||
|
||||
- Know which workflow is active
|
||||
- Understand their role in the workflow
|
||||
- Access previous artifacts
|
||||
- Know expected outputs
|
||||
- Guide toward workflow goals
|
||||
|
||||
This creates a seamless experience where the entire team works together toward the workflow's objectives.
|
||||
Agents should be workflow-aware: know active workflow, their role, access artifacts, understand expected outputs.
|
||||
==================== END: utils#workflow-management ====================
|
||||
|
||||
==================== START: utils#template-format ====================
|
||||
@@ -1603,13 +1500,9 @@ Templates in the BMAD method use standardized markup for AI processing. These co
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Context
|
||||
|
||||
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -1618,7 +1511,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from bmad-core/checklists/
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
|
||||
1057
dist/teams/team-no-ui.txt
vendored
1057
dist/teams/team-no-ui.txt
vendored
File diff suppressed because it is too large
Load Diff
36
docs/agentic-tools/claude-code-guide.md
Normal file
36
docs/agentic-tools/claude-code-guide.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# BMAD Method Guide for Claude Code
|
||||
|
||||
This guide covers Claude Code-specific setup and usage with BMAD Method. For the complete workflow, see the [BMAD Workflow Guide](../bmad-workflow-guide.md).
|
||||
|
||||
## Installation
|
||||
|
||||
When running `npx bmad-method install`, select **Claude Code** as your IDE. This creates:
|
||||
|
||||
- `.bmad-core/` folder with all agents
|
||||
- `.claude/commands/` folder with agent command files (`.md`)
|
||||
|
||||
## Using BMAD Agents in Claude Code
|
||||
|
||||
Type `/agent-name` in your chat to activate an agent:
|
||||
|
||||
- `/bmad-master` - Universal task executor
|
||||
- `/sm` - Scrum Master
|
||||
- `/dev` - Full-stack developer
|
||||
- `/architect` - Solution architect
|
||||
- `/pm` - Product manager
|
||||
- `/analyst` - Business analyst
|
||||
- `/qa` - QA specialist
|
||||
- `/po` - Product owner
|
||||
- `/ux-expert` - UX specialist
|
||||
|
||||
## Claude Code-Specific Features
|
||||
|
||||
- **Command files**: Stored in `.claude/commands/` as `.md` files
|
||||
- **Activation**: Use forward slash `/` prefix for all agents
|
||||
- **Chat management**: Start new chats when switching agents for clean context
|
||||
|
||||
## Tips for Claude Code Users
|
||||
|
||||
- Commands are auto-suggested as you type `/`
|
||||
- Each agent supports `*help` to see available commands
|
||||
- Claude Code maintains excellent context within each chat
|
||||
42
docs/agentic-tools/cline-guide.md
Normal file
42
docs/agentic-tools/cline-guide.md
Normal file
@@ -0,0 +1,42 @@
|
||||
# BMAD Method Guide for Cline (VS Code)
|
||||
|
||||
This guide covers Cline-specific setup and usage with BMAD Method. For the complete workflow, see the [BMAD Workflow Guide](../bmad-workflow-guide.md).
|
||||
|
||||
## Installation
|
||||
|
||||
When running `npx bmad-method install`, select **Cline** as your IDE. This creates:
|
||||
|
||||
- `.clinerules/` directory with numbered agent rule files (`.md`)
|
||||
- Agents ordered by priority (bmad-master first)
|
||||
|
||||
## Using BMAD Agents in Cline
|
||||
|
||||
1. **Open Cline panel** in VS Code
|
||||
2. **Type `@agent-name`** in the chat (e.g., `@dev`, `@sm`, `@architect`)
|
||||
3. The agent adopts that persona for the conversation
|
||||
|
||||
## Available Agents
|
||||
|
||||
All agents use `@` prefix:
|
||||
|
||||
- `@bmad-master` - Universal task executor
|
||||
- `@sm` - Scrum Master
|
||||
- `@dev` - Full-stack developer
|
||||
- `@architect` - Solution architect
|
||||
- `@pm` - Product manager
|
||||
- `@analyst` - Business analyst
|
||||
- `@qa` - QA specialist
|
||||
- `@po` - Product owner
|
||||
- `@ux-expert` - UX specialist
|
||||
|
||||
## Cline-Specific Features
|
||||
|
||||
- **Rule files**: Stored as numbered files in `.clinerules/` (e.g., `01-bmad-master.md`)
|
||||
- **Agent ordering**: Prioritized list with core agents first
|
||||
- **VS Code integration**: Works within VS Code's Cline extension panel
|
||||
|
||||
## Tips for Cline Users
|
||||
|
||||
- Cline maintains conversation context well
|
||||
- Use `@agent-name` at the start of your message for best results
|
||||
- Agent rules are loaded automatically when mentioned
|
||||
37
docs/agentic-tools/cursor-guide.md
Normal file
37
docs/agentic-tools/cursor-guide.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# BMAD Method Guide for Cursor
|
||||
|
||||
This guide covers Cursor-specific setup and usage with BMAD Method. For the complete workflow, see the [BMAD Workflow Guide](../bmad-workflow-guide.md).
|
||||
|
||||
## Installation
|
||||
|
||||
When running `npx bmad-method install`, select **Cursor** as your IDE. This creates:
|
||||
|
||||
- `.bmad-core/` folder with all agents
|
||||
- `.cursor/rules/` folder with agent rule files (`.mdc`)
|
||||
|
||||
## Using BMAD Agents in Cursor
|
||||
|
||||
Type `@agent-name` in chat (Ctrl+L / Cmd+L) to activate an agent:
|
||||
|
||||
- `@bmad-master` - Universal task executor
|
||||
- `@sm` - Scrum Master
|
||||
- `@dev` - Full-stack developer
|
||||
- `@architect` - Solution architect
|
||||
- `@pm` - Product manager
|
||||
- `@analyst` - Business analyst
|
||||
- `@qa` - QA specialist
|
||||
- `@po` - Product owner
|
||||
- `@ux-expert` - UX specialist
|
||||
|
||||
## Cursor-Specific Features
|
||||
|
||||
- **Rule files**: Stored in `.cursor/rules/` as `.mdc` files
|
||||
- **Auto-completion**: Cursor suggests agents as you type `@`
|
||||
- **Context awareness**: Agents can see your current file selection
|
||||
- **Custom agents**: For better performance, copy agent content into Cursor's custom modes
|
||||
|
||||
## Tips for Cursor Users
|
||||
|
||||
- Start new chats when switching agents
|
||||
- Each agent supports `*help` to see available commands
|
||||
- Leverage Cursor's file context for more accurate assistance
|
||||
46
docs/agentic-tools/gemini-cli-guide.md
Normal file
46
docs/agentic-tools/gemini-cli-guide.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# BMAD Method Guide for Gemini CLI
|
||||
|
||||
This guide covers Gemini CLI-specific setup and usage with BMAD Method. For the complete workflow, see the [BMAD Workflow Guide](../bmad-workflow-guide.md).
|
||||
|
||||
## Installation
|
||||
|
||||
When running `npx bmad-method install`, select **Gemini CLI** as your IDE. This creates:
|
||||
|
||||
- `.gemini/agents/` directory with all agent context files
|
||||
- `.gemini/settings.json` configured to load all agents automatically
|
||||
|
||||
## Using BMAD Agents with Gemini CLI
|
||||
|
||||
Simply mention the agent in your prompt:
|
||||
|
||||
- "As @dev, implement the login feature"
|
||||
- "Acting as @architect, review this system design"
|
||||
- "@sm, create the next story for our project"
|
||||
|
||||
The Gemini CLI automatically loads the appropriate agent context.
|
||||
|
||||
## Available Agents
|
||||
|
||||
All agents are referenced with `@` in prompts:
|
||||
|
||||
- `@bmad-master` - Universal task executor
|
||||
- `@sm` - Scrum Master
|
||||
- `@dev` - Full-stack developer
|
||||
- `@architect` - Solution architect
|
||||
- `@pm` - Product manager
|
||||
- `@analyst` - Business analyst
|
||||
- `@qa` - QA specialist
|
||||
- `@po` - Product owner
|
||||
- `@ux-expert` - UX specialist
|
||||
|
||||
## Gemini CLI-Specific Features
|
||||
|
||||
- **Context files**: All agents loaded as context in `.gemini/agents/`
|
||||
- **Automatic loading**: Settings.json ensures agents are always available
|
||||
- **Natural language**: No special syntax needed, just mention the agent
|
||||
|
||||
## Tips for Gemini CLI Users
|
||||
|
||||
- Be explicit about which agent you're addressing
|
||||
- You can switch agents mid-conversation by mentioning a different one
|
||||
- The CLI maintains context across your session
|
||||
46
docs/agentic-tools/roo-code-guide.md
Normal file
46
docs/agentic-tools/roo-code-guide.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# BMAD Method Guide for Roo Code
|
||||
|
||||
This guide covers Roo Code-specific setup and usage with BMAD Method. For the complete workflow, see the [BMAD Workflow Guide](../bmad-workflow-guide.md).
|
||||
|
||||
## Installation
|
||||
|
||||
When running `npx bmad-method install`, select **Roo Code** as your IDE. This creates:
|
||||
|
||||
- `.bmad-core/` folder with all agents
|
||||
- `.roomodes` file in project root with custom modes
|
||||
|
||||
## Using BMAD Agents in Roo Code
|
||||
|
||||
Select mode from the mode selector (usually in status bar):
|
||||
|
||||
- `bmad-bmad-master` - 🧙 Universal task executor
|
||||
- `bmad-sm` - 🏃 Scrum Master
|
||||
- `bmad-dev` - 💻 Full-stack developer
|
||||
- `bmad-architect` - 🏗️ Solution architect
|
||||
- `bmad-pm` - 📋 Product manager
|
||||
- `bmad-analyst` - 📊 Business analyst
|
||||
- `bmad-qa` - 🧪 QA specialist
|
||||
- `bmad-po` - 🎯 Product owner
|
||||
- `bmad-ux-expert` - 🎨 UX specialist
|
||||
|
||||
## Roo Code-Specific Features
|
||||
|
||||
- **Mode file**: `.roomodes` in project root
|
||||
- **Mode switching**: Use mode selector instead of starting new chats
|
||||
- **Context preservation**: Maintains context across mode switches
|
||||
- **File permissions**: Each agent has specific file access:
|
||||
|
||||
### File Permission Summary
|
||||
|
||||
- **Documentation agents** (analyst, pm, po, sm): `.md`, `.txt` only
|
||||
- **bmad-architect**: `.md`, `.txt`, `.yml`, `.yaml`, `.json`
|
||||
- **bmad-qa**: Test files (`.test.*`, `.spec.*`) and `.md`
|
||||
- **bmad-ux-expert**: `.md`, `.css`, `.scss`, `.html`, `.jsx`, `.tsx`
|
||||
- **Full access**: `bmad-dev`, `bmad-bmad-master`, `bmad-orchestrator`
|
||||
|
||||
## Tips for Roo Code Users
|
||||
|
||||
- Switch modes instead of starting new chats
|
||||
- Each mode supports `*help` to see available commands
|
||||
- Agents respect file permission boundaries
|
||||
- Context persists across mode switches
|
||||
37
docs/agentic-tools/windsurf-guide.md
Normal file
37
docs/agentic-tools/windsurf-guide.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# BMAD Method Guide for Windsurf
|
||||
|
||||
This guide covers Windsurf-specific setup and usage with BMAD Method. For the complete workflow, see the [BMAD Workflow Guide](../bmad-workflow-guide.md).
|
||||
|
||||
## Installation
|
||||
|
||||
When running `npx bmad-method install`, select **Windsurf** as your IDE. This creates:
|
||||
|
||||
- `.bmad-core/` folder with all agents
|
||||
- `.windsurf/rules/` folder with agent rule files (`.md`)
|
||||
|
||||
## Using BMAD Agents in Windsurf
|
||||
|
||||
Type `@agent-name` in chat to activate an agent:
|
||||
|
||||
- `@bmad-master` - Universal task executor
|
||||
- `@sm` - Scrum Master
|
||||
- `@dev` - Full-stack developer
|
||||
- `@architect` - Solution architect
|
||||
- `@pm` - Product manager
|
||||
- `@analyst` - Business analyst
|
||||
- `@qa` - QA specialist
|
||||
- `@po` - Product owner
|
||||
- `@ux-expert` - UX specialist
|
||||
|
||||
## Windsurf-Specific Features
|
||||
|
||||
- **Rule files**: Stored in `.windsurf/rules/` as `.md` files
|
||||
- **Activation**: Use `@` prefix to mention agents
|
||||
- **Collaborative features**: Works well with BMAD's agent-switching pattern
|
||||
- **Project context**: Agents have access to your full project context
|
||||
|
||||
## Tips for Windsurf Users
|
||||
|
||||
- Start new chats when switching agents
|
||||
- Each agent supports `*help` to see available commands
|
||||
- Leverage Windsurf's collaboration features for team reviews
|
||||
@@ -1,121 +0,0 @@
|
||||
# BMAD Method Guide for Claude Code
|
||||
|
||||
This guide walks you through the complete BMAD workflow using Claude Code as your AI-powered IDE.
|
||||
|
||||
## Step 1: Install BMAD in Your Project
|
||||
|
||||
1. Navigate to your project directory
|
||||
2. Run the BMAD installer:
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
3. When prompted:
|
||||
- **Installation Type**: Choose "Complete installation (recommended)"
|
||||
- **IDE**: Select "Claude Code"
|
||||
|
||||
This creates a `.bmad-core` folder with all agents and a `.claude/commands` folder with agent commands.
|
||||
|
||||
## Step 2: Set Up Team Fullstack in Gemini
|
||||
|
||||
For ideation and planning, use Google's Gemini Custom Gem with the team-fullstack configuration:
|
||||
|
||||
1. Open [Google gems](https://gemini.google.com/gems/view)
|
||||
2. Create a new Gem - give it a title and description
|
||||
3. Copy the contents of `.<install location>/<web-bundles>/teams/team-fullstack.txt` (location can vary if you chose a non default installation location for the bundles) - or just use the bundle premade from the repo dist folder.
|
||||
4. Paste this content into Gemini to set up the team
|
||||
|
||||
### Gemini Planning Phase
|
||||
|
||||
In Gemini, ask the BMAD team to help you:
|
||||
|
||||
- **Ideate** your project concept
|
||||
- **Brainstorm** features and requirements
|
||||
- **Create a PRD** (Product Requirements Document)
|
||||
- **Design the architecture**
|
||||
|
||||
Ask questions like:
|
||||
|
||||
- "Help me brainstorm a [type of application] that does [core functionality]"
|
||||
- "Create a comprehensive PRD for this concept"
|
||||
- "Design the technical architecture for this system"
|
||||
|
||||
Copy the PRD and architecture documents that Gemini creates into your project's `docs/` folder:
|
||||
|
||||
- `docs/prd.md`
|
||||
- `docs/architecture.md`
|
||||
|
||||
## Step 3: Back to Claude Code - Document Sharding
|
||||
|
||||
Once you have your PRD and architecture documents in the `docs/` folder:
|
||||
|
||||
1. **Start a new chat in Claude Code**
|
||||
2. **Load the bmad-master agent**: Type `/bmad-master`
|
||||
3. **Shard the PRD**: Type `*shard-doc docs/prd.md prd`
|
||||
4. **Shard the architecture**: Type `*shard-doc docs/architecture.md architecture`
|
||||
|
||||
This creates organized folders:
|
||||
|
||||
- `docs/prd/` - Contains broken down PRD sections
|
||||
- `docs/architecture/` - Contains broken down architecture sections
|
||||
|
||||
## Step 4: Story Development Cycle
|
||||
|
||||
Now begin the iterative development cycle:
|
||||
|
||||
### Create Stories (Scrum Master)
|
||||
|
||||
1. **Start a new chat**
|
||||
2. **Load SM agent**: Type `/sm`
|
||||
3. **Create story**: Type `*create` (this runs the create-next-story task)
|
||||
4. **Review the generated story**
|
||||
5. **If approved**: Set story status to "Approved" in the story file
|
||||
|
||||
### Implement Stories (Developer)
|
||||
|
||||
1. **Start a new chat**
|
||||
2. **Load Dev agent**: Type `/dev`
|
||||
3. **The agent will ask which story to implement**
|
||||
4. **Follow the development tasks** the agent provides
|
||||
5. **When story is complete**: Mark status as "Done"
|
||||
|
||||
### Repeat the Cycle
|
||||
|
||||
1. **Start a new chat with SM agent** (`/sm`)
|
||||
2. **Create next story**: Type `*create`
|
||||
3. **Review and approve**
|
||||
4. **Start new chat with Dev agent** (`/dev`)
|
||||
5. **Implement the story**
|
||||
6. **Repeat until project complete**
|
||||
|
||||
## Available Commands in Claude Code
|
||||
|
||||
All BMAD agents are available as Claude Code commands:
|
||||
|
||||
- `/bmad-master` - Universal task executor
|
||||
- `/sm` - Scrum Master for story creation
|
||||
- `/dev` - Full-stack developer for implementation
|
||||
- `/architect` - Solution architect for design
|
||||
- `/pm` - Product manager for planning
|
||||
- `/analyst` - Business analyst for requirements
|
||||
- `/qa` - QA specialist for testing
|
||||
- `/po` - Product owner for prioritization
|
||||
- `/ux-expert` - UX specialist for design
|
||||
|
||||
## Key Workflow Principles
|
||||
|
||||
1. **Always start new chats** when switching agents to avoid context confusion
|
||||
2. **Use Gemini for initial planning** and ideation with the team-fullstack bundle
|
||||
3. **Use bmad-master for document management** (sharding, templates, etc.)
|
||||
4. **Follow the SM → Dev cycle** for consistent story development
|
||||
5. **Review and approve stories** before implementation begins
|
||||
|
||||
## Tips for Success
|
||||
|
||||
- **Keep chats focused**: Each chat should have one agent and one primary task
|
||||
- **Use \*help command**: Every agent supports `*help` to see available commands
|
||||
- **Review generated content**: Always review and approve stories before marking them ready
|
||||
- **Maintain status updates**: Keep story statuses current (Draft → Approved → InProgress → Done)
|
||||
|
||||
This workflow ensures systematic, AI-assisted development following agile principles with clear handoffs between planning, story creation, and implementation phases.
|
||||
@@ -204,12 +204,180 @@ graph TD
|
||||
F -->|Approved| G["Dev: Implement Story"]
|
||||
F -->|Needs Changes| E
|
||||
G --> H["Dev: Complete story Tasks"]
|
||||
H --> I{"User Verification"}
|
||||
I -->|Verified Complete| J["Mark Story as Done"]
|
||||
I -->|Needs Fixes| G
|
||||
J --> E
|
||||
H --> I["Dev: Mark Ready for Review"]
|
||||
I --> J{"User Verification"}
|
||||
J -->|Request QA Review| K["QA: Run review-story task"]
|
||||
J -->|Approve Without QA| M["Mark Story as Done"]
|
||||
K --> L{"QA Review Results"}
|
||||
L -->|Needs Work| G
|
||||
L -->|Approved| M["Mark Story as Done"]
|
||||
J -->|Needs Fixes| G
|
||||
M --> E
|
||||
|
||||
style J fill:#34a853,color:#fff
|
||||
style M fill:#34a853,color:#fff
|
||||
style K fill:#f9ab00,color:#fff
|
||||
```
|
||||
|
||||
This cycle continues, with the Scrum Master and Developer agents working in tandem, until all stories in the epic are completed.
|
||||
This cycle continues, with the Scrum Master, Developer, and optionally QA agents working together. The QA agent provides senior developer review capabilities through the `review-story` task, offering code refactoring, quality improvements, and knowledge transfer. This ensures high code quality while maintaining development velocity.
|
||||
|
||||
## 8. Complete Source Tree
|
||||
|
||||
The BMAD-METHOD project structure is designed for clarity, modularity, and extensibility. Here's the complete source tree with explanations:
|
||||
|
||||
```plaintext
|
||||
bmad-method/
|
||||
├── .bmad-core/ # Core framework (installed in user projects)
|
||||
│ ├── agents/ # Individual agent definitions
|
||||
│ │ ├── analyst.md # Business analyst agent
|
||||
│ │ ├── architect.md # Solution architect agent
|
||||
│ │ ├── bmad-master.md # Universal expert agent
|
||||
│ │ ├── bmad-orchestrator.md # Multi-agent coordinator
|
||||
│ │ ├── dev.md # Full-stack developer agent
|
||||
│ │ ├── pm.md # Product manager agent
|
||||
│ │ ├── po.md # Product owner agent
|
||||
│ │ ├── qa.md # QA specialist agent
|
||||
│ │ ├── sm.md # Scrum master agent
|
||||
│ │ └── ux-expert.md # UX designer agent
|
||||
│ ├── agent-teams/ # Pre-configured agent teams
|
||||
│ │ ├── team-all.yml # All agents bundle
|
||||
│ │ ├── team-fullstack.yml # Full-stack development team
|
||||
│ │ ├── team-ide-minimal.yml # Minimal IDE-focused team
|
||||
│ │ └── team-no-ui.yml # Backend-only team
|
||||
│ ├── checklists/ # Quality assurance checklists
|
||||
│ │ ├── architect-checklist.md
|
||||
│ │ ├── po-master-checklist.md
|
||||
│ │ └── story-dod-checklist.md
|
||||
│ ├── data/ # Knowledge base and preferences
|
||||
│ │ ├── bmad-kb.md # Core knowledge base
|
||||
│ │ └── technical-preferences.md # User tech preferences
|
||||
│ ├── tasks/ # Reusable task definitions
|
||||
│ │ ├── advanced-elicitation.md # Deep diving techniques
|
||||
│ │ ├── create-doc.md # Document creation task
|
||||
│ │ ├── create-next-story.md # Story generation task
|
||||
│ │ ├── doc-migration-task.md # V3 to V4 migration
|
||||
│ │ ├── execute-checklist.md # Checklist runner
|
||||
│ │ └── shard-doc.md # Document sharding task
|
||||
│ ├── templates/ # Document templates
|
||||
│ │ ├── full-stack-architecture-tmpl.md
|
||||
│ │ ├── prd-tmpl.md
|
||||
│ │ ├── project-brief-tmpl.md
|
||||
│ │ ├── story-tmpl.md
|
||||
│ │ └── [other templates...]
|
||||
│ ├── utils/ # Utility components
|
||||
│ │ ├── agent-switcher.web # Web UI agent switching
|
||||
│ │ ├── template-format.md # Template markup spec
|
||||
│ │ └── workflow-management.md # Workflow helpers
|
||||
│ ├── workflows/ # Development workflows
|
||||
│ │ ├── brownfield-enhancement.yml
|
||||
│ │ ├── greenfield-fullstack.yml
|
||||
│ │ ├── greenfield-service.yml
|
||||
│ │ └── greenfield-simple.yml
|
||||
│ └── core-config.yml # V4 configuration system
|
||||
│
|
||||
├── dist/ # Pre-built bundles (generated)
|
||||
│ ├── agents/ # Individual agent bundles
|
||||
│ │ ├── analyst.txt
|
||||
│ │ ├── architect.txt
|
||||
│ │ └── [other agents...]
|
||||
│ ├── teams/ # Team bundles for web UI
|
||||
│ │ ├── team-all.txt
|
||||
│ │ ├── team-fullstack.txt
|
||||
│ │ └── [other teams...]
|
||||
│ └── expansion-packs/ # Expansion pack bundles
|
||||
│
|
||||
├── docs/ # Documentation
|
||||
│ ├── agentic-tools/ # IDE-specific guides
|
||||
│ │ ├── claude-code-guide.md
|
||||
│ │ ├── cursor-guide.md
|
||||
│ │ ├── cline-guide.md
|
||||
│ │ ├── gemini-cli-guide.md
|
||||
│ │ ├── roo-code-guide.md
|
||||
│ │ └── windsurf-guide.md
|
||||
│ ├── bmad-workflow-guide.md # Universal workflow guide
|
||||
│ ├── core-architecture.md # This document
|
||||
│ ├── expansion-packs.md # Expansion pack guide
|
||||
│ ├── user-guide.md # Comprehensive user guide
|
||||
│ └── [other docs...]
|
||||
│
|
||||
├── expansion-packs/ # Domain-specific extensions
|
||||
│ ├── bmad-2d-phaser-game-dev/ # Game development pack
|
||||
│ ├── bmad-creator-tools/ # Agent creation tools
|
||||
│ ├── bmad-infrastructure-devops/ # DevOps pack
|
||||
│ └── README.md
|
||||
│
|
||||
├── tools/ # Build and installation tools
|
||||
│ ├── builders/ # Build system
|
||||
│ │ └── web-builder.js # Bundle generator
|
||||
│ ├── cli.js # Main CLI tool
|
||||
│ ├── installer/ # NPX installer
|
||||
│ │ ├── index.js # Installer entry point
|
||||
│ │ ├── config/ # Installation configs
|
||||
│ │ ├── lib/ # Installer utilities
|
||||
│ │ └── templates/ # IDE template files
|
||||
│ └── lib/ # Shared libraries
|
||||
│ ├── bundle-utils.js
|
||||
│ ├── dependency-resolver.js
|
||||
│ └── file-processor.js
|
||||
│
|
||||
├── .github/ # GitHub configuration
|
||||
│ ├── workflows/ # GitHub Actions
|
||||
│ └── ISSUE_TEMPLATE/ # Issue templates
|
||||
│
|
||||
├── common/ # Shared resources
|
||||
│ ├── tasks/ # Common tasks
|
||||
│ └── utils/ # Common utilities
|
||||
│
|
||||
├── bmad-core/ # Source for .bmad-core
|
||||
│ └── [mirrors .bmad-core structure]
|
||||
│
|
||||
├── package.json # Node.js configuration
|
||||
├── README.md # Project readme
|
||||
├── CONTRIBUTING.md # Contribution guidelines
|
||||
├── GUIDING-PRINCIPLES.md # Core principles
|
||||
└── LICENSE # MIT license
|
||||
```
|
||||
|
||||
### Directory Purposes
|
||||
|
||||
#### Core Framework (.bmad-core/)
|
||||
|
||||
- **agents/**: Individual AI agent personalities and capabilities
|
||||
- **agent-teams/**: Bundles of agents for specific workflows
|
||||
- **checklists/**: Quality assurance and validation steps
|
||||
- **data/**: Knowledge base and user preferences
|
||||
- **tasks/**: Reusable procedures agents can execute
|
||||
- **templates/**: Document templates with embedded AI instructions
|
||||
- **utils/**: Helper components for agents
|
||||
- **workflows/**: Structured development processes
|
||||
|
||||
#### Generated Bundles (dist/)
|
||||
|
||||
- Pre-built text files ready for web UI upload
|
||||
- Automatically generated by the build system
|
||||
- Includes resolved dependencies for each agent/team
|
||||
|
||||
#### Tools (tools/)
|
||||
|
||||
- **cli.js**: Main build tool for creating bundles
|
||||
- **installer/**: NPX-based installer for projects
|
||||
- **builders/**: Bundle generation logic
|
||||
- **lib/**: Shared utilities for build system
|
||||
|
||||
#### Expansion Packs (expansion-packs/)
|
||||
|
||||
- Domain-specific agent collections
|
||||
- Extend BMAD beyond software development
|
||||
- Each pack is self-contained with its own agents, tasks, and templates
|
||||
|
||||
#### Documentation (docs/)
|
||||
|
||||
- Comprehensive guides for users
|
||||
- Technical architecture documentation
|
||||
- IDE-specific setup instructions
|
||||
|
||||
### Key Files
|
||||
|
||||
- **core-config.yml**: V4's flexible configuration system
|
||||
- **bmad-kb.md**: Central knowledge base loaded by most agents
|
||||
- **template-format.md**: Specification for BMAD's template markup
|
||||
- **dependency-resolver.js**: Manages agent resource loading
|
||||
|
||||
@@ -1,131 +0,0 @@
|
||||
# BMAD Method Guide for Cursor
|
||||
|
||||
This guide walks you through the complete BMAD workflow using Cursor as your AI-powered IDE.
|
||||
|
||||
## Step 1: Install BMAD in Your Project
|
||||
|
||||
1. Navigate to your project directory
|
||||
2. Run the BMAD installer:
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
3. When prompted:
|
||||
- **Installation Type**: Choose "Complete installation (recommended)"
|
||||
- **IDE**: Select "Cursor"
|
||||
|
||||
This creates a `.bmad-core` folder with all agents and a `.cursor/rules` folder with agent rules.
|
||||
|
||||
## Step 2: Set Up Team Fullstack in Gemini
|
||||
|
||||
For ideation and planning, use Google's Gemini Custom Gem with the team-fullstack configuration:
|
||||
|
||||
1. Open [Google gems](https://gemini.google.com/gems/view)
|
||||
2. Create a new Gem - give it a title and description
|
||||
3. Copy the contents of `.<install location>/<web-bundles>/teams/team-fullstack.txt` (location can vary if you chose a non default installation location for the bundles) - or just use the bundle premade from the repo dist folder.
|
||||
4. Paste this content into Gemini to set up the team
|
||||
|
||||
### Gemini Planning Phase
|
||||
|
||||
In Gemini, ask the BMAD team to help you:
|
||||
|
||||
- **Ideate** your project concept
|
||||
- **Brainstorm** features and requirements
|
||||
- **Create a PRD** (Product Requirements Document)
|
||||
- **Design the architecture**
|
||||
|
||||
Ask questions like:
|
||||
|
||||
- "Help me brainstorm a [type of application] that does [core functionality]"
|
||||
- "Create a comprehensive PRD for this concept"
|
||||
- "Design the technical architecture for this system"
|
||||
|
||||
Copy the PRD and architecture documents that Gemini creates into your project's `docs/` folder:
|
||||
|
||||
- `docs/prd.md`
|
||||
- `docs/architecture.md`
|
||||
|
||||
## Step 3: Back to Cursor - Document Sharding
|
||||
|
||||
Once you have your PRD and architecture documents in the `docs/` folder:
|
||||
|
||||
1. **Start a new chat in Cursor**
|
||||
2. **Load the bmad-master agent**: Type `@bmad-master`
|
||||
3. **Shard the PRD**: Type `*shard-doc docs/prd.md prd`
|
||||
4. **Shard the architecture**: Type `*shard-doc docs/architecture.md architecture`
|
||||
|
||||
This creates organized folders:
|
||||
|
||||
- `docs/prd/` - Contains broken down PRD sections
|
||||
- `docs/architecture/` - Contains broken down architecture sections
|
||||
|
||||
## Step 4: Story Development Cycle
|
||||
|
||||
Now begin the iterative development cycle:
|
||||
|
||||
### Create Stories (Scrum Master)
|
||||
|
||||
1. **Start a new chat**
|
||||
2. **Load SM agent**: Type `@sm`
|
||||
3. **Create story**: Type `*create` (this runs the create-next-story task)
|
||||
4. **Review the generated story**
|
||||
5. **If approved**: Set story status to "Approved" in the story file
|
||||
|
||||
### Implement Stories (Developer)
|
||||
|
||||
1. **Start a new chat**
|
||||
2. **Load Dev agent**: Type `@dev`
|
||||
3. **The agent will ask which story to implement**
|
||||
4. **Follow the development tasks** the agent provides
|
||||
5. **When story is complete**: Mark status as "Done"
|
||||
|
||||
### Repeat the Cycle
|
||||
|
||||
1. **Start a new chat with SM agent** (`@sm`)
|
||||
2. **Create next story**: Type `*create`
|
||||
3. **Review and approve**
|
||||
4. **Start new chat with Dev agent** (`@dev`)
|
||||
5. **Implement the story**
|
||||
6. **Repeat until project complete**
|
||||
|
||||
## Available Agent Rules in Cursor
|
||||
|
||||
All BMAD agents are available as Cursor rules (use `@` prefix):
|
||||
|
||||
- `@bmad-master` - Universal task executor
|
||||
- `@sm` - Scrum Master for story creation
|
||||
- `@dev` - Full-stack developer for implementation
|
||||
- `@architect` - Solution architect for design
|
||||
- `@pm` - Product manager for planning
|
||||
- `@analyst` - Business analyst for requirements
|
||||
- `@qa` - QA specialist for testing
|
||||
- `@po` - Product owner for prioritization
|
||||
- `@ux-expert` - UX specialist for design
|
||||
|
||||
Alternatively, and more performance - you can copy the contents of an agent file into a custom mode - see the cursor docs on how to use custom agents.
|
||||
|
||||
## Cursor-Specific Features
|
||||
|
||||
- **Agent rules are stored in**: `.cursor/rules/` as `.mdc` files
|
||||
- **Auto-completion**: Cursor will suggest `@agent-name` as you type
|
||||
- **Rule activation**: Rules activate automatically when you mention `@agent-name`
|
||||
- **Context awareness**: Agents have access to your current file context
|
||||
|
||||
## Key Workflow Principles
|
||||
|
||||
1. **Always start new chats** when switching agents to avoid context confusion
|
||||
2. **Use Gemini for initial planning** and ideation with the team-fullstack bundle
|
||||
3. **Use bmad-master for document management** (sharding, templates, etc.)
|
||||
4. **Follow the SM → Dev cycle** for consistent story development
|
||||
5. **Review and approve stories** before implementation begins
|
||||
|
||||
## Tips for Success
|
||||
|
||||
- **Keep chats focused**: Each chat should have one agent and one primary task
|
||||
- **Use \*help command**: Every agent supports `*help` to see available commands
|
||||
- **Review generated content**: Always review and approve stories before marking them ready
|
||||
- **Maintain status updates**: Keep story statuses current (Draft → Approved → InProgress → Done)
|
||||
- **Leverage Cursor's context**: Agents can see your current file selection for better assistance
|
||||
|
||||
This workflow ensures systematic, AI-assisted development following agile principles with clear handoffs between planning, story creation, and implementation phases.
|
||||
@@ -1,121 +0,0 @@
|
||||
# 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!
|
||||
@@ -132,6 +132,21 @@ Property investment and management:
|
||||
- **Flip Strategist**: Renovation ROI, project planning
|
||||
- **Agent Assistant**: Listing optimization, showing prep
|
||||
|
||||
### Personal Development Pack
|
||||
|
||||
Complete personal growth system:
|
||||
|
||||
- **Life Coach**: Guides personal growth and transformation
|
||||
- **Goal Strategist**: Helps achieve objectives with SMART goals
|
||||
- **Habit Builder**: Creates lasting habits with accountability
|
||||
- **Mindset Mentor**: Develops positive thinking patterns
|
||||
|
||||
Key tasks include:
|
||||
|
||||
- `goal-setting`: Defines SMART goals with action plans
|
||||
- `habit-tracking`: Monitors habit formation progress
|
||||
- `reflection-exercise`: Facilitates deep self-reflection
|
||||
|
||||
## Unique & Innovative Packs
|
||||
|
||||
### Role-Playing Game Master Pack
|
||||
|
||||
@@ -1,142 +0,0 @@
|
||||
# BMAD Method Guide for Roo Code
|
||||
|
||||
This guide walks you through the complete BMAD workflow using Roo Code as your AI-powered IDE.
|
||||
|
||||
## Step 1: Install BMAD in Your Project
|
||||
|
||||
1. Navigate to your project directory
|
||||
2. Run the BMAD installer:
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
3. When prompted:
|
||||
- **Installation Type**: Choose "Complete installation (recommended)"
|
||||
- **IDE**: Select "Roo Code"
|
||||
|
||||
This creates a `.bmad-core` folder with all agents and a `.roomodes` file (in the project root) with custom modes.
|
||||
|
||||
## Step 2: Set Up Team Fullstack in Gemini
|
||||
|
||||
For ideation and planning, use Google's Gemini Custom Gem with the team-fullstack configuration:
|
||||
|
||||
1. Open [Google gems](https://gemini.google.com/gems/view)
|
||||
2. Create a new Gem - give it a title and description
|
||||
3. Copy the contents of `.<install location>/<web-bundles>/teams/team-fullstack.txt` (location can vary if you chose a non default installation location for the bundles) - or just use the bundle premade from the repo dist folder.
|
||||
4. Paste this content into Gemini to set up the team
|
||||
|
||||
### Gemini Planning Phase
|
||||
|
||||
In Gemini, ask the BMAD team to help you:
|
||||
|
||||
- **Ideate** your project concept
|
||||
- **Brainstorm** features and requirements
|
||||
- **Create a PRD** (Product Requirements Document)
|
||||
- **Design the architecture**
|
||||
|
||||
Ask questions like:
|
||||
|
||||
- "Help me brainstorm a [type of application] that does [core functionality]"
|
||||
- "Create a comprehensive PRD for this concept"
|
||||
- "Design the technical architecture for this system"
|
||||
|
||||
Copy the PRD and architecture documents that Gemini creates into your project's `docs/` folder:
|
||||
|
||||
- `docs/prd.md`
|
||||
- `docs/architecture.md`
|
||||
|
||||
## Step 3: Back to Roo Code - Document Sharding
|
||||
|
||||
Once you have your PRD and architecture documents in the `docs/` folder:
|
||||
|
||||
1. **Open your project in Roo Code**
|
||||
2. **Select the bmad-master mode** from the mode selector (usually in status bar)
|
||||
3. **Shard the PRD**: Type `*shard-doc docs/prd.md prd`
|
||||
4. **Shard the architecture**: Type `*shard-doc docs/architecture.md architecture`
|
||||
|
||||
This creates organized folders:
|
||||
|
||||
- `docs/prd/` - Contains broken down PRD sections
|
||||
- `docs/architecture/` - Contains broken down architecture sections
|
||||
|
||||
## Step 4: Story Development Cycle
|
||||
|
||||
Now begin the iterative development cycle:
|
||||
|
||||
### Create Stories (Scrum Master)
|
||||
|
||||
1. **Start a new chat or conversation**
|
||||
2. **Switch to SM mode**: Select `bmad-sm` from the mode selector
|
||||
3. **Create story**: Type `*create` (this runs the create-next-story task)
|
||||
4. **Review the generated story**
|
||||
5. **If approved**: Set story status to "Approved" in the story file
|
||||
|
||||
### Implement Stories (Developer)
|
||||
|
||||
1. **Start a new conversation**
|
||||
2. **Switch to Dev mode**: Select `bmad-dev` from the mode selector
|
||||
3. **The agent will ask which story to implement**
|
||||
4. **Follow the development tasks** the agent provides
|
||||
5. **When story is complete**: Mark status as "Done"
|
||||
|
||||
### Repeat the Cycle
|
||||
|
||||
1. **Switch to SM mode** (`bmad-sm`)
|
||||
2. **Create next story**: Type `*create`
|
||||
3. **Review and approve**
|
||||
4. **Switch to Dev mode** (`bmad-dev`)
|
||||
5. **Implement the story**
|
||||
6. **Repeat until project complete**
|
||||
|
||||
## Available Custom Modes in Roo Code
|
||||
|
||||
All BMAD agents are available as custom modes:
|
||||
|
||||
- `bmad-bmad-master` - 🧙 Universal task executor
|
||||
- `bmad-sm` - 🏃 Scrum Master for story creation
|
||||
- `bmad-dev` - 💻 Full-stack developer for implementation
|
||||
- `bmad-architect` - 🏗️ Solution architect for design
|
||||
- `bmad-pm` - 📋 Product manager for planning
|
||||
- `bmad-analyst` - 📊 Business analyst for requirements
|
||||
- `bmad-qa` - 🧪 QA specialist for testing
|
||||
- `bmad-po` - 🎯 Product owner for prioritization
|
||||
- `bmad-ux-expert` - 🎨 UX specialist for design
|
||||
|
||||
## Roo Code-Specific Features
|
||||
|
||||
- **Custom modes are stored in**: `.roomodes` file (in the project root)
|
||||
- **Mode switching**: Use the mode selector in Roo Code's interface
|
||||
- **File permissions**: Each agent has specific file access permissions
|
||||
- **Documentation agents** (SM, PM, PO, Analyst): Limited to `.md` and `.txt` files
|
||||
- **Technical agents** (Dev, Architect, Master): Full file access
|
||||
- **QA agents**: Access to test files and documentation
|
||||
- **UX agents**: Access to design-related files
|
||||
- **Context preservation**: Modes maintain context within conversations
|
||||
|
||||
## Key Workflow Principles
|
||||
|
||||
1. **Switch modes instead of starting new chats** - Roo Code handles context better with mode switching
|
||||
2. **Use Gemini for initial planning** and ideation with the team-fullstack bundle
|
||||
3. **Use bmad-master mode for document management** (sharding, templates, etc.)
|
||||
4. **Follow the SM → Dev mode cycle** for consistent story development
|
||||
5. **Review and approve stories** before implementation begins
|
||||
|
||||
## Tips for Success
|
||||
|
||||
- **Use mode selector effectively**: Switch modes as needed for different tasks
|
||||
- **Respect file permissions**: Agents can only edit files they have permission for
|
||||
- **Use \*help command**: Every mode supports `*help` to see available commands
|
||||
- **Review generated content**: Always review and approve stories before marking them ready
|
||||
- **Maintain status updates**: Keep story statuses current (Draft → Approved → InProgress → Done)
|
||||
- **Leverage Roo's context**: Modes can maintain context across the conversation
|
||||
|
||||
## File Permission Summary
|
||||
|
||||
- **bmad-analyst, bmad-pm, bmad-po, bmad-sm**: `.md`, `.txt` files only
|
||||
- **bmad-architect**: `.md`, `.txt`, `.yml`, `.yaml`, `.json` files
|
||||
- **bmad-qa**: Test files (`.test.js`, `.spec.ts`, etc.) and `.md` files
|
||||
- **bmad-ux-expert**: `.md`, `.css`, `.scss`, `.html`, `.jsx`, `.tsx` files
|
||||
- **bmad-dev, bmad-bmad-master, bmad-orchestrator**: Full file access
|
||||
|
||||
This workflow ensures systematic, AI-assisted development following agile principles with clear handoffs between planning, story creation, and implementation phases.
|
||||
@@ -1,6 +1,6 @@
|
||||
# BMAD-METHOD User Guide
|
||||
# BMAD-METHOD Agentic Agile Driven Development User Guide
|
||||
|
||||
This comprehensive guide will help you understand and effectively use the BMAD-METHOD framework for AI-assisted software development.
|
||||
This comprehensive guide will help you understand and effectively use the BMad Method framework for AI-assisted software development.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
@@ -61,6 +61,19 @@ Best for: Cursor, Claude Code, Windsurf, VS Code users
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
### CLI Commands
|
||||
|
||||
```bash
|
||||
# List all available agents
|
||||
npx bmad-method list
|
||||
|
||||
# Install or update (automatically detects existing installations)
|
||||
npx bmad-method install
|
||||
|
||||
# Check installation status
|
||||
npx bmad-method status
|
||||
```
|
||||
|
||||
### First Steps
|
||||
|
||||
1. **Choose Your Environment**: Web UI or IDE
|
||||
@@ -68,20 +81,47 @@ npx bmad-method install
|
||||
3. **Initialize Project**: Run `/help` or `*help` to see capabilities
|
||||
4. **Start Development**: Begin with planning or jump into coding
|
||||
|
||||
### Upgrading from V3 to V4
|
||||
|
||||
If you have an existing BMAD-METHOD V3 project, simply run the installer in your project directory:
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
# The installer will automatically detect your V3 installation and offer to upgrade
|
||||
```
|
||||
|
||||
The upgrade process will:
|
||||
|
||||
1. Create a backup of your V3 files in `.bmad-v3-backup/`
|
||||
2. Install the new V4 `.bmad-core/` structure
|
||||
3. Migrate your documents (PRD, Architecture, Stories, Epics)
|
||||
4. Set up IDE integration for all V4 agents
|
||||
5. Create an install manifest for future updates
|
||||
|
||||
After upgrading:
|
||||
|
||||
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 by 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.
|
||||
|
||||
The reason #2 and #3 are optional is because now BMAD V4 makes sharding optional for the SM. See [Core Configuration](#core-configuration-coreconfigyml)
|
||||
|
||||
**Note**: The agents in `.bmad-core/` fully replace the items in `bmad-agent/` - you can remove the backup folder versions.
|
||||
|
||||
## Agent System
|
||||
|
||||
### Core Development Team
|
||||
|
||||
| Agent | Role | Primary Functions | When to Use |
|
||||
| ----------- | ------------------ | --------------------------------------- | -------------------------------------- |
|
||||
| `analyst` | Business Analyst | Market research, requirements gathering | Project planning, competitive analysis |
|
||||
| `pm` | Product Manager | PRD creation, feature prioritization | Strategic planning, roadmaps |
|
||||
| `architect` | Solution Architect | System design, technical architecture | Complex systems, scalability planning |
|
||||
| `dev` | Developer | Code implementation, debugging | All development tasks |
|
||||
| `qa` | QA Specialist | Test planning, quality assurance | Testing strategies, bug validation |
|
||||
| `ux-expert` | UX Designer | UI/UX design, prototypes | User experience, interface design |
|
||||
| `po` | Product Owner | Backlog management, story validation | Story refinement, acceptance criteria |
|
||||
| `sm` | Scrum Master | Sprint planning, story creation | Project management, workflow |
|
||||
| Agent | Role | Primary Functions | When to Use |
|
||||
| ----------- | ------------------ | ---------------------------------------------- | ------------------------------------------------- |
|
||||
| `analyst` | Business Analyst | Market research, requirements gathering | Project planning, competitive analysis |
|
||||
| `pm` | Product Manager | PRD creation, feature prioritization | Strategic planning, roadmaps |
|
||||
| `architect` | Solution Architect | System design, technical architecture | Complex systems, scalability planning |
|
||||
| `dev` | Developer | Sequential task execution, testing, validation | Story implementation with test-driven development |
|
||||
| `qa` | QA Specialist | Code review, refactoring, test validation | Senior developer review via `review-story` task |
|
||||
| `ux-expert` | UX Designer | UI/UX design, prototypes | User experience, interface design |
|
||||
| `po` | Product Owner | Backlog management, story validation | Story refinement, acceptance criteria |
|
||||
| `sm` | Scrum Master | Sprint planning, story creation | Project management, workflow |
|
||||
|
||||
### Meta Agents
|
||||
|
||||
@@ -284,20 +324,29 @@ Once planning is complete and documents are sharded, BMAD follows a structured d
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["Start: Planning Artifacts Complete"] --> B["PO: Shard Epics"]
|
||||
B --> C["PO: Shard Arch"]
|
||||
C --> D["Development Phase"]
|
||||
D --> E["Scrum Master: Drafts next story from sharded epic"]
|
||||
E --> F{"User Approval"}
|
||||
F -->|Approved| G["Dev: Implement Story"]
|
||||
F -->|Needs Changes| E
|
||||
G --> H["Dev: Complete story Tasks"]
|
||||
H --> I{"User Verification"}
|
||||
I -->|Verified Complete| J["Mark Story as Done"]
|
||||
I -->|Needs Fixes| G
|
||||
J --> E
|
||||
A["Development Phase Start"] --> B["SM: Reviews Previous Story Dev/QA Notes"]
|
||||
B --> B2["SM: Drafts Next Story from Sharded Epic + Architecture"]
|
||||
B2 --> C{"User Approval"}
|
||||
C -->|Approved| D["Dev: Sequential Task Execution"]
|
||||
C -->|Needs Changes| B2
|
||||
D --> E["Dev: Implement Tasks + Tests"]
|
||||
E --> F["Dev: Run All Validations"]
|
||||
F --> G["Dev: Mark Ready for Review + Add Notes"]
|
||||
G --> H{"User Verification"}
|
||||
H -->|Request QA Review| I["QA: Senior Dev Review + Active Refactoring"]
|
||||
H -->|Approve Without QA| K["Mark Story as Done"]
|
||||
I --> J["QA: Review, Refactor Code, Add Tests, Document Notes"]
|
||||
J --> L{"QA Decision"}
|
||||
L -->|Needs Dev Work| D
|
||||
L -->|Approved| K
|
||||
H -->|Needs Fixes| D
|
||||
K --> B
|
||||
|
||||
style J fill:#34a853,color:#fff
|
||||
style K fill:#34a853,color:#fff
|
||||
style I fill:#f9ab00,color:#fff
|
||||
style J fill:#ffd54f,color:#000
|
||||
style E fill:#e3f2fd,color:#000
|
||||
style B fill:#e8f5e9,color:#000
|
||||
```
|
||||
|
||||
### Workflow Phases
|
||||
@@ -319,15 +368,213 @@ graph TD
|
||||
|
||||
- **SM**: Draft next story from sharded epic
|
||||
- **User**: Review and approve story
|
||||
- **Dev**: Implement all story tasks
|
||||
- **Dev**: Sequential task execution:
|
||||
- Reads each task in the story
|
||||
- Implements code for the task
|
||||
- Writes tests alongside implementation
|
||||
- Runs validations (linting, tests)
|
||||
- Updates task checkbox [x] only if all validations pass
|
||||
- Maintains Debug Log for temporary changes
|
||||
- Updates File List with all created/modified files
|
||||
- **Dev**: After all tasks complete:
|
||||
- Runs integration tests (if specified)
|
||||
- Runs E2E tests (if specified)
|
||||
- Validates Definition of Done checklist
|
||||
- Marks story as "Ready for Review"
|
||||
- **User**: Verify implementation
|
||||
- **Optional QA Review**: User can request QA to run `review-story` task
|
||||
- **Repeat**: Until all stories complete
|
||||
|
||||
#### 4. Quality Assurance
|
||||
#### Dev Agent Workflow Details
|
||||
|
||||
- **QA**: Test planning and execution
|
||||
- **Dev**: Bug fixes and refinements
|
||||
- **PO**: Acceptance criteria validation
|
||||
The Dev agent follows a strict test-driven sequential workflow:
|
||||
|
||||
**Key Behaviors:**
|
||||
|
||||
- **Story-Centric**: Works only from the story file, never loads PRD/architecture unless specified in dev notes
|
||||
- **Sequential Execution**: Completes tasks one by one, marking [x] only after validations pass
|
||||
- **Test-Driven**: Writes tests alongside code for every task
|
||||
- **Quality Gates**: Never marks tasks complete if validations fail
|
||||
- **Debug Logging**: Tracks temporary changes in the story's Debug Log table
|
||||
- **File Tracking**: Maintains complete File List of all created/modified files
|
||||
|
||||
**Blocking Conditions:**
|
||||
The Dev agent will stop and request help if:
|
||||
|
||||
- Story is not approved
|
||||
- Requirements are ambiguous after checking the story
|
||||
- Validations fail 3 times for the same task
|
||||
- Critical configuration files are missing
|
||||
- Automated tests or linting fails
|
||||
|
||||
#### 4. Quality Assurance Integration
|
||||
|
||||
The QA agent plays a crucial role after development:
|
||||
|
||||
- **When Dev marks "Ready for Review"**: Story is ready for user verification
|
||||
- **User Options**:
|
||||
- **Direct Approval**: If satisfied, mark story as "Done"
|
||||
- **Request Changes**: Send back to Dev with specific feedback
|
||||
- **Request QA Review**: Ask QA to run the `review-story` task for senior developer review
|
||||
- **QA Review Process** (`/qa run review-story`):
|
||||
|
||||
- Reviews code as a senior developer with authority to refactor
|
||||
- **Active Refactoring**: Makes improvements directly in the code
|
||||
- **Comprehensive Review Focus**:
|
||||
- Code architecture and design patterns
|
||||
- Refactoring opportunities and code duplication
|
||||
- Performance optimizations and security concerns
|
||||
- Best practices and patterns
|
||||
- **Standards Compliance**: Verifies adherence to:
|
||||
- `docs/coding-standards.md`
|
||||
- `docs/unified-project-structure.md`
|
||||
- `docs/testing-strategy.md`
|
||||
- **Test Coverage Review**: Can add missing tests if critical coverage is lacking
|
||||
- **Documentation**: Adds comments for complex logic if missing
|
||||
- **Results Documentation** in story's QA Results section:
|
||||
- Code quality assessment
|
||||
- Refactoring performed with WHY and HOW explanations
|
||||
- Compliance check results
|
||||
- Improvements checklist (completed vs. pending items)
|
||||
- Security and performance findings
|
||||
- Final approval status
|
||||
|
||||
### Understanding the SM/Dev/QA Story Workflow
|
||||
|
||||
The story file is the central artifact that enables seamless collaboration between the Scrum Master (SM), Developer (Dev), and Quality Assurance (QA) agents. Here's how they work together:
|
||||
|
||||
#### Why We Have the Scrum Master
|
||||
|
||||
The SM agent serves as a critical bridge between high-level planning and technical implementation:
|
||||
|
||||
1. **Document Synthesis**: Reads sharded PRD epics and architecture documents to extract relevant technical details
|
||||
2. **Story Enrichment**: Creates self-contained stories with all technical context needed for implementation
|
||||
3. **Continuous Learning**: Uses notes from previous stories to improve future story preparation
|
||||
4. **Developer Efficiency**: Ensures developers have everything needed without searching multiple documents
|
||||
|
||||
#### The Story Creation Process
|
||||
|
||||
When the SM agent executes the `create-next-story` task:
|
||||
|
||||
1. **Loads Configuration**: Reads `core-config.yml` to understand project structure
|
||||
2. **Identifies Next Story**: Sequentially processes stories from epics (1.1, 1.2, 2.1, etc.)
|
||||
3. **Gathers Architecture Context**: Reads relevant sharded architecture documents based on story type:
|
||||
|
||||
- Backend stories: data models, API specs, database schemas
|
||||
- Frontend stories: component specs, UI patterns, workflows
|
||||
- Full-stack: both backend and frontend documents
|
||||
|
||||
4. **Reviews Previous Story**: Extracts Dev and QA notes to learn from past implementation
|
||||
|
||||
#### The Story Template Structure
|
||||
|
||||
The story template contains embedded LLM instructions for different agents:
|
||||
|
||||
**SM Agent Instructions**:
|
||||
|
||||
- Populate Dev Notes with specific technical details from architecture
|
||||
- Include source references for all technical guidance
|
||||
- Create detailed tasks based on architecture constraints
|
||||
- Add testing requirements from testing strategy
|
||||
|
||||
**Dev Agent Instructions**:
|
||||
|
||||
- Update Debug Log References during implementation
|
||||
- Document any deviations in Completion Notes
|
||||
- Maintain comprehensive File List of all changes
|
||||
- Track requirement changes in Change Log
|
||||
|
||||
**QA Agent Instructions**:
|
||||
|
||||
- Append review results in QA Results section
|
||||
- Document refactoring performed with explanations
|
||||
- Note security and performance considerations
|
||||
|
||||
#### How Agents Pass Information
|
||||
|
||||
##### SM → Dev Flow
|
||||
|
||||
The SM prepares the story with:
|
||||
|
||||
- **Dev Notes**: Specific technical guidance extracted from architecture
|
||||
- **Testing Requirements**: Unit, integration, and E2E test specifications
|
||||
- **Tasks/Subtasks**: Detailed implementation steps with AC mappings
|
||||
|
||||
##### Dev → SM Flow
|
||||
|
||||
The Dev agent provides feedback through:
|
||||
|
||||
- **Completion Notes**: Deviations or discoveries that impact future stories
|
||||
- **Debug Log References**: Technical challenges and solutions
|
||||
- **File List**: Complete inventory of created/modified files
|
||||
- **Change Log**: Any requirement modifications during development
|
||||
|
||||
##### QA → SM Flow
|
||||
|
||||
The QA agent contributes:
|
||||
|
||||
- **Code Quality Assessment**: Senior developer perspective on implementation quality
|
||||
- **Refactoring Performed**: Direct code improvements with:
|
||||
- What was changed
|
||||
- Why the change was made
|
||||
- How it improves the code
|
||||
- **Compliance Results**: Verification against coding standards, project structure, and testing strategy
|
||||
- **Test Coverage**: Added tests for critical missing coverage
|
||||
- **Security Review**: Any security concerns found and whether addressed
|
||||
- **Performance Considerations**: Performance issues found and optimizations made
|
||||
- **Improvements Checklist**: Items completed (marked [x]) vs. items for Dev to address (marked [ ])
|
||||
- **Learning Opportunities**: Explanations for junior/mid-level developer growth
|
||||
|
||||
#### Example: How Notes Flow Between Stories
|
||||
|
||||
**Story 1.1 Completion**:
|
||||
|
||||
```markdown
|
||||
### Completion Notes List
|
||||
|
||||
- Discovered that user authentication requires additional session management not specified in architecture
|
||||
- Created new SessionManager service in services/auth/session-manager.ts
|
||||
- Recommend updating architecture to include session management patterns
|
||||
```
|
||||
|
||||
**Story 1.2 Creation** (SM uses the above notes):
|
||||
|
||||
```markdown
|
||||
## Dev Notes
|
||||
|
||||
### Previous Story Insights
|
||||
|
||||
- Story 1.1 created SessionManager service for auth (services/auth/session-manager.ts)
|
||||
- Consider using SessionManager for this story's user profile feature
|
||||
- Architecture update pending for session management patterns
|
||||
```
|
||||
|
||||
This continuous feedback loop ensures each story benefits from lessons learned in previous implementations.
|
||||
|
||||
#### QA Agent Key Principles
|
||||
|
||||
When the QA agent performs the review-story task:
|
||||
|
||||
- **Senior Developer Authority**: Reviews as a senior developer with authority to refactor directly
|
||||
- **Active Improvement**: Makes code improvements rather than just identifying issues
|
||||
- **Teaching Focus**: Explains all changes for developer learning and growth
|
||||
- **Pragmatic Balance**: Focuses on significant improvements, not nitpicks
|
||||
- **Quality Gates**: Can block story completion if critical issues exist
|
||||
|
||||
**QA Blocking Conditions**:
|
||||
The QA will stop 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 require discussion
|
||||
|
||||
- **Benefits of QA Review**:
|
||||
- Code quality improvements and refactoring
|
||||
- Knowledge transfer through documented explanations
|
||||
- Catching edge cases and security issues
|
||||
- Ensuring architectural consistency
|
||||
|
||||
### Workflow Types
|
||||
|
||||
@@ -528,7 +775,7 @@ Web UI agents focus on planning and documentation. Here's how to interact with e
|
||||
|
||||
### Dynamic Resource Loading
|
||||
|
||||
BMAD's dependency system ensures agents only load necessary resources:
|
||||
BMad's dependency system ensures agents only load necessary resources:
|
||||
|
||||
- **Templates**: Only relevant document templates
|
||||
- **Tasks**: Only required automation tasks
|
||||
@@ -595,7 +842,7 @@ phases:
|
||||
|
||||
Templates are self-contained documents that embed both output structure and processing instructions. Follow these patterns from existing templates:
|
||||
|
||||
#### Template Structure
|
||||
#### Template Structure Example
|
||||
|
||||
```markdown
|
||||
# {{Project Name}} Document Title
|
||||
@@ -1135,7 +1382,7 @@ Add specialized capabilities:
|
||||
- **Data Pack**: Analytics, ML integration
|
||||
- **Security Pack**: Security analysis, compliance
|
||||
|
||||
## Troubleshooting
|
||||
## Troubleshooting Guide
|
||||
|
||||
### Common Issues
|
||||
|
||||
@@ -1178,7 +1425,7 @@ Add specialized capabilities:
|
||||
- **Documentation**: [Browse docs](https://github.com/bmadcode/bmad-method/tree/main/docs)
|
||||
- **YouTube**: [BMadCode Channel](https://www.youtube.com/@BMadCode)
|
||||
|
||||
## Best Practices
|
||||
## Best Practices and Tips
|
||||
|
||||
### Project Organization
|
||||
|
||||
@@ -1201,7 +1448,7 @@ project/
|
||||
- Version control all BMAD-generated content
|
||||
- Regular backups of `.bmad-core/` customizations
|
||||
|
||||
### Development Workflow
|
||||
### Recommended Development Flow
|
||||
|
||||
#### Planning Phase
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## Automated Releases (Recommended)
|
||||
|
||||
The easiest way to release new versions is through **automatic semantic releases**. Just commit with the right message format and push - everything else happens automatically!
|
||||
The easiest way to release new versions is through **automatic semantic releases**. Just commit with the right message format and push and everything else happens automatically.
|
||||
|
||||
### Commit Message Format
|
||||
|
||||
@@ -58,7 +58,7 @@ npm run release:test # Safe to run locally - tests the config
|
||||
|
||||
## Manual Release Methods (Exceptions Only)
|
||||
|
||||
**⚠️ Only use these methods if you need to bypass the automatic system**
|
||||
⚠️ Only use these methods if you need to bypass the automatic system
|
||||
|
||||
### Quick Manual Version Bump
|
||||
|
||||
@@ -75,11 +75,3 @@ git push && git push --tags
|
||||
### Manual GitHub Actions Trigger
|
||||
|
||||
You can also trigger releases manually through GitHub Actions workflow dispatch if needed.
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
**For 99% of releases**: Just use `fix:` or `feat:` commit messages and push. Everything else is automatic!
|
||||
|
||||
**Manual methods**: Only needed for special cases or if you want to bypass the automated system.
|
||||
|
||||
@@ -16,7 +16,6 @@ Guiding Principles of V4:
|
||||
- Helpers for installers and web builders that will work with any OS and IDE easily
|
||||
- Align all agents to be the same for IDE and Web, without losing the power of the web versions, or the leanness of the files in the IDE to reduce context
|
||||
- Further improvements to the two most important agents - the SM and DEV
|
||||
- Expansion Packs - Coming soon...
|
||||
|
||||
## V3
|
||||
|
||||
|
||||
@@ -1,129 +0,0 @@
|
||||
# BMAD Method Guide for Windsurf
|
||||
|
||||
This guide walks you through the complete BMAD workflow using Windsurf as your AI-powered IDE.
|
||||
|
||||
## Step 1: Install BMAD in Your Project
|
||||
|
||||
1. Navigate to your project directory
|
||||
2. Run the BMAD installer:
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
3. When prompted:
|
||||
- **Installation Type**: Choose "Complete installation (recommended)"
|
||||
- **IDE**: Select "Windsurf"
|
||||
|
||||
This creates a `.bmad-core` folder with all agents and a `.windsurf/rules` folder with agent rules.
|
||||
|
||||
## Step 2: Set Up Team Fullstack in Gemini
|
||||
|
||||
For ideation and planning, use Google's Gemini Custom Gem with the team-fullstack configuration:
|
||||
|
||||
1. Open [Google gems](https://gemini.google.com/gems/view)
|
||||
2. Create a new Gem - give it a title and description
|
||||
3. Copy the contents of `.<install location>/<web-bundles>/teams/team-fullstack.txt` (location can vary if you chose a non default installation location for the bundles) - or just use the bundle premade from the repo dist folder.
|
||||
4. Paste this content into Gemini to set up the team
|
||||
|
||||
### Gemini Planning Phase
|
||||
|
||||
In Gemini, ask the BMAD team to help you:
|
||||
|
||||
- **Ideate** your project concept
|
||||
- **Brainstorm** features and requirements
|
||||
- **Create a PRD** (Product Requirements Document)
|
||||
- **Design the architecture**
|
||||
|
||||
Ask questions like:
|
||||
|
||||
- "Help me brainstorm a [type of application] that does [core functionality]"
|
||||
- "Create a comprehensive PRD for this concept"
|
||||
- "Design the technical architecture for this system"
|
||||
|
||||
Copy the PRD and architecture documents that Gemini creates into your project's `docs/` folder:
|
||||
|
||||
- `docs/prd.md`
|
||||
- `docs/architecture.md`
|
||||
|
||||
## Step 3: Back to Windsurf - Document Sharding
|
||||
|
||||
Once you have your PRD and architecture documents in the `docs/` folder:
|
||||
|
||||
1. **Start a new chat in Windsurf**
|
||||
2. **Load the bmad-master agent**: Type `@bmad-master`
|
||||
3. **Shard the PRD**: Type `*shard-doc docs/prd.md prd`
|
||||
4. **Shard the architecture**: Type `*shard-doc docs/architecture.md architecture`
|
||||
|
||||
This creates organized folders:
|
||||
|
||||
- `docs/prd/` - Contains broken down PRD sections
|
||||
- `docs/architecture/` - Contains broken down architecture sections
|
||||
|
||||
## Step 4: Story Development Cycle
|
||||
|
||||
Now begin the iterative development cycle:
|
||||
|
||||
### Create Stories (Scrum Master)
|
||||
|
||||
1. **Start a new chat**
|
||||
2. **Load SM agent**: Type `@sm`
|
||||
3. **Create story**: Type `*create` (this runs the create-next-story task)
|
||||
4. **Review the generated story**
|
||||
5. **If approved**: Set story status to "Approved" in the story file
|
||||
|
||||
### Implement Stories (Developer)
|
||||
|
||||
1. **Start a new chat**
|
||||
2. **Load Dev agent**: Type `@dev`
|
||||
3. **The agent will ask which story to implement**
|
||||
4. **Follow the development tasks** the agent provides
|
||||
5. **When story is complete**: Mark status as "Done"
|
||||
|
||||
### Repeat the Cycle
|
||||
|
||||
1. **Start a new chat with SM agent** (`@sm`)
|
||||
2. **Create next story**: Type `*create`
|
||||
3. **Review and approve**
|
||||
4. **Start new chat with Dev agent** (`@dev`)
|
||||
5. **Implement the story**
|
||||
6. **Repeat until project complete**
|
||||
|
||||
## Available Agent Rules in Windsurf
|
||||
|
||||
All BMAD agents are available as Windsurf rules (use `@` prefix):
|
||||
|
||||
- `@bmad-master` - Universal task executor
|
||||
- `@sm` - Scrum Master for story creation
|
||||
- `@dev` - Full-stack developer for implementation
|
||||
- `@architect` - Solution architect for design
|
||||
- `@pm` - Product manager for planning
|
||||
- `@analyst` - Business analyst for requirements
|
||||
- `@qa` - QA specialist for testing
|
||||
- `@po` - Product owner for prioritization
|
||||
- `@ux-expert` - UX specialist for design
|
||||
|
||||
## Windsurf-Specific Features
|
||||
|
||||
- **Agent rules are stored in**: `.windsurf/rules/` as `.md` files
|
||||
- **Rule activation**: Rules activate when you mention `@agent-name` in chat
|
||||
- **Collaborative workflow**: Windsurf's collaborative features work well with BMAD's agent-switching pattern
|
||||
- **Context awareness**: Agents have access to your project context
|
||||
|
||||
## Key Workflow Principles
|
||||
|
||||
1. **Always start new chats** when switching agents to avoid context confusion
|
||||
2. **Use Gemini for initial planning** and ideation with the team-fullstack bundle
|
||||
3. **Use bmad-master for document management** (sharding, templates, etc.)
|
||||
4. **Follow the SM → Dev cycle** for consistent story development
|
||||
5. **Review and approve stories** before implementation begins
|
||||
|
||||
## Tips for Success
|
||||
|
||||
- **Keep chats focused**: Each chat should have one agent and one primary task
|
||||
- **Use \*help command**: Every agent supports `*help` to see available commands
|
||||
- **Review generated content**: Always review and approve stories before marking them ready
|
||||
- **Maintain status updates**: Keep story statuses current (Draft → Approved → InProgress → Done)
|
||||
- **Leverage Windsurf's collaboration**: Use the collaborative features for team reviews
|
||||
|
||||
This workflow ensures systematic, AI-assisted development following agile principles with clear handoffs between planning, story creation, and implementation phases.
|
||||
@@ -1,22 +1,18 @@
|
||||
# Working in the Brownfield: A Complete Guide
|
||||
|
||||
> 🚀 **HIGHLY RECOMMENDED: Use Gemini Web for Brownfield Documentation!**
|
||||
> 🚀 **HIGHLY RECOMMENDED: Use Gemini Web or Gemini CLI for Brownfield Documentation!**
|
||||
>
|
||||
> Gemini Web's 1M+ token context window can analyze your ENTIRE codebase at once:
|
||||
> Gemini Web's 1M+ token context window or Gemini CLI (when its working) 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:
|
||||
## When to Use BMad for Brownfield
|
||||
|
||||
- Add significant new features to existing applications
|
||||
- Modernize legacy codebases
|
||||
@@ -29,7 +25,7 @@ BMAD-METHOD excels at brownfield development when you need to:
|
||||
|
||||
### Choose Your Approach
|
||||
|
||||
#### Approach A: PRD-First (Recommended for Large Codebases/Monorepos)
|
||||
#### Approach A: PRD-First (Recommended if adding very large and complex new features, single or multiple epics or massive changes)
|
||||
|
||||
**Best for**: Large codebases, monorepos, or when you know exactly what you want to build
|
||||
|
||||
@@ -116,7 +112,7 @@ The analyst will generate comprehensive documentation of everything.
|
||||
|
||||
#### Option A: Full Brownfield Workflow (Recommended for Major Changes)
|
||||
|
||||
**1. Create Brownfield PRD**
|
||||
**1. Create Brownfield PRD**:
|
||||
|
||||
```bash
|
||||
@pm
|
||||
@@ -143,7 +139,7 @@ The PM agent will:
|
||||
- "What are the critical constraints we must respect?"
|
||||
- "What is your timeline and team size?"
|
||||
|
||||
**2. Create Brownfield Architecture**
|
||||
**2. Create Brownfield Architecture**:
|
||||
|
||||
```bash
|
||||
@architect
|
||||
|
||||
5
expansion-packs/bmad-2d-phaser-game-dev/config.yml
Normal file
5
expansion-packs/bmad-2d-phaser-game-dev/config.yml
Normal file
@@ -0,0 +1,5 @@
|
||||
name: bmad-2d-phaser-game-dev
|
||||
version: 1.1.0
|
||||
short-title: 2D game development with Phaser 3 & TypeScript
|
||||
description: 2D Game Development expansion pack for BMAD Method - Phaser 3 & TypeScript focused
|
||||
author: Brian (BMad)
|
||||
@@ -1,45 +0,0 @@
|
||||
name: bmad-2d-phaser-game-dev
|
||||
version: 1.0.0
|
||||
description: 2D Game Development expansion pack for BMAD Method - Phaser 3 & TypeScript focused
|
||||
author: BMAD Team
|
||||
files:
|
||||
- source: agents/game-designer.md
|
||||
destination: .bmad-core/agents/game-designer.md
|
||||
- source: agents/game-developer.md
|
||||
destination: .bmad-core/agents/game-developer.md
|
||||
- source: agents/game-sm.md
|
||||
destination: .bmad-core/agents/game-sm.md
|
||||
- source: team-game-dev.yml
|
||||
destination: .bmad-core/agent-teams/team-game-dev.yml
|
||||
- source: templates/game-design-doc-tmpl.md
|
||||
destination: .bmad-core/templates/game-design-doc-tmpl.md
|
||||
- source: templates/game-architecture-tmpl.md
|
||||
destination: .bmad-core/templates/game-architecture-tmpl.md
|
||||
- source: templates/level-design-doc-tmpl.md
|
||||
destination: .bmad-core/templates/level-design-doc-tmpl.md
|
||||
- source: templates/game-story-tmpl.md
|
||||
destination: .bmad-core/templates/game-story-tmpl.md
|
||||
- source: templates/game-brief-tmpl.md
|
||||
destination: .bmad-core/templates/game-brief-tmpl.md
|
||||
- source: tasks/create-game-story.md
|
||||
destination: .bmad-core/tasks/create-game-story.md
|
||||
- source: tasks/game-design-brainstorming.md
|
||||
destination: .bmad-core/tasks/game-design-brainstorming.md
|
||||
- source: tasks/advanced-elicitation.md
|
||||
destination: .bmad-core/tasks/advanced-elicitation.md
|
||||
- source: checklists/game-story-dod-checklist.md
|
||||
destination: .bmad-core/checklists/game-story-dod-checklist.md
|
||||
- source: checklists/game-design-checklist.md
|
||||
destination: .bmad-core/checklists/game-design-checklist.md
|
||||
- source: data/bmad-kb.md
|
||||
destination: .bmad-core/data/bmad-kb.md
|
||||
- source: data/development-guidelines.md
|
||||
destination: .bmad-core/data/development-guidelines.md
|
||||
- source: workflows/game-dev-greenfield.yml
|
||||
destination: .bmad-core/workflows/game-dev-greenfield.yml
|
||||
- source: workflows/game-prototype.yml
|
||||
destination: .bmad-core/workflows/game-prototype.yml
|
||||
dependencies:
|
||||
- architect
|
||||
- developer
|
||||
- sm
|
||||
5
expansion-packs/bmad-creator-tools/config.yml
Normal file
5
expansion-packs/bmad-creator-tools/config.yml
Normal file
@@ -0,0 +1,5 @@
|
||||
name: bmad-creator-tools
|
||||
version: 1.0.0
|
||||
short-title: Tools for creating BMAD framework components
|
||||
description: Tools for creating and extending BMAD framework components.
|
||||
author: Brian (BMad)
|
||||
@@ -436,17 +436,17 @@ IMPORTANT: Work through plan.md checklist systematically!
|
||||
|
||||
**Step 2: Copy Core Utilities**
|
||||
|
||||
Before proceeding, copy these essential files from bmad-core:
|
||||
Before proceeding, copy these essential files from common:
|
||||
|
||||
```bash
|
||||
# Copy core task utilities
|
||||
cp bmad-core/tasks/create-doc.md expansion-packs/{pack-name}/tasks/
|
||||
cp bmad-core/tasks/execute-checklist.md expansion-packs/{pack-name}/tasks/
|
||||
cp common/tasks/create-doc.md expansion-packs/{pack-name}/tasks/
|
||||
cp common/tasks/execute-checklist.md expansion-packs/{pack-name}/tasks/
|
||||
|
||||
# Copy core utility files
|
||||
mkdir -p expansion-packs/{pack-name}/utils
|
||||
cp bmad-core/utils/template-format.md expansion-packs/{pack-name}/utils/
|
||||
cp bmad-core/utils/workflow-management.md expansion-packs/{pack-name}/utils/
|
||||
cp common/utils/template-format.md expansion-packs/{pack-name}/utils/
|
||||
cp common/utils/workflow-management.md expansion-packs/{pack-name}/utils/
|
||||
```
|
||||
|
||||
**Step 3: Technical Implementation**
|
||||
5
expansion-packs/bmad-infrastructure-devops/config.yml
Normal file
5
expansion-packs/bmad-infrastructure-devops/config.yml
Normal file
@@ -0,0 +1,5 @@
|
||||
name: bmad-infrastructure-devops
|
||||
version: 1.0.0
|
||||
short-title: Infrastructure and DevOps capabilities
|
||||
description: This expansion pack extends BMAD Method with comprehensive infrastructure and DevOps capabilities. It's designed for teams that need to define, implement, and manage cloud infrastructure alongside their application development.
|
||||
author: Brian (BMad)
|
||||
@@ -1,23 +0,0 @@
|
||||
name: bmad-infrastructure-devops
|
||||
version: 1.0.0
|
||||
description: Infrastructure & DevOps expansion pack for BMAD Method - Platform engineering and cloud infrastructure focused
|
||||
author: BMAD Team
|
||||
files:
|
||||
- source: agents/infra-devops-platform.md
|
||||
destination: .bmad-core/agents/infra-devops-platform.md
|
||||
- source: templates/infrastructure-architecture-tmpl.md
|
||||
destination: .bmad-core/templates/infrastructure-architecture-tmpl.md
|
||||
- source: templates/infrastructure-platform-from-arch-tmpl.md
|
||||
destination: .bmad-core/templates/infrastructure-platform-from-arch-tmpl.md
|
||||
- source: tasks/create-doc.md
|
||||
destination: .bmad-core/tasks/create-doc.md
|
||||
- source: tasks/review-infrastructure.md
|
||||
destination: .bmad-core/tasks/review-infrastructure.md
|
||||
- source: tasks/validate-infrastructure.md
|
||||
destination: .bmad-core/tasks/validate-infrastructure.md
|
||||
- source: checklists/infrastructure-checklist.md
|
||||
destination: .bmad-core/checklists/infrastructure-checklist.md
|
||||
dependencies:
|
||||
- architect
|
||||
- operations-specialist
|
||||
- security-specialist
|
||||
@@ -1,74 +0,0 @@
|
||||
# Create Document from Template Task
|
||||
|
||||
## Purpose
|
||||
|
||||
- Generate documents from any specified template following embedded instructions from the perspective of the selected agent persona
|
||||
|
||||
## Instructions
|
||||
|
||||
### 1. Identify Template and Context
|
||||
|
||||
- Determine which template to use (user-provided or list available for selection to user)
|
||||
|
||||
- Agent-specific templates are listed in the agent's dependencies under `templates`. For each template listed, consider it a document the agent can create. So if an agent has:
|
||||
|
||||
@{example}
|
||||
dependencies:
|
||||
templates: - prd-tmpl - architecture-tmpl
|
||||
@{/example}
|
||||
|
||||
You would offer to create "PRD" and "Architecture" documents when the user asks what you can help with.
|
||||
|
||||
- Gather all relevant inputs, or ask for them, or else rely on user providing necessary details to complete the document
|
||||
- Understand the document purpose and target audience
|
||||
|
||||
### 2. Determine Interaction Mode
|
||||
|
||||
Confirm with the user their preferred interaction style:
|
||||
|
||||
- **Incremental:** Work through chunks of the document.
|
||||
- **YOLO Mode:** Draft complete document making reasonable assumptions in one shot. (Can be entered also after starting incremental by just typing /yolo)
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
#### CRITICAL: Never display template markup, LLM instructions, or examples to users
|
||||
|
||||
- Replace all {{placeholders}} with actual content
|
||||
- Execute all [[LLM: instructions]] internally
|
||||
- Process `<<REPEAT>>` sections as needed
|
||||
- Evaluate ^^CONDITION^^ blocks and include only if applicable
|
||||
- Use @{examples} for guidance but never output them
|
||||
|
||||
### 5. Content Generation
|
||||
|
||||
- **Incremental Mode**: Present each major section for review before proceeding
|
||||
- **YOLO Mode**: Generate all sections, then review complete document with user
|
||||
- Apply any elicitation protocols specified in template
|
||||
- Incorporate user feedback and iterate as needed
|
||||
|
||||
### 6. Validation
|
||||
|
||||
If template specifies a checklist:
|
||||
|
||||
- Run the appropriate checklist against completed document
|
||||
- Document completion status for each item
|
||||
- Address any deficiencies found
|
||||
- Present validation summary to user
|
||||
|
||||
### 7. Final Presentation
|
||||
|
||||
- Present clean, formatted content only
|
||||
- Ensure all sections are complete
|
||||
- DO NOT truncate or summarize content
|
||||
- Begin directly with document content (no preamble)
|
||||
- Include any handoff prompts specified in template
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Template markup is for AI processing only - never expose to users
|
||||
@@ -1,12 +0,0 @@
|
||||
name: bmad-creator-tools
|
||||
version: 1.0.0
|
||||
description: Tools for creating and extending BMAD framework components
|
||||
type: creator-tools
|
||||
compatibility:
|
||||
bmad-version: '>=4.0.0'
|
||||
components:
|
||||
agents:
|
||||
- bmad-the-creator
|
||||
tasks:
|
||||
- create-agent
|
||||
- generate-expansion-pack
|
||||
@@ -1,26 +0,0 @@
|
||||
# Template Format Conventions
|
||||
|
||||
Templates in the BMAD method use standardized markup for AI processing. These conventions ensure consistent document generation.
|
||||
|
||||
## Template Markup Elements
|
||||
|
||||
- **{{placeholders}}**: Variables to be replaced with actual content
|
||||
- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
|
||||
- **REPEAT** sections: Content blocks that may be repeated as needed
|
||||
- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
|
||||
- **@{examples}**: Example content for guidance (never output to users)
|
||||
|
||||
## Processing Rules
|
||||
|
||||
- Replace all {{placeholders}} with project-specific content
|
||||
- Execute all [[LLM: instructions]] internally without showing users
|
||||
- Process conditional and repeat blocks as specified
|
||||
- Use examples for guidance but never include them in final output
|
||||
- Present only clean, formatted content to users
|
||||
|
||||
## Critical Guidelines
|
||||
|
||||
- **NEVER display template markup, LLM instructions, or examples to users**
|
||||
- Template elements are for AI processing only
|
||||
- Focus on faithful template execution and clean output
|
||||
- All template-specific instructions are embedded within templates
|
||||
@@ -1,223 +0,0 @@
|
||||
# Workflow Management
|
||||
|
||||
This utility enables the BMAD orchestrator to manage and execute team workflows.
|
||||
|
||||
## Important: Dynamic Workflow Loading
|
||||
|
||||
The BMAD orchestrator MUST read the available workflows from the current team configuration's `workflows` field. Do not use hardcoded workflow lists. Each team bundle defines its own set of supported workflows based on the agents it includes.
|
||||
|
||||
**Critical Distinction**:
|
||||
|
||||
- When asked "what workflows are available?", show ONLY the workflows defined in the current team bundle's configuration
|
||||
- Use `/agent-list` to show agents in the current bundle
|
||||
- Use `/workflows` to show workflows in the current bundle, NOT any creation tasks
|
||||
|
||||
### Workflow Descriptions
|
||||
|
||||
When displaying workflows, use these descriptions based on the workflow ID:
|
||||
|
||||
- **greenfield-fullstack**: Build a new full-stack application from concept to development
|
||||
- **brownfield-fullstack**: Enhance an existing full-stack application with new features
|
||||
- **greenfield-service**: Build a new backend service or API from concept to development
|
||||
- **brownfield-service**: Enhance an existing backend service or API
|
||||
- **greenfield-ui**: Build a new frontend/UI application from concept to development
|
||||
- **brownfield-ui**: Enhance an existing frontend/UI application
|
||||
|
||||
## Workflow Commands
|
||||
|
||||
### /workflows
|
||||
|
||||
Lists all available workflows for the current team. The available workflows are determined by the team configuration and may include workflows such as:
|
||||
|
||||
- greenfield-fullstack
|
||||
- brownfield-fullstack
|
||||
- greenfield-service
|
||||
- brownfield-service
|
||||
- greenfield-ui
|
||||
- brownfield-ui
|
||||
|
||||
The actual list depends on which team bundle is loaded. When responding to this command, display the workflows that are configured in the current team's `workflows` field.
|
||||
|
||||
Example response format:
|
||||
|
||||
```text
|
||||
Available workflows for [Team Name]:
|
||||
1. [workflow-id] - [Brief description based on workflow type]
|
||||
2. [workflow-id] - [Brief description based on workflow type]
|
||||
[... etc. ...]
|
||||
|
||||
Use /workflow-start {number or id} to begin a workflow.
|
||||
```
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
|
||||
Starts a specific workflow and transitions to the first agent.
|
||||
|
||||
Example: `/workflow-start greenfield-fullstack`
|
||||
|
||||
### /workflow-status
|
||||
|
||||
Shows current workflow progress, completed artifacts, and next steps.
|
||||
|
||||
Example response:
|
||||
|
||||
```text
|
||||
Current Workflow: Greenfield Full-Stack Development
|
||||
Stage: Product Planning (2 of 6)
|
||||
Completed:
|
||||
✓ Discovery & Requirements
|
||||
- project-brief (completed by Mary)
|
||||
|
||||
In Progress:
|
||||
⚡ Product Planning
|
||||
- Create PRD (John) - awaiting input
|
||||
|
||||
Next: Technical Architecture
|
||||
```
|
||||
|
||||
### /workflow-resume
|
||||
|
||||
Resumes a workflow from where it left off, useful when starting a new chat.
|
||||
|
||||
User can provide completed artifacts:
|
||||
|
||||
```text
|
||||
User: /workflow-resume greenfield-fullstack
|
||||
I have completed: project-brief, PRD
|
||||
BMad: I see you've completed Discovery and part of Product Planning.
|
||||
Based on the greenfield-fullstack workflow, the next step is:
|
||||
- UX Strategy with Sally (ux-expert)
|
||||
|
||||
Would you like me to load Sally to continue?
|
||||
```
|
||||
|
||||
### /workflow-next
|
||||
|
||||
Shows the next recommended agent and action in the current workflow.
|
||||
|
||||
## Workflow Execution Flow
|
||||
|
||||
### 1. Starting a Workflow
|
||||
|
||||
When a workflow is started:
|
||||
|
||||
1. Load the workflow definition
|
||||
2. Identify the first stage and step
|
||||
3. Transition to the required agent
|
||||
4. Provide context about expected inputs/outputs
|
||||
5. Guide artifact creation
|
||||
|
||||
### 2. Stage Transitions
|
||||
|
||||
After each artifact is completed:
|
||||
|
||||
1. Mark the step as complete
|
||||
2. Check transition conditions
|
||||
3. If stage is complete, move to next stage
|
||||
4. Load the appropriate agent
|
||||
5. Pass relevant artifacts as context
|
||||
|
||||
### 3. Artifact Tracking
|
||||
|
||||
Track all created artifacts:
|
||||
|
||||
```yaml
|
||||
workflow_state:
|
||||
current_workflow: greenfield-fullstack
|
||||
current_stage: planning
|
||||
current_step: 2
|
||||
artifacts:
|
||||
project-brief:
|
||||
status: completed
|
||||
created_by: analyst
|
||||
timestamp: 2024-01-15T10:30:00.000Z
|
||||
prd:
|
||||
status: in-progress
|
||||
created_by: pm
|
||||
started: 2024-01-15T11:00:00.000Z
|
||||
```
|
||||
|
||||
### 4. Workflow Interruption Handling
|
||||
|
||||
When user returns after interruption:
|
||||
|
||||
1. Ask if continuing previous workflow
|
||||
2. Request any completed artifacts
|
||||
3. Analyze provided artifacts
|
||||
4. Determine workflow position
|
||||
5. Suggest next appropriate step
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
User: I'm working on a new app. Here's my PRD and architecture doc.
|
||||
BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||
it looks like you're following the greenfield-fullstack workflow and have completed
|
||||
stages 1-3. The next recommended step would be:
|
||||
|
||||
Stage 4: Validation & Refinement
|
||||
- Load Sarah (Product Owner) to validate all artifacts
|
||||
|
||||
Would you like to continue with this workflow?
|
||||
```
|
||||
|
||||
## Workflow Context Passing
|
||||
|
||||
When transitioning between agents, pass:
|
||||
|
||||
1. Previous artifacts created
|
||||
2. Current workflow stage
|
||||
3. Expected outputs
|
||||
4. Any decisions or constraints identified
|
||||
|
||||
Example transition:
|
||||
|
||||
```text
|
||||
BMad: Great! John has completed the PRD. According to the greenfield-fullstack workflow,
|
||||
the next step is UX Strategy with Sally.
|
||||
|
||||
/ux-expert
|
||||
|
||||
Sally: I see we're in the Product Planning stage of the greenfield-fullstack workflow.
|
||||
I have access to:
|
||||
- Project Brief from Mary
|
||||
- PRD from John
|
||||
|
||||
Let's create the UX strategy and UI specifications. First, let me review
|
||||
the PRD to understand the features we're designing for...
|
||||
```
|
||||
|
||||
## Multi-Path Workflows
|
||||
|
||||
Some workflows may have multiple paths:
|
||||
|
||||
```yaml
|
||||
conditional_paths:
|
||||
- condition: project_type == 'mobile'
|
||||
next_stage: mobile-specific-design
|
||||
- condition: project_type == 'web'
|
||||
next_stage: web-architecture
|
||||
- default: fullstack-architecture
|
||||
```
|
||||
|
||||
Handle these by asking clarifying questions when needed.
|
||||
|
||||
## Workflow Best Practices
|
||||
|
||||
1. **Always show progress** - Users should know where they are
|
||||
2. **Explain transitions** - Why moving to next agent
|
||||
3. **Preserve context** - Pass relevant information forward
|
||||
4. **Allow flexibility** - Users can skip or modify steps
|
||||
5. **Track everything** - Maintain complete workflow state
|
||||
|
||||
## Integration with Agents
|
||||
|
||||
Each agent should be workflow-aware:
|
||||
|
||||
- Know which workflow is active
|
||||
- Understand their role in the workflow
|
||||
- Access previous artifacts
|
||||
- Know expected outputs
|
||||
- Guide toward workflow goals
|
||||
|
||||
This creates a seamless experience where the entire team works together toward the workflow's objectives.
|
||||
4
package-lock.json
generated
4
package-lock.json
generated
@@ -1,12 +1,12 @@
|
||||
{
|
||||
"name": "bmad-method",
|
||||
"version": "4.14.0",
|
||||
"version": "4.20.0",
|
||||
"lockfileVersion": 3,
|
||||
"requires": true,
|
||||
"packages": {
|
||||
"": {
|
||||
"name": "bmad-method",
|
||||
"version": "4.14.0",
|
||||
"version": "4.20.0",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"@kayvan/markdown-tree-parser": "^1.5.0",
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "bmad-method",
|
||||
"version": "4.14.0",
|
||||
"version": "4.20.0",
|
||||
"description": "Breakthrough Method of Agile AI-driven Development",
|
||||
"main": "tools/cli.js",
|
||||
"bin": {
|
||||
|
||||
41
test-ide-paths.js
Normal file
41
test-ide-paths.js
Normal file
@@ -0,0 +1,41 @@
|
||||
// Test script to verify IDE setup paths for expansion pack agents
|
||||
const path = require('path');
|
||||
const fs = require('fs-extra');
|
||||
|
||||
// Simulate the findAgentPath logic
|
||||
function simulateFindAgentPath(agentId, installDir) {
|
||||
const possiblePaths = [
|
||||
path.join(installDir, ".bmad-core", "agents", `${agentId}.md`),
|
||||
path.join(installDir, "agents", `${agentId}.md`),
|
||||
// Expansion pack paths
|
||||
path.join(installDir, ".bmad-2d-phaser-game-dev", "agents", `${agentId}.md`),
|
||||
path.join(installDir, ".bmad-infrastructure-devops", "agents", `${agentId}.md`),
|
||||
path.join(installDir, ".bmad-creator-tools", "agents", `${agentId}.md`)
|
||||
];
|
||||
|
||||
// Simulate finding the agent in an expansion pack
|
||||
if (agentId === 'game-developer') {
|
||||
return path.join(installDir, ".bmad-2d-phaser-game-dev", "agents", `${agentId}.md`);
|
||||
}
|
||||
|
||||
// Default to core
|
||||
return path.join(installDir, ".bmad-core", "agents", `${agentId}.md`);
|
||||
}
|
||||
|
||||
// Test different scenarios
|
||||
const testDir = '/project';
|
||||
const agents = ['dev', 'game-developer', 'infra-devops-platform'];
|
||||
|
||||
console.log('Testing IDE path references:\n');
|
||||
|
||||
agents.forEach(agentId => {
|
||||
const agentPath = simulateFindAgentPath(agentId, testDir);
|
||||
const relativePath = path.relative(testDir, agentPath).replace(/\\/g, '/');
|
||||
|
||||
console.log(`Agent: ${agentId}`);
|
||||
console.log(` Full path: ${agentPath}`);
|
||||
console.log(` Relative path: ${relativePath}`);
|
||||
console.log(` Roo customInstructions: CRITICAL Read the full YML from ${relativePath} ...`);
|
||||
console.log(` Cursor MDC reference: [${relativePath}](mdc:${relativePath})`);
|
||||
console.log('');
|
||||
});
|
||||
@@ -9,8 +9,8 @@ class WebBuilder {
|
||||
this.resolver = new DependencyResolver(this.rootDir);
|
||||
this.templatePath = path.join(
|
||||
this.rootDir,
|
||||
"bmad-core",
|
||||
"utils",
|
||||
"tools",
|
||||
"md-assets",
|
||||
"web-agent-startup-instructions.md"
|
||||
);
|
||||
}
|
||||
@@ -117,35 +117,39 @@ class WebBuilder {
|
||||
const yamlContent = yamlMatch[1];
|
||||
const yamlStartIndex = content.indexOf(yamlMatch[0]);
|
||||
const yamlEndIndex = yamlStartIndex + yamlMatch[0].length;
|
||||
|
||||
|
||||
// Parse YAML and remove root and IDE-FILE-RESOLUTION properties
|
||||
try {
|
||||
const yaml = require("js-yaml");
|
||||
const parsed = yaml.load(yamlContent);
|
||||
|
||||
|
||||
// Remove the properties if they exist at root level
|
||||
delete parsed.root;
|
||||
delete parsed['IDE-FILE-RESOLUTION'];
|
||||
delete parsed['REQUEST-RESOLUTION'];
|
||||
|
||||
delete parsed["IDE-FILE-RESOLUTION"];
|
||||
delete parsed["REQUEST-RESOLUTION"];
|
||||
|
||||
// Also remove from activation-instructions if they exist
|
||||
if (parsed['activation-instructions'] && Array.isArray(parsed['activation-instructions'])) {
|
||||
parsed['activation-instructions'] = parsed['activation-instructions'].filter(instruction => {
|
||||
return !instruction.startsWith('IDE-FILE-RESOLUTION:') &&
|
||||
!instruction.startsWith('REQUEST-RESOLUTION:');
|
||||
});
|
||||
if (parsed["activation-instructions"] && Array.isArray(parsed["activation-instructions"])) {
|
||||
parsed["activation-instructions"] = parsed["activation-instructions"].filter(
|
||||
(instruction) => {
|
||||
return (
|
||||
!instruction.startsWith("IDE-FILE-RESOLUTION:") &&
|
||||
!instruction.startsWith("REQUEST-RESOLUTION:")
|
||||
);
|
||||
}
|
||||
);
|
||||
}
|
||||
|
||||
|
||||
// Reconstruct the YAML
|
||||
const cleanedYaml = yaml.dump(parsed, { lineWidth: -1 });
|
||||
|
||||
|
||||
// Get the agent name from the YAML for the header
|
||||
const agentName = parsed.agent?.id || 'agent';
|
||||
|
||||
const agentName = parsed.agent?.id || "agent";
|
||||
|
||||
// Build the new content with just the agent header and YAML
|
||||
const newHeader = `# ${agentName}\n\nCRITICAL: Read the full YML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:\n\n`;
|
||||
const afterYaml = content.substring(yamlEndIndex);
|
||||
|
||||
|
||||
return newHeader + "```yaml\n" + cleanedYaml.trim() + "\n```" + afterYaml;
|
||||
} catch (error) {
|
||||
console.warn("Failed to process agent YAML:", error.message);
|
||||
@@ -156,12 +160,12 @@ class WebBuilder {
|
||||
|
||||
formatSection(path, content) {
|
||||
const separator = "====================";
|
||||
|
||||
|
||||
// Process agent content if this is an agent file
|
||||
if (path.startsWith("agents#")) {
|
||||
content = this.processAgentContent(content);
|
||||
}
|
||||
|
||||
|
||||
return [
|
||||
`${separator} START: ${path} ${separator}`,
|
||||
content.trim(),
|
||||
@@ -341,6 +345,28 @@ class WebBuilder {
|
||||
}
|
||||
}
|
||||
|
||||
// If not found in core, try common folder
|
||||
if (!found) {
|
||||
for (const ext of extensions) {
|
||||
const commonPath = path.join(
|
||||
this.rootDir,
|
||||
"common",
|
||||
resourceType,
|
||||
`${resourceName}${ext}`
|
||||
);
|
||||
try {
|
||||
const commonContent = await fs.readFile(commonPath, "utf8");
|
||||
sections.push(
|
||||
this.formatSection(`${resourceType}#${resourceName}`, commonContent)
|
||||
);
|
||||
found = true;
|
||||
break;
|
||||
} catch (error) {
|
||||
// Not in common either, continue
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (!found) {
|
||||
console.warn(
|
||||
` ⚠ Dependency ${resourceType}#${resourceName} not found in expansion pack or core`
|
||||
@@ -516,6 +542,21 @@ class WebBuilder {
|
||||
}
|
||||
}
|
||||
|
||||
// If not found in core, try common folder
|
||||
if (!found) {
|
||||
for (const ext of extensions) {
|
||||
const commonPath = path.join(this.rootDir, "common", dep.type, `${dep.name}${ext}`);
|
||||
try {
|
||||
const content = await fs.readFile(commonPath, "utf8");
|
||||
sections.push(this.formatSection(key, content));
|
||||
found = true;
|
||||
break;
|
||||
} catch (error) {
|
||||
// Not in common either, continue
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (!found) {
|
||||
console.warn(` ⚠ Dependency ${key} not found in expansion pack or core`);
|
||||
}
|
||||
|
||||
@@ -40,7 +40,7 @@ try {
|
||||
|
||||
program
|
||||
.version(version)
|
||||
.description('BMAD Method installer - AI-powered Agile development framework');
|
||||
.description('BMAD Method installer - Universal AI agent framework for any domain');
|
||||
|
||||
program
|
||||
.command('install')
|
||||
@@ -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, cline, other)')
|
||||
.option('-i, --ide <ide...>', 'Configure for specific IDE(s) - can specify multiple (cursor, claude-code, windsurf, roo, cline, gemini, other)')
|
||||
.option('-e, --expansion-packs <packs...>', 'Install specific expansion packs (can specify multiple)')
|
||||
.action(async (options) => {
|
||||
try {
|
||||
@@ -314,7 +314,8 @@ async function promptInstallation() {
|
||||
{ name: 'Claude Code', value: 'claude-code' },
|
||||
{ name: 'Windsurf', value: 'windsurf' },
|
||||
{ name: 'Roo Code', value: 'roo' },
|
||||
{ name: 'Cline', value: 'cline' }
|
||||
{ name: 'Cline', value: 'cline' },
|
||||
{ name: 'Gemini CLI', value: 'gemini' }
|
||||
]
|
||||
}
|
||||
]);
|
||||
@@ -328,7 +329,7 @@ async function promptInstallation() {
|
||||
type: 'confirm',
|
||||
name: 'includeWebBundles',
|
||||
message: 'Would you like to include pre-built web bundles? (standalone files for ChatGPT, Claude, Gemini)',
|
||||
default: true
|
||||
default: false
|
||||
}
|
||||
]);
|
||||
|
||||
|
||||
58
tools/installer/config/ide-agent-config.yml
Normal file
58
tools/installer/config/ide-agent-config.yml
Normal file
@@ -0,0 +1,58 @@
|
||||
# IDE-specific agent configurations
|
||||
# This file defines agent-specific settings for different IDEs
|
||||
|
||||
# Roo Code file permissions
|
||||
# Each agent can have restricted file access based on regex patterns
|
||||
# If an agent is not listed here, it gets full edit access
|
||||
roo-permissions:
|
||||
# Core agents
|
||||
analyst:
|
||||
fileRegex: "\\.(md|txt)$"
|
||||
description: "Documentation and text files"
|
||||
pm:
|
||||
fileRegex: "\\.(md|txt)$"
|
||||
description: "Product documentation"
|
||||
architect:
|
||||
fileRegex: "\\.(md|txt|yml|yaml|json)$"
|
||||
description: "Architecture docs and configs"
|
||||
qa:
|
||||
fileRegex: "\\.(test|spec)\\.(js|ts|jsx|tsx)$|\\.md$"
|
||||
description: "Test files and documentation"
|
||||
ux-expert:
|
||||
fileRegex: "\\.(md|css|scss|html|jsx|tsx)$"
|
||||
description: "Design-related files"
|
||||
po:
|
||||
fileRegex: "\\.(md|txt)$"
|
||||
description: "Story and requirement docs"
|
||||
sm:
|
||||
fileRegex: "\\.(md|txt)$"
|
||||
description: "Process and planning docs"
|
||||
# Expansion pack agents
|
||||
game-designer:
|
||||
fileRegex: "\\.(md|txt|json|yaml|yml)$"
|
||||
description: "Game design documents and configs"
|
||||
game-sm:
|
||||
fileRegex: "\\.(md|txt)$"
|
||||
description: "Game project management docs"
|
||||
|
||||
# Cline agent ordering
|
||||
# Lower numbers appear first in the list
|
||||
# Agents not listed get order 99
|
||||
cline-order:
|
||||
# Core agents
|
||||
bmad-master: 1
|
||||
bmad-orchestrator: 2
|
||||
pm: 3
|
||||
analyst: 4
|
||||
architect: 5
|
||||
po: 6
|
||||
sm: 7
|
||||
dev: 8
|
||||
qa: 9
|
||||
ux-expert: 10
|
||||
# Expansion pack agents
|
||||
bmad-the-creator: 11
|
||||
game-designer: 12
|
||||
game-developer: 13
|
||||
game-sm: 14
|
||||
infra-devops-platform: 15
|
||||
@@ -8,50 +8,6 @@ installation-options:
|
||||
name: Single Agent
|
||||
description: Select and install a single agent with its dependencies
|
||||
action: copy-agent
|
||||
agent-dependencies:
|
||||
core-files:
|
||||
- bmad-core/utils/template-format.md
|
||||
dev:
|
||||
- bmad-core/templates/story-tmpl.md
|
||||
- bmad-core/checklists/story-dod-checklist.md
|
||||
pm:
|
||||
- bmad-core/templates/prd-tmpl.md
|
||||
- bmad-core/templates/brownfield-prd-tmpl.md
|
||||
- bmad-core/checklists/pm-checklist.md
|
||||
- bmad-core/checklists/change-checklist.md
|
||||
- bmad-core/tasks/advanced-elicitation.md
|
||||
- bmad-core/tasks/create-doc.md
|
||||
- bmad-core/tasks/correct-course.md
|
||||
- bmad-core/tasks/create-deep-research-prompt.md
|
||||
- bmad-core/tasks/brownfield-create-epic.md
|
||||
- bmad-core/tasks/brownfield-create-story.md
|
||||
- bmad-core/tasks/execute-checklist.md
|
||||
- bmad-core/tasks/shard-doc.md
|
||||
architect:
|
||||
- bmad-core/templates/architecture-tmpl.md
|
||||
- bmad-core/checklists/architect-checklist.md
|
||||
sm:
|
||||
- bmad-core/templates/story-tmpl.md
|
||||
- bmad-core/checklists/story-draft-checklist.md
|
||||
- bmad-core/workflows/*.yml
|
||||
po:
|
||||
- bmad-core/checklists/po-master-checklist.md
|
||||
- bmad-core/templates/acceptance-criteria-tmpl.md
|
||||
analyst:
|
||||
- bmad-core/templates/prd-tmpl.md
|
||||
- bmad-core/tasks/advanced-elicitation.md
|
||||
qa:
|
||||
- bmad-core/checklists/story-dod-checklist.md
|
||||
- bmad-core/templates/test-plan-tmpl.md
|
||||
ux-expert:
|
||||
- bmad-core/templates/ux-tmpl.md
|
||||
bmad-master:
|
||||
- bmad-core/templates/*.md
|
||||
- bmad-core/tasks/*.md
|
||||
- bmad-core/schemas/*.yml
|
||||
bmad-orchestrator:
|
||||
- bmad-core/agent-teams/*.yml
|
||||
- bmad-core/workflows/*.yml
|
||||
ide-configurations:
|
||||
cursor:
|
||||
name: Cursor
|
||||
@@ -101,44 +57,13 @@ ide-configurations:
|
||||
# 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
|
||||
file: bmad-core/agents/analyst.md
|
||||
description: Requirements gathering and analysis
|
||||
- id: pm
|
||||
name: Product Manager
|
||||
file: bmad-core/agents/pm.md
|
||||
description: Product strategy and roadmap planning
|
||||
- id: architect
|
||||
name: Solution Architect
|
||||
file: bmad-core/agents/architect.md
|
||||
description: Technical design and architecture
|
||||
- id: po
|
||||
name: Product Owner
|
||||
file: bmad-core/agents/po.md
|
||||
description: Backlog management and prioritization
|
||||
- id: sm
|
||||
name: Scrum Master
|
||||
file: bmad-core/agents/sm.md
|
||||
description: Agile process and story creation
|
||||
- id: dev
|
||||
name: Developer
|
||||
file: bmad-core/agents/dev.md
|
||||
description: Code implementation and testing
|
||||
- id: qa
|
||||
name: QA Engineer
|
||||
file: bmad-core/agents/qa.md
|
||||
description: Quality assurance and testing
|
||||
- id: ux-expert
|
||||
name: UX Expert
|
||||
file: bmad-core/agents/ux-expert.md
|
||||
description: User experience design
|
||||
- id: bmad-master
|
||||
name: BMAD Master
|
||||
file: bmad-core/agents/bmad-master.md
|
||||
description: BMAD framework expert and guide
|
||||
- id: bmad-orchestrator
|
||||
name: BMAD Orchestrator
|
||||
file: bmad-core/agents/bmad-orchestrator.md
|
||||
description: Multi-agent workflow coordinator
|
||||
gemini:
|
||||
name: Gemini CLI
|
||||
rule-dir: .gemini/agents/
|
||||
format: context-files
|
||||
instructions: |
|
||||
# To use BMAD agents with the Gemini CLI:
|
||||
# 1. The installer creates a .gemini/ directory in your project.
|
||||
# 2. It also configures .gemini/settings.json to load all agent files.
|
||||
# 3. Simply mention the agent in your prompt (e.g., "As @dev, ...").
|
||||
# 4. The Gemini CLI will automatically have the context for that agent.
|
||||
|
||||
@@ -26,8 +26,47 @@ class ConfigLoader {
|
||||
}
|
||||
|
||||
async getAvailableAgents() {
|
||||
const config = await this.load();
|
||||
return config['available-agents'] || [];
|
||||
const agentsDir = path.join(this.getBmadCorePath(), 'agents');
|
||||
|
||||
try {
|
||||
const entries = await fs.readdir(agentsDir, { withFileTypes: true });
|
||||
const agents = [];
|
||||
|
||||
for (const entry of entries) {
|
||||
if (entry.isFile() && entry.name.endsWith('.md')) {
|
||||
const agentPath = path.join(agentsDir, entry.name);
|
||||
const agentId = path.basename(entry.name, '.md');
|
||||
|
||||
try {
|
||||
const agentContent = await fs.readFile(agentPath, 'utf8');
|
||||
|
||||
// Extract YAML block from agent file
|
||||
const yamlMatch = agentContent.match(/```yml\n([\s\S]*?)\n```/);
|
||||
if (yamlMatch) {
|
||||
const yamlContent = yaml.load(yamlMatch[1]);
|
||||
const agentConfig = yamlContent.agent || {};
|
||||
|
||||
agents.push({
|
||||
id: agentId,
|
||||
name: agentConfig.title || agentConfig.name || agentId,
|
||||
file: `bmad-core/agents/${entry.name}`,
|
||||
description: agentConfig.whenToUse || 'No description available'
|
||||
});
|
||||
}
|
||||
} catch (error) {
|
||||
console.warn(`Failed to read agent ${entry.name}: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Sort agents by name for consistent display
|
||||
agents.sort((a, b) => a.name.localeCompare(b.name));
|
||||
|
||||
return agents;
|
||||
} catch (error) {
|
||||
console.warn(`Failed to read agents directory: ${error.message}`);
|
||||
return [];
|
||||
}
|
||||
}
|
||||
|
||||
async getAvailableExpansionPacks() {
|
||||
@@ -38,24 +77,45 @@ class ConfigLoader {
|
||||
const expansionPacks = [];
|
||||
|
||||
for (const entry of entries) {
|
||||
if (entry.isDirectory()) {
|
||||
const manifestPath = path.join(expansionPacksDir, entry.name, 'manifest.yml');
|
||||
if (entry.isDirectory() && !entry.name.startsWith('.')) {
|
||||
const packPath = path.join(expansionPacksDir, entry.name);
|
||||
const configPath = path.join(packPath, 'config.yml');
|
||||
|
||||
try {
|
||||
const manifestContent = await fs.readFile(manifestPath, 'utf8');
|
||||
const manifest = yaml.load(manifestContent);
|
||||
// Read config.yml
|
||||
const configContent = await fs.readFile(configPath, 'utf8');
|
||||
const config = yaml.load(configContent);
|
||||
|
||||
expansionPacks.push({
|
||||
id: entry.name,
|
||||
name: manifest.name || entry.name,
|
||||
description: manifest.description || 'No description available',
|
||||
version: manifest.version || '1.0.0',
|
||||
author: manifest.author || 'Unknown',
|
||||
manifestPath: manifestPath,
|
||||
dependencies: manifest.dependencies || []
|
||||
name: config.name || entry.name,
|
||||
description: config['short-title'] || config.description || 'No description available',
|
||||
fullDescription: config.description || config['short-title'] || 'No description available',
|
||||
version: config.version || '1.0.0',
|
||||
author: config.author || 'BMAD Team',
|
||||
packPath: packPath,
|
||||
dependencies: config.dependencies?.agents || []
|
||||
});
|
||||
} catch (error) {
|
||||
console.warn(`Failed to read manifest for expansion pack ${entry.name}: ${error.message}`);
|
||||
// Fallback if config.yml doesn't exist or can't be read
|
||||
console.warn(`Failed to read config for expansion pack ${entry.name}: ${error.message}`);
|
||||
|
||||
// Try to derive info from directory name as fallback
|
||||
const name = entry.name
|
||||
.split('-')
|
||||
.map(word => word.charAt(0).toUpperCase() + word.slice(1))
|
||||
.join(' ');
|
||||
|
||||
expansionPacks.push({
|
||||
id: entry.name,
|
||||
name: name,
|
||||
description: 'No description available',
|
||||
fullDescription: 'No description available',
|
||||
version: '1.0.0',
|
||||
author: 'BMAD Team',
|
||||
packPath: packPath,
|
||||
dependencies: []
|
||||
});
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -72,36 +132,24 @@ class ConfigLoader {
|
||||
const DependencyResolver = require('../../lib/dependency-resolver');
|
||||
const resolver = new DependencyResolver(path.join(__dirname, '..', '..', '..'));
|
||||
|
||||
try {
|
||||
const agentDeps = await resolver.resolveAgentDependencies(agentId);
|
||||
|
||||
// Convert to flat list of file paths
|
||||
const depPaths = [];
|
||||
|
||||
// Core files and utilities are included automatically by DependencyResolver
|
||||
|
||||
// Add agent file itself is already handled by installer
|
||||
|
||||
// Add all resolved resources
|
||||
for (const resource of agentDeps.resources) {
|
||||
const filePath = `.bmad-core/${resource.type}/${resource.id}.md`;
|
||||
if (!depPaths.includes(filePath)) {
|
||||
depPaths.push(filePath);
|
||||
}
|
||||
const agentDeps = await resolver.resolveAgentDependencies(agentId);
|
||||
|
||||
// Convert to flat list of file paths
|
||||
const depPaths = [];
|
||||
|
||||
// Core files and utilities are included automatically by DependencyResolver
|
||||
|
||||
// Add agent file itself is already handled by installer
|
||||
|
||||
// Add all resolved resources
|
||||
for (const resource of agentDeps.resources) {
|
||||
const filePath = `.bmad-core/${resource.type}/${resource.id}.md`;
|
||||
if (!depPaths.includes(filePath)) {
|
||||
depPaths.push(filePath);
|
||||
}
|
||||
|
||||
return depPaths;
|
||||
} catch (error) {
|
||||
console.warn(`Failed to dynamically resolve dependencies for ${agentId}: ${error.message}`);
|
||||
|
||||
// Fall back to static config
|
||||
const config = await this.load();
|
||||
const dependencies = config['agent-dependencies'] || {};
|
||||
const coreFiles = dependencies['core-files'] || [];
|
||||
const agentDeps = dependencies[agentId] || [];
|
||||
|
||||
return [...coreFiles, ...agentDeps];
|
||||
}
|
||||
|
||||
return depPaths;
|
||||
}
|
||||
|
||||
async getIdeConfiguration(ide) {
|
||||
|
||||
@@ -90,6 +90,7 @@ class FileManager {
|
||||
agent: config.agent || null,
|
||||
ide_setup: config.ide || null,
|
||||
ides_setup: config.ides || [],
|
||||
expansion_packs: config.expansionPacks || [],
|
||||
files: [],
|
||||
};
|
||||
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
const path = require("path");
|
||||
const fs = require("fs-extra");
|
||||
const yaml = require("js-yaml");
|
||||
const fileManager = require("./file-manager");
|
||||
const configLoader = require("./config-loader");
|
||||
|
||||
@@ -13,6 +15,27 @@ async function initializeModules() {
|
||||
}
|
||||
|
||||
class IdeSetup {
|
||||
constructor() {
|
||||
this.ideAgentConfig = null;
|
||||
}
|
||||
|
||||
async loadIdeAgentConfig() {
|
||||
if (this.ideAgentConfig) return this.ideAgentConfig;
|
||||
|
||||
try {
|
||||
const configPath = path.join(__dirname, '..', 'config', 'ide-agent-config.yml');
|
||||
const configContent = await fs.readFile(configPath, 'utf8');
|
||||
this.ideAgentConfig = yaml.load(configContent);
|
||||
return this.ideAgentConfig;
|
||||
} catch (error) {
|
||||
console.warn('Failed to load IDE agent configuration, using defaults');
|
||||
return {
|
||||
'roo-permissions': {},
|
||||
'cline-order': {}
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
async setup(ide, installDir, selectedAgent = null) {
|
||||
await initializeModules();
|
||||
const ideConfig = await configLoader.getIdeConfiguration(ide);
|
||||
@@ -33,6 +56,8 @@ class IdeSetup {
|
||||
return this.setupRoo(installDir, selectedAgent);
|
||||
case "cline":
|
||||
return this.setupCline(installDir, selectedAgent);
|
||||
case "gemini":
|
||||
return this.setupGeminiCli(installDir, selectedAgent);
|
||||
default:
|
||||
console.log(chalk.yellow(`\nIDE ${ide} not yet supported`));
|
||||
return false;
|
||||
@@ -46,13 +71,10 @@ class IdeSetup {
|
||||
await fileManager.ensureDirectory(cursorRulesDir);
|
||||
|
||||
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`);
|
||||
}
|
||||
// Find the agent file
|
||||
const agentPath = await this.findAgentPath(agentId, installDir);
|
||||
|
||||
if (await fileManager.pathExists(agentPath)) {
|
||||
if (agentPath) {
|
||||
const agentContent = await fileManager.readFile(agentPath);
|
||||
const mdcPath = path.join(cursorRulesDir, `${agentId}.mdc`);
|
||||
|
||||
@@ -63,8 +85,9 @@ class IdeSetup {
|
||||
mdcContent += "alwaysApply: false\n";
|
||||
mdcContent += "---\n\n";
|
||||
mdcContent += `# ${agentId.toUpperCase()} Agent Rule\n\n`;
|
||||
mdcContent += `This rule is triggered when the user types \`@${agentId}\` and activates the ${this.getAgentTitle(
|
||||
agentId
|
||||
mdcContent += `This rule is triggered when the user types \`@${agentId}\` and activates the ${await this.getAgentTitle(
|
||||
agentId,
|
||||
installDir
|
||||
)} agent persona.\n\n`;
|
||||
mdcContent += "## Agent Activation\n\n";
|
||||
mdcContent +=
|
||||
@@ -80,10 +103,12 @@ class IdeSetup {
|
||||
}
|
||||
mdcContent += "\n```\n\n";
|
||||
mdcContent += "## File Reference\n\n";
|
||||
mdcContent += `The complete agent definition is available in [.bmad-core/agents/${agentId}.md](mdc:.bmad-core/agents/${agentId}.md).\n\n`;
|
||||
const relativePath = path.relative(installDir, agentPath).replace(/\\/g, '/');
|
||||
mdcContent += `The complete agent definition is available in [${relativePath}](mdc:${relativePath}).\n\n`;
|
||||
mdcContent += "## Usage\n\n";
|
||||
mdcContent += `When the user types \`@${agentId}\`, activate this ${this.getAgentTitle(
|
||||
agentId
|
||||
mdcContent += `When the user types \`@${agentId}\`, activate this ${await this.getAgentTitle(
|
||||
agentId,
|
||||
installDir
|
||||
)} persona and follow all instructions defined in the YML configuration above.\n`;
|
||||
|
||||
await fileManager.writeFile(mdcPath, mdcContent);
|
||||
@@ -103,14 +128,11 @@ class IdeSetup {
|
||||
await fileManager.ensureDirectory(commandsDir);
|
||||
|
||||
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`);
|
||||
}
|
||||
// Find the agent file
|
||||
const agentPath = await this.findAgentPath(agentId, installDir);
|
||||
const commandPath = path.join(commandsDir, `${agentId}.md`);
|
||||
|
||||
if (await fileManager.pathExists(agentPath)) {
|
||||
if (agentPath) {
|
||||
// Create command file with agent content
|
||||
const agentContent = await fileManager.readFile(agentPath);
|
||||
|
||||
@@ -136,20 +158,18 @@ class IdeSetup {
|
||||
await fileManager.ensureDirectory(windsurfRulesDir);
|
||||
|
||||
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`);
|
||||
}
|
||||
// Find the agent file
|
||||
const agentPath = await this.findAgentPath(agentId, installDir);
|
||||
|
||||
if (await fileManager.pathExists(agentPath)) {
|
||||
if (agentPath) {
|
||||
const agentContent = await fileManager.readFile(agentPath);
|
||||
const mdPath = path.join(windsurfRulesDir, `${agentId}.md`);
|
||||
|
||||
// Create MD content (similar to Cursor but without frontmatter)
|
||||
let mdContent = `# ${agentId.toUpperCase()} Agent Rule\n\n`;
|
||||
mdContent += `This rule is triggered when the user types \`@${agentId}\` and activates the ${this.getAgentTitle(
|
||||
agentId
|
||||
mdContent += `This rule is triggered when the user types \`@${agentId}\` and activates the ${await this.getAgentTitle(
|
||||
agentId,
|
||||
installDir
|
||||
)} agent persona.\n\n`;
|
||||
mdContent += "## Agent Activation\n\n";
|
||||
mdContent +=
|
||||
@@ -165,10 +185,12 @@ class IdeSetup {
|
||||
}
|
||||
mdContent += "\n```\n\n";
|
||||
mdContent += "## File Reference\n\n";
|
||||
mdContent += `The complete agent definition is available in [.bmad-core/agents/${agentId}.md](.bmad-core/agents/${agentId}.md).\n\n`;
|
||||
const relativePath = path.relative(installDir, agentPath).replace(/\\/g, '/');
|
||||
mdContent += `The complete agent definition is available in [${relativePath}](${relativePath}).\n\n`;
|
||||
mdContent += "## Usage\n\n";
|
||||
mdContent += `When the user types \`@${agentId}\`, activate this ${this.getAgentTitle(
|
||||
agentId
|
||||
mdContent += `When the user types \`@${agentId}\`, activate this ${await this.getAgentTitle(
|
||||
agentId,
|
||||
installDir
|
||||
)} persona and follow all instructions defined in the YML configuration above.\n`;
|
||||
|
||||
await fileManager.writeFile(mdPath, mdContent);
|
||||
@@ -181,32 +203,93 @@ class IdeSetup {
|
||||
return true;
|
||||
}
|
||||
|
||||
async findAgentPath(agentId, installDir) {
|
||||
// Try to find the agent file in various locations
|
||||
const possiblePaths = [
|
||||
path.join(installDir, ".bmad-core", "agents", `${agentId}.md`),
|
||||
path.join(installDir, "agents", `${agentId}.md`)
|
||||
];
|
||||
|
||||
// Also check expansion pack directories
|
||||
const glob = require("glob");
|
||||
const expansionDirs = glob.sync(".*/agents", { cwd: installDir });
|
||||
for (const expDir of expansionDirs) {
|
||||
possiblePaths.push(path.join(installDir, expDir, `${agentId}.md`));
|
||||
}
|
||||
|
||||
for (const agentPath of possiblePaths) {
|
||||
if (await fileManager.pathExists(agentPath)) {
|
||||
return agentPath;
|
||||
}
|
||||
}
|
||||
|
||||
return null;
|
||||
}
|
||||
|
||||
async getAllAgentIds(installDir) {
|
||||
// Check if .bmad-core is a subdirectory (full install) or if agents are in root (single agent install)
|
||||
const glob = require("glob");
|
||||
const allAgentIds = [];
|
||||
|
||||
// Check core agents in .bmad-core or root
|
||||
let agentsDir = path.join(installDir, ".bmad-core", "agents");
|
||||
if (!(await fileManager.pathExists(agentsDir))) {
|
||||
agentsDir = path.join(installDir, "agents");
|
||||
}
|
||||
|
||||
const glob = require("glob");
|
||||
const agentFiles = glob.sync("*.md", { cwd: agentsDir });
|
||||
return agentFiles.map((file) => path.basename(file, ".md"));
|
||||
|
||||
if (await fileManager.pathExists(agentsDir)) {
|
||||
const agentFiles = glob.sync("*.md", { cwd: agentsDir });
|
||||
allAgentIds.push(...agentFiles.map((file) => path.basename(file, ".md")));
|
||||
}
|
||||
|
||||
// Also check for expansion pack agents in dot folders
|
||||
const expansionDirs = glob.sync(".*/agents", { cwd: installDir });
|
||||
for (const expDir of expansionDirs) {
|
||||
const fullExpDir = path.join(installDir, expDir);
|
||||
const expAgentFiles = glob.sync("*.md", { cwd: fullExpDir });
|
||||
allAgentIds.push(...expAgentFiles.map((file) => path.basename(file, ".md")));
|
||||
}
|
||||
|
||||
// Remove duplicates
|
||||
return [...new Set(allAgentIds)];
|
||||
}
|
||||
|
||||
getAgentTitle(agentId) {
|
||||
const agentTitles = {
|
||||
analyst: "Business Analyst",
|
||||
architect: "Solution Architect",
|
||||
"bmad-master": "BMAD Master",
|
||||
"bmad-orchestrator": "BMAD Orchestrator",
|
||||
dev: "Developer",
|
||||
pm: "Product Manager",
|
||||
po: "Product Owner",
|
||||
qa: "QA Specialist",
|
||||
sm: "Scrum Master",
|
||||
"ux-expert": "UX Expert",
|
||||
};
|
||||
return agentTitles[agentId] || agentId;
|
||||
async getAgentTitle(agentId, installDir) {
|
||||
// Try to find the agent file in various locations
|
||||
const possiblePaths = [
|
||||
path.join(installDir, ".bmad-core", "agents", `${agentId}.md`),
|
||||
path.join(installDir, "agents", `${agentId}.md`)
|
||||
];
|
||||
|
||||
// Also check expansion pack directories
|
||||
const glob = require("glob");
|
||||
const expansionDirs = glob.sync(".*/agents", { cwd: installDir });
|
||||
for (const expDir of expansionDirs) {
|
||||
possiblePaths.push(path.join(installDir, expDir, `${agentId}.md`));
|
||||
}
|
||||
|
||||
for (const agentPath of possiblePaths) {
|
||||
if (await fileManager.pathExists(agentPath)) {
|
||||
try {
|
||||
const agentContent = await fileManager.readFile(agentPath);
|
||||
const yamlMatch = agentContent.match(/```ya?ml\n([\s\S]*?)```/);
|
||||
|
||||
if (yamlMatch) {
|
||||
const yaml = yamlMatch[1];
|
||||
const titleMatch = yaml.match(/title:\s*(.+)/);
|
||||
if (titleMatch) {
|
||||
return titleMatch[1].trim();
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
console.warn(`Failed to read agent title for ${agentId}: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Fallback to formatted agent ID
|
||||
return agentId.split('-').map(word =>
|
||||
word.charAt(0).toUpperCase() + word.slice(1)
|
||||
).join(' ');
|
||||
}
|
||||
|
||||
async setupRoo(installDir, selectedAgent) {
|
||||
@@ -230,40 +313,9 @@ class IdeSetup {
|
||||
// Create new modes content
|
||||
let newModesContent = "";
|
||||
|
||||
// Define file permissions for each agent type
|
||||
const agentPermissions = {
|
||||
analyst: {
|
||||
fileRegex: "\\.(md|txt)$",
|
||||
description: "Documentation and text files",
|
||||
},
|
||||
pm: {
|
||||
fileRegex: "\\.(md|txt)$",
|
||||
description: "Product documentation",
|
||||
},
|
||||
architect: {
|
||||
fileRegex: "\\.(md|txt|yml|yaml|json)$",
|
||||
description: "Architecture docs and configs",
|
||||
},
|
||||
dev: null, // Full edit access
|
||||
qa: {
|
||||
fileRegex: "\\.(test|spec)\\.(js|ts|jsx|tsx)$|\\.md$",
|
||||
description: "Test files and documentation",
|
||||
},
|
||||
"ux-expert": {
|
||||
fileRegex: "\\.(md|css|scss|html|jsx|tsx)$",
|
||||
description: "Design-related files",
|
||||
},
|
||||
po: {
|
||||
fileRegex: "\\.(md|txt)$",
|
||||
description: "Story and requirement docs",
|
||||
},
|
||||
sm: {
|
||||
fileRegex: "\\.(md|txt)$",
|
||||
description: "Process and planning docs",
|
||||
},
|
||||
"bmad-orchestrator": null, // Full edit access
|
||||
"bmad-master": null, // Full edit access
|
||||
};
|
||||
// Load dynamic agent permissions from configuration
|
||||
const config = await this.loadIdeAgentConfig();
|
||||
const agentPermissions = config['roo-permissions'] || {};
|
||||
|
||||
for (const agentId of agents) {
|
||||
// Skip if already exists
|
||||
@@ -273,12 +325,9 @@ class IdeSetup {
|
||||
}
|
||||
|
||||
// Read agent file to extract all information
|
||||
let agentPath = path.join(installDir, ".bmad-core", "agents", `${agentId}.md`);
|
||||
if (!(await fileManager.pathExists(agentPath))) {
|
||||
agentPath = path.join(installDir, "agents", `${agentId}.md`);
|
||||
}
|
||||
const agentPath = await this.findAgentPath(agentId, installDir);
|
||||
|
||||
if (await fileManager.pathExists(agentPath)) {
|
||||
if (agentPath) {
|
||||
const agentContent = await fileManager.readFile(agentPath);
|
||||
|
||||
// Extract YAML content
|
||||
@@ -292,7 +341,7 @@ class IdeSetup {
|
||||
const whenToUseMatch = yaml.match(/whenToUse:\s*"(.+)"/);
|
||||
const roleDefinitionMatch = yaml.match(/roleDefinition:\s*"(.+)"/);
|
||||
|
||||
const title = titleMatch ? titleMatch[1].trim() : this.getAgentTitle(agentId);
|
||||
const title = titleMatch ? titleMatch[1].trim() : await this.getAgentTitle(agentId, installDir);
|
||||
const icon = iconMatch ? iconMatch[1].trim() : "🤖";
|
||||
const whenToUse = whenToUseMatch ? whenToUseMatch[1].trim() : `Use for ${title} tasks`;
|
||||
const roleDefinition = roleDefinitionMatch
|
||||
@@ -304,7 +353,9 @@ class IdeSetup {
|
||||
newModesContent += ` name: '${icon} ${title}'\n`;
|
||||
newModesContent += ` roleDefinition: ${roleDefinition}\n`;
|
||||
newModesContent += ` whenToUse: ${whenToUse}\n`;
|
||||
newModesContent += ` customInstructions: CRITICAL Read the full YML from .bmad-core/agents/${agentId}.md start activation to alter your state of being follow startup section instructions stay in this being until told to exit this mode\n`;
|
||||
// Get relative path from installDir to agent file
|
||||
const relativePath = path.relative(installDir, agentPath).replace(/\\/g, '/');
|
||||
newModesContent += ` customInstructions: CRITICAL Read the full YML from ${relativePath} start activation to alter your state of being follow startup section instructions stay in this being until told to exit this mode\n`;
|
||||
newModesContent += ` groups:\n`;
|
||||
newModesContent += ` - read\n`;
|
||||
|
||||
@@ -349,28 +400,15 @@ class IdeSetup {
|
||||
|
||||
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
|
||||
};
|
||||
// Load dynamic agent ordering from configuration
|
||||
const config = await this.loadIdeAgentConfig();
|
||||
const agentOrder = config['cline-order'] || {};
|
||||
|
||||
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`);
|
||||
}
|
||||
// Find the agent file
|
||||
const agentPath = await this.findAgentPath(agentId, installDir);
|
||||
|
||||
if (await fileManager.pathExists(agentPath)) {
|
||||
if (agentPath) {
|
||||
const agentContent = await fileManager.readFile(agentPath);
|
||||
|
||||
// Get numeric prefix for ordering
|
||||
@@ -379,8 +417,8 @@ class IdeSetup {
|
||||
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`;
|
||||
let mdContent = `# ${await this.getAgentTitle(agentId, installDir)} Agent\n\n`;
|
||||
mdContent += `This rule defines the ${await this.getAgentTitle(agentId, installDir)} 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";
|
||||
@@ -398,9 +436,10 @@ class IdeSetup {
|
||||
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`;
|
||||
const relativePath = path.relative(installDir, agentPath).replace(/\\/g, '/');
|
||||
mdContent += `- Reference the complete agent definition in [${relativePath}](${relativePath})\n\n`;
|
||||
mdContent += "## Usage\n\n";
|
||||
mdContent += `Type \`@${agentId}\` to activate this ${this.getAgentTitle(agentId)} persona.\n`;
|
||||
mdContent += `Type \`@${agentId}\` to activate this ${await this.getAgentTitle(agentId, installDir)} persona.\n`;
|
||||
|
||||
await fileManager.writeFile(mdPath, mdContent);
|
||||
console.log(chalk.green(`✓ Created rule: ${prefix}-${agentId}.md`));
|
||||
@@ -411,6 +450,63 @@ class IdeSetup {
|
||||
|
||||
return true;
|
||||
}
|
||||
|
||||
async setupGeminiCli(installDir, selectedAgent) {
|
||||
await initializeModules();
|
||||
const geminiDir = path.join(installDir, ".gemini");
|
||||
const agentsContextDir = path.join(geminiDir, "agents");
|
||||
await fileManager.ensureDirectory(agentsContextDir);
|
||||
|
||||
// Get all available agents
|
||||
const agents = await this.getAllAgentIds(installDir);
|
||||
const agentContextFiles = [];
|
||||
|
||||
for (const agentId of agents) {
|
||||
// Find the source agent file
|
||||
const agentPath = await this.findAgentPath(agentId, installDir);
|
||||
|
||||
if (agentPath) {
|
||||
const agentContent = await fileManager.readFile(agentPath);
|
||||
const contextFilePath = path.join(agentsContextDir, `${agentId}.md`);
|
||||
|
||||
// Copy the agent content directly into its own context file
|
||||
await fileManager.writeFile(contextFilePath, agentContent);
|
||||
|
||||
// Store the relative path for settings.json
|
||||
const relativePath = path.relative(geminiDir, contextFilePath);
|
||||
agentContextFiles.push(relativePath.replace(/\\/g, '/')); // Ensure forward slashes for consistency
|
||||
console.log(chalk.green(`✓ Created context file for @${agentId}`));
|
||||
}
|
||||
}
|
||||
|
||||
console.log(chalk.green(`\n✓ Created individual agent context files in ${agentsContextDir}`));
|
||||
|
||||
// Add GEMINI.md to the context files array
|
||||
agentContextFiles.push("GEMINI.md");
|
||||
|
||||
// Create or update settings.json
|
||||
const settingsPath = path.join(geminiDir, "settings.json");
|
||||
let settings = {};
|
||||
|
||||
if (await fileManager.pathExists(settingsPath)) {
|
||||
try {
|
||||
const existingSettings = await fileManager.readFile(settingsPath);
|
||||
settings = JSON.parse(existingSettings);
|
||||
console.log(chalk.yellow("Found existing .gemini/settings.json. Merging settings..."));
|
||||
} catch (e) {
|
||||
console.error(chalk.red("Error parsing existing settings.json. It will be overwritten."), e);
|
||||
settings = {};
|
||||
}
|
||||
}
|
||||
|
||||
// Set contextFileName to our new array of files
|
||||
settings.contextFileName = agentContextFiles;
|
||||
|
||||
await fileManager.writeFile(settingsPath, JSON.stringify(settings, null, 2));
|
||||
console.log(chalk.green(`✓ Configured .gemini/settings.json to load all agent context files.`));
|
||||
|
||||
return true;
|
||||
}
|
||||
}
|
||||
|
||||
module.exports = new IdeSetup();
|
||||
|
||||
@@ -225,6 +225,10 @@ class Installer {
|
||||
const sourceDir = configLoader.getBmadCorePath();
|
||||
const bmadCoreDestDir = path.join(installDir, ".bmad-core");
|
||||
await fileManager.copyDirectory(sourceDir, bmadCoreDestDir);
|
||||
|
||||
// Copy common/ items to .bmad-core
|
||||
spinner.text = "Copying common utilities...";
|
||||
await this.copyCommonItems(installDir, ".bmad-core", spinner);
|
||||
|
||||
// Get list of all files for manifest
|
||||
const glob = require("glob");
|
||||
@@ -283,6 +287,11 @@ class Installer {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Copy common/ items to .bmad-core
|
||||
spinner.text = "Copying common utilities...";
|
||||
const commonFiles = await this.copyCommonItems(installDir, ".bmad-core", spinner);
|
||||
files.push(...commonFiles);
|
||||
} else if (config.installType === "team") {
|
||||
// Team installation
|
||||
spinner.text = `Installing ${config.team} team...`;
|
||||
@@ -313,6 +322,11 @@ class Installer {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Copy common/ items to .bmad-core
|
||||
spinner.text = "Copying common utilities...";
|
||||
const commonFiles = await this.copyCommonItems(installDir, ".bmad-core", spinner);
|
||||
files.push(...commonFiles);
|
||||
} else if (config.installType === "expansion-only") {
|
||||
// Expansion-only installation - create minimal .bmad-core structure
|
||||
spinner.text = "Creating minimal .bmad-core structure for expansion packs...";
|
||||
@@ -341,6 +355,10 @@ class Installer {
|
||||
);
|
||||
files.push(...copiedFiles.map(f => `.bmad-core/${f}`));
|
||||
}
|
||||
|
||||
// Copy common/ items to .bmad-core
|
||||
spinner.text = "Copying common utilities...";
|
||||
await this.copyCommonItems(installDir, ".bmad-core", spinner);
|
||||
}
|
||||
|
||||
// Install expansion packs if requested
|
||||
@@ -607,8 +625,10 @@ class Installer {
|
||||
console.log(chalk.green("✓ .bmad-core framework installed with all agents and workflows"));
|
||||
|
||||
if (config.expansionPacks && config.expansionPacks.length > 0) {
|
||||
const packNames = config.expansionPacks.join(", ");
|
||||
console.log(chalk.green(`✓ Expansion packs installed: ${packNames}`));
|
||||
console.log(chalk.green(`✓ Expansion packs installed:`));
|
||||
for (const packId of config.expansionPacks) {
|
||||
console.log(chalk.green(` - ${packId} → .${packId}/`));
|
||||
}
|
||||
}
|
||||
|
||||
if (config.includeWebBundles && config.webBundlesDirectory) {
|
||||
@@ -797,9 +817,13 @@ class Installer {
|
||||
continue;
|
||||
}
|
||||
|
||||
const expansionPackDir = path.dirname(pack.manifestPath);
|
||||
const expansionPackDir = pack.packPath;
|
||||
|
||||
// Define the folders to copy from expansion packs to .bmad-core
|
||||
// Create dedicated dot folder for this expansion pack
|
||||
const expansionDotFolder = path.join(installDir, `.${packId}`);
|
||||
await fileManager.ensureDirectory(expansionDotFolder);
|
||||
|
||||
// Define the folders to copy from expansion packs
|
||||
const foldersToSync = [
|
||||
'agents',
|
||||
'agent-teams',
|
||||
@@ -824,21 +848,47 @@ class Installer {
|
||||
nodir: true
|
||||
});
|
||||
|
||||
// Copy each file to the destination
|
||||
// Copy each file to the expansion pack's dot folder
|
||||
for (const file of files) {
|
||||
const sourcePath = path.join(sourceFolder, file);
|
||||
const destPath = path.join(installDir, '.bmad-core', folder, file);
|
||||
const destPath = path.join(expansionDotFolder, folder, file);
|
||||
|
||||
if (await fileManager.copyFile(sourcePath, destPath)) {
|
||||
installedFiles.push(path.join('.bmad-core', folder, file));
|
||||
installedFiles.push(path.join(`.${packId}`, folder, file));
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Web bundles are now available in the dist/ directory and don't need to be copied
|
||||
// Copy config.yml
|
||||
const configPath = path.join(expansionPackDir, 'config.yml');
|
||||
if (await fileManager.pathExists(configPath)) {
|
||||
const configDestPath = path.join(expansionDotFolder, 'config.yml');
|
||||
if (await fileManager.copyFile(configPath, configDestPath)) {
|
||||
installedFiles.push(path.join(`.${packId}`, 'config.yml'));
|
||||
}
|
||||
}
|
||||
|
||||
// Copy README if it exists
|
||||
const readmePath = path.join(expansionPackDir, 'README.md');
|
||||
if (await fileManager.pathExists(readmePath)) {
|
||||
const readmeDestPath = path.join(expansionDotFolder, 'README.md');
|
||||
if (await fileManager.copyFile(readmePath, readmeDestPath)) {
|
||||
installedFiles.push(path.join(`.${packId}`, 'README.md'));
|
||||
}
|
||||
}
|
||||
|
||||
console.log(chalk.green(`✓ Installed expansion pack: ${pack.name}`));
|
||||
// Copy common/ items to expansion pack folder
|
||||
spinner.text = `Copying common utilities to ${packId}...`;
|
||||
await this.copyCommonItems(installDir, `.${packId}`, spinner);
|
||||
|
||||
// Check and resolve core dependencies
|
||||
await this.resolveExpansionPackCoreDependencies(installDir, expansionDotFolder, packId, spinner);
|
||||
|
||||
// Check and resolve core agents referenced by teams
|
||||
await this.resolveExpansionPackCoreAgents(installDir, expansionDotFolder, packId, spinner);
|
||||
|
||||
console.log(chalk.green(`✓ Installed expansion pack: ${pack.name} to ${`.${packId}`}`));
|
||||
} catch (error) {
|
||||
console.error(chalk.red(`Failed to install expansion pack ${packId}: ${error.message}`));
|
||||
}
|
||||
@@ -847,6 +897,168 @@ class Installer {
|
||||
return installedFiles;
|
||||
}
|
||||
|
||||
async resolveExpansionPackCoreDependencies(installDir, expansionDotFolder, packId, spinner) {
|
||||
const glob = require('glob');
|
||||
const yaml = require('yaml');
|
||||
const fs = require('fs').promises;
|
||||
|
||||
// Find all agent files in the expansion pack
|
||||
const agentFiles = glob.sync('agents/*.md', {
|
||||
cwd: expansionDotFolder
|
||||
});
|
||||
|
||||
for (const agentFile of agentFiles) {
|
||||
const agentPath = path.join(expansionDotFolder, agentFile);
|
||||
const agentContent = await fs.readFile(agentPath, 'utf8');
|
||||
|
||||
// Extract YAML frontmatter to check dependencies
|
||||
const yamlMatch = agentContent.match(/```yaml\n([\s\S]*?)```/);
|
||||
if (yamlMatch) {
|
||||
try {
|
||||
const agentConfig = yaml.parse(yamlMatch[1]);
|
||||
const dependencies = agentConfig.dependencies || {};
|
||||
|
||||
// Check for core dependencies (those that don't exist in the expansion pack)
|
||||
for (const depType of ['tasks', 'templates', 'checklists', 'workflows', 'utils', 'data']) {
|
||||
const deps = dependencies[depType] || [];
|
||||
|
||||
for (const dep of deps) {
|
||||
const depFileName = dep.endsWith('.md') ? dep : `${dep}.md`;
|
||||
const expansionDepPath = path.join(expansionDotFolder, depType, depFileName);
|
||||
|
||||
// Check if dependency exists in expansion pack
|
||||
if (!(await fileManager.pathExists(expansionDepPath))) {
|
||||
// Try to find it in core
|
||||
const coreDepPath = path.join(configLoader.getBmadCorePath(), depType, depFileName);
|
||||
|
||||
if (await fileManager.pathExists(coreDepPath)) {
|
||||
spinner.text = `Copying core dependency ${dep} for ${packId}...`;
|
||||
|
||||
// Copy from core to expansion pack dot folder
|
||||
const destPath = path.join(expansionDotFolder, depType, depFileName);
|
||||
await fileManager.copyFile(coreDepPath, destPath);
|
||||
|
||||
console.log(chalk.dim(` Added core dependency: ${depType}/${depFileName}`));
|
||||
} else {
|
||||
console.warn(chalk.yellow(` Warning: Dependency ${depType}/${dep} not found in core or expansion pack`));
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
console.warn(chalk.yellow(` Warning: Could not parse agent dependencies: ${error.message}`));
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
async resolveExpansionPackCoreAgents(installDir, expansionDotFolder, packId, spinner) {
|
||||
const glob = require('glob');
|
||||
const yaml = require('yaml');
|
||||
const fs = require('fs').promises;
|
||||
|
||||
// Find all team files in the expansion pack
|
||||
const teamFiles = glob.sync('agent-teams/*.yml', {
|
||||
cwd: expansionDotFolder
|
||||
});
|
||||
|
||||
// Also get existing agents in the expansion pack
|
||||
const existingAgents = new Set();
|
||||
const agentFiles = glob.sync('agents/*.md', {
|
||||
cwd: expansionDotFolder
|
||||
});
|
||||
for (const agentFile of agentFiles) {
|
||||
const agentName = path.basename(agentFile, '.md');
|
||||
existingAgents.add(agentName);
|
||||
}
|
||||
|
||||
// Process each team file
|
||||
for (const teamFile of teamFiles) {
|
||||
const teamPath = path.join(expansionDotFolder, teamFile);
|
||||
const teamContent = await fs.readFile(teamPath, 'utf8');
|
||||
|
||||
try {
|
||||
const teamConfig = yaml.parse(teamContent);
|
||||
const agents = teamConfig.agents || [];
|
||||
|
||||
// Add bmad-orchestrator if not present (required for all teams)
|
||||
if (!agents.includes('bmad-orchestrator')) {
|
||||
agents.unshift('bmad-orchestrator');
|
||||
}
|
||||
|
||||
// Check each agent in the team
|
||||
for (const agentId of agents) {
|
||||
if (!existingAgents.has(agentId)) {
|
||||
// Agent not in expansion pack, try to get from core
|
||||
const coreAgentPath = path.join(configLoader.getBmadCorePath(), 'agents', `${agentId}.md`);
|
||||
|
||||
if (await fileManager.pathExists(coreAgentPath)) {
|
||||
spinner.text = `Copying core agent ${agentId} for ${packId}...`;
|
||||
|
||||
// Copy agent file
|
||||
const destPath = path.join(expansionDotFolder, 'agents', `${agentId}.md`);
|
||||
await fileManager.copyFile(coreAgentPath, destPath);
|
||||
existingAgents.add(agentId);
|
||||
|
||||
console.log(chalk.dim(` Added core agent: ${agentId}`));
|
||||
|
||||
// Now resolve this agent's dependencies too
|
||||
const agentContent = await fs.readFile(coreAgentPath, 'utf8');
|
||||
const yamlMatch = agentContent.match(/```ya?ml\n([\s\S]*?)```/);
|
||||
|
||||
if (yamlMatch) {
|
||||
try {
|
||||
// Clean up the YAML to handle command descriptions
|
||||
let yamlContent = yamlMatch[1];
|
||||
yamlContent = yamlContent.replace(/^(\s*-)(\s*"[^"]+")(\s*-\s*.*)$/gm, '$1$2');
|
||||
|
||||
const agentConfig = yaml.parse(yamlContent);
|
||||
const dependencies = agentConfig.dependencies || {};
|
||||
|
||||
// Copy all dependencies for this agent
|
||||
for (const depType of ['tasks', 'templates', 'checklists', 'workflows', 'utils', 'data']) {
|
||||
const deps = dependencies[depType] || [];
|
||||
|
||||
for (const dep of deps) {
|
||||
const depFileName = dep.endsWith('.md') || dep.endsWith('.yml') ? dep : `${dep}.md`;
|
||||
const expansionDepPath = path.join(expansionDotFolder, depType, depFileName);
|
||||
|
||||
// Check if dependency exists in expansion pack
|
||||
if (!(await fileManager.pathExists(expansionDepPath))) {
|
||||
// Try to find it in core
|
||||
const coreDepPath = path.join(configLoader.getBmadCorePath(), depType, depFileName);
|
||||
|
||||
if (await fileManager.pathExists(coreDepPath)) {
|
||||
const destDepPath = path.join(expansionDotFolder, depType, depFileName);
|
||||
await fileManager.copyFile(coreDepPath, destDepPath);
|
||||
console.log(chalk.dim(` Added agent dependency: ${depType}/${depFileName}`));
|
||||
} else {
|
||||
// Try common folder
|
||||
const commonDepPath = path.join(this.rootDir, 'common', depType, depFileName);
|
||||
if (await fileManager.pathExists(commonDepPath)) {
|
||||
const destDepPath = path.join(expansionDotFolder, depType, depFileName);
|
||||
await fileManager.copyFile(commonDepPath, destDepPath);
|
||||
console.log(chalk.dim(` Added agent dependency from common: ${depType}/${depFileName}`));
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
console.warn(chalk.yellow(` Warning: Could not parse agent ${agentId} dependencies: ${error.message}`));
|
||||
}
|
||||
}
|
||||
} else {
|
||||
console.warn(chalk.yellow(` Warning: Core agent ${agentId} not found for team ${path.basename(teamFile, '.yml')}`));
|
||||
}
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
console.warn(chalk.yellow(` Warning: Could not parse team file ${teamFile}: ${error.message}`));
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
getWebBundleInfo(config) {
|
||||
const webBundleType = config.webBundleType || 'all';
|
||||
|
||||
@@ -944,6 +1156,48 @@ class Installer {
|
||||
}
|
||||
}
|
||||
|
||||
async copyCommonItems(installDir, targetSubdir, spinner) {
|
||||
const glob = require('glob');
|
||||
const fs = require('fs').promises;
|
||||
const sourceBase = path.dirname(path.dirname(path.dirname(path.dirname(__filename)))); // Go up to project root
|
||||
const commonPath = path.join(sourceBase, 'common');
|
||||
const targetPath = path.join(installDir, targetSubdir);
|
||||
const copiedFiles = [];
|
||||
|
||||
// Check if common/ exists
|
||||
if (!(await fileManager.pathExists(commonPath))) {
|
||||
console.warn(chalk.yellow('Warning: common/ folder not found'));
|
||||
return copiedFiles;
|
||||
}
|
||||
|
||||
// Copy all items from common/ to target
|
||||
const commonItems = glob.sync('**/*', {
|
||||
cwd: commonPath,
|
||||
nodir: true
|
||||
});
|
||||
|
||||
for (const item of commonItems) {
|
||||
const sourcePath = path.join(commonPath, item);
|
||||
const destPath = path.join(targetPath, item);
|
||||
|
||||
// Read the file content
|
||||
const content = await fs.readFile(sourcePath, 'utf8');
|
||||
|
||||
// Replace {root} with the target subdirectory
|
||||
const updatedContent = content.replace(/\{root\}/g, targetSubdir);
|
||||
|
||||
// Ensure directory exists
|
||||
await fileManager.ensureDirectory(path.dirname(destPath));
|
||||
|
||||
// Write the updated content
|
||||
await fs.writeFile(destPath, updatedContent, 'utf8');
|
||||
copiedFiles.push(path.join(targetSubdir, item));
|
||||
}
|
||||
|
||||
console.log(chalk.dim(` Added ${commonItems.length} common utilities`));
|
||||
return copiedFiles;
|
||||
}
|
||||
|
||||
async findInstallation() {
|
||||
// Look for .bmad-core in current directory or parent directories
|
||||
let currentDir = process.cwd();
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "bmad-method",
|
||||
"version": "4.14.0",
|
||||
"version": "4.20.0",
|
||||
"description": "BMAD Method installer - AI-powered Agile development framework",
|
||||
"main": "lib/installer.js",
|
||||
"bin": {
|
||||
|
||||
@@ -6,6 +6,7 @@ class DependencyResolver {
|
||||
constructor(rootDir) {
|
||||
this.rootDir = rootDir;
|
||||
this.bmadCore = path.join(rootDir, 'bmad-core');
|
||||
this.common = path.join(rootDir, 'common');
|
||||
this.cache = new Map();
|
||||
}
|
||||
|
||||
@@ -123,6 +124,7 @@ class DependencyResolver {
|
||||
let content = null;
|
||||
let filePath = null;
|
||||
|
||||
// First try bmad-core
|
||||
for (const ext of extensions) {
|
||||
try {
|
||||
filePath = path.join(this.bmadCore, type, `${id}${ext}`);
|
||||
@@ -132,6 +134,19 @@ class DependencyResolver {
|
||||
// Try next extension
|
||||
}
|
||||
}
|
||||
|
||||
// If not found in bmad-core, try common folder
|
||||
if (!content) {
|
||||
for (const ext of extensions) {
|
||||
try {
|
||||
filePath = path.join(this.common, type, `${id}${ext}`);
|
||||
content = await fs.readFile(filePath, 'utf8');
|
||||
break;
|
||||
} catch (e) {
|
||||
// Try next extension
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (!content) {
|
||||
console.warn(`Resource not found: ${type}/${id}`);
|
||||
|
||||
Reference in New Issue
Block a user