bmad-method 5.0.0-beta.2 → 5.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.github/ISSUE_TEMPLATE/bug_report.md +3 -3
- package/.github/ISSUE_TEMPLATE/feature_request.md +3 -3
- package/.github/workflows/discord.yaml +11 -2
- package/.github/workflows/format-check.yaml +42 -0
- package/.github/workflows/manual-release.yaml +173 -0
- package/.husky/pre-commit +3 -0
- package/.vscode/settings.json +26 -1
- package/CHANGELOG.md +0 -11
- package/README.md +2 -0
- package/bmad-core/agent-teams/team-all.yaml +1 -1
- package/bmad-core/agents/bmad-orchestrator.md +1 -1
- package/bmad-core/agents/dev.md +4 -4
- package/bmad-core/data/bmad-kb.md +1 -1
- package/bmad-core/data/test-levels-framework.md +12 -12
- package/bmad-core/tasks/facilitate-brainstorming-session.md +1 -1
- package/bmad-core/tasks/nfr-assess.md +10 -10
- package/bmad-core/tasks/qa-gate.md +23 -23
- package/bmad-core/tasks/review-story.md +18 -18
- package/bmad-core/tasks/risk-profile.md +25 -25
- package/bmad-core/tasks/test-design.md +9 -9
- package/bmad-core/tasks/trace-requirements.md +21 -21
- package/bmad-core/templates/architecture-tmpl.yaml +49 -49
- package/bmad-core/templates/brainstorming-output-tmpl.yaml +5 -5
- package/bmad-core/templates/brownfield-architecture-tmpl.yaml +31 -31
- package/bmad-core/templates/brownfield-prd-tmpl.yaml +13 -13
- package/bmad-core/templates/competitor-analysis-tmpl.yaml +19 -6
- package/bmad-core/templates/front-end-architecture-tmpl.yaml +21 -9
- package/bmad-core/templates/front-end-spec-tmpl.yaml +24 -24
- package/bmad-core/templates/fullstack-architecture-tmpl.yaml +122 -104
- package/bmad-core/templates/market-research-tmpl.yaml +2 -2
- package/bmad-core/templates/prd-tmpl.yaml +9 -9
- package/bmad-core/templates/project-brief-tmpl.yaml +4 -4
- package/bmad-core/templates/qa-gate-tmpl.yaml +9 -9
- package/bmad-core/templates/story-tmpl.yaml +12 -12
- package/bmad-core/workflows/brownfield-fullstack.yaml +9 -9
- package/bmad-core/workflows/brownfield-service.yaml +1 -1
- package/bmad-core/workflows/brownfield-ui.yaml +1 -1
- package/bmad-core/workflows/greenfield-fullstack.yaml +1 -1
- package/bmad-core/workflows/greenfield-service.yaml +1 -1
- package/bmad-core/workflows/greenfield-ui.yaml +1 -1
- package/common/utils/bmad-doc-template.md +5 -5
- package/dist/agents/analyst.txt +28 -15
- package/dist/agents/architect.txt +220 -190
- package/dist/agents/bmad-master.txt +298 -255
- package/dist/agents/bmad-orchestrator.txt +1 -1
- package/dist/agents/pm.txt +20 -20
- package/dist/agents/po.txt +11 -11
- package/dist/agents/qa.txt +275 -618
- package/dist/agents/sm.txt +11 -11
- package/dist/agents/ux-expert.txt +23 -23
- package/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.txt +109 -109
- package/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt +75 -77
- package/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.txt +41 -41
- package/dist/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt +483 -474
- package/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-architect.txt +1 -1
- package/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt +149 -149
- package/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt +20 -20
- package/dist/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt +371 -358
- package/dist/expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.txt +25 -25
- package/dist/teams/team-all.txt +581 -881
- package/dist/teams/team-fullstack.txt +316 -273
- package/dist/teams/team-ide-minimal.txt +276 -619
- package/dist/teams/team-no-ui.txt +281 -238
- package/docs/versioning-and-releases.md +114 -44
- package/eslint.config.mjs +119 -0
- package/expansion-packs/Complete AI Agent System - Blank Templates & Google Cloud Setup/PART 1 - Google Cloud Vertex AI Setup Documentation/1.4 Deployment Configuration/1.4.2 - cloudbuild.yaml +26 -26
- package/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.md +4 -4
- package/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.md +1 -1
- package/expansion-packs/bmad-2d-phaser-game-dev/data/development-guidelines.md +26 -28
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-architecture-tmpl.yaml +50 -50
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-brief-tmpl.yaml +23 -23
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-design-doc-tmpl.yaml +24 -24
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-story-tmpl.yaml +42 -42
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/level-design-doc-tmpl.yaml +65 -65
- package/expansion-packs/bmad-2d-phaser-game-dev/workflows/game-dev-greenfield.yaml +5 -5
- package/expansion-packs/bmad-2d-phaser-game-dev/workflows/game-prototype.yaml +1 -1
- package/expansion-packs/bmad-2d-unity-game-dev/agents/game-developer.md +3 -3
- package/expansion-packs/bmad-2d-unity-game-dev/data/bmad-kb.md +1 -1
- package/expansion-packs/bmad-2d-unity-game-dev/templates/game-brief-tmpl.yaml +23 -23
- package/expansion-packs/bmad-2d-unity-game-dev/templates/game-design-doc-tmpl.yaml +63 -63
- package/expansion-packs/bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml +20 -20
- package/expansion-packs/bmad-2d-unity-game-dev/templates/level-design-doc-tmpl.yaml +65 -65
- package/expansion-packs/bmad-2d-unity-game-dev/workflows/game-dev-greenfield.yaml +5 -5
- package/expansion-packs/bmad-2d-unity-game-dev/workflows/game-prototype.yaml +1 -1
- package/expansion-packs/bmad-infrastructure-devops/templates/infrastructure-architecture-tmpl.yaml +20 -20
- package/expansion-packs/bmad-infrastructure-devops/templates/infrastructure-platform-from-arch-tmpl.yaml +7 -7
- package/package.json +62 -39
- package/prettier.config.mjs +32 -0
- package/release_notes.md +30 -0
- package/tools/bmad-npx-wrapper.js +10 -10
- package/tools/builders/web-builder.js +124 -130
- package/tools/bump-all-versions.js +42 -33
- package/tools/bump-expansion-version.js +23 -16
- package/tools/cli.js +10 -12
- package/tools/flattener/aggregate.js +10 -10
- package/tools/flattener/binary.js +44 -17
- package/tools/flattener/discovery.js +19 -18
- package/tools/flattener/files.js +6 -6
- package/tools/flattener/ignoreRules.js +125 -125
- package/tools/flattener/main.js +201 -304
- package/tools/flattener/projectRoot.js +75 -73
- package/tools/flattener/prompts.js +9 -9
- package/tools/flattener/stats.helpers.js +131 -67
- package/tools/flattener/stats.js +3 -3
- package/tools/flattener/test-matrix.js +201 -193
- package/tools/flattener/xml.js +33 -31
- package/tools/installer/bin/bmad.js +130 -89
- package/tools/installer/config/ide-agent-config.yaml +1 -1
- package/tools/installer/config/install.config.yaml +2 -2
- package/tools/installer/lib/config-loader.js +46 -42
- package/tools/installer/lib/file-manager.js +91 -113
- package/tools/installer/lib/ide-base-setup.js +57 -56
- package/tools/installer/lib/ide-setup.js +375 -343
- package/tools/installer/lib/installer.js +875 -714
- package/tools/installer/lib/memory-profiler.js +54 -53
- package/tools/installer/lib/module-manager.js +19 -15
- package/tools/installer/lib/resource-locator.js +26 -28
- package/tools/installer/package.json +19 -19
- package/tools/lib/dependency-resolver.js +26 -30
- package/tools/lib/yaml-utils.js +7 -7
- package/tools/preview-release-notes.js +66 -0
- package/tools/shared/bannerArt.js +3 -3
- package/tools/sync-installer-version.js +7 -9
- package/tools/update-expansion-version.js +14 -15
- package/tools/upgraders/v3-to-v4-upgrader.js +203 -294
- package/tools/version-bump.js +41 -26
- package/tools/yaml-format.js +56 -43
- package/.github/workflows/promote-to-stable.yml +0 -144
- package/.github/workflows/release.yaml +0 -60
- package/.releaserc.json +0 -21
- package/tools/semantic-release-sync-installer.js +0 -30
|
@@ -1098,7 +1098,7 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
|
|
|
1098
1098
|
|
|
1099
1099
|
- **Claude Code**: `/agent-name` (e.g., `/bmad-master`)
|
|
1100
1100
|
- **Cursor**: `@agent-name` (e.g., `@bmad-master`)
|
|
1101
|
-
- **Windsurf**:
|
|
1101
|
+
- **Windsurf**: `/agent-name` (e.g., `/bmad-master`)
|
|
1102
1102
|
- **Trae**: `@agent-name` (e.g., `@bmad-master`)
|
|
1103
1103
|
- **Roo Code**: Select mode from mode selector (e.g., `bmad-master`)
|
|
1104
1104
|
- **GitHub Copilot**: Open the Chat view (`⌃⌘I` on Mac, `Ctrl+Alt+I` on Windows/Linux) and select **Agent** from the chat mode selector.
|
|
@@ -1838,7 +1838,7 @@ Agents should be workflow-aware: know active workflow, their role, access artifa
|
|
|
1838
1838
|
==================== START: .bmad-core/tasks/facilitate-brainstorming-session.md ====================
|
|
1839
1839
|
---
|
|
1840
1840
|
docOutputLocation: docs/brainstorming-session-results.md
|
|
1841
|
-
template:
|
|
1841
|
+
template: '.bmad-core/templates/brainstorming-output-tmpl.yaml'
|
|
1842
1842
|
---
|
|
1843
1843
|
|
|
1844
1844
|
# Facilitate Brainstorming Session Task
|
|
@@ -2632,12 +2632,12 @@ sections:
|
|
|
2632
2632
|
- id: introduction
|
|
2633
2633
|
instruction: |
|
|
2634
2634
|
This template guides creation of a comprehensive Project Brief that serves as the foundational input for product development.
|
|
2635
|
-
|
|
2635
|
+
|
|
2636
2636
|
Start by asking the user which mode they prefer:
|
|
2637
|
-
|
|
2637
|
+
|
|
2638
2638
|
1. **Interactive Mode** - Work through each section collaboratively
|
|
2639
2639
|
2. **YOLO Mode** - Generate complete draft for review and refinement
|
|
2640
|
-
|
|
2640
|
+
|
|
2641
2641
|
Before beginning, understand what inputs are available (brainstorming results, market research, competitive analysis, initial ideas) and gather project context.
|
|
2642
2642
|
|
|
2643
2643
|
- id: executive-summary
|
|
@@ -2958,7 +2958,7 @@ sections:
|
|
|
2958
2958
|
instruction: Map the end-to-end customer experience for primary segments
|
|
2959
2959
|
template: |
|
|
2960
2960
|
For primary customer segment:
|
|
2961
|
-
|
|
2961
|
+
|
|
2962
2962
|
1. **Awareness:** {{discovery_process}}
|
|
2963
2963
|
2. **Consideration:** {{evaluation_criteria}}
|
|
2964
2964
|
3. **Purchase:** {{decision_triggers}}
|
|
@@ -3159,7 +3159,7 @@ sections:
|
|
|
3159
3159
|
title: Competitor Prioritization Matrix
|
|
3160
3160
|
instruction: |
|
|
3161
3161
|
Help categorize competitors by market share and strategic threat level
|
|
3162
|
-
|
|
3162
|
+
|
|
3163
3163
|
Create a 2x2 matrix:
|
|
3164
3164
|
- Priority 1 (Core Competitors): High Market Share + High Threat
|
|
3165
3165
|
- Priority 2 (Emerging Threats): Low Market Share + High Threat
|
|
@@ -3224,7 +3224,14 @@ sections:
|
|
|
3224
3224
|
title: Feature Comparison Matrix
|
|
3225
3225
|
instruction: Create a detailed comparison table of key features across competitors
|
|
3226
3226
|
type: table
|
|
3227
|
-
columns:
|
|
3227
|
+
columns:
|
|
3228
|
+
[
|
|
3229
|
+
"Feature Category",
|
|
3230
|
+
"{{your_company}}",
|
|
3231
|
+
"{{competitor_1}}",
|
|
3232
|
+
"{{competitor_2}}",
|
|
3233
|
+
"{{competitor_3}}",
|
|
3234
|
+
]
|
|
3228
3235
|
rows:
|
|
3229
3236
|
- category: "Core Functionality"
|
|
3230
3237
|
items:
|
|
@@ -3236,7 +3243,13 @@ sections:
|
|
|
3236
3243
|
- ["Onboarding Time", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
|
|
3237
3244
|
- category: "Integration & Ecosystem"
|
|
3238
3245
|
items:
|
|
3239
|
-
- [
|
|
3246
|
+
- [
|
|
3247
|
+
"API Availability",
|
|
3248
|
+
"{{availability}}",
|
|
3249
|
+
"{{availability}}",
|
|
3250
|
+
"{{availability}}",
|
|
3251
|
+
"{{availability}}",
|
|
3252
|
+
]
|
|
3240
3253
|
- ["Third-party Integrations", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
|
|
3241
3254
|
- category: "Pricing & Plans"
|
|
3242
3255
|
items:
|
|
@@ -3263,7 +3276,7 @@ sections:
|
|
|
3263
3276
|
title: Positioning Map
|
|
3264
3277
|
instruction: |
|
|
3265
3278
|
Describe competitor positions on key dimensions
|
|
3266
|
-
|
|
3279
|
+
|
|
3267
3280
|
Create a positioning description using 2 key dimensions relevant to the market, such as:
|
|
3268
3281
|
- Price vs. Features
|
|
3269
3282
|
- Ease of Use vs. Power
|
|
@@ -3298,7 +3311,7 @@ sections:
|
|
|
3298
3311
|
title: Blue Ocean Opportunities
|
|
3299
3312
|
instruction: |
|
|
3300
3313
|
Identify uncontested market spaces
|
|
3301
|
-
|
|
3314
|
+
|
|
3302
3315
|
List opportunities to create new market space:
|
|
3303
3316
|
- Underserved segments
|
|
3304
3317
|
- Unaddressed use cases
|
|
@@ -3402,11 +3415,11 @@ sections:
|
|
|
3402
3415
|
- id: summary-details
|
|
3403
3416
|
template: |
|
|
3404
3417
|
**Topic:** {{session_topic}}
|
|
3405
|
-
|
|
3418
|
+
|
|
3406
3419
|
**Session Goals:** {{stated_goals}}
|
|
3407
|
-
|
|
3420
|
+
|
|
3408
3421
|
**Techniques Used:** {{techniques_list}}
|
|
3409
|
-
|
|
3422
|
+
|
|
3410
3423
|
**Total Ideas Generated:** {{total_ideas}}
|
|
3411
3424
|
- id: key-themes
|
|
3412
3425
|
title: "Key Themes Identified:"
|
|
@@ -3531,7 +3544,7 @@ sections:
|
|
|
3531
3544
|
- id: footer
|
|
3532
3545
|
content: |
|
|
3533
3546
|
---
|
|
3534
|
-
|
|
3547
|
+
|
|
3535
3548
|
*Session facilitated using the BMAD-METHOD brainstorming framework*
|
|
3536
3549
|
==================== END: .bmad-core/templates/brainstorming-output-tmpl.yaml ====================
|
|
3537
3550
|
|
|
@@ -4296,7 +4309,7 @@ sections:
|
|
|
4296
4309
|
condition: PRD has UX/UI requirements
|
|
4297
4310
|
instruction: |
|
|
4298
4311
|
Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps:
|
|
4299
|
-
|
|
4312
|
+
|
|
4300
4313
|
1. Pre-fill all subsections with educated guesses based on project context
|
|
4301
4314
|
2. Present the complete rendered section to user
|
|
4302
4315
|
3. Clearly let the user know where assumptions were made
|
|
@@ -4338,7 +4351,7 @@ sections:
|
|
|
4338
4351
|
title: Technical Assumptions
|
|
4339
4352
|
instruction: |
|
|
4340
4353
|
Gather technical decisions that will guide the Architect. Steps:
|
|
4341
|
-
|
|
4354
|
+
|
|
4342
4355
|
1. Check if .bmad-core/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices
|
|
4343
4356
|
2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets
|
|
4344
4357
|
3. For unknowns, offer guidance based on project goals and MVP scope
|
|
@@ -4366,9 +4379,9 @@ sections:
|
|
|
4366
4379
|
title: Epic List
|
|
4367
4380
|
instruction: |
|
|
4368
4381
|
Present a high-level list of all epics for user approval. 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.
|
|
4369
|
-
|
|
4382
|
+
|
|
4370
4383
|
CRITICAL: Epics MUST be logically sequential following agile best practices:
|
|
4371
|
-
|
|
4384
|
+
|
|
4372
4385
|
- Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
|
|
4373
4386
|
- 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 - remember this when we produce the stories for the first epic!
|
|
4374
4387
|
- Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
|
|
@@ -4387,11 +4400,11 @@ sections:
|
|
|
4387
4400
|
repeatable: true
|
|
4388
4401
|
instruction: |
|
|
4389
4402
|
After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit.
|
|
4390
|
-
|
|
4403
|
+
|
|
4391
4404
|
For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve).
|
|
4392
|
-
|
|
4405
|
+
|
|
4393
4406
|
CRITICAL STORY SEQUENCING REQUIREMENTS:
|
|
4394
|
-
|
|
4407
|
+
|
|
4395
4408
|
- Stories within each epic MUST be logically sequential
|
|
4396
4409
|
- Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation
|
|
4397
4410
|
- No story should depend on work from a later story or epic
|
|
@@ -4419,7 +4432,7 @@ sections:
|
|
|
4419
4432
|
repeatable: true
|
|
4420
4433
|
instruction: |
|
|
4421
4434
|
Define clear, comprehensive, and testable acceptance criteria that:
|
|
4422
|
-
|
|
4435
|
+
|
|
4423
4436
|
- Precisely define what "done" means from a functional perspective
|
|
4424
4437
|
- Are unambiguous and serve as basis for verification
|
|
4425
4438
|
- Include any critical non-functional requirements from the PRD
|
|
@@ -4461,19 +4474,19 @@ sections:
|
|
|
4461
4474
|
title: Intro Project Analysis and Context
|
|
4462
4475
|
instruction: |
|
|
4463
4476
|
IMPORTANT - SCOPE ASSESSMENT REQUIRED:
|
|
4464
|
-
|
|
4477
|
+
|
|
4465
4478
|
This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding:
|
|
4466
|
-
|
|
4479
|
+
|
|
4467
4480
|
1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories."
|
|
4468
|
-
|
|
4481
|
+
|
|
4469
4482
|
2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first.
|
|
4470
|
-
|
|
4483
|
+
|
|
4471
4484
|
3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions.
|
|
4472
|
-
|
|
4485
|
+
|
|
4473
4486
|
Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements.
|
|
4474
|
-
|
|
4487
|
+
|
|
4475
4488
|
CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?"
|
|
4476
|
-
|
|
4489
|
+
|
|
4477
4490
|
Do not proceed with any recommendations until the user has validated your understanding of the existing system.
|
|
4478
4491
|
sections:
|
|
4479
4492
|
- id: existing-project-overview
|
|
@@ -4499,7 +4512,7 @@ sections:
|
|
|
4499
4512
|
- Note: "Document-project analysis available - using existing technical documentation"
|
|
4500
4513
|
- List key documents created by document-project
|
|
4501
4514
|
- Skip the missing documentation check below
|
|
4502
|
-
|
|
4515
|
+
|
|
4503
4516
|
Otherwise, check for existing documentation:
|
|
4504
4517
|
sections:
|
|
4505
4518
|
- id: available-docs
|
|
@@ -4623,7 +4636,7 @@ sections:
|
|
|
4623
4636
|
If document-project output available:
|
|
4624
4637
|
- Extract from "Actual Tech Stack" table in High Level Architecture section
|
|
4625
4638
|
- Include version numbers and any noted constraints
|
|
4626
|
-
|
|
4639
|
+
|
|
4627
4640
|
Otherwise, document the current technology stack:
|
|
4628
4641
|
template: |
|
|
4629
4642
|
**Languages**: {{languages}}
|
|
@@ -4662,7 +4675,7 @@ sections:
|
|
|
4662
4675
|
- Reference "Technical Debt and Known Issues" section
|
|
4663
4676
|
- Include "Workarounds and Gotchas" that might impact enhancement
|
|
4664
4677
|
- Note any identified constraints from "Critical Technical Debt"
|
|
4665
|
-
|
|
4678
|
+
|
|
4666
4679
|
Build risk assessment incorporating existing known issues:
|
|
4667
4680
|
template: |
|
|
4668
4681
|
**Technical Risks**: {{technical_risks}}
|
|
@@ -4685,7 +4698,7 @@ sections:
|
|
|
4685
4698
|
title: "Epic 1: {{enhancement_title}}"
|
|
4686
4699
|
instruction: |
|
|
4687
4700
|
Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
|
|
4688
|
-
|
|
4701
|
+
|
|
4689
4702
|
CRITICAL STORY SEQUENCING FOR BROWNFIELD:
|
|
4690
4703
|
- Stories must ensure existing functionality remains intact
|
|
4691
4704
|
- Each story should include verification that existing features still work
|
|
@@ -4698,7 +4711,7 @@ sections:
|
|
|
4698
4711
|
- Each story must deliver value while maintaining system integrity
|
|
4699
4712
|
template: |
|
|
4700
4713
|
**Epic Goal**: {{epic_goal}}
|
|
4701
|
-
|
|
4714
|
+
|
|
4702
4715
|
**Integration Requirements**: {{integration_requirements}}
|
|
4703
4716
|
sections:
|
|
4704
4717
|
- id: story
|
|
@@ -5362,7 +5375,7 @@ sections:
|
|
|
5362
5375
|
title: Introduction
|
|
5363
5376
|
instruction: |
|
|
5364
5377
|
Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification.
|
|
5365
|
-
|
|
5378
|
+
|
|
5366
5379
|
Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.
|
|
5367
5380
|
content: |
|
|
5368
5381
|
This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience.
|
|
@@ -5371,7 +5384,7 @@ sections:
|
|
|
5371
5384
|
title: Overall UX Goals & Principles
|
|
5372
5385
|
instruction: |
|
|
5373
5386
|
Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine:
|
|
5374
|
-
|
|
5387
|
+
|
|
5375
5388
|
1. Target User Personas - elicit details or confirm existing ones from PRD
|
|
5376
5389
|
2. Key Usability Goals - understand what success looks like for users
|
|
5377
5390
|
3. Core Design Principles - establish 3-5 guiding principles
|
|
@@ -5412,7 +5425,7 @@ sections:
|
|
|
5412
5425
|
title: Information Architecture (IA)
|
|
5413
5426
|
instruction: |
|
|
5414
5427
|
Collaborate with the user to create a comprehensive information architecture:
|
|
5415
|
-
|
|
5428
|
+
|
|
5416
5429
|
1. Build a Site Map or Screen Inventory showing all major areas
|
|
5417
5430
|
2. Define the Navigation Structure (primary, secondary, breadcrumbs)
|
|
5418
5431
|
3. Use Mermaid diagrams for visual representation
|
|
@@ -5442,22 +5455,22 @@ sections:
|
|
|
5442
5455
|
title: Navigation Structure
|
|
5443
5456
|
template: |
|
|
5444
5457
|
**Primary Navigation:** {{primary_nav_description}}
|
|
5445
|
-
|
|
5458
|
+
|
|
5446
5459
|
**Secondary Navigation:** {{secondary_nav_description}}
|
|
5447
|
-
|
|
5460
|
+
|
|
5448
5461
|
**Breadcrumb Strategy:** {{breadcrumb_strategy}}
|
|
5449
5462
|
|
|
5450
5463
|
- id: user-flows
|
|
5451
5464
|
title: User Flows
|
|
5452
5465
|
instruction: |
|
|
5453
5466
|
For each critical user task identified in the PRD:
|
|
5454
|
-
|
|
5467
|
+
|
|
5455
5468
|
1. Define the user's goal clearly
|
|
5456
5469
|
2. Map out all steps including decision points
|
|
5457
5470
|
3. Consider edge cases and error states
|
|
5458
5471
|
4. Use Mermaid flow diagrams for clarity
|
|
5459
5472
|
5. Link to external tools (Figma/Miro) if detailed flows exist there
|
|
5460
|
-
|
|
5473
|
+
|
|
5461
5474
|
Create subsections for each major flow.
|
|
5462
5475
|
elicit: true
|
|
5463
5476
|
repeatable: true
|
|
@@ -5466,9 +5479,9 @@ sections:
|
|
|
5466
5479
|
title: "{{flow_name}}"
|
|
5467
5480
|
template: |
|
|
5468
5481
|
**User Goal:** {{flow_goal}}
|
|
5469
|
-
|
|
5482
|
+
|
|
5470
5483
|
**Entry Points:** {{entry_points}}
|
|
5471
|
-
|
|
5484
|
+
|
|
5472
5485
|
**Success Criteria:** {{success_criteria}}
|
|
5473
5486
|
sections:
|
|
5474
5487
|
- id: flow-diagram
|
|
@@ -5499,14 +5512,14 @@ sections:
|
|
|
5499
5512
|
title: "{{screen_name}}"
|
|
5500
5513
|
template: |
|
|
5501
5514
|
**Purpose:** {{screen_purpose}}
|
|
5502
|
-
|
|
5515
|
+
|
|
5503
5516
|
**Key Elements:**
|
|
5504
5517
|
- {{element_1}}
|
|
5505
5518
|
- {{element_2}}
|
|
5506
5519
|
- {{element_3}}
|
|
5507
|
-
|
|
5520
|
+
|
|
5508
5521
|
**Interaction Notes:** {{interaction_notes}}
|
|
5509
|
-
|
|
5522
|
+
|
|
5510
5523
|
**Design File Reference:** {{specific_frame_link}}
|
|
5511
5524
|
|
|
5512
5525
|
- id: component-library
|
|
@@ -5525,11 +5538,11 @@ sections:
|
|
|
5525
5538
|
title: "{{component_name}}"
|
|
5526
5539
|
template: |
|
|
5527
5540
|
**Purpose:** {{component_purpose}}
|
|
5528
|
-
|
|
5541
|
+
|
|
5529
5542
|
**Variants:** {{component_variants}}
|
|
5530
|
-
|
|
5543
|
+
|
|
5531
5544
|
**States:** {{component_states}}
|
|
5532
|
-
|
|
5545
|
+
|
|
5533
5546
|
**Usage Guidelines:** {{usage_guidelines}}
|
|
5534
5547
|
|
|
5535
5548
|
- id: branding-style
|
|
@@ -5575,13 +5588,13 @@ sections:
|
|
|
5575
5588
|
title: Iconography
|
|
5576
5589
|
template: |
|
|
5577
5590
|
**Icon Library:** {{icon_library}}
|
|
5578
|
-
|
|
5591
|
+
|
|
5579
5592
|
**Usage Guidelines:** {{icon_guidelines}}
|
|
5580
5593
|
- id: spacing-layout
|
|
5581
5594
|
title: Spacing & Layout
|
|
5582
5595
|
template: |
|
|
5583
5596
|
**Grid System:** {{grid_system}}
|
|
5584
|
-
|
|
5597
|
+
|
|
5585
5598
|
**Spacing Scale:** {{spacing_scale}}
|
|
5586
5599
|
|
|
5587
5600
|
- id: accessibility
|
|
@@ -5599,12 +5612,12 @@ sections:
|
|
|
5599
5612
|
- Color contrast ratios: {{contrast_requirements}}
|
|
5600
5613
|
- Focus indicators: {{focus_requirements}}
|
|
5601
5614
|
- Text sizing: {{text_requirements}}
|
|
5602
|
-
|
|
5615
|
+
|
|
5603
5616
|
**Interaction:**
|
|
5604
5617
|
- Keyboard navigation: {{keyboard_requirements}}
|
|
5605
5618
|
- Screen reader support: {{screen_reader_requirements}}
|
|
5606
5619
|
- Touch targets: {{touch_requirements}}
|
|
5607
|
-
|
|
5620
|
+
|
|
5608
5621
|
**Content:**
|
|
5609
5622
|
- Alternative text: {{alt_text_requirements}}
|
|
5610
5623
|
- Heading structure: {{heading_requirements}}
|
|
@@ -5631,11 +5644,11 @@ sections:
|
|
|
5631
5644
|
title: Adaptation Patterns
|
|
5632
5645
|
template: |
|
|
5633
5646
|
**Layout Changes:** {{layout_adaptations}}
|
|
5634
|
-
|
|
5647
|
+
|
|
5635
5648
|
**Navigation Changes:** {{nav_adaptations}}
|
|
5636
|
-
|
|
5649
|
+
|
|
5637
5650
|
**Content Priority:** {{content_adaptations}}
|
|
5638
|
-
|
|
5651
|
+
|
|
5639
5652
|
**Interaction Changes:** {{interaction_adaptations}}
|
|
5640
5653
|
|
|
5641
5654
|
- id: animation
|
|
@@ -5669,7 +5682,7 @@ sections:
|
|
|
5669
5682
|
title: Next Steps
|
|
5670
5683
|
instruction: |
|
|
5671
5684
|
After completing the UI/UX specification:
|
|
5672
|
-
|
|
5685
|
+
|
|
5673
5686
|
1. Recommend review with stakeholders
|
|
5674
5687
|
2. Suggest creating/updating visual designs in design tool
|
|
5675
5688
|
3. Prepare for handoff to Design Architect for frontend architecture
|
|
@@ -5718,20 +5731,20 @@ sections:
|
|
|
5718
5731
|
- id: intro-content
|
|
5719
5732
|
content: |
|
|
5720
5733
|
This document outlines the overall project architecture for {{project_name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies.
|
|
5721
|
-
|
|
5734
|
+
|
|
5722
5735
|
**Relationship to Frontend Architecture:**
|
|
5723
5736
|
If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components.
|
|
5724
5737
|
- id: starter-template
|
|
5725
5738
|
title: Starter Template or Existing Project
|
|
5726
5739
|
instruction: |
|
|
5727
5740
|
Before proceeding further with architecture design, check if the project is based on a starter template or existing codebase:
|
|
5728
|
-
|
|
5741
|
+
|
|
5729
5742
|
1. Review the PRD and brainstorming brief for any mentions of:
|
|
5730
5743
|
- Starter templates (e.g., Create React App, Next.js, Vue CLI, Angular CLI, etc.)
|
|
5731
5744
|
- Existing projects or codebases being used as a foundation
|
|
5732
5745
|
- Boilerplate projects or scaffolding tools
|
|
5733
5746
|
- Previous projects to be cloned or adapted
|
|
5734
|
-
|
|
5747
|
+
|
|
5735
5748
|
2. If a starter template or existing project is mentioned:
|
|
5736
5749
|
- Ask the user to provide access via one of these methods:
|
|
5737
5750
|
- Link to the starter template documentation
|
|
@@ -5744,16 +5757,16 @@ sections:
|
|
|
5744
5757
|
- Existing architectural patterns and conventions
|
|
5745
5758
|
- Any limitations or constraints imposed by the starter
|
|
5746
5759
|
- Use this analysis to inform and align your architecture decisions
|
|
5747
|
-
|
|
5760
|
+
|
|
5748
5761
|
3. If no starter template is mentioned but this is a greenfield project:
|
|
5749
5762
|
- Suggest appropriate starter templates based on the tech stack preferences
|
|
5750
5763
|
- Explain the benefits (faster setup, best practices, community support)
|
|
5751
5764
|
- Let the user decide whether to use one
|
|
5752
|
-
|
|
5765
|
+
|
|
5753
5766
|
4. If the user confirms no starter template will be used:
|
|
5754
5767
|
- Proceed with architecture design from scratch
|
|
5755
5768
|
- Note that manual setup will be required for all tooling and configuration
|
|
5756
|
-
|
|
5769
|
+
|
|
5757
5770
|
Document the decision here before proceeding with the architecture design. If none, just say N/A
|
|
5758
5771
|
elicit: true
|
|
5759
5772
|
- id: changelog
|
|
@@ -5781,7 +5794,7 @@ sections:
|
|
|
5781
5794
|
title: High Level Overview
|
|
5782
5795
|
instruction: |
|
|
5783
5796
|
Based on the PRD's Technical Assumptions section, describe:
|
|
5784
|
-
|
|
5797
|
+
|
|
5785
5798
|
1. The main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven)
|
|
5786
5799
|
2. Repository structure decision from PRD (Monorepo/Polyrepo)
|
|
5787
5800
|
3. Service architecture decision from PRD
|
|
@@ -5798,17 +5811,17 @@ sections:
|
|
|
5798
5811
|
- Data flow directions
|
|
5799
5812
|
- External integrations
|
|
5800
5813
|
- User entry points
|
|
5801
|
-
|
|
5814
|
+
|
|
5802
5815
|
- id: architectural-patterns
|
|
5803
5816
|
title: Architectural and Design Patterns
|
|
5804
5817
|
instruction: |
|
|
5805
5818
|
List the key high-level patterns that will guide the architecture. For each pattern:
|
|
5806
|
-
|
|
5819
|
+
|
|
5807
5820
|
1. Present 2-3 viable options if multiple exist
|
|
5808
5821
|
2. Provide your recommendation with clear rationale
|
|
5809
5822
|
3. Get user confirmation before finalizing
|
|
5810
5823
|
4. These patterns should align with the PRD's technical assumptions and project goals
|
|
5811
|
-
|
|
5824
|
+
|
|
5812
5825
|
Common patterns to consider:
|
|
5813
5826
|
- Architectural style patterns (Serverless, Event-Driven, Microservices, CQRS, Hexagonal)
|
|
5814
5827
|
- Code organization patterns (Dependency Injection, Repository, Module, Factory)
|
|
@@ -5824,23 +5837,23 @@ sections:
|
|
|
5824
5837
|
title: Tech Stack
|
|
5825
5838
|
instruction: |
|
|
5826
5839
|
This is the DEFINITIVE technology selection section. Work with the user to make specific choices:
|
|
5827
|
-
|
|
5840
|
+
|
|
5828
5841
|
1. Review PRD technical assumptions and any preferences from .bmad-core/data/technical-preferences.yaml or an attached technical-preferences
|
|
5829
5842
|
2. For each category, present 2-3 viable options with pros/cons
|
|
5830
5843
|
3. Make a clear recommendation based on project needs
|
|
5831
5844
|
4. Get explicit user approval for each selection
|
|
5832
5845
|
5. Document exact versions (avoid "latest" - pin specific versions)
|
|
5833
5846
|
6. This table is the single source of truth - all other docs must reference these choices
|
|
5834
|
-
|
|
5847
|
+
|
|
5835
5848
|
Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about - let the user know if they are not sure on any that you can also provide suggestions with rationale:
|
|
5836
|
-
|
|
5849
|
+
|
|
5837
5850
|
- Starter templates (if any)
|
|
5838
5851
|
- Languages and runtimes with exact versions
|
|
5839
5852
|
- Frameworks and libraries / packages
|
|
5840
5853
|
- Cloud provider and key services choices
|
|
5841
5854
|
- Database and storage solutions - if unclear suggest sql or nosql or other types depending on the project and depending on cloud provider offer a suggestion
|
|
5842
5855
|
- Development tools
|
|
5843
|
-
|
|
5856
|
+
|
|
5844
5857
|
Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback - this statement and the options should be rendered and then prompt right all before allowing user input.
|
|
5845
5858
|
elicit: true
|
|
5846
5859
|
sections:
|
|
@@ -5864,13 +5877,13 @@ sections:
|
|
|
5864
5877
|
title: Data Models
|
|
5865
5878
|
instruction: |
|
|
5866
5879
|
Define the core data models/entities:
|
|
5867
|
-
|
|
5880
|
+
|
|
5868
5881
|
1. Review PRD requirements and identify key business entities
|
|
5869
5882
|
2. For each model, explain its purpose and relationships
|
|
5870
5883
|
3. Include key attributes and data types
|
|
5871
5884
|
4. Show relationships between models
|
|
5872
5885
|
5. Discuss design decisions with user
|
|
5873
|
-
|
|
5886
|
+
|
|
5874
5887
|
Create a clear conceptual model before moving to database schema.
|
|
5875
5888
|
elicit: true
|
|
5876
5889
|
repeatable: true
|
|
@@ -5879,11 +5892,11 @@ sections:
|
|
|
5879
5892
|
title: "{{model_name}}"
|
|
5880
5893
|
template: |
|
|
5881
5894
|
**Purpose:** {{model_purpose}}
|
|
5882
|
-
|
|
5895
|
+
|
|
5883
5896
|
**Key Attributes:**
|
|
5884
5897
|
- {{attribute_1}}: {{type_1}} - {{description_1}}
|
|
5885
5898
|
- {{attribute_2}}: {{type_2}} - {{description_2}}
|
|
5886
|
-
|
|
5899
|
+
|
|
5887
5900
|
**Relationships:**
|
|
5888
5901
|
- {{relationship_1}}
|
|
5889
5902
|
- {{relationship_2}}
|
|
@@ -5892,7 +5905,7 @@ sections:
|
|
|
5892
5905
|
title: Components
|
|
5893
5906
|
instruction: |
|
|
5894
5907
|
Based on the architectural patterns, tech stack, and data models from above:
|
|
5895
|
-
|
|
5908
|
+
|
|
5896
5909
|
1. Identify major logical components/services and their responsibilities
|
|
5897
5910
|
2. Consider the repository structure (monorepo/polyrepo) from PRD
|
|
5898
5911
|
3. Define clear boundaries and interfaces between components
|
|
@@ -5901,7 +5914,7 @@ sections:
|
|
|
5901
5914
|
- Key interfaces/APIs exposed
|
|
5902
5915
|
- Dependencies on other components
|
|
5903
5916
|
- Technology specifics based on tech stack choices
|
|
5904
|
-
|
|
5917
|
+
|
|
5905
5918
|
5. Create component diagrams where helpful
|
|
5906
5919
|
elicit: true
|
|
5907
5920
|
sections:
|
|
@@ -5910,13 +5923,13 @@ sections:
|
|
|
5910
5923
|
title: "{{component_name}}"
|
|
5911
5924
|
template: |
|
|
5912
5925
|
**Responsibility:** {{component_description}}
|
|
5913
|
-
|
|
5926
|
+
|
|
5914
5927
|
**Key Interfaces:**
|
|
5915
5928
|
- {{interface_1}}
|
|
5916
5929
|
- {{interface_2}}
|
|
5917
|
-
|
|
5930
|
+
|
|
5918
5931
|
**Dependencies:** {{dependencies}}
|
|
5919
|
-
|
|
5932
|
+
|
|
5920
5933
|
**Technology Stack:** {{component_tech_details}}
|
|
5921
5934
|
- id: component-diagrams
|
|
5922
5935
|
title: Component Diagrams
|
|
@@ -5933,13 +5946,13 @@ sections:
|
|
|
5933
5946
|
condition: Project requires external API integrations
|
|
5934
5947
|
instruction: |
|
|
5935
5948
|
For each external service integration:
|
|
5936
|
-
|
|
5949
|
+
|
|
5937
5950
|
1. Identify APIs needed based on PRD requirements and component design
|
|
5938
5951
|
2. If documentation URLs are unknown, ask user for specifics
|
|
5939
5952
|
3. Document authentication methods and security considerations
|
|
5940
5953
|
4. List specific endpoints that will be used
|
|
5941
5954
|
5. Note any rate limits or usage constraints
|
|
5942
|
-
|
|
5955
|
+
|
|
5943
5956
|
If no external APIs are needed, state this explicitly and skip to next section.
|
|
5944
5957
|
elicit: true
|
|
5945
5958
|
repeatable: true
|
|
@@ -5952,10 +5965,10 @@ sections:
|
|
|
5952
5965
|
- **Base URL(s):** {{api_base_url}}
|
|
5953
5966
|
- **Authentication:** {{auth_method}}
|
|
5954
5967
|
- **Rate Limits:** {{rate_limits}}
|
|
5955
|
-
|
|
5968
|
+
|
|
5956
5969
|
**Key Endpoints Used:**
|
|
5957
5970
|
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
|
|
5958
|
-
|
|
5971
|
+
|
|
5959
5972
|
**Integration Notes:** {{integration_considerations}}
|
|
5960
5973
|
|
|
5961
5974
|
- id: core-workflows
|
|
@@ -5964,13 +5977,13 @@ sections:
|
|
|
5964
5977
|
mermaid_type: sequence
|
|
5965
5978
|
instruction: |
|
|
5966
5979
|
Illustrate key system workflows using sequence diagrams:
|
|
5967
|
-
|
|
5980
|
+
|
|
5968
5981
|
1. Identify critical user journeys from PRD
|
|
5969
5982
|
2. Show component interactions including external APIs
|
|
5970
5983
|
3. Include error handling paths
|
|
5971
5984
|
4. Document async operations
|
|
5972
5985
|
5. Create both high-level and detailed diagrams as needed
|
|
5973
|
-
|
|
5986
|
+
|
|
5974
5987
|
Focus on workflows that clarify architecture decisions or complex interactions.
|
|
5975
5988
|
elicit: true
|
|
5976
5989
|
|
|
@@ -5981,13 +5994,13 @@ sections:
|
|
|
5981
5994
|
language: yaml
|
|
5982
5995
|
instruction: |
|
|
5983
5996
|
If the project includes a REST API:
|
|
5984
|
-
|
|
5997
|
+
|
|
5985
5998
|
1. Create an OpenAPI 3.0 specification
|
|
5986
5999
|
2. Include all endpoints from epics/stories
|
|
5987
6000
|
3. Define request/response schemas based on data models
|
|
5988
6001
|
4. Document authentication requirements
|
|
5989
6002
|
5. Include example requests/responses
|
|
5990
|
-
|
|
6003
|
+
|
|
5991
6004
|
Use YAML format for better readability. If no REST API, skip this section.
|
|
5992
6005
|
elicit: true
|
|
5993
6006
|
template: |
|
|
@@ -6004,13 +6017,13 @@ sections:
|
|
|
6004
6017
|
title: Database Schema
|
|
6005
6018
|
instruction: |
|
|
6006
6019
|
Transform the conceptual data models into concrete database schemas:
|
|
6007
|
-
|
|
6020
|
+
|
|
6008
6021
|
1. Use the database type(s) selected in Tech Stack
|
|
6009
6022
|
2. Create schema definitions using appropriate notation
|
|
6010
6023
|
3. Include indexes, constraints, and relationships
|
|
6011
6024
|
4. Consider performance and scalability
|
|
6012
6025
|
5. For NoSQL, show document structures
|
|
6013
|
-
|
|
6026
|
+
|
|
6014
6027
|
Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.)
|
|
6015
6028
|
elicit: true
|
|
6016
6029
|
|
|
@@ -6020,14 +6033,14 @@ sections:
|
|
|
6020
6033
|
language: plaintext
|
|
6021
6034
|
instruction: |
|
|
6022
6035
|
Create a project folder structure that reflects:
|
|
6023
|
-
|
|
6036
|
+
|
|
6024
6037
|
1. The chosen repository structure (monorepo/polyrepo)
|
|
6025
6038
|
2. The service architecture (monolith/microservices/serverless)
|
|
6026
6039
|
3. The selected tech stack and languages
|
|
6027
6040
|
4. Component organization from above
|
|
6028
6041
|
5. Best practices for the chosen frameworks
|
|
6029
6042
|
6. Clear separation of concerns
|
|
6030
|
-
|
|
6043
|
+
|
|
6031
6044
|
Adapt the structure based on project needs. For monorepos, show service separation. For serverless, show function organization. Include language-specific conventions.
|
|
6032
6045
|
elicit: true
|
|
6033
6046
|
examples:
|
|
@@ -6045,13 +6058,13 @@ sections:
|
|
|
6045
6058
|
title: Infrastructure and Deployment
|
|
6046
6059
|
instruction: |
|
|
6047
6060
|
Define the deployment architecture and practices:
|
|
6048
|
-
|
|
6061
|
+
|
|
6049
6062
|
1. Use IaC tool selected in Tech Stack
|
|
6050
6063
|
2. Choose deployment strategy appropriate for the architecture
|
|
6051
6064
|
3. Define environments and promotion flow
|
|
6052
6065
|
4. Establish rollback procedures
|
|
6053
6066
|
5. Consider security, monitoring, and cost optimization
|
|
6054
|
-
|
|
6067
|
+
|
|
6055
6068
|
Get user input on deployment preferences and CI/CD tool choices.
|
|
6056
6069
|
elicit: true
|
|
6057
6070
|
sections:
|
|
@@ -6087,13 +6100,13 @@ sections:
|
|
|
6087
6100
|
title: Error Handling Strategy
|
|
6088
6101
|
instruction: |
|
|
6089
6102
|
Define comprehensive error handling approach:
|
|
6090
|
-
|
|
6103
|
+
|
|
6091
6104
|
1. Choose appropriate patterns for the language/framework from Tech Stack
|
|
6092
6105
|
2. Define logging standards and tools
|
|
6093
6106
|
3. Establish error categories and handling rules
|
|
6094
6107
|
4. Consider observability and debugging needs
|
|
6095
6108
|
5. Ensure security (no sensitive data in logs)
|
|
6096
|
-
|
|
6109
|
+
|
|
6097
6110
|
This section guides both AI and human developers in consistent error handling.
|
|
6098
6111
|
elicit: true
|
|
6099
6112
|
sections:
|
|
@@ -6140,13 +6153,13 @@ sections:
|
|
|
6140
6153
|
title: Coding Standards
|
|
6141
6154
|
instruction: |
|
|
6142
6155
|
These standards are MANDATORY for AI agents. Work with user to define ONLY the critical rules needed to prevent bad code. Explain that:
|
|
6143
|
-
|
|
6156
|
+
|
|
6144
6157
|
1. This section directly controls AI developer behavior
|
|
6145
6158
|
2. Keep it minimal - assume AI knows general best practices
|
|
6146
6159
|
3. Focus on project-specific conventions and gotchas
|
|
6147
6160
|
4. Overly detailed standards bloat context and slow development
|
|
6148
6161
|
5. Standards will be extracted to separate file for dev agent use
|
|
6149
|
-
|
|
6162
|
+
|
|
6150
6163
|
For each standard, get explicit user confirmation it's necessary.
|
|
6151
6164
|
elicit: true
|
|
6152
6165
|
sections:
|
|
@@ -6168,7 +6181,7 @@ sections:
|
|
|
6168
6181
|
- "Never use console.log in production code - use logger"
|
|
6169
6182
|
- "All API responses must use ApiResponse wrapper type"
|
|
6170
6183
|
- "Database queries must use repository pattern, never direct ORM"
|
|
6171
|
-
|
|
6184
|
+
|
|
6172
6185
|
Avoid obvious rules like "use SOLID principles" or "write clean code"
|
|
6173
6186
|
repeatable: true
|
|
6174
6187
|
template: "- **{{rule_name}}:** {{rule_description}}"
|
|
@@ -6186,14 +6199,14 @@ sections:
|
|
|
6186
6199
|
title: Test Strategy and Standards
|
|
6187
6200
|
instruction: |
|
|
6188
6201
|
Work with user to define comprehensive test strategy:
|
|
6189
|
-
|
|
6202
|
+
|
|
6190
6203
|
1. Use test frameworks from Tech Stack
|
|
6191
6204
|
2. Decide on TDD vs test-after approach
|
|
6192
6205
|
3. Define test organization and naming
|
|
6193
6206
|
4. Establish coverage goals
|
|
6194
6207
|
5. Determine integration test infrastructure
|
|
6195
6208
|
6. Plan for test data and external dependencies
|
|
6196
|
-
|
|
6209
|
+
|
|
6197
6210
|
Note: Basic info goes in Coding Standards for dev agent. This detailed section is for QA agent and team reference.
|
|
6198
6211
|
elicit: true
|
|
6199
6212
|
sections:
|
|
@@ -6214,7 +6227,7 @@ sections:
|
|
|
6214
6227
|
- **Location:** {{unit_test_location}}
|
|
6215
6228
|
- **Mocking Library:** {{mocking_library}}
|
|
6216
6229
|
- **Coverage Requirement:** {{unit_coverage}}
|
|
6217
|
-
|
|
6230
|
+
|
|
6218
6231
|
**AI Agent Requirements:**
|
|
6219
6232
|
- Generate tests for all public methods
|
|
6220
6233
|
- Cover edge cases and error conditions
|
|
@@ -6256,7 +6269,7 @@ sections:
|
|
|
6256
6269
|
title: Security
|
|
6257
6270
|
instruction: |
|
|
6258
6271
|
Define MANDATORY security requirements for AI and human developers:
|
|
6259
|
-
|
|
6272
|
+
|
|
6260
6273
|
1. Focus on implementation-specific rules
|
|
6261
6274
|
2. Reference security tools from Tech Stack
|
|
6262
6275
|
3. Define clear patterns for common scenarios
|
|
@@ -6325,16 +6338,16 @@ sections:
|
|
|
6325
6338
|
title: Next Steps
|
|
6326
6339
|
instruction: |
|
|
6327
6340
|
After completing the architecture:
|
|
6328
|
-
|
|
6341
|
+
|
|
6329
6342
|
1. If project has UI components:
|
|
6330
6343
|
- Use "Frontend Architecture Mode"
|
|
6331
6344
|
- Provide this document as input
|
|
6332
|
-
|
|
6345
|
+
|
|
6333
6346
|
2. For all projects:
|
|
6334
6347
|
- Review with Product Owner
|
|
6335
6348
|
- Begin story implementation with Dev agent
|
|
6336
6349
|
- Set up infrastructure with DevOps agent
|
|
6337
|
-
|
|
6350
|
+
|
|
6338
6351
|
3. Include specific prompts for next agents if needed
|
|
6339
6352
|
sections:
|
|
6340
6353
|
- id: architect-prompt
|
|
@@ -6367,16 +6380,16 @@ sections:
|
|
|
6367
6380
|
title: Template and Framework Selection
|
|
6368
6381
|
instruction: |
|
|
6369
6382
|
Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided.
|
|
6370
|
-
|
|
6383
|
+
|
|
6371
6384
|
Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase:
|
|
6372
|
-
|
|
6385
|
+
|
|
6373
6386
|
1. Review the PRD, main architecture document, and brainstorming brief for mentions of:
|
|
6374
6387
|
- Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.)
|
|
6375
6388
|
- UI kit or component library starters
|
|
6376
6389
|
- Existing frontend projects being used as a foundation
|
|
6377
6390
|
- Admin dashboard templates or other specialized starters
|
|
6378
6391
|
- Design system implementations
|
|
6379
|
-
|
|
6392
|
+
|
|
6380
6393
|
2. If a frontend starter template or existing project is mentioned:
|
|
6381
6394
|
- Ask the user to provide access via one of these methods:
|
|
6382
6395
|
- Link to the starter template documentation
|
|
@@ -6392,7 +6405,7 @@ sections:
|
|
|
6392
6405
|
- Testing setup and patterns
|
|
6393
6406
|
- Build and development scripts
|
|
6394
6407
|
- Use this analysis to ensure your frontend architecture aligns with the starter's patterns
|
|
6395
|
-
|
|
6408
|
+
|
|
6396
6409
|
3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is:
|
|
6397
6410
|
- Based on the framework choice, suggest appropriate starters:
|
|
6398
6411
|
- React: Create React App, Next.js, Vite + React
|
|
@@ -6400,11 +6413,11 @@ sections:
|
|
|
6400
6413
|
- Angular: Angular CLI
|
|
6401
6414
|
- Or suggest popular UI templates if applicable
|
|
6402
6415
|
- Explain benefits specific to frontend development
|
|
6403
|
-
|
|
6416
|
+
|
|
6404
6417
|
4. If the user confirms no starter template will be used:
|
|
6405
6418
|
- Note that all tooling, bundling, and configuration will need manual setup
|
|
6406
6419
|
- Proceed with frontend architecture from scratch
|
|
6407
|
-
|
|
6420
|
+
|
|
6408
6421
|
Document the starter template decision and any constraints it imposes before proceeding.
|
|
6409
6422
|
sections:
|
|
6410
6423
|
- id: changelog
|
|
@@ -6426,12 +6439,24 @@ sections:
|
|
|
6426
6439
|
rows:
|
|
6427
6440
|
- ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6428
6441
|
- ["UI Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6429
|
-
- [
|
|
6442
|
+
- [
|
|
6443
|
+
"State Management",
|
|
6444
|
+
"{{state_management}}",
|
|
6445
|
+
"{{version}}",
|
|
6446
|
+
"{{purpose}}",
|
|
6447
|
+
"{{why_chosen}}",
|
|
6448
|
+
]
|
|
6430
6449
|
- ["Routing", "{{routing_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6431
6450
|
- ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6432
6451
|
- ["Styling", "{{styling_solution}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6433
6452
|
- ["Testing", "{{test_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6434
|
-
- [
|
|
6453
|
+
- [
|
|
6454
|
+
"Component Library",
|
|
6455
|
+
"{{component_lib}}",
|
|
6456
|
+
"{{version}}",
|
|
6457
|
+
"{{purpose}}",
|
|
6458
|
+
"{{why_chosen}}",
|
|
6459
|
+
]
|
|
6435
6460
|
- ["Form Handling", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6436
6461
|
- ["Animation", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6437
6462
|
- ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
@@ -6579,33 +6604,33 @@ sections:
|
|
|
6579
6604
|
elicit: true
|
|
6580
6605
|
content: |
|
|
6581
6606
|
This document outlines the complete fullstack architecture for {{project_name}}, including backend systems, frontend implementation, and their integration. It serves as the single source of truth for AI-driven development, ensuring consistency across the entire technology stack.
|
|
6582
|
-
|
|
6607
|
+
|
|
6583
6608
|
This unified approach combines what would traditionally be separate backend and frontend architecture documents, streamlining the development process for modern fullstack applications where these concerns are increasingly intertwined.
|
|
6584
6609
|
sections:
|
|
6585
6610
|
- id: starter-template
|
|
6586
6611
|
title: Starter Template or Existing Project
|
|
6587
6612
|
instruction: |
|
|
6588
6613
|
Before proceeding with architecture design, check if the project is based on any starter templates or existing codebases:
|
|
6589
|
-
|
|
6614
|
+
|
|
6590
6615
|
1. Review the PRD and other documents for mentions of:
|
|
6591
6616
|
- Fullstack starter templates (e.g., T3 Stack, MEAN/MERN starters, Django + React templates)
|
|
6592
6617
|
- Monorepo templates (e.g., Nx, Turborepo starters)
|
|
6593
6618
|
- Platform-specific starters (e.g., Vercel templates, AWS Amplify starters)
|
|
6594
6619
|
- Existing projects being extended or cloned
|
|
6595
|
-
|
|
6620
|
+
|
|
6596
6621
|
2. If starter templates or existing projects are mentioned:
|
|
6597
6622
|
- Ask the user to provide access (links, repos, or files)
|
|
6598
6623
|
- Analyze to understand pre-configured choices and constraints
|
|
6599
6624
|
- Note any architectural decisions already made
|
|
6600
6625
|
- Identify what can be modified vs what must be retained
|
|
6601
|
-
|
|
6626
|
+
|
|
6602
6627
|
3. If no starter is mentioned but this is greenfield:
|
|
6603
6628
|
- Suggest appropriate fullstack starters based on tech preferences
|
|
6604
6629
|
- Consider platform-specific options (Vercel, AWS, etc.)
|
|
6605
6630
|
- Let user decide whether to use one
|
|
6606
|
-
|
|
6631
|
+
|
|
6607
6632
|
4. Document the decision and any constraints it imposes
|
|
6608
|
-
|
|
6633
|
+
|
|
6609
6634
|
If none, state "N/A - Greenfield project"
|
|
6610
6635
|
- id: changelog
|
|
6611
6636
|
title: Change Log
|
|
@@ -6631,17 +6656,17 @@ sections:
|
|
|
6631
6656
|
title: Platform and Infrastructure Choice
|
|
6632
6657
|
instruction: |
|
|
6633
6658
|
Based on PRD requirements and technical assumptions, make a platform recommendation:
|
|
6634
|
-
|
|
6659
|
+
|
|
6635
6660
|
1. Consider common patterns (not an exhaustive list, use your own best judgement and search the web as needed for emerging trends):
|
|
6636
6661
|
- **Vercel + Supabase**: For rapid development with Next.js, built-in auth/storage
|
|
6637
6662
|
- **AWS Full Stack**: For enterprise scale with Lambda, API Gateway, S3, Cognito
|
|
6638
6663
|
- **Azure**: For .NET ecosystems or enterprise Microsoft environments
|
|
6639
6664
|
- **Google Cloud**: For ML/AI heavy applications or Google ecosystem integration
|
|
6640
|
-
|
|
6665
|
+
|
|
6641
6666
|
2. Present 2-3 viable options with clear pros/cons
|
|
6642
6667
|
3. Make a recommendation with rationale
|
|
6643
6668
|
4. Get explicit user confirmation
|
|
6644
|
-
|
|
6669
|
+
|
|
6645
6670
|
Document the choice and key services that will be used.
|
|
6646
6671
|
template: |
|
|
6647
6672
|
**Platform:** {{selected_platform}}
|
|
@@ -6651,7 +6676,7 @@ sections:
|
|
|
6651
6676
|
title: Repository Structure
|
|
6652
6677
|
instruction: |
|
|
6653
6678
|
Define the repository approach based on PRD requirements and platform choice, explain your rationale or ask questions to the user if unsure:
|
|
6654
|
-
|
|
6679
|
+
|
|
6655
6680
|
1. For modern fullstack apps, monorepo is often preferred
|
|
6656
6681
|
2. Consider tooling (Nx, Turborepo, Lerna, npm workspaces)
|
|
6657
6682
|
3. Define package/app boundaries
|
|
@@ -6673,7 +6698,7 @@ sections:
|
|
|
6673
6698
|
- Databases and storage
|
|
6674
6699
|
- External integrations
|
|
6675
6700
|
- CDN and caching layers
|
|
6676
|
-
|
|
6701
|
+
|
|
6677
6702
|
Use appropriate diagram type for clarity.
|
|
6678
6703
|
- id: architectural-patterns
|
|
6679
6704
|
title: Architectural Patterns
|
|
@@ -6683,7 +6708,7 @@ sections:
|
|
|
6683
6708
|
- Frontend patterns (e.g., Component-based, State management)
|
|
6684
6709
|
- Backend patterns (e.g., Repository, CQRS, Event-driven)
|
|
6685
6710
|
- Integration patterns (e.g., BFF, API Gateway)
|
|
6686
|
-
|
|
6711
|
+
|
|
6687
6712
|
For each pattern, provide recommendation and rationale.
|
|
6688
6713
|
repeatable: true
|
|
6689
6714
|
template: "- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}"
|
|
@@ -6697,7 +6722,7 @@ sections:
|
|
|
6697
6722
|
title: Tech Stack
|
|
6698
6723
|
instruction: |
|
|
6699
6724
|
This is the DEFINITIVE technology selection for the entire project. Work with user to finalize all choices. This table is the single source of truth - all development must use these exact versions.
|
|
6700
|
-
|
|
6725
|
+
|
|
6701
6726
|
Key areas to cover:
|
|
6702
6727
|
- Frontend and backend languages/frameworks
|
|
6703
6728
|
- Databases and caching
|
|
@@ -6706,7 +6731,7 @@ sections:
|
|
|
6706
6731
|
- Testing tools for both frontend and backend
|
|
6707
6732
|
- Build and deployment tools
|
|
6708
6733
|
- Monitoring and logging
|
|
6709
|
-
|
|
6734
|
+
|
|
6710
6735
|
Upon render, elicit feedback immediately.
|
|
6711
6736
|
elicit: true
|
|
6712
6737
|
sections:
|
|
@@ -6716,11 +6741,29 @@ sections:
|
|
|
6716
6741
|
columns: [Category, Technology, Version, Purpose, Rationale]
|
|
6717
6742
|
rows:
|
|
6718
6743
|
- ["Frontend Language", "{{fe_language}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6719
|
-
- [
|
|
6720
|
-
|
|
6744
|
+
- [
|
|
6745
|
+
"Frontend Framework",
|
|
6746
|
+
"{{fe_framework}}",
|
|
6747
|
+
"{{version}}",
|
|
6748
|
+
"{{purpose}}",
|
|
6749
|
+
"{{why_chosen}}",
|
|
6750
|
+
]
|
|
6751
|
+
- [
|
|
6752
|
+
"UI Component Library",
|
|
6753
|
+
"{{ui_library}}",
|
|
6754
|
+
"{{version}}",
|
|
6755
|
+
"{{purpose}}",
|
|
6756
|
+
"{{why_chosen}}",
|
|
6757
|
+
]
|
|
6721
6758
|
- ["State Management", "{{state_mgmt}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6722
6759
|
- ["Backend Language", "{{be_language}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6723
|
-
- [
|
|
6760
|
+
- [
|
|
6761
|
+
"Backend Framework",
|
|
6762
|
+
"{{be_framework}}",
|
|
6763
|
+
"{{version}}",
|
|
6764
|
+
"{{purpose}}",
|
|
6765
|
+
"{{why_chosen}}",
|
|
6766
|
+
]
|
|
6724
6767
|
- ["API Style", "{{api_style}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6725
6768
|
- ["Database", "{{database}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
6726
6769
|
- ["Cache", "{{cache}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
|
@@ -6741,14 +6784,14 @@ sections:
|
|
|
6741
6784
|
title: Data Models
|
|
6742
6785
|
instruction: |
|
|
6743
6786
|
Define the core data models/entities that will be shared between frontend and backend:
|
|
6744
|
-
|
|
6787
|
+
|
|
6745
6788
|
1. Review PRD requirements and identify key business entities
|
|
6746
6789
|
2. For each model, explain its purpose and relationships
|
|
6747
6790
|
3. Include key attributes and data types
|
|
6748
6791
|
4. Show relationships between models
|
|
6749
6792
|
5. Create TypeScript interfaces that can be shared
|
|
6750
6793
|
6. Discuss design decisions with user
|
|
6751
|
-
|
|
6794
|
+
|
|
6752
6795
|
Create a clear conceptual model before moving to database schema.
|
|
6753
6796
|
elicit: true
|
|
6754
6797
|
repeatable: true
|
|
@@ -6757,7 +6800,7 @@ sections:
|
|
|
6757
6800
|
title: "{{model_name}}"
|
|
6758
6801
|
template: |
|
|
6759
6802
|
**Purpose:** {{model_purpose}}
|
|
6760
|
-
|
|
6803
|
+
|
|
6761
6804
|
**Key Attributes:**
|
|
6762
6805
|
- {{attribute_1}}: {{type_1}} - {{description_1}}
|
|
6763
6806
|
- {{attribute_2}}: {{type_2}} - {{description_2}}
|
|
@@ -6776,7 +6819,7 @@ sections:
|
|
|
6776
6819
|
title: API Specification
|
|
6777
6820
|
instruction: |
|
|
6778
6821
|
Based on the chosen API style from Tech Stack:
|
|
6779
|
-
|
|
6822
|
+
|
|
6780
6823
|
1. If REST API, create an OpenAPI 3.0 specification
|
|
6781
6824
|
2. If GraphQL, provide the GraphQL schema
|
|
6782
6825
|
3. If tRPC, show router definitions
|
|
@@ -6784,7 +6827,7 @@ sections:
|
|
|
6784
6827
|
5. Define request/response schemas based on data models
|
|
6785
6828
|
6. Document authentication requirements
|
|
6786
6829
|
7. Include example requests/responses
|
|
6787
|
-
|
|
6830
|
+
|
|
6788
6831
|
Use appropriate format for the chosen API style. If no API (e.g., static site), skip this section.
|
|
6789
6832
|
elicit: true
|
|
6790
6833
|
sections:
|
|
@@ -6819,7 +6862,7 @@ sections:
|
|
|
6819
6862
|
title: Components
|
|
6820
6863
|
instruction: |
|
|
6821
6864
|
Based on the architectural patterns, tech stack, and data models from above:
|
|
6822
|
-
|
|
6865
|
+
|
|
6823
6866
|
1. Identify major logical components/services across the fullstack
|
|
6824
6867
|
2. Consider both frontend and backend components
|
|
6825
6868
|
3. Define clear boundaries and interfaces between components
|
|
@@ -6828,7 +6871,7 @@ sections:
|
|
|
6828
6871
|
- Key interfaces/APIs exposed
|
|
6829
6872
|
- Dependencies on other components
|
|
6830
6873
|
- Technology specifics based on tech stack choices
|
|
6831
|
-
|
|
6874
|
+
|
|
6832
6875
|
5. Create component diagrams where helpful
|
|
6833
6876
|
elicit: true
|
|
6834
6877
|
sections:
|
|
@@ -6837,13 +6880,13 @@ sections:
|
|
|
6837
6880
|
title: "{{component_name}}"
|
|
6838
6881
|
template: |
|
|
6839
6882
|
**Responsibility:** {{component_description}}
|
|
6840
|
-
|
|
6883
|
+
|
|
6841
6884
|
**Key Interfaces:**
|
|
6842
6885
|
- {{interface_1}}
|
|
6843
6886
|
- {{interface_2}}
|
|
6844
|
-
|
|
6887
|
+
|
|
6845
6888
|
**Dependencies:** {{dependencies}}
|
|
6846
|
-
|
|
6889
|
+
|
|
6847
6890
|
**Technology Stack:** {{component_tech_details}}
|
|
6848
6891
|
- id: component-diagrams
|
|
6849
6892
|
title: Component Diagrams
|
|
@@ -6860,13 +6903,13 @@ sections:
|
|
|
6860
6903
|
condition: Project requires external API integrations
|
|
6861
6904
|
instruction: |
|
|
6862
6905
|
For each external service integration:
|
|
6863
|
-
|
|
6906
|
+
|
|
6864
6907
|
1. Identify APIs needed based on PRD requirements and component design
|
|
6865
6908
|
2. If documentation URLs are unknown, ask user for specifics
|
|
6866
6909
|
3. Document authentication methods and security considerations
|
|
6867
6910
|
4. List specific endpoints that will be used
|
|
6868
6911
|
5. Note any rate limits or usage constraints
|
|
6869
|
-
|
|
6912
|
+
|
|
6870
6913
|
If no external APIs are needed, state this explicitly and skip to next section.
|
|
6871
6914
|
elicit: true
|
|
6872
6915
|
repeatable: true
|
|
@@ -6879,10 +6922,10 @@ sections:
|
|
|
6879
6922
|
- **Base URL(s):** {{api_base_url}}
|
|
6880
6923
|
- **Authentication:** {{auth_method}}
|
|
6881
6924
|
- **Rate Limits:** {{rate_limits}}
|
|
6882
|
-
|
|
6925
|
+
|
|
6883
6926
|
**Key Endpoints Used:**
|
|
6884
6927
|
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
|
|
6885
|
-
|
|
6928
|
+
|
|
6886
6929
|
**Integration Notes:** {{integration_considerations}}
|
|
6887
6930
|
|
|
6888
6931
|
- id: core-workflows
|
|
@@ -6891,14 +6934,14 @@ sections:
|
|
|
6891
6934
|
mermaid_type: sequence
|
|
6892
6935
|
instruction: |
|
|
6893
6936
|
Illustrate key system workflows using sequence diagrams:
|
|
6894
|
-
|
|
6937
|
+
|
|
6895
6938
|
1. Identify critical user journeys from PRD
|
|
6896
6939
|
2. Show component interactions including external APIs
|
|
6897
6940
|
3. Include both frontend and backend flows
|
|
6898
6941
|
4. Include error handling paths
|
|
6899
6942
|
5. Document async operations
|
|
6900
6943
|
6. Create both high-level and detailed diagrams as needed
|
|
6901
|
-
|
|
6944
|
+
|
|
6902
6945
|
Focus on workflows that clarify architecture decisions or complex interactions.
|
|
6903
6946
|
elicit: true
|
|
6904
6947
|
|
|
@@ -6906,13 +6949,13 @@ sections:
|
|
|
6906
6949
|
title: Database Schema
|
|
6907
6950
|
instruction: |
|
|
6908
6951
|
Transform the conceptual data models into concrete database schemas:
|
|
6909
|
-
|
|
6952
|
+
|
|
6910
6953
|
1. Use the database type(s) selected in Tech Stack
|
|
6911
6954
|
2. Create schema definitions using appropriate notation
|
|
6912
6955
|
3. Include indexes, constraints, and relationships
|
|
6913
6956
|
4. Consider performance and scalability
|
|
6914
6957
|
5. For NoSQL, show document structures
|
|
6915
|
-
|
|
6958
|
+
|
|
6916
6959
|
Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.)
|
|
6917
6960
|
elicit: true
|
|
6918
6961
|
|
|
@@ -7048,60 +7091,60 @@ sections:
|
|
|
7048
7091
|
type: code
|
|
7049
7092
|
language: plaintext
|
|
7050
7093
|
examples:
|
|
7051
|
-
|
|
7052
|
-
|
|
7053
|
-
|
|
7054
|
-
|
|
7055
|
-
|
|
7056
|
-
|
|
7057
|
-
|
|
7058
|
-
|
|
7059
|
-
|
|
7060
|
-
|
|
7061
|
-
|
|
7062
|
-
|
|
7063
|
-
|
|
7064
|
-
|
|
7065
|
-
|
|
7066
|
-
|
|
7067
|
-
|
|
7068
|
-
|
|
7069
|
-
|
|
7070
|
-
|
|
7071
|
-
|
|
7072
|
-
|
|
7073
|
-
|
|
7074
|
-
|
|
7075
|
-
|
|
7076
|
-
|
|
7077
|
-
|
|
7078
|
-
|
|
7079
|
-
|
|
7080
|
-
|
|
7081
|
-
|
|
7082
|
-
|
|
7083
|
-
|
|
7084
|
-
|
|
7085
|
-
|
|
7086
|
-
|
|
7087
|
-
|
|
7088
|
-
|
|
7089
|
-
|
|
7090
|
-
|
|
7091
|
-
|
|
7092
|
-
|
|
7093
|
-
|
|
7094
|
-
|
|
7095
|
-
|
|
7096
|
-
|
|
7097
|
-
|
|
7098
|
-
|
|
7099
|
-
|
|
7100
|
-
|
|
7101
|
-
|
|
7102
|
-
|
|
7103
|
-
|
|
7104
|
-
|
|
7094
|
+
- |
|
|
7095
|
+
{{project-name}}/
|
|
7096
|
+
├── .github/ # CI/CD workflows
|
|
7097
|
+
│ └── workflows/
|
|
7098
|
+
│ ├── ci.yaml
|
|
7099
|
+
│ └── deploy.yaml
|
|
7100
|
+
├── apps/ # Application packages
|
|
7101
|
+
│ ├── web/ # Frontend application
|
|
7102
|
+
│ │ ├── src/
|
|
7103
|
+
│ │ │ ├── components/ # UI components
|
|
7104
|
+
│ │ │ ├── pages/ # Page components/routes
|
|
7105
|
+
│ │ │ ├── hooks/ # Custom React hooks
|
|
7106
|
+
│ │ │ ├── services/ # API client services
|
|
7107
|
+
│ │ │ ├── stores/ # State management
|
|
7108
|
+
│ │ │ ├── styles/ # Global styles/themes
|
|
7109
|
+
│ │ │ └── utils/ # Frontend utilities
|
|
7110
|
+
│ │ ├── public/ # Static assets
|
|
7111
|
+
│ │ ├── tests/ # Frontend tests
|
|
7112
|
+
│ │ └── package.json
|
|
7113
|
+
│ └── api/ # Backend application
|
|
7114
|
+
│ ├── src/
|
|
7115
|
+
│ │ ├── routes/ # API routes/controllers
|
|
7116
|
+
│ │ ├── services/ # Business logic
|
|
7117
|
+
│ │ ├── models/ # Data models
|
|
7118
|
+
│ │ ├── middleware/ # Express/API middleware
|
|
7119
|
+
│ │ ├── utils/ # Backend utilities
|
|
7120
|
+
│ │ └── {{serverless_or_server_entry}}
|
|
7121
|
+
│ ├── tests/ # Backend tests
|
|
7122
|
+
│ └── package.json
|
|
7123
|
+
├── packages/ # Shared packages
|
|
7124
|
+
│ ├── shared/ # Shared types/utilities
|
|
7125
|
+
│ │ ├── src/
|
|
7126
|
+
│ │ │ ├── types/ # TypeScript interfaces
|
|
7127
|
+
│ │ │ ├── constants/ # Shared constants
|
|
7128
|
+
│ │ │ └── utils/ # Shared utilities
|
|
7129
|
+
│ │ └── package.json
|
|
7130
|
+
│ ├── ui/ # Shared UI components
|
|
7131
|
+
│ │ ├── src/
|
|
7132
|
+
│ │ └── package.json
|
|
7133
|
+
│ └── config/ # Shared configuration
|
|
7134
|
+
│ ├── eslint/
|
|
7135
|
+
│ ├── typescript/
|
|
7136
|
+
│ └── jest/
|
|
7137
|
+
├── infrastructure/ # IaC definitions
|
|
7138
|
+
│ └── {{iac_structure}}
|
|
7139
|
+
├── scripts/ # Build/deploy scripts
|
|
7140
|
+
├── docs/ # Documentation
|
|
7141
|
+
│ ├── prd.md
|
|
7142
|
+
│ ├── front-end-spec.md
|
|
7143
|
+
│ └── fullstack-architecture.md
|
|
7144
|
+
├── .env.example # Environment template
|
|
7145
|
+
├── package.json # Root package.json
|
|
7146
|
+
├── {{monorepo_config}} # Monorepo configuration
|
|
7147
|
+
└── README.md
|
|
7105
7148
|
|
|
7106
7149
|
- id: development-workflow
|
|
7107
7150
|
title: Development Workflow
|
|
@@ -7128,13 +7171,13 @@ sections:
|
|
|
7128
7171
|
template: |
|
|
7129
7172
|
# Start all services
|
|
7130
7173
|
{{start_all_command}}
|
|
7131
|
-
|
|
7174
|
+
|
|
7132
7175
|
# Start frontend only
|
|
7133
7176
|
{{start_frontend_command}}
|
|
7134
|
-
|
|
7177
|
+
|
|
7135
7178
|
# Start backend only
|
|
7136
7179
|
{{start_backend_command}}
|
|
7137
|
-
|
|
7180
|
+
|
|
7138
7181
|
# Run tests
|
|
7139
7182
|
{{test_commands}}
|
|
7140
7183
|
- id: environment-config
|
|
@@ -7147,10 +7190,10 @@ sections:
|
|
|
7147
7190
|
template: |
|
|
7148
7191
|
# Frontend (.env.local)
|
|
7149
7192
|
{{frontend_env_vars}}
|
|
7150
|
-
|
|
7193
|
+
|
|
7151
7194
|
# Backend (.env)
|
|
7152
7195
|
{{backend_env_vars}}
|
|
7153
|
-
|
|
7196
|
+
|
|
7154
7197
|
# Shared
|
|
7155
7198
|
{{shared_env_vars}}
|
|
7156
7199
|
|
|
@@ -7167,7 +7210,7 @@ sections:
|
|
|
7167
7210
|
- **Build Command:** {{frontend_build_command}}
|
|
7168
7211
|
- **Output Directory:** {{frontend_output_dir}}
|
|
7169
7212
|
- **CDN/Edge:** {{cdn_strategy}}
|
|
7170
|
-
|
|
7213
|
+
|
|
7171
7214
|
**Backend Deployment:**
|
|
7172
7215
|
- **Platform:** {{backend_deploy_platform}}
|
|
7173
7216
|
- **Build Command:** {{backend_build_command}}
|
|
@@ -7198,12 +7241,12 @@ sections:
|
|
|
7198
7241
|
- CSP Headers: {{csp_policy}}
|
|
7199
7242
|
- XSS Prevention: {{xss_strategy}}
|
|
7200
7243
|
- Secure Storage: {{storage_strategy}}
|
|
7201
|
-
|
|
7244
|
+
|
|
7202
7245
|
**Backend Security:**
|
|
7203
7246
|
- Input Validation: {{validation_approach}}
|
|
7204
7247
|
- Rate Limiting: {{rate_limit_config}}
|
|
7205
7248
|
- CORS Policy: {{cors_config}}
|
|
7206
|
-
|
|
7249
|
+
|
|
7207
7250
|
**Authentication Security:**
|
|
7208
7251
|
- Token Storage: {{token_strategy}}
|
|
7209
7252
|
- Session Management: {{session_approach}}
|
|
@@ -7215,7 +7258,7 @@ sections:
|
|
|
7215
7258
|
- Bundle Size Target: {{bundle_size}}
|
|
7216
7259
|
- Loading Strategy: {{loading_approach}}
|
|
7217
7260
|
- Caching Strategy: {{fe_cache_strategy}}
|
|
7218
|
-
|
|
7261
|
+
|
|
7219
7262
|
**Backend Performance:**
|
|
7220
7263
|
- Response Time Target: {{response_target}}
|
|
7221
7264
|
- Database Optimization: {{db_optimization}}
|
|
@@ -7231,10 +7274,10 @@ sections:
|
|
|
7231
7274
|
type: code
|
|
7232
7275
|
language: text
|
|
7233
7276
|
template: |
|
|
7234
|
-
|
|
7235
|
-
|
|
7236
|
-
|
|
7237
|
-
|
|
7277
|
+
E2E Tests
|
|
7278
|
+
/ \
|
|
7279
|
+
Integration Tests
|
|
7280
|
+
/ \
|
|
7238
7281
|
Frontend Unit Backend Unit
|
|
7239
7282
|
- id: test-organization
|
|
7240
7283
|
title: Test Organization
|
|
@@ -7353,7 +7396,7 @@ sections:
|
|
|
7353
7396
|
- JavaScript errors
|
|
7354
7397
|
- API response times
|
|
7355
7398
|
- User interactions
|
|
7356
|
-
|
|
7399
|
+
|
|
7357
7400
|
**Backend Metrics:**
|
|
7358
7401
|
- Request rate
|
|
7359
7402
|
- Error rate
|
|
@@ -7384,40 +7427,40 @@ sections:
|
|
|
7384
7427
|
title: Introduction
|
|
7385
7428
|
instruction: |
|
|
7386
7429
|
IMPORTANT - SCOPE AND ASSESSMENT REQUIRED:
|
|
7387
|
-
|
|
7430
|
+
|
|
7388
7431
|
This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding:
|
|
7389
|
-
|
|
7432
|
+
|
|
7390
7433
|
1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead."
|
|
7391
|
-
|
|
7434
|
+
|
|
7392
7435
|
2. **REQUIRED INPUTS**:
|
|
7393
7436
|
- Completed brownfield-prd.md
|
|
7394
7437
|
- Existing project technical documentation (from docs folder or user-provided)
|
|
7395
7438
|
- Access to existing project structure (IDE or uploaded files)
|
|
7396
|
-
|
|
7439
|
+
|
|
7397
7440
|
3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions.
|
|
7398
|
-
|
|
7441
|
+
|
|
7399
7442
|
4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?"
|
|
7400
|
-
|
|
7443
|
+
|
|
7401
7444
|
If any required inputs are missing, request them before proceeding.
|
|
7402
7445
|
elicit: true
|
|
7403
7446
|
sections:
|
|
7404
7447
|
- id: intro-content
|
|
7405
7448
|
content: |
|
|
7406
7449
|
This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system.
|
|
7407
|
-
|
|
7450
|
+
|
|
7408
7451
|
**Relationship to Existing Architecture:**
|
|
7409
7452
|
This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements.
|
|
7410
7453
|
- id: existing-project-analysis
|
|
7411
7454
|
title: Existing Project Analysis
|
|
7412
7455
|
instruction: |
|
|
7413
7456
|
Analyze the existing project structure and architecture:
|
|
7414
|
-
|
|
7457
|
+
|
|
7415
7458
|
1. Review existing documentation in docs folder
|
|
7416
7459
|
2. Examine current technology stack and versions
|
|
7417
7460
|
3. Identify existing architectural patterns and conventions
|
|
7418
7461
|
4. Note current deployment and infrastructure setup
|
|
7419
7462
|
5. Document any constraints or limitations
|
|
7420
|
-
|
|
7463
|
+
|
|
7421
7464
|
CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations."
|
|
7422
7465
|
elicit: true
|
|
7423
7466
|
sections:
|
|
@@ -7446,12 +7489,12 @@ sections:
|
|
|
7446
7489
|
title: Enhancement Scope and Integration Strategy
|
|
7447
7490
|
instruction: |
|
|
7448
7491
|
Define how the enhancement will integrate with the existing system:
|
|
7449
|
-
|
|
7492
|
+
|
|
7450
7493
|
1. Review the brownfield PRD enhancement scope
|
|
7451
7494
|
2. Identify integration points with existing code
|
|
7452
7495
|
3. Define boundaries between new and existing functionality
|
|
7453
7496
|
4. Establish compatibility requirements
|
|
7454
|
-
|
|
7497
|
+
|
|
7455
7498
|
VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?"
|
|
7456
7499
|
elicit: true
|
|
7457
7500
|
sections:
|
|
@@ -7480,7 +7523,7 @@ sections:
|
|
|
7480
7523
|
title: Tech Stack Alignment
|
|
7481
7524
|
instruction: |
|
|
7482
7525
|
Ensure new components align with existing technology choices:
|
|
7483
|
-
|
|
7526
|
+
|
|
7484
7527
|
1. Use existing technology stack as the foundation
|
|
7485
7528
|
2. Only introduce new technologies if absolutely necessary
|
|
7486
7529
|
3. Justify any new additions with clear rationale
|
|
@@ -7503,7 +7546,7 @@ sections:
|
|
|
7503
7546
|
title: Data Models and Schema Changes
|
|
7504
7547
|
instruction: |
|
|
7505
7548
|
Define new data models and how they integrate with existing schema:
|
|
7506
|
-
|
|
7549
|
+
|
|
7507
7550
|
1. Identify new entities required for the enhancement
|
|
7508
7551
|
2. Define relationships with existing data models
|
|
7509
7552
|
3. Plan database schema changes (additions, modifications)
|
|
@@ -7519,11 +7562,11 @@ sections:
|
|
|
7519
7562
|
template: |
|
|
7520
7563
|
**Purpose:** {{model_purpose}}
|
|
7521
7564
|
**Integration:** {{integration_with_existing}}
|
|
7522
|
-
|
|
7565
|
+
|
|
7523
7566
|
**Key Attributes:**
|
|
7524
7567
|
- {{attribute_1}}: {{type_1}} - {{description_1}}
|
|
7525
7568
|
- {{attribute_2}}: {{type_2}} - {{description_2}}
|
|
7526
|
-
|
|
7569
|
+
|
|
7527
7570
|
**Relationships:**
|
|
7528
7571
|
- **With Existing:** {{existing_relationships}}
|
|
7529
7572
|
- **With New:** {{new_relationships}}
|
|
@@ -7535,7 +7578,7 @@ sections:
|
|
|
7535
7578
|
- **Modified Tables:** {{modified_tables_list}}
|
|
7536
7579
|
- **New Indexes:** {{new_indexes_list}}
|
|
7537
7580
|
- **Migration Strategy:** {{migration_approach}}
|
|
7538
|
-
|
|
7581
|
+
|
|
7539
7582
|
**Backward Compatibility:**
|
|
7540
7583
|
- {{compatibility_measure_1}}
|
|
7541
7584
|
- {{compatibility_measure_2}}
|
|
@@ -7544,12 +7587,12 @@ sections:
|
|
|
7544
7587
|
title: Component Architecture
|
|
7545
7588
|
instruction: |
|
|
7546
7589
|
Define new components and their integration with existing architecture:
|
|
7547
|
-
|
|
7590
|
+
|
|
7548
7591
|
1. Identify new components required for the enhancement
|
|
7549
7592
|
2. Define interfaces with existing components
|
|
7550
7593
|
3. Establish clear boundaries and responsibilities
|
|
7551
7594
|
4. Plan integration points and data flow
|
|
7552
|
-
|
|
7595
|
+
|
|
7553
7596
|
MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?"
|
|
7554
7597
|
elicit: true
|
|
7555
7598
|
sections:
|
|
@@ -7562,15 +7605,15 @@ sections:
|
|
|
7562
7605
|
template: |
|
|
7563
7606
|
**Responsibility:** {{component_description}}
|
|
7564
7607
|
**Integration Points:** {{integration_points}}
|
|
7565
|
-
|
|
7608
|
+
|
|
7566
7609
|
**Key Interfaces:**
|
|
7567
7610
|
- {{interface_1}}
|
|
7568
7611
|
- {{interface_2}}
|
|
7569
|
-
|
|
7612
|
+
|
|
7570
7613
|
**Dependencies:**
|
|
7571
7614
|
- **Existing Components:** {{existing_dependencies}}
|
|
7572
7615
|
- **New Components:** {{new_dependencies}}
|
|
7573
|
-
|
|
7616
|
+
|
|
7574
7617
|
**Technology Stack:** {{component_tech_details}}
|
|
7575
7618
|
- id: interaction-diagram
|
|
7576
7619
|
title: Component Interaction Diagram
|
|
@@ -7583,7 +7626,7 @@ sections:
|
|
|
7583
7626
|
condition: Enhancement requires API changes
|
|
7584
7627
|
instruction: |
|
|
7585
7628
|
Define new API endpoints and integration with existing APIs:
|
|
7586
|
-
|
|
7629
|
+
|
|
7587
7630
|
1. Plan new API endpoints required for the enhancement
|
|
7588
7631
|
2. Ensure consistency with existing API patterns
|
|
7589
7632
|
3. Define authentication and authorization integration
|
|
@@ -7633,17 +7676,17 @@ sections:
|
|
|
7633
7676
|
- **Base URL:** {{api_base_url}}
|
|
7634
7677
|
- **Authentication:** {{auth_method}}
|
|
7635
7678
|
- **Integration Method:** {{integration_approach}}
|
|
7636
|
-
|
|
7679
|
+
|
|
7637
7680
|
**Key Endpoints Used:**
|
|
7638
7681
|
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
|
|
7639
|
-
|
|
7682
|
+
|
|
7640
7683
|
**Error Handling:** {{error_handling_strategy}}
|
|
7641
7684
|
|
|
7642
7685
|
- id: source-tree-integration
|
|
7643
7686
|
title: Source Tree Integration
|
|
7644
7687
|
instruction: |
|
|
7645
7688
|
Define how new code will integrate with existing project structure:
|
|
7646
|
-
|
|
7689
|
+
|
|
7647
7690
|
1. Follow existing project organization patterns
|
|
7648
7691
|
2. Identify where new files/folders will be placed
|
|
7649
7692
|
3. Ensure consistency with existing naming conventions
|
|
@@ -7682,7 +7725,7 @@ sections:
|
|
|
7682
7725
|
title: Infrastructure and Deployment Integration
|
|
7683
7726
|
instruction: |
|
|
7684
7727
|
Define how the enhancement will be deployed alongside existing infrastructure:
|
|
7685
|
-
|
|
7728
|
+
|
|
7686
7729
|
1. Use existing deployment pipeline and infrastructure
|
|
7687
7730
|
2. Identify any infrastructure changes needed
|
|
7688
7731
|
3. Plan deployment strategy to minimize risk
|
|
@@ -7712,7 +7755,7 @@ sections:
|
|
|
7712
7755
|
title: Coding Standards and Conventions
|
|
7713
7756
|
instruction: |
|
|
7714
7757
|
Ensure new code follows existing project conventions:
|
|
7715
|
-
|
|
7758
|
+
|
|
7716
7759
|
1. Document existing coding standards from project analysis
|
|
7717
7760
|
2. Identify any enhancement-specific requirements
|
|
7718
7761
|
3. Ensure consistency with existing codebase patterns
|
|
@@ -7743,7 +7786,7 @@ sections:
|
|
|
7743
7786
|
title: Testing Strategy
|
|
7744
7787
|
instruction: |
|
|
7745
7788
|
Define testing approach for the enhancement:
|
|
7746
|
-
|
|
7789
|
+
|
|
7747
7790
|
1. Integrate with existing test suite
|
|
7748
7791
|
2. Ensure existing functionality remains intact
|
|
7749
7792
|
3. Plan for testing new features
|
|
@@ -7783,7 +7826,7 @@ sections:
|
|
|
7783
7826
|
title: Security Integration
|
|
7784
7827
|
instruction: |
|
|
7785
7828
|
Ensure security consistency with existing system:
|
|
7786
|
-
|
|
7829
|
+
|
|
7787
7830
|
1. Follow existing security patterns and tools
|
|
7788
7831
|
2. Ensure new features don't introduce vulnerabilities
|
|
7789
7832
|
3. Maintain existing security posture
|
|
@@ -7818,7 +7861,7 @@ sections:
|
|
|
7818
7861
|
title: Next Steps
|
|
7819
7862
|
instruction: |
|
|
7820
7863
|
After completing the brownfield architecture:
|
|
7821
|
-
|
|
7864
|
+
|
|
7822
7865
|
1. Review integration points with existing system
|
|
7823
7866
|
2. Begin story implementation with Dev agent
|
|
7824
7867
|
3. Set up deployment pipeline integration
|
|
@@ -8437,7 +8480,7 @@ workflow:
|
|
|
8437
8480
|
elicitation: advanced-elicitation
|
|
8438
8481
|
|
|
8439
8482
|
agent_config:
|
|
8440
|
-
editable_sections:
|
|
8483
|
+
editable_sections:
|
|
8441
8484
|
- Status
|
|
8442
8485
|
- Story
|
|
8443
8486
|
- Acceptance Criteria
|
|
@@ -8454,7 +8497,7 @@ sections:
|
|
|
8454
8497
|
instruction: Select the current status of the story
|
|
8455
8498
|
owner: scrum-master
|
|
8456
8499
|
editors: [scrum-master, dev-agent]
|
|
8457
|
-
|
|
8500
|
+
|
|
8458
8501
|
- id: story
|
|
8459
8502
|
title: Story
|
|
8460
8503
|
type: template-text
|
|
@@ -8466,7 +8509,7 @@ sections:
|
|
|
8466
8509
|
elicit: true
|
|
8467
8510
|
owner: scrum-master
|
|
8468
8511
|
editors: [scrum-master]
|
|
8469
|
-
|
|
8512
|
+
|
|
8470
8513
|
- id: acceptance-criteria
|
|
8471
8514
|
title: Acceptance Criteria
|
|
8472
8515
|
type: numbered-list
|
|
@@ -8474,7 +8517,7 @@ sections:
|
|
|
8474
8517
|
elicit: true
|
|
8475
8518
|
owner: scrum-master
|
|
8476
8519
|
editors: [scrum-master]
|
|
8477
|
-
|
|
8520
|
+
|
|
8478
8521
|
- id: tasks-subtasks
|
|
8479
8522
|
title: Tasks / Subtasks
|
|
8480
8523
|
type: bullet-list
|
|
@@ -8491,7 +8534,7 @@ sections:
|
|
|
8491
8534
|
elicit: true
|
|
8492
8535
|
owner: scrum-master
|
|
8493
8536
|
editors: [scrum-master, dev-agent]
|
|
8494
|
-
|
|
8537
|
+
|
|
8495
8538
|
- id: dev-notes
|
|
8496
8539
|
title: Dev Notes
|
|
8497
8540
|
instruction: |
|
|
@@ -8515,7 +8558,7 @@ sections:
|
|
|
8515
8558
|
elicit: true
|
|
8516
8559
|
owner: scrum-master
|
|
8517
8560
|
editors: [scrum-master]
|
|
8518
|
-
|
|
8561
|
+
|
|
8519
8562
|
- id: change-log
|
|
8520
8563
|
title: Change Log
|
|
8521
8564
|
type: table
|
|
@@ -8523,7 +8566,7 @@ sections:
|
|
|
8523
8566
|
instruction: Track changes made to this story document
|
|
8524
8567
|
owner: scrum-master
|
|
8525
8568
|
editors: [scrum-master, dev-agent, qa-agent]
|
|
8526
|
-
|
|
8569
|
+
|
|
8527
8570
|
- id: dev-agent-record
|
|
8528
8571
|
title: Dev Agent Record
|
|
8529
8572
|
instruction: This section is populated by the development agent during implementation
|
|
@@ -8536,25 +8579,25 @@ sections:
|
|
|
8536
8579
|
instruction: Record the specific AI agent model and version used for development
|
|
8537
8580
|
owner: dev-agent
|
|
8538
8581
|
editors: [dev-agent]
|
|
8539
|
-
|
|
8582
|
+
|
|
8540
8583
|
- id: debug-log-references
|
|
8541
8584
|
title: Debug Log References
|
|
8542
8585
|
instruction: Reference any debug logs or traces generated during development
|
|
8543
8586
|
owner: dev-agent
|
|
8544
8587
|
editors: [dev-agent]
|
|
8545
|
-
|
|
8588
|
+
|
|
8546
8589
|
- id: completion-notes
|
|
8547
8590
|
title: Completion Notes List
|
|
8548
8591
|
instruction: Notes about the completion of tasks and any issues encountered
|
|
8549
8592
|
owner: dev-agent
|
|
8550
8593
|
editors: [dev-agent]
|
|
8551
|
-
|
|
8594
|
+
|
|
8552
8595
|
- id: file-list
|
|
8553
8596
|
title: File List
|
|
8554
8597
|
instruction: List all files created, modified, or affected during story implementation
|
|
8555
8598
|
owner: dev-agent
|
|
8556
8599
|
editors: [dev-agent]
|
|
8557
|
-
|
|
8600
|
+
|
|
8558
8601
|
- id: qa-results
|
|
8559
8602
|
title: QA Results
|
|
8560
8603
|
instruction: Results from QA Agent QA review of the completed story implementation
|
|
@@ -9020,7 +9063,7 @@ workflow:
|
|
|
9020
9063
|
- Single story (< 4 hours) → Use brownfield-create-story task
|
|
9021
9064
|
- Small feature (1-3 stories) → Use brownfield-create-epic task
|
|
9022
9065
|
- Major enhancement (multiple epics) → Continue with full workflow
|
|
9023
|
-
|
|
9066
|
+
|
|
9024
9067
|
Ask user: "Can you describe the enhancement scope? Is this a small fix, a feature addition, or a major enhancement requiring architectural changes?"
|
|
9025
9068
|
|
|
9026
9069
|
- step: routing_decision
|
|
@@ -9181,7 +9224,7 @@ workflow:
|
|
|
9181
9224
|
notes: |
|
|
9182
9225
|
All stories implemented and reviewed!
|
|
9183
9226
|
Project development phase complete.
|
|
9184
|
-
|
|
9227
|
+
|
|
9185
9228
|
Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
|
|
9186
9229
|
|
|
9187
9230
|
flow_diagram: |
|
|
@@ -9265,35 +9308,35 @@ workflow:
|
|
|
9265
9308
|
{{if single_story}}: Proceeding with brownfield-create-story task for immediate implementation.
|
|
9266
9309
|
{{if small_feature}}: Creating focused epic with brownfield-create-epic task.
|
|
9267
9310
|
{{if major_enhancement}}: Continuing with comprehensive planning workflow.
|
|
9268
|
-
|
|
9311
|
+
|
|
9269
9312
|
documentation_assessment: |
|
|
9270
9313
|
Documentation assessment complete:
|
|
9271
9314
|
{{if adequate}}: Existing documentation is sufficient. Proceeding directly to PRD creation.
|
|
9272
9315
|
{{if inadequate}}: Running document-project to capture current system state before PRD.
|
|
9273
|
-
|
|
9316
|
+
|
|
9274
9317
|
document_project_to_pm: |
|
|
9275
9318
|
Project analysis complete. Key findings documented in:
|
|
9276
9319
|
- {{document_list}}
|
|
9277
9320
|
Use these findings to inform PRD creation and avoid re-analyzing the same aspects.
|
|
9278
|
-
|
|
9321
|
+
|
|
9279
9322
|
pm_to_architect_decision: |
|
|
9280
9323
|
PRD complete and saved as docs/prd.md.
|
|
9281
9324
|
Architectural changes identified: {{yes/no}}
|
|
9282
9325
|
{{if yes}}: Proceeding to create architecture document for: {{specific_changes}}
|
|
9283
9326
|
{{if no}}: No architectural changes needed. Proceeding to validation.
|
|
9284
|
-
|
|
9327
|
+
|
|
9285
9328
|
architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for integration safety."
|
|
9286
|
-
|
|
9329
|
+
|
|
9287
9330
|
po_to_sm: |
|
|
9288
9331
|
All artifacts validated.
|
|
9289
9332
|
Documentation type available: {{sharded_prd / brownfield_docs}}
|
|
9290
9333
|
{{if sharded}}: Use standard create-next-story task.
|
|
9291
9334
|
{{if brownfield}}: Use create-brownfield-story task to handle varied documentation formats.
|
|
9292
|
-
|
|
9335
|
+
|
|
9293
9336
|
sm_story_creation: |
|
|
9294
9337
|
Creating story from {{documentation_type}}.
|
|
9295
9338
|
{{if missing_context}}: May need to gather additional context from user during story creation.
|
|
9296
|
-
|
|
9339
|
+
|
|
9297
9340
|
complete: "All planning artifacts validated and development can begin. Stories will be created based on available documentation format."
|
|
9298
9341
|
==================== END: .bmad-core/workflows/brownfield-fullstack.yaml ====================
|
|
9299
9342
|
|
|
@@ -9427,7 +9470,7 @@ workflow:
|
|
|
9427
9470
|
notes: |
|
|
9428
9471
|
All stories implemented and reviewed!
|
|
9429
9472
|
Project development phase complete.
|
|
9430
|
-
|
|
9473
|
+
|
|
9431
9474
|
Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
|
|
9432
9475
|
|
|
9433
9476
|
flow_diagram: |
|
|
@@ -9624,7 +9667,7 @@ workflow:
|
|
|
9624
9667
|
notes: |
|
|
9625
9668
|
All stories implemented and reviewed!
|
|
9626
9669
|
Project development phase complete.
|
|
9627
|
-
|
|
9670
|
+
|
|
9628
9671
|
Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
|
|
9629
9672
|
|
|
9630
9673
|
flow_diagram: |
|
|
@@ -9849,7 +9892,7 @@ workflow:
|
|
|
9849
9892
|
notes: |
|
|
9850
9893
|
All stories implemented and reviewed!
|
|
9851
9894
|
Project development phase complete.
|
|
9852
|
-
|
|
9895
|
+
|
|
9853
9896
|
Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
|
|
9854
9897
|
|
|
9855
9898
|
flow_diagram: |
|
|
@@ -10068,7 +10111,7 @@ workflow:
|
|
|
10068
10111
|
notes: |
|
|
10069
10112
|
All stories implemented and reviewed!
|
|
10070
10113
|
Service development phase complete.
|
|
10071
|
-
|
|
10114
|
+
|
|
10072
10115
|
Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
|
|
10073
10116
|
|
|
10074
10117
|
flow_diagram: |
|
|
@@ -10296,7 +10339,7 @@ workflow:
|
|
|
10296
10339
|
notes: |
|
|
10297
10340
|
All stories implemented and reviewed!
|
|
10298
10341
|
Project development phase complete.
|
|
10299
|
-
|
|
10342
|
+
|
|
10300
10343
|
Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
|
|
10301
10344
|
|
|
10302
10345
|
flow_diagram: |
|