Compare commits

...

71 Commits

Author SHA1 Message Date
manjaroblack
2a9e07d4fd chore: add code formatting config and pre-commit hooks 2025-08-16 19:00:08 -05:00
Brian Madison
51284d6ecf fix: handle existing tags in promote-to-stable workflow
- Check for existing git tags when calculating new version
- Automatically increment version if tag already exists
- Prevents workflow failure when tag v5.1.0 already exists
2025-08-16 17:14:38 -05:00
Brian Madison
6cba05114e fix: stable tag 2025-08-16 17:10:10 -05:00
Murat K Ozcan
ac360cd0bf chore: configure changelog file path in semantic-release config (#448)
Co-authored-by: Murat Ozcan <murat@Murats-MacBook-Pro.local>
2025-08-16 16:27:45 -05:00
manjaroblack
fab9d5e1f5 feat(flattener): prompt for detailed stats; polish .stats.md with emojis (#422)
* feat: add detailed statistics and markdown report generation to flattener tool

* fix: remove redundant error handling for project root detection
2025-08-16 08:03:28 -05:00
Brian Madison
93426c2d2f feat: publish stable release 5.0.0
BREAKING CHANGE: Promote beta features to stable release for v5.0.0

This commit ensures the stable release gets properly published to NPM and GitHub releases.
2025-08-15 23:06:28 -05:00
github-actions[bot]
f56d37a60a release: promote to stable 5.0.0
- Promote beta features to stable release
- Update version from 4.38.0 to 5.0.0
- Automated promotion via GitHub Actions
2025-08-15 23:06:28 -05:00
github-actions[bot]
224cfc05dc release: promote to stable 4.38.0
- Promote beta features to stable release
- Update version from 4.37.0 to 4.38.0
- Automated promotion via GitHub Actions
2025-08-15 23:06:27 -05:00
Brian Madison
6cb2fa68b3 fix: update package-lock.json for semver dependency 2025-08-15 23:06:27 -05:00
Brian Madison
d21ac491a0 release: create stable 4.37.0 release
Promote beta features to stable release with dual publishing support
2025-08-15 23:06:27 -05:00
Thiago Freitas
848e33fdd9 Feature: Installer commands for Crush CLI (#429)
* feat: add support for Crush IDE configuration and commands

* fix: update Crush IDE instructions for clarity on persona/task switching

---------

Co-authored-by: Brian <bmadcode@gmail.com>
2025-08-15 22:38:44 -05:00
Murat K Ozcan
0b61175d98 feat: transform QA agent into Test Architect with advanced quality ca… (#433)
* feat: transform QA agent into Test Architect with advanced quality capabilities

  - Add 6 specialized quality assessment commands
  - Implement risk-based testing with scoring
  - Create quality gate system with deterministic decisions
  - Add comprehensive test design and NFR validation
  - Update documentation with stage-based workflow integration

* feat: transform QA agent into Test Architect with advanced quality capabilities

  - Add 6 specialized quality assessment commands
  - Implement risk-based testing with scoring
  - Create quality gate system with deterministic decisions
  - Add comprehensive test design and NFR validation
  - Update documentation with stage-based workflow integration

* docs: refined the docs for test architect

* fix: addressed review comments from manjaroblack, round 1

* fix: addressed review comments from manjaroblack, round 1

---------

Co-authored-by: Murat Ozcan <murat@mac.lan>
Co-authored-by: Brian <bmadcode@gmail.com>
2025-08-15 21:02:37 -05:00
cecil-the-coder
33269c888d fix: resolve CommonJS import compatibility for chalk, inquirer, and ora (#442)
Adds .default fallback for CommonJS imports to resolve compatibility issues
with newer versions of chalk, inquirer, and ora packages.

Fixes installer failures when error handlers or interactive prompts are triggered.

Changes:
- chalk: require('chalk').default || require('chalk')
- inquirer: require('inquirer').default || require('inquirer')
- ora: require('ora').default || require('ora')

Affects: installer.js, ide-setup.js, file-manager.js, ide-base-setup.js, bmad.js

Co-authored-by: Cecil <cecilthecoder@gmail.com>
2025-08-15 21:01:30 -05:00
Brian Madison
7f016d0020 fix: add permissions and authentication for promotion workflow
- Add contents:write permission for GitHub Actions
- Configure git to use GITHUB_TOKEN for authentication
- Set remote URL with access token for push operations
- This should resolve the 403 permission denied error
2025-08-15 20:25:12 -05:00
Brian Madison
8b0b72b7b4 docs: document dual publishing strategy and automated promotion
- Add comprehensive documentation for dual publishing workflow
- Document GitHub Actions promotion process
- Clarify user experience for stable vs beta installations
- Include step-by-step promotion instructions
2025-08-15 20:18:36 -05:00
Brian Madison
1c3420335b test: trigger beta release to test current workflow
This will create a new beta version that we can then promote to stable using the new automated workflow
2025-08-15 20:17:58 -05:00
Brian Madison
fb02234b59 feat: add automated promotion workflow for stable releases
- Add GitHub Actions workflow for one-click promotion to stable
- Supports patch/minor/major version bumps
- Automatically merges main to stable and handles version updates
- Eliminates manual git operations for stable releases
2025-08-15 20:17:49 -05:00
Brian Madison
e0dcbcf527 fix: update versions for dual publishing beta releases 2025-08-15 20:03:10 -05:00
Brian Madison
75ba8d82e1 feat: republish beta with corrected dependencies and tags 2025-08-15 19:39:35 -05:00
Brian Madison
f3e429d746 feat: trigger new beta release with fixed dependencies
This creates a new beta version that includes the semver dependency fix
2025-08-15 19:38:06 -05:00
Brian Madison
5ceca3aeb9 fix: add semver dependency and correct NPM dist-tag configuration
- Add missing semver dependency to installer package.json
- Configure semantic-release to use correct channels (beta/latest)
- This ensures beta releases publish to @beta tag correctly
2025-08-15 19:33:07 -05:00
Brian Madison
8e324f60b0 fix: remove git plugin to resolve branch protection conflicts
- Beta releases don't need to commit version bumps back to repo
- This allows semantic-release to complete successfully
- NPM publishing will still work for @beta tag
2025-08-15 19:15:55 -05:00
Brian Madison
8a29f0e319 test: verify dual publishing workflow 2025-08-15 19:14:32 -05:00
Brian Madison
d92ba835fa feat: implement dual NPM publishing strategy
- Configure semantic-release for @beta and @latest tags
- Main branch publishes to @beta (bleeding edge)
- Stable branch publishes to @latest (production)
- Enable CI/CD workflow for both branches
2025-08-15 19:03:48 -05:00
Aaron
9868437f10 Add update-check command (#423)
* Add update-check command

* Adding additional information to update-check command and aligning with cli theme

* Correct update-check message to exclude global
2025-08-14 22:24:37 -05:00
Stefan Klümpers
d563266b97 feat: install Cursor rules to subdirectory (#438)
* feat: install Cursor rules to subdirectory

Implement feature request #376 to avoid filename collisions and confusion
between repo-specific and BMAD-specific rules.

Changes:
- Move Cursor rules from .cursor/rules/ to .cursor/rules/bmad/
- Update installer configuration to use new subdirectory structure
- Update upgrader to reflect new rule directory path

This keeps BMAD Method files separate from existing project rules,
reducing chance of conflicts and improving organization.

Fixes #376

* chore: correct formatting in cursor rules directory path

---------

Co-authored-by: Stefan Klümpers <stefan.kluempers@materna.group>
2025-08-14 22:23:44 -05:00
Yongjip Kim
3efcfd54d4 fix(docs): fix broken link in GUIDING-PRINCIPLES.md (#428)
Co-authored-by: Brian <bmadcode@gmail.com>
2025-08-14 13:40:11 -05:00
Benjamin Wiese
31e44b110e Remove bmad-core/bmad-core including empty file (#431)
Co-authored-by: Ben Wiese <benjamin.wiese@simplifier.io>
2025-08-14 13:39:28 -05:00
semantic-release-bot
ffcb4d4bf2 chore(release): 4.36.2 [skip ci]
## [4.36.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.36.1...v4.36.2) (2025-08-10)

### Bug Fixes

* align installer dependencies with root package versions for ESM compatibility ([#420](https://github.com/bmadcode/BMAD-METHOD/issues/420)) ([3f6b674](3f6b67443d))
2025-08-10 14:26:15 +00:00
circus
3f6b67443d fix: align installer dependencies with root package versions for ESM compatibility (#420)
Downgrade chalk, inquirer, and ora in tools/installer to CommonJS-compatible versions:
- chalk: ^5.4.1 -> ^4.1.2
- inquirer: ^12.6.3 -> ^8.2.6
- ora: ^8.2.0 -> ^5.4.1

Resolves 'is not a function' errors caused by ESM/CommonJS incompatibility.
2025-08-10 09:25:46 -05:00
semantic-release-bot
85a0d83fc5 chore(release): 4.36.1 [skip ci]
## [4.36.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.36.0...v4.36.1) (2025-08-09)

### Bug Fixes

* update Node.js version to 20 in release workflow and reduce Discord spam ([3f7e19a](3f7e19a098))
2025-08-09 20:49:42 +00:00
Brian Madison
3f7e19a098 fix: update Node.js version to 20 in release workflow and reduce Discord spam
- Update release workflow Node.js version from 18 to 20 to match package.json requirements
- Remove push trigger from Discord workflow to reduce notification spam

This should resolve the semantic-release content-length header error after org migration.
2025-08-09 15:49:13 -05:00
semantic-release-bot
23df54c955 chore(release): 4.36.0 [skip ci]
# [4.36.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.35.3...v4.36.0) (2025-08-09)

### Features

* modularize flattener tool into separate components with improved project root detection ([#417](https://github.com/bmadcode/BMAD-METHOD/issues/417)) ([0fdbca7](0fdbca73fc))
2025-08-09 20:33:49 +00:00
manjaroblack
0fdbca73fc feat: modularize flattener tool into separate components with improved project root detection (#417) 2025-08-09 15:33:23 -05:00
Daniel Willitzer
5d7d7c9015 Merge pull request #369 from antmikinka/pr/part-1-gcp-setup
Feat(Expansion Pack): Part 1 - Google Cloud Setup
2025-08-08 19:23:48 -07:00
Brian Madison
dd2b4ed5ac discord PR spam 2025-08-08 20:07:32 -05:00
Lior Assouline
8f40576681 Flatten venv & many other bins dir fix (#408)
* added .venv to ignore list of flattener

* more files pattern to ignore

---------

Co-authored-by: Lior Assouline <Lior.Assouline@harmonicinc.com>
2025-08-08 07:54:47 -05:00
Yanqing Wang
fe86675c5f Update link in README.md (#384) 2025-08-07 07:49:14 -05:00
semantic-release-bot
8211d2daff chore(release): 4.35.3 [skip ci]
## [4.35.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.35.2...v4.35.3) (2025-08-06)

### Bug Fixes

* doc location improvement ([1676f51](1676f5189e))
2025-08-06 05:01:55 +00:00
Brian Madison
1676f5189e fix: doc location improvement 2025-08-06 00:00:26 -05:00
semantic-release-bot
3c3d58939f chore(release): 4.35.2 [skip ci]
## [4.35.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.35.1...v4.35.2) (2025-08-06)

### Bug Fixes

* npx status check ([f7c2a4f](f7c2a4fb6c))
2025-08-06 03:34:49 +00:00
Brian Madison
2d954d3481 merge 2025-08-05 22:34:21 -05:00
Brian Madison
f7c2a4fb6c fix: npx status check 2025-08-05 22:33:47 -05:00
semantic-release-bot
9df28d5313 chore(release): 4.35.1 [skip ci]
## [4.35.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.35.0...v4.35.1) (2025-08-06)

### Bug Fixes

* npx hanging commands ([2cf322e](2cf322ee0d))
2025-08-06 03:22:35 +00:00
Brian Madison
2cf322ee0d fix: npx hanging commands 2025-08-05 22:22:04 -05:00
semantic-release-bot
5dc4043577 chore(release): 4.35.0 [skip ci]
# [4.35.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.34.0...v4.35.0) (2025-08-04)

### Features

* add qwen-code ide support to bmad installer. ([#392](https://github.com/bmadcode/BMAD-METHOD/issues/392)) ([a72b790](a72b790f3b))
2025-08-04 01:24:35 +00:00
Houston Zhang
a72b790f3b feat: add qwen-code ide support to bmad installer. (#392)
Co-authored-by: Djanghao <hstnz>
2025-08-03 20:24:09 -05:00
semantic-release-bot
55f834954f chore(release): 4.34.0 [skip ci]
# [4.34.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.33.1...v4.34.0) (2025-08-03)

### Features

* add KiloCode integration support to BMAD installer ([#390](https://github.com/bmadcode/BMAD-METHOD/issues/390)) ([dcebe91](dcebe91d5e))
2025-08-03 14:50:09 +00:00
Mbosinwa Awunor
dcebe91d5e feat: add KiloCode integration support to BMAD installer (#390) 2025-08-03 09:49:39 -05:00
caseyrubin
ce5b37b628 Update user-guide.md (#378)
Align pre-dev validation cycle with BMad method.
2025-07-30 22:07:19 -05:00
yaksh gandhi
c079c28dc4 Update README.md (#338) 2025-07-28 21:07:24 -05:00
semantic-release-bot
4fc8e752a6 chore(release): 4.33.1 [skip ci]
## [4.33.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.33.0...v4.33.1) (2025-07-29)

### Bug Fixes

* dev agent yaml syntax for develop-story command ([#362](https://github.com/bmadcode/BMAD-METHOD/issues/362)) ([bcb3728](bcb3728f88))
2025-07-29 02:05:28 +00:00
Duane Cilliers
bcb3728f88 fix: dev agent yaml syntax for develop-story command (#362) 2025-07-28 21:05:00 -05:00
semantic-release-bot
f7963cbaa9 chore(release): 4.33.0 [skip ci]
# [4.33.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.32.0...v4.33.0) (2025-07-28)

### Features

* version bump ([e9dd4e7](e9dd4e7beb))
2025-07-28 04:54:52 +00:00
Brian Madison
e9dd4e7beb feat: version bump 2025-07-27 23:54:23 -05:00
manjaroblack
a80ea150f2 eat: enhance flattener tool with improved CLI integration and custom directory support (#372)
* feat(cli): move flatten command to installer and update docs

Refactor the flatten command from tools/cli.js to tools/installer/bin/bmad.js for better integration. Add support for custom input directory and improve error handling. Update documentation in README.md and working-in-the-brownfield.md to reflect new command usage. Also clean up package-lock.json and add it to .gitignore.

* chore: update gitignore and add package-lock.json for installer tool

Remove package-lock.json from root gitignore since it's now needed for the installer tool
Add package-lock.json with dependencies for the bmad-method installer

---------

Co-authored-by: Devin Stagner <devin@blackstag.family>
2025-07-27 18:02:08 -05:00
antmikinka
c7fc5d3606 Feat(Expansion Pack): Part 1 - Google Cloud Setup 2025-07-27 12:26:53 -07:00
semantic-release-bot
a2ddf926e5 chore(release): 4.32.0 [skip ci]
# [4.32.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.31.0...v4.32.0) (2025-07-27)

### Bug Fixes

* Add package-lock.json to fix GitHub Actions dependency resolution ([cce7a75](cce7a758a6))
* GHA fix ([62ccccd](62ccccdc9e))

### Features

* Overhaul and Enhance 2D Unity Game Dev Expansion Pack ([#350](https://github.com/bmadcode/BMAD-METHOD/issues/350)) ([a7038d4](a7038d43d1))
2025-07-27 03:35:50 +00:00
Brian Madison
62ccccdc9e fix: GHA fix 2025-07-26 22:35:23 -05:00
Brian Madison
cce7a758a6 fix: Add package-lock.json to fix GitHub Actions dependency resolution 2025-07-26 14:59:02 -05:00
manjaroblack
5efbff3227 Feat/flattener-tool (#337)
* This PR introduces a powerful new Codebase Flattener Tool that aggregates entire codebases into AI-optimized XML format, making it easy to share project context with AI assistants for analysis, debugging, and development assistance.

- AI-Optimized XML Output : Generates clean, structured XML specifically designed for AI model consumption
- Smart File Discovery : Recursive file scanning with intelligent filtering using glob patterns
- Binary File Detection : Automatically identifies and excludes binary files, focusing on source code
- Progress Tracking : Real-time progress indicators with comprehensive completion statistics
- Flexible Output : Customizable output file location and naming via CLI arguments
- Gitignore Integration : Automatically respects .gitignore patterns to exclude unnecessary files
- CDATA Handling : Proper XML CDATA sections with escape sequence handling for ]]> patterns
- Content Indentation : Beautiful XML formatting with properly indented file content (4-space indentation)
- Error Handling : Robust error handling with detailed logging for problematic files
- Hierarchical Formatting : Clean XML structure with proper indentation and formatting
- File Content Preservation : Maintains original file formatting within indented CDATA sections
- Exclusion Logic : Prevents self-inclusion of output files ( flattened-codebase.xml , repomix-output.xml )
- tools/flattener/main.js - Complete flattener implementation with CLI interface
- package.json - Added new dependencies (glob, minimatch, fs-extra, commander, ora, chalk)
- package-lock.json - Updated dependency tree
- .gitignore - Added exclusions for flattener outputs
- README.md - Comprehensive documentation with usage examples
- docs/bmad-workflow-guide.md - Integration guidance
- tools/cli.js - CLI integration
- .vscode/settings.json - SonarLint configuration
```
current directory
npm run flatten

npm run flatten -- --output my-project.xml
npm run flatten -- -o /path/to/output/codebase.xml
```
The tool provides comprehensive completion summaries including:

- File count and breakdown (text/binary/errors)
- Source code size and generated XML size
- Total lines of code and estimated token count
- Processing progress and performance metrics
- Bug Fix : Corrected typo in exclusion patterns ( repromix-output.xml → repomix-output.xml )
- Performance : Efficient file processing with streaming and progress indicators
- Reliability : Comprehensive error handling and validation
- Maintainability : Clean, well-documented code with modular functions
- AI Integration : Perfect for sharing codebase context with AI assistants
- Code Reviews : Streamlined code review process with complete project context
- Documentation : Enhanced project documentation and analysis capabilities
- Development Workflow : Improved development assistance and debugging support
This tool significantly enhances the BMad-Method framework's AI integration capabilities, providing developers with a seamless way to share complete project context for enhanced AI-assisted development workflows.

* docs(bmad-core): update documentation for enhanced workflow and user guide

- Fix typos and improve clarity in user guide
- Add new enhanced development workflow documentation
- Update brownfield workflow with flattened codebase instructions
- Improve consistency in documentation formatting

* chore: remove unused files and configurations

- Delete deprecated bmad workflow guide and roomodes file
- Remove sonarlint project configuration
- Downgrade ora dependency version
- Remove jest test script

* Update package.json

Removed jest as it is not needed.

* Update working-in-the-brownfield.md

added documentation for sharding docs

* perf(flattener): improve memory efficiency by streaming xml output

- Replace in-memory XML generation with streaming approach
- Add comprehensive common ignore patterns list
- Update statistics calculation to use file size instead of content length

* fix/chore: Update console.log for user-guide.md install path. Cleaned up config files/folders and updated .gitignore (#347)

* fix: Update console.log for user-guide.md install path

Changed
IMPORTANT: Please read the user guide installed at docs/user-guilde.md
to
IMPORTANT: Please read the user guide installed at .bmad-core/user-guide.md

WHY: the actual install location of the user-guide.md is in the .bmad-core directory.

* chore: remove formatting configs and clean up gitignore

- Delete husky pre-commit hook and prettier config files
- Remove VS Code chat/copilot settings
- Reorganize and clean up gitignore entries

* feat: Overhaul and Enhance 2D Unity Game Dev Expansion Pack (#350)

* Updated game-sm agent to match the new core framework patterns

* feat:Created more comprehensive game story matching new format system as well

* feat:Added Game specific course correct task

* feat:Updated dod-checklist to match new DoD format

* feat:Added new Architect agent for appropriate architecture doc creation and design

* feat:Overhaul of game-architecture-tmpl template

* feat:Updated rest of templates besides level which doesnt really need it

* feat: Finished extended architecture documentation needed for new game story tasks

* feat: Updated game Developer to new format

* feat: Updated last agent to new format and updated bmad-kb. bmad-kb I did my best with but im not sure of it's valid usage in the expansion pack, the AI generated more of the file then myself. I made sure to include it due to the new core-config file

* feat: Finished updating designer agent to new format and cleaned up template linting errors

* Built dist for web bundle

* Increased expansion pack minor verison number

* Updated architecht and design for sharding built-in

* chore: bump bmad-2d-unity-game-dev version (minor)

* updated config.yaml for game-specific pieces to supplement core-config.yaml

* Updated game-core-config and epic processing for game story and game design. Initial implementation was far too generic

* chore: bump bmad-2d-unity-game-dev version (patch)

* feat: Fixed issue with multi-configs being needed. chore: bump bmad-2d-unity-game-dev version (patch)

* Chore: Built web-bundle

* feat: Added the ability to specify the unity editor install location.\nchore: bump bmad-2d-unity-game-dev version (patch)

* feat: core-config must be in two places to support inherited tasks at this time so added instructions to copy and create one in expansion pack folder as well. chore: bump bmad-2d-unity-game-dev version (patch)

* This PR introduces a powerful new Codebase Flattener Tool that aggregates entire codebases into AI-optimized XML format, making it easy to share project context with AI assistants for analysis, debugging, and development assistance.

- AI-Optimized XML Output : Generates clean, structured XML specifically designed for AI model consumption
- Smart File Discovery : Recursive file scanning with intelligent filtering using glob patterns
- Binary File Detection : Automatically identifies and excludes binary files, focusing on source code
- Progress Tracking : Real-time progress indicators with comprehensive completion statistics
- Flexible Output : Customizable output file location and naming via CLI arguments
- Gitignore Integration : Automatically respects .gitignore patterns to exclude unnecessary files
- CDATA Handling : Proper XML CDATA sections with escape sequence handling for ]]> patterns
- Content Indentation : Beautiful XML formatting with properly indented file content (4-space indentation)
- Error Handling : Robust error handling with detailed logging for problematic files
- Hierarchical Formatting : Clean XML structure with proper indentation and formatting
- File Content Preservation : Maintains original file formatting within indented CDATA sections
- Exclusion Logic : Prevents self-inclusion of output files ( flattened-codebase.xml , repomix-output.xml )
- tools/flattener/main.js - Complete flattener implementation with CLI interface
- package.json - Added new dependencies (glob, minimatch, fs-extra, commander, ora, chalk)
- package-lock.json - Updated dependency tree
- .gitignore - Added exclusions for flattener outputs
- README.md - Comprehensive documentation with usage examples
- docs/bmad-workflow-guide.md - Integration guidance
- tools/cli.js - CLI integration
- .vscode/settings.json - SonarLint configuration
```
current directory
npm run flatten

npm run flatten -- --output my-project.xml
npm run flatten -- -o /path/to/output/codebase.xml
```
The tool provides comprehensive completion summaries including:

- File count and breakdown (text/binary/errors)
- Source code size and generated XML size
- Total lines of code and estimated token count
- Processing progress and performance metrics
- Bug Fix : Corrected typo in exclusion patterns ( repromix-output.xml → repomix-output.xml )
- Performance : Efficient file processing with streaming and progress indicators
- Reliability : Comprehensive error handling and validation
- Maintainability : Clean, well-documented code with modular functions
- AI Integration : Perfect for sharing codebase context with AI assistants
- Code Reviews : Streamlined code review process with complete project context
- Documentation : Enhanced project documentation and analysis capabilities
- Development Workflow : Improved development assistance and debugging support
This tool significantly enhances the BMad-Method framework's AI integration capabilities, providing developers with a seamless way to share complete project context for enhanced AI-assisted development workflows.

* chore: remove unused files and configurations

- Delete deprecated bmad workflow guide and roomodes file
- Remove sonarlint project configuration
- Downgrade ora dependency version
- Remove jest test script

* docs: update command names and agent references in documentation

- Change `*create` to `*draft` in workflow guide
- Update PM agent commands to use consistent naming
- Replace `analyst` references with `architect`
- Fix command examples to match new naming conventions

---------

Co-authored-by: PinkyD <paulbeanjr@gmail.com>
2025-07-26 14:56:00 -05:00
PinkyD
a7038d43d1 feat: Overhaul and Enhance 2D Unity Game Dev Expansion Pack (#350)
* Updated game-sm agent to match the new core framework patterns

* feat:Created more comprehensive game story matching new format system as well

* feat:Added Game specific course correct task

* feat:Updated dod-checklist to match new DoD format

* feat:Added new Architect agent for appropriate architecture doc creation and design

* feat:Overhaul of game-architecture-tmpl template

* feat:Updated rest of templates besides level which doesnt really need it

* feat: Finished extended architecture documentation needed for new game story tasks

* feat: Updated game Developer to new format

* feat: Updated last agent to new format and updated bmad-kb. bmad-kb I did my best with but im not sure of it's valid usage in the expansion pack, the AI generated more of the file then myself. I made sure to include it due to the new core-config file

* feat: Finished updating designer agent to new format and cleaned up template linting errors

* Built dist for web bundle

* Increased expansion pack minor verison number

* Updated architecht and design for sharding built-in

* chore: bump bmad-2d-unity-game-dev version (minor)

* updated config.yaml for game-specific pieces to supplement core-config.yaml

* Updated game-core-config and epic processing for game story and game design. Initial implementation was far too generic

* chore: bump bmad-2d-unity-game-dev version (patch)

* feat: Fixed issue with multi-configs being needed. chore: bump bmad-2d-unity-game-dev version (patch)

* Chore: Built web-bundle

* feat: Added the ability to specify the unity editor install location.\nchore: bump bmad-2d-unity-game-dev version (patch)

* feat: core-config must be in two places to support inherited tasks at this time so added instructions to copy and create one in expansion pack folder as well. chore: bump bmad-2d-unity-game-dev version (patch)
2025-07-23 07:14:06 -05:00
manjaroblack
9afe4fbdaf fix/chore: Update console.log for user-guide.md install path. Cleaned up config files/folders and updated .gitignore (#347)
* fix: Update console.log for user-guide.md install path

Changed
IMPORTANT: Please read the user guide installed at docs/user-guilde.md
to
IMPORTANT: Please read the user guide installed at .bmad-core/user-guide.md

WHY: the actual install location of the user-guide.md is in the .bmad-core directory.

* chore: remove formatting configs and clean up gitignore

- Delete husky pre-commit hook and prettier config files
- Remove VS Code chat/copilot settings
- Reorganize and clean up gitignore entries
2025-07-22 21:22:48 -05:00
semantic-release-bot
bfaaa0ee11 chore(release): 4.31.0 [skip ci]
# [4.31.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.30.4...v4.31.0) (2025-07-20)

### Bug Fixes

* enhanced user guide with better diagrams ([c445962](c445962f25))

### Features

* Installation includes a getting started user guide with detailed mermaid diagram ([df57d77](df57d772ca))
2025-07-20 02:18:34 +00:00
Brian Madison
df57d772ca feat: Installation includes a getting started user guide with detailed mermaid diagram 2025-07-19 21:18:06 -05:00
Brian Madison
c445962f25 fix: enhanced user guide with better diagrams 2025-07-19 20:54:41 -05:00
semantic-release-bot
e44271b191 chore(release): 4.30.4 [skip ci]
## [4.30.4](https://github.com/bmadcode/BMAD-METHOD/compare/v4.30.3...v4.30.4) (2025-07-19)

### Bug Fixes

* docs ([8619006](8619006c16))
* lint fix ([49e4897](49e489701e))
2025-07-19 15:07:57 +00:00
Brian Madison
49e489701e fix: lint fix 2025-07-19 10:07:34 -05:00
Brian Madison
8619006c16 fix: docs 2025-07-19 00:36:13 -05:00
Brian Madison
a72f1cc3bd merge 2025-07-19 00:35:53 -05:00
Brian Madison
c6dc345b95 direct commands in agents 2025-07-19 00:30:42 -05:00
202 changed files with 42979 additions and 17998 deletions

View File

@@ -1,9 +1,9 @@
---
name: Bug report
about: Create a report to help us improve
title: ""
labels: ""
assignees: ""
title: ''
labels: ''
assignees: ''
---
**Describe the bug**

View File

@@ -1,9 +1,9 @@
---
name: Feature request
about: Suggest an idea for this project
title: ""
labels: ""
assignees: ""
title: ''
labels: ''
assignees: ''
---
**Did you discuss the idea first in Discord Server (#general-dev)**

25
.github/workflows/discord.yaml vendored Normal file
View File

@@ -0,0 +1,25 @@
name: Discord Notification
"on":
[
pull_request,
release,
create,
delete,
issue_comment,
pull_request_review,
pull_request_review_comment,
]
jobs:
notify:
runs-on: ubuntu-latest
steps:
- name: Notify Discord
uses: sarisia/actions-status-discord@v1
if: always()
with:
webhook: ${{ secrets.DISCORD_WEBHOOK }}
status: ${{ job.status }}
title: "Triggered by ${{ github.event_name }}"
color: 0x5865F2

42
.github/workflows/format-check.yaml vendored Normal file
View File

@@ -0,0 +1,42 @@
name: format-check
"on":
pull_request:
branches: ["**"]
jobs:
prettier:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm"
- name: Install dependencies
run: npm ci
- name: Prettier format check
run: npm run format:check
eslint:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm"
- name: Install dependencies
run: npm ci
- name: ESLint
run: npm run lint

148
.github/workflows/promote-to-stable.yaml vendored Normal file
View File

@@ -0,0 +1,148 @@
name: Promote to Stable
"on":
workflow_dispatch:
inputs:
version_bump:
description: "Version bump type"
required: true
default: "minor"
type: choice
options:
- patch
- minor
- major
jobs:
promote:
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 0
token: ${{ secrets.GITHUB_TOKEN }}
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
registry-url: "https://registry.npmjs.org"
- name: Configure Git
run: |
git config --global user.name "github-actions[bot]"
git config --global user.email "github-actions[bot]@users.noreply.github.com"
- name: Install dependencies
run: npm ci
- name: Get current version and calculate new version
id: version
run: |
# Get current version from package.json
CURRENT_VERSION=$(node -p "require('./package.json').version")
echo "current_version=$CURRENT_VERSION" >> $GITHUB_OUTPUT
# Remove beta suffix if present
BASE_VERSION=$(echo $CURRENT_VERSION | sed 's/-beta\.[0-9]\+//')
echo "base_version=$BASE_VERSION" >> $GITHUB_OUTPUT
# Calculate new version based on bump type
IFS='.' read -ra VERSION_PARTS <<< "$BASE_VERSION"
MAJOR=${VERSION_PARTS[0]}
MINOR=${VERSION_PARTS[1]}
PATCH=${VERSION_PARTS[2]}
case "${{ github.event.inputs.version_bump }}" in
"major")
NEW_VERSION="$((MAJOR + 1)).0.0"
;;
"minor")
NEW_VERSION="$MAJOR.$((MINOR + 1)).0"
;;
"patch")
NEW_VERSION="$MAJOR.$MINOR.$((PATCH + 1))"
;;
*)
NEW_VERSION="$BASE_VERSION"
;;
esac
# Check if calculated version already exists (either as NPM package or git tag)
while npm view bmad-method@$NEW_VERSION version >/dev/null 2>&1 || git ls-remote --tags origin | grep -q "refs/tags/v$NEW_VERSION"; do
echo "Version $NEW_VERSION already exists, incrementing..."
IFS='.' read -ra NEW_VERSION_PARTS <<< "$NEW_VERSION"
NEW_MAJOR=${NEW_VERSION_PARTS[0]}
NEW_MINOR=${NEW_VERSION_PARTS[1]}
NEW_PATCH=${NEW_VERSION_PARTS[2]}
case "${{ github.event.inputs.version_bump }}" in
"major")
NEW_VERSION="$((NEW_MAJOR + 1)).0.0"
;;
"minor")
NEW_VERSION="$NEW_MAJOR.$((NEW_MINOR + 1)).0"
;;
"patch")
NEW_VERSION="$NEW_MAJOR.$NEW_MINOR.$((NEW_PATCH + 1))"
;;
esac
done
echo "new_version=$NEW_VERSION" >> $GITHUB_OUTPUT
echo "Promoting from $CURRENT_VERSION to $NEW_VERSION"
- name: Update package.json versions
run: |
# Update main package.json
npm version ${{ steps.version.outputs.new_version }} --no-git-tag-version
# Update installer package.json
sed -i 's/"version": ".*"/"version": "${{ steps.version.outputs.new_version }}"/' tools/installer/package.json
- name: Update package-lock.json
run: npm install --package-lock-only
- name: Commit stable release
run: |
git add .
git commit -m "release: promote to stable ${{ steps.version.outputs.new_version }}"
- name: Create and push stable tag
run: |
# Create new tag (version check already ensures it doesn't exist)
git tag -a "v${{ steps.version.outputs.new_version }}" -m "Stable release v${{ steps.version.outputs.new_version }}"
# Push the new tag
git push origin "v${{ steps.version.outputs.new_version }}"
- name: Push changes to main
run: |
git push origin HEAD:main
- name: Publish to NPM with stable tag
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
run: |
# Publish with the stable (latest) tag
npm publish --tag latest
# Also tag the previous beta version as stable if it exists
if npm view bmad-method@${{ steps.version.outputs.current_version }} version >/dev/null 2>&1; then
npm dist-tag add bmad-method@${{ steps.version.outputs.new_version }} stable || true
fi
- name: Summary
run: |
echo "🎉 Successfully promoted to stable!"
echo "📦 Version: ${{ steps.version.outputs.new_version }}"
echo "🏷️ Git tag: v${{ steps.version.outputs.new_version }}"
echo "✅ Published to NPM with 'latest' tag"
echo "✅ Users running 'npx bmad-method install' will now get version ${{ steps.version.outputs.new_version }}"
echo "🚀 The stable release will be automatically published to NPM via semantic-release"
echo "✅ Users running 'npx bmad-method install' will now get version ${{ steps.version.outputs.new_version }}"

View File

@@ -1,5 +1,5 @@
name: Release
'on':
"on":
push:
branches:
- main
@@ -22,7 +22,7 @@ permissions:
jobs:
release:
runs-on: ubuntu-latest
if: '!contains(github.event.head_commit.message, ''[skip ci]'')'
if: ${{ github.event_name != 'push' || !contains(github.event.head_commit.message, '[skip ci]') }}
steps:
- name: Checkout
uses: actions/checkout@v4
@@ -32,9 +32,9 @@ jobs:
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '18'
cache: npm
registry-url: https://registry.npmjs.org
node-version: "20"
cache: "npm"
registry-url: "https://registry.npmjs.org"
- name: Install dependencies
run: npm ci
- name: Run tests and validation
@@ -57,3 +57,17 @@ jobs:
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
run: npm run release
- name: Clean changelog formatting
if: github.event_name == 'push'
run: |
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
# Remove any Claude Code attribution from changelog
sed -i '/🤖 Generated with \[Claude Code\]/,+2d' CHANGELOG.md || true
# Format and commit if changes exist
npm run format
if ! git diff --quiet CHANGELOG.md; then
git add CHANGELOG.md
git commit -m "chore: clean changelog formatting [skip ci]"
git push
fi

40
.gitignore vendored
View File

@@ -1,30 +1,46 @@
# Node modules
# Dependencies
node_modules/
pnpm-lock.yaml
bun.lock
deno.lock
pnpm-workspace.yaml
package-lock.json
# Logs
logs
logs/
*.log
npm-debug.log*
# Build output
build/*.txt
web-bundles/
# Environment variables
.env
# System files
.DS_Store
Thumbs.db
# Environment variables
.env
# Development tools and configs
.prettierignore
.prettierrc
CLAUDE.md
.ai/*
test-project-install/*
sample-project/*
.claude
# IDE and editor configs
.windsurf/
.trae/
.bmad*/.cursor/
# AI assistant files
CLAUDE.md
.ai/*
.claude
.gemini
# Project-specific
.bmad-core
.bmad-creator-tools
.gemini
.bmad*/.cursor/
web-bundles/
test-project-install/*
sample-project/*
flattened-codebase.xml
*.stats.md

View File

@@ -1,2 +1,3 @@
# Run lint-staged to format and lint YAML files
npx lint-staged
#!/usr/bin/env sh
npx --no-install lint-staged

View File

@@ -1,21 +0,0 @@
# Dependencies
node_modules/
package-lock.json
# Build outputs
dist/
# Generated files
*.log
*.lock
# BMad core files (have their own formatting)
bmad-core/**/*.md
# Specific files that need custom formatting
.roomodes
CHANGELOG.md
# IDE files
.vscode/
.idea/

View File

@@ -1,23 +0,0 @@
{
"printWidth": 100,
"tabWidth": 2,
"useTabs": false,
"semi": true,
"singleQuote": false,
"quoteProps": "as-needed",
"trailingComma": "es5",
"bracketSpacing": true,
"bracketSameLine": false,
"arrowParens": "always",
"proseWrap": "preserve",
"endOfLine": "lf",
"overrides": [
{
"files": "*.md",
"options": {
"proseWrap": "preserve",
"printWidth": 120
}
}
]
}

View File

@@ -1,18 +1,22 @@
{
"branches": ["main"],
"branches": [
{
"name": "main",
"prerelease": "beta",
"channel": "beta"
}
],
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/changelog",
"@semantic-release/npm",
"./tools/semantic-release-sync-installer.js",
[
"@semantic-release/git",
"@semantic-release/changelog",
{
"assets": ["package.json", "package-lock.json", "tools/installer/package.json", "CHANGELOG.md"],
"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
"changelogFile": "CHANGELOG.md"
}
],
"@semantic-release/npm",
"./tools/semantic-release-sync-installer.js",
"@semantic-release/github"
]
}

33
.vscode/settings.json vendored
View File

@@ -1,10 +1,4 @@
{
"chat.agent.enabled": true,
"chat.agent.maxRequests": 15,
"github.copilot.chat.agent.runTasks": true,
"chat.mcp.discovery.enabled": true,
"github.copilot.chat.agent.autoFix": true,
"chat.tools.autoApprove": false,
"cSpell.words": [
"Agentic",
"atlasing",
@@ -46,5 +40,30 @@
"tileset",
"Trae",
"VNET"
]
],
"json.schemas": [
{
"fileMatch": ["package.json"],
"url": "https://json.schemastore.org/package.json"
},
{
"fileMatch": [".vscode/settings.json"],
"url": "vscode://schemas/settings/folder"
}
],
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
"[json]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
"[yaml]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
"[markdown]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
"prettier.prettierPath": "node_modules/prettier",
"prettier.requireConfig": true,
"yaml.format.enable": false,
"eslint.useFlatConfig": true,
"eslint.validate": ["javascript", "yaml"],
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
},
"editor.rulers": [100]
}

View File

@@ -1,526 +1,539 @@
## [4.30.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.30.2...v4.30.3) (2025-07-19)
## [4.36.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.36.1...v4.36.2) (2025-08-10)
### Bug Fixes
* improve code in the installer to be more memory efficient ([849e428](https://github.com/bmadcode/BMAD-METHOD/commit/849e42871ab845098fd196217bce83e43c736b8a))
- align installer dependencies with root package versions for ESM compatibility ([#420](https://github.com/bmadcode/BMAD-METHOD/issues/420)) ([3f6b674](https://github.com/bmadcode/BMAD-METHOD/commit/3f6b67443d61ae6add98656374bed27da4704644))
## [4.36.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.36.0...v4.36.1) (2025-08-09)
### Bug Fixes
- update Node.js version to 20 in release workflow and reduce Discord spam ([3f7e19a](https://github.com/bmadcode/BMAD-METHOD/commit/3f7e19a098155341a2b89796addc47b0623cb87a))
# [4.36.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.35.3...v4.36.0) (2025-08-09)
### Features
- modularize flattener tool into separate components with improved project root detection ([#417](https://github.com/bmadcode/BMAD-METHOD/issues/417)) ([0fdbca7](https://github.com/bmadcode/BMAD-METHOD/commit/0fdbca73fc60e306109f682f018e105e2b4623a2))
## [4.35.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.35.2...v4.35.3) (2025-08-06)
### Bug Fixes
- doc location improvement ([1676f51](https://github.com/bmadcode/BMAD-METHOD/commit/1676f5189ed057fa2d7facbd6a771fe67cdb6372))
## [4.35.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.35.1...v4.35.2) (2025-08-06)
### Bug Fixes
- npx status check ([f7c2a4f](https://github.com/bmadcode/BMAD-METHOD/commit/f7c2a4fb6c454b17d250b85537129b01ffee6b85))
## [4.35.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.35.0...v4.35.1) (2025-08-06)
### Bug Fixes
- npx hanging commands ([2cf322e](https://github.com/bmadcode/BMAD-METHOD/commit/2cf322ee0d9b563a4998c72b2c5eab259594739b))
# [4.35.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.34.0...v4.35.0) (2025-08-04)
### Features
- add qwen-code ide support to bmad installer. ([#392](https://github.com/bmadcode/BMAD-METHOD/issues/392)) ([a72b790](https://github.com/bmadcode/BMAD-METHOD/commit/a72b790f3be6c77355511ace2d63e6bec4d751f1))
# [4.34.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.33.1...v4.34.0) (2025-08-03)
### Features
- add KiloCode integration support to BMAD installer ([#390](https://github.com/bmadcode/BMAD-METHOD/issues/390)) ([dcebe91](https://github.com/bmadcode/BMAD-METHOD/commit/dcebe91d5ea68e69aa27183411a81639d444efd7))
## [4.33.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.33.0...v4.33.1) (2025-07-29)
### Bug Fixes
- dev agent yaml syntax for develop-story command ([#362](https://github.com/bmadcode/BMAD-METHOD/issues/362)) ([bcb3728](https://github.com/bmadcode/BMAD-METHOD/commit/bcb3728f8868c0f83bca3d61fbd7e15c4e114526))
# [4.33.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.32.0...v4.33.0) (2025-07-28)
### Features
- version bump ([e9dd4e7](https://github.com/bmadcode/BMAD-METHOD/commit/e9dd4e7beb46d0c80df0cd65ae02d1867a56d7c1))
# [4.32.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.31.0...v4.32.0) (2025-07-27)
### Bug Fixes
- Add package-lock.json to fix GitHub Actions dependency resolution ([cce7a75](https://github.com/bmadcode/BMAD-METHOD/commit/cce7a758a632053e26d143b678eb7963599b432d))
- GHA fix ([62ccccd](https://github.com/bmadcode/BMAD-METHOD/commit/62ccccdc9e85f8621f63f99bd1ce0d14abe09783))
### Features
- Overhaul and Enhance 2D Unity Game Dev Expansion Pack ([#350](https://github.com/bmadcode/BMAD-METHOD/issues/350)) ([a7038d4](https://github.com/bmadcode/BMAD-METHOD/commit/a7038d43d18246f6aef175aa89ba059b7c94f61f))
# [4.31.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.30.4...v4.31.0) (2025-07-20)
### Bug Fixes
- enhanced user guide with better diagrams ([c445962](https://github.com/bmadcode/BMAD-METHOD/commit/c445962f259cd7d84c47a896e7fda99e83a30c8d))
### Features
- Installation includes a getting started user guide with detailed mermaid diagram ([df57d77](https://github.com/bmadcode/BMAD-METHOD/commit/df57d772cac9f9010811e7e86a6433a0fe636a45))
## [4.30.4](https://github.com/bmadcode/BMAD-METHOD/compare/v4.30.3...v4.30.4) (2025-07-19)
### Bug Fixes
- docs ([8619006](https://github.com/bmadcode/BMAD-METHOD/commit/8619006c16731b99fa36b434d209a0c2caf2d998))
- lint fix ([49e4897](https://github.com/bmadcode/BMAD-METHOD/commit/49e489701e55feac481806740ea54bebef042fba))
## [4.30.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.30.2...v4.30.3) (2025-07-19)
### Bug Fixes
- improve code in the installer to be more memory efficient ([849e428](https://github.com/bmadcode/BMAD-METHOD/commit/849e42871ab845098fd196217bce83e43c736b8a))
## [4.30.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.30.1...v4.30.2) (2025-07-17)
### Bug Fixes
* remove z2 ([dcb36a9](https://github.com/bmadcode/BMAD-METHOD/commit/dcb36a9b44b6644f6b2723c9067abaa9b0bc1999))
- remove z2 ([dcb36a9](https://github.com/bmadcode/BMAD-METHOD/commit/dcb36a9b44b6644f6b2723c9067abaa9b0bc1999))
## [4.30.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.30.0...v4.30.1) (2025-07-15)
### Bug Fixes
* added logo to installer, because why not... ([2cea37a](https://github.com/bmadcode/BMAD-METHOD/commit/2cea37aa8c1924ddf5aa476f4c312837f2615a70))
- added logo to installer, because why not... ([2cea37a](https://github.com/bmadcode/BMAD-METHOD/commit/2cea37aa8c1924ddf5aa476f4c312837f2615a70))
# [4.30.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.29.7...v4.30.0) (2025-07-15)
### Features
* installer is now VERY clear about IDE selection being a multiselect ([e24b6f8](https://github.com/bmadcode/BMAD-METHOD/commit/e24b6f84fd9e4ff4b99263019b5021ca2b145b2f))
- installer is now VERY clear about IDE selection being a multiselect ([e24b6f8](https://github.com/bmadcode/BMAD-METHOD/commit/e24b6f84fd9e4ff4b99263019b5021ca2b145b2f))
## [4.29.7](https://github.com/bmadcode/BMAD-METHOD/compare/v4.29.6...v4.29.7) (2025-07-14)
### Bug Fixes
* bundle build ([0723eed](https://github.com/bmadcode/BMAD-METHOD/commit/0723eed88140e76146dfbfdddd49afe86e8522ee))
- bundle build ([0723eed](https://github.com/bmadcode/BMAD-METHOD/commit/0723eed88140e76146dfbfdddd49afe86e8522ee))
## [4.29.6](https://github.com/bmadcode/BMAD-METHOD/compare/v4.29.5...v4.29.6) (2025-07-14)
### Bug Fixes
* improve agent task folowing in agressing cost saving ide model combos ([3621c33](https://github.com/bmadcode/BMAD-METHOD/commit/3621c330e65f328e7326f93a5fe27e65b08907e7))
- improve agent task folowing in agressing cost saving ide model combos ([3621c33](https://github.com/bmadcode/BMAD-METHOD/commit/3621c330e65f328e7326f93a5fe27e65b08907e7))
## [4.29.5](https://github.com/bmadcode/BMAD-METHOD/compare/v4.29.4...v4.29.5) (2025-07-14)
### Bug Fixes
* windows regex issue ([9f48c1a](https://github.com/bmadcode/BMAD-METHOD/commit/9f48c1a869a9cc54fb5e7d899c2af7a5cef70e10))
- windows regex issue ([9f48c1a](https://github.com/bmadcode/BMAD-METHOD/commit/9f48c1a869a9cc54fb5e7d899c2af7a5cef70e10))
## [4.29.4](https://github.com/bmadcode/BMAD-METHOD/compare/v4.29.3...v4.29.4) (2025-07-14)
### Bug Fixes
* empty .roomodes, support Windows-style newlines in YAML block regex ([#311](https://github.com/bmadcode/BMAD-METHOD/issues/311)) ([551e30b](https://github.com/bmadcode/BMAD-METHOD/commit/551e30b65e1f04386f0bd0193f726828df684d5b))
- empty .roomodes, support Windows-style newlines in YAML block regex ([#311](https://github.com/bmadcode/BMAD-METHOD/issues/311)) ([551e30b](https://github.com/bmadcode/BMAD-METHOD/commit/551e30b65e1f04386f0bd0193f726828df684d5b))
## [4.29.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.29.2...v4.29.3) (2025-07-13)
### Bug Fixes
* annoying YAML lint error ([afea271](https://github.com/bmadcode/BMAD-METHOD/commit/afea271e5e3b14a0da497e241b6521ba5a80b85b))
- annoying YAML lint error ([afea271](https://github.com/bmadcode/BMAD-METHOD/commit/afea271e5e3b14a0da497e241b6521ba5a80b85b))
## [4.29.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.29.1...v4.29.2) (2025-07-13)
### Bug Fixes
* add readme note about discord joining issues ([4ceaced](https://github.com/bmadcode/BMAD-METHOD/commit/4ceacedd7370ea80181db0d66cf8da8dcbfdd109))
- add readme note about discord joining issues ([4ceaced](https://github.com/bmadcode/BMAD-METHOD/commit/4ceacedd7370ea80181db0d66cf8da8dcbfdd109))
## [4.29.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.29.0...v4.29.1) (2025-07-13)
### Bug Fixes
* brianstorming facilitation output ([f62c05a](https://github.com/bmadcode/BMAD-METHOD/commit/f62c05ab0f54e6c26c67cd9ac11200b172d11076))
- brianstorming facilitation output ([f62c05a](https://github.com/bmadcode/BMAD-METHOD/commit/f62c05ab0f54e6c26c67cd9ac11200b172d11076))
# [4.29.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.28.0...v4.29.0) (2025-07-13)
### Features
* Claude Code slash commands for Tasks and Agents! ([e9e541a](https://github.com/bmadcode/BMAD-METHOD/commit/e9e541a52e45f6632b2f8c91d10e39c077c1ecc9))
- Claude Code slash commands for Tasks and Agents! ([e9e541a](https://github.com/bmadcode/BMAD-METHOD/commit/e9e541a52e45f6632b2f8c91d10e39c077c1ecc9))
# [4.28.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.27.6...v4.28.0) (2025-07-12)
### Features
* bmad-master can load kb properly ([3c13c56](https://github.com/bmadcode/BMAD-METHOD/commit/3c13c564988f9750e043939dd770aea4196a7e7a))
- bmad-master can load kb properly ([3c13c56](https://github.com/bmadcode/BMAD-METHOD/commit/3c13c564988f9750e043939dd770aea4196a7e7a))
## [4.27.6](https://github.com/bmadcode/BMAD-METHOD/compare/v4.27.5...v4.27.6) (2025-07-08)
### Bug Fixes
* installer improvement ([db30230](https://github.com/bmadcode/BMAD-METHOD/commit/db302309f42da49daa309b5ba1a625c719e5bb14))
- installer improvement ([db30230](https://github.com/bmadcode/BMAD-METHOD/commit/db302309f42da49daa309b5ba1a625c719e5bb14))
## [4.27.5](https://github.com/bmadcode/BMAD-METHOD/compare/v4.27.4...v4.27.5) (2025-07-08)
### Bug Fixes
* installer for github copilot asks follow up questions right away now so it does not seem to hang, and some minor doc improvements ([cadf8b6](https://github.com/bmadcode/BMAD-METHOD/commit/cadf8b6750afd5daa32eb887608c614584156a69))
- installer for github copilot asks follow up questions right away now so it does not seem to hang, and some minor doc improvements ([cadf8b6](https://github.com/bmadcode/BMAD-METHOD/commit/cadf8b6750afd5daa32eb887608c614584156a69))
## [4.27.4](https://github.com/bmadcode/BMAD-METHOD/compare/v4.27.3...v4.27.4) (2025-07-07)
### Bug Fixes
* doc updates ([1b86cd4](https://github.com/bmadcode/BMAD-METHOD/commit/1b86cd4db3644ca2b2b4a94821cc8b5690d78e0a))
- doc updates ([1b86cd4](https://github.com/bmadcode/BMAD-METHOD/commit/1b86cd4db3644ca2b2b4a94821cc8b5690d78e0a))
## [4.27.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.27.2...v4.27.3) (2025-07-07)
### Bug Fixes
* remove test zoo folder ([908dcd7](https://github.com/bmadcode/BMAD-METHOD/commit/908dcd7e9afae3fd23cd894c0d09855fc9c42d0e))
- remove test zoo folder ([908dcd7](https://github.com/bmadcode/BMAD-METHOD/commit/908dcd7e9afae3fd23cd894c0d09855fc9c42d0e))
## [4.27.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.27.1...v4.27.2) (2025-07-07)
### Bug Fixes
* improve output ([a5ffe7b](https://github.com/bmadcode/BMAD-METHOD/commit/a5ffe7b9b209ae02a9d97adf60fe73c0bc9701e4))
- improve output ([a5ffe7b](https://github.com/bmadcode/BMAD-METHOD/commit/a5ffe7b9b209ae02a9d97adf60fe73c0bc9701e4))
## [4.27.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.27.0...v4.27.1) (2025-07-07)
### Bug Fixes
* build web bundles with new file extension includsion ([92201ae](https://github.com/bmadcode/BMAD-METHOD/commit/92201ae7ede620ec09b4764edaed97be42a3b78f))
- build web bundles with new file extension includsion ([92201ae](https://github.com/bmadcode/BMAD-METHOD/commit/92201ae7ede620ec09b4764edaed97be42a3b78f))
# [4.27.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.26.0...v4.27.0) (2025-07-06)
### Bug Fixes
* readme consolidation and version bumps ([0a61d3d](https://github.com/bmadcode/BMAD-METHOD/commit/0a61d3de4af880f6e3bf934a92b1827754ed8ce6))
- readme consolidation and version bumps ([0a61d3d](https://github.com/bmadcode/BMAD-METHOD/commit/0a61d3de4af880f6e3bf934a92b1827754ed8ce6))
### Features
* big improvement to advanced elicitation ([1bc9960](https://github.com/bmadcode/BMAD-METHOD/commit/1bc9960808098fba6b43850311799022319df841))
* experimental doc creator v2 and template system ([b785371](https://github.com/bmadcode/BMAD-METHOD/commit/b78537115da06b01e140833fd1d73950c7f2e41f))
* Massive improvement to the brainstorming task! ([9f53caf](https://github.com/bmadcode/BMAD-METHOD/commit/9f53caf4c6f9c67195b1aae14d54987f81d76e07))
* WIP create-docv2 ([c107af0](https://github.com/bmadcode/BMAD-METHOD/commit/c107af05984718c1af2cf80118353e8d2e6f906f))
- big improvement to advanced elicitation ([1bc9960](https://github.com/bmadcode/BMAD-METHOD/commit/1bc9960808098fba6b43850311799022319df841))
- experimental doc creator v2 and template system ([b785371](https://github.com/bmadcode/BMAD-METHOD/commit/b78537115da06b01e140833fd1d73950c7f2e41f))
- Massive improvement to the brainstorming task! ([9f53caf](https://github.com/bmadcode/BMAD-METHOD/commit/9f53caf4c6f9c67195b1aae14d54987f81d76e07))
- WIP create-docv2 ([c107af0](https://github.com/bmadcode/BMAD-METHOD/commit/c107af05984718c1af2cf80118353e8d2e6f906f))
# [4.26.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.25.1...v4.26.0) (2025-07-06)
### Features
* **trae:** add support for trae ide integration ([#298](https://github.com/bmadcode/BMAD-METHOD/issues/298)) ([fae0f5f](https://github.com/bmadcode/BMAD-METHOD/commit/fae0f5ff73a603dc1aacc29f184e2a4138446524))
- **trae:** add support for trae ide integration ([#298](https://github.com/bmadcode/BMAD-METHOD/issues/298)) ([fae0f5f](https://github.com/bmadcode/BMAD-METHOD/commit/fae0f5ff73a603dc1aacc29f184e2a4138446524))
## [4.25.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.25.0...v4.25.1) (2025-07-06)
### Bug Fixes
* spelling errors in documentation. ([#297](https://github.com/bmadcode/BMAD-METHOD/issues/297)) ([47b9d9f](https://github.com/bmadcode/BMAD-METHOD/commit/47b9d9f3e87be62c8520ed6cb0048df727a9534f))
- spelling errors in documentation. ([#297](https://github.com/bmadcode/BMAD-METHOD/issues/297)) ([47b9d9f](https://github.com/bmadcode/BMAD-METHOD/commit/47b9d9f3e87be62c8520ed6cb0048df727a9534f))
# [4.25.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.24.6...v4.25.0) (2025-07-05)
### Bug Fixes
* update web bundles ([42684e6](https://github.com/bmadcode/BMAD-METHOD/commit/42684e68af4396797962f3f851147523a6741608))
- update web bundles ([42684e6](https://github.com/bmadcode/BMAD-METHOD/commit/42684e68af4396797962f3f851147523a6741608))
### Features
* improvements to agent task usage, sm story drafting, dev implementation, qa review process, and addition of a new sm independant review of a draft story ([2874a54](https://github.com/bmadcode/BMAD-METHOD/commit/2874a54a9b25b48c199b2e9dc63a9555e716c636))
- improvements to agent task usage, sm story drafting, dev implementation, qa review process, and addition of a new sm independant review of a draft story ([2874a54](https://github.com/bmadcode/BMAD-METHOD/commit/2874a54a9b25b48c199b2e9dc63a9555e716c636))
## [4.24.6](https://github.com/bmadcode/BMAD-METHOD/compare/v4.24.5...v4.24.6) (2025-07-04)
### Bug Fixes
* version bump and web build fix ([1c845e5](https://github.com/bmadcode/BMAD-METHOD/commit/1c845e5b2c77a77d887d8216152ba09110c72e40))
- version bump and web build fix ([1c845e5](https://github.com/bmadcode/BMAD-METHOD/commit/1c845e5b2c77a77d887d8216152ba09110c72e40))
## [4.24.5](https://github.com/bmadcode/BMAD-METHOD/compare/v4.24.4...v4.24.5) (2025-07-04)
### Bug Fixes
* yaml standardization in files and installer actions ([094f9f3](https://github.com/bmadcode/BMAD-METHOD/commit/094f9f3eabf563c9a89ecaf360fed63386b46ed4))
- yaml standardization in files and installer actions ([094f9f3](https://github.com/bmadcode/BMAD-METHOD/commit/094f9f3eabf563c9a89ecaf360fed63386b46ed4))
## [4.24.4](https://github.com/bmadcode/BMAD-METHOD/compare/v4.24.3...v4.24.4) (2025-07-04)
### Bug Fixes
* documentation updates ([2018ad0](https://github.com/bmadcode/BMAD-METHOD/commit/2018ad07c7d4c68efb3c24d85ac7612942c6df9c))
- documentation updates ([2018ad0](https://github.com/bmadcode/BMAD-METHOD/commit/2018ad07c7d4c68efb3c24d85ac7612942c6df9c))
## [4.24.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.24.2...v4.24.3) (2025-07-04)
### Bug Fixes
* update YAML library from 'yaml' to 'js-yaml' in resolveExpansionPackCoreAgents for consistency ([#295](https://github.com/bmadcode/BMAD-METHOD/issues/295)) ([03f30ad](https://github.com/bmadcode/BMAD-METHOD/commit/03f30ad28b282fbb4fa5a6ed6b57d0327218cce0))
- update YAML library from 'yaml' to 'js-yaml' in resolveExpansionPackCoreAgents for consistency ([#295](https://github.com/bmadcode/BMAD-METHOD/issues/295)) ([03f30ad](https://github.com/bmadcode/BMAD-METHOD/commit/03f30ad28b282fbb4fa5a6ed6b57d0327218cce0))
## [4.24.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.24.1...v4.24.2) (2025-07-03)
### Bug Fixes
* version bump and restore dist folder ([87c451a](https://github.com/bmadcode/BMAD-METHOD/commit/87c451a5c3161fbc86f88619a2bfcfc322eb247e))
- version bump and restore dist folder ([87c451a](https://github.com/bmadcode/BMAD-METHOD/commit/87c451a5c3161fbc86f88619a2bfcfc322eb247e))
## [4.24.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.24.0...v4.24.1) (2025-07-03)
### Bug Fixes
* centralized yamlExtraction function and all now fix character issues for windows ([e2985d6](https://github.com/bmadcode/BMAD-METHOD/commit/e2985d6093136575e8d8c91ce53c82abc4097de6))
* filtering extension stripping logic update ([405954a](https://github.com/bmadcode/BMAD-METHOD/commit/405954ad924d8bd66f94c918643f6e9c091d4d09))
* standardize on file extension .yaml instead of a mix of yml and yaml ([a4c0b18](https://github.com/bmadcode/BMAD-METHOD/commit/a4c0b1839d12d2ad21b7949aa30f4f7d82ec6c9c))
- centralized yamlExtraction function and all now fix character issues for windows ([e2985d6](https://github.com/bmadcode/BMAD-METHOD/commit/e2985d6093136575e8d8c91ce53c82abc4097de6))
- filtering extension stripping logic update ([405954a](https://github.com/bmadcode/BMAD-METHOD/commit/405954ad924d8bd66f94c918643f6e9c091d4d09))
- standardize on file extension .yaml instead of a mix of yml and yaml ([a4c0b18](https://github.com/bmadcode/BMAD-METHOD/commit/a4c0b1839d12d2ad21b7949aa30f4f7d82ec6c9c))
# [4.24.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.23.0...v4.24.0) (2025-07-02)
### Bug Fixes
* corrected cursor agent update instructions ([84e394a](https://github.com/bmadcode/BMAD-METHOD/commit/84e394ac11136d9cf8164cefc9ca8e298e8ef0ec))
- corrected cursor agent update instructions ([84e394a](https://github.com/bmadcode/BMAD-METHOD/commit/84e394ac11136d9cf8164cefc9ca8e298e8ef0ec))
### Features
* workflow plans introduced, preliminary feature under review ([731589a](https://github.com/bmadcode/BMAD-METHOD/commit/731589aa287c31ea120e232b4dcc07e9790500ff))
- workflow plans introduced, preliminary feature under review ([731589a](https://github.com/bmadcode/BMAD-METHOD/commit/731589aa287c31ea120e232b4dcc07e9790500ff))
# [4.23.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.22.1...v4.23.0) (2025-07-01)
### Features
* Github Copilot integration ([#284](https://github.com/bmadcode/BMAD-METHOD/issues/284)) ([1a4ca4f](https://github.com/bmadcode/BMAD-METHOD/commit/1a4ca4ffa630c2d4156bdd7a040d4c2274801757))
- Github Copilot integration ([#284](https://github.com/bmadcode/BMAD-METHOD/issues/284)) ([1a4ca4f](https://github.com/bmadcode/BMAD-METHOD/commit/1a4ca4ffa630c2d4156bdd7a040d4c2274801757))
## [4.22.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.22.0...v4.22.1) (2025-06-30)
### Bug Fixes
* update expansion versions ([6905fe7](https://github.com/bmadcode/BMAD-METHOD/commit/6905fe72f6c2abefbfd65729d1be85752130a1d2))
- update expansion versions ([6905fe7](https://github.com/bmadcode/BMAD-METHOD/commit/6905fe72f6c2abefbfd65729d1be85752130a1d2))
# [4.22.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.21.2...v4.22.0) (2025-06-30)
### Features
* create doc more explicit and readme improvement ([a1b30d9](https://github.com/bmadcode/BMAD-METHOD/commit/a1b30d9341d2ceff79db2c7e178860c5ef0d99e5))
- create doc more explicit and readme improvement ([a1b30d9](https://github.com/bmadcode/BMAD-METHOD/commit/a1b30d9341d2ceff79db2c7e178860c5ef0d99e5))
## [4.21.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.21.1...v4.21.2) (2025-06-30)
### Bug Fixes
* improve create-doc task clarity for template execution ([86d5139](https://github.com/bmadcode/BMAD-METHOD/commit/86d5139aea7097cc5d4ee9da0f7d3e395ce0835e))
- improve create-doc task clarity for template execution ([86d5139](https://github.com/bmadcode/BMAD-METHOD/commit/86d5139aea7097cc5d4ee9da0f7d3e395ce0835e))
## [4.21.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.21.0...v4.21.1) (2025-06-30)
### Bug Fixes
* readme clarifies that the installer handles installs upgrades and expansion installation ([9371a57](https://github.com/bmadcode/BMAD-METHOD/commit/9371a5784f6a6f2ad358a72ea0cde9c980357167))
- readme clarifies that the installer handles installs upgrades and expansion installation ([9371a57](https://github.com/bmadcode/BMAD-METHOD/commit/9371a5784f6a6f2ad358a72ea0cde9c980357167))
# [4.21.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.20.0...v4.21.0) (2025-06-30)
### Bug Fixes
* remove unneeded files ([c48f200](https://github.com/bmadcode/BMAD-METHOD/commit/c48f200727384f37a42f4c6b1a946cb90f2445fe))
- remove unneeded files ([c48f200](https://github.com/bmadcode/BMAD-METHOD/commit/c48f200727384f37a42f4c6b1a946cb90f2445fe))
### Features
* massive installer improvement update ([c151bda](https://github.com/bmadcode/BMAD-METHOD/commit/c151bda93833aa310ccc7c0eabcf483376f9e82a))
- massive installer improvement update ([c151bda](https://github.com/bmadcode/BMAD-METHOD/commit/c151bda93833aa310ccc7c0eabcf483376f9e82a))
# [4.20.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.19.2...v4.20.0) (2025-06-29)
### Features
* Massive documentation refactor, added explanation of the new expanded role of the QA agent that will make your code quality MUCH better. 2 new diagram clearly explain the role of the pre dev ideation cycle (prd and architecture) and the details of how the dev cycle works. ([c881dcc](https://github.com/bmadcode/BMAD-METHOD/commit/c881dcc48ff827ddfe8653aa364a021a66ce66eb))
- Massive documentation refactor, added explanation of the new expanded role of the QA agent that will make your code quality MUCH better. 2 new diagram clearly explain the role of the pre dev ideation cycle (prd and architecture) and the details of how the dev cycle works. ([c881dcc](https://github.com/bmadcode/BMAD-METHOD/commit/c881dcc48ff827ddfe8653aa364a021a66ce66eb))
## [4.19.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.19.1...v4.19.2) (2025-06-28)
### Bug Fixes
* docs update and correction ([2408068](https://github.com/bmadcode/BMAD-METHOD/commit/240806888448bb3a42acfd2f209976d489157e21))
- docs update and correction ([2408068](https://github.com/bmadcode/BMAD-METHOD/commit/240806888448bb3a42acfd2f209976d489157e21))
## [4.19.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.19.0...v4.19.1) (2025-06-28)
### Bug Fixes
* discord link ([2ea806b](https://github.com/bmadcode/BMAD-METHOD/commit/2ea806b3af58ad37fcb695146883a9cd3003363d))
- discord link ([2ea806b](https://github.com/bmadcode/BMAD-METHOD/commit/2ea806b3af58ad37fcb695146883a9cd3003363d))
# [4.19.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.18.0...v4.19.0) (2025-06-28)
### Bug Fixes
* expansion install config ([50d17ed](https://github.com/bmadcode/BMAD-METHOD/commit/50d17ed65d40f6688f3b6e62732fb2280b6b116e))
- expansion install config ([50d17ed](https://github.com/bmadcode/BMAD-METHOD/commit/50d17ed65d40f6688f3b6e62732fb2280b6b116e))
### Features
* install for ide now sets up rules also for expansion agents! ([b82978f](https://github.com/bmadcode/BMAD-METHOD/commit/b82978fd38ea789a799ccc1373cfb61a2001c1e0))
- install for ide now sets up rules also for expansion agents! ([b82978f](https://github.com/bmadcode/BMAD-METHOD/commit/b82978fd38ea789a799ccc1373cfb61a2001c1e0))
# [4.18.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.17.0...v4.18.0) (2025-06-28)
### Features
* expansion teams can now include core agents and include their assets automatically ([c70f1a0](https://github.com/bmadcode/BMAD-METHOD/commit/c70f1a056b0f6e3c805096ee5d27f0a3640fb00c))
* remove hardcoding from installer for agents, improve expansion pack installation to its own locations, common files moved to common folder ([95e833b](https://github.com/bmadcode/BMAD-METHOD/commit/95e833beebc3a60f73a7a1c67d534c8eb6bf48fd))
- expansion teams can now include core agents and include their assets automatically ([c70f1a0](https://github.com/bmadcode/BMAD-METHOD/commit/c70f1a056b0f6e3c805096ee5d27f0a3640fb00c))
- remove hardcoding from installer for agents, improve expansion pack installation to its own locations, common files moved to common folder ([95e833b](https://github.com/bmadcode/BMAD-METHOD/commit/95e833beebc3a60f73a7a1c67d534c8eb6bf48fd))
# [4.17.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.16.1...v4.17.0) (2025-06-27)
### Features
* add GEMINI.md to agent context files ([#272](https://github.com/bmadcode/BMAD-METHOD/issues/272)) ([b557570](https://github.com/bmadcode/BMAD-METHOD/commit/b557570081149352e4efbef8046935650f6ecea1))
- add GEMINI.md to agent context files ([#272](https://github.com/bmadcode/BMAD-METHOD/issues/272)) ([b557570](https://github.com/bmadcode/BMAD-METHOD/commit/b557570081149352e4efbef8046935650f6ecea1))
## [4.16.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.16.0...v4.16.1) (2025-06-26)
### Bug Fixes
* remove accidental folder add ([b1c2de1](https://github.com/bmadcode/BMAD-METHOD/commit/b1c2de1fb58029f68e021faa90cd5d5faf345198))
- remove accidental folder add ([b1c2de1](https://github.com/bmadcode/BMAD-METHOD/commit/b1c2de1fb58029f68e021faa90cd5d5faf345198))
# [4.16.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.15.0...v4.16.0) (2025-06-26)
### Features
* repo builds all rules sets for supported ides for easy copy if desired ([ea945bb](https://github.com/bmadcode/BMAD-METHOD/commit/ea945bb43f6ea50594910b954c72e79f96a8504c))
- repo builds all rules sets for supported ides for easy copy if desired ([ea945bb](https://github.com/bmadcode/BMAD-METHOD/commit/ea945bb43f6ea50594910b954c72e79f96a8504c))
# [4.15.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.14.1...v4.15.0) (2025-06-26)
### Features
* Add Gemini CLI Integration ([#271](https://github.com/bmadcode/BMAD-METHOD/issues/271)) ([44b9d7b](https://github.com/bmadcode/BMAD-METHOD/commit/44b9d7bcb5cbb6de5a15d8f2ec7918d186ac9576))
- Add Gemini CLI Integration ([#271](https://github.com/bmadcode/BMAD-METHOD/issues/271)) ([44b9d7b](https://github.com/bmadcode/BMAD-METHOD/commit/44b9d7bcb5cbb6de5a15d8f2ec7918d186ac9576))
## [4.14.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.14.0...v4.14.1) (2025-06-26)
### Bug Fixes
* add updated web builds ([6dabbcb](https://github.com/bmadcode/BMAD-METHOD/commit/6dabbcb670ef22708db6c01dac82069547ca79d6))
- add updated web builds ([6dabbcb](https://github.com/bmadcode/BMAD-METHOD/commit/6dabbcb670ef22708db6c01dac82069547ca79d6))
# [4.14.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.13.0...v4.14.0) (2025-06-25)
### Features
* enhance QA agent as senior developer with code review capabilities and major brownfield improvements ([3af3d33](https://github.com/bmadcode/BMAD-METHOD/commit/3af3d33d4a40586479a382620687fa99a9f6a5f7))
- enhance QA agent as senior developer with code review capabilities and major brownfield improvements ([3af3d33](https://github.com/bmadcode/BMAD-METHOD/commit/3af3d33d4a40586479a382620687fa99a9f6a5f7))
# [4.13.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.12.0...v4.13.0) (2025-06-24)
### Features
* **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))
- **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))
# [4.12.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.11.0...v4.12.0) (2025-06-23)
### Features
* **dev-agent:** add quality gates to prevent task completion with failing validations ([#261](https://github.com/bmadcode/BMAD-METHOD/issues/261)) ([45110ff](https://github.com/bmadcode/BMAD-METHOD/commit/45110ffffe6d29cc08e227e22a901892185dfbd2))
- **dev-agent:** add quality gates to prevent task completion with failing validations ([#261](https://github.com/bmadcode/BMAD-METHOD/issues/261)) ([45110ff](https://github.com/bmadcode/BMAD-METHOD/commit/45110ffffe6d29cc08e227e22a901892185dfbd2))
# [4.11.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.3...v4.11.0) (2025-06-21)
### Bug Fixes
* resolve web bundles directory path when using relative paths in NPX installer ([5c8485d](https://github.com/bmadcode/BMAD-METHOD/commit/5c8485d09ffec60ad4965ced62f4595890cb7535))
- resolve web bundles directory path when using relative paths in NPX installer ([5c8485d](https://github.com/bmadcode/BMAD-METHOD/commit/5c8485d09ffec60ad4965ced62f4595890cb7535))
### Features
* add markdown-tree integration for document sharding ([540578b](https://github.com/bmadcode/BMAD-METHOD/commit/540578b39d1815e41e11f0e87545de3f09ee54e1))
- add markdown-tree integration for document sharding ([540578b](https://github.com/bmadcode/BMAD-METHOD/commit/540578b39d1815e41e11f0e87545de3f09ee54e1))
## [4.10.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.2...v4.10.3) (2025-06-20)
### Bug Fixes
* bundle update ([2cf3ba1](https://github.com/bmadcode/BMAD-METHOD/commit/2cf3ba1ab8dd7e52584bef16a96e65e7d2513c4f))
- bundle update ([2cf3ba1](https://github.com/bmadcode/BMAD-METHOD/commit/2cf3ba1ab8dd7e52584bef16a96e65e7d2513c4f))
## [4.10.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.1...v4.10.2) (2025-06-20)
### Bug Fixes
* file formatting ([c78a35f](https://github.com/bmadcode/BMAD-METHOD/commit/c78a35f547459b07a15d94c827ec05921cd21571))
- file formatting ([c78a35f](https://github.com/bmadcode/BMAD-METHOD/commit/c78a35f547459b07a15d94c827ec05921cd21571))
## [4.10.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.0...v4.10.1) (2025-06-20)
### Bug Fixes
* SM sometimes would skip the rest of the epic stories, fixed ([1148b32](https://github.com/bmadcode/BMAD-METHOD/commit/1148b32fa97586d2f86d07a70ffbf9bb8c327261))
- SM sometimes would skip the rest of the epic stories, fixed ([1148b32](https://github.com/bmadcode/BMAD-METHOD/commit/1148b32fa97586d2f86d07a70ffbf9bb8c327261))
# [4.10.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.9.2...v4.10.0) (2025-06-19)
### Features
* Core Config and doc sharding is now optional in v4 ([ff6112d](https://github.com/bmadcode/BMAD-METHOD/commit/ff6112d6c2f822ed22c75046f5a14f05e36041c2))
- Core Config and doc sharding is now optional in v4 ([ff6112d](https://github.com/bmadcode/BMAD-METHOD/commit/ff6112d6c2f822ed22c75046f5a14f05e36041c2))
## [4.9.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.9.1...v4.9.2) (2025-06-19)
### Bug Fixes
* bad brownfield yml ([09d2ad6](https://github.com/bmadcode/BMAD-METHOD/commit/09d2ad6aea187996d0a2e1dff27d9bf7e3e6dc06))
- bad brownfield yml ([09d2ad6](https://github.com/bmadcode/BMAD-METHOD/commit/09d2ad6aea187996d0a2e1dff27d9bf7e3e6dc06))
## [4.9.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.9.0...v4.9.1) (2025-06-19)
### Bug Fixes
* dist bundles updated ([d9a989d](https://github.com/bmadcode/BMAD-METHOD/commit/d9a989dbe50da62cf598afa07a8588229c56b69c))
- dist bundles updated ([d9a989d](https://github.com/bmadcode/BMAD-METHOD/commit/d9a989dbe50da62cf598afa07a8588229c56b69c))
# [4.9.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.8.0...v4.9.0) (2025-06-19)
### Features
* dev can use debug log configured in core-config.yaml ([0e5aaf0](https://github.com/bmadcode/BMAD-METHOD/commit/0e5aaf07bbc6fd9f2706ea26e35f5f38fd72147a))
- dev can use debug log configured in core-config.yaml ([0e5aaf0](https://github.com/bmadcode/BMAD-METHOD/commit/0e5aaf07bbc6fd9f2706ea26e35f5f38fd72147a))
# [4.8.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.7.0...v4.8.0) (2025-06-19)
### Bug Fixes
* installer has fast v4 update option now to keep the bmad method up to date with changes easily without breaking any customizations from the user. The SM and DEV are much more configurable to find epics stories and architectureal information when the prd and architecture are deviant from v4 templates and/or have not been sharded. so a config will give the user the option to configure the SM to use the full large documents or the sharded versions! ([aea7f3c](https://github.com/bmadcode/BMAD-METHOD/commit/aea7f3cc86e749d25ed18bed761dc2839023b3b3))
* prevent double installation when updating v4 ([af0e767](https://github.com/bmadcode/BMAD-METHOD/commit/af0e767ecf1b91d41f114e1a5d7bf5da08de57d6))
* resolve undefined config properties in performUpdate ([0185e01](https://github.com/bmadcode/BMAD-METHOD/commit/0185e012bb579948a4de1ea3950db4e399761619))
* update file-manager to properly handle YAML manifest files ([724cdd0](https://github.com/bmadcode/BMAD-METHOD/commit/724cdd07a199cb12b82236ad34ca1a0c61eb43e2))
- installer has fast v4 update option now to keep the bmad method up to date with changes easily without breaking any customizations from the user. The SM and DEV are much more configurable to find epics stories and architectureal information when the prd and architecture are deviant from v4 templates and/or have not been sharded. so a config will give the user the option to configure the SM to use the full large documents or the sharded versions! ([aea7f3c](https://github.com/bmadcode/BMAD-METHOD/commit/aea7f3cc86e749d25ed18bed761dc2839023b3b3))
- prevent double installation when updating v4 ([af0e767](https://github.com/bmadcode/BMAD-METHOD/commit/af0e767ecf1b91d41f114e1a5d7bf5da08de57d6))
- resolve undefined config properties in performUpdate ([0185e01](https://github.com/bmadcode/BMAD-METHOD/commit/0185e012bb579948a4de1ea3950db4e399761619))
- update file-manager to properly handle YAML manifest files ([724cdd0](https://github.com/bmadcode/BMAD-METHOD/commit/724cdd07a199cb12b82236ad34ca1a0c61eb43e2))
### Features
* add early v4 detection for improved update flow ([29e7bbf](https://github.com/bmadcode/BMAD-METHOD/commit/29e7bbf4c5aa7e17854061a5ee695f44324f307a))
* add file resolution context for IDE agents ([74d9bb4](https://github.com/bmadcode/BMAD-METHOD/commit/74d9bb4b2b70a341673849a1df704f6eac70c3de))
* update web builder to remove IDE-specific properties from agent bundles ([2f2a1e7](https://github.com/bmadcode/BMAD-METHOD/commit/2f2a1e72d6a70f8127db6ba58a563d0f289621c3))
- add early v4 detection for improved update flow ([29e7bbf](https://github.com/bmadcode/BMAD-METHOD/commit/29e7bbf4c5aa7e17854061a5ee695f44324f307a))
- add file resolution context for IDE agents ([74d9bb4](https://github.com/bmadcode/BMAD-METHOD/commit/74d9bb4b2b70a341673849a1df704f6eac70c3de))
- update web builder to remove IDE-specific properties from agent bundles ([2f2a1e7](https://github.com/bmadcode/BMAD-METHOD/commit/2f2a1e72d6a70f8127db6ba58a563d0f289621c3))
# [4.7.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.6.3...v4.7.0) (2025-06-19)
### Features
* extensive bmad-kb for web orchestrator to be much more helpful ([e663a11](https://github.com/bmadcode/BMAD-METHOD/commit/e663a1146b89e7b5078d9726649a51ae5624da46))
- extensive bmad-kb for web orchestrator to be much more helpful ([e663a11](https://github.com/bmadcode/BMAD-METHOD/commit/e663a1146b89e7b5078d9726649a51ae5624da46))
## [4.6.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.6.2...v4.6.3) (2025-06-19)
### Bug Fixes
* SM fixed file resolution issue in v4 ([61ab116](https://github.com/bmadcode/BMAD-METHOD/commit/61ab1161e59a92d657ab663082abcaf26729fa6b))
- SM fixed file resolution issue in v4 ([61ab116](https://github.com/bmadcode/BMAD-METHOD/commit/61ab1161e59a92d657ab663082abcaf26729fa6b))
## [4.6.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.6.1...v4.6.2) (2025-06-19)
### Bug Fixes
* installer upgrade path fixed ([bd6a558](https://github.com/bmadcode/BMAD-METHOD/commit/bd6a55892906077a700f488bde175b57e846729d))
- installer upgrade path fixed ([bd6a558](https://github.com/bmadcode/BMAD-METHOD/commit/bd6a55892906077a700f488bde175b57e846729d))
## [4.6.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.6.0...v4.6.1) (2025-06-19)
### Bug Fixes
* expansion pack builder now includes proper dependencies from core as needed, and default template file name save added to template llm instructions ([9dded00](https://github.com/bmadcode/BMAD-METHOD/commit/9dded003565879901246885d60787695e0d0b7bd))
- expansion pack builder now includes proper dependencies from core as needed, and default template file name save added to template llm instructions ([9dded00](https://github.com/bmadcode/BMAD-METHOD/commit/9dded003565879901246885d60787695e0d0b7bd))
# [4.6.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.5.1...v4.6.0) (2025-06-18)
### Bug Fixes
* orchestractor yml ([3727cc7](https://github.com/bmadcode/BMAD-METHOD/commit/3727cc764a7c7295932ff872e2e5be8b4c4e6859))
- orchestractor yml ([3727cc7](https://github.com/bmadcode/BMAD-METHOD/commit/3727cc764a7c7295932ff872e2e5be8b4c4e6859))
### Features
* removed some templates that are not ready for use ([b03aece](https://github.com/bmadcode/BMAD-METHOD/commit/b03aece79e52cfe9585225de5aff7659293d9295))
- removed some templates that are not ready for use ([b03aece](https://github.com/bmadcode/BMAD-METHOD/commit/b03aece79e52cfe9585225de5aff7659293d9295))
## [4.5.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.5.0...v4.5.1) (2025-06-18)
### Bug Fixes
* docs had some ide specific errors ([a954c7e](https://github.com/bmadcode/BMAD-METHOD/commit/a954c7e24284a6637483a9e47fc63a8f9d7dfbad))
- docs had some ide specific errors ([a954c7e](https://github.com/bmadcode/BMAD-METHOD/commit/a954c7e24284a6637483a9e47fc63a8f9d7dfbad))
# [4.5.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.4.2...v4.5.0) (2025-06-17)
### Bug Fixes
* installer relative path issue for npx resolved ([8b9bda5](https://github.com/bmadcode/BMAD-METHOD/commit/8b9bda5639ec882f1887f20b4610a6c2183042c6))
* readme updated to indicate move of web-bundles ([7e9574f](https://github.com/bmadcode/BMAD-METHOD/commit/7e9574f571f41ae5003a1664d999c282dd7398be))
* temp disable yml linting ([296c2fb](https://github.com/bmadcode/BMAD-METHOD/commit/296c2fbcbd9ac40b3c68633ba7454aacf1e31204))
* update documentation and installer to reflect .roomodes file location in project root ([#236](https://github.com/bmadcode/BMAD-METHOD/issues/236)) ([bd7f030](https://github.com/bmadcode/BMAD-METHOD/commit/bd7f03016bfa13e39cb39aedb24db9fccbed18a7))
- installer relative path issue for npx resolved ([8b9bda5](https://github.com/bmadcode/BMAD-METHOD/commit/8b9bda5639ec882f1887f20b4610a6c2183042c6))
- readme updated to indicate move of web-bundles ([7e9574f](https://github.com/bmadcode/BMAD-METHOD/commit/7e9574f571f41ae5003a1664d999c282dd7398be))
- temp disable yml linting ([296c2fb](https://github.com/bmadcode/BMAD-METHOD/commit/296c2fbcbd9ac40b3c68633ba7454aacf1e31204))
- update documentation and installer to reflect .roomodes file location in project root ([#236](https://github.com/bmadcode/BMAD-METHOD/issues/236)) ([bd7f030](https://github.com/bmadcode/BMAD-METHOD/commit/bd7f03016bfa13e39cb39aedb24db9fccbed18a7))
### Features
* bmad the creator expansion with some basic tools for modifying bmad method ([2d61df4](https://github.com/bmadcode/BMAD-METHOD/commit/2d61df419ac683f5691b6ee3fab81174f3d2cdde))
* can now select different web bundles from what ide agents are installed ([0c41633](https://github.com/bmadcode/BMAD-METHOD/commit/0c41633b07d7dd4d7dda8d3a14d572eac0dcbb47))
* installer offers option to install web bundles ([e934769](https://github.com/bmadcode/BMAD-METHOD/commit/e934769a5e35dba99f59b4e2e6bb49131c43a526))
* robust installer ([1fbeed7](https://github.com/bmadcode/BMAD-METHOD/commit/1fbeed75ea446b0912277cfec376ee34f0b3d853))
- bmad the creator expansion with some basic tools for modifying bmad method ([2d61df4](https://github.com/bmadcode/BMAD-METHOD/commit/2d61df419ac683f5691b6ee3fab81174f3d2cdde))
- can now select different web bundles from what ide agents are installed ([0c41633](https://github.com/bmadcode/BMAD-METHOD/commit/0c41633b07d7dd4d7dda8d3a14d572eac0dcbb47))
- installer offers option to install web bundles ([e934769](https://github.com/bmadcode/BMAD-METHOD/commit/e934769a5e35dba99f59b4e2e6bb49131c43a526))
- robust installer ([1fbeed7](https://github.com/bmadcode/BMAD-METHOD/commit/1fbeed75ea446b0912277cfec376ee34f0b3d853))
## [4.4.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.4.1...v4.4.2) (2025-06-17)
### Bug Fixes
* single agent install and team installation support ([18a382b](https://github.com/bmadcode/BMAD-METHOD/commit/18a382baa4e4a82db20affa3525eb951af1081e0))
- single agent install and team installation support ([18a382b](https://github.com/bmadcode/BMAD-METHOD/commit/18a382baa4e4a82db20affa3525eb951af1081e0))
## [4.4.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.4.0...v4.4.1) (2025-06-17)
@@ -561,10 +574,6 @@
- Manual version bumping via npm scripts is now disabled. Use conventional commits for automated releases.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
# [4.2.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.1.0...v4.2.0) (2025-06-15)
### Bug Fixes
@@ -673,3 +682,5 @@ Co-Authored-By: Claude <noreply@anthropic.com>
### Features
- add versioning and release automation ([0ea5e50](https://github.com/bmadcode/BMAD-METHOD/commit/0ea5e50aa7ace5946d0100c180dd4c0da3e2fd8c))
# Promote to stable release 5.0.0

View File

@@ -8,7 +8,7 @@ Thank you for considering contributing to this project! This document outlines t
Also note, we use the discussions feature in GitHub to have a community to discuss potential ideas, uses, additions and enhancements.
💬 **Discord Community**: Join our [Discord server](https://discord.gg/g6ypHytrCB) for real-time discussions:
💬 **Discord Community**: Join our [Discord server](https://discord.gg/gk8jAdXWmj) for real-time discussions:
- **#general-dev** - Technical discussions, feature ideas, and development questions
- **#bugs-issues** - Bug reports and issue discussions

View File

@@ -40,12 +40,12 @@ This two-phase approach eliminates both **planning inconsistency** and **context
- **[Install and Build software with Full Stack Agile AI Team](#quick-start)** → Quick Start Instruction
- **[Learn how to use BMad](docs/user-guide.md)** → Complete user guide and walkthrough
- **[See available AI agents](#available-agents)** → Specialized roles for your team
- **[See available AI agents](/bmad-core/agents))** → Specialized roles for your team
- **[Explore non-technical uses](#-beyond-software-development---expansion-packs)** → Creative writing, business, wellness, education
- **[Create my own AI agents](#creating-your-own-expansion-pack)** → Build agents for your domain
- **[Create my own AI agents](docs/expansion-packs.md)** → Build agents for your domain
- **[Browse ready-made expansion packs](expansion-packs/)** → Game dev, DevOps, infrastructure and get inspired with ideas and examples
- **[Understand the architecture](docs/core-architecture.md)** → Technical deep dive
- **[Join the community](https://discord.gg/g6ypHytrCB)** → Get help and share ideas
- **[Join the community](https://discord.gg/gk8jAdXWmj)** → Get help and share ideas
## Important: Keep Your BMad Installation Updated
@@ -110,6 +110,86 @@ npm run install:bmad # build and install all to a destination folder
BMad's natural language framework works in ANY domain. Expansion packs provide specialized AI agents for creative writing, business strategy, health & wellness, education, and more. Also expansion packs can expand the core BMad-Method with specific functionality that is not generic for all cases. [See the Expansion Packs Guide](docs/expansion-packs.md) and learn to create your own!
## Codebase Flattener Tool
The BMad-Method includes a powerful codebase flattener tool designed to prepare your project files for AI model consumption. This tool aggregates your entire codebase into a single XML file, making it easy to share your project context with AI assistants for analysis, debugging, or development assistance.
### Features
- **AI-Optimized Output**: Generates clean XML format specifically designed for AI model consumption
- **Smart Filtering**: Automatically respects `.gitignore` patterns to exclude unnecessary files
- **Binary File Detection**: Intelligently identifies and excludes binary files, focusing on source code
- **Progress Tracking**: Real-time progress indicators and comprehensive completion statistics
- **Flexible Output**: Customizable output file location and naming
### Usage
```bash
# Basic usage - creates flattened-codebase.xml in current directory
npx bmad-method flatten
# Specify custom input directory
npx bmad-method flatten --input /path/to/source/directory
npx bmad-method flatten -i /path/to/source/directory
# Specify custom output file
npx bmad-method flatten --output my-project.xml
npx bmad-method flatten -o /path/to/output/codebase.xml
# Combine input and output options
npx bmad-method flatten --input /path/to/source --output /path/to/output/codebase.xml
```
### Example Output
The tool will display progress and provide a comprehensive summary:
```text
📊 Completion Summary:
✅ Successfully processed 156 files into flattened-codebase.xml
📁 Output file: /path/to/your/project/flattened-codebase.xml
📏 Total source size: 2.3 MB
📄 Generated XML size: 2.1 MB
📝 Total lines of code: 15,847
🔢 Estimated tokens: 542,891
📊 File breakdown: 142 text, 14 binary, 0 errors
```
The generated XML file contains your project's text-based source files in a structured format that AI models can easily parse and understand, making it perfect for code reviews, architecture discussions, or getting AI assistance with your BMad-Method projects.
#### Advanced Usage & Options
- CLI options
- `-i, --input <path>`: Directory to flatten. Default: current working directory or auto-detected project root when run interactively.
- `-o, --output <path>`: Output file path. Default: `flattened-codebase.xml` in the chosen directory.
- Interactive mode
- If you do not pass `--input` and `--output` and the terminal is interactive (TTY), the tool will attempt to detect your project root (by looking for markers like `.git`, `package.json`, etc.) and prompt you to confirm or override the paths.
- In non-interactive contexts (e.g., CI), it will prefer the detected root silently; otherwise it falls back to the current directory and default filename.
- File discovery and ignoring
- Uses `git ls-files` when inside a git repository for speed and correctness; otherwise falls back to a glob-based scan.
- Applies your `.gitignore` plus a curated set of default ignore patterns (e.g., `node_modules`, build outputs, caches, logs, IDE folders, lockfiles, large media/binaries, `.env*`, and previously generated XML outputs).
- Binary handling
- Binary files are detected and excluded from the XML content. They are counted in the final summary but not embedded in the output.
- XML format and safety
- UTF-8 encoded file with root element `<files>`.
- Each text file is emitted as a `<file path="relative/path">` element whose content is wrapped in `<![CDATA[ ... ]]>`.
- The tool safely handles occurrences of `]]>` inside content by splitting the CDATA to preserve correctness.
- File contents are preserved as-is and indented for readability inside the XML.
- Performance
- Concurrency is selected automatically based on your CPU and workload size. No configuration required.
- Running inside a git repo improves discovery performance.
#### Minimal XML example
```xml
<?xml version="1.0" encoding="UTF-8"?>
<files>
<file path="src/index.js"><![CDATA[
// your source content
]]></file>
</files>
```
## Documentation & Resources
### Essential Guides
@@ -117,11 +197,10 @@ BMad's natural language framework works in ANY domain. Expansion packs provide s
- 📖 **[User Guide](docs/user-guide.md)** - Complete walkthrough from project inception to completion
- 🏗️ **[Core Architecture](docs/core-architecture.md)** - Technical deep dive and system design
- 🚀 **[Expansion Packs Guide](docs/expansion-packs.md)** - Extend BMad to any domain beyond software development
- [IDE Specific Guides available in this folder](docs/agentic-tools/)
## Support
- 💬 [Discord Community](https://discord.gg/g6ypHytrCB)
- 💬 [Discord Community](https://discord.gg/gk8jAdXWmj)
- 🐛 [Issue Tracker](https://github.com/bmadcode/bmad-method/issues)
- 💬 [Discussions](https://github.com/bmadcode/bmad-method/discussions)

View File

@@ -4,7 +4,7 @@ bundle:
description: Includes every core system agent.
agents:
- bmad-orchestrator
- '*'
- "*"
workflows:
- brownfield-fullstack.yaml
- brownfield-service.yaml

View File

@@ -54,14 +54,14 @@ persona:
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
- create-project-brief: use task create-doc with project-brief-tmpl.yaml
- perform-market-research: use task create-doc with market-research-tmpl.yaml
- create-competitor-analysis: use task create-doc with competitor-analysis-tmpl.yaml
- yolo: Toggle Yolo Mode
- doc-out: Output full document to current destination file
- execute-checklist {checklist}: Run task execute-checklist (default->architect-checklist)
- research-prompt {topic}: execute task create-deep-research-prompt for architectural decisions
- brainstorm {topic}: Facilitate structured brainstorming session
- doc-out: Output full document in progress to current destination file
- research-prompt {topic}: execute task create-deep-research-prompt.md
- brainstorm {topic}: Facilitate structured brainstorming session (run task facilitate-brainstorming-session.md with template brainstorming-output-tmpl.yaml)
- elicit: run the task advanced-elicitation
- document-project: Analyze and document existing project structure comprehensively
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
dependencies:
tasks:

View File

@@ -1,6 +1,5 @@
# architect
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
@@ -55,11 +54,16 @@ persona:
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
- yolo: Toggle Yolo Mode
- create-full-stack-architecture: use create-doc with fullstack-architecture-tmpl.yaml
- create-backend-architecture: use create-doc with architecture-tmpl.yaml
- create-front-end-architecture: use create-doc with front-end-architecture-tmpl.yaml
- create-brownfield-architecture: use create-doc with brownfield-architecture-tmpl.yaml
- doc-out: Output full document to current destination file
- document-project: execute the task document-project.md
- execute-checklist {checklist}: Run task execute-checklist (default->architect-checklist)
- research {topic}: execute task create-deep-research-prompt for architectural decisions
- research {topic}: execute task create-deep-research-prompt
- shard-prd: run the task shard-doc.md for the provided architecture.md (ask if not found)
- yolo: Toggle Yolo Mode
- exit: Say goodbye as the Architect, and then abandon inhabiting this persona
dependencies:
tasks:

View File

@@ -1,6 +1,5 @@
# BMad Master
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
@@ -52,10 +51,11 @@ commands:
- kb: Toggle KB mode off (default) or on, when on will load and reference the {root}/data/bmad-kb.md and converse with the user answering his questions with this informational resource
- task {task}: Execute task, if not found or none specified, ONLY list available dependencies/tasks listed below
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
- doc-out: Output full document to current destination file
- document-project: execute the task document-project.md
- execute-checklist {checklist}: Run task execute-checklist (no checklist = ONLY show available checklists listed under dependencies/checklist below)
- shard-doc {document} {destination}: run the task shard-doc against the optionally provided document to the specified destination
- yolo: Toggle Yolo Mode
- doc-out: Output full document to current destination file
- exit: Exit (confirm)
dependencies:

View File

@@ -1,6 +1,5 @@
# BMad Web Orchestrator
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
@@ -132,7 +131,7 @@ workflow-guidance:
- Understand each workflow's purpose, options, and decision points
- Ask clarifying questions based on the workflow's structure
- Guide users through workflow selection when multiple options exist
- When appropriate, suggest: "Would you like me to create a detailed workflow plan before starting?"
- When appropriate, suggest: 'Would you like me to create a detailed workflow plan before starting?'
- For workflows with divergent paths, help users choose the right path
- Adapt questions to the specific domain (e.g., game dev vs infrastructure vs web dev)
- Only recommend workflows that actually exist in the current bundle

View File

@@ -35,10 +35,9 @@ agent:
id: dev
title: Full Stack Developer
icon: 💻
whenToUse: "Use for code implementation, debugging, refactoring, and development best practices"
whenToUse: 'Use for code implementation, debugging, refactoring, and development best practices'
customization:
persona:
role: Expert Senior Software Engineer & Implementation Specialist
style: Extremely concise, pragmatic, detail-oriented, solution-focused
@@ -57,15 +56,15 @@ commands:
- run-tests: Execute linting and tests
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
develop-story:
order-of-execution: "Read (first or next) task→Implement Task and its subtasks→Write tests→Execute validations→Only if ALL pass, then update the task checkbox with [x]→Update story section File List to ensure it lists and new or modified or deleted source file→repeat order-of-execution until complete"
story-file-updates-ONLY:
- develop-story:
- order-of-execution: 'Read (first or next) task→Implement Task and its subtasks→Write tests→Execute validations→Only if ALL pass, then update the task checkbox with [x]→Update story section File List to ensure it lists and new or modified or deleted source file→repeat order-of-execution until complete'
- story-file-updates-ONLY:
- CRITICAL: ONLY UPDATE THE STORY FILE WITH UPDATES TO SECTIONS INDICATED BELOW. DO NOT MODIFY ANY OTHER SECTIONS.
- CRITICAL: You are ONLY authorized to edit these specific sections of story files - Tasks / Subtasks Checkboxes, Dev Agent Record section and all its subsections, Agent Model Used, Debug Log References, Completion Notes List, File List, Change Log, Status
- CRITICAL: DO NOT modify Status, Story, Acceptance Criteria, Dev Notes, Testing sections, or any other sections not listed above
blocking: "HALT for: Unapproved deps needed, confirm with user | Ambiguous after story check | 3 failures attempting to implement or fix something repeatedly | Missing config | Failing regression"
ready-for-review: "Code matches requirements + All validations pass + Follows standards + File List complete"
completion: "All Tasks and Subtasks marked [x] and have tests→Validations and full regression passes (DON'T BE LAZY, EXECUTE ALL TESTS and CONFIRM)→Ensure File List is Complete→run the task execute-checklist for the checklist story-dod-checklist→set story status: 'Ready for Review'→HALT"
- blocking: 'HALT for: Unapproved deps needed, confirm with user | Ambiguous after story check | 3 failures attempting to implement or fix something repeatedly | Missing config | Failing regression'
- ready-for-review: 'Code matches requirements + All validations pass + Follows standards + File List complete'
- completion: "All Tasks and Subtasks marked [x] and have tests→Validations and full regression passes (DON'T BE LAZY, EXECUTE ALL TESTS and CONFIRM)→Ensure File List is Complete→run the task execute-checklist for the checklist story-dod-checklist→set story status: 'Ready for Review'→HALT"
dependencies:
tasks:

View File

@@ -50,9 +50,16 @@ persona:
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- create-doc {template}: execute task create-doc for template provided, if no template then ONLY list dependencies.templates
- yolo: Toggle Yolo Mode
- create-prd: run task create-doc.md with template prd-tmpl.yaml
- create-brownfield-prd: run task create-doc.md with template brownfield-prd-tmpl.yaml
- create-brownfield-epic: run task brownfield-create-epic.md
- create-brownfield-story: run task brownfield-create-story.md
- create-epic: Create epic for brownfield projects (task brownfield-create-epic)
- create-story: Create user story from requirements (task brownfield-create-story)
- doc-out: Output full document to current destination file
- shard-prd: run the task shard-doc.md for the provided prd.md (ask if not found)
- correct-course: execute the correct-course task
- yolo: Toggle Yolo Mode
- exit: Exit (confirm)
dependencies:
tasks:

View File

@@ -53,23 +53,20 @@ persona:
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
- execute-checklist {checklist}: Run task execute-checklist (default->po-master-checklist)
- execute-checklist-po: Run task execute-checklist (checklist po-master-checklist)
- shard-doc {document} {destination}: run the task shard-doc against the optionally provided document to the specified destination
- correct-course: execute the correct-course task
- create-epic: Create epic for brownfield projects (task brownfield-create-epic)
- create-story: Create user story from requirements (task brownfield-create-story)
- yolo: Toggle Yolo Mode off on - on will skip doc section confirmations
- doc-out: Output full document to current destination file
- validate-story-draft {story}: run the task validate-next-story against the provided story file
- yolo: Toggle Yolo Mode off on - on will skip doc section confirmations
- exit: Exit (confirm)
dependencies:
tasks:
- execute-checklist.md
- shard-doc.md
- correct-course.md
- brownfield-create-epic.md
- brownfield-create-story.md
- validate-next-story.md
templates:
- story-tmpl.yaml

View File

@@ -30,26 +30,30 @@ activation-instructions:
agent:
name: Quinn
id: qa
title: Senior Developer & QA Architect
title: Test Architect & Quality Advisor
icon: 🧪
whenToUse: Use for senior code review, refactoring, test planning, quality assurance, and mentoring through code improvements
whenToUse: |
Use for comprehensive test architecture review, quality gate decisions,
and code improvement. Provides thorough analysis including requirements
traceability, risk assessment, and test strategy.
Advisory only - teams choose their quality bar.
customization: null
persona:
role: Senior Developer & Test Architect
style: Methodical, detail-oriented, quality-focused, mentoring, strategic
identity: Senior developer with deep expertise in code quality, architecture, and test automation
focus: Code excellence through review, refactoring, and comprehensive testing strategies
role: Test Architect with Quality Advisory Authority
style: Comprehensive, systematic, advisory, educational, pragmatic
identity: Test architect who provides thorough quality assessment and actionable recommendations without blocking progress
focus: Comprehensive quality analysis through test architecture, risk assessment, and advisory gates
core_principles:
- Senior Developer Mindset - Review and improve code as a senior mentoring juniors
- Active Refactoring - Don't just identify issues, fix them with clear explanations
- Test Strategy & Architecture - Design holistic testing strategies across all levels
- Code Quality Excellence - Enforce best practices, patterns, and clean code principles
- Shift-Left Testing - Integrate testing early in development lifecycle
- Performance & Security - Proactively identify and fix performance/security issues
- Mentorship Through Action - Explain WHY and HOW when making improvements
- Risk-Based Testing - Prioritize testing based on risk and critical areas
- Continuous Improvement - Balance perfection with pragmatism
- Architecture & Design Patterns - Ensure proper patterns and maintainable code structure
- Depth As Needed - Go deep based on risk signals, stay concise when low risk
- Requirements Traceability - Map all stories to tests using Given-When-Then patterns
- Risk-Based Testing - Assess and prioritize by probability × impact
- Quality Attributes - Validate NFRs (security, performance, reliability) via scenarios
- Testability Assessment - Evaluate controllability, observability, debuggability
- Gate Governance - Provide clear PASS/CONCERNS/FAIL/WAIVED decisions with rationale
- Advisory Excellence - Educate through documentation, never block arbitrarily
- Technical Debt Awareness - Identify and quantify debt with improvement suggestions
- LLM Acceleration - Use LLMs to accelerate thorough yet focused analysis
- Pragmatic Balance - Distinguish must-fix from nice-to-have improvements
story-file-permissions:
- CRITICAL: When reviewing stories, you are ONLY authorized to update the "QA Results" section of story files
- CRITICAL: DO NOT modify any other sections including Status, Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Testing, Dev Agent Record, Change Log, or any other sections
@@ -57,14 +61,28 @@ story-file-permissions:
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- review {story}: execute the task review-story for the highest sequence story in docs/stories unless another is specified - keep any specified technical-preferences in mind as needed
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
- exit: Say goodbye as the QA Engineer, and then abandon inhabiting this persona
- review {story}: |
Adaptive, risk-aware comprehensive review.
Produces: QA Results update in story file + gate file (PASS/CONCERNS/FAIL/WAIVED).
Gate file location: docs/qa/gates/{epic}.{story}-{slug}.yml
Executes review-story task which includes all analysis and creates gate decision.
- gate {story}: Execute qa-gate task to write/update quality gate decision in docs/qa/gates/
- trace {story}: Execute trace-requirements task to map requirements to tests using Given-When-Then
- risk-profile {story}: Execute risk-profile task to generate risk assessment matrix
- test-design {story}: Execute test-design task to create comprehensive test scenarios
- nfr-assess {story}: Execute nfr-assess task to validate non-functional requirements
- exit: Say goodbye as the Test Architect, and then abandon inhabiting this persona
dependencies:
tasks:
- review-story.md
- qa-gate.md
- trace-requirements.md
- risk-profile.md
- test-design.md
- nfr-assess.md
data:
- technical-preferences.md
templates:
- story-tmpl.yaml
- qa-gate-tmpl.yaml
```

View File

@@ -46,9 +46,9 @@ persona:
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- draft: Execute task create-next-story
- correct-course: Execute task correct-course
- checklist {checklist}: Show numbered list of checklists if not provided, execute task execute-checklist
- draft: Execute task create-next-story.md
- correct-course: Execute task correct-course.md
- story-checklist: Execute task execute-checklist.md with checklist story-draft-checklist.md
- exit: Say goodbye as the Scrum Master, and then abandon inhabiting this persona
dependencies:
tasks:

View File

@@ -51,15 +51,12 @@ persona:
# All commands require * prefix when used (e.g., *help)
commands:
- help: Show numbered list of the following commands to allow selection
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
- generate-ui-prompt: Create AI frontend generation prompt
- research {topic}: Execute create-deep-research-prompt task to generate a prompt to init UX deep research
- execute-checklist {checklist}: Run task execute-checklist (default->po-master-checklist)
- create-front-end-spec: run task create-doc.md with template front-end-spec-tmpl.yaml
- generate-ui-prompt: Run task generate-ai-frontend-prompt.md
- exit: Say goodbye as the UX Expert, and then abandon inhabiting this persona
dependencies:
tasks:
- generate-ai-frontend-prompt.md
- create-deep-research-prompt.md
- create-doc.md
- execute-checklist.md
templates:

View File

@@ -403,33 +403,28 @@ Ask the user if they want to work through the checklist:
Now that you've completed the checklist, generate a comprehensive validation report that includes:
1. Executive Summary
- Overall architecture readiness (High/Medium/Low)
- Critical risks identified
- Key strengths of the architecture
- Project type (Full-stack/Frontend/Backend) and sections evaluated
2. Section Analysis
- Pass rate for each major section (percentage of items passed)
- Most concerning failures or gaps
- Sections requiring immediate attention
- Note any sections skipped due to project type
3. Risk Assessment
- Top 5 risks by severity
- Mitigation recommendations for each
- Timeline impact of addressing issues
4. Recommendations
- Must-fix items before development
- Should-fix items for better quality
- Nice-to-have improvements
5. AI Implementation Readiness
- Specific concerns for AI agent implementation
- Areas needing additional clarification
- Complexity hotspots to address

View File

@@ -304,7 +304,6 @@ Ask the user if they want to work through the checklist:
Create a comprehensive validation report that includes:
1. Executive Summary
- Overall PRD completeness (percentage)
- MVP scope appropriateness (Too Large/Just Right/Too Small)
- Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
@@ -312,26 +311,22 @@ Create a comprehensive validation report that includes:
2. Category Analysis Table
Fill in the actual table with:
- Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
- Critical Issues: Specific problems that block progress
3. Top Issues by Priority
- BLOCKERS: Must fix before architect can proceed
- HIGH: Should fix for quality
- MEDIUM: Would improve clarity
- LOW: Nice to have
4. MVP Scope Assessment
- Features that might be cut for true MVP
- Missing features that are essential
- Complexity concerns
- Timeline realism
5. Technical Readiness
- Clarity of technical constraints
- Identified technical risks
- Areas needing architect investigation

View File

@@ -8,12 +8,10 @@ PROJECT TYPE DETECTION:
First, determine the project type by checking:
1. Is this a GREENFIELD project (new from scratch)?
- Look for: New project initialization, no existing codebase references
- Check for: prd.md, architecture.md, new project setup stories
2. Is this a BROWNFIELD project (enhancing existing system)?
- Look for: References to existing codebase, enhancement/modification language
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
@@ -347,7 +345,6 @@ Ask the user if they want to work through the checklist:
Generate a comprehensive validation report that adapts to project type:
1. Executive Summary
- Project type: [Greenfield/Brownfield] with [UI/No UI]
- Overall readiness (percentage)
- Go/No-Go recommendation
@@ -357,42 +354,36 @@ Generate a comprehensive validation report that adapts to project type:
2. Project-Specific Analysis
FOR GREENFIELD:
- Setup completeness
- Dependency sequencing
- MVP scope appropriateness
- Development timeline feasibility
FOR BROWNFIELD:
- Integration risk level (High/Medium/Low)
- Existing system impact assessment
- Rollback readiness
- User disruption potential
3. Risk Assessment
- Top 5 risks by severity
- Mitigation recommendations
- Timeline impact of addressing issues
- [BROWNFIELD] Specific integration risks
4. MVP Completeness
- Core features coverage
- Missing essential functionality
- Scope creep identified
- True MVP vs over-engineering
5. Implementation Readiness
- Developer clarity score (1-10)
- Ambiguous requirements count
- Missing technical details
- [BROWNFIELD] Integration point clarity
6. Recommendations
- Must-fix before development
- Should-fix for quality
- Consider for improvement

View File

@@ -25,14 +25,12 @@ The goal is quality delivery, not just checking boxes.]]
1. **Requirements Met:**
[[LLM: Be specific - list each requirement and whether it's complete]]
- [ ] All functional requirements specified in the story are implemented.
- [ ] All acceptance criteria defined in the story are met.
2. **Coding Standards & Project Structure:**
[[LLM: Code quality matters for maintainability. Check each item carefully]]
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
- [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
- [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
@@ -44,7 +42,6 @@ The goal is quality delivery, not just checking boxes.]]
3. **Testing:**
[[LLM: Testing proves your code works. Be honest about test coverage]]
- [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
- [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
- [ ] All tests (unit, integration, E2E if applicable) pass successfully.
@@ -53,14 +50,12 @@ The goal is quality delivery, not just checking boxes.]]
4. **Functionality & Verification:**
[[LLM: Did you actually run and test your code? Be specific about what you tested]]
- [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
- [ ] Edge cases and potential error conditions considered and handled gracefully.
5. **Story Administration:**
[[LLM: Documentation helps the next developer. What should they know?]]
- [ ] All tasks within the story file are marked as complete.
- [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
- [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
@@ -68,7 +63,6 @@ The goal is quality delivery, not just checking boxes.]]
6. **Dependencies, Build & Configuration:**
[[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
- [ ] Project builds successfully without errors.
- [ ] Project linting passes
- [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
@@ -79,7 +73,6 @@ The goal is quality delivery, not just checking boxes.]]
7. **Documentation (If Applicable):**
[[LLM: Good documentation prevents future confusion. What needs explaining?]]
- [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
- [ ] User-facing documentation updated, if changes impact users.
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.

View File

@@ -117,19 +117,16 @@ Note: We don't need every file listed - just the important ones.]]
Generate a concise validation report:
1. Quick Summary
- Story readiness: READY / NEEDS REVISION / BLOCKED
- Clarity score (1-10)
- Major gaps identified
2. Fill in the validation table with:
- PASS: Requirements clearly met
- PARTIAL: Some gaps but workable
- FAIL: Critical information missing
3. Specific Issues (if any)
- List concrete problems to fix
- Suggest specific improvements
- Identify any blocking dependencies

View File

@@ -298,7 +298,7 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
- **Claude Code**: `/agent-name` (e.g., `/bmad-master`)
- **Cursor**: `@agent-name` (e.g., `@bmad-master`)
- **Windsurf**: `@agent-name` (e.g., `@bmad-master`)
- **Windsurf**: `/agent-name` (e.g., `/bmad-master`)
- **Trae**: `@agent-name` (e.g., `@bmad-master`)
- **Roo Code**: Select mode from mode selector (e.g., `bmad-master`)
- **GitHub Copilot**: Open the Chat view (`⌃⌘I` on Mac, `Ctrl+Alt+I` on Windows/Linux) and select **Agent** from the chat mode selector.
@@ -651,8 +651,11 @@ Templates with Level 2 headings (`##`) can be automatically sharded:
```markdown
## Goals and Background Context
## Requirements
## User Interface Design Goals
## Success Metrics
```

View File

@@ -3,16 +3,19 @@
## Core Reflective Methods
**Expand or Contract for Audience**
- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
- Identify specific target audience if relevant
- Tailor content complexity and depth accordingly
**Explain Reasoning (CoT Step-by-Step)**
- Walk through the step-by-step thinking process
- Reveal underlying assumptions and decision points
- Show how conclusions were reached from current role's perspective
**Critique and Refine**
- Review output for flaws, inconsistencies, or improvement areas
- Identify specific weaknesses from role's expertise
- Suggest refined version reflecting domain knowledge
@@ -20,12 +23,14 @@
## Structural Analysis Methods
**Analyze Logical Flow and Dependencies**
- Examine content structure for logical progression
- Check internal consistency and coherence
- Identify and validate dependencies between elements
- Confirm effective ordering and sequencing
**Assess Alignment with Overall Goals**
- Evaluate content contribution to stated objectives
- Identify any misalignments or gaps
- Interpret alignment from specific role's perspective
@@ -34,12 +39,14 @@
## Risk and Challenge Methods
**Identify Potential Risks and Unforeseen Issues**
- Brainstorm potential risks from role's expertise
- Identify overlooked edge cases or scenarios
- Anticipate unintended consequences
- Highlight implementation challenges
**Challenge from Critical Perspective**
- Adopt critical stance on current content
- Play devil's advocate from specified viewpoint
- Argue against proposal highlighting weaknesses
@@ -48,12 +55,14 @@
## Creative Exploration Methods
**Tree of Thoughts Deep Dive**
- Break problem into discrete "thoughts" or intermediate steps
- Explore multiple reasoning paths simultaneously
- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
- Apply search algorithms (BFS/DFS) to find optimal solution paths
**Hindsight is 20/20: The 'If Only...' Reflection**
- Imagine retrospective scenario based on current content
- Identify the one "if only we had known/done X..." insight
- Describe imagined consequences humorously or dramatically
@@ -62,6 +71,7 @@
## Multi-Persona Collaboration Methods
**Agile Team Perspective Shift**
- Rotate through different Scrum team member viewpoints
- Product Owner: Focus on user value and business impact
- Scrum Master: Examine process flow and team dynamics
@@ -69,12 +79,14 @@
- QA: Identify testing scenarios and quality concerns
**Stakeholder Round Table**
- Convene virtual meeting with multiple personas
- Each persona contributes unique perspective on content
- Identify conflicts and synergies between viewpoints
- Synthesize insights into actionable recommendations
**Meta-Prompting Analysis**
- Step back to analyze the structure and logic of current approach
- Question the format and methodology being used
- Suggest alternative frameworks or mental models
@@ -83,24 +95,28 @@
## Advanced 2025 Techniques
**Self-Consistency Validation**
- Generate multiple reasoning paths for same problem
- Compare consistency across different approaches
- Identify most reliable and robust solution
- Highlight areas where approaches diverge and why
**ReWOO (Reasoning Without Observation)**
- Separate parametric reasoning from tool-based actions
- Create reasoning plan without external dependencies
- Identify what can be solved through pure reasoning
- Optimize for efficiency and reduced token usage
**Persona-Pattern Hybrid**
- Combine specific role expertise with elicitation pattern
- Architect + Risk Analysis: Deep technical risk assessment
- UX Expert + User Journey: End-to-end experience critique
- PM + Stakeholder Analysis: Multi-perspective impact review
**Emergent Collaboration Discovery**
- Allow multiple perspectives to naturally emerge
- Identify unexpected insights from persona interactions
- Explore novel combinations of viewpoints
@@ -109,18 +125,21 @@
## Game-Based Elicitation Methods
**Red Team vs Blue Team**
- Red Team: Attack the proposal, find vulnerabilities
- Blue Team: Defend and strengthen the approach
- Competitive analysis reveals blind spots
- Results in more robust, battle-tested solutions
**Innovation Tournament**
- Pit multiple alternative approaches against each other
- Score each approach across different criteria
- Crowd-source evaluation from different personas
- Identify winning combination of features
**Escape Room Challenge**
- Present content as constraints to work within
- Find creative solutions within tight limitations
- Identify minimum viable approach
@@ -129,6 +148,7 @@
## Process Control
**Proceed / No Further Actions**
- Acknowledge choice to finalize current work
- Accept output as-is or move to next step
- Prepare to continue without additional elicitation

View File

@@ -0,0 +1,146 @@
# Test Levels Framework
Comprehensive guide for determining appropriate test levels (unit, integration, E2E) for different scenarios.
## Test Level Decision Matrix
### Unit Tests
**When to use:**
- Testing pure functions and business logic
- Algorithm correctness
- Input validation and data transformation
- Error handling in isolated components
- Complex calculations or state machines
**Characteristics:**
- Fast execution (immediate feedback)
- No external dependencies (DB, API, file system)
- Highly maintainable and stable
- Easy to debug failures
**Example scenarios:**
```yaml
unit_test:
component: 'PriceCalculator'
scenario: 'Calculate discount with multiple rules'
justification: 'Complex business logic with multiple branches'
mock_requirements: 'None - pure function'
```
### Integration Tests
**When to use:**
- Component interaction verification
- Database operations and transactions
- API endpoint contracts
- Service-to-service communication
- Middleware and interceptor behavior
**Characteristics:**
- Moderate execution time
- Tests component boundaries
- May use test databases or containers
- Validates system integration points
**Example scenarios:**
```yaml
integration_test:
components: ['UserService', 'AuthRepository']
scenario: 'Create user with role assignment'
justification: 'Critical data flow between service and persistence'
test_environment: 'In-memory database'
```
### End-to-End Tests
**When to use:**
- Critical user journeys
- Cross-system workflows
- Visual regression testing
- Compliance and regulatory requirements
- Final validation before release
**Characteristics:**
- Slower execution
- Tests complete workflows
- Requires full environment setup
- Most realistic but most brittle
**Example scenarios:**
```yaml
e2e_test:
journey: 'Complete checkout process'
scenario: 'User purchases with saved payment method'
justification: 'Revenue-critical path requiring full validation'
environment: 'Staging with test payment gateway'
```
## Test Level Selection Rules
### Favor Unit Tests When:
- Logic can be isolated
- No side effects involved
- Fast feedback needed
- High cyclomatic complexity
### Favor Integration Tests When:
- Testing persistence layer
- Validating service contracts
- Testing middleware/interceptors
- Component boundaries critical
### Favor E2E Tests When:
- User-facing critical paths
- Multi-system interactions
- Regulatory compliance scenarios
- Visual regression important
## Anti-patterns to Avoid
- E2E testing for business logic validation
- Unit testing framework behavior
- Integration testing third-party libraries
- Duplicate coverage across levels
## Duplicate Coverage Guard
**Before adding any test, check:**
1. Is this already tested at a lower level?
2. Can a unit test cover this instead of integration?
3. Can an integration test cover this instead of E2E?
**Coverage overlap is only acceptable when:**
- Testing different aspects (unit: logic, integration: interaction, e2e: user experience)
- Critical paths requiring defense in depth
- Regression prevention for previously broken functionality
## Test Naming Conventions
- Unit: `test_{component}_{scenario}`
- Integration: `test_{flow}_{interaction}`
- E2E: `test_{journey}_{outcome}`
## Test ID Format
`{EPIC}.{STORY}-{LEVEL}-{SEQ}`
Examples:
- `1.3-UNIT-001`
- `1.3-INT-002`
- `1.3-E2E-001`

View File

@@ -0,0 +1,172 @@
# Test Priorities Matrix
Guide for prioritizing test scenarios based on risk, criticality, and business impact.
## Priority Levels
### P0 - Critical (Must Test)
**Criteria:**
- Revenue-impacting functionality
- Security-critical paths
- Data integrity operations
- Regulatory compliance requirements
- Previously broken functionality (regression prevention)
**Examples:**
- Payment processing
- Authentication/authorization
- User data creation/deletion
- Financial calculations
- GDPR/privacy compliance
**Testing Requirements:**
- Comprehensive coverage at all levels
- Both happy and unhappy paths
- Edge cases and error scenarios
- Performance under load
### P1 - High (Should Test)
**Criteria:**
- Core user journeys
- Frequently used features
- Features with complex logic
- Integration points between systems
- Features affecting user experience
**Examples:**
- User registration flow
- Search functionality
- Data import/export
- Notification systems
- Dashboard displays
**Testing Requirements:**
- Primary happy paths required
- Key error scenarios
- Critical edge cases
- Basic performance validation
### P2 - Medium (Nice to Test)
**Criteria:**
- Secondary features
- Admin functionality
- Reporting features
- Configuration options
- UI polish and aesthetics
**Examples:**
- Admin settings panels
- Report generation
- Theme customization
- Help documentation
- Analytics tracking
**Testing Requirements:**
- Happy path coverage
- Basic error handling
- Can defer edge cases
### P3 - Low (Test if Time Permits)
**Criteria:**
- Rarely used features
- Nice-to-have functionality
- Cosmetic issues
- Non-critical optimizations
**Examples:**
- Advanced preferences
- Legacy feature support
- Experimental features
- Debug utilities
**Testing Requirements:**
- Smoke tests only
- Can rely on manual testing
- Document known limitations
## Risk-Based Priority Adjustments
### Increase Priority When:
- High user impact (affects >50% of users)
- High financial impact (>$10K potential loss)
- Security vulnerability potential
- Compliance/legal requirements
- Customer-reported issues
- Complex implementation (>500 LOC)
- Multiple system dependencies
### Decrease Priority When:
- Feature flag protected
- Gradual rollout planned
- Strong monitoring in place
- Easy rollback capability
- Low usage metrics
- Simple implementation
- Well-isolated component
## Test Coverage by Priority
| Priority | Unit Coverage | Integration Coverage | E2E Coverage |
| -------- | ------------- | -------------------- | ------------------ |
| P0 | >90% | >80% | All critical paths |
| P1 | >80% | >60% | Main happy paths |
| P2 | >60% | >40% | Smoke tests |
| P3 | Best effort | Best effort | Manual only |
## Priority Assignment Rules
1. **Start with business impact** - What happens if this fails?
2. **Consider probability** - How likely is failure?
3. **Factor in detectability** - Would we know if it failed?
4. **Account for recoverability** - Can we fix it quickly?
## Priority Decision Tree
```
Is it revenue-critical?
├─ YES → P0
└─ NO → Does it affect core user journey?
├─ YES → Is it high-risk?
│ ├─ YES → P0
│ └─ NO → P1
└─ NO → Is it frequently used?
├─ YES → P1
└─ NO → Is it customer-facing?
├─ YES → P2
└─ NO → P3
```
## Test Execution Order
1. Execute P0 tests first (fail fast on critical issues)
2. Execute P1 tests second (core functionality)
3. Execute P2 tests if time permits
4. P3 tests only in full regression cycles
## Continuous Adjustment
Review and adjust priorities based on:
- Production incident patterns
- User feedback and complaints
- Usage analytics
- Test failure history
- Business priority changes

View File

@@ -139,16 +139,19 @@ Critical: This is where you'll need to be interactive with the user if informati
Create Dev Technical Guidance section with available information:
```markdown
````markdown
## Dev Technical Guidance
### Existing System Context
[Extract from available documentation]
### Integration Approach
[Based on patterns found or ask user]
### Technical Constraints
[From documentation or user input]
### Missing Information
@@ -191,6 +194,7 @@ Example task structure for brownfield:
- [ ] Integration test for {{integration point}}
- [ ] Update existing tests if needed
```
````
### 5. Risk Assessment and Mitigation
@@ -202,14 +206,17 @@ Add section for brownfield-specific risks:
## Risk Assessment
### Implementation Risks
- **Primary Risk**: {{main risk to existing system}}
- **Mitigation**: {{how to address}}
- **Verification**: {{how to confirm safety}}
### Rollback Plan
- {{Simple steps to undo changes if needed}}
### Safety Checks
- [ ] Existing {{feature}} tested before changes
- [ ] Changes can be feature-flagged or isolated
- [ ] Rollback procedure documented
@@ -252,6 +259,7 @@ Include header noting documentation context:
<!-- Context: Brownfield enhancement to {{existing system}} -->
## Status: Draft
[Rest of story content...]
```

View File

@@ -21,63 +21,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
Present these numbered options to the user:
1. **Product Validation Research**
- Validate product hypotheses and market fit
- Test assumptions about user needs and solutions
- Assess technical and business feasibility
- Identify risks and mitigation strategies
2. **Market Opportunity Research**
- Analyze market size and growth potential
- Identify market segments and dynamics
- Assess market entry strategies
- Evaluate timing and market readiness
3. **User & Customer Research**
- Deep dive into user personas and behaviors
- Understand jobs-to-be-done and pain points
- Map customer journeys and touchpoints
- Analyze willingness to pay and value perception
4. **Competitive Intelligence Research**
- Detailed competitor analysis and positioning
- Feature and capability comparisons
- Business model and strategy analysis
- Identify competitive advantages and gaps
5. **Technology & Innovation Research**
- Assess technology trends and possibilities
- Evaluate technical approaches and architectures
- Identify emerging technologies and disruptions
- Analyze build vs. buy vs. partner options
6. **Industry & Ecosystem Research**
- Map industry value chains and dynamics
- Identify key players and relationships
- Analyze regulatory and compliance factors
- Understand partnership opportunities
7. **Strategic Options Research**
- Evaluate different strategic directions
- Assess business model alternatives
- Analyze go-to-market strategies
- Consider expansion and scaling paths
8. **Risk & Feasibility Research**
- Identify and assess various risk factors
- Evaluate implementation challenges
- Analyze resource requirements
- Consider regulatory and legal implications
9. **Custom Research Focus**
- User-defined research objectives
- Specialized domain investigation
- Cross-functional research needs
@@ -246,13 +237,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
### 5. Review and Refinement
1. **Present Complete Prompt**
- Show the full research prompt
- Explain key elements and rationale
- Highlight any assumptions made
2. **Gather Feedback**
- Are the objectives clear and correct?
- Do the questions address all concerns?
- Is the scope appropriate?

View File

@@ -112,7 +112,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
### Change Log
| Date | Version | Description | Author |
|------|---------|-------------|--------|
| ------ | ------- | --------------------------- | --------- |
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
## Quick Reference - Key Files and Entry Points
@@ -137,7 +137,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
### Actual Tech Stack (from package.json/requirements.txt)
| Category | Technology | Version | Notes |
|----------|------------|---------|--------|
| --------- | ---------- | ------- | -------------------------- |
| Runtime | Node.js | 16.x | [Any constraints] |
| Framework | Express | 4.18.2 | [Custom middleware?] |
| Database | PostgreSQL | 13 | [Connection pooling setup] |
@@ -179,6 +179,7 @@ project-root/
### Data Models
Instead of duplicating, reference actual model files:
- **User Model**: See `src/models/User.js`
- **Order Model**: See `src/models/Order.js`
- **Related Types**: TypeScript definitions in `src/types/`
@@ -209,7 +210,7 @@ Instead of duplicating, reference actual model files:
### External Services
| Service | Purpose | Integration Type | Key Files |
|---------|---------|------------------|-----------|
| -------- | -------- | ---------------- | ------------------------------ |
| Stripe | Payments | REST API | `src/integrations/stripe/` |
| SendGrid | Emails | SDK | `src/services/emailService.js` |
@@ -256,6 +257,7 @@ npm run test:integration # Runs integration tests (requires local DB)
### Files That Will Need Modification
Based on the enhancement requirements, these files will be affected:
- `src/services/userService.js` - Add new user fields
- `src/models/User.js` - Update schema
- `src/routes/userRoutes.js` - New endpoints

View File

@@ -1,6 +1,6 @@
---
docOutputLocation: docs/brainstorming-session-results.md
template: "{root}/templates/brainstorming-output-tmpl.yaml"
template: '{root}/templates/brainstorming-output-tmpl.yaml'
---
# Facilitate Brainstorming Session Task

View File

@@ -11,14 +11,12 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
### Required Steps
1. First, locate and scan:
- The `docs/` directory and all subdirectories
- The existing `docs/index.md` file (create if absent)
- All markdown (`.md`) and text (`.txt`) files in the documentation structure
- Note the folder structure for hierarchical organization
2. For the existing `docs/index.md`:
- Parse current entries
- Note existing file references and descriptions
- Identify any broken links or missing files
@@ -26,7 +24,6 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
- Preserve existing folder sections
3. For each documentation file found:
- Extract the title (from first heading or filename)
- Generate a brief description by analyzing the content
- Create a relative markdown link to the file
@@ -35,7 +32,6 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
- If missing or outdated, prepare an update
4. For any missing or non-existent files found in index:
- Present a list of all entries that reference non-existent files
- For each entry:
- Show the full entry details (title, path, description)
@@ -88,7 +84,6 @@ Documents within the `another-folder/` directory:
### [Nested Document](./another-folder/document.md)
Description of nested document.
```
### Index Entry Format
@@ -157,7 +152,6 @@ For each file referenced in the index but not found in the filesystem:
### Special Cases
1. **Sharded Documents**: If a folder contains an `index.md` file, treat it as a sharded document:
- Use the folder's `index.md` title as the section title
- List the folder's documents as subsections
- Note in the description that this is a multi-part document

View File

@@ -6,7 +6,7 @@ Provide a user-friendly interface to the BMad knowledge base without overwhelmin
## Instructions
When entering KB mode (*kb-mode), follow these steps:
When entering KB mode (\*kb-mode), follow these steps:
### 1. Welcome and Guide
@@ -48,12 +48,12 @@ Or ask me about anything else related to BMad-Method!
When user is done or wants to exit KB mode:
- Summarize key points discussed if helpful
- Remind them they can return to KB mode anytime with *kb-mode
- Remind them they can return to KB mode anytime with \*kb-mode
- Suggest next steps based on what was discussed
## Example Interaction
**User**: *kb-mode
**User**: \*kb-mode
**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.

View File

@@ -0,0 +1,343 @@
# nfr-assess
Quick NFR validation focused on the core four: security, performance, reliability, maintainability.
## Inputs
```yaml
required:
- story_id: '{epic}.{story}' # e.g., "1.3"
- story_path: 'docs/stories/{epic}.{story}.*.md'
optional:
- architecture_refs: 'docs/architecture/*.md'
- technical_preferences: 'docs/technical-preferences.md'
- acceptance_criteria: From story file
```
## Purpose
Assess non-functional requirements for a story and generate:
1. YAML block for the gate file's `nfr_validation` section
2. Brief markdown assessment saved to `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md`
## Process
### 0. Fail-safe for Missing Inputs
If story_path or story file can't be found:
- Still create assessment file with note: "Source story not found"
- Set all selected NFRs to CONCERNS with notes: "Target unknown / evidence missing"
- Continue with assessment to provide value
### 1. Elicit Scope
**Interactive mode:** Ask which NFRs to assess
**Non-interactive mode:** Default to core four (security, performance, reliability, maintainability)
```text
Which NFRs should I assess? (Enter numbers or press Enter for default)
[1] Security (default)
[2] Performance (default)
[3] Reliability (default)
[4] Maintainability (default)
[5] Usability
[6] Compatibility
[7] Portability
[8] Functional Suitability
> [Enter for 1-4]
```
### 2. Check for Thresholds
Look for NFR requirements in:
- Story acceptance criteria
- `docs/architecture/*.md` files
- `docs/technical-preferences.md`
**Interactive mode:** Ask for missing thresholds
**Non-interactive mode:** Mark as CONCERNS with "Target unknown"
```text
No performance requirements found. What's your target response time?
> 200ms for API calls
No security requirements found. Required auth method?
> JWT with refresh tokens
```
**Unknown targets policy:** If a target is missing and not provided, mark status as CONCERNS with notes: "Target unknown"
### 3. Quick Assessment
For each selected NFR, check:
- Is there evidence it's implemented?
- Can we validate it?
- Are there obvious gaps?
### 4. Generate Outputs
## Output 1: Gate YAML Block
Generate ONLY for NFRs actually assessed (no placeholders):
```yaml
# Gate YAML (copy/paste):
nfr_validation:
_assessed: [security, performance, reliability, maintainability]
security:
status: CONCERNS
notes: 'No rate limiting on auth endpoints'
performance:
status: PASS
notes: 'Response times < 200ms verified'
reliability:
status: PASS
notes: 'Error handling and retries implemented'
maintainability:
status: CONCERNS
notes: 'Test coverage at 65%, target is 80%'
```
## Deterministic Status Rules
- **FAIL**: Any selected NFR has critical gap or target clearly not met
- **CONCERNS**: No FAILs, but any NFR is unknown/partial/missing evidence
- **PASS**: All selected NFRs meet targets with evidence
## Quality Score Calculation
```
quality_score = 100
- 20 for each FAIL attribute
- 10 for each CONCERNS attribute
Floor at 0, ceiling at 100
```
If `technical-preferences.md` defines custom weights, use those instead.
## Output 2: Brief Assessment Report
**ALWAYS save to:** `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md`
```markdown
# NFR Assessment: {epic}.{story}
Date: {date}
Reviewer: Quinn
<!-- Note: Source story not found (if applicable) -->
## Summary
- Security: CONCERNS - Missing rate limiting
- Performance: PASS - Meets <200ms requirement
- Reliability: PASS - Proper error handling
- Maintainability: CONCERNS - Test coverage below target
## Critical Issues
1. **No rate limiting** (Security)
- Risk: Brute force attacks possible
- Fix: Add rate limiting middleware to auth endpoints
2. **Test coverage 65%** (Maintainability)
- Risk: Untested code paths
- Fix: Add tests for uncovered branches
## Quick Wins
- Add rate limiting: ~2 hours
- Increase test coverage: ~4 hours
- Add performance monitoring: ~1 hour
```
## Output 3: Story Update Line
**End with this line for the review task to quote:**
```
NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
```
## Output 4: Gate Integration Line
**Always print at the end:**
```
Gate NFR block ready → paste into docs/qa/gates/{epic}.{story}-{slug}.yml under nfr_validation
```
## Assessment Criteria
### Security
**PASS if:**
- Authentication implemented
- Authorization enforced
- Input validation present
- No hardcoded secrets
**CONCERNS if:**
- Missing rate limiting
- Weak encryption
- Incomplete authorization
**FAIL if:**
- No authentication
- Hardcoded credentials
- SQL injection vulnerabilities
### Performance
**PASS if:**
- Meets response time targets
- No obvious bottlenecks
- Reasonable resource usage
**CONCERNS if:**
- Close to limits
- Missing indexes
- No caching strategy
**FAIL if:**
- Exceeds response time limits
- Memory leaks
- Unoptimized queries
### Reliability
**PASS if:**
- Error handling present
- Graceful degradation
- Retry logic where needed
**CONCERNS if:**
- Some error cases unhandled
- No circuit breakers
- Missing health checks
**FAIL if:**
- No error handling
- Crashes on errors
- No recovery mechanisms
### Maintainability
**PASS if:**
- Test coverage meets target
- Code well-structured
- Documentation present
**CONCERNS if:**
- Test coverage below target
- Some code duplication
- Missing documentation
**FAIL if:**
- No tests
- Highly coupled code
- No documentation
## Quick Reference
### What to Check
```yaml
security:
- Authentication mechanism
- Authorization checks
- Input validation
- Secret management
- Rate limiting
performance:
- Response times
- Database queries
- Caching usage
- Resource consumption
reliability:
- Error handling
- Retry logic
- Circuit breakers
- Health checks
- Logging
maintainability:
- Test coverage
- Code structure
- Documentation
- Dependencies
```
## Key Principles
- Focus on the core four NFRs by default
- Quick assessment, not deep analysis
- Gate-ready output format
- Brief, actionable findings
- Skip what doesn't apply
- Deterministic status rules for consistency
- Unknown targets → CONCERNS, not guesses
---
## Appendix: ISO 25010 Reference
<details>
<summary>Full ISO 25010 Quality Model (click to expand)</summary>
### All 8 Quality Characteristics
1. **Functional Suitability**: Completeness, correctness, appropriateness
2. **Performance Efficiency**: Time behavior, resource use, capacity
3. **Compatibility**: Co-existence, interoperability
4. **Usability**: Learnability, operability, accessibility
5. **Reliability**: Maturity, availability, fault tolerance
6. **Security**: Confidentiality, integrity, authenticity
7. **Maintainability**: Modularity, reusability, testability
8. **Portability**: Adaptability, installability
Use these when assessing beyond the core four.
</details>
<details>
<summary>Example: Deep Performance Analysis (click to expand)</summary>
```yaml
performance_deep_dive:
response_times:
p50: 45ms
p95: 180ms
p99: 350ms
database:
slow_queries: 2
missing_indexes: ['users.email', 'orders.user_id']
caching:
hit_rate: 0%
recommendation: 'Add Redis for session data'
load_test:
max_rps: 150
breaking_point: 200 rps
```
</details>

159
bmad-core/tasks/qa-gate.md Normal file
View File

@@ -0,0 +1,159 @@
# qa-gate
Create or update a quality gate decision file for a story based on review findings.
## Purpose
Generate a standalone quality gate file that provides a clear pass/fail decision with actionable feedback. This gate serves as an advisory checkpoint for teams to understand quality status.
## Prerequisites
- Story has been reviewed (manually or via review-story task)
- Review findings are available
- Understanding of story requirements and implementation
## Gate File Location
**ALWAYS** create file at: `docs/qa/gates/{epic}.{story}-{slug}.yml`
Slug rules:
- Convert to lowercase
- Replace spaces with hyphens
- Strip punctuation
- Example: "User Auth - Login!" becomes "user-auth-login"
## Minimal Required Schema
```yaml
schema: 1
story: '{epic}.{story}'
gate: PASS|CONCERNS|FAIL|WAIVED
status_reason: '1-2 sentence explanation of gate decision'
reviewer: 'Quinn'
updated: '{ISO-8601 timestamp}'
top_issues: [] # Empty array if no issues
waiver: { active: false } # Only set active: true if WAIVED
```
## Schema with Issues
```yaml
schema: 1
story: '1.3'
gate: CONCERNS
status_reason: 'Missing rate limiting on auth endpoints poses security risk.'
reviewer: 'Quinn'
updated: '2025-01-12T10:15:00Z'
top_issues:
- id: 'SEC-001'
severity: high # ONLY: low|medium|high
finding: 'No rate limiting on login endpoint'
suggested_action: 'Add rate limiting middleware before production'
- id: 'TEST-001'
severity: medium
finding: 'No integration tests for auth flow'
suggested_action: 'Add integration test coverage'
waiver: { active: false }
```
## Schema when Waived
```yaml
schema: 1
story: '1.3'
gate: WAIVED
status_reason: 'Known issues accepted for MVP release.'
reviewer: 'Quinn'
updated: '2025-01-12T10:15:00Z'
top_issues:
- id: 'PERF-001'
severity: low
finding: 'Dashboard loads slowly with 1000+ items'
suggested_action: 'Implement pagination in next sprint'
waiver:
active: true
reason: 'MVP release - performance optimization deferred'
approved_by: 'Product Owner'
```
## Gate Decision Criteria
### PASS
- All acceptance criteria met
- No high-severity issues
- Test coverage meets project standards
### CONCERNS
- Non-blocking issues present
- Should be tracked and scheduled
- Can proceed with awareness
### FAIL
- Acceptance criteria not met
- High-severity issues present
- Recommend return to InProgress
### WAIVED
- Issues explicitly accepted
- Requires approval and reason
- Proceed despite known issues
## Severity Scale
**FIXED VALUES - NO VARIATIONS:**
- `low`: Minor issues, cosmetic problems
- `medium`: Should fix soon, not blocking
- `high`: Critical issues, should block release
## Issue ID Prefixes
- `SEC-`: Security issues
- `PERF-`: Performance issues
- `REL-`: Reliability issues
- `TEST-`: Testing gaps
- `MNT-`: Maintainability concerns
- `ARCH-`: Architecture issues
- `DOC-`: Documentation gaps
- `REQ-`: Requirements issues
## Output Requirements
1. **ALWAYS** create gate file at: `docs/qa/gates/{epic}.{story}-{slug}.yml`
2. **ALWAYS** append this exact format to story's QA Results section:
```
Gate: {STATUS} → docs/qa/gates/{epic}.{story}-{slug}.yml
```
3. Keep status_reason to 1-2 sentences maximum
4. Use severity values exactly: `low`, `medium`, or `high`
## Example Story Update
After creating gate file, append to story's QA Results section:
```markdown
## QA Results
### Review Date: 2025-01-12
### Reviewed By: Quinn (Test Architect)
[... existing review content ...]
### Gate Status
Gate: CONCERNS → docs/qa/gates/1.3-user-auth-login.yml
```
## Key Principles
- Keep it minimal and predictable
- Fixed severity scale (low/medium/high)
- Always write to standard path
- Always update story with gate reference
- Clear, actionable findings

View File

@@ -1,6 +1,16 @@
# review-story
When a developer agent marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
Perform a comprehensive test architecture review with quality gate decision. This adaptive, risk-aware review creates both a story update and a detailed gate file.
## Inputs
```yaml
required:
- story_id: '{epic}.{story}' # e.g., "1.3"
- story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
- story_title: '{title}' # If missing, derive from story file H1
- story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
```
## Prerequisites
@@ -8,98 +18,133 @@ When a developer agent marks a story as "Ready for Review", perform a comprehens
- Developer has completed all tasks and updated the File List
- All automated tests are passing
## Review Process
## Review Process - Adaptive Test Architecture
1. **Read the Complete Story**
- Review all acceptance criteria
- Understand the dev notes and requirements
- Note any completion notes from the developer
### 1. Risk Assessment (Determines Review Depth)
2. **Verify Implementation Against Dev Notes Guidance**
- Review the "Dev Notes" section for specific technical guidance provided to the developer
- Verify the developer's implementation follows the architectural patterns specified in Dev Notes
- Check that file locations match the project structure guidance in Dev Notes
- Confirm any specified libraries, frameworks, or technical approaches were used correctly
- Validate that security considerations mentioned in Dev Notes were implemented
**Auto-escalate to deep review when:**
3. **Focus on the File List**
- Verify all files listed were actually created/modified
- Check for any missing files that should have been updated
- Ensure file locations align with the project structure guidance from Dev Notes
- Auth/payment/security files touched
- No tests added to story
- Diff > 500 lines
- Previous gate was FAIL/CONCERNS
- Story has > 5 acceptance criteria
4. **Senior Developer Code Review**
- Review code with the eye of a senior developer
- If changes form a cohesive whole, review them together
- If changes are independent, review incrementally file by file
- Focus on:
- Code architecture and design patterns
- Refactoring opportunities
### 2. Comprehensive Analysis
**A. Requirements Traceability**
- Map each acceptance criteria to its validating tests (document mapping with Given-When-Then, not test code)
- Identify coverage gaps
- Verify all requirements have corresponding test cases
**B. Code Quality Review**
- Architecture and design patterns
- Refactoring opportunities (and perform them)
- Code duplication or inefficiencies
- Performance optimizations
- Security concerns
- Best practices and patterns
- Security vulnerabilities
- Best practices adherence
5. **Active Refactoring**
- As a senior developer, you CAN and SHOULD refactor code where improvements are needed
- When refactoring:
- Make the changes directly in the files
- Explain WHY you're making the change
- Describe HOW the change improves the code
- Ensure all tests still pass after refactoring
- Update the File List if you modify additional files
**C. Test Architecture Assessment**
- Test coverage adequacy at appropriate levels
- Test level appropriateness (what should be unit vs integration vs e2e)
- Test design quality and maintainability
- Test data management strategy
- Mock/stub usage appropriateness
- Edge case and error scenario coverage
- Test execution time and reliability
**D. Non-Functional Requirements (NFRs)**
- Security: Authentication, authorization, data protection
- Performance: Response times, resource usage
- Reliability: Error handling, recovery mechanisms
- Maintainability: Code clarity, documentation
**E. Testability Evaluation**
- Controllability: Can we control the inputs?
- Observability: Can we observe the outputs?
- Debuggability: Can we debug failures easily?
**F. Technical Debt Identification**
- Accumulated shortcuts
- Missing tests
- Outdated dependencies
- Architecture violations
### 3. Active Refactoring
- Refactor code where safe and appropriate
- Run tests to ensure changes don't break functionality
- Document all changes in QA Results section with clear WHY and HOW
- Do NOT alter story content beyond QA Results section
- Do NOT change story Status or File List; recommend next status only
### 4. Standards Compliance Check
6. **Standards Compliance Check**
- Verify adherence to `docs/coding-standards.md`
- Check compliance with `docs/unified-project-structure.md`
- Validate testing approach against `docs/testing-strategy.md`
- Ensure all guidelines mentioned in the story are followed
7. **Acceptance Criteria Validation**
### 5. Acceptance Criteria Validation
- Verify each AC is fully implemented
- Check for any missing functionality
- Validate edge cases are handled
8. **Test Coverage Review**
- Ensure unit tests cover edge cases
- Add missing tests if critical coverage is lacking
- Verify integration tests (if required) are comprehensive
- Check that test assertions are meaningful
- Look for missing test scenarios
### 6. Documentation and Comments
9. **Documentation and Comments**
- Verify code is self-documenting where possible
- Add comments for complex logic if missing
- Ensure any API changes are documented
## Update Story File - QA Results Section ONLY
## Output 1: Update Story File - QA Results Section ONLY
**CRITICAL**: You are ONLY authorized to update the "QA Results" section of the story file. DO NOT modify any other sections.
**QA Results Anchor Rule:**
- If `## QA Results` doesn't exist, append it at end of file
- If it exists, append a new dated entry below existing entries
- Never edit other sections
After review and any refactoring, append your results to the story file in the QA Results section:
```markdown
## QA Results
### Review Date: [Date]
### Reviewed By: Quinn (Senior Developer QA)
### Reviewed By: Quinn (Test Architect)
### Code Quality Assessment
[Overall assessment of implementation quality]
### Refactoring Performed
[List any refactoring you performed with explanations]
- **File**: [filename]
- **Change**: [what was changed]
- **Why**: [reason for change]
- **How**: [how it improves the code]
### Compliance Check
- Coding Standards: [✓/✗] [notes if any]
- Project Structure: [✓/✗] [notes if any]
- Testing Strategy: [✓/✗] [notes if any]
- All ACs Met: [✓/✗] [notes if any]
### Improvements Checklist
[Check off items you handled yourself, leave unchecked for dev to address]
- [x] Refactored user service for better error handling (services/user.service.ts)
@@ -109,22 +154,144 @@ After review and any refactoring, append your results to the story file in the Q
- [ ] Update API documentation for new error codes
### Security Review
[Any security concerns found and whether addressed]
### Performance Considerations
[Any performance issues found and whether addressed]
### Final Status
[✓ Approved - Ready for Done] / [✗ Changes Required - See unchecked items above]
### Files Modified During Review
[If you modified files, list them here - ask Dev to update File List]
### Gate Status
Gate: {STATUS} → docs/qa/gates/{epic}.{story}-{slug}.yml
Risk profile: docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
# Note: Paths should reference core-config.yaml for custom configurations
### Recommended Status
[✓ Ready for Done] / [✗ Changes Required - See unchecked items above]
(Story owner decides final status)
```
## Output 2: Create Quality Gate File
**Template and Directory:**
- Render from `templates/qa-gate-tmpl.yaml`
- Create `docs/qa/gates/` directory if missing (or configure in core-config.yaml)
- Save to: `docs/qa/gates/{epic}.{story}-{slug}.yml`
Gate file structure:
```yaml
schema: 1
story: '{epic}.{story}'
story_title: '{story title}'
gate: PASS|CONCERNS|FAIL|WAIVED
status_reason: '1-2 sentence explanation of gate decision'
reviewer: 'Quinn (Test Architect)'
updated: '{ISO-8601 timestamp}'
top_issues: [] # Empty if no issues
waiver: { active: false } # Set active: true only if WAIVED
# Extended fields (optional but recommended):
quality_score: 0-100 # 100 - (20*FAILs) - (10*CONCERNS) or use technical-preferences.md weights
expires: '{ISO-8601 timestamp}' # Typically 2 weeks from review
evidence:
tests_reviewed: { count }
risks_identified: { count }
trace:
ac_covered: [1, 2, 3] # AC numbers with test coverage
ac_gaps: [4] # AC numbers lacking coverage
nfr_validation:
security:
status: PASS|CONCERNS|FAIL
notes: 'Specific findings'
performance:
status: PASS|CONCERNS|FAIL
notes: 'Specific findings'
reliability:
status: PASS|CONCERNS|FAIL
notes: 'Specific findings'
maintainability:
status: PASS|CONCERNS|FAIL
notes: 'Specific findings'
recommendations:
immediate: # Must fix before production
- action: 'Add rate limiting'
refs: ['api/auth/login.ts']
future: # Can be addressed later
- action: 'Consider caching'
refs: ['services/data.ts']
```
### Gate Decision Criteria
**Deterministic rule (apply in order):**
If risk_summary exists, apply its thresholds first (≥9 → FAIL, ≥6 → CONCERNS), then NFR statuses, then top_issues severity.
1. **Risk thresholds (if risk_summary present):**
- If any risk score ≥ 9 → Gate = FAIL (unless waived)
- Else if any score ≥ 6 → Gate = CONCERNS
2. **Test coverage gaps (if trace available):**
- If any P0 test from test-design is missing → Gate = CONCERNS
- If security/data-loss P0 test missing → Gate = FAIL
3. **Issue severity:**
- If any `top_issues.severity == high` → Gate = FAIL (unless waived)
- Else if any `severity == medium` → Gate = CONCERNS
4. **NFR statuses:**
- If any NFR status is FAIL → Gate = FAIL
- Else if any NFR status is CONCERNS → Gate = CONCERNS
- Else → Gate = PASS
- WAIVED only when waiver.active: true with reason/approver
Detailed criteria:
- **PASS**: All critical requirements met, no blocking issues
- **CONCERNS**: Non-critical issues found, team should review
- **FAIL**: Critical issues that should be addressed
- **WAIVED**: Issues acknowledged but explicitly waived by team
### Quality Score Calculation
```text
quality_score = 100 - (20 × number of FAILs) - (10 × number of CONCERNS)
Bounded between 0 and 100
```
If `technical-preferences.md` defines custom weights, use those instead.
### Suggested Owner Convention
For each issue in `top_issues`, include a `suggested_owner`:
- `dev`: Code changes needed
- `sm`: Requirements clarification needed
- `po`: Business decision needed
## Key Principles
- You are a SENIOR developer reviewing junior/mid-level work
- You have the authority and responsibility to improve code directly
- You are a Test Architect providing comprehensive quality assessment
- You have the authority to improve code directly when appropriate
- Always explain your changes for learning purposes
- Balance between perfection and pragmatism
- Focus on significant improvements, not nitpicks
- Focus on risk-based prioritization
- Provide actionable recommendations with clear ownership
## Blocking Conditions
@@ -140,6 +307,8 @@ Stop the review and request clarification if:
After review:
1. If all items are checked and approved: Update story status to "Done"
2. If unchecked items remain: Keep status as "Review" for dev to address
3. Always provide constructive feedback and explanations for learning
1. Update the QA Results section in the story file
2. Create the gate file in `docs/qa/gates/`
3. Recommend status: "Ready for Done" or "Changes Required" (owner decides)
4. If files were modified, list them in QA Results and ask Dev to update File List
5. Always provide constructive feedback and actionable recommendations

View File

@@ -0,0 +1,353 @@
# risk-profile
Generate a comprehensive risk assessment matrix for a story implementation using probability × impact analysis.
## Inputs
```yaml
required:
- story_id: '{epic}.{story}' # e.g., "1.3"
- story_path: 'docs/stories/{epic}.{story}.*.md'
- story_title: '{title}' # If missing, derive from story file H1
- story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
```
## Purpose
Identify, assess, and prioritize risks in the story implementation. Provide risk mitigation strategies and testing focus areas based on risk levels.
## Risk Assessment Framework
### Risk Categories
**Category Prefixes:**
- `TECH`: Technical Risks
- `SEC`: Security Risks
- `PERF`: Performance Risks
- `DATA`: Data Risks
- `BUS`: Business Risks
- `OPS`: Operational Risks
1. **Technical Risks (TECH)**
- Architecture complexity
- Integration challenges
- Technical debt
- Scalability concerns
- System dependencies
2. **Security Risks (SEC)**
- Authentication/authorization flaws
- Data exposure vulnerabilities
- Injection attacks
- Session management issues
- Cryptographic weaknesses
3. **Performance Risks (PERF)**
- Response time degradation
- Throughput bottlenecks
- Resource exhaustion
- Database query optimization
- Caching failures
4. **Data Risks (DATA)**
- Data loss potential
- Data corruption
- Privacy violations
- Compliance issues
- Backup/recovery gaps
5. **Business Risks (BUS)**
- Feature doesn't meet user needs
- Revenue impact
- Reputation damage
- Regulatory non-compliance
- Market timing
6. **Operational Risks (OPS)**
- Deployment failures
- Monitoring gaps
- Incident response readiness
- Documentation inadequacy
- Knowledge transfer issues
## Risk Analysis Process
### 1. Risk Identification
For each category, identify specific risks:
```yaml
risk:
id: 'SEC-001' # Use prefixes: SEC, PERF, DATA, BUS, OPS, TECH
category: security
title: 'Insufficient input validation on user forms'
description: 'Form inputs not properly sanitized could lead to XSS attacks'
affected_components:
- 'UserRegistrationForm'
- 'ProfileUpdateForm'
detection_method: 'Code review revealed missing validation'
```
### 2. Risk Assessment
Evaluate each risk using probability × impact:
**Probability Levels:**
- `High (3)`: Likely to occur (>70% chance)
- `Medium (2)`: Possible occurrence (30-70% chance)
- `Low (1)`: Unlikely to occur (<30% chance)
**Impact Levels:**
- `High (3)`: Severe consequences (data breach, system down, major financial loss)
- `Medium (2)`: Moderate consequences (degraded performance, minor data issues)
- `Low (1)`: Minor consequences (cosmetic issues, slight inconvenience)
**Risk Score = Probability × Impact**
- 9: Critical Risk (Red)
- 6: High Risk (Orange)
- 4: Medium Risk (Yellow)
- 2-3: Low Risk (Green)
- 1: Minimal Risk (Blue)
### 3. Risk Prioritization
Create risk matrix:
```markdown
## Risk Matrix
| Risk ID | Description | Probability | Impact | Score | Priority |
| -------- | ----------------------- | ----------- | ---------- | ----- | -------- |
| SEC-001 | XSS vulnerability | High (3) | High (3) | 9 | Critical |
| PERF-001 | Slow query on dashboard | Medium (2) | Medium (2) | 4 | Medium |
| DATA-001 | Backup failure | Low (1) | High (3) | 3 | Low |
```
### 4. Risk Mitigation Strategies
For each identified risk, provide mitigation:
```yaml
mitigation:
risk_id: 'SEC-001'
strategy: 'preventive' # preventive|detective|corrective
actions:
- 'Implement input validation library (e.g., validator.js)'
- 'Add CSP headers to prevent XSS execution'
- 'Sanitize all user inputs before storage'
- 'Escape all outputs in templates'
testing_requirements:
- 'Security testing with OWASP ZAP'
- 'Manual penetration testing of forms'
- 'Unit tests for validation functions'
residual_risk: 'Low - Some zero-day vulnerabilities may remain'
owner: 'dev'
timeline: 'Before deployment'
```
## Outputs
### Output 1: Gate YAML Block
Generate for pasting into gate file under `risk_summary`:
**Output rules:**
- Only include assessed risks; do not emit placeholders
- Sort risks by score (desc) when emitting highest and any tabular lists
- If no risks: totals all zeros, omit highest, keep recommendations arrays empty
```yaml
# risk_summary (paste into gate file):
risk_summary:
totals:
critical: X # score 9
high: Y # score 6
medium: Z # score 4
low: W # score 2-3
highest:
id: SEC-001
score: 9
title: 'XSS on profile form'
recommendations:
must_fix:
- 'Add input sanitization & CSP'
monitor:
- 'Add security alerts for auth endpoints'
```
### Output 2: Markdown Report
**Save to:** `docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md`
```markdown
# Risk Profile: Story {epic}.{story}
Date: {date}
Reviewer: Quinn (Test Architect)
## Executive Summary
- Total Risks Identified: X
- Critical Risks: Y
- High Risks: Z
- Risk Score: XX/100 (calculated)
## Critical Risks Requiring Immediate Attention
### 1. [ID]: Risk Title
**Score: 9 (Critical)**
**Probability**: High - Detailed reasoning
**Impact**: High - Potential consequences
**Mitigation**:
- Immediate action required
- Specific steps to take
**Testing Focus**: Specific test scenarios needed
## Risk Distribution
### By Category
- Security: X risks (Y critical)
- Performance: X risks (Y critical)
- Data: X risks (Y critical)
- Business: X risks (Y critical)
- Operational: X risks (Y critical)
### By Component
- Frontend: X risks
- Backend: X risks
- Database: X risks
- Infrastructure: X risks
## Detailed Risk Register
[Full table of all risks with scores and mitigations]
## Risk-Based Testing Strategy
### Priority 1: Critical Risk Tests
- Test scenarios for critical risks
- Required test types (security, load, chaos)
- Test data requirements
### Priority 2: High Risk Tests
- Integration test scenarios
- Edge case coverage
### Priority 3: Medium/Low Risk Tests
- Standard functional tests
- Regression test suite
## Risk Acceptance Criteria
### Must Fix Before Production
- All critical risks (score 9)
- High risks affecting security/data
### Can Deploy with Mitigation
- Medium risks with compensating controls
- Low risks with monitoring in place
### Accepted Risks
- Document any risks team accepts
- Include sign-off from appropriate authority
## Monitoring Requirements
Post-deployment monitoring for:
- Performance metrics for PERF risks
- Security alerts for SEC risks
- Error rates for operational risks
- Business KPIs for business risks
## Risk Review Triggers
Review and update risk profile when:
- Architecture changes significantly
- New integrations added
- Security vulnerabilities discovered
- Performance issues reported
- Regulatory requirements change
```
## Risk Scoring Algorithm
Calculate overall story risk score:
```
Base Score = 100
For each risk:
- Critical (9): Deduct 20 points
- High (6): Deduct 10 points
- Medium (4): Deduct 5 points
- Low (2-3): Deduct 2 points
Minimum score = 0 (extremely risky)
Maximum score = 100 (minimal risk)
```
## Risk-Based Recommendations
Based on risk profile, recommend:
1. **Testing Priority**
- Which tests to run first
- Additional test types needed
- Test environment requirements
2. **Development Focus**
- Code review emphasis areas
- Additional validation needed
- Security controls to implement
3. **Deployment Strategy**
- Phased rollout for high-risk changes
- Feature flags for risky features
- Rollback procedures
4. **Monitoring Setup**
- Metrics to track
- Alerts to configure
- Dashboard requirements
## Integration with Quality Gates
**Deterministic gate mapping:**
- Any risk with score 9 Gate = FAIL (unless waived)
- Else if any score 6 Gate = CONCERNS
- Else Gate = PASS
- Unmitigated risks Document in gate
### Output 3: Story Hook Line
**Print this line for review task to quote:**
```
Risk profile: docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
```
## Key Principles
- Identify risks early and systematically
- Use consistent probability × impact scoring
- Provide actionable mitigation strategies
- Link risks to specific test requirements
- Track residual risk after mitigation
- Update risk profile as story evolves

View File

@@ -91,13 +91,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
For each extracted section:
1. **Generate filename**: Convert the section heading to lowercase-dash-case
- Remove special characters
- Replace spaces with dashes
- Example: "## Tech Stack" → `tech-stack.md`
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:

View File

@@ -0,0 +1,174 @@
# test-design
Create comprehensive test scenarios with appropriate test level recommendations for story implementation.
## Inputs
```yaml
required:
- story_id: '{epic}.{story}' # e.g., "1.3"
- story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
- story_title: '{title}' # If missing, derive from story file H1
- story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
```
## Purpose
Design a complete test strategy that identifies what to test, at which level (unit/integration/e2e), and why. This ensures efficient test coverage without redundancy while maintaining appropriate test boundaries.
## Dependencies
```yaml
data:
- test-levels-framework.md # Unit/Integration/E2E decision criteria
- test-priorities-matrix.md # P0/P1/P2/P3 classification system
```
## Process
### 1. Analyze Story Requirements
Break down each acceptance criterion into testable scenarios. For each AC:
- Identify the core functionality to test
- Determine data variations needed
- Consider error conditions
- Note edge cases
### 2. Apply Test Level Framework
**Reference:** Load `test-levels-framework.md` for detailed criteria
Quick rules:
- **Unit**: Pure logic, algorithms, calculations
- **Integration**: Component interactions, DB operations
- **E2E**: Critical user journeys, compliance
### 3. Assign Priorities
**Reference:** Load `test-priorities-matrix.md` for classification
Quick priority assignment:
- **P0**: Revenue-critical, security, compliance
- **P1**: Core user journeys, frequently used
- **P2**: Secondary features, admin functions
- **P3**: Nice-to-have, rarely used
### 4. Design Test Scenarios
For each identified test need, create:
```yaml
test_scenario:
id: '{epic}.{story}-{LEVEL}-{SEQ}'
requirement: 'AC reference'
priority: P0|P1|P2|P3
level: unit|integration|e2e
description: 'What is being tested'
justification: 'Why this level was chosen'
mitigates_risks: ['RISK-001'] # If risk profile exists
```
### 5. Validate Coverage
Ensure:
- Every AC has at least one test
- No duplicate coverage across levels
- Critical paths have multiple levels
- Risk mitigations are addressed
## Outputs
### Output 1: Test Design Document
**Save to:** `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md`
```markdown
# Test Design: Story {epic}.{story}
Date: {date}
Designer: Quinn (Test Architect)
## Test Strategy Overview
- Total test scenarios: X
- Unit tests: Y (A%)
- Integration tests: Z (B%)
- E2E tests: W (C%)
- Priority distribution: P0: X, P1: Y, P2: Z
## Test Scenarios by Acceptance Criteria
### AC1: {description}
#### Scenarios
| ID | Level | Priority | Test | Justification |
| ------------ | ----------- | -------- | ------------------------- | ------------------------ |
| 1.3-UNIT-001 | Unit | P0 | Validate input format | Pure validation logic |
| 1.3-INT-001 | Integration | P0 | Service processes request | Multi-component flow |
| 1.3-E2E-001 | E2E | P1 | User completes journey | Critical path validation |
[Continue for all ACs...]
## Risk Coverage
[Map test scenarios to identified risks if risk profile exists]
## Recommended Execution Order
1. P0 Unit tests (fail fast)
2. P0 Integration tests
3. P0 E2E tests
4. P1 tests in order
5. P2+ as time permits
```
### Output 2: Gate YAML Block
Generate for inclusion in quality gate:
```yaml
test_design:
scenarios_total: X
by_level:
unit: Y
integration: Z
e2e: W
by_priority:
p0: A
p1: B
p2: C
coverage_gaps: [] # List any ACs without tests
```
### Output 3: Trace References
Print for use by trace-requirements task:
```text
Test design matrix: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
P0 tests identified: {count}
```
## Quality Checklist
Before finalizing, verify:
- [ ] Every AC has test coverage
- [ ] Test levels are appropriate (not over-testing)
- [ ] No duplicate coverage across levels
- [ ] Priorities align with business risk
- [ ] Test IDs follow naming convention
- [ ] Scenarios are atomic and independent
## Key Principles
- **Shift left**: Prefer unit over integration, integration over E2E
- **Risk-based**: Focus on what could go wrong
- **Efficient coverage**: Test once at the right level
- **Maintainability**: Consider long-term test maintenance
- **Fast feedback**: Quick tests run first

View File

@@ -0,0 +1,264 @@
# trace-requirements
Map story requirements to test cases using Given-When-Then patterns for comprehensive traceability.
## Purpose
Create a requirements traceability matrix that ensures every acceptance criterion has corresponding test coverage. This task helps identify gaps in testing and ensures all requirements are validated.
**IMPORTANT**: Given-When-Then is used here for documenting the mapping between requirements and tests, NOT for writing the actual test code. Tests should follow your project's testing standards (no BDD syntax in test code).
## Prerequisites
- Story file with clear acceptance criteria
- Access to test files or test specifications
- Understanding of the implementation
## Traceability Process
### 1. Extract Requirements
Identify all testable requirements from:
- Acceptance Criteria (primary source)
- User story statement
- Tasks/subtasks with specific behaviors
- Non-functional requirements mentioned
- Edge cases documented
### 2. Map to Test Cases
For each requirement, document which tests validate it. Use Given-When-Then to describe what the test validates (not how it's written):
```yaml
requirement: 'AC1: User can login with valid credentials'
test_mappings:
- test_file: 'auth/login.test.ts'
test_case: 'should successfully login with valid email and password'
# Given-When-Then describes WHAT the test validates, not HOW it's coded
given: 'A registered user with valid credentials'
when: 'They submit the login form'
then: 'They are redirected to dashboard and session is created'
coverage: full
- test_file: 'e2e/auth-flow.test.ts'
test_case: 'complete login flow'
given: 'User on login page'
when: 'Entering valid credentials and submitting'
then: 'Dashboard loads with user data'
coverage: integration
```
### 3. Coverage Analysis
Evaluate coverage for each requirement:
**Coverage Levels:**
- `full`: Requirement completely tested
- `partial`: Some aspects tested, gaps exist
- `none`: No test coverage found
- `integration`: Covered in integration/e2e tests only
- `unit`: Covered in unit tests only
### 4. Gap Identification
Document any gaps found:
```yaml
coverage_gaps:
- requirement: 'AC3: Password reset email sent within 60 seconds'
gap: 'No test for email delivery timing'
severity: medium
suggested_test:
type: integration
description: 'Test email service SLA compliance'
- requirement: 'AC5: Support 1000 concurrent users'
gap: 'No load testing implemented'
severity: high
suggested_test:
type: performance
description: 'Load test with 1000 concurrent connections'
```
## Outputs
### Output 1: Gate YAML Block
**Generate for pasting into gate file under `trace`:**
```yaml
trace:
totals:
requirements: X
full: Y
partial: Z
none: W
planning_ref: 'docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md'
uncovered:
- ac: 'AC3'
reason: 'No test found for password reset timing'
notes: 'See docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md'
```
### Output 2: Traceability Report
**Save to:** `docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md`
Create a traceability report with:
```markdown
# Requirements Traceability Matrix
## Story: {epic}.{story} - {title}
### Coverage Summary
- Total Requirements: X
- Fully Covered: Y (Z%)
- Partially Covered: A (B%)
- Not Covered: C (D%)
### Requirement Mappings
#### AC1: {Acceptance Criterion 1}
**Coverage: FULL**
Given-When-Then Mappings:
- **Unit Test**: `auth.service.test.ts::validateCredentials`
- Given: Valid user credentials
- When: Validation method called
- Then: Returns true with user object
- **Integration Test**: `auth.integration.test.ts::loginFlow`
- Given: User with valid account
- When: Login API called
- Then: JWT token returned and session created
#### AC2: {Acceptance Criterion 2}
**Coverage: PARTIAL**
[Continue for all ACs...]
### Critical Gaps
1. **Performance Requirements**
- Gap: No load testing for concurrent users
- Risk: High - Could fail under production load
- Action: Implement load tests using k6 or similar
2. **Security Requirements**
- Gap: Rate limiting not tested
- Risk: Medium - Potential DoS vulnerability
- Action: Add rate limit tests to integration suite
### Test Design Recommendations
Based on gaps identified, recommend:
1. Additional test scenarios needed
2. Test types to implement (unit/integration/e2e/performance)
3. Test data requirements
4. Mock/stub strategies
### Risk Assessment
- **High Risk**: Requirements with no coverage
- **Medium Risk**: Requirements with only partial coverage
- **Low Risk**: Requirements with full unit + integration coverage
```
## Traceability Best Practices
### Given-When-Then for Mapping (Not Test Code)
Use Given-When-Then to document what each test validates:
**Given**: The initial context the test sets up
- What state/data the test prepares
- User context being simulated
- System preconditions
**When**: The action the test performs
- What the test executes
- API calls or user actions tested
- Events triggered
**Then**: What the test asserts
- Expected outcomes verified
- State changes checked
- Values validated
**Note**: This is for documentation only. Actual test code follows your project's standards (e.g., describe/it blocks, no BDD syntax).
### Coverage Priority
Prioritize coverage based on:
1. Critical business flows
2. Security-related requirements
3. Data integrity requirements
4. User-facing features
5. Performance SLAs
### Test Granularity
Map at appropriate levels:
- Unit tests for business logic
- Integration tests for component interaction
- E2E tests for user journeys
- Performance tests for NFRs
## Quality Indicators
Good traceability shows:
- Every AC has at least one test
- Critical paths have multiple test levels
- Edge cases are explicitly covered
- NFRs have appropriate test types
- Clear Given-When-Then for each test
## Red Flags
Watch for:
- ACs with no test coverage
- Tests that don't map to requirements
- Vague test descriptions
- Missing edge case coverage
- NFRs without specific tests
## Integration with Gates
This traceability feeds into quality gates:
- Critical gaps → FAIL
- Minor gaps → CONCERNS
- Missing P0 tests from test-design → CONCERNS
### Output 3: Story Hook Line
**Print this line for review task to quote:**
```text
Trace matrix: docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
```
- Full coverage → PASS contribution
## Key Principles
- Every requirement must be testable
- Use Given-When-Then for clarity
- Identify both presence and absence
- Prioritize based on risk
- Make recommendations actionable

View File

@@ -141,7 +141,14 @@ sections:
title: Feature Comparison Matrix
instruction: Create a detailed comparison table of key features across competitors
type: table
columns: ["Feature Category", "{{your_company}}", "{{competitor_1}}", "{{competitor_2}}", "{{competitor_3}}"]
columns:
[
"Feature Category",
"{{your_company}}",
"{{competitor_1}}",
"{{competitor_2}}",
"{{competitor_3}}",
]
rows:
- category: "Core Functionality"
items:
@@ -153,7 +160,13 @@ sections:
- ["Onboarding Time", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
- category: "Integration & Ecosystem"
items:
- ["API Availability", "{{availability}}", "{{availability}}", "{{availability}}", "{{availability}}"]
- [
"API Availability",
"{{availability}}",
"{{availability}}",
"{{availability}}",
"{{availability}}",
]
- ["Third-party Integrations", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
- category: "Pricing & Plans"
items:

View File

@@ -75,12 +75,24 @@ sections:
rows:
- ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["UI Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["State Management", "{{state_management}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- [
"State Management",
"{{state_management}}",
"{{version}}",
"{{purpose}}",
"{{why_chosen}}",
]
- ["Routing", "{{routing_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Styling", "{{styling_solution}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Testing", "{{test_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Component Library", "{{component_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- [
"Component Library",
"{{component_lib}}",
"{{version}}",
"{{purpose}}",
"{{why_chosen}}",
]
- ["Form Handling", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Animation", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]

View File

@@ -156,11 +156,29 @@ sections:
columns: [Category, Technology, Version, Purpose, Rationale]
rows:
- ["Frontend Language", "{{fe_language}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Frontend Framework", "{{fe_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["UI Component Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- [
"Frontend Framework",
"{{fe_framework}}",
"{{version}}",
"{{purpose}}",
"{{why_chosen}}",
]
- [
"UI Component Library",
"{{ui_library}}",
"{{version}}",
"{{purpose}}",
"{{why_chosen}}",
]
- ["State Management", "{{state_mgmt}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Backend Language", "{{be_language}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Backend Framework", "{{be_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- [
"Backend Framework",
"{{be_framework}}",
"{{version}}",
"{{purpose}}",
"{{why_chosen}}",
]
- ["API Style", "{{api_style}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Database", "{{database}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Cache", "{{cache}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]

View File

@@ -0,0 +1,102 @@
template:
id: qa-gate-template-v1
name: Quality Gate Decision
version: 1.0
output:
format: yaml
filename: docs/qa/gates/{{epic_num}}.{{story_num}}-{{story_slug}}.yml
title: "Quality Gate: {{epic_num}}.{{story_num}}"
# Required fields (keep these first)
schema: 1
story: "{{epic_num}}.{{story_num}}"
story_title: "{{story_title}}"
gate: "{{gate_status}}" # PASS|CONCERNS|FAIL|WAIVED
status_reason: "{{status_reason}}" # 1-2 sentence summary of why this gate decision
reviewer: "Quinn (Test Architect)"
updated: "{{iso_timestamp}}"
# Always present but only active when WAIVED
waiver: { active: false }
# Issues (if any) - Use fixed severity: low | medium | high
top_issues: []
# Risk summary (from risk-profile task if run)
risk_summary:
totals: { critical: 0, high: 0, medium: 0, low: 0 }
recommendations:
must_fix: []
monitor: []
# Examples section using block scalars for clarity
examples:
with_issues: |
top_issues:
- id: "SEC-001"
severity: high # ONLY: low|medium|high
finding: "No rate limiting on login endpoint"
suggested_action: "Add rate limiting middleware before production"
- id: "TEST-001"
severity: medium
finding: "Missing integration tests for auth flow"
suggested_action: "Add test coverage for critical paths"
when_waived: |
waiver:
active: true
reason: "Accepted for MVP release - will address in next sprint"
approved_by: "Product Owner"
# ============ Optional Extended Fields ============
# Uncomment and use if your team wants more detail
optional_fields_examples:
quality_and_expiry: |
quality_score: 75 # 0-100 (optional scoring)
expires: "2025-01-26T00:00:00Z" # Optional gate freshness window
evidence: |
evidence:
tests_reviewed: 15
risks_identified: 3
trace:
ac_covered: [1, 2, 3] # AC numbers with test coverage
ac_gaps: [4] # AC numbers lacking coverage
nfr_validation: |
nfr_validation:
security: { status: CONCERNS, notes: "Rate limiting missing" }
performance: { status: PASS, notes: "" }
reliability: { status: PASS, notes: "" }
maintainability: { status: PASS, notes: "" }
history: |
history: # Append-only audit trail
- at: "2025-01-12T10:00:00Z"
gate: FAIL
note: "Initial review - missing tests"
- at: "2025-01-12T15:00:00Z"
gate: CONCERNS
note: "Tests added but rate limiting still missing"
risk_summary: |
risk_summary: # From risk-profile task
totals:
critical: 0
high: 0
medium: 0
low: 0
# 'highest' is emitted only when risks exist
recommendations:
must_fix: []
monitor: []
recommendations: |
recommendations:
immediate: # Must fix before production
- action: "Add rate limiting to auth endpoints"
refs: ["api/auth/login.ts:42-68"]
future: # Can be addressed later
- action: "Consider caching for better performance"
refs: ["services/data.service.ts"]

View File

@@ -9,7 +9,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -22,14 +21,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -38,7 +35,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -46,7 +42,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -60,7 +55,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -70,7 +64,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context

View File

@@ -14,7 +14,7 @@ template:
output:
format: markdown
filename: default-path/to/{{filename}}.md
title: "{{variable}} Document Title"
title: '{{variable}} Document Title'
workflow:
mode: interactive
@@ -108,8 +108,8 @@ sections:
Use `{{variable_name}}` in titles, templates, and content:
```yaml
title: "Epic {{epic_number}} {{epic_title}}"
template: "As a {{user_type}}, I want {{action}}, so that {{benefit}}."
title: 'Epic {{epic_number}} {{epic_title}}'
template: 'As a {{user_type}}, I want {{action}}, so that {{benefit}}.'
```
### Conditional Sections
@@ -212,7 +212,7 @@ choices:
- id: criteria
title: Acceptance Criteria
type: numbered-list
item_template: "{{criterion_number}}: {{criteria}}"
item_template: '{{criterion_number}}: {{criteria}}'
repeatable: true
```
@@ -220,7 +220,7 @@ choices:
````yaml
examples:
- "FR6: The system must authenticate users within 2 seconds"
- 'FR6: The system must authenticate users within 2 seconds'
- |
```mermaid
sequenceDiagram

View File

@@ -76,14 +76,14 @@ persona:
- Numbered Options Protocol - Always use numbered lists for selections
commands:
- help: Show numbered list of the following commands to allow selection
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
- create-project-brief: use task create-doc with project-brief-tmpl.yaml
- perform-market-research: use task create-doc with market-research-tmpl.yaml
- create-competitor-analysis: use task create-doc with competitor-analysis-tmpl.yaml
- yolo: Toggle Yolo Mode
- doc-out: Output full document to current destination file
- execute-checklist {checklist}: Run task execute-checklist (default->architect-checklist)
- research-prompt {topic}: execute task create-deep-research-prompt for architectural decisions
- brainstorm {topic}: Facilitate structured brainstorming session
- doc-out: Output full document in progress to current destination file
- research-prompt {topic}: execute task create-deep-research-prompt.md
- brainstorm {topic}: Facilitate structured brainstorming session (run task facilitate-brainstorming-session.md with template brainstorming-output-tmpl.yaml)
- elicit: run the task advanced-elicitation
- document-project: Analyze and document existing project structure comprehensively
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
dependencies:
tasks:
@@ -106,7 +106,7 @@ dependencies:
==================== START: .bmad-core/tasks/facilitate-brainstorming-session.md ====================
---
docOutputLocation: docs/brainstorming-session-results.md
template: ".bmad-core/templates/brainstorming-output-tmpl.yaml"
template: '.bmad-core/templates/brainstorming-output-tmpl.yaml'
---
# Facilitate Brainstorming Session Task
@@ -266,63 +266,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
Present these numbered options to the user:
1. **Product Validation Research**
- Validate product hypotheses and market fit
- Test assumptions about user needs and solutions
- Assess technical and business feasibility
- Identify risks and mitigation strategies
2. **Market Opportunity Research**
- Analyze market size and growth potential
- Identify market segments and dynamics
- Assess market entry strategies
- Evaluate timing and market readiness
3. **User & Customer Research**
- Deep dive into user personas and behaviors
- Understand jobs-to-be-done and pain points
- Map customer journeys and touchpoints
- Analyze willingness to pay and value perception
4. **Competitive Intelligence Research**
- Detailed competitor analysis and positioning
- Feature and capability comparisons
- Business model and strategy analysis
- Identify competitive advantages and gaps
5. **Technology & Innovation Research**
- Assess technology trends and possibilities
- Evaluate technical approaches and architectures
- Identify emerging technologies and disruptions
- Analyze build vs. buy vs. partner options
6. **Industry & Ecosystem Research**
- Map industry value chains and dynamics
- Identify key players and relationships
- Analyze regulatory and compliance factors
- Understand partnership opportunities
7. **Strategic Options Research**
- Evaluate different strategic directions
- Assess business model alternatives
- Analyze go-to-market strategies
- Consider expansion and scaling paths
8. **Risk & Feasibility Research**
- Identify and assess various risk factors
- Evaluate implementation challenges
- Analyze resource requirements
- Consider regulatory and legal implications
9. **Custom Research Focus**
- User-defined research objectives
- Specialized domain investigation
- Cross-functional research needs
@@ -491,13 +482,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
### 5. Review and Refinement
1. **Present Complete Prompt**
- Show the full research prompt
- Explain key elements and rationale
- Highlight any assumptions made
2. **Gather Feedback**
- Are the objectives clear and correct?
- Do the questions address all concerns?
- Is the scope appropriate?
@@ -873,7 +862,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
### Change Log
| Date | Version | Description | Author |
|------|---------|-------------|--------|
| ------ | ------- | --------------------------- | --------- |
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
## Quick Reference - Key Files and Entry Points
@@ -898,7 +887,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
### Actual Tech Stack (from package.json/requirements.txt)
| Category | Technology | Version | Notes |
|----------|------------|---------|--------|
| --------- | ---------- | ------- | -------------------------- |
| Runtime | Node.js | 16.x | [Any constraints] |
| Framework | Express | 4.18.2 | [Custom middleware?] |
| Database | PostgreSQL | 13 | [Connection pooling setup] |
@@ -940,6 +929,7 @@ project-root/
### Data Models
Instead of duplicating, reference actual model files:
- **User Model**: See `src/models/User.js`
- **Order Model**: See `src/models/Order.js`
- **Related Types**: TypeScript definitions in `src/types/`
@@ -970,7 +960,7 @@ Instead of duplicating, reference actual model files:
### External Services
| Service | Purpose | Integration Type | Key Files |
|---------|---------|------------------|-----------|
| -------- | -------- | ---------------- | ------------------------------ |
| Stripe | Payments | REST API | `src/integrations/stripe/` |
| SendGrid | Emails | SDK | `src/services/emailService.js` |
@@ -1017,6 +1007,7 @@ npm run test:integration # Runs integration tests (requires local DB)
### Files That Will Need Modification
Based on the enhancement requirements, these files will be affected:
- `src/services/userService.js` - Add new user fields
- `src/models/User.js` - Update schema
- `src/routes/userRoutes.js` - New endpoints
@@ -1110,24 +1101,24 @@ template:
output:
format: markdown
filename: docs/brief.md
title: "Project Brief: {{project_name}}"
title: 'Project Brief: {{project_name}}'
workflow:
mode: interactive
elicitation: advanced-elicitation
custom_elicitation:
title: "Project Brief Elicitation Actions"
title: 'Project Brief Elicitation Actions'
options:
- "Expand section with more specific details"
- "Validate against similar successful products"
- "Stress test assumptions with edge cases"
- "Explore alternative solution approaches"
- "Analyze resource/constraint trade-offs"
- "Generate risk mitigation strategies"
- "Challenge scope from MVP minimalist view"
- "Brainstorm creative feature possibilities"
- "If only we had [resource/capability/time]..."
- "Proceed to next section"
- 'Expand section with more specific details'
- 'Validate against similar successful products'
- 'Stress test assumptions with edge cases'
- 'Explore alternative solution approaches'
- 'Analyze resource/constraint trade-offs'
- 'Generate risk mitigation strategies'
- 'Challenge scope from MVP minimalist view'
- 'Brainstorm creative feature possibilities'
- 'If only we had [resource/capability/time]...'
- 'Proceed to next section'
sections:
- id: introduction
@@ -1149,7 +1140,7 @@ sections:
- Primary problem being solved
- Target market identification
- Key value proposition
template: "{{executive_summary_content}}"
template: '{{executive_summary_content}}'
- id: problem-statement
title: Problem Statement
@@ -1159,7 +1150,7 @@ sections:
- Impact of the problem (quantify if possible)
- Why existing solutions fall short
- Urgency and importance of solving this now
template: "{{detailed_problem_description}}"
template: '{{detailed_problem_description}}'
- id: proposed-solution
title: Proposed Solution
@@ -1169,7 +1160,7 @@ sections:
- Key differentiators from existing solutions
- Why this solution will succeed where others haven't
- High-level vision for the product
template: "{{solution_description}}"
template: '{{solution_description}}'
- id: target-users
title: Target Users
@@ -1181,12 +1172,12 @@ sections:
- Goals they're trying to achieve
sections:
- id: primary-segment
title: "Primary User Segment: {{segment_name}}"
template: "{{primary_user_description}}"
title: 'Primary User Segment: {{segment_name}}'
template: '{{primary_user_description}}'
- id: secondary-segment
title: "Secondary User Segment: {{segment_name}}"
title: 'Secondary User Segment: {{segment_name}}'
condition: Has secondary user segment
template: "{{secondary_user_description}}"
template: '{{secondary_user_description}}'
- id: goals-metrics
title: Goals & Success Metrics
@@ -1195,15 +1186,15 @@ sections:
- id: business-objectives
title: Business Objectives
type: bullet-list
template: "- {{objective_with_metric}}"
template: '- {{objective_with_metric}}'
- id: user-success-metrics
title: User Success Metrics
type: bullet-list
template: "- {{user_metric}}"
template: '- {{user_metric}}'
- id: kpis
title: Key Performance Indicators (KPIs)
type: bullet-list
template: "- {{kpi}}: {{definition_and_target}}"
template: '- {{kpi}}: {{definition_and_target}}'
- id: mvp-scope
title: MVP Scope
@@ -1212,14 +1203,14 @@ sections:
- id: core-features
title: Core Features (Must Have)
type: bullet-list
template: "- **{{feature}}:** {{description_and_rationale}}"
template: '- **{{feature}}:** {{description_and_rationale}}'
- id: out-of-scope
title: Out of Scope for MVP
type: bullet-list
template: "- {{feature_or_capability}}"
template: '- {{feature_or_capability}}'
- id: mvp-success-criteria
title: MVP Success Criteria
template: "{{mvp_success_definition}}"
template: '{{mvp_success_definition}}'
- id: post-mvp-vision
title: Post-MVP Vision
@@ -1227,13 +1218,13 @@ sections:
sections:
- id: phase-2-features
title: Phase 2 Features
template: "{{next_priority_features}}"
template: '{{next_priority_features}}'
- id: long-term-vision
title: Long-term Vision
template: "{{one_two_year_vision}}"
template: '{{one_two_year_vision}}'
- id: expansion-opportunities
title: Expansion Opportunities
template: "{{potential_expansions}}"
template: '{{potential_expansions}}'
- id: technical-considerations
title: Technical Considerations
@@ -1274,7 +1265,7 @@ sections:
- id: key-assumptions
title: Key Assumptions
type: bullet-list
template: "- {{assumption}}"
template: '- {{assumption}}'
- id: risks-questions
title: Risks & Open Questions
@@ -1283,15 +1274,15 @@ sections:
- id: key-risks
title: Key Risks
type: bullet-list
template: "- **{{risk}}:** {{description_and_impact}}"
template: '- **{{risk}}:** {{description_and_impact}}'
- id: open-questions
title: Open Questions
type: bullet-list
template: "- {{question}}"
template: '- {{question}}'
- id: research-areas
title: Areas Needing Further Research
type: bullet-list
template: "- {{research_topic}}"
template: '- {{research_topic}}'
- id: appendices
title: Appendices
@@ -1308,10 +1299,10 @@ sections:
- id: stakeholder-input
title: B. Stakeholder Input
condition: Has stakeholder feedback
template: "{{stakeholder_feedback}}"
template: '{{stakeholder_feedback}}'
- id: references
title: C. References
template: "{{relevant_links_and_docs}}"
template: '{{relevant_links_and_docs}}'
- id: next-steps
title: Next Steps
@@ -1319,7 +1310,7 @@ sections:
- id: immediate-actions
title: Immediate Actions
type: numbered-list
template: "{{action_item}}"
template: '{{action_item}}'
- id: pm-handoff
title: PM Handoff
content: |
@@ -1334,24 +1325,24 @@ template:
output:
format: markdown
filename: docs/market-research.md
title: "Market Research Report: {{project_product_name}}"
title: 'Market Research Report: {{project_product_name}}'
workflow:
mode: interactive
elicitation: advanced-elicitation
custom_elicitation:
title: "Market Research Elicitation Actions"
title: 'Market Research Elicitation Actions'
options:
- "Expand market sizing calculations with sensitivity analysis"
- "Deep dive into a specific customer segment"
- "Analyze an emerging market trend in detail"
- "Compare this market to an analogous market"
- "Stress test market assumptions"
- "Explore adjacent market opportunities"
- "Challenge market definition and boundaries"
- "Generate strategic scenarios (best/base/worst case)"
- "If only we had considered [X market factor]..."
- "Proceed to next section"
- 'Expand market sizing calculations with sensitivity analysis'
- 'Deep dive into a specific customer segment'
- 'Analyze an emerging market trend in detail'
- 'Compare this market to an analogous market'
- 'Stress test market assumptions'
- 'Explore adjacent market opportunities'
- 'Challenge market definition and boundaries'
- 'Generate strategic scenarios (best/base/worst case)'
- 'If only we had considered [X market factor]...'
- 'Proceed to next section'
sections:
- id: executive-summary
@@ -1433,7 +1424,7 @@ sections:
repeatable: true
sections:
- id: segment
title: "Segment {{segment_number}}: {{segment_name}}"
title: 'Segment {{segment_number}}: {{segment_name}}'
template: |
- **Description:** {{brief_overview}}
- **Size:** {{number_of_customers_market_value}}
@@ -1502,20 +1493,20 @@ sections:
instruction: Analyze each force with specific evidence and implications
sections:
- id: supplier-power
title: "Supplier Power: {{power_level}}"
template: "{{analysis_and_implications}}"
title: 'Supplier Power: {{power_level}}'
template: '{{analysis_and_implications}}'
- id: buyer-power
title: "Buyer Power: {{power_level}}"
template: "{{analysis_and_implications}}"
title: 'Buyer Power: {{power_level}}'
template: '{{analysis_and_implications}}'
- id: competitive-rivalry
title: "Competitive Rivalry: {{intensity_level}}"
template: "{{analysis_and_implications}}"
title: 'Competitive Rivalry: {{intensity_level}}'
template: '{{analysis_and_implications}}'
- id: threat-new-entry
title: "Threat of New Entry: {{threat_level}}"
template: "{{analysis_and_implications}}"
title: 'Threat of New Entry: {{threat_level}}'
template: '{{analysis_and_implications}}'
- id: threat-substitutes
title: "Threat of Substitutes: {{threat_level}}"
template: "{{analysis_and_implications}}"
title: 'Threat of Substitutes: {{threat_level}}'
template: '{{analysis_and_implications}}'
- id: adoption-lifecycle
title: Technology Adoption Lifecycle Stage
instruction: |
@@ -1533,7 +1524,7 @@ sections:
repeatable: true
sections:
- id: opportunity
title: "Opportunity {{opportunity_number}}: {{name}}"
title: 'Opportunity {{opportunity_number}}: {{name}}'
template: |
- **Description:** {{what_is_the_opportunity}}
- **Size/Potential:** {{quantified_potential}}
@@ -1589,24 +1580,24 @@ template:
output:
format: markdown
filename: docs/competitor-analysis.md
title: "Competitive Analysis Report: {{project_product_name}}"
title: 'Competitive Analysis Report: {{project_product_name}}'
workflow:
mode: interactive
elicitation: advanced-elicitation
custom_elicitation:
title: "Competitive Analysis Elicitation Actions"
title: 'Competitive Analysis Elicitation Actions'
options:
- "Deep dive on a specific competitor's strategy"
- "Analyze competitive dynamics in a specific segment"
- "War game competitive responses to your moves"
- "Explore partnership vs. competition scenarios"
- "Stress test differentiation claims"
- "Analyze disruption potential (yours or theirs)"
- "Compare to competition in adjacent markets"
- "Generate win/loss analysis insights"
- 'Analyze competitive dynamics in a specific segment'
- 'War game competitive responses to your moves'
- 'Explore partnership vs. competition scenarios'
- 'Stress test differentiation claims'
- 'Analyze disruption potential (yours or theirs)'
- 'Compare to competition in adjacent markets'
- 'Generate win/loss analysis insights'
- "If only we had known about [competitor X's plan]..."
- "Proceed to next section"
- 'Proceed to next section'
sections:
- id: executive-summary
@@ -1673,7 +1664,7 @@ sections:
repeatable: true
sections:
- id: competitor
title: "{{competitor_name}} - Priority {{priority_level}}"
title: '{{competitor_name}} - Priority {{priority_level}}'
sections:
- id: company-overview
title: Company Overview
@@ -1705,11 +1696,11 @@ sections:
- id: strengths
title: Strengths
type: bullet-list
template: "- {{strength}}"
template: '- {{strength}}'
- id: weaknesses
title: Weaknesses
type: bullet-list
template: "- {{weakness}}"
template: '- {{weakness}}'
- id: market-position
title: Market Position & Performance
template: |
@@ -1725,24 +1716,37 @@ sections:
title: Feature Comparison Matrix
instruction: Create a detailed comparison table of key features across competitors
type: table
columns: ["Feature Category", "{{your_company}}", "{{competitor_1}}", "{{competitor_2}}", "{{competitor_3}}"]
columns:
[
'Feature Category',
'{{your_company}}',
'{{competitor_1}}',
'{{competitor_2}}',
'{{competitor_3}}',
]
rows:
- category: "Core Functionality"
- category: 'Core Functionality'
items:
- ["Feature A", "{{status}}", "{{status}}", "{{status}}", "{{status}}"]
- ["Feature B", "{{status}}", "{{status}}", "{{status}}", "{{status}}"]
- category: "User Experience"
- ['Feature A', '{{status}}', '{{status}}', '{{status}}', '{{status}}']
- ['Feature B', '{{status}}', '{{status}}', '{{status}}', '{{status}}']
- category: 'User Experience'
items:
- ["Mobile App", "{{rating}}", "{{rating}}", "{{rating}}", "{{rating}}"]
- ["Onboarding Time", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
- category: "Integration & Ecosystem"
- ['Mobile App', '{{rating}}', '{{rating}}', '{{rating}}', '{{rating}}']
- ['Onboarding Time', '{{time}}', '{{time}}', '{{time}}', '{{time}}']
- category: 'Integration & Ecosystem'
items:
- ["API Availability", "{{availability}}", "{{availability}}", "{{availability}}", "{{availability}}"]
- ["Third-party Integrations", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
- category: "Pricing & Plans"
- [
'API Availability',
'{{availability}}',
'{{availability}}',
'{{availability}}',
'{{availability}}',
]
- ['Third-party Integrations', '{{number}}', '{{number}}', '{{number}}', '{{number}}']
- category: 'Pricing & Plans'
items:
- ["Starting Price", "{{price}}", "{{price}}", "{{price}}", "{{price}}"]
- ["Free Tier", "{{yes_no}}", "{{yes_no}}", "{{yes_no}}", "{{yes_no}}"]
- ['Starting Price', '{{price}}', '{{price}}', '{{price}}', '{{price}}']
- ['Free Tier', '{{yes_no}}', '{{yes_no}}', '{{yes_no}}', '{{yes_no}}']
- id: swot-comparison
title: SWOT Comparison
instruction: Create SWOT analysis for your solution vs. top competitors
@@ -1755,7 +1759,7 @@ sections:
- **Opportunities:** {{opportunities}}
- **Threats:** {{threats}}
- id: vs-competitor
title: "vs. {{main_competitor}}"
title: 'vs. {{main_competitor}}'
template: |
- **Competitive Advantages:** {{your_advantages}}
- **Competitive Disadvantages:** {{their_advantages}}
@@ -1885,7 +1889,7 @@ template:
output:
format: markdown
filename: docs/brainstorming-session-results.md
title: "Brainstorming Session Results"
title: 'Brainstorming Session Results'
workflow:
mode: non-interactive
@@ -1910,38 +1914,38 @@ sections:
**Total Ideas Generated:** {{total_ideas}}
- id: key-themes
title: "Key Themes Identified:"
title: 'Key Themes Identified:'
type: bullet-list
template: "- {{theme}}"
template: '- {{theme}}'
- id: technique-sessions
title: Technique Sessions
repeatable: true
sections:
- id: technique
title: "{{technique_name}} - {{duration}}"
title: '{{technique_name}} - {{duration}}'
sections:
- id: description
template: "**Description:** {{technique_description}}"
template: '**Description:** {{technique_description}}'
- id: ideas-generated
title: "Ideas Generated:"
title: 'Ideas Generated:'
type: numbered-list
template: "{{idea}}"
template: '{{idea}}'
- id: insights
title: "Insights Discovered:"
title: 'Insights Discovered:'
type: bullet-list
template: "- {{insight}}"
template: '- {{insight}}'
- id: connections
title: "Notable Connections:"
title: 'Notable Connections:'
type: bullet-list
template: "- {{connection}}"
template: '- {{connection}}'
- id: idea-categorization
title: Idea Categorization
sections:
- id: immediate-opportunities
title: Immediate Opportunities
content: "*Ideas ready to implement now*"
content: '*Ideas ready to implement now*'
repeatable: true
type: numbered-list
template: |
@@ -1951,7 +1955,7 @@ sections:
- Resources needed: {{requirements}}
- id: future-innovations
title: Future Innovations
content: "*Ideas requiring development/research*"
content: '*Ideas requiring development/research*'
repeatable: true
type: numbered-list
template: |
@@ -1961,7 +1965,7 @@ sections:
- Timeline estimate: {{timeline}}
- id: moonshots
title: Moonshots
content: "*Ambitious, transformative concepts*"
content: '*Ambitious, transformative concepts*'
repeatable: true
type: numbered-list
template: |
@@ -1971,9 +1975,9 @@ sections:
- Challenges to overcome: {{challenges}}
- id: insights-learnings
title: Insights & Learnings
content: "*Key realizations from the session*"
content: '*Key realizations from the session*'
type: bullet-list
template: "- {{insight}}: {{description_and_implications}}"
template: '- {{insight}}: {{description_and_implications}}'
- id: action-planning
title: Action Planning
@@ -1982,21 +1986,21 @@ sections:
title: Top 3 Priority Ideas
sections:
- id: priority-1
title: "#1 Priority: {{idea_name}}"
title: '#1 Priority: {{idea_name}}'
template: |
- Rationale: {{rationale}}
- Next steps: {{next_steps}}
- Resources needed: {{resources}}
- Timeline: {{timeline}}
- id: priority-2
title: "#2 Priority: {{idea_name}}"
title: '#2 Priority: {{idea_name}}'
template: |
- Rationale: {{rationale}}
- Next steps: {{next_steps}}
- Resources needed: {{resources}}
- Timeline: {{timeline}}
- id: priority-3
title: "#3 Priority: {{idea_name}}"
title: '#3 Priority: {{idea_name}}'
template: |
- Rationale: {{rationale}}
- Next steps: {{next_steps}}
@@ -2009,19 +2013,19 @@ sections:
- id: what-worked
title: What Worked Well
type: bullet-list
template: "- {{aspect}}"
template: '- {{aspect}}'
- id: areas-exploration
title: Areas for Further Exploration
type: bullet-list
template: "- {{area}}: {{reason}}"
template: '- {{area}}: {{reason}}'
- id: recommended-techniques
title: Recommended Follow-up Techniques
type: bullet-list
template: "- {{technique}}: {{reason}}"
template: '- {{technique}}: {{reason}}'
- id: questions-emerged
title: Questions That Emerged
type: bullet-list
template: "- {{question}}"
template: '- {{question}}'
- id: next-session
title: Next Session Planning
template: |
@@ -2337,7 +2341,7 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
- **Claude Code**: `/agent-name` (e.g., `/bmad-master`)
- **Cursor**: `@agent-name` (e.g., `@bmad-master`)
- **Windsurf**: `@agent-name` (e.g., `@bmad-master`)
- **Windsurf**: `/agent-name` (e.g., `/bmad-master`)
- **Trae**: `@agent-name` (e.g., `@bmad-master`)
- **Roo Code**: Select mode from mode selector (e.g., `bmad-master`)
- **GitHub Copilot**: Open the Chat view (`⌃⌘I` on Mac, `Ctrl+Alt+I` on Windows/Linux) and select **Agent** from the chat mode selector.
@@ -2690,8 +2694,11 @@ Templates with Level 2 headings (`##`) can be automatically sharded:
```markdown
## Goals and Background Context
## Requirements
## User Interface Design Goals
## Success Metrics
```

View File

@@ -76,11 +76,16 @@ persona:
- Living Architecture - Design for change and adaptation
commands:
- help: Show numbered list of the following commands to allow selection
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
- yolo: Toggle Yolo Mode
- create-full-stack-architecture: use create-doc with fullstack-architecture-tmpl.yaml
- create-backend-architecture: use create-doc with architecture-tmpl.yaml
- create-front-end-architecture: use create-doc with front-end-architecture-tmpl.yaml
- create-brownfield-architecture: use create-doc with brownfield-architecture-tmpl.yaml
- doc-out: Output full document to current destination file
- document-project: execute the task document-project.md
- execute-checklist {checklist}: Run task execute-checklist (default->architect-checklist)
- research {topic}: execute task create-deep-research-prompt for architectural decisions
- research {topic}: execute task create-deep-research-prompt
- shard-prd: run the task shard-doc.md for the provided architecture.md (ask if not found)
- yolo: Toggle Yolo Mode
- exit: Say goodbye as the Architect, and then abandon inhabiting this persona
dependencies:
tasks:
@@ -228,63 +233,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
Present these numbered options to the user:
1. **Product Validation Research**
- Validate product hypotheses and market fit
- Test assumptions about user needs and solutions
- Assess technical and business feasibility
- Identify risks and mitigation strategies
2. **Market Opportunity Research**
- Analyze market size and growth potential
- Identify market segments and dynamics
- Assess market entry strategies
- Evaluate timing and market readiness
3. **User & Customer Research**
- Deep dive into user personas and behaviors
- Understand jobs-to-be-done and pain points
- Map customer journeys and touchpoints
- Analyze willingness to pay and value perception
4. **Competitive Intelligence Research**
- Detailed competitor analysis and positioning
- Feature and capability comparisons
- Business model and strategy analysis
- Identify competitive advantages and gaps
5. **Technology & Innovation Research**
- Assess technology trends and possibilities
- Evaluate technical approaches and architectures
- Identify emerging technologies and disruptions
- Analyze build vs. buy vs. partner options
6. **Industry & Ecosystem Research**
- Map industry value chains and dynamics
- Identify key players and relationships
- Analyze regulatory and compliance factors
- Understand partnership opportunities
7. **Strategic Options Research**
- Evaluate different strategic directions
- Assess business model alternatives
- Analyze go-to-market strategies
- Consider expansion and scaling paths
8. **Risk & Feasibility Research**
- Identify and assess various risk factors
- Evaluate implementation challenges
- Analyze resource requirements
- Consider regulatory and legal implications
9. **Custom Research Focus**
- User-defined research objectives
- Specialized domain investigation
- Cross-functional research needs
@@ -453,13 +449,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
### 5. Review and Refinement
1. **Present Complete Prompt**
- Show the full research prompt
- Explain key elements and rationale
- Highlight any assumptions made
2. **Gather Feedback**
- Are the objectives clear and correct?
- Do the questions address all concerns?
- Is the scope appropriate?
@@ -611,7 +605,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
### Change Log
| Date | Version | Description | Author |
|------|---------|-------------|--------|
| ------ | ------- | --------------------------- | --------- |
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
## Quick Reference - Key Files and Entry Points
@@ -636,7 +630,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
### Actual Tech Stack (from package.json/requirements.txt)
| Category | Technology | Version | Notes |
|----------|------------|---------|--------|
| --------- | ---------- | ------- | -------------------------- |
| Runtime | Node.js | 16.x | [Any constraints] |
| Framework | Express | 4.18.2 | [Custom middleware?] |
| Database | PostgreSQL | 13 | [Connection pooling setup] |
@@ -678,6 +672,7 @@ project-root/
### Data Models
Instead of duplicating, reference actual model files:
- **User Model**: See `src/models/User.js`
- **Order Model**: See `src/models/Order.js`
- **Related Types**: TypeScript definitions in `src/types/`
@@ -708,7 +703,7 @@ Instead of duplicating, reference actual model files:
### External Services
| Service | Purpose | Integration Type | Key Files |
|---------|---------|------------------|-----------|
| -------- | -------- | ---------------- | ------------------------------ |
| Stripe | Payments | REST API | `src/integrations/stripe/` |
| SendGrid | Emails | SDK | `src/services/emailService.js` |
@@ -755,6 +750,7 @@ npm run test:integration # Runs integration tests (requires local DB)
### Files That Will Need Modification
Based on the enhancement requirements, these files will be affected:
- `src/services/userService.js` - Add new user fields
- `src/models/User.js` - Update schema
- `src/routes/userRoutes.js` - New endpoints
@@ -852,7 +848,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -865,14 +860,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -881,7 +874,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -889,7 +881,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -903,7 +894,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -913,7 +903,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
@@ -944,7 +933,7 @@ template:
output:
format: markdown
filename: docs/architecture.md
title: "{{project_name}} Architecture Document"
title: '{{project_name}} Architecture Document'
workflow:
mode: interactive
@@ -1055,11 +1044,11 @@ sections:
- Code organization patterns (Dependency Injection, Repository, Module, Factory)
- Data patterns (Event Sourcing, Saga, Database per Service)
- Communication patterns (REST, GraphQL, Message Queue, Pub/Sub)
template: "- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}"
template: '- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}'
examples:
- "**Serverless Architecture:** Using AWS Lambda for compute - _Rationale:_ Aligns with PRD requirement for cost optimization and automatic scaling"
- "**Repository Pattern:** Abstract data access logic - _Rationale:_ Enables testing and future database migration flexibility"
- "**Event-Driven Communication:** Using SNS/SQS for service decoupling - _Rationale:_ Supports async processing and system resilience"
- '**Serverless Architecture:** Using AWS Lambda for compute - _Rationale:_ Aligns with PRD requirement for cost optimization and automatic scaling'
- '**Repository Pattern:** Abstract data access logic - _Rationale:_ Enables testing and future database migration flexibility'
- '**Event-Driven Communication:** Using SNS/SQS for service decoupling - _Rationale:_ Supports async processing and system resilience'
- id: tech-stack
title: Tech Stack
@@ -1097,9 +1086,9 @@ sections:
columns: [Category, Technology, Version, Purpose, Rationale]
instruction: Populate the technology stack table with all relevant technologies
examples:
- "| **Language** | TypeScript | 5.3.3 | Primary development language | Strong typing, excellent tooling, team expertise |"
- "| **Runtime** | Node.js | 20.11.0 | JavaScript runtime | LTS version, stable performance, wide ecosystem |"
- "| **Framework** | NestJS | 10.3.2 | Backend framework | Enterprise-ready, good DI, matches team patterns |"
- '| **Language** | TypeScript | 5.3.3 | Primary development language | Strong typing, excellent tooling, team expertise |'
- '| **Runtime** | Node.js | 20.11.0 | JavaScript runtime | LTS version, stable performance, wide ecosystem |'
- '| **Framework** | NestJS | 10.3.2 | Backend framework | Enterprise-ready, good DI, matches team patterns |'
- id: data-models
title: Data Models
@@ -1117,7 +1106,7 @@ sections:
repeatable: true
sections:
- id: model
title: "{{model_name}}"
title: '{{model_name}}'
template: |
**Purpose:** {{model_purpose}}
@@ -1148,7 +1137,7 @@ sections:
sections:
- id: component-list
repeatable: true
title: "{{component_name}}"
title: '{{component_name}}'
template: |
**Responsibility:** {{component_description}}
@@ -1186,7 +1175,7 @@ sections:
repeatable: true
sections:
- id: api
title: "{{api_name}} API"
title: '{{api_name}} API'
template: |
- **Purpose:** {{api_purpose}}
- **Documentation:** {{api_docs_url}}
@@ -1311,12 +1300,12 @@ sections:
- id: environments
title: Environments
repeatable: true
template: "- **{{env_name}}:** {{env_purpose}} - {{env_details}}"
template: '- **{{env_name}}:** {{env_purpose}} - {{env_details}}'
- id: promotion-flow
title: Environment Promotion Flow
type: code
language: text
template: "{{promotion_flow_diagram}}"
template: '{{promotion_flow_diagram}}'
- id: rollback-strategy
title: Rollback Strategy
template: |
@@ -1412,16 +1401,16 @@ sections:
Avoid obvious rules like "use SOLID principles" or "write clean code"
repeatable: true
template: "- **{{rule_name}}:** {{rule_description}}"
template: '- **{{rule_name}}:** {{rule_description}}'
- id: language-specifics
title: Language-Specific Guidelines
condition: Critical language-specific rules needed
instruction: Add ONLY if critical for preventing AI mistakes. Most teams don't need this section.
sections:
- id: language-rules
title: "{{language_name}} Specifics"
title: '{{language_name}} Specifics'
repeatable: true
template: "- **{{rule_topic}}:** {{rule_detail}}"
template: '- **{{rule_topic}}:** {{rule_detail}}'
- id: test-strategy
title: Test Strategy and Standards
@@ -1469,9 +1458,9 @@ sections:
- **Test Infrastructure:**
- **{{dependency_name}}:** {{test_approach}} ({{test_tool}})
examples:
- "**Database:** In-memory H2 for unit tests, Testcontainers PostgreSQL for integration"
- "**Message Queue:** Embedded Kafka for tests"
- "**External APIs:** WireMock for stubbing"
- '**Database:** In-memory H2 for unit tests, Testcontainers PostgreSQL for integration'
- '**Message Queue:** Embedded Kafka for tests'
- '**External APIs:** WireMock for stubbing'
- id: e2e-tests
title: End-to-End Tests
template: |
@@ -1597,7 +1586,7 @@ template:
output:
format: markdown
filename: docs/ui-architecture.md
title: "{{project_name}} Frontend Architecture Document"
title: '{{project_name}} Frontend Architecture Document'
workflow:
mode: interactive
@@ -1665,17 +1654,29 @@ sections:
columns: [Category, Technology, Version, Purpose, Rationale]
instruction: Fill in appropriate technology choices based on the selected framework and project requirements.
rows:
- ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["UI Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["State Management", "{{state_management}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Routing", "{{routing_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Styling", "{{styling_solution}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Testing", "{{test_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Component Library", "{{component_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Form Handling", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Animation", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ['Framework', '{{framework}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['UI Library', '{{ui_library}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- [
'State Management',
'{{state_management}}',
'{{version}}',
'{{purpose}}',
'{{why_chosen}}',
]
- ['Routing', '{{routing_library}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Build Tool', '{{build_tool}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Styling', '{{styling_solution}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Testing', '{{test_framework}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- [
'Component Library',
'{{component_lib}}',
'{{version}}',
'{{purpose}}',
'{{why_chosen}}',
]
- ['Form Handling', '{{form_library}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Animation', '{{animation_lib}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Dev Tools', '{{dev_tools}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- id: project-structure
title: Project Structure
@@ -1769,12 +1770,12 @@ sections:
title: Testing Best Practices
type: numbered-list
items:
- "**Unit Tests**: Test individual components in isolation"
- "**Integration Tests**: Test component interactions"
- "**E2E Tests**: Test critical user flows (using Cypress/Playwright)"
- "**Coverage Goals**: Aim for 80% code coverage"
- "**Test Structure**: Arrange-Act-Assert pattern"
- "**Mock External Dependencies**: API calls, routing, state management"
- '**Unit Tests**: Test individual components in isolation'
- '**Integration Tests**: Test component interactions'
- '**E2E Tests**: Test critical user flows (using Cypress/Playwright)'
- '**Coverage Goals**: Aim for 80% code coverage'
- '**Test Structure**: Arrange-Act-Assert pattern'
- '**Mock External Dependencies**: API calls, routing, state management'
- id: environment-configuration
title: Environment Configuration
@@ -1806,7 +1807,7 @@ template:
output:
format: markdown
filename: docs/architecture.md
title: "{{project_name}} Fullstack Architecture Document"
title: '{{project_name}} Fullstack Architecture Document'
workflow:
mode: interactive
@@ -1927,12 +1928,12 @@ sections:
For each pattern, provide recommendation and rationale.
repeatable: true
template: "- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}"
template: '- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}'
examples:
- "**Jamstack Architecture:** Static site generation with serverless APIs - _Rationale:_ Optimal performance and scalability for content-heavy applications"
- "**Component-Based UI:** Reusable React components with TypeScript - _Rationale:_ Maintainability and type safety across large codebases"
- "**Repository Pattern:** Abstract data access logic - _Rationale:_ Enables testing and future database migration flexibility"
- "**API Gateway Pattern:** Single entry point for all API calls - _Rationale:_ Centralized auth, rate limiting, and monitoring"
- '**Jamstack Architecture:** Static site generation with serverless APIs - _Rationale:_ Optimal performance and scalability for content-heavy applications'
- '**Component-Based UI:** Reusable React components with TypeScript - _Rationale:_ Maintainability and type safety across large codebases'
- '**Repository Pattern:** Abstract data access logic - _Rationale:_ Enables testing and future database migration flexibility'
- '**API Gateway Pattern:** Single entry point for all API calls - _Rationale:_ Centralized auth, rate limiting, and monitoring'
- id: tech-stack
title: Tech Stack
@@ -1956,27 +1957,45 @@ sections:
type: table
columns: [Category, Technology, Version, Purpose, Rationale]
rows:
- ["Frontend Language", "{{fe_language}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Frontend Framework", "{{fe_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["UI Component Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["State Management", "{{state_mgmt}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Backend Language", "{{be_language}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Backend Framework", "{{be_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["API Style", "{{api_style}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Database", "{{database}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Cache", "{{cache}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["File Storage", "{{storage}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Authentication", "{{auth}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Frontend Testing", "{{fe_test}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Backend Testing", "{{be_test}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["E2E Testing", "{{e2e_test}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Bundler", "{{bundler}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["IaC Tool", "{{iac_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["CI/CD", "{{cicd}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Monitoring", "{{monitoring}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Logging", "{{logging}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["CSS Framework", "{{css_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ['Frontend Language', '{{fe_language}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- [
'Frontend Framework',
'{{fe_framework}}',
'{{version}}',
'{{purpose}}',
'{{why_chosen}}',
]
- [
'UI Component Library',
'{{ui_library}}',
'{{version}}',
'{{purpose}}',
'{{why_chosen}}',
]
- ['State Management', '{{state_mgmt}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Backend Language', '{{be_language}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- [
'Backend Framework',
'{{be_framework}}',
'{{version}}',
'{{purpose}}',
'{{why_chosen}}',
]
- ['API Style', '{{api_style}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Database', '{{database}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Cache', '{{cache}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['File Storage', '{{storage}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Authentication', '{{auth}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Frontend Testing', '{{fe_test}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Backend Testing', '{{be_test}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['E2E Testing', '{{e2e_test}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Build Tool', '{{build_tool}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Bundler', '{{bundler}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['IaC Tool', '{{iac_tool}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['CI/CD', '{{cicd}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Monitoring', '{{monitoring}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['Logging', '{{logging}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- ['CSS Framework', '{{css_framework}}', '{{version}}', '{{purpose}}', '{{why_chosen}}']
- id: data-models
title: Data Models
@@ -1995,7 +2014,7 @@ sections:
repeatable: true
sections:
- id: model
title: "{{model_name}}"
title: '{{model_name}}'
template: |
**Purpose:** {{model_purpose}}
@@ -2007,11 +2026,11 @@ sections:
title: TypeScript Interface
type: code
language: typescript
template: "{{model_interface}}"
template: '{{model_interface}}'
- id: relationships
title: Relationships
type: bullet-list
template: "- {{relationship}}"
template: '- {{relationship}}'
- id: api-spec
title: API Specification
@@ -2048,13 +2067,13 @@ sections:
condition: API style is GraphQL
type: code
language: graphql
template: "{{graphql_schema}}"
template: '{{graphql_schema}}'
- id: trpc-api
title: tRPC Router Definitions
condition: API style is tRPC
type: code
language: typescript
template: "{{trpc_routers}}"
template: '{{trpc_routers}}'
- id: components
title: Components
@@ -2075,7 +2094,7 @@ sections:
sections:
- id: component-list
repeatable: true
title: "{{component_name}}"
title: '{{component_name}}'
template: |
**Responsibility:** {{component_description}}
@@ -2113,7 +2132,7 @@ sections:
repeatable: true
sections:
- id: api
title: "{{api_name}} API"
title: '{{api_name}} API'
template: |
- **Purpose:** {{api_purpose}}
- **Documentation:** {{api_docs_url}}
@@ -2170,12 +2189,12 @@ sections:
title: Component Organization
type: code
language: text
template: "{{component_structure}}"
template: '{{component_structure}}'
- id: component-template
title: Component Template
type: code
language: typescript
template: "{{component_template}}"
template: '{{component_template}}'
- id: state-management
title: State Management Architecture
instruction: Detail state management approach based on chosen solution.
@@ -2184,11 +2203,11 @@ sections:
title: State Structure
type: code
language: typescript
template: "{{state_structure}}"
template: '{{state_structure}}'
- id: state-patterns
title: State Management Patterns
type: bullet-list
template: "- {{pattern}}"
template: '- {{pattern}}'
- id: routing-architecture
title: Routing Architecture
instruction: Define routing structure based on framework choice.
@@ -2197,12 +2216,12 @@ sections:
title: Route Organization
type: code
language: text
template: "{{route_structure}}"
template: '{{route_structure}}'
- id: protected-routes
title: Protected Route Pattern
type: code
language: typescript
template: "{{protected_route_example}}"
template: '{{protected_route_example}}'
- id: frontend-services
title: Frontend Services Layer
instruction: Define how frontend communicates with backend.
@@ -2211,12 +2230,12 @@ sections:
title: API Client Setup
type: code
language: typescript
template: "{{api_client_setup}}"
template: '{{api_client_setup}}'
- id: service-example
title: Service Example
type: code
language: typescript
template: "{{service_example}}"
template: '{{service_example}}'
- id: backend-architecture
title: Backend Architecture
@@ -2234,12 +2253,12 @@ sections:
title: Function Organization
type: code
language: text
template: "{{function_structure}}"
template: '{{function_structure}}'
- id: function-template
title: Function Template
type: code
language: typescript
template: "{{function_template}}"
template: '{{function_template}}'
- id: traditional-server
condition: Traditional server architecture chosen
sections:
@@ -2247,12 +2266,12 @@ sections:
title: Controller/Route Organization
type: code
language: text
template: "{{controller_structure}}"
template: '{{controller_structure}}'
- id: controller-template
title: Controller Template
type: code
language: typescript
template: "{{controller_template}}"
template: '{{controller_template}}'
- id: database-architecture
title: Database Architecture
instruction: Define database schema and access patterns.
@@ -2261,12 +2280,12 @@ sections:
title: Schema Design
type: code
language: sql
template: "{{database_schema}}"
template: '{{database_schema}}'
- id: data-access-layer
title: Data Access Layer
type: code
language: typescript
template: "{{repository_pattern}}"
template: '{{repository_pattern}}'
- id: auth-architecture
title: Authentication and Authorization
instruction: Define auth implementation details.
@@ -2275,12 +2294,12 @@ sections:
title: Auth Flow
type: mermaid
mermaid_type: sequence
template: "{{auth_flow_diagram}}"
template: '{{auth_flow_diagram}}'
- id: auth-middleware
title: Middleware/Guards
type: code
language: typescript
template: "{{auth_middleware}}"
template: '{{auth_middleware}}'
- id: unified-project-structure
title: Unified Project Structure
@@ -2356,12 +2375,12 @@ sections:
title: Prerequisites
type: code
language: bash
template: "{{prerequisites_commands}}"
template: '{{prerequisites_commands}}'
- id: initial-setup
title: Initial Setup
type: code
language: bash
template: "{{setup_commands}}"
template: '{{setup_commands}}'
- id: dev-commands
title: Development Commands
type: code
@@ -2417,15 +2436,15 @@ sections:
title: CI/CD Pipeline
type: code
language: yaml
template: "{{cicd_pipeline_config}}"
template: '{{cicd_pipeline_config}}'
- id: environments
title: Environments
type: table
columns: [Environment, Frontend URL, Backend URL, Purpose]
rows:
- ["Development", "{{dev_fe_url}}", "{{dev_be_url}}", "Local development"]
- ["Staging", "{{staging_fe_url}}", "{{staging_be_url}}", "Pre-production testing"]
- ["Production", "{{prod_fe_url}}", "{{prod_be_url}}", "Live environment"]
- ['Development', '{{dev_fe_url}}', '{{dev_be_url}}', 'Local development']
- ['Staging', '{{staging_fe_url}}', '{{staging_be_url}}', 'Pre-production testing']
- ['Production', '{{prod_fe_url}}', '{{prod_be_url}}', 'Live environment']
- id: security-performance
title: Security and Performance
@@ -2484,17 +2503,17 @@ sections:
title: Frontend Tests
type: code
language: text
template: "{{frontend_test_structure}}"
template: '{{frontend_test_structure}}'
- id: backend-tests
title: Backend Tests
type: code
language: text
template: "{{backend_test_structure}}"
template: '{{backend_test_structure}}'
- id: e2e-tests
title: E2E Tests
type: code
language: text
template: "{{e2e_test_structure}}"
template: '{{e2e_test_structure}}'
- id: test-examples
title: Test Examples
sections:
@@ -2502,17 +2521,17 @@ sections:
title: Frontend Component Test
type: code
language: typescript
template: "{{frontend_test_example}}"
template: '{{frontend_test_example}}'
- id: backend-test
title: Backend API Test
type: code
language: typescript
template: "{{backend_test_example}}"
template: '{{backend_test_example}}'
- id: e2e-test
title: E2E Test
type: code
language: typescript
template: "{{e2e_test_example}}"
template: '{{e2e_test_example}}'
- id: coding-standards
title: Coding Standards
@@ -2522,22 +2541,22 @@ sections:
- id: critical-rules
title: Critical Fullstack Rules
repeatable: true
template: "- **{{rule_name}}:** {{rule_description}}"
template: '- **{{rule_name}}:** {{rule_description}}'
examples:
- "**Type Sharing:** Always define types in packages/shared and import from there"
- "**API Calls:** Never make direct HTTP calls - use the service layer"
- "**Environment Variables:** Access only through config objects, never process.env directly"
- "**Error Handling:** All API routes must use the standard error handler"
- "**State Updates:** Never mutate state directly - use proper state management patterns"
- '**Type Sharing:** Always define types in packages/shared and import from there'
- '**API Calls:** Never make direct HTTP calls - use the service layer'
- '**Environment Variables:** Access only through config objects, never process.env directly'
- '**Error Handling:** All API routes must use the standard error handler'
- '**State Updates:** Never mutate state directly - use proper state management patterns'
- id: naming-conventions
title: Naming Conventions
type: table
columns: [Element, Frontend, Backend, Example]
rows:
- ["Components", "PascalCase", "-", "`UserProfile.tsx`"]
- ["Hooks", "camelCase with 'use'", "-", "`useAuth.ts`"]
- ["API Routes", "-", "kebab-case", "`/api/user-profile`"]
- ["Database Tables", "-", "snake_case", "`user_profiles`"]
- ['Components', 'PascalCase', '-', '`UserProfile.tsx`']
- ['Hooks', "camelCase with 'use'", '-', '`useAuth.ts`']
- ['API Routes', '-', 'kebab-case', '`/api/user-profile`']
- ['Database Tables', '-', 'snake_case', '`user_profiles`']
- id: error-handling
title: Error Handling Strategy
@@ -2548,7 +2567,7 @@ sections:
title: Error Flow
type: mermaid
mermaid_type: sequence
template: "{{error_flow_diagram}}"
template: '{{error_flow_diagram}}'
- id: error-format
title: Error Response Format
type: code
@@ -2567,12 +2586,12 @@ sections:
title: Frontend Error Handling
type: code
language: typescript
template: "{{frontend_error_handler}}"
template: '{{frontend_error_handler}}'
- id: backend-error-handling
title: Backend Error Handling
type: code
language: typescript
template: "{{backend_error_handler}}"
template: '{{backend_error_handler}}'
- id: monitoring
title: Monitoring and Observability
@@ -2614,7 +2633,7 @@ template:
output:
format: markdown
filename: docs/architecture.md
title: "{{project_name}} Brownfield Enhancement Architecture"
title: '{{project_name}} Brownfield Enhancement Architecture'
workflow:
mode: interactive
@@ -2672,11 +2691,11 @@ sections:
- id: available-docs
title: Available Documentation
type: bullet-list
template: "- {{existing_docs_summary}}"
template: '- {{existing_docs_summary}}'
- id: constraints
title: Identified Constraints
type: bullet-list
template: "- {{constraint}}"
template: '- {{constraint}}'
- id: changelog
title: Change Log
type: table
@@ -2756,7 +2775,7 @@ sections:
repeatable: true
sections:
- id: model
title: "{{model_name}}"
title: '{{model_name}}'
template: |
**Purpose:** {{model_purpose}}
**Integration:** {{integration_with_existing}}
@@ -2799,7 +2818,7 @@ sections:
repeatable: true
sections:
- id: component
title: "{{component_name}}"
title: '{{component_name}}'
template: |
**Responsibility:** {{component_description}}
**Integration Points:** {{integration_points}}
@@ -2842,7 +2861,7 @@ sections:
repeatable: true
sections:
- id: endpoint
title: "{{endpoint_name}}"
title: '{{endpoint_name}}'
template: |
- **Method:** {{http_method}}
- **Endpoint:** {{endpoint_path}}
@@ -2853,12 +2872,12 @@ sections:
title: Request
type: code
language: json
template: "{{request_schema}}"
template: '{{request_schema}}'
- id: response
title: Response
type: code
language: json
template: "{{response_schema}}"
template: '{{response_schema}}'
- id: external-api-integration
title: External API Integration
@@ -2867,7 +2886,7 @@ sections:
repeatable: true
sections:
- id: external-api
title: "{{api_name}} API"
title: '{{api_name}} API'
template: |
- **Purpose:** {{api_purpose}}
- **Documentation:** {{api_docs_url}}
@@ -2896,7 +2915,7 @@ sections:
type: code
language: plaintext
instruction: Document relevant parts of current structure
template: "{{existing_structure_relevant_parts}}"
template: '{{existing_structure_relevant_parts}}'
- id: new-file-organization
title: New File Organization
type: code
@@ -2971,7 +2990,7 @@ sections:
title: Enhancement-Specific Standards
condition: New patterns needed for enhancement
repeatable: true
template: "- **{{standard_name}}:** {{standard_description}}"
template: '- **{{standard_name}}:** {{standard_description}}'
- id: integration-rules
title: Critical Integration Rules
template: |
@@ -3491,33 +3510,28 @@ Ask the user if they want to work through the checklist:
Now that you've completed the checklist, generate a comprehensive validation report that includes:
1. Executive Summary
- Overall architecture readiness (High/Medium/Low)
- Critical risks identified
- Key strengths of the architecture
- Project type (Full-stack/Frontend/Backend) and sections evaluated
2. Section Analysis
- Pass rate for each major section (percentage of items passed)
- Most concerning failures or gaps
- Sections requiring immediate attention
- Note any sections skipped due to project type
3. Risk Assessment
- Top 5 risks by severity
- Mitigation recommendations for each
- Timeline impact of addressing issues
4. Recommendations
- Must-fix items before development
- Should-fix items for better quality
- Nice-to-have improvements
5. AI Implementation Readiness
- Specific concerns for AI agent implementation
- Areas needing additional clarification
- Complexity hotspots to address

File diff suppressed because it is too large Load Diff

View File

@@ -405,7 +405,7 @@ Provide a user-friendly interface to the BMad knowledge base without overwhelmin
## Instructions
When entering KB mode (*kb-mode), follow these steps:
When entering KB mode (\*kb-mode), follow these steps:
### 1. Welcome and Guide
@@ -447,12 +447,12 @@ Or ask me about anything else related to BMad-Method!
When user is done or wants to exit KB mode:
- Summarize key points discussed if helpful
- Remind them they can return to KB mode anytime with *kb-mode
- Remind them they can return to KB mode anytime with \*kb-mode
- Suggest next steps based on what was discussed
## Example Interaction
**User**: *kb-mode
**User**: \*kb-mode
**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.
@@ -775,7 +775,7 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
- **Claude Code**: `/agent-name` (e.g., `/bmad-master`)
- **Cursor**: `@agent-name` (e.g., `@bmad-master`)
- **Windsurf**: `@agent-name` (e.g., `@bmad-master`)
- **Windsurf**: `/agent-name` (e.g., `/bmad-master`)
- **Trae**: `@agent-name` (e.g., `@bmad-master`)
- **Roo Code**: Select mode from mode selector (e.g., `bmad-master`)
- **GitHub Copilot**: Open the Chat view (`⌃⌘I` on Mac, `Ctrl+Alt+I` on Windows/Linux) and select **Agent** from the chat mode selector.
@@ -1128,8 +1128,11 @@ Templates with Level 2 headings (`##`) can be automatically sharded:
```markdown
## Goals and Background Context
## Requirements
## User Interface Design Goals
## Success Metrics
```
@@ -1286,16 +1289,19 @@ Use the **expansion-creator** pack to build your own:
## Core Reflective Methods
**Expand or Contract for Audience**
- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
- Identify specific target audience if relevant
- Tailor content complexity and depth accordingly
**Explain Reasoning (CoT Step-by-Step)**
- Walk through the step-by-step thinking process
- Reveal underlying assumptions and decision points
- Show how conclusions were reached from current role's perspective
**Critique and Refine**
- Review output for flaws, inconsistencies, or improvement areas
- Identify specific weaknesses from role's expertise
- Suggest refined version reflecting domain knowledge
@@ -1303,12 +1309,14 @@ Use the **expansion-creator** pack to build your own:
## Structural Analysis Methods
**Analyze Logical Flow and Dependencies**
- Examine content structure for logical progression
- Check internal consistency and coherence
- Identify and validate dependencies between elements
- Confirm effective ordering and sequencing
**Assess Alignment with Overall Goals**
- Evaluate content contribution to stated objectives
- Identify any misalignments or gaps
- Interpret alignment from specific role's perspective
@@ -1317,12 +1325,14 @@ Use the **expansion-creator** pack to build your own:
## Risk and Challenge Methods
**Identify Potential Risks and Unforeseen Issues**
- Brainstorm potential risks from role's expertise
- Identify overlooked edge cases or scenarios
- Anticipate unintended consequences
- Highlight implementation challenges
**Challenge from Critical Perspective**
- Adopt critical stance on current content
- Play devil's advocate from specified viewpoint
- Argue against proposal highlighting weaknesses
@@ -1331,12 +1341,14 @@ Use the **expansion-creator** pack to build your own:
## Creative Exploration Methods
**Tree of Thoughts Deep Dive**
- Break problem into discrete "thoughts" or intermediate steps
- Explore multiple reasoning paths simultaneously
- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
- Apply search algorithms (BFS/DFS) to find optimal solution paths
**Hindsight is 20/20: The 'If Only...' Reflection**
- Imagine retrospective scenario based on current content
- Identify the one "if only we had known/done X..." insight
- Describe imagined consequences humorously or dramatically
@@ -1345,6 +1357,7 @@ Use the **expansion-creator** pack to build your own:
## Multi-Persona Collaboration Methods
**Agile Team Perspective Shift**
- Rotate through different Scrum team member viewpoints
- Product Owner: Focus on user value and business impact
- Scrum Master: Examine process flow and team dynamics
@@ -1352,12 +1365,14 @@ Use the **expansion-creator** pack to build your own:
- QA: Identify testing scenarios and quality concerns
**Stakeholder Round Table**
- Convene virtual meeting with multiple personas
- Each persona contributes unique perspective on content
- Identify conflicts and synergies between viewpoints
- Synthesize insights into actionable recommendations
**Meta-Prompting Analysis**
- Step back to analyze the structure and logic of current approach
- Question the format and methodology being used
- Suggest alternative frameworks or mental models
@@ -1366,24 +1381,28 @@ Use the **expansion-creator** pack to build your own:
## Advanced 2025 Techniques
**Self-Consistency Validation**
- Generate multiple reasoning paths for same problem
- Compare consistency across different approaches
- Identify most reliable and robust solution
- Highlight areas where approaches diverge and why
**ReWOO (Reasoning Without Observation)**
- Separate parametric reasoning from tool-based actions
- Create reasoning plan without external dependencies
- Identify what can be solved through pure reasoning
- Optimize for efficiency and reduced token usage
**Persona-Pattern Hybrid**
- Combine specific role expertise with elicitation pattern
- Architect + Risk Analysis: Deep technical risk assessment
- UX Expert + User Journey: End-to-end experience critique
- PM + Stakeholder Analysis: Multi-perspective impact review
**Emergent Collaboration Discovery**
- Allow multiple perspectives to naturally emerge
- Identify unexpected insights from persona interactions
- Explore novel combinations of viewpoints
@@ -1392,18 +1411,21 @@ Use the **expansion-creator** pack to build your own:
## Game-Based Elicitation Methods
**Red Team vs Blue Team**
- Red Team: Attack the proposal, find vulnerabilities
- Blue Team: Defend and strengthen the approach
- Competitive analysis reveals blind spots
- Results in more robust, battle-tested solutions
**Innovation Tournament**
- Pit multiple alternative approaches against each other
- Score each approach across different criteria
- Crowd-source evaluation from different personas
- Identify winning combination of features
**Escape Room Challenge**
- Present content as constraints to work within
- Find creative solutions within tight limitations
- Identify minimum viable approach
@@ -1412,6 +1434,7 @@ Use the **expansion-creator** pack to build your own:
## Process Control
**Proceed / No Further Actions**
- Acknowledge choice to finalize current work
- Accept output as-is or move to next step
- Prepare to continue without additional elicitation

26
dist/agents/dev.txt vendored
View File

@@ -72,15 +72,15 @@ commands:
- run-tests: Execute linting and tests
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
develop-story:
order-of-execution: Read (first or next) task→Implement Task and its subtasks→Write tests→Execute validations→Only if ALL pass, then update the task checkbox with [x]→Update story section File List to ensure it lists and new or modified or deleted source file→repeat order-of-execution until complete
story-file-updates-ONLY:
- develop-story:
- order-of-execution: Read (first or next) task→Implement Task and its subtasks→Write tests→Execute validations→Only if ALL pass, then update the task checkbox with [x]→Update story section File List to ensure it lists and new or modified or deleted source file→repeat order-of-execution until complete
- story-file-updates-ONLY:
- CRITICAL: ONLY UPDATE THE STORY FILE WITH UPDATES TO SECTIONS INDICATED BELOW. DO NOT MODIFY ANY OTHER SECTIONS.
- CRITICAL: You are ONLY authorized to edit these specific sections of story files - Tasks / Subtasks Checkboxes, Dev Agent Record section and all its subsections, Agent Model Used, Debug Log References, Completion Notes List, File List, Change Log, Status
- CRITICAL: DO NOT modify Status, Story, Acceptance Criteria, Dev Notes, Testing sections, or any other sections not listed above
blocking: 'HALT for: Unapproved deps needed, confirm with user | Ambiguous after story check | 3 failures attempting to implement or fix something repeatedly | Missing config | Failing regression'
ready-for-review: Code matches requirements + All validations pass + Follows standards + File List complete
completion: 'All Tasks and Subtasks marked [x] and have tests→Validations and full regression passes (DON''T BE LAZY, EXECUTE ALL TESTS and CONFIRM)→Ensure File List is Complete→run the task execute-checklist for the checklist story-dod-checklist→set story status: ''Ready for Review''→HALT'
- blocking: 'HALT for: Unapproved deps needed, confirm with user | Ambiguous after story check | 3 failures attempting to implement or fix something repeatedly | Missing config | Failing regression'
- ready-for-review: Code matches requirements + All validations pass + Follows standards + File List complete
- completion: 'All Tasks and Subtasks marked [x] and have tests→Validations and full regression passes (DON''T BE LAZY, EXECUTE ALL TESTS and CONFIRM)→Ensure File List is Complete→run the task execute-checklist for the checklist story-dod-checklist→set story status: ''Ready for Review''→HALT'
dependencies:
tasks:
- execute-checklist.md
@@ -102,7 +102,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -115,14 +114,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -131,7 +128,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -139,7 +135,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -153,7 +148,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -163,7 +157,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
@@ -351,14 +344,12 @@ The goal is quality delivery, not just checking boxes.]]
1. **Requirements Met:**
[[LLM: Be specific - list each requirement and whether it's complete]]
- [ ] All functional requirements specified in the story are implemented.
- [ ] All acceptance criteria defined in the story are met.
2. **Coding Standards & Project Structure:**
[[LLM: Code quality matters for maintainability. Check each item carefully]]
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
- [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
- [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
@@ -370,7 +361,6 @@ The goal is quality delivery, not just checking boxes.]]
3. **Testing:**
[[LLM: Testing proves your code works. Be honest about test coverage]]
- [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
- [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
- [ ] All tests (unit, integration, E2E if applicable) pass successfully.
@@ -379,14 +369,12 @@ The goal is quality delivery, not just checking boxes.]]
4. **Functionality & Verification:**
[[LLM: Did you actually run and test your code? Be specific about what you tested]]
- [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
- [ ] Edge cases and potential error conditions considered and handled gracefully.
5. **Story Administration:**
[[LLM: Documentation helps the next developer. What should they know?]]
- [ ] All tasks within the story file are marked as complete.
- [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
- [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
@@ -394,7 +382,6 @@ The goal is quality delivery, not just checking boxes.]]
6. **Dependencies, Build & Configuration:**
[[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
- [ ] Project builds successfully without errors.
- [ ] Project linting passes
- [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
@@ -405,7 +392,6 @@ The goal is quality delivery, not just checking boxes.]]
7. **Documentation (If Applicable):**
[[LLM: Good documentation prevents future confusion. What needs explaining?]]
- [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
- [ ] User-facing documentation updated, if changes impact users.
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.

116
dist/agents/pm.txt vendored
View File

@@ -72,9 +72,16 @@ persona:
- Strategic thinking & outcome-oriented
commands:
- help: Show numbered list of the following commands to allow selection
- create-doc {template}: execute task create-doc for template provided, if no template then ONLY list dependencies.templates
- yolo: Toggle Yolo Mode
- create-prd: run task create-doc.md with template prd-tmpl.yaml
- create-brownfield-prd: run task create-doc.md with template brownfield-prd-tmpl.yaml
- create-brownfield-epic: run task brownfield-create-epic.md
- create-brownfield-story: run task brownfield-create-story.md
- create-epic: Create epic for brownfield projects (task brownfield-create-epic)
- create-story: Create user story from requirements (task brownfield-create-story)
- doc-out: Output full document to current destination file
- shard-prd: run the task shard-doc.md for the provided prd.md (ask if not found)
- correct-course: execute the correct-course task
- yolo: Toggle Yolo Mode
- exit: Exit (confirm)
dependencies:
tasks:
@@ -297,63 +304,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
Present these numbered options to the user:
1. **Product Validation Research**
- Validate product hypotheses and market fit
- Test assumptions about user needs and solutions
- Assess technical and business feasibility
- Identify risks and mitigation strategies
2. **Market Opportunity Research**
- Analyze market size and growth potential
- Identify market segments and dynamics
- Assess market entry strategies
- Evaluate timing and market readiness
3. **User & Customer Research**
- Deep dive into user personas and behaviors
- Understand jobs-to-be-done and pain points
- Map customer journeys and touchpoints
- Analyze willingness to pay and value perception
4. **Competitive Intelligence Research**
- Detailed competitor analysis and positioning
- Feature and capability comparisons
- Business model and strategy analysis
- Identify competitive advantages and gaps
5. **Technology & Innovation Research**
- Assess technology trends and possibilities
- Evaluate technical approaches and architectures
- Identify emerging technologies and disruptions
- Analyze build vs. buy vs. partner options
6. **Industry & Ecosystem Research**
- Map industry value chains and dynamics
- Identify key players and relationships
- Analyze regulatory and compliance factors
- Understand partnership opportunities
7. **Strategic Options Research**
- Evaluate different strategic directions
- Assess business model alternatives
- Analyze go-to-market strategies
- Consider expansion and scaling paths
8. **Risk & Feasibility Research**
- Identify and assess various risk factors
- Evaluate implementation challenges
- Analyze resource requirements
- Consider regulatory and legal implications
9. **Custom Research Focus**
- User-defined research objectives
- Specialized domain investigation
- Cross-functional research needs
@@ -522,13 +520,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
### 5. Review and Refinement
1. **Present Complete Prompt**
- Show the full research prompt
- Explain key elements and rationale
- Highlight any assumptions made
2. **Gather Feedback**
- Are the objectives clear and correct?
- Do the questions address all concerns?
- Is the scope appropriate?
@@ -890,7 +886,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -903,14 +898,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -919,7 +912,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -927,7 +919,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -941,7 +932,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -951,7 +941,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
@@ -1068,13 +1057,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
For each extracted section:
1. **Generate filename**: Convert the section heading to lowercase-dash-case
- Remove special characters
- Replace spaces with dashes
- Example: "## Tech Stack" → `tech-stack.md`
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:
@@ -1172,7 +1159,7 @@ template:
output:
format: markdown
filename: docs/prd.md
title: "{{project_name}} Product Requirements Document (PRD)"
title: '{{project_name}} Product Requirements Document (PRD)'
workflow:
mode: interactive
@@ -1209,14 +1196,14 @@ sections:
prefix: FR
instruction: Each Requirement will be a bullet markdown and an identifier sequence starting with FR
examples:
- "FR6: The Todo List uses AI to detect and warn against potentially duplicate todo items that are worded differently."
- 'FR6: The Todo List uses AI to detect and warn against potentially duplicate todo items that are worded differently.'
- id: non-functional
title: Non Functional
type: numbered-list
prefix: NFR
instruction: Each Requirement will be a bullet markdown and an identifier sequence starting with NFR
examples:
- "NFR1: AWS service usage must aim to stay within free-tier limits where feasible."
- 'NFR1: AWS service usage must aim to stay within free-tier limits where feasible.'
- id: ui-goals
title: User Interface Design Goals
@@ -1242,24 +1229,24 @@ sections:
title: Core Screens and Views
instruction: From a product perspective, what are the most critical screens or views necessary to deliver the the PRD values and goals? This is meant to be Conceptual High Level to Drive Rough Epic or User Stories
examples:
- "Login Screen"
- "Main Dashboard"
- "Item Detail Page"
- "Settings Page"
- 'Login Screen'
- 'Main Dashboard'
- 'Item Detail Page'
- 'Settings Page'
- id: accessibility
title: "Accessibility: {None|WCAG AA|WCAG AAA|Custom Requirements}"
title: 'Accessibility: {None|WCAG AA|WCAG AAA|Custom Requirements}'
- id: branding
title: Branding
instruction: Any known branding elements or style guides that must be incorporated?
examples:
- "Replicate the look and feel of early 1900s black and white cinema, including animated effects replicating film damage or projector glitches during page or state transitions."
- "Attached is the full color pallet and tokens for our corporate branding."
- 'Replicate the look and feel of early 1900s black and white cinema, including animated effects replicating film damage or projector glitches during page or state transitions.'
- 'Attached is the full color pallet and tokens for our corporate branding.'
- id: target-platforms
title: "Target Device and Platforms: {Web Responsive|Mobile Only|Desktop Only|Cross-Platform}"
title: 'Target Device and Platforms: {Web Responsive|Mobile Only|Desktop Only|Cross-Platform}'
examples:
- "Web Responsive, and all mobile platforms"
- "iPhone Only"
- "ASCII Windows Desktop"
- 'Web Responsive, and all mobile platforms'
- 'iPhone Only'
- 'ASCII Windows Desktop'
- id: technical-assumptions
title: Technical Assumptions
@@ -1278,13 +1265,13 @@ sections:
testing: [Unit Only, Unit + Integration, Full Testing Pyramid]
sections:
- id: repository-structure
title: "Repository Structure: {Monorepo|Polyrepo|Multi-repo}"
title: 'Repository Structure: {Monorepo|Polyrepo|Multi-repo}'
- id: service-architecture
title: Service Architecture
instruction: "CRITICAL DECISION - Document the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo)."
instruction: 'CRITICAL DECISION - Document the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo).'
- id: testing-requirements
title: Testing Requirements
instruction: "CRITICAL DECISION - Document the testing requirements, unit only, integration, e2e, manual, need for manual testing convenience methods)."
instruction: 'CRITICAL DECISION - Document the testing requirements, unit only, integration, e2e, manual, need for manual testing convenience methods).'
- id: additional-assumptions
title: Additional Technical Assumptions and Requests
instruction: Throughout the entire process of drafting this document, if any other technical assumptions are raised or discovered appropriate for the architect, add them here as additional bulleted items
@@ -1304,10 +1291,10 @@ sections:
- Cross Cutting Concerns should flow through epics and stories and not be final stories. For example, adding a logging framework as a last story of an epic, or at the end of a project as a final epic or story would be terrible as we would not have logging from the beginning.
elicit: true
examples:
- "Epic 1: Foundation & Core Infrastructure: Establish project setup, authentication, and basic user management"
- "Epic 2: Core Business Entities: Create and manage primary domain objects with CRUD operations"
- "Epic 3: User Workflows & Interactions: Enable key user journeys and business processes"
- "Epic 4: Reporting & Analytics: Provide insights and data visualization for users"
- 'Epic 1: Foundation & Core Infrastructure: Establish project setup, authentication, and basic user management'
- 'Epic 2: Core Business Entities: Create and manage primary domain objects with CRUD operations'
- 'Epic 3: User Workflows & Interactions: Enable key user journeys and business processes'
- 'Epic 4: Reporting & Analytics: Provide insights and data visualization for users'
- id: epic-details
title: Epic {{epic_number}} {{epic_title}}
@@ -1329,7 +1316,7 @@ sections:
- Think "junior developer working for 2-4 hours" - stories must be small, focused, and self-contained
- If a story seems complex, break it down further as long as it can deliver a vertical slice
elicit: true
template: "{{epic_goal}}"
template: '{{epic_goal}}'
sections:
- id: story
title: Story {{epic_number}}.{{story_number}} {{story_title}}
@@ -1342,7 +1329,7 @@ sections:
- id: acceptance-criteria
title: Acceptance Criteria
type: numbered-list
item_template: "{{criterion_number}}: {{criteria}}"
item_template: '{{criterion_number}}: {{criteria}}'
repeatable: true
instruction: |
Define clear, comprehensive, and testable acceptance criteria that:
@@ -1377,7 +1364,7 @@ template:
output:
format: markdown
filename: docs/prd.md
title: "{{project_name}} Brownfield Enhancement PRD"
title: '{{project_name}} Brownfield Enhancement PRD'
workflow:
mode: interactive
@@ -1440,7 +1427,7 @@ sections:
- External API Documentation [[LLM: If from document-project, check ✓]]
- UX/UI Guidelines [[LLM: May not be in document-project]]
- Technical Debt Documentation [[LLM: If from document-project, check ✓]]
- "Other: {{other_docs}}"
- 'Other: {{other_docs}}'
instruction: |
- If document-project was already run: "Using existing project analysis from document-project output."
- If critical documentation is missing and no document-project: "I recommend running the document-project task first..."
@@ -1460,7 +1447,7 @@ sections:
- UI/UX Overhaul
- Technology Stack Upgrade
- Bug Fix and Stability Improvements
- "Other: {{other_type}}"
- 'Other: {{other_type}}'
- id: enhancement-description
title: Enhancement Description
instruction: 2-3 sentences describing what the user wants to add or change
@@ -1501,29 +1488,29 @@ sections:
prefix: FR
instruction: Each Requirement will be a bullet markdown with identifier starting with FR
examples:
- "FR1: The existing Todo List will integrate with the new AI duplicate detection service without breaking current functionality."
- 'FR1: The existing Todo List will integrate with the new AI duplicate detection service without breaking current functionality.'
- id: non-functional
title: Non Functional
type: numbered-list
prefix: NFR
instruction: Each Requirement will be a bullet markdown with identifier starting with NFR. Include constraints from existing system
examples:
- "NFR1: Enhancement must maintain existing performance characteristics and not exceed current memory usage by more than 20%."
- 'NFR1: Enhancement must maintain existing performance characteristics and not exceed current memory usage by more than 20%.'
- id: compatibility
title: Compatibility Requirements
instruction: Critical for brownfield - what must remain compatible
type: numbered-list
prefix: CR
template: "{{requirement}}: {{description}}"
template: '{{requirement}}: {{description}}'
items:
- id: cr1
template: "CR1: {{existing_api_compatibility}}"
template: 'CR1: {{existing_api_compatibility}}'
- id: cr2
template: "CR2: {{database_schema_compatibility}}"
template: 'CR2: {{database_schema_compatibility}}'
- id: cr3
template: "CR3: {{ui_ux_consistency}}"
template: 'CR3: {{ui_ux_consistency}}'
- id: cr4
template: "CR4: {{integration_compatibility}}"
template: 'CR4: {{integration_compatibility}}'
- id: ui-enhancement-goals
title: User Interface Enhancement Goals
@@ -1606,10 +1593,10 @@ sections:
- id: epic-approach
title: Epic Approach
instruction: Explain the rationale for epic structure - typically single epic for brownfield unless multiple unrelated features
template: "**Epic Structure Decision**: {{epic_decision}} with rationale"
template: '**Epic Structure Decision**: {{epic_decision}} with rationale'
- id: epic-details
title: "Epic 1: {{enhancement_title}}"
title: 'Epic 1: {{enhancement_title}}'
instruction: |
Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
@@ -1629,7 +1616,7 @@ sections:
**Integration Requirements**: {{integration_requirements}}
sections:
- id: story
title: "Story 1.{{story_number}} {{story_title}}"
title: 'Story 1.{{story_number}} {{story_title}}'
repeatable: true
template: |
As a {{user_type}},
@@ -1640,16 +1627,16 @@ sections:
title: Acceptance Criteria
type: numbered-list
instruction: Define criteria that include both new functionality and existing system integrity
item_template: "{{criterion_number}}: {{criteria}}"
item_template: '{{criterion_number}}: {{criteria}}'
- id: integration-verification
title: Integration Verification
instruction: Specific verification steps to ensure existing functionality remains intact
type: numbered-list
prefix: IV
items:
- template: "IV1: {{existing_functionality_verification}}"
- template: "IV2: {{integration_point_verification}}"
- template: "IV3: {{performance_impact_verification}}"
- template: 'IV1: {{existing_functionality_verification}}'
- template: 'IV2: {{integration_point_verification}}'
- template: 'IV3: {{performance_impact_verification}}'
==================== END: .bmad-core/templates/brownfield-prd-tmpl.yaml ====================
==================== START: .bmad-core/checklists/pm-checklist.md ====================
@@ -1959,7 +1946,6 @@ Ask the user if they want to work through the checklist:
Create a comprehensive validation report that includes:
1. Executive Summary
- Overall PRD completeness (percentage)
- MVP scope appropriateness (Too Large/Just Right/Too Small)
- Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
@@ -1967,26 +1953,22 @@ Create a comprehensive validation report that includes:
2. Category Analysis Table
Fill in the actual table with:
- Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
- Critical Issues: Specific problems that block progress
3. Top Issues by Priority
- BLOCKERS: Must fix before architect can proceed
- HIGH: Should fix for quality
- MEDIUM: Would improve clarity
- LOW: Nice to have
4. MVP Scope Assessment
- Features that might be cut for true MVP
- Missing features that are essential
- Complexity concerns
- Timeline realism
5. Technical Readiness
- Clarity of technical constraints
- Identified technical risks
- Areas needing architect investigation

342
dist/agents/po.txt vendored
View File

@@ -75,23 +75,20 @@ persona:
- Documentation Ecosystem Integrity - Maintain consistency across all documents
commands:
- help: Show numbered list of the following commands to allow selection
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
- execute-checklist {checklist}: Run task execute-checklist (default->po-master-checklist)
- execute-checklist-po: Run task execute-checklist (checklist po-master-checklist)
- shard-doc {document} {destination}: run the task shard-doc against the optionally provided document to the specified destination
- correct-course: execute the correct-course task
- create-epic: Create epic for brownfield projects (task brownfield-create-epic)
- create-story: Create user story from requirements (task brownfield-create-story)
- yolo: Toggle Yolo Mode off on - on will skip doc section confirmations
- doc-out: Output full document to current destination file
- validate-story-draft {story}: run the task validate-next-story against the provided story file
- yolo: Toggle Yolo Mode off on - on will skip doc section confirmations
- exit: Exit (confirm)
dependencies:
tasks:
- execute-checklist.md
- shard-doc.md
- correct-course.md
- brownfield-create-epic.md
- brownfield-create-story.md
- validate-next-story.md
templates:
- story-tmpl.yaml
@@ -113,7 +110,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -126,14 +122,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -142,7 +136,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -150,7 +143,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -164,7 +156,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -174,7 +165,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
@@ -291,13 +281,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
For each extracted section:
1. **Generate filename**: Convert the section heading to lowercase-dash-case
- Remove special characters
- Replace spaces with dashes
- Example: "## Tech Stack" → `tech-stack.md`
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:
@@ -460,319 +448,6 @@ Document sharded successfully:
- **Implicit:** An annotated change-checklist (or the record of its completion) reflecting the discussions, findings, and decisions made during the process.
==================== END: .bmad-core/tasks/correct-course.md ====================
==================== START: .bmad-core/tasks/brownfield-create-epic.md ====================
# Create Brownfield Epic Task
## Purpose
Create a single epic for smaller brownfield enhancements that don't require the full PRD and Architecture documentation process. This task is for isolated features or modifications that can be completed within a focused scope.
## When to Use This Task
**Use this task when:**
- The enhancement can be completed in 1-3 stories
- No significant architectural changes are required
- The enhancement follows existing project patterns
- Integration complexity is minimal
- Risk to existing system is low
**Use the full brownfield PRD/Architecture process when:**
- The enhancement requires multiple coordinated stories
- Architectural planning is needed
- Significant integration work is required
- Risk assessment and mitigation planning is necessary
## Instructions
### 1. Project Analysis (Required)
Before creating the epic, gather essential information about the existing project:
**Existing Project Context:**
- [ ] Project purpose and current functionality understood
- [ ] Existing technology stack identified
- [ ] Current architecture patterns noted
- [ ] Integration points with existing system identified
**Enhancement Scope:**
- [ ] Enhancement clearly defined and scoped
- [ ] Impact on existing functionality assessed
- [ ] Required integration points identified
- [ ] Success criteria established
### 2. Epic Creation
Create a focused epic following this structure:
#### Epic Title
{{Enhancement Name}} - Brownfield Enhancement
#### Epic Goal
{{1-2 sentences describing what the epic will accomplish and why it adds value}}
#### Epic Description
**Existing System Context:**
- Current relevant functionality: {{brief description}}
- Technology stack: {{relevant existing technologies}}
- Integration points: {{where new work connects to existing system}}
**Enhancement Details:**
- What's being added/changed: {{clear description}}
- How it integrates: {{integration approach}}
- Success criteria: {{measurable outcomes}}
#### Stories
List 1-3 focused stories that complete the epic:
1. **Story 1:** {{Story title and brief description}}
2. **Story 2:** {{Story title and brief description}}
3. **Story 3:** {{Story title and brief description}}
#### Compatibility Requirements
- [ ] Existing APIs remain unchanged
- [ ] Database schema changes are backward compatible
- [ ] UI changes follow existing patterns
- [ ] Performance impact is minimal
#### Risk Mitigation
- **Primary Risk:** {{main risk to existing system}}
- **Mitigation:** {{how risk will be addressed}}
- **Rollback Plan:** {{how to undo changes if needed}}
#### Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Existing functionality verified through testing
- [ ] Integration points working correctly
- [ ] Documentation updated appropriately
- [ ] No regression in existing features
### 3. Validation Checklist
Before finalizing the epic, ensure:
**Scope Validation:**
- [ ] Epic can be completed in 1-3 stories maximum
- [ ] No architectural documentation is required
- [ ] Enhancement follows existing patterns
- [ ] Integration complexity is manageable
**Risk Assessment:**
- [ ] Risk to existing system is low
- [ ] Rollback plan is feasible
- [ ] Testing approach covers existing functionality
- [ ] Team has sufficient knowledge of integration points
**Completeness Check:**
- [ ] Epic goal is clear and achievable
- [ ] Stories are properly scoped
- [ ] Success criteria are measurable
- [ ] Dependencies are identified
### 4. Handoff to Story Manager
Once the epic is validated, provide this handoff to the Story Manager:
---
**Story Manager Handoff:**
"Please develop detailed user stories for this brownfield epic. Key considerations:
- This is an enhancement to an existing system running {{technology stack}}
- Integration points: {{list key integration points}}
- Existing patterns to follow: {{relevant existing patterns}}
- Critical compatibility requirements: {{key requirements}}
- Each story must include verification that existing functionality remains intact
The epic should maintain system integrity while delivering {{epic goal}}."
---
## Success Criteria
The epic creation is successful when:
1. Enhancement scope is clearly defined and appropriately sized
2. Integration approach respects existing system architecture
3. Risk to existing functionality is minimized
4. Stories are logically sequenced for safe implementation
5. Compatibility requirements are clearly specified
6. Rollback plan is feasible and documented
## Important Notes
- This task is specifically for SMALL brownfield enhancements
- If the scope grows beyond 3 stories, consider the full brownfield PRD process
- Always prioritize existing system integrity over new functionality
- When in doubt about scope or complexity, escalate to full brownfield planning
==================== END: .bmad-core/tasks/brownfield-create-epic.md ====================
==================== START: .bmad-core/tasks/brownfield-create-story.md ====================
# Create Brownfield Story Task
## Purpose
Create a single user story for very small brownfield enhancements that can be completed in one focused development session. This task is for minimal additions or bug fixes that require existing system integration awareness.
## When to Use This Task
**Use this task when:**
- The enhancement can be completed in a single story
- No new architecture or significant design is required
- The change follows existing patterns exactly
- Integration is straightforward with minimal risk
- Change is isolated with clear boundaries
**Use brownfield-create-epic when:**
- The enhancement requires 2-3 coordinated stories
- Some design work is needed
- Multiple integration points are involved
**Use the full brownfield PRD/Architecture process when:**
- The enhancement requires multiple coordinated stories
- Architectural planning is needed
- Significant integration work is required
## Instructions
### 1. Quick Project Assessment
Gather minimal but essential context about the existing project:
**Current System Context:**
- [ ] Relevant existing functionality identified
- [ ] Technology stack for this area noted
- [ ] Integration point(s) clearly understood
- [ ] Existing patterns for similar work identified
**Change Scope:**
- [ ] Specific change clearly defined
- [ ] Impact boundaries identified
- [ ] Success criteria established
### 2. Story Creation
Create a single focused story following this structure:
#### Story Title
{{Specific Enhancement}} - Brownfield Addition
#### User Story
As a {{user type}},
I want {{specific action/capability}},
So that {{clear benefit/value}}.
#### Story Context
**Existing System Integration:**
- Integrates with: {{existing component/system}}
- Technology: {{relevant tech stack}}
- Follows pattern: {{existing pattern to follow}}
- Touch points: {{specific integration points}}
#### Acceptance Criteria
**Functional Requirements:**
1. {{Primary functional requirement}}
2. {{Secondary functional requirement (if any)}}
3. {{Integration requirement}}
**Integration Requirements:** 4. Existing {{relevant functionality}} continues to work unchanged 5. New functionality follows existing {{pattern}} pattern 6. Integration with {{system/component}} maintains current behavior
**Quality Requirements:** 7. Change is covered by appropriate tests 8. Documentation is updated if needed 9. No regression in existing functionality verified
#### Technical Notes
- **Integration Approach:** {{how it connects to existing system}}
- **Existing Pattern Reference:** {{link or description of pattern to follow}}
- **Key Constraints:** {{any important limitations or requirements}}
#### Definition of Done
- [ ] Functional requirements met
- [ ] Integration requirements verified
- [ ] Existing functionality regression tested
- [ ] Code follows existing patterns and standards
- [ ] Tests pass (existing and new)
- [ ] Documentation updated if applicable
### 3. Risk and Compatibility Check
**Minimal Risk Assessment:**
- **Primary Risk:** {{main risk to existing system}}
- **Mitigation:** {{simple mitigation approach}}
- **Rollback:** {{how to undo if needed}}
**Compatibility Verification:**
- [ ] No breaking changes to existing APIs
- [ ] Database changes (if any) are additive only
- [ ] UI changes follow existing design patterns
- [ ] Performance impact is negligible
### 4. Validation Checklist
Before finalizing the story, confirm:
**Scope Validation:**
- [ ] Story can be completed in one development session
- [ ] Integration approach is straightforward
- [ ] Follows existing patterns exactly
- [ ] No design or architecture work required
**Clarity Check:**
- [ ] Story requirements are unambiguous
- [ ] Integration points are clearly specified
- [ ] Success criteria are testable
- [ ] Rollback approach is simple
## Success Criteria
The story creation is successful when:
1. Enhancement is clearly defined and appropriately scoped for single session
2. Integration approach is straightforward and low-risk
3. Existing system patterns are identified and will be followed
4. Rollback plan is simple and feasible
5. Acceptance criteria include existing functionality verification
## Important Notes
- This task is for VERY SMALL brownfield changes only
- If complexity grows during analysis, escalate to brownfield-create-epic
- Always prioritize existing system integrity
- When in doubt about integration complexity, use brownfield-create-epic instead
- Stories should take no more than 4 hours of focused development work
==================== END: .bmad-core/tasks/brownfield-create-story.md ====================
==================== START: .bmad-core/tasks/validate-next-story.md ====================
# Validate Next Story Task
@@ -918,7 +593,7 @@ template:
output:
format: markdown
filename: docs/stories/{{epic_num}}.{{story_num}}.{{story_title_short}}.md
title: "Story {{epic_num}}.{{story_num}}: {{story_title_short}}"
title: 'Story {{epic_num}}.{{story_num}}: {{story_title_short}}'
workflow:
mode: interactive
@@ -1020,7 +695,7 @@ sections:
sections:
- id: agent-model
title: Agent Model Used
template: "{{agent_model_name_version}}"
template: '{{agent_model_name_version}}'
instruction: Record the specific AI agent model and version used for development
owner: dev-agent
editors: [dev-agent]
@@ -1061,12 +736,10 @@ PROJECT TYPE DETECTION:
First, determine the project type by checking:
1. Is this a GREENFIELD project (new from scratch)?
- Look for: New project initialization, no existing codebase references
- Check for: prd.md, architecture.md, new project setup stories
2. Is this a BROWNFIELD project (enhancing existing system)?
- Look for: References to existing codebase, enhancement/modification language
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
@@ -1400,7 +1073,6 @@ Ask the user if they want to work through the checklist:
Generate a comprehensive validation report that adapts to project type:
1. Executive Summary
- Project type: [Greenfield/Brownfield] with [UI/No UI]
- Overall readiness (percentage)
- Go/No-Go recommendation
@@ -1410,42 +1082,36 @@ Generate a comprehensive validation report that adapts to project type:
2. Project-Specific Analysis
FOR GREENFIELD:
- Setup completeness
- Dependency sequencing
- MVP scope appropriateness
- Development timeline feasibility
FOR BROWNFIELD:
- Integration risk level (High/Medium/Low)
- Existing system impact assessment
- Rollback readiness
- User disruption potential
3. Risk Assessment
- Top 5 risks by severity
- Mitigation recommendations
- Timeline impact of addressing issues
- [BROWNFIELD] Specific integration risks
4. MVP Completeness
- Core features coverage
- Missing essential functionality
- Scope creep identified
- True MVP vs over-engineering
5. Implementation Readiness
- Developer clarity score (1-10)
- Ambiguous requirements count
- Missing technical details
- [BROWNFIELD] Integration point clarity
6. Recommendations
- Must-fix before development
- Should-fix for quality
- Consider for improvement

1746
dist/agents/qa.txt vendored

File diff suppressed because it is too large Load Diff

20
dist/agents/sm.txt vendored
View File

@@ -68,9 +68,9 @@ persona:
- You are NOT allowed to implement stories or modify code EVER!
commands:
- help: Show numbered list of the following commands to allow selection
- draft: Execute task create-next-story
- correct-course: Execute task correct-course
- checklist {checklist}: Show numbered list of checklists if not provided, execute task execute-checklist
- draft: Execute task create-next-story.md
- correct-course: Execute task correct-course.md
- story-checklist: Execute task execute-checklist.md with checklist story-draft-checklist.md
- exit: Say goodbye as the Scrum Master, and then abandon inhabiting this persona
dependencies:
tasks:
@@ -211,7 +211,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -224,14 +223,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -240,7 +237,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -248,7 +244,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -262,7 +257,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -272,7 +266,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
@@ -376,7 +369,7 @@ template:
output:
format: markdown
filename: docs/stories/{{epic_num}}.{{story_num}}.{{story_title_short}}.md
title: "Story {{epic_num}}.{{story_num}}: {{story_title_short}}"
title: 'Story {{epic_num}}.{{story_num}}: {{story_title_short}}'
workflow:
mode: interactive
@@ -478,7 +471,7 @@ sections:
sections:
- id: agent-model
title: Agent Model Used
template: "{{agent_model_name_version}}"
template: '{{agent_model_name_version}}'
instruction: Record the specific AI agent model and version used for development
owner: dev-agent
editors: [dev-agent]
@@ -628,19 +621,16 @@ Note: We don't need every file listed - just the important ones.]]
Generate a concise validation report:
1. Quick Summary
- Story readiness: READY / NEEDS REVISION / BLOCKED
- Clarity score (1-10)
- Major gaps identified
2. Fill in the validation table with:
- PASS: Requirements clearly met
- PARTIAL: Some gaps but workable
- FAIL: Critical information missing
3. Specific Issues (if any)
- List concrete problems to fix
- Suggest specific improvements
- Identify any blocking dependencies

View File

@@ -73,15 +73,12 @@ persona:
- You can craft effective prompts for AI UI generation tools like v0, or Lovable.
commands:
- help: Show numbered list of the following commands to allow selection
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
- generate-ui-prompt: Create AI frontend generation prompt
- research {topic}: Execute create-deep-research-prompt task to generate a prompt to init UX deep research
- execute-checklist {checklist}: Run task execute-checklist (default->po-master-checklist)
- create-front-end-spec: run task create-doc.md with template front-end-spec-tmpl.yaml
- generate-ui-prompt: Run task generate-ai-frontend-prompt.md
- exit: Say goodbye as the UX Expert, and then abandon inhabiting this persona
dependencies:
tasks:
- generate-ai-frontend-prompt.md
- create-deep-research-prompt.md
- create-doc.md
- execute-checklist.md
templates:
@@ -145,298 +142,6 @@ You will now synthesize the inputs and the above principles into a final, compre
- <important_note>Conclude by reminding the user that all AI-generated code will require careful human review, testing, and refinement to be considered production-ready.</important_note>
==================== END: .bmad-core/tasks/generate-ai-frontend-prompt.md ====================
==================== START: .bmad-core/tasks/create-deep-research-prompt.md ====================
# Create Deep Research Prompt Task
This task helps create comprehensive research prompts for various types of deep analysis. It can process inputs from brainstorming sessions, project briefs, market research, or specific research questions to generate targeted prompts for deeper investigation.
## Purpose
Generate well-structured research prompts that:
- Define clear research objectives and scope
- Specify appropriate research methodologies
- Outline expected deliverables and formats
- Guide systematic investigation of complex topics
- Ensure actionable insights are captured
## Research Type Selection
CRITICAL: First, help the user select the most appropriate research focus based on their needs and any input documents they've provided.
### 1. Research Focus Options
Present these numbered options to the user:
1. **Product Validation Research**
- Validate product hypotheses and market fit
- Test assumptions about user needs and solutions
- Assess technical and business feasibility
- Identify risks and mitigation strategies
2. **Market Opportunity Research**
- Analyze market size and growth potential
- Identify market segments and dynamics
- Assess market entry strategies
- Evaluate timing and market readiness
3. **User & Customer Research**
- Deep dive into user personas and behaviors
- Understand jobs-to-be-done and pain points
- Map customer journeys and touchpoints
- Analyze willingness to pay and value perception
4. **Competitive Intelligence Research**
- Detailed competitor analysis and positioning
- Feature and capability comparisons
- Business model and strategy analysis
- Identify competitive advantages and gaps
5. **Technology & Innovation Research**
- Assess technology trends and possibilities
- Evaluate technical approaches and architectures
- Identify emerging technologies and disruptions
- Analyze build vs. buy vs. partner options
6. **Industry & Ecosystem Research**
- Map industry value chains and dynamics
- Identify key players and relationships
- Analyze regulatory and compliance factors
- Understand partnership opportunities
7. **Strategic Options Research**
- Evaluate different strategic directions
- Assess business model alternatives
- Analyze go-to-market strategies
- Consider expansion and scaling paths
8. **Risk & Feasibility Research**
- Identify and assess various risk factors
- Evaluate implementation challenges
- Analyze resource requirements
- Consider regulatory and legal implications
9. **Custom Research Focus**
- User-defined research objectives
- Specialized domain investigation
- Cross-functional research needs
### 2. Input Processing
**If Project Brief provided:**
- Extract key product concepts and goals
- Identify target users and use cases
- Note technical constraints and preferences
- Highlight uncertainties and assumptions
**If Brainstorming Results provided:**
- Synthesize main ideas and themes
- Identify areas needing validation
- Extract hypotheses to test
- Note creative directions to explore
**If Market Research provided:**
- Build on identified opportunities
- Deepen specific market insights
- Validate initial findings
- Explore adjacent possibilities
**If Starting Fresh:**
- Gather essential context through questions
- Define the problem space
- Clarify research objectives
- Establish success criteria
## Process
### 3. Research Prompt Structure
CRITICAL: collaboratively develop a comprehensive research prompt with these components.
#### A. Research Objectives
CRITICAL: collaborate with the user to articulate clear, specific objectives for the research.
- Primary research goal and purpose
- Key decisions the research will inform
- Success criteria for the research
- Constraints and boundaries
#### B. Research Questions
CRITICAL: collaborate with the user to develop specific, actionable research questions organized by theme.
**Core Questions:**
- Central questions that must be answered
- Priority ranking of questions
- Dependencies between questions
**Supporting Questions:**
- Additional context-building questions
- Nice-to-have insights
- Future-looking considerations
#### C. Research Methodology
**Data Collection Methods:**
- Secondary research sources
- Primary research approaches (if applicable)
- Data quality requirements
- Source credibility criteria
**Analysis Frameworks:**
- Specific frameworks to apply
- Comparison criteria
- Evaluation methodologies
- Synthesis approaches
#### D. Output Requirements
**Format Specifications:**
- Executive summary requirements
- Detailed findings structure
- Visual/tabular presentations
- Supporting documentation
**Key Deliverables:**
- Must-have sections and insights
- Decision-support elements
- Action-oriented recommendations
- Risk and uncertainty documentation
### 4. Prompt Generation
**Research Prompt Template:**
```markdown
## Research Objective
[Clear statement of what this research aims to achieve]
## Background Context
[Relevant information from project brief, brainstorming, or other inputs]
## Research Questions
### Primary Questions (Must Answer)
1. [Specific, actionable question]
2. [Specific, actionable question]
...
### Secondary Questions (Nice to Have)
1. [Supporting question]
2. [Supporting question]
...
## Research Methodology
### Information Sources
- [Specific source types and priorities]
### Analysis Frameworks
- [Specific frameworks to apply]
### Data Requirements
- [Quality, recency, credibility needs]
## Expected Deliverables
### Executive Summary
- Key findings and insights
- Critical implications
- Recommended actions
### Detailed Analysis
[Specific sections needed based on research type]
### Supporting Materials
- Data tables
- Comparison matrices
- Source documentation
## Success Criteria
[How to evaluate if research achieved its objectives]
## Timeline and Priority
[If applicable, any time constraints or phasing]
```
### 5. Review and Refinement
1. **Present Complete Prompt**
- Show the full research prompt
- Explain key elements and rationale
- Highlight any assumptions made
2. **Gather Feedback**
- Are the objectives clear and correct?
- Do the questions address all concerns?
- Is the scope appropriate?
- Are output requirements sufficient?
3. **Refine as Needed**
- Incorporate user feedback
- Adjust scope or focus
- Add missing elements
- Clarify ambiguities
### 6. Next Steps Guidance
**Execution Options:**
1. **Use with AI Research Assistant**: Provide this prompt to an AI model with research capabilities
2. **Guide Human Research**: Use as a framework for manual research efforts
3. **Hybrid Approach**: Combine AI and human research using this structure
**Integration Points:**
- How findings will feed into next phases
- Which team members should review results
- How to validate findings
- When to revisit or expand research
## Important Notes
- The quality of the research prompt directly impacts the quality of insights gathered
- Be specific rather than general in research questions
- Consider both current state and future implications
- Balance comprehensiveness with focus
- Document assumptions and limitations clearly
- Plan for iterative refinement based on initial findings
==================== END: .bmad-core/tasks/create-deep-research-prompt.md ====================
==================== START: .bmad-core/tasks/create-doc.md ====================
# Create Document from Template (YAML Driven)
@@ -553,7 +258,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -566,14 +270,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -582,7 +284,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -590,7 +291,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -604,7 +304,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -614,7 +313,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
@@ -645,7 +343,7 @@ template:
output:
format: markdown
filename: docs/front-end-spec.md
title: "{{project_name}} UI/UX Specification"
title: '{{project_name}} UI/UX Specification'
workflow:
mode: interactive
@@ -673,29 +371,29 @@ sections:
sections:
- id: user-personas
title: Target User Personas
template: "{{persona_descriptions}}"
template: '{{persona_descriptions}}'
examples:
- "**Power User:** Technical professionals who need advanced features and efficiency"
- "**Casual User:** Occasional users who prioritize ease of use and clear guidance"
- "**Administrator:** System managers who need control and oversight capabilities"
- '**Power User:** Technical professionals who need advanced features and efficiency'
- '**Casual User:** Occasional users who prioritize ease of use and clear guidance'
- '**Administrator:** System managers who need control and oversight capabilities'
- id: usability-goals
title: Usability Goals
template: "{{usability_goals}}"
template: '{{usability_goals}}'
examples:
- "Ease of learning: New users can complete core tasks within 5 minutes"
- "Efficiency of use: Power users can complete frequent tasks with minimal clicks"
- "Error prevention: Clear validation and confirmation for destructive actions"
- "Memorability: Infrequent users can return without relearning"
- 'Ease of learning: New users can complete core tasks within 5 minutes'
- 'Efficiency of use: Power users can complete frequent tasks with minimal clicks'
- 'Error prevention: Clear validation and confirmation for destructive actions'
- 'Memorability: Infrequent users can return without relearning'
- id: design-principles
title: Design Principles
template: "{{design_principles}}"
template: '{{design_principles}}'
type: numbered-list
examples:
- "**Clarity over cleverness** - Prioritize clear communication over aesthetic innovation"
- '**Clarity over cleverness** - Prioritize clear communication over aesthetic innovation'
- "**Progressive disclosure** - Show only what's needed, when it's needed"
- "**Consistent patterns** - Use familiar UI patterns throughout the application"
- "**Immediate feedback** - Every action should have a clear, immediate response"
- "**Accessible by default** - Design for all users from the start"
- '**Consistent patterns** - Use familiar UI patterns throughout the application'
- '**Immediate feedback** - Every action should have a clear, immediate response'
- '**Accessible by default** - Design for all users from the start'
- id: changelog
title: Change Log
type: table
@@ -717,7 +415,7 @@ sections:
title: Site Map / Screen Inventory
type: mermaid
mermaid_type: graph
template: "{{sitemap_diagram}}"
template: '{{sitemap_diagram}}'
examples:
- |
graph TD
@@ -757,7 +455,7 @@ sections:
repeatable: true
sections:
- id: flow
title: "{{flow_name}}"
title: '{{flow_name}}'
template: |
**User Goal:** {{flow_goal}}
@@ -769,13 +467,13 @@ sections:
title: Flow Diagram
type: mermaid
mermaid_type: graph
template: "{{flow_diagram}}"
template: '{{flow_diagram}}'
- id: edge-cases
title: "Edge Cases & Error Handling:"
title: 'Edge Cases & Error Handling:'
type: bullet-list
template: "- {{edge_case}}"
template: '- {{edge_case}}'
- id: notes
template: "**Notes:** {{flow_notes}}"
template: '**Notes:** {{flow_notes}}'
- id: wireframes-mockups
title: Wireframes & Mockups
@@ -784,13 +482,13 @@ sections:
elicit: true
sections:
- id: design-files
template: "**Primary Design Files:** {{design_tool_link}}"
template: '**Primary Design Files:** {{design_tool_link}}'
- id: key-screen-layouts
title: Key Screen Layouts
repeatable: true
sections:
- id: screen
title: "{{screen_name}}"
title: '{{screen_name}}'
template: |
**Purpose:** {{screen_purpose}}
@@ -810,13 +508,13 @@ sections:
elicit: true
sections:
- id: design-system-approach
template: "**Design System Approach:** {{design_system_approach}}"
template: '**Design System Approach:** {{design_system_approach}}'
- id: core-components
title: Core Components
repeatable: true
sections:
- id: component
title: "{{component_name}}"
title: '{{component_name}}'
template: |
**Purpose:** {{component_purpose}}
@@ -833,19 +531,19 @@ sections:
sections:
- id: visual-identity
title: Visual Identity
template: "**Brand Guidelines:** {{brand_guidelines_link}}"
template: '**Brand Guidelines:** {{brand_guidelines_link}}'
- id: color-palette
title: Color Palette
type: table
columns: ["Color Type", "Hex Code", "Usage"]
columns: ['Color Type', 'Hex Code', 'Usage']
rows:
- ["Primary", "{{primary_color}}", "{{primary_usage}}"]
- ["Secondary", "{{secondary_color}}", "{{secondary_usage}}"]
- ["Accent", "{{accent_color}}", "{{accent_usage}}"]
- ["Success", "{{success_color}}", "Positive feedback, confirmations"]
- ["Warning", "{{warning_color}}", "Cautions, important notices"]
- ["Error", "{{error_color}}", "Errors, destructive actions"]
- ["Neutral", "{{neutral_colors}}", "Text, borders, backgrounds"]
- ['Primary', '{{primary_color}}', '{{primary_usage}}']
- ['Secondary', '{{secondary_color}}', '{{secondary_usage}}']
- ['Accent', '{{accent_color}}', '{{accent_usage}}']
- ['Success', '{{success_color}}', 'Positive feedback, confirmations']
- ['Warning', '{{warning_color}}', 'Cautions, important notices']
- ['Error', '{{error_color}}', 'Errors, destructive actions']
- ['Neutral', '{{neutral_colors}}', 'Text, borders, backgrounds']
- id: typography
title: Typography
sections:
@@ -858,13 +556,13 @@ sections:
- id: type-scale
title: Type Scale
type: table
columns: ["Element", "Size", "Weight", "Line Height"]
columns: ['Element', 'Size', 'Weight', 'Line Height']
rows:
- ["H1", "{{h1_size}}", "{{h1_weight}}", "{{h1_line}}"]
- ["H2", "{{h2_size}}", "{{h2_weight}}", "{{h2_line}}"]
- ["H3", "{{h3_size}}", "{{h3_weight}}", "{{h3_line}}"]
- ["Body", "{{body_size}}", "{{body_weight}}", "{{body_line}}"]
- ["Small", "{{small_size}}", "{{small_weight}}", "{{small_line}}"]
- ['H1', '{{h1_size}}', '{{h1_weight}}', '{{h1_line}}']
- ['H2', '{{h2_size}}', '{{h2_weight}}', '{{h2_line}}']
- ['H3', '{{h3_size}}', '{{h3_weight}}', '{{h3_line}}']
- ['Body', '{{body_size}}', '{{body_weight}}', '{{body_line}}']
- ['Small', '{{small_size}}', '{{small_weight}}', '{{small_line}}']
- id: iconography
title: Iconography
template: |
@@ -885,7 +583,7 @@ sections:
sections:
- id: compliance-target
title: Compliance Target
template: "**Standard:** {{compliance_standard}}"
template: '**Standard:** {{compliance_standard}}'
- id: key-requirements
title: Key Requirements
template: |
@@ -905,7 +603,7 @@ sections:
- Form labels: {{form_requirements}}
- id: testing-strategy
title: Testing Strategy
template: "{{accessibility_testing}}"
template: '{{accessibility_testing}}'
- id: responsiveness
title: Responsiveness Strategy
@@ -915,12 +613,12 @@ sections:
- id: breakpoints
title: Breakpoints
type: table
columns: ["Breakpoint", "Min Width", "Max Width", "Target Devices"]
columns: ['Breakpoint', 'Min Width', 'Max Width', 'Target Devices']
rows:
- ["Mobile", "{{mobile_min}}", "{{mobile_max}}", "{{mobile_devices}}"]
- ["Tablet", "{{tablet_min}}", "{{tablet_max}}", "{{tablet_devices}}"]
- ["Desktop", "{{desktop_min}}", "{{desktop_max}}", "{{desktop_devices}}"]
- ["Wide", "{{wide_min}}", "-", "{{wide_devices}}"]
- ['Mobile', '{{mobile_min}}', '{{mobile_max}}', '{{mobile_devices}}']
- ['Tablet', '{{tablet_min}}', '{{tablet_max}}', '{{tablet_devices}}']
- ['Desktop', '{{desktop_min}}', '{{desktop_max}}', '{{desktop_devices}}']
- ['Wide', '{{wide_min}}', '-', '{{wide_devices}}']
- id: adaptation-patterns
title: Adaptation Patterns
template: |
@@ -939,11 +637,11 @@ sections:
sections:
- id: motion-principles
title: Motion Principles
template: "{{motion_principles}}"
template: '{{motion_principles}}'
- id: key-animations
title: Key Animations
repeatable: true
template: "- **{{animation_name}}:** {{animation_description}} (Duration: {{duration}}, Easing: {{easing}})"
template: '- **{{animation_name}}:** {{animation_description}} (Duration: {{duration}}, Easing: {{easing}})'
- id: performance
title: Performance Considerations
@@ -957,7 +655,7 @@ sections:
- **Animation FPS:** {{animation_goal}}
- id: design-strategies
title: Design Strategies
template: "{{performance_strategies}}"
template: '{{performance_strategies}}'
- id: next-steps
title: Next Steps
@@ -972,17 +670,17 @@ sections:
- id: immediate-actions
title: Immediate Actions
type: numbered-list
template: "{{action}}"
template: '{{action}}'
- id: design-handoff-checklist
title: Design Handoff Checklist
type: checklist
items:
- "All user flows documented"
- "Component inventory complete"
- "Accessibility requirements defined"
- "Responsive strategy clear"
- "Brand guidelines incorporated"
- "Performance goals established"
- 'All user flows documented'
- 'Component inventory complete'
- 'Accessibility requirements defined'
- 'Responsive strategy clear'
- 'Brand guidelines incorporated'
- 'Performance goals established'
- id: checklist-results
title: Checklist Results

View File

@@ -210,7 +210,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -223,14 +222,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -239,7 +236,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -247,7 +243,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -261,7 +256,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -271,7 +265,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
@@ -306,7 +299,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
[[LLM: Begin by understanding the game design context and goals. Ask clarifying questions if needed to determine the best approach for game-specific ideation.]]
1. **Establish Game Context**
- Understand the game genre or opportunity area
- Identify target audience and platform constraints
- Determine session goals (concept exploration vs. mechanic refinement)
@@ -324,7 +316,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
1. **"What If" Game Scenarios**
[[LLM: Generate provocative what-if questions that challenge game design assumptions and expand thinking beyond current genre limitations.]]
- What if players could rewind time in any genre?
- What if the game world reacted to the player's real-world location?
- What if failure was more rewarding than success?
@@ -333,7 +324,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
2. **Cross-Genre Fusion**
[[LLM: Help user combine unexpected game genres and mechanics to create unique experiences.]]
- "How might [genre A] mechanics work in [genre B]?"
- Puzzle mechanics in action games
- Dating sim elements in strategy games
@@ -342,7 +332,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
3. **Player Motivation Reversal**
[[LLM: Flip traditional player motivations to reveal new gameplay possibilities.]]
- What if losing was the goal?
- What if cooperation was forced in competitive games?
- What if players had to help their enemies?
@@ -359,7 +348,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
1. **SCAMPER for Game Mechanics**
[[LLM: Guide through each SCAMPER prompt specifically for game design.]]
- **S** = Substitute: What mechanics can be substituted? (walking → flying → swimming)
- **C** = Combine: What systems can be merged? (inventory + character growth)
- **A** = Adapt: What mechanics from other media? (books, movies, sports)
@@ -370,7 +358,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
2. **Player Agency Spectrum**
[[LLM: Explore different levels of player control and agency across game systems.]]
- Full Control: Direct character movement, combat, building
- Indirect Control: Setting rules, giving commands, environmental changes
- Influence Only: Suggestions, preferences, emotional reactions
@@ -378,7 +365,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
3. **Temporal Game Design**
[[LLM: Explore how time affects gameplay and player experience.]]
- Real-time vs. turn-based mechanics
- Time travel and manipulation
- Persistent vs. session-based progress
@@ -389,7 +375,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
1. **Emotion-First Design**
[[LLM: Start with target emotions and work backward to mechanics that create them.]]
- Target Emotion: Wonder → Mechanics: Discovery, mystery, scale
- Target Emotion: Triumph → Mechanics: Challenge, skill growth, recognition
- Target Emotion: Connection → Mechanics: Cooperation, shared goals, communication
@@ -397,7 +382,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
2. **Player Archetype Brainstorming**
[[LLM: Design for different player types and motivations.]]
- Achievers: Progression, completion, mastery
- Explorers: Discovery, secrets, world-building
- Socializers: Interaction, cooperation, community
@@ -406,7 +390,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
3. **Accessibility-First Innovation**
[[LLM: Generate ideas that make games more accessible while creating new gameplay.]]
- Visual impairment considerations leading to audio-focused mechanics
- Motor accessibility inspiring one-handed or simplified controls
- Cognitive accessibility driving clear feedback and pacing
@@ -416,7 +399,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
1. **Environmental Storytelling**
[[LLM: Brainstorm ways the game world itself tells stories without explicit narrative.]]
- How does the environment show history?
- What do interactive objects reveal about characters?
- How can level design communicate mood?
@@ -424,7 +406,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
2. **Player-Generated Narrative**
[[LLM: Explore ways players create their own stories through gameplay.]]
- Emergent storytelling through player choices
- Procedural narrative generation
- Player-to-player story sharing
@@ -432,7 +413,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
3. **Genre Expectation Subversion**
[[LLM: Identify and deliberately subvert player expectations within genres.]]
- Fantasy RPG where magic is mundane
- Horror game where monsters are friendly
- Racing game where going slow is optimal
@@ -442,7 +422,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
1. **Platform-Specific Design**
[[LLM: Generate ideas that leverage unique platform capabilities.]]
- Mobile: GPS, accelerometer, camera, always-connected
- Web: URLs, tabs, social sharing, real-time collaboration
- Console: Controllers, TV viewing, couch co-op
@@ -450,7 +429,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
2. **Constraint-Based Creativity**
[[LLM: Use technical or design constraints as creative catalysts.]]
- One-button games
- Games without graphics
- Games that play in notification bars
@@ -496,19 +474,16 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
[[LLM: Guide the brainstorming session with appropriate pacing for game design exploration.]]
1. **Inspiration Phase** (10-15 min)
- Reference existing games and mechanics
- Explore player experiences and emotions
- Gather visual and thematic inspiration
2. **Divergent Exploration** (25-35 min)
- Generate many game concepts or mechanics
- Use expansion and fusion techniques
- Encourage wild and impossible ideas
3. **Player-Centered Filtering** (15-20 min)
- Consider target audience reactions
- Evaluate emotional impact and engagement
- Group ideas by player experience goals
@@ -629,63 +604,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
Present these numbered options to the user:
1. **Product Validation Research**
- Validate product hypotheses and market fit
- Test assumptions about user needs and solutions
- Assess technical and business feasibility
- Identify risks and mitigation strategies
2. **Market Opportunity Research**
- Analyze market size and growth potential
- Identify market segments and dynamics
- Assess market entry strategies
- Evaluate timing and market readiness
3. **User & Customer Research**
- Deep dive into user personas and behaviors
- Understand jobs-to-be-done and pain points
- Map customer journeys and touchpoints
- Analyze willingness to pay and value perception
4. **Competitive Intelligence Research**
- Detailed competitor analysis and positioning
- Feature and capability comparisons
- Business model and strategy analysis
- Identify competitive advantages and gaps
5. **Technology & Innovation Research**
- Assess technology trends and possibilities
- Evaluate technical approaches and architectures
- Identify emerging technologies and disruptions
- Analyze build vs. buy vs. partner options
6. **Industry & Ecosystem Research**
- Map industry value chains and dynamics
- Identify key players and relationships
- Analyze regulatory and compliance factors
- Understand partnership opportunities
7. **Strategic Options Research**
- Evaluate different strategic directions
- Assess business model alternatives
- Analyze go-to-market strategies
- Consider expansion and scaling paths
8. **Risk & Feasibility Research**
- Identify and assess various risk factors
- Evaluate implementation challenges
- Analyze resource requirements
- Consider regulatory and legal implications
9. **Custom Research Focus**
- User-defined research objectives
- Specialized domain investigation
- Cross-functional research needs
@@ -854,13 +820,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
### 5. Review and Refinement
1. **Present Complete Prompt**
- Show the full research prompt
- Explain key elements and rationale
- Highlight any assumptions made
2. **Gather Feedback**
- Are the objectives clear and correct?
- Do the questions address all concerns?
- Is the scope appropriate?
@@ -918,7 +882,6 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
2. If the section contains game flow diagrams, level layouts, or system diagrams, explain each diagram briefly with game development context before offering elicitation options (e.g., "The gameplay loop diagram shows how player actions lead to rewards and progression. Notice how each step maintains player engagement and creates opportunities for skill development.")
3. If the section contains multiple game elements (like multiple mechanics, multiple levels, multiple systems, etc.), inform the user they can apply elicitation actions to:
- The entire section as a whole
- Individual game elements within the section (specify which element when selecting an action)
@@ -1018,8 +981,8 @@ template:
version: 2.0
output:
format: markdown
filename: "docs/{{game_name}}-game-design-document.md"
title: "{{game_title}} Game Design Document (GDD)"
filename: 'docs/{{game_name}}-game-design-document.md'
title: '{{game_title}} Game Design Document (GDD)'
workflow:
mode: interactive
@@ -1056,7 +1019,7 @@ sections:
title: Unique Selling Points
instruction: List 3-5 key features that differentiate this game from competitors
type: numbered-list
template: "{{usp}}"
template: '{{usp}}'
- id: core-gameplay
title: Core Gameplay
@@ -1101,7 +1064,7 @@ sections:
repeatable: true
sections:
- id: mechanic
title: "{{mechanic_name}}"
title: '{{mechanic_name}}'
template: |
**Description:** {{detailed_description}}
@@ -1166,7 +1129,7 @@ sections:
repeatable: true
sections:
- id: level-type
title: "{{level_type_name}}"
title: '{{level_type_name}}'
template: |
**Purpose:** {{gameplay_purpose}}
**Duration:** {{target_time}}
@@ -1267,10 +1230,10 @@ sections:
instruction: Break down the development into phases that can be converted to epics
sections:
- id: phase-1-core-systems
title: "Phase 1: Core Systems ({{duration}})"
title: 'Phase 1: Core Systems ({{duration}})'
sections:
- id: foundation-epic
title: "Epic: Foundation"
title: 'Epic: Foundation'
type: bullet-list
template: |
- Engine setup and configuration
@@ -1278,41 +1241,41 @@ sections:
- Core input handling
- Asset loading pipeline
- id: core-mechanics-epic
title: "Epic: Core Mechanics"
title: 'Epic: Core Mechanics'
type: bullet-list
template: |
- {{primary_mechanic}} implementation
- Basic physics and collision
- Player controller
- id: phase-2-gameplay-features
title: "Phase 2: Gameplay Features ({{duration}})"
title: 'Phase 2: Gameplay Features ({{duration}})'
sections:
- id: game-systems-epic
title: "Epic: Game Systems"
title: 'Epic: Game Systems'
type: bullet-list
template: |
- {{mechanic_2}} implementation
- {{mechanic_3}} implementation
- Game state management
- id: content-creation-epic
title: "Epic: Content Creation"
title: 'Epic: Content Creation'
type: bullet-list
template: |
- Level loading system
- First playable levels
- Basic UI implementation
- id: phase-3-polish-optimization
title: "Phase 3: Polish & Optimization ({{duration}})"
title: 'Phase 3: Polish & Optimization ({{duration}})'
sections:
- id: performance-epic
title: "Epic: Performance"
title: 'Epic: Performance'
type: bullet-list
template: |
- Optimization and profiling
- Mobile platform testing
- Memory management
- id: user-experience-epic
title: "Epic: User Experience"
title: 'Epic: User Experience'
type: bullet-list
template: |
- Audio implementation
@@ -1354,7 +1317,7 @@ sections:
title: References
instruction: List any competitive analysis, inspiration, or research sources
type: bullet-list
template: "{{reference}}"
template: '{{reference}}'
==================== END: .bmad-2d-phaser-game-dev/templates/game-design-doc-tmpl.yaml ====================
==================== START: .bmad-2d-phaser-game-dev/templates/level-design-doc-tmpl.yaml ====================
@@ -1364,8 +1327,8 @@ template:
version: 2.0
output:
format: markdown
filename: "docs/{{game_name}}-level-design-document.md"
title: "{{game_title}} Level Design Document"
filename: 'docs/{{game_name}}-level-design-document.md'
title: '{{game_title}} Level Design Document'
workflow:
mode: interactive
@@ -1426,7 +1389,7 @@ sections:
repeatable: true
sections:
- id: level-category
title: "{{category_name}} Levels"
title: '{{category_name}} Levels'
template: |
**Purpose:** {{gameplay_purpose}}
@@ -1731,19 +1694,19 @@ sections:
title: Playtesting Checklist
type: checklist
items:
- "Level completes within target time range"
- "All mechanics function correctly"
- "Difficulty feels appropriate for level category"
- "Player guidance is clear and effective"
- "No exploits or sequence breaks (unless intended)"
- 'Level completes within target time range'
- 'All mechanics function correctly'
- 'Difficulty feels appropriate for level category'
- 'Player guidance is clear and effective'
- 'No exploits or sequence breaks (unless intended)'
- id: player-experience-testing
title: Player Experience Testing
type: checklist
items:
- "Tutorial levels teach effectively"
- "Challenge feels fair and rewarding"
- "Flow and pacing maintain engagement"
- "Audio and visual feedback support gameplay"
- 'Tutorial levels teach effectively'
- 'Challenge feels fair and rewarding'
- 'Flow and pacing maintain engagement'
- 'Audio and visual feedback support gameplay'
- id: balance-validation
title: Balance Validation
template: |
@@ -1851,8 +1814,8 @@ template:
version: 2.0
output:
format: markdown
filename: "docs/{{game_name}}-game-brief.md"
title: "{{game_title}} Game Brief"
filename: 'docs/{{game_name}}-game-brief.md'
title: '{{game_title}} Game Brief'
workflow:
mode: interactive
@@ -2138,21 +2101,21 @@ sections:
title: Development Roadmap
sections:
- id: phase-1-preproduction
title: "Phase 1: Pre-Production ({{duration}})"
title: 'Phase 1: Pre-Production ({{duration}})'
type: bullet-list
template: |
- Detailed Game Design Document creation
- Technical architecture planning
- Art style exploration and pipeline setup
- id: phase-2-prototype
title: "Phase 2: Prototype ({{duration}})"
title: 'Phase 2: Prototype ({{duration}})'
type: bullet-list
template: |
- Core mechanic implementation
- Technical proof of concept
- Initial playtesting and iteration
- id: phase-3-production
title: "Phase 3: Production ({{duration}})"
title: 'Phase 3: Production ({{duration}})'
type: bullet-list
template: |
- Full feature development

View File

@@ -113,7 +113,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -126,14 +125,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -142,7 +139,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -150,7 +146,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -164,7 +159,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -174,7 +168,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
@@ -204,8 +197,8 @@ template:
version: 2.0
output:
format: markdown
filename: "docs/{{game_name}}-game-architecture.md"
title: "{{game_title}} Game Architecture Document"
filename: 'docs/{{game_name}}-game-architecture.md'
title: '{{game_title}} Game Architecture Document'
workflow:
mode: interactive
@@ -429,7 +422,7 @@ sections:
repeatable: true
sections:
- id: mechanic-system
title: "{{mechanic_name}} System"
title: '{{mechanic_name}} System'
template: |
**Purpose:** {{system_purpose}}
@@ -726,7 +719,7 @@ sections:
instruction: Break down the architecture implementation into phases that align with the GDD development phases
sections:
- id: phase-1-foundation
title: "Phase 1: Foundation ({{duration}})"
title: 'Phase 1: Foundation ({{duration}})'
sections:
- id: phase-1-core
title: Core Systems
@@ -744,7 +737,7 @@ sections:
- "Basic Scene Management System"
- "Asset Loading Foundation"
- id: phase-2-game-systems
title: "Phase 2: Game Systems ({{duration}})"
title: 'Phase 2: Game Systems ({{duration}})'
sections:
- id: phase-2-gameplay
title: Gameplay Systems
@@ -762,7 +755,7 @@ sections:
- "Physics and Collision Framework"
- "Game State Management System"
- id: phase-3-content-polish
title: "Phase 3: Content & Polish ({{duration}})"
title: 'Phase 3: Content & Polish ({{duration}})'
sections:
- id: phase-3-content
title: Content Systems
@@ -1052,7 +1045,7 @@ interface GameState {
interface GameSettings {
musicVolume: number;
sfxVolume: number;
difficulty: "easy" | "normal" | "hard";
difficulty: 'easy' | 'normal' | 'hard';
controls: ControlScheme;
}
```
@@ -1093,12 +1086,12 @@ class GameScene extends Phaser.Scene {
private inputManager!: InputManager;
constructor() {
super({ key: "GameScene" });
super({ key: 'GameScene' });
}
preload(): void {
// Load only scene-specific assets
this.load.image("player", "assets/player.png");
this.load.image('player', 'assets/player.png');
}
create(data: SceneData): void {
@@ -1123,7 +1116,7 @@ class GameScene extends Phaser.Scene {
this.inputManager.destroy();
// Remove event listeners
this.events.off("*");
this.events.off('*');
}
}
```
@@ -1132,13 +1125,13 @@ class GameScene extends Phaser.Scene {
```typescript
// Proper scene transitions with data
this.scene.start("NextScene", {
this.scene.start('NextScene', {
playerScore: this.playerScore,
currentLevel: this.currentLevel + 1,
});
// Scene overlays for UI
this.scene.launch("PauseMenuScene");
this.scene.launch('PauseMenuScene');
this.scene.pause();
```
@@ -1182,7 +1175,7 @@ class Player extends GameEntity {
private health!: HealthComponent;
constructor(scene: Phaser.Scene, x: number, y: number) {
super(scene, x, y, "player");
super(scene, x, y, 'player');
this.movement = this.addComponent(new MovementComponent(this));
this.health = this.addComponent(new HealthComponent(this, 100));
@@ -1202,7 +1195,7 @@ class GameManager {
constructor(scene: Phaser.Scene) {
if (GameManager.instance) {
throw new Error("GameManager already exists!");
throw new Error('GameManager already exists!');
}
this.scene = scene;
@@ -1212,7 +1205,7 @@ class GameManager {
static getInstance(): GameManager {
if (!GameManager.instance) {
throw new Error("GameManager not initialized!");
throw new Error('GameManager not initialized!');
}
return GameManager.instance;
}
@@ -1259,7 +1252,7 @@ class BulletPool {
}
// Pool exhausted - create new bullet
console.warn("Bullet pool exhausted, creating new bullet");
console.warn('Bullet pool exhausted, creating new bullet');
return new Bullet(this.scene, 0, 0);
}
@@ -1359,12 +1352,12 @@ class InputManager {
}
private setupKeyboard(): void {
this.keys = this.scene.input.keyboard.addKeys("W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT");
this.keys = this.scene.input.keyboard.addKeys('W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT');
}
private setupTouch(): void {
this.scene.input.on("pointerdown", this.handlePointerDown, this);
this.scene.input.on("pointerup", this.handlePointerUp, this);
this.scene.input.on('pointerdown', this.handlePointerDown, this);
this.scene.input.on('pointerup', this.handlePointerUp, this);
}
update(): void {
@@ -1391,9 +1384,9 @@ class InputManager {
class AssetManager {
loadAssets(): Promise<void> {
return new Promise((resolve, reject) => {
this.scene.load.on("filecomplete", this.handleFileComplete, this);
this.scene.load.on("loaderror", this.handleLoadError, this);
this.scene.load.on("complete", () => resolve());
this.scene.load.on('filecomplete', this.handleFileComplete, this);
this.scene.load.on('loaderror', this.handleLoadError, this);
this.scene.load.on('complete', () => resolve());
this.scene.load.start();
});
@@ -1409,8 +1402,8 @@ class AssetManager {
private loadFallbackAsset(key: string): void {
// Load placeholder or default assets
switch (key) {
case "player":
this.scene.load.image("player", "assets/defaults/default-player.png");
case 'player':
this.scene.load.image('player', 'assets/defaults/default-player.png');
break;
default:
console.warn(`No fallback for asset: ${key}`);
@@ -1437,11 +1430,11 @@ class GameSystem {
private attemptRecovery(context: string): void {
switch (context) {
case "update":
case 'update':
// Reset system state
this.reset();
break;
case "render":
case 'render':
// Disable visual effects
this.disableEffects();
break;
@@ -1461,7 +1454,7 @@ class GameSystem {
```typescript
// Example test for game mechanics
describe("HealthComponent", () => {
describe('HealthComponent', () => {
let healthComponent: HealthComponent;
beforeEach(() => {
@@ -1469,18 +1462,18 @@ describe("HealthComponent", () => {
healthComponent = new HealthComponent(mockEntity, 100);
});
test("should initialize with correct health", () => {
test('should initialize with correct health', () => {
expect(healthComponent.currentHealth).toBe(100);
expect(healthComponent.maxHealth).toBe(100);
});
test("should handle damage correctly", () => {
test('should handle damage correctly', () => {
healthComponent.takeDamage(25);
expect(healthComponent.currentHealth).toBe(75);
expect(healthComponent.isAlive()).toBe(true);
});
test("should handle death correctly", () => {
test('should handle death correctly', () => {
healthComponent.takeDamage(150);
expect(healthComponent.currentHealth).toBe(0);
expect(healthComponent.isAlive()).toBe(false);
@@ -1493,7 +1486,7 @@ describe("HealthComponent", () => {
**Scene Testing:**
```typescript
describe("GameScene Integration", () => {
describe('GameScene Integration', () => {
let scene: GameScene;
let mockGame: Phaser.Game;
@@ -1503,7 +1496,7 @@ describe("GameScene Integration", () => {
scene = new GameScene();
});
test("should initialize all systems", () => {
test('should initialize all systems', () => {
scene.create({});
expect(scene.gameManager).toBeDefined();
@@ -1564,25 +1557,21 @@ src/
### Story Implementation Process
1. **Read Story Requirements:**
- Understand acceptance criteria
- Identify technical requirements
- Review performance constraints
2. **Plan Implementation:**
- Identify files to create/modify
- Consider component architecture
- Plan testing approach
3. **Implement Feature:**
- Follow TypeScript strict mode
- Use established patterns
- Maintain 60 FPS performance
4. **Test Implementation:**
- Write unit tests for game logic
- Test cross-platform functionality
- Validate performance targets

View File

@@ -318,7 +318,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -331,14 +330,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -347,7 +344,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -355,7 +351,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -369,7 +364,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -379,7 +373,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
@@ -409,8 +402,8 @@ template:
version: 2.0
output:
format: markdown
filename: "stories/{{epic_name}}/{{story_id}}-{{story_name}}.md"
title: "Story: {{story_title}}"
filename: 'stories/{{epic_name}}/{{story_id}}-{{story_name}}.md'
title: 'Story: {{story_title}}'
workflow:
mode: interactive
@@ -439,7 +432,7 @@ sections:
- id: description
title: Description
instruction: Provide a clear, concise description of what this story implements. Focus on the specific game feature or system being built. Reference the GDD section that defines this feature.
template: "{{clear_description_of_what_needs_to_be_implemented}}"
template: '{{clear_description_of_what_needs_to_be_implemented}}'
- id: acceptance-criteria
title: Acceptance Criteria
@@ -449,22 +442,22 @@ sections:
title: Functional Requirements
type: checklist
items:
- "{{specific_functional_requirement}}"
- '{{specific_functional_requirement}}'
- id: technical-requirements
title: Technical Requirements
type: checklist
items:
- "Code follows TypeScript strict mode standards"
- "Maintains 60 FPS on target devices"
- "No memory leaks or performance degradation"
- "{{specific_technical_requirement}}"
- 'Code follows TypeScript strict mode standards'
- 'Maintains 60 FPS on target devices'
- 'No memory leaks or performance degradation'
- '{{specific_technical_requirement}}'
- id: game-design-requirements
title: Game Design Requirements
type: checklist
items:
- "{{gameplay_requirement_from_gdd}}"
- "{{balance_requirement_if_applicable}}"
- "{{player_experience_requirement}}"
- '{{gameplay_requirement_from_gdd}}'
- '{{balance_requirement_if_applicable}}'
- '{{player_experience_requirement}}'
- id: technical-specifications
title: Technical Specifications
@@ -629,14 +622,14 @@ sections:
instruction: Checklist that must be completed before the story is considered finished
type: checklist
items:
- "All acceptance criteria met"
- "Code reviewed and approved"
- "Unit tests written and passing"
- "Integration tests passing"
- "Performance targets met"
- "No linting errors"
- "Documentation updated"
- "{{game_specific_dod_item}}"
- 'All acceptance criteria met'
- 'Code reviewed and approved'
- 'Unit tests written and passing'
- 'Integration tests passing'
- 'Performance targets met'
- 'No linting errors'
- 'Documentation updated'
- '{{game_specific_dod_item}}'
- id: notes
title: Notes

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -239,7 +239,6 @@ To conduct a thorough review of existing infrastructure to identify improvement
### 3. Conduct Systematic Review
- **If "Incremental Mode" was selected:**
- For each section of the infrastructure checklist:
- **a. Present Section Focus:** Explain what aspects of infrastructure this section reviews
- **b. Work Through Items:** Examine each checklist item against current infrastructure
@@ -425,7 +424,6 @@ To comprehensively validate platform infrastructure changes against security, re
### 4. Execute Comprehensive Platform Validation Process
- **If "Incremental Mode" was selected:**
- For each section of the infrastructure checklist (Sections 1-16):
- **a. Present Section Purpose:** Explain what this section validates and why it's important for platform operations
- **b. Work Through Items:** Present each checklist item, guide the user through validation, and document compliance or gaps
@@ -532,23 +530,23 @@ template:
output:
format: markdown
filename: docs/infrastructure-architecture.md
title: "{{project_name}} Infrastructure Architecture"
title: '{{project_name}} Infrastructure Architecture'
workflow:
mode: interactive
elicitation: advanced-elicitation
custom_elicitation:
title: "Infrastructure Architecture Elicitation Actions"
title: 'Infrastructure Architecture Elicitation Actions'
sections:
- id: infrastructure-overview
options:
- "Multi-Cloud Strategy Analysis - Evaluate cloud provider options and vendor lock-in considerations"
- "Regional Distribution Planning - Analyze latency requirements and data residency needs"
- "Environment Isolation Strategy - Design security boundaries and resource segregation"
- "Scalability Patterns Review - Assess auto-scaling needs and traffic patterns"
- "Compliance Requirements Analysis - Review regulatory and security compliance needs"
- "Cost-Benefit Analysis - Compare infrastructure options and TCO"
- "Proceed to next section"
- 'Multi-Cloud Strategy Analysis - Evaluate cloud provider options and vendor lock-in considerations'
- 'Regional Distribution Planning - Analyze latency requirements and data residency needs'
- 'Environment Isolation Strategy - Design security boundaries and resource segregation'
- 'Scalability Patterns Review - Assess auto-scaling needs and traffic patterns'
- 'Compliance Requirements Analysis - Review regulatory and security compliance needs'
- 'Cost-Benefit Analysis - Compare infrastructure options and TCO'
- 'Proceed to next section'
sections:
- id: initial-setup
@@ -608,7 +606,7 @@ sections:
sections:
- id: environments
repeatable: true
title: "{{environment_name}} Environment"
title: '{{environment_name}} Environment'
template: |
- **Purpose:** {{environment_purpose}}
- **Resources:** {{environment_resources}}
@@ -959,24 +957,24 @@ template:
output:
format: markdown
filename: docs/platform-infrastructure/platform-implementation.md
title: "{{project_name}} Platform Infrastructure Implementation"
title: '{{project_name}} Platform Infrastructure Implementation'
workflow:
mode: interactive
elicitation: advanced-elicitation
custom_elicitation:
title: "Platform Implementation Elicitation Actions"
title: 'Platform Implementation Elicitation Actions'
sections:
- id: foundation-infrastructure
options:
- "Platform Layer Security Hardening - Additional security controls and compliance validation"
- "Performance Optimization - Network and resource optimization"
- "Operational Excellence Enhancement - Automation and monitoring improvements"
- "Platform Integration Validation - Verify foundation supports upper layers"
- "Developer Experience Analysis - Foundation impact on developer workflows"
- "Disaster Recovery Testing - Foundation resilience validation"
- "BMAD Workflow Integration - Cross-agent support verification"
- "Finalize and Proceed to Container Platform"
- 'Platform Layer Security Hardening - Additional security controls and compliance validation'
- 'Performance Optimization - Network and resource optimization'
- 'Operational Excellence Enhancement - Automation and monitoring improvements'
- 'Platform Integration Validation - Verify foundation supports upper layers'
- 'Developer Experience Analysis - Foundation impact on developer workflows'
- 'Disaster Recovery Testing - Foundation resilience validation'
- 'BMAD Workflow Integration - Cross-agent support verification'
- 'Finalize and Proceed to Container Platform'
sections:
- id: initial-setup

2727
dist/teams/team-all.txt vendored

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -65,7 +65,7 @@ See [Expansion Packs Guide](../docs/expansion-packs.md) for detailed examples an
### Template Rules
Templates follow the [BMad Document Template](common/utils/bmad-doc-template.md) specification using YAML format:
Templates follow the [BMad Document Template](../common/utils/bmad-doc-template.md) specification using YAML format:
1. **Structure**: Templates are defined in YAML with clear metadata, workflow configuration, and section hierarchy
2. **Separation of Concerns**: Instructions for LLMs are in `instruction` fields, separate from content

View File

@@ -1,19 +0,0 @@
# BMad Method Guide for Claude Code
For the complete workflow, see the [BMad Workflow Guide](../bmad-workflow-guide.md).
## Installation
When running `npx bmad-method install`, select **Claude Code** as your IDE. This creates:
- `.bmad-core/` folder with all agents
- `.claude/commands/BMad` folder with agent command files (`.md`)
## Using BMad Agents in Claude Code
Type `/agent-name` in your chat to activate an agent.
## Tips for Claude Code Users
- Commands are auto-suggested as you type `/`
- More coming soon...

View File

@@ -1,16 +0,0 @@
# BMad Method Guide for Cline (VS Code)
For the complete workflow, see the [BMad Workflow Guide](../bmad-workflow-guide.md).
## Installation
When running `npx bmad-method install`, select **Cline** as your IDE. This creates:
- `.clinerules/` directory with numbered agent rule files (`.md`)
- Agents ordered by priority (bmad-master first)
## Using BMad Agents in Cline
1. **Open Cline panel** in VS Code
2. **Type `@agent-name`** in the chat (e.g., `@dev`, `@sm`, `@architect`)
3. The agent adopts that persona for the conversation

View File

@@ -1,14 +0,0 @@
# BMad Method Guide for Cursor
For the complete workflow, see the [BMad Workflow Guide](../bmad-workflow-guide.md).
## Installation
When running `npx bmad-method install`, select **Cursor** as your IDE. This creates:
- `.bmad-core/` folder with all agents
- `.cursor/rules/` folder with agent rule files (`.mdc`)
## Using BMad Agents in Cursor
Type `@agent-name` in chat (Ctrl+L / Cmd+L) to activate an agent. Make sure you select the icon that looks like a small ruler if presented with multiple options in the popup window.

View File

@@ -1,31 +0,0 @@
# BMad Method Guide for Gemini CLI
For the complete workflow, see the [BMad Workflow Guide](../bmad-workflow-guide.md).
## Installation
When running `npx bmad-method install`, select **Gemini CLI** as your IDE. This creates:
- `.gemini/bmad-method/` directory with all agent context in GEMINI.md file
## Using BMad Agents with Gemini CLI
Simply mention the agent in your prompt:
- "As \*dev, implement the login feature"
- "Acting as \*architect, review this system design"
- "\*sm, create the next story for our project"
The Gemini CLI automatically loads the appropriate agent context.
## Gemini CLI-Specific Features
- **Context files**: All agents loaded as context in `.gemini/bmad-method/GEMINI.md`
- **Automatic loading**: GEMINI.md ensures agents are always available
- **Natural language**: No special syntax needed, just mention the agent
## Tips for Gemini CLI Users
- Be explicit about which agent you're addressing
- You can switch agents mid-conversation by mentioning a different one
- The CLI maintains context across your session

View File

@@ -1,42 +0,0 @@
# BMad Method Guide for GitHub Copilot
For the complete workflow, see the [BMad Workflow Guide](../bmad-workflow-guide.md).
## Installation
When running `npx bmad-method install`, select **GitHub Copilot** as your IDE. This command will perform the following actions:
- Create the `.bmad-core/` directory with all the agent rule files.
- Create the `.vscode/` directory and add a `settings.json` file if it does not already exist, and add the basic configuration to enable GitHub Copilot's agent mode.
- Create a chatmodes file under your .github folder for each specific agent being added
## Using BMAD Agents in GitHub Copilot
1. **Open GitHub Copilot chat** in VS Code (`⌃⌘I` on Mac, `Ctrl+Alt+I` on Windows/Linux).
2. Select the agent you want to use from the chat input's participant selector (e.g., `@workspace` > `dev`).
3. The agent adopts that persona for the conversation.
4. Use `*help` to see the commands available for the selected agent.
## Available Agents
You can switch between agents using the chat participant selector. The following agents are available for GitHub Copilot:
- `bmad-master` - Master Task Executor
- `dev` - Development expert
- `qa` - Quality Assurance specialist
- `ux-expert` - UX specialist
## GitHub Copilot-Specific Features
- **Settings**: Use the `.vscode/settings.json` file to configure Copilot behavior. The installer can configure these for you.
- `chat.agent.maxRequests`: Maximum requests per agent session (recommended: 15).
- `github.copilot.chat.agent.runTasks`: Allow agents to run workspace tasks (e.g., from `package.json` scripts).
- `github.copilot.chat.agent.autoFix`: Enable automatic error detection and fixing in generated code.
- `chat.tools.autoApprove`: Auto-approve ALL tools without confirmation (use with caution).
- **VS Code integration**: Works within VS Code's GitHub Copilot chat panel.
- **Tool Confirmation**: Copilot will ask for confirmation before running tools that can modify files. You can approve a tool once, for the session, or always.
## Tips for GitHub Copilot Users
- You can use a `.github/copilot-instructions.md` file to provide additional context or instructions for your projects that are not covered by the BMAD framework.
- BMAD agents can come with a pre-configured set of tools. You can see which tools an agent uses by looking at the `tools` section in its `.github/chatmodes/[agent].chatmode.md` file.

View File

@@ -1,15 +0,0 @@
# BMad Method Guide for Roo Code
For the complete workflow, see the [BMad Workflow Guide](../bmad-workflow-guide.md).
## Installation
When running `npx bmad-method install`, select **Roo Code** as your IDE. This creates:
- `.bmad-core/` folder with all agents
- `.roomodes` file in project root with custom modes
## Roo Code-Specific Features
- **Mode file**: `.roomodes` in project root
- **Mode switching**: Use mode selecto

View File

@@ -1,14 +0,0 @@
# BMad Method Guide for Trae
For the complete workflow, see the [BMad Workflow Guide](../bmad-workflow-guide.md).
## Installation
When running `npx bmad-method install`, select **Trae** as your IDE. This creates:
- `.bmad-core/` folder with all agents
- `.trae/rules/` folder with agent rule files (`.md`)
## Using BMad Agents in Trae
Type `@agent-name` in chat to activate an agent.

View File

@@ -1,14 +0,0 @@
# BMad Method Guide for Windsurf
For the complete workflow, see the [BMad Workflow Guide](../bmad-workflow-guide.md).
## Installation
When running `npx bmad-method install`, select **Windsurf** as your IDE. This creates:
- `.bmad-core/` folder with all agents
- `.windsurf/rules/` folder with agent rule files (`.md`)
## Using BMad Agents in Windsurf
Type `@agent-name` in chat to activate an agent.

View File

@@ -1,166 +0,0 @@
# BMad Method Universal Workflow Guide
This guide outlines the core BMad workflow that applies regardless of which AI-powered IDE you're using.
## Overview
The BMad Method follows a structured approach to AI-assisted software development:
1. **Install BMad** in your project
2. **Plan with Gemini** using team-fullstack
3. **Organize with bmad-master** (document sharding)
4. **Develop iteratively** with SM → Dev cycles
## The Complete Workflow
### Phase 1: Project Setup
1. **Install BMad in your project**:
```bash
npx bmad-method install
```
- Choose "Complete installation"
- Select your IDE (Cursor, Claude Code, Windsurf, Trae, Roo Code, or GitHub Copilot)
2. **Verify installation**:
- `.bmad-core/` folder created with all agents
- IDE-specific integration files created
- All agent commands/rules/modes available
### Phase 2: Ideation & Planning (Gemini)
Use Google's Gemini for collaborative planning with the full team:
1. **Open [Google Gems](https://gemini.google.com/gems/view)**
2. **Create a new Gem**:
- Give it a title and description (e.g., "BMad Team Fullstack")
3. **Load team-fullstack**:
- Copy contents of: `web-bundles/teams/team-fullstack.txt` from your project
- Paste this content into the Gem setup to configure the team
4. **Collaborate with the team**:
- Business Analyst: Requirements gathering
- Product Manager: Feature prioritization
- Solution Architect: Technical design
- UX Expert: User experience design
### Example Gemini Sessions:
```text
"I want to build a [type] application that [core purpose].
Help me brainstorm features and create a comprehensive PRD."
"Based on this PRD, design a scalable technical architecture
that can handle [specific requirements]."
```
5. **Export planning documents**:
- Copy the PRD output and save as `docs/prd.md` in your project
- Copy the architecture output and save as `docs/architecture.md` in your project
### Phase 3: Document Organization (IDE)
Switch back to your IDE for document management:
1. **Load bmad-master agent** (syntax varies by IDE)
2. **Shard the PRD**:
```
*shard-doc docs/prd.md prd
```
3. **Shard the architecture**:
```
*shard-doc docs/architecture.md architecture
```
**Result**: Organized folder structure:
- `docs/prd/` - Broken down PRD sections
- `docs/architecture/` - Broken down architecture sections
### Phase 4: Iterative Development
Follow the SM → Dev cycle for systematic story development:
#### Story Creation (Scrum Master)
1. **Start new chat/conversation**
2. **Load SM agent**
3. **Execute**: `*create` (runs create-next-story task)
4. **Review generated story** in `docs/stories/`
5. **Update status**: Change from "Draft" to "Approved"
#### Story Implementation (Developer)
1. **Start new chat/conversation**
2. **Load Dev agent**
3. **Agent asks**: Which story to implement
4. **Follow development tasks**
5. **Complete implementation**
6. **Update status**: Change to "Done"
#### Repeat Until Complete
- **SM**: Create next story → Review → Approve
- **Dev**: Implement story → Complete → Mark done
- **Continue**: Until all features implemented
## IDE-Specific Syntax
### Agent Loading Syntax by IDE:
- **Claude Code**: `/agent-name` (e.g., `/bmad-master`)
- **Cursor**: `@agent-name` (e.g., `@bmad-master`)
- **Gemini CLI**: `*agent-name` (e.g., `*bmad-master`)
- **Windsurf**: `@agent-name` (e.g., `@bmad-master`)
- **Trae**: `@agent-name` (e.g., `@bmad-master`)
- **Roo Code**: Select mode from mode selector (e.g., `bmad-master`)
- **GitHub Copilot**: Open the Chat view (`⌃⌘I` on Mac, `Ctrl+Alt+I` on Windows/Linux) and select **Agent** from the chat mode selector.
### Chat Management:
- **Claude Code, Cursor, Windsurf, Trae**: Start new chats when switching agents
- **Roo Code**: Switch modes within the same conversation
## Available Agents
### Core Development Agents:
- **bmad-master**: Universal task executor, document management
- **sm**: Scrum Master for story creation and agile process
- **dev**: Full-stack developer for implementation
- **architect**: Solution architect for technical design
### Specialized Agents:
- **pm**: Product manager for planning and prioritization
- **analyst**: Business analyst for requirements
- **qa**: QA specialist for testing strategies
- **po**: Product owner for backlog management
- **ux-expert**: UX specialist for design
## Key Principles
1. **Agent Specialization**: Each agent has specific expertise and responsibilities
2. **Clean Handoffs**: Always start fresh when switching between agents
3. **Status Tracking**: Maintain story statuses (Draft → Approved → InProgress → Done)
4. **Iterative Development**: Complete one story before starting the next
5. **Documentation First**: Always start with solid PRD and architecture
## Common Commands
Every agent supports these core commands:
- `*help` - Show available commands
- `*status` - Show current context/progress
- `*exit` - Exit the agent mode
## Success Tips
- **Use Gemini for big picture planning** - The team-fullstack bundle provides collaborative expertise
- **Use bmad-master for document organization** - Sharding creates manageable chunks
- **Follow the SM → Dev cycle religiously** - This ensures systematic progress
- **Keep conversations focused** - One agent, one task per conversation
- **Review everything** - Always review and approve before marking complete
This workflow ensures systematic, AI-assisted development following agile principles with clear separation of concerns and consistent progress tracking.

View File

@@ -0,0 +1,248 @@
# Enhanced IDE Development Workflow
This is a simple step-by-step guide to help you efficiently manage your development workflow using the BMad Method. The workflow integrates the Test Architect (QA agent) throughout the development lifecycle to ensure quality, prevent regressions, and maintain high standards. Refer to the **[<ins>User Guide</ins>](user-guide.md)** for any scenario that is not covered here.
## Create New Branch
1. **Start new branch**
## Story Creation (Scrum Master)
1. **Start new chat/conversation**
2. **Load SM agent**
3. **Execute**: `*draft` (runs create-next-story task)
4. **Review generated story** in `docs/stories/`
5. **Update status**: Change from "Draft" to "Approved"
## Story Implementation (Developer)
1. **Start new chat/conversation**
2. **Load Dev agent**
3. **Execute**: `*develop-story {selected-story}` (runs execute-checklist task)
4. **Review generated report** in `{selected-story}`
## Test Architect Integration Throughout Workflow
The Test Architect (Quinn) provides comprehensive quality assurance throughout the development lifecycle. Here's how to leverage each capability at the right time.
**Command Aliases:** Documentation uses short forms (`*risk`, `*design`, `*nfr`, `*trace`) for the full commands (`*risk-profile`, `*test-design`, `*nfr-assess`, `*trace-requirements`).
### Quick Command Reference
| **Stage** | **Command** | **Purpose** | **Output** | **Priority** |
| ------------------------ | ----------- | --------------------------------------- | --------------------------------------------------------------- | --------------------------- |
| **After Story Approval** | `*risk` | Identify integration & regression risks | `docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md` | High for complex/brownfield |
| | `*design` | Create test strategy for dev | `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md` | High for new features |
| **During Development** | `*trace` | Verify test coverage | `docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md` | Medium |
| | `*nfr` | Validate quality attributes | `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md` | High for critical features |
| **After Development** | `*review` | Comprehensive assessment | QA Results in story + `docs/qa/gates/{epic}.{story}-{slug}.yml` | **Required** |
| **Post-Review** | `*gate` | Update quality decision | Updated `docs/qa/gates/{epic}.{story}-{slug}.yml` | As needed |
### Stage 1: After Story Creation (Before Dev Starts)
**RECOMMENDED - Set Developer Up for Success:**
```bash
# 1. RISK ASSESSMENT (Run FIRST for complex stories)
@qa *risk {approved-story}
# Identifies:
# - Technical debt impact
# - Integration complexity
# - Regression potential (1-9 scoring)
# - Mitigation strategies
# Critical for: Brownfield, API changes, data migrations
# 2. TEST DESIGN (Run SECOND to guide implementation)
@qa *design {approved-story}
# Provides:
# - Test scenarios per acceptance criterion
# - Test level recommendations (unit/integration/E2E)
# - Risk-based priorities (P0/P1/P2)
# - Test data requirements
# Share with Dev: Include in story comments or attach to ticket
```
### Stage 2: During Development (Mid-Implementation Checkpoints)
**Developer Self-Service Quality Checks:**
```bash
# 3. REQUIREMENTS TRACING (Verify coverage mid-development)
@qa *trace {story-in-progress}
# Validates:
# - All acceptance criteria have tests
# - No missing test scenarios
# - Appropriate test levels
# - Given-When-Then documentation clarity
# Run when: After writing initial tests
# 4. NFR VALIDATION (Check quality attributes)
@qa *nfr {story-in-progress}
# Assesses:
# - Security: Authentication, authorization, data protection
# - Performance: Response times, resource usage
# - Reliability: Error handling, recovery
# - Maintainability: Code quality, documentation
# Run when: Before marking "Ready for Review"
```
### Stage 3: Story Review (Quality Gate Assessment)
**REQUIRED - Comprehensive Test Architecture Review:**
**Prerequisite:** All tests green locally; lint & type checks pass.
```bash
# 5. FULL REVIEW (Standard review process)
@qa *review {completed-story}
```
**What Happens During Review:**
1. **Deep Code Analysis**
- Architecture pattern compliance
- Code quality and maintainability
- Security vulnerability scanning
- Performance bottleneck detection
2. **Active Refactoring**
- Improves code directly when safe
- Fixes obvious issues immediately
- Suggests complex refactoring for dev
3. **Test Validation**
- Coverage at all levels (unit/integration/E2E)
- Test quality (no flaky tests, proper assertions)
- Regression test adequacy
4. **Gate Decision**
- Creates: `docs/qa/gates/{epic}.{story}-{slug}.yml`
- Adds: QA Results section to story file
- Status: PASS/CONCERNS/FAIL/WAIVED
### Stage 4: Post-Review (After Addressing Issues)
**Update Gate Status After Fixes:**
```bash
# 6. GATE UPDATE (Document final decision)
@qa *gate {reviewed-story}
# Updates: Quality gate with new status
# Use when: After addressing review feedback
# Documents: What was fixed, what was waived
```
### Understanding Gate Decisions
| **Status** | **Meaning** | **Action Required** | **Can Proceed?** |
| ------------ | -------------------------------------------- | ----------------------- | ---------------- |
| **PASS** | All critical requirements met | None | ✅ Yes |
| **CONCERNS** | Non-critical issues found | Team review recommended | ⚠️ With caution |
| **FAIL** | Critical issues (security, missing P0 tests) | Must fix | ❌ No |
| **WAIVED** | Issues acknowledged and accepted | Document reasoning | ✅ With approval |
### Risk-Based Testing Strategy
The Test Architect uses risk scoring to prioritize testing:
| **Risk Score** | **Calculation** | **Testing Priority** | **Gate Impact** |
| -------------- | ------------------------------ | ------------------------- | ------------------------ |
| **9** | High probability × High impact | P0 - Must test thoroughly | FAIL if untested |
| **6** | Medium-high combinations | P1 - Should test well | CONCERNS if gaps |
| **4** | Medium combinations | P1 - Should test | CONCERNS if notable gaps |
| **2-3** | Low-medium combinations | P2 - Nice to have | Note in review |
| **1** | Minimal risk | P2 - Minimal | Note in review |
### Special Situations & Best Practices
#### High-Risk or Brownfield Stories
```bash
# ALWAYS run this sequence:
@qa *risk {story} # First - identify dangers
@qa *design {story} # Second - plan defense
# Then during dev:
@qa *trace {story} # Verify regression coverage
@qa *nfr {story} # Check performance impact
# Finally:
@qa *review {story} # Deep integration analysis
```
#### Complex Integrations
- Run `*trace` multiple times during development
- Focus on integration test coverage
- Use `*nfr` to validate cross-system performance
- Review with extra attention to API contracts
#### Performance-Critical Features
- Run `*nfr` early and often (not just at review)
- Establish performance baselines before changes
- Document acceptable performance degradation
- Consider load testing requirements in `*design`
### Test Quality Standards Enforced
Quinn ensures all tests meet these standards:
- **No Flaky Tests**: Proper async handling, explicit waits
- **No Hard Waits**: Dynamic strategies only (polling, events)
- **Stateless**: Tests run independently and in parallel
- **Self-Cleaning**: Tests manage their own test data
- **Appropriate Levels**: Unit for logic, integration for interactions, E2E for journeys
- **Clear Assertions**: Keep assertions in tests, not buried in helpers
### Documentation & Audit Trail
All Test Architect activities create permanent records:
- **Assessment Reports**: Timestamped analysis in `docs/qa/assessments/`
- **Gate Files**: Decision records in `docs/qa/gates/`
- **Story Updates**: QA Results sections in story files
- **Traceability**: Requirements to test mapping maintained
## Commit Changes and Push
1. **Commit changes**
2. **Push to remote**
## Complete Development Cycle Flow
### The Full Workflow with Test Architect
1. **SM**: Create next story → Review → Approve
2. **QA (Optional)**: Risk assessment (`*risk`) → Test design (`*design`)
3. **Dev**: Implement story → Write tests → Complete
4. **QA (Optional)**: Mid-dev checks (`*trace`, `*nfr`)
5. **Dev**: Mark Ready for Review
6. **QA (Required)**: Review story (`*review`) → Gate decision
7. **Dev (If needed)**: Address issues
8. **QA (If needed)**: Update gate (`*gate`)
9. **Commit**: All changes
10. **Push**: To remote
11. **Continue**: Until all features implemented
### Quick Decision Guide
**Should I run Test Architect commands?**
| **Scenario** | **Before Dev** | **During Dev** | **After Dev** |
| ------------------------ | ------------------------------- | ---------------------------- | ---------------------------- |
| **Simple bug fix** | Optional | Optional | Required `*review` |
| **New feature** | Recommended `*risk`, `*design` | Optional `*trace` | Required `*review` |
| **Brownfield change** | **Required** `*risk`, `*design` | Recommended `*trace`, `*nfr` | Required `*review` |
| **API modification** | **Required** `*risk`, `*design` | **Required** `*trace` | Required `*review` |
| **Performance-critical** | Recommended `*design` | **Required** `*nfr` | Required `*review` |
| **Data migration** | **Required** `*risk`, `*design` | **Required** `*trace` | Required `*review` + `*gate` |
### Success Metrics
The Test Architect helps achieve:
- **Zero regression defects** in production
- **100% requirements coverage** with tests
- **Clear quality gates** for go/no-go decisions
- **Documented risk acceptance** for technical debt
- **Consistent test quality** across the team
- **Shift-left testing** with early risk identification

View File

@@ -14,7 +14,7 @@ A pull request (PR) is how you propose changes to a project on GitHub. Think of
- **For bug fixes**: Create an issue using the [bug report template](https://github.com/bmadcode/bmad-method/issues/new?template=bug_report.md)
- **For new features**:
1. Discuss in Discord [#general-dev channel](https://discord.gg/g6ypHytrCB)
1. Discuss in Discord [#general-dev channel](https://discord.gg/gk8jAdXWmj)
2. Create an issue using the [feature request template](https://github.com/bmadcode/bmad-method/issues/new?template=feature_request.md)
- **For large changes**: Always open an issue first to discuss alignment
@@ -131,7 +131,7 @@ git push origin fix/typo-in-readme
## Need Help?
- 💬 Join our [Discord Community](https://discord.gg/g6ypHytrCB) for real-time help:
- 💬 Join our [Discord Community](https://discord.gg/gk8jAdXWmj) for real-time help:
- **#general-dev** - Technical questions and feature discussions
- **#bugs-issues** - Get help with bugs before filing issues
- 💬 Ask questions in [GitHub Discussions](https://github.com/bmadcode/bmad-method/discussions)

File diff suppressed because it is too large Load Diff

View File

@@ -2,10 +2,10 @@
> **HIGHLY RECOMMENDED: Use Gemini Web or Gemini CLI for Brownfield Documentation Generation!**
>
> Gemini Web's 1M+ token context window or Gemini CLI (when its working) can analyze your ENTIRE codebase or critical sections of it all at once (obviously within reason):
> Gemini Web's 1M+ token context window or Gemini CLI (when it's working) can analyze your ENTIRE codebase, or critical sections of it, all at once (obviously within reason):
>
> - Upload via GitHub URL or use gemini cli in the project folder
> - If in the web: Upload up to 1000 files or the zipped project or just give it the github url
> - If working in the web: use `npx bmad-method flatten` to flatten your project into a single file, then upload that file to your web agent.
## What is Brownfield Development?
@@ -22,10 +22,13 @@ Brownfield development refers to adding features, fixing bugs, or modernizing ex
## When NOT to use a Brownfield Flow
If you have just completed an MVP with BMad, and you want to continue with post-MVP, its easier to just talk to the PM and ask him to work with you to create a new epic to add into the PRD, shard out the epic, update any architecture documents with the architect, and just go from there.
If you have just completed an MVP with BMad, and you want to continue with post-MVP, its easier to just talk to the PM and ask it to work with you to create a new epic to add into the PRD, shard out the epic, update any architecture documents with the architect, and just go from there.
## The Complete Brownfield Workflow
1. **Follow the [<ins>User Guide - Installation</ins>](user-guide.md#installation) steps to setup your agent in the web.**
2. **Generate a 'flattened' single file of your entire codebase** run: `npx bmad-method flatten`
### Choose Your Approach
#### Approach A: PRD-First (Recommended if adding very large and complex new features, single or multiple epics or massive changes)
@@ -48,11 +51,11 @@ If you have just completed an MVP with BMad, and you want to continue with post-
#### Phase 1: Define Requirements First
**In Gemini Web (with your codebase uploaded):**
**In Gemini Web (with your flattened-codebase.xml uploaded):**
```bash
@pm
*create-doc brownfield-prd
*create-brownfield-prd
```
The PM will:
@@ -69,11 +72,11 @@ The PM will:
**Still in Gemini Web, now with PRD context:**
```bash
@analyst
@architect
*document-project
```
The analyst will:
The architect will:
- **Ask about your focus** if no PRD was provided
- **Offer options**: Create PRD, provide requirements, or describe the enhancement
@@ -82,11 +85,11 @@ The analyst will:
- **Skip unrelated areas** to keep docs lean
- **Generate ONE architecture document** for all environments
The analyst creates:
The architect creates:
- **One comprehensive architecture document** following fullstack-architecture template
- **Covers all system aspects** in a single file
- **Easy to copy and save** as `docs/project-architecture.md`
- **Easy to copy and save** as `docs/architecture.md`
- **Can be sharded later** in IDE if desired
For example, if you say "Add payment processing to user service":
@@ -104,22 +107,21 @@ For example, if you say "Add payment processing to user service":
1. **Go to Gemini Web** (gemini.google.com)
2. **Upload your project**:
- **Option A**: Paste your GitHub repository URL directly
- **Option B**: Upload up to 1000 files from your src/project folder
- **Option C**: Zip your project and upload the archive
3. **Load the analyst agent**: Upload `dist/agents/analyst.txt`
- **Option B**: Upload your flattened-codebase.xml file
3. **Load the architect agent**: Upload `dist/agents/architect.txt`
4. **Run documentation**: Type `*document-project`
The analyst will generate comprehensive documentation of everything.
The architect will generate comprehensive documentation of everything.
#### Phase 2: Plan Your Enhancement
#### Option A: Full Brownfield Workflow (Recommended for Major Changes)
##### Option A: Full Brownfield Workflow (Recommended for Major Changes)
**1. Create Brownfield PRD**:
```bash
@pm
*create-doc brownfield-prd
*create-brownfield-prd
```
The PM agent will:
@@ -146,7 +148,7 @@ The PM agent will:
```bash
@architect
*create-doc brownfield-architecture
*create-brownfield-architecture
```
The architect will:
@@ -157,13 +159,13 @@ The architect will:
- **Identify technical risks**
- **Define compatibility requirements**
#### Option B: Quick Enhancement (For Focused Changes)
##### Option B: Quick Enhancement (For Focused Changes)
**For Single Epic Without Full PRD**:
```bash
@pm
*brownfield-create-epic
*create-brownfield-epic
```
Use when:
@@ -177,7 +179,7 @@ Use when:
```bash
@pm
*brownfield-create-story
*create-brownfield-story
```
Use when:
@@ -191,7 +193,7 @@ Use when:
```bash
@po
*execute-checklist po-master-checklist
*execute-checklist-po
```
The PO ensures:
@@ -201,26 +203,28 @@ The PO ensures:
- Risk mitigation strategies in place
- Clear integration approach
### Phase 4: Transition to Development
### Phase 4: Save and Shard Documents
Follow the enhanced IDE Development Workflow:
1. **Ensure documents are in project**:
- Copy `docs/prd.md` (or brownfield-prd.md)
- Copy `docs/architecture.md` (or brownfield-architecture.md)
2. **Shard documents**:
1. Save your PRD and Architecture as:
docs/prd.md
docs/architecture.md
(Note: You can optionally prefix with 'brownfield-' if managing multiple versions)
2. Shard your docs:
In your IDE
```bash
@po
# Ask to shard docs/prd.md
shard docs/prd.md
```
3. **Development cycle**:
- **SM** creates stories with integration awareness
- **Dev** implements with existing code respect
- **QA** reviews for compatibility and improvements
```bash
@po
shard docs/architecture.md
```
### Phase 5: Transition to Development
**Follow the [<ins>Enhanced IDE Development Workflow</ins>](enhanced-ide-development-workflow.md)**
## Brownfield Best Practices
@@ -252,12 +256,172 @@ Brownfield changes should:
### 4. Test Integration Thoroughly
Focus testing on:
#### Why the Test Architect is Critical for Brownfield
- Integration points
- Existing functionality (regression)
- Performance impact
- Data migrations
In brownfield projects, the Test Architect (Quinn) becomes your safety net against breaking existing functionality. Unlike greenfield where you're building fresh, brownfield requires careful validation that new changes don't destabilize what already works.
#### Brownfield-Specific Testing Challenges
The Test Architect addresses unique brownfield complexities:
| **Challenge** | **How Test Architect Helps** | **Command** |
| --------------------------- | ------------------------------------------------- | ------------------- |
| **Regression Risks** | Identifies which existing features might break | `*risk` |
| **Legacy Dependencies** | Maps integration points and hidden dependencies | `*trace` |
| **Performance Degradation** | Validates no slowdown in existing flows | `*nfr` |
| **Coverage Gaps** | Finds untested legacy code that new changes touch | `*design` |
| **Breaking Changes** | Detects API/contract violations | `*review` |
| **Migration Safety** | Validates data transformations and rollback plans | `*risk` + `*review` |
#### Complete Test Architect Workflow for Brownfield
##### Stage 1: Before Development (Risk & Strategy)
**CRITICAL FOR BROWNFIELD - Run These First:**
```bash
# 1. RISK ASSESSMENT (Run IMMEDIATELY after story creation)
@qa *risk {brownfield-story}
# Identifies: Legacy dependencies, breaking changes, integration points
# Output: docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
# Brownfield Focus:
# - Regression probability scoring
# - Affected downstream systems
# - Data migration risks
# - Rollback complexity
# 2. TEST DESIGN (After risk assessment)
@qa *design {brownfield-story}
# Creates: Regression test strategy + new feature tests
# Output: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
# Brownfield Focus:
# - Existing functionality that needs regression tests
# - Integration test requirements
# - Performance benchmarks to maintain
# - Feature flag test scenarios
```
##### Stage 2: During Development (Continuous Validation)
**Monitor Integration Health While Coding:**
```bash
# 3. REQUIREMENTS TRACING (Mid-development checkpoint)
@qa *trace {brownfield-story}
# Maps: New requirements + existing functionality preservation
# Output: docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
# Brownfield Focus:
# - Existing features that must still work
# - New/old feature interactions
# - API contract preservation
# - Missing regression test coverage
# 4. NFR VALIDATION (Before considering "done")
@qa *nfr {brownfield-story}
# Validates: Performance, security, reliability unchanged
# Output: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
# Brownfield Focus:
# - Performance regression detection
# - Security implications of integrations
# - Backward compatibility validation
# - Load/stress on legacy components
```
##### Stage 3: Code Review (Deep Integration Analysis)
**Comprehensive Brownfield Review:**
```bash
# 5. FULL REVIEW (When development complete)
@qa *review {brownfield-story}
# Performs: Deep analysis + active refactoring
# Outputs:
# - QA Results in story file
# - Gate file: docs/qa/gates/{epic}.{story}-{slug}.yml
```
The review specifically analyzes:
- **API Breaking Changes**: Validates all existing contracts maintained
- **Data Migration Safety**: Checks transformation logic and rollback procedures
- **Performance Regression**: Compares against baseline metrics
- **Integration Points**: Validates all touchpoints with legacy code
- **Feature Flag Logic**: Ensures proper toggle behavior
- **Dependency Impacts**: Maps affected downstream systems
##### Stage 4: Post-Review (Gate Updates)
```bash
# 6. GATE STATUS UPDATE (After addressing issues)
@qa *gate {brownfield-story}
# Updates: Quality gate decision after fixes
# Output: docs/qa/gates/{epic}.{story}-{slug}.yml
# Brownfield Considerations:
# - May WAIVE certain legacy code issues
# - Documents technical debt acceptance
# - Tracks migration progress
```
#### Brownfield-Specific Risk Scoring
The Test Architect uses enhanced risk scoring for brownfield:
| **Risk Category** | **Brownfield Factors** | **Impact on Gate** |
| ---------------------- | ------------------------------------------ | ------------------- |
| **Regression Risk** | Number of integration points × Age of code | Score ≥9 = FAIL |
| **Data Risk** | Migration complexity × Data volume | Score ≥6 = CONCERNS |
| **Performance Risk** | Current load × Added complexity | Score ≥6 = CONCERNS |
| **Compatibility Risk** | API consumers × Contract changes | Score ≥9 = FAIL |
#### Brownfield Testing Standards
Quinn enforces additional standards for brownfield:
- **Regression Test Coverage**: Every touched legacy module needs tests
- **Performance Baselines**: Must maintain or improve current metrics
- **Rollback Procedures**: Every change needs a rollback plan
- **Feature Flags**: All risky changes behind toggles
- **Integration Tests**: Cover all legacy touchpoints
- **Contract Tests**: Validate API compatibility
- **Data Validation**: Migration correctness checks
#### Quick Reference: Brownfield Test Commands
| **Scenario** | **Commands to Run** | **Order** | **Why Critical** |
| --------------------------------- | ---------------------------------------------------- | ---------- | ----------------------------- |
| **Adding Feature to Legacy Code** | `*risk` → `*design` → `*trace` → `*review` | Sequential | Map all dependencies first |
| **API Modification** | `*risk` → `*design` → `*nfr` → `*review` | Sequential | Prevent breaking consumers |
| **Performance-Critical Change** | `*nfr` early and often → `*review` | Continuous | Catch degradation immediately |
| **Data Migration** | `*risk` → `*design` → `*trace` → `*review` → `*gate` | Full cycle | Ensure data integrity |
| **Bug Fix in Complex System** | `*risk` → `*trace` → `*review` | Focused | Prevent side effects |
#### Integration with Brownfield Scenarios
**Scenario-Specific Guidance:**
1. **Legacy Code Modernization**
- Start with `*risk` to map all dependencies
- Use `*design` to plan strangler fig approach
- Run `*trace` frequently to ensure nothing breaks
- `*review` with focus on gradual migration
2. **Adding Features to Monolith**
- `*risk` identifies integration complexity
- `*design` plans isolation strategies
- `*nfr` monitors performance impact
- `*review` validates no monolith degradation
3. **Microservice Extraction**
- `*risk` maps service boundaries
- `*trace` ensures functionality preservation
- `*nfr` validates network overhead acceptable
- `*gate` documents accepted trade-offs
4. **Database Schema Changes**
- `*risk` assesses migration complexity
- `*design` plans backward-compatible approach
- `*trace` maps all affected queries
- `*review` validates migration safety
### 5. Communicate Changes
@@ -274,29 +438,63 @@ Document:
1. Document existing system
2. Create brownfield PRD focusing on integration
3. Architecture emphasizes compatibility
4. Stories include integration tasks
3. **Test Architect Early Involvement**:
- Run `@qa *risk` on draft stories to identify integration risks
- Use `@qa *design` to plan regression test strategy
4. Architecture emphasizes compatibility
5. Stories include integration tasks with test requirements
6. **During Development**:
- Developer runs `@qa *trace` to verify coverage
- Use `@qa *nfr` to monitor performance impact
7. **Review Stage**: `@qa *review` validates integration safety
### Scenario 2: Modernizing Legacy Code
1. Extensive documentation phase
2. PRD includes migration strategy
3. Architecture plans gradual transition
4. Stories follow strangler fig pattern
3. **Test Architect Strategy Planning**:
- `@qa *risk` assesses modernization complexity
- `@qa *design` plans parallel testing approach
4. Architecture plans gradual transition (strangler fig pattern)
5. Stories follow incremental modernization with:
- Regression tests for untouched legacy code
- Integration tests for new/old boundaries
- Performance benchmarks at each stage
6. **Continuous Validation**: Run `@qa *trace` after each increment
7. **Gate Management**: Use `@qa *gate` to track technical debt acceptance
### Scenario 3: Bug Fix in Complex System
1. Document relevant subsystems
2. Use `brownfield-create-story` for focused fix
3. Include regression test requirements
4. QA validates no side effects
2. Use `create-brownfield-story` for focused fix
3. **Test Architect Risk Assessment**: Run `@qa *risk` to identify side effect potential
4. Include regression test requirements from `@qa *design` output
5. **During Fix**: Use `@qa *trace` to map affected functionality
6. **Before Commit**: Run `@qa *review` for comprehensive validation
7. Test Architect validates no side effects using:
- Risk profiling for side effect analysis (probability × impact scoring)
- Trace matrix to ensure fix doesn't break related features
- NFR assessment to verify performance/security unchanged
- Gate decision documents fix safety
### Scenario 4: API Integration
1. Document existing API patterns
2. PRD defines integration requirements
3. Architecture ensures consistent patterns
4. Stories include API documentation updates
3. **Test Architect Contract Analysis**:
- `@qa *risk` identifies breaking change potential
- `@qa *design` creates contract test strategy
4. Architecture ensures consistent patterns
5. **API Testing Focus**:
- Contract tests for backward compatibility
- Integration tests for new endpoints
- Performance tests for added load
6. Stories include API documentation updates
7. **Validation Checkpoints**:
- `@qa *trace` maps all API consumers
- `@qa *nfr` validates response times
- `@qa *review` ensures no breaking changes
8. **Gate Decision**: Document any accepted breaking changes with migration path
## Troubleshooting
@@ -310,7 +508,7 @@ Document:
### "Too much boilerplate for small changes"
**Solution**: Use `brownfield-create-story` instead of full workflow
**Solution**: Use `create-brownfield-story` instead of full workflow
### "Integration points unclear"
@@ -322,19 +520,37 @@ Document:
```bash
# Document existing project
@analyst → *document-project
@architect *document-project
# Create enhancement PRD
@pm *create-doc brownfield-prd
@pm *create-brownfield-prd
# Create architecture with integration focus
@architect *create-doc brownfield-architecture
@architect *create-brownfield-architecture
# Quick epic creation
@pm → *brownfield-create-epic
@pm *create-brownfield-epic
# Single story creation
@pm → *brownfield-create-story
@pm *create-brownfield-story
```
### Test Architect Commands for Brownfield
Note: Short forms shown below. Full commands: `*risk-profile`, `*test-design`, `*nfr-assess`, `*trace-requirements`
```bash
# BEFORE DEVELOPMENT (Planning)
@qa *risk {story} # Assess regression & integration risks
@qa *design {story} # Plan regression + new feature tests
# DURING DEVELOPMENT (Validation)
@qa *trace {story} # Verify coverage of old + new
@qa *nfr {story} # Check performance degradation
# AFTER DEVELOPMENT (Review)
@qa *review {story} # Deep integration analysis
@qa *gate {story} # Update quality decision
```
### Decision Tree
@@ -349,13 +565,33 @@ Do you have a large codebase or monorepo?
Is this a major enhancement affecting multiple systems?
├─ Yes → Full Brownfield Workflow
│ └─ ALWAYS run Test Architect *risk + *design first
└─ No → Is this more than a simple bug fix?
├─ Yes → brownfield-create-epic
└─ No → brownfield-create-story
├─ Yes → *create-brownfield-epic
│ └─ Run Test Architect *risk for integration points
└─ No → *create-brownfield-story
└─ Still run *risk if touching critical paths
Does the change touch legacy code?
├─ Yes → Test Architect is MANDATORY
│ ├─ *risk → Identify regression potential
│ ├─ *design → Plan test coverage
│ └─ *review → Validate no breakage
└─ No → Test Architect is RECOMMENDED
└─ *review → Ensure quality standards
```
## Conclusion
Brownfield development with BMad-Method provides structure and safety when modifying existing systems. The key is providing comprehensive context through documentation, using specialized templates that consider integration requirements, and following workflows that respect existing constraints while enabling progress.
Brownfield development with BMad Method provides structure and safety when modifying existing systems. The Test Architect becomes your critical safety net, using risk assessment, regression testing, and continuous validation to ensure new changes don't destabilize existing functionality.
Remember: **Document First, Plan Carefully, Integrate Safely**
**The Brownfield Success Formula:**
1. **Document First** - Understand what exists
2. **Assess Risk Early** - Use Test Architect `*risk` before coding
3. **Plan Test Strategy** - Design regression + new feature tests
4. **Validate Continuously** - Check integration health during development
5. **Review Comprehensively** - Deep analysis before committing
6. **Gate Decisively** - Document quality decisions
Remember: **In brownfield, the Test Architect isn't optional - it's your insurance policy against breaking production.**

119
eslint.config.mjs Normal file
View File

@@ -0,0 +1,119 @@
import js from '@eslint/js';
import eslintConfigPrettier from 'eslint-config-prettier/flat';
import nodePlugin from 'eslint-plugin-n';
import unicorn from 'eslint-plugin-unicorn';
import yml from 'eslint-plugin-yml';
export default [
// Global ignores for files/folders that should not be linted
{
ignores: ['dist/**', 'coverage/**', '**/*.min.js'],
},
// Base JavaScript recommended rules
js.configs.recommended,
// Node.js rules
...nodePlugin.configs['flat/mixed-esm-and-cjs'],
// Unicorn rules (modern best practices)
unicorn.configs.recommended,
// YAML linting
...yml.configs['flat/recommended'],
// Place Prettier last to disable conflicting stylistic rules
eslintConfigPrettier,
// Project-specific tweaks
{
rules: {
// Allow console for CLI tools in this repo
'no-console': 'off',
// Enforce .yaml file extension for consistency
'yml/file-extension': [
'error',
{
extension: 'yaml',
caseSensitive: true,
},
],
// Prefer double quotes in YAML wherever quoting is used, but allow the other to avoid escapes
'yml/quotes': [
'error',
{
prefer: 'double',
avoidEscape: true,
},
],
// Relax some Unicorn rules that are too opinionated for this codebase
'unicorn/prevent-abbreviations': 'off',
'unicorn/no-null': 'off',
},
},
// CLI/CommonJS scripts under tools/**
{
files: ['tools/**/*.js'],
rules: {
// Allow CommonJS patterns for Node CLI scripts
'unicorn/prefer-module': 'off',
'unicorn/import-style': 'off',
'unicorn/no-process-exit': 'off',
'n/no-process-exit': 'off',
'unicorn/no-await-expression-member': 'off',
'unicorn/prefer-top-level-await': 'off',
// Avoid failing CI on incidental unused vars in internal scripts
'no-unused-vars': 'off',
// Reduce style-only churn in internal tools
'unicorn/prefer-ternary': 'off',
'unicorn/filename-case': 'off',
'unicorn/no-array-reduce': 'off',
'unicorn/no-array-callback-reference': 'off',
'unicorn/consistent-function-scoping': 'off',
'n/no-extraneous-require': 'off',
'n/no-extraneous-import': 'off',
'n/no-unpublished-require': 'off',
'n/no-unpublished-import': 'off',
// Some scripts intentionally use globals provided at runtime
'no-undef': 'off',
// Additional relaxed rules for legacy/internal scripts
'no-useless-catch': 'off',
'unicorn/prefer-number-properties': 'off',
'no-unreachable': 'off',
},
},
// ESLint config file should not be checked for publish-related Node rules
{
files: ['eslint.config.mjs'],
rules: {
'n/no-unpublished-import': 'off',
},
},
// YAML workflow templates allow empty mapping values intentionally
{
files: ['bmad-core/workflows/**/*.yaml'],
rules: {
'yml/no-empty-mapping-value': 'off',
},
},
// GitHub workflow files in this repo may use empty mapping values
{
files: ['.github/workflows/**/*.yaml'],
rules: {
'yml/no-empty-mapping-value': 'off',
},
},
// Other GitHub YAML files may intentionally use empty values and reserved filenames
{
files: ['.github/**/*.yaml'],
rules: {
'yml/no-empty-mapping-value': 'off',
'unicorn/filename-case': 'off',
},
},
];

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 181 KiB

View File

@@ -0,0 +1,13 @@
# 1. Create new Google Cloud Project
gcloud projects create {{PROJECT_ID}} --name="{{COMPANY_NAME}} AI Agent System"
# 2. Set default project
gcloud config set project {{PROJECT_ID}}
# 3. Enable required APIs
gcloud services enable aiplatform.googleapis.com
gcloud services enable storage.googleapis.com
gcloud services enable cloudfunctions.googleapis.com
gcloud services enable run.googleapis.com
gcloud services enable firestore.googleapis.com
gcloud services enable secretmanager.googleapis.com

View File

@@ -0,0 +1,13 @@
# 1. Create new Google Cloud Project
gcloud projects create {{PROJECT_ID}} --name="{{COMPANY_NAME}} AI Agent System"
# 2. Set default project
gcloud config set project {{PROJECT_ID}}
# 3. Enable required APIs
gcloud services enable aiplatform.googleapis.com
gcloud services enable storage.googleapis.com
gcloud services enable cloudfunctions.googleapis.com
gcloud services enable run.googleapis.com
gcloud services enable firestore.googleapis.com
gcloud services enable secretmanager.googleapis.com

View File

@@ -0,0 +1,25 @@
{{company_name}}-ai-agents/
├── agents/
│ ├── __init__.py
│ ├── {{team_1}}/
│ │ ├── __init__.py
│ │ ├── {{agent_1}}.py
│ │ └── {{agent_2}}.py
│ └── {{team_2}}/
├── tasks/
│ ├── __init__.py
│ ├── {{task_category_1}}/
│ └── {{task_category_2}}/
├── templates/
│ ├── {{document_type_1}}/
│ └── {{document_type_2}}/
├── checklists/
├── data/
├── workflows/
├── config/
│ ├── settings.py
│ └── agent_config.yaml
├── main.py
└── deployment/
├── Dockerfile
└── cloudbuild.yaml

View File

@@ -0,0 +1,34 @@
import os
from pydantic import BaseSettings
class Settings(BaseSettings):
# Google Cloud Configuration
project_id: str = "{{PROJECT_ID}}"
location: str = "{{LOCATION}}" # e.g., "us-central1"
# Company Information
company_name: str = "{{COMPANY_NAME}}"
industry: str = "{{INDUSTRY}}"
business_type: str = "{{BUSINESS_TYPE}}"
# Agent Configuration
default_model: str = "gemini-1.5-pro"
max_iterations: int = 10
timeout_seconds: int = 300
# Storage Configuration
bucket_name: str = "{{COMPANY_NAME}}-ai-agents-storage"
database_name: str = "{{COMPANY_NAME}}-ai-agents-db"
# API Configuration
session_service_type: str = "vertex" # or "in_memory" for development
artifact_service_type: str = "gcs" # or "in_memory" for development
memory_service_type: str = "vertex" # or "in_memory" for development
# Security
service_account_path: str = "./{{COMPANY_NAME}}-ai-agents-key.json"
class Config:
env_file = ".env"
settings = Settings()

View File

@@ -0,0 +1,70 @@
import asyncio
from google.adk.agents import LlmAgent
from google.adk.runners import Runner
from google.adk.sessions import VertexAiSessionService
from google.adk.artifacts import GcsArtifactService
from google.adk.memory import VertexAiRagMemoryService
from google.adk.models import Gemini
from config.settings import settings
from agents.{{primary_team}}.{{main_orchestrator}} import {{MainOrchestratorClass}}
class {{CompanyName}}AISystem:
def __init__(self):
self.settings = settings
self.runner = None
self.main_orchestrator = None
async def initialize(self):
"""Initialize the AI agent system"""
# Create main orchestrator
self.main_orchestrator = {{MainOrchestratorClass}}()
# Initialize services
session_service = VertexAiSessionService(
project=self.settings.project_id,
location=self.settings.location
)
artifact_service = GcsArtifactService(
bucket_name=self.settings.bucket_name
)
memory_service = VertexAiRagMemoryService(
rag_corpus=f"projects/{self.settings.project_id}/locations/{self.settings.location}/ragCorpora/{{COMPANY_NAME}}-knowledge"
)
# Create runner
self.runner = Runner(
app_name=f"{self.settings.company_name}-AI-System",
agent=self.main_orchestrator,
session_service=session_service,
artifact_service=artifact_service,
memory_service=memory_service
)
print(f"{self.settings.company_name} AI Agent System initialized successfully!")
async def run_agent_interaction(self, user_id: str, session_id: str, message: str):
"""Run agent interaction"""
if not self.runner:
await self.initialize()
async for event in self.runner.run_async(
user_id=user_id,
session_id=session_id,
new_message=message
):
yield event
# Application factory
async def create_app():
ai_system = {{CompanyName}}AISystem()
await ai_system.initialize()
return ai_system
if __name__ == "__main__":
# Development server
import uvicorn
uvicorn.run("main:app", host="0.0.0.0", port=8000, reload=True)

View File

@@ -0,0 +1,26 @@
steps:
# Build the container image
- name: "gcr.io/cloud-builders/docker"
args: ["build", "-t", "gcr.io/{{PROJECT_ID}}/{{COMPANY_NAME}}-ai-agents:$COMMIT_SHA", "."]
# Push the container image to Container Registry
- name: "gcr.io/cloud-builders/docker"
args: ["push", "gcr.io/{{PROJECT_ID}}/{{COMPANY_NAME}}-ai-agents:$COMMIT_SHA"]
# Deploy container image to Cloud Run
- name: "gcr.io/google.com/cloudsdktool/cloud-sdk"
entrypoint: gcloud
args:
- "run"
- "deploy"
- "{{COMPANY_NAME}}-ai-agents"
- "--image"
- "gcr.io/{{PROJECT_ID}}/{{COMPANY_NAME}}-ai-agents:$COMMIT_SHA"
- "--region"
- "{{LOCATION}}"
- "--platform"
- "managed"
- "--allow-unauthenticated"
images:
- "gcr.io/{{PROJECT_ID}}/{{COMPANY_NAME}}-ai-agents:$COMMIT_SHA"

Some files were not shown because too many files have changed in this diff Show More