mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00: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)
This commit is contained in:
Brian Madison
@@ -35,14 +35,9 @@ user_skill_level:
|
||||
- value: "expert"
|
||||
label: "Expert - Deep technical knowledge, be direct and technical"
|
||||
|
||||
tech_docs:
|
||||
prompt: "Where is Technical Documentation located within the project?"
|
||||
default: "{output_folder}/technical"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
dev_ephemeral_location:
|
||||
prompt: "Where should ephemeral development artifacts be stored (workflow and sprint status, stories, epics, temp context, etc...)?"
|
||||
default: "{bmad_folder}-ephemeral"
|
||||
sprint_artifacts:
|
||||
prompt: "Where should Sprint Artifacts be stored (sprint status, stories, story context, temp context, etc...)?"
|
||||
default: "{output_folder}/stories"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
# TEA Agent Configuration
|
||||
|
||||
@@ -63,9 +63,9 @@ async function install(options) {
|
||||
}
|
||||
|
||||
// Create dev story location if configured
|
||||
if (config['dev_ephemeral_location']) {
|
||||
if (config['sprint_artifacts']) {
|
||||
// Strip {project-root}/ prefix if present
|
||||
const storyConfig = config['dev_ephemeral_location'].replace('{project-root}/', '');
|
||||
const storyConfig = config['sprint_artifacts'].replace('{project-root}/', '');
|
||||
const storyPath = path.join(projectRoot, storyConfig);
|
||||
if (!(await fs.pathExists(storyPath))) {
|
||||
logger.log(chalk.yellow(`Creating story directory: ${storyConfig}`));
|
||||
|
||||
@@ -15,7 +15,7 @@ agent:
|
||||
principles: Documentation is teaching. Every doc helps someone accomplish a task. Clarity above all. Docs are living artifacts that evolve with code.
|
||||
|
||||
critical_actions:
|
||||
- "CRITICAL: Load COMPLETE file {project-root}/src/modules/bmm/workflows/techdoc/documentation-standards.md into permanent memory and follow ALL rules within"
|
||||
- "CRITICAL: Load COMPLETE file {project-root}/{bmad_folder}/bmm/workflows/techdoc/documentation-standards.md into permanent memory and follow ALL rules within"
|
||||
- "Load into memory {project-root}/{bmad_folder}/bmm/config.yaml and set variables"
|
||||
- "Remember the user's name is {user_name}"
|
||||
- "ALWAYS communicate in {communication_language}"
|
||||
|
||||
@@ -1,85 +0,0 @@
|
||||
<task id="{bmad_folder}/bmm/tasks/daily-standup.xml" name="Daily Standup">
|
||||
<llm critical="true">
|
||||
<i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
|
||||
<i>DO NOT skip steps or change the sequence</i>
|
||||
<i>HALT immediately when halt-conditions are met</i>
|
||||
<i>Each action tag within a step tag is a REQUIRED action to complete that step</i>
|
||||
<i>Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution</i>
|
||||
</llm>
|
||||
<flow>
|
||||
<step n="1" title="Project Context Discovery">
|
||||
<action>Check for stories folder at {project-root}{output_folder}/stories/</action>
|
||||
<action>Find current story by identifying highest numbered story file</action>
|
||||
<action>Read story status (In Progress, Ready for Review, etc.)</action>
|
||||
<action>Extract agent notes from Dev Agent Record, TEA Results, PO Notes sections</action>
|
||||
<action>Check for next story references from epics</action>
|
||||
<action>Identify blockers from story sections</action>
|
||||
</step>
|
||||
|
||||
<step n="2" title="Initialize Standup with Context">
|
||||
<output>
|
||||
🏃 DAILY STANDUP - Story-{{number}}: {{title}}
|
||||
|
||||
Current Sprint Status:
|
||||
- Active Story: story-{{number}} ({{status}} - {{percentage}}% complete)
|
||||
- Next in Queue: story-{{next-number}}: {{next-title}}
|
||||
- Blockers: {{blockers-from-story}}
|
||||
|
||||
Team assembled based on story participants:
|
||||
{{ List Agents from {project-root}/{bmad_folder}/_cfg/agent-manifest.csv }}
|
||||
</output>
|
||||
</step>
|
||||
|
||||
<step n="3" title="Structured Standup Discussion">
|
||||
<action>Each agent provides three items referencing real story data</action>
|
||||
<action>What I see: Their perspective on current work, citing story sections (1-2 sentences)</action>
|
||||
<action>What concerns me: Issues from their domain or story blockers (1-2 sentences)</action>
|
||||
<action>What I suggest: Actionable recommendations for progress (1-2 sentences)</action>
|
||||
</step>
|
||||
|
||||
<step n="4" title="Create Standup Summary">
|
||||
<output>
|
||||
📋 STANDUP SUMMARY:
|
||||
Key Items from Story File:
|
||||
- {{completion-percentage}}% complete ({{tasks-complete}}/{{total-tasks}} tasks)
|
||||
- Blocker: {{main-blocker}}
|
||||
- Next: {{next-story-reference}}
|
||||
|
||||
Action Items:
|
||||
- {{agent}}: {{action-item}}
|
||||
- {{agent}}: {{action-item}}
|
||||
- {{agent}}: {{action-item}}
|
||||
|
||||
Need extended discussion? Use *party-mode for detailed breakout.
|
||||
</output>
|
||||
</step>
|
||||
</flow>
|
||||
|
||||
<agent-selection>
|
||||
<context type="prd-review">
|
||||
<i>Primary: Sarah (PO), Mary (Analyst), Winston (Architect)</i>
|
||||
<i>Secondary: Murat (TEA), James (Dev)</i>
|
||||
</context>
|
||||
<context type="story-planning">
|
||||
<i>Primary: Sarah (PO), Bob (SM), James (Dev)</i>
|
||||
<i>Secondary: Murat (TEA)</i>
|
||||
</context>
|
||||
<context type="validate-architecture">
|
||||
<i>Primary: Winston (Architect), James (Dev), Murat (TEA)</i>
|
||||
<i>Secondary: Sarah (PO)</i>
|
||||
</context>
|
||||
<context type="implementation">
|
||||
<i>Primary: James (Dev), Murat (TEA), Winston (Architect)</i>
|
||||
<i>Secondary: Sarah (PO)</i>
|
||||
</context>
|
||||
</agent-selection>
|
||||
|
||||
<llm critical="true">
|
||||
<i>This task extends party-mode with agile-specific structure</i>
|
||||
<i>Time-box responses (standup = brief)</i>
|
||||
<i>Focus on actionable items from real story data when available</i>
|
||||
<i>End with clear next steps</i>
|
||||
<i>No deep dives (suggest breakout if needed)</i>
|
||||
<i>If no stories folder detected, run general standup format</i>
|
||||
</llm>
|
||||
</task>
|
||||
@@ -23,19 +23,6 @@ domain_knowledge_base: "{installed_path}/domain-knowledge-base.md"
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/domain-brief.md"
|
||||
|
||||
# Workflow metadata
|
||||
version: "6.0.0-alpha"
|
||||
category: "analysis"
|
||||
complexity: "medium"
|
||||
execution_time: "30-45 minutes"
|
||||
prerequisites:
|
||||
- "Basic project understanding"
|
||||
when_to_use:
|
||||
- "Complex regulated domains (healthcare, finance, aerospace)"
|
||||
- "Novel technical domains requiring deep understanding"
|
||||
- "Before PRD when domain expertise needed"
|
||||
- "When compliance and regulations matter"
|
||||
|
||||
standalone: true
|
||||
|
||||
# Web bundle configuration for standalone deployment
|
||||
|
||||
@@ -140,5 +140,5 @@ _List minor improvements that would enhance the prompt:_
|
||||
|
||||
**Validation Complete:** ☐ Yes ☐ No
|
||||
**Ready to Execute:** ☐ Yes ☐ No
|
||||
**Reviewer:** \***\*\_\*\***
|
||||
**Date:** \***\*\_\*\***
|
||||
**Reviewer:** {agent}
|
||||
**Date:** {date}
|
||||
|
||||
@@ -245,5 +245,5 @@ _List areas requiring further investigation:_
|
||||
|
||||
**Validation Complete:** ☐ Yes ☐ No
|
||||
**Ready for Decision:** ☐ Yes ☐ No
|
||||
**Reviewer:** \***\*\_\*\***
|
||||
**Date:** \***\*\_\*\***
|
||||
**Reviewer:** {agent}
|
||||
**Date:** {date}
|
||||
|
||||
@@ -295,5 +295,5 @@ _List areas requiring further investigation:_
|
||||
|
||||
**Validation Complete:** ☐ Yes ☐ No
|
||||
**Ready for Distribution:** ☐ Yes ☐ No
|
||||
**Reviewer:** **\*\***\_\_\_\_**\*\***
|
||||
**Date:** **\*\***\_\_\_\_**\*\***
|
||||
**Reviewer:** {reviewer}
|
||||
**Date:** {date}
|
||||
|
||||
@@ -296,14 +296,10 @@ If ANY of these are true, validation FAILS:
|
||||
|
||||
## Validation Summary
|
||||
|
||||
**Total Validation Points:** ~85
|
||||
|
||||
### Scoring Guide
|
||||
|
||||
- **Pass Rate ≥ 95% (81+/85):** ✅ EXCELLENT - Ready for architecture phase
|
||||
- **Pass Rate 85-94% (72-80/85):** ⚠️ GOOD - Minor fixes needed
|
||||
- **Pass Rate 70-84% (60-71/85):** ⚠️ FAIR - Important issues to address
|
||||
- **Pass Rate < 70% (<60/85):** ❌ POOR - Significant rework required
|
||||
- **Pass Rate ≥ 95%:** ✅ EXCELLENT - Ready for architecture phase
|
||||
- **Pass Rate 85-94%:** ⚠️ GOOD - Minor fixes needed
|
||||
- **Pass Rate 70-84%:** ⚠️ FAIR - Important issues to address
|
||||
- **Pass Rate < 70%:** ❌ POOR - Significant rework required
|
||||
|
||||
### Critical Issue Threshold
|
||||
|
||||
@@ -316,7 +312,7 @@ If ANY of these are true, validation FAILS:
|
||||
|
||||
**When validating:**
|
||||
|
||||
1. **Load ALL documents:**
|
||||
1. **Load ALL documents - whole or sharded (but not both of each) for example epics.md vs epics/\*.md:**
|
||||
- PRD.md (required)
|
||||
- epics.md (required)
|
||||
- product-brief.md (if exists)
|
||||
|
||||
@@ -129,14 +129,14 @@ Ensure stories are:
|
||||
|
||||
For each story in epic {{N}}, output variables following this pattern:
|
||||
|
||||
- story*title*{{N}}_1, story_title_{{N}}\_2, etc.
|
||||
- story*title*{{N}}_1, story_title_{{N}}\*2, etc.
|
||||
- Each containing: user story, BDD acceptance criteria, prerequisites, technical notes</action>
|
||||
|
||||
<template-output>epic*title*{{N}}</template-output>
|
||||
<template-output>epic*goal*{{N}}</template-output>
|
||||
|
||||
<action>For each story M in epic {{N}}, generate story content</action>
|
||||
<template-output>story*title*{{N}}\_{{M}}</template-output>
|
||||
<template-output>story-title-{{N}}\_{{M}}</template-output>
|
||||
|
||||
<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
@@ -13,7 +13,7 @@
|
||||
## 1. Output Files Exist
|
||||
|
||||
- [ ] tech-spec.md created in output folder
|
||||
- [ ] Story file(s) created in dev_ephemeral_location
|
||||
- [ ] Story file(s) created in sprint_artifacts
|
||||
- Level 0: 1 story file (story-{slug}.md)
|
||||
- Level 1: epics.md + 2-3 story files (story-{epic-slug}-N.md)
|
||||
- [ ] bmm-workflow-status.yaml updated (if not standalone mode)
|
||||
|
||||
@@ -72,9 +72,3 @@ So that {{value_benefit}}.
|
||||
---
|
||||
|
||||
<!-- End epic repeat -->
|
||||
|
||||
---
|
||||
|
||||
## Tech-Spec Reference
|
||||
|
||||
See [tech-spec.md](../tech-spec.md) for complete technical implementation details.
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
|
||||
<action>Read the completed tech-spec.md file from {output_folder}/tech-spec.md</action>
|
||||
<action>Load bmm-workflow-status.yaml from {output_folder}/bmm-workflow-status.yaml (if exists)</action>
|
||||
<action>Extract dev_ephemeral_location from config (where stories are stored)</action>
|
||||
<action>Extract sprint_artifacts from config (where stories are stored)</action>
|
||||
|
||||
<action>Extract from the ENHANCED tech-spec structure:
|
||||
|
||||
@@ -42,7 +42,7 @@
|
||||
</example>
|
||||
|
||||
<action>Set story_filename = "story-{slug}.md"</action>
|
||||
<action>Set story_path = "{dev_ephemeral_location}/story-{slug}.md"</action>
|
||||
<action>Set story_path = "{sprint_artifacts}/story-{slug}.md"</action>
|
||||
|
||||
</step>
|
||||
|
||||
@@ -193,7 +193,7 @@ Only needed for extremely complex scenarios:
|
||||
2. Generate additional story context (for complex edge cases)
|
||||
3. Exit for now
|
||||
|
||||
Select option (1-3):</ask>
|
||||
Select option (1-3)</ask>
|
||||
|
||||
</step>
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
<action>Read the completed tech-spec.md file from {output_folder}/tech-spec.md</action>
|
||||
<action>Load bmm-workflow-status.yaml from {output_folder}/bmm-workflow-status.yaml (if exists)</action>
|
||||
<action>Extract dev_ephemeral_location from config (where stories are stored)</action>
|
||||
<action>Extract sprint_artifacts from config (where stories are stored)</action>
|
||||
|
||||
<action>Extract from the ENHANCED tech-spec structure:
|
||||
|
||||
@@ -178,7 +178,7 @@ Since tech-spec is context-rich, populate ALL template fields:
|
||||
</guidelines>
|
||||
|
||||
<for-each story="1 to story_count">
|
||||
<action>Set story_path_{n} = "{dev_ephemeral_location}/story-{epic_slug}-{n}.md"</action>
|
||||
<action>Set story_path_{n} = "{sprint_artifacts}/story-{epic_slug}-{n}.md"</action>
|
||||
<action>Create story file from user_story_template with the following content:</action>
|
||||
|
||||
<template-output file="{story_path_{n}}">
|
||||
@@ -391,7 +391,7 @@ Stories are implementation-ready!</output>
|
||||
- `story-{epic_slug}-3.md` → Third story
|
||||
{{/if}}
|
||||
|
||||
**Story Location:** `{dev_ephemeral_location}/`
|
||||
**Story Location:** `{sprint_artifacts}/`
|
||||
|
||||
**Next Steps - Iterative Implementation:**
|
||||
|
||||
|
||||
@@ -123,13 +123,13 @@ This ensures the tech-spec is grounded in reality and gives developers everythin
|
||||
Search for and load (using dual-strategy: whole first, then sharded):
|
||||
|
||||
1. **Product Brief:**
|
||||
- Search pattern: {output*folder}/\_brief*.md
|
||||
- Sharded: {output*folder}/\_brief*/index.md
|
||||
- Search pattern: {output-folder}/_brief_.md
|
||||
- Sharded: {output-folder}/_brief_/index.md
|
||||
- If found: Load completely and extract key context
|
||||
|
||||
2. **Research Documents:**
|
||||
- Search pattern: {output*folder}/\_research*.md
|
||||
- Sharded: {output*folder}/\_research*/index.md
|
||||
- Search pattern: {output-folder}/\_research\*.md
|
||||
- Sharded: {output-folder}/\_research\*/index.md
|
||||
- If found: Load completely and extract insights
|
||||
|
||||
3. **Document-Project Output (CRITICAL for brownfield):**
|
||||
|
||||
@@ -319,29 +319,3 @@ decision_rules:
|
||||
- quick_prototype: "Railway"
|
||||
- global_edge: "Fly.io"
|
||||
- kubernetes_needed: "GCP or AWS EKS"
|
||||
|
||||
# Anti-patterns to avoid
|
||||
anti_patterns:
|
||||
overengineering:
|
||||
signs:
|
||||
- "Microservices for < 10k users"
|
||||
- "Kubernetes for single app"
|
||||
- "GraphQL for 5 endpoints"
|
||||
- "Event sourcing for CRUD app"
|
||||
recommendation: "Start simple, evolve as needed"
|
||||
|
||||
underengineering:
|
||||
signs:
|
||||
- "No authentication strategy"
|
||||
- "No error handling plan"
|
||||
- "No monitoring approach"
|
||||
- "No backup strategy"
|
||||
recommendation: "Cover the fundamentals"
|
||||
|
||||
technology_soup:
|
||||
signs:
|
||||
- "5+ different databases"
|
||||
- "Multiple frontend frameworks"
|
||||
- "Inconsistent patterns"
|
||||
- "Too many languages"
|
||||
recommendation: "Maintain consistency"
|
||||
|
||||
@@ -225,19 +225,15 @@
|
||||
|
||||
### Critical Issues Found
|
||||
|
||||
- [ ] Issue 1: **\*\***\_\_\_**\*\***
|
||||
- [ ] Issue 2: **\*\***\_\_\_**\*\***
|
||||
- [ ] Issue 3: **\*\***\_\_\_**\*\***
|
||||
<!-- replace with list of critical issues found, or N/A -->
|
||||
|
||||
### Recommended Actions Before Implementation
|
||||
|
||||
1. ***
|
||||
2. ***
|
||||
3. ***
|
||||
<!-- replace with list of recommended actions, or N/A -->
|
||||
|
||||
---
|
||||
|
||||
**Next Step**: Run the **solutioning-gate-check** workflow to validate alignment between PRD, Architecture, and Stories before beginning implementation.
|
||||
**Next Step**: Run the **solutioning-gate-check** workflow to validate alignment between PRD, UX, Architecture, and Stories before beginning implementation.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Decision Architecture can run standalone or as part of BMM workflow path.</output>
|
||||
<output>No workflow status file found. Create Architecture can run standalone or as part of BMM workflow path.</output>
|
||||
<output>**Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing.</output>
|
||||
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
||||
<check if="continue">
|
||||
@@ -33,17 +33,9 @@
|
||||
<action>Check status of "create-architecture" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_level < 3">
|
||||
<output>**Note: Level {{project_level}} Project**
|
||||
|
||||
The Detailed Architecture is typically for Level 3-4 projects, but can be used for any project that needs architectural planning.
|
||||
|
||||
For Level {{project_level}}, we'll keep the architecture appropriately scoped.
|
||||
</output>
|
||||
</check>
|
||||
|
||||
<check if="create-architecture status is file path (already completed)">
|
||||
<check if="create-architecture status is indicates already completed">
|
||||
<output>⚠️ Architecture already completed: {{create-architecture status}}</output>
|
||||
<ask>Re-running will overwrite the existing architecture. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
@@ -62,7 +54,6 @@ For Level {{project_level}}, we'll keep the architecture appropriately scoped.
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
|
||||
<action>Check for existing PRD and epics files using fuzzy matching</action>
|
||||
|
||||
@@ -70,21 +61,22 @@ For Level {{project_level}}, we'll keep the architecture appropriately scoped.
|
||||
<check if="PRD_not_found">
|
||||
<output>**PRD Not Found**
|
||||
|
||||
Decision Architecture works from your Product Requirements Document (PRD).
|
||||
Creation of an Architecture works from your Product Requirements Document (PRD), along with an optional UX Design and other assets.
|
||||
|
||||
Looking for: _PRD_, PRD.md, or prd/index.md + files in {output_folder}
|
||||
Looking for: _prd_.md, or prd/\* + files in {output_folder}
|
||||
|
||||
Please run the PRD workflow first to define your requirements.
|
||||
|
||||
Architect: `create-prd`
|
||||
Please talk to the PM Agent to run the Create PRD workflow first to define your requirements, or if I am mistaken and it does exist, provide the file now.
|
||||
</output>
|
||||
<action>Exit workflow - PRD required</action>
|
||||
<ask>Would you like to exit, or can you provide a PRD?
|
||||
<action if='yes to exit'>Exit workflow - PRD required</action>
|
||||
<action if='prd provided'>Proceed to Step 1</action>
|
||||
</ask>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Load and understand project context">
|
||||
<action>Load the PRD using fuzzy matching: {prd_file}, if the PRD is mulitple files in a folder, load the index file and all files associated with the PRD</action>
|
||||
<action>Load the PRD using fuzzy matching: {prd_file}, if the PRD is multiple files in a folder, load the index file and all files associated with the PRD</action>
|
||||
<action>Load epics file using fuzzy matching: {epics_file}</action>
|
||||
|
||||
<action>Check for UX specification using fuzzy matching:
|
||||
@@ -623,14 +615,15 @@ Enforcement: "All agents MUST follow this pattern"
|
||||
<action>Run validation checklist from {installed_path}/checklist.md</action>
|
||||
|
||||
<action>Verify MANDATORY items:
|
||||
□ Decision table has Version column with specific versions
|
||||
□ Every epic is mapped to architecture components
|
||||
□ Source tree is complete, not generic
|
||||
□ No placeholder text remains
|
||||
□ All FRs from PRD have architectural support
|
||||
□ All NFRs from PRD are addressed
|
||||
□ Implementation patterns cover all potential conflicts
|
||||
□ Novel patterns are fully documented (if applicable)
|
||||
|
||||
- [] Decision table has Version column with specific versions
|
||||
- [] Every epic is mapped to architecture components
|
||||
- [] Source tree is complete, not generic
|
||||
- [] No placeholder text remains
|
||||
- [] All FRs from PRD have architectural support
|
||||
- [] All NFRs from PRD are addressed
|
||||
- [] Implementation patterns cover all potential conflicts
|
||||
- [] Novel patterns are fully documented (if applicable)
|
||||
</action>
|
||||
|
||||
<check if="validation_failed">
|
||||
|
||||
@@ -12,29 +12,20 @@ document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Input requirements - We work from PRD, Epics, and optionally UX Spec
|
||||
recommended_inputs:
|
||||
- prd: "Product Requirements Document with FRs and NFRs"
|
||||
- epics: "Epic definitions with user stories and acceptance criteria"
|
||||
- ux_spec: "UX specification with interface designs and interaction patterns (optional)"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
input_file_patterns:
|
||||
prd:
|
||||
whole: "{output_folder}/*prd*.md"
|
||||
sharded: "{output_folder}/*prd*/index.md"
|
||||
|
||||
epics:
|
||||
whole: "{output_folder}/*epic*.md"
|
||||
sharded: "{output_folder}/*epic*/index.md"
|
||||
|
||||
ux_design:
|
||||
whole: "{output_folder}/*ux*.md"
|
||||
sharded: "{output_folder}/*ux*/index.md"
|
||||
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
sharded: "{output_folder}/index.md"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/architecture"
|
||||
@@ -50,20 +41,6 @@ pattern_categories: "{installed_path}/pattern-categories.csv"
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/architecture.md"
|
||||
|
||||
# Workflow metadata
|
||||
version: "1.3.2"
|
||||
replaces: "architecture"
|
||||
paradigm: "facilitation-driven"
|
||||
execution_time: "30-90 minutes depending on user skill level"
|
||||
features:
|
||||
- "Starter template discovery and integration"
|
||||
- "Dynamic version verification via web search"
|
||||
- "Adaptive facilitation by skill level"
|
||||
- "Decision-focused architecture"
|
||||
- "Novel pattern design for unique concepts"
|
||||
- "Intelligent pattern identification - LLM figures out what patterns matter"
|
||||
- "Implementation patterns for agent consistency"
|
||||
|
||||
standalone: true
|
||||
|
||||
# Web bundle configuration for standalone deployment
|
||||
|
||||
@@ -4,10 +4,10 @@
|
||||
|
||||
### Core Planning Documents
|
||||
|
||||
- [ ] PRD exists and is complete (Level 2-4 projects)
|
||||
- [ ] PRD exists and is complete
|
||||
- [ ] PRD contains measurable success criteria
|
||||
- [ ] PRD defines clear scope boundaries and exclusions
|
||||
- [ ] Architecture document exists (architecture\*.md) (Level 3-4 projects)
|
||||
- [ ] Architecture document exists (architecture\*.md)
|
||||
- [ ] Technical Specification exists with implementation details
|
||||
- [ ] Epic and story breakdown document exists
|
||||
- [ ] All documents are dated and versioned
|
||||
@@ -22,7 +22,7 @@
|
||||
|
||||
## Alignment Verification
|
||||
|
||||
### PRD to Architecture Alignment (Level 3-4)
|
||||
### PRD to Architecture Alignment
|
||||
|
||||
- [ ] Every functional requirement in PRD has architectural support documented
|
||||
- [ ] All non-functional requirements from PRD are addressed in architecture
|
||||
@@ -33,7 +33,7 @@
|
||||
- [ ] If architecture.md: All technology choices have verified versions
|
||||
- [ ] If UX spec exists: Architecture supports UX requirements
|
||||
|
||||
### PRD to Stories Coverage (Level 2-4)
|
||||
### PRD to Stories Coverage
|
||||
|
||||
- [ ] Every PRD requirement maps to at least one story
|
||||
- [ ] All user journeys in PRD have complete story coverage
|
||||
@@ -154,21 +154,15 @@
|
||||
|
||||
### Critical Issues Found
|
||||
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
<!-- checklist of critical issues or N/A -->
|
||||
|
||||
### High Priority Issues Found
|
||||
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
<!-- checklist of high priority issues or N/A -->
|
||||
|
||||
### Medium Priority Issues Found
|
||||
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
<!-- checklist of medium priority issues or N/A -->
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
<action>Check if {workflow_status_file} exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Implementation Ready Check can run standalone or as part of BMM workflow path.</output>
|
||||
@@ -23,14 +23,13 @@
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Load the FULL file: {workflow_status_file}</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "solutioning-gate-check" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Get {selected_track} (quick-flow, bmad-method, or enterprise-bmad-method)</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<action>Based on the project_level, understand what artifacts should exist: - Level 0-1: Tech spec and simple stories only (no PRD, minimal solutioning) - Level 2: PRD, tech spec, epics/stories (no separate architecture doc) - Level 3-4: Full suite - PRD, architecture document, epics/stories, possible UX artifacts
|
||||
</action>
|
||||
<action>Based on the selected_track, understand what artifacts should exist: - quick-flow: Tech spec and simple stories in an epic only (no PRD, minimal solutioning) - bmad-method and enterprise-bmad-method: PRD, tech spec, epics/stories, architecture, possible UX artifacts</action>
|
||||
|
||||
<check if="solutioning-gate-check status is file path (already completed)">
|
||||
<output>⚠️ Gate check already completed: {{solutioning-gate-check status}}</output>
|
||||
@@ -53,28 +52,18 @@
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
|
||||
<critical>The validation approach must adapt to the project level - don't look for documents that shouldn't exist at lower levels</critical>
|
||||
|
||||
<template-output>project_context</template-output>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Discover and inventory project artifacts">
|
||||
<action>Search the {output_folder} for relevant planning and solutioning documents based on project level identified in Step 0</action>
|
||||
<action>Search the {output_folder} for relevant planning and solutioning documents</action>
|
||||
|
||||
<action>For Level 0-1 projects, locate:
|
||||
|
||||
- Technical specification document(s)
|
||||
- Story/task lists or simple epic breakdowns
|
||||
- Any API or interface definitions
|
||||
</action>
|
||||
|
||||
<action>For Level 2-4 projects, locate:
|
||||
<action>Locate:
|
||||
|
||||
- Product Requirements Document (PRD)
|
||||
- Architecture document (architecture.md) (Level 3-4 only)
|
||||
- Technical Specification (Level 2 includes architecture within)
|
||||
- Architecture
|
||||
- Epic and story breakdowns
|
||||
- UX artifacts if the active path includes UX workflow
|
||||
- UX Design artifacts if the active path includes UX workflow
|
||||
- Any supplementary planning documents
|
||||
</action>
|
||||
|
||||
@@ -91,15 +80,15 @@
|
||||
|
||||
<step n="2" goal="Deep analysis of core planning documents">
|
||||
<action>Load and thoroughly analyze each discovered document to extract:
|
||||
- Core requirements and success criteria
|
||||
- Architectural decisions and constraints
|
||||
- Technical implementation approaches
|
||||
- User stories and acceptance criteria
|
||||
- Dependencies and sequencing requirements
|
||||
- Any assumptions or risks documented
|
||||
- Core requirements and success criteria
|
||||
- Architectural decisions and constraints
|
||||
- Technical implementation approaches
|
||||
- User stories and acceptance criteria
|
||||
- Dependencies and sequencing requirements
|
||||
- Any assumptions or risks documented
|
||||
</action>
|
||||
|
||||
<action>For PRD analysis (Level 2-4), focus on:
|
||||
<action>For PRD analysis, focus on:
|
||||
|
||||
- User requirements and use cases
|
||||
- Functional and non-functional requirements
|
||||
@@ -131,9 +120,8 @@
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Cross-reference validation and alignment check">
|
||||
<action>Systematically validate alignment between all artifacts, adapting validation based on project level</action>
|
||||
|
||||
<action>PRD ↔ Architecture Alignment (Level 3-4):
|
||||
<action>PRD ↔ Architecture Alignment:
|
||||
|
||||
- Verify every PRD requirement has corresponding architectural support
|
||||
- Check that architectural decisions don't contradict PRD constraints
|
||||
@@ -142,7 +130,7 @@
|
||||
- If using new architecture workflow: verify implementation patterns are defined
|
||||
</action>
|
||||
|
||||
<action>PRD ↔ Stories Coverage (Level 2-4):
|
||||
<action>PRD ↔ Stories Coverage:
|
||||
|
||||
- Map each PRD requirement to implementing stories
|
||||
- Identify any PRD requirements without story coverage
|
||||
@@ -158,13 +146,6 @@
|
||||
- Ensure infrastructure and setup stories exist for architectural components
|
||||
</action>
|
||||
|
||||
<action>For Level 0-1 projects (Tech Spec only):
|
||||
|
||||
- Validate internal consistency within tech spec
|
||||
- Check that all specified features have corresponding stories
|
||||
- Verify story sequencing matches technical dependencies
|
||||
</action>
|
||||
|
||||
<template-output>alignment_validation</template-output>
|
||||
</step>
|
||||
|
||||
@@ -219,20 +200,20 @@
|
||||
</step>
|
||||
|
||||
<step n="5" goal="UX and special concerns validation" optional="true">
|
||||
<check if="UX artifacts exist or UX workflow in active path">
|
||||
<action>Review UX artifacts and validate integration:
|
||||
- Check that UX requirements are reflected in PRD
|
||||
- Verify stories include UX implementation tasks
|
||||
- Ensure architecture supports UX requirements (performance, responsiveness)
|
||||
- Identify any UX concerns not addressed in stories
|
||||
</action>
|
||||
<check if="UX artifacts exist or UX workflow in active path">
|
||||
<action>Review UX artifacts and validate integration:
|
||||
- Check that UX requirements are reflected in PRD
|
||||
- Verify stories include UX implementation tasks
|
||||
- Ensure architecture supports UX requirements (performance, responsiveness)
|
||||
- Identify any UX concerns not addressed in stories
|
||||
</action>
|
||||
|
||||
<action>Validate accessibility and usability coverage:
|
||||
<action>Validate accessibility and usability coverage:
|
||||
- Check for accessibility requirement coverage in stories
|
||||
- Verify responsive design considerations if applicable
|
||||
- Ensure user flow completeness across stories
|
||||
</action>
|
||||
|
||||
- Check for accessibility requirement coverage in stories
|
||||
- Verify responsive design considerations if applicable
|
||||
- Ensure user flow completeness across stories
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<template-output>ux_validation</template-output>
|
||||
@@ -269,7 +250,7 @@
|
||||
|
||||
<step n="7" goal="Update status and complete" tag="workflow-status">
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Load the FULL file: {workflow_status_file}</action>
|
||||
<action>Find workflow_status key "solutioning-gate-check"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["solutioning-gate-check"] = "{output_folder}/bmm-readiness-assessment-{{date}}.md"</action>
|
||||
|
||||
@@ -1,189 +0,0 @@
|
||||
# Implementation Readiness Validation Criteria
|
||||
# Defines systematic validation rules by project level
|
||||
|
||||
validation_rules:
|
||||
# Level 0-1 Projects (Simple, minimal planning)
|
||||
level_0_1:
|
||||
required_documents:
|
||||
- tech_spec
|
||||
- stories_or_tasks
|
||||
|
||||
validations:
|
||||
- name: "Tech Spec Completeness"
|
||||
checks:
|
||||
- "All features defined with implementation approach"
|
||||
- "Technical dependencies identified"
|
||||
- "API contracts defined if applicable"
|
||||
- "Data models specified"
|
||||
|
||||
- name: "Story Coverage"
|
||||
checks:
|
||||
- "All tech spec features have corresponding stories"
|
||||
- "Stories are sequenced logically"
|
||||
- "Technical tasks are defined"
|
||||
- "No critical gaps in coverage"
|
||||
|
||||
# Level 2 Projects (PRD + Tech Spec, no separate architecture)
|
||||
level_2:
|
||||
required_documents:
|
||||
- prd
|
||||
- tech_spec # Includes architecture decisions
|
||||
- epics_and_stories
|
||||
|
||||
validations:
|
||||
- name: "PRD to Tech Spec Alignment"
|
||||
checks:
|
||||
- "All PRD requirements addressed in tech spec"
|
||||
- "Architecture embedded in tech spec covers PRD needs"
|
||||
- "Non-functional requirements are specified"
|
||||
- "Technical approach supports business goals"
|
||||
|
||||
- name: "Story Coverage and Alignment"
|
||||
checks:
|
||||
- "Every PRD requirement has story coverage"
|
||||
- "Stories align with tech spec approach"
|
||||
- "Epic breakdown is complete"
|
||||
- "Acceptance criteria match PRD success criteria"
|
||||
|
||||
- name: "Sequencing Validation"
|
||||
checks:
|
||||
- "Foundation stories come first"
|
||||
- "Dependencies are properly ordered"
|
||||
- "Iterative delivery is possible"
|
||||
- "No circular dependencies"
|
||||
|
||||
# Level 3-4 Projects (Full planning with separate architecture)
|
||||
level_3_4:
|
||||
required_documents:
|
||||
- prd
|
||||
- architecture
|
||||
- epics_and_stories
|
||||
|
||||
validations:
|
||||
- name: "PRD Completeness"
|
||||
checks:
|
||||
- "User requirements fully documented"
|
||||
- "Success criteria are measurable"
|
||||
- "Scope boundaries clearly defined"
|
||||
- "Priorities are assigned"
|
||||
|
||||
- name: "Architecture Coverage"
|
||||
checks:
|
||||
- "All PRD requirements have architectural support"
|
||||
- "System design is complete"
|
||||
- "Integration points defined"
|
||||
- "Security architecture specified"
|
||||
- "Performance considerations addressed"
|
||||
- "If architecture.md: Implementation patterns defined"
|
||||
- "If architecture.md: Technology versions verified and current"
|
||||
- "If architecture.md: Starter template command documented (if applicable)"
|
||||
|
||||
- name: "PRD-Architecture Alignment"
|
||||
checks:
|
||||
- "No architecture gold-plating beyond PRD"
|
||||
- "NFRs from PRD reflected in architecture"
|
||||
- "Technology choices support requirements"
|
||||
- "Scalability matches expected growth"
|
||||
- "If UX spec exists: Architecture supports UX requirements"
|
||||
- "If UX spec exists: Component library supports interaction patterns"
|
||||
|
||||
- name: "Story Implementation Coverage"
|
||||
checks:
|
||||
- "All architectural components have stories"
|
||||
- "Infrastructure setup stories exist"
|
||||
- "Integration implementation planned"
|
||||
- "Security implementation stories present"
|
||||
|
||||
- name: "Comprehensive Sequencing"
|
||||
checks:
|
||||
- "Infrastructure before features"
|
||||
- "Authentication before protected resources"
|
||||
- "Core features before enhancements"
|
||||
- "Dependencies properly ordered"
|
||||
- "Allows for iterative releases"
|
||||
|
||||
# Special validation contexts
|
||||
special_contexts:
|
||||
greenfield:
|
||||
additional_checks:
|
||||
- "Project initialization stories exist"
|
||||
- "If using architecture.md: First story is starter template initialization"
|
||||
- "Development environment setup documented"
|
||||
- "CI/CD pipeline stories included"
|
||||
- "Initial data/schema setup planned"
|
||||
- "Deployment infrastructure stories present"
|
||||
|
||||
ux_workflow_active:
|
||||
additional_checks:
|
||||
- "UX requirements in PRD"
|
||||
- "UX implementation stories exist"
|
||||
- "Accessibility requirements covered"
|
||||
- "Responsive design addressed"
|
||||
- "User flow continuity maintained"
|
||||
|
||||
api_heavy:
|
||||
additional_checks:
|
||||
- "API contracts fully defined"
|
||||
- "Versioning strategy documented"
|
||||
- "Authentication/authorization specified"
|
||||
- "Rate limiting considered"
|
||||
- "API documentation stories included"
|
||||
|
||||
# Severity definitions
|
||||
severity_levels:
|
||||
critical:
|
||||
description: "Must be resolved before implementation"
|
||||
examples:
|
||||
- "Missing stories for core requirements"
|
||||
- "Conflicting technical approaches"
|
||||
- "No infrastructure setup for greenfield"
|
||||
- "Security requirements not addressed"
|
||||
|
||||
high:
|
||||
description: "Should be addressed to reduce risk"
|
||||
examples:
|
||||
- "Incomplete acceptance criteria"
|
||||
- "Unclear story dependencies"
|
||||
- "Missing error handling coverage"
|
||||
- "Performance requirements not validated"
|
||||
|
||||
medium:
|
||||
description: "Consider addressing for smoother implementation"
|
||||
examples:
|
||||
- "Documentation gaps"
|
||||
- "Test strategy not defined"
|
||||
- "Monitoring approach unclear"
|
||||
- "Minor sequencing improvements possible"
|
||||
|
||||
low:
|
||||
description: "Minor improvements for consideration"
|
||||
examples:
|
||||
- "Formatting inconsistencies"
|
||||
- "Optional enhancements identified"
|
||||
- "Style guide compliance"
|
||||
- "Nice-to-have features noted"
|
||||
|
||||
# Readiness decision criteria
|
||||
readiness_decisions:
|
||||
ready:
|
||||
criteria:
|
||||
- "No critical issues found"
|
||||
- "All required documents present"
|
||||
- "Core alignments validated"
|
||||
- "Story sequencing logical"
|
||||
- "Team can begin implementation"
|
||||
|
||||
ready_with_conditions:
|
||||
criteria:
|
||||
- "Only high/medium issues found"
|
||||
- "Mitigation plans identified"
|
||||
- "Core path to MVP clear"
|
||||
- "Issues won't block initial stories"
|
||||
|
||||
not_ready:
|
||||
criteria:
|
||||
- "Critical issues identified"
|
||||
- "Major gaps in coverage"
|
||||
- "Conflicting approaches found"
|
||||
- "Required documents missing"
|
||||
- "Blocking dependencies unresolved"
|
||||
@@ -14,6 +14,7 @@ date: system-generated
|
||||
# Workflow status integration
|
||||
workflow_status_workflow: "{project-root}/{bmad_folder}/bmm/workflows/workflow-status/workflow.yaml"
|
||||
workflow_paths_dir: "{project-root}/{bmad_folder}/bmm/workflows/workflow-status/paths"
|
||||
workflow_status_file: "{output_folder}/bmm-workflow-status.yaml"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/solutioning-gate-check"
|
||||
@@ -38,29 +39,21 @@ input_file_patterns:
|
||||
prd:
|
||||
whole: "{output_folder}/*prd*.md"
|
||||
sharded: "{output_folder}/*prd*/index.md"
|
||||
|
||||
epics:
|
||||
whole: "{output_folder}/*epic*.md"
|
||||
sharded: "{output_folder}/*epic*/index.md"
|
||||
|
||||
architecture:
|
||||
whole: "{output_folder}/*architecture*.md"
|
||||
sharded: "{output_folder}/*architecture*/index.md"
|
||||
|
||||
ux_design:
|
||||
whole: "{output_folder}/*ux*.md"
|
||||
sharded: "{output_folder}/*ux*/index.md"
|
||||
|
||||
tech_spec:
|
||||
whole: "{output_folder}/*tech-spec*.md"
|
||||
sharded: "{output_folder}/*tech-spec*/index.md"
|
||||
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
|
||||
# Validation criteria data
|
||||
validation_criteria: "{installed_path}/validation-criteria.yaml"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle: false
|
||||
|
||||
@@ -11,29 +11,24 @@ communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
date: system-generated
|
||||
ephemeral_files: "{config_source}:dev_ephemeral_location"
|
||||
sprint_status: "{context_dir}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/code-review"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
# This is an action workflow (no output template document)
|
||||
template: false
|
||||
|
||||
# Variables (can be provided by caller)
|
||||
variables:
|
||||
story_path: "{ephemeral_files}/stories" # Optional: Explicit path to story file. If not provided, finds first story with status "review"
|
||||
story_dir: "{ephemeral_files}/stories" # Directory containing story files
|
||||
tech_spec_search_dir: "{project-root}/docs"
|
||||
story_dir: "{sprint_artifacts}"
|
||||
tech_spec_search_dir: "{output_folder}"
|
||||
tech_spec_glob_template: "tech-spec-epic-{{epic_num}}*.md"
|
||||
arch_docs_search_dirs: |
|
||||
- "{project-root}/docs"
|
||||
- "{output_folder}"
|
||||
arch_docs_file_names: |
|
||||
- architecture.md
|
||||
backlog_file: "{project-root}/docs/backlog.md"
|
||||
backlog_file: "{output_folder}/backlog.md"
|
||||
update_epic_followups: true
|
||||
epic_followups_section_title: "Post-Review Follow-ups"
|
||||
|
||||
@@ -55,5 +50,4 @@ input_file_patterns:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle: false
|
||||
|
||||
@@ -18,28 +18,6 @@ validation: "{installed_path}/checklist.md"
|
||||
checklist: "{installed_path}/checklist.md"
|
||||
default_output_file: "{output_folder}/sprint-change-proposal-{date}.md"
|
||||
|
||||
# Workflow execution mode (interactive: step-by-step with user, non-interactive: automated)
|
||||
mode: interactive
|
||||
|
||||
required_inputs:
|
||||
- change_trigger: "Description of the issue or change that triggered this workflow"
|
||||
- project_documents: "Access to PRD, Epics/Stories, Architecture, UI/UX specs"
|
||||
|
||||
output_artifacts:
|
||||
- sprint_change_proposal: "Comprehensive proposal documenting issue, impact, and recommended changes"
|
||||
- artifact_edits: "Specific before/after edits for affected documents"
|
||||
- handoff_plan: "Clear routing for implementation based on change scope"
|
||||
|
||||
halt_conditions:
|
||||
- "Change trigger unclear or undefined"
|
||||
- "Core project documents unavailable"
|
||||
- "Impact analysis incomplete"
|
||||
- "User approval not obtained"
|
||||
|
||||
execution_modes:
|
||||
- incremental: "Recommended - Refine each edit with user collaboration"
|
||||
- batch: "Present all changes at once for review"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle: false
|
||||
|
||||
@@ -10,43 +10,14 @@
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Load config and initialize">
|
||||
<action>Resolve variables from config_source: story_dir (dev_ephemeral_location), output_folder, user_name, communication_language. If story_dir missing → ASK user to provide a stories directory and update variable.</action>
|
||||
<action>Resolve variables from config_source: story_dir (sprint_artifacts), output_folder, user_name, communication_language. If story_dir missing → ASK user to provide a stories directory and update variable.</action>
|
||||
<action>Create {{story_dir}} if it does not exist</action>
|
||||
<action>Resolve installed component paths from workflow.yaml: template, instructions, validation</action>
|
||||
<action>Resolve recommended inputs if present: epics_file, prd_file, architecture_file</action>
|
||||
<action>Load architecture/standards docs: For each file name in {{arch_docs_file_names}} within {{arch_docs_search_dirs}}, read if exists. Collect testing, coding standards, security, and architectural patterns.</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Discover and load source documents">
|
||||
<action>
|
||||
Selective Epic Loading
|
||||
|
||||
**Strategy**: This workflow needs only ONE specific epic and its stories, not all epics. This provides huge efficiency gains when epics are sharded.
|
||||
|
||||
**Epic Discovery Process (SELECTIVE OPTIMIZATION):**
|
||||
|
||||
1. **Determine which epic** you need (epic_num from story context - e.g., story "3-2-feature-name" needs Epic 3)
|
||||
2. **Check for sharded version**: Look for `epics/*n*.md` where n is the epic number such as epics/epic-3-foo.md
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand structure
|
||||
- **Load ONLY `epic-{epic_num}.md`** (e.g., `epics/epic-3.md` for Epic 3)
|
||||
- DO NOT load all epic files - only the one needed!
|
||||
- This is the key efficiency optimization for large multi-epic projects
|
||||
4. **If whole document found**: Load the complete `epics.md` file and extract the relevant epic
|
||||
|
||||
**Other Documents (prd, architecture, ux-design) - Full Load:**
|
||||
|
||||
1. **Search for whole document first** - Use fuzzy file matching
|
||||
2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand structure
|
||||
- Read ALL section files listed in the index
|
||||
- Treat combined content as single document
|
||||
4. **Brownfield projects**: The `document-project` workflow creates `{output_folder}/docs/index.md`
|
||||
|
||||
**Priority**: If both whole and sharded versions exist, use the whole document.
|
||||
|
||||
**UX-Heavy Projects**: Always check for ux-design documentation as it provides critical context for UI-focused stories.
|
||||
</action>
|
||||
<critical>PREVIOUS STORY CONTINUITY: Essential for maintaining context and learning from prior development</critical>
|
||||
|
||||
<action>Find the previous completed story to extract dev agent learnings and review findings:
|
||||
@@ -139,12 +110,12 @@
|
||||
<check if="no backlog story found">
|
||||
<output>📋 No backlog stories found in sprint-status.yaml
|
||||
|
||||
All stories are either already drafted or completed.
|
||||
All stories are either already drafted or completed.
|
||||
|
||||
**Options:**
|
||||
1. Run sprint-planning to refresh story tracking
|
||||
2. Load PM agent and run correct-course to add more stories
|
||||
3. Check if current sprint is complete
|
||||
**Options:**
|
||||
1. Run sprint-planning to refresh story tracking
|
||||
2. Load PM agent and run correct-course to add more stories
|
||||
3. Check if current sprint is complete
|
||||
</output>
|
||||
<action>HALT</action>
|
||||
</check>
|
||||
|
||||
@@ -8,7 +8,7 @@ output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
story_dir: "{config_source}:dev_ephemeral_location/stories"
|
||||
story_dir: "{config_source}:sprint_artifacts"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/create-story"
|
||||
@@ -18,7 +18,7 @@ validation: "{installed_path}/checklist.md"
|
||||
|
||||
# Variables and inputs
|
||||
variables:
|
||||
sprint_status: "{config_source}:dev_ephemeral_location/sprint-status.yaml || {output_folder}/sprint-status.yaml" # Primary source for story tracking
|
||||
sprint_status: "{config_source}:sprint_artifacts/sprint-status.yaml || {output_folder}/sprint-status.yaml" # Primary source for story tracking
|
||||
epics_file: "{output_folder}/epics.md" # Preferred source for epic/story breakdown
|
||||
prd_file: "{output_folder}/PRD.md" # Fallback for requirements
|
||||
architecture_file: "{output_folder}/architecture.md" # Optional architecture context
|
||||
@@ -32,8 +32,6 @@ variables:
|
||||
- *architecture*.md
|
||||
story_title: "" # Will be elicited if not derivable
|
||||
|
||||
# Output configuration
|
||||
# Uses story_key from sprint-status.yaml (e.g., "1-2-user-authentication")
|
||||
default_output_file: "{story_dir}/{{story_key}}.md"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
|
||||
@@ -1,367 +0,0 @@
|
||||
# Workflow Audit Report
|
||||
|
||||
**Workflow:** dev-story
|
||||
**Audit Date:** 2025-10-25
|
||||
**Auditor:** Audit Workflow (BMAD v6)
|
||||
**Workflow Type:** Action Workflow
|
||||
**Module:** BMM (BMad Method)
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
**Overall Status:** GOOD - Minor issues to address
|
||||
|
||||
- Critical Issues: 0
|
||||
- Important Issues: 3
|
||||
- Cleanup Recommendations: 2
|
||||
|
||||
The dev-story workflow is well-structured and follows most BMAD v6 standards. The workflow correctly sets `web_bundle: false` as expected for implementation workflows. However, there are several config variable usage issues and some variables referenced in instructions that are not defined in the YAML.
|
||||
|
||||
---
|
||||
|
||||
## 1. Standard Config Block Validation
|
||||
|
||||
**Status:** PASS ✓
|
||||
|
||||
The workflow.yaml contains all required standard config variables:
|
||||
|
||||
- ✓ `config_source: "{project-root}/{bmad_folder}/bmm/config.yaml"` - Correctly defined
|
||||
- ✓ `output_folder: "{config_source}:output_folder"` - Pulls from config_source
|
||||
- ✓ `user_name: "{config_source}:user_name"` - Pulls from config_source
|
||||
- ✓ `communication_language: "{config_source}:communication_language"` - Pulls from config_source
|
||||
- ✓ `date: system-generated` - Correctly set
|
||||
|
||||
All standard config variables are present and properly formatted using {project-root} variable syntax.
|
||||
|
||||
---
|
||||
|
||||
## 2. YAML/Instruction/Template Alignment
|
||||
|
||||
**Variables Analyzed:** 9 (excluding standard config)
|
||||
**Used in Instructions:** 6
|
||||
**Unused (Bloat):** 3
|
||||
|
||||
### YAML Variables Defined
|
||||
|
||||
1. `story_dir` - USED in instructions (file paths)
|
||||
2. `context_path` - UNUSED (appears to duplicate story_dir)
|
||||
3. `story_file` - USED in instructions
|
||||
4. `context_file` - USED in instructions
|
||||
5. `installed_path` - USED in instructions (workflow.xml reference)
|
||||
6. `instructions` - USED in instructions (self-reference in critical tag)
|
||||
7. `validation` - USED in instructions (checklist reference)
|
||||
8. `web_bundle` - CONFIGURATION (correctly set to false)
|
||||
9. `date` - USED in instructions (config variable)
|
||||
|
||||
### Variables Used in Instructions But NOT Defined in YAML
|
||||
|
||||
**IMPORTANT ISSUE:** The following variables are referenced in instructions.md but are NOT defined in workflow.yaml:
|
||||
|
||||
1. `{user_skill_level}` - Used 4 times (lines 6, 13, 173, 182)
|
||||
2. `{document_output_language}` - Used 1 time (line 7)
|
||||
3. `{run_until_complete}` - Used 1 time (line 108)
|
||||
4. `{run_tests_command}` - Used 1 time (line 120)
|
||||
|
||||
These variables appear to be pulling from config.yaml but are not explicitly defined in the workflow.yaml file. While the config_source mechanism may provide these, workflow.yaml should document all variables used in the workflow for clarity.
|
||||
|
||||
### Unused Variables (Bloat)
|
||||
|
||||
1. **context_path** - Defined as `"{config_source}:dev_ephemeral_location"` but never used. This duplicates `story_dir` functionality.
|
||||
|
||||
---
|
||||
|
||||
## 3. Config Variable Usage
|
||||
|
||||
**Communication Language:** PASS ✓
|
||||
**User Name:** PASS ✓
|
||||
**Output Folder:** PASS ✓
|
||||
**Date:** PASS ✓
|
||||
|
||||
### Detailed Analysis
|
||||
|
||||
**Communication Language:**
|
||||
|
||||
- ✓ Used in line 6: "Communicate all responses in {communication_language}"
|
||||
- ✓ Properly used as agent instruction variable (not in template)
|
||||
|
||||
**User Name:**
|
||||
|
||||
- ✓ Used in line 169: "Communicate to {user_name} that story implementation is complete"
|
||||
- ✓ Appropriately used for personalization
|
||||
|
||||
**Output Folder:**
|
||||
|
||||
- ✓ Used multiple times for sprint-status.yaml file paths
|
||||
- ✓ All file operations target {output_folder} correctly
|
||||
- ✓ No hardcoded paths detected
|
||||
|
||||
**Date:**
|
||||
|
||||
- ✓ Available for agent use (system-generated)
|
||||
- ✓ Used appropriately in context of workflow execution
|
||||
|
||||
### Additional Config Variables
|
||||
|
||||
**IMPORTANT ISSUE:** The workflow uses additional variables that appear to come from config but are not explicitly documented:
|
||||
|
||||
1. `{user_skill_level}` - Used to tailor communication style
|
||||
2. `{document_output_language}` - Used for document generation
|
||||
3. `{run_until_complete}` - Used for execution control
|
||||
4. `{run_tests_command}` - Used for test execution
|
||||
|
||||
These should either be:
|
||||
|
||||
- Added to workflow.yaml with proper config_source references, OR
|
||||
- Documented as optional config variables with defaults
|
||||
|
||||
---
|
||||
|
||||
## 4. Web Bundle Validation
|
||||
|
||||
**Web Bundle Present:** No (Intentional)
|
||||
**Status:** EXPECTED ✓
|
||||
|
||||
The workflow correctly sets `web_bundle: false`. This is the expected configuration for implementation workflows that:
|
||||
|
||||
- Run locally in the development environment
|
||||
- Don't need to be bundled for web deployment
|
||||
- Are IDE-integrated workflows
|
||||
|
||||
**No issues found** - This is the correct configuration for dev-story.
|
||||
|
||||
---
|
||||
|
||||
## 5. Bloat Detection
|
||||
|
||||
**Bloat Percentage:** 11% (1 unused field / 9 total fields)
|
||||
**Cleanup Potential:** Low
|
||||
|
||||
### Unused YAML Fields
|
||||
|
||||
1. **context_path** (line 11 in workflow.yaml)
|
||||
- Defined as: `"{config_source}:dev_ephemeral_location"`
|
||||
- Never referenced in instructions.md
|
||||
- Duplicates functionality of `story_dir` variable
|
||||
- **Recommendation:** Remove this variable as `story_dir` serves the same purpose
|
||||
|
||||
### Hardcoded Values
|
||||
|
||||
No significant hardcoded values that should be variables were detected. The workflow properly uses variables for:
|
||||
|
||||
- File paths ({output_folder}, {story_dir})
|
||||
- User personalization ({user_name})
|
||||
- Communication style ({communication_language}, {user_skill_level})
|
||||
|
||||
### Calculation
|
||||
|
||||
- Total yaml fields: 9 (excluding standard config and metadata)
|
||||
- Used fields: 8
|
||||
- Unused fields: 1 (context_path)
|
||||
- Bloat percentage: 11%
|
||||
|
||||
**Status:** Acceptable (under 15% threshold)
|
||||
|
||||
---
|
||||
|
||||
## 6. Template Variable Mapping
|
||||
|
||||
**Not Applicable** - This is an action workflow, not a document workflow.
|
||||
|
||||
No template.md file exists, which is correct for action-type workflows.
|
||||
|
||||
---
|
||||
|
||||
## 7. Instructions Quality Analysis
|
||||
|
||||
### Structure
|
||||
|
||||
- ✓ Steps numbered sequentially (1, 1.5, 2-7)
|
||||
- ✓ Each step has clear goal attributes
|
||||
- ✓ Proper use of XML tags (<action>, <check>, <goto>, <anchor>, <output>)
|
||||
- ✓ Logical flow control with anchors and conditional checks
|
||||
- ✓ Repeat patterns used appropriately (step 2-5 loop)
|
||||
|
||||
### Critical Tags
|
||||
|
||||
- ✓ Critical blocks present and well-defined
|
||||
- ✓ Clear references to workflow execution engine
|
||||
- ✓ Workflow.yaml load requirement specified
|
||||
- ✓ Communication preferences documented
|
||||
|
||||
### Variable Usage Consistency
|
||||
|
||||
**ISSUE:** Inconsistent variable syntax found:
|
||||
|
||||
1. Lines 4, 5 use `{project_root}` (underscore)
|
||||
2. Line 166 uses `{project-root}` (hyphen)
|
||||
|
||||
**Recommendation:** Standardize to `{project-root}` throughout (hyphen is the standard in BMAD v6)
|
||||
|
||||
### Step Quality
|
||||
|
||||
**Excellent:**
|
||||
|
||||
- Steps are focused and single-purpose
|
||||
- Clear HALT conditions defined
|
||||
- Comprehensive validation checks
|
||||
- Good error handling patterns
|
||||
- Iterative execution model well-structured
|
||||
|
||||
**Areas for improvement:**
|
||||
|
||||
- Step 1 is complex and could potentially be split
|
||||
- Some <action if="..."> conditionals could be clearer with <check> blocks
|
||||
|
||||
---
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Critical (Fix Immediately)
|
||||
|
||||
None - No critical issues detected.
|
||||
|
||||
### Important (Address Soon)
|
||||
|
||||
1. **Document or Define Missing Variables**
|
||||
- Add explicit definitions in workflow.yaml for: `user_skill_level`, `document_output_language`, `run_until_complete`, `run_tests_command`
|
||||
- OR document these as optional config variables with defaults
|
||||
- These variables are used in instructions but not defined in YAML
|
||||
- **Impact:** Reduces clarity and may cause confusion about variable sources
|
||||
|
||||
2. **Standardize project-root Variable Syntax**
|
||||
- Change line 4 `{project_root}` to `{project-root}` (hyphen)
|
||||
- Ensure consistency with BMAD v6 standard naming convention
|
||||
- **Impact:** Maintains consistency with framework standards
|
||||
|
||||
3. **Remove or Use context_path Variable**
|
||||
- Variable `context_path` is defined but never used
|
||||
- Since `story_dir` serves the same purpose, remove `context_path`
|
||||
- OR if there's a semantic difference, document why both exist
|
||||
- **Impact:** Reduces bloat and potential confusion
|
||||
|
||||
### Cleanup (Nice to Have)
|
||||
|
||||
1. **Consider Splitting Step 1**
|
||||
- Step 1 handles both story discovery AND file loading
|
||||
- Could be split into "1. Find Story" and "2. Load Story Files"
|
||||
- Would improve clarity and maintainability
|
||||
- **Impact:** Minor improvement to workflow structure
|
||||
|
||||
2. **Add Variable Documentation Comment**
|
||||
- Add a comment block in workflow.yaml listing all variables used by this workflow
|
||||
- Include both explicit YAML variables and config-pulled variables
|
||||
- Example format:
|
||||
```yaml
|
||||
# Workflow-specific variables
|
||||
# - story_file: Path to story markdown
|
||||
# - story_dir: Directory containing stories
|
||||
#
|
||||
# Config-pulled variables (from bmm/config.yaml)
|
||||
# - user_skill_level: User's technical skill level
|
||||
# - document_output_language: Language for generated docs
|
||||
```
|
||||
- **Impact:** Improves developer understanding and maintenance
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
### Structure ✓
|
||||
|
||||
- [x] workflow.yaml loads without YAML syntax errors
|
||||
- [x] instructions.md exists and is properly formatted
|
||||
- [x] No template.md (correct for action workflow)
|
||||
- [x] All critical headers present in instructions
|
||||
- [x] Workflow type correctly identified (action)
|
||||
- [x] All referenced files exist
|
||||
- [x] No placeholder text remains
|
||||
|
||||
### Standard Config Block ✓
|
||||
|
||||
- [x] config_source points to correct module config
|
||||
- [x] output_folder pulls from config_source
|
||||
- [x] user_name pulls from config_source
|
||||
- [x] communication_language pulls from config_source
|
||||
- [x] date is system-generated
|
||||
- [x] Config source uses {project-root} variable
|
||||
- [x] Standard config comment present
|
||||
|
||||
### Config Variable Usage ✓
|
||||
|
||||
- [x] Instructions communicate in {communication_language}
|
||||
- [x] Instructions address {user_name}
|
||||
- [x] All file outputs use {output_folder}
|
||||
- [x] No hardcoded paths
|
||||
- [x] Date available for agent awareness
|
||||
|
||||
### YAML/Instruction/Template Alignment ⚠️
|
||||
|
||||
- [⚠️] Some variables used in instructions not defined in YAML
|
||||
- [x] Template variables N/A (action workflow)
|
||||
- [x] Variable names are descriptive
|
||||
- [⚠️] One unused yaml field (context_path)
|
||||
|
||||
### Web Bundle Validation ✓
|
||||
|
||||
- [x] web_bundle: false is correct for this workflow
|
||||
- [x] No web_bundle section needed
|
||||
- [x] Workflow is local/IDE-integrated only
|
||||
|
||||
### Instructions Quality ✓
|
||||
|
||||
- [x] Steps numbered sequentially
|
||||
- [x] Clear goal attributes
|
||||
- [x] Proper XML tag usage
|
||||
- [x] Logical flow control
|
||||
- [⚠️] Minor inconsistency: {project_root} vs {project-root}
|
||||
|
||||
### Bloat Detection ✓
|
||||
|
||||
- [x] Bloat percentage: 11% (acceptable, under 15%)
|
||||
- [x] No significant hardcoded values
|
||||
- [x] No redundant configuration
|
||||
- [x] One cleanup recommendation (context_path)
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Define missing variables** - Add explicit YAML definitions or document as config-pulled variables
|
||||
2. **Standardize variable syntax** - Change `{project_root}` to `{project-root}`
|
||||
3. **Remove context_path** - Clean up unused variable
|
||||
4. **Re-run audit** - Verify improvements after fixes
|
||||
|
||||
---
|
||||
|
||||
## Additional Notes
|
||||
|
||||
### Strengths
|
||||
|
||||
1. **Comprehensive Workflow Logic:** The dev-story workflow is well-thought-out with proper error handling, validation gates, and iterative execution
|
||||
2. **Config Integration:** Excellent use of config variables for user personalization and output management
|
||||
3. **Clear Documentation:** Instructions are detailed with specific HALT conditions and validation checkpoints
|
||||
4. **Proper Web Bundle Setting:** Correctly identifies this as a local-only workflow with web_bundle: false
|
||||
5. **Step Flow:** Excellent use of anchors, goto, and conditional checks for complex flow control
|
||||
|
||||
### Workflow Purpose
|
||||
|
||||
This workflow executes user stories by:
|
||||
|
||||
- Finding ready-for-dev stories from sprint status
|
||||
- Implementing tasks and subtasks incrementally
|
||||
- Writing comprehensive tests
|
||||
- Validating against acceptance criteria
|
||||
- Updating story status through sprint lifecycle
|
||||
- Supporting different user skill levels with adaptive communication
|
||||
|
||||
The workflow is a critical part of the BMM implementation phase and shows mature design patterns.
|
||||
|
||||
---
|
||||
|
||||
**Audit Complete** - Generated by audit-workflow v1.0
|
||||
|
||||
**Pass Rate:** 89% (62 passed / 70 total checks)
|
||||
**Recommendation:** Good - Minor fixes needed
|
||||
|
||||
The dev-story workflow is production-ready with minor improvements recommended. The issues identified are primarily documentation and consistency improvements rather than functional problems.
|
||||
@@ -9,9 +9,7 @@ user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
story_dir: "{config_source}:dev_ephemeral_location"
|
||||
run_until_complete: "{config_source}:run_until_complete"
|
||||
run_tests_command: "{config_source}:run_tests_command"
|
||||
story_dir: "{config_source}:sprint_artifacts"
|
||||
date: system-generated
|
||||
|
||||
story_file: "" # Explicit story path; auto-discovered if empty
|
||||
|
||||
@@ -15,7 +15,7 @@
|
||||
|
||||
**Epic Discovery Process (SELECTIVE OPTIMIZATION):**
|
||||
|
||||
1. **Determine which epic** you need (epic_num from workflow context or user input)
|
||||
1. **Determine which epic** you need (epic_num from {sprint_status} or user input)
|
||||
2. **Check for sharded version**: Look for `epics/index.md`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand structure
|
||||
@@ -27,7 +27,7 @@
|
||||
**Other Documents (prd, gdd, architecture, ux-design) - Full Load:**
|
||||
|
||||
1. **Search for whole document first** - Use fuzzy file matching
|
||||
2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md`
|
||||
2. **Check for sharded version** - If whole document not found, look for `{doc-name}/*.*`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand structure
|
||||
- Read ALL section files listed in the index
|
||||
@@ -158,7 +158,7 @@ Continuing to regenerate tech spec...
|
||||
<invoke-task>Validate against checklist at {installed_path}/checklist.md using {bmad_folder}/core/tasks/validate-workflow.xml</invoke-task>
|
||||
|
||||
<!-- Mark epic as contexted -->
|
||||
<action>Load the FULL file: {{output_folder}}/sprint-status.yaml</action>
|
||||
<action>Load the FULL file: {sprint_status}</action>
|
||||
<action>Find development_status key "epic-{{epic_id}}"</action>
|
||||
<action>Verify current status is "backlog" (expected previous state)</action>
|
||||
<action>Update development_status["epic-{{epic_id}}"] = "contexted"</action>
|
||||
|
||||
@@ -8,8 +8,8 @@ output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
context_dir: "{config_source}:dev_ephemeral_location/stories"
|
||||
sprint_status: "{context_dir}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
@@ -41,8 +41,6 @@ instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{context_dir}/tech-spec-epic-{{epic_id}}.md"
|
||||
|
||||
default_output_file: "{sprint_artifacts}/tech-spec-epic-{{epic_id}}.md"
|
||||
standalone: true
|
||||
|
||||
web_bundle: false
|
||||
|
||||
@@ -382,7 +382,7 @@ Alice (Product Owner): "Good thinking - helps us connect what we learned to what
|
||||
<action>Attempt to load next epic using selective loading strategy:</action>
|
||||
|
||||
**Try sharded first (more specific):**
|
||||
<action>Check if file exists: {output*folder}/\_epic*/epic-{{next_epic_num}}.md</action>
|
||||
<action>Check if file exists: {output-folder}/\_epic\*/epic-{{next_epic_num}}.md</action>
|
||||
|
||||
<check if="sharded epic file found">
|
||||
<action>Load {output_folder}/*epic*/epic-{{next_epic_num}}.md</action>
|
||||
@@ -391,7 +391,7 @@ Alice (Product Owner): "Good thinking - helps us connect what we learned to what
|
||||
|
||||
**Fallback to whole document:**
|
||||
<check if="sharded epic not found">
|
||||
<action>Check if file exists: {output*folder}/\_epic*.md</action>
|
||||
<action>Check if file exists: {output-folder}/\_epic\*.md</action>
|
||||
|
||||
<check if="whole epic file found">
|
||||
<action>Load entire epics document</action>
|
||||
|
||||
@@ -10,15 +10,12 @@ communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
date: system-generated
|
||||
ephemeral_files: "{config_source}:dev_ephemeral_location"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
|
||||
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/retrospective"
|
||||
template: false
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
|
||||
mode: interactive
|
||||
trigger: "Run AFTER completing an epic"
|
||||
|
||||
required_inputs:
|
||||
- agent_manifest: "{project-root}/{bmad_folder}/_cfg/agent-manifest.csv"
|
||||
|
||||
@@ -31,40 +28,20 @@ input_file_patterns:
|
||||
sharded_index: "{output_folder}/*epic*/index.md"
|
||||
sharded_single: "{output_folder}/*epic*/epic-{{epic_num}}.md"
|
||||
previous_retrospective:
|
||||
pattern: "{ephemeral_files}/retrospectives/epic-{{prev_epic_num}}-retro-*.md"
|
||||
pattern: "{sprint_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md"
|
||||
architecture:
|
||||
whole: "{output_folder}/*architecture*.md"
|
||||
sharded: "{output_folder}/*architecture*/index.md"
|
||||
sharded: "{output_folder}/*architecture*/*.md"
|
||||
prd:
|
||||
whole: "{output_folder}/*prd*.md"
|
||||
sharded: "{output_folder}/*prd*/index.md"
|
||||
sharded: "{output_folder}/*prd*/*.md"
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
sharded: "{output_folder}/*.md"
|
||||
|
||||
# Required files
|
||||
sprint_status_file: "{context_dir}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
story_directory: "{ephemeral_files}/stories"
|
||||
retrospectives_folder: "{ephemeral_files}/retrospectives"
|
||||
|
||||
output_artifacts:
|
||||
- retrospective_summary: "Comprehensive review of what went well and what could improve"
|
||||
- lessons_learned: "Key insights for future epics"
|
||||
- action_items: "Specific improvements with ownership"
|
||||
- next_epic_preparation: "Dependencies, gaps, and preparation tasks for next epic"
|
||||
- critical_path: "Blockers or prerequisites that must be addressed"
|
||||
|
||||
facilitation:
|
||||
facilitator: "Bob (Scrum Master)"
|
||||
tone: "Psychological safety - no blame, focus on systems and processes"
|
||||
format: "Two-part: (1) Review completed epic + (2) Preview next epic preparation"
|
||||
|
||||
validation_required:
|
||||
- testing_complete: "Has full regression testing been completed?"
|
||||
- deployment_status: "Has epic been deployed to production?"
|
||||
- business_validation: "Have stakeholders reviewed and accepted deliverables?"
|
||||
- technical_health: "Is codebase in stable, maintainable state?"
|
||||
- blocker_resolution: "Any unresolved blockers that will impact next epic?"
|
||||
sprint_status_file: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
story_directory: "{sprint_artifacts}"
|
||||
retrospectives_folder: "{sprint_artifacts}"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle: false
|
||||
|
||||
@@ -8,7 +8,7 @@ output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
ephemeral_files: "{config_source}:dev_ephemeral_location"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/sprint-planning"
|
||||
@@ -20,19 +20,18 @@ validation: "{installed_path}/checklist.md"
|
||||
variables:
|
||||
# Project identification
|
||||
project_name: "{config_source}:project_name"
|
||||
project_key: "{config_source}:project_name" # Future: Jira project key, Linear workspace ID, etc.
|
||||
|
||||
# Tracking system configuration
|
||||
tracking_system: "file-system" # Options: file-system, Future will support other options from config of mcp such as jira, linear, trello
|
||||
story_location: "{project-root}/docs/stories" # Relative path for file-system, Future will support URL for Jira/Linear/Trello
|
||||
story_location_absolute: "{config_source}:dev_ephemeral_location" # Absolute path for file operations
|
||||
story_location_absolute: "{config_source}:sprint_artifacts" # Absolute path for file operations
|
||||
|
||||
# Source files (file-system only)
|
||||
epics_location: "{output_folder}" # Directory containing epic*.md files
|
||||
epics_pattern: "epic*.md" # Pattern to find epic files
|
||||
|
||||
# Output configuration
|
||||
status_file: "{ephemeral_files}/sprint-status.yaml"
|
||||
status_file: "{sprint_artifacts}/sprint-status.yaml"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
|
||||
@@ -11,35 +11,6 @@
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Technical context file (.context.xml). Concise, structured, project-relative paths only.</critical>
|
||||
|
||||
## 📚 Document Discovery - Selective Epic Loading
|
||||
|
||||
**Strategy**: This workflow needs only ONE specific epic and its stories, not all epics. This provides huge efficiency gains when epics are sharded.
|
||||
|
||||
**Epic Discovery Process (SELECTIVE OPTIMIZATION):**
|
||||
|
||||
1. **Determine which epic** you need (epic_num from story key - e.g., story "3-2-feature-name" needs Epic 3)
|
||||
2. **Check for sharded version**: Look for `epics/index.md`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand structure
|
||||
- **Load ONLY `epic-{epic_num}.md`** (e.g., `epics/epic-3.md` for Epic 3)
|
||||
- DO NOT load all epic files - only the one needed!
|
||||
- This is the key efficiency optimization for large multi-epic projects
|
||||
4. **If whole document found**: Load the complete `epics.md` file and extract the relevant epic
|
||||
|
||||
**Other Documents (prd, architecture, ux-design) - Full Load:**
|
||||
|
||||
1. **Search for whole document first** - Use fuzzy file matching
|
||||
2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand structure
|
||||
- Read ALL section files listed in the index
|
||||
- Treat combined content as single document
|
||||
4. **Brownfield projects**: The `document-project` workflow creates `{output_folder}/docs/index.md`
|
||||
|
||||
**Priority**: If both whole and sharded versions exist, use the whole document.
|
||||
|
||||
**UX-Heavy Projects**: Always check for ux-design documentation as it provides critical context for UI-focused stories.
|
||||
|
||||
<workflow>
|
||||
<step n="1" goal="Find drafted story and check for existing context" tag="sprint-status">
|
||||
<check if="{{story_path}} is provided">
|
||||
@@ -89,10 +60,10 @@
|
||||
<check if="context file already exists">
|
||||
<output>⚠️ Context file already exists: {default_output_file}
|
||||
|
||||
**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
|
||||
**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
|
||||
</output>
|
||||
<ask>Choose action (replace/verify/cancel):</ask>
|
||||
|
||||
|
||||
@@ -9,9 +9,9 @@ output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
story_path: "{config_source}:dev_ephemeral_location/stories"
|
||||
story_path: "{config_source}:sprint_artifacts/stories"
|
||||
date: system-generated
|
||||
ephemeral_files: "{config_source}:dev_ephemeral_location"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
sprint_status: "{context_dir}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
|
||||
# Workflow components
|
||||
|
||||
@@ -17,7 +17,7 @@ instructions: "{installed_path}/instructions.md"
|
||||
|
||||
# Variables and inputs
|
||||
variables:
|
||||
story_dir: "{config_source}:dev_ephemeral_location/stories" # Directory where stories are stored
|
||||
story_dir: "{config_source}:sprint_artifacts/stories" # Directory where stories are stored
|
||||
|
||||
# Output configuration - no output file, just status updates
|
||||
default_output_file: ""
|
||||
|
||||
@@ -14,12 +14,12 @@
|
||||
|
||||
<action>If {{story_path}} is provided → use it directly; extract story_key from filename or metadata; GOTO mark_ready</action>
|
||||
|
||||
<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>
|
||||
<critical>MUST read COMPLETE {sprint_status} file from start to end to preserve order</critical>
|
||||
<action>Load the FULL file: {sprint_status}</action>
|
||||
<action>Read ALL lines from beginning to end - do not skip any content</action>
|
||||
<action>Parse the development_status section completely</action>
|
||||
|
||||
<action>Find ALL stories (reading in order from top to bottom) where:
|
||||
<action>Find ALL stories (reading in order from start to end) where:
|
||||
|
||||
- Key matches pattern: number-number-name (e.g., "1-2-user-auth")
|
||||
- NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
|
||||
@@ -30,7 +30,7 @@
|
||||
<action>Count total drafted stories found</action>
|
||||
|
||||
<check if="no drafted stories found">
|
||||
<output>📋 No drafted stories found in sprint-status.yaml
|
||||
<output>📋 No drafted stories found in {sprint_status}
|
||||
|
||||
All stories are either still in backlog or already marked ready/in-progress/done.
|
||||
|
||||
@@ -67,7 +67,7 @@ All stories are either still in backlog or already marked ready/in-progress/done
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Update sprint status to ready-for-dev" tag="sprint-status">
|
||||
<action>Load the FULL file: {{output_folder}}/sprint-status.yaml</action>
|
||||
<action>Load the FULL file: {sprint_status}</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>
|
||||
|
||||
@@ -9,7 +9,7 @@ output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
sprint_status: "{context_dir}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
sprint_status: "{output_folder}/sprint-status.yaml || {sprint_artifacts}/sprint-status.yaml"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/story-ready"
|
||||
@@ -17,10 +17,7 @@ instructions: "{installed_path}/instructions.md"
|
||||
|
||||
# Variables and inputs
|
||||
variables:
|
||||
story_dir: "{config_source}:dev_ephemeral_location/stories" # Directory where stories are stored
|
||||
|
||||
# Output configuration - no output file, just status updates
|
||||
default_output_file: ""
|
||||
story_dir: "{config_source}:sprint_artifacts"
|
||||
|
||||
standalone: true
|
||||
|
||||
|
||||
@@ -325,11 +325,11 @@ findings.batches_completed: [
|
||||
</check>
|
||||
|
||||
<action>Build API contracts catalog</action>
|
||||
<action>IMMEDIATELY write to: {output*folder}/api-contracts-{part_id}.md</action>
|
||||
<action>IMMEDIATELY write to: {output-folder}/api-contracts-{part_id}.md</action>
|
||||
<action>Validate document has all required sections</action>
|
||||
<action>Update state file with output generated</action>
|
||||
<action>PURGE detailed API data, keep only: "{{api_count}} endpoints documented"</action>
|
||||
<template-output>api_contracts*{part_id}</template-output>
|
||||
<template-output>api_contracts\*{part_id}</template-output>
|
||||
</check>
|
||||
|
||||
<check if="requires_data_models == true">
|
||||
@@ -346,11 +346,11 @@ findings.batches_completed: [
|
||||
</check>
|
||||
|
||||
<action>Build database schema documentation</action>
|
||||
<action>IMMEDIATELY write to: {output*folder}/data-models-{part_id}.md</action>
|
||||
<action>IMMEDIATELY write to: {output-folder}/data-models-{part_id}.md</action>
|
||||
<action>Validate document completeness</action>
|
||||
<action>Update state file with output generated</action>
|
||||
<action>PURGE detailed schema data, keep only: "{{table_count}} tables documented"</action>
|
||||
<template-output>data_models*{part_id}</template-output>
|
||||
<template-output>data_models\*{part_id}</template-output>
|
||||
</check>
|
||||
|
||||
<check if="requires_state_management == true">
|
||||
|
||||
@@ -14,21 +14,21 @@
|
||||
|
||||
**Check for BMM planning artifacts:**
|
||||
|
||||
- PRD files: {output*folder}/\_prd*.md or {output*folder}/\_prd*/index.md
|
||||
- Tech-spec files: {output*folder}/\_tech-spec*.md or {output*folder}/\_spec*.md
|
||||
- Epic files: {output*folder}/\_epic*.md or {output*folder}/\_epic*/index.md
|
||||
- Architecture: {output*folder}/\_architecture*.md or {output*folder}/\_arch*.md
|
||||
- UX Design: {output*folder}/\_ux*.md or {output*folder}/\_design*.md
|
||||
- Product Brief: {output*folder}/\_brief*.md
|
||||
- Research docs: {output*folder}/\_research*.md
|
||||
- Brainstorm docs: {output*folder}/\_brainstorm*.md
|
||||
- PRD files: {output-folder}/\_prd*.md or {output-folder}/\_prd*/index.md
|
||||
- Tech-spec files: {output-folder}/\_tech-spec*.md or {output-folder}/\_spec*.md
|
||||
- Epic files: {output-folder}/\_epic*.md or {output-folder}/\_epic*/index.md
|
||||
- Architecture: {output-folder}/\_architecture*.md or {output-folder}/\_arch*.md
|
||||
- UX Design: {output-folder}/\_ux*.md or {output-folder}/\_design*.md
|
||||
- Product Brief: {output-folder}/\_brief\*.md
|
||||
- Research docs: {output-folder}/\_research\*.md
|
||||
- Brainstorm docs: {output-folder}/\_brainstorm\*.md
|
||||
|
||||
**Check for implementation artifacts:**
|
||||
|
||||
- The following could be in or nested under {output_folder} OR {ephemeral_location} - CHECK BOTH LOCATIONS
|
||||
- Story files: {output*folder}/stories/*.md or {ephemeral*location}/stories/*.md
|
||||
- Sprint status: {output_folder}/sprint-status.yaml or {ephemeral_location}/sprint-status.yaml
|
||||
- Existing workflow status: {output_folder}/bmm-workflow-status.yaml or {ephemeral_location}/bmm-workflow-status.yaml
|
||||
- The following could be in or nested under {output_folder} OR {sprint_artifacts} - CHECK BOTH LOCATIONS
|
||||
- Story files: {output-folder}/stories/*.md or {ephemeral*location}/stories/\*.md
|
||||
- Sprint status: {output_folder}/sprint-status.yaml or {sprint_artifacts}/sprint-status.yaml
|
||||
- Existing workflow status: {output_folder}/bmm-workflow-status.yaml or {sprint_artifacts}/bmm-workflow-status.yaml
|
||||
|
||||
**Check for codebase:**
|
||||
|
||||
@@ -660,13 +660,13 @@ For each phase in path file:
|
||||
|
||||
- Brainstorm: {output_folder}/brainstorm\*.md
|
||||
- Research: {output_folder}/research\*.md
|
||||
- Product Brief: {output*folder}/\_brief*.md
|
||||
- PRD: {output*folder}/\_prd*.md or {output*folder}/\_prd*/index.md
|
||||
- Tech-spec: {output*folder}/\_tech-spec*.md or {output*folder}/\_spec*.md
|
||||
- Epics: {output*folder}/\_epic*.md or {output*folder}/\_epic*/index.md
|
||||
- UX Design: {output*folder}/\_ux*.md or {output*folder}/\_design*.md
|
||||
- Architecture: {output*folder}/\_architecture*.md or {output*folder}/\_arch*.md
|
||||
- Sprint Planning: {output*folder}/\_sprint*.yaml
|
||||
- Product Brief: {output-folder}/\_brief\*.md
|
||||
- PRD: {output-folder}/\_prd*.md or {output-folder}/\_prd*/index.md
|
||||
- Tech-spec: {output-folder}/\_tech-spec*.md or {output-folder}/\_spec*.md
|
||||
- Epics: {output-folder}/\_epic*.md or {output-folder}/\_epic*/index.md
|
||||
- UX Design: {output-folder}/\_ux*.md or {output-folder}/\_design*.md
|
||||
- Architecture: {output-folder}/\_architecture*.md or {output-folder}/\_arch*.md
|
||||
- Sprint Planning: {output-folder}/\_sprint\*.yaml
|
||||
|
||||
**CRITICAL:** If file exists, replace workflow status with ONLY the file path, preserving agent comment.
|
||||
Example: `prd: docs/prd.md # agent: pm` (NOT "completed - docs/prd.md")
|
||||
|
||||
@@ -6,7 +6,7 @@ author: "BMad"
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/{bmad_folder}/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
ephemeral_location: "{config_source}:dev_ephemeral_location"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
user_name: "{config_source}:user_name"
|
||||
project_name: "{config_source}:project_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
# Extended enterprise planning for complex brownfield with security/devops/test (30+ stories typically)
|
||||
|
||||
method_name: "BMad Enterprise Method"
|
||||
track: "enterprise"
|
||||
track: "enterprise-bmad-method"
|
||||
field_type: "brownfield"
|
||||
description: "Enterprise-grade planning for complex brownfield additions with extended requirements"
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# BMad Enterprise Method - Greenfield
|
||||
# Extended enterprise planning with security/devops/test for greenfield (30+ stories typically)
|
||||
|
||||
method_name: "BMad Enterprise Method"
|
||||
track: "enterprise"
|
||||
method_name: "Enterprise BMad Method"
|
||||
track: "enterprise-bmad-method"
|
||||
field_type: "greenfield"
|
||||
description: "Complete enterprise-grade planning with security, devops, and test strategy"
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
# Full product + architecture planning for complex brownfield additions (10-50+ stories typically)
|
||||
|
||||
method_name: "BMad Method"
|
||||
track: "method"
|
||||
track: "bmad-method"
|
||||
field_type: "brownfield"
|
||||
description: "Complete product and system design for complex brownfield work"
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
# Full product + architecture planning for greenfield projects (10-50+ stories typically)
|
||||
|
||||
method_name: "BMad Method"
|
||||
track: "method"
|
||||
track: "bmad-method"
|
||||
field_type: "greenfield"
|
||||
description: "Complete product and system design methodology for greenfield projects"
|
||||
|
||||
|
||||
@@ -1,49 +0,0 @@
|
||||
# Workflow Status Template
|
||||
# This tracks progress through phases 1-3 of the BMM methodology
|
||||
# Phase 4 (Implementation) is tracked separately in sprint-status.yaml
|
||||
|
||||
# generated: 2025-10-29
|
||||
# project: Enterprise Customer Portal
|
||||
# project_type: software
|
||||
# project_level: 3
|
||||
# field_type: greenfield
|
||||
# workflow_path: greenfield-level-3.yaml
|
||||
|
||||
# STATUS DEFINITIONS:
|
||||
# ==================
|
||||
# Initial Status (before completion):
|
||||
# - required: Must be completed to progress
|
||||
# - optional: Can be completed but not required
|
||||
# - recommended: Strongly suggested but not required
|
||||
# - conditional: Required only if certain conditions met (e.g., if_has_ui)
|
||||
#
|
||||
# Completion Status:
|
||||
# - {file-path}: File created/found (e.g., "docs/product-brief.md")
|
||||
# - skipped: Optional/conditional workflow that was skipped
|
||||
|
||||
generated: 2025-10-29
|
||||
project: Enterprise Customer Portal
|
||||
project_type: software
|
||||
project_level: 3
|
||||
field_type: greenfield
|
||||
workflow_path: greenfield-level-3.yaml
|
||||
|
||||
workflow_status:
|
||||
# Phase 1: Analysis
|
||||
brainstorm-project: docs/brainstorm-session-2025-10-15.md
|
||||
research: docs/research-api-patterns.md
|
||||
product-brief: docs/product-brief.md
|
||||
|
||||
# Phase 2: Planning
|
||||
prd: docs/prd.md
|
||||
validate-prd: skipped
|
||||
create-design: docs/ux-design.md
|
||||
|
||||
# Phase 3: Solutioning
|
||||
create-architecture: required
|
||||
validate-architecture: optional
|
||||
solutioning-gate-check: recommended
|
||||
|
||||
# Phase 4: Implementation
|
||||
sprint-planning: required
|
||||
# Note: Subsequent implementation workflows tracked in sprint-status.yaml
|
||||
Reference in New Issue
Block a user