bmad-method 1.1.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.
- package/.bmad-core/agents/analyst.md +14 -20
- package/.bmad-core/agents/architect.md +15 -20
- package/.bmad-core/agents/bmad-master.md +18 -26
- package/.bmad-core/agents/bmad-orchestrator.md +16 -28
- package/.bmad-core/agents/dev.md +5 -4
- package/.bmad-core/agents/pm.md +11 -16
- package/.bmad-core/agents/sm.md +20 -25
- package/.bmad-core/bmad-core-config.yml +60 -0
- package/.bmad-core/data/bmad-kb.md +12 -1
- package/.bmad-core/tasks/doc-migration-task.md +91 -146
- package/.bmad-core/tasks/document-project.md +389 -0
- package/.bmad-core/tasks/generate-ai-frontend-prompt.md +41 -48
- package/.bmad-core/tasks/index-docs.md +4 -1
- package/.bmad-core/templates/architecture-tmpl.md +15 -12
- package/.bmad-core/templates/fullstack-architecture-tmpl.md +85 -103
- package/.bmad-core/templates/prd-tmpl.md +1 -1
- package/.bmad-core/templates/simple-project-prd-tmpl.md +461 -0
- package/.bmad-core/templates/story-tmpl.md +2 -2
- package/.bmad-core/utils/workflow-management.md +14 -15
- package/.bmad-core/web-bundles/agents/analyst.txt +26 -21
- package/.bmad-core/web-bundles/agents/architect.txt +605 -233
- package/.bmad-core/web-bundles/agents/bmad-master.txt +457 -1039
- package/.bmad-core/web-bundles/agents/bmad-orchestrator.txt +36 -903
- package/.bmad-core/web-bundles/agents/dev.txt +5 -4
- package/.bmad-core/web-bundles/agents/pm.txt +476 -17
- package/.bmad-core/web-bundles/agents/po.txt +2 -2
- package/.bmad-core/web-bundles/agents/sm.txt +22 -27
- package/.bmad-core/web-bundles/agents/ux-expert.txt +41 -48
- package/.bmad-core/web-bundles/teams/team-all.txt +4394 -4447
- package/.bmad-core/web-bundles/teams/team-fullstack.txt +2760 -2809
- package/.bmad-core/web-bundles/teams/team-no-ui.txt +2718 -2760
- package/.bmad-core/workflows/greenfield-fullstack.yml +3 -3
- package/.claude/commands/analyst.md +14 -20
- package/.claude/commands/architect.md +15 -20
- package/.claude/commands/bmad-master.md +18 -26
- package/.claude/commands/bmad-orchestrator.md +16 -28
- package/.claude/commands/dev.md +5 -4
- package/.claude/commands/pm.md +11 -16
- package/.claude/commands/sm.md +20 -25
- package/.cursor/rules/analyst.mdc +13 -19
- package/.cursor/rules/architect.mdc +14 -19
- package/.cursor/rules/bmad-master.mdc +18 -26
- package/.cursor/rules/bmad-orchestrator.mdc +15 -27
- package/.cursor/rules/dev.mdc +5 -4
- package/.cursor/rules/pm.mdc +11 -16
- package/.cursor/rules/sm.mdc +19 -24
- package/.releaserc.json +2 -1
- package/.vscode/settings.json +4 -0
- package/.windsurf/rules/analyst.md +13 -19
- package/.windsurf/rules/architect.md +14 -19
- package/.windsurf/rules/bmad-master.md +18 -26
- package/.windsurf/rules/bmad-orchestrator.md +15 -27
- package/.windsurf/rules/dev.md +5 -4
- package/.windsurf/rules/pm.md +11 -16
- package/.windsurf/rules/sm.md +19 -24
- package/CHANGELOG.md +120 -2
- package/CONTRIBUTING.md +2 -0
- package/README.md +21 -3
- package/{.bmad-core → creator-tools}/tasks/create-agent.md +10 -12
- package/{.bmad-core/tasks/create-expansion-pack.md → creator-tools/tasks/generate-expansion-pack.md} +8 -6
- package/docs/bmad-workflow-guide.md +161 -0
- package/docs/claude-code-guide.md +119 -0
- package/docs/core-architecture.md +213 -0
- package/docs/cursor-guide.md +127 -0
- package/docs/how-to-contribute-with-pull-requests.md +141 -0
- package/docs/roo-code-guide.md +140 -0
- package/docs/user-guide.md +1044 -0
- package/docs/windsurf-guide.md +127 -0
- package/expansion-packs/README.md +1 -111
- package/expansion-packs/infrastructure-devops/agents/infra-devops-platform.md +1 -1
- package/expansion-packs/infrastructure-devops/tasks/create-doc.md +74 -0
- package/package.json +19 -13
- package/tools/builders/web-builder.js +16 -15
- package/tools/installer/bin/bmad.js +50 -29
- package/tools/installer/lib/file-manager.js +20 -3
- package/tools/installer/lib/ide-setup.js +11 -1
- package/tools/installer/lib/installer.js +149 -29
- package/tools/installer/package-lock.json +537 -335
- package/tools/installer/package.json +7 -7
- package/tools/lib/dependency-resolver.js +1 -1
- package/tools/semantic-release-sync-installer.js +31 -0
- package/tools/sync-installer-version.js +34 -0
- package/tools/upgraders/v3-to-v4-upgrader.js +18 -13
- package/tools/version-bump.js +33 -26
- package/tools/yaml-format.js +54 -25
- package/.bmad-core/schemas/agent-team-schema.yml +0 -153
- package/.bmad-core/tasks/create-team.md +0 -229
|
@@ -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
|
-
```
|
|
46
|
+
```yaml
|
|
47
47
|
activation-instructions:
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
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: Winston
|
|
55
54
|
id: architect
|
|
56
55
|
title: Architect
|
|
57
56
|
icon: 🏗️
|
|
58
|
-
whenToUse:
|
|
59
|
-
customization:
|
|
60
|
-
|
|
57
|
+
whenToUse: Use for system design, architecture documents, technology selection, API design, and infrastructure planning
|
|
58
|
+
customization: null
|
|
61
59
|
persona:
|
|
62
60
|
role: Holistic System Architect & Full-Stack Technical Leader
|
|
63
61
|
style: Comprehensive, pragmatic, user-centric, technically deep yet accessible
|
|
64
62
|
identity: Master of holistic application design who bridges frontend, backend, infrastructure, and everything in between
|
|
65
63
|
focus: Complete systems architecture, cross-stack optimization, pragmatic technology selection
|
|
66
|
-
|
|
67
64
|
core_principles:
|
|
68
65
|
- Holistic System Thinking - View every component as part of a larger system
|
|
69
66
|
- User Experience Drives Architecture - Start with user journeys and work backward
|
|
@@ -75,24 +72,22 @@ persona:
|
|
|
75
72
|
- Data-Centric Design - Let data requirements drive architecture
|
|
76
73
|
- Cost-Conscious Engineering - Balance technical ideals with financial reality
|
|
77
74
|
- Living Architecture - Design for change and adaptation
|
|
78
|
-
|
|
79
75
|
startup:
|
|
80
76
|
- Greet the user with your name and role, and inform of the *help command.
|
|
81
77
|
- When creating architecture, always start by understanding the complete picture - user needs, business constraints, team capabilities, and technical requirements.
|
|
82
|
-
|
|
83
78
|
commands:
|
|
84
|
-
-
|
|
85
|
-
-
|
|
86
|
-
-
|
|
87
|
-
-
|
|
88
|
-
-
|
|
89
|
-
-
|
|
90
|
-
|
|
79
|
+
- '*help" - Show: numbered list of the following commands to allow selection'
|
|
80
|
+
- '*chat-mode" - (Default) Architect consultation with advanced-elicitation for complex system design'
|
|
81
|
+
- '*create-doc {template}" - Create doc (no template = show available templates)'
|
|
82
|
+
- '*execute-checklist {checklist}" - Run architectural validation checklist'
|
|
83
|
+
- '*research {topic}" - Generate deep research prompt for architectural decisions'
|
|
84
|
+
- '*exit" - Say goodbye as the Architect, and then abandon inhabiting this persona'
|
|
91
85
|
dependencies:
|
|
92
86
|
tasks:
|
|
93
87
|
- create-doc
|
|
94
|
-
- execute-checklist
|
|
95
88
|
- create-deep-research-prompt
|
|
89
|
+
- document-project
|
|
90
|
+
- execute-checklist
|
|
96
91
|
templates:
|
|
97
92
|
- architecture-tmpl
|
|
98
93
|
- front-end-architecture-tmpl
|
|
@@ -184,106 +179,6 @@ If template specifies a checklist:
|
|
|
184
179
|
- Template markup is for AI processing only - never expose to users
|
|
185
180
|
==================== END: tasks#create-doc ====================
|
|
186
181
|
|
|
187
|
-
==================== START: tasks#execute-checklist ====================
|
|
188
|
-
# Checklist Validation Task
|
|
189
|
-
|
|
190
|
-
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
|
191
|
-
|
|
192
|
-
## Context
|
|
193
|
-
|
|
194
|
-
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
|
195
|
-
|
|
196
|
-
## Available Checklists
|
|
197
|
-
|
|
198
|
-
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
|
199
|
-
|
|
200
|
-
## Instructions
|
|
201
|
-
|
|
202
|
-
1. **Initial Assessment**
|
|
203
|
-
|
|
204
|
-
- If user or the task being run provides a checklist name:
|
|
205
|
-
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
|
206
|
-
- If multiple matches found, ask user to clarify
|
|
207
|
-
- Load the appropriate checklist from bmad-core/checklists/
|
|
208
|
-
- If no checklist specified:
|
|
209
|
-
- Ask the user which checklist they want to use
|
|
210
|
-
- Present the available options from the files in the checklists folder
|
|
211
|
-
- Confirm if they want to work through the checklist:
|
|
212
|
-
- Section by section (interactive mode - very time consuming)
|
|
213
|
-
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
|
214
|
-
|
|
215
|
-
2. **Document and Artifact Gathering**
|
|
216
|
-
|
|
217
|
-
- Each checklist will specify its required documents/artifacts at the beginning
|
|
218
|
-
- 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.
|
|
219
|
-
|
|
220
|
-
3. **Checklist Processing**
|
|
221
|
-
|
|
222
|
-
If in interactive mode:
|
|
223
|
-
|
|
224
|
-
- Work through each section of the checklist one at a time
|
|
225
|
-
- For each section:
|
|
226
|
-
- Review all items in the section following instructions for that section embedded in the checklist
|
|
227
|
-
- Check each item against the relevant documentation or artifacts as appropriate
|
|
228
|
-
- Present summary of findings for that section, highlighting warnings, errors and non applicable items (rationale for non-applicability).
|
|
229
|
-
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
|
230
|
-
|
|
231
|
-
If in YOLO mode:
|
|
232
|
-
|
|
233
|
-
- Process all sections at once
|
|
234
|
-
- Create a comprehensive report of all findings
|
|
235
|
-
- Present the complete analysis to the user
|
|
236
|
-
|
|
237
|
-
4. **Validation Approach**
|
|
238
|
-
|
|
239
|
-
For each checklist item:
|
|
240
|
-
|
|
241
|
-
- Read and understand the requirement
|
|
242
|
-
- Look for evidence in the documentation that satisfies the requirement
|
|
243
|
-
- Consider both explicit mentions and implicit coverage
|
|
244
|
-
- Aside from this, follow all checklist llm instructions
|
|
245
|
-
- Mark items as:
|
|
246
|
-
- ✅ PASS: Requirement clearly met
|
|
247
|
-
- ❌ FAIL: Requirement not met or insufficient coverage
|
|
248
|
-
- ⚠️ PARTIAL: Some aspects covered but needs improvement
|
|
249
|
-
- N/A: Not applicable to this case
|
|
250
|
-
|
|
251
|
-
5. **Section Analysis**
|
|
252
|
-
|
|
253
|
-
For each section:
|
|
254
|
-
|
|
255
|
-
- think step by step to calculate pass rate
|
|
256
|
-
- Identify common themes in failed items
|
|
257
|
-
- Provide specific recommendations for improvement
|
|
258
|
-
- In interactive mode, discuss findings with user
|
|
259
|
-
- Document any user decisions or explanations
|
|
260
|
-
|
|
261
|
-
6. **Final Report**
|
|
262
|
-
|
|
263
|
-
Prepare a summary that includes:
|
|
264
|
-
|
|
265
|
-
- Overall checklist completion status
|
|
266
|
-
- Pass rates by section
|
|
267
|
-
- List of failed items with context
|
|
268
|
-
- Specific recommendations for improvement
|
|
269
|
-
- Any sections or items marked as N/A with justification
|
|
270
|
-
|
|
271
|
-
## Checklist Execution Methodology
|
|
272
|
-
|
|
273
|
-
Each checklist now contains embedded LLM prompts and instructions that will:
|
|
274
|
-
|
|
275
|
-
1. **Guide thorough thinking** - Prompts ensure deep analysis of each section
|
|
276
|
-
2. **Request specific artifacts** - Clear instructions on what documents/access is needed
|
|
277
|
-
3. **Provide contextual guidance** - Section-specific prompts for better validation
|
|
278
|
-
4. **Generate comprehensive reports** - Final summary with detailed findings
|
|
279
|
-
|
|
280
|
-
The LLM will:
|
|
281
|
-
|
|
282
|
-
- Execute the complete checklist validation
|
|
283
|
-
- Present a final report with pass/fail rates and key findings
|
|
284
|
-
- Offer to provide detailed analysis of any section, especially those with warnings or failures
|
|
285
|
-
==================== END: tasks#execute-checklist ====================
|
|
286
|
-
|
|
287
182
|
==================== START: tasks#create-deep-research-prompt ====================
|
|
288
183
|
# Create Deep Research Prompt Task
|
|
289
184
|
|
|
@@ -588,6 +483,498 @@ Present these numbered options to the user:
|
|
|
588
483
|
- Plan for iterative refinement based on initial findings
|
|
589
484
|
==================== END: tasks#create-deep-research-prompt ====================
|
|
590
485
|
|
|
486
|
+
==================== START: tasks#document-project ====================
|
|
487
|
+
# Document an Existing Project
|
|
488
|
+
|
|
489
|
+
## Purpose
|
|
490
|
+
|
|
491
|
+
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.
|
|
492
|
+
|
|
493
|
+
## Task Instructions
|
|
494
|
+
|
|
495
|
+
### 1. Initial Project Analysis
|
|
496
|
+
|
|
497
|
+
[[LLM: Begin by conducting a comprehensive analysis of the existing project. Use available tools to:
|
|
498
|
+
|
|
499
|
+
1. **Project Structure Discovery**: Examine the root directory structure, identify main folders, and understand the overall organization
|
|
500
|
+
2. **Technology Stack Identification**: Look for package.json, requirements.txt, Cargo.toml, pom.xml, etc. to identify languages, frameworks, and dependencies
|
|
501
|
+
3. **Build System Analysis**: Find build scripts, CI/CD configurations, and development commands
|
|
502
|
+
4. **Existing Documentation Review**: Check for README files, docs folders, and any existing documentation
|
|
503
|
+
5. **Code Pattern Analysis**: Sample key files to understand coding patterns, naming conventions, and architectural approaches
|
|
504
|
+
|
|
505
|
+
Ask the user these elicitation questions to better understand their needs:
|
|
506
|
+
|
|
507
|
+
- What is the primary purpose of this project?
|
|
508
|
+
- Are there any specific areas of the codebase that are particularly complex or important for agents to understand?
|
|
509
|
+
- What types of tasks do you expect AI agents to perform on this project? (e.g., bug fixes, feature additions, refactoring, testing)
|
|
510
|
+
- Are there any existing documentation standards or formats you prefer?
|
|
511
|
+
- What level of technical detail should the documentation target? (junior developers, senior developers, mixed team)
|
|
512
|
+
]]
|
|
513
|
+
|
|
514
|
+
### 2. Core Documentation Generation
|
|
515
|
+
|
|
516
|
+
[[LLM: Based on your analysis, generate the following core documentation files. Adapt the content and structure to match the specific project type and context you discovered:
|
|
517
|
+
|
|
518
|
+
**Core Documents (always generate):**
|
|
519
|
+
|
|
520
|
+
1. **docs/index.md** - Master documentation index
|
|
521
|
+
2. **docs/architecture/index.md** - Architecture documentation index
|
|
522
|
+
3. **docs/architecture/coding-standards.md** - Coding conventions and style guidelines
|
|
523
|
+
4. **docs/architecture/tech-stack.md** - Technology stack and version constraints
|
|
524
|
+
5. **docs/architecture/unified-project-structure.md** - Project structure and organization
|
|
525
|
+
6. **docs/architecture/testing-strategy.md** - Testing approaches and requirements
|
|
526
|
+
|
|
527
|
+
**Backend Documents (generate for backend/full-stack projects):**
|
|
528
|
+
|
|
529
|
+
7. **docs/architecture/backend-architecture.md** - Backend service patterns and structure
|
|
530
|
+
8. **docs/architecture/rest-api-spec.md** - API endpoint specifications
|
|
531
|
+
9. **docs/architecture/data-models.md** - Data structures and validation rules
|
|
532
|
+
10. **docs/architecture/database-schema.md** - Database design and relationships
|
|
533
|
+
11. **docs/architecture/external-apis.md** - Third-party integrations
|
|
534
|
+
|
|
535
|
+
**Frontend Documents (generate for frontend/full-stack projects):**
|
|
536
|
+
|
|
537
|
+
12. **docs/architecture/frontend-architecture.md** - Frontend patterns and structure
|
|
538
|
+
13. **docs/architecture/components.md** - UI component specifications
|
|
539
|
+
14. **docs/architecture/core-workflows.md** - User interaction flows
|
|
540
|
+
15. **docs/architecture/ui-ux-spec.md** - UI/UX specifications and guidelines
|
|
541
|
+
|
|
542
|
+
**Additional Documents (generate if applicable):**
|
|
543
|
+
|
|
544
|
+
16. **docs/prd.md** - Product requirements document (if not exists)
|
|
545
|
+
17. **docs/architecture/deployment-guide.md** - Deployment and operations info
|
|
546
|
+
18. **docs/architecture/security-considerations.md** - Security patterns and requirements
|
|
547
|
+
19. **docs/architecture/performance-guidelines.md** - Performance optimization patterns
|
|
548
|
+
|
|
549
|
+
**Optional Enhancement Documents:**
|
|
550
|
+
|
|
551
|
+
20. **docs/architecture/troubleshooting-guide.md** - Common issues and solutions
|
|
552
|
+
21. **docs/architecture/changelog-conventions.md** - Change management practices
|
|
553
|
+
22. **docs/architecture/code-review-checklist.md** - Review standards and practices
|
|
554
|
+
|
|
555
|
+
Present each document section by section, using the advanced elicitation task after each major section.]]
|
|
556
|
+
|
|
557
|
+
### 3. Document Structure Template
|
|
558
|
+
|
|
559
|
+
[[LLM: Use this standardized structure for each documentation file, adapting content as needed:
|
|
560
|
+
|
|
561
|
+
```markdown
|
|
562
|
+
# {{Document Title}}
|
|
563
|
+
|
|
564
|
+
## Overview
|
|
565
|
+
|
|
566
|
+
{{Brief description of what this document covers and why it's important for AI agents}}
|
|
567
|
+
|
|
568
|
+
## Quick Reference
|
|
569
|
+
|
|
570
|
+
{{Key points, commands, or patterns that agents need most frequently}}
|
|
571
|
+
|
|
572
|
+
## Detailed Information
|
|
573
|
+
|
|
574
|
+
{{Comprehensive information organized into logical sections}}
|
|
575
|
+
|
|
576
|
+
## Examples
|
|
577
|
+
|
|
578
|
+
{{Concrete examples showing proper usage or implementation}}
|
|
579
|
+
|
|
580
|
+
## Common Patterns
|
|
581
|
+
|
|
582
|
+
{{Recurring patterns agents should recognize and follow}}
|
|
583
|
+
|
|
584
|
+
## Things to Avoid
|
|
585
|
+
|
|
586
|
+
{{Anti-patterns, deprecated approaches, or common mistakes}}
|
|
587
|
+
|
|
588
|
+
## Related Resources
|
|
589
|
+
|
|
590
|
+
{{Links to other relevant documentation or external resources}}
|
|
591
|
+
```
|
|
592
|
+
|
|
593
|
+
Each document should be:
|
|
594
|
+
|
|
595
|
+
- **Concrete and actionable** - Focus on what agents need to do, not just concepts
|
|
596
|
+
- **Pattern-focused** - Highlight recurring patterns agents can recognize and replicate
|
|
597
|
+
- **Example-rich** - Include specific code examples and real file references
|
|
598
|
+
- **Context-aware** - Reference actual project files, folders, and conventions
|
|
599
|
+
- **Assumption-free** - Don't assume agents know project history or implicit knowledge
|
|
600
|
+
]]
|
|
601
|
+
|
|
602
|
+
### 4. Content Guidelines for Each Document Type
|
|
603
|
+
|
|
604
|
+
#### Core Architecture Documents
|
|
605
|
+
|
|
606
|
+
##### docs/architecture/index.md
|
|
607
|
+
|
|
608
|
+
[[LLM: Create a comprehensive index of all architecture documentation:
|
|
609
|
+
|
|
610
|
+
- List all architecture documents with brief descriptions
|
|
611
|
+
- Group documents by category (backend, frontend, shared)
|
|
612
|
+
- Include quick links to key sections
|
|
613
|
+
- Provide reading order recommendations for different use cases]]
|
|
614
|
+
|
|
615
|
+
##### docs/architecture/unified-project-structure.md
|
|
616
|
+
|
|
617
|
+
[[LLM: Document the complete project structure:
|
|
618
|
+
|
|
619
|
+
- Root-level directory structure with explanations
|
|
620
|
+
- Where each type of code belongs (backend, frontend, tests, etc.)
|
|
621
|
+
- File naming conventions and patterns
|
|
622
|
+
- Module/package organization
|
|
623
|
+
- Generated vs. source file locations
|
|
624
|
+
- Build output locations]]
|
|
625
|
+
|
|
626
|
+
##### docs/architecture/coding-standards.md
|
|
627
|
+
|
|
628
|
+
[[LLM: Capture project-wide coding conventions:
|
|
629
|
+
|
|
630
|
+
- Language-specific style guidelines
|
|
631
|
+
- Naming conventions (variables, functions, classes, files)
|
|
632
|
+
- Code organization within files
|
|
633
|
+
- Import/export patterns
|
|
634
|
+
- Comment and documentation standards
|
|
635
|
+
- Linting and formatting tool configurations
|
|
636
|
+
- Git commit message conventions]]
|
|
637
|
+
|
|
638
|
+
##### docs/architecture/tech-stack.md
|
|
639
|
+
|
|
640
|
+
[[LLM: Document all technologies and versions:
|
|
641
|
+
|
|
642
|
+
- Primary languages and versions
|
|
643
|
+
- Frameworks and major libraries with versions
|
|
644
|
+
- Development tools and their versions
|
|
645
|
+
- Database systems and versions
|
|
646
|
+
- External services and APIs used
|
|
647
|
+
- Browser/runtime requirements]]
|
|
648
|
+
|
|
649
|
+
##### docs/architecture/testing-strategy.md
|
|
650
|
+
|
|
651
|
+
[[LLM: Define testing approaches and requirements:
|
|
652
|
+
|
|
653
|
+
- Test file locations and naming conventions
|
|
654
|
+
- Unit testing patterns and frameworks
|
|
655
|
+
- Integration testing approaches
|
|
656
|
+
- E2E testing setup (if applicable)
|
|
657
|
+
- Test coverage requirements
|
|
658
|
+
- Mocking strategies
|
|
659
|
+
- Test data management]]
|
|
660
|
+
|
|
661
|
+
#### Backend Architecture Documents
|
|
662
|
+
|
|
663
|
+
##### docs/architecture/backend-architecture.md
|
|
664
|
+
|
|
665
|
+
[[LLM: Document backend service structure:
|
|
666
|
+
|
|
667
|
+
- Service layer organization
|
|
668
|
+
- Controller/route patterns
|
|
669
|
+
- Middleware architecture
|
|
670
|
+
- Authentication/authorization patterns
|
|
671
|
+
- Request/response flow
|
|
672
|
+
- Background job processing
|
|
673
|
+
- Service communication patterns]]
|
|
674
|
+
|
|
675
|
+
##### docs/architecture/rest-api-spec.md
|
|
676
|
+
|
|
677
|
+
[[LLM: Specify all API endpoints:
|
|
678
|
+
|
|
679
|
+
- Base URL and versioning strategy
|
|
680
|
+
- Authentication methods
|
|
681
|
+
- Common headers and parameters
|
|
682
|
+
- Each endpoint with:
|
|
683
|
+
- HTTP method and path
|
|
684
|
+
- Request parameters/body
|
|
685
|
+
- Response format and status codes
|
|
686
|
+
- Error responses
|
|
687
|
+
- Rate limiting and quotas]]
|
|
688
|
+
|
|
689
|
+
##### docs/architecture/data-models.md
|
|
690
|
+
|
|
691
|
+
[[LLM: Define data structures and validation:
|
|
692
|
+
|
|
693
|
+
- Core business entities
|
|
694
|
+
- Data validation rules
|
|
695
|
+
- Relationships between entities
|
|
696
|
+
- Computed fields and derivations
|
|
697
|
+
- Data transformation patterns
|
|
698
|
+
- Serialization formats]]
|
|
699
|
+
|
|
700
|
+
##### docs/architecture/database-schema.md
|
|
701
|
+
|
|
702
|
+
[[LLM: Document database design:
|
|
703
|
+
|
|
704
|
+
- Database type and version
|
|
705
|
+
- Table/collection structures
|
|
706
|
+
- Indexes and constraints
|
|
707
|
+
- Relationships and foreign keys
|
|
708
|
+
- Migration patterns
|
|
709
|
+
- Seed data requirements
|
|
710
|
+
- Backup and recovery procedures]]
|
|
711
|
+
|
|
712
|
+
##### docs/architecture/external-apis.md
|
|
713
|
+
|
|
714
|
+
[[LLM: Document third-party integrations:
|
|
715
|
+
|
|
716
|
+
- List of external services used
|
|
717
|
+
- Authentication methods for each
|
|
718
|
+
- API endpoints and usage patterns
|
|
719
|
+
- Rate limits and quotas
|
|
720
|
+
- Error handling strategies
|
|
721
|
+
- Webhook configurations
|
|
722
|
+
- Data synchronization patterns]]
|
|
723
|
+
|
|
724
|
+
#### Frontend Architecture Documents
|
|
725
|
+
|
|
726
|
+
##### docs/architecture/frontend-architecture.md
|
|
727
|
+
|
|
728
|
+
[[LLM: Document frontend application structure:
|
|
729
|
+
|
|
730
|
+
- Component hierarchy and organization
|
|
731
|
+
- State management patterns
|
|
732
|
+
- Routing architecture
|
|
733
|
+
- Data fetching patterns
|
|
734
|
+
- Authentication flow
|
|
735
|
+
- Error boundary strategies
|
|
736
|
+
- Performance optimization patterns]]
|
|
737
|
+
|
|
738
|
+
##### docs/architecture/components.md
|
|
739
|
+
|
|
740
|
+
[[LLM: Specify UI components:
|
|
741
|
+
|
|
742
|
+
- Component library/design system used
|
|
743
|
+
- Custom component specifications
|
|
744
|
+
- Props and state for each component
|
|
745
|
+
- Component composition patterns
|
|
746
|
+
- Styling approaches
|
|
747
|
+
- Accessibility requirements
|
|
748
|
+
- Component testing patterns]]
|
|
749
|
+
|
|
750
|
+
##### docs/architecture/core-workflows.md
|
|
751
|
+
|
|
752
|
+
[[LLM: Document user interaction flows:
|
|
753
|
+
|
|
754
|
+
- Major user journeys
|
|
755
|
+
- Screen flow diagrams
|
|
756
|
+
- Form handling patterns
|
|
757
|
+
- Navigation patterns
|
|
758
|
+
- Data flow through workflows
|
|
759
|
+
- Error states and recovery
|
|
760
|
+
- Loading and transition states]]
|
|
761
|
+
|
|
762
|
+
##### docs/architecture/ui-ux-spec.md
|
|
763
|
+
|
|
764
|
+
[[LLM: Define UI/UX guidelines:
|
|
765
|
+
|
|
766
|
+
- Design system specifications
|
|
767
|
+
- Color palette and typography
|
|
768
|
+
- Spacing and layout grids
|
|
769
|
+
- Responsive breakpoints
|
|
770
|
+
- Animation and transition guidelines
|
|
771
|
+
- Accessibility standards
|
|
772
|
+
- Browser compatibility requirements]]
|
|
773
|
+
|
|
774
|
+
### 5. Adaptive Content Strategy
|
|
775
|
+
|
|
776
|
+
[[LLM: Adapt your documentation approach based on project characteristics:
|
|
777
|
+
|
|
778
|
+
**For Web Applications:**
|
|
779
|
+
|
|
780
|
+
- Focus on component patterns, routing, state management
|
|
781
|
+
- Include build processes, asset handling, and deployment
|
|
782
|
+
- Cover API integration patterns and data fetching
|
|
783
|
+
|
|
784
|
+
**For Backend Services:**
|
|
785
|
+
|
|
786
|
+
- Emphasize service architecture, data models, and API design
|
|
787
|
+
- Include database interaction patterns and migration strategies
|
|
788
|
+
- Cover authentication, authorization, and security patterns
|
|
789
|
+
|
|
790
|
+
**For CLI Tools:**
|
|
791
|
+
|
|
792
|
+
- Focus on command structure, argument parsing, and output formatting
|
|
793
|
+
- Include plugin/extension patterns if applicable
|
|
794
|
+
- Cover configuration file handling and user interaction patterns
|
|
795
|
+
|
|
796
|
+
**For Libraries/Frameworks:**
|
|
797
|
+
|
|
798
|
+
- Emphasize public API design and usage patterns
|
|
799
|
+
- Include extension points and customization approaches
|
|
800
|
+
- Cover versioning, compatibility, and migration strategies
|
|
801
|
+
|
|
802
|
+
**For Mobile Applications:**
|
|
803
|
+
|
|
804
|
+
- Focus on platform-specific patterns and navigation
|
|
805
|
+
- Include state management and data persistence approaches
|
|
806
|
+
- Cover platform integration and native feature usage
|
|
807
|
+
|
|
808
|
+
**For Data Science/ML Projects:**
|
|
809
|
+
|
|
810
|
+
- Emphasize data pipeline patterns and model organization
|
|
811
|
+
- Include experiment tracking and reproducibility approaches
|
|
812
|
+
- Cover data validation and model deployment patterns
|
|
813
|
+
]]
|
|
814
|
+
|
|
815
|
+
### 6. Quality Assurance
|
|
816
|
+
|
|
817
|
+
[[LLM: Before completing each document:
|
|
818
|
+
|
|
819
|
+
1. **Accuracy Check**: Verify all file paths, commands, and code examples work
|
|
820
|
+
2. **Completeness Review**: Ensure the document covers the most important patterns an agent would encounter
|
|
821
|
+
3. **Clarity Assessment**: Check that explanations are clear and actionable
|
|
822
|
+
4. **Consistency Verification**: Ensure terminology and patterns align across all documents
|
|
823
|
+
5. **Agent Perspective**: Review from the viewpoint of an AI agent that needs to contribute to this project
|
|
824
|
+
|
|
825
|
+
Ask the user to review each completed document and use the advanced elicitation task to refine based on their feedback.]]
|
|
826
|
+
|
|
827
|
+
### 7. Final Integration
|
|
828
|
+
|
|
829
|
+
[[LLM: After all documents are completed:
|
|
830
|
+
|
|
831
|
+
1. Ensure all documents are created in the proper BMAD-expected locations:
|
|
832
|
+
|
|
833
|
+
- Core docs in `docs/` (index.md, prd.md)
|
|
834
|
+
- Architecture shards in `docs/architecture/` subdirectory
|
|
835
|
+
- Create the `docs/architecture/` directory if it doesn't exist
|
|
836
|
+
|
|
837
|
+
2. Create/update the master index documents:
|
|
838
|
+
|
|
839
|
+
- Update `docs/index.md` to reference all documentation
|
|
840
|
+
- Create `docs/architecture/index.md` listing all architecture shards
|
|
841
|
+
|
|
842
|
+
3. Verify document cross-references:
|
|
843
|
+
|
|
844
|
+
- Ensure all documents link to related documentation
|
|
845
|
+
- Check that file paths match the actual project structure
|
|
846
|
+
- Validate that examples reference real files in the project
|
|
847
|
+
|
|
848
|
+
4. Provide maintenance guidance:
|
|
849
|
+
|
|
850
|
+
- Document update triggers (when to update each doc)
|
|
851
|
+
- Create a simple checklist for keeping docs current
|
|
852
|
+
- Suggest automated validation approaches
|
|
853
|
+
|
|
854
|
+
5. Summary report including:
|
|
855
|
+
- List of all documents created with their paths
|
|
856
|
+
- Any gaps or areas needing human review
|
|
857
|
+
- Recommendations for project-specific additions
|
|
858
|
+
- Next steps for maintaining documentation accuracy
|
|
859
|
+
|
|
860
|
+
Present a summary of what was created and ask if any additional documentation would be helpful for AI agents working on this specific project.]]
|
|
861
|
+
|
|
862
|
+
## Success Criteria
|
|
863
|
+
|
|
864
|
+
- Documentation enables AI agents to understand project context without additional explanation
|
|
865
|
+
- All major architectural patterns and coding conventions are captured
|
|
866
|
+
- Examples reference actual project files and demonstrate real usage
|
|
867
|
+
- Documentation is structured consistently and easy to navigate
|
|
868
|
+
- Content is actionable and focuses on what agents need to do, not just understand
|
|
869
|
+
|
|
870
|
+
## Notes
|
|
871
|
+
|
|
872
|
+
- This task is designed to work with any project type, language, or framework
|
|
873
|
+
- The documentation should reflect the project as it actually is, not as it should be
|
|
874
|
+
- Focus on patterns that agents can recognize and replicate consistently
|
|
875
|
+
- Include both positive examples (what to do) and negative examples (what to avoid)
|
|
876
|
+
==================== END: tasks#document-project ====================
|
|
877
|
+
|
|
878
|
+
==================== START: tasks#execute-checklist ====================
|
|
879
|
+
# Checklist Validation Task
|
|
880
|
+
|
|
881
|
+
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
|
882
|
+
|
|
883
|
+
## Context
|
|
884
|
+
|
|
885
|
+
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
|
886
|
+
|
|
887
|
+
## Available Checklists
|
|
888
|
+
|
|
889
|
+
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
|
890
|
+
|
|
891
|
+
## Instructions
|
|
892
|
+
|
|
893
|
+
1. **Initial Assessment**
|
|
894
|
+
|
|
895
|
+
- If user or the task being run provides a checklist name:
|
|
896
|
+
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
|
897
|
+
- If multiple matches found, ask user to clarify
|
|
898
|
+
- Load the appropriate checklist from bmad-core/checklists/
|
|
899
|
+
- If no checklist specified:
|
|
900
|
+
- Ask the user which checklist they want to use
|
|
901
|
+
- Present the available options from the files in the checklists folder
|
|
902
|
+
- Confirm if they want to work through the checklist:
|
|
903
|
+
- Section by section (interactive mode - very time consuming)
|
|
904
|
+
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
|
905
|
+
|
|
906
|
+
2. **Document and Artifact Gathering**
|
|
907
|
+
|
|
908
|
+
- Each checklist will specify its required documents/artifacts at the beginning
|
|
909
|
+
- 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.
|
|
910
|
+
|
|
911
|
+
3. **Checklist Processing**
|
|
912
|
+
|
|
913
|
+
If in interactive mode:
|
|
914
|
+
|
|
915
|
+
- Work through each section of the checklist one at a time
|
|
916
|
+
- For each section:
|
|
917
|
+
- Review all items in the section following instructions for that section embedded in the checklist
|
|
918
|
+
- Check each item against the relevant documentation or artifacts as appropriate
|
|
919
|
+
- Present summary of findings for that section, highlighting warnings, errors and non applicable items (rationale for non-applicability).
|
|
920
|
+
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
|
921
|
+
|
|
922
|
+
If in YOLO mode:
|
|
923
|
+
|
|
924
|
+
- Process all sections at once
|
|
925
|
+
- Create a comprehensive report of all findings
|
|
926
|
+
- Present the complete analysis to the user
|
|
927
|
+
|
|
928
|
+
4. **Validation Approach**
|
|
929
|
+
|
|
930
|
+
For each checklist item:
|
|
931
|
+
|
|
932
|
+
- Read and understand the requirement
|
|
933
|
+
- Look for evidence in the documentation that satisfies the requirement
|
|
934
|
+
- Consider both explicit mentions and implicit coverage
|
|
935
|
+
- Aside from this, follow all checklist llm instructions
|
|
936
|
+
- Mark items as:
|
|
937
|
+
- ✅ PASS: Requirement clearly met
|
|
938
|
+
- ❌ FAIL: Requirement not met or insufficient coverage
|
|
939
|
+
- ⚠️ PARTIAL: Some aspects covered but needs improvement
|
|
940
|
+
- N/A: Not applicable to this case
|
|
941
|
+
|
|
942
|
+
5. **Section Analysis**
|
|
943
|
+
|
|
944
|
+
For each section:
|
|
945
|
+
|
|
946
|
+
- think step by step to calculate pass rate
|
|
947
|
+
- Identify common themes in failed items
|
|
948
|
+
- Provide specific recommendations for improvement
|
|
949
|
+
- In interactive mode, discuss findings with user
|
|
950
|
+
- Document any user decisions or explanations
|
|
951
|
+
|
|
952
|
+
6. **Final Report**
|
|
953
|
+
|
|
954
|
+
Prepare a summary that includes:
|
|
955
|
+
|
|
956
|
+
- Overall checklist completion status
|
|
957
|
+
- Pass rates by section
|
|
958
|
+
- List of failed items with context
|
|
959
|
+
- Specific recommendations for improvement
|
|
960
|
+
- Any sections or items marked as N/A with justification
|
|
961
|
+
|
|
962
|
+
## Checklist Execution Methodology
|
|
963
|
+
|
|
964
|
+
Each checklist now contains embedded LLM prompts and instructions that will:
|
|
965
|
+
|
|
966
|
+
1. **Guide thorough thinking** - Prompts ensure deep analysis of each section
|
|
967
|
+
2. **Request specific artifacts** - Clear instructions on what documents/access is needed
|
|
968
|
+
3. **Provide contextual guidance** - Section-specific prompts for better validation
|
|
969
|
+
4. **Generate comprehensive reports** - Final summary with detailed findings
|
|
970
|
+
|
|
971
|
+
The LLM will:
|
|
972
|
+
|
|
973
|
+
- Execute the complete checklist validation
|
|
974
|
+
- Present a final report with pass/fail rates and key findings
|
|
975
|
+
- Offer to provide detailed analysis of any section, especially those with warnings or failures
|
|
976
|
+
==================== END: tasks#execute-checklist ====================
|
|
977
|
+
|
|
591
978
|
==================== START: templates#architecture-tmpl ====================
|
|
592
979
|
# {{Project Name}} Architecture Document
|
|
593
980
|
|
|
@@ -727,7 +1114,7 @@ Common patterns to consider:
|
|
|
727
1114
|
|
|
728
1115
|
[[LLM: This is the DEFINITIVE technology selection section. Work with the user to make specific choices:
|
|
729
1116
|
|
|
730
|
-
1. Review PRD technical assumptions and any preferences from `data#technical-preferences`
|
|
1117
|
+
1. Review PRD technical assumptions and any preferences from `data#technical-preferences` or an attached `technical-preferences`
|
|
731
1118
|
2. For each category, present 2-3 viable options with pros/cons
|
|
732
1119
|
3. Make a clear recommendation based on project needs
|
|
733
1120
|
4. Get explicit user approval for each selection
|
|
@@ -935,15 +1322,18 @@ Use YAML format for better readability. If no REST API, skip this section.]]
|
|
|
935
1322
|
```yaml
|
|
936
1323
|
openapi: 3.0.0
|
|
937
1324
|
info:
|
|
938
|
-
title:
|
|
939
|
-
|
|
940
|
-
|
|
941
|
-
|
|
1325
|
+
title:
|
|
1326
|
+
'[object Object]': null
|
|
1327
|
+
version:
|
|
1328
|
+
'[object Object]': null
|
|
1329
|
+
description:
|
|
1330
|
+
'[object Object]': null
|
|
942
1331
|
servers:
|
|
943
|
-
- url:
|
|
944
|
-
|
|
945
|
-
|
|
946
|
-
|
|
1332
|
+
- url:
|
|
1333
|
+
'[object Object]': null
|
|
1334
|
+
description:
|
|
1335
|
+
'[object Object]': null
|
|
1336
|
+
```text
|
|
947
1337
|
|
|
948
1338
|
^^/CONDITION: has_rest_api^^
|
|
949
1339
|
|
|
@@ -1054,7 +1444,7 @@ Get user input on deployment preferences and CI/CD tool choices.]]
|
|
|
1054
1444
|
|
|
1055
1445
|
### Environment Promotion Flow
|
|
1056
1446
|
|
|
1057
|
-
```
|
|
1447
|
+
```text
|
|
1058
1448
|
{{promotion_flow_diagram}}
|
|
1059
1449
|
```
|
|
1060
1450
|
|
|
@@ -1650,9 +2040,9 @@ Document the choice and key services that will be used.]]
|
|
|
1650
2040
|
|
|
1651
2041
|
Use appropriate diagram type for clarity.]]
|
|
1652
2042
|
|
|
1653
|
-
|
|
2043
|
+
````mermaid
|
|
1654
2044
|
{{architecture_diagram}}
|
|
1655
|
-
```
|
|
2045
|
+
```text
|
|
1656
2046
|
|
|
1657
2047
|
### Architectural Patterns
|
|
1658
2048
|
|
|
@@ -1763,7 +2153,7 @@ After presenting all data models, apply `tasks#advanced-elicitation` protocol]]
|
|
|
1763
2153
|
model_interface;
|
|
1764
2154
|
}
|
|
1765
2155
|
}
|
|
1766
|
-
|
|
2156
|
+
````
|
|
1767
2157
|
|
|
1768
2158
|
**Relationships:**
|
|
1769
2159
|
|
|
@@ -1787,7 +2177,7 @@ After presenting all data models, apply `tasks#advanced-elicitation` protocol]]
|
|
|
1787
2177
|
|
|
1788
2178
|
**TypeScript Interface:**
|
|
1789
2179
|
|
|
1790
|
-
|
|
2180
|
+
````typescript
|
|
1791
2181
|
interface User {
|
|
1792
2182
|
id: string;
|
|
1793
2183
|
email: string;
|
|
@@ -1803,7 +2193,7 @@ interface UserProfile {
|
|
|
1803
2193
|
bio?: string;
|
|
1804
2194
|
preferences: Record<string, any>;
|
|
1805
2195
|
}
|
|
1806
|
-
```
|
|
2196
|
+
```text
|
|
1807
2197
|
|
|
1808
2198
|
**Relationships:**
|
|
1809
2199
|
|
|
@@ -1827,27 +2217,30 @@ Use appropriate format for the chosen API style. If no API (e.g., static site),
|
|
|
1827
2217
|
|
|
1828
2218
|
^^CONDITION: has_rest_api^^
|
|
1829
2219
|
|
|
1830
|
-
```
|
|
2220
|
+
```yml
|
|
1831
2221
|
openapi: 3.0.0
|
|
1832
2222
|
info:
|
|
1833
|
-
title:
|
|
1834
|
-
|
|
1835
|
-
|
|
1836
|
-
|
|
2223
|
+
title:
|
|
2224
|
+
'[object Object]': null
|
|
2225
|
+
version:
|
|
2226
|
+
'[object Object]': null
|
|
2227
|
+
description:
|
|
2228
|
+
'[object Object]': null
|
|
1837
2229
|
servers:
|
|
1838
|
-
- url:
|
|
1839
|
-
|
|
1840
|
-
|
|
1841
|
-
|
|
2230
|
+
- url:
|
|
2231
|
+
'[object Object]': null
|
|
2232
|
+
description:
|
|
2233
|
+
'[object Object]': null
|
|
2234
|
+
````
|
|
1842
2235
|
|
|
1843
2236
|
^^/CONDITION: has_rest_api^^
|
|
1844
2237
|
|
|
1845
2238
|
^^CONDITION: has_graphql_api^^
|
|
1846
2239
|
|
|
1847
|
-
|
|
2240
|
+
````graphql
|
|
1848
2241
|
# GraphQL Schema
|
|
1849
2242
|
{{graphql_schema}}
|
|
1850
|
-
```
|
|
2243
|
+
```text
|
|
1851
2244
|
|
|
1852
2245
|
^^/CONDITION: has_graphql_api^^
|
|
1853
2246
|
|
|
@@ -1860,7 +2253,7 @@ servers:
|
|
|
1860
2253
|
trpc_routers;
|
|
1861
2254
|
}
|
|
1862
2255
|
}
|
|
1863
|
-
|
|
2256
|
+
````
|
|
1864
2257
|
|
|
1865
2258
|
^^/CONDITION: has_trpc_api^^
|
|
1866
2259
|
|
|
@@ -2005,19 +2398,19 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2005
2398
|
|
|
2006
2399
|
**Component Organization:**
|
|
2007
2400
|
|
|
2008
|
-
|
|
2401
|
+
`````text
|
|
2009
2402
|
{{component_structure}}
|
|
2010
|
-
```
|
|
2403
|
+
```text
|
|
2011
2404
|
|
|
2012
2405
|
**Component Template:**
|
|
2013
2406
|
|
|
2014
|
-
|
|
2407
|
+
````typescript
|
|
2015
2408
|
{
|
|
2016
2409
|
{
|
|
2017
2410
|
component_template;
|
|
2018
2411
|
}
|
|
2019
2412
|
}
|
|
2020
|
-
```
|
|
2413
|
+
```text
|
|
2021
2414
|
|
|
2022
2415
|
### State Management Architecture
|
|
2023
2416
|
|
|
@@ -2031,7 +2424,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2031
2424
|
state_structure;
|
|
2032
2425
|
}
|
|
2033
2426
|
}
|
|
2034
|
-
|
|
2427
|
+
`````
|
|
2035
2428
|
|
|
2036
2429
|
**State Management Patterns:**
|
|
2037
2430
|
|
|
@@ -2044,19 +2437,19 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2044
2437
|
|
|
2045
2438
|
**Route Organization:**
|
|
2046
2439
|
|
|
2047
|
-
```
|
|
2440
|
+
```text
|
|
2048
2441
|
{{route_structure}}
|
|
2049
|
-
```
|
|
2442
|
+
```text
|
|
2050
2443
|
|
|
2051
2444
|
**Protected Route Pattern:**
|
|
2052
2445
|
|
|
2053
|
-
|
|
2446
|
+
````typescript
|
|
2054
2447
|
{
|
|
2055
2448
|
{
|
|
2056
2449
|
protected_route_example;
|
|
2057
2450
|
}
|
|
2058
2451
|
}
|
|
2059
|
-
```
|
|
2452
|
+
```text
|
|
2060
2453
|
|
|
2061
2454
|
### Frontend Services Layer
|
|
2062
2455
|
|
|
@@ -2070,17 +2463,17 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2070
2463
|
api_client_setup;
|
|
2071
2464
|
}
|
|
2072
2465
|
}
|
|
2073
|
-
|
|
2466
|
+
````
|
|
2074
2467
|
|
|
2075
2468
|
**Service Example:**
|
|
2076
2469
|
|
|
2077
|
-
|
|
2470
|
+
````typescript
|
|
2078
2471
|
{
|
|
2079
2472
|
{
|
|
2080
2473
|
service_example;
|
|
2081
2474
|
}
|
|
2082
2475
|
}
|
|
2083
|
-
```
|
|
2476
|
+
```text
|
|
2084
2477
|
|
|
2085
2478
|
## Backend Architecture
|
|
2086
2479
|
|
|
@@ -2095,9 +2488,11 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2095
2488
|
^^CONDITION: serverless^^
|
|
2096
2489
|
**Function Organization:**
|
|
2097
2490
|
|
|
2098
|
-
|
|
2491
|
+
````
|
|
2492
|
+
|
|
2099
2493
|
{{function_structure}}
|
|
2100
|
-
|
|
2494
|
+
|
|
2495
|
+
````text
|
|
2101
2496
|
|
|
2102
2497
|
**Function Template:**
|
|
2103
2498
|
|
|
@@ -2107,26 +2502,26 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2107
2502
|
function_template;
|
|
2108
2503
|
}
|
|
2109
2504
|
}
|
|
2110
|
-
|
|
2505
|
+
````
|
|
2111
2506
|
|
|
2112
2507
|
^^/CONDITION: serverless^^
|
|
2113
2508
|
|
|
2114
2509
|
^^CONDITION: traditional_server^^
|
|
2115
2510
|
**Controller/Route Organization:**
|
|
2116
2511
|
|
|
2117
|
-
|
|
2512
|
+
`````text
|
|
2118
2513
|
{{controller_structure}}
|
|
2119
|
-
```
|
|
2514
|
+
```text
|
|
2120
2515
|
|
|
2121
2516
|
**Controller Template:**
|
|
2122
2517
|
|
|
2123
|
-
|
|
2518
|
+
````typescript
|
|
2124
2519
|
{
|
|
2125
2520
|
{
|
|
2126
2521
|
controller_template;
|
|
2127
2522
|
}
|
|
2128
2523
|
}
|
|
2129
|
-
```
|
|
2524
|
+
```text
|
|
2130
2525
|
|
|
2131
2526
|
^^/CONDITION: traditional_server^^
|
|
2132
2527
|
|
|
@@ -2138,17 +2533,17 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2138
2533
|
|
|
2139
2534
|
```sql
|
|
2140
2535
|
{{database_schema}}
|
|
2141
|
-
|
|
2536
|
+
`````
|
|
2142
2537
|
|
|
2143
2538
|
**Data Access Layer:**
|
|
2144
2539
|
|
|
2145
|
-
|
|
2540
|
+
````typescript
|
|
2146
2541
|
{
|
|
2147
2542
|
{
|
|
2148
2543
|
repository_pattern;
|
|
2149
2544
|
}
|
|
2150
2545
|
}
|
|
2151
|
-
```
|
|
2546
|
+
```text
|
|
2152
2547
|
|
|
2153
2548
|
### Authentication and Authorization
|
|
2154
2549
|
|
|
@@ -2158,17 +2553,17 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2158
2553
|
|
|
2159
2554
|
```mermaid
|
|
2160
2555
|
{{auth_flow_diagram}}
|
|
2161
|
-
|
|
2556
|
+
````
|
|
2162
2557
|
|
|
2163
2558
|
**Middleware/Guards:**
|
|
2164
2559
|
|
|
2165
|
-
|
|
2560
|
+
````typescript
|
|
2166
2561
|
{
|
|
2167
2562
|
{
|
|
2168
2563
|
auth_middleware;
|
|
2169
2564
|
}
|
|
2170
2565
|
}
|
|
2171
|
-
```
|
|
2566
|
+
```text
|
|
2172
2567
|
|
|
2173
2568
|
## Unified Project Structure
|
|
2174
2569
|
|
|
@@ -2228,7 +2623,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2228
2623
|
├── package.json # Root package.json
|
|
2229
2624
|
├── {{monorepo_config}} # Monorepo configuration
|
|
2230
2625
|
└── README.md
|
|
2231
|
-
|
|
2626
|
+
````
|
|
2232
2627
|
|
|
2233
2628
|
@{example: vercel_structure}
|
|
2234
2629
|
apps/
|
|
@@ -2250,19 +2645,19 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2250
2645
|
|
|
2251
2646
|
**Prerequisites:**
|
|
2252
2647
|
|
|
2253
|
-
|
|
2648
|
+
````bash
|
|
2254
2649
|
{{prerequisites_commands}}
|
|
2255
|
-
```
|
|
2650
|
+
```text
|
|
2256
2651
|
|
|
2257
2652
|
**Initial Setup:**
|
|
2258
2653
|
|
|
2259
2654
|
```bash
|
|
2260
2655
|
{{setup_commands}}
|
|
2261
|
-
|
|
2656
|
+
````
|
|
2262
2657
|
|
|
2263
2658
|
**Development Commands:**
|
|
2264
2659
|
|
|
2265
|
-
|
|
2660
|
+
````bash
|
|
2266
2661
|
# Start all services
|
|
2267
2662
|
{{start_all_command}}
|
|
2268
2663
|
|
|
@@ -2274,7 +2669,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2274
2669
|
|
|
2275
2670
|
# Run tests
|
|
2276
2671
|
{{test_commands}}
|
|
2277
|
-
```
|
|
2672
|
+
```text
|
|
2278
2673
|
|
|
2279
2674
|
### Environment Configuration
|
|
2280
2675
|
|
|
@@ -2289,7 +2684,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2289
2684
|
|
|
2290
2685
|
# Shared
|
|
2291
2686
|
{{shared_env_vars}}
|
|
2292
|
-
|
|
2687
|
+
````
|
|
2293
2688
|
|
|
2294
2689
|
## Deployment Architecture
|
|
2295
2690
|
|
|
@@ -2312,9 +2707,9 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2312
2707
|
|
|
2313
2708
|
### CI/CD Pipeline
|
|
2314
2709
|
|
|
2315
|
-
|
|
2316
|
-
|
|
2317
|
-
```
|
|
2710
|
+
````yaml
|
|
2711
|
+
'[object Object]': null
|
|
2712
|
+
```text
|
|
2318
2713
|
|
|
2319
2714
|
### Environments
|
|
2320
2715
|
|
|
@@ -2372,33 +2767,42 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2372
2767
|
|
|
2373
2768
|
### Testing Pyramid
|
|
2374
2769
|
|
|
2375
|
-
|
|
2770
|
+
````
|
|
2771
|
+
|
|
2376
2772
|
E2E Tests
|
|
2377
2773
|
/ \
|
|
2378
2774
|
Integration Tests
|
|
2379
|
-
|
|
2380
|
-
|
|
2381
|
-
|
|
2775
|
+
|
|
2776
|
+
/ \
|
|
2777
|
+
Frontend Unit Backend Unit
|
|
2778
|
+
|
|
2779
|
+
```text
|
|
2382
2780
|
|
|
2383
2781
|
### Test Organization
|
|
2384
2782
|
|
|
2385
2783
|
**Frontend Tests:**
|
|
2386
2784
|
|
|
2387
2785
|
```
|
|
2786
|
+
|
|
2388
2787
|
{{frontend_test_structure}}
|
|
2389
|
-
|
|
2788
|
+
|
|
2789
|
+
````text
|
|
2390
2790
|
|
|
2391
2791
|
**Backend Tests:**
|
|
2392
2792
|
|
|
2393
|
-
```
|
|
2793
|
+
```text
|
|
2794
|
+
|
|
2394
2795
|
{{backend_test_structure}}
|
|
2395
|
-
|
|
2796
|
+
|
|
2797
|
+
```text
|
|
2396
2798
|
|
|
2397
2799
|
**E2E Tests:**
|
|
2398
2800
|
|
|
2399
|
-
|
|
2801
|
+
````
|
|
2802
|
+
|
|
2400
2803
|
{{e2e_test_structure}}
|
|
2401
|
-
|
|
2804
|
+
|
|
2805
|
+
````text
|
|
2402
2806
|
|
|
2403
2807
|
### Test Examples
|
|
2404
2808
|
|
|
@@ -2410,17 +2814,17 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2410
2814
|
frontend_test_example;
|
|
2411
2815
|
}
|
|
2412
2816
|
}
|
|
2413
|
-
|
|
2817
|
+
````
|
|
2414
2818
|
|
|
2415
2819
|
**Backend API Test:**
|
|
2416
2820
|
|
|
2417
|
-
|
|
2821
|
+
````typescript
|
|
2418
2822
|
{
|
|
2419
2823
|
{
|
|
2420
2824
|
backend_test_example;
|
|
2421
2825
|
}
|
|
2422
2826
|
}
|
|
2423
|
-
```
|
|
2827
|
+
```text
|
|
2424
2828
|
|
|
2425
2829
|
**E2E Test:**
|
|
2426
2830
|
|
|
@@ -2430,7 +2834,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2430
2834
|
e2e_test_example;
|
|
2431
2835
|
}
|
|
2432
2836
|
}
|
|
2433
|
-
|
|
2837
|
+
````
|
|
2434
2838
|
|
|
2435
2839
|
## Coding Standards
|
|
2436
2840
|
|
|
@@ -2471,9 +2875,9 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2471
2875
|
|
|
2472
2876
|
### Error Flow
|
|
2473
2877
|
|
|
2474
|
-
|
|
2878
|
+
````mermaid
|
|
2475
2879
|
{{error_flow_diagram}}
|
|
2476
|
-
```
|
|
2880
|
+
```text
|
|
2477
2881
|
|
|
2478
2882
|
### Error Response Format
|
|
2479
2883
|
|
|
@@ -2487,17 +2891,17 @@ interface ApiError {
|
|
|
2487
2891
|
requestId: string;
|
|
2488
2892
|
};
|
|
2489
2893
|
}
|
|
2490
|
-
|
|
2894
|
+
````
|
|
2491
2895
|
|
|
2492
2896
|
### Frontend Error Handling
|
|
2493
2897
|
|
|
2494
|
-
|
|
2898
|
+
````typescript
|
|
2495
2899
|
{
|
|
2496
2900
|
{
|
|
2497
2901
|
frontend_error_handler;
|
|
2498
2902
|
}
|
|
2499
2903
|
}
|
|
2500
|
-
```
|
|
2904
|
+
```text
|
|
2501
2905
|
|
|
2502
2906
|
### Backend Error Handling
|
|
2503
2907
|
|
|
@@ -2507,7 +2911,7 @@ interface ApiError {
|
|
|
2507
2911
|
backend_error_handler;
|
|
2508
2912
|
}
|
|
2509
2913
|
}
|
|
2510
|
-
|
|
2914
|
+
````
|
|
2511
2915
|
|
|
2512
2916
|
## Monitoring and Observability
|
|
2513
2917
|
|
|
@@ -2541,38 +2945,6 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
|
|
2541
2945
|
## Checklist Results Report
|
|
2542
2946
|
|
|
2543
2947
|
[[LLM: Before running the checklist, offer to output the full architecture document. Once user confirms, execute the `architect-checklist` and populate results here.]]
|
|
2544
|
-
|
|
2545
|
-
## Next Steps
|
|
2546
|
-
|
|
2547
|
-
[[LLM: Provide specific next steps for implementation.]]
|
|
2548
|
-
|
|
2549
|
-
### Implementation Order
|
|
2550
|
-
|
|
2551
|
-
1. **Environment Setup**
|
|
2552
|
-
|
|
2553
|
-
- Initialize monorepo structure
|
|
2554
|
-
- Configure development environment
|
|
2555
|
-
- Set up version control
|
|
2556
|
-
|
|
2557
|
-
2. **Foundation (Epic 1)**
|
|
2558
|
-
|
|
2559
|
-
- Implement authentication flow
|
|
2560
|
-
- Set up database schema
|
|
2561
|
-
- Create basic API structure
|
|
2562
|
-
- Implement core UI components
|
|
2563
|
-
|
|
2564
|
-
3. **Feature Development**
|
|
2565
|
-
- Follow story sequence from PRD
|
|
2566
|
-
- Maintain type safety across stack
|
|
2567
|
-
- Write tests as you go
|
|
2568
|
-
|
|
2569
|
-
### Developer Handoff Prompts
|
|
2570
|
-
|
|
2571
|
-
**For Scrum Master:**
|
|
2572
|
-
"Create stories for {{Project Name}} using the PRD at docs/prd.md and this fullstack architecture at docs/fullstack-architecture.md. Focus on Epic 1 implementation."
|
|
2573
|
-
|
|
2574
|
-
**For Developer:**
|
|
2575
|
-
"Implement Story 1.1 from docs/stories/epic1/story-1.1.md using the fullstack architecture at docs/fullstack-architecture.md. Follow the coding standards and use the defined tech stack."
|
|
2576
2948
|
==================== END: templates#fullstack-architecture-tmpl ====================
|
|
2577
2949
|
|
|
2578
2950
|
==================== START: templates#brownfield-architecture-tmpl ====================
|