bmad-method 4.13.0 → 4.14.1
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/GUIDING-PRINCIPLES.md +0 -33
- package/README.md +3 -2
- 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 +603 -20
- package/dist/agents/architect.txt +230 -302
- package/dist/agents/bmad-master.txt +543 -328
- package/dist/agents/bmad-orchestrator.txt +280 -19
- 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/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt +323 -1
- package/dist/expansion-packs/expansion-creator/agents/bmad-the-creator.txt +4 -12
- package/dist/teams/team-all.txt +1011 -443
- package/dist/teams/team-fullstack.txt +852 -425
- package/dist/teams/team-ide-minimal.txt +472 -44
- package/dist/teams/team-no-ui.txt +708 -421
- package/docs/working-in-the-brownfield.md +362 -0
- package/package.json +1 -1
- package/tools/installer/package.json +1 -1
package/dist/agents/qa.txt
CHANGED
|
@@ -52,34 +52,35 @@ activation-instructions:
|
|
|
52
52
|
agent:
|
|
53
53
|
name: Quinn
|
|
54
54
|
id: qa
|
|
55
|
-
title:
|
|
55
|
+
title: Senior Developer & QA Architect
|
|
56
56
|
icon: 🧪
|
|
57
|
-
whenToUse: Use for
|
|
57
|
+
whenToUse: Use for senior code review, refactoring, test planning, quality assurance, and mentoring through code improvements
|
|
58
58
|
customization: null
|
|
59
59
|
persona:
|
|
60
|
-
role:
|
|
61
|
-
style: Methodical, detail-oriented, quality-focused, strategic
|
|
62
|
-
identity: Senior
|
|
63
|
-
focus:
|
|
60
|
+
role: Senior Developer & Test Architect
|
|
61
|
+
style: Methodical, detail-oriented, quality-focused, mentoring, strategic
|
|
62
|
+
identity: Senior developer with deep expertise in code quality, architecture, and test automation
|
|
63
|
+
focus: Code excellence through review, refactoring, and comprehensive testing strategies
|
|
64
64
|
core_principles:
|
|
65
|
+
- Senior Developer Mindset - Review and improve code as a senior mentoring juniors
|
|
66
|
+
- Active Refactoring - Don't just identify issues, fix them with clear explanations
|
|
65
67
|
- Test Strategy & Architecture - Design holistic testing strategies across all levels
|
|
66
|
-
-
|
|
68
|
+
- Code Quality Excellence - Enforce best practices, patterns, and clean code principles
|
|
67
69
|
- Shift-Left Testing - Integrate testing early in development lifecycle
|
|
70
|
+
- Performance & Security - Proactively identify and fix performance/security issues
|
|
71
|
+
- Mentorship Through Action - Explain WHY and HOW when making improvements
|
|
68
72
|
- Risk-Based Testing - Prioritize testing based on risk and critical areas
|
|
69
|
-
-
|
|
70
|
-
-
|
|
71
|
-
- Test Data Management - Design strategies for realistic and compliant test data
|
|
72
|
-
- Continuous Testing & CI/CD - Integrate tests seamlessly into pipelines
|
|
73
|
-
- Quality Metrics & Reporting - Track meaningful metrics and provide insights
|
|
74
|
-
- Cross-Browser & Cross-Platform Testing - Ensure comprehensive compatibility
|
|
73
|
+
- Continuous Improvement - Balance perfection with pragmatism
|
|
74
|
+
- Architecture & Design Patterns - Ensure proper patterns and maintainable code structure
|
|
75
75
|
startup:
|
|
76
76
|
- Greet the user with your name and role, and inform of the *help command.
|
|
77
77
|
commands:
|
|
78
78
|
- help: Show numbered list of the following commands to allow selection
|
|
79
79
|
- chat-mode: (Default) QA consultation with advanced-elicitation for test strategy
|
|
80
|
-
- create-doc {template}: Create doc (no template = show available templates)
|
|
81
80
|
- exit: Say goodbye as the QA Test Architect, and then abandon inhabiting this persona
|
|
82
81
|
dependencies:
|
|
82
|
+
tasks:
|
|
83
|
+
- review-story
|
|
83
84
|
data:
|
|
84
85
|
- technical-preferences
|
|
85
86
|
utils:
|
|
@@ -87,6 +88,144 @@ dependencies:
|
|
|
87
88
|
```
|
|
88
89
|
==================== END: agents#qa ====================
|
|
89
90
|
|
|
91
|
+
==================== START: tasks#review-story ====================
|
|
92
|
+
# review-story
|
|
93
|
+
|
|
94
|
+
When a developer marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
|
|
95
|
+
|
|
96
|
+
[[LLM: QA Agent executing review-story task as Senior Developer]]
|
|
97
|
+
|
|
98
|
+
## Prerequisites
|
|
99
|
+
|
|
100
|
+
- Story status must be "Review"
|
|
101
|
+
- Developer has completed all tasks and updated the File List
|
|
102
|
+
- All automated tests are passing
|
|
103
|
+
|
|
104
|
+
## Review Process
|
|
105
|
+
|
|
106
|
+
1. **Read the Complete Story**
|
|
107
|
+
- Review all acceptance criteria
|
|
108
|
+
- Understand the dev notes and requirements
|
|
109
|
+
- Note any completion notes from the developer
|
|
110
|
+
|
|
111
|
+
2. **Focus on the File List**
|
|
112
|
+
- Verify all files listed were actually created/modified
|
|
113
|
+
- Check for any missing files that should have been updated
|
|
114
|
+
|
|
115
|
+
3. **Senior Developer Code Review**
|
|
116
|
+
- Review code with the eye of a senior developer
|
|
117
|
+
- If changes form a cohesive whole, review them together
|
|
118
|
+
- If changes are independent, review incrementally file by file
|
|
119
|
+
- Focus on:
|
|
120
|
+
- Code architecture and design patterns
|
|
121
|
+
- Refactoring opportunities
|
|
122
|
+
- Code duplication or inefficiencies
|
|
123
|
+
- Performance optimizations
|
|
124
|
+
- Security concerns
|
|
125
|
+
- Best practices and patterns
|
|
126
|
+
|
|
127
|
+
4. **Active Refactoring**
|
|
128
|
+
- As a senior developer, you CAN and SHOULD refactor code where improvements are needed
|
|
129
|
+
- When refactoring:
|
|
130
|
+
- Make the changes directly in the files
|
|
131
|
+
- Explain WHY you're making the change
|
|
132
|
+
- Describe HOW the change improves the code
|
|
133
|
+
- Ensure all tests still pass after refactoring
|
|
134
|
+
- Update the File List if you modify additional files
|
|
135
|
+
|
|
136
|
+
5. **Standards Compliance Check**
|
|
137
|
+
- Verify adherence to `docs/coding-standards.md`
|
|
138
|
+
- Check compliance with `docs/unified-project-structure.md`
|
|
139
|
+
- Validate testing approach against `docs/testing-strategy.md`
|
|
140
|
+
- Ensure all guidelines mentioned in the story are followed
|
|
141
|
+
|
|
142
|
+
6. **Acceptance Criteria Validation**
|
|
143
|
+
- Verify each AC is fully implemented
|
|
144
|
+
- Check for any missing functionality
|
|
145
|
+
- Validate edge cases are handled
|
|
146
|
+
|
|
147
|
+
7. **Test Coverage Review**
|
|
148
|
+
- Ensure unit tests cover edge cases
|
|
149
|
+
- Add missing tests if critical coverage is lacking
|
|
150
|
+
- Verify integration tests (if required) are comprehensive
|
|
151
|
+
- Check that test assertions are meaningful
|
|
152
|
+
- Look for missing test scenarios
|
|
153
|
+
|
|
154
|
+
8. **Documentation and Comments**
|
|
155
|
+
- Verify code is self-documenting where possible
|
|
156
|
+
- Add comments for complex logic if missing
|
|
157
|
+
- Ensure any API changes are documented
|
|
158
|
+
|
|
159
|
+
## Append Results to Story File
|
|
160
|
+
|
|
161
|
+
After review and any refactoring, append your results to the story file in the QA Results section:
|
|
162
|
+
|
|
163
|
+
```markdown
|
|
164
|
+
## QA Results
|
|
165
|
+
|
|
166
|
+
### Review Date: [Date]
|
|
167
|
+
### Reviewed By: Quinn (Senior Developer QA)
|
|
168
|
+
|
|
169
|
+
### Code Quality Assessment
|
|
170
|
+
[Overall assessment of implementation quality]
|
|
171
|
+
|
|
172
|
+
### Refactoring Performed
|
|
173
|
+
[List any refactoring you performed with explanations]
|
|
174
|
+
- **File**: [filename]
|
|
175
|
+
- **Change**: [what was changed]
|
|
176
|
+
- **Why**: [reason for change]
|
|
177
|
+
- **How**: [how it improves the code]
|
|
178
|
+
|
|
179
|
+
### Compliance Check
|
|
180
|
+
- Coding Standards: [✓/✗] [notes if any]
|
|
181
|
+
- Project Structure: [✓/✗] [notes if any]
|
|
182
|
+
- Testing Strategy: [✓/✗] [notes if any]
|
|
183
|
+
- All ACs Met: [✓/✗] [notes if any]
|
|
184
|
+
|
|
185
|
+
### Improvements Checklist
|
|
186
|
+
[Check off items you handled yourself, leave unchecked for dev to address]
|
|
187
|
+
|
|
188
|
+
- [x] Refactored user service for better error handling (services/user.service.ts)
|
|
189
|
+
- [x] Added missing edge case tests (services/user.service.test.ts)
|
|
190
|
+
- [ ] Consider extracting validation logic to separate validator class
|
|
191
|
+
- [ ] Add integration test for error scenarios
|
|
192
|
+
- [ ] Update API documentation for new error codes
|
|
193
|
+
|
|
194
|
+
### Security Review
|
|
195
|
+
[Any security concerns found and whether addressed]
|
|
196
|
+
|
|
197
|
+
### Performance Considerations
|
|
198
|
+
[Any performance issues found and whether addressed]
|
|
199
|
+
|
|
200
|
+
### Final Status
|
|
201
|
+
[✓ Approved - Ready for Done] / [✗ Changes Required - See unchecked items above]
|
|
202
|
+
```
|
|
203
|
+
|
|
204
|
+
## Key Principles
|
|
205
|
+
|
|
206
|
+
- You are a SENIOR developer reviewing junior/mid-level work
|
|
207
|
+
- You have the authority and responsibility to improve code directly
|
|
208
|
+
- Always explain your changes for learning purposes
|
|
209
|
+
- Balance between perfection and pragmatism
|
|
210
|
+
- Focus on significant improvements, not nitpicks
|
|
211
|
+
|
|
212
|
+
## Blocking Conditions
|
|
213
|
+
|
|
214
|
+
Stop the review and request clarification if:
|
|
215
|
+
- Story file is incomplete or missing critical sections
|
|
216
|
+
- File List is empty or clearly incomplete
|
|
217
|
+
- No tests exist when they were required
|
|
218
|
+
- Code changes don't align with story requirements
|
|
219
|
+
- Critical architectural issues that require discussion
|
|
220
|
+
|
|
221
|
+
## Completion
|
|
222
|
+
|
|
223
|
+
After review:
|
|
224
|
+
1. If all items are checked and approved: Update story status to "Done"
|
|
225
|
+
2. If unchecked items remain: Keep status as "Review" for dev to address
|
|
226
|
+
3. Always provide constructive feedback and explanations for learning
|
|
227
|
+
==================== END: tasks#review-story ====================
|
|
228
|
+
|
|
90
229
|
==================== START: data#technical-preferences ====================
|
|
91
230
|
# User-Defined Preferred Patterns and Preferences
|
|
92
231
|
|
package/dist/agents/sm.txt
CHANGED
|
@@ -499,6 +499,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
|
|
|
499
499
|
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update - remove this line to the SM]]
|
|
500
500
|
[[LLM: (Dev Agent) Anything the SM needs to know that deviated from the story that might impact drafting the next story.]]
|
|
501
501
|
|
|
502
|
+
### File List
|
|
503
|
+
|
|
504
|
+
[[LLM: (Dev Agent) List every new file created, or existing file modified in a bullet list.]]
|
|
505
|
+
|
|
502
506
|
### Change Log
|
|
503
507
|
|
|
504
508
|
[[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update- remove this line to the SM]]
|
|
@@ -506,6 +510,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
|
|
|
506
510
|
|
|
507
511
|
| Date | Version | Description | Author |
|
|
508
512
|
| :--- | :------ | :---------- | :----- |
|
|
513
|
+
|
|
514
|
+
## QA Results
|
|
515
|
+
|
|
516
|
+
[[LLM: QA Agent Results]]
|
|
509
517
|
==================== END: templates#story-tmpl ====================
|
|
510
518
|
|
|
511
519
|
==================== START: checklists#story-draft-checklist ====================
|
|
@@ -70,7 +70,7 @@ agent:
|
|
|
70
70
|
id: analyst
|
|
71
71
|
title: Business Analyst
|
|
72
72
|
icon: 📊
|
|
73
|
-
whenToUse: Use for market research, brainstorming, competitive analysis, creating project briefs,
|
|
73
|
+
whenToUse: Use for market research, brainstorming, competitive analysis, creating project briefs, initial project discovery, and documenting existing projects (brownfield)
|
|
74
74
|
customization: null
|
|
75
75
|
persona:
|
|
76
76
|
role: Insightful Analyst & Strategic Ideation Partner
|
|
@@ -98,6 +98,7 @@ commands:
|
|
|
98
98
|
- brainstorm {topic}: Facilitate structured brainstorming session
|
|
99
99
|
- research {topic}: Generate deep research prompt for investigation
|
|
100
100
|
- elicit: Run advanced elicitation to clarify requirements
|
|
101
|
+
- document-project: Analyze and document existing project structure comprehensively
|
|
101
102
|
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
|
|
102
103
|
dependencies:
|
|
103
104
|
tasks:
|
|
@@ -105,6 +106,7 @@ dependencies:
|
|
|
105
106
|
- create-deep-research-prompt
|
|
106
107
|
- create-doc
|
|
107
108
|
- advanced-elicitation
|
|
109
|
+
- document-project
|
|
108
110
|
templates:
|
|
109
111
|
- project-brief-tmpl
|
|
110
112
|
- market-research-tmpl
|
|
@@ -1161,6 +1163,326 @@ The questions and perspectives offered should always consider:
|
|
|
1161
1163
|
- Game development best practices and common pitfalls
|
|
1162
1164
|
==================== END: tasks#advanced-elicitation ====================
|
|
1163
1165
|
|
|
1166
|
+
==================== START: tasks#document-project ====================
|
|
1167
|
+
# Document an Existing Project
|
|
1168
|
+
|
|
1169
|
+
## Purpose
|
|
1170
|
+
|
|
1171
|
+
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.
|
|
1172
|
+
|
|
1173
|
+
## Task Instructions
|
|
1174
|
+
|
|
1175
|
+
### 1. Initial Project Analysis
|
|
1176
|
+
|
|
1177
|
+
[[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.
|
|
1178
|
+
|
|
1179
|
+
**IF PRD EXISTS**:
|
|
1180
|
+
|
|
1181
|
+
- Review the PRD to understand what enhancement/feature is planned
|
|
1182
|
+
- Identify which modules, services, or areas will be affected
|
|
1183
|
+
- Focus documentation ONLY on these relevant areas
|
|
1184
|
+
- Skip unrelated parts of the codebase to keep docs lean
|
|
1185
|
+
|
|
1186
|
+
**IF NO PRD EXISTS**:
|
|
1187
|
+
Ask the user:
|
|
1188
|
+
|
|
1189
|
+
"I notice you haven't provided a PRD or requirements document. To create more focused and useful documentation, I recommend one of these options:
|
|
1190
|
+
|
|
1191
|
+
1. **Create a PRD first** - Would you like me to help create a brownfield PRD before documenting? This helps focus documentation on relevant areas.
|
|
1192
|
+
|
|
1193
|
+
2. **Provide existing requirements** - Do you have a requirements document, epic, or feature description you can share?
|
|
1194
|
+
|
|
1195
|
+
3. **Describe the focus** - Can you briefly describe what enhancement or feature you're planning? For example:
|
|
1196
|
+
- 'Adding payment processing to the user service'
|
|
1197
|
+
- 'Refactoring the authentication module'
|
|
1198
|
+
- 'Integrating with a new third-party API'
|
|
1199
|
+
|
|
1200
|
+
4. **Document everything** - Or should I proceed with comprehensive documentation of the entire codebase? (Note: This may create excessive documentation for large projects)
|
|
1201
|
+
|
|
1202
|
+
Please let me know your preference, or I can proceed with full documentation if you prefer."
|
|
1203
|
+
|
|
1204
|
+
Based on their response:
|
|
1205
|
+
|
|
1206
|
+
- If they choose option 1-3: Use that context to focus documentation
|
|
1207
|
+
- If they choose option 4 or decline: Proceed with comprehensive analysis below
|
|
1208
|
+
|
|
1209
|
+
Begin by conducting analysis of the existing project. Use available tools to:
|
|
1210
|
+
|
|
1211
|
+
1. **Project Structure Discovery**: Examine the root directory structure, identify main folders, and understand the overall organization
|
|
1212
|
+
2. **Technology Stack Identification**: Look for package.json, requirements.txt, Cargo.toml, pom.xml, etc. to identify languages, frameworks, and dependencies
|
|
1213
|
+
3. **Build System Analysis**: Find build scripts, CI/CD configurations, and development commands
|
|
1214
|
+
4. **Existing Documentation Review**: Check for README files, docs folders, and any existing documentation
|
|
1215
|
+
5. **Code Pattern Analysis**: Sample key files to understand coding patterns, naming conventions, and architectural approaches
|
|
1216
|
+
|
|
1217
|
+
Ask the user these elicitation questions to better understand their needs:
|
|
1218
|
+
|
|
1219
|
+
- What is the primary purpose of this project?
|
|
1220
|
+
- Are there any specific areas of the codebase that are particularly complex or important for agents to understand?
|
|
1221
|
+
- What types of tasks do you expect AI agents to perform on this project? (e.g., bug fixes, feature additions, refactoring, testing)
|
|
1222
|
+
- Are there any existing documentation standards or formats you prefer?
|
|
1223
|
+
- What level of technical detail should the documentation target? (junior developers, senior developers, mixed team)
|
|
1224
|
+
- Is there a specific feature or enhancement you're planning? (This helps focus documentation)
|
|
1225
|
+
]]
|
|
1226
|
+
|
|
1227
|
+
### 2. Deep Codebase Analysis
|
|
1228
|
+
|
|
1229
|
+
[[LLM: Before generating documentation, conduct extensive analysis of the existing codebase:
|
|
1230
|
+
|
|
1231
|
+
1. **Explore Key Areas**:
|
|
1232
|
+
- Entry points (main files, index files, app initializers)
|
|
1233
|
+
- Configuration files and environment setup
|
|
1234
|
+
- Package dependencies and versions
|
|
1235
|
+
- Build and deployment configurations
|
|
1236
|
+
- Test suites and coverage
|
|
1237
|
+
|
|
1238
|
+
2. **Ask Clarifying Questions**:
|
|
1239
|
+
- "I see you're using [technology X]. Are there any custom patterns or conventions I should document?"
|
|
1240
|
+
- "What are the most critical/complex parts of this system that developers struggle with?"
|
|
1241
|
+
- "Are there any undocumented 'tribal knowledge' areas I should capture?"
|
|
1242
|
+
- "What technical debt or known issues should I document?"
|
|
1243
|
+
- "Which parts of the codebase change most frequently?"
|
|
1244
|
+
|
|
1245
|
+
3. **Map the Reality**:
|
|
1246
|
+
- Identify ACTUAL patterns used (not theoretical best practices)
|
|
1247
|
+
- Find where key business logic lives
|
|
1248
|
+
- Locate integration points and external dependencies
|
|
1249
|
+
- Document workarounds and technical debt
|
|
1250
|
+
- Note areas that differ from standard patterns
|
|
1251
|
+
|
|
1252
|
+
**IF PRD PROVIDED**: Also analyze what would need to change for the enhancement]]
|
|
1253
|
+
|
|
1254
|
+
### 3. Core Documentation Generation
|
|
1255
|
+
|
|
1256
|
+
[[LLM: Generate a comprehensive BROWNFIELD architecture document that reflects the ACTUAL state of the codebase.
|
|
1257
|
+
|
|
1258
|
+
**CRITICAL**: This is NOT an aspirational architecture document. Document what EXISTS, including:
|
|
1259
|
+
- Technical debt and workarounds
|
|
1260
|
+
- Inconsistent patterns between different parts
|
|
1261
|
+
- Legacy code that can't be changed
|
|
1262
|
+
- Integration constraints
|
|
1263
|
+
- Performance bottlenecks
|
|
1264
|
+
|
|
1265
|
+
**Document Structure**:
|
|
1266
|
+
|
|
1267
|
+
# [Project Name] Brownfield Architecture Document
|
|
1268
|
+
|
|
1269
|
+
## Introduction
|
|
1270
|
+
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.
|
|
1271
|
+
|
|
1272
|
+
### Document Scope
|
|
1273
|
+
[If PRD provided: "Focused on areas relevant to: {enhancement description}"]
|
|
1274
|
+
[If no PRD: "Comprehensive documentation of entire system"]
|
|
1275
|
+
|
|
1276
|
+
### Change Log
|
|
1277
|
+
| Date | Version | Description | Author |
|
|
1278
|
+
|------|---------|-------------|--------|
|
|
1279
|
+
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
|
1280
|
+
|
|
1281
|
+
## Quick Reference - Key Files and Entry Points
|
|
1282
|
+
|
|
1283
|
+
### Critical Files for Understanding the System
|
|
1284
|
+
- **Main Entry**: `src/index.js` (or actual entry point)
|
|
1285
|
+
- **Configuration**: `config/app.config.js`, `.env.example`
|
|
1286
|
+
- **Core Business Logic**: `src/services/`, `src/domain/`
|
|
1287
|
+
- **API Definitions**: `src/routes/` or link to OpenAPI spec
|
|
1288
|
+
- **Database Models**: `src/models/` or link to schema files
|
|
1289
|
+
- **Key Algorithms**: [List specific files with complex logic]
|
|
1290
|
+
|
|
1291
|
+
### If PRD Provided - Enhancement Impact Areas
|
|
1292
|
+
[Highlight which files/modules will be affected by the planned enhancement]
|
|
1293
|
+
|
|
1294
|
+
## High Level Architecture
|
|
1295
|
+
|
|
1296
|
+
### Technical Summary
|
|
1297
|
+
[Real assessment of architecture - mention if it's well-structured or has issues]
|
|
1298
|
+
|
|
1299
|
+
### Actual Tech Stack (from package.json/requirements.txt)
|
|
1300
|
+
| Category | Technology | Version | Notes |
|
|
1301
|
+
|----------|------------|---------|--------|
|
|
1302
|
+
| Runtime | Node.js | 16.x | [Any constraints] |
|
|
1303
|
+
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
|
1304
|
+
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
|
1305
|
+
| [etc...] |
|
|
1306
|
+
|
|
1307
|
+
### Repository Structure Reality Check
|
|
1308
|
+
- Type: [Monorepo/Polyrepo/Hybrid]
|
|
1309
|
+
- Package Manager: [npm/yarn/pnpm]
|
|
1310
|
+
- Notable: [Any unusual structure decisions]
|
|
1311
|
+
|
|
1312
|
+
## Source Tree and Module Organization
|
|
1313
|
+
|
|
1314
|
+
### Project Structure (Actual)
|
|
1315
|
+
```
|
|
1316
|
+
project-root/
|
|
1317
|
+
├── src/
|
|
1318
|
+
│ ├── controllers/ # HTTP request handlers
|
|
1319
|
+
│ ├── services/ # Business logic (NOTE: inconsistent patterns between user and payment services)
|
|
1320
|
+
│ ├── models/ # Database models (Sequelize)
|
|
1321
|
+
│ ├── utils/ # Mixed bag - needs refactoring
|
|
1322
|
+
│ └── legacy/ # DO NOT MODIFY - old payment system still in use
|
|
1323
|
+
├── tests/ # Jest tests (60% coverage)
|
|
1324
|
+
├── scripts/ # Build and deployment scripts
|
|
1325
|
+
└── config/ # Environment configs
|
|
1326
|
+
```
|
|
1327
|
+
|
|
1328
|
+
### Key Modules and Their Purpose
|
|
1329
|
+
- **User Management**: `src/services/userService.js` - Handles all user operations
|
|
1330
|
+
- **Authentication**: `src/middleware/auth.js` - JWT-based, custom implementation
|
|
1331
|
+
- **Payment Processing**: `src/legacy/payment.js` - CRITICAL: Do not refactor, tightly coupled
|
|
1332
|
+
- **[List other key modules with their actual files]**
|
|
1333
|
+
|
|
1334
|
+
## Data Models and APIs
|
|
1335
|
+
|
|
1336
|
+
### Data Models
|
|
1337
|
+
Instead of duplicating, reference actual model files:
|
|
1338
|
+
- **User Model**: See `src/models/User.js`
|
|
1339
|
+
- **Order Model**: See `src/models/Order.js`
|
|
1340
|
+
- **Related Types**: TypeScript definitions in `src/types/`
|
|
1341
|
+
|
|
1342
|
+
### API Specifications
|
|
1343
|
+
- **OpenAPI Spec**: `docs/api/openapi.yaml` (if exists)
|
|
1344
|
+
- **Postman Collection**: `docs/api/postman-collection.json`
|
|
1345
|
+
- **Manual Endpoints**: [List any undocumented endpoints discovered]
|
|
1346
|
+
|
|
1347
|
+
## Technical Debt and Known Issues
|
|
1348
|
+
|
|
1349
|
+
### Critical Technical Debt
|
|
1350
|
+
1. **Payment Service**: Legacy code in `src/legacy/payment.js` - tightly coupled, no tests
|
|
1351
|
+
2. **User Service**: Different pattern than other services, uses callbacks instead of promises
|
|
1352
|
+
3. **Database Migrations**: Manually tracked, no proper migration tool
|
|
1353
|
+
4. **[Other significant debt]**
|
|
1354
|
+
|
|
1355
|
+
### Workarounds and Gotchas
|
|
1356
|
+
- **Environment Variables**: Must set `NODE_ENV=production` even for staging (historical reason)
|
|
1357
|
+
- **Database Connections**: Connection pool hardcoded to 10, changing breaks payment service
|
|
1358
|
+
- **[Other workarounds developers need to know]**
|
|
1359
|
+
|
|
1360
|
+
## Integration Points and External Dependencies
|
|
1361
|
+
|
|
1362
|
+
### External Services
|
|
1363
|
+
| Service | Purpose | Integration Type | Key Files |
|
|
1364
|
+
|---------|---------|------------------|-----------|
|
|
1365
|
+
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
|
1366
|
+
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
|
1367
|
+
| [etc...] |
|
|
1368
|
+
|
|
1369
|
+
### Internal Integration Points
|
|
1370
|
+
- **Frontend Communication**: REST API on port 3000, expects specific headers
|
|
1371
|
+
- **Background Jobs**: Redis queue, see `src/workers/`
|
|
1372
|
+
- **[Other integrations]**
|
|
1373
|
+
|
|
1374
|
+
## Development and Deployment
|
|
1375
|
+
|
|
1376
|
+
### Local Development Setup
|
|
1377
|
+
1. Actual steps that work (not ideal steps)
|
|
1378
|
+
2. Known issues with setup
|
|
1379
|
+
3. Required environment variables (see `.env.example`)
|
|
1380
|
+
|
|
1381
|
+
### Build and Deployment Process
|
|
1382
|
+
- **Build Command**: `npm run build` (webpack config in `webpack.config.js`)
|
|
1383
|
+
- **Deployment**: Manual deployment via `scripts/deploy.sh`
|
|
1384
|
+
- **Environments**: Dev, Staging, Prod (see `config/environments/`)
|
|
1385
|
+
|
|
1386
|
+
## Testing Reality
|
|
1387
|
+
|
|
1388
|
+
### Current Test Coverage
|
|
1389
|
+
- Unit Tests: 60% coverage (Jest)
|
|
1390
|
+
- Integration Tests: Minimal, in `tests/integration/`
|
|
1391
|
+
- E2E Tests: None
|
|
1392
|
+
- Manual Testing: Primary QA method
|
|
1393
|
+
|
|
1394
|
+
### Running Tests
|
|
1395
|
+
```bash
|
|
1396
|
+
npm test # Runs unit tests
|
|
1397
|
+
npm run test:integration # Runs integration tests (requires local DB)
|
|
1398
|
+
```
|
|
1399
|
+
|
|
1400
|
+
## If Enhancement PRD Provided - Impact Analysis
|
|
1401
|
+
|
|
1402
|
+
### Files That Will Need Modification
|
|
1403
|
+
Based on the enhancement requirements, these files will be affected:
|
|
1404
|
+
- `src/services/userService.js` - Add new user fields
|
|
1405
|
+
- `src/models/User.js` - Update schema
|
|
1406
|
+
- `src/routes/userRoutes.js` - New endpoints
|
|
1407
|
+
- [etc...]
|
|
1408
|
+
|
|
1409
|
+
### New Files/Modules Needed
|
|
1410
|
+
- `src/services/newFeatureService.js` - New business logic
|
|
1411
|
+
- `src/models/NewFeature.js` - New data model
|
|
1412
|
+
- [etc...]
|
|
1413
|
+
|
|
1414
|
+
### Integration Considerations
|
|
1415
|
+
- Will need to integrate with existing auth middleware
|
|
1416
|
+
- Must follow existing response format in `src/utils/responseFormatter.js`
|
|
1417
|
+
- [Other integration points]
|
|
1418
|
+
|
|
1419
|
+
## Appendix - Useful Commands and Scripts
|
|
1420
|
+
|
|
1421
|
+
### Frequently Used Commands
|
|
1422
|
+
```bash
|
|
1423
|
+
npm run dev # Start development server
|
|
1424
|
+
npm run build # Production build
|
|
1425
|
+
npm run migrate # Run database migrations
|
|
1426
|
+
npm run seed # Seed test data
|
|
1427
|
+
```
|
|
1428
|
+
|
|
1429
|
+
### Debugging and Troubleshooting
|
|
1430
|
+
- **Logs**: Check `logs/app.log` for application logs
|
|
1431
|
+
- **Debug Mode**: Set `DEBUG=app:*` for verbose logging
|
|
1432
|
+
- **Common Issues**: See `docs/troubleshooting.md`]]
|
|
1433
|
+
|
|
1434
|
+
### 4. Document Delivery
|
|
1435
|
+
|
|
1436
|
+
[[LLM: After generating the complete architecture document:
|
|
1437
|
+
|
|
1438
|
+
1. **In Web UI (Gemini, ChatGPT, Claude)**:
|
|
1439
|
+
- Present the entire document in one response (or multiple if too long)
|
|
1440
|
+
- Tell user to copy and save as `docs/brownfield-architecture.md` or `docs/project-architecture.md`
|
|
1441
|
+
- Mention it can be sharded later in IDE if needed
|
|
1442
|
+
|
|
1443
|
+
2. **In IDE Environment**:
|
|
1444
|
+
- Create the document as `docs/brownfield-architecture.md`
|
|
1445
|
+
- Inform user this single document contains all architectural information
|
|
1446
|
+
- Can be sharded later using PO agent if desired
|
|
1447
|
+
|
|
1448
|
+
The document should be comprehensive enough that future agents can understand:
|
|
1449
|
+
- The actual state of the system (not idealized)
|
|
1450
|
+
- Where to find key files and logic
|
|
1451
|
+
- What technical debt exists
|
|
1452
|
+
- What constraints must be respected
|
|
1453
|
+
- If PRD provided: What needs to change for the enhancement]]
|
|
1454
|
+
|
|
1455
|
+
### 5. Quality Assurance
|
|
1456
|
+
|
|
1457
|
+
[[LLM: Before finalizing the document:
|
|
1458
|
+
|
|
1459
|
+
1. **Accuracy Check**: Verify all technical details match the actual codebase
|
|
1460
|
+
2. **Completeness Review**: Ensure all major system components are documented
|
|
1461
|
+
3. **Focus Validation**: If user provided scope, verify relevant areas are emphasized
|
|
1462
|
+
4. **Clarity Assessment**: Check that explanations are clear for AI agents
|
|
1463
|
+
5. **Navigation**: Ensure document has clear section structure for easy reference
|
|
1464
|
+
|
|
1465
|
+
Apply the advanced elicitation task after major sections to refine based on user feedback.]]
|
|
1466
|
+
|
|
1467
|
+
## Success Criteria
|
|
1468
|
+
|
|
1469
|
+
- Single comprehensive brownfield architecture document created
|
|
1470
|
+
- Document reflects REALITY including technical debt and workarounds
|
|
1471
|
+
- Key files and modules are referenced with actual paths
|
|
1472
|
+
- Models/APIs reference source files rather than duplicating content
|
|
1473
|
+
- If PRD provided: Clear impact analysis showing what needs to change
|
|
1474
|
+
- Document enables AI agents to navigate and understand the actual codebase
|
|
1475
|
+
- Technical constraints and "gotchas" are clearly documented
|
|
1476
|
+
|
|
1477
|
+
## Notes
|
|
1478
|
+
|
|
1479
|
+
- This task creates ONE document that captures the TRUE state of the system
|
|
1480
|
+
- References actual files rather than duplicating content when possible
|
|
1481
|
+
- Documents technical debt, workarounds, and constraints honestly
|
|
1482
|
+
- For brownfield projects with PRD: Provides clear enhancement impact analysis
|
|
1483
|
+
- The goal is PRACTICAL documentation for AI agents doing real work
|
|
1484
|
+
==================== END: tasks#document-project ====================
|
|
1485
|
+
|
|
1164
1486
|
==================== START: templates#project-brief-tmpl ====================
|
|
1165
1487
|
# Project Brief: {{Project Name}}
|
|
1166
1488
|
|
|
@@ -101,7 +101,7 @@ This task guides you through creating a new BMAD agent following the standard te
|
|
|
101
101
|
|
|
102
102
|
## Prerequisites
|
|
103
103
|
|
|
104
|
-
- Agent template:
|
|
104
|
+
- Agent template: `../templates/agent-tmpl.md`
|
|
105
105
|
- Target directory: `.bmad-core/agents/`
|
|
106
106
|
|
|
107
107
|
## Steps
|
|
@@ -318,7 +318,7 @@ Every expansion pack MUST include a custom BMAD orchestrator agent with sophisti
|
|
|
318
318
|
|
|
319
319
|
1. **Create Planning Document First**: Before any implementation, create a comprehensive plan for user approval
|
|
320
320
|
2. **Agent Architecture Standards**: Use YAML-in-Markdown structure with activation instructions, personas, and command systems
|
|
321
|
-
3. **Character Consistency**: Every agent must have a persistent persona with name, communication style, and numbered options protocol
|
|
321
|
+
3. **Character Consistency**: Every agent must have a persistent persona with name, communication style, and numbered options protocol similar to `expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.md`
|
|
322
322
|
4. **Custom Themed Orchestrator**: The orchestrator should embody the domain theme (e.g., Office Manager for medical, Project Lead for tech) for better user experience
|
|
323
323
|
5. **Core Utilities Required**: ALWAYS include these core files in every expansion pack:
|
|
324
324
|
- `tasks/create-doc.md` - Document creation from templates
|
|
@@ -326,8 +326,8 @@ Every expansion pack MUST include a custom BMAD orchestrator agent with sophisti
|
|
|
326
326
|
- `utils/template-format.md` - Template markup conventions
|
|
327
327
|
- `utils/workflow-management.md` - Workflow orchestration
|
|
328
328
|
6. **Team and Workflow Requirements**: If pack has >1 agent, MUST include:
|
|
329
|
-
- At least one team configuration in `agent-teams/`
|
|
330
|
-
- At least one workflow in `workflows/`
|
|
329
|
+
- At least one team configuration in `expansion-packs/{new-expansion}/agent-teams/`
|
|
330
|
+
- At least one workflow in `expansion-packs/{new-expansion}workflows/`
|
|
331
331
|
7. **Template Sophistication**: Implement LLM instruction embedding with `[[LLM: guidance]]`, conditional content, and variable systems
|
|
332
332
|
8. **Workflow Orchestration**: Include decision trees, handoff protocols, and validation loops
|
|
333
333
|
9. **Quality Assurance Integration**: Multi-level checklists with star ratings and ready/not-ready frameworks
|
|
@@ -1318,14 +1318,6 @@ Embedded knowledge (automatic):
|
|
|
1318
1318
|
- [ ] Template conditional content tested with different scenarios
|
|
1319
1319
|
- [ ] Workflow decision trees validated with sample use cases
|
|
1320
1320
|
- [ ] Character interactions tested for consistency and professional authenticity
|
|
1321
|
-
|
|
1322
|
-
```
|
|
1323
|
-
|
|
1324
|
-
```
|
|
1325
|
-
|
|
1326
|
-
```
|
|
1327
|
-
|
|
1328
|
-
```
|
|
1329
1321
|
==================== END: tasks#generate-expansion-pack ====================
|
|
1330
1322
|
|
|
1331
1323
|
==================== START: tasks#advanced-elicitation ====================
|