Major Enhancements:
- Installation path is now fully configurable, allowing users to specify custom installation directories during setup
- Default installation location changed to .bmad (hidden directory) for cleaner project root organization
Web Bundle Improvements:
- All web bundles (single agent and team) now include party mode support for multi-agent collaboration!
- Advanced elicitation capabilities integrated into standalone agents
- All bundles enhanced with party mode agent manifests
- Added default-party.csv files to bmm, bmgd, and cis module teams
- The default party file is what will be used with single agent bundles. teams can customize for different party configurations before web bundling through a setting in the team yaml file
- New web bundle outputs for all agents (analyst, architect, dev, pm, sm, tea, tech-writer, ux-designer, game-*, creative-squad)
Phase 4 Workflow Updates (In Progress):
- Initiated shift to separate phase 4 implementation artifacts from documentation
- Phase 4 implementation artifacts (stories, code review, sprint plan, context files) will move to dedicated location outside docs folder
- Installer questions and configuration added for artifact path selection
- Updated workflow.yaml files for code-review, sprint-planning, story-context, epic-tech-context, and retrospective workflows to support this, but still might require some udpates
Additional Changes:
- New agent and action command header models for standardization
- Enhanced web-bundle-activation-steps fragment
- Updated web-bundler.js to support new structure
- VS Code settings updated for new .bmad directory
- Party mode instructions and workflow enhanced for better orchestration
IDE Installer Updates:
- Show version number of installer in cli
- improved Installer UX
- Gemini TOML Improved to have clear loading instructions with @ commands
- All tools agent launcher mds improved to use a central file template critical indication isntead of hardcoding in 2 different locations.
2025-11-09 17:39:05 -06:00
|
|
|
# Module Brief Validation Checklist
|
|
|
|
|
|
|
|
|
|
## Core Identity
|
|
|
|
|
|
|
|
|
|
- [ ] Module code follows kebab-case convention
|
|
|
|
|
- [ ] Module name is clear and memorable
|
|
|
|
|
- [ ] Module category is identified
|
|
|
|
|
- [ ] Target users are clearly defined
|
|
|
|
|
- [ ] Unique value proposition is articulated
|
|
|
|
|
|
|
|
|
|
## Vision and Concept
|
|
|
|
|
|
|
|
|
|
- [ ] Problem being solved is clearly stated
|
|
|
|
|
- [ ] Solution approach is explained
|
|
|
|
|
- [ ] Module scope is well-defined
|
|
|
|
|
- [ ] Success criteria are measurable
|
|
|
|
|
|
|
|
|
|
## Agent Architecture
|
|
|
|
|
|
|
|
|
|
- [ ] At least one agent is defined
|
|
|
|
|
- [ ] Each agent has a clear role and purpose
|
|
|
|
|
- [ ] Agent personalities are defined (if using personality themes)
|
|
|
|
|
- [ ] Agent interactions are mapped (for multi-agent modules)
|
|
|
|
|
- [ ] Key commands for each agent are listed
|
|
|
|
|
|
|
|
|
|
## Workflow Ecosystem
|
|
|
|
|
|
|
|
|
|
- [ ] Core workflows (2-3) are identified
|
|
|
|
|
- [ ] Each workflow has clear purpose
|
|
|
|
|
- [ ] Workflow complexity is assessed
|
|
|
|
|
- [ ] Input/output for workflows is defined
|
|
|
|
|
- [ ] Workflow categories are logical
|
|
|
|
|
|
|
|
|
|
## User Experience
|
|
|
|
|
|
|
|
|
|
- [ ] Primary use case is documented
|
|
|
|
|
- [ ] User scenarios demonstrate value
|
|
|
|
|
- [ ] User journey is realistic
|
|
|
|
|
- [ ] Learning curve is considered
|
|
|
|
|
- [ ] User feedback mechanism planned
|
|
|
|
|
|
|
|
|
|
## Technical Planning
|
|
|
|
|
|
|
|
|
|
- [ ] Data requirements are identified
|
|
|
|
|
- [ ] Integration points are mapped
|
|
|
|
|
- [ ] Dependencies are listed
|
|
|
|
|
- [ ] Technical complexity is assessed
|
|
|
|
|
- [ ] Performance requirements stated
|
|
|
|
|
|
|
|
|
|
## Development Roadmap
|
|
|
|
|
|
|
|
|
|
- [ ] Phase 1 MVP is clearly scoped
|
|
|
|
|
- [ ] Phase 2 enhancements are outlined
|
|
|
|
|
- [ ] Phase 3 polish items listed
|
|
|
|
|
- [ ] Timeline estimates provided
|
|
|
|
|
- [ ] Deliverables are specific
|
|
|
|
|
|
|
|
|
|
## Risk Management
|
|
|
|
|
|
|
|
|
|
- [ ] Technical risks identified
|
|
|
|
|
- [ ] Usability risks considered
|
|
|
|
|
- [ ] Scope risks acknowledged
|
|
|
|
|
- [ ] Mitigation strategies provided
|
|
|
|
|
- [ ] Open questions documented
|
|
|
|
|
|
|
|
|
|
## Creative Elements (Optional)
|
|
|
|
|
|
|
|
|
|
- [ ] Personality theme is consistent (if used)
|
|
|
|
|
- [ ] Special features add value
|
|
|
|
|
- [ ] Module feels cohesive
|
|
|
|
|
- [ ] Fun elements don't compromise functionality
|
|
|
|
|
|
|
|
|
|
## Documentation Quality
|
|
|
|
|
|
|
|
|
|
- [ ] All sections have content (no empty placeholders)
|
|
|
|
|
- [ ] Writing is clear and concise
|
|
|
|
|
- [ ] Technical terms are explained
|
|
|
|
|
- [ ] Examples are provided where helpful
|
|
|
|
|
- [ ] Next steps are actionable
|
|
|
|
|
|
|
|
|
|
## Implementation Readiness
|
|
|
|
|
|
|
|
|
|
- [ ] Brief provides enough detail for create-module workflow
|
|
|
|
|
- [ ] Agent specifications sufficient for create-agent workflow
|
|
|
|
|
- [ ] Workflow descriptions ready for create-workflow
|
|
|
|
|
- [ ] Resource requirements are clear
|
|
|
|
|
- [ ] Success metrics are measurable
|
|
|
|
|
|
|
|
|
|
## Final Validation
|
|
|
|
|
|
|
|
|
|
- [ ] Module concept is viable
|
|
|
|
|
- [ ] Scope is achievable
|
|
|
|
|
- [ ] Value is clear
|
|
|
|
|
- [ ] Brief is complete
|
|
|
|
|
- [ ] Ready for development
|
|
|
|
|
|
|
|
|
|
## Issues Found
|
|
|
|
|
|
|
|
|
|
### Critical Issues
|
|
|
|
|
|
|
|
|
|
<!-- Must be fixed before proceeding to build -->
|
|
|
|
|
|
|
|
|
|
### Recommendations
|
|
|
|
|
|
|
|
|
|
<!-- Suggested improvements -->
|
|
|
|
|
|
|
|
|
|
### Nice-to-Haves
|
|
|
|
|
|
|
|
|
|
<!-- Optional enhancements -->
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
**Validation Complete:** ⬜ Yes / ⬜ With Issues / ⬜ Needs Revision
|
|
|
|
|
|
2025-11-11 17:30:12 -06:00
|
|
|
**Validated By:** {name}
|
|
|
|
|
**Date:** {date}
|