bmad-method 4.12.0 → 4.14.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +14 -0
- package/CONTRIBUTING.md +128 -1
- package/GUIDING-PRINCIPLES.md +85 -0
- package/README.md +56 -6
- package/bmad-core/agents/analyst.md +3 -1
- package/bmad-core/agents/dev.md +3 -2
- package/bmad-core/agents/qa.md +15 -14
- package/bmad-core/data/bmad-kb.md +280 -19
- package/bmad-core/tasks/document-project.md +250 -322
- package/bmad-core/tasks/review-story.md +135 -0
- package/bmad-core/templates/story-tmpl.md +8 -0
- package/bmad-core/workflows/brownfield-fullstack.yml +36 -1
- package/bmad-core/workflows/brownfield-service.yml +36 -1
- package/bmad-core/workflows/brownfield-ui.yml +36 -1
- package/bmad-core/workflows/greenfield-fullstack.yml +36 -1
- package/bmad-core/workflows/greenfield-service.yml +36 -1
- package/bmad-core/workflows/greenfield-ui.yml +36 -1
- package/dist/agents/analyst.txt +227 -17
- package/dist/agents/bmad-master.txt +260 -24
- package/dist/agents/bmad-orchestrator.txt +227 -17
- package/dist/agents/dev.txt +6 -4
- package/dist/agents/pm.txt +25 -7
- package/dist/agents/po.txt +33 -7
- package/dist/agents/qa.txt +153 -14
- package/dist/agents/sm.txt +8 -0
- package/dist/expansion-packs/expansion-creator/agents/bmad-the-creator.txt +4 -12
- package/dist/teams/team-all.txt +635 -48
- package/dist/teams/team-fullstack.txt +476 -30
- package/dist/teams/team-ide-minimal.txt +419 -42
- package/dist/teams/team-no-ui.txt +332 -26
- package/docs/expansion-pack-ideas.md +121 -0
- package/docs/expansion-packs.md +265 -0
- package/docs/working-in-the-brownfield.md +362 -0
- package/expansion-packs/expansion-creator/tasks/create-agent.md +1 -1
- package/expansion-packs/expansion-creator/tasks/generate-expansion-pack.md +3 -11
- package/package.json +1 -1
- package/tools/installer/bin/bmad.js +12 -11
- package/tools/installer/config/install.config.yml +8 -3
- package/tools/installer/lib/ide-setup.js +71 -0
- package/tools/installer/package.json +1 -1
- package/tools/upgraders/v3-to-v4-upgrader.js +1 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,17 @@
|
|
|
1
|
+
# [4.14.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.13.0...v4.14.0) (2025-06-25)
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
### Features
|
|
5
|
+
|
|
6
|
+
* enhance QA agent as senior developer with code review capabilities and major brownfield improvements ([3af3d33](https://github.com/bmadcode/BMAD-METHOD/commit/3af3d33d4a40586479a382620687fa99a9f6a5f7))
|
|
7
|
+
|
|
8
|
+
# [4.13.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.12.0...v4.13.0) (2025-06-24)
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
### Features
|
|
12
|
+
|
|
13
|
+
* **ide-setup:** add support for Cline IDE and configuration rules ([#262](https://github.com/bmadcode/BMAD-METHOD/issues/262)) ([913dbec](https://github.com/bmadcode/BMAD-METHOD/commit/913dbeced60ad65086df6233086d83a51ead81a9))
|
|
14
|
+
|
|
1
15
|
# [4.12.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.11.0...v4.12.0) (2025-06-23)
|
|
2
16
|
|
|
3
17
|
|
package/CONTRIBUTING.md
CHANGED
|
@@ -4,6 +4,8 @@ Thank you for considering contributing to this project! This document outlines t
|
|
|
4
4
|
|
|
5
5
|
🆕 **New to GitHub or pull requests?** Check out our [beginner-friendly Pull Request Guide](docs/how-to-contribute-with-pull-requests.md) first!
|
|
6
6
|
|
|
7
|
+
📋 **Before contributing**, please read our [Guiding Principles](GUIDING-PRINCIPLES.md) to understand the BMAD Method's core philosophy and architectural decisions.
|
|
8
|
+
|
|
7
9
|
Also note, we use the discussions feature in GitHub to have a community to discuss potential ideas, uses, additions and enhancements.
|
|
8
10
|
|
|
9
11
|
## Code of Conduct
|
|
@@ -26,6 +28,65 @@ By participating in this project, you agree to abide by our Code of Conduct. Ple
|
|
|
26
28
|
|
|
27
29
|
Please only propose small granular commits! If its large or significant, please discuss in the discussions tab and open up an issue first. I do not want you to waste your time on a potentially very large PR to have it rejected because it is not aligned or deviates from other planned changes. Communicate and lets work together to build and improve this great community project!
|
|
28
30
|
|
|
31
|
+
**Important**: All contributions must align with our [Guiding Principles](GUIDING-PRINCIPLES.md). Key points:
|
|
32
|
+
|
|
33
|
+
- Keep dev agents lean - they need context for coding, not documentation
|
|
34
|
+
- Web/planning agents can be larger with more complex tasks
|
|
35
|
+
- Everything is natural language (markdown) - no code in core framework
|
|
36
|
+
- Use expansion packs for domain-specific features
|
|
37
|
+
|
|
38
|
+
#### Which Branch for Your PR?
|
|
39
|
+
|
|
40
|
+
**Submit to `next` branch** (most contributions):
|
|
41
|
+
|
|
42
|
+
- ✨ New features or agents
|
|
43
|
+
- 🎨 Enhancements to existing features
|
|
44
|
+
- 📚 Documentation updates
|
|
45
|
+
- ♻️ Code refactoring
|
|
46
|
+
- ⚡ Performance improvements
|
|
47
|
+
- 🧪 New tests
|
|
48
|
+
- 🎁 New expansion packs
|
|
49
|
+
|
|
50
|
+
**Submit to `main` branch** (critical only):
|
|
51
|
+
|
|
52
|
+
- 🚨 Critical bug fixes that break basic functionality
|
|
53
|
+
- 🔒 Security patches
|
|
54
|
+
- 📚 Fixing dangerously incorrect documentation
|
|
55
|
+
- 🐛 Bugs preventing installation or basic usage
|
|
56
|
+
|
|
57
|
+
**When in doubt, submit to `next`**. We'd rather test changes thoroughly before they hit stable.
|
|
58
|
+
|
|
59
|
+
#### PR Size Guidelines
|
|
60
|
+
|
|
61
|
+
- **Ideal PR size**: 200-400 lines of code changes
|
|
62
|
+
- **Maximum PR size**: 800 lines (excluding generated files)
|
|
63
|
+
- **One feature/fix per PR**: Each PR should address a single issue or add one feature
|
|
64
|
+
- **If your change is larger**: Break it into multiple smaller PRs that can be reviewed independently
|
|
65
|
+
- **Related changes**: Even related changes should be separate PRs if they deliver independent value
|
|
66
|
+
|
|
67
|
+
#### Breaking Down Large PRs
|
|
68
|
+
|
|
69
|
+
If your change exceeds 800 lines, use this checklist to split it:
|
|
70
|
+
|
|
71
|
+
- [ ] Can I separate the refactoring from the feature implementation?
|
|
72
|
+
- [ ] Can I introduce the new API/interface in one PR and implementation in another?
|
|
73
|
+
- [ ] Can I split by file or module?
|
|
74
|
+
- [ ] Can I create a base PR with shared utilities first?
|
|
75
|
+
- [ ] Can I separate test additions from implementation?
|
|
76
|
+
- [ ] Even if changes are related, can they deliver value independently?
|
|
77
|
+
- [ ] Can these changes be merged in any order without breaking things?
|
|
78
|
+
|
|
79
|
+
Example breakdown:
|
|
80
|
+
|
|
81
|
+
1. PR #1: Add utility functions and types (100 lines)
|
|
82
|
+
2. PR #2: Refactor existing code to use utilities (200 lines)
|
|
83
|
+
3. PR #3: Implement new feature using refactored code (300 lines)
|
|
84
|
+
4. PR #4: Add comprehensive tests (200 lines)
|
|
85
|
+
|
|
86
|
+
**Note**: PRs #1 and #4 could be submitted simultaneously since they deliver independent value and don't depend on each other's merge order.
|
|
87
|
+
|
|
88
|
+
#### Pull Request Steps
|
|
89
|
+
|
|
29
90
|
1. Fork the repository
|
|
30
91
|
2. Create a new branch (`git checkout -b feature/your-feature-name`)
|
|
31
92
|
3. Make your changes
|
|
@@ -34,9 +95,75 @@ Please only propose small granular commits! If its large or significant, please
|
|
|
34
95
|
6. Push to your branch (`git push origin feature/your-feature-name`)
|
|
35
96
|
7. Open a Pull Request against the main branch
|
|
36
97
|
|
|
98
|
+
## Pull Request Description Guidelines
|
|
99
|
+
|
|
100
|
+
Keep PR descriptions short and to the point following this template:
|
|
101
|
+
|
|
102
|
+
### PR Description Template
|
|
103
|
+
|
|
104
|
+
Keep your PR description concise and focused. Use this template:
|
|
105
|
+
|
|
106
|
+
```markdown
|
|
107
|
+
## What
|
|
108
|
+
|
|
109
|
+
[1-2 sentences describing WHAT changed]
|
|
110
|
+
|
|
111
|
+
## Why
|
|
112
|
+
|
|
113
|
+
[1-2 sentences explaining WHY this change is needed]
|
|
114
|
+
|
|
115
|
+
## How
|
|
116
|
+
|
|
117
|
+
[2-3 bullets listing HOW you implemented it]
|
|
118
|
+
|
|
119
|
+
-
|
|
120
|
+
-
|
|
121
|
+
-
|
|
122
|
+
|
|
123
|
+
## Testing
|
|
124
|
+
|
|
125
|
+
[1-2 sentences on how you tested this]
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
**Maximum PR description length: 200 words** (excluding code examples if needed)
|
|
129
|
+
|
|
130
|
+
### Good vs Bad PR Descriptions
|
|
131
|
+
|
|
132
|
+
❌ **Bad Example:**
|
|
133
|
+
|
|
134
|
+
> This revolutionary PR introduces a paradigm-shifting enhancement to the system's architecture by implementing a state-of-the-art solution that leverages cutting-edge methodologies to optimize performance metrics and deliver unprecedented value to stakeholders through innovative approaches...
|
|
135
|
+
|
|
136
|
+
✅ **Good Example:**
|
|
137
|
+
|
|
138
|
+
> **What:** Added validation for agent dependency resolution
|
|
139
|
+
> **Why:** Build was failing silently when agents had circular dependencies
|
|
140
|
+
> **How:**
|
|
141
|
+
>
|
|
142
|
+
> - Added cycle detection in dependency-resolver.js
|
|
143
|
+
> - Throws clear error with dependency chain
|
|
144
|
+
> **Testing:** Tested with circular deps between 3 agents
|
|
145
|
+
|
|
37
146
|
## Commit Message Convention
|
|
38
147
|
|
|
39
|
-
|
|
148
|
+
Use conventional commits format:
|
|
149
|
+
|
|
150
|
+
- `feat:` New feature
|
|
151
|
+
- `fix:` Bug fix
|
|
152
|
+
- `docs:` Documentation only
|
|
153
|
+
- `refactor:` Code change that neither fixes a bug nor adds a feature
|
|
154
|
+
- `test:` Adding missing tests
|
|
155
|
+
- `chore:` Changes to build process or auxiliary tools
|
|
156
|
+
|
|
157
|
+
Keep commit messages under 72 characters.
|
|
158
|
+
|
|
159
|
+
### Atomic Commits
|
|
160
|
+
|
|
161
|
+
Each commit should represent one logical change:
|
|
162
|
+
|
|
163
|
+
- **Do:** One bug fix per commit
|
|
164
|
+
- **Do:** One feature addition per commit
|
|
165
|
+
- **Don't:** Mix refactoring with bug fixes
|
|
166
|
+
- **Don't:** Combine unrelated changes
|
|
40
167
|
|
|
41
168
|
## Code Style
|
|
42
169
|
|
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
# BMAD Method Guiding Principles
|
|
2
|
+
|
|
3
|
+
The BMAD Method is a natural language framework for AI-assisted software development. These principles ensure contributions maintain the method's effectiveness.
|
|
4
|
+
|
|
5
|
+
## Core Principles
|
|
6
|
+
|
|
7
|
+
### 1. Dev Agents Must Be Lean
|
|
8
|
+
|
|
9
|
+
- **Minimize dev agent dependencies**: Development agents that work in IDEs must have minimal context overhead
|
|
10
|
+
- **Save context for code**: Every line counts - dev agents should focus on coding, not documentation
|
|
11
|
+
- **Web agents can be larger**: Planning agents (PRD Writer, Architect) used in web UI can have more complex tasks and dependencies
|
|
12
|
+
- **Small files, loaded on demand**: Multiple small, focused files are better than large files with many branches
|
|
13
|
+
|
|
14
|
+
### 2. Natural Language First
|
|
15
|
+
|
|
16
|
+
- **Everything is markdown**: Agents, tasks, templates - all written in plain English
|
|
17
|
+
- **No code in core**: The framework itself contains no programming code, only natural language instructions
|
|
18
|
+
- **Self-contained templates**: Templates include their own generation instructions using `[[LLM: ...]]` markup
|
|
19
|
+
|
|
20
|
+
### 3. Agent and Task Design
|
|
21
|
+
|
|
22
|
+
- **Agents define roles**: Each agent is a persona with specific expertise (e.g., Frontend Developer, API Developer)
|
|
23
|
+
- **Tasks are procedures**: Step-by-step instructions an agent follows to complete work
|
|
24
|
+
- **Templates are outputs**: Structured documents with embedded instructions for generation
|
|
25
|
+
- **Dependencies matter**: Explicitly declare only what's needed
|
|
26
|
+
|
|
27
|
+
## Practical Guidelines
|
|
28
|
+
|
|
29
|
+
### When to Add to Core
|
|
30
|
+
|
|
31
|
+
- Universal software development needs only
|
|
32
|
+
- Doesn't bloat dev agent contexts
|
|
33
|
+
- Follows existing agent/task/template patterns
|
|
34
|
+
|
|
35
|
+
### When to Create Expansion Packs
|
|
36
|
+
|
|
37
|
+
- Domain-specific needs beyond software development
|
|
38
|
+
- Non-technical domains (business, wellness, education, creative)
|
|
39
|
+
- Specialized technical domains (games, infrastructure, mobile)
|
|
40
|
+
- Heavy documentation or knowledge bases
|
|
41
|
+
- Anything that would bloat core agents
|
|
42
|
+
|
|
43
|
+
See [Expansion Packs Guide](../docs/expansion-packs.md) for detailed examples and ideas.
|
|
44
|
+
|
|
45
|
+
### Agent Design Rules
|
|
46
|
+
|
|
47
|
+
1. **Web/Planning Agents**: Can have richer context, multiple tasks, extensive templates
|
|
48
|
+
2. **Dev Agents**: Minimal dependencies, focused on code generation, lean task sets
|
|
49
|
+
3. **All Agents**: Clear persona, specific expertise, well-defined capabilities
|
|
50
|
+
|
|
51
|
+
### Task Writing Rules
|
|
52
|
+
|
|
53
|
+
1. Write clear step-by-step procedures
|
|
54
|
+
2. Use markdown formatting for readability
|
|
55
|
+
3. Keep dev agent tasks focused and concise
|
|
56
|
+
4. Planning tasks can be more elaborate
|
|
57
|
+
5. **Prefer multiple small tasks over one large branching task**
|
|
58
|
+
- Instead of one task with many conditional paths
|
|
59
|
+
- Create multiple focused tasks the agent can choose from
|
|
60
|
+
- This keeps context overhead minimal
|
|
61
|
+
6. **Reuse common tasks** - Don't create new document creation tasks
|
|
62
|
+
- Use the existing `create-doc` task
|
|
63
|
+
- Pass the appropriate template with embedded LLM instructions
|
|
64
|
+
- This maintains consistency and reduces duplication
|
|
65
|
+
|
|
66
|
+
### Template Rules
|
|
67
|
+
|
|
68
|
+
1. Include generation instructions with `[[LLM: ...]]` markup
|
|
69
|
+
2. Provide clear structure for output
|
|
70
|
+
3. Make templates reusable across agents
|
|
71
|
+
4. Use standardized markup elements:
|
|
72
|
+
- `{{placeholders}}` for variables to be replaced
|
|
73
|
+
- `[[LLM: instructions]]` for AI-only processing (never shown to users)
|
|
74
|
+
- `REPEAT` sections for repeatable content blocks
|
|
75
|
+
- `^^CONDITION^^` blocks for conditional content
|
|
76
|
+
- `@{examples}` for guidance examples (never output to users)
|
|
77
|
+
5. NEVER display template markup or LLM instructions to users
|
|
78
|
+
6. Focus on clean output - all processing instructions stay internal
|
|
79
|
+
|
|
80
|
+
## Remember
|
|
81
|
+
|
|
82
|
+
- The power is in natural language orchestration, not code
|
|
83
|
+
- Dev agents code, planning agents plan
|
|
84
|
+
- Keep dev agents lean for maximum coding efficiency
|
|
85
|
+
- Expansion packs handle specialized domains
|
package/README.md
CHANGED
|
@@ -188,14 +188,14 @@ The reason #2 and 3 are optional is because now BMad V4 makes sharding optional
|
|
|
188
188
|
|
|
189
189
|
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.
|
|
190
190
|
|
|
191
|
-
#### Key Features
|
|
191
|
+
#### Key Features
|
|
192
192
|
|
|
193
193
|
- **Version Awareness**: Agents understand if your PRD/Architecture follows V4 conventions or earlier versions
|
|
194
194
|
- **Flexible Document Locations**: Works whether your epics are embedded in PRD or properly sharded
|
|
195
195
|
- **Developer Context**: Define which files the dev agent should always load
|
|
196
196
|
- **Debug Support**: Built-in logging for troubleshooting story implementation
|
|
197
197
|
|
|
198
|
-
#### Why It Matters
|
|
198
|
+
#### Why It Matters
|
|
199
199
|
|
|
200
200
|
- **Use BMAD with ANY project structure** - V3, V4, or custom layouts
|
|
201
201
|
- **No forced migrations** - Keep your existing document organization
|
|
@@ -241,7 +241,7 @@ tools/
|
|
|
241
241
|
├── installer/ # NPX installer
|
|
242
242
|
└── lib/ # Build utilities
|
|
243
243
|
|
|
244
|
-
expansion-packs/ #
|
|
244
|
+
expansion-packs/ # Domain-specific add-ons (Technical & Non-Technical)
|
|
245
245
|
|
|
246
246
|
dist/ # 📦 PRE-BUILT BUNDLES (Ready to use!)
|
|
247
247
|
├── agents/ # Individual agent bundles (.txt files)
|
|
@@ -289,12 +289,60 @@ Rich templates for all document types:
|
|
|
289
289
|
|
|
290
290
|
Ask the agent you are using for help with /help (in the web) or \*help in the ide to see what commands are available!
|
|
291
291
|
|
|
292
|
+
## Expansion Packs - Beyond Software Development
|
|
293
|
+
|
|
294
|
+
BMAD Method's natural language framework isn't limited to software development. Create specialized agents for ANY domain:
|
|
295
|
+
|
|
296
|
+
### Technical Expansion Packs
|
|
297
|
+
|
|
298
|
+
- 🎮 **Game Development** - Game designers, level creators, narrative writers
|
|
299
|
+
- 🏗️ **Infrastructure/DevOps** - Cloud architects, security specialists, SRE agents
|
|
300
|
+
- 📱 **Mobile Development** - iOS/Android specialists, UX designers
|
|
301
|
+
- 🔗 **Blockchain/Web3** - Smart contract developers, DeFi architects
|
|
302
|
+
|
|
303
|
+
### Non-Technical Expansion Packs
|
|
304
|
+
|
|
305
|
+
- 💼 **Business Strategy** - Strategic planners, market analysts, business coaches
|
|
306
|
+
- 💪 **Health & Wellness** - Fitness coaches, nutrition advisors, meditation guides
|
|
307
|
+
- 🎨 **Creative Arts** - Story writers, world builders, character developers
|
|
308
|
+
- 📚 **Education** - Curriculum designers, tutors, learning coaches
|
|
309
|
+
- 🧠 **Personal Development** - Life coaches, goal setters, habit builders
|
|
310
|
+
- 🏢 **Professional Services** - Legal advisors, medical protocols, research assistants
|
|
311
|
+
|
|
312
|
+
### Creating Your Own Expansion Pack
|
|
313
|
+
|
|
314
|
+
The BMAD framework can support any domain where structured AI assistance is valuable:
|
|
315
|
+
|
|
316
|
+
1. Define specialized agents with domain expertise
|
|
317
|
+
2. Create task procedures for common workflows
|
|
318
|
+
3. Build templates for domain-specific outputs
|
|
319
|
+
4. Package as an expansion pack for others to use
|
|
320
|
+
|
|
321
|
+
📖 **[Read the full Expansion Packs Guide](docs/expansion-packs.md)** for detailed examples and inspiration!
|
|
322
|
+
|
|
323
|
+
🛠️ **[Use the Expansion Pack Creator](expansion-packs/expansion-creator/README.md)** to build your own!
|
|
324
|
+
|
|
292
325
|
## Contributing
|
|
293
326
|
|
|
294
|
-
We welcome
|
|
327
|
+
**We're excited about contributions and welcome your ideas, improvements, and expansion packs!** 🎉
|
|
328
|
+
|
|
329
|
+
### Before Contributing - MUST READ
|
|
330
|
+
|
|
331
|
+
To ensure your contribution aligns with the BMAD Method and gets merged smoothly:
|
|
332
|
+
|
|
333
|
+
1. 📋 **Read [CONTRIBUTING.md](CONTRIBUTING.md)** - Our contribution guidelines, PR requirements, and process
|
|
334
|
+
2. 🎯 **Read [GUIDING-PRINCIPLES.md](GUIDING-PRINCIPLES.md)** - Core principles that keep BMAD powerful through simplicity
|
|
335
|
+
3. 🆕 **New to GitHub?** Start with our [Pull Request Guide](docs/how-to-contribute-with-pull-requests.md)
|
|
336
|
+
|
|
337
|
+
### Key Points to Remember
|
|
338
|
+
|
|
339
|
+
- Keep dev agents lean (save context for coding!)
|
|
340
|
+
- Use small, focused files over large branching ones
|
|
341
|
+
- Reuse existing tasks (like `create-doc`) instead of creating duplicates
|
|
342
|
+
- Consider expansion packs for domain-specific features
|
|
343
|
+
- All contributions must follow our natural language, markdown-based approach
|
|
295
344
|
|
|
296
|
-
|
|
297
|
-
- See [CONTRIBUTING.md](CONTRIBUTING.md) for detailed guidelines
|
|
345
|
+
We're building something amazing together - let's keep it simple, powerful, and focused! 💪
|
|
298
346
|
|
|
299
347
|
### Development Setup
|
|
300
348
|
|
|
@@ -310,10 +358,12 @@ npm install
|
|
|
310
358
|
|
|
311
359
|
- 🏗️ [Core Architecture](docs/core-architecture.md) - Complete technical architecture and system design
|
|
312
360
|
- 📖 [User Guide](docs/user-guide.md) - Comprehensive guide to using BMAD-METHOD effectively
|
|
361
|
+
- 🚀 [Expansion Packs Guide](docs/expansion-packs.md) - Extend BMAD to any domain beyond software development
|
|
313
362
|
|
|
314
363
|
### Workflow Guides
|
|
315
364
|
|
|
316
365
|
- 📚 [Universal BMAD Workflow Guide](docs/bmad-workflow-guide.md) - Core workflow that applies to all IDEs
|
|
366
|
+
- 🏗️ [Working in the Brownfield Guide](docs/working-in-the-brownfield.md) - Complete guide for enhancing existing projects
|
|
317
367
|
- 🎯 [Cursor Guide](docs/cursor-guide.md) - Complete workflow for Cursor users
|
|
318
368
|
- 🤖 [Claude Code Guide](docs/claude-code-guide.md) - Complete workflow for Claude Code users
|
|
319
369
|
- 🌊 [Windsurf Guide](docs/windsurf-guide.md) - Complete workflow for Windsurf users
|
|
@@ -16,7 +16,7 @@ agent:
|
|
|
16
16
|
id: analyst
|
|
17
17
|
title: Business Analyst
|
|
18
18
|
icon: 📊
|
|
19
|
-
whenToUse: Use for market research, brainstorming, competitive analysis, creating project briefs,
|
|
19
|
+
whenToUse: Use for market research, brainstorming, competitive analysis, creating project briefs, initial project discovery, and documenting existing projects (brownfield)
|
|
20
20
|
customization: null
|
|
21
21
|
persona:
|
|
22
22
|
role: Insightful Analyst & Strategic Ideation Partner
|
|
@@ -44,6 +44,7 @@ commands: # All commands require * prefix when used (e.g., *help)
|
|
|
44
44
|
- brainstorm {topic}: Facilitate structured brainstorming session
|
|
45
45
|
- research {topic}: Generate deep research prompt for investigation
|
|
46
46
|
- elicit: Run advanced elicitation to clarify requirements
|
|
47
|
+
- document-project: Analyze and document existing project structure comprehensively
|
|
47
48
|
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
|
|
48
49
|
dependencies:
|
|
49
50
|
tasks:
|
|
@@ -51,6 +52,7 @@ dependencies:
|
|
|
51
52
|
- create-deep-research-prompt
|
|
52
53
|
- create-doc
|
|
53
54
|
- advanced-elicitation
|
|
55
|
+
- document-project
|
|
54
56
|
templates:
|
|
55
57
|
- project-brief-tmpl
|
|
56
58
|
- market-research-tmpl
|
package/bmad-core/agents/dev.md
CHANGED
|
@@ -52,9 +52,10 @@ task-execution:
|
|
|
52
52
|
- "Debug Log: | Task | File | Change | Reverted? |"
|
|
53
53
|
- "Completion Notes: Deviations only, <50 words"
|
|
54
54
|
- "Change Log: Requirement changes only"
|
|
55
|
+
- "File List: CRITICAL - Maintain complete list of ALL files created/modified during implementation"
|
|
55
56
|
blocking: "Unapproved deps | Ambiguous after story check | 3 failures | Missing config | Failing validations"
|
|
56
|
-
done: "Code matches reqs + All validations pass + Follows standards"
|
|
57
|
-
completion: "All [x]→Validations pass→Integration(if noted)→E2E(if noted)→DoD→
|
|
57
|
+
done: "Code matches reqs + All validations pass + Follows standards + File List complete"
|
|
58
|
+
completion: "All [x]→Validations pass→Integration(if noted)→E2E(if noted)→DoD→Update File List→Mark Ready for Review→HALT"
|
|
58
59
|
|
|
59
60
|
dependencies:
|
|
60
61
|
tasks:
|
package/bmad-core/agents/qa.md
CHANGED
|
@@ -14,34 +14,35 @@ activation-instructions:
|
|
|
14
14
|
agent:
|
|
15
15
|
name: Quinn
|
|
16
16
|
id: qa
|
|
17
|
-
title:
|
|
17
|
+
title: Senior Developer & QA Architect
|
|
18
18
|
icon: 🧪
|
|
19
|
-
whenToUse: Use for
|
|
19
|
+
whenToUse: Use for senior code review, refactoring, test planning, quality assurance, and mentoring through code improvements
|
|
20
20
|
customization: null
|
|
21
21
|
persona:
|
|
22
|
-
role:
|
|
23
|
-
style: Methodical, detail-oriented, quality-focused, strategic
|
|
24
|
-
identity: Senior
|
|
25
|
-
focus:
|
|
22
|
+
role: Senior Developer & Test Architect
|
|
23
|
+
style: Methodical, detail-oriented, quality-focused, mentoring, strategic
|
|
24
|
+
identity: Senior developer with deep expertise in code quality, architecture, and test automation
|
|
25
|
+
focus: Code excellence through review, refactoring, and comprehensive testing strategies
|
|
26
26
|
core_principles:
|
|
27
|
+
- Senior Developer Mindset - Review and improve code as a senior mentoring juniors
|
|
28
|
+
- Active Refactoring - Don't just identify issues, fix them with clear explanations
|
|
27
29
|
- Test Strategy & Architecture - Design holistic testing strategies across all levels
|
|
28
|
-
-
|
|
30
|
+
- Code Quality Excellence - Enforce best practices, patterns, and clean code principles
|
|
29
31
|
- Shift-Left Testing - Integrate testing early in development lifecycle
|
|
32
|
+
- Performance & Security - Proactively identify and fix performance/security issues
|
|
33
|
+
- Mentorship Through Action - Explain WHY and HOW when making improvements
|
|
30
34
|
- Risk-Based Testing - Prioritize testing based on risk and critical areas
|
|
31
|
-
-
|
|
32
|
-
-
|
|
33
|
-
- Test Data Management - Design strategies for realistic and compliant test data
|
|
34
|
-
- Continuous Testing & CI/CD - Integrate tests seamlessly into pipelines
|
|
35
|
-
- Quality Metrics & Reporting - Track meaningful metrics and provide insights
|
|
36
|
-
- Cross-Browser & Cross-Platform Testing - Ensure comprehensive compatibility
|
|
35
|
+
- Continuous Improvement - Balance perfection with pragmatism
|
|
36
|
+
- Architecture & Design Patterns - Ensure proper patterns and maintainable code structure
|
|
37
37
|
startup:
|
|
38
38
|
- Greet the user with your name and role, and inform of the *help command.
|
|
39
39
|
commands: # All commands require * prefix when used (e.g., *help)
|
|
40
40
|
- help: Show numbered list of the following commands to allow selection
|
|
41
41
|
- chat-mode: (Default) QA consultation with advanced-elicitation for test strategy
|
|
42
|
-
- create-doc {template}: Create doc (no template = show available templates)
|
|
43
42
|
- exit: Say goodbye as the QA Test Architect, and then abandon inhabiting this persona
|
|
44
43
|
dependencies:
|
|
44
|
+
tasks:
|
|
45
|
+
- review-story
|
|
45
46
|
data:
|
|
46
47
|
- technical-preferences
|
|
47
48
|
utils:
|