bmad-method 4.2.0 → 4.4.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.
Files changed (90) hide show
  1. package/.bmad-core/agents/analyst.md +14 -20
  2. package/.bmad-core/agents/architect.md +15 -20
  3. package/.bmad-core/agents/bmad-master.md +18 -26
  4. package/.bmad-core/agents/bmad-orchestrator.md +16 -28
  5. package/.bmad-core/agents/dev.md +5 -4
  6. package/.bmad-core/agents/pm.md +11 -16
  7. package/.bmad-core/agents/sm.md +20 -25
  8. package/.bmad-core/bmad-core-config.yml +60 -0
  9. package/.bmad-core/data/bmad-kb.md +12 -1
  10. package/.bmad-core/tasks/doc-migration-task.md +91 -146
  11. package/.bmad-core/tasks/document-project.md +389 -0
  12. package/.bmad-core/tasks/generate-ai-frontend-prompt.md +41 -48
  13. package/.bmad-core/tasks/index-docs.md +8 -3
  14. package/.bmad-core/templates/architecture-tmpl.md +15 -12
  15. package/.bmad-core/templates/fullstack-architecture-tmpl.md +85 -103
  16. package/.bmad-core/templates/prd-tmpl.md +1 -1
  17. package/.bmad-core/templates/simple-project-prd-tmpl.md +461 -0
  18. package/.bmad-core/templates/story-tmpl.md +2 -2
  19. package/.bmad-core/utils/workflow-management.md +14 -15
  20. package/.bmad-core/web-bundles/agents/analyst.txt +26 -21
  21. package/.bmad-core/web-bundles/agents/architect.txt +605 -233
  22. package/.bmad-core/web-bundles/agents/bmad-master.txt +457 -1039
  23. package/.bmad-core/web-bundles/agents/bmad-orchestrator.txt +36 -903
  24. package/.bmad-core/web-bundles/agents/dev.txt +5 -4
  25. package/.bmad-core/web-bundles/agents/pm.txt +476 -17
  26. package/.bmad-core/web-bundles/agents/po.txt +2 -2
  27. package/.bmad-core/web-bundles/agents/sm.txt +22 -27
  28. package/.bmad-core/web-bundles/agents/ux-expert.txt +41 -48
  29. package/.bmad-core/web-bundles/teams/team-all.txt +4394 -4447
  30. package/.bmad-core/web-bundles/teams/team-fullstack.txt +2760 -2809
  31. package/.bmad-core/web-bundles/teams/team-no-ui.txt +2718 -2760
  32. package/.bmad-core/workflows/greenfield-fullstack.yml +3 -3
  33. package/.claude/commands/analyst.md +14 -20
  34. package/.claude/commands/architect.md +15 -20
  35. package/.claude/commands/bmad-master.md +18 -26
  36. package/.claude/commands/bmad-orchestrator.md +16 -28
  37. package/.claude/commands/dev.md +5 -4
  38. package/.claude/commands/pm.md +11 -16
  39. package/.claude/commands/sm.md +20 -25
  40. package/.cursor/rules/analyst.mdc +13 -19
  41. package/.cursor/rules/architect.mdc +14 -19
  42. package/.cursor/rules/bmad-master.mdc +18 -26
  43. package/.cursor/rules/bmad-orchestrator.mdc +15 -27
  44. package/.cursor/rules/dev.mdc +5 -4
  45. package/.cursor/rules/pm.mdc +11 -16
  46. package/.cursor/rules/sm.mdc +19 -24
  47. package/.releaserc.json +2 -1
  48. package/.vscode/settings.json +4 -0
  49. package/.windsurf/rules/analyst.md +13 -19
  50. package/.windsurf/rules/architect.md +14 -19
  51. package/.windsurf/rules/bmad-master.md +18 -26
  52. package/.windsurf/rules/bmad-orchestrator.md +15 -27
  53. package/.windsurf/rules/dev.md +5 -4
  54. package/.windsurf/rules/pm.md +11 -16
  55. package/.windsurf/rules/sm.md +19 -24
  56. package/CHANGELOG.md +120 -2
  57. package/CONTRIBUTING.md +2 -0
  58. package/README.md +20 -2
  59. package/{.bmad-core → creator-tools}/tasks/create-agent.md +10 -12
  60. package/{.bmad-core/tasks/create-expansion-pack.md → creator-tools/tasks/generate-expansion-pack.md} +8 -6
  61. package/docs/bmad-workflow-guide.md +161 -0
  62. package/docs/claude-code-guide.md +119 -0
  63. package/docs/core-architecture.md +213 -0
  64. package/docs/cursor-guide.md +127 -0
  65. package/docs/how-to-contribute-with-pull-requests.md +141 -0
  66. package/docs/roo-code-guide.md +140 -0
  67. package/docs/user-guide.md +1044 -0
  68. package/docs/versioning-and-releases.md +4 -4
  69. package/docs/windsurf-guide.md +127 -0
  70. package/expansion-packs/README.md +1 -111
  71. package/expansion-packs/infrastructure-devops/agents/infra-devops-platform.md +3 -3
  72. package/expansion-packs/infrastructure-devops/tasks/create-doc.md +74 -0
  73. package/package.json +19 -13
  74. package/tools/builders/web-builder.js +16 -15
  75. package/tools/installer/README.md +2 -2
  76. package/tools/installer/bin/bmad.js +50 -29
  77. package/tools/installer/lib/file-manager.js +20 -3
  78. package/tools/installer/lib/ide-setup.js +11 -1
  79. package/tools/installer/lib/installer.js +149 -29
  80. package/tools/installer/package-lock.json +537 -335
  81. package/tools/installer/package.json +7 -7
  82. package/tools/lib/dependency-resolver.js +1 -1
  83. package/tools/semantic-release-sync-installer.js +31 -0
  84. package/tools/sync-installer-version.js +34 -0
  85. package/tools/upgraders/v3-to-v4-upgrader.js +18 -13
  86. package/tools/version-bump.js +33 -26
  87. package/tools/yaml-format.js +54 -25
  88. package/.bmad-core/schemas/agent-team-schema.yml +0 -153
  89. package/.bmad-core/tasks/create-team.md +0 -229
  90. package/.claude/settings.local.json +0 -22
@@ -0,0 +1,461 @@
1
+ # {{Project Name}} Product Requirements Document (PRD)
2
+
3
+ [[LLM: If available, review any provided document or ask if any are optionally available: Project Brief]]
4
+
5
+ ## Goals and Background Context
6
+
7
+ [[LLM: Populate the 2 child sections based on what we have received from user description or the provided brief. Allow user to review the 2 sections and offer changes before proceeding]]
8
+
9
+ ### Goals
10
+
11
+ [[LLM: Bullet list of 1 line desired outcomes the PRD will deliver if successful - user and project desires]]
12
+
13
+ ### Background Context
14
+
15
+ [[LLM: 1-2 short paragraphs summarizing the background context, such as what we learned in the brief without being redundant with the goals, what and why this solves a problem, what the current landscape or need is etc...]]
16
+
17
+ ### Change Log
18
+
19
+ [[LLM: Track document versions and changes]]
20
+
21
+ | Date | Version | Description | Author |
22
+ | :--- | :------ | :---------- | :----- |
23
+
24
+ ## Requirements
25
+
26
+ [[LLM: Draft the list of functional and non functional requirements under the two child sections, and immediately execute tasks#advanced-elicitation display]]
27
+
28
+ ### Functional
29
+
30
+ [[LLM: Each Requirement will be a bullet markdown and an identifier sequence starting with FR`.]]
31
+ @{example: - FR6: The Todo List uses AI to detect and warn against adding potentially duplicate todo items that are worded differently.}
32
+
33
+ ### Non Functional
34
+
35
+ [[LLM: Each Requirement will be a bullet markdown and an identifier sequence starting with NFR`.]]
36
+ @{example: - NFR1: AWS service usage **must** aim to stay within free-tier limits where feasible.}
37
+
38
+ ^^CONDITION: has_ui^^
39
+
40
+ ## User Interface Design Goals
41
+
42
+ [[LLM: Capture high-level UI/UX vision to inform story creation and also generate a prompt for Lovable or V0 if the user would like either. Steps:
43
+
44
+ 1. Pre-fill all subsections with educated guesses based on project context
45
+ 2. Present the complete rendered section to user
46
+ 3. Clearly let the user know where assumptions were made
47
+ 4. Ask targeted questions for unclear/missing elements or areas needing more specification
48
+ 5. This is NOT detailed UI spec - focus on product vision and user goals
49
+ 6. After section completion, immediately apply `tasks#advanced-elicitation` protocol]]
50
+
51
+ ### Overall UX Vision
52
+
53
+ ### Key Interaction Paradigms
54
+
55
+ ### Core Screens and Views
56
+
57
+ [[LLM: From a product perspective, what are the most critical screens or views necessary to deliver the the PRD values and goals? This is meant to be Conceptual High Level to Drive Rough Epic or User Stories]]
58
+
59
+ @{example}
60
+
61
+ - Login Screen
62
+ - Main Dashboard
63
+ - Item Detail Page
64
+ - Settings Page
65
+ @{/example}
66
+
67
+ ### Accessibility: { None, WCAG, etc }
68
+
69
+ ### Branding
70
+
71
+ [[LLM: Any known branding elements or style guides that must be incorporated?]]
72
+
73
+ @{example}
74
+
75
+ - Replicate the look and feel of early 1900s black and white cinema, including animated effects replicating film damage or projector glitches during page or state transitions.
76
+ - Attached is the full color pallet and tokens for our corporate branding.
77
+ @{/example}
78
+
79
+ ### Target Device and Platforms
80
+
81
+ @{example}
82
+ "Web Responsive, and all mobile platforms", "IPhone Only", "ASCII Windows Desktop"
83
+ @{/example}
84
+
85
+ ^^/CONDITION: has_ui^^
86
+
87
+ ## Technical Assumptions
88
+
89
+ [[LLM: Gather technical decisions that will be used for this simple technical PRD that includes architecture decisions. Steps:
90
+
91
+ 1. Check if `data#technical-preferences` or an attached `technical-preferences` file exists - use it to pre-populate choices
92
+ 2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets
93
+ 3. For unknowns, offer guidance based on project goals and MVP scope
94
+ 4. Document ALL technical choices with rationale (why this choice fits the project)
95
+ 5. These become constraints for the Architect - be specific and complete
96
+ 6. After section completion, apply `tasks#advanced-elicitation` protocol.]]
97
+
98
+ ### Repository Structure: { Monorepo, Polyrepo, etc...}
99
+
100
+ ### Service Architecture
101
+
102
+ [[LLM: CRITICAL DECISION - Document the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo).]]
103
+
104
+ ## Testing requirements
105
+
106
+ [[LLM: CRITICAL DECISION - Document the testing requirements, unit only, integration, e2e, manual, need for manual testing convenience methods).]]
107
+
108
+ ### Additional Technical Assumptions and Requests
109
+
110
+ [[LLM: Throughout the entire process of drafting this document, if any other technical assumptions are raised or discovered appropriate for the architect, add them here as additional bulleted items]]
111
+
112
+ ## Data Models
113
+
114
+ [[LLM: Define the core data models/entities that will be used in the front end (if there is one), core application or back end, and if both, shared between frontend and backend:
115
+
116
+ 1. Review PRD requirements and identify key business entities
117
+ 2. For each model, explain its purpose and relationships
118
+ 3. Include key attributes and data types
119
+ 4. Show relationships between models
120
+ 5. Create TypeScript interfaces that can be shared
121
+ 6. Discuss design decisions with user
122
+
123
+ Create a clear conceptual model before moving to database schema.
124
+
125
+ After presenting all data models, apply `tasks#advanced-elicitation` protocol]]
126
+
127
+ <<REPEAT: data_model>>
128
+
129
+ ### {{model_name}}
130
+
131
+ **Purpose:** {{model_purpose}}
132
+
133
+ **Key Attributes:**
134
+
135
+ - {{attribute_1}}: {{type_1}} - {{description_1}}
136
+ - {{attribute_2}}: {{type_2}} - {{description_2}}
137
+
138
+ **TypeScript Interface:**
139
+
140
+ ````typescript
141
+ {
142
+ {
143
+ model_interface;
144
+ }
145
+ }
146
+ ```text
147
+
148
+ **Relationships:**
149
+
150
+ - {{relationship_1}}
151
+ - {{relationship_2}}
152
+ <</REPEAT>>
153
+
154
+ @{example: data_model}
155
+
156
+ ### User
157
+
158
+ **Purpose:** Represents authenticated users in the system
159
+
160
+ **Key Attributes:**
161
+
162
+ - id: string - Unique identifier
163
+ - email: string - User's email address
164
+ - name: string - Display name
165
+ - role: enum - User permission level
166
+ - timestamps: Date - Created and updated times
167
+
168
+ **TypeScript Interface:**
169
+
170
+ ```typescript
171
+ interface User {
172
+ id: string;
173
+ email: string;
174
+ name: string;
175
+ role: "admin" | "user" | "guest";
176
+ createdAt: Date;
177
+ updatedAt: Date;
178
+ profile?: UserProfile;
179
+ }
180
+
181
+ interface UserProfile {
182
+ avatarUrl?: string;
183
+ bio?: string;
184
+ preferences: Record<string, any>;
185
+ }
186
+ ````
187
+
188
+ **Relationships:**
189
+
190
+ - Has many Posts (1:n)
191
+ - Has one Profile (1:1)
192
+ @{/example}
193
+
194
+ ## REST API Spec
195
+
196
+ [[LLM: Based on the chosen API style from Tech Stack:
197
+
198
+ 1. If REST API, create an OpenAPI 3.0 specification
199
+ 2. If GraphQL, provide the GraphQL schema
200
+ 3. If tRPC, show router definitions
201
+ 4. Include all endpoints from epics/stories
202
+ 5. Define request/response schemas based on data models
203
+ 6. Document authentication requirements
204
+ 7. Include example requests/responses
205
+
206
+ Use appropriate format for the chosen API style. If no API (e.g., static site), skip this section.]]
207
+
208
+ ^^CONDITION: has_rest_api^^
209
+
210
+ ````yml
211
+ openapi: 3.0.0
212
+ info:
213
+ title:
214
+ '[object Object]': null
215
+ version:
216
+ '[object Object]': null
217
+ description:
218
+ '[object Object]': null
219
+ servers:
220
+ - url:
221
+ '[object Object]': null
222
+ description:
223
+ '[object Object]': null
224
+ ```text
225
+
226
+ ^^/CONDITION: has_rest_api^^
227
+
228
+ ^^CONDITION: has_graphql_api^^
229
+
230
+ ```graphql
231
+ # GraphQL Schema
232
+ {{graphql_schema}}
233
+ ````
234
+
235
+ ^^/CONDITION: has_graphql_api^^
236
+
237
+ ^^CONDITION: has_trpc_api^^
238
+
239
+ ```typescript
240
+ // tRPC Router Definitions
241
+ {
242
+ {
243
+ trpc_routers;
244
+ }
245
+ }
246
+ ```
247
+
248
+ ^^/CONDITION: has_trpc_api^^
249
+
250
+ [[LLM: After presenting the API spec (or noting its absence if not applicable), apply `tasks#advanced-elicitation` protocol]]
251
+
252
+ ## Components
253
+
254
+ [[LLM: Based on the architectural patterns, tech stack, and data models from above:
255
+
256
+ 1. Identify major logical components/services across the fullstack
257
+ 2. Consider both frontend and backend components
258
+ 3. Define clear boundaries and interfaces between components
259
+ 4. For each component, specify:
260
+
261
+ - Primary responsibility
262
+ - Key interfaces/APIs exposed
263
+ - Dependencies on other components
264
+ - Technology specifics based on tech stack choices
265
+
266
+ 5. Create component diagrams where helpful
267
+ 6. After presenting all components, apply `tasks#advanced-elicitation` protocol]]
268
+
269
+ <<REPEAT: component>>
270
+
271
+ ### {{component_name}}
272
+
273
+ **Responsibility:** {{component_description}}
274
+
275
+ **Key Interfaces:**
276
+
277
+ - {{interface_1}}
278
+ - {{interface_2}}
279
+
280
+ **Dependencies:** {{dependencies}}
281
+
282
+ **Technology Stack:** {{component_tech_details}}
283
+ <</REPEAT>>
284
+
285
+ ### Component Diagrams
286
+
287
+ [[LLM: Create Mermaid diagrams to visualize component relationships. Options:
288
+
289
+ - C4 Container diagram for high-level view
290
+ - Component diagram for detailed internal structure
291
+ - Sequence diagrams for complex interactions
292
+ Choose the most appropriate for clarity
293
+
294
+ After presenting the diagrams, apply `tasks#advanced-elicitation` protocol]]
295
+
296
+ ## External APIs
297
+
298
+ [[LLM: For each external service integration:
299
+
300
+ 1. Identify APIs needed based on PRD requirements and component design
301
+ 2. If documentation URLs are unknown, ask user for specifics
302
+ 3. Document authentication methods and security considerations
303
+ 4. List specific endpoints that will be used
304
+ 5. Note any rate limits or usage constraints
305
+
306
+ If no external APIs are needed, state this explicitly and skip to next section.]]
307
+
308
+ ^^CONDITION: has_external_apis^^
309
+
310
+ <<REPEAT: external_api>>
311
+
312
+ ### {{api_name}} API
313
+
314
+ - **Purpose:** {{api_purpose}}
315
+ - **Documentation:** {{api_docs_url}}
316
+ - **Base URL(s):** {{api_base_url}}
317
+ - **Authentication:** {{auth_method}}
318
+ - **Rate Limits:** {{rate_limits}}
319
+
320
+ **Key Endpoints Used:**
321
+ <<REPEAT: endpoint>>
322
+
323
+ - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
324
+ <</REPEAT>>
325
+
326
+ **Integration Notes:** {{integration_considerations}}
327
+ <</REPEAT>>
328
+
329
+ @{example: external_api}
330
+
331
+ ### Stripe API
332
+
333
+ - **Purpose:** Payment processing and subscription management
334
+ - **Documentation:** https://stripe.com/docs/api
335
+ - **Base URL(s):** `https://api.stripe.com/v1`
336
+ - **Authentication:** Bearer token with secret key
337
+ - **Rate Limits:** 100 requests per second
338
+
339
+ **Key Endpoints Used:**
340
+
341
+ - `POST /customers` - Create customer profiles
342
+ - `POST /payment_intents` - Process payments
343
+ - `POST /subscriptions` - Manage subscriptions
344
+ @{/example}
345
+
346
+ ^^/CONDITION: has_external_apis^^
347
+
348
+ [[LLM: After presenting external APIs (or noting their absence), apply `tasks#advanced-elicitation` protocol]]
349
+
350
+ ## Coding Standards
351
+
352
+ [[LLM: Define MINIMAL but CRITICAL standards for AI agents. Focus only on project-specific rules that prevent common mistakes. These will be used by dev agents.
353
+
354
+ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
355
+
356
+ ### Critical Fullstack Rules
357
+
358
+ <<REPEAT: critical_rule>>
359
+
360
+ - **{{rule_name}}:** {{rule_description}}
361
+ <</REPEAT>>
362
+
363
+ @{example: critical_rules}
364
+
365
+ - **Type Sharing:** Always define types in packages/shared and import from there
366
+ - **API Calls:** Never make direct HTTP calls - use the service layer
367
+ - **Environment Variables:** Access only through config objects, never process.env directly
368
+ - **Error Handling:** All API routes must use the standard error handler
369
+ - **State Updates:** Never mutate state directly - use proper state management patterns
370
+ @{/example}
371
+
372
+ ### Naming Conventions
373
+
374
+ | Element | Frontend | Backend | Example |
375
+ | :-------------- | :------------------- | :--------- | :------------------ |
376
+ | Components | PascalCase | - | `UserProfile.tsx` |
377
+ | Hooks | camelCase with 'use' | - | `useAuth.ts` |
378
+ | API Routes | - | kebab-case | `/api/user-profile` |
379
+ | Database Tables | - | snake_case | `user_profiles` |
380
+
381
+ ## Epics
382
+
383
+ [[LLM: First, present a high-level list of all epics for user approval, the epic_list and immediately execute tasks#advanced-elicitation display. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
384
+
385
+ CRITICAL: Epics MUST be logically sequential following agile best practices:
386
+
387
+ - Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
388
+ - Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page
389
+ - Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
390
+ - Not every project needs multiple epics, an epic needs to deliver value. For example, an API completed can deliver value even if a UI is not complete and planned for a separate epic.
391
+ - Err on the side of less epics, but let the user know your rationale and offer options for splitting them if it seems some are too large or focused on disparate things.
392
+ - Cross Cutting Concerns should flow through epics and stories and not be final stories. For example, adding a logging framework as a last story of an epic, or at the end of a project as a final epic or story would be terrible as we would not have logging from the beginning.]]
393
+
394
+ <<REPEAT: epic_list>>
395
+
396
+ - Epic{{epic_number}} {{epic_title}}: {{short_goal}}
397
+
398
+ <</REPEAT>>
399
+
400
+ @{example: epic_list}
401
+
402
+ 1. Foundation & Core Infrastructure: Establish project setup, authentication, and basic user management
403
+ 2. Core Business Entities: Create and manage primary domain objects with CRUD operations
404
+ 3. User Workflows & Interactions: Enable key user journeys and business processes
405
+ 4. Reporting & Analytics: Provide insights and data visualization for users
406
+
407
+ @{/example}
408
+
409
+ [[LLM: After the epic list is approved, present each `epic_details` with all its stories and acceptance criteria as a complete review unit and immediately execute tasks#advanced-elicitation display, before moving on to the next epic.]]
410
+
411
+ <<REPEAT: epic_details>>
412
+
413
+ ## Epic {{epic_number}} {{epic_title}}
414
+
415
+ {{epic_goal}} [[LLM: Expanded goal - 2-3 sentences describing the objective and value all the stories will achieve]]
416
+
417
+ [[LLM: CRITICAL STORY SEQUENCING REQUIREMENTS:
418
+
419
+ - Stories within each epic MUST be logically sequential
420
+ - Each story should be a "vertical slice" delivering complete functionality
421
+ - No story should depend on work from a later story or epic
422
+ - Identify and note any direct prerequisite stories
423
+ - Focus on "what" and "why" not "how" (leave technical implementation to Architect) yet be precise enough to support a logical sequential order of operations from story to story.
424
+ - Ensure each story delivers clear user or business value, try to avoid enablers and build them into stories that deliver value.
425
+ - Size stories for AI agent execution: Each story must be completable by a single AI agent in one focused session without context overflow
426
+ - Think "junior developer working for 2-4 hours" - stories must be small, focused, and self-contained
427
+ - If a story seems complex, break it down further as long as it can deliver a vertical slice
428
+ - Each story should result in working, testable code before the agent's context window fills]]
429
+
430
+ <<REPEAT: story>>
431
+
432
+ ### Story {{epic_number}}.{{story_number}} {{story_title}}
433
+
434
+ As a {{user_type}},
435
+ I want {{action}},
436
+ so that {{benefit}}.
437
+
438
+ #### Acceptance Criteria
439
+
440
+ [[LLM: Define clear, comprehensive, and testable acceptance criteria that:
441
+
442
+ - Precisely define what "done" means from a functional perspective
443
+ - Are unambiguous and serve as basis for verification
444
+ - Include any critical non-functional requirements from the PRD
445
+ - Consider local testability for backend/data components
446
+ - Specify UI/UX requirements and framework adherence where applicable
447
+ - Avoid cross-cutting concerns that should be in other stories or PRD sections]]
448
+
449
+ <<REPEAT: criteria>>
450
+
451
+ - {{criterion number}}: {{criteria}}
452
+
453
+ <</REPEAT>>
454
+ <</REPEAT>>
455
+ <</REPEAT>>
456
+
457
+ ## Next Steps
458
+
459
+ ### Design Architect Prompt
460
+
461
+ [[LLM: This section will contain the prompt for the Design Architect, keep it short and to the point to initiate create architecture mode using this document as input.]]
@@ -49,12 +49,12 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
49
49
 
50
50
  ### Completion Notes List
51
51
 
52
- [[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update]]
52
+ [[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update - remove this line to the SM]]
53
53
  [[LLM: (Dev Agent) Anything the SM needs to know that deviated from the story that might impact drafting the next story.]]
54
54
 
55
55
  ### Change Log
56
56
 
57
- [[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update]]
57
+ [[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update- remove this line to the SM]]
58
58
  [[LLM: (Dev Agent) Track document versions and changes during development that deviate from story dev start]]
59
59
 
60
60
  | Date | Version | Description | Author |
@@ -9,8 +9,7 @@ The BMAD orchestrator MUST read the available workflows from the current team co
9
9
  **Critical Distinction**:
10
10
 
11
11
  - When asked "what workflows are available?", show ONLY the workflows defined in the current team bundle's configuration
12
- - The create-\* tasks (create-agent, create-team, etc.) are for CREATING new configurations, not for listing what's available in the current session
13
- - Use `/agent-list` to show agents in the current bundle, NOT the create-agent task
12
+ - Use `/agent-list` to show agents in the current bundle
14
13
  - Use `/workflows` to show workflows in the current bundle, NOT any creation tasks
15
14
 
16
15
  ### Workflow Descriptions
@@ -41,14 +40,14 @@ The actual list depends on which team bundle is loaded. When responding to this
41
40
 
42
41
  Example response format:
43
42
 
44
- ```text
43
+ ````text
45
44
  Available workflows for [Team Name]:
46
45
  1. [workflow-id] - [Brief description based on workflow type]
47
46
  2. [workflow-id] - [Brief description based on workflow type]
48
47
  [... etc. ...]
49
48
 
50
49
  Use /workflow-start {number or id} to begin a workflow.
51
- ```
50
+ ```text
52
51
 
53
52
  ### /workflow-start {workflow-id}
54
53
 
@@ -74,7 +73,7 @@ In Progress:
74
73
  - Create PRD (John) - awaiting input
75
74
 
76
75
  Next: Technical Architecture
77
- ```
76
+ ````
78
77
 
79
78
  ### /workflow-resume
80
79
 
@@ -82,7 +81,7 @@ Resumes a workflow from where it left off, useful when starting a new chat.
82
81
 
83
82
  User can provide completed artifacts:
84
83
 
85
- ```text
84
+ ````text
86
85
  User: /workflow-resume greenfield-fullstack
87
86
  I have completed: project-brief, PRD
88
87
  BMad: I see you've completed Discovery and part of Product Planning.
@@ -90,7 +89,7 @@ BMad: I see you've completed Discovery and part of Product Planning.
90
89
  - UX Strategy with Sally (ux-expert)
91
90
 
92
91
  Would you like me to load Sally to continue?
93
- ```
92
+ ```text
94
93
 
95
94
  ### /workflow-next
96
95
 
@@ -131,12 +130,12 @@ workflow_state:
131
130
  project-brief:
132
131
  status: completed
133
132
  created_by: analyst
134
- timestamp: 2024-01-15T10:30:00Z
133
+ timestamp: 2024-01-15T10:30:00.000Z
135
134
  prd:
136
135
  status: in-progress
137
136
  created_by: pm
138
- started: 2024-01-15T11:00:00Z
139
- ```
137
+ started: 2024-01-15T11:00:00.000Z
138
+ ````
140
139
 
141
140
  ### 4. Workflow Interruption Handling
142
141
 
@@ -150,7 +149,7 @@ When user returns after interruption:
150
149
 
151
150
  Example:
152
151
 
153
- ```text
152
+ ````text
154
153
  User: I'm working on a new app. Here's my PRD and architecture doc.
155
154
  BMad: I see you have a PRD and architecture document. Based on these artifacts,
156
155
  it looks like you're following the greenfield-fullstack workflow and have completed
@@ -160,7 +159,7 @@ BMad: I see you have a PRD and architecture document. Based on these artifacts,
160
159
  - Load Sarah (Product Owner) to validate all artifacts
161
160
 
162
161
  Would you like to continue with this workflow?
163
- ```
162
+ ```text
164
163
 
165
164
  ## Workflow Context Passing
166
165
 
@@ -186,7 +185,7 @@ Sally: I see we're in the Product Planning stage of the greenfield-fullstack wor
186
185
 
187
186
  Let's create the UX strategy and UI specifications. First, let me review
188
187
  the PRD to understand the features we're designing for...
189
- ```
188
+ ````
190
189
 
191
190
  ## Multi-Path Workflows
192
191
 
@@ -194,9 +193,9 @@ Some workflows may have multiple paths:
194
193
 
195
194
  ```yaml
196
195
  conditional_paths:
197
- - condition: "project_type == 'mobile'"
196
+ - condition: project_type == 'mobile'
198
197
  next_stage: mobile-specific-design
199
- - condition: "project_type == 'web'"
198
+ - condition: project_type == 'web'
200
199
  next_stage: web-architecture
201
200
  - default: fullstack-architecture
202
201
  ```
@@ -43,27 +43,24 @@ These references map directly to bundle sections:
43
43
 
44
44
  CRITICAL: Read the full YML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
45
45
 
46
- ```yml
46
+ ```yaml
47
47
  activation-instructions:
48
- - Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
49
- - Only read the files/tasks listed here when user selects them for execution to minimize context usage
50
- - The customization field ALWAYS takes precedence over any conflicting instructions
51
- - When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
52
-
48
+ - Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
49
+ - Only read the files/tasks listed here when user selects them for execution to minimize context usage
50
+ - The customization field ALWAYS takes precedence over any conflicting instructions
51
+ - When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
53
52
  agent:
54
53
  name: Mary
55
54
  id: analyst
56
55
  title: Business Analyst
57
56
  icon: 📊
58
- whenToUse: "Use for market research, brainstorming, competitive analysis, creating project briefs, and initial project discovery"
59
- customization:
60
-
57
+ whenToUse: Use for market research, brainstorming, competitive analysis, creating project briefs, and initial project discovery
58
+ customization: null
61
59
  persona:
62
60
  role: Insightful Analyst & Strategic Ideation Partner
63
61
  style: Analytical, inquisitive, creative, facilitative, objective, data-informed
64
62
  identity: Strategic analyst specializing in brainstorming, market research, competitive analysis, and project briefing
65
63
  focus: Research planning, ideation facilitation, strategic analysis, actionable insights
66
-
67
64
  core_principles:
68
65
  - Curiosity-Driven Inquiry - Ask probing "why" questions to uncover underlying truths
69
66
  - Objective & Evidence-Based Analysis - Ground findings in verifiable data and credible sources
@@ -76,19 +73,16 @@ persona:
76
73
  - Maintaining a Broad Perspective - Stay aware of market trends and dynamics
77
74
  - Integrity of Information - Ensure accurate sourcing and representation
78
75
  - Numbered Options Protocol - Always use numbered lists for selections
79
-
80
76
  startup:
81
77
  - Greet the user with your name and role, and inform of the *help command.
82
-
83
78
  commands:
84
- - "*help" - Show: numbered list of the following commands to allow selection
85
- - "*chat-mode" - (Default) Strategic analysis consultation with advanced-elicitation
86
- - "*create-doc {template}" - Create doc (no template = show available templates)
87
- - "*brainstorm {topic}" - Facilitate structured brainstorming session
88
- - "*research {topic}" - Generate deep research prompt for investigation
89
- - "*elicit" - Run advanced elicitation to clarify requirements
90
- - "*exit" - Say goodbye as the Business Analyst, and then abandon inhabiting this persona
91
-
79
+ - '*help" - Show: numbered list of the following commands to allow selection'
80
+ - '*chat-mode" - (Default) Strategic analysis consultation with advanced-elicitation'
81
+ - '*create-doc {template}" - Create doc (no template = show available templates)'
82
+ - '*brainstorm {topic}" - Facilitate structured brainstorming session'
83
+ - '*research {topic}" - Generate deep research prompt for investigation'
84
+ - '*elicit" - Run advanced elicitation to clarify requirements'
85
+ - '*exit" - Say goodbye as the Business Analyst, and then abandon inhabiting this persona'
92
86
  dependencies:
93
87
  tasks:
94
88
  - brainstorming-techniques
@@ -1646,7 +1640,18 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
1646
1640
  7. **START_SMALL_SCALE_FAST**: Test concepts, then expand.
1647
1641
  8. **EMBRACE_THE_CHAOS**: Adapt and overcome challenges.
1648
1642
 
1649
- ## TODO: ADD MORE CONTENT ONCE STABLE ALPHA BUILD
1643
+ ## IDE Development Workflow
1644
+
1645
+ 1. Shard the PRD (And Architecture documents if they exist also based on workflow type) using the Doc Shard task. The BMad-Master agent can help you do this. You will select the task, provide the doc to shard and the output folder. for example: `BMad Master, please Shard the docs/prd.md to the doc/prd/ folder` - this should ask you to use the md-tree-parser which is recommended, but either way shoudl result in multiple documents being created in the folder docs/prd.
1646
+ 2. If you have fullstack, front end and or back end architecture documents you will want to follow the same thing, but shard all of these to an architecture folder instead of a prd folder.
1647
+ 3. Ensure that you have at least one epic-n.md file in your prd folder, with the stories in order to develop.
1648
+ 4. The docs or architecture folder or prd folder should have a source tree document and coding standards at a minimum. These are used by the dev agent, and the many other sharded docs are used by the SM agent.
1649
+ 5. Use a new chat window to allow the SM agent to `draft the next story`.
1650
+ 6. If you agree the story is correct, mark it as approved in the status field, and then start a new chat window with the dev agent.
1651
+ 7. Ask the dev agent to implement the next story. If you draft the story file into the chat it will save time for the dev to have to find what the next one is. The dev should follow the tasks and subtasks marking them off as they are completed. The dev agent will also leave notes potentially for the SM to know about any deviations that might have occured to help draft the next story.
1652
+ 8. Once complete and you have verified, mark it done, and start a new chat. Ask the SM to draft the next story - repeating the cycle.
1653
+
1654
+ With this work flow, there is only 1 story in progress at a time, worked sequentially.
1650
1655
  ==================== END: data#bmad-kb ====================
1651
1656
 
1652
1657
  ==================== START: utils#template-format ====================