bmad-method 4.36.2 → 4.37.0-beta.2
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/.github/workflows/release.yaml +1 -0
- package/.releaserc.json +11 -8
- package/bmad-core/agents/analyst.md +1 -1
- package/bmad-core/agents/architect.md +3 -2
- package/bmad-core/agents/bmad-master.md +1 -0
- package/bmad-core/agents/bmad-orchestrator.md +10 -9
- package/bmad-core/agents/dev.md +10 -9
- package/bmad-core/agents/po.md +1 -1
- package/bmad-core/agents/qa.md +1 -1
- package/bmad-core/agents/sm.md +1 -1
- package/bmad-core/agents/ux-expert.md +1 -1
- package/bmad-core/checklists/architect-checklist.md +5 -0
- package/bmad-core/checklists/pm-checklist.md +5 -0
- package/bmad-core/checklists/po-master-checklist.md +9 -0
- package/bmad-core/checklists/story-dod-checklist.md +7 -0
- package/bmad-core/checklists/story-draft-checklist.md +3 -0
- package/bmad-core/data/bmad-kb.md +2 -5
- package/bmad-core/data/elicitation-methods.md +0 -20
- package/bmad-core/tasks/create-brownfield-story.md +3 -11
- package/bmad-core/tasks/create-deep-research-prompt.md +11 -0
- package/bmad-core/tasks/document-project.md +13 -15
- package/bmad-core/tasks/facilitate-brainstorming-session.md +1 -1
- package/bmad-core/tasks/index-docs.md +6 -0
- package/bmad-core/tasks/kb-mode-interaction.md +3 -3
- package/bmad-core/tasks/review-story.md +1 -10
- package/bmad-core/tasks/shard-doc.md +2 -0
- package/common/tasks/execute-checklist.md +7 -0
- package/docs/GUIDING-PRINCIPLES.md +1 -1
- package/docs/working-in-the-brownfield.md +1 -1
- package/expansion-packs/Complete AI Agent System - Blank Templates & Google Cloud Setup/README.md +14 -14
- package/expansion-packs/bmad-2d-phaser-game-dev/data/bmad-kb.md +4 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/data/development-guidelines.md +5 -3
- package/expansion-packs/bmad-2d-phaser-game-dev/tasks/advanced-elicitation.md +1 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/tasks/game-design-brainstorming.md +18 -0
- package/expansion-packs/bmad-2d-unity-game-dev/checklists/game-architect-checklist.md +5 -0
- package/expansion-packs/bmad-2d-unity-game-dev/checklists/game-story-dod-checklist.md +8 -0
- package/expansion-packs/bmad-2d-unity-game-dev/data/bmad-kb.md +7 -0
- package/expansion-packs/bmad-2d-unity-game-dev/data/development-guidelines.md +4 -0
- package/expansion-packs/bmad-2d-unity-game-dev/tasks/advanced-elicitation.md +1 -0
- package/expansion-packs/bmad-2d-unity-game-dev/tasks/correct-course-game.md +10 -0
- package/expansion-packs/bmad-2d-unity-game-dev/tasks/game-design-brainstorming.md +18 -0
- package/expansion-packs/bmad-infrastructure-devops/data/bmad-kb.md +3 -0
- package/expansion-packs/bmad-infrastructure-devops/tasks/review-infrastructure.md +1 -0
- package/expansion-packs/bmad-infrastructure-devops/tasks/validate-infrastructure.md +1 -0
- package/package.json +1 -1
- package/tools/installer/bin/bmad.js +58 -0
- package/tools/installer/config/install.config.yaml +1 -1
- package/tools/installer/lib/ide-setup.js +1 -1
- package/tools/installer/package.json +3 -2
- package/tools/upgraders/v3-to-v4-upgrader.js +1 -1
- package/bmad-core/bmad-core/user-guide.md +0 -0
|
@@ -128,7 +128,7 @@ Critical: For brownfield, ALWAYS include criteria about maintaining existing fun
|
|
|
128
128
|
Standard structure:
|
|
129
129
|
|
|
130
130
|
1. New functionality works as specified
|
|
131
|
-
2. Existing {{affected feature}} continues to work unchanged
|
|
131
|
+
2. Existing {{affected feature}} continues to work unchanged
|
|
132
132
|
3. Integration with {{existing system}} maintains current behavior
|
|
133
133
|
4. No regression in {{related area}}
|
|
134
134
|
5. Performance remains within acceptable bounds
|
|
@@ -139,19 +139,16 @@ Critical: This is where you'll need to be interactive with the user if informati
|
|
|
139
139
|
|
|
140
140
|
Create Dev Technical Guidance section with available information:
|
|
141
141
|
|
|
142
|
-
|
|
142
|
+
```markdown
|
|
143
143
|
## Dev Technical Guidance
|
|
144
144
|
|
|
145
145
|
### Existing System Context
|
|
146
|
-
|
|
147
146
|
[Extract from available documentation]
|
|
148
147
|
|
|
149
148
|
### Integration Approach
|
|
150
|
-
|
|
151
149
|
[Based on patterns found or ask user]
|
|
152
150
|
|
|
153
151
|
### Technical Constraints
|
|
154
|
-
|
|
155
152
|
[From documentation or user input]
|
|
156
153
|
|
|
157
154
|
### Missing Information
|
|
@@ -194,7 +191,6 @@ Example task structure for brownfield:
|
|
|
194
191
|
- [ ] Integration test for {{integration point}}
|
|
195
192
|
- [ ] Update existing tests if needed
|
|
196
193
|
```
|
|
197
|
-
````
|
|
198
194
|
|
|
199
195
|
### 5. Risk Assessment and Mitigation
|
|
200
196
|
|
|
@@ -206,17 +202,14 @@ Add section for brownfield-specific risks:
|
|
|
206
202
|
## Risk Assessment
|
|
207
203
|
|
|
208
204
|
### Implementation Risks
|
|
209
|
-
|
|
210
205
|
- **Primary Risk**: {{main risk to existing system}}
|
|
211
206
|
- **Mitigation**: {{how to address}}
|
|
212
207
|
- **Verification**: {{how to confirm safety}}
|
|
213
208
|
|
|
214
209
|
### Rollback Plan
|
|
215
|
-
|
|
216
210
|
- {{Simple steps to undo changes if needed}}
|
|
217
211
|
|
|
218
212
|
### Safety Checks
|
|
219
|
-
|
|
220
213
|
- [ ] Existing {{feature}} tested before changes
|
|
221
214
|
- [ ] Changes can be feature-flagged or isolated
|
|
222
215
|
- [ ] Rollback procedure documented
|
|
@@ -259,7 +252,6 @@ Include header noting documentation context:
|
|
|
259
252
|
<!-- Context: Brownfield enhancement to {{existing system}} -->
|
|
260
253
|
|
|
261
254
|
## Status: Draft
|
|
262
|
-
|
|
263
255
|
[Rest of story content...]
|
|
264
256
|
```
|
|
265
257
|
|
|
@@ -280,7 +272,7 @@ Key Integration Points Identified:
|
|
|
280
272
|
Risks Noted:
|
|
281
273
|
- {{primary risk}}
|
|
282
274
|
|
|
283
|
-
{{If missing info}}:
|
|
275
|
+
{{If missing info}}:
|
|
284
276
|
Note: Some technical details were unclear. The story includes exploration tasks to gather needed information during implementation.
|
|
285
277
|
|
|
286
278
|
Next Steps:
|
|
@@ -21,54 +21,63 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
|
|
21
21
|
Present these numbered options to the user:
|
|
22
22
|
|
|
23
23
|
1. **Product Validation Research**
|
|
24
|
+
|
|
24
25
|
- Validate product hypotheses and market fit
|
|
25
26
|
- Test assumptions about user needs and solutions
|
|
26
27
|
- Assess technical and business feasibility
|
|
27
28
|
- Identify risks and mitigation strategies
|
|
28
29
|
|
|
29
30
|
2. **Market Opportunity Research**
|
|
31
|
+
|
|
30
32
|
- Analyze market size and growth potential
|
|
31
33
|
- Identify market segments and dynamics
|
|
32
34
|
- Assess market entry strategies
|
|
33
35
|
- Evaluate timing and market readiness
|
|
34
36
|
|
|
35
37
|
3. **User & Customer Research**
|
|
38
|
+
|
|
36
39
|
- Deep dive into user personas and behaviors
|
|
37
40
|
- Understand jobs-to-be-done and pain points
|
|
38
41
|
- Map customer journeys and touchpoints
|
|
39
42
|
- Analyze willingness to pay and value perception
|
|
40
43
|
|
|
41
44
|
4. **Competitive Intelligence Research**
|
|
45
|
+
|
|
42
46
|
- Detailed competitor analysis and positioning
|
|
43
47
|
- Feature and capability comparisons
|
|
44
48
|
- Business model and strategy analysis
|
|
45
49
|
- Identify competitive advantages and gaps
|
|
46
50
|
|
|
47
51
|
5. **Technology & Innovation Research**
|
|
52
|
+
|
|
48
53
|
- Assess technology trends and possibilities
|
|
49
54
|
- Evaluate technical approaches and architectures
|
|
50
55
|
- Identify emerging technologies and disruptions
|
|
51
56
|
- Analyze build vs. buy vs. partner options
|
|
52
57
|
|
|
53
58
|
6. **Industry & Ecosystem Research**
|
|
59
|
+
|
|
54
60
|
- Map industry value chains and dynamics
|
|
55
61
|
- Identify key players and relationships
|
|
56
62
|
- Analyze regulatory and compliance factors
|
|
57
63
|
- Understand partnership opportunities
|
|
58
64
|
|
|
59
65
|
7. **Strategic Options Research**
|
|
66
|
+
|
|
60
67
|
- Evaluate different strategic directions
|
|
61
68
|
- Assess business model alternatives
|
|
62
69
|
- Analyze go-to-market strategies
|
|
63
70
|
- Consider expansion and scaling paths
|
|
64
71
|
|
|
65
72
|
8. **Risk & Feasibility Research**
|
|
73
|
+
|
|
66
74
|
- Identify and assess various risk factors
|
|
67
75
|
- Evaluate implementation challenges
|
|
68
76
|
- Analyze resource requirements
|
|
69
77
|
- Consider regulatory and legal implications
|
|
70
78
|
|
|
71
79
|
9. **Custom Research Focus**
|
|
80
|
+
|
|
72
81
|
- User-defined research objectives
|
|
73
82
|
- Specialized domain investigation
|
|
74
83
|
- Cross-functional research needs
|
|
@@ -237,11 +246,13 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
|
|
237
246
|
### 5. Review and Refinement
|
|
238
247
|
|
|
239
248
|
1. **Present Complete Prompt**
|
|
249
|
+
|
|
240
250
|
- Show the full research prompt
|
|
241
251
|
- Explain key elements and rationale
|
|
242
252
|
- Highlight any assumptions made
|
|
243
253
|
|
|
244
254
|
2. **Gather Feedback**
|
|
255
|
+
|
|
245
256
|
- Are the objectives clear and correct?
|
|
246
257
|
- Do the questions address all concerns?
|
|
247
258
|
- Is the scope appropriate?
|
|
@@ -111,9 +111,9 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
|
|
111
111
|
|
|
112
112
|
### Change Log
|
|
113
113
|
|
|
114
|
-
| Date
|
|
115
|
-
|
|
116
|
-
| [Date] | 1.0
|
|
114
|
+
| Date | Version | Description | Author |
|
|
115
|
+
|------|---------|-------------|--------|
|
|
116
|
+
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
|
117
117
|
|
|
118
118
|
## Quick Reference - Key Files and Entry Points
|
|
119
119
|
|
|
@@ -136,11 +136,11 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
|
|
136
136
|
|
|
137
137
|
### Actual Tech Stack (from package.json/requirements.txt)
|
|
138
138
|
|
|
139
|
-
| Category
|
|
140
|
-
|
|
141
|
-
| Runtime
|
|
142
|
-
| Framework | Express
|
|
143
|
-
| Database
|
|
139
|
+
| Category | Technology | Version | Notes |
|
|
140
|
+
|----------|------------|---------|--------|
|
|
141
|
+
| Runtime | Node.js | 16.x | [Any constraints] |
|
|
142
|
+
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
|
143
|
+
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
|
144
144
|
|
|
145
145
|
etc...
|
|
146
146
|
|
|
@@ -179,7 +179,6 @@ project-root/
|
|
|
179
179
|
### Data Models
|
|
180
180
|
|
|
181
181
|
Instead of duplicating, reference actual model files:
|
|
182
|
-
|
|
183
182
|
- **User Model**: See `src/models/User.js`
|
|
184
183
|
- **Order Model**: See `src/models/Order.js`
|
|
185
184
|
- **Related Types**: TypeScript definitions in `src/types/`
|
|
@@ -209,10 +208,10 @@ Instead of duplicating, reference actual model files:
|
|
|
209
208
|
|
|
210
209
|
### External Services
|
|
211
210
|
|
|
212
|
-
| Service
|
|
213
|
-
|
|
214
|
-
| Stripe
|
|
215
|
-
| SendGrid | Emails
|
|
211
|
+
| Service | Purpose | Integration Type | Key Files |
|
|
212
|
+
|---------|---------|------------------|-----------|
|
|
213
|
+
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
|
214
|
+
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
|
216
215
|
|
|
217
216
|
etc...
|
|
218
217
|
|
|
@@ -257,7 +256,6 @@ npm run test:integration # Runs integration tests (requires local DB)
|
|
|
257
256
|
### Files That Will Need Modification
|
|
258
257
|
|
|
259
258
|
Based on the enhancement requirements, these files will be affected:
|
|
260
|
-
|
|
261
259
|
- `src/services/userService.js` - Add new user fields
|
|
262
260
|
- `src/models/User.js` - Update schema
|
|
263
261
|
- `src/routes/userRoutes.js` - New endpoints
|
|
@@ -340,4 +338,4 @@ Apply the advanced elicitation task after major sections to refine based on user
|
|
|
340
338
|
- References actual files rather than duplicating content when possible
|
|
341
339
|
- Documents technical debt, workarounds, and constraints honestly
|
|
342
340
|
- For brownfield projects with PRD: Provides clear enhancement impact analysis
|
|
343
|
-
- The goal is PRACTICAL documentation for AI agents doing real work
|
|
341
|
+
- The goal is PRACTICAL documentation for AI agents doing real work
|
|
@@ -43,7 +43,7 @@ If user selects Option 1, present numbered list of techniques from the brainstor
|
|
|
43
43
|
1. Apply selected technique according to data file description
|
|
44
44
|
2. Keep engaging with technique until user indicates they want to:
|
|
45
45
|
- Choose a different technique
|
|
46
|
-
- Apply current ideas to a new technique
|
|
46
|
+
- Apply current ideas to a new technique
|
|
47
47
|
- Move to convergent phase
|
|
48
48
|
- End session
|
|
49
49
|
|
|
@@ -11,12 +11,14 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
|
|
11
11
|
### Required Steps
|
|
12
12
|
|
|
13
13
|
1. First, locate and scan:
|
|
14
|
+
|
|
14
15
|
- The `docs/` directory and all subdirectories
|
|
15
16
|
- The existing `docs/index.md` file (create if absent)
|
|
16
17
|
- All markdown (`.md`) and text (`.txt`) files in the documentation structure
|
|
17
18
|
- Note the folder structure for hierarchical organization
|
|
18
19
|
|
|
19
20
|
2. For the existing `docs/index.md`:
|
|
21
|
+
|
|
20
22
|
- Parse current entries
|
|
21
23
|
- Note existing file references and descriptions
|
|
22
24
|
- Identify any broken links or missing files
|
|
@@ -24,6 +26,7 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
|
|
24
26
|
- Preserve existing folder sections
|
|
25
27
|
|
|
26
28
|
3. For each documentation file found:
|
|
29
|
+
|
|
27
30
|
- Extract the title (from first heading or filename)
|
|
28
31
|
- Generate a brief description by analyzing the content
|
|
29
32
|
- Create a relative markdown link to the file
|
|
@@ -32,6 +35,7 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
|
|
32
35
|
- If missing or outdated, prepare an update
|
|
33
36
|
|
|
34
37
|
4. For any missing or non-existent files found in index:
|
|
38
|
+
|
|
35
39
|
- Present a list of all entries that reference non-existent files
|
|
36
40
|
- For each entry:
|
|
37
41
|
- Show the full entry details (title, path, description)
|
|
@@ -84,6 +88,7 @@ Documents within the `another-folder/` directory:
|
|
|
84
88
|
### [Nested Document](./another-folder/document.md)
|
|
85
89
|
|
|
86
90
|
Description of nested document.
|
|
91
|
+
|
|
87
92
|
```
|
|
88
93
|
|
|
89
94
|
### Index Entry Format
|
|
@@ -152,6 +157,7 @@ For each file referenced in the index but not found in the filesystem:
|
|
|
152
157
|
### Special Cases
|
|
153
158
|
|
|
154
159
|
1. **Sharded Documents**: If a folder contains an `index.md` file, treat it as a sharded document:
|
|
160
|
+
|
|
155
161
|
- Use the folder's `index.md` title as the section title
|
|
156
162
|
- List the folder's documents as subsections
|
|
157
163
|
- Note in the description that this is a multi-part document
|
|
@@ -6,7 +6,7 @@ Provide a user-friendly interface to the BMad knowledge base without overwhelmin
|
|
|
6
6
|
|
|
7
7
|
## Instructions
|
|
8
8
|
|
|
9
|
-
When entering KB mode (
|
|
9
|
+
When entering KB mode (*kb-mode), follow these steps:
|
|
10
10
|
|
|
11
11
|
### 1. Welcome and Guide
|
|
12
12
|
|
|
@@ -48,12 +48,12 @@ Or ask me about anything else related to BMad-Method!
|
|
|
48
48
|
When user is done or wants to exit KB mode:
|
|
49
49
|
|
|
50
50
|
- Summarize key points discussed if helpful
|
|
51
|
-
- Remind them they can return to KB mode anytime with
|
|
51
|
+
- Remind them they can return to KB mode anytime with *kb-mode
|
|
52
52
|
- Suggest next steps based on what was discussed
|
|
53
53
|
|
|
54
54
|
## Example Interaction
|
|
55
55
|
|
|
56
|
-
**User**:
|
|
56
|
+
**User**: *kb-mode
|
|
57
57
|
|
|
58
58
|
**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.
|
|
59
59
|
|
|
@@ -81,31 +81,25 @@ After review and any refactoring, append your results to the story file in the Q
|
|
|
81
81
|
## QA Results
|
|
82
82
|
|
|
83
83
|
### Review Date: [Date]
|
|
84
|
-
|
|
85
84
|
### Reviewed By: Quinn (Senior Developer QA)
|
|
86
85
|
|
|
87
86
|
### Code Quality Assessment
|
|
88
|
-
|
|
89
87
|
[Overall assessment of implementation quality]
|
|
90
88
|
|
|
91
89
|
### Refactoring Performed
|
|
92
|
-
|
|
93
90
|
[List any refactoring you performed with explanations]
|
|
94
|
-
|
|
95
91
|
- **File**: [filename]
|
|
96
92
|
- **Change**: [what was changed]
|
|
97
93
|
- **Why**: [reason for change]
|
|
98
94
|
- **How**: [how it improves the code]
|
|
99
95
|
|
|
100
96
|
### Compliance Check
|
|
101
|
-
|
|
102
97
|
- Coding Standards: [✓/✗] [notes if any]
|
|
103
98
|
- Project Structure: [✓/✗] [notes if any]
|
|
104
99
|
- Testing Strategy: [✓/✗] [notes if any]
|
|
105
100
|
- All ACs Met: [✓/✗] [notes if any]
|
|
106
101
|
|
|
107
102
|
### Improvements Checklist
|
|
108
|
-
|
|
109
103
|
[Check off items you handled yourself, leave unchecked for dev to address]
|
|
110
104
|
|
|
111
105
|
- [x] Refactored user service for better error handling (services/user.service.ts)
|
|
@@ -115,15 +109,12 @@ After review and any refactoring, append your results to the story file in the Q
|
|
|
115
109
|
- [ ] Update API documentation for new error codes
|
|
116
110
|
|
|
117
111
|
### Security Review
|
|
118
|
-
|
|
119
112
|
[Any security concerns found and whether addressed]
|
|
120
113
|
|
|
121
114
|
### Performance Considerations
|
|
122
|
-
|
|
123
115
|
[Any performance issues found and whether addressed]
|
|
124
116
|
|
|
125
117
|
### Final Status
|
|
126
|
-
|
|
127
118
|
[✓ Approved - Ready for Done] / [✗ Changes Required - See unchecked items above]
|
|
128
119
|
```
|
|
129
120
|
|
|
@@ -151,4 +142,4 @@ After review:
|
|
|
151
142
|
|
|
152
143
|
1. If all items are checked and approved: Update story status to "Done"
|
|
153
144
|
2. If unchecked items remain: Keep status as "Review" for dev to address
|
|
154
|
-
3. Always provide constructive feedback and explanations for learning
|
|
145
|
+
3. Always provide constructive feedback and explanations for learning
|
|
@@ -91,11 +91,13 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
|
|
|
91
91
|
For each extracted section:
|
|
92
92
|
|
|
93
93
|
1. **Generate filename**: Convert the section heading to lowercase-dash-case
|
|
94
|
+
|
|
94
95
|
- Remove special characters
|
|
95
96
|
- Replace spaces with dashes
|
|
96
97
|
- Example: "## Tech Stack" → `tech-stack.md`
|
|
97
98
|
|
|
98
99
|
2. **Adjust heading levels**:
|
|
100
|
+
|
|
99
101
|
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
|
|
100
102
|
- All subsection levels decrease by 1:
|
|
101
103
|
|
|
@@ -9,6 +9,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
|
|
9
9
|
## Instructions
|
|
10
10
|
|
|
11
11
|
1. **Initial Assessment**
|
|
12
|
+
|
|
12
13
|
- If user or the task being run provides a checklist name:
|
|
13
14
|
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
|
14
15
|
- If multiple matches found, ask user to clarify
|
|
@@ -21,12 +22,14 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
|
|
21
22
|
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
|
22
23
|
|
|
23
24
|
2. **Document and Artifact Gathering**
|
|
25
|
+
|
|
24
26
|
- Each checklist will specify its required documents/artifacts at the beginning
|
|
25
27
|
- 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.
|
|
26
28
|
|
|
27
29
|
3. **Checklist Processing**
|
|
28
30
|
|
|
29
31
|
If in interactive mode:
|
|
32
|
+
|
|
30
33
|
- Work through each section of the checklist one at a time
|
|
31
34
|
- For each section:
|
|
32
35
|
- Review all items in the section following instructions for that section embedded in the checklist
|
|
@@ -35,6 +38,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
|
|
35
38
|
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
|
36
39
|
|
|
37
40
|
If in YOLO mode:
|
|
41
|
+
|
|
38
42
|
- Process all sections at once
|
|
39
43
|
- Create a comprehensive report of all findings
|
|
40
44
|
- Present the complete analysis to the user
|
|
@@ -42,6 +46,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
|
|
42
46
|
4. **Validation Approach**
|
|
43
47
|
|
|
44
48
|
For each checklist item:
|
|
49
|
+
|
|
45
50
|
- Read and understand the requirement
|
|
46
51
|
- Look for evidence in the documentation that satisfies the requirement
|
|
47
52
|
- Consider both explicit mentions and implicit coverage
|
|
@@ -55,6 +60,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
|
|
55
60
|
5. **Section Analysis**
|
|
56
61
|
|
|
57
62
|
For each section:
|
|
63
|
+
|
|
58
64
|
- think step by step to calculate pass rate
|
|
59
65
|
- Identify common themes in failed items
|
|
60
66
|
- Provide specific recommendations for improvement
|
|
@@ -64,6 +70,7 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
|
|
64
70
|
6. **Final Report**
|
|
65
71
|
|
|
66
72
|
Prepare a summary that includes:
|
|
73
|
+
|
|
67
74
|
- Overall checklist completion status
|
|
68
75
|
- Pass rates by section
|
|
69
76
|
- List of failed items with context
|
|
@@ -65,7 +65,7 @@ See [Expansion Packs Guide](../docs/expansion-packs.md) for detailed examples an
|
|
|
65
65
|
|
|
66
66
|
### Template Rules
|
|
67
67
|
|
|
68
|
-
Templates follow the [BMad Document Template](common/utils/bmad-doc-template.md) specification using YAML format:
|
|
68
|
+
Templates follow the [BMad Document Template](../common/utils/bmad-doc-template.md) specification using YAML format:
|
|
69
69
|
|
|
70
70
|
1. **Structure**: Templates are defined in YAML with clear metadata, workflow configuration, and section hierarchy
|
|
71
71
|
2. **Separation of Concerns**: Instructions for LLMs are in `instruction` fields, separate from content
|
|
@@ -27,7 +27,7 @@ If you have just completed an MVP with BMad, and you want to continue with post-
|
|
|
27
27
|
## The Complete Brownfield Workflow
|
|
28
28
|
|
|
29
29
|
1. **Follow the [<ins>User Guide - Installation</ins>](user-guide.md#installation) steps to setup your agent in the web.**
|
|
30
|
-
2. **Generate a 'flattened' single file of your entire codebase** run:
|
|
30
|
+
2. **Generate a 'flattened' single file of your entire codebase** run: ```npx bmad-method flatten```
|
|
31
31
|
|
|
32
32
|
### Choose Your Approach
|
|
33
33
|
|
package/expansion-packs/Complete AI Agent System - Blank Templates & Google Cloud Setup/README.md
CHANGED
|
@@ -8,21 +8,21 @@ This expansion pack provides a complete, deployable starter kit for building and
|
|
|
8
8
|
|
|
9
9
|
## Features
|
|
10
10
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
11
|
+
* **Automated GCP Setup**: `gcloud` scripts to configure your project, service accounts, and required APIs in minutes.
|
|
12
|
+
* **Production-Ready Deployment**: Includes a `Dockerfile` and `cloudbuild.yaml` for easy, repeatable deployments to Google Cloud Run.
|
|
13
|
+
* **Rich Template Library**: A comprehensive set of BMad-compatible templates for Teams, Agents, Tasks, Workflows, Documents, and Checklists.
|
|
14
|
+
* **Pre-configured Agent Roles**: Includes powerful master templates for key agent archetypes like Orchestrators and Specialists.
|
|
15
|
+
* **Highly Customizable**: Easily adapt the entire system with company-specific variables and industry-specific configurations.
|
|
16
|
+
* **Powered by Google ADK**: Built on the official Google Agent Development Kit for robust and native integration with Vertex AI services.
|
|
17
17
|
|
|
18
18
|
## Prerequisites
|
|
19
19
|
|
|
20
20
|
Before you begin, ensure you have the following installed and configured:
|
|
21
21
|
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
22
|
+
* A Google Cloud Platform (GCP) Account with an active billing account.
|
|
23
|
+
* The [Google Cloud SDK (`gcloud` CLI)](https://www.google.com/search?q=%5Bhttps://cloud.google.com/sdk/docs/install%5D\(https://cloud.google.com/sdk/docs/install\)) installed and authenticated.
|
|
24
|
+
* [Docker](https://www.docker.com/products/docker-desktop/) installed on your local machine.
|
|
25
|
+
* Python 3.11+
|
|
26
26
|
|
|
27
27
|
## Quick Start Guide
|
|
28
28
|
|
|
@@ -32,9 +32,9 @@ Follow these steps to get your own AI agent system running on Google Cloud.
|
|
|
32
32
|
|
|
33
33
|
The setup scripts use placeholder variables. Before running them, open the files in the `/scripts` directory and replace the following placeholders with your own values:
|
|
34
34
|
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
35
|
+
* `{{PROJECT_ID}}`: Your unique Google Cloud project ID.
|
|
36
|
+
* `{{COMPANY_NAME}}`: Your company or project name (used for naming resources).
|
|
37
|
+
* `{{LOCATION}}`: The GCP region you want to deploy to (e.g., `us-central1`).
|
|
38
38
|
|
|
39
39
|
### 2\. Run the GCP Setup Scripts
|
|
40
40
|
|
|
@@ -106,4 +106,4 @@ This expansion pack has a comprehensive structure to get you started:
|
|
|
106
106
|
|
|
107
107
|
## Contributing
|
|
108
108
|
|
|
109
|
-
Contributions are welcome\! Please follow the main project's `CONTRIBUTING.md` guidelines. For major changes or new features for this expansion pack, please open an issue or discussion first.
|
|
109
|
+
Contributions are welcome\! Please follow the main project's `CONTRIBUTING.md` guidelines. For major changes or new features for this expansion pack, please open an issue or discussion first.
|
|
@@ -39,11 +39,13 @@ You are developing games as a "Player Experience CEO" - thinking like a game dir
|
|
|
39
39
|
### Phase 1: Game Concept and Design
|
|
40
40
|
|
|
41
41
|
1. **Game Designer**: Start with brainstorming and concept development
|
|
42
|
+
|
|
42
43
|
- Use \*brainstorm to explore game concepts and mechanics
|
|
43
44
|
- Create Game Brief using game-brief-tmpl
|
|
44
45
|
- Develop core game pillars and player experience goals
|
|
45
46
|
|
|
46
47
|
2. **Game Designer**: Create comprehensive Game Design Document
|
|
48
|
+
|
|
47
49
|
- Use game-design-doc-tmpl to create detailed GDD
|
|
48
50
|
- Define all game mechanics, progression, and balance
|
|
49
51
|
- Specify technical requirements and platform targets
|
|
@@ -63,11 +65,13 @@ You are developing games as a "Player Experience CEO" - thinking like a game dir
|
|
|
63
65
|
### Phase 3: Story-Driven Development
|
|
64
66
|
|
|
65
67
|
5. **Game Scrum Master**: Break down design into development stories
|
|
68
|
+
|
|
66
69
|
- Use create-game-story task to create detailed implementation stories
|
|
67
70
|
- Each story should be immediately actionable by game developers
|
|
68
71
|
- Apply game-story-dod-checklist to ensure story quality
|
|
69
72
|
|
|
70
73
|
6. **Game Developer**: Implement game features story by story
|
|
74
|
+
|
|
71
75
|
- Follow TypeScript strict mode and Phaser 3 best practices
|
|
72
76
|
- Maintain 60 FPS performance target throughout development
|
|
73
77
|
- Use test-driven development for game logic components
|
|
@@ -380,9 +380,7 @@ class InputManager {
|
|
|
380
380
|
}
|
|
381
381
|
|
|
382
382
|
private setupKeyboard(): void {
|
|
383
|
-
this.keys = this.scene.input.keyboard.addKeys(
|
|
384
|
-
"W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT",
|
|
385
|
-
);
|
|
383
|
+
this.keys = this.scene.input.keyboard.addKeys("W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT");
|
|
386
384
|
}
|
|
387
385
|
|
|
388
386
|
private setupTouch(): void {
|
|
@@ -587,21 +585,25 @@ src/
|
|
|
587
585
|
### Story Implementation Process
|
|
588
586
|
|
|
589
587
|
1. **Read Story Requirements:**
|
|
588
|
+
|
|
590
589
|
- Understand acceptance criteria
|
|
591
590
|
- Identify technical requirements
|
|
592
591
|
- Review performance constraints
|
|
593
592
|
|
|
594
593
|
2. **Plan Implementation:**
|
|
594
|
+
|
|
595
595
|
- Identify files to create/modify
|
|
596
596
|
- Consider component architecture
|
|
597
597
|
- Plan testing approach
|
|
598
598
|
|
|
599
599
|
3. **Implement Feature:**
|
|
600
|
+
|
|
600
601
|
- Follow TypeScript strict mode
|
|
601
602
|
- Use established patterns
|
|
602
603
|
- Maintain 60 FPS performance
|
|
603
604
|
|
|
604
605
|
4. **Test Implementation:**
|
|
606
|
+
|
|
605
607
|
- Write unit tests for game logic
|
|
606
608
|
- Test cross-platform functionality
|
|
607
609
|
- Validate performance targets
|
|
@@ -18,6 +18,7 @@
|
|
|
18
18
|
2. If the section contains game flow diagrams, level layouts, or system diagrams, explain each diagram briefly with game development context before offering elicitation options (e.g., "The gameplay loop diagram shows how player actions lead to rewards and progression. Notice how each step maintains player engagement and creates opportunities for skill development.")
|
|
19
19
|
|
|
20
20
|
3. If the section contains multiple game elements (like multiple mechanics, multiple levels, multiple systems, etc.), inform the user they can apply elicitation actions to:
|
|
21
|
+
|
|
21
22
|
- The entire section as a whole
|
|
22
23
|
- Individual game elements within the section (specify which element when selecting an action)
|
|
23
24
|
|