bmad-method 4.12.0 → 4.14.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (41) hide show
  1. package/CHANGELOG.md +14 -0
  2. package/CONTRIBUTING.md +128 -1
  3. package/GUIDING-PRINCIPLES.md +85 -0
  4. package/README.md +56 -6
  5. package/bmad-core/agents/analyst.md +3 -1
  6. package/bmad-core/agents/dev.md +3 -2
  7. package/bmad-core/agents/qa.md +15 -14
  8. package/bmad-core/data/bmad-kb.md +280 -19
  9. package/bmad-core/tasks/document-project.md +250 -322
  10. package/bmad-core/tasks/review-story.md +135 -0
  11. package/bmad-core/templates/story-tmpl.md +8 -0
  12. package/bmad-core/workflows/brownfield-fullstack.yml +36 -1
  13. package/bmad-core/workflows/brownfield-service.yml +36 -1
  14. package/bmad-core/workflows/brownfield-ui.yml +36 -1
  15. package/bmad-core/workflows/greenfield-fullstack.yml +36 -1
  16. package/bmad-core/workflows/greenfield-service.yml +36 -1
  17. package/bmad-core/workflows/greenfield-ui.yml +36 -1
  18. package/dist/agents/analyst.txt +227 -17
  19. package/dist/agents/bmad-master.txt +260 -24
  20. package/dist/agents/bmad-orchestrator.txt +227 -17
  21. package/dist/agents/dev.txt +6 -4
  22. package/dist/agents/pm.txt +25 -7
  23. package/dist/agents/po.txt +33 -7
  24. package/dist/agents/qa.txt +153 -14
  25. package/dist/agents/sm.txt +8 -0
  26. package/dist/expansion-packs/expansion-creator/agents/bmad-the-creator.txt +4 -12
  27. package/dist/teams/team-all.txt +635 -48
  28. package/dist/teams/team-fullstack.txt +476 -30
  29. package/dist/teams/team-ide-minimal.txt +419 -42
  30. package/dist/teams/team-no-ui.txt +332 -26
  31. package/docs/expansion-pack-ideas.md +121 -0
  32. package/docs/expansion-packs.md +265 -0
  33. package/docs/working-in-the-brownfield.md +362 -0
  34. package/expansion-packs/expansion-creator/tasks/create-agent.md +1 -1
  35. package/expansion-packs/expansion-creator/tasks/generate-expansion-pack.md +3 -11
  36. package/package.json +1 -1
  37. package/tools/installer/bin/bmad.js +12 -11
  38. package/tools/installer/config/install.config.yml +8 -3
  39. package/tools/installer/lib/ide-setup.js +71 -0
  40. package/tools/installer/package.json +1 -1
  41. package/tools/upgraders/v3-to-v4-upgrader.js +1 -0
package/CHANGELOG.md CHANGED
@@ -1,3 +1,17 @@
1
+ # [4.14.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.13.0...v4.14.0) (2025-06-25)
2
+
3
+
4
+ ### Features
5
+
6
+ * enhance QA agent as senior developer with code review capabilities and major brownfield improvements ([3af3d33](https://github.com/bmadcode/BMAD-METHOD/commit/3af3d33d4a40586479a382620687fa99a9f6a5f7))
7
+
8
+ # [4.13.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.12.0...v4.13.0) (2025-06-24)
9
+
10
+
11
+ ### Features
12
+
13
+ * **ide-setup:** add support for Cline IDE and configuration rules ([#262](https://github.com/bmadcode/BMAD-METHOD/issues/262)) ([913dbec](https://github.com/bmadcode/BMAD-METHOD/commit/913dbeced60ad65086df6233086d83a51ead81a9))
14
+
1
15
  # [4.12.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.11.0...v4.12.0) (2025-06-23)
2
16
 
3
17
 
package/CONTRIBUTING.md CHANGED
@@ -4,6 +4,8 @@ Thank you for considering contributing to this project! This document outlines t
4
4
 
5
5
  🆕 **New to GitHub or pull requests?** Check out our [beginner-friendly Pull Request Guide](docs/how-to-contribute-with-pull-requests.md) first!
6
6
 
7
+ 📋 **Before contributing**, please read our [Guiding Principles](GUIDING-PRINCIPLES.md) to understand the BMAD Method's core philosophy and architectural decisions.
8
+
7
9
  Also note, we use the discussions feature in GitHub to have a community to discuss potential ideas, uses, additions and enhancements.
8
10
 
9
11
  ## Code of Conduct
@@ -26,6 +28,65 @@ By participating in this project, you agree to abide by our Code of Conduct. Ple
26
28
 
27
29
  Please only propose small granular commits! If its large or significant, please discuss in the discussions tab and open up an issue first. I do not want you to waste your time on a potentially very large PR to have it rejected because it is not aligned or deviates from other planned changes. Communicate and lets work together to build and improve this great community project!
28
30
 
31
+ **Important**: All contributions must align with our [Guiding Principles](GUIDING-PRINCIPLES.md). Key points:
32
+
33
+ - Keep dev agents lean - they need context for coding, not documentation
34
+ - Web/planning agents can be larger with more complex tasks
35
+ - Everything is natural language (markdown) - no code in core framework
36
+ - Use expansion packs for domain-specific features
37
+
38
+ #### Which Branch for Your PR?
39
+
40
+ **Submit to `next` branch** (most contributions):
41
+
42
+ - ✨ New features or agents
43
+ - 🎨 Enhancements to existing features
44
+ - 📚 Documentation updates
45
+ - ♻️ Code refactoring
46
+ - ⚡ Performance improvements
47
+ - 🧪 New tests
48
+ - 🎁 New expansion packs
49
+
50
+ **Submit to `main` branch** (critical only):
51
+
52
+ - 🚨 Critical bug fixes that break basic functionality
53
+ - 🔒 Security patches
54
+ - 📚 Fixing dangerously incorrect documentation
55
+ - 🐛 Bugs preventing installation or basic usage
56
+
57
+ **When in doubt, submit to `next`**. We'd rather test changes thoroughly before they hit stable.
58
+
59
+ #### PR Size Guidelines
60
+
61
+ - **Ideal PR size**: 200-400 lines of code changes
62
+ - **Maximum PR size**: 800 lines (excluding generated files)
63
+ - **One feature/fix per PR**: Each PR should address a single issue or add one feature
64
+ - **If your change is larger**: Break it into multiple smaller PRs that can be reviewed independently
65
+ - **Related changes**: Even related changes should be separate PRs if they deliver independent value
66
+
67
+ #### Breaking Down Large PRs
68
+
69
+ If your change exceeds 800 lines, use this checklist to split it:
70
+
71
+ - [ ] Can I separate the refactoring from the feature implementation?
72
+ - [ ] Can I introduce the new API/interface in one PR and implementation in another?
73
+ - [ ] Can I split by file or module?
74
+ - [ ] Can I create a base PR with shared utilities first?
75
+ - [ ] Can I separate test additions from implementation?
76
+ - [ ] Even if changes are related, can they deliver value independently?
77
+ - [ ] Can these changes be merged in any order without breaking things?
78
+
79
+ Example breakdown:
80
+
81
+ 1. PR #1: Add utility functions and types (100 lines)
82
+ 2. PR #2: Refactor existing code to use utilities (200 lines)
83
+ 3. PR #3: Implement new feature using refactored code (300 lines)
84
+ 4. PR #4: Add comprehensive tests (200 lines)
85
+
86
+ **Note**: PRs #1 and #4 could be submitted simultaneously since they deliver independent value and don't depend on each other's merge order.
87
+
88
+ #### Pull Request Steps
89
+
29
90
  1. Fork the repository
30
91
  2. Create a new branch (`git checkout -b feature/your-feature-name`)
31
92
  3. Make your changes
@@ -34,9 +95,75 @@ Please only propose small granular commits! If its large or significant, please
34
95
  6. Push to your branch (`git push origin feature/your-feature-name`)
35
96
  7. Open a Pull Request against the main branch
36
97
 
98
+ ## Pull Request Description Guidelines
99
+
100
+ Keep PR descriptions short and to the point following this template:
101
+
102
+ ### PR Description Template
103
+
104
+ Keep your PR description concise and focused. Use this template:
105
+
106
+ ```markdown
107
+ ## What
108
+
109
+ [1-2 sentences describing WHAT changed]
110
+
111
+ ## Why
112
+
113
+ [1-2 sentences explaining WHY this change is needed]
114
+
115
+ ## How
116
+
117
+ [2-3 bullets listing HOW you implemented it]
118
+
119
+ -
120
+ -
121
+ -
122
+
123
+ ## Testing
124
+
125
+ [1-2 sentences on how you tested this]
126
+ ```
127
+
128
+ **Maximum PR description length: 200 words** (excluding code examples if needed)
129
+
130
+ ### Good vs Bad PR Descriptions
131
+
132
+ ❌ **Bad Example:**
133
+
134
+ > This revolutionary PR introduces a paradigm-shifting enhancement to the system's architecture by implementing a state-of-the-art solution that leverages cutting-edge methodologies to optimize performance metrics and deliver unprecedented value to stakeholders through innovative approaches...
135
+
136
+ ✅ **Good Example:**
137
+
138
+ > **What:** Added validation for agent dependency resolution
139
+ > **Why:** Build was failing silently when agents had circular dependencies
140
+ > **How:**
141
+ >
142
+ > - Added cycle detection in dependency-resolver.js
143
+ > - Throws clear error with dependency chain
144
+ > **Testing:** Tested with circular deps between 3 agents
145
+
37
146
  ## Commit Message Convention
38
147
 
39
- PRs with a wall of AI Generated marketing hype that is unclear in what is being proposed will be closed and rejected. Your best change to contribute is with a small clear PR description explaining, what is the issue being solved or gap in the system being filled. Also explain how it leads to the core guiding principles of the project.
148
+ Use conventional commits format:
149
+
150
+ - `feat:` New feature
151
+ - `fix:` Bug fix
152
+ - `docs:` Documentation only
153
+ - `refactor:` Code change that neither fixes a bug nor adds a feature
154
+ - `test:` Adding missing tests
155
+ - `chore:` Changes to build process or auxiliary tools
156
+
157
+ Keep commit messages under 72 characters.
158
+
159
+ ### Atomic Commits
160
+
161
+ Each commit should represent one logical change:
162
+
163
+ - **Do:** One bug fix per commit
164
+ - **Do:** One feature addition per commit
165
+ - **Don't:** Mix refactoring with bug fixes
166
+ - **Don't:** Combine unrelated changes
40
167
 
41
168
  ## Code Style
42
169
 
@@ -0,0 +1,85 @@
1
+ # BMAD Method Guiding Principles
2
+
3
+ The BMAD Method is a natural language framework for AI-assisted software development. These principles ensure contributions maintain the method's effectiveness.
4
+
5
+ ## Core Principles
6
+
7
+ ### 1. Dev Agents Must Be Lean
8
+
9
+ - **Minimize dev agent dependencies**: Development agents that work in IDEs must have minimal context overhead
10
+ - **Save context for code**: Every line counts - dev agents should focus on coding, not documentation
11
+ - **Web agents can be larger**: Planning agents (PRD Writer, Architect) used in web UI can have more complex tasks and dependencies
12
+ - **Small files, loaded on demand**: Multiple small, focused files are better than large files with many branches
13
+
14
+ ### 2. Natural Language First
15
+
16
+ - **Everything is markdown**: Agents, tasks, templates - all written in plain English
17
+ - **No code in core**: The framework itself contains no programming code, only natural language instructions
18
+ - **Self-contained templates**: Templates include their own generation instructions using `[[LLM: ...]]` markup
19
+
20
+ ### 3. Agent and Task Design
21
+
22
+ - **Agents define roles**: Each agent is a persona with specific expertise (e.g., Frontend Developer, API Developer)
23
+ - **Tasks are procedures**: Step-by-step instructions an agent follows to complete work
24
+ - **Templates are outputs**: Structured documents with embedded instructions for generation
25
+ - **Dependencies matter**: Explicitly declare only what's needed
26
+
27
+ ## Practical Guidelines
28
+
29
+ ### When to Add to Core
30
+
31
+ - Universal software development needs only
32
+ - Doesn't bloat dev agent contexts
33
+ - Follows existing agent/task/template patterns
34
+
35
+ ### When to Create Expansion Packs
36
+
37
+ - Domain-specific needs beyond software development
38
+ - Non-technical domains (business, wellness, education, creative)
39
+ - Specialized technical domains (games, infrastructure, mobile)
40
+ - Heavy documentation or knowledge bases
41
+ - Anything that would bloat core agents
42
+
43
+ See [Expansion Packs Guide](../docs/expansion-packs.md) for detailed examples and ideas.
44
+
45
+ ### Agent Design Rules
46
+
47
+ 1. **Web/Planning Agents**: Can have richer context, multiple tasks, extensive templates
48
+ 2. **Dev Agents**: Minimal dependencies, focused on code generation, lean task sets
49
+ 3. **All Agents**: Clear persona, specific expertise, well-defined capabilities
50
+
51
+ ### Task Writing Rules
52
+
53
+ 1. Write clear step-by-step procedures
54
+ 2. Use markdown formatting for readability
55
+ 3. Keep dev agent tasks focused and concise
56
+ 4. Planning tasks can be more elaborate
57
+ 5. **Prefer multiple small tasks over one large branching task**
58
+ - Instead of one task with many conditional paths
59
+ - Create multiple focused tasks the agent can choose from
60
+ - This keeps context overhead minimal
61
+ 6. **Reuse common tasks** - Don't create new document creation tasks
62
+ - Use the existing `create-doc` task
63
+ - Pass the appropriate template with embedded LLM instructions
64
+ - This maintains consistency and reduces duplication
65
+
66
+ ### Template Rules
67
+
68
+ 1. Include generation instructions with `[[LLM: ...]]` markup
69
+ 2. Provide clear structure for output
70
+ 3. Make templates reusable across agents
71
+ 4. Use standardized markup elements:
72
+ - `{{placeholders}}` for variables to be replaced
73
+ - `[[LLM: instructions]]` for AI-only processing (never shown to users)
74
+ - `REPEAT` sections for repeatable content blocks
75
+ - `^^CONDITION^^` blocks for conditional content
76
+ - `@{examples}` for guidance examples (never output to users)
77
+ 5. NEVER display template markup or LLM instructions to users
78
+ 6. Focus on clean output - all processing instructions stay internal
79
+
80
+ ## Remember
81
+
82
+ - The power is in natural language orchestration, not code
83
+ - Dev agents code, planning agents plan
84
+ - Keep dev agents lean for maximum coding efficiency
85
+ - Expansion packs handle specialized domains
package/README.md CHANGED
@@ -188,14 +188,14 @@ The reason #2 and 3 are optional is because now BMad V4 makes sharding optional
188
188
 
189
189
  This configuration file tells BMAD agents exactly where to find your project documents and how they're structured. It's the key to V4's flexibility and backwards compatibility.
190
190
 
191
- #### Key Features:
191
+ #### Key Features
192
192
 
193
193
  - **Version Awareness**: Agents understand if your PRD/Architecture follows V4 conventions or earlier versions
194
194
  - **Flexible Document Locations**: Works whether your epics are embedded in PRD or properly sharded
195
195
  - **Developer Context**: Define which files the dev agent should always load
196
196
  - **Debug Support**: Built-in logging for troubleshooting story implementation
197
197
 
198
- #### Why It Matters:
198
+ #### Why It Matters
199
199
 
200
200
  - **Use BMAD with ANY project structure** - V3, V4, or custom layouts
201
201
  - **No forced migrations** - Keep your existing document organization
@@ -241,7 +241,7 @@ tools/
241
241
  ├── installer/ # NPX installer
242
242
  └── lib/ # Build utilities
243
243
 
244
- expansion-packs/ # Optional add-ons (DevOps, Mobile, etc.)
244
+ expansion-packs/ # Domain-specific add-ons (Technical & Non-Technical)
245
245
 
246
246
  dist/ # 📦 PRE-BUILT BUNDLES (Ready to use!)
247
247
  ├── agents/ # Individual agent bundles (.txt files)
@@ -289,12 +289,60 @@ Rich templates for all document types:
289
289
 
290
290
  Ask the agent you are using for help with /help (in the web) or \*help in the ide to see what commands are available!
291
291
 
292
+ ## Expansion Packs - Beyond Software Development
293
+
294
+ BMAD Method's natural language framework isn't limited to software development. Create specialized agents for ANY domain:
295
+
296
+ ### Technical Expansion Packs
297
+
298
+ - 🎮 **Game Development** - Game designers, level creators, narrative writers
299
+ - 🏗️ **Infrastructure/DevOps** - Cloud architects, security specialists, SRE agents
300
+ - 📱 **Mobile Development** - iOS/Android specialists, UX designers
301
+ - 🔗 **Blockchain/Web3** - Smart contract developers, DeFi architects
302
+
303
+ ### Non-Technical Expansion Packs
304
+
305
+ - 💼 **Business Strategy** - Strategic planners, market analysts, business coaches
306
+ - 💪 **Health & Wellness** - Fitness coaches, nutrition advisors, meditation guides
307
+ - 🎨 **Creative Arts** - Story writers, world builders, character developers
308
+ - 📚 **Education** - Curriculum designers, tutors, learning coaches
309
+ - 🧠 **Personal Development** - Life coaches, goal setters, habit builders
310
+ - 🏢 **Professional Services** - Legal advisors, medical protocols, research assistants
311
+
312
+ ### Creating Your Own Expansion Pack
313
+
314
+ The BMAD framework can support any domain where structured AI assistance is valuable:
315
+
316
+ 1. Define specialized agents with domain expertise
317
+ 2. Create task procedures for common workflows
318
+ 3. Build templates for domain-specific outputs
319
+ 4. Package as an expansion pack for others to use
320
+
321
+ 📖 **[Read the full Expansion Packs Guide](docs/expansion-packs.md)** for detailed examples and inspiration!
322
+
323
+ 🛠️ **[Use the Expansion Pack Creator](expansion-packs/expansion-creator/README.md)** to build your own!
324
+
292
325
  ## Contributing
293
326
 
294
- We welcome contributions!
327
+ **We're excited about contributions and welcome your ideas, improvements, and expansion packs!** 🎉
328
+
329
+ ### Before Contributing - MUST READ
330
+
331
+ To ensure your contribution aligns with the BMAD Method and gets merged smoothly:
332
+
333
+ 1. 📋 **Read [CONTRIBUTING.md](CONTRIBUTING.md)** - Our contribution guidelines, PR requirements, and process
334
+ 2. 🎯 **Read [GUIDING-PRINCIPLES.md](GUIDING-PRINCIPLES.md)** - Core principles that keep BMAD powerful through simplicity
335
+ 3. 🆕 **New to GitHub?** Start with our [Pull Request Guide](docs/how-to-contribute-with-pull-requests.md)
336
+
337
+ ### Key Points to Remember
338
+
339
+ - Keep dev agents lean (save context for coding!)
340
+ - Use small, focused files over large branching ones
341
+ - Reuse existing tasks (like `create-doc`) instead of creating duplicates
342
+ - Consider expansion packs for domain-specific features
343
+ - All contributions must follow our natural language, markdown-based approach
295
344
 
296
- - 🆕 **New to GitHub?** Start with our [Pull Request Guide](docs/how-to-contribute-with-pull-requests.md)
297
- - See [CONTRIBUTING.md](CONTRIBUTING.md) for detailed guidelines
345
+ We're building something amazing together - let's keep it simple, powerful, and focused! 💪
298
346
 
299
347
  ### Development Setup
300
348
 
@@ -310,10 +358,12 @@ npm install
310
358
 
311
359
  - 🏗️ [Core Architecture](docs/core-architecture.md) - Complete technical architecture and system design
312
360
  - 📖 [User Guide](docs/user-guide.md) - Comprehensive guide to using BMAD-METHOD effectively
361
+ - 🚀 [Expansion Packs Guide](docs/expansion-packs.md) - Extend BMAD to any domain beyond software development
313
362
 
314
363
  ### Workflow Guides
315
364
 
316
365
  - 📚 [Universal BMAD Workflow Guide](docs/bmad-workflow-guide.md) - Core workflow that applies to all IDEs
366
+ - 🏗️ [Working in the Brownfield Guide](docs/working-in-the-brownfield.md) - Complete guide for enhancing existing projects
317
367
  - 🎯 [Cursor Guide](docs/cursor-guide.md) - Complete workflow for Cursor users
318
368
  - 🤖 [Claude Code Guide](docs/claude-code-guide.md) - Complete workflow for Claude Code users
319
369
  - 🌊 [Windsurf Guide](docs/windsurf-guide.md) - Complete workflow for Windsurf users
@@ -16,7 +16,7 @@ agent:
16
16
  id: analyst
17
17
  title: Business Analyst
18
18
  icon: 📊
19
- whenToUse: Use for market research, brainstorming, competitive analysis, creating project briefs, and initial project discovery
19
+ whenToUse: Use for market research, brainstorming, competitive analysis, creating project briefs, initial project discovery, and documenting existing projects (brownfield)
20
20
  customization: null
21
21
  persona:
22
22
  role: Insightful Analyst & Strategic Ideation Partner
@@ -44,6 +44,7 @@ commands: # All commands require * prefix when used (e.g., *help)
44
44
  - brainstorm {topic}: Facilitate structured brainstorming session
45
45
  - research {topic}: Generate deep research prompt for investigation
46
46
  - elicit: Run advanced elicitation to clarify requirements
47
+ - document-project: Analyze and document existing project structure comprehensively
47
48
  - exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
48
49
  dependencies:
49
50
  tasks:
@@ -51,6 +52,7 @@ dependencies:
51
52
  - create-deep-research-prompt
52
53
  - create-doc
53
54
  - advanced-elicitation
55
+ - document-project
54
56
  templates:
55
57
  - project-brief-tmpl
56
58
  - market-research-tmpl
@@ -52,9 +52,10 @@ task-execution:
52
52
  - "Debug Log: | Task | File | Change | Reverted? |"
53
53
  - "Completion Notes: Deviations only, <50 words"
54
54
  - "Change Log: Requirement changes only"
55
+ - "File List: CRITICAL - Maintain complete list of ALL files created/modified during implementation"
55
56
  blocking: "Unapproved deps | Ambiguous after story check | 3 failures | Missing config | Failing validations"
56
- done: "Code matches reqs + All validations pass + Follows standards"
57
- completion: "All [x]→Validations pass→Integration(if noted)→E2E(if noted)→DoD→Summary→HALT"
57
+ done: "Code matches reqs + All validations pass + Follows standards + File List complete"
58
+ completion: "All [x]→Validations pass→Integration(if noted)→E2E(if noted)→DoD→Update File ListMark Ready for Review→HALT"
58
59
 
59
60
  dependencies:
60
61
  tasks:
@@ -14,34 +14,35 @@ activation-instructions:
14
14
  agent:
15
15
  name: Quinn
16
16
  id: qa
17
- title: Quality Assurance Test Architect
17
+ title: Senior Developer & QA Architect
18
18
  icon: 🧪
19
- whenToUse: Use for test planning, test case creation, quality assurance, bug reporting, and testing strategy
19
+ whenToUse: Use for senior code review, refactoring, test planning, quality assurance, and mentoring through code improvements
20
20
  customization: null
21
21
  persona:
22
- role: Test Architect & Automation Expert
23
- style: Methodical, detail-oriented, quality-focused, strategic
24
- identity: Senior quality advocate with expertise in test architecture and automation
25
- focus: Comprehensive testing strategies, automation frameworks, quality assurance at every phase
22
+ role: Senior Developer & Test Architect
23
+ style: Methodical, detail-oriented, quality-focused, mentoring, strategic
24
+ identity: Senior developer with deep expertise in code quality, architecture, and test automation
25
+ focus: Code excellence through review, refactoring, and comprehensive testing strategies
26
26
  core_principles:
27
+ - Senior Developer Mindset - Review and improve code as a senior mentoring juniors
28
+ - Active Refactoring - Don't just identify issues, fix them with clear explanations
27
29
  - Test Strategy & Architecture - Design holistic testing strategies across all levels
28
- - Automation Excellence - Build maintainable and efficient test automation frameworks
30
+ - Code Quality Excellence - Enforce best practices, patterns, and clean code principles
29
31
  - Shift-Left Testing - Integrate testing early in development lifecycle
32
+ - Performance & Security - Proactively identify and fix performance/security issues
33
+ - Mentorship Through Action - Explain WHY and HOW when making improvements
30
34
  - Risk-Based Testing - Prioritize testing based on risk and critical areas
31
- - Performance & Load Testing - Ensure systems meet performance requirements
32
- - Security Testing Integration - Incorporate security testing into QA process
33
- - Test Data Management - Design strategies for realistic and compliant test data
34
- - Continuous Testing & CI/CD - Integrate tests seamlessly into pipelines
35
- - Quality Metrics & Reporting - Track meaningful metrics and provide insights
36
- - Cross-Browser & Cross-Platform Testing - Ensure comprehensive compatibility
35
+ - Continuous Improvement - Balance perfection with pragmatism
36
+ - Architecture & Design Patterns - Ensure proper patterns and maintainable code structure
37
37
  startup:
38
38
  - Greet the user with your name and role, and inform of the *help command.
39
39
  commands: # All commands require * prefix when used (e.g., *help)
40
40
  - help: Show numbered list of the following commands to allow selection
41
41
  - chat-mode: (Default) QA consultation with advanced-elicitation for test strategy
42
- - create-doc {template}: Create doc (no template = show available templates)
43
42
  - exit: Say goodbye as the QA Test Architect, and then abandon inhabiting this persona
44
43
  dependencies:
44
+ tasks:
45
+ - review-story
45
46
  data:
46
47
  - technical-preferences
47
48
  utils: