bmad-method 4.13.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.
@@ -0,0 +1,362 @@
1
+ # Working in the Brownfield: A Complete Guide
2
+
3
+ > 🚀 **HIGHLY RECOMMENDED: Use Gemini Web for Brownfield Documentation!**
4
+ >
5
+ > Gemini Web's 1M+ token context window can analyze your ENTIRE codebase at once:
6
+ >
7
+ > - Upload via GitHub URL
8
+ > - Upload up to 1000 files
9
+ > - Upload zipped project
10
+ >
11
+ > This is MUCH more cost-effective than IDE analysis which reads files one by one!
12
+
13
+ ## What is Brownfield Development?
14
+
15
+ 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.
16
+
17
+ ## When to Use BMAD for Brownfield
18
+
19
+ BMAD-METHOD excels at brownfield development when you need to:
20
+
21
+ - Add significant new features to existing applications
22
+ - Modernize legacy codebases
23
+ - Integrate new technologies or services
24
+ - Refactor complex systems
25
+ - Fix bugs that require architectural understanding
26
+ - Document undocumented systems
27
+
28
+ ## The Complete Brownfield Workflow
29
+
30
+ ### Choose Your Approach
31
+
32
+ #### Approach A: PRD-First (Recommended for Large Codebases/Monorepos)
33
+
34
+ **Best for**: Large codebases, monorepos, or when you know exactly what you want to build
35
+
36
+ 1. **Create PRD First** to define requirements
37
+ 2. **Document only relevant areas** based on PRD needs
38
+ 3. **More efficient** - avoids documenting unused code
39
+
40
+ #### Approach B: Document-First (Good for Smaller Projects)
41
+
42
+ **Best for**: Smaller codebases, unknown systems, or exploratory changes
43
+
44
+ 1. **Document entire system** first
45
+ 2. **Create PRD** with full context
46
+ 3. **More thorough** - captures everything
47
+
48
+ ### Approach A: PRD-First Workflow (Recommended)
49
+
50
+ #### Phase 1: Define Requirements First
51
+
52
+ **In Gemini Web (with your codebase uploaded):**
53
+
54
+ ```bash
55
+ @pm
56
+ *create-doc brownfield-prd
57
+ ```
58
+
59
+ The PM will:
60
+
61
+ - **Ask about your enhancement** requirements
62
+ - **Explore the codebase** to understand current state
63
+ - **Identify affected areas** that need documentation
64
+ - **Create focused PRD** with clear scope
65
+
66
+ **Key Advantage**: The PRD identifies which parts of your monorepo/large codebase actually need documentation!
67
+
68
+ #### Phase 2: Focused Documentation
69
+
70
+ **Still in Gemini Web, now with PRD context:**
71
+
72
+ ```bash
73
+ @analyst
74
+ *document-project
75
+ ```
76
+
77
+ The analyst will:
78
+
79
+ - **Ask about your focus** if no PRD was provided
80
+ - **Offer options**: Create PRD, provide requirements, or describe the enhancement
81
+ - **Reference the PRD/description** to understand scope
82
+ - **Focus on relevant modules** identified in PRD or your description
83
+ - **Skip unrelated areas** to keep docs lean
84
+ - **Generate ONE architecture document** for all environments
85
+
86
+ The analyst creates:
87
+
88
+ - **One comprehensive architecture document** following fullstack-architecture template
89
+ - **Covers all system aspects** in a single file
90
+ - **Easy to copy and save** as `docs/project-architecture.md`
91
+ - **Can be sharded later** in IDE if desired
92
+
93
+ For example, if you say "Add payment processing to user service":
94
+
95
+ - Documents only: user service, API endpoints, database schemas, payment integrations
96
+ - Creates focused source tree showing only payment-related code paths
97
+ - Skips: admin panels, reporting modules, unrelated microservices
98
+
99
+ ### Approach B: Document-First Workflow
100
+
101
+ #### Phase 1: Document the Existing System
102
+
103
+ **Best Approach - Gemini Web with 1M+ Context**:
104
+
105
+ 1. **Go to Gemini Web** (gemini.google.com)
106
+ 2. **Upload your project**:
107
+ - **Option A**: Paste your GitHub repository URL directly
108
+ - **Option B**: Upload up to 1000 files from your src/project folder
109
+ - **Option C**: Zip your project and upload the archive
110
+ 3. **Load the analyst agent**: Upload `dist/agents/analyst.txt`
111
+ 4. **Run documentation**: Type `*document-project`
112
+
113
+ The analyst will generate comprehensive documentation of everything.
114
+
115
+ #### Phase 2: Plan Your Enhancement
116
+
117
+ #### Option A: Full Brownfield Workflow (Recommended for Major Changes)
118
+
119
+ **1. Create Brownfield PRD**
120
+
121
+ ```bash
122
+ @pm
123
+ *create-doc brownfield-prd
124
+ ```
125
+
126
+ The PM agent will:
127
+
128
+ - **Analyze existing documentation** from Phase 1
129
+ - **Request specific enhancement details** from you
130
+ - **Assess complexity** and recommend approach
131
+ - **Create epic/story structure** for the enhancement
132
+ - **Identify risks and integration points**
133
+
134
+ **How PM Agent Gets Project Context**:
135
+
136
+ - In Gemini Web: Already has full project context from Phase 1 documentation
137
+ - In IDE: Will ask "Please provide the path to your existing project documentation"
138
+
139
+ **Key Prompts You'll Encounter**:
140
+
141
+ - "What specific enhancement or feature do you want to add?"
142
+ - "Are there any existing systems or APIs this needs to integrate with?"
143
+ - "What are the critical constraints we must respect?"
144
+ - "What is your timeline and team size?"
145
+
146
+ **2. Create Brownfield Architecture**
147
+
148
+ ```bash
149
+ @architect
150
+ *create-doc brownfield-architecture
151
+ ```
152
+
153
+ The architect will:
154
+
155
+ - **Review the brownfield PRD**
156
+ - **Design integration strategy**
157
+ - **Plan migration approach** if needed
158
+ - **Identify technical risks**
159
+ - **Define compatibility requirements**
160
+
161
+ #### Option B: Quick Enhancement (For Focused Changes)
162
+
163
+ **For Single Epic Without Full PRD**:
164
+
165
+ ```bash
166
+ @pm
167
+ *brownfield-create-epic
168
+ ```
169
+
170
+ Use when:
171
+
172
+ - Enhancement is well-defined and isolated
173
+ - Existing documentation is comprehensive
174
+ - Changes don't impact multiple systems
175
+ - You need quick turnaround
176
+
177
+ **For Single Story**:
178
+
179
+ ```bash
180
+ @pm
181
+ *brownfield-create-story
182
+ ```
183
+
184
+ Use when:
185
+
186
+ - Bug fix or tiny feature
187
+ - Very isolated change
188
+ - No architectural impact
189
+ - Clear implementation path
190
+
191
+ ### Phase 3: Validate Planning Artifacts
192
+
193
+ ```bash
194
+ @po
195
+ *execute-checklist po-master-checklist
196
+ ```
197
+
198
+ The PO ensures:
199
+
200
+ - Compatibility with existing system
201
+ - No breaking changes planned
202
+ - Risk mitigation strategies in place
203
+ - Clear integration approach
204
+
205
+ ### Phase 4: Transition to Development
206
+
207
+ Follow the enhanced IDE Development Workflow:
208
+
209
+ 1. **Ensure documents are in project**:
210
+
211
+ - Copy `docs/prd.md` (or brownfield-prd.md)
212
+ - Copy `docs/architecture.md` (or brownfield-architecture.md)
213
+
214
+ 2. **Shard documents**:
215
+
216
+ ```bash
217
+ @po
218
+ # Ask to shard docs/prd.md
219
+ ```
220
+
221
+ 3. **Development cycle**:
222
+ - **SM** creates stories with integration awareness
223
+ - **Dev** implements with existing code respect
224
+ - **QA** reviews for compatibility and improvements
225
+
226
+ ## Brownfield Best Practices
227
+
228
+ ### 1. Always Document First
229
+
230
+ Even if you think you know the codebase:
231
+
232
+ - Run `document-project` to capture current state
233
+ - AI agents need this context
234
+ - Discovers undocumented patterns
235
+
236
+ ### 2. Respect Existing Patterns
237
+
238
+ The brownfield templates specifically look for:
239
+
240
+ - Current coding conventions
241
+ - Existing architectural patterns
242
+ - Technology constraints
243
+ - Team preferences
244
+
245
+ ### 3. Plan for Gradual Rollout
246
+
247
+ Brownfield changes should:
248
+
249
+ - Support feature flags
250
+ - Plan rollback strategies
251
+ - Include migration scripts
252
+ - Maintain backwards compatibility
253
+
254
+ ### 4. Test Integration Thoroughly
255
+
256
+ Focus testing on:
257
+
258
+ - Integration points
259
+ - Existing functionality (regression)
260
+ - Performance impact
261
+ - Data migrations
262
+
263
+ ### 5. Communicate Changes
264
+
265
+ Document:
266
+
267
+ - What changed and why
268
+ - Migration instructions
269
+ - New patterns introduced
270
+ - Deprecation notices
271
+
272
+ ## Common Brownfield Scenarios
273
+
274
+ ### Scenario 1: Adding a New Feature
275
+
276
+ 1. Document existing system
277
+ 2. Create brownfield PRD focusing on integration
278
+ 3. Architecture emphasizes compatibility
279
+ 4. Stories include integration tasks
280
+
281
+ ### Scenario 2: Modernizing Legacy Code
282
+
283
+ 1. Extensive documentation phase
284
+ 2. PRD includes migration strategy
285
+ 3. Architecture plans gradual transition
286
+ 4. Stories follow strangler fig pattern
287
+
288
+ ### Scenario 3: Bug Fix in Complex System
289
+
290
+ 1. Document relevant subsystems
291
+ 2. Use `brownfield-create-story` for focused fix
292
+ 3. Include regression test requirements
293
+ 4. QA validates no side effects
294
+
295
+ ### Scenario 4: API Integration
296
+
297
+ 1. Document existing API patterns
298
+ 2. PRD defines integration requirements
299
+ 3. Architecture ensures consistent patterns
300
+ 4. Stories include API documentation updates
301
+
302
+ ## Troubleshooting
303
+
304
+ ### "The AI doesn't understand my codebase"
305
+
306
+ **Solution**: Re-run `document-project` with more specific paths to critical files
307
+
308
+ ### "Generated plans don't fit our patterns"
309
+
310
+ **Solution**: Update generated documentation with your specific conventions before planning phase
311
+
312
+ ### "Too much boilerplate for small changes"
313
+
314
+ **Solution**: Use `brownfield-create-story` instead of full workflow
315
+
316
+ ### "Integration points unclear"
317
+
318
+ **Solution**: Provide more context during PRD creation, specifically highlighting integration systems
319
+
320
+ ## Quick Reference
321
+
322
+ ### Brownfield-Specific Commands
323
+
324
+ ```bash
325
+ # Document existing project
326
+ @analyst → *document-project
327
+
328
+ # Create enhancement PRD
329
+ @pm → *create-doc brownfield-prd
330
+
331
+ # Create architecture with integration focus
332
+ @architect → *create-doc brownfield-architecture
333
+
334
+ # Quick epic creation
335
+ @pm → *brownfield-create-epic
336
+
337
+ # Single story creation
338
+ @pm → *brownfield-create-story
339
+ ```
340
+
341
+ ### Decision Tree
342
+
343
+ ```text
344
+ Do you have a large codebase or monorepo?
345
+ ├─ Yes → PRD-First Approach
346
+ │ └─ Create PRD → Document only affected areas
347
+ └─ No → Is the codebase well-known to you?
348
+ ├─ Yes → PRD-First Approach
349
+ └─ No → Document-First Approach
350
+
351
+ Is this a major enhancement affecting multiple systems?
352
+ ├─ Yes → Full Brownfield Workflow
353
+ └─ No → Is this more than a simple bug fix?
354
+ ├─ Yes → brownfield-create-epic
355
+ └─ No → brownfield-create-story
356
+ ```
357
+
358
+ ## Conclusion
359
+
360
+ Brownfield development with BMAD-METHOD provides structure and safety when modifying existing systems. The key is providing comprehensive context through documentation, using specialized templates that consider integration requirements, and following workflows that respect existing constraints while enabling progress.
361
+
362
+ Remember: **Document First, Plan Carefully, Integrate Safely**
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "bmad-method",
3
- "version": "4.13.0",
3
+ "version": "4.14.0",
4
4
  "description": "Breakthrough Method of Agile AI-driven Development",
5
5
  "main": "tools/cli.js",
6
6
  "bin": {
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "bmad-method",
3
- "version": "4.13.0",
3
+ "version": "4.14.0",
4
4
  "description": "BMAD Method installer - AI-powered Agile development framework",
5
5
  "main": "lib/installer.js",
6
6
  "bin": {