2025-09-28 23:17:07 -05:00
<!-- BMAD BMM Story Context Assembly Instructions (v6) -->
2025-10-17 23:44:43 -05:00
```xml
2025-11-08 13:58:43 -06:00
< critical > The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml< / critical >
2025-09-28 23:17:07 -05:00
< critical > You MUST have already loaded and processed: {installed_path}/workflow.yaml< / critical >
2025-10-25 19:25:28 -05:00
< critical > Communicate all responses in {communication_language}< / critical >
2025-10-17 20:33:38 -05:00
< critical > Generate all documents in {document_output_language}< / critical >
2025-10-25 19:25:28 -05:00
< critical > This workflow assembles a Story Context file for a single drafted story by extracting acceptance criteria, tasks, relevant docs/code, interfaces, constraints, and testing guidance.< / critical >
2025-11-09 23:17:29 -06:00
< critical > If {story_path} is provided, use it. Otherwise, find the first story with status "drafted" in sprint-status.yaml. If none found, HALT.< / critical >
2025-10-25 19:25:28 -05:00
< critical > Check if context file already exists. If it does, ask user if they want to replace it, verify it, or cancel.< / critical >
2025-09-28 23:17:07 -05:00
2025-10-26 15:03:54 -05:00
< critical > DOCUMENT OUTPUT: Technical context file (.context.xml). Concise, structured, project-relative paths only.< / critical >
2025-10-12 22:19:28 -05:00
2025-10-17 20:33:38 -05:00
< workflow >
2025-10-25 19:25:28 -05:00
< step n = "1" goal = "Find drafted story and check for existing context" tag = "sprint-status" >
< check if = "{{story_path}} is provided" >
< action > Use {{story_path}} directly< / action >
< action > Read COMPLETE story file and parse sections< / action >
< action > Extract story_key from filename or story metadata< / action >
< action > Verify Status is "drafted" - if not, HALT with message: "Story status must be 'drafted' to generate context"< / action >
< / check >
2025-10-25 14:26:30 -05:00
2025-10-25 19:25:28 -05:00
< check if = "{{story_path}} is NOT provided" >
< critical > MUST read COMPLETE sprint-status.yaml file from start to end to preserve order< / critical >
< action > Load the FULL file: {{output_folder}}/sprint-status.yaml< / action >
< action > Read ALL lines from beginning to end - do not skip any content< / action >
< action > Parse the development_status section completely< / action >
2025-10-25 14:26:30 -05:00
2025-10-25 19:25:28 -05:00
< action > Find FIRST story (reading in order from top to bottom) where:
- Key matches pattern: number-number-name (e.g., "1-2-user-auth")
- NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
- Status value equals "drafted"
< / action >
2025-10-25 14:26:30 -05:00
2025-10-25 19:25:28 -05:00
< check if = "no story with status 'drafted' found" >
< output > 📋 No drafted stories found in sprint-status.yaml
2025-11-09 23:17:29 -06:00
All stories are either still in backlog or already marked ready/in-progress/done.
2025-10-25 14:26:30 -05:00
2025-11-09 23:17:29 -06:00
**Next Steps:**
1. Run `create-story` to draft more stories
2. Run `sprint-planning` to refresh story tracking
2025-10-25 19:25:28 -05:00
< / output >
< action > HALT< / action >
< / check >
< action > Use the first drafted story found< / action >
2025-11-09 23:17:29 -06:00
< action > Find matching story file in {{story_path}} using story_key pattern< / action >
2025-10-25 19:25:28 -05:00
< action > Read the COMPLETE story file< / action >
2025-10-25 14:26:30 -05:00
< / check >
2025-10-25 19:25:28 -05:00
< action > Extract {{epic_id}}, {{story_id}}, {{story_title}}, {{story_status}} from filename/content< / action >
< action > Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes< / action >
< action > Extract user story fields (asA, iWant, soThat)< / action >
< template-output file = "{default_output_file}" > story_tasks< / template-output >
< template-output file = "{default_output_file}" > acceptance_criteria< / template-output >
2025-10-25 14:26:30 -05:00
2025-10-25 19:25:28 -05:00
<!-- Check if context file already exists -->
< action > Check if file exists at {default_output_file}< / action >
2025-10-25 14:26:30 -05:00
2025-10-25 19:25:28 -05:00
< check if = "context file already exists" >
< output > ⚠️ Context file already exists: {default_output_file}
2025-10-25 14:26:30 -05:00
feat: Add documentation guides, simplify folder structure, and major workflow refactoring
Created two comprehensive guides for v6 features:
**docs/agent-customization-guide.md**
- Complete guide for customizing agent names, personas, memories, and behaviors
- Update-safe customization via bmad/_cfg/agents/ configuration files
- Real-world examples (TDD setup, multilingual agents, custom workflows)
- Troubleshooting and best practices
**docs/web-bundles-gemini-gpt-guide.md**
- Comprehensive guide for using BMad agents in Gemini Gems and Custom GPTs
- Critical setup rules with exact configuration text required
- Cost-saving strategy: web planning → local implementation (60-80% savings)
- Platform comparison (Gemini Gems strongly recommended over Custom GPTs)
- Complete workflow examples showing full planning-to-implementation cycle
- Team bundle guidance (Gemini 2.5 Pro+ only)
**README.md updates**
- Added prominent links in v6 Core Enhancements section
- Created new "Customization & Sharing" documentation category
- Web Bundles feature highlighted with direct guide link
**Unified output folder structure across all modules:**
**Before (confusing):**
- output_folder: Main docs
- game_design_docs: Separate design folder
- tech_docs: Separate technical folder
- dev_ephemeral_location: Separate ephemeral folder outside docs
**After (simplified):**
- output_folder: Single location for ALL AI-generated artifacts (default: "docs")
- Clearer prompt: "Where should AI Generated Artifacts be saved?"
- sprint_artifacts: Phase 4 ephemeral content now WITHIN output_folder
- BMM: {output_folder}/stories (stories, context, reports)
- BMGD: {output_folder}/sprint-artifacts
- No longer in separate {bmad_folder}-ephemeral location
**Benefits:**
- One clear location for all planning artifacts (PRD, Architecture, UX, etc.)
- Phase 4 ephemeral items logically grouped within output folder
- Eliminated confusing separate folder proliferation
- sprint_artifacts now configurable per module
**Files changed:**
- src/core/_module-installer/install-config.yaml
- src/modules/bmm/_module-installer/install-config.yaml
- src/modules/bmgd/_module-installer/install-config.yaml
**Also cleaned up BMGD config:**
- Renamed: specified_framework → primary_platform (clearer naming)
- Removed: unused data_path variable
Replaced old "project_level" (0-4) system with new "selected_track" terminology:
- **quick-flow**: Bug fixes and small features (replaces Level 0-1)
- **bmad-method**: Full planning track (replaces Level 2-3)
- **enterprise-bmad-method**: Extended planning (replaces Level 4)
**Core workflow updates:**
- solutioning-gate-check: Complete rewrite of validation logic for track-based artifacts
- architecture: Updated context detection, error handling, and messaging for tracks
- workflow-init: Updated artifact detection patterns for track-based paths
- All workflow status paths updated (method-greenfield, method-brownfield, enterprise-*)
Unified variable naming conventions across all workflows:
- {output_folder} → {output-folder} (hyphenated format)
- {dev_ephemeral_location} → {sprint_artifacts} (clearer purpose)
- Hardcoded status file paths → {workflow_status_file} variable
Fixed corrupted variable patterns throughout workflow files:
- {output*folder} → {output-folder}
- {ephemeral*location} → {sprint_artifacts}
- \_prd* → *prd* (escaped underscore artifacts)
- **\*\***\_\_\_**\*\*** → proper field placeholders
Affected patterns included malformed glob patterns, template variables, and markdown formatting artifacts from previous edits.
**Architecture workflow (create-architecture):**
- Fixed: "Decision Architecture" → "Create Architecture" (consistent naming)
- Improved PRD not found handling with exit/continue options
- Better user guidance when running standalone vs. within workflow path
- Removed hardcoded Level checks, now track-aware
- Enhanced validation checklist formatting (□ → - [])
- Typo fixes: "mulitple" → "multiple"
**Solutioning gate check:**
- Complete validation logic rewrite for track-based system
- Removed Level-specific artifact expectations
- Simplified document discovery (track determines what exists)
- Better analysis prompts and user feedback
**Workflow-init:**
- Updated artifact detection patterns for new folder structure
- Fixed corrupt glob patterns throughout
- Better sprint_artifacts location detection
- Improved workflow path assignment logic
**Various workflows:**
- Consistent variable naming across 40+ workflow files
- Improved error messages and user guidance
- Better markdown formatting (checkboxes, lists)
- Removed redundant validation criteria files (now inline)
Removed duplicate BMGD 4-production workflows (12 workflows):
- code-review, correct-course, create-story, dev-story
- epic-tech-context, retrospective, sprint-planning
- story-context, story-done, story-ready
**Why:** BMGD now uses shared BMM Phase 4 implementation workflows
**Benefit:** Single source of truth, no duplication to maintain
Also removed:
- validation-criteria.yaml (validation now inline in instructions)
- architecture-patterns.yaml references (patterns now managed differently)
- AUDIT-REPORT.md files (stale audit artifacts)
**BMB workflows:**
- Updated checklists for workflow and module creation
- Improved agent architecture documentation
- Minor instruction clarifications
**Core brainstorming workflow:**
- Updated README with usage examples
- Enhanced instructions and template clarity
- Better integration with other modules
**BMM installer:**
- Updated for track-based system
- sprint_artifacts configuration
**Tech Writer agent:**
- Minor configuration update for documentation workflows
Removed 200+ files that should not be in repository:
- Installed agent markdown files (analyst, architect, dev, pm, sm, tea, etc.)
- Complete workflow instruction copies
- Documentation duplicates (quick-start, agents-guide, workflows-*)
- Test architecture knowledge base (22 files, 14,000+ lines)
- Configuration files (config.yaml, team definitions)
These are generated during installation and should not be version controlled.
Removed 21 pre-generated XML bundles:
- BMM agents (analyst, architect, dev, pm, sm, tea, tech-writer, ux-designer)
- BMGD agents (game-architect, game-designer, game-dev, game-scrum-master)
- CIS agents (brainstorming-coach, creative-problem-solver, etc.)
- Team bundles (team-fullstack, team-gamedev, creative-squad)
**Why:** Users should generate fresh bundles via `npm run bundle` to get latest changes and customizations.
- **2 new documentation files** (comprehensive guides)
- **98 source files modified** (299 insertions, 6,567 deletions)
- **3 installer config files simplified** (major folder structure improvement)
- **200+ .bmad/ artifacts removed** (should not be in repo)
- **21 web-bundle files removed** (users regenerate as needed)
- **12 duplicate workflows removed** (BMGD consolidation)
- **40+ workflows updated** (track system, variable standardization, corruption fixes)
2025-11-11 12:22:31 -06:00
**What would you like to do?**
1. **Replace** - Generate new context file (overwrites existing)
2. **Verify** - Validate existing context file
3. **Cancel** - Exit without changes
2025-10-25 19:25:28 -05:00
< / output >
< ask > Choose action (replace/verify/cancel):< / ask >
2025-10-25 14:26:30 -05:00
2025-10-25 19:25:28 -05:00
< check if = "user chooses verify" >
< action > GOTO validation_step< / action >
< / check >
2025-10-25 14:26:30 -05:00
2025-10-25 19:25:28 -05:00
< check if = "user chooses cancel" >
< action > HALT with message: "Context generation cancelled"< / action >
< / check >
2025-10-25 14:26:30 -05:00
2025-10-25 19:25:28 -05:00
< check if = "user chooses replace" >
< action > Continue to generate new context file< / action >
< / check >
< / check >
2025-10-25 14:26:30 -05:00
2025-10-25 19:25:28 -05:00
< action > Store project root path for relative path conversion: extract from {project-root} variable< / action >
< action > Define path normalization function: convert any absolute path to project-relative by removing project root prefix< / action >
< action > Initialize output by writing template to {default_output_file}< / action >
2025-09-28 23:17:07 -05:00
< template-output file = "{default_output_file}" > as_a< / template-output >
< template-output file = "{default_output_file}" > i_want< / template-output >
< template-output file = "{default_output_file}" > so_that< / template-output >
< / step >
2025-10-21 22:25:26 -05:00
< step n = "2" goal = "Collect relevant documentation" >
2025-10-13 21:11:20 -05:00
< action > Scan docs and src module docs for items relevant to this story's domain: search keywords from story title, ACs, and tasks.< / action >
feat: transform tech-spec workflow into intelligent Quick Spec Flow for Level 0-1
This major enhancement revolutionizes the tech-spec workflow from a basic template-filling exercise into a context-aware, intelligent planning system for rapid development of bug fixes and small features.
## Tech-Spec Workflow Transformation (11 files)
### Core Workflow Intelligence (instructions.md)
- Add standalone mode with interactive level/field-type detection
- Implement brownfield convention detection and user confirmation
- Integrate WebSearch for current framework versions and starter templates
- Add comprehensive context discovery (stack, patterns, dependencies)
- Implement auto-validation with quality scoring (always runs)
- Add UX/UI considerations capture for user-facing changes
- Add test framework detection and pattern analysis
- Transform from batch generation to living document approach
### Comprehensive Tech-Spec Template (tech-spec-template.md)
- Expand from 8 to 23 sections for complete context
- Add Context section (available docs, project stack, existing structure)
- Add Development Context (conventions, test framework, existing code)
- Add UX/UI Considerations section
- Add Developer Resources (file paths, key locations, testing)
- Add Integration Points and Configuration Changes
- All sections populated via template-output tags during workflow
### Enhanced Story Generation
- Level 0 (instructions-level0-story.md): Extract from comprehensive tech-spec
- Level 1 (instructions-level1-stories.md): Add story sequence validation, AC quality checks
- User Story Template: Add Dev Agent Record sections for implementation tracking
- Epic Template: Complete rewrite with proper structure and variables
### Validation & Quality (checklist.md)
- Add context gathering completeness checks
- Add definitiveness validation (no "use X or Y" statements)
- Add brownfield integration quality scoring
- Add stack alignment verification
- Add implementation readiness assessment
- Auto-generates validation report with scores
### Configuration (workflow.yaml)
- Add runtime variables: project_level, project_type, development_context, change_type, field_type
- Enable standalone operation without workflow-status.yaml
- Support both workflow-init integration and quick-start mode
## Phase 4 Integration (3 files)
### Story Context Workflow
- Add tech_spec to input_file_patterns (recognizes as authoritative source)
- Update instructions to prioritize tech-spec for Level 0-1 projects
- Tech-spec provides brownfield analysis, framework details, existing patterns
### Create Story Workflow
- Add tech_spec to input_file_patterns
- Enable story generation from tech-spec (alternative to PRD)
- Supports both Quick Spec Flow and traditional BMM flow
## Documentation (2 new files)
### Quick Spec Flow Guide (docs/quick-spec-flow.md)
- Comprehensive 595-line guide for Level 0-1 rapid development
- Complete user journey examples (bug fix, small feature)
- Context discovery explanation (stack, brownfield, conventions)
- Auto-validation details and benefits
- Integration with Phase 4 workflows
- Comparison: Quick Spec vs Full BMM
- Real-world examples and best practices
### Scale Adaptive System (docs/scale-adaptive-system.md)
- Complete 950-line technical guide to BMad Method's 5-level system
- Key terminology: Analysis, Tech-Spec, Epic-Tech-Spec, Architecture
- Level 0-4 workflows, planning docs, and progression
- Brownfield emphasis: document-project required first
- Tech-spec (upfront, Level 0-1) vs epic-tech-spec (during implementation, Level 2-4)
- Architecture document replaces tech-spec at Level 2+ (scales with complexity)
- Retrospectives after each epic in multi-epic projects
- Workflow path configuration reference
### README Updates
- Add Quick Spec Flow announcement with benefits
- Link to Scale Adaptive System documentation
- Clarify when to use Quick Spec Flow vs Full BMM
## Key Features
### Context-Aware Intelligence
- Auto-detects project stack from package.json, requirements.txt, etc.
- Analyzes brownfield codebases using document-project output
- Detects code conventions and confirms with user before proceeding
- Uses WebSearch for up-to-date framework info and starter templates
### Brownfield Respect
- Detects existing patterns (code style, test framework, naming conventions)
- Asks user for confirmation before applying conventions
- Adapts to existing code vs forcing changes
- References document-project analysis for comprehensive context
### Auto-Validation
- Always runs (not optional)
- Validates context gathering, definitiveness, brownfield integration
- Scores tech-spec quality and implementation readiness
- Validates story sequence for Level 1 (no forward dependencies)
### Living Document Approach
- Write to tech-spec continuously during discovery
- Progressive refinement vs batch generation
- Template variables populated via template-output tags in real-time
## Breaking Changes
None - all changes are additive and backward compatible.
## Impact
This transformation enables:
- Bug fixes and small features implemented in minutes vs hours
- Automatic stack detection and brownfield analysis
- Respect for existing conventions and patterns
- Current best practices via WebSearch integration
- Comprehensive context that can replace story-context for simple efforts
- Seamless integration with Phase 4 implementation workflows
Quick Spec Flow now provides a **true fast path from idea to implementation** for Level 0-1 projects while maintaining quality through auto-validation and comprehensive context gathering.
2025-11-02 08:17:23 -06:00
< action > Prefer authoritative sources: PRD, Tech-Spec, Architecture, Front-end Spec, Testing standards, module-specific docs.< / action >
< action > Note: Tech-Spec is used for Level 0-1 projects (instead of PRD). It contains comprehensive technical context, brownfield analysis, framework details, existing patterns, and implementation guidance.< / action >
2025-10-13 21:11:20 -05:00
< action > For each discovered document: convert absolute paths to project-relative format by removing {project-root} prefix. Store only relative paths (e.g., "docs/prd.md" not "/Users/.../docs/prd.md").< / action >
2025-09-28 23:17:07 -05:00
< template-output file = "{default_output_file}" >
2025-10-13 21:11:20 -05:00
Add artifacts.docs entries with {path, title, section, snippet}:
- path: PROJECT-RELATIVE path only (strip {project-root} prefix)
- title: Document title
- section: Relevant section name
- snippet: Brief excerpt (2-3 sentences max, NO invention)
2025-09-28 23:17:07 -05:00
< / template-output >
< / step >
2025-10-21 22:25:26 -05:00
< step n = "3" goal = "Analyze existing code, interfaces, and constraints" >
2025-09-28 23:17:07 -05:00
< action > Search source tree for modules, files, and symbols matching story intent and AC keywords (controllers, services, components, tests).< / action >
< action > Identify existing interfaces/APIs the story should reuse rather than recreate.< / action >
< action > Extract development constraints from Dev Notes and architecture (patterns, layers, testing requirements).< / action >
2025-10-13 21:11:20 -05:00
< action > For all discovered code artifacts: convert absolute paths to project-relative format (strip {project-root} prefix).< / action >
2025-09-28 23:17:07 -05:00
< template-output file = "{default_output_file}" >
2025-10-13 21:11:20 -05:00
Add artifacts.code entries with {path, kind, symbol, lines, reason}:
- path: PROJECT-RELATIVE path only (e.g., "src/services/api.js" not full path)
- kind: file type (controller, service, component, test, etc.)
- symbol: function/class/interface name
- lines: line range if specific (e.g., "45-67")
- reason: brief explanation of relevance to this story
Populate interfaces with API/interface signatures:
- name: Interface or API name
- kind: REST endpoint, GraphQL, function signature, class interface
- signature: Full signature or endpoint definition
- path: PROJECT-RELATIVE path to definition
Populate constraints with development rules:
- Extract from Dev Notes and architecture
- Include: required patterns, layer restrictions, testing requirements, coding standards
2025-09-28 23:17:07 -05:00
< / template-output >
< / step >
2025-10-21 22:25:26 -05:00
< step n = "4" goal = "Gather dependencies and frameworks" >
2025-09-28 23:17:07 -05:00
< action > Detect dependency manifests and frameworks in the repo:
- Node: package.json (dependencies/devDependencies)
- Python: pyproject.toml/requirements.txt
- Go: go.mod
- Unity: Packages/manifest.json, Assets/, ProjectSettings/
- Other: list notable frameworks/configs found</ action >
< template-output file = "{default_output_file}" >
Populate artifacts.dependencies with keys for detected ecosystems and their packages with version ranges where present
< / template-output >
< / step >
2025-10-21 22:25:26 -05:00
< step n = "5" goal = "Testing standards and ideas" >
2025-09-28 23:17:07 -05:00
< action > From Dev Notes, architecture docs, testing docs, and existing tests, extract testing standards (frameworks, patterns, locations).< / action >
< template-output file = "{default_output_file}" >
Populate tests.standards with a concise paragraph
Populate tests.locations with directories or glob patterns where tests live
Populate tests.ideas with initial test ideas mapped to acceptance criteria IDs
< / template-output >
< / step >
2025-10-21 22:25:26 -05:00
< step n = "6" goal = "Validate and save" >
2025-10-25 19:25:28 -05:00
< anchor id = "validation_step" / >
< action > Validate output context file structure and content< / action >
2025-11-08 13:58:43 -06:00
< invoke-task > Validate against checklist at {installed_path}/checklist.md using {bmad_folder}/core/tasks/validate-workflow.xml< / invoke-task >
2025-09-28 23:17:07 -05:00
< / step >
2025-10-25 14:26:30 -05:00
< step n = "7" goal = "Update story file and mark ready for dev" tag = "sprint-status" >
< action > Open {{story_path}}< / action >
< action > Find the "Status:" line (usually at the top)< / action >
2025-10-25 15:41:13 -05:00
< action > Update story file: Change Status to "ready-for-dev"< / action >
2025-09-28 23:17:07 -05:00
< action > Under 'Dev Agent Record' → 'Context Reference' (create if missing), add or update a list item for {default_output_file}.< / action >
< action > Save the story file.< / action >
2025-10-25 14:26:30 -05:00
<!-- Update sprint status to mark ready - for - dev -->
< action > Load the FULL file: {{output_folder}}/sprint-status.yaml< / action >
< action > Find development_status key matching {{story_key}}< / action >
< action > Verify current status is "drafted" (expected previous state)< / action >
< action > Update development_status[{{story_key}}] = "ready-for-dev"< / action >
< action > Save file, preserving ALL comments and structure including STATUS DEFINITIONS< / action >
< check if = "story key not found in file" >
< output > ⚠️ Story file updated, but could not update sprint-status: {{story_key}} not found
You may need to run sprint-planning to refresh tracking.
< / output >
< / check >
2025-10-25 19:25:28 -05:00
< output > ✅ Story context generated successfully, {user_name}!
**Story Details:**
2025-10-30 08:13:18 -05:00
2025-10-25 19:25:28 -05:00
- Story: {{epic_id}}.{{story_id}} - {{story_title}}
- Story Key: {{story_key}}
- Context File: {default_output_file}
- Status: drafted → ready-for-dev
**Context Includes:**
2025-10-30 08:13:18 -05:00
2025-10-25 19:25:28 -05:00
- Documentation artifacts and references
- Existing code and interfaces
- Dependencies and frameworks
- Testing standards and ideas
- Development constraints
**Next Steps:**
2025-10-30 08:13:18 -05:00
2025-10-25 19:25:28 -05:00
1. Review the context file: {default_output_file}
2. Run `dev-story` to implement the story
3. Generate context for more drafted stories if needed
< / output >
2025-10-12 22:19:28 -05:00
< / step >
2025-09-28 23:17:07 -05:00
< / workflow >
2025-10-17 23:44:43 -05:00
```