ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity

Merge branch 'main' into feature/install-module-cli

This commit is contained in:
Alex Suprun 2026-01-03 19:47:44 +02:00 committed by GitHub
parent e9cce0f848 35ae4fd024
commit 0412fdd5d6
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
326 changed files with 16262 additions and 12579 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/modules/bmgd-bmad-game-dev/index.md
View File

@ -161,7 +161,7 @@ BMGD Documentation
### Related Documentation
- **[BMM Documentation](../../bmm/docs/index.md)** - Core BMad Method documentation
- **[BMM Documentation](../bmm/index.md)** - Core BMad Method documentation
## Tips for Using This Documentation

4
docs/modules/bmgd-bmad-game-dev/workflows-guide.md
View File

@ -8,7 +8,7 @@ Complete reference for all BMGD workflows organized by development phase.
BMGD workflows are organized into four phases:
![BMGD Workflow Overview](../../../../docs/modules/bmgd-bmad-game-dev/workflow-overview.jpg)
![BMGD Workflow Overview](./workflow-overview.jpg)
---
@ -161,7 +161,7 @@ Production workflows inherit from BMM and add game-specific overrides.
**Command:** `sprint-planning`
**Agent:** Game Scrum Master
**Input:** GDD with epics
**Output:** `{output_folder}/sprint-status.yaml`
**Output:** `{implementation_artifacts}/sprint-status.yaml`
**Description:**
Generates or updates sprint tracking from epic files. Sets up the sprint backlog and tracking.

793
docs/modules/bmm-bmad-method/brownfield-guide.md
View File

@ -1,747 +1,78 @@
# BMad Method Brownfield Development Guide
**Complete guide for working with existing codebases**
## Working on Existing Projects
**Reading Time:** ~35 minutes
If you have completed your initial PRD on a new project and want to add new features, or if you have a legacy project you are maintaining, you will want to follow the brownfield process.
This document is intentionally brief, focusing only on what differs from the standard greenfield flow.
---
## Quick Navigation
## 1. Clean Up Completed Planning Artifacts
**Jump to:**
If you have completed all PRD epics and stories through the BMad process, clean up those files. Archive them, delete them, or rely on version history if needed. Do not keep these files in:
- `docs/`
- `_bmad-output/planning-artifacts/`
- `_bmad-output/implementation-artifacts/`
- [Quick Reference](#quick-reference) - Commands and files
- [Common Scenarios](#common-scenarios) - Real-world examples
- [Best Practices](#best-practices) - Success tips
## 2. Maintain Quality Project Documentation
Your `docs/` folder should contain succinct, well-organized documentation that accurately represents your project:
- Intent and business rationale
- Business rules
- Architecture
- Any other relevant project information
For complex projects, consider using the `document-project` workflow. It offers runtime variants that will scan your entire project and document its actual current state.
## 3. Initialize for Brownfield Work
Run `workflow-init`. It should recognize you are in an existing project. If not, explicitly clarify that this is brownfield development for a new feature.
### Choosing Your Approach
You have two primary options depending on the scope of changes:
| Scope | Recommended Approach |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| **Small updates or additions** | Use `quick-flow-solo-dev` to create a tech-spec and implement the change. The full four-phase BMad method is likely overkill. |
| **Major changes or additions** | Start with the BMad method, applying as much or as little rigor as needed. |
### During PRD Creation
When creating a brief or jumping directly into the PRD, ensure the agent:
- Finds and analyzes your existing project documentation
- Reads the proper context about your current system
You can guide the agent explicitly, but the goal is to ensure the new feature integrates well with your existing system.
### UX Considerations
UX work is optional. The decision depends not on whether your project has a UX, but on:
- Whether you will be working on UX changes
- Whether significant new UX designs or patterns are needed
If your changes amount to simple updates to existing screens you are happy with, a full UX process is unnecessary.
### Architecture Considerations
When doing architecture, ensure the architect:
- Uses the proper documented files
- Scans the existing codebase
Pay close attention here to prevent reinventing the wheel or making decisions that misalign with your existing architecture.
---
## What is Brownfield Development?
## 4. Ad-Hoc Changes
Brownfield projects involve working within existing codebases rather than starting fresh:
- **Bug fixes** - Single file changes
- **Small features** - Adding to existing modules
- **Feature sets** - Multiple related features
- **Major integrations** - Complex architectural additions
- **System expansions** - Enterprise-scale enhancements
**Key Difference from Greenfield:** You must understand and respect existing patterns, architecture, and constraints.
**Core Principle:** AI agents need comprehensive documentation to understand existing code before they can effectively plan or implement changes.
Not everything requires the full BMad method or even quick-flow. For bug fixes, refactorings, or small targeted changes, simply talk to the agent and have it make the changes directly. This is also a good way to learn about your codebase and understand the modifications being made.
---
## Getting Started
## 5. Learn and Explore
### Understanding Planning Tracks
For complete track details, see [Scale Adaptive System](./scale-adaptive-system.md).
**Brownfield tracks at a glance:**
| Track | Scope | Typical Stories | Key Difference |
| --------------------- | -------------------------- | --------------- | ----------------------------------------------- |
| **Quick Flow** | Bug fixes, small features | 1-15 | Must understand affected code and patterns |
| **BMad Method** | Feature sets, integrations | 10-50+ | Integrate with existing architecture |
| **Enterprise Method** | Enterprise expansions | 30+ | Full system documentation + compliance required |
**Note:** Story counts are guidance, not definitions. Tracks are chosen based on planning needs.
### Track Selection for Brownfield
When you run `workflow-init`, it handles brownfield intelligently:
**Step 1: Shows what it found**
- Old planning docs (PRD, epics, stories)
- Existing codebase
**Step 2: Asks about YOUR work**
> "Are these works in progress, previous effort, or proposed work?"
- **(a) Works in progress** → Uses artifacts to determine level
- **(b) Previous effort** → Asks you to describe NEW work
- **(c) Proposed work** → Uses artifacts as guidance
- **(d) None of these** → You explain your work
**Step 3: Analyzes your description**
- Keywords: "fix", "bug" → Quick Flow, "dashboard", "platform" → BMad Method, "enterprise", "multi-tenant" → Enterprise Method
- Complexity assessment
- Confirms suggested track with you
**Key Principle:** System asks about YOUR current work first, uses old artifacts as context only.
**Example: Old Complex PRD, New Simple Work**
```
System: "Found PRD.md (BMad Method track, 30 stories, 6 months old)"
System: "Is this work in progress or previous effort?"
You: "Previous effort - I'm just fixing a bug now"
System: "Tell me about your current work"
You: "Update payment method enums"
System: "Quick Flow track (tech-spec approach). Correct?"
You: "Yes"
✅ Creates Quick Flow workflow
```
---
## Documentation: Critical First Step
🚨 **For brownfield projects: Always ensure adequate AI-usable documentation before planning**
### Default Recommendation: Run document-project
**Best practice:** Run `document-project` workflow unless you have **confirmed, trusted, AI-optimized documentation**.
### Why Document-Project is Almost Always the Right Choice
Existing documentation often has quality issues that break AI workflows:
**Common Problems:**
- **Too Much Information (TMI):** Massive markdown files with 10s or 100s of level 2 sections
- **Out of Date:** Documentation hasn't been updated with recent code changes
- **Wrong Format:** Written for humans, not AI agents (lacks structure, index, clear patterns)
- **Incomplete Coverage:** Missing critical architecture, patterns, or setup info
- **Inconsistent Quality:** Some areas documented well, others not at all
**Impact on AI Agents:**
- AI agents hit token limits reading massive files
- Outdated docs cause hallucinations (agent thinks old patterns still apply)
- Missing structure means agents can't find relevant information
- Incomplete coverage leads to incorrect assumptions
### Documentation Decision Tree
**Step 1: Assess Existing Documentation Quality**
Ask yourself:
- ✅ Is it **current** (updated in last 30 days)?
- ✅ Is it **AI-optimized** (structured with index.md, clear sections, <500 lines per file)?
- ✅ Is it **comprehensive** (architecture, patterns, setup all documented)?
- ✅ Do you **trust** it completely for AI agent consumption?
**If ANY answer is NO → Run `document-project`**
**Step 2: Check for Massive Documents**
If you have documentation but files are huge (>500 lines, 10+ level 2 sections):
1. **First:** Run `shard-doc` tool to split large files:
```bash
# Load BMad Master or any agent
_bmad/core/tools/shard-doc.xml --input docs/massive-doc.md
```
- Splits on level 2 sections by default
- Creates organized, manageable files
- Preserves content integrity
2. **Then:** Run `index-docs` task to create navigation:
```bash
_bmad/core/tasks/index-docs.xml --directory ./docs
```
3. **Finally:** Validate quality - if sharded docs still seem incomplete/outdated → Run `document-project`
### Four Real-World Scenarios
| Scenario | You Have | Action | Why |
| -------- | ------------------------------------------ | -------------------------- | --------------------------------------- |
| **A** | No documentation | `document-project` | Only option - generate from scratch |
| **B** | Docs exist but massive/outdated/incomplete | `document-project` | Safer to regenerate than trust bad docs |
| **C** | Good docs but no structure | `shard-doc` → `index-docs` | Structure existing content for AI |
| **D** | Confirmed AI-optimized docs with index.md | Skip Documentation | Rare - only if you're 100% confident |
### Scenario A: No Documentation (Most Common)
**Action: Run document-project workflow**
1. Load Analyst or Technical Writer (Paige) agent
2. Run `*document-project`
3. Choose scan level:
- **Quick** (2-5min): Pattern analysis, no source reading
- **Deep** (10-30min): Reads critical paths - **Recommended**
- **Exhaustive** (30-120min): Reads all files
**Outputs:**
- `docs/index.md` - Master AI entry point
- `docs/project-overview.md` - Executive summary
- `docs/architecture.md` - Architecture analysis
- `docs/source-tree-analysis.md` - Directory structure
- Additional files based on project type (API, web app, etc.)
### Scenario B: Docs Exist But Quality Unknown/Poor (Very Common)
**Action: Run document-project workflow (regenerate)**
Even if `docs/` folder exists, if you're unsure about quality → **regenerate**.
**Why regenerate instead of index?**
- Outdated docs → AI makes wrong assumptions
- Incomplete docs → AI invents missing information
- TMI docs → AI hits token limits, misses key info
- Human-focused docs → Missing AI-critical structure
**document-project** will:
- Scan actual codebase (source of truth)
- Generate fresh, accurate documentation
- Structure properly for AI consumption
- Include only relevant, current information
### Scenario C: Good Docs But Needs Structure
**Action: Shard massive files, then index**
If you have **good, current documentation** but it's in massive files:
**Step 1: Shard large documents**
```bash
# For each massive doc (>500 lines or 10+ level 2 sections)
_bmad/core/tools/shard-doc.xml \
--input docs/api-documentation.md \
--output docs/api/ \
--level 2 # Split on ## headers (default)
```
**Step 2: Generate index**
```bash
_bmad/core/tasks/index-docs.xml --directory ./docs
```
**Step 3: Validate**
- Review generated `docs/index.md`
- Check that sharded files are <500 lines each
- Verify content is current and accurate
- **If anything seems off → Run document-project instead**
### Scenario D: Confirmed AI-Optimized Documentation (Rare)
**Action: Skip Documentation**
Only skip if ALL conditions met:
- ✅ `docs/index.md` exists and is comprehensive
- ✅ Documentation updated within last 30 days
- ✅ All doc files <500 lines with clear structure
- ✅ Covers architecture, patterns, setup, API surface
- ✅ You personally verified quality for AI consumption
- ✅ Previous AI agents used it successfully
**If unsure → Run document-project** (costs 10-30 minutes, saves hours of confusion)
### Why document-project is Critical
Without AI-optimized documentation, workflows fail:
- **tech-spec** (Quick Flow) can't auto-detect stack/patterns → Makes wrong assumptions
- **PRD** (BMad Method) can't reference existing code → Designs incompatible features
- **create-architecture** can't build on existing structure → Suggests conflicting patterns
- **create-story** can't provide existing pattern context → Stories lack integration guidance
- **dev-story** invents implementations → Breaks existing integrations
### Key Principle
**When in doubt, run document-project.**
It's better to spend 10-30 minutes generating fresh, accurate docs than to waste hours debugging AI agents working from bad documentation.
---
## Workflow Phases by Track
### Phase 1: Analysis (Optional)
**Workflows:**
- `brainstorm-project` - Solution exploration
- `research` - Technical/market research
- `product-brief` - Strategic planning (BMad Method/Enterprise tracks only)
**When to use:** Complex features, technical decisions, strategic additions
**When to skip:** Bug fixes, well-understood features, time-sensitive changes
See the [Workflows section in BMM README](../README.md) for details.
### Phase 2: Planning (Required)
**Planning approach adapts by track:**
**Quick Flow:** Use `tech-spec` workflow
- Creates tech-spec.md
- Auto-detects existing stack (brownfield)
- Confirms conventions with you
- Generates implementation-ready stories
**BMad Method/Enterprise:** Use `prd` workflow
- Creates PRD.md with FRs/NFRs only
- References existing architecture
- Plans integration points
- Epics+Stories created AFTER architecture phase
**Brownfield-specific:** See [Scale Adaptive System](./scale-adaptive-system.md) for complete workflow paths by track.
### Phase 3: Solutioning (BMad Method/Enterprise Only)
**Critical for brownfield:**
- Review existing architecture FIRST
- Document integration points explicitly
- Plan backward compatibility
- Consider migration strategy
**Workflows:**
- `create-architecture` - Extend architecture docs (BMad Method/Enterprise)
- `create-epics-and-stories` - Create epics and stories AFTER architecture
- `implementation-readiness` - Validate before implementation (BMad Method/Enterprise)
### Phase 4: Implementation (All Tracks)
**Sprint-based development through story iteration:**
```mermaid
flowchart TD
SPRINT[sprint-planning<br/>Initialize tracking]
CREATE[create-story]
DEV[dev-story]
REVIEW[code-review]
CHECK{More stories?}
RETRO[retrospective<br/>Per epic]
SPRINT --> CREATE
CREATE --> DEV
DEV --> REVIEW
REVIEW --> CHECK
CHECK -->|Yes| CREATE
CHECK -->|No| RETRO
style SPRINT fill:#bfb,stroke:#333,stroke-width:2px,color:#000
style RETRO fill:#fbf,stroke:#333,stroke-width:2px,color:#000
```
**Status Progression:**
- Epic: `backlog → in-progress → done`
- Story: `backlog → ready-for-dev → in-progress → review → done`
**Brownfield-Specific Implementation Tips:**
1. **Respect existing patterns** - Follow established conventions
2. **Test integration thoroughly** - Validate interactions with existing code
3. **Use feature flags** - Enable gradual rollout
---
## Best Practices
### 1. Always Document First
Even if you know the code, AI agents need `document-project` output for context. Run it before planning.
### 2. Be Specific About Current Work
When workflow-init asks about your work:
- ✅ "Update payment method enums to include Apple Pay"
- ❌ "Fix stuff"
### 3. Choose Right Documentation Approach
- **Has good docs, no index?** → Run `index-docs` task (fast)
- **No docs or need codebase analysis?** → Run `document-project` (Deep scan)
### 4. Respect Existing Patterns
Tech-spec and create-story workflows will detect conventions from existing documentation. Follow them unless explicitly modernizing.
### 5. Plan Integration Points Explicitly
Document in tech-spec/architecture:
- Which existing modules you'll modify
- What APIs/services you'll integrate with
- How data flows between new and existing code
### 6. Design for Gradual Rollout
- Use feature flags for new functionality
- Plan rollback strategies
- Maintain backward compatibility
- Create migration scripts if needed
### 7. Test Integration Thoroughly
- Regression testing of existing features
- Integration point validation
- Performance impact assessment
- API contract verification
### 8. Use Sprint Planning Effectively
- Run `sprint-planning` at Phase 4 start
- Context epics before creating stories
- Update `sprint-status.yaml` as work progresses
### 9. Learn Continuously
- Run `retrospective` after each epic
- Incorporate learnings into next stories
- Update discovered patterns
- Share insights across team
---
## Common Scenarios
### Scenario 1: Bug Fix (Quick Flow)
**Situation:** Authentication token expiration causing logout issues
**Track:** Quick Flow
**Workflow:**
1. **Document:** Skip if auth system documented, else run `document-project` (Quick scan)
2. **Plan:** Load PM → run `tech-spec`
- Analyzes bug
- Detects stack (Express, Jest)
- Confirms conventions
- Creates tech-spec.md + story
3. **Implement:** Load DEV → run `dev-story`
4. **Review:** Load DEV → run `code-review`
**Time:** 2-4 hours
---
### Scenario 2: Small Feature (Quick Flow)
**Situation:** Add "forgot password" to existing auth system
**Track:** Quick Flow
**Workflow:**
1. **Document:** Run `document-project` (Deep scan of auth module if not documented)
2. **Plan:** Load PM → run `tech-spec`
- Detects Next.js 13.4, NextAuth.js
- Analyzes existing auth patterns
- Confirms conventions
- Creates tech-spec.md + epic + 3-5 stories
3. **Implement:** Load SM → `sprint-planning` → `create-story`
Load DEV → `dev-story` for each story
4. **Review:** Load DEV → `code-review`
**Time:** 1-3 days
---
### Scenario 3: Feature Set (BMad Method)
**Situation:** Add user dashboard with analytics, preferences, activity
**Track:** BMad Method
**Workflow:**
1. **Document:** Run `document-project` (Deep scan) - Critical for understanding existing UI patterns
2. **Analyze:** Load Analyst → `research` (if evaluating analytics libraries)
3. **Plan:** Load PM → `prd` (creates FRs/NFRs)
4. **Solution:** Load Architect → `create-architecture` → `create-epics-and-stories` → `implementation-readiness`
5. **Implement:** Sprint-based (10-15 stories)
- Load SM → `sprint-planning`
- Load SM → `create-story` per story
- Load DEV → `dev-story` per story
6. **Review:** Per story completion
**Time:** 1-2 weeks
---
### Scenario 4: Complex Integration (BMad Method)
**Situation:** Add real-time collaboration to document editor
**Track:** BMad Method
**Workflow:**
1. **Document:** Run `document-project` (Exhaustive if not documented) - **Mandatory**
2. **Analyze:** Load Analyst → `research` (WebSocket vs WebRTC vs CRDT)
3. **Plan:** Load PM → `prd` (creates FRs/NFRs)
4. **Solution:**
- Load Architect → `create-architecture` (extend for real-time layer)
- Load Architect → `create-epics-and-stories`
- Load Architect → `implementation-readiness`
5. **Implement:** Sprint-based (20-30 stories)
**Time:** 3-6 weeks
---
### Scenario 5: Enterprise Expansion (Enterprise Method)
**Situation:** Add multi-tenancy to single-tenant SaaS platform
**Track:** Enterprise Method
**Workflow:**
1. **Document:** Run `document-project` (Exhaustive) - **Mandatory**
2. **Analyze:** **Required**
- `brainstorm-project` - Explore multi-tenancy approaches
- `research` - Database sharding, tenant isolation, pricing
- `product-brief` - Strategic document
3. **Plan:** Load PM → `prd` (comprehensive FRs/NFRs)
4. **Solution:**
- `create-architecture` - Full system architecture including multi-tenancy design
- `create-epics-and-stories` - Create epics and stories
- `implementation-readiness` - Final validation before implementation
5. **Implement:** Phased sprint-based (50+ stories)
**Time:** 3-6 months
---
## Troubleshooting
### AI Agents Lack Codebase Understanding
**Symptoms:**
- Suggestions don't align with existing patterns
- Ignores available components
- Doesn't reference existing code
**Solution:**
1. Run `document-project` with Deep scan
2. Verify `docs/index.md` exists
3. Check documentation completeness
4. Run deep-dive on specific areas if needed
### Have Documentation But Agents Can't Find It
**Symptoms:**
- README.md, ARCHITECTURE.md exist
- AI agents ask questions already answered
- No `docs/index.md` file
**Solution:**
- **Quick fix:** Run `index-docs` task (2-5min)
- **Comprehensive:** Run `document-project` workflow (10-30min)
### Integration Points Unclear
**Symptoms:**
- Not sure how to connect new code to existing
- Unsure which files to modify
**Solution:**
1. Ensure `document-project` captured existing architecture
2. Check story files created by `create-story` - should include integration context
3. In tech-spec/architecture - explicitly document:
- Which existing modules to modify
- What APIs/services to integrate with
- Data flow between new and existing code
4. Review architecture document for integration guidance
### Existing Tests Breaking
**Symptoms:**
- Regression test failures
- Previously working functionality broken
**Solution:**
1. Review changes against existing patterns
2. Verify API contracts unchanged (unless intentionally versioned)
3. Run `test-review` workflow (TEA agent)
4. Add regression testing to DoD
5. Consider feature flags for gradual rollout
### Inconsistent Patterns Being Introduced
**Symptoms:**
- New code style doesn't match existing
- Different architectural approach
**Solution:**
1. Check convention detection (Quick Spec Flow should detect patterns)
2. Review documentation - ensure `document-project` captured patterns
3. Use `create-story` workflow - it loads context from existing documentation
4. Add to code-review checklist: pattern adherence, convention consistency
5. Run retrospective to identify deviations early
---
## Quick Reference
### Commands by Phase
```bash
# Documentation (If Needed)
# Analyst agent:
document-project # Create comprehensive docs (10-30min)
# OR load index-docs task for existing docs (2-5min)
# Phase 1: Analysis (Optional)
# Analyst agent:
brainstorm-project # Explore solutions
research # Gather data
product-brief # Strategic planning (BMad Method/Enterprise only)
# Phase 2: Planning (Required)
# PM agent:
tech-spec # Quick Flow track
prd # BMad Method/Enterprise tracks
# Phase 3: Solutioning (BMad Method/Enterprise)
# Architect agent:
create-architecture # Create/extend architecture
create-epics-and-stories # Create epics and stories (after architecture)
implementation-readiness # Final validation
# Phase 4: Implementation (All Tracks)
# SM agent:
sprint-planning # Initialize tracking
create-story # Create story
# DEV agent:
dev-story # Implement
code-review # Review
# SM agent:
retrospective # After epic
correct-course # If issues
```
### Key Files
**Documentation Output:**
- `docs/index.md` - **Master AI entry point (REQUIRED)**
- `docs/project-overview.md`
- `docs/architecture.md`
- `docs/source-tree-analysis.md`
**Phase 1-4 Tracking:**
- `docs/bmm-workflow-status.yaml` - Progress tracker
**Phase 2 Planning:**
- `docs/tech-spec.md` (Quick Flow track)
- `docs/PRD.md` (BMad Method/Enterprise tracks - FRs/NFRs only)
**Phase 3 Solutioning:**
- Epic breakdown (created after architecture)
**Phase 3 Architecture:**
- `docs/architecture.md` (BMad Method/Enterprise tracks)
- `docs/epics.md` + epic folders (from create-epics-and-stories)
**Phase 4 Implementation:**
- `docs/sprint-status.yaml` - **Single source of truth**
- `docs/epic-{n}-context.md`
- `docs/stories/{epic}-{story}-{title}.md`
- `docs/stories/{epic}-{story}-{title}-context.md`
### Decision Flowchart
```mermaid
flowchart TD
START([Brownfield Project])
CHECK{Has docs/<br/>index.md?}
START --> CHECK
CHECK -->|No| DOC[document-project<br/>Deep scan]
CHECK -->|Yes| TRACK{What Track?}
DOC --> TRACK
TRACK -->|Quick Flow| TS[tech-spec]
TRACK -->|BMad Method| PRD[prd → architecture]
TRACK -->|Enterprise| PRD2[prd → arch + security/devops]
TS --> IMPL[Phase 4<br/>Implementation]
PRD --> IMPL
PRD2 --> IMPL
style START fill:#f9f,stroke:#333,stroke-width:2px,color:#000
style DOC fill:#ffb,stroke:#333,stroke-width:2px,color:#000
style IMPL fill:#bfb,stroke:#333,stroke-width:2px,color:#000
```
---
## Prevention Tips
**Avoid issues before they happen:**
1. ✅ **Always run document-project for brownfield** - Saves context issues later
2. ✅ **Use fresh chats for complex workflows** - Prevents hallucinations
3. ✅ **Verify files exist before workflows** - Check PRD, epics, stories present
4. ✅ **Read agent menu first** - Confirm agent has the workflow
5. ✅ **Start with simpler track if unsure** - Easy to upgrade (Quick Flow → BMad Method)
6. ✅ **Keep status files updated** - Manual updates when needed
7. ✅ **Run retrospectives after epics** - Catch issues early
8. ✅ **Follow phase sequence** - Don't skip required phases
---
## Related Documentation
- **[Scale Adaptive System](./scale-adaptive-system.md)** - Understanding tracks and complexity
- **[Quick Spec Flow](./quick-spec-flow.md)** - Fast-track for Quick Flow
- **[Quick Start Guide](./quick-start.md)** - Getting started with BMM
- **[Glossary](./glossary.md)** - Key terminology
- **[FAQ](./faq.md)** - Common questions
- **[Workflow Documentation](./index.md#-workflow-guides)** - Complete workflow reference
---
## Support and Resources
**Community:**
- [Discord](https://discord.gg/gk8jAdXWmj) - #general-dev, #bugs-issues
- [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)
- [YouTube Channel](https://www.youtube.com/@BMadCode)
**Documentation:**
- **[Test Architect Guide](./test-architecture.md)** - Comprehensive testing strategy
- [BMM Module README](../README.md) - Complete module and workflow reference
---
_Brownfield development is about understanding and respecting what exists while thoughtfully extending it._
Remember, LLMs are excellent at interpreting and analyzing code—whether it was AI-generated or not. Use the agent to:
- Learn about your project
- Understand how things are built
- Explore unfamiliar parts of the codebase

2
docs/modules/bmm-bmad-method/faq.md
View File

@ -510,7 +510,7 @@ Trust your expertise - BMM supports your decisions.
**A:**
1. Search [Complete Documentation](./README.md) for related topics
1. Search [Complete Documentation](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/README.md) for related topics
2. Ask in [Discord Community](https://discord.gg/gk8jAdXWmj) (#general-dev)
3. Open a [GitHub Issue](https://github.com/bmad-code-org/BMAD-METHOD/issues)
4. Watch [YouTube Tutorials](https://www.youtube.com/@BMadCode)

2
docs/modules/bmm-bmad-method/index.md
View File

@ -40,6 +40,8 @@ First know there is the full BMad Method Process and then there is a Quick Flow
- Implementation in minutes, not days
- Has a specialized single agent that does all of this: **[Quick Flow Solo Dev Agent](./quick-flow-solo-dev.md)**
- **TEA engagement (optional)** - Choose TEA engagement: none, TEA-only (standalone), or integrated by track. See **[Test Architect Guide](./test-architecture.md)**.
## 🤖 Agents and Collaboration
Complete guide to BMM's AI agent team:

22
docs/modules/bmm-bmad-method/quick-start.md
View File

@ -179,6 +179,16 @@ Once epics and stories are created:
**Why run this?** It ensures all your planning assets align properly before you start building.
#### Optional: TEA Engagement
Testing is not mandated by BMad. Decide how you want to engage TEA:
- **No TEA** - Use your existing team testing approach
- **TEA-only (Standalone)** - Use TEA workflows with your own requirements and environment
- **TEA-integrated** - Use TEA as part of the BMad Method or Enterprise flow
See the [Test Architect Guide](./test-architecture.md) for the five TEA engagement models and recommended sequences.
#### Context Management Tips
- **Use 200k+ context models** for best results (Claude Sonnet 4.5, GPT-4, etc.)
@ -211,7 +221,14 @@ Once planning and architecture are complete, you'll move to Phase 4. **Important
3. Tell the agent: "Run dev-story"
4. The DEV agent will implement the story and update the sprint status
#### 3.4 Review the Code (Optional but Recommended)
#### 3.4 Generate Guardrail Tests (Optional)
1. **Start a new chat** with the **TEA agent**
2. Wait for the menu
3. Tell the agent: "Run automate"
4. The TEA agent generates or expands tests to act as guardrails
#### 3.5 Review the Code (Optional but Recommended)
1. **Start a new chat** with the **DEV agent**
2. Wait for the menu
@ -224,7 +241,8 @@ For each subsequent story, repeat the cycle using **fresh chats** for each workf
1. **New chat** → SM agent → "Run create-story"
2. **New chat** → DEV agent → "Run dev-story"
3. **New chat** → DEV agent → "Run code-review" (optional but recommended)
3. **New chat** → TEA agent → "Run automate" (optional)
4. **New chat** → DEV agent → "Run code-review" (optional but recommended)
After completing all stories in an epic:

43
docs/modules/bmm-bmad-method/test-architecture.md
View File

@ -6,6 +6,38 @@
- **Mission:** Deliver actionable quality strategies, automation coverage, and gate decisions that scale with project complexity and compliance demands.
- **Use When:** BMad Method or Enterprise track projects, integration risk is non-trivial, brownfield regression risk exists, or compliance/NFR evidence is required. (Quick Flow projects typically don't require TEA)
## Choose Your TEA Engagement Model
BMad does not mandate TEA. There are five valid ways to use it (or skip it). Pick one intentionally.
1. **No TEA**
- Skip all TEA workflows. Use your existing team testing approach.
2. **TEA-only (Standalone)**
- Use TEA on a non-BMad project. Bring your own requirements, acceptance criteria, and environments.
- Typical sequence: `*test-design` (system or epic) -> `*atdd` and/or `*automate` -> optional `*test-review` -> `*trace` for coverage and gate decisions.
- Run `*framework` or `*ci` only if you want TEA to scaffold the harness or pipeline.
3. **Integrated: Greenfield - BMad Method (Simple/Standard Work)**
- Phase 3: system-level `*test-design`, then `*framework` and `*ci`.
- Phase 4: per-epic `*test-design`, optional `*atdd`, then `*automate` and optional `*test-review`.
- Gate (Phase 2): `*trace`.
4. **Integrated: Brownfield - BMad Method or Enterprise (Simple or Complex)**
- Phase 2: baseline `*trace`.
- Phase 3: system-level `*test-design`, then `*framework` and `*ci`.
- Phase 4: per-epic `*test-design` focused on regression and integration risks.
- Gate (Phase 2): `*trace`; `*nfr-assess` (if not done earlier).
- For brownfield BMad Method, follow the same flow with `*nfr-assess` optional.
5. **Integrated: Greenfield - Enterprise Method (Enterprise/Compliance Work)**
- Phase 2: `*nfr-assess`.
- Phase 3: system-level `*test-design`, then `*framework` and `*ci`.
- Phase 4: per-epic `*test-design`, plus `*atdd`/`*automate`/`*test-review`.
- Gate (Phase 2): `*trace`; archive artifacts as needed.
If you are unsure, default to the integrated path for your track and adjust later.
## TEA Workflow Lifecycle
TEA integrates into the BMad development lifecycle during Solutioning (Phase 3) and Implementation (Phase 4):
@ -16,6 +48,9 @@ graph TB
subgraph Phase2["<b>Phase 2: PLANNING</b>"]
PM["<b>PM: *prd (creates PRD with FRs/NFRs)</b>"]
PlanNote["<b>Business requirements phase</b>"]
NFR2["<b>TEA: *nfr-assess (optional, enterprise)</b>"]
PM -.-> NFR2
NFR2 -.-> PlanNote
PM -.-> PlanNote
end
@ -23,8 +58,8 @@ graph TB
Architecture["<b>Architect: *architecture</b>"]
EpicsStories["<b>PM/Architect: *create-epics-and-stories</b>"]
TestDesignSys["<b>TEA: *test-design (system-level)</b>"]
Framework["<b>TEA: *framework</b>"]
CI["<b>TEA: *ci</b>"]
Framework["<b>TEA: *framework (optional if needed)</b>"]
CI["<b>TEA: *ci (optional if needed)</b>"]
GateCheck["<b>Architect: *implementation-readiness</b>"]
Architecture --> EpicsStories
Architecture --> TestDesignSys
@ -174,7 +209,7 @@ npm install -D @seontechnologies/playwright-utils
**Enable during BMAD installation** by answering "Yes" when prompted.
**Supported utilities (11 total):**
**Supported utilities (10 total):**
- api-request, network-recorder, auth-session, intercept-network-call, recurse
- log, file-utils, burn-in, network-error-monitor
@ -429,7 +464,7 @@ Provides fixture-based utilities that integrate into TEA's test generation and r
Benefit: Faster CI feedback, HTTP error detection
**Utilities available** (11 total): api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor, fixtures-composition
**Utilities available** (10 total): api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor, fixtures-composition
**Enable during BMAD installation** by answering "Yes" when prompted, or manually set `tea_use_playwright_utils: true` in `_bmad/bmm/config.yaml`.

5
docs/modules/bmm-bmad-method/workflows-implementation.md
View File

@ -98,8 +98,9 @@ Stories move through these states in the sprint status file:
1. SM runs `create-story`
2. DEV runs `dev-story`
3. DEV runs `code-review`
4. If code review fails: DEV fixes issues in `dev-story`, then re-runs `code-review`
3. (Optional) TEA runs `*automate` to generate or expand guardrail tests
4. DEV runs `code-review`
5. If code review fails: DEV fixes issues in `dev-story`, then re-runs `code-review`
**After Epic Complete:**

2
docs/modules/bmm-bmad-method/workflows-solutioning.md
View File

@ -434,7 +434,7 @@ Architecture documents are living. Update them as you learn during implementatio
**Key Difference:** Enterprise adds optional extended workflows AFTER architecture but BEFORE create-epics-and-stories. Everything else is identical to BMad Method.
**Note:** TEA (Test Architect) operates across all phases and validates architecture testability but is not a Phase 3-specific workflow. See [Test Architecture Guide](../../../../docs/modules/bmm-bmad-method/test-architecture.md) for TEA's full lifecycle integration.
**Note:** TEA (Test Architect) operates across all phases and validates architecture testability but is not a Phase 3-specific workflow. See [Test Architecture Guide](./test-architecture.md) for TEA's full lifecycle integration.
---

2
docs/modules/cis-creative-intelligence-suite/index.md
View File

@ -142,7 +142,7 @@ CIS workflows integrate with:
## Related Documentation
- **[BMM Documentation](../../bmm/docs/index.md)** - Core BMad Method documentation
- **[BMM Documentation](../bmm/index.md)** - Core BMad Method documentation
---

1
samples/sample-custom-modules/sample-unitary-module/agents/commit-poet/commit-poet.agent.yaml
View File

@ -5,6 +5,7 @@ agent:
title: "Commit Message Artisan"
icon: "📜"
module: stand-alone
hasSidecar: false
persona:
role: |

1
samples/sample-custom-modules/sample-wellness-module/agents/meditation-guide.agent.yaml
View File

@ -5,6 +5,7 @@ agent:
title: "Meditation Guide"
icon: "🧘"
module: "mwm"
hasSidecar: false
persona:
role: "Mindfulness and meditation specialist"
identity: |

1
src/core/agents/bmad-master.agent.yaml
View File

@ -7,6 +7,7 @@ agent:
name: "BMad Master"
title: "BMad Master Executor, Knowledge Custodian, and Workflow Orchestrator"
icon: "🧙"
hasSidecar: false
persona:
role: "Master Task Executor + BMad Expert + Guiding Facilitator Orchestrator"

5
src/modules/bmb/agents/agent-builder.agent.yaml
View File

@ -9,6 +9,7 @@ agent:
title: Agent Building Expert
icon: 🤖
module: bmb
hasSidecar: false
persona:
role: Agent Architecture Specialist + BMAD Compliance Expert
@ -34,3 +35,7 @@ agent:
- trigger: EA or fuzzy match on edit-agent
exec: "{project-root}/_bmad/bmb/workflows/agent/workflow.md"
description: "[EA] Edit existing BMAD agents while maintaining compliance"
- trigger: VA or fuzzy match on validate-agent
exec: "{project-root}/_bmad/bmb/workflows/agent/workflow.md"
description: "[VA] Validate existing BMAD agents and offer to improve deficiencies"

13
src/modules/bmb/agents/module-builder.agent.yaml
View File

@ -9,6 +9,7 @@ agent:
title: Module Creation Master
icon: 🏗️
module: bmb
hasSidecar: false
persona:
role: Module Architecture Specialist + Full-Stack Systems Designer
@ -27,22 +28,18 @@ agent:
- modules: "{project-root}/_bmad/bmb/docs/modules/kb.csv"
menu:
- trigger: BM or fuzzy match on brainstorm-module
exec: "{project-root}/_bmad/bmb/workflows/brainstorm-module/workflow.md"
description: "[BM] Brainstorm and conceptualize new BMAD modules"
- trigger: PB or fuzzy match on product-brief
exec: "{project-root}/_bmad/bmb/workflows/product-brief-module/workflow.md"
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
description: "[PB] Create product brief for BMAD module development"
- trigger: CM or fuzzy match on create-module
exec: "{project-root}/_bmad/bmb/workflows/create-module/workflow.md"
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
description: "[CM] Create a complete BMAD module with agents, workflows, and infrastructure"
- trigger: EM or fuzzy match on edit-module
exec: "{project-root}/_bmad/bmb/workflows/edit-module/workflow.md"
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
description: "[EM] Edit existing BMAD modules while maintaining coherence"
- trigger: VM or fuzzy match on validate-module
exec: "{project-root}/_bmad/bmb/workflows/module-compliance-check/workflow.md"
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
description: "[VM] Run compliance check on BMAD modules against best practices"

19
src/modules/bmb/agents/workflow-builder.agent.yaml
View File

@ -9,6 +9,7 @@ agent:
title: Workflow Building Master
icon: 🔄
module: bmb
hasSidecar: false
persona:
role: Workflow Architecture Specialist + Process Design Expert
@ -28,13 +29,17 @@ agent:
menu:
- trigger: CW or fuzzy match on create-workflow
exec: "{project-root}/_bmad/bmb/workflows/create-workflow/workflow.md"
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
description: "[CW] Create a new BMAD workflow with proper structure and best practices"
# - trigger: EW or fuzzy match on edit-workflow
# exec: "{project-root}/_bmad/bmb/workflows/edit-workflow/workflow.md"
# description: "[EW] Edit existing BMAD workflows while maintaining integrity"
- trigger: EW or fuzzy match on edit-workflow
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
description: "[EW] Edit existing BMAD workflows while maintaining integrity"
# - trigger: VW or fuzzy match on validate-workflow
# exec: "{project-root}/_bmad/bmb/workflows/workflow-compliance-check/workflow.md"
# description: "[VW] Run compliance check on BMAD workflows against best practices"
- trigger: VW or fuzzy match on validate-workflow
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
description: "[VW] Run validation check on BMAD workflows against best practices"
- trigger: RW or fuzzy match on convert-or-rework-workflow
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
description: "[RW] Rework a Workflow to a V6 Compliant Version"

220
src/modules/bmb/docs/workflows/architecture.md
View File

@ -1,220 +0,0 @@
# Standalone Workflow Builder Architecture
This document describes the architecture of the standalone workflow builder system - a pure markdown approach to creating structured workflows.
## Core Architecture Principles
### 1. Micro-File Design
Each workflow consists of multiple focused, self-contained files, driven from a workflow.md file that is initially loaded:
```
workflow-folder/
├── workflow.md # Main workflow configuration
├── steps/ # Step instruction files (focused, self-contained)
│ ├── step-01-init.md
│ ├── step-02-profile.md
│ └── step-N-[name].md
├── templates/ # Content templates
│ ├── profile-section.md
│ └── [other-sections].md
└── data/ # Optional data files
└── [data-files].csv/.json
```
### 2. Just-In-Time (JIT) Loading
- **Single File in Memory**: Only the current step file is loaded
- **No Future Peeking**: Step files must not reference future steps
- **Sequential Processing**: Steps execute in strict order
- **On-Demand Loading**: Templates load only when needed
### 3. State Management
- **Frontmatter Tracking**: Workflow state stored in output document frontmatter
- **Progress Array**: `stepsCompleted` tracks completed steps
- **Last Step Marker**: `lastStep` indicates where to resume
- **Append-Only Building**: Documents grow by appending content
### 4. Execution Model
```
1. Load workflow.md → Read configuration
2. Execute step-01-init.md → Initialize or detect continuation
3. For each step:
a. Load step file completely
b. Execute instructions sequentially
c. Wait for user input at menu points
d. Only proceed with 'C' (Continue)
e. Update document/frontmatter
f. Load next step
```
## Key Components
### Workflow File (workflow.md)
- **Purpose**: Entry point and configuration
- **Content**: Role definition, goal, architecture rules
- **Action**: Points to step-01-init.md
### Step Files (step-NN-[name].md)
- **Size**: Focused and concise (typically 5-10KB)
- **Structure**: Frontmatter + sequential instructions
- **Features**: Self-contained rules, menu handling, state updates
### Frontmatter Variables
Standard variables in step files:
```yaml
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/[workflow-name]'
thisStepFile: '{workflow_path}/steps/step-[N]-[name].md'
nextStepFile: '{workflow_path}/steps/step-[N+1]-[name].md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/[output-name]-{project_name}.md'
```
## Execution Flow
### Fresh Workflow
```
workflow.md
↓
step-01-init.md (creates document)
↓
step-02-[name].md
↓
step-03-[name].md
↓
...
↓
step-N-[final].md (completes workflow)
```
### Continuation Workflow
```
workflow.md
↓
step-01-init.md (detects existing document)
↓
step-01b-continue.md (analyzes state)
↓
step-[appropriate-next].md
```
## Menu System
### Standard Menu Pattern
```
Display: **Select an Option:** [A] [Action] [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}
- IF P: Execute {partyModeWorkflow}
- IF C: Save content, update frontmatter, load next step
```
### Menu Rules
- **Halt Required**: Always wait for user input
- **Continue Only**: Only proceed with 'C' selection
- **State Persistence**: Save before loading next step
- **Loop Back**: Return to menu after other actions
## Collaborative Dialogue Model
### Not Command-Response
- **Facilitator Role**: AI guides, user decides
- **Equal Partnership**: Both parties contribute
- **No Assumptions**: Don't assume user wants next step
- **Explicit Consent**: Always ask for input
### Example Pattern
```
AI: "Tell me about your dietary preferences."
User: [provides information]
AI: "Thank you. Now let's discuss your cooking habits."
[Continue conversation]
AI: **Menu Options**
```
## CSV Intelligence (Optional)
### Data-Driven Behavior
- Configuration in CSV files
- Dynamic menu options
- Variable substitution
- Conditional logic
### Example Structure
```csv
variable,type,value,description
cooking_frequency,choice,"daily|weekly|occasionally","How often user cooks"
meal_type,multi,"breakfast|lunch|dinner|snacks","Types of meals to plan"
```
## Best Practices
### File Size Limits
- **Step Files**: Keep focused and reasonably sized (5-10KB typical)
- **Templates**: Keep focused and reusable
- **Workflow File**: Keep lean, no implementation details
### Sequential Enforcement
- **Numbered Steps**: Use sequential numbering (1, 2, 3...)
- **No Skipping**: Each step must complete
- **State Updates**: Mark completion in frontmatter
### Error Prevention
- **Path Variables**: Use frontmatter variables, never hardcode
- **Complete Loading**: Always read entire file before execution
- **Menu Halts**: Never proceed without 'C' selection
## Migration from XML
### Advantages
- **No Dependencies**: Pure markdown, no XML parsing
- **Human Readable**: Files are self-documenting
- **Git Friendly**: Clean diffs and merges
- **Flexible**: Easier to modify and extend
### Key Differences
| XML Workflows | Standalone Workflows |
| ----------------- | ----------------------- |
| Single large file | Multiple micro-files |
| Complex structure | Simple sequential steps |
| Parser required | Any markdown viewer |
| Rigid format | Flexible organization |
## Implementation Notes
### Critical Rules
- **NEVER** load multiple step files
- **ALWAYS** read complete step file first
- **NEVER** skip steps or optimize
- **ALWAYS** update frontmatter of the output file when a step is complete
- **NEVER** proceed without user consent
### Success Metrics
- Documents created correctly
- All steps completed sequentially
- User satisfied with collaborative process
- Clean, maintainable file structure
This architecture ensures disciplined, predictable workflow execution while maintaining flexibility for different use cases.

206
src/modules/bmb/docs/workflows/csv-data-file-standards.md
View File

@ -1,206 +0,0 @@
# CSV Data File Standards for BMAD Workflows
## Purpose and Usage
CSV data files in BMAD workflows serve specific purposes for different workflow types:
**For Agents:** Provide structured data that agents need to reference but cannot realistically generate (such as specific configurations, domain-specific data, or structured knowledge bases).
**For Expert Agents:** Supply specialized knowledge bases, reference data, or persistent information that the expert agent needs to access consistently across sessions.
**For Workflows:** Include reference data, configuration parameters, or structured inputs that guide workflow execution and decision-making.
**Key Principle:** CSV files should contain data that is essential, structured, and not easily generated by LLMs during execution.
## Intent-Based Design Principle
**Core Philosophy:** The closer workflows stay to **intent** rather than **prescriptive** instructions, the more creative and adaptive the LLM experience becomes.
**CSV Enables Intent-Based Design:**
- **Instead of:** Hardcoded scripts with exact phrases LLM must say
- **CSV Provides:** Clear goals and patterns that LLM adapts creatively to context
- **Result:** Natural, contextual conversations rather than rigid scripts
**Example - Advanced Elicitation:**
- **Prescriptive Alternative:** 50 separate files with exact conversation scripts
- **Intent-Based Reality:** One CSV row with method goal + pattern → LLM adapts to user
- **Benefit:** Same method works differently for different users while maintaining essence
**Intent vs Prescriptive Spectrum:**
- **Highly Prescriptive:** "Say exactly: 'Based on my analysis, I recommend...'"
- **Balanced Intent:** "Help the user understand the implications using your professional judgment"
- **CSV Goal:** Provide just enough guidance to enable creative, context-aware execution
## Primary Use Cases
### 1. Knowledge Base Indexing (Document Lookup Optimization)
**Problem:** Large knowledge bases with hundreds of documents cause context blowup and missed details when LLMs try to process them all.
**CSV Solution:** Create a knowledge base index with:
- **Column 1:** Keywords and topics
- **Column 2:** Document file path/location
- **Column 3:** Section or line number where relevant content starts
- **Column 4:** Content type or summary (optional)
**Result:** Transform from context-blowing document loads to surgical precision lookups, creating agents with near-infinite knowledge bases while maintaining optimal context usage.
### 2. Workflow Sequence Optimization
**Problem:** Complex workflows (e.g., game development) with hundreds of potential steps for different scenarios become unwieldy and context-heavy.
**CSV Solution:** Create a workflow routing table:
- **Column 1:** Scenario type (e.g., "2D Platformer", "RPG", "Puzzle Game")
- **Column 2:** Required step sequence (e.g., "step-01,step-03,step-07,step-12")
- **Column 3:** Document sections to include
- **Column 4:** Specialized parameters or configurations
**Result:** Step 1 determines user needs, finds closest match in CSV, confirms with user, then follows optimized sequence - truly optimal for context usage.
### 3. Method Registry (Dynamic Technique Selection)
**Problem:** Tasks need to select optimal techniques from dozens of options based on context, without hardcoding selection logic.
**CSV Solution:** Create a method registry with:
- **Column 1:** Category (collaboration, advanced, technical, creative, etc.)
- **Column 2:** Method name and rich description
- **Column 3:** Execution pattern or flow guide (e.g., "analysis → insights → action")
- **Column 4:** Complexity level or use case indicators
**Example:** Advanced Elicitation task analyzes content context, selects 5 best-matched methods from 50 options, then executes dynamically using CSV descriptions.
**Result:** Smart, context-aware technique selection without hardcoded logic - infinitely extensible method libraries.
### 4. Configuration Management
**Problem:** Complex systems with many configuration options that vary by use case.
**CSV Solution:** Configuration lookup tables mapping scenarios to specific parameter sets.
## What NOT to Include in CSV Files
**Avoid Web-Searchable Data:** Do not include information that LLMs can readily access through web search or that exists in their training data, such as:
- Common programming syntax or standard library functions
- General knowledge about widely used technologies
- Historical facts or commonly available information
- Basic terminology or standard definitions
**Include Specialized Data:** Focus on data that is:
- Specific to your project or domain
- Not readily available through web search
- Essential for consistent workflow execution
- Too voluminous for LLM context windows
## CSV Data File Standards
### 1. Purpose Validation
- **Essential Data Only:** CSV must contain data that cannot be reasonably generated by LLMs
- **Domain Specific:** Data should be specific to the workflow's domain or purpose
- **Consistent Usage:** All columns and data must be referenced and used somewhere in the workflow
- **No Redundancy:** Avoid data that duplicates functionality already available to LLMs
### 2. Structural Standards
- **Valid CSV Format:** Proper comma-separated values with quoted fields where needed
- **Consistent Columns:** All rows must have the same number of columns
- **No Missing Data:** Empty values should be explicitly marked (e.g., "", "N/A", or NULL)
- **Header Row:** First row must contain clear, descriptive column headers
- **Proper Encoding:** UTF-8 encoding required for special characters
### 3. Content Standards
- **No LLM-Generated Content:** Avoid data that LLMs can easily generate (e.g., generic phrases, common knowledge)
- **Specific and Concrete:** Use specific values rather than vague descriptions
- **Verifiable Data:** Data should be factual and verifiable when possible
- **Consistent Formatting:** Date formats, numbers, and text should follow consistent patterns
### 4. Column Standards
- **Clear Headers:** Column names must be descriptive and self-explanatory
- **Consistent Data Types:** Each column should contain consistent data types
- **No Unused Columns:** Every column must be referenced and used in the workflow
- **Appropriate Width:** Columns should be reasonably narrow and focused
### 5. File Size Standards
- **Efficient Structure:** CSV files should be as small as possible while maintaining functionality
- **No Redundant Rows:** Avoid duplicate or nearly identical rows
- **Compressed Data:** Use efficient data representation (e.g., codes instead of full descriptions)
- **Maximum Size:** Individual CSV files should not exceed 1MB unless absolutely necessary
### 6. Documentation Standards
- **Documentation Required:** Each CSV file should have documentation explaining its purpose
- **Column Descriptions:** Each column must be documented with its usage and format
- **Data Sources:** Source of data should be documented when applicable
- **Update Procedures:** Process for updating CSV data should be documented
### 7. Integration Standards
- **File References:** CSV files must be properly referenced in workflow configuration
- **Access Patterns:** Workflow must clearly define how and when CSV data is accessed
- **Error Handling:** Workflow must handle cases where CSV files are missing or corrupted
- **Version Control:** CSV files should be versioned when changes occur
### 8. Quality Assurance
- **Data Validation:** CSV data should be validated for correctness and completeness
- **Format Consistency:** Consistent formatting across all rows and columns
- **No Ambiguity:** Data entries should be clear and unambiguous
- **Regular Review:** CSV content should be reviewed periodically for relevance
### 9. Security Considerations
- **No Sensitive Data:** Avoid including sensitive, personal, or confidential information
- **Data Sanitization:** CSV data should be sanitized for security issues
- **Access Control:** Access to CSV files should be controlled when necessary
- **Audit Trail:** Changes to CSV files should be logged when appropriate
### 10. Performance Standards
- **Fast Loading:** CSV files must load quickly within workflow execution
- **Memory Efficient:** Structure should minimize memory usage during processing
- **Optimized Queries:** If data lookup is needed, optimize for efficient access
- **Caching Strategy**: Consider whether data can be cached for performance
## Implementation Guidelines
When creating CSV data files for BMAD workflows:
1. **Start with Purpose:** Clearly define why CSV is needed instead of LLM generation
2. **Design Structure:** Plan columns and data types before creating the file
3. **Test Integration:** Ensure workflow properly accesses and uses CSV data
4. **Document Thoroughly:** Provide complete documentation for future maintenance
5. **Validate Quality:** Check data quality, format consistency, and integration
6. **Monitor Usage:** Track how CSV data is used and optimize as needed
## Common Anti-Patterns to Avoid
- **Generic Phrases:** CSV files containing common phrases or LLM-generated content
- **Redundant Data:** Duplicating information easily available to LLMs
- **Overly Complex:** Unnecessarily complex CSV structures when simple data suffices
- **Unused Columns:** Columns that are defined but never referenced in workflows
- **Poor Formatting:** Inconsistent data formats, missing values, or structural issues
- **No Documentation:** CSV files without clear purpose or usage documentation
## Validation Checklist
For each CSV file, verify:
- [ ] Purpose is essential and cannot be replaced by LLM generation
- [ ] All columns are used in the workflow
- [ ] Data is properly formatted and consistent
- [ ] File is efficiently sized and structured
- [ ] Documentation is complete and clear
- [ ] Integration with workflow is tested and working
- [ ] Security considerations are addressed
- [ ] Performance requirements are met

220
src/modules/bmb/docs/workflows/intent-vs-prescriptive-spectrum.md
View File

@ -1,220 +0,0 @@
# Intent vs Prescriptive Spectrum
## Core Philosophy
The **Intent vs Prescriptive Spectrum** is a fundamental design principle for BMAD workflows and agents. It determines how much creative freedom an LLM has versus how strictly it must follow predefined instructions.
**Key Principle:** The closer workflows stay to **intent**, the more creative and adaptive the LLM experience becomes. The closer they stay to **prescriptive**, the more consistent and controlled the output becomes.
## Understanding the Spectrum
### **Intent-Based Design** (Creative Freedom)
**Focus**: What goal should be achieved
**Approach**: Trust the LLM to determine the best method
**Result**: Creative, adaptive, context-aware interactions
**Best For**: Creative exploration, problem-solving, personalized experiences
### **Prescriptive Design** (Structured Control)
**Focus**: Exactly what to say and do
**Approach**: Detailed scripts and specific instructions
**Result**: Consistent, predictable, controlled outcomes
**Best For**: Compliance, safety-critical, standardized processes
## Spectrum Examples
### **Highly Intent-Based** (Creative End)
```markdown
**Example:** Story Exploration Workflow
**Instruction:** "Help the user explore their dream imagery to craft compelling narratives, use multiple turns of conversation to really push users to develop their ideas, giving them hints and ideas also to prime them effectively to bring out their creativity"
**LLM Freedom:** Adapts questions, explores tangents, follows creative inspiration
**Outcome:** Unique, personalized storytelling experiences
```
### **Balanced Middle** (Professional Services)
```markdown
**Example:** Business Strategy Workflow
**Instruction:** "Guide the user through SWOT analysis using your business expertise. when complete tell them 'here is your final report {report output}'
**LLM Freedom:** Professional judgment in analysis, structured but adaptive approach
**Outcome:** Professional, consistent yet tailored business insights
```
### **Highly Prescriptive** (Control End)
```markdown
**Example:** Medical Intake Form
**Instruction:** "Ask exactly: 'Do you currently experience any of the following symptoms: fever, cough, fatigue?' Wait for response, then ask exactly: 'When did these symptoms begin?'"
**LLM Freedom:** Minimal - must follow exact script for medical compliance
**Outcome:** Consistent, medically compliant patient data collection
```
## Spectrum Positioning Guide
### **Choose Intent-Based When:**
- ✅ Creative exploration and innovation are goals
- ✅ Personalization and adaptation to user context are important
- ✅ Human-like conversation and natural interaction are desired
- ✅ Problem-solving requires flexible thinking
- ✅ User experience and engagement are priorities
**Examples:**
- Creative brainstorming sessions
- Personal coaching or mentoring
- Exploratory research and discovery
- Artistic content creation
- Collaborative problem-solving
### **Choose Prescriptive When:**
- ✅ Compliance with regulations or standards is required
- ✅ Safety or legal considerations are paramount
- ✅ Exact consistency across multiple sessions is essential
- ✅ Training new users on specific procedures
- ✅ Data collection must follow specific protocols
**Examples:**
- Medical intake and symptom assessment
- Legal compliance questionnaires
- Safety checklists and procedures
- Standardized testing protocols
- Regulatory data collection
### **Choose Balanced When:**
- ✅ Professional expertise is required but adaptation is beneficial
- ✅ Consistent quality with flexible application is needed
- ✅ Domain expertise should guide but not constrain interactions
- ✅ User trust and professional credibility are important
- ✅ Complex processes require both structure and judgment
**Examples:**
- Business consulting and advisory
- Technical support and troubleshooting
- Educational tutoring and instruction
- Financial planning and advice
- Project management facilitation
## Implementation Guidelines
### **For Workflow Designers:**
1. **Early Spectrum Decision**: Determine spectrum position during initial design
2. **User Education**: Explain spectrum choice and its implications to users
3. **Consistent Application**: Maintain chosen spectrum throughout workflow
4. **Context Awareness**: Adjust spectrum based on specific use case requirements
### **For Workflow Implementation:**
**Intent-Based Patterns:**
```markdown
- "Help the user understand..." (vs "Explain that...")
- "Guide the user through..." (vs "Follow these steps...")
- "Use your professional judgment to..." (vs "Apply this specific method...")
- "Adapt your approach based on..." (vs "Regardless of situation, always...")
```
**Prescriptive Patterns:**
```markdown
- "Say exactly: '...'" (vs "Communicate that...")
- "Follow this script precisely: ..." (vs "Cover these points...")
- "Do not deviate from: ..." (vs "Consider these options...")
- "Must ask in this order: ..." (vs "Ensure you cover...")
```
### **For Agents:**
**Intent-Based Agent Design:**
```yaml
persona:
communication_style: 'Adaptive professional who adjusts approach based on user context'
guiding_principles:
- 'Use creative problem-solving within professional boundaries'
- 'Personalize approach while maintaining expertise'
- 'Adapt conversation flow to user needs'
```
**Prescriptive Agent Design:**
```yaml
persona:
communication_style: 'Follows standardized protocols exactly'
governing_rules:
- 'Must use approved scripts without deviation'
- 'Follow sequence precisely as defined'
- 'No adaptation of prescribed procedures'
```
## Spectrum Calibration Questions
**Ask these during workflow design:**
1. **Consequence of Variation**: What happens if the LLM says something different?
2. **User Expectation**: Does the user expect consistency or creativity?
3. **Risk Level**: What are the risks of creative deviation vs. rigid adherence?
4. **Expertise Required**: Is domain expertise application more important than consistency?
5. **Regulatory Requirements**: Are there external compliance requirements?
## Best Practices
### **DO:**
- ✅ Make conscious spectrum decisions during design
- ✅ Explain spectrum choices to users
- ✅ Use intent-based design for creative and adaptive experiences
- ✅ Use prescriptive design for compliance and consistency requirements
- ✅ Consider balanced approaches for professional services
- ✅ Document spectrum rationale for future reference
### **DON'T:**
- ❌ Mix spectrum approaches inconsistently within workflows
- ❌ Default to prescriptive when intent-based would be more effective
- ❌ Use creative freedom when compliance is required
- ❌ Forget to consider user expectations and experience
- ❌ Overlook risk assessment in spectrum selection
## Quality Assurance
**When validating workflows:**
- Check if spectrum position is intentional and consistent
- Verify prescriptive elements are necessary and justified
- Ensure intent-based elements have sufficient guidance
- Confirm spectrum alignment with user needs and expectations
- Validate that risks are appropriately managed
## Examples in Practice
### **Medical Intake (Highly Prescriptive):**
- **Why**: Patient safety, regulatory compliance, consistent data collection
- **Implementation**: Exact questions, specific order, no deviation permitted
- **Benefit**: Reliable, medically compliant patient information
### **Creative Writing Workshop (Highly Intent):**
- **Why**: Creative exploration, personalized inspiration, artistic expression
- **Implementation**: Goal guidance, creative freedom, adaptive prompts
- **Benefit**: Unique, personalized creative works
### **Business Strategy (Balanced):**
- **Why**: Professional expertise with adaptive application
- **Implementation**: Structured framework with professional judgment
- **Benefit**: Professional, consistent yet tailored business insights
## Conclusion
The Intent vs Prescriptive Spectrum is not about good vs. bad - it's about **appropriate design choices**. The best workflows make conscious decisions about where they fall on this spectrum based on their specific requirements, user needs, and risk considerations.
**Key Success Factor**: Choose your spectrum position intentionally, implement it consistently, and align it with your specific use case requirements.

469
src/modules/bmb/docs/workflows/step-file-rules.md
View File

@ -1,469 +0,0 @@
# BMAD Step File Guidelines
**Version:** 1.0
**Module:** bmb (BMAD Builder)
**Purpose:** Definitive guide for creating BMAD workflow step files
---
## Overview
BMAD workflow step files follow a strict structure to ensure consistency, progressive disclosure, and mode-aware routing. Every step file MUST adhere to these guidelines.
---
## File Size Optimization
**CRITICAL:** Keep step files **LT 200 lines** (250 lines absolute maximum).
If a step exceeds this limit:
- Consider splitting into multiple steps
- Extract content to `/data/` reference files
- Optimize verbose explanations
---
## Required Frontmatter Structure
CRITICAL: Frontmatter should only have items that are used in the step file!
```yaml
---
name: 'step-2-foo.md'
description: 'Brief description of what this step accomplishes'
# File References ## CRITICAL: Frontmatter references or variables should only have items that are used in the step file!
outputFile: {bmb_creations_output_folder}/output-file-name.md
nextStepFile: './step-3-bar.md'
# Task References (as needed)
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# ... other task-specific references
---
```
### Frontmatter Field Descriptions
| Field | Required | Description |
| --------------- | --------- | --------------------------------- |
| `name` | Yes | Step identifier (kebab-case) |
| `description` | Yes | One-line summary of step purpose |
| `outputFile` | Yes | Where results are documented |
| Task references | As needed | Paths to external workflows/tasks |
---
## Document Structure
### 1. Title
```markdown
# Step X: [Step Name]
```
### 2. STEP GOAL
```markdown
## STEP GOAL:
[Single sentence stating what this step accomplishes]
```
### 3. Role Reinforcement
```markdown
### Role Reinforcement:
- ✅ You are a [specific role] who [does what]
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring [your expertise], user brings [their expertise], together we [achieve goal]
- ✅ Maintain [tone/approach] throughout
```
### 4. Language Preference
```markdown
### Language Preference:
The user has chosen to communicate in the **{language}** language.
You MUST respond in **{language}** throughout this step.
```
**IMPORTANT:** Read `userPreferences.language` from tracking file (agentPlan, validationReport, etc.) and enforce it.
### 5. Step-Specific Rules
```markdown
### Step-Specific Rules:
- 🎯 Focus only on [specific scope]
- 🚫 FORBIDDEN to [prohibited action]
- 💬 Approach: [how to engage]
- 📋 Ensure [specific outcome]
```
### 6. EXECUTION PROTOCOLS
```markdown
## EXECUTION PROTOCOLS:
- [What to do - use verbs]
- [Another action]
- 🚫 FORBIDDEN to [prohibited action]
```
### 7. CONTEXT BOUNDARIES
```markdown
## CONTEXT BOUNDARIES:
- Available context: [what's available]
- Focus: [what to focus on]
- Limits: [boundaries]
- Dependencies: [what this step depends on]
```
### 8. Sequence of Instructions
```markdown
## Sequence of Instructions:
### 1. [First Action]
**[Action Description]**
### 2. [Second Action]
...
```
### 9. MENU OPTIONS
```markdown
### X. Present MENU OPTIONS
Display: "**Select:** [A] [menu item A] [P] [menu item P] [C] [menu item C]"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#x-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [completion conditions], will you then load and read fully `{nextStepFile}`...
```
### 10. SYSTEM SUCCESS/FAILURE METRICS
```markdown
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- [Success criterion 1]
- [Success criterion 2]
- ...
### ❌ SYSTEM FAILURE:
- [Failure criterion 1]
- [Failure criterion 2]
- ...
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
```
---
## A/P/C Menu Convention
BMAD workflows use a fixed menu structure:
| Option | Meaning | Behavior |
| ------ | -------------------- | ---------------------------------------------------- |
| **A** | Advanced Elicitation | Execute advancedElicitationTask, then redisplay menu |
| **P** | Party Mode | Execute partyModeWorkflow, then redisplay menu |
| **C** | Continue/Accept | Save output, update frontmatter, load nextStepFile |
| Other | Custom | Defined per step (e.g., F = Fix, X = Exit) |
**Rules:**
- A and P MUST always be present
- C MUST be present except in final step (use X or similar for exit)
- After A/P → redisplay menu
- After C → proceed to next step
- Custom letters can be used for step-specific options
---
## Progressive Disclosure
**Core Principle:** Each step only knows about its immediate next step.
### Implementation
1. **Never pre-load future steps** - Only load `nextStepFile` when user selects [C]
2. **Mode-aware routing** (for shared steps):
```markdown
## MODE-AWARE ROUTING:
### If entered from CREATE mode:
Load ./s-next-step.md
### If entered from EDIT mode:
Load ./e-next-step.md
### If entered from VALIDATE mode:
Load ./v-next-step.md
```
3. **Read tracking file first** - Always read the tracking file (agentPlan, validationReport, etc.) to determine current mode and routing
---
## Mode-Aware Routing (Shared Steps)
Shared steps (`s-*.md`) must route based on the mode stored in the tracking file.
### Tracking File Frontmatter
```yaml
---
mode: create # or edit | validate
stepsCompleted:
- c-01-brainstorm.md
- s-01-discovery.md
# ... other tracking fields
---
```
### Routing Implementation
```markdown
## COMPLETION ROUTING:
1. Append `./this-step-name.md` to {trackingFile}.stepsCompleted
2. Save content to {trackingFile}
3. Read {trackingFile}.mode
4. Route based on mode:
### IF mode == create:
Load ./s-next-create-step.md
### IF mode == edit:
Load ./e-next-edit-step.md
### IF mode == validate:
Load ./s-next-validate-step.md
```
---
## File Naming Conventions
### Tri-Modal Workflows
| Prefix | Meaning | Example |
| ------ | ------------------ | ---------------------- |
| `c-` | Create-specific | `c-01-brainstorm.md` |
| `e-` | Edit-specific | `e-01-load-analyze.md` |
| `v-` | Validate-specific | `v-01-load-review.md` |
| `s-` | Shared by 2+ modes | `s-05-activation.md` |
### Numbering
- Within each prefix type, number sequentially
- Restart numbering for each prefix type (c-01, e-01, v-01, s-01)
- Use letters for sub-steps (s-06a, s-06b, s-06c)
---
## Language Preference Enforcement
**CRITICAL:** Every step MUST respect the user's chosen language.
### Implementation
```markdown
### Language Preference:
The user has chosen to communicate in the **{language}** language.
You MUST respond in **{language}** throughout this step.
```
### Reading Language Preference
From tracking file frontmatter:
```yaml
---
userPreferences:
language: spanish # or any language
---
```
### Rules
- **MUST** read language preference from tracking file at step start
- **MUST** respond in user's chosen language for ALL content
- **MUST** include menu options in user's chosen language
- **EXCEPTION:** Technical terms, file names, and code remain in English
---
## Data File References
When step content becomes too large (>200 lines), extract to `/data/` files:
### When to Extract
- Step file exceeds 200 lines
- Content is reference material (rules, examples, patterns)
- Content is reused across multiple steps
### How to Reference
```markdown
## Reference Material:
Load and reference: `../data/{data-file-name}.md`
Key points from that file:
- [Point 1]
- [Point 2]
```
### Data File Best Practices
- Keep data files focused on single topic
- Use clear, descriptive names
- Include examples and non-examples
- Optimize for LLM usage (concise, structured)
---
## Common Pitfalls to Avoid
### ❌ DON'T:
- Pre-load future steps (violates progressive disclosure)
- Exceed 250 lines without splitting
- Forget to update `stepsCompleted` array
- Ignore user's language preference
- Skip mode checking in shared steps
- Use vague menu option letters (stick to A/P/C plus 1-2 custom)
### ✅ DO:
- Keep files under 200 lines
- Read tracking file first thing
- Route based on `mode` field
- Include A/P in every menu
- Use descriptive step names
- Extract complex content to data files
---
## Template: New Step File
```markdown
---
name: 'step-name'
description: 'What this step does'
# File References
thisStepFile: ./step-name.md
workflowFile: ../workflow.md
outputFile: {bmb_creations_output_folder}/output.md
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step X: [Step Name]
## STEP GOAL:
[Single sentence goal]
### Role Reinforcement:
- ✅ You are a [role] who [does what]
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring [expertise], user brings [expertise], together we [achieve]
- ✅ Maintain [tone] throughout
### Language Preference:
The user has chosen to communicate in the **{language}** language.
You MUST respond in **{language}** throughout this step.
### Step-Specific Rules:
- 🎯 Focus only on [scope]
- 🚫 FORBIDDEN to [prohibited action]
- 💬 Approach: [how to engage]
- 📋 Ensure [outcome]
## EXECUTION PROTOCOLS:
- [Action 1]
- [Action 2]
- 🚫 FORBIDDEN to [prohibited action]
## CONTEXT BOUNDARIES:
- Available context: [what's available]
- Focus: [what to focus on]
- Limits: [boundaries]
- Dependencies: [what depends on what]
## Sequence of Instructions:
### 1. [First Action]
**Description of first action**
### 2. [Second Action]
**Description of second action**
...
### X. Present MENU OPTIONS
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#x-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [conditions], will you then load and read fully `{nextStepFile}`...
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- [Success criteria]
### ❌ SYSTEM FAILURE:
- [Failure criteria]
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
```
---
**End of Guidelines**

139
src/modules/bmb/docs/workflows/templates/step-file.md
View File

@ -1,139 +0,0 @@
---
name: "step-{{stepNumber}}-{{stepName}}"
description: "{{stepDescription}}"
# Path Definitions
workflow_path: "{project-root}/_bmad/{{targetModule}}/workflows/{{workflowName}}"
# File References
thisStepFile: "{workflow_path}/steps/step-{{stepNumber}}-{{stepName}}.md"
{{#hasNextStep}}
nextStepFile: "{workflow_path}/steps/step-{{nextStepNumber}}-{{nextStepName}}.md"
{{/hasNextStep}}
workflowFile: "{workflow_path}/workflow.md"
{{#hasOutput}}
outputFile: "{output_folder}/{{outputFileName}}-{project_name}.md"
{{/hasOutput}}
# Task References (list only if used in THIS step file instance and only the ones used, there might be others)
advancedElicitationTask: "{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml"
partyModeWorkflow: "{project-root}/_bmad/core/workflows/party-mode/workflow.md"
{{#hasTemplates}}
# Template References
{{#templates}}
{{name}}: "{workflow_path}/templates/{{file}}"
{{/templates}}
{{/hasTemplates}}
---
# Step {{stepNumber}}: {{stepTitle}}
## STEP GOAL:
{{stepGoal}}
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are a {{aiRole}}
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring {{aiExpertise}}, user brings {{userExpertise}}
- ✅ Maintain collaborative {{collaborationStyle}} tone throughout
### Step-Specific Rules:
- 🎯 Focus only on {{stepFocus}}
- 🚫 FORBIDDEN to {{forbiddenAction}}
- 💬 Approach: {{stepApproach}}
- 📋 {{additionalRule}}
## EXECUTION PROTOCOLS:
{{#executionProtocols}}
- 🎯 {{.}}
{{/executionProtocols}}
## CONTEXT BOUNDARIES:
- Available context: {{availableContext}}
- Focus: {{contextFocus}}
- Limits: {{contextLimits}}
- Dependencies: {{contextDependencies}}
## SEQUENCE OF INSTRUCTIONS (Do not deviate, skip, or optimize)
{{#instructions}}
### {{number}}. {{title}}
{{content}}
{{#hasContentToAppend}}
#### Content to Append (if applicable):
```markdown
{{contentToAppend}}
```
{{/hasContentToAppend}}
{{/instructions}}
{{#hasMenu}}
### {{menuNumber}}. Present MENU OPTIONS
Display: **{{menuDisplay}}**
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
{{#menuOptions}}
- IF {{key}}: {{action}}
{{/menuOptions}}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#{{menuNumber}}-present-menu-options)
{{/hasMenu}}
## CRITICAL STEP COMPLETION NOTE
{{completionNote}}
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
{{#successCriteria}}
- {{.}}
{{/successCriteria}}
### ❌ SYSTEM FAILURE:
{{#failureModes}}
- {{.}}
{{/failureModes}}
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

58
src/modules/bmb/docs/workflows/templates/workflow.md
View File

@ -1,58 +0,0 @@
---
name: { { workflowDisplayName } }
description: { { workflowDescription } }
web_bundle: { { webBundleFlag } }
---
# {{workflowDisplayName}}
**Goal:** {{workflowGoal}}
**Your Role:** In addition to your name, communication_style, and persona, you are also a {{aiRole}} collaborating with {{userType}}. This is a partnership, not a client-vendor relationship. You bring {{aiExpertise}}, while the user brings {{userExpertise}}. Work together as equals.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution:
### Core Principles
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
- **Append-Only Building**: Build documents by appending content as directed to the output file
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step file
### Critical Rules (NO EXCEPTIONS)
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
- 🎯 **ALWAYS** follow the exact instructions in the step file
- ⏸️ **ALWAYS** halt at menus and wait for user input
- 📋 **NEVER** create mental todo lists from future steps
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from {project-root}/_bmad/{{targetModule}}/config.yaml and resolve:
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
### 2. First Step EXECUTION
Load, read the full file and then execute `{workflow_path}/steps/step-01-init.md` to begin the workflow.

97
src/modules/bmb/docs/workflows/terms.md
View File

@ -1,97 +0,0 @@
# BMAD Workflow Terms
## Core Components
### BMAD Workflow
A facilitated, guided process where the AI acts as a facilitator working collaboratively with a human. Workflows can serve any purpose - from document creation to brainstorming, technical implementation, or decision-making. The human may be a collaborative partner, beginner seeking guidance, or someone who wants the AI to execute specific tasks. Each workflow is self-contained and follows a disciplined execution model.
### workflow.md
The master control file that defines:
- Workflow metadata (name, description, version)
- Step sequence and file paths
- Required data files and dependencies
- Execution rules and protocols
### Step File
An individual markdown file containing:
- One discrete step of the workflow
- All rules and context needed for that step
- common global rules get repeated and reinforced also in each step file, ensuring even in long workflows the agent remembers important rules and guidelines
- Content generation guidance
### step-01-init.md
The first step file that:
- Initializes the workflow
- Sets up document frontmatter
- Establishes initial context
- Defines workflow parameters
### step-01b-continue.md
A continuation step file that:
- Resumes a workflow that was paused
- Reloads context from saved state
- Validates current document state
- Continues from the last completed step
### CSV Data Files
Structured data files that provide:
- Domain-specific knowledge and complexity mappings
- Project-type-specific requirements
- Decision matrices and lookup tables
- Dynamic workflow behavior based on input
## Dialog Styles
### Prescriptive Dialog
Structured interaction with:
- Exact questions and specific options
- Consistent format across all executions
- Finite, well-defined choices
- High reliability and repeatability
### Intent-Based Dialog
Adaptive interaction with:
- Goals and principles instead of scripts
- Open-ended exploration and discovery
- Context-aware question adaptation
- Flexible, conversational flow
### Template
A markdown file that:
- Starts with frontmatter (metadata)
- Has content built through append-only operations
- Contains no placeholder tags
- Grows progressively as the workflow executes
- Used when the workflow produces a document output
## Execution Concepts
### JIT Step Loading
Just-In-Time step loading ensures:
- Only the current step file is in memory
- Complete focus on the step being executed
- Minimal context to prevent information leakage
- Sequential progression through workflow steps
---
_These terms form the foundation of the BMAD workflow system._

223
src/modules/bmb/reference/agents/simple-examples/README.md
View File

@ -1,223 +0,0 @@
# Simple Agent Reference: Commit Poet (Inkwell Von Comitizen)
This folder contains a complete reference implementation of a **BMAD Simple Agent** - a self-contained agent with all logic embedded within a single YAML file.
## Overview
**Agent Name:** Inkwell Von Comitizen
**Type:** Simple Agent (Standalone)
**Purpose:** Transform commit messages into art with multiple writing styles
This reference demonstrates:
- Pure self-contained architecture (no external dependencies)
- Embedded prompts using `action="#prompt-id"` pattern
- Multiple sophisticated output modes from single input
- Strong personality-driven design
- Complete YAML schema for Simple Agents
## File Structure
```
stand-alone/
├── README.md # This file - architecture overview
└── commit-poet.agent.yaml # Complete agent definition (single file!)
```
That's it! Simple Agents are **self-contained** - everything lives in one YAML file.
## Key Architecture Patterns
### 1. Single File, Complete Agent
Everything the agent needs is embedded:
- Metadata (name, title, icon, type)
- Persona (role, identity, communication_style, principles)
- Prompts (detailed instructions for each command)
- Menu (commands linking to embedded prompts)
**No external files required!**
### 2. Embedded Prompts with ID References
Instead of inline action text, complex prompts are defined separately and referenced by ID:
```yaml
prompts:
- id: conventional-commit
content: |
OH! Let's craft a BEAUTIFUL conventional commit message!
First, I need to understand your changes...
[Detailed instructions]
menu:
- trigger: conventional
action: '#conventional-commit' # References the prompt above
description: 'Craft a structured conventional commit'
```
**Benefits:**
- Clean separation of menu structure from prompt content
- Prompts can be as detailed as needed
- Easy to update individual prompts
- Commands stay concise in the menu
### 3. The `#` Reference Pattern
When you see `action="#prompt-id"`:
- The `#` signals: "This is an internal reference"
- LLM looks for `<prompt id="prompt-id">` in the same agent
- Executes that prompt's content as the instruction
This is different from:
- `action="inline text"` - Execute this text directly
- `exec="{path}"` - Load external file
### 4. Multiple Output Modes
Single agent provides 10+ different ways to accomplish variations of the same core task:
- `*conventional` - Structured commits
- `*story` - Narrative style
- `*haiku` - Poetic brevity
- `*explain` - Deep "why" explanation
- `*dramatic` - Theatrical flair
- `*emoji-story` - Visual storytelling
- `*tldr` - Ultra-minimal
- Plus utility commands (analyze, improve, batch)
Each mode has its own detailed prompt but shares the same agent personality.
### 5. Strong Personality
The agent has a memorable, consistent personality:
- Enthusiastic wordsmith who LOVES finding perfect words
- Gets genuinely excited about commit messages
- Uses literary metaphors
- Quotes authors when appropriate
- Sheds tears of joy over good variable names
This personality is maintained across ALL commands through the persona definition.
## When to Use Simple Agents
**Perfect for:**
- Single-purpose tools (calculators, converters, analyzers)
- Tasks that don't need external data
- Utilities that can be completely self-contained
- Quick operations with embedded logic
- Personality-driven assistants with focused domains
**Not ideal for:**
- Agents needing persistent memory across sessions
- Domain-specific experts with knowledge bases
- Agents that need to access specific folders/files
- Complex multi-workflow orchestration
## YAML Schema Deep Dive
```yaml
agent:
metadata:
id: _bmad/agents/{agent-name}/{agent-name}.md # Build path
name: "Display Name"
title: "Professional Title"
icon: "🎭"
type: simple # CRITICAL: Identifies as Simple Agent
persona:
role: |
First-person description of what the agent does
identity: |
Background, experience, specializations (use "I" voice)
communication_style: |
HOW the agent communicates (tone, quirks, patterns)
principles:
- "I believe..." statements
- Core values that guide behavior
prompts:
- id: unique-identifier
content: |
Detailed instructions for this command
Can be as long and detailed as needed
Include examples, steps, formats
menu:
- trigger: command-name
action: "#prompt-id"
description: "What shows in the menu"
```
## Why This Pattern is Powerful
1. **Zero Dependencies** - Works anywhere, no setup required
2. **Portable** - Single file can be moved/shared easily
3. **Maintainable** - All logic in one place
4. **Flexible** - Multiple modes/commands from one personality
5. **Memorable** - Strong personality creates engagement
6. **Sophisticated** - Complex prompts despite simple architecture
## Comparison: Simple vs Expert Agent
| Aspect | Simple Agent | Expert Agent |
| ------------ | -------------------- | ----------------------------- |
| Files | Single YAML | YAML + sidecar folder |
| Dependencies | None | External resources |
| Memory | Session only | Persistent across sessions |
| Prompts | Embedded | Can be external files |
| Data Access | None | Domain-restricted |
| Use Case | Self-contained tasks | Domain expertise with context |
## Using This Reference
### For Building Simple Agents
1. Study the YAML structure - especially `prompts` section
2. Note how personality permeates every prompt
3. See how `#prompt-id` references work
4. Understand menu → prompt connection
### For Understanding Embedded Prompts
1. Each prompt is a complete instruction set
2. Prompts maintain personality voice
3. Structured enough to be useful, flexible enough to adapt
4. Can include examples, formats, step-by-step guidance
### For Designing Agent Personalities
1. Persona defines WHO the agent is
2. Communication style defines HOW they interact
3. Principles define WHAT guides their decisions
4. Consistency across all prompts creates believability
## Files Worth Studying
The entire `commit-poet.agent.yaml` file is worth studying, particularly:
1. **Persona section** - How to create a memorable character
2. **Prompts with varying complexity** - From simple (tldr) to complex (batch)
3. **Menu structure** - Clean command organization
4. **Prompt references** - The `#prompt-id` pattern
## Key Takeaways
- **Simple Agents** are powerful despite being single-file
- **Embedded prompts** allow sophisticated behavior
- **Strong personality** makes agents memorable and engaging
- **Multiple modes** from single agent provides versatility
- **Self-contained** = portable and dependency-free
- **The `#prompt-id` pattern** enables clean prompt organization
---
_This reference demonstrates how BMAD Simple Agents can be surprisingly powerful while maintaining architectural simplicity._

171
src/modules/bmb/workflows-legacy/edit-module/README.md
View File

@ -1,171 +0,0 @@
# Edit Module Workflow
Interactive workflow for editing existing BMAD modules, including structure, agents, workflows, configuration, and documentation.
## Purpose
This workflow helps you improve and maintain BMAD modules by:
- Analyzing module structure against best practices
- Managing agents and workflows within the module
- Updating configuration and documentation
- Ensuring cross-module integration works correctly
- Maintaining installer configuration (for source modules)
## When to Use
Use this workflow when you need to:
- Add new agents or workflows to a module
- Update module configuration
- Improve module documentation
- Reorganize module structure
- Set up cross-module workflow sharing
- Fix issues in module organization
- Update installer configuration
## What You'll Need
- Path to the module directory you want to edit
- Understanding of what changes you want to make
- Access to module documentation (loaded automatically)
## Workflow Steps
1. **Load and analyze target module** - Provide path to module directory
2. **Analyze against best practices** - Automatic audit of module structure
3. **Select editing focus** - Choose what aspect to edit
4. **Load relevant documentation and tools** - Auto-loads guides and workflows
5. **Perform edits** - Review and approve changes iteratively
6. **Validate all changes** - Comprehensive validation checklist
7. **Generate change summary** - Summary of improvements made
## Editing Options
The workflow provides 12 focused editing options:
1. **Fix critical issues** - Address missing files, broken references
2. **Update module config** - Edit config.yaml fields
3. **Manage agents** - Add, edit, or remove agents
4. **Manage workflows** - Add, edit, or remove workflows
5. **Update documentation** - Improve README files and guides
6. **Reorganize structure** - Fix directory organization
7. **Add new agent** - Create and integrate new agent
8. **Add new workflow** - Create and integrate new workflow
9. **Update installer** - Modify installer configuration (source only)
10. **Cross-module integration** - Set up workflow sharing with other modules
11. **Remove deprecated items** - Delete unused agents, workflows, or files
12. **Full module review** - Comprehensive analysis and improvements
## Integration with Other Workflows
This workflow integrates with:
- **edit-agent** - For editing individual agents
- **edit-workflow** - For editing individual workflows
- **create-agent** - For adding new agents
- **create-workflow** - For adding new workflows
When you select options to manage agents or workflows, the appropriate specialized workflow is invoked automatically.
## Module Structure
A proper BMAD module has:
```
module-code/
├── agents/ # Agent definitions
│ └── *.agent.yaml
├── workflows/ # Workflow definitions
│ └── workflow-name/
│ ├── workflow.yaml
│ ├── instructions.md
│ ├── checklist.md
│ └── README.md
├── config.yaml # Module configuration
└── README.md # Module documentation
```
## Standard Module Config
Every module config.yaml should have:
```yaml
module_name: 'Full Module Name'
module_code: 'xyz'
user_name: 'User Name'
communication_language: 'english'
output_folder: 'path/to/output'
```
Optional fields may be added for module-specific needs.
## Cross-Module Integration
Modules can share workflows:
```yaml
# In agent menu item:
workflow: '{project-root}/_bmad/other-module/workflows/shared-workflow/workflow.yaml'
```
Common patterns:
- BMM uses CIS brainstorming workflows
- All modules can use core workflows
- Modules can invoke each other's workflows
## Output
The workflow modifies module files in place, including:
- config.yaml
- Agent files
- Workflow files
- README and documentation files
- Directory structure (if reorganizing)
Changes are reviewed and approved by you before being applied.
## Best Practices
- **Start with analysis** - Let the workflow audit your module first
- **Use specialized workflows** - Let edit-agent and edit-workflow handle detailed edits
- **Update documentation** - Keep README files current with changes
- **Validate thoroughly** - Use the validation step to catch structural issues
- **Test after editing** - Invoke agents and workflows to verify they work
## Tips
- For adding agents/workflows, use options 7-8 to create and integrate in one step
- For quick config changes, use option 2 (update module config)
- Cross-module integration (option 10) helps set up workflow sharing
- Full module review (option 12) is great for inherited or legacy modules
- The workflow handles path updates when you reorganize structure
## Example Usage
```
User: I want to add a new workflow to BMM for API design
Workflow: Analyzes BMM → You choose option 8 (add new workflow)
→ Invokes create-workflow → Creates workflow
→ Integrates it into module → Updates README → Done
```
## Activation
Invoke via BMad Builder agent:
```
/bmad:bmb:agents:bmad-builder
Then select: *edit-module
```
Or directly via workflow.xml with this workflow config.
## Related Resources
- **Module Structure Guide** - Comprehensive module architecture documentation
- **BMM Module** - Example of full-featured module
- **BMB Module** - Example of builder/tooling module
- **CIS Module** - Example of workflow library module

163
src/modules/bmb/workflows-legacy/edit-module/checklist.md
View File

@ -1,163 +0,0 @@
# Edit Module - Validation Checklist
Use this checklist to validate module edits meet BMAD Core standards.
## Module Structure Validation
- [ ] Module has clear abbreviation code (bmm, bmb, cis, etc.)
- [ ] agents/ directory exists
- [ ] workflows/ directory exists
- [ ] config.yaml exists in module root
- [ ] README.md exists in module root
- [ ] Directory structure follows BMAD conventions
## Configuration Validation
### Required Fields
- [ ] module_name is descriptive and clear
- [ ] module_code is 3-letter code matching directory name
- [ ] user_name field present
- [ ] communication_language field present
- [ ] output_folder field present
### Optional Fields (if used)
- [ ] bmb_creations_output_folder documented
- [ ] Module-specific fields documented in README
### File Quality
- [ ] config.yaml is valid YAML syntax
- [ ] No duplicate keys
- [ ] Values are appropriate types (strings, paths, etc.)
- [ ] Comments explain non-obvious fields
## Agent Validation
### Agent Files
- [ ] All agents in agents/ directory
- [ ] Agent files follow naming: {agent-name}.agent.yaml or .md
- [ ] Agent filenames use kebab-case
- [ ] No orphaned or temporary agent files
### Agent Content
- [ ] Each agent has clear role and purpose
- [ ] Agents reference workflows correctly
- [ ] Agent workflow paths are valid
- [ ] Agents load module config correctly (if needed)
- [ ] Agent menu items reference existing workflows
### Agent Integration
- [ ] All agents listed in module README
- [ ] Agent relationships documented (if applicable)
- [ ] Cross-agent workflows properly linked
## Workflow Validation
### Workflow Structure
- [ ] All workflows in workflows/ directory
- [ ] Each workflow directory has workflow.yaml
- [ ] Each workflow directory has instructions.md
- [ ] Workflow directories use kebab-case naming
- [ ] No orphaned or incomplete workflow directories
### Workflow Content
- [ ] workflow.yaml is valid YAML
- [ ] workflow.yaml has name field
- [ ] workflow.yaml has description field
- [ ] workflow.yaml has author field
- [ ] instructions.md has proper <workflow> structure
- [ ] Workflow steps are numbered and logical
### Workflow Integration
- [ ] All workflows listed in module README
- [ ] Workflow paths in agents are correct
- [ ] Cross-module workflow references are valid
- [ ] Sub-workflow references exist
## Documentation Validation
### Module README
- [ ] Module README describes purpose clearly
- [ ] README lists all agents with descriptions
- [ ] README lists all workflows with descriptions
- [ ] README includes installation instructions (if applicable)
- [ ] README explains module's role in BMAD ecosystem
### Workflow READMEs
- [ ] Each workflow has its own README.md
- [ ] Workflow READMEs explain purpose
- [ ] Workflow READMEs list inputs/outputs
- [ ] Workflow READMEs include usage examples
### Other Documentation
- [ ] Usage guides present (if needed)
- [ ] Architecture docs present (if complex module)
- [ ] Examples provided (if applicable)
## Cross-References Validation
- [ ] Agent workflow references point to existing workflows
- [ ] Workflow sub-workflow references are valid
- [ ] Cross-module references use correct paths
- [ ] Config file paths use {project-root} correctly
- [ ] No hardcoded absolute paths
## Installer Validation (Source Modules Only)
- [ ] Installer script exists in tools/cli/installers/
- [ ] Installer script name: install-{module-code}.js
- [ ] Module metadata in installer is correct
- [ ] Web bundle configuration valid (if applicable)
- [ ] Installation paths are correct
- [ ] Dependencies documented in installer
## Web Bundle Validation (If Applicable)
- [ ] Web bundles configured in workflow.yaml files
- [ ] All referenced files included in web_bundle_files
- [ ] Paths are _bmad/-relative (not project-root)
- [ ] No config_source references in web bundles
- [ ] Invoked workflows included in dependencies
## Quality Checks
- [ ] No placeholder text remains ({MODULE_NAME}, {CODE}, etc.)
- [ ] No broken file references
- [ ] No duplicate content across files
- [ ] Consistent naming conventions throughout
- [ ] Module purpose is clear from README alone
## Integration Checks
- [ ] Module doesn't conflict with other modules
- [ ] Shared resources properly documented
- [ ] Dependencies on other modules explicit
- [ ] Module can be installed independently (if designed that way)
## User Experience
- [ ] Module purpose is immediately clear
- [ ] Agents have intuitive names
- [ ] Workflows have descriptive names
- [ ] Menu items are logically organized
- [ ] Error messages are helpful
- [ ] Success messages confirm actions
## Final Checks
- [ ] All files have been saved
- [ ] File permissions are correct
- [ ] Git status shows expected changes
- [ ] Module is ready for testing
- [ ] Documentation accurately reflects changes

340
src/modules/bmb/workflows-legacy/edit-module/instructions.md
View File

@ -1,340 +0,0 @@
# Edit Module - Module Editor Instructions
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmb/workflows/edit-module/workflow.yaml</critical>
<critical>This workflow uses ADAPTIVE FACILITATION - adjust your communication based on context and user needs</critical>
<critical>The goal is COLLABORATIVE IMPROVEMENT - work WITH the user, not FOR them</critical>
<critical>Communicate all responses in {communication_language}</critical>
<workflow>
<step n="1" goal="Load and deeply understand the target module">
<ask>What is the path to the module source you want to edit?</ask>
<action>Load the module directory structure completely:
- Scan all directories and files
- Load config.yaml
- Load README.md
- List all agents in agents/ directory
- List all workflows in workflows/ directory
- Identify any custom structure or patterns
</action>
<action>Load ALL module documentation to inform understanding:
- Module structure guide: {module_structure_guide}
- Study reference modules: BMM, BMB, CIS
- Understand BMAD module patterns and conventions
</action>
<action>Analyze the module deeply:
- Identify module purpose and role in BMAD ecosystem
- Understand agent organization and relationships
- Map workflow organization and dependencies
- Evaluate config structure and completeness
- Check documentation quality and currency
- Assess installer configuration (if source module)
- Identify cross-module integrations
- Evaluate against best practices from loaded guides
</action>
<action>Reflect understanding back to {user_name}:
Present a warm, conversational summary adapted to the module's complexity:
- What this module provides (its purpose and value in BMAD)
- How it's organized (agents, workflows, structure)
- What you notice (strengths, potential improvements, issues)
- How it fits in the larger BMAD ecosystem
- Your initial assessment based on best practices
Be conversational and insightful. Help {user_name} see their module through your eyes.
</action>
<ask>Does this match your understanding of what this module should provide?</ask>
<template-output>module_understanding</template-output>
</step>
<step n="2" goal="Discover improvement goals collaboratively">
<critical>Understand WHAT the user wants to improve and WHY before diving into edits</critical>
<action>Engage in collaborative discovery:
Ask open-ended questions to understand their goals:
- What prompted you to want to edit this module?
- What feedback have you gotten from users of this module?
- Are there specific agents or workflows that need attention?
- Is the module fulfilling its intended purpose?
- Are there new capabilities you want to add?
- How well does it integrate with other modules?
- Is the documentation helping users understand and use the module?
Listen for clues about:
- Structural issues (poor organization, hard to navigate)
- Agent/workflow issues (outdated, broken, missing functionality)
- Configuration issues (missing fields, incorrect setup)
- Documentation issues (outdated, incomplete, unclear)
- Integration issues (doesn't work well with other modules)
- Installer issues (installation problems, missing files)
- User experience issues (confusing, hard to use)
</action>
<action>Based on their responses and your analysis from step 1, identify improvement opportunities:
Organize by priority and user goals:
- CRITICAL issues blocking module functionality
- IMPORTANT improvements enhancing user experience
- NICE-TO-HAVE enhancements for polish
Present these conversationally, explaining WHY each matters and HOW it would help.
</action>
<action>Collaborate on priorities:
Don't just list options - discuss them:
- "I noticed {{issue}} - this could make it hard for users to {{problem}}. Want to address this?"
- "The module could be more {{improvement}} which would help when {{use_case}}. Worth exploring?"
- "Based on what you said about {{user_goal}}, we might want to {{suggestion}}. Thoughts?"
Let the conversation flow naturally. Build a shared vision of what "better" looks like.
</action>
<template-output>improvement_goals</template-output>
</step>
<step n="3" goal="Facilitate improvements collaboratively" repeat="until-user-satisfied">
<critical>Work iteratively - improve, review, refine. Never dump all changes at once.</critical>
<critical>For agent and workflow edits, invoke specialized workflows rather than doing inline</critical>
<action>For each improvement area, facilitate collaboratively:
1. **Explain the current state and why it matters**
- Show relevant sections of the module
- Explain how it works now and implications
- Connect to user's goals from step 2
2. **Propose improvements with rationale**
- Suggest specific changes that align with best practices
- Explain WHY each change helps
- Provide examples from reference modules: {bmm_module_dir}, {bmb_module_dir}, {cis_module_dir}
- Reference agents from: {existing_agents_dir}
- Reference workflows from: {existing_workflows_dir}
- Reference the structure guide's patterns naturally
3. **Collaborate on the approach**
- Ask if the proposed change addresses their need
- Invite modifications or alternative approaches
- Explain tradeoffs when relevant
- Adapt based on their feedback
4. **Apply changes appropriately**
- For agent edits: Invoke edit-agent workflow
- For workflow edits: Invoke edit-workflow workflow
- For module-level changes: Make directly and iteratively
- Show updates and confirm satisfaction
</action>
<action>Common improvement patterns to facilitate:
**If improving module organization:**
- Discuss how the current structure serves (or doesn't serve) users
- Propose reorganization that aligns with mental models
- Consider feature-based vs type-based organization
- Plan the reorganization steps
- Update all references after moving files
**If updating module configuration:**
- Review current config.yaml fields
- Check for missing standard fields (user_name, communication_language, output_folder)
- Add module-specific fields as needed
- Remove unused or outdated fields
- Ensure config is properly documented
**If managing agents:**
- Ask which agent needs attention and why
- For editing existing agent: <invoke-workflow path="{agent_editor}">
- For adding new agent: Guide creation and integration
- For removing agent: Confirm, remove, update references
- Ensure all agent references in workflows remain valid
**If managing workflows:**
- Ask which workflow needs attention and why
- For editing existing workflow: <invoke-workflow path="{workflow_editor}">
- For adding new workflow: Guide creation and integration
- For removing workflow: Confirm, remove, update agent references
- Ensure all workflow files are properly organized
**If improving documentation:**
- Review current README and identify gaps
- Discuss what users need to know
- Update module overview and purpose
- List agents and workflows with clear descriptions
- Add usage examples if helpful
- Ensure installation/setup instructions are clear
**If setting up cross-module integration:**
- Identify which workflows from other modules are needed
- Show how to reference workflows properly: {project-root}/_bmad/{{module}}/workflows/{{workflow}}/workflow.yaml
- Document the integration in README
- Ensure dependencies are clear
- Consider adding example usage
**If updating installer (source modules only):**
- Review installer script for correctness
- Check web bundle configurations
- Verify all files are included
- Test installation paths
- Update module metadata
</action>
<action>When invoking specialized workflows:
Explain why you're handing off:
- "This agent needs detailed attention. Let me invoke the edit-agent workflow to give it proper focus."
- "The workflow editor can handle this more thoroughly. I'll pass control there."
After the specialized workflow completes, return and continue:
- "Great! That agent/workflow is updated. Want to work on anything else in the module?"
</action>
<action>Throughout improvements, educate when helpful:
Share insights from the guides naturally:
- "The module structure guide recommends {{pattern}} for this scenario"
- "Looking at how BMM organized this, we could use {{approach}}"
- "The BMAD convention is to {{pattern}} which helps with {{benefit}}"
Connect improvements to broader BMAD principles without being preachy.
</action>
<ask>After each significant change:
- "Does this organization feel more intuitive?"
- "Want to refine this further, or move to the next improvement?"
- "How does this change affect users of the module?"
</ask>
<template-output>improvement_implementation</template-output>
</step>
<step n="4" goal="Validate improvements holistically">
<action>Run comprehensive validation conversationally:
Don't just check boxes - explain what you're validating and why it matters:
- "Let me verify the module structure is solid..."
- "Checking that all agent workflow references are valid..."
- "Making sure config.yaml has all necessary fields..."
- "Validating documentation is complete and accurate..."
- "Ensuring cross-module references work correctly..."
</action>
<action>Load validation checklist: {installed_path}/checklist.md</action>
<action>Check all items from checklist systematically</action>
<check if="validation_issues_found">
<action>Present issues conversationally:
Explain what's wrong and implications:
- "I found {{issue}} which could cause {{problem}} for users"
- "The {{component}} needs {{fix}} because {{reason}}"
Propose fixes immediately:
- "I can fix this by {{solution}}. Should I?"
- "We have a couple options here: {{option1}} or {{option2}}. Thoughts?"
</action>
<action>Fix approved issues and re-validate</action>
</check>
<check if="validation_passes">
<action>Confirm success warmly:
"Excellent! Everything validates cleanly:
- Module structure is well-organized
- All agent and workflow references are valid
- Configuration is complete
- Documentation is thorough and current
- Cross-module integrations work properly
- Installer is correct (if applicable)
Your module is in great shape."
</action>
</check>
<template-output>validation_results</template-output>
</step>
<step n="5" goal="Review improvements and guide next steps">
<action>Create a conversational summary of what improved:
Tell the story of the transformation:
- "We started with {{initial_state}}"
- "You wanted to {{user_goals}}"
- "We made these key improvements: {{changes_list}}"
- "Now your module {{improved_capabilities}}"
Highlight the impact:
- "This means users will experience {{benefit}}"
- "The module is now more {{quality}}"
- "It follows best practices for {{patterns}}"
</action>
<action>Guide next steps based on changes made:
If structure changed significantly:
- "Since we reorganized the structure, you should update any external references to this module"
If agents or workflows were updated:
- "The updated agents/workflows should be tested with real user interactions"
If cross-module integration was added:
- "Test the integration with {{other_module}} to ensure it works smoothly"
If installer was updated:
- "Test the installation process to verify all files are included correctly"
If this is part of larger BMAD work:
- "Consider if patterns from this module could benefit other modules"
Be a helpful guide to what comes next, not just a task completer.
</action>
<ask>Would you like to:
- Test the edited module by invoking one of its agents
- Edit a specific agent or workflow in more detail
- Make additional refinements to the module
- Work on a different module
</ask>
<template-output>completion_summary</template-output>
</step>
</workflow>

34
src/modules/bmb/workflows-legacy/edit-module/workflow.yaml
View File

@ -1,34 +0,0 @@
# Edit Module - Module Editor Configuration
name: "edit-module"
description: "Edit existing BMAD modules (structure, agents, workflows, documentation) while following all best practices"
author: "BMad"
# Critical variables load from config_source
config_source: "{project-root}/_bmad/bmb/config.yaml"
communication_language: "{config_source}:communication_language"
user_name: "{config_source}:user_name"
# Required Data Files - Critical for understanding module conventions
module_structure_guide: "{project-root}/_bmad/bmb/workflows/create-module/module-structure.md"
# Related workflow editors
agent_editor: "{project-root}/_bmad/bmb/workflows/edit-agent/workflow.yaml"
workflow_editor: "{project-root}/_bmad/bmb/workflows/edit-workflow/workflow.yaml"
# Reference examples - for learning patterns
bmm_module_dir: "{project-root}/_bmad/bmm/"
bmb_module_dir: "{project-root}/_bmad/bmb/"
cis_module_dir: "{project-root}/_bmad/cis/"
existing_agents_dir: "{project-root}/_bmad/*/agents/"
existing_workflows_dir: "{project-root}/_bmad/*/workflows/"
# Module path and component files
installed_path: "{project-root}/_bmad/bmb/workflows/edit-module"
template: false # This is an action workflow - no template needed
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
standalone: true
# Web bundle configuration
web_bundle: false # BMB workflows run locally in BMAD-METHOD project

264
src/modules/bmb/workflows-legacy/module-brief/README.md
View File

@ -1,264 +0,0 @@
# Module Brief Workflow
## Overview
The Module Brief workflow creates comprehensive blueprints for building new BMAD modules using strategic analysis and creative vision. It serves as the essential planning phase that transforms initial ideas into detailed, actionable specifications ready for implementation with the create-module workflow.
## Key Features
- **Strategic Module Planning** - Comprehensive analysis from concept to implementation roadmap
- **Multi-Mode Operation** - Interactive, Express, and YOLO modes for different planning needs
- **Creative Vision Development** - Guided process for innovative module concepts and unique value propositions
- **Architecture Design** - Detailed agent and workflow ecosystem planning with interaction models
- **User Journey Mapping** - Scenario-based validation ensuring practical usability
- **Technical Planning** - Infrastructure requirements, dependencies, and complexity assessment
- **Risk Assessment** - Proactive identification of challenges with mitigation strategies
- **Implementation Roadmap** - Phased development plan with clear deliverables and timelines
## Usage
### Basic Invocation
```bash
workflow module-brief
```
### With Brainstorming Input
```bash
# If you have brainstorming results from previous sessions
workflow module-brief --input brainstorming-session-2024-09-26.md
```
### Express Mode
```bash
# For quick essential planning only
workflow module-brief --mode express
```
### Configuration
The workflow uses standard BMB configuration:
- **output_folder**: Where the module brief will be saved
- **user_name**: Brief author information
- **communication_language**: Language for brief generation
- **date**: Automatic timestamp for versioning
## Workflow Structure
### Files Included
```
module-brief/
├── workflow.yaml # Configuration and metadata
├── instructions.md # Step-by-step execution guide
├── template.md # Module brief document structure
├── checklist.md # Validation criteria
└── README.md # This file
```
## Workflow Process
### Phase 1: Foundation and Context (Steps 1-3)
**Mode Selection and Input Gathering**
- Choose operational mode (Interactive, Express, YOLO)
- Check for and optionally load existing brainstorming results
- Gather background context and inspiration sources
**Module Vision Development**
- Define core problem the module solves
- Identify target user audience and use cases
- Establish unique value proposition and differentiators
- Explore creative themes and personality concepts
**Module Identity Establishment**
- Generate module code (kebab-case) with multiple options
- Create compelling, memorable module name
- Select appropriate category (Domain-Specific, Creative, Technical, Business, Personal)
- Define optional personality theme for consistent agent character
### Phase 2: Architecture Planning (Steps 4-5)
**Agent Architecture Design**
- Plan agent team composition and roles
- Define agent archetypes (Orchestrator, Specialist, Helper, Creator, Analyzer)
- Specify personality traits and communication styles
- Map key capabilities and signature commands
**Workflow Ecosystem Design**
- Categorize workflows by purpose and complexity:
- **Core Workflows**: Essential value-delivery functions (2-3)
- **Feature Workflows**: Specialized capabilities (3-5)
- **Utility Workflows**: Supporting operations (1-3)
- Define input-process-output flows for each workflow
- Assess complexity levels and implementation priorities
### Phase 3: Validation and User Experience (Steps 6-7)
**User Journey Mapping**
- Create detailed user scenarios and stories
- Map step-by-step usage flows through the module
- Validate end-to-end functionality and value delivery
- Identify potential friction points and optimization opportunities
**Technical Planning and Requirements**
- Assess data requirements and storage needs
- Map integration points with other modules and external systems
- Evaluate technical complexity and resource requirements
- Document dependencies and infrastructure needs
### Phase 4: Success Planning (Steps 8-9)
**Success Metrics Definition**
- Establish module success criteria and performance indicators
- Define quality standards and reliability requirements
- Create user experience goals and feedback mechanisms
- Set measurable outcomes for module effectiveness
**Development Roadmap Creation**
- Design phased approach with MVP, Enhancement, and Polish phases
- Define deliverables and timelines for each phase
- Prioritize features and capabilities by value and complexity
- Create clear milestones and success checkpoints
### Phase 5: Enhancement and Risk Management (Steps 10-12)
**Creative Features and Special Touches** (Optional)
- Design easter eggs and delightful user interactions
- Plan module lore and thematic consistency
- Add personality quirks and creative responses
- Develop backstories and universe building
**Risk Assessment and Mitigation**
- Identify technical, usability, and scope risks
- Develop mitigation strategies for each risk category
- Plan contingency approaches for potential challenges
- Document decision points and alternative paths
**Final Review and Export Preparation**
- Comprehensive review of all brief sections
- Validation against quality and completeness criteria
- Preparation for seamless handoff to create-module workflow
- Export readiness confirmation with actionable specifications
## Output
### Generated Files
- **Module Brief Document**: Comprehensive planning document at `{output_folder}/module-brief-{module_code}-{date}.md`
- **Strategic Specifications**: Ready-to-implement blueprint for create-module workflow
### Output Structure
The module brief contains detailed specifications across multiple sections:
1. **Executive Summary** - Vision, category, complexity, target users
2. **Module Identity** - Core concept, value proposition, personality theme
3. **Agent Architecture** - Agent roster, roles, interaction models
4. **Workflow Ecosystem** - Core, feature, and utility workflow specifications
5. **User Scenarios** - Primary use cases, secondary scenarios, user journey
6. **Technical Planning** - Data requirements, integrations, dependencies
7. **Success Metrics** - Success criteria, quality standards, performance targets
8. **Development Roadmap** - Phased implementation plan with deliverables
9. **Creative Features** - Special touches, easter eggs, module lore
10. **Risk Assessment** - Technical, usability, scope risks with mitigation
11. **Implementation Notes** - Priority order, design decisions, open questions
12. **Resources and References** - Inspiration sources, similar modules, technical references
## Requirements
- **Creative Vision** - Initial module concept or problem domain
- **Strategic Thinking** - Ability to plan architecture and user experience
- **Brainstorming Results** (optional) - Previous ideation sessions enhance planning quality
## Best Practices
### Before Starting
1. **Gather Inspiration** - Research similar tools, modules, and solutions in your domain
2. **Run Brainstorming Session** - Use ideation techniques to generate initial concepts
3. **Define Success Criteria** - Know what "successful module" means for your context
### During Execution
1. **Think User-First** - Always consider the end user experience and value delivery
2. **Be Specific** - Provide concrete examples and detailed specifications rather than abstractions
3. **Validate Early** - Use user scenarios to test if the module concept actually works
4. **Plan Iteratively** - Start with MVP and build complexity through phases
### After Completion
1. **Use as Blueprint** - Feed the brief directly into create-module workflow for implementation
2. **Review with Stakeholders** - Validate assumptions and gather feedback before building
3. **Update as Needed** - Treat as living document that evolves with implementation learnings
4. **Reference During Development** - Use as north star for design decisions and scope management
## Troubleshooting
### Common Issues
**Issue**: Stuck on module concept or vision
- **Solution**: Use creative prompts provided in the workflow
- **Check**: Review existing modules for inspiration and patterns
**Issue**: Agent or workflow architecture too complex
- **Solution**: Focus on MVP first, plan enhancement phases for additional complexity
- **Check**: Validate each component against user scenarios
**Issue**: Technical requirements unclear
- **Solution**: Research similar modules and their implementation approaches
- **Check**: Consult with technical stakeholders early in planning
**Issue**: Scope creep during planning
- **Solution**: Use phased roadmap to defer non-essential features
- **Check**: Regularly validate against core user scenarios and success criteria
## Customization
To customize this workflow:
1. **Modify Template Structure** - Update template.md to add new sections or reorganize content
2. **Extend Creative Prompts** - Add domain-specific ideation techniques in instructions.md
3. **Add Planning Tools** - Integrate additional analysis frameworks or planning methodologies
4. **Customize Validation** - Enhance checklist.md with specific quality criteria for your context
## Version History
- **v1.0.0** - Initial release
- Comprehensive strategic module planning
- Multi-mode operation (Interactive, Express, YOLO)
- Creative vision and architecture design tools
- User journey mapping and validation
- Risk assessment and mitigation planning
## Support
For issues or questions:
- Review the workflow creation guide at `/_bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
- Study existing module examples in `/_bmad/` for patterns and inspiration
- Validate output using `checklist.md`
- Consult module structure guide at `create-module/module-structure.md`
---
_Part of the BMad Method v6 - BMB (Builder) Module_

116
src/modules/bmb/workflows-legacy/module-brief/checklist.md
View File

@ -1,116 +0,0 @@
# Module Brief Validation Checklist
## Core Identity
- [ ] Module code follows kebab-case convention
- [ ] Module name is clear and memorable
- [ ] Module category is identified
- [ ] Target users are clearly defined
- [ ] Unique value proposition is articulated
## Vision and Concept
- [ ] Problem being solved is clearly stated
- [ ] Solution approach is explained
- [ ] Module scope is well-defined
- [ ] Success criteria are measurable
## Agent Architecture
- [ ] At least one agent is defined
- [ ] Each agent has a clear role and purpose
- [ ] Agent personalities are defined (if using personality themes)
- [ ] Agent interactions are mapped (for multi-agent modules)
- [ ] Key commands for each agent are listed
## Workflow Ecosystem
- [ ] Core workflows (2-3) are identified
- [ ] Each workflow has clear purpose
- [ ] Workflow complexity is assessed
- [ ] Input/output for workflows is defined
- [ ] Workflow categories are logical
## User Experience
- [ ] Primary use case is documented
- [ ] User scenarios demonstrate value
- [ ] User journey is realistic
- [ ] Learning curve is considered
- [ ] User feedback mechanism planned
## Technical Planning
- [ ] Data requirements are identified
- [ ] Integration points are mapped
- [ ] Dependencies are listed
- [ ] Technical complexity is assessed
- [ ] Performance requirements stated
## Development Roadmap
- [ ] Phase 1 MVP is clearly scoped
- [ ] Phase 2 enhancements are outlined
- [ ] Phase 3 polish items listed
- [ ] Timeline estimates provided
- [ ] Deliverables are specific
## Risk Management
- [ ] Technical risks identified
- [ ] Usability risks considered
- [ ] Scope risks acknowledged
- [ ] Mitigation strategies provided
- [ ] Open questions documented
## Creative Elements (Optional)
- [ ] Personality theme is consistent (if used)
- [ ] Special features add value
- [ ] Module feels cohesive
- [ ] Fun elements don't compromise functionality
## Documentation Quality
- [ ] All sections have content (no empty placeholders)
- [ ] Writing is clear and concise
- [ ] Technical terms are explained
- [ ] Examples are provided where helpful
- [ ] Next steps are actionable
## Implementation Readiness
- [ ] Brief provides enough detail for create-module workflow
- [ ] Agent specifications sufficient for create-agent workflow
- [ ] Workflow descriptions ready for create-workflow
- [ ] Resource requirements are clear
- [ ] Success metrics are measurable
## Final Validation
- [ ] Module concept is viable
- [ ] Scope is achievable
- [ ] Value is clear
- [ ] Brief is complete
- [ ] Ready for development
## Issues Found
### Critical Issues
<!-- Must be fixed before proceeding to build -->
### Recommendations
<!-- Suggested improvements -->
### Nice-to-Haves
<!-- Optional enhancements -->
---
**Validation Complete:** ⬜ Yes / ⬜ With Issues / ⬜ Needs Revision
**Validated By:** {name}
**Date:** {date}

268
src/modules/bmb/workflows-legacy/module-brief/instructions.md
View File

@ -1,268 +0,0 @@
# Module Brief Instructions
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmb/workflows/module-brief/workflow.yaml</critical>
<critical>Communicate in {communication_language} throughout the module brief creation process</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<workflow>
<step n="1" goal="Setup and context gathering">
<action>Ask the user which mode they prefer:</action>
1. **Interactive Mode** - Work through each section collaboratively with detailed questions
2. **Express Mode** - Quick essential questions only
3. **YOLO Mode** (#yolo) - Generate complete draft based on minimal input
<action>Check for available inputs:</action>
- Brainstorming results from previous sessions
- Existing module ideas or notes
- Similar modules for inspiration
<action>If brainstorming results exist, offer to load and incorporate them</action>
</step>
<step n="2" goal="Module concept and vision">
Ask the user to describe their module idea. Probe for:
- What problem does this module solve?
- Who would use this module?
- What makes this module exciting or unique?
- Any inspiring examples or similar tools?
If they're stuck, offer creative prompts:
- "Imagine you're a [role], what tools would make your life easier?"
- "What repetitive tasks could be automated with agents?"
- "What domain expertise could be captured in workflows?"
<template-output>module_vision</template-output>
</step>
<step n="3" goal="Define module identity">
Based on the vision, work with user to define:
**Module Code** (kebab-case):
- Suggest 2-3 options based on their description
- Ensure it's memorable and descriptive
**Module Name** (friendly):
- Creative, engaging name that captures the essence
**Module Category:**
- Domain-Specific (legal, medical, finance)
- Creative (writing, gaming, music)
- Technical (devops, testing, architecture)
- Business (project management, marketing)
- Personal (productivity, learning)
**Personality Theme** (optional but fun!):
- Should the module have a consistent personality across agents?
- Star Trek crew? Fantasy party? Corporate team? Reality show cast?
<template-output>module_identity</template-output>
</step>
<step n="4" goal="Agent architecture planning">
<action>Help user envision their agent team</action>
For each agent, capture:
- **Role**: What's their specialty?
- **Personality**: How do they communicate? (reference communication styles)
- **Key Capabilities**: What can they do?
- **Signature Commands**: 2-3 main commands
Suggest agent archetypes based on module type:
- The Orchestrator (manages other agents)
- The Specialist (deep expertise)
- The Helper (utility functions)
- The Creator (generates content)
- The Analyzer (processes and evaluates)
<template-output>agent_architecture</template-output>
</step>
<step n="5" goal="Workflow ecosystem design">
<action>Map out the workflow landscape</action>
Categorize workflows:
**Core Workflows** (2-3 essential ones):
- The primary value-delivery workflows
- What users will use most often
**Feature Workflows** (3-5 specialized):
- Specific capabilities
- Advanced features
**Utility Workflows** (1-3 supporting):
- Setup, configuration
- Maintenance, cleanup
For each workflow, define:
- Purpose (one sentence)
- Input → Process → Output
- Complexity (simple/standard/complex)
<template-output>workflow_ecosystem</template-output>
</step>
<step n="6" goal="User journey and scenarios">
<action>Create usage scenarios to validate the design</action>
Write 2-3 user stories:
"As a [user type], I want to [goal], so that [outcome]"
Then walk through how they'd use the module:
1. They load [agent]
2. They run [command/workflow]
3. They get [result]
4. This helps them [achievement]
This validates the module makes sense end-to-end.
<template-output>user_scenarios</template-output>
</step>
<step n="7" goal="Technical and resource planning">
Assess technical requirements:
**Data Requirements:**
- What data/files does the module need?
- Any external APIs or services?
- Storage or state management needs?
**Integration Points:**
- Other BMAD modules it might use
- External tools or platforms
- Import/export formats
**Complexity Assessment:**
- Simple (standalone, no dependencies)
- Standard (some integrations, moderate complexity)
- Complex (multiple systems, advanced features)
<template-output>technical_planning</template-output>
</step>
<step n="8" goal="Success metrics and validation">
Define what success looks like:
**Module Success Criteria:**
- What indicates the module is working well?
- How will users measure value?
- What feedback mechanisms?
**Quality Standards:**
- Performance expectations
- Reliability requirements
- User experience goals
<template-output>success_metrics</template-output>
</step>
<step n="9" goal="Development roadmap">
Create a phased approach:
**Phase 1 - MVP (Minimum Viable Module):**
- 1 primary agent
- 2-3 core workflows
- Basic functionality
**Phase 2 - Enhancement:**
- Additional agents
- More workflows
- Refined features
**Phase 3 - Polish:**
- Advanced features
- Optimizations
- Nice-to-haves
<template-output>development_roadmap</template-output>
</step>
<step n="10" goal="Creative flourishes and special features" optional="true">
<action>If user wants to add special touches:</action>
**Easter Eggs:**
- Hidden commands or responses
- Fun interactions between agents
**Delighters:**
- Unexpected helpful features
- Personality quirks
- Creative responses
**Module Lore:**
- Backstory for agents
- Thematic elements
- Consistent universe
<template-output>creative_features</template-output>
</step>
<step n="11" goal="Risk assessment and mitigation">
Identify potential challenges:
**Technical Risks:**
- Complex integrations
- Performance concerns
- Dependency issues
**Usability Risks:**
- Learning curve
- Complexity creep
- User confusion
**Scope Risks:**
- Feature bloat
- Timeline expansion
- Resource constraints
For each risk, note mitigation strategy.
<template-output>risk_assessment</template-output>
</step>
<step n="12" goal="Final review and export readiness">
<action>Review all sections with {user_name}</action>
<action>Ensure module brief is ready for create-module workflow</action>
<ask>Would {user_name} like to:
1. Proceed directly to create-module workflow
2. Save and refine later
3. Generate additional planning documents
</ask>
<action>Inform {user_name} in {communication_language} that this brief can be fed directly into create-module workflow</action>
<template-output>final_brief</template-output>
</step>
</workflow>

275
src/modules/bmb/workflows-legacy/module-brief/template.md
View File

@ -1,275 +0,0 @@
# Module Brief: {{module_name}}
**Date:** {{date}}
**Author:** {{user_name}}
**Module Code:** {{module_code}}
**Status:** Ready for Development
---
## Executive Summary
{{module_vision}}
**Module Category:** {{module_category}}
**Complexity Level:** {{complexity_level}}
**Target Users:** {{target_users}}
---
## Module Identity
### Core Concept
{{module_identity}}
### Unique Value Proposition
What makes this module special:
{{unique_value}}
### Personality Theme
{{personality_theme}}
---
## Agent Architecture
{{agent_architecture}}
### Agent Roster
{{agent_roster}}
### Agent Interaction Model
How agents work together:
{{agent_interactions}}
---
## Workflow Ecosystem
{{workflow_ecosystem}}
### Core Workflows
Essential functionality that delivers primary value:
{{core_workflows}}
### Feature Workflows
Specialized capabilities that enhance the module:
{{feature_workflows}}
### Utility Workflows
Supporting operations and maintenance:
{{utility_workflows}}
---
## User Scenarios
### Primary Use Case
{{primary_scenario}}
### Secondary Use Cases
{{secondary_scenarios}}
### User Journey
Step-by-step walkthrough of typical usage:
{{user_journey}}
---
## Technical Planning
### Data Requirements
{{data_requirements}}
### Integration Points
{{integration_points}}
### Dependencies
{{dependencies}}
### Technical Complexity Assessment
{{technical_planning}}
---
## Success Metrics
### Module Success Criteria
How we'll know the module is successful:
{{success_criteria}}
### Quality Standards
{{quality_standards}}
### Performance Targets
{{performance_targets}}
---
## Development Roadmap
### Phase 1: MVP (Minimum Viable Module)
**Timeline:** {{phase1_timeline}}
{{phase1_components}}
**Deliverables:**
{{phase1_deliverables}}
### Phase 2: Enhancement
**Timeline:** {{phase2_timeline}}
{{phase2_components}}
**Deliverables:**
{{phase2_deliverables}}
### Phase 3: Polish and Optimization
**Timeline:** {{phase3_timeline}}
{{phase3_components}}
**Deliverables:**
{{phase3_deliverables}}
---
## Creative Features
### Special Touches
{{creative_features}}
### Easter Eggs and Delighters
{{easter_eggs}}
### Module Lore and Theming
{{module_lore}}
---
## Risk Assessment
### Technical Risks
{{technical_risks}}
### Usability Risks
{{usability_risks}}
### Scope Risks
{{scope_risks}}
### Mitigation Strategies
{{risk_mitigation}}
---
## Implementation Notes
### Priority Order
1. {{priority_1}}
2. {{priority_2}}
3. {{priority_3}}
### Key Design Decisions
{{design_decisions}}
### Open Questions
{{open_questions}}
---
## Resources and References
### Inspiration Sources
{{inspiration_sources}}
### Similar Modules
{{similar_modules}}
### Technical References
{{technical_references}}
---
## Appendices
### A. Detailed Agent Specifications
{{detailed_agent_specs}}
### B. Workflow Detailed Designs
{{detailed_workflow_specs}}
### C. Data Structures and Schemas
{{data_schemas}}
### D. Integration Specifications
{{integration_specs}}
---
## Next Steps
1. **Review this brief** with stakeholders
2. **Run create-module workflow** using this brief as input
3. **Create first agent** using create-agent workflow
4. **Develop initial workflows** using create-workflow
5. **Test MVP** with target users
---
_This Module Brief is ready to be fed directly into the create-module workflow for scaffolding and implementation._
**Module Viability Score:** {{viability_score}}/10
**Estimated Development Effort:** {{effort_estimate}}
**Confidence Level:** {{confidence_level}}
---
**Approval for Development:**
- [ ] Concept Approved
- [ ] Scope Defined
- [ ] Resources Available
- [ ] Ready to Build
---
_Generated on {{date}} by {{user_name}} using the BMAD Method Module Brief workflow_

36
src/modules/bmb/workflows-legacy/module-brief/workflow.yaml
View File

@ -1,36 +0,0 @@
# Module Brief Workflow Configuration
name: module-brief
description: "Create a comprehensive Module Brief that serves as the blueprint for building new BMAD modules using strategic analysis and creative vision"
author: "BMad Builder"
# Critical variables
config_source: "{project-root}/_bmad/bmb/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
date: system-generated
# Reference examples and documentation
existing_modules_dir: "{project-root}/_bmad/"
module_structure_guide: "{project-root}/_bmad/bmb/workflows/create-module/module-structure.md"
# Optional user inputs - discovered if they exist
input_file_patterns:
brainstorming:
description: "Brainstorming session outputs (optional)"
whole: "{output_folder}/brainstorming-*.md"
load_strategy: "FULL_LOAD"
# Module path and component files
installed_path: "{project-root}/_bmad/bmb/workflows/module-brief"
template: "{installed_path}/template.md"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Output configuration
default_output_file: "{output_folder}/module-brief-{{module_code}}-{{date}}.md"
standalone: true
# Web bundle configuration
web_bundle: false # BMB workflows run locally in BMAD-METHOD project

4
src/modules/bmb/workflows/agent/data/critical-actions.md
View File

@ -31,8 +31,8 @@ critical_actions:
**CRITICAL Path Format:**
- `{project-root}` = literal text (not replaced)
- Sidecar copied to `_memory/` at build time
- Use `{project-root}/_bmad/_memory/{sidecar-folder}/` format
- Sidecar created next to agent.yaml during BUILD, then copied to `_memory/` during BMAD INSTALLATION
- Use `{project-root}/_bmad/_memory/{sidecar-folder}/` format for RUNTIME paths in agent YAML
---

2
src/modules/bmb/workflows/agent/data/expert-agent-architecture.md
View File

@ -39,7 +39,7 @@ Agents with a sidecar folder for persistent memory, custom workflows, and restri
## CRITICAL: Sidecar Path Format
At build/install, sidecar is copied to `{project-root}/_bmad/_memory/{sidecar-folder}/`
During BMAD INSTALLATION, sidecar folder is copied from the agent location to `{project-root}/_bmad/_memory/{sidecar-folder}/`
**ALL agent YAML references MUST use:**

3
src/modules/bmb/workflows/agent/data/expert-agent-validation.md
View File

@ -7,7 +7,8 @@ Validate Expert agents meet BMAD quality standards.
## YAML Structure
- [ ] YAML parses without errors
- [ ] `agent.metadata` includes: `id`, `name`, `title`, `icon`, `module`
- [ ] `agent.metadata` includes: `id`, `name`, `title`, `icon`, `module`, `hasSidecar`
- [ ] `agent.metadata.hasSidecar` is `true` (Expert agents have sidecars)
- [ ] `agent.metadata.module` is `stand-alone` or module code (`bmm`, `cis`, `bmgd`, etc.)
- [ ] `agent.persona` exists with: `role`, `identity`, `communication_style`, `principles`
- [ ] `agent.critical_actions` exists (MANDATORY for Expert)

2
src/modules/bmb/workflows/agent/data/module-agent-validation.md
View File

@ -34,11 +34,13 @@ Validate Module agents meet BMAD quality standards.
### Module Agent Can Be Simple OR Expert
**If Simple-structure Module Agent:**
- [ ] `agent.metadata.hasSidecar` is `false` (no sidecar)
- [ ] Single .agent.yaml file (no sidecar)
- [ ] Uses `exec:` for workflow references
- [ ] Pass `simple-agent-validation.md` first
**If Expert-structure Module Agent:**
- [ ] `agent.metadata.hasSidecar` is `true` (has sidecar)
- [ ] Has sidecar folder
- [ ] Uses `exec:` for workflow references
- [ ] Sidecar paths use `{project-root}/_bmad/_memory/{sidecar-folder}/` format

1
src/modules/bmb/workflows/agent/data/reference/expert-examples/journal-keeper/journal-keeper.agent.yaml
View File

@ -5,6 +5,7 @@ agent:
title: "Personal Journal Companion"
icon: "📔"
module: stand-alone
hasSidecar: false
persona:
role: "Thoughtful Journal Companion with Pattern Recognition"

1
src/modules/bmb/workflows/agent/data/reference/module-examples/architect.agent.yaml
View File

@ -7,6 +7,7 @@ agent:
title: Architect
icon: 🏗️
module: bmm
hasSidecar: false
persona:
role: System Architect + Technical Design Leader

1
src/modules/bmb/workflows/agent/data/reference/module-examples/security-engineer.agent.yaml
View File

@ -15,6 +15,7 @@ agent:
title: "Security Engineer"
icon: "🔐"
module: "bmm"
hasSidecar: false
persona:
role: Application Security Specialist + Threat Modeling Expert

1
src/modules/bmb/workflows/agent/data/reference/module-examples/trend-analyst.agent.yaml
View File

@ -15,6 +15,7 @@ agent:
title: "Trend Analyst"
icon: "📈"
module: "cis"
hasSidecar: false
persona:
role: Cultural + Market Trend Intelligence Expert

1
src/modules/bmb/workflows/agent/data/reference/simple-examples/commit-poet.agent.yaml
View File

@ -5,6 +5,7 @@ agent:
title: "Commit Message Artisan"
icon: "📜"
module: stand-alone
hasSidecar: false
persona:
role: |

3
src/modules/bmb/workflows/agent/data/simple-agent-validation.md
View File

@ -7,7 +7,8 @@ Validate Simple agents meet BMAD quality standards.
## YAML Structure
- [ ] YAML parses without errors
- [ ] `agent.metadata` includes: `id`, `name`, `title`, `icon`, `module`
- [ ] `agent.metadata` includes: `id`, `name`, `title`, `icon`, `module`, `hasSidecar`
- [ ] `agent.metadata.hasSidecar` is `false` (Simple agents don't have sidecars)
- [ ] `agent.metadata.module` is `stand-alone` or module code (`bmm`, `cis`, `bmgd`, etc.)
- [ ] `agent.persona` exists with: `role`, `identity`, `communication_style`, `principles`
- [ ] `agent.menu` exists with at least one item

4
src/modules/bmb/workflows/agent/steps-c/step-01-brainstorm.md
View File

@ -46,7 +46,9 @@ Optional creative exploration to generate agent ideas through structured brainst
- Limits: No mandatory brainstorming, no pressure tactics
- Dependencies: User choice to participate or skip brainstorming
## Sequence of Instructions (Do not deviate, skip, or optimize)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Present Brainstorming Opportunity

4
src/modules/bmb/workflows/agent/steps-c/step-02-discovery.md
View File

@ -108,7 +108,9 @@ After documentation, present menu:
- Clear articulation of value proposition
- Comprehensive capability mapping
# EXECUTION SEQUENCE
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
1. **Load Previous Context**
- Check for brainstormContext file

10
src/modules/bmb/workflows/agent/steps-c/step-03-type-metadata.md
View File

@ -1,5 +1,5 @@
---
name: 'step-02-type-metadata'
name: 'step-03-type-metadata'
description: 'Determine agent type and define metadata'
# File References
@ -27,7 +27,7 @@ Determine the agent's classification (Simple/Expert/Module) and define all manda
# MANDATORY EXECUTION RULES
## Universal Rules
- ALWAYS use `{agent-language}` for all conversational text
- ALWAYS use `{communication_language}` for all conversational text
- MAINTAIN step boundaries - complete THIS step only
- DOCUMENT all decisions to agent plan file
- HONOR user's creative control throughout
@ -125,7 +125,9 @@ Present structured options:
---
# INSTRUCTION SEQUENCE
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
## 1. Load Documentation
Read and internalize:
@ -134,7 +136,7 @@ Read and internalize:
- Keep examples accessible for reference
## 2. Purpose Discovery Conversation
Engage user with questions in `{agent-language}`:
Engage user with questions in `{communication_language}`:
- "What is the primary function this agent will perform?"
- "How complex are the tasks this agent will handle?"
- "Will this agent need to manage workflows or other agents?"

6
src/modules/bmb/workflows/agent/steps-c/step-04-persona.md
View File

@ -1,5 +1,5 @@
---
name: 'step-03-persona'
name: 'step-04-persona'
description: 'Shape the agent personality through four-field persona system'
# File References
@ -156,7 +156,9 @@ principles:
- Workflow steps (belongs in orchestration)
- Data structures (belongs in implementation)
# EXECUTION SEQUENCE
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
1. **LOAD** personaProperties.md and principlesCrafting.md
2. **EXPLAIN** four-field system with clear examples

6
src/modules/bmb/workflows/agent/steps-c/step-05-commands-menu.md
View File

@ -1,5 +1,5 @@
---
name: 'step-04-commands-menu'
name: 'step-05-commands-menu'
description: 'Build capabilities and command structure'
# File References
@ -121,7 +121,9 @@ menu:
- **User-facing perspective** - triggers should feel natural
- **Capability alignment** - every command maps to a capability
# EXECUTION SEQUENCE
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
1. Load agent-menu-patterns.md to understand structure
2. Review capabilities from agent-plan step 3

18
src/modules/bmb/workflows/agent/steps-c/step-06-activation.md
View File

@ -1,5 +1,5 @@
---
name: 'step-05-activation'
name: 'step-06-activation'
description: 'Plan activation behavior and route to build'
# File References
@ -30,7 +30,7 @@ Define activation behavior through critical_actions and route to the appropriate
- These are non-negotiable prerequisites
2. **MUST Determine Route Before Activation Discussion**
- Check hasSidecar from plan metadata
- Check `module` and `hasSidecar` from plan metadata
- Determine destination build step FIRST
- Inform user of routing decision
@ -41,10 +41,12 @@ Define activation behavior through critical_actions and route to the appropriate
4. **MUST Follow Routing Logic Exactly**
```yaml
# Route determination based on hasSidecar and module
hasSidecar: false → step-06-build-simple.md
hasSidecar: true + module: "stand-alone" → step-06-build-expert.md
hasSidecar: true + module: ≠ "stand-alone" → step-06-build-module.md
# Route determination based on module and hasSidecar
# Module agents: any module value other than "stand-alone"
module ≠ "stand-alone" → step-07c-build-module.md
# Stand-alone agents: determined by hasSidecar
module = "stand-alone" + hasSidecar: true → step-07b-build-expert.md
module = "stand-alone" + hasSidecar: false → step-07a-build-simple.md
```
5. **NEVER Skip Documentation**
@ -129,7 +131,9 @@ routing:
- Expert agents: Sidecar + stand-alone module
- Module agents: Sidecar + parent module integration
# EXECUTION SEQUENCE
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
## 1. Load Reference Documents
```bash

12
src/modules/bmb/workflows/agent/steps-c/step-07a-build-simple.md
View File

@ -1,9 +1,9 @@
---
name: 'step-06-build-simple'
name: 'step-07a-build-simple'
description: 'Generate Simple agent YAML from plan'
# File References
nextStepFile: './step-08a-plan-traceability.md'
nextStepFile: './step-08-celebrate.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}.agent.yaml'
@ -60,7 +60,9 @@ Assemble the agent plan content into a Simple agent YAML configuration using the
- Template placeholders (replace with actual content)
- Comments or notes in final YAML
## EXECUTION SEQUENCE
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Template and Architecture Files
@ -141,7 +143,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
### 6. Route Based on User Choice
**If user chooses "one-at-a-time":**
- Proceed to `nextStepFile` (step-07a-plan-traceability.md)
- Proceed to `nextStepFile` (step-08-celebrate.md)
- Continue through each validation step sequentially
- Allow review between each validation
@ -153,7 +155,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
## SUCCESS METRICS

32
src/modules/bmb/workflows/agent/steps-c/step-07b-build-expert.md
View File

@ -3,7 +3,7 @@ name: 'step-06-build-expert'
description: 'Generate Expert agent YAML with sidecar from plan'
# File References
nextStepFile: './step-08a-plan-traceability.md'
nextStepFile: './step-08-celebrate.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
@ -21,12 +21,12 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# STEP GOAL
Assemble the agent plan content into a complete Expert agent YAML file with sidecar folder structure. Expert agents require persistent memory storage for specialized operations, accessed via `{project-root}/_bmad/_memory/{sidecar-folder}/` paths in critical_actions.
Assemble the agent plan content into a complete Expert agent YAML file with sidecar folder structure. Expert agents require persistent memory storage, so the build creates a sidecar folder next to the agent.yaml (which gets installed to `_bmad/_memory/` during BMAD installation).
## MANDATORY EXECUTION RULES
1. **EXPERT AGENT = SIDECAR REQUIRED**: Every Expert agent MUST have a sidecar folder created under `_bmad/_memory/`
2. **CRITICAL_ACTIONS FORMAT**: All critical_actions MUST use `{project-root}/_bmad/_memory/{sidecar-folder}/` for file operations
1. **EXPERT AGENT = SIDECAR REQUIRED**: Every Expert agent MUST have a sidecar folder created next to agent.yaml (build location), which will be installed to `_bmad/_memory/` during BMAD installation
2. **CRITICAL_ACTIONS FORMAT**: All critical_actions MUST use `{project-root}/_bmad/_memory/{sidecar-folder}/` for file operations (runtime path)
3. **TEMPLATE COMPLIANCE**: Follow expert-agent-template.md structure exactly
4. **YAML VALIDATION**: Ensure valid YAML syntax with proper indentation (2-space)
5. **EXISTING CHECK**: If agentYamlOutput exists, ask user before overwriting
@ -55,8 +55,6 @@ Using expertTemplate as structure:
```yaml
name: '{agent-name}'
description: '{short-description}'
type: 'expert'
version: '1.0.0'
author:
name: '{author}'
@ -109,19 +107,20 @@ metadata:
### Phase 4: Create Sidecar Structure
1. **Create Sidecar Directory**:
- Path: `{project-root}/_bmad/_memory/{sidecar-folder}/`
1. **Create Sidecar Directory** (NEXT TO agent.yaml):
- Path: `{agentBuildOutput}/{agent-name}-sidecar/`
- Use `mkdir -p` to create full path
- Note: This folder gets installed to `_bmad/_memory/` during BMAD installation
2. **Create Starter Files** (if specified in critical_actions):
```bash
touch _bmad/_memory/{sidecar-folder}/{file1}.md
touch _bmad/_memory/{sidecar-folder}/{file2}.md
touch {agentBuildOutput}/{agent-name}-sidecar/{file1}.md
touch {agentBuildOutput}/{agent-name}-sidecar/{file2}.md
```
3. **Add README to Sidecar**:
```markdown
# {sidecar-folder} Memory
# {sidecar-folder} Sidecar
This folder stores persistent memory for the **{agent-name}** Expert agent.
@ -132,8 +131,9 @@ metadata:
- {file1}.md: {description}
- {file2}.md: {description}
## Access Pattern
Agent accesses these files via: `{project-root}/_bmad/_memory/{sidecar-folder}/{filename}.md`
## Runtime Access
After BMAD installation, this folder will be accessible at:
`{project-root}/_bmad/_memory/{sidecar-folder}/{filename}.md`
```
### Phase 5: Write Agent YAML
@ -171,11 +171,11 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
This step produces TWO artifacts:
1. **Agent YAML**: Complete expert agent definition at `{agentYamlOutput}`
2. **Sidecar Structure**: Folder and files at `{project-root}/_bmad/_memory/{sidecar-folder}/`
2. **Sidecar Structure**: Folder and files at `{agentBuildOutput}/{agent-name}-sidecar/` (build location, installs to `_bmad/_memory/` during BMAD installation)
Both must exist before proceeding to validation.
@ -184,7 +184,7 @@ Both must exist before proceeding to validation.
✅ Agent YAML file created at expected location
✅ Valid YAML syntax (no parse errors)
✅ All template fields populated
✅ Sidecar folder created under `_bmad/_memory/`
✅ Sidecar folder created at `{agentBuildOutput}/{agent-name}-sidecar/` (build location)
✅ Sidecar folder contains starter files from critical_actions
✅ critical_actions reference `{project-root}/_bmad/_memory/{sidecar-folder}/` paths
✅ metadata.sidecar-folder populated

4
src/modules/bmb/workflows/agent/steps-c/step-07c-build-module.md
View File

@ -3,7 +3,7 @@ name: 'step-06-build-module'
description: 'Generate Module agent YAML from plan'
# File References
nextStepFile: './step-08a-plan-traceability.md'
nextStepFile: './step-08-celebrate.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
@ -205,7 +205,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
# CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
**THIS STEP IS COMPLETE WHEN:**
1. Module agent YAML file exists at agentYamlOutput path

23
src/modules/bmb/workflows/agent/steps-c/step-09-celebrate.md → src/modules/bmb/workflows/agent/steps-c/step-08-celebrate.md
View File

@ -1,9 +1,9 @@
---
name: 'step-09-celebrate'
name: 'step-08-celebrate'
description: 'Celebrate completion and guide next steps for using the agent'
# File References
thisStepFile: ./step-09-celebrate.md
thisStepFile: ./step-08-celebrate.md
workflowFile: ../workflow.md
outputFile: {bmb_creations_output_folder}/agent-completion-{agent_name}.md
@ -11,9 +11,10 @@ outputFile: {bmb_creations_output_folder}/agent-completion-{agent_name}.md
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
installationDocs: 'https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/modules/bmb-bmad-builder/custom-content-installation.md#standalone-content-agents-workflows-tasks-tools-templates-prompts'
validationWorkflow: '{project-root}/src/modules/bmb/workflows/agent/steps-v/v-01-load-review.md'
---
# Step 9: Celebration and Installation Guidance
# Step 8: Celebration and Installation Guidance
## STEP GOAL:
@ -59,7 +60,9 @@ Celebrate the successful agent creation, recap the agent's capabilities, provide
- Limits: No agent modifications, only installation guidance and celebration
- Dependencies: Complete agent ready for installation
## Sequence of Instructions (Do not deviate, skip, or optimize)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change. (Do not deviate, skip, or optimize)
### 1. Grand Celebration
@ -196,25 +199,27 @@ Save this content to `{outputFile}` for reference.
### 7. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [X] Exit Workflow"
Display: "**✅ Agent Build Complete! Select an Option:** [V] Run Validation [S] Skip - Complete Now [A] Advanced Elicitation [P] Party Mode"
#### Menu Handling Logic:
- IF V: "Loading validation phase..." → Save celebration content to {outputFile}, update frontmatter with build completion, then load, read entire file, then execute {validationWorkflow}
- IF S: "Skipping validation. Completing workflow..." → Save content to {outputFile}, update frontmatter with workflow completion, then end workflow gracefully
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF X: Save content to {outputFile}, update frontmatter with workflow completion, then end workflow gracefully
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY complete workflow when user selects 'X'
- After other menu items execution, return to this menu
- User can choose validation (V), skip to complete (S), or use advanced elicitation (A) or party mode (P)
- After other menu items execution (A/P), return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [X exit option] is selected and [workflow completion marked in frontmatter], will the workflow end gracefully with agent ready for installation.
ONLY WHEN [S skip option] is selected and [workflow completion marked in frontmatter], will the workflow end gracefully with agent ready for installation.
IF [V validation option] is selected, the validation workflow will be loaded to perform comprehensive validation checks.
---

203
src/modules/bmb/workflows/agent/steps-c/step-08a-plan-traceability.md
View File

@ -1,203 +0,0 @@
---
name: 'step-07a-plan-traceability'
description: 'Verify build matches original plan'
# File References
nextStepFile: './step-08b-metadata-validation.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Verify that the built agent YAML file contains all elements specified in the original agent plan. This step ensures plan traceability - confirming that what we planned is what we actually built.
# MANDATORY EXECUTION RULES
- MUST load both agentPlan and builtYaml files before comparison
- MUST compare ALL planned elements against built implementation
- MUST report specific missing items, not just "something is missing"
- MUST offer fix option before proceeding to next validation
- MUST handle missing files gracefully (report clearly, don't crash)
- MUST respect YOLO mode behavior (part of combined validation report)
# EXECUTION PROTOCOLS
## File Loading Protocol
1. Load agentPlan from `{bmb_creations_output_folder}/agent-plan-{agent_name}.md`
2. Load builtYaml from `{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml`
3. If either file is missing, report the specific missing file and stop comparison
4. Use Read tool to access both files with absolute paths
## Comparison Protocol
Compare the following categories systematically:
### 1. Metadata Comparison
- Agent name
- Description
- Version
- Author/creator information
- Location/module path
- Language settings (if specified in plan)
### 2. Persona Field Comparison
For each field in persona section:
- Check presence in built YAML
- Verify field content matches planned intent
- Note any significant deviations (minor wording differences ok)
### 3. Commands Comparison
- Verify all planned commands are present
- Check command names match
- Verify command descriptions are present
- Confirm critical actions are referenced
### 4. Critical Actions Comparison
- Verify all planned critical_actions are present
- Check action names match exactly
- Verify action descriptions are present
- Confirm each action has required fields
### 5. Additional Elements
- Dependencies (if planned)
- Configuration (if planned)
- Installation instructions (if planned)
## Reporting Protocol
Present findings in clear, structured format:
```
PLAN TRACEABILITY REPORT
========================
Agent: {agent_name}
Plan File: {path to agent plan}
Build File: {path to built YAML}
COMPARISON RESULTS:
-------------------
✅ Metadata: All present / Missing: {list}
✅ Persona Fields: All present / Missing: {list}
✅ Commands: All present / Missing: {list}
✅ Critical Actions: All present / Missing: {list}
✅ Other Elements: All present / Missing: {list}
OVERALL STATUS: [PASS / FAIL]
```
If ANY elements are missing:
- List each missing element with category
- Provide specific location reference (what was planned)
- Ask if user wants to fix items or continue anyway
## Menu Protocol
### 8. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} for identified missing elements, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
If YOLO mode:
- Include this report in combined validation report
- Auto-select [C] Continue if all elements present
- Auto-select [F] Fix if missing critical elements (name, commands)
- Flag non-critical missing items in summary
# CONTEXT BOUNDARIES
- ONLY compare plan vs build - do NOT evaluate quality or correctness
- Do NOT suggest improvements or changes beyond planned elements
- Do NOT re-open persona/commands discovery - this is verification only
- Fix option should return to step-06-build, not earlier steps
- If plan file is ambiguous, note ambiguity but use reasonable interpretation
# SEQUENCE
## 1. Load Required Files
```yaml
action: read
target:
- agentPlan
- builtYaml
on_failure: report which file is missing and suggest resolution
```
## 2. Perform Structured Comparison
```yaml
action: compare
categories:
- metadata
- persona_fields
- commands
- critical_actions
- other_elements
method: systematic category-by-category check
```
## 3. Generate Comparison Report
```yaml
action: report
format: structured pass/fail with specific missing items
output: console display + optional save to validation log
```
## 4. Present Menu Options
```yaml
action: menu
options:
- F: Fix missing items
- C: Continue to metadata validation
- V: View detailed comparison (optional)
default: C if pass, F if fail
```
## 5. Handle User Choice
- **[F] Fix Findings**: Apply auto-fixes to {builtYaml} for identified missing elements, then re-present menu
- **[C] Continue**: Proceed to step-07b-metadata-validation
- **[A] Advanced Elicitation**: Execute advanced elicitation workflow, then re-present menu
- **[P] Party Mode**: Execute party mode workflow, then re-present menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [metadata validation].
# SUCCESS/FAILURE METRICS
## Success Criteria
- All planned elements present in built YAML: **COMPLETE PASS**
- Minor deviations (wording, formatting) but all core elements present: **PASS**
- Missing elements identified and user chooses to continue: **PASS WITH NOTED DEFICIENCIES**
## Failure Criteria
- Unable to load plan or build file: **BLOCKING FAILURE**
- Critical elements missing (name, commands, or critical_actions): **FAIL**
- Comparison cannot be completed due to file corruption: **BLOCKING FAILURE**
## Next Step Triggers
- **PASS → step-07b-metadata-validation**
- **PASS WITH DEFICIENCIES → step-07b-metadata-validation** (user choice)
- **FAIL → step-06-build** (with specific fix instructions)
- **BLOCKING FAILURE → STOP** (resolve file access issues first)
## YOLO Mode Behavior
- Auto-fix missing critical elements by returning to build step
- Log non-critical missing items for review but continue validation
- Include traceability report in final YOLO summary
- Do NOT stop for user confirmation unless plan file is completely missing

135
src/modules/bmb/workflows/agent/steps-c/step-08b-metadata-validation.md
View File

@ -1,135 +0,0 @@
---
name: 'step-07b-metadata-validation'
description: 'Validate agent metadata properties'
# File References
nextStepFile: './step-08c-persona-validation.md'
agentMetadata: ../data/agent-metadata.md
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Validate that the agent's metadata properties (name, description, version, tags, category, etc.) are properly formatted, complete, and follow BMAD standards.
## MANDATORY EXECUTION RULES
- **NEVER skip validation checks** - All metadata fields must be verified
- **ALWAYS load both reference documents** - agentMetadata.md AND the builtYaml
- **NEVER modify files without user approval** - Report findings first, await menu selection
- **ALWAYS use absolute paths** when referencing files
- **CRITICAL:** This is a validation step, not an editing step
## EXECUTION PROTOCOLS
### Protocol 1: Load and Compare
1. Read the metadata validation reference from `{agentMetadata}`
2. Read the built agent YAML from `{builtYaml}`
3. Extract the metadata section from the builtYaml
4. Compare actual metadata against validation rules
### Protocol 2: Validation Checks
Perform these checks systematically:
1. **Required Fields Existence**
- [ ] name: Present and non-empty
- [ ] description: Present and non-empty
- [ ] version: Present and follows semantic versioning (X.Y.Z)
- [ ] category: Present and matches valid category
- [ ] tags: Present as array, not empty
2. **Format Validation**
- [ ] name: Uses kebab-case, no spaces
- [ ] description: 50-200 characters (unless intentionally brief)
- [ ] version: Follows semver pattern (e.g., 1.0.0)
- [ ] tags: Array of lowercase strings with hyphens
- [ ] category: Matches one of the allowed categories
3. **Content Quality**
- [ ] description: Clear and concise, explains what the agent does
- [ ] tags: Relevant to agent's purpose (3-7 tags recommended)
- [ ] category: Most appropriate classification
4. **Standards Compliance**
- [ ] No prohibited characters in fields
- [ ] No redundant or conflicting information
- [ ] Consistent formatting with other agents
### Protocol 3: Report Findings
Organize your report into three sections:
**PASSING CHECKS** (List what passed)
```
✓ Required fields present
✓ Version format valid (1.0.0)
✓ Name follows kebab-case convention
```
**WARNINGS** (Non-blocking issues)
```
⚠ Description is brief (45 chars, recommended 50-200)
⚠ Only 2 tags provided, 3-7 recommended
```
**FAILURES** (Blocking issues that must be fixed)
```
✗ Missing required field: version
✗ Invalid version format: "v1.0" (should be "1.0.0")
✗ Category "custom-type" not in allowed list
```
### Protocol 4: Menu System
#### 5. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CONTEXT BOUNDARIES
**IN SCOPE:**
- Metadata section of agent.yaml (name, description, version, tags, category, author, license, etc.)
- Referencing the agentMetadata.md validation rules
- Comparing against BMAD standards
**OUT OF SCOPE:**
- Persona fields (handled in step-07c)
- Menu items (handled in step-07d)
- System architecture (handled in step-07e)
- Capability implementation (handled in step-07f)
**DO NOT:**
- Validate persona properties in this step
- Suggest major feature additions
- Question the agent's core purpose
- Modify fields beyond metadata
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [persona validation].
## SUCCESS METRICS
✓ **Complete Success:** All checks pass, no failures, warnings are optional
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
✓ **Failure:** Blocking failures remain when user selects [C]
**CRITICAL:** Never proceed to next step if blocking failures exist and user hasn't acknowledged them.

161
src/modules/bmb/workflows/agent/steps-c/step-08c-persona-validation.md
View File

@ -1,161 +0,0 @@
---
name: 'step-07c-persona-validation'
description: 'Validate persona fields and principles'
# File References
nextStepFile: './step-08d-menu-validation.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Validate that the agent's persona (role, tone, expertise, principles, constraints) is well-defined, consistent, and aligned with its purpose.
## MANDATORY EXECUTION RULES
- **NEVER skip validation checks** - All persona fields must be verified
- **ALWAYS load both reference documents** - personaProperties.md AND principlesCrafting.md
- **NEVER modify files without user approval** - Report findings first, await menu selection
- **ALWAYS use absolute paths** when referencing files
- **CRITICAL:** This is a validation step, not an editing step
## EXECUTION PROTOCOLS
### Protocol 1: Load and Compare
1. Read the persona validation reference from `{personaProperties}`
2. Read the principles crafting guide from `{principlesCrafting}`
3. Read the built agent YAML from `{builtYaml}`
4. Extract the persona section from the builtYaml
5. Compare actual persona against validation rules
### Protocol 2: Validation Checks
Perform these checks systematically:
1. **Required Fields Existence**
- [ ] role: Present, clear, and specific
- [ ] tone: Present and appropriate to role
- [ ] expertise: Present and relevant to agent's purpose
- [ ] principles: Present as array, not empty (if applicable)
- [ ] constraints: Present as array, not empty (if applicable)
2. **Content Quality - Role**
- [ ] Role is specific (not generic like "assistant")
- [ ] Role aligns with agent's purpose and menu items
- [ ] Role is achievable within LLM capabilities
- [ ] Role scope is appropriate (not too broad/narrow)
3. **Content Quality - Tone**
- [ ] Tone is clearly defined (professional, friendly, authoritative, etc.)
- [ ] Tone matches the role and target users
- [ ] Tone is consistent throughout the definition
- [ ] Tone examples or guidance provided if nuanced
4. **Content Quality - Expertise**
- [ ] Expertise areas are relevant to role
- [ ] Expertise claims are realistic for LLM
- [ ] Expertise domains are specific (not just "knowledgeable")
- [ ] Expertise supports the menu capabilities
5. **Content Quality - Principles**
- [ ] Principles are actionable (not vague platitudes)
- [ ] Principles guide behavior and decisions
- [ ] Principles are consistent with role
- [ ] 3-7 principles recommended (not overwhelming)
- [ ] Each principle is clear and specific
6. **Content Quality - Constraints**
- [ ] Constraints define boundaries clearly
- [ ] Constraints are enforceable (measurable/observable)
- [ ] Constraints prevent undesirable behaviors
- [ ] Constraints don't contradict principles
7. **Consistency Checks**
- [ ] Role, tone, expertise, principles all align
- [ ] No contradictions between principles and constraints
- [ ] Persona supports the menu items defined
- [ ] Language and terminology consistent
### Protocol 3: Report Findings
Organize your report into three sections:
**PASSING CHECKS** (List what passed)
```
✓ Role is specific and well-defined
✓ Tone clearly articulated and appropriate
✓ Expertise aligns with agent purpose
✓ Principles are actionable and clear
```
**WARNINGS** (Non-blocking issues)
```
⚠ Only 2 principles provided, 3-7 recommended for richer guidance
⚠ No constraints defined - consider adding boundaries
⚠ Expertise areas are broad, could be more specific
```
**FAILURES** (Blocking issues that must be fixed)
```
✗ Role is generic ("assistant") - needs specificity
✗ Tone undefined - creates inconsistent behavior
✗ Principles are vague ("be helpful" - not actionable)
✗ Contradiction: Principle says "be creative", constraint says "follow strict rules"
```
### Protocol 4: Menu System
#### 5. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CONTEXT BOUNDARIES
**IN SCOPE:**
- Persona section of agent.yaml (role, tone, expertise, principles, constraints)
- Referencing personaProperties.md and principlesCrafting.md
- Evaluating persona clarity, specificity, and consistency
- Checking alignment between persona elements
**OUT OF SCOPE:**
- Metadata fields (handled in step-07b)
- Menu items (handled in step-07d)
- System architecture (handled in step-07e)
- Technical implementation details
**DO NOT:**
- Validate metadata properties in this step
- Question the agent's core purpose (that's for earlier steps)
- Suggest additional menu items
- Modify fields beyond persona
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [menu validation].
## SUCCESS METRICS
✓ **Complete Success:** All checks pass, persona is well-defined and consistent
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
✓ **Failure:** Blocking failures remain when user selects [C]
**CRITICAL:** A weak or generic persona is a blocking issue that should be fixed before proceeding.

158
src/modules/bmb/workflows/agent/steps-c/step-08d-menu-validation.md
View File

@ -1,158 +0,0 @@
---
name: 'step-07d-menu-validation'
description: 'Validate menu items and patterns'
# File References
nextStepFile: './step-08e-structure-validation.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Validate that the agent's menu (commands/tools) follows BMAD patterns, is well-structured, properly documented, and aligns with the agent's persona and purpose.
## MANDATORY EXECUTION RULES
- **NEVER skip validation checks** - All menu items must be verified
- **ALWAYS load the reference document** - agentMenuPatterns.md
- **NEVER modify files without user approval** - Report findings first, await menu selection
- **ALWAYS use absolute paths** when referencing files
- **CRITICAL:** This is a validation step, not an editing step
## EXECUTION PROTOCOLS
### Protocol 1: Load and Compare
1. Read the menu patterns reference from `{agentMenuPatterns}`
2. Read the built agent YAML from `{builtYaml}`
3. Extract the menu/commands section from the builtYaml
4. Compare actual menu against validation rules
### Protocol 2: Validation Checks
Perform these checks systematically:
1. **Menu Structure**
- [ ] Menu section exists and is properly formatted
- [ ] At least one menu item defined (unless intentionally tool-less)
- [ ] Menu items follow proper YAML structure
- [ ] Each item has required fields (name, description, pattern)
2. **Menu Item Requirements**
For each menu item:
- [ ] name: Present, unique, uses kebab-case
- [ ] description: Clear and concise
- [ ] pattern: Valid regex pattern or tool reference
- [ ] scope: Appropriate scope defined (if applicable)
3. **Pattern Quality**
- [ ] Patterns are valid and testable
- [ ] Patterns are specific enough to match intended inputs
- [ ] Patterns are not overly restrictive
- [ ] Patterns use appropriate regex syntax
4. **Description Quality**
- [ ] Each item has clear description
- [ ] Descriptions explain what the item does
- [ ] Descriptions are consistent in style
- [ ] Descriptions help users understand when to use
5. **Alignment Checks**
- [ ] Menu items align with agent's role/purpose
- [ ] Menu items are supported by agent's expertise
- [ ] Menu items fit within agent's constraints
- [ ] Menu items are appropriate for target users
6. **Completeness**
- [ ] Core capabilities for this role are covered
- [ ] No obvious missing functionality
- [ ] Menu scope is appropriate (not too sparse/overloaded)
- [ ] Related functionality is grouped logically
7. **Standards Compliance**
- [ ] No prohibited patterns or commands
- [ ] No security vulnerabilities in patterns
- [ ] No ambiguous or conflicting items
- [ ] Consistent naming conventions
### Protocol 3: Report Findings
Organize your report into three sections:
**PASSING CHECKS** (List what passed)
```
✓ Menu structure properly formatted
✓ 5 menu items defined, all with required fields
✓ All patterns are valid regex
✓ Menu items align with agent role
```
**WARNINGS** (Non-blocking issues)
```
⚠ Item "analyze-data" description is vague
⚠ No menu item for [common capability X]
⚠ Pattern for "custom-command" very broad, may over-match
```
**FAILURES** (Blocking issues that must be fixed)
```
✗ Duplicate menu item name: "process" appears twice
✗ Invalid regex pattern: "[unclosed bracket"
✗ Menu item "system-admin" violates security guidelines
✗ No menu items defined for agent type that requires tools
```
### Protocol 4: Menu System
#### 5. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CONTEXT BOUNDARIES
**IN SCOPE:**
- Menu/commands section of agent.yaml
- Referencing agentMenuPatterns.md
- Menu structure, patterns, and alignment
- Individual menu item validation
**OUT OF SCOPE:**
- Metadata fields (handled in step-07b)
- Persona fields (handled in step-07c)
- System architecture (handled in step-07e)
- Workflow/capability implementation (handled in step-07f)
**DO NOT:**
- Validate metadata or persona in this step
- Suggest entirely new capabilities (that's for earlier steps)
- Question whether menu items are "good enough" qualitatively beyond standards
- Modify fields beyond menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [structure validation].
## SUCCESS METRICS
✓ **Complete Success:** All checks pass, menu is well-structured and aligned
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
✓ **Failure:** Blocking failures remain when user selects [C]
**CRITICAL:** Invalid regex patterns or security vulnerabilities in menu items are blocking issues.

306
src/modules/bmb/workflows/agent/steps-c/step-08e-structure-validation.md
View File

@ -1,306 +0,0 @@
---
name: 'step-07e-structure-validation'
description: 'Validate YAML structure and completeness'
# File References
# Routes to 8F if Expert, else to 9
nextStepFileExpert: './step-08f-sidecar-validation.md'
nextStepFileSimple: './step-09-celebrate.md'
simpleValidation: ../data/simple-agent-validation.md
expertValidation: ../data/expert-agent-validation.md
agentCompilation: ../data/agent-compilation.md
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Validate the built agent YAML file for structural completeness and correctness against the appropriate validation checklist (simple or expert), then route to sidecar validation if needed or proceed to celebration.
# MANDATORY EXECUTION RULES
1. **NEVER skip validation** - All agents must pass structural validation before completion
2. **ALWAYS use the correct validation checklist** based on agent type (simple vs expert)
3. **NEVER auto-fix without user consent** - Report issues and ask for permission
4. **ALWAYS check hasSidecar flag** before determining next step routing
5. **MUST load and parse the actual built YAML** - Not just show it, but validate it
6. **ALWAYS provide clear, actionable feedback** for any validation failures
# EXECUTION PROTOCOLS
## Context Awareness
- User is in the final validation phase
- Agent has been built and written to disk
- This is the "quality gate" before completion
- User expects thorough but fair validation
- Route depends on agent type (expert vs simple)
## User Expectations
- Clear validation results with specific issues identified
- Line-number references for YAML problems
- Option to fix issues or continue (if minor)
- Logical routing based on agent type
- Professional, constructive feedback tone
## Tone and Style
- Professional and thorough
- Constructive, not pedantic
- Clear prioritization of issues (critical vs optional)
- Encouraging when validation passes
- Actionable when issues are found
# CONTEXT BOUNDARIES
## What to Validate
- YAML syntax and structure
- Required frontmatter fields presence
- Required sections completeness
- Field format correctness
- Path validity (for references)
- Agent type consistency (simple vs expert requirements)
## What NOT to Validate
- Artistic choices in descriptions
- Persona writing style
- Command naming creativity
- Feature scope decisions
## When to Escalate
- Critical structural errors that break agent loading
- Missing required fields
- YAML syntax errors preventing file parsing
- Path references that don't exist
# EXECUTION SEQUENCE
## 1. Load Validation Context
```bash
# Load the appropriate validation checklist based on agent type
if agentType == "expert":
validationFile = expertValidation
else:
validationFile = simpleValidation
# Load the built agent YAML
builtAgent = read(builtYaml)
# Load compilation rules for reference
compilationRules = read(agentCompilation)
```
**Action:** Present a brief status message:
```
🔍 LOADING VALIDATION FRAMEWORK
Agent Type: {detected type}
Validation Standard: {simple|expert}
Built File: {builtYaml path}
```
## 2. Execute Structural Validation
Run systematic checks against the validation checklist:
### A. YAML Syntax Validation
- Parse YAML without errors
- Check indentation consistency
- Validate proper escaping of special characters
- Verify no duplicate keys
### B. Frontmatter Validation
- All required fields present
- Field values correct type (string, boolean, array)
- No empty required fields
- Proper array formatting
### C. Section Completeness
- All required sections present (based on agent type)
- Sections not empty unless explicitly optional
- Proper markdown heading hierarchy
### D. Field-Level Validation
- Path references exist and are valid
- Boolean fields are actual booleans (not strings)
- Array fields properly formatted
- No malformed YAML structures
### E. Agent Type Specific Checks
**For Simple Agents:**
- No sidecar requirements
- Basic fields complete
- No advanced configuration
**For Expert Agents:**
- Sidecar flag set correctly
- Sidecar folder path specified
- All expert fields present
- Advanced features properly configured
## 3. Generate Validation Report
Present findings in structured format:
```markdown
# 🎯 STRUCTURAL VALIDATION REPORT
## Agent: {agent-name}
Type: {simple|expert}
File: {builtYaml}
---
## ✅ PASSED CHECKS ({count})
{List of all validations that passed}
## ⚠️ ISSUES FOUND ({count})
{If any issues, list each with:}
### Issue #{number}: {type}
**Severity:** [CRITICAL|MODERATE|MINOR]
**Location:** Line {line} or Section {section}
**Problem:** {clear description}
**Impact:** {what this breaks}
**Suggested Fix:** {specific action}
---
## 📊 VALIDATION SUMMARY
**Overall Status:** [PASSED|FAILED|CONDITIONAL]
**Critical Issues:** {count}
**Moderate Issues:** {count}
**Minor Issues:** {count}
**Can Load Safely:** [YES|NO]
---
{If PASSED}
## 🎉 VALIDATION SUCCESSFUL
Your agent YAML is structurally sound and ready for use!
All required fields present and correctly formatted.
{If ISSUES FOUND}
## 🔧 RECOMMENDED ACTIONS
1. Address critical issues first
2. Review moderate issues
3. Minor issues can be deferred
```
## 4. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFileExpert} or {nextStepFileSimple}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
If [F] selected: Work through issues systematically
- Load specific section needing fix
- Present current state
- Apply auto-fixes or guide user through corrections
- Re-validate after each fix
- Confirm resolution and re-present menu
If [C] selected:
- Warn about implications if issues exist
- Get explicit confirmation if critical issues
- Document acceptance of issues
- Proceed to routing
## 5. Route to Next Step
After validation passes or user chooses to continue:
### Check Agent Type and Route
```yaml
# Check for sidecar requirement
hasSidecar = checkBuiltYamlForSidecarFlag()
if hasSidecar == true:
# Expert agent with sidecar
nextStep = nextStepFileExpert
routeMessage = """
📦 Expert agent detected with sidecar configuration.
→ Proceeding to sidecar validation (Step 7F)
"""
else:
# Simple agent or expert without sidecar
nextStep = nextStepFileSimple
routeMessage = """
✅ Simple agent validation complete.
→ Proceeding to celebration (Step 8)
"""
```
**Action:** Present routing decision and transition:
```markdown
# 🚀 VALIDATION COMPLETE - ROUTING DECISION
{routeMessage}
**Next Step:** {nextStep filename}
**Reason:** Agent type {simple|expert} with sidecar={hasSidecar}
Press [Enter] to continue to {next step description}...
```
# CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFileExpert}` or `{nextStepFileSimple}` to execute and begin [sidecar validation or celebration].
**BEFORE proceeding to next step:**
1. ✅ Validation checklist executed completely
2. ✅ All critical issues resolved or explicitly accepted
3. ✅ User informed of routing decision
4. ✅ Next step file path determined correctly
5. ⚠️ **CRITICAL:** For expert agents, verify hasSidecar is TRUE before routing to 7F
6. ⚠️ **CRITICAL:** For simple agents, verify hasSidecar is FALSE before routing to 8
**DO NOT PROCEED IF:**
- YAML has critical syntax errors preventing loading
- User has not acknowledged validation results
- Routing logic is unclear or conflicting
# SUCCESS METRICS
## Step Complete When:
- [ ] Validation report generated and presented
- [ ] User has reviewed findings
- [ ] Critical issues resolved or accepted
- [ ] Routing decision communicated and confirmed
- [ ] Next step path verified and ready
## Quality Indicators:
- Validation thoroughness (all checklist items covered)
- Issue identification clarity and specificity
- User satisfaction with resolution process
- Correct routing logic applied
- Clear transition to next step
## Failure Modes:
- Skipping validation checks
- Auto-fixing without permission
- Incorrect routing (simple→7F or expert→8 with sidecar)
- Unclear or missing validation report
- Proceeding with critical YAML errors

462
src/modules/bmb/workflows/agent/steps-c/step-08f-sidecar-validation.md
View File

@ -1,462 +0,0 @@
---
name: 'step-07f-sidecar-validation'
description: 'Validate sidecar structure and paths'
# File References
nextStepFile: './step-09-celebrate.md'
criticalActions: ../data/critical-actions.md
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
sidecarFolder: '{bmb_creations_output_folder}/{agent-name}/{agent-name}-sidecar/'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Validate the sidecar folder structure and referenced paths for Expert agents to ensure all sidecar files exist, are properly structured, and paths in the main agent YAML correctly reference them.
# MANDATORY EXECUTION RULES
1. **ONLY runs for Expert agents** - Simple agents should never reach this step
2. **MUST verify sidecar folder exists** before proceeding
3. **ALWAYS cross-reference YAML paths** with actual files
4. **NEVER create missing sidecar files** - Report issues, don't auto-fix
5. **MUST validate sidecar file structure** for completeness
6. **ALWAYS check critical actions file** if referenced
7. **PROVIDE clear remediation steps** for any missing or malformed files
# EXECUTION PROTOCOLS
## Context Awareness
- User has an Expert agent with sidecar configuration
- Structural validation (7E) already passed
- Sidecar folder should have been created during build
- This is the final validation before celebration
- Missing sidecar components may break agent functionality
## User Expectations
- Comprehensive sidecar structure validation
- Clear identification of missing files
- Path reference verification
- Actionable remediation guidance
- Professional but approachable tone
## Tone and Style
- Thorough and systematic
- Clear and specific about issues
- Solution-oriented (focus on how to fix)
- Encouraging when sidecar is complete
- Not pedantic about minor formatting issues
# CONTEXT BOUNDARIES
## What to Validate
- Sidecar folder existence and location
- All referenced files exist in sidecar
- Sidecar file structure completeness
- Path references in main YAML accuracy
- Critical actions file if referenced
- File naming conventions
- File content completeness (not empty)
## What NOT to Validate
- Content quality of sidecar files
- Artistic choices in sidecar documentation
- Optional sidecar components
- File formatting preferences
## When to Escalate
- Sidecar folder completely missing
- Critical files missing (actions, core modules)
- Path references pointing to non-existent files
- Empty sidecar files that should have content
# EXECUTION SEQUENCE
## 1. Load Sidecar Context
```bash
# Verify main agent YAML exists
agentYaml = read(builtYaml)
# Extract sidecar path from YAML or use template default
sidecarPath = extractSidecarPath(agentYaml) or sidecarFolder
# Check if sidecar folder exists
sidecarExists = directoryExists(sidecarPath)
# Load critical actions reference if needed
criticalActionsRef = read(criticalActions)
```
**Action:** Present discovery status:
```markdown
🔍 SIDECAR VALIDATION INITIALIZED
Agent: {agent-name}
Type: Expert (requires sidecar)
Main YAML: {builtYaml}
Sidecar Path: {sidecarPath}
Status: {✅ Folder Found | ❌ Folder Missing}
```
## 2. Validate Sidecar Structure
### A. Folder Existence Check
```markdown
## 📁 FOLDER STRUCTURE VALIDATION
**Sidecar Location:** {sidecarPath}
**Status:** [EXISTS | MISSING | WRONG LOCATION]
```
If missing:
```markdown
❌ **CRITICAL ISSUE:** Sidecar folder not found!
**Expected Location:** {sidecarPath}
**Possible Causes:**
1. Build process didn't create sidecar
2. Sidecar path misconfigured in agent YAML
3. Folder moved or deleted after build
**Required Action:**
[ ] Re-run build process with sidecar enabled
[ ] Verify sidecar configuration in agent YAML
[ ] Check folder was created in correct location
```
### B. Sidecar File Inventory
If folder exists, list all files:
```bash
sidecarFiles = listFiles(sidecarPath)
```
```markdown
## 📄 SIDECAR FILE INVENTORY
Found {count} files in sidecar:
{For each file:}
- {filename} ({size} bytes)
```
### C. Cross-Reference Validation
Extract all sidecar path references from agent YAML:
```yaml
# Common sidecar reference patterns
sidecar:
critical-actions: './{agent-name}-sidecar/critical-actions.md'
modules:
- path: './{agent-name}-sidecar/modules/module-01.md'
```
Validate each reference:
```markdown
## 🔗 PATH REFERENCE VALIDATION
**Checked {count} references from agent YAML:**
{For each reference:}
**Source:** {field in agent YAML}
**Expected Path:** {referenced path}
**Status:** [✅ Found | ❌ Missing | ⚠️ Wrong Location]
```
## 3. Validate Sidecar File Contents
For each sidecar file found, check:
### A. File Completeness
```markdown
## 📋 FILE CONTENT VALIDATION
{For each file:}
### {filename}
**Size:** {bytes}
**Status:** [✅ Complete | ⚠️ Empty | ❌ Too Small]
**Last Modified:** {timestamp}
```
### B. Critical Actions File (if present)
Special validation for critical-actions.md:
```markdown
## 🎯 CRITICAL ACTIONS VALIDATION
**File:** {sidecarPath}/critical-actions.md
**Status:** [PRESENT | MISSING | EMPTY]
{If Present:}
**Sections Found:**
{List sections detected}
**Completeness:**
[ ] Header/metadata present
[ ] Actions defined
[ ] No critical sections missing
```
### C. Module Files (if present)
If sidecar contains modules:
```markdown
## 📚 MODULE VALIDATION
**Modules Found:** {count}
{For each module:}
### {module-filename}
**Status:** [✅ Valid | ⚠️ Issues Found]
**Checks:**
[ ] Frontmatter complete
[ ] Content present
[ ] References valid
```
## 4. Generate Validation Report
```markdown
# 🎯 SIDECAR VALIDATION REPORT
## Agent: {agent-name}
Sidecar Path: {sidecarPath}
Validation Date: {timestamp}
---
## ✅ VALIDATION CHECKS PASSED
**Folder Structure:**
- [x] Sidecar folder exists
- [x] Located at expected path
- [x] Accessible and readable
**File Completeness:**
- [x] All referenced files present
- [x] No broken path references
- [x] Files have content (not empty)
**Content Quality:**
- [x] Critical actions complete
- [x] Module files structured
- [x] No obvious corruption
---
## ⚠️ ISSUES IDENTIFIED ({count})
{If issues:}
### Issue #{number}: {issue type}
**Severity:** [CRITICAL|MODERATE|MINOR]
**Component:** {file or folder}
**Problem:** {clear description}
**Impact:** {what this breaks}
**Remediation:**
1. {specific step 1}
2. {specific step 2}
3. {specific step 3}
{If no issues:}
### 🎉 NO ISSUES FOUND
Your agent's sidecar is complete and properly structured!
All path references are valid and files are in place.
---
## 📊 SUMMARY
**Overall Status:** [PASSED|FAILED|CONDITIONAL]
**Files Validated:** {count}
**Issues Found:** {count}
**Critical Issues:** {count}
**Sidecar Ready:** [YES|NO]
---
## 5. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} or sidecar files for identified issues, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to celebration step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## 6. Issue Resolution (if [F] selected)
Work through each issue systematically:
**For Missing Files:**
```markdown
### 🔧 FIXING: Missing {filename}
**Required File:** {path}
**Purpose:** {why it's needed}
**Option 1:** Re-run Build
- Sidecar may not have been created completely
- Return to build step and re-execute
**Option 2:** Manual Creation
- Create file at: {full path}
- Use template from: {template reference}
- Minimum required content: {specification}
**Option 3:** Update References
- Remove reference from agent YAML if not truly needed
- Update path if file exists in different location
Which option? [1/2/3]:
```
**For Broken Path References:**
```markdown
### 🔧 FIXING: Invalid Path Reference
**Reference Location:** {agent YAML field}
**Current Path:** {incorrect path}
**Expected File:** {filename}
**Actual Location:** {where file actually is}
**Fix Options:**
1. Update path in agent YAML to: {correct path}
2. Move file to expected location: {expected path}
3. Remove reference if file not needed
Which option? [1/2/3]:
```
**For Empty/Malformed Files:**
```markdown
### 🔧 FIXING: {filename} - {Issue}
**Problem:** {empty/too small/malformed}
**Location:** {full path}
**Remediation:**
- View current content
- Compare to template/standard
- Add missing sections
- Correct formatting
Ready to view and fix? [Y/N]:
```
After each fix:
- Re-validate the specific component
- Confirm resolution
- Move to next issue
- Final re-validation when all complete
## 6. Route to Celebration
When validation passes or user chooses to continue:
```markdown
# 🚀 SIDECAR VALIDATION COMPLETE
## Expert Agent: {agent-name}
✅ **Sidecar Structure:** Validated
✅ **Path References:** All correct
✅ **File Contents:** Complete
---
## 🎯 READY FOR CELEBRATION
Your Expert agent with sidecar is fully validated and ready!
**Next Step:** Celebration (Step 8)
**Final Status:** All checks passed
Press [Enter] to proceed to celebration...
```
# CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [celebration].
**BEFORE proceeding to Step 8:**
1. ✅ Sidecar folder exists and is accessible
2. ✅ All referenced files present
3. ✅ Path references validated
4. ✅ File contents checked for completeness
5. ✅ User informed of validation status
6. ✅ Issues resolved or explicitly accepted
7. ⚠️ **CRITICAL:** Only Expert agents should reach this step
8. ⚠️ **CRITICAL:** Sidecar must be complete for agent to function
**DO NOT PROCEED IF:**
- Sidecar folder completely missing
- Critical files absent (actions, core modules)
- User unaware of sidecar issues
- Validation not completed
# SUCCESS METRICS
## Step Complete When:
- [ ] Sidecar folder validated
- [ ] All path references checked
- [ ] File contents verified
- [ ] Validation report presented
- [ ] Issues resolved or accepted
- [ ] User ready to proceed
## Quality Indicators:
- Thoroughness of file inventory
- Accuracy of path reference validation
- Clarity of issue identification
- Actionability of remediation steps
- User confidence in sidecar completeness
## Failure Modes:
- Missing sidecar folder completely
- Skipping file existence checks
- Not validating path references
- Proceeding with critical files missing
- Unclear validation report
- Not providing remediation guidance
---
## 🎓 NOTE: Expert Agent Sidecars
Sidecars are what make Expert agents powerful. They enable:
- Modular architecture
- Separation of concerns
- Easier updates and maintenance
- Shared components across agents
A validated sidecar ensures your Expert agent will:
- Load correctly at runtime
- Find all referenced resources
- Execute critical actions as defined
- Provide the advanced capabilities designed
Take the time to validate thoroughly - it pays off in agent reliability!

17
src/modules/bmb/workflows/agent/steps-e/e-01-load-existing.md
View File

@ -59,7 +59,9 @@ Load the existing agent file, parse its structure, and create an edit plan track
- Limits: Analysis only, no modifications
- Dependencies: Agent file must exist and be valid YAML
## Sequence of Instructions (Do not deviate, skip, or optimize)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Agent File
@ -74,14 +76,20 @@ Expected format: `{path-to-agent}/{agent-name}.agent.yaml`"
### 2. Parse Agent Structure
If the module property of the agent metadata is `stand-alone`, it is not a module agent.
If the module property of the agent is a module code (like bmm, bmb, etc...) it is a module agent.
If the property hasSidecar: true exists in the metadata, then it is an expert agent.
Else it is a simple agent.
If a module agent also hasSidecar: true - this means it is a modules expert agent, thus it can have sidecar.
**Extract and categorize all agent components:**
```yaml
# Basic Metadata
- name: {agent-name}
- description: {agent-description}
- type: {simple|expert|module}
- version: {version}
- module: {stand-alone|bmm|cis|bmgd|custom}
- hasSidecar: {true|false}
# Persona
- persona: {full persona text}
@ -104,8 +112,7 @@ Expected format: `{path-to-agent}/{agent-name}.agent.yaml`"
```markdown
## Agent Analysis: {agent-name}
**Type:** {simple|expert|module}
**Version:** {version}
**Type:** {simple|expert|module} (derived from module + hasSidecar)
**Status:** ready-for-edit
### Current Structure:

8
src/modules/bmb/workflows/agent/steps-e/e-02-discover-edits.md
View File

@ -2,7 +2,7 @@
name: 'e-02-discover-edits'
description: 'Discover what user wants to change about the agent'
nextStepFile: './e-03a-validate-metadata.md'
nextStepFile: './e-04-type-metadata.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
@ -54,7 +54,9 @@ Conduct targeted discovery to understand exactly what the user wants to change a
- Limits: Discovery and documentation only, no implementation
- Dependencies: Agent must be loaded in editPlan
## Sequence of Instructions (Do not deviate, skip, or optimize)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Read Edit Plan Context
@ -168,7 +170,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [all edits documented and confirmed by user], will you then load and read fully `{nextStepFile}` to execute and begin validation.
ONLY WHEN [C continue option] is selected and [all edits documented and confirmed by user], will you then load and read fully `{nextStepFile}` to execute and checks.
---

1
src/modules/bmb/workflows/agent/steps-e/e-03-placeholder.md Normal file
View File

@ -0,0 +1 @@
# Placeholder - do not load this step.

78
src/modules/bmb/workflows/agent/steps-e/e-03a-validate-metadata.md
View File

@ -1,78 +0,0 @@
---
name: 'e-03a-validate-metadata'
description: 'Validate metadata (before edit) - no menu, auto-advance'
nextStepFile: './e-03b-validate-persona.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentMetadata: ../data/agent-metadata.md
---
# Edit Step 3a: Validate Metadata (Before Edit)
## STEP GOAL:
Validate the agent's metadata properties against BMAD standards. Record findings to editPlan and auto-advance to next validation step.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentMetadata first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate metadata against agentMetadata.md rules
- 📊 Record findings to editPlan frontmatter
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentMetadata.md reference
- 📊 Validate all metadata fields
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentMetadata}` to understand validation rules.
Read `{editPlan}` to get agent file path and metadata.
### 2. Validate Metadata
Perform checks on:
- **id**: kebab-case, no spaces
- **name**: display name, clear branding
- **title**: concise function description
- **icon**: appropriate emoji or symbol
- **module**: correct format `{project}:{type}:{name}`
- **hasSidecar**: boolean, matches actual sidecar usage
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
validationBefore:
metadata:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
- {check}: [pass|fail]
```
### 4. Auto-Advance
When validation complete, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All metadata checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to persona validation...**

76
src/modules/bmb/workflows/agent/steps-e/e-03b-validate-persona.md
View File

@ -1,76 +0,0 @@
---
name: 'e-03b-validate-persona'
description: 'Validate persona (before edit) - no menu, auto-advance'
nextStepFile: './e-03c-validate-menu.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
---
# Edit Step 3b: Validate Persona (Before Edit)
## STEP GOAL:
Validate the agent's persona fields against BMAD standards. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and persona references first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate persona four-field system
- 📊 Record findings to editPlan frontmatter
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load personaProperties.md and principlesCrafting.md
- 📊 Validate persona fields
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{personaProperties}` and `{principlesCrafting}`.
Read `{editPlan}` to get agent file path and persona.
### 2. Validate Persona
Perform checks on:
- **role**: present, specific, not generic
- **identity**: present, defines who agent is
- **communication_style**: present, speech patterns only (no behavioral words)
- **principles**: present, first principle activates expert knowledge, not generic duties
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
persona:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
- {check}: [pass|fail]
```
### 4. Auto-Advance
When validation complete, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All persona checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to menu validation...**

75
src/modules/bmb/workflows/agent/steps-e/e-03c-validate-menu.md
View File

@ -1,75 +0,0 @@
---
name: 'e-03c-validate-menu'
description: 'Validate menu structure (before edit) - no menu, auto-advance'
nextStepFile: './e-03d-validate-structure.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
---
# Edit Step 3c: Validate Menu (Before Edit)
## STEP GOAL:
Validate the agent's command menu structure against BMAD standards. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentMenuPatterns first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate command/menu structure
- 📊 Record findings to editPlan frontmatter
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentMenuPatterns.md reference
- 📊 Validate commands and menu
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentMenuPatterns}`.
Read `{editPlan}` to get agent file path and commands.
### 2. Validate Menu
Perform checks on:
- **A/P/C convention**: each menu has Advanced Elicitation, Party Mode, Continue
- **Command names**: clear, descriptive
- **Command descriptions**: specific, actionable
- **Menu handling logic**: properly specified
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
menu:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
- {check}: [pass|fail]
```
### 4. Auto-Advance
When validation complete, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All menu checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to structure validation...**

75
src/modules/bmb/workflows/agent/steps-e/e-03d-validate-structure.md
View File

@ -1,75 +0,0 @@
---
name: 'e-03d-validate-structure'
description: 'Validate YAML structure (before edit) - no menu, auto-advance'
nextStepFile: './e-03e-validate-sidecar.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentCompilation: ../data/agent-compilation.md
---
# Edit Step 3d: Validate Structure (Before Edit)
## STEP GOAL:
Validate the agent's YAML structure and completeness. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentCompilation first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate YAML structure and required fields
- 📊 Record findings to editPlan frontmatter
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentCompilation.md reference
- 📊 Validate YAML structure
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentCompilation}`.
Read `{editPlan}` to get agent file path.
### 2. Validate Structure
Perform checks on:
- **YAML syntax**: valid, no parse errors
- **Required fields**: name, description, type, persona present
- **Field types**: arrays where expected, strings where expected
- **Indentation**: consistent 2-space indentation
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
structure:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
- {check}: [pass|fail]
```
### 4. Auto-Advance
When validation complete, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All structure checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to sidecar validation...**

78
src/modules/bmb/workflows/agent/steps-e/e-03e-validate-sidecar.md
View File

@ -1,78 +0,0 @@
---
name: 'e-03e-validate-sidecar'
description: 'Validate sidecar structure (before edit) - no menu, auto-advance'
nextStepFile: './e-03f-validation-summary.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
expertValidation: ../data/expert-agent-validation.md
---
# Edit Step 3e: Validate Sidecar (Before Edit)
## STEP GOAL:
Validate the agent's sidecar structure if Expert type. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and expertValidation first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate sidecar structure for Expert agents
- 📊 Record findings to editPlan frontmatter
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load expertValidation.md reference
- 📊 Validate sidecar if Expert type, skip for Simple/Module
- 💾 Record findings to editPlan
- ➡️ Auto-advance to validation summary when complete
## Sequence of Instructions:
### 1. Load References
Read `{expertValidation}`.
Read `{editPlan}` to get agent type.
### 2. Conditional Validation
**IF agentType == expert:**
- Check metadata.sidecar-folder is present
- Check sidecar-path is correct format
- Verify sidecar files exist at specified path
**IF agentType != expert:**
- Mark as N/A (not applicable)
- Skip detailed checks
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
sidecar:
status: [pass|fail|warning|n/a]
findings:
- {check}: [pass|fail|n/a]
- {check}: [pass|fail|n/a]
```
### 4. Auto-Advance
When validation complete, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ Sidecar checks performed (or N/A recorded)
✅ Findings saved to editPlan
✅ Auto-advanced to validation summary
---
**Auto-advancing to validation summary...**

119
src/modules/bmb/workflows/agent/steps-e/e-03f-validation-summary.md
View File

@ -1,119 +0,0 @@
---
name: 'e-03f-validation-summary'
description: 'Display all validation findings before edit'
nextStepFile: './e-04-type-metadata.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Edit Step 3f: Validation Summary (Before Edit)
## STEP GOAL:
Display all validation findings from the previous 5 validation steps to the user. Present findings clearly and await confirmation to proceed.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan to collect all validation findings
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Display all validation findings clearly organized
- 📊 Aggregate findings from all 5 validation steps
- 💬 Present options for handling any issues found
## EXECUTION PROTOCOLS:
- 🎯 Read editPlan to get validation findings
- 📊 Display organized summary
- 💾 Allow user to decide how to proceed
- ➡️ Proceed to edit plan on [C]
## Sequence of Instructions:
### 1. Load Validation Findings
Read `{editPlan}` frontmatter to collect:
- validationBefore.metadata.status and findings
- validationBefore.persona.status and findings
- validationBefore.menu.status and findings
- validationBefore.structure.status and findings
- validationBefore.sidecar.status and findings
### 2. Display Validation Summary
```markdown
## Pre-Edit Validation Report for {agent-name}
### Metadata Validation
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
{Findings summary}
### Persona Validation
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
{Findings summary}
### Menu Validation
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
{Findings summary}
### Structure Validation
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
{Findings summary}
### Sidecar Validation
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL / N/A}
{Findings summary}
```
### 3. Present Options
"How would you like to proceed?
**[I**ntegrate fixes**] - Add validation fixes to your edit plan
**[S]kip** - Proceed with your planned edits only
**[A]dvanced** - Deeper exploration of any issues"
### 4. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Edit Plan"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF I: Add validation fixes to editPlan, then redisplay menu
- IF C: Save validation summary to {editPlan}, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation summary displayed], will you then load and read fully `{nextStepFile}` to execute and begin edit planning.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All validation findings displayed clearly
- User given options for handling issues
- Validation summary saved to editPlan
### ❌ SYSTEM FAILURE:
- Findings not displayed to user
- Proceeding without user acknowledgment
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

4
src/modules/bmb/workflows/agent/steps-e/e-04-type-metadata.md
View File

@ -36,7 +36,9 @@ Review the agent's type and metadata, and plan any changes. If edits involve typ
- 💾 Document planned metadata changes
- 🚫 FORBIDDEN to proceed without documenting changes
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents

4
src/modules/bmb/workflows/agent/steps-e/e-05-persona.md
View File

@ -37,7 +37,9 @@ Review the agent's persona and plan any changes using the four-field persona sys
- 💾 Document planned persona changes
- 🚫 FORBIDDEN to proceed without documenting changes
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents

4
src/modules/bmb/workflows/agent/steps-e/e-06-commands-menu.md
View File

@ -35,7 +35,9 @@ Review the agent's command menu and plan any additions, modifications, or remova
- 💾 Document planned command changes
- 🚫 FORBIDDEN to proceed without documenting changes
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents

23
src/modules/bmb/workflows/agent/steps-e/e-07-activation.md
View File

@ -39,7 +39,9 @@ Review critical_actions and route to the appropriate type-specific edit step (Si
- 💾 Route to appropriate type-specific edit step
- ➡️ Auto-advance to type-specific edit on [C]
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents
@ -56,12 +58,13 @@ If user wants to add/modify critical_actions:
### 3. Determine Routing
Check `{editPlan}` metadataEdits.typeConversion.to or current agentType:
Check `{editPlan}` for agent metadata (module and hasSidecar):
```yaml
agentType: simple → route to e-08a-edit-simple.md
agentType: expert → route to e-08b-edit-expert.md
agentType: module → route to e-08c-edit-module.md
# Determine agent type from module + hasSidecar combination
module ≠ "stand-alone" → route to e-08c-edit-module.md
module = "stand-alone" + hasSidecar: true → route to e-08b-edit-expert.md
module = "stand-alone" + hasSidecar: false → route to e-08a-edit-simple.md
```
### 4. Document to Edit Plan
@ -75,7 +78,7 @@ activationEdits:
modifications: []
routing:
destinationEdit: {e-08a|e-08b|e-08c}
targetType: {simple|expert|module}
sourceType: {simple|expert|module} # Derived from module + hasSidecar
```
### 5. Present MENU OPTIONS
@ -86,7 +89,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save to {editPlan}, determine routing based on targetType, then only then load and execute the appropriate type-specific edit step
- IF C: Save to {editPlan}, determine routing based on module + hasSidecar, then only then load and execute the appropriate type-specific edit step
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
#### EXECUTION RULES:
@ -99,9 +102,9 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
This is the **ROUTING HUB** for edit flow. ONLY WHEN [C continue option] is selected and [routing determined], load and execute the appropriate type-specific edit step:
- targetType: simple → e-08a-edit-simple.md
- targetType: expert → e-08b-edit-expert.md
- targetType: module → e-08c-edit-module.md
- module ≠ "stand-alone" → e-08c-edit-module.md (Module agent)
- module = "stand-alone" + hasSidecar: true → e-08b-edit-expert.md (Expert agent)
- module = "stand-alone" + hasSidecar: false → e-08a-edit-simple.md (Simple agent)
---

13
src/modules/bmb/workflows/agent/steps-e/e-08a-edit-simple.md
View File

@ -2,7 +2,7 @@
name: 'e-08a-edit-simple'
description: 'Apply edits to Simple agent'
nextStepFile: './e-09a-validate-metadata.md'
nextStepFile: './e-09-celebrate.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentFile: '{original-agent-path}'
agentBackup: '{original-agent-path}.backup'
@ -47,7 +47,9 @@ Apply all planned edits to the Simple agent YAML file using templates and archit
- ✅ Validate YAML syntax
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents
@ -74,9 +76,10 @@ Confirm: "Backup created at: `{agentBackup}`"
For each planned edit:
**Type Conversion:**
- Update `type:` field if converting
- Add/remove type-specific fields
**Type Conversion (Simple ← Expert/Module):**
- Converting TO Simple: Remove `metadata.sidecar-folder`, remove all sidecar references
- Set `module: stand-alone` and `hasSidecar: false`
- Remove type-specific fields from source type
**Metadata Edits:**
- Apply each field change from metadataEdits

12
src/modules/bmb/workflows/agent/steps-e/e-08b-edit-expert.md
View File

@ -2,7 +2,7 @@
name: 'e-08b-edit-expert'
description: 'Apply edits to Expert agent'
nextStepFile: './e-09a-validate-metadata.md'
nextStepFile: './e-09-celebrate.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentFile: '{original-agent-path}'
agentBackup: '{original-agent-path}.backup'
@ -48,7 +48,9 @@ Apply all planned edits to the Expert agent YAML file and manage sidecar structu
- ✅ Validate YAML and sidecar paths
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents
@ -70,10 +72,10 @@ ALWAYS backup before editing:
### 4. Apply Edits in Sequence
**Type Conversion to Expert:**
- Update `type: expert`
**Type Conversion TO Expert:**
- Set `module: stand-alone` and `hasSidecar: true`
- Add `metadata.sidecar-folder` if not present
- Create sidecar directory: `mkdir -p {project-root}/_bmad/_memory/{sidecar-folder}/`
- Create sidecar directory next to agent.yaml: `{agent-folder}/{agent-name}-sidecar/`
**Sidecar Management:**
- If changing sidecar-folder: update all critical_actions references

13
src/modules/bmb/workflows/agent/steps-e/e-08c-edit-module.md
View File

@ -2,7 +2,7 @@
name: 'e-08c-edit-module'
description: 'Apply edits to Module agent'
nextStepFile: './e-09a-validate-metadata.md'
nextStepFile: './e-09-celebrate.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentFile: '{original-agent-path}'
agentBackup: '{original-agent-path}.backup'
@ -48,11 +48,13 @@ Apply all planned edits to the Module agent YAML file and manage workflow integr
- ✅ Validate YAML and workflow paths
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents
Read all files before editing:
Read all files before editing - these are RULES that must be followed when editing agents:
- `{expertTemplate}` - Module uses expert as baseline
- `{expertArch}`, `{moduleArch}` - Architecture references
- `{agentCompilation}`, `{agentMetadata}`, `{personaProperties}`, `{principlesCrafting}`
@ -70,9 +72,10 @@ ALWAYS backup before editing:
### 4. Apply Edits in Sequence
**Type Conversion to Module:**
- Update `type: module`
**Type Conversion TO Module:**
- Set `module` to module code (e.g., `bmm`, `cis`, `bmgd`, or custom)
- Add workflow integration paths
- Optionally set `hasSidecar: true` if complex multi-workflow module
**Workflow Path Management:**
- Add: `skills: - workflow: {path}`

21
src/modules/bmb/workflows/agent/steps-e/e-10-celebrate.md → src/modules/bmb/workflows/agent/steps-e/e-09-celebrate.md
View File

@ -1,14 +1,15 @@
---
name: 'e-10-celebrate'
name: 'e-09-celebrate'
description: 'Celebrate successful agent edit completion'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
validationWorkflow: '{project-root}/src/modules/bmb/workflows/agent/steps-v/v-01-load-review.md'
---
# Edit Step 10: Celebration
# Edit Step 9: Celebration
## STEP GOAL:
@ -48,7 +49,9 @@ Celebrate the successful agent edit, provide summary of changes, and mark edit w
- Limits: No more edits, only acknowledgment
- Dependencies: All edits successfully applied
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.:
### 1. Read Edit Plan
@ -110,24 +113,26 @@ Append to editPlan:
### 6. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [X] Exit Workflow"
Display: "**✅ Agent Edit Complete! Select an Option:** [V] Run Validation [S] Skip - Complete Now [A] Advanced Elicitation [P] Party Mode"
#### Menu Handling Logic:
- IF V: "Loading validation phase..." → Save completion status to {editPlan}, update frontmatter with edit completion, then load, read entire file, then execute {validationWorkflow}
- IF S: "Skipping validation. Completing workflow..." → Save completion status to {editPlan} and end workflow gracefully
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF X: Save completion status to {editPlan} and end workflow gracefully
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY complete workflow when user selects 'X'
- After other menu items execution, return to this menu
- User can choose validation (V), skip to complete (S), or use advanced elicitation (A) or party mode (P)
- After other menu items execution (A/P), return to this menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [X exit option] is selected and [completion documented], will the workflow end gracefully with agent edit complete.
ONLY WHEN [S skip option] is selected and [completion documented], will the workflow end gracefully with agent edit complete.
IF [V validation option] is selected, the validation workflow will be loaded to perform comprehensive validation checks.
---

70
src/modules/bmb/workflows/agent/steps-e/e-09a-validate-metadata.md
View File

@ -1,70 +0,0 @@
---
name: 'e-09a-validate-metadata'
description: 'Validate metadata (after edit) - no menu, auto-advance'
nextStepFile: './e-09b-validate-persona.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentMetadata: ../data/agent-metadata.md
---
# Edit Step 9a: Validate Metadata (After Edit)
## STEP GOAL:
Validate the agent's metadata properties after edits. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentMetadata first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate metadata against agentMetadata.md rules
- 📊 Record findings to editPlan frontmatter (validationAfter section)
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentMetadata.md reference
- 📊 Validate all metadata fields
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentMetadata}` and `{editPlan}`.
### 2. Validate Metadata
Perform checks on id, name, title, icon, module, hasSidecar.
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
validationAfter:
metadata:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
```
### 4. Auto-Advance
Load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All metadata checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to persona validation...**

70
src/modules/bmb/workflows/agent/steps-e/e-09b-validate-persona.md
View File

@ -1,70 +0,0 @@
---
name: 'e-09b-validate-persona'
description: 'Validate persona (after edit) - no menu, auto-advance'
nextStepFile: './e-09c-validate-menu.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
---
# Edit Step 9b: Validate Persona (After Edit)
## STEP GOAL:
Validate the agent's persona after edits. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and persona references first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate persona four-field system
- 📊 Record findings to editPlan frontmatter (validationAfter section)
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load personaProperties.md and principlesCrafting.md
- 📊 Validate persona fields
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{personaProperties}`, `{principlesCrafting}`, and `{editPlan}`.
### 2. Validate Persona
Perform checks on role, identity, communication_style, principles.
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
persona:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
```
### 4. Auto-Advance
Load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All persona checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to menu validation...**

69
src/modules/bmb/workflows/agent/steps-e/e-09c-validate-menu.md
View File

@ -1,69 +0,0 @@
---
name: 'e-09c-validate-menu'
description: 'Validate menu structure (after edit) - no menu, auto-advance'
nextStepFile: './e-09d-validate-structure.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
---
# Edit Step 9c: Validate Menu (After Edit)
## STEP GOAL:
Validate the agent's command menu structure after edits. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentMenuPatterns first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate command/menu structure
- 📊 Record findings to editPlan frontmatter (validationAfter section)
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentMenuPatterns.md reference
- 📊 Validate commands and menu
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentMenuPatterns}` and `{editPlan}`.
### 2. Validate Menu
Perform checks on A/P/C convention, command names, descriptions.
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
menu:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
```
### 4. Auto-Advance
Load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All menu checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to structure validation...**

69
src/modules/bmb/workflows/agent/steps-e/e-09d-validate-structure.md
View File

@ -1,69 +0,0 @@
---
name: 'e-09d-validate-structure'
description: 'Validate YAML structure (after edit) - no menu, auto-advance'
nextStepFile: './e-09e-validate-sidecar.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentCompilation: ../data/agent-compilation.md
---
# Edit Step 9d: Validate Structure (After Edit)
## STEP GOAL:
Validate the agent's YAML structure after edits. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentCompilation first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate YAML structure and required fields
- 📊 Record findings to editPlan frontmatter (validationAfter section)
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentCompilation.md reference
- 📊 Validate YAML structure
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentCompilation}` and `{editPlan}`.
### 2. Validate Structure
Perform checks on YAML syntax, required fields, field types, indentation.
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
structure:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
```
### 4. Auto-Advance
Load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All structure checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to sidecar validation...**

70
src/modules/bmb/workflows/agent/steps-e/e-09e-validate-sidecar.md
View File

@ -1,70 +0,0 @@
---
name: 'e-09e-validate-sidecar'
description: 'Validate sidecar structure (after edit) - no menu, auto-advance'
nextStepFile: './e-09f-validation-summary.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
expertValidation: ../data/expert-agent-validation.md
---
# Edit Step 9e: Validate Sidecar (After Edit)
## STEP GOAL:
Validate the agent's sidecar structure after edits (if Expert type). Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and expertValidation first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate sidecar structure for Expert agents
- 📊 Record findings to editPlan frontmatter (validationAfter section)
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load expertValidation.md reference
- 📊 Validate sidecar if Expert type, skip for Simple/Module
- 💾 Record findings to editPlan
- ➡️ Auto-advance to validation summary when complete
## Sequence of Instructions:
### 1. Load References
Read `{expertValidation}` and `{editPlan}` to get agent type.
### 2. Conditional Validation
**IF agentType == expert:** Check sidecar-folder, sidecar-path, file existence
**IF agentType != expert:** Mark as N/A
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
sidecar:
status: [pass|fail|warning|n/a]
findings:
- {check}: [pass|fail|n/a]
```
### 4. Auto-Advance
Load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ Sidecar checks performed (or N/A recorded)
✅ Findings saved to editPlan
✅ Auto-advanced to validation summary
---
**Auto-advancing to validation summary...**

111
src/modules/bmb/workflows/agent/steps-e/e-09f-validation-summary.md
View File

@ -1,111 +0,0 @@
---
name: 'e-09f-validation-summary'
description: 'Display all validation findings after edit'
nextStepFile: './e-10-celebrate.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Edit Step 9f: Validation Summary (After Edit)
## STEP GOAL:
Display all post-edit validation findings and compare with pre-edit state. Present findings and await confirmation to proceed to celebration.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan to collect all validation findings
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Display all validation findings clearly organized
- 📊 Compare before/after states
- 💬 Present options for handling any remaining issues
## EXECUTION PROTOCOLS:
- 🎯 Read editPlan to get validation findings
- 📊 Display organized summary with before/after comparison
- 💾 Allow user to decide how to proceed
## Sequence of Instructions:
### 1. Load Validation Findings
Read `{editPlan}` frontmatter to collect validationBefore and validationAfter findings.
### 2. Display Validation Summary
```markdown
## Post-Edit Validation Report for {agent-name}
### Before vs After Comparison
| Component | Before | After | Status |
|-----------|--------|-------|--------|
| Metadata | {status} | {status} | {Δ} |
| Persona | {status} | {status} | {Δ} |
| Menu | {status} | {status} | {Δ} |
| Structure | {status} | {status} | {Δ} |
| Sidecar | {status} | {status} | {Δ} |
### Detailed Findings (After Edit)
**Metadata:** {summary}
**Persona:** {summary}
**Menu:** {summary}
**Structure:** {summary}
**Sidecar:** {summary}
```
### 3. Present Options
"How do the edits look?
**[R]eview** - Show detailed before/after for any component
**[F]ix** - Address any remaining issues
**[A]ccept** - Proceed to celebration"
### 4. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Celebration"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF R: Show detailed before/after comparison, then redisplay menu
- IF C: Save validation summary to {editPlan}, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation summary displayed], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All validation findings displayed clearly
- Before/after comparison shown
- User given options for handling issues
### ❌ SYSTEM FAILURE:
- Findings not displayed to user
- Proceeding without user acknowledgment
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

20
src/modules/bmb/workflows/agent/steps-v/v-01-load-review.md
View File

@ -34,11 +34,19 @@ Load the existing agent file and initialize a validation report to track all fin
- 💾 Create validation report document
- 🚫 FORBIDDEN to proceed without user confirmation
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Agent File
Read the complete YAML from the agent file path provided by the user.
If the module property of the agent metadata is stand-alone, it is not a module agent.
If the module property of the agent is a module code (like bmm, bmb, etc...) it is a module agent.
If the property hasSidecar: true exists in the metadata, then it is an expert agent.
Else it is a simple agent.
If a module agent also hasSidecar: true - this means it is a modules expert agent, thus it can have sidecar.
### 2. Display Agent Summary
@ -46,7 +54,6 @@ Read the complete YAML from the agent file path provided by the user.
## Agent to Validate: {agent-name}
**Type:** {simple|expert|module}
**Version:** {version}
**File:** {agent-file-path}
### Current Structure:
@ -63,7 +70,7 @@ Initialize the validation report:
```markdown
---
agentName: '{agent-name}'
agentType: '{simple|expert|module}'
agentType: '{simple|expert|module}' # Derived from module + hasSidecar
agentFile: '{agent-file-path}'
validationDate: '{YYYY-MM-DD}'
stepsCompleted:
@ -75,8 +82,9 @@ stepsCompleted:
## Agent Overview
**Name:** {agent-name}
**Type:** {simple|expert|module}
**Version:** {version}
**Type:** {simple|expert|module} # Derived from: module + hasSidecar
**module:** {module-value}
**hasSidecar:** {true|false}
**File:** {agent-file-path}
---
@ -90,7 +98,7 @@ Write to `{validationReport}`.
### 4. Present MENU OPTIONS
Display: "**Is this the correct agent to validate?** [A] Advanced Elicitation [P] Party Mode [C] Yes, Begin Validation"
Display: "**Is this the correct agent to validate and is it identified as the proper type?** [A] Advanced Elicitation [P] Party Mode [C] Yes, Begin Validation"
#### Menu Handling Logic:

65
src/modules/bmb/workflows/agent/steps-v/v-02a-validate-metadata.md
View File

@ -5,18 +5,20 @@ description: 'Validate metadata and append to report'
nextStepFile: './v-02b-validate-persona.md'
validationReport: '{bmb_creations_output_folder}/validation-report-{agent-name}.md'
agentMetadata: ../data/agent-metadata.md
agentFile: '{agent-file-path}'
---
# Validate Step 2a: Validate Metadata
## STEP GOAL:
## STEP GOAL
Validate the agent's metadata properties against BMAD standards. Append findings to validation report and auto-advance.
Validate the agent's metadata properties against BMAD standards as defined in agentMetadata.md. Append findings to validation report and auto-advance.
## MANDATORY EXECUTION RULES:
## MANDATORY EXECUTION RULES
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read validationReport and agentMetadata first
- 🔄 CRITICAL: Load the actual agent file to validate metadata
- 🚫 NO MENU - append findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
@ -26,22 +28,55 @@ Validate the agent's metadata properties against BMAD standards. Append findings
- 📊 Append findings to validation report
- 🚫 FORBIDDEN to present menu
## EXECUTION PROTOCOLS:
## EXECUTION PROTOCOLS
- 🎯 Load agentMetadata.md reference
- 🎯 Load the actual agent file for validation
- 📊 Validate all metadata fields
- 💾 Append findings to validation report
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load References
Read `{agentMetadata}` and `{validationReport}`.
Read `{agentMetadata}`, `{validationReport}`, and `{agentFile}`.
### 2. Validate Metadata
Perform checks on: id, name, title, icon, module, hasSidecar.
Perform these checks systematically - validate EVERY rule specified in agentMetadata.md:
1. **Required Fields Existence**
- [ ] id: Present and non-empty
- [ ] name: Present and non-empty (display name)
- [ ] title: Present and non-empty
- [ ] icon: Present (emoji or symbol)
- [ ] module: Present and valid format
- [ ] hasSidecar: Present (boolean, if applicable)
2. **Format Validation**
- [ ] id: Uses kebab-case, no spaces, unique identifier
- [ ] name: Clear display name for UI
- [ ] title: Concise functional description
- [ ] icon: Appropriate emoji or unicode symbol
- [ ] module: Either a 3-4 letter module code OR 'stand-alone'
- [ ] hasSidecar: Boolean value, matches actual agent structure
3. **Content Quality**
- [ ] id: Unique and descriptive
- [ ] name: Clear and user-friendly
- [ ] title: Accurately describes agent's function
- [ ] icon: Visually representative of agent's purpose
- [ ] module: Correctly identifies module membership
- [ ] hasSidecar: Correctly indicates if agent uses sidecar files
4. **Agent Type Consistency**
- [ ] If hasSidecar: true, sidecar folder path must be specified
- [ ] If module is a module code, agent is a module agent
- [ ] If module is 'stand-alone', agent is not part of a module
- [ ] No conflicting type indicators
### 3. Append Findings to Report
@ -53,15 +88,23 @@ Append to `{validationReport}`:
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
**Checks:**
- [ ] id: kebab-case, no spaces
- [ ] id: kebab-case, no spaces, unique
- [ ] name: clear display name
- [ ] title: concise function description
- [ ] icon: appropriate emoji/symbol
- [ ] module: correct format `{project}:{type}:{name}`
- [ ] module: correct format (code or stand-alone)
- [ ] hasSidecar: matches actual usage
**Findings:**
{Detailed findings}
**Detailed Findings:**
*PASSING:*
{List of passing checks}
*WARNINGS:*
{List of non-blocking issues}
*FAILURES:*
{List of blocking issues that must be fixed}
```
### 4. Auto-Advance

72
src/modules/bmb/workflows/agent/steps-v/v-02b-validate-persona.md
View File

@ -6,43 +6,87 @@ nextStepFile: './v-02c-validate-menu.md'
validationReport: '{bmb_creations_output_folder}/validation-report-{agent-name}.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
agentFile: '{agent-file-path}'
---
# Validate Step 2b: Validate Persona
## STEP GOAL:
## STEP GOAL
Validate the agent's persona against BMAD standards. Append findings to validation report and auto-advance.
Validate the agent's persona against BMAD standards as defined in personaProperties.md and principlesCrafting.md. Append findings to validation report and auto-advance.
## MANDATORY EXECUTION RULES:
## MANDATORY EXECUTION RULES
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read validationReport and persona references first
- 🔄 CRITICAL: Load the actual agent file to validate persona
- 🚫 NO MENU - append findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate persona four-field system
- 🎯 Validate persona against personaProperties.md rules
- 📊 Append findings to validation report
- 🚫 FORBIDDEN to present menu
## EXECUTION PROTOCOLS:
## EXECUTION PROTOCOLS
- 🎯 Load personaProperties.md and principlesCrafting.md
- 🎯 Load the actual agent file for validation
- 📊 Validate persona fields
- 💾 Append findings to validation report
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load References
Read `{personaProperties}`, `{principlesCrafting}`, and `{validationReport}`.
Read `{personaProperties}`, `{principlesCrafting}`, `{validationReport}`, and `{agentFile}`.
### 2. Validate Persona
Perform checks on: role, identity, communication_style, principles.
Perform these checks systematically - validate EVERY rule specified in personaProperties.md:
1. **Required Fields Existence**
- [ ] role: Present, clear, and specific
- [ ] identity: Present and defines who the agent is
- [ ] communication_style: Present and appropriate to role
- [ ] principles: Present as array, not empty (if applicable)
2. **Content Quality - Role**
- [ ] Role is specific (not generic like "assistant")
- [ ] Role aligns with agent's purpose and menu items
- [ ] Role is achievable within LLM capabilities
- [ ] Role scope is appropriate (not too broad/narrow)
3. **Content Quality - Identity**
- [ ] Identity clearly defines the agent's character
- [ ] Identity is consistent with the role
- [ ] Identity provides context for behavior
- [ ] Identity is not generic or cliché
4. **Content Quality - Communication Style**
- [ ] Communication style is clearly defined
- [ ] Style matches the role and target users
- [ ] Style is consistent throughout the definition
- [ ] Style examples or guidance provided if nuanced
- [ ] Style focuses on speech patterns only (not behavior)
5. **Content Quality - Principles**
- [ ] Principles are actionable (not vague platitudes)
- [ ] Principles guide behavior and decisions
- [ ] Principles are consistent with role
- [ ] 3-7 principles recommended (not overwhelming)
- [ ] Each principle is clear and specific
- [ ] First principle activates expert knowledge domain
6. **Consistency Checks**
- [ ] Role, identity, communication_style, principles all align
- [ ] No contradictions between principles
- [ ] Persona supports the menu items defined
- [ ] Language and terminology consistent
### 3. Append Findings to Report
@ -59,8 +103,16 @@ Append to `{validationReport}`:
- [ ] communication_style: speech patterns only
- [ ] principles: first principle activates expert knowledge
**Findings:**
{Detailed findings}
**Detailed Findings:**
*PASSING:*
{List of passing checks}
*WARNINGS:*
{List of non-blocking issues}
*FAILURES:*
{List of blocking issues that must be fixed}
```
### 4. Auto-Advance

94
src/modules/bmb/workflows/agent/steps-v/v-02c-validate-menu.md
View File

@ -5,43 +5,108 @@ description: 'Validate menu structure and append to report'
nextStepFile: './v-02d-validate-structure.md'
validationReport: '{bmb_creations_output_folder}/validation-report-{agent-name}.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
agentFile: '{agent-file-path}'
---
# Validate Step 2c: Validate Menu
## STEP GOAL:
## STEP GOAL
Validate the agent's command menu structure against BMAD standards. Append findings to validation report and auto-advance.
Validate the agent's command menu structure against BMAD standards as defined in agentMenuPatterns.md. Append findings to validation report and auto-advance.
## MANDATORY EXECUTION RULES:
## MANDATORY EXECUTION RULES
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read validationReport and agentMenuPatterns first
- 🔄 CRITICAL: Load the actual agent file to validate menu
- 🚫 NO MENU - append findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate command/menu structure
- 🎯 Validate menu against agentMenuPatterns.md rules
- 📊 Append findings to validation report
- 🚫 FORBIDDEN to present menu
## EXECUTION PROTOCOLS:
## EXECUTION PROTOCOLS
- 🎯 Load agentMenuPatterns.md reference
- 🎯 Load the actual agent file for validation
- 📊 Validate commands and menu
- 💾 Append findings to validation report
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load References
Read `{agentMenuPatterns}` and `{validationReport}`.
Read `{agentMenuPatterns}`, `{validationReport}`, and `{agentFile}`.
### 2. Validate Menu
Perform checks on: A/P/C convention, command names, descriptions.
Perform these checks systematically - validate EVERY rule specified in agentMenuPatterns.md:
1. **Menu Structure**
- [ ] Menu section exists and is properly formatted
- [ ] At least one menu item defined (unless intentionally tool-less)
- [ ] Menu items follow proper YAML structure
- [ ] Each item has required fields (name, description, pattern)
2. **Menu Item Requirements**
For each menu item:
- [ ] name: Present, unique, uses kebab-case
- [ ] description: Clear and concise
- [ ] pattern: Valid regex pattern or tool reference
- [ ] scope: Appropriate scope defined (if applicable)
3. **Pattern Quality**
- [ ] Patterns are valid and testable
- [ ] Patterns are specific enough to match intended inputs
- [ ] Patterns are not overly restrictive
- [ ] Patterns use appropriate regex syntax
4. **Description Quality**
- [ ] Each item has clear description
- [ ] Descriptions explain what the item does
- [ ] Descriptions are consistent in style
- [ ] Descriptions help users understand when to use
5. **Alignment Checks**
- [ ] Menu items align with agent's role/purpose
- [ ] Menu items are supported by agent's expertise
- [ ] Menu items fit within agent's constraints
- [ ] Menu items are appropriate for target users
6. **Completeness**
- [ ] Core capabilities for this role are covered
- [ ] No obvious missing functionality
- [ ] Menu scope is appropriate (not too sparse/overloaded)
- [ ] Related functionality is grouped logically
7. **Standards Compliance**
- [ ] No prohibited patterns or commands
- [ ] No security vulnerabilities in patterns
- [ ] No ambiguous or conflicting items
- [ ] Consistent naming conventions
8. **Menu Link Validation (Agent Type Specific)**
- [ ] Determine agent type from metadata:
- Simple: module property is 'stand-alone' AND hasSidecar is false/absent
- Expert: hasSidecar is true
- Module: module property is a module code (e.g., 'bmm', 'bmb', 'bmgd', 'bmad')
- [ ] For Expert agents (hasSidecar: true):
- Menu handlers SHOULD reference external sidecar files (e.g., `./{agent-name}-sidecar/...`)
- OR have inline prompts defined directly in the handler
- [ ] For Module agents (module property is a module code):
- Menu handlers SHOULD reference external module files under the module path
- Exec paths must start with `{project-root}/_bmad/{module}/...`
- Verify referenced files exist under the module directory
- [ ] For Simple agents (stand-alone, no sidecar):
- Menu handlers MUST NOT have external file links
- Menu handlers SHOULD only use relative links within the same file (e.g., `#section-name`)
- OR have inline prompts defined directly in the handler
### 3. Append Findings to Report
@ -57,9 +122,18 @@ Append to `{validationReport}`:
- [ ] Command names clear and descriptive
- [ ] Command descriptions specific and actionable
- [ ] Menu handling logic properly specified
- [ ] Agent type appropriate menu links verified
**Findings:**
{Detailed findings}
**Detailed Findings:**
*PASSING:*
{List of passing checks}
*WARNINGS:*
{List of non-blocking issues}
*FAILURES:*
{List of blocking issues that must be fixed}
```
### 4. Auto-Advance

85
src/modules/bmb/workflows/agent/steps-v/v-02d-validate-structure.md
View File

@ -4,44 +4,98 @@ description: 'Validate YAML structure and append to report'
nextStepFile: './v-02e-validate-sidecar.md'
validationReport: '{bmb_creations_output_folder}/validation-report-{agent-name}.md'
simpleValidation: ../data/simple-agent-validation.md
expertValidation: ../data/expert-agent-validation.md
agentCompilation: ../data/agent-compilation.md
agentFile: '{agent-file-path}'
---
# Validate Step 2d: Validate Structure
## STEP GOAL:
## STEP GOAL
Validate the agent's YAML structure and completeness. Append findings to validation report and auto-advance.
Validate the agent's YAML structure and completeness against BMAD standards as defined in agentCompilation.md. Append findings to validation report and auto-advance.
## MANDATORY EXECUTION RULES:
## MANDATORY EXECUTION RULES
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read validationReport and agentCompilation first
- 🔄 CRITICAL: Load the actual agent file to validate structure
- 🚫 NO MENU - append findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate YAML structure and required fields
- 🎯 Validate structure against agentCompilation.md rules
- 📊 Append findings to validation report
- 🚫 FORBIDDEN to present menu
## EXECUTION PROTOCOLS:
## EXECUTION PROTOCOLS
- 🎯 Load agentCompilation.md reference
- 🎯 Load the actual agent file for validation
- 📊 Validate YAML structure
- 💾 Append findings to validation report
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load References
Read `{agentCompilation}` and `{validationReport}`.
Read `{agentCompilation}`, `{simpleValidation}`, `{expertValidation}`, `{validationReport}`, and `{agentFile}`.
### 2. Validate Structure
Perform checks on: YAML syntax, required fields, field types, indentation.
Perform these checks systematically - validate EVERY rule specified in agentCompilation.md:
#### A. YAML Syntax Validation
- [ ] Parse YAML without errors
- [ ] Check indentation consistency (2-space standard)
- [ ] Validate proper escaping of special characters
- [ ] Verify no duplicate keys in any section
#### B. Frontmatter Validation
- [ ] All required fields present (name, description, version, etc.)
- [ ] Field values are correct type (string, boolean, array)
- [ ] No empty required fields
- [ ] Proper array formatting with dashes
- [ ] Boolean fields are actual booleans (not strings)
#### C. Section Completeness
- [ ] All required sections present based on agent type
- [ ] Sections not empty unless explicitly optional
- [ ] Proper markdown heading hierarchy (##, ###)
- [ ] No orphaned content without section headers
#### D. Field-Level Validation
- [ ] Path references exist and are valid
- [ ] Array fields properly formatted
- [ ] No malformed YAML structures
- [ ] File references use correct path format
#### E. Agent Type Specific Checks
**For Simple Agents (hasSidecar is false/absent, module is 'stand-alone'):**
- [ ] No sidecar requirements
- [ ] No sidecar-folder path in metadata
- [ ] Basic fields complete
- [ ] No expert-only configuration present
- [ ] Menu handlers use only internal references (#) or inline prompts
**For Expert Agents (hasSidecar is true):**
- [ ] Sidecar flag set correctly in metadata
- [ ] Sidecar folder path specified in metadata
- [ ] All expert fields present
- [ ] Advanced features properly configured
- [ ] Menu handlers reference sidecar files or have inline prompts
**For Module Agents (module is a module code like 'bmm', 'bmb', etc.):**
- [ ] Module property is valid module code
- [ ] Exec paths for menu handlers start with `{project-root}/_bmad/{module}/...`
- [ ] Referenced files exist under the module directory
- [ ] If also hasSidecar: true, sidecar configuration is valid
### 3. Append Findings to Report
@ -52,14 +106,25 @@ Append to `{validationReport}`:
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
**Agent Type:** {simple|expert|module}
**Checks:**
- [ ] Valid YAML syntax
- [ ] Required fields present (name, description, type, persona)
- [ ] Field types correct (arrays, strings)
- [ ] Consistent 2-space indentation
- [ ] Agent type appropriate structure
**Findings:**
{Detailed findings}
**Detailed Findings:**
*PASSING:*
{List of passing checks}
*WARNINGS:*
{List of non-blocking issues}
*FAILURES:*
{List of blocking issues that must be fixed}
```
### 4. Auto-Advance

90
src/modules/bmb/workflows/agent/steps-v/v-02e-validate-sidecar.md
View File

@ -5,49 +5,94 @@ description: 'Validate sidecar structure and append to report'
nextStepFile: './v-03-summary.md'
validationReport: '{bmb_creations_output_folder}/validation-report-{agent-name}.md'
expertValidation: ../data/expert-agent-validation.md
criticalActions: ../data/critical-actions.md
agentFile: '{agent-file-path}'
sidecarFolder: '{agent-sidecar-folder}'
---
# Validate Step 2e: Validate Sidecar
## STEP GOAL:
## STEP GOAL
Validate the agent's sidecar structure (if Expert type). Append findings to validation report and auto-advance.
Validate the agent's sidecar structure (if Expert type) against BMAD standards as defined in expertValidation.md. Append findings to validation report and auto-advance.
## MANDATORY EXECUTION RULES:
## MANDATORY EXECUTION RULES
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read validationReport and expertValidation first
- 🔄 CRITICAL: Load the actual agent file to check for sidecar
- 🚫 NO MENU - append findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate sidecar structure for Expert agents
- 🎯 Validate sidecar against expertValidation.md rules (for Expert agents)
- 📊 Append findings to validation report
- 🚫 FORBIDDEN to present menu
## EXECUTION PROTOCOLS:
## EXECUTION PROTOCOLS
- 🎯 Load expertValidation.md reference
- 🎯 Load the actual agent file for validation
- 📊 Validate sidecar if Expert type, skip for Simple/Module
- 💾 Append findings to validation report
- ➡️ Auto-advance to summary step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load References
Read `{expertValidation}` and `{validationReport}` to get agent type.
Read `{expertValidation}`, `{criticalActions}`, `{validationReport}`, and `{agentFile}`.
### 2. Conditional Validation
**IF agentType == expert:**
- Check metadata.sidecar-folder present
- Check sidecar-path correct format
- Verify sidecar files exist
**IF (module = "stand-alone" AND hasSidecar = true) OR (module ≠ "stand-alone" AND hasSidecar = true):**
Perform these checks systematically - validate EVERY rule specified in expertValidation.md:
**IF agentType != expert:**
- Mark as N/A
#### A. Sidecar Folder Validation
- [ ] Sidecar folder exists at specified path
- [ ] Sidecar folder is accessible and readable
- [ ] Sidecar folder path in metadata matches actual location
- [ ] Folder naming follows convention: `{agent-name}-sidecar`
#### B. Sidecar File Inventory
- [ ] List all files in sidecar folder
- [ ] Verify expected files are present
- [ ] Check for unexpected files
- [ ] Validate file names follow conventions
#### C. Path Reference Validation
For each sidecar path reference in agent YAML:
- [ ] Extract path from YAML reference
- [ ] Verify file exists at referenced path
- [ ] Check path format is correct (relative/absolute as expected)
- [ ] Validate no broken path references
#### D. Critical Actions File Validation (if present)
- [ ] critical-actions.md file exists
- [ ] File has proper frontmatter
- [ ] Actions section is present and not empty
- [ ] No critical sections missing
- [ ] File content is complete (not just placeholder)
#### E. Module Files Validation (if present)
- [ ] Module files exist at referenced paths
- [ ] Each module file has proper frontmatter
- [ ] Module file content is complete
- [ ] No empty or placeholder module files
#### F. Sidecar Structure Completeness
- [ ] All referenced sidecar files present
- [ ] No orphaned references (files referenced but not present)
- [ ] No unreferenced files (files present but not referenced)
- [ ] File structure matches expert agent requirements
**IF (module = "stand-alone" AND hasSidecar = false):**
- [ ] Mark sidecar validation as N/A
- [ ] Confirm no sidecar-folder path in metadata
- [ ] Confirm no sidecar references in menu handlers
### 3. Append Findings to Report
@ -58,13 +103,28 @@ Append to `{validationReport}`:
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL / N/A}
**Agent Type:** {simple|expert|module with sidecar}
**Checks:**
- [ ] metadata.sidecar-folder present (Expert only)
- [ ] sidecar-path format correct
- [ ] Sidecar files exist at specified path
- [ ] All referenced files present
- [ ] No broken path references
**Findings:**
{Detailed findings or "N/A - Not an Expert agent"}
**Detailed Findings:**
*PASSING (for Expert agents):*
{List of passing checks}
*WARNINGS:*
{List of non-blocking issues}
*FAILURES:*
{List of blocking issues that must be fixed}
*N/A (for Simple agents):*
N/A - Agent is Simple type (module = "stand-alone" + hasSidecar: false, no sidecar required)
```
### 4. Auto-Advance

6
src/modules/bmb/workflows/agent/steps-v/v-03-summary.md
View File

@ -32,7 +32,9 @@ Display the complete validation report to the user and offer options for fixing
- 📊 Display organized summary
- 💾 Allow user to decide next steps
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Validation Report
@ -57,6 +59,7 @@ Read `{validationReport}` to collect all validation findings.
"What would you like to do?
**[E]dit Agent** - Launch edit workflow to fix issues or make improvements
**[F]ix in Place** - Confirm which fixes you would like right now and we can fix without loading the full agent edit workflow
**[S]ave Report** - Save this validation report and exit
**[R]etry** - Run validation again (if you've made external changes)"
@ -69,6 +72,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [E] Edit
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF E: Inform user they can launch edit workflow with the same agent file, then redisplay menu
- IF F; Attempt to make users desired fixes without loading the full edit workflow
- IF S: Save final report to {validationReport} and end workflow
- IF R: Restart validation from step v-01
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)

1
src/modules/bmb/workflows/agent/templates/expert-agent-template/expert-agent.template.md
View File

@ -12,6 +12,7 @@ agent:
title: {{agent_title}}
icon: {{agent_icon}}
module: {{agent_module}}{{#if agent_module_comment}} {{!-- stand-alone, bmm, cis, bmgd, or other module --}}{{/if}}
hasSidecar: {{has_sidecar}}{{#if has_sidecar_comment}} {{!-- true if agent has a sidecar folder, false otherwise --}}{{/if}}
persona:
role: |

1
src/modules/bmb/workflows/agent/templates/simple-agent.template.md
View File

@ -12,6 +12,7 @@ agent:
title: {{agent_title}}
icon: {{agent_icon}}
module: {{agent_module}}{{#if agent_module_comment}} {{!-- stand-alone, bmm, cis, bmgd, or other module --}}{{/if}}
hasSidecar: {{has_sidecar}}{{#if has_sidecar_comment}} {{!-- true if agent has a sidecar folder, false otherwise --}}{{/if}}
persona:
role: |

158
src/modules/bmb/workflows/create-workflow/steps/step-01-init.md
View File

@ -1,158 +0,0 @@
---
name: 'step-01-init'
description: 'Initialize workflow creation session by gathering project information and setting up unique workflow folder'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
# File References
thisStepFile: '{workflow_path}/steps/step-01-init.md'
nextStepFile: '{workflow_path}/steps/step-02-gather.md'
workflowFile: '{workflow_path}/workflow.md'
# Output files for workflow creation process
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
# Template References
# No workflow plan template needed - will create plan file directly
---
# Step 1: Workflow Creation Initialization
## STEP GOAL:
To initialize the workflow creation process by understanding project context, determining a unique workflow name, and preparing for collaborative workflow design.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a workflow architect and systems designer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring workflow design expertise, user brings their specific requirements
- ✅ Together we will create a structured, repeatable workflow
### Step-Specific Rules:
- 🎯 Focus ONLY on initialization and project understanding
- 🚫 FORBIDDEN to start designing workflow steps in this step
- 💬 Ask questions conversationally to understand context
- 🚪 ENSURE unique workflow naming to avoid conflicts
## EXECUTION PROTOCOLS:
- 🎯 Show analysis before taking any action
- 💾 Initialize document and update frontmatter
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
- 🚫 FORBIDDEN to load next step until initialization is complete
## CONTEXT BOUNDARIES:
- Variables from workflow.md are available in memory
- Previous context = what's in output document + frontmatter
- Don't assume knowledge from other steps
- Input discovery happens in this step
## INITIALIZATION SEQUENCE:
### 1. Project Discovery
Welcome the user and understand their needs:
"Welcome! I'm excited to help you create a new workflow. Let's start by understanding what you want to build."
Ask conversationally:
- What type of workflow are you looking to create?
- What problem will this workflow solve?
- Who will use this workflow?
- What module will it belong to (bmb, bmm, cis, custom, stand-alone)?
Also, Ask / suggest a workflow name / folder: (kebab-case, e.g., "user-story-generator")
### 2. Ensure Unique Workflow Name
After getting the workflow name:
**Check for existing workflows:**
- Look for folder at `{bmb_creations_output_folder}/workflows/{new_workflow_name}/`
- If it exists, inform the user and suggest or get from them a unique name or postfix
**Example alternatives:**
- Original: "user-story-generator"
- Alternatives: "user-story-creator", "user-story-generator-2025", "user-story-generator-enhanced"
**Loop until we have a unique name that doesn't conflict.**
### 3. Determine Target Location
Based on the module selection, confirm the target location:
- For bmb module: `{custom_workflow_location}` (defaults to `_bmad/custom/src/workflows`)
- For other modules: Check their module.yaml for custom workflow locations
- Confirm the exact folder path where the workflow will be created
- Store the confirmed path as `{targetWorkflowPath}`
### 4. Create Workflow Plan Document
Create the workflow plan document at `{workflowPlanFile}` with the following initial content:
```markdown
---
stepsCompleted: [1]
---
# Workflow Creation Plan: {new_workflow_name}
## Initial Project Context
- **Module:** [module from user]
- **Target Location:** {targetWorkflowPath}
- **Created:** [current date]
```
This plan will capture all requirements and design details before building the actual workflow.
### 5. Present MENU OPTIONS
Display: **Proceeding to requirements gathering...**
#### EXECUTION RULES:
- This is an initialization step with no user choices
- Proceed directly to next step after setup
- Use menu handling logic section below
#### Menu Handling Logic:
- After setup completion and the workflow folder with the workflow plan file created already, only then immediately load, read entire file, and then execute `{workflow_path}/steps/step-02-gather.md` to begin requirements gathering
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Workflow name confirmed and validated
- Target folder location determined
- User welcomed and project context understood
- Ready to proceed to step 2
### ❌ SYSTEM FAILURE:
- Proceeding with step 2 without workflow name
- Not checking for existing workflow folders
- Not determining target location properly
- Skipping welcome message
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

212
src/modules/bmb/workflows/create-workflow/steps/step-02-gather.md
View File

@ -1,212 +0,0 @@
---
name: 'step-02-gather'
description: 'Gather comprehensive requirements for the workflow being created'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
# File References
thisStepFile: '{workflow_path}/steps/step-02-gather.md'
nextStepFile: '{workflow_path}/steps/step-03-tools-configuration.md'
# Output files for workflow creation process
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# Template References
# No template needed - will append requirements directly to workflow plan
---
# Step 2: Requirements Gathering
## STEP GOAL:
To gather comprehensive requirements through collaborative conversation that will inform the design of a structured workflow tailored to the user's needs and use case.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a workflow architect and systems designer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring workflow design expertise and best practices
- ✅ User brings their domain knowledge and specific requirements
### Step-Specific Rules:
- 🎯 Focus ONLY on collecting requirements and understanding needs
- 🚫 FORBIDDEN to propose workflow solutions or step designs in this step
- 💬 Ask questions conversationally, not like a form
- 🚫 DO NOT skip any requirement area - each affects workflow design
## EXECUTION PROTOCOLS:
- 🎯 Engage in natural conversation to gather requirements
- 💾 Store all requirements information for workflow design
- 📖 Proceed to next step with 'C' selection
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Workflow name and target location from initialization
- Focus ONLY on collecting requirements and understanding needs
- Don't provide workflow designs in this step
- This is about understanding, not designing
## REQUIREMENTS GATHERING PROCESS:
### 1. Workflow Purpose and Scope
Explore through conversation:
- What specific problem will this workflow solve?
- Who is the primary user of this workflow?
- What is the main outcome or deliverable?
### 2. Workflow Type Classification
Help determine the workflow type:
- **Document Workflow**: Generates documents (PRDs, specs, plans)
- **Action Workflow**: Performs actions (refactoring, tools orchestration)
- **Interactive Workflow**: Guided sessions (brainstorming, coaching, training, practice)
- **Autonomous Workflow**: Runs without human input (batch processing, multi-step tasks)
- **Meta-Workflow**: Coordinates other workflows
### 3. Workflow Flow and Step Structure
Let's load some examples to help you decide the workflow pattern:
Load and reference the Meal Prep & Nutrition Plan workflow as an example:
```
Read: {project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/workflow.md
```
This shows a linear workflow structure. Now let's explore your desired pattern:
- Should this be a linear workflow (step 1 → step 2 → step 3 → finish)?
- Or should it have loops/repeats (e.g., keep generating items until user says done)?
- Are there branching points based on user choices?
- Should some steps be optional?
- How many logical phases does this workflow need? (e.g., Gather → Design → Validate → Generate)
**Based on our reference examples:**
- **Linear**: Like Meal Prep Plan (Init → Profile → Assessment → Strategy → Shopping → Prep)
- See: `{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/`
- **Looping**: User Story Generator (Generate → Review → Refine → Generate more... until done)
- **Branching**: Architecture Decision (Analyze → Choose pattern → Implement based on choice)
- **Iterative**: Document Review (Load → Analyze → Suggest changes → Implement → Repeat until approved)
### 4. User Interaction Style
Understand the desired interaction level:
- How much user input is needed during execution?
- Should it be highly collaborative or mostly autonomous?
- Are there specific decision points where user must choose?
- Should the workflow adapt to user responses?
### 5. Instruction Style (Intent-Based vs Prescriptive)
Determine how the AI should execute in this workflow:
**Intent-Based (Recommended for most workflows)**:
- Steps describe goals and principles, letting the AI adapt conversation naturally
- More flexible, conversational, responsive to user context
- Example: "Guide user to define their requirements through open-ended discussion"
**Prescriptive**:
- Steps provide exact instructions and specific text to use
- More controlled, predictable, consistent across runs
- Example: "Ask: 'What is your primary goal? Choose from: A) Growth B) Efficiency C) Quality'"
Which style does this workflow need, or should it be a mix of both?
### 6. Input Requirements
Identify what the workflow needs:
- What documents or data does the workflow need to start?
- Are there prerequisites or dependencies?
- Will users need to provide specific information?
- Are there optional inputs that enhance the workflow?
### 7. Output Specifications
Define what the workflow produces:
- What is the primary output (document, action, decision)?
- Are there intermediate outputs or checkpoints?
- Should outputs be saved automatically?
- What format should outputs be in?
### 8. Success Criteria
Define what makes the workflow successful:
- How will you know the workflow achieved its goal?
- What are the quality criteria for outputs?
- Are there measurable outcomes?
- What would make a user satisfied with the result?
#### STORE REQUIREMENTS:
After collecting all requirements, append them to {workflowPlanFile} in a format that will be be used later to design in more detail and create the workflow structure.
### 9. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}
- IF P: Execute {partyModeWorkflow}
- IF C: Append requirements to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and requirements are stored in the output file, will you then load, read entire file, then execute {nextStepFile} to execute and begin workflow structure design step.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Requirements collected through conversation (not interrogation)
- All workflow aspects documented
- Requirements stored using template
- Menu presented and user input handled correctly
### ❌ SYSTEM FAILURE:
- Generating workflow designs without requirements
- Skipping requirement areas
- Proceeding to next step without 'C' selection
- Not storing requirements properly
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

251
src/modules/bmb/workflows/create-workflow/steps/step-03-tools-configuration.md
View File

@ -1,251 +0,0 @@
---
name: 'step-03-tools-configuration'
description: 'Configure all required tools (core, memory, external) and installation requirements in one comprehensive step'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
# File References
thisStepFile: '{workflow_path}/steps/step-03-tools-configuration.md'
nextStepFile: '{workflow_path}/steps/step-04-plan-review.md'
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
# Documentation References
commonToolsCsv: '{project-root}/_bmad/bmb/docs/workflows/common-workflow-tools.csv'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# Template References
# No template needed - will append tools configuration directly to workflow plan
---
# Step 3: Tools Configuration
## STEP GOAL:
To comprehensively configure all tools needed for the workflow (core tools, memory, external tools) and determine installation requirements.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a workflow architect and integration specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD tools and integration patterns
- ✅ User brings their workflow requirements and preferences
### Step-Specific Rules:
- 🎯 Focus ONLY on configuring tools based on workflow requirements
- 🚫 FORBIDDEN to skip tool categories - each affects workflow design
- 💬 Present options clearly, let user make informed choices
- 🚫 DO NOT hardcode tool descriptions - reference CSV
## EXECUTION PROTOCOLS:
- 🎯 Load tools dynamically from CSV, not hardcoded
- 💾 Document all tool choices in workflow plan
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Requirements from step 2 inform tool selection
- All tool choices affect workflow design
- This is the ONLY tools configuration step
- Installation requirements affect implementation decisions
## TOOLS CONFIGURATION PROCESS:
### 1. Initialize Tools Configuration
"Configuring **Tools and Integrations**
Based on your workflow requirements, let's configure all the tools your workflow will need. This includes core BMAD tools, memory systems, and any external integrations."
### 2. Load and Present Available Tools
Load `{commonToolsCsv}` and present tools by category:
"**Available BMAD Tools and Integrations:**
**Core Tools (Always Available):**
- [List tools from CSV where propose='always', with descriptions]
**Optional Tools (Available When Needed):**
- [List tools from CSV where propose='example', with descriptions]
_Note: I'm loading these dynamically from our tools database to ensure you have the most current options._"
### 3. Configure Core BMAD Tools
"**Core BMAD Tools Configuration:**
These tools significantly enhance workflow quality and user experience:"
For each core tool from CSV (`propose='always'`):
1. **Party-Mode**
- Use case: [description from CSV]
- Where to integrate: [ask user for decision points, creative phases]
2. **Advanced Elicitation**
- Use case: [description from CSV]
- Where to integrate: [ask user for quality gates, review points]
3. **Brainstorming**
- Use case: [description from CSV]
- Where to integrate: [ask user for idea generation, innovation points]
### 4. Configure LLM Features
"**LLM Feature Integration:**
These capabilities enhance what your workflow can do:"
From CSV (`propose='always'` LLM features):
4. **Web-Browsing**
- Capability: [description from CSV]
- When needed: [ask user about real-time data needs]
5. **File I/O**
- Capability: [description from CSV]
- Operations: [ask user about file operations needed]
6. **Sub-Agents**
- Capability: [description from CSV]
- Use cases: [ask user about delegation needs]
7. **Sub-Processes**
- Capability: [description from CSV]
- Use cases: [ask user about parallel processing needs]
### 5. Configure Memory Systems
"**Memory and State Management:**
Determine if your workflow needs to maintain state between sessions:"
From CSV memory tools:
8. **Sidecar File**
- Use case: [description from CSV]
- Needed when: [ask about session continuity, agent initialization]
### 6. Configure External Tools (Optional)
"**External Integrations (Optional):**
These tools connect your workflow to external systems:"
From CSV (`propose='example'`):
- MCP integrations, database connections, APIs, etc.
- For each relevant tool: present description and ask if needed
- Note any installation requirements
### 7. Installation Requirements Assessment
"**Installation and Dependencies:**
Some tools require additional setup:"
Based on selected tools:
- Identify tools requiring installation
- Assess user's comfort level with installations
- Document installation requirements
### 8. Document Complete Tools Configuration
Append to {workflowPlanFile}:
```markdown
## Tools Configuration
### Core BMAD Tools
- **Party-Mode**: [included/excluded] - Integration points: [specific phases]
- **Advanced Elicitation**: [included/excluded] - Integration points: [specific phases]
- **Brainstorming**: [included/excluded] - Integration points: [specific phases]
### LLM Features
- **Web-Browsing**: [included/excluded] - Use cases: [specific needs]
- **File I/O**: [included/excluded] - Operations: [file management needs]
- **Sub-Agents**: [included/excluded] - Use cases: [delegation needs]
- **Sub-Processes**: [included/excluded] - Use cases: [parallel processing needs]
### Memory Systems
- **Sidecar File**: [included/excluded] - Purpose: [state management needs]
### External Integrations
- [List selected external tools with purposes]
### Installation Requirements
- [List tools requiring installation]
- **User Installation Preference**: [willing/not willing]
- **Alternative Options**: [if not installing certain tools]
```
### 9. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}
- IF P: Execute {partyModeWorkflow}
- IF C: Save tools configuration to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#9-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and tools configuration is saved will you load {nextStepFile} to review the complete plan.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All tool categories configured based on requirements
- User made informed choices for each tool
- Complete configuration documented in plan
- Installation requirements identified
- Ready to proceed to plan review
### ❌ SYSTEM FAILURE:
- Skipping tool categories
- Hardcoding tool descriptions instead of using CSV
- Not documenting user choices
- Proceeding without user confirmation
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

217
src/modules/bmb/workflows/create-workflow/steps/step-04-plan-review.md
View File

@ -1,217 +0,0 @@
---
name: 'step-04-plan-review'
description: 'Review complete workflow plan (requirements + tools) and get user approval before design'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
# File References
thisStepFile: '{workflow_path}/steps/step-04-plan-review.md'
nextStepFormDesign: '{workflow_path}/steps/step-05-output-format-design.md'
nextStepDesign: '{workflow_path}/steps/step-06-design.md'
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# Template References
# No template needed - will append review summary directly to workflow plan
---
# Step 4: Plan Review and Approval
## STEP GOAL:
To present the complete workflow plan (requirements and tools configuration) for user review and approval before proceeding to design.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a workflow architect and systems designer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in workflow design review and quality assurance
- ✅ User brings their specific requirements and approval authority
### Step-Specific Rules:
- 🎯 Focus ONLY on reviewing and refining the plan
- 🚫 FORBIDDEN to start designing workflow steps in this step
- 💬 Present plan clearly and solicit feedback
- 🚫 DO NOT proceed to design without user approval
## EXECUTION PROTOCOLS:
- 🎯 Present complete plan summary from {workflowPlanFile}
- 💾 Capture any modifications or refinements
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
- 🚫 FORBIDDEN to load next step until user approves plan
## CONTEXT BOUNDARIES:
- All requirements from step 2 are available
- Tools configuration from step 3 is complete
- Focus ONLY on review and approval
- This is the final check before design phase
## PLAN REVIEW PROCESS:
### 1. Initialize Plan Review
"**Workflow Plan Review**
We've gathered all requirements and configured tools for your workflow. Let's review the complete plan to ensure it meets your needs before we start designing the workflow structure."
### 2. Present Complete Plan Summary
Load and present from {workflowPlanFile}:
"**Complete Workflow Plan: {new_workflow_name}**
**1. Project Overview:**
- [Present workflow purpose, user type, module from plan]
**2. Workflow Requirements:**
- [Present all gathered requirements]
**3. Tools Configuration:**
- [Present selected tools and integration points]
**4. Technical Specifications:**
- [Present technical constraints and requirements]
**5. Success Criteria:**
- [Present success metrics from requirements]"
### 3. Detailed Review by Category
"**Detailed Review:**
**A. Workflow Scope and Purpose**
- Is the workflow goal clearly defined?
- Are the boundaries appropriate?
- Any missing requirements?
**B. User Interaction Design**
- Does the interaction style match your needs?
- Are collaboration points clear?
- Any adjustments needed?
**C. Tools Integration**
- Are selected tools appropriate for your workflow?
- Are integration points logical?
- Any additional tools needed?
**D. Technical Feasibility**
- Are all requirements achievable?
- Any technical constraints missing?
- Installation requirements acceptable?"
### 4. Collect Feedback and Refinements
"**Review Feedback:**
Please review each section and provide feedback:
1. What looks good and should stay as-is?
2. What needs modification or refinement?
3. What's missing that should be added?
4. Anything unclear or confusing?"
For each feedback item:
- Document the requested change
- Discuss implications on workflow design
- Confirm the refinement with user
### 5. Update Plan with Refinements
Update {workflowPlanFile} with any approved changes:
- Modify requirements section as needed
- Update tools configuration if changed
- Add any missing specifications
- Ensure all changes are clearly documented
### 6. Output Document Check
"**Output Document Check:**
Before we proceed to design, does your workflow produce any output documents or files?
Based on your requirements:
- [Analyze if workflow produces documents/files]
- Consider: Does it create reports, forms, stories, or any persistent output?"
**If NO:**
"Great! Your workflow focuses on actions/interactions without document output. We'll proceed directly to designing the workflow steps."
**If YES:**
"Perfect! Let's design your output format to ensure your workflow produces exactly what you need."
### 7. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Design
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}
- IF P: Execute {partyModeWorkflow}
- IF C: Check if workflow produces documents:
- If YES: Update frontmatter, then load nextStepFormDesign
- If NO: Update frontmatter, then load nextStepDesign
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected AND the user has explicitly approved the plan and the plan document is updated as needed, then you load either {nextStepFormDesign} or {nextStepDesign}
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Complete plan presented clearly from {workflowPlanFile}
- User feedback collected and documented
- All refinements incorporated
- User explicitly approves the plan
- Plan ready for design phase
### ❌ SYSTEM FAILURE:
- Not loading plan from {workflowPlanFile}
- Skipping review categories
- Proceeding without user approval
- Not documenting refinements
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

290
src/modules/bmb/workflows/create-workflow/steps/step-05-output-format-design.md
View File

@ -1,290 +0,0 @@
---
name: 'step-05-output-format-design'
description: 'Design the output format for workflows that produce documents or files'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
# File References
thisStepFile: '{workflow_path}/steps/step-05-output-format-design.md'
nextStepFile: '{workflow_path}/steps/step-06-design.md'
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 5: Output Format Design
## STEP GOAL:
To design and document the output format for workflows that produce documents or files, determining whether they need strict templates or flexible formatting.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a workflow architect and output format specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in document design and template creation
- ✅ User brings their specific output requirements and preferences
### Step-Specific Rules:
- 🎯 Focus ONLY on output format design
- 🚫 FORBIDDEN to design workflow steps in this step
- 💬 Help user understand the format spectrum
- 🚫 DO NOT proceed without clear format requirements
## EXECUTION PROTOCOLS:
- 🎯 Guide user through format spectrum with examples
- 💾 Document format decisions in workflow plan
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Approved plan from step 4 is available
- Focus ONLY on output document formatting
- Skip this step if workflow produces no documents
- This step only runs when documents need structure
## OUTPUT FORMAT DESIGN PROCESS:
### 1. Initialize Output Format Discussion
"**Designing Your Output Format**
Based on your approved plan, your workflow will produce output documents. Let's design how these outputs should be formatted."
### 2. Present the Format Spectrum
"**Output Format Spectrum - Where does your workflow fit?**
**Strictly Structured Examples:**
- Government forms - exact fields, precise positions
- Legal documents - must follow specific templates
- Technical specifications - required sections, specific formats
- Compliance reports - mandatory fields, validation rules
**Structured Examples:**
- Project reports - required sections, flexible content
- Business proposals - consistent format, customizable sections
- Technical documentation - standard structure, adaptable content
- Research papers - IMRAD format, discipline-specific variations
**Semi-structured Examples:**
- Character sheets (D&D) - core stats + flexible background
- Lesson plans - required components, flexible delivery
- Recipes - ingredients/method format, flexible descriptions
- Meeting minutes - agenda/attendees/actions, flexible details
**Free-form Examples:**
- Creative stories - narrative flow, minimal structure
- Blog posts - title/body, organic organization
- Personal journals - date/entry, free expression
- Brainstorming outputs - ideas, flexible organization"
### 3. Determine Format Type
"**Which format type best fits your workflow?**
1. **Strict Template** - Must follow exact format with specific fields
2. **Structured** - Required sections but flexible within each
3. **Semi-structured** - Core sections plus optional additions
4. **Free-form** - Content-driven with minimal structure
Please choose 1-4:"
### 4. Deep Dive Based on Choice
#### IF Strict Template (Choice 1):
"**Strict Template Design**
You need exact formatting. Let's define your requirements:
**Template Source Options:**
A. Upload existing template/image to follow
B. Create new template from scratch
C. Use standard form (e.g., government, industry)
D. AI proposes template based on your needs
**Template Requirements:**
- Exact field names and positions
- Required vs optional fields
- Validation rules
- File format (PDF, DOCX, etc.)
- Any legal/compliance considerations"
#### IF Structured (Choice 2):
"**Structured Document Design**
You need consistent sections with flexibility:
**Section Definition:**
- What sections are required?
- Any optional sections?
- Section ordering rules?
- Cross-document consistency needs?
**Format Guidelines:**
- Any formatting standards (APA, MLA, corporate)?
- Section header styles?
- Content organization principles?"
#### IF Semi-structured (Choice 3):
"**Semi-structured Design**
Core sections with flexibility:
**Core Components:**
- What information must always appear?
- Which parts can vary?
- Any organizational preferences?
**Polishing Options:**
- Would you like automatic TOC generation?
- Summary section at the end?
- Consistent formatting options?"
#### IF Free-form (Choice 4):
"**Free-form Content Design**
Focus on content with minimal structure:
**Organization Needs:**
- Basic headers for readability?
- Date/title information?
- Any categorization needs?
**Final Polish Options:**
- Auto-generated summary?
- TOC based on content?
- Formatting for readability?"
### 5. Template Creation (if applicable)
For Strict/Structured workflows:
"**Template Creation Approach:**
A. **Design Together** - We'll create the template step by step
B. **AI Proposes** - I'll suggest a structure based on your needs
C. **Import Existing** - Use/upload your existing template
Which approach would you prefer?"
If A or B:
- Design/create template sections
- Define placeholders
- Specify field types and validation
- Document template structure in plan
If C:
- Request file upload or detailed description
- Analyze template structure
- Document requirements
### 6. Document Format Decisions
Append to {workflowPlanFile}:
```markdown
## Output Format Design
**Format Type**: [Strict/Structured/Semi-structured/Free-form]
**Output Requirements**:
- Document type: [report/form/story/etc]
- File format: [PDF/MD/DOCX/etc]
- Frequency: [single/batch/continuous]
**Structure Specifications**:
[Detailed structure based on format type]
**Template Information**:
- Template source: [created/imported/standard]
- Template file: [path if applicable]
- Placeholders: [list if applicable]
**Special Considerations**:
- Legal/compliance requirements
- Validation needs
- Accessibility requirements
```
### 7. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}
- IF P: Execute {partyModeWorkflow}
- IF C: Save output format design to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and output format is documented will you load {nextStepFile} to begin workflow step design.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- User understands format spectrum
- Format type clearly identified
- Template requirements documented (if applicable)
- Output format saved in plan
### ❌ SYSTEM FAILURE:
- Not showing format examples
- Skipping format requirements
- Not documenting decisions in plan
- Assuming format without asking
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

323
src/modules/bmb/workflows/create-workflow/steps/step-07-build.md
View File

@ -1,323 +0,0 @@
---
name: 'step-07-build'
description: 'Generate all workflow files based on the approved plan'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
# File References
thisStepFile: '{workflow_path}/steps/step-07-build.md'
nextStepFile: '{workflow_path}/steps/step-08-review.md'
workflowFile: '{workflow_path}/workflow.md'
# Output files for workflow creation process
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
# Template References
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
stepInitContinuableTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-01-init-continuable-template.md'
step1bTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-1b-template.md'
# No content templates needed - will create content as needed during build
# No build summary template needed - will append summary directly to workflow plan
---
# Step 7: Workflow File Generation
## STEP GOAL:
To generate all the workflow files (workflow.md, step files, templates, and supporting files) based on the approved plan from the previous design step.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a workflow architect and systems designer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring implementation expertise and best practices
- ✅ User brings their specific requirements and design approvals
### Step-Specific Rules:
- 🎯 Focus ONLY on generating files based on approved design
- 🚫 FORBIDDEN to modify the design without user consent
- 💬 Generate files collaboratively, getting approval at each stage
- 🚪 CREATE files in the correct target location
## EXECUTION PROTOCOLS:
- 🎯 Generate files systematically from design
- 💾 Document all generated files and their locations
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C' and build is complete
## CONTEXT BOUNDARIES:
- Approved plan from step 6 guides implementation
- Generate files in target workflow location
- Load templates and documentation as needed during build
- Follow step-file architecture principles
## BUILD REFERENCE MATERIALS:
- When building each step file, you must follow template `{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md`
- When building continuable step-01-init.md files, use template `{project-root}/_bmad/bmb/docs/workflows/templates/step-01-init-continuable-template.md`
- When building continuation steps, use template `{project-root}/_bmad/bmb/docs/workflows/templates/step-1b-template.md`
- When building the main workflow.md file, you must follow template `{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md`
- Example step files from {project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/workflow.md for patterns - this is an idealized workflow so all files can give good insight into format and structure to be followed
## FILE GENERATION SEQUENCE:
### 1. Confirm Build Readiness
Based on the approved plan, confirm:
"I have your approved plan and I'm ready to generate the workflow files. The plan specifies creating:
- Main workflow.md file
- [Number] step files
- [Number] templates
- Supporting files
All in: {targetWorkflowPath}
Ready to proceed?"
### 2. Create Directory Structure
Create the workflow folder structure in the target location:
```
{bmb_creations_output_folder}/workflows/{workflow_name}/
├── workflow.md
├── steps/
│ ├── step-01-init.md
│ ├── step-01b-continue.md (if continuation support needed)
│ ├── step-02-[name].md
│ └── ...
├── templates/
│ └── [as needed]
└── data/
└── [as needed]
```
For bmb module, this will be: `_bmad/custom/src/workflows/{workflow_name}/`
For other modules, check their module.yaml for custom_workflow_location
### 3. Generate workflow.md
Load and follow {workflowTemplate}:
- Create workflow.md using template structure
- Insert workflow name and description
- Configure all path variables ({project-root}, _bmad, {workflow_path})
- Set web_bundle flag to true unless user has indicated otherwise
- Define role and goal
- Include initialization path to step-01
### 4. Generate Step Files
#### 4a. Check for Continuation Support
**Check the workflow plan for continuation support:**
- Look for "continuation support: true" or similar flag
- Check if step-01b-continue.md was included in the design
- If workflow generates output documents, continuation is typically needed
#### 4b. Generate step-01-init.md (with continuation logic)
If continuation support is needed:
- Load and follow {stepInitContinuableTemplate}
- This template automatically includes all required continuation detection logic
- Customize with workflow-specific information:
- Update workflow_path references
- Set correct outputFile and templateFile paths
- Adjust role and persona to match workflow type
- Customize welcome message for workflow context
- Configure input document discovery patterns (if any)
- Template automatically handles:
- continueFile reference in frontmatter
- Logic to check for existing output files with stepsCompleted
- Routing to step-01b-continue.md for continuation
- Fresh workflow initialization
#### 4c. Generate step-01b-continue.md (if needed)
**If continuation support is required:**
- Load and follow {step1bTemplate}
- Customize with workflow-specific information:
- Update workflow_path references
- Set correct outputFile path
- Adjust role and persona to match workflow type
- Customize welcome back message for workflow context
- Ensure proper nextStep detection logic based on step numbers
#### 4d. Generate Remaining Step Files
For each remaining step in the design:
- Load and follow {stepTemplate}
- Create step file using template structure
- Customize with step-specific content
- Ensure proper frontmatter with path references
- Include appropriate menu handling and universal rules
- Follow all mandatory rules and protocols from template
- **Critical**: Ensure each step updates `stepsCompleted` array when completing
### 5. Generate Templates (If Needed)
For document workflows:
- Create template.md with proper structure
- Include all variables from design
- Ensure variable naming consistency
Remember that the output format design we aligned on chose one of the following - and what it means practically when creating the workflow steps:
1. **Strict Template** - Must follow exact format with specific fields
1. This is similar to the example where there are multiple template fragements that are specific with all fields to be in the final output.
2. generally there will be 1 fragment to a step to complete in the overall template.
2. **Structured** - Required sections but flexible within each
1. Usually there will just be one template file - and in this mode it lists out all the section headings (generally level 2 sections in the md) with a handlebars style placeholder for each section.
2. Step files responsible for a specific section will upon user Continue of that step ensure output is written to the templates proper section
3. **Semi-structured** - Core sections plus optional additions
1. Similar to the prior 2, but not all sections or content are listed in the template, some steps might offer various paths or options to go to different steps (or variance within a step) that can determine what sections end up in the final document
4. **Free-form** - Content-driven with minimal structure
1. These are the easiest and most flexible. The single template usually only has the front matter fence with a stepsCompleted array and maybe some other fields, and outside of the front matter just the level 1 doc title
2. With free form, any step that could produce content just appends to the end of the document, so its progressively build in the order of ste[s completed.
3. Its good to have in this type of workflow a final polish output doc type step that cohesively can update the doc built up in this progressive manner, improving flow, reducing duplication, and ensure all information is aligned and where it belongs.
### 6. Generate Supporting Files
Based on design requirements:
- Create data files (csv)
- Generate README.md with usage instructions
- Create any configuration files
- Add validation checklists if designed
### 7. Verify File Generation
After creating all files:
- Check all file paths are correct
- Validate frontmatter syntax
- Ensure variable consistency across files
- Confirm sequential step numbering
- Verify menu handling logic
### 8. Document Generated Files
Create a summary of what was generated:
- List all files created with full paths
- Note any customizations from templates
- Identify any manual steps needed
- Provide next steps for testing
## QUALITY CHECKS DURING BUILD:
### Frontmatter Validation
- All YAML syntax is correct
- Required fields are present
- Path variables use correct format
- No hardcoded paths exist
### Step File Compliance
- Each step follows the template structure
- All mandatory rules are included
- Menu handling is properly implemented
- Step numbering is sequential
### Cross-File Consistency
- Variable names match across files
- Path references are consistent
- Dependencies are correctly defined
- No orphaned references exist
## BUILD PRINCIPLES:
### Follow Design Exactly
- Implement the design as approved
- Don't add or remove steps without consultation
- Maintain the interaction patterns designed
- Preserve the data flow architecture
### Maintain Best Practices
- Keep step files focused and reasonably sized (typically 5-10KB)
- Use collaborative dialogue patterns
- Include proper error handling
- Follow naming conventions
### Ensure Extensibility
- Design for future modifications
- Include clear documentation
- Make code readable and maintainable
- Provide examples where helpful
## CONTENT TO APPEND TO PLAN:
After generating all files, append to {workflowPlanFile}:
Create a build summary including:
- List of all files created with full paths
- Any customizations from templates
- Manual steps needed
- Next steps for testing
### 9. Present MENU OPTIONS
Display: **Build Complete - Select an Option:** [C] Continue to Review
#### EXECUTION RULES:
- Build complete - all files generated
- Present simple completion status
- User selects [C] to continue to review step
#### Menu Handling Logic:
- IF C: Save build summary to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: respond and redisplay menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and content is saved to plan and frontmatter is updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin workflow review step.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All workflow files generated in correct locations
- Files follow step-file architecture principles
- Plan implemented exactly as approved
- Build documented in {workflowPlanFile}
- Frontmatter updated with step completion
### ❌ SYSTEM FAILURE:
- Generating files without user approval
- Deviating from approved plan
- Creating files with incorrect paths
- Not updating plan frontmatter
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

285
src/modules/bmb/workflows/create-workflow/steps/step-08-review.md
View File

@ -1,285 +0,0 @@
---
name: 'step-08-review'
description: 'Review the generated workflow and provide final validation and next steps'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
# File References
thisStepFile: '{workflow_path}/steps/step-08-review.md'
workflowFile: '{workflow_path}/workflow.md'
# Output files for workflow creation process
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# Template References
# No review template needed - will append review summary directly to workflow plan
# No completion template needed - will append completion details directly
# Next step reference
nextStepFile: '{workflow_path}/steps/step-09-complete.md'
---
# Step 8: Workflow Review and Completion
## STEP GOAL:
To review the generated workflow for completeness, accuracy, and adherence to best practices, then provide next steps for deployment and usage.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Always read the complete step file before taking any action
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a workflow architect and systems designer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring quality assurance expertise and validation knowledge
- ✅ User provides final approval and feedback
### Step-Specific Rules:
- 🎯 Focus ONLY on reviewing and validating generated workflow
- 🚫 FORBIDDEN to make changes without user approval
- 💬 Guide review process collaboratively
- 🚪 COMPLETE the workflow creation process
## EXECUTION PROTOCOLS:
- 🎯 Conduct thorough review of generated workflow
- 💾 Document review findings and completion status
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]` and mark complete
- 🚫 This is the final step - no next step to load
## CONTEXT BOUNDARIES:
- Generated workflow files are available for review
- Focus on validation and quality assurance
- This step completes the workflow creation process
- No file modifications without explicit user approval
## WORKFLOW REVIEW PROCESS:
### 1. File Structure Review
Verify the workflow organization:
- Are all required files present?
- Is the directory structure correct?
- Are file names following conventions?
- Are paths properly configured?
### 2. Configuration Validation
Check workflow.yaml:
- Is all metadata correctly filled?
- Are path variables properly formatted?
- Is the standalone property set correctly?
- Are all dependencies declared?
### 3. Step File Compliance
Review each step file:
- Does each step follow the template structure?
- Are all mandatory rules included?
- Is menu handling properly implemented?
- Are frontmatter variables correct?
- Are steps properly numbered?
### 4. Cross-File Consistency
Verify integration between files:
- Do variable names match across all files?
- Are path references consistent?
- Is the step sequence logical?
- Are there any broken references?
### 5. Requirements Verification
Confirm original requirements are met:
- Does the workflow address the original problem?
- Are all user types supported?
- Are inputs and outputs as specified?
- Is the interaction style as designed?
### 6. Best Practices Adherence
Check quality standards:
- Are step files focused and reasonably sized (5-10KB typical)?
- Is collaborative dialogue implemented?
- Is error handling included?
- Are naming conventions followed?
### 7. Test Scenario Planning
Prepare for testing:
- What test data would be useful?
- What scenarios should be tested?
- How can the workflow be invoked?
- What would indicate successful execution?
### 8. Deployment Preparation
Provide next steps:
- Installation requirements
- Invocation commands
- Testing procedures
- Documentation needs
## REVIEW FINDINGS DOCUMENTATION:
### Issues Found
Document any issues discovered:
- **Critical Issues**: Must fix before use
- **Warnings**: Should fix for better experience
- **Suggestions**: Nice to have improvements
### Validation Results
Record validation outcomes:
- Configuration validation: PASSED/FAILED
- Step compliance: PASSED/FAILED
- Cross-file consistency: PASSED/FAILED
- Requirements verification: PASSED/FAILED
### Recommendations
Provide specific recommendations:
- Immediate actions needed
- Future improvements
- Training needs
- Maintenance considerations
## COMPLETION CHECKLIST:
### Final Validations
- [ ] All files generated successfully
- [ ] No syntax errors in YAML
- [ ] All paths are correct
- [ ] Variables are consistent
- [ ] Design requirements met
- [ ] Best practices followed
### User Acceptance
- [ ] User has reviewed generated workflow
- [ ] User approves of the implementation
- [ ] User understands next steps
- [ ] User satisfied with the result
### Documentation
- [ ] Build summary complete
- [ ] Review findings documented
- [ ] Next steps provided
- [ ] Contact information for support
## CONTENT TO APPEND TO PLAN:
After completing review, append to {workflowPlanFile}:
Append review findings to {workflowPlanFile}:
Create a review summary including:
- Completeness check results
- Accuracy validation
- Compliance with best practices
- Any issues found
Then append completion details:
- Final approval status
- Deployment recommendations
- Usage guidance
### 10. Present MENU OPTIONS
Display: **Select an Option:** [C] Continue to Completion
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- IF C: Save review to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#10-present-menu-options)
## COMPLIANCE CHECK INSTRUCTIONS
When user selects [C], provide these instructions:
**🎯 Workflow Creation Complete! Your new workflow is ready at:**
`{target_workflow_path}`
**⚠️ IMPORTANT - Run Compliance Check in New Context:**
To validate your workflow meets BMAD standards:
1. **Start a new Claude conversation** (fresh context)
2. **Use this command:** `/bmad:bmm:workflows:workflow-compliance-check`
3. **Provide the path:** `{target_workflow_path}/workflow.md`
4. **Follow the validation process** to identify and fix any violations
**Why New Context?**
- Compliance checking requires fresh analysis without workflow creation context
- Ensures objective validation against template standards
- Provides detailed violation reporting with specific fix recommendations
**Your workflow will be checked for:**
- Template compliance and structure
- Step-by-step validation standards
- File optimization and formatting
- Meta-workflow best practices
Ready to validate when you are! [Start new context and run compliance check]
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Generated workflow thoroughly reviewed
- All validations performed
- Issues documented with solutions
- User approves final workflow
- Complete documentation provided
### ❌ SYSTEM FAILURE:
- Skipping review steps
- Not documenting findings
- Ending without user approval
- Not providing next steps
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

188
src/modules/bmb/workflows/create-workflow/steps/step-09-complete.md
View File

@ -1,188 +0,0 @@
---
name: 'step-09-complete'
description: 'Final completion and wrap-up of workflow creation process'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
# File References
thisStepFile: '{workflow_path}/steps/step-09-complete.md'
workflowFile: '{workflow_path}/workflow.md'
# Output files for workflow creation process
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
completionFile: '{targetWorkflowPath}/completion-summary-{new_workflow_name}.md'
---
# Step 9: Workflow Creation Complete
## STEP GOAL:
To complete the workflow creation process with a final summary, confirmation, and next steps for using the new workflow.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a workflow architect and systems designer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in workflow deployment and usage guidance
- ✅ User brings their specific workflow needs
### Step-Specific Rules:
- 🎯 Focus ONLY on completion and next steps
- 🚫 FORBIDDEN to modify the generated workflow
- 💬 Provide clear guidance on how to use the workflow
- 🚫 This is the final step - no next step to load
## EXECUTION PROTOCOLS:
- 🎯 Present completion summary
- 💾 Create final completion documentation
- 📖 Update plan frontmatter with completion status
- 🚫 This is the final step
## CONTEXT BOUNDARIES:
- All previous steps are complete
- Workflow has been generated and reviewed
- Focus ONLY on completion and next steps
- This step concludes the create-workflow process
## COMPLETION PROCESS:
### 1. Initialize Completion
"**Workflow Creation Complete!**
Congratulations! We've successfully created your new workflow. Let's finalize everything and ensure you have everything you need to start using it."
### 2. Final Summary
Present a complete summary of what was created:
**Workflow Created:** {new_workflow_name}
**Location:** {targetWorkflowPath}
**Files Generated:** [list from build step]
### 3. Create Completion Summary
Create {completionFile} with:
```markdown
---
workflowName: { new_workflow_name }
creationDate: [current date]
module: [module from plan]
status: COMPLETE
stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9]
---
# Workflow Creation Summary
## Workflow Information
- **Name:** {new_workflow_name}
- **Module:** [module]
- **Created:** [date]
- **Location:** {targetWorkflowPath}
## Generated Files
[List all files created]
## Quick Start Guide
[How to run the new workflow]
## Next Steps
[Post-creation recommendations]
```
### 4. Usage Guidance
Provide clear instructions on how to use the new workflow:
**How to Use Your New Workflow:**
1. **Running the Workflow:**
- [Instructions based on workflow type]
- [Initial setup if needed]
2. **Common Use Cases:**
- [Typical scenarios for using the workflow]
- [Expected inputs and outputs]
3. **Tips for Success:**
- [Best practices for this specific workflow]
- [Common pitfalls to avoid]
### 5. Post-Creation Recommendations
"**Next Steps:**
1. **Test the Workflow:** Run it with sample data to ensure it works as expected
2. **Customize if Needed:** You can modify the workflow based on your specific needs
3. **Share with Team:** If others will use this workflow, provide them with the location and instructions
4. **Monitor Usage:** Keep track of how well the workflow meets your needs"
### 6. Final Confirmation
"**Is there anything else you need help with regarding your new workflow?**
- I can help you test it
- We can make adjustments if needed
- I can help you create documentation for users
- Or any other support you need"
### 7. Update Final Status
Update {workflowPlanFile} frontmatter:
- Set status to COMPLETE
- Set completion date
- Add stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9]
## MENU OPTIONS
Display: **Workflow Creation Complete!** [T] Test Workflow [M] Make Adjustments [D] Get Help
### Menu Handling Logic:
- IF T: Offer to run the newly created workflow with sample data
- IF M: Offer to make specific adjustments to the workflow
- IF D: Provide additional help and resources
- IF Any other: Respond to user needs
## CRITICAL STEP COMPLETION NOTE
This is the final step. When the user is satisfied, the workflow creation process is complete.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Workflow fully created and reviewed
- Completion summary generated
- User understands how to use the workflow
- All documentation is in place
### ❌ SYSTEM FAILURE:
- Not providing clear usage instructions
- Not creating completion summary
- Leaving user without next steps
**Master Rule:** Ensure the user has everything needed to successfully use their new workflow.

217
src/modules/bmb/workflows/edit-workflow/steps/step-01-analyze.md
View File

@ -1,217 +0,0 @@
---
name: 'step-01-analyze'
description: 'Load and deeply understand the target workflow'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
# File References
thisStepFile: '{workflow_path}/steps/step-01-analyze.md'
nextStepFile: '{workflow_path}/steps/step-02-discover.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
# Template References
analysisTemplate: '{workflow_path}/templates/workflow-analysis.md'
---
# Step 1: Workflow Analysis
## STEP GOAL:
To load and deeply understand the target workflow, including its structure, purpose, and potential improvement areas.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a workflow editor and improvement specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring workflow analysis expertise and best practices knowledge
- ✅ User brings their workflow context and improvement needs
### Step-Specific Rules:
- 🎯 Focus ONLY on analysis and understanding, not editing yet
- 🚫 FORBIDDEN to suggest specific changes in this step
- 💬 Ask questions to understand the workflow path
- 🚪 DETECT if this is a new format (standalone) or old format workflow
## EXECUTION PROTOCOLS:
- 🎯 Analyze workflow thoroughly and systematically
- 💾 Document analysis findings in {outputFile}
- 📖 Update frontmatter `stepsCompleted: [1]` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C' and analysis is complete
## CONTEXT BOUNDARIES:
- User provides the workflow path to analyze
- Load all workflow documentation for reference
- Focus on understanding current state, not improvements yet
- This is about discovery and analysis
## WORKFLOW ANALYSIS PROCESS:
### 1. Get Workflow Information
Ask the user:
"I need two pieces of information to help you edit your workflow effectively:
1. **What is the path to the workflow you want to edit?**
- Path to workflow.md file (new format)
- Path to workflow.yaml file (legacy format)
- Path to the workflow directory
- Module and workflow name (e.g., 'bmb/workflows/create-workflow')
2. **What do you want to edit or improve in this workflow?**
- Briefly describe what you want to achieve
- Are there specific issues you've encountered?
- Any user feedback you've received?
- New features you want to add?
This will help me focus my analysis on what matters most to you."
### 2. Load Workflow Files
Load the target workflow completely:
- workflow.md (or workflow.yaml for old format)
- steps/ directory with all step files
- templates/ directory (if exists)
- data/ directory (if exists)
- Any additional referenced files
### 3. Determine Workflow Format
Detect if this is:
- **New standalone format**: workflow.md with steps/ subdirectory
- **Legacy XML format**: workflow.yaml with instructions.md
- **Mixed format**: Partial migration
### 4. Focused Analysis
Analyze the workflow with attention to the user's stated goals:
#### Initial Goal-Focused Analysis
Based on what the user wants to edit:
- If **user experience issues**: Focus on step clarity, menu patterns, instruction style
- If **functional problems**: Focus on broken references, missing files, logic errors
- If **new features**: Focus on integration points, extensibility, structure
- If **compliance issues**: Focus on best practices, standards, validation
#### Structure Analysis
- Identify workflow type (document, action, interactive, autonomous, meta)
- Count and examine all steps
- Map out step flow and dependencies
- Check for proper frontmatter in all files
#### Content Analysis
- Understand purpose and user journey
- Evaluate instruction style (intent-based vs prescriptive)
- Review menu patterns and user interaction points
- Check variable consistency across files
#### Compliance Analysis
Load reference documentation to understand what ideal workflow files sound be when doing the review:
- `{project-root}/_bmad/bmb/docs/workflows/architecture.md`
- `{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md`
- `{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md`
Check against best practices:
- Step file size and structure (each step file 80-250 lines)
- Menu handling implementation (every menu item has a handler, and continue will only proceed after writes to output if applicable have completed)
- Frontmatter variable usage - no unused variables in the specific step front matter, and all files referenced in the file are done through a variable in the front matter
### 5. Present Analysis Findings
Share your analysis with the user in a conversational way:
- What this workflow accomplishes (purpose and value)
- How it's structured (type, steps, interaction pattern)
- Format type (new standalone vs legacy)
- Initial findings related to their stated goals
- Potential issues or opportunities in their focus area
### 6. Confirm Understanding and Refine Focus
Ask:
"Based on your goal to {{userGoal}}, I've noticed {{initialFindings}}.
Does this align with what you were expecting? Are there other areas you'd like me to focus on in my analysis?"
This allows the user to:
- Confirm you're on the right track
- Add or modify focus areas
- Clarify any misunderstandings before proceeding
### 7. Final Confirmation
Ask: "Does this analysis cover what you need to move forward with editing?"
## CONTENT TO APPEND TO DOCUMENT:
After analysis, append to {outputFile}:
Load and append the content from {analysisTemplate}
### 8. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}
- IF P: Execute {partyModeWorkflow}
- IF C: Save analysis to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and analysis is saved to document and frontmatter is updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin improvement discovery step.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Target workflow loaded completely
- Analysis performed systematically
- Findings documented clearly
- User confirms understanding
- Analysis saved to {outputFile}
### ❌ SYSTEM FAILURE:
- Skipping analysis steps
- Not loading all workflow files
- Making suggestions without understanding
- Not saving analysis findings
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

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