ros/BMAD-METHOD
1
0
Fork 0
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git synced 2026-01-30 04:32:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix missing scripts from installation, and add ability to exclude workflows from being added as commands in tools, the first being the example workflow meant just for workflow example to the workflow builder

Browse Source
This commit is contained in:
Brian Madison
2026-01-07 16:21:08 +08:00
parent 692f14f2e7
commit 7bf05c9d9d
34 changed files with 202 additions and 3826 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/core/tasks/shard-doc.xml
View File

@@ -1,4 +1,4 @@
<tool id="_bmad/core/tasks/shard-doc" name="Shard Document" <task id="_bmad/core/tasks/shard-doc" name="Shard Document"
description="Splits large markdown documents into smaller, organized files based on level 2 (default) sections" webskip="true" description="Splits large markdown documents into smaller, organized files based on level 2 (default) sections" webskip="true"
standalone="true"> standalone="true">
<objective>Split large markdown documents into smaller, organized files based on level 2 sections using @kayvan/markdown-tree-parser tool</objective> <objective>Split large markdown documents into smaller, organized files based on level 2 sections using @kayvan/markdown-tree-parser tool</objective>
@@ -106,4 +106,4 @@
<halt-conditions critical="true"> <halt-conditions critical="true">
<i>HALT if npx command fails or produces no output files</i> <i>HALT if npx command fails or produces no output files</i>
</halt-conditions> </halt-conditions>
</tool> </task>

89
src/core/tasks/validate-workflow.xml
View File

@@ -1,89 +0,0 @@
<task id="_bmad/core/tasks/validate-workflow.xml" name="Validate Workflow Output">
<objective>Run a checklist against a document with thorough analysis and produce a validation report</objective>
<inputs>
<input name="workflow" desc="Workflow path containing checklist.md" />
<input name="checklist" desc="Checklist to validate against (defaults to workflow's checklist.md)" />
<input name="document" desc="Document to validate (ask user if not specified)" />
</inputs>
<flow>
<step n="1" title="Setup">
<action>If checklist not provided, load checklist.md from workflow location</action>
<action>Try to fuzzy match for files similar to the input document name or if user did not provide the document. If document not
provided or unsure, ask user: "Which document should I validate?"</action>
<action>Load both the checklist and document</action>
</step>
<step n="2" title="Validate" critical="true">
<mandate>For EVERY checklist item, WITHOUT SKIPPING ANY:</mandate>
<for-each-item>
<action>Read requirement carefully</action>
<action>Search document for evidence along with any ancillary loaded documents or artifacts (quotes with line numbers)</action>
<action>Analyze deeply - look for explicit AND implied coverage</action>
<mark-as>
✓ PASS - Requirement fully met (provide evidence)
⚠ PARTIAL - Some coverage but incomplete (explain gaps)
✗ FAIL - Not met or severely deficient (explain why)
➖ N/A - Not applicable (explain reason)
</mark-as>
</for-each-item>
<critical>DO NOT SKIP ANY SECTIONS OR ITEMS</critical>
</step>
<step n="3" title="Generate Report">
<action>Create validation-report-{timestamp}.md in document's folder</action>
<report-format>
# Validation Report
**Document:** {document-path}
**Checklist:** {checklist-path}
**Date:** {timestamp}
## Summary
- Overall: X/Y passed (Z%)
- Critical Issues: {count}
## Section Results
### {Section Name}
Pass Rate: X/Y (Z%)
{For each item:}
[MARK] {Item description}
Evidence: {Quote with line# or explanation}
{If FAIL/PARTIAL: Impact: {why this matters}}
## Failed Items
{All ✗ items with recommendations}
## Partial Items
{All ⚠ items with what's missing}
## Recommendations
1. Must Fix: {critical failures}
2. Should Improve: {important gaps}
3. Consider: {minor improvements}
</report-format>
</step>
<step n="4" title="Summary for User">
<action>Present section-by-section summary</action>
<action>Highlight all critical issues</action>
<action>Provide path to saved report</action>
<action>HALT - do not continue unless user asks</action>
</step>
</flow>
<critical-rules>
<rule>NEVER skip sections - validate EVERYTHING</rule>
<rule>ALWAYS provide evidence (quotes + line numbers) for marks</rule>
<rule>Think deeply about each requirement - don't rush</rule>
<rule>Save report to document's folder automatically</rule>
<rule>HALT after presenting summary - wait for user</rule>
</critical-rules>
</task>

1
src/modules/bmb/reference/workflows/meal-prep-nutrition/workflow.md
View File

@@ -2,6 +2,7 @@
name: Meal Prep & Nutrition Plan name: Meal Prep & Nutrition Plan
description: Creates personalized meal plans through collaborative nutrition planning between an expert facilitator and individual seeking to improve their nutrition habits. description: Creates personalized meal plans through collaborative nutrition planning between an expert facilitator and individual seeking to improve their nutrition habits.
web_bundle: true web_bundle: true
standalone: false
--- ---
# Meal Prep & Nutrition Plan Workflow # Meal Prep & Nutrition Plan Workflow

156
src/modules/bmb/workflows/create-module/steps/step-01-init.md
View File

@@ -1,156 +0,0 @@
---
nextStepFile: '{installed_path}/steps/step-02-concept.md'
continueFile: '{installed_path}/steps/step-01b-continue.md'
modulePlanTemplate: '{installed_path}/templates/module-plan.template.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
customModuleLocation: '{bmb_creations_output_folder}'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
---
# Step 1: Workflow Initialization
## STEP GOAL:
To initialize the create-module workflow by getting the module name from the user, checking for existing work, handling continuation if needed, and creating the initial module plan document.
## 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 Module Architect and BMAD Systems Specialist
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD architecture and module creation, user brings their module requirements
- ✅ Maintain collaborative, guiding tone throughout
### Step-Specific Rules:
- 🎯 Focus ONLY on initialization, getting module name, and setting up tracking
- 🚫 FORBIDDEN to look ahead to future steps
- 💬 Handle initialization professionally
- 🚪 DETECT existing workflow state and handle continuation properly
## 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 setup 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
- Module brief discovery happens in this step
## SEQUENCE OF INSTRUCTIONS:
### 1. Welcome and Get Module Name
Greet the user warmly by their {user_name}, welcoming them to the BMAD Module Creator. Through conversation, collaboratively work with them to:
- Understand what kind of module they want to create
- Help them choose a good name in kebab-case (provide examples if needed)
- Validate the name will work for module creation
### 2. Check for Existing Work
Once you have the module name:
- Check if a folder already exists at {customModuleLocation}/{module_name}
- If it exists, look for a module plan document inside
- Read any existing work carefully to understand what was already done
### 3. Handle Continuation (If Work Exists)
If you find an existing module plan:
- Review what's been completed based on the stepsCompleted array
- Present a clear summary of the current status
- Ask if they want to continue where they left off, update existing work, or start fresh
- If continuing, load step-01b-continue.md
### 4. Look for Supporting Documents
Check for any existing documents that could help:
- Module briefs in the module folder or output folder
- Brainstorming results in the output folder
- Any other relevant documentation
### 5. Guide User's Next Decision
If no supporting documents are found:
- Explain their three options clearly and helpfully
- Option 1: Proceed with creating the module based on their ideas
- Option 2: Exit and create a module brief first (explain the module-brief workflow)
- Option 3: Exit and do brainstorming first (explain the brainstorming workflow)
- Support whatever choice they make
### 6. Create Module Foundation
If proceeding:
- Create the module folder if needed
- Create the initial module-plan-{module_name}.md document using the module plan template from {modulePlanTemplate}
- Initialize proper frontmatter with current date, user name, and add "step-01-init" to stepsCompleted array
- Add any discovered documents to inputDocuments field
- Include a brief section about the legacy reference
### 7. Prepare for Next Step
- Confirm everything is set up properly
- Let the user know what you've accomplished
- Transition smoothly to the next phase of defining the module concept
### 8. Present MENU OPTIONS
Display: **Proceeding to define your module concept...**
#### EXECUTION RULES:
- This is an initialization step with no user choices (after inputs handled)
- Proceed directly to next step after setup
- Use menu handling logic section below
#### Menu Handling Logic:
- After setup completion, add step-01-init to the end of the stepsCompleted array in module plan frontmatter, then load, read entire file, then execute `{nextStepFile}` to define the module concept
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Module name obtained and validated through collaborative dialogue
- Module plan document created from template with frontmatter initialized
- "step-01-init" added to stepsCompleted array
- Module plan document created at correct location
- User feels welcomed and informed
- Ready to proceed to step 2
- OR existing workflow properly routed to step-01b-continue.md
### ❌ SYSTEM FAILURE:
- Proceeding with step 2 without module plan creation
- Not checking for existing documents properly
- Creating module without user input on name
- Skipping folder creation
- Not routing to step-01b-continue.md when appropriate
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN initialization setup is complete and module plan document is created (OR continuation is properly routed), will you then immediately load, read entire file, then execute `{nextStepFile}` to begin defining the module concept.

170
src/modules/bmb/workflows/create-module/steps/step-01b-continue.md
View File

@@ -1,170 +0,0 @@
---
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
---
# Step 1b: Continue Module Creation
## 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 Module Architect and BMAD Systems Specialist
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD architecture and module creation, user brings their module requirements
- ✅ Maintain collaborative, guiding tone throughout
### Step-Specific Rules:
- 🎯 Focus ONLY on handling continuation and resuming workflow
- 🚫 FORBIDDEN to modify existing work without user consent
- 💬 Present status clearly and get user direction
- 📋 Track completion status accurately
## EXECUTION PROTOCOLS:
- 🎯 Load and analyze existing module plan
- 💾 Update frontmatter with continuation status
- 📖 Route to appropriate next step based on progress
- 🚫 FORBIDDEN to skip steps just because they exist
## CONTEXT BOUNDARIES:
- Module plan document exists with previous work
- Focus on understanding what's been done and what remains
- Don't assume completion without verification
- User direction guides next actions
## STEP GOAL:
To resume module creation by presenting current status, understanding what's been accomplished, and determining the next step in the process.
## CONTINUATION HANDLING SEQUENCE:
### 1. Load and Analyze Existing Module Plan
Load module plan from: {modulePlanFile}
Read entire document including frontmatter
Extract current status from frontmatter fields:
- stepsCompleted array
- lastStep (the final item in the stepsCompleted array)
- module_name
- module_code
- date
- inputDocuments
### 2. Present Current Status
"Welcome back! I found your in-progress module creation for **{module_name}**.
**Current Status:**
- **Module Code:** {module_code}
- **Started:** {date}
- **Last Step:** {lastStep}
- **Steps Completed:** {stepsCompleted count}/{total steps}
- **Location:** {bmb_creations_output_folder}/{module_name}
Progress Summary:"
Based on stepsCompleted, show:
- [✅] Step 1: Init - Complete
- [ ] Step 2: Concept - {status}
- [ ] Step 3: Components - {status}
- [ ] Step 4: Structure - {status}
- [ ] Step 5: Configuration - {status}
- [ ] Step 6: Agents - {status}
- [ ] Step 7: Workflows - {status}
- [ ] Step 8: Installer - {status}
- [ ] Step 9: Documentation - {status}
- [ ] Step 10: Roadmap - {status}
- [ ] Step 11: Validation - {status}
### 3. Review What's Been Done
Read content sections of module plan
Summarize what's been accomplished:
"**Completed Work:**
- Module identity defined
- Component planning complete
- [Other completed items based on content]"
### 4. Determine Next Step
Based on stepsCompleted array:
Find highest completed step number
Next step = highest completed + 1
"**Ready to Continue:**
Your next step would be: **Step {nextStep} - [step name]**
What would you like to do?
1. **Continue** from where you left off
2. **Review** what's been done so far
3. **Modify** previous work
4. **Start over** with a new plan"
### 5. Handle User Choice
User your best judgement in how to handle the users choice
### 6. Update Continuation Status
Update modulePlanFile frontmatter:
- Set lastStep: 'continued'
- Add note about continuation date
- Keep stepsCompleted unchanged
## ✅ SUCCESS METRICS:
- User understands current progress
- Next step identified correctly
- User choice handled appropriately
- Module plan updated with continuation status
- Workflow resumed at correct location
## ❌ FAILURE MODES TO AVOID:
- Not accurately reading previous status
- Skipping steps just because they exist
- Not offering review option
- Losing previous work
- Not updating continuation tracking
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Existing work properly loaded and analyzed
- User clearly understands current status
- Continuation options presented clearly
- Next step determined correctly
- Module plan updated with continuation information
### ❌ SYSTEM FAILURE:
- Not reading existing plan completely
- Misrepresenting progress status
- Losing track of what's been done
- Not offering appropriate continuation options
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN user selects 'C' (Continue) and appropriate updates are saved to modulePlanFile, will you then load, read entire file, then execute the determined next step file to resume the module creation workflow.

218
src/modules/bmb/workflows/create-module/steps/step-02-concept.md
View File

@@ -1,218 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-03-components.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
moduleStructureGuide: '{project-root}/bmb/workflows/create-agent-legacy/create-module/module-structure.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 2: Define Module Concept and Scope
## 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 Module Architect and Business Analyst
- ✅ 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 module design and BMAD patterns, user brings their domain knowledge
- ✅ Maintain collaborative, educational tone
### Step-Specific Rules:
- 🎯 Focus ONLY on defining the module concept and scope
- 🚫 FORBIDDEN to start designing components in this step
- 💬 Ask questions conversationally to understand vision
- 🚫 FORBIDDEN to proceed without clear module identity
## EXECUTION PROTOCOLS:
- 🎯 Load and study module structure guide for context
- 💾 Document all module identity details in plan
- 📖 Add "step-02-concept" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Module name and location from step 1
- Input documents (brief/brainstorming) if any
- Focus ONLY on concept and scope definition
- Don't assume module details beyond what user provides
## STEP GOAL:
To articulate the module's vision, define its identity, and establish clear boundaries for what it will and won't do.
## MODULE CONCEPT DEFINITION PROCESS:
### 1. Load Context and Briefs
"Let's define your module's concept and identity. This will guide all the decisions we make about agents, workflows, and features."
Load module-plan.md and check inputDocuments field
Read the module brief completely
"I see you have a module brief. Let me review that to understand your vision..."
Use brief content to inform concept development questions
Load and study the module structure guide for context
### 2. Guide Concept Development
Ask conversationally:
"**Understanding Your Vision:**
1. **What problem will this module solve?** - What pain point or need are you addressing?
2. **Who is the primary user?** - Who will benefit most from this module?
3. **What's the main outcome?** - What will users be able to do after using your module?
4. **Why is this important?** - What makes this module valuable or unique?"
### 3. Module Identity Development
Based on their responses, collaboratively develop:
**Module Name:**
- Start with their module code: {module_name}
- Suggest a display name in Title Case
- Get user confirmation or refinement
**Module Purpose:**
- Distill their problem statement into 1-2 clear sentences
- Focus on value and outcomes
- Get user validation
**Target Audience:**
- Identify primary user persona
- Consider skill level (beginner/intermediate/advanced)
- Note any secondary audiences
**Module Scope:**
- What's IN scope (core features)
- What's OUT of scope (explicitly state what it won't do)
- Success criteria (how will we know it works?)
### 4. Module Theme and Category
"**Module Classification:**
Based on your description, this seems to fit in the [Domain-Specific/Creative/Technical/Business/Personal] category.
Does this sound right? Or would you categorize it differently?
**Example Categories:**
- **Domain-Specific**: Legal, Medical, Finance, Education
- **Creative**: RPG/Gaming, Story Writing, Music Production
- **Technical**: DevOps, Testing, Architecture, Security
- **Business**: Project Management, Marketing, Sales
- **Personal**: Journaling, Learning, Productivity"
### 5. Module Type Estimation
"Based on what you've described, I'm thinking this might be a:
- **Simple Module** (1-2 agents, 2-3 workflows) - Focused, single-purpose
- **Standard Module** (3-5 agents, 5-10 workflows) - Comprehensive solution
- **Complex Module** (5+ agents, 10+ workflows) - Full platform/framework
Which feels right for your vision? We'll confirm this after planning components."
### 6. Document Module Concept
Update module-plan.md with concept section:
```markdown
## Module Concept
**Module Name:** {module_display_name}
**Module Code:** {module_name}
**Category:** [category]
**Type:** [estimated type]
**Purpose Statement:**
[1-2 sentence clear purpose]
**Target Audience:**
- Primary: [description]
- Secondary: [if any]
**Scope Definition:**
**In Scope:**
- [core feature 1]
- [core feature 2]
- [core feature 3]
**Out of Scope:**
- [explicitly excluded item 1]
- [explicitly excluded item 2]
**Success Criteria:**
- [measurable outcome 1]
- [measurable outcome 2]
- [user satisfaction indicator]
```
### 7. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to explore alternative concept approaches
- IF P: Execute {partyModeWorkflow} to get creative input on module identity
- IF C: Save concept to module-plan.md, add step-02-concept to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### 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 then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Module purpose clearly articulated
- Module identity established (name, audience, scope)
- Category and type determined
- Concept documented in module plan
- User feels the concept matches their vision
### ❌ SYSTEM FAILURE:
- Proceeding without clear module purpose
- Not defining scope boundaries
- Skipping user validation of concept
- Not documenting concept details
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and module concept is saved to module-plan.md with stepsCompleted updated to [1, 2], will you then load, read entire file, then execute `{nextStepFile}` to begin component planning.

268
src/modules/bmb/workflows/create-module/steps/step-03-components.md
View File

@@ -1,268 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-04-structure.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
agent_examples_path: '{project-root}/bmb/reference/agents/module-examples'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 3: Plan Module Components
## 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 Module 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 BMAD component design patterns, user brings their domain requirements
- ✅ Maintain collaborative, design-focused tone
### Step-Specific Rules:
- 🎯 Focus ONLY on planning component architecture
- 🚫 FORBIDDEN to create actual components in this step
- 💬 Present component options with reasoning
- 🚫 FORBIDDEN to finalize component list without user agreement
## EXECUTION PROTOCOLS:
- 🎯 Reference agent examples for patterns
- 💾 Document component plan in detail
- 📖 Add "step-03-components" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Module concept from step 2 is available
- Focus on planning, not implementation
- Consider BMAD patterns and best practices
- Reference examples but don't copy exactly
## STEP GOAL:
To design the component architecture for the module, determining what agents, workflows, and tasks are needed to fulfill the module's purpose.
## COMPONENT PLANNING PROCESS:
### 1. Initialize Component Planning
"Now that we have a clear module concept, let's plan the components that will bring it to life.
Based on your module's purpose and scope, we'll design:
- **Agents** - The AI personas that will help users
- **Workflows** - The step-by-step processes for accomplishing tasks
- **Tasks** - Quick utilities and supporting functions"
### 2. Agent Planning
"**Agent Architecture:**
Think about the different roles or perspectives needed to accomplish your module's goals. Each agent should have a clear, distinct purpose."
Reference agent examples for patterns
Load and browse agent examples: {agent_examples_path}
"**Common Agent Patterns:**
- **Primary Agent** - The main interface/orchestrator
- **Specialist Agents** - Domain-specific experts
- **Utility Agents** - Helper/support functions
**Example by Module Type:**
**Technical Modules (e.g., DevOps, Testing):**
- Implementation Specialist
- Reviewer/Auditor
- Documentation Expert
**Creative Modules (e.g., Story Writing, Game Design):**
- Creative Director
- World Builder
- Content Generator
**Business Modules (e.g., Project Management):**
- Project Coordinator
- Facilitator
- Analyst"
"**For your {module_category} module, I suggest considering:**
[Suggest 2-4 specific agent types based on module concept]
**What resonates with your vision?** Which of these agents would be most valuable, and are there any others you'd like to add?"
### 3. Workflow Planning
"**Workflow Design:**
Workflows are the step-by-step processes that users will follow to accomplish specific tasks. Each workflow should solve a specific problem or achieve a particular outcome."
**Types of Workflows:**
- **Document Workflows** - Generate reports, plans, specifications
- **Action Workflows** - Perform operations, create structures
- **Interactive Workflows** - Guided sessions, coaching, training
**Example Workflow Patterns:**
"For your module's purpose, consider these potential workflows:
1. **[Primary Workflow Name]** - Main workflow for core functionality
2. **[Supporting Workflow 1]** - For specific use case
3. **[Supporting Workflow 2]** - For another use case
Remember: We'll create workflow PLANS first, not full implementations. These plans can be used later with the create-workflow workflow."
### 4. Task Planning (Optional)
"**Task Planning (if needed):**
Tasks are single-operation utilities that don't need full workflows. They're good for:
- Quick actions
- Shared subroutines
- Helper functions
Does your module need any tasks? For example:
- Status checking
- Quick formatting
- Validation utilities"
### 5. Component Integration Planning
"**How Components Work Together:**
Let's think about how your components will interact:
- **Agent Collaboration**: Will agents work together or independently?
- **Workflow Dependencies**: Do workflows need to call each other?
- **Task Usage**: Which workflows will use which tasks?"
### 6. Component Priority and MVP
"**Starting Point (MVP):**
To ensure success, let's identify the minimum viable set:
**Must Have (Phase 1):**
- [List essential agents]
- [List essential workflows]
**Nice to Have (Phase 2):**
- [Additional agents]
- [Additional workflows]
- [Tasks if any]
This approach lets you launch with core functionality and expand later."
### 7. Document Component Plan
Update module-plan.md with component section:
```markdown
## Component Architecture
### Agents (N planned)
1. **[Agent Name]** - [Brief purpose]
- Type: [Primary/Specialist/Utility]
- Role: [Specific role description]
2. **[Agent Name]** - [Brief purpose]
- Type: [Primary/Specialist/Utility]
- Role: [Specific role description]
### Workflows (N planned)
1. **[Workflow Name]** - [Purpose]
- Type: [Document/Action/Interactive]
- Primary user: [Who uses this]
- Key output: [What it produces]
2. **[Workflow Name]** - [Purpose]
- Type: [Document/Action/Interactive]
- Primary user: [Who uses this]
- Key output: [What it produces]
### Tasks (N planned)
1. **[Task Name]** - [Single-purpose function]
- Used by: [Which workflows/agents]
### Component Integration
- Agents collaborate via: [description]
- Workflow dependencies: [description]
- Task usage patterns: [description]
### Development Priority
**Phase 1 (MVP):**
- [List of components to create first]
**Phase 2 (Enhancement):**
- [List of components for later]
```
### 8. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to explore alternative component architectures
- IF P: Execute {partyModeWorkflow} to get creative input on component design
- IF C: Save component plan to module-plan.md, add step-03-components to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### 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 then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Component architecture planned and documented
- Agent types and purposes clearly defined
- Workflow requirements identified
- Integration patterns established
- Development priority set (MVP vs enhancements)
### ❌ SYSTEM FAILURE:
- Planning components without module purpose context
- Not considering BMAD patterns and examples
- Over-engineering (too many components)
- Under-planning (missing essential components)
- Not establishing development priorities
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and component plan is saved to module-plan.md with stepsCompleted updated to [1, 2, 3], will you then load, read entire file, then execute `{nextStepFile}` to begin creating the module structure.

229
src/modules/bmb/workflows/create-module/steps/step-04-structure.md
View File

@@ -1,229 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-05-config.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 4: Create Module Structure
## 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 Module Architect and Systems Organizer
- ✅ 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 structure patterns, user brings their component requirements
- ✅ Maintain collaborative, organized tone
### Step-Specific Rules:
- 🎯 Focus ONLY on creating directory structure and determining complexity
- 🚫 FORBIDDEN to create actual component files in this step
- 💬 Explain structure decisions clearly
- 🚫 FORBIDDEN to proceed without confirming structure
## EXECUTION PROTOCOLS:
- 🎯 Use component count to determine module type
- 💾 Create all required directories
- 📖 Add "step-04-structure" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Component plan from step 3 is available
- Standard BMAD module structure to follow
- Focus on structure creation, not content
- Module folder already exists from step 1
## STEP GOAL:
To determine the module's complexity type and create the complete directory structure for the module.
## MODULE STRUCTURE CREATION PROCESS:
### 1. Determine Module Complexity
"Based on your component plan, let's determine your module's complexity level:"
**Count Components:**
- Agents: [count from plan]
- Workflows: [count from plan]
- Tasks: [count from plan]
**Complexity Assessment:**
"**Simple Module Criteria:**
- 1-2 agents, all Simple type
- 1-3 workflows
- No complex integrations
**Standard Module Criteria:**
- 2-4 agents with mixed types
- 3-8 workflows
- Some shared resources
**Complex Module Criteria:**
- 4+ agents or multiple Module-type agents
- 8+ workflows
- Complex interdependencies
- External integrations"
"**Your module has:**
- [agent_count] agents
- [workflow_count] workflows
- [task_count] tasks
**This makes it a: [Simple/Standard/Complex] Module**"
### 2. Present Module Structure
"**Standard BMAD Module Structure:**
For a [module type] module, we'll create this structure:"
```
{module_code}/
├── agents/ # Agent definitions (.md)
│ ├── [agent-name].md
│ └── ...
├── workflows/ # Workflow folders
│ ├── [workflow-name]/
│ │ ├── workflow-plan.md # Descriptive plan
│ │ └── README.md # Workflow documentation
│ └── ...
├── tasks/ # Task files (if any)
│ └── [task-name].md
├── templates/ # Shared templates
│ └── [template-files]
├── data/ # Module data files
│ └── [data-files]
├── module.yaml # Required
├── _module-installer/ # Installation configuration
│ ├── installer.js # Optional
│ └── assets/ # Optional install assets
└── README.md # Module documentation
```
### 3. Create Directory Structure
Create all directories in {bmb_creations_output_folder}/{module_name}/:
1. **agents/** - For agent definition files
2. **workflows/** - For workflow folders
3. **tasks/** - For task files (if tasks planned)
4. **templates/** - For shared templates
5. **data/** - For module data
6. **_module-installer/** - For installation configuration
### 4. Create Placeholder README
Create initial README.md with basic structure:
````markdown
# {module_display_name}
{module_purpose}
## Installation
```bash
bmad install {module_code}
```
````
## Components
_Module documentation will be completed in Step 9_
## Quick Start
_Getting started guide will be added in Step 9_
---
_This module is currently under construction_
````
### 5. Document Structure Creation
Update module-plan.md with structure section:
```markdown
## Module Structure
**Module Type:** [Simple/Standard/Complex]
**Location:** {bmb_creations_output_folder}/{module_name}
**Directory Structure Created:**
- ✅ agents/
- ✅ workflows/
- ✅ tasks/
- ✅ templates/
- ✅ data/
- ✅ _module-installer/
- ✅ README.md (placeholder)
**Rationale for Type:**
[Explain why it's Simple/Standard/Complex based on component counts]
````
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to explore alternative structure approaches
- IF P: Execute {partyModeWorkflow} to get creative input on organization
- IF C: Save structure info to module-plan.md, add step-04-structure to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### 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 then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Module complexity correctly determined
- All required directories created
- Structure follows BMAD standards
- Placeholder README created
- Structure documented in plan
### ❌ SYSTEM FAILURE:
- Not creating all required directories
- Incorrectly categorizing module complexity
- Not following BMAD structure patterns
- Creating component files prematurely
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and structure is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4], will you then load, read entire file, then execute `{nextStepFile}` to begin configuration planning.

234
src/modules/bmb/workflows/create-module/steps/step-05-config.md
View File

@@ -1,234 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-06-agents.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 5: Plan Module Configuration
## 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 Module Architect and Configuration 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 installation patterns, user brings their module requirements
- ✅ Maintain collaborative, planning-focused tone
### Step-Specific Rules:
- 🎯 Focus ONLY on planning configuration fields
- 🚫 FORBIDDEN to create installer files in this step
- 💬 Present configuration options clearly
- 🚫 FORBIDDEN to finalize without user input
## EXECUTION PROTOCOLS:
- 🎯 Consider what users might want to configure
- 💾 Document all configuration field plans
- 📖 Add "step-05-config" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Module concept and components from previous steps
- Standard BMAD installer configuration patterns
- Focus on planning, not implementation
- Consider user customization needs
## STEP GOAL:
To determine what configuration settings the module needs and plan how they'll be implemented in the installer.
## CONFIGURATION PLANNING PROCESS:
### 1. Initialize Configuration Planning
"Now let's plan the configuration for your module's installer. This determines what users can customize when they install your module."
**Configuration allows users to:**
- Set up file locations
- Choose features or behavior
- Provide API keys or credentials
- Adjust output formats
- Configure integrations
### 2. Assess Configuration Needs
"**Configuration Assessment:**
Does your {module_display_name} module need any user-configurable settings during installation?"
**Common Configuration Categories:**
**1. Output/Data Paths**
- Where should outputs be saved?
- What's the default data directory?
- Any special folder structures needed?
**2. Feature Toggles**
- Enable/disable specific features
- Choose between behavior modes
- Set verbosity levels
**3. Integration Settings**
- API keys (for external services)
- Service endpoints
- Authentication credentials
**4. User Preferences**
- Default language
- Time zone
- Skill level (beginner/advanced)
- Detail level (minimal/standard/verbose)"
### 3. Plan Configuration Fields
"**For each configuration need, let's define:**
1. **Field Name** (snake_case, e.g., 'output_path')
2. **Type** - INTERACTIVE (asks user) or STATIC (hardcoded)
3. **Prompt** (what to ask user, if interactive)
4. **Default Value** (sensible default)
5. **Input Type** - text, single-select, multi-select
6. **Result Template** - how to store the value"
**Examples:**
"**INTERACTIVE Text Input:**
```yaml
output_path:
prompt: 'Where should {module_name} save outputs?'
default: 'output/{module_name}'
result: '{project-root}/{value}'
```
**INTERACTIVE Single-Select:**
```yaml
detail_level:
prompt: 'How detailed should outputs be?'
default: 'standard'
result: '{value}'
single-select:
- value: 'minimal'
label: 'Minimal - Brief summaries only'
- value: 'standard'
label: 'Standard - Balanced detail'
- value: 'detailed'
label: 'Detailed - Comprehensive information'
```
**STATIC Value:**
````yaml
module_version:
result: "1.0.0"
```"
### 4. Design Configuration for Your Module
"**Based on your module's purpose, consider these potential configurations:"
[Suggest relevant configurations based on module type and purpose]
"**Which of these apply to your module?**
- [Present options relevant to the specific module]
**Any additional configurations needed?**"
### 5. Document Configuration Plan
Update module-plan.md with configuration section:
```markdown
## Configuration Planning
### Required Configuration Fields
1. **[field_name]**
- Type: [INTERACTIVE/STATIC]
- Purpose: [what it controls]
- Default: [default value]
- Input Type: [text/single-select/multi-select]
- Prompt: [user prompt if interactive]
2. **[field_name]**
- Type: [INTERACTIVE/STATIC]
- Purpose: [what it controls]
- Default: [default value]
- Input Type: [text/single-select/multi-select]
- Prompt: [user prompt if interactive]
### Installation Questions Flow
1. [First question]
2. [Second question]
3. [Additional questions...]
### Result Configuration Structure
The module.yaml will generate:
- Module configuration at: _bmad/{module_code}/config.yaml
- User settings stored as: [describe structure]
````
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to explore additional configuration options
- IF P: Execute {partyModeWorkflow} to get input on user experience
- IF C: Save configuration plan to module-plan.md, add step-05-config to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### 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 then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All necessary configuration fields identified
- Field types and prompts clearly defined
- User interaction flow planned
- Configuration structure documented
- Ready for installer implementation
### ❌ SYSTEM FAILURE:
- Skipping configuration planning for modules that need it
- Over-configuring (too many options)
- Not considering user experience
- Not documenting configuration plans
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and configuration plan is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5], will you then load, read entire file, then execute `{nextStepFile}` to begin agent creation.

297
src/modules/bmb/workflows/create-module/steps/step-06-agents.md
View File

@@ -1,297 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-07-workflows.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
agentTemplate: '{installed_path}/templates/agent.template.md'
agent_examples_path: '{project-root}/bmb/reference/agents/module-examples'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 6: Create Module Agents
## 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 Module Architect and Agent 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 BMAD agent patterns, user brings their domain requirements
- ✅ Maintain collaborative, creative tone
### Step-Specific Rules:
- 🎯 Focus on creating proper YAML agent files following the template
- 🚫 FORBIDDEN to use create-agent workflow (it's problematic)
- 💬 Create placeholder workflow folders with README.md for each agent
- 🚫 FORBIDDEN to create full workflows in this step
## EXECUTION PROTOCOLS:
- 🎯 Follow agent.template.md exactly for structure
- 💾 Save agents as .yaml files to module's agents folder
- 📖 Create workflow folders with README.md plans
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Component plan from step 3 defines which agents to create
- Agent template provides the required YAML structure
- Module structure already created
- Focus on agent creation and workflow placeholders
## STEP GOAL:
To create the primary agent(s) for the module using the proper agent template and create placeholder workflow folders for each agent.
## AGENT CREATION PROCESS:
### 1. Review Agent Plan
"Let's create the agents for your {module_display_name} module.
From your component plan, you have:
- [agent_count] agents planned
- [list of agent types from plan]
I'll create each agent following the proper BMAD template and set up placeholder workflow folders for them."
### 2. Load Agent Template
Load and study the agent template from {agentTemplate}
Reference agent examples from {agent_examples_path} for patterns
### 3. Create Each Agent
For each agent in the component plan:
#### 3.1 Determine Agent Characteristics
"**Agent: [Agent Name]**
Let's design this agent by understanding what it needs:
**Memory & Learning:**
1. Does this agent need to remember things across sessions? (conversations, preferences, patterns)
- If yes: We'll add sidecar folder structure for memory
- If no: No persistent memory needed
**Interaction Types:** 2. What does this agent DO?
- Conversational interactions? → Use embedded prompts
- Quick single actions? → Use inline actions
- Complex multi-step processes? → Consider workflows
- Document generation? → Likely need workflows
**Multiple Agent Usage:** 3. Will other agents in this module need the same workflows?
- If yes: Definitely create separate workflow files
- If no: Could embed in agent file
**Based on this, what combination does [Agent Name] need?**
- Memory/Persistence: [Yes/No]
- Embedded prompts: [List main interactions]
- Workflows needed: [Which processes need separate files?]"
#### 3.2 Present Agent Design
"**Agent Design: [Agent Name]**
**Core Identity:**
- Name: [Suggested name]
- Title: [Brief description]
- Icon: [Appropriate emoji]
**Persona:**
- Role: [What the agent does]
- Identity: [Personality/background]
- Communication Style: [How they communicate]
- Principles: [3-5 core principles]
**Structure:**
- Memory needed: [Yes/No - sidecar folder]
- Embedded prompts: [List main interaction prompts]
- Workflow processes: [Which need separate files]
**Menu Items Planned:**
- [List with trigger codes and types]
**Quick actions vs Workflows:**
- Quick prompts: [single-step interactions]
- Workflows: [multi-step, shared processes]
Does this design match what you envisioned? What should we adjust?"
#### 3.3 Create Agent File and Structure
After user confirmation:
Create hybrid agent file with only needed sections:
```yaml
agent:
metadata:
name: '[Agent Name]'
title: '[Agent Title]'
icon: '[Icon]'
module: '{module_code}'
persona:
role: '[Agent Role]'
identity: |
[Multi-line identity description]
communication_style: |
[Multi-line communication style]
principles:
- '[Principle 1]'
- '[Principle 2]'
- '[Principle 3]'
# Only include if agent needs memory/persistence
critical_actions:
- 'Load COMPLETE file ./[agent-name]-sidecar/memories.md and integrate all past interactions'
- 'ONLY read/write files in ./[agent-name]-sidecar/ - this is our private workspace'
# Only include if agent has embedded prompts
prompts:
- id: '[prompt-name]'
content: |
<instructions>
[How to use this prompt]
</instructions>
[Detailed prompt content]
menu:
# Always include
- multi: '[CH] Chat with agent or [SPM] Start Party Mode'
triggers:
- party-mode:
input: SPM
route: '{project-root}/_bmad/core/workflows/edit-agent/workflow.md'
type: exec
- expert-chat:
input: CH
action: agent responds as expert
type: action
# Group related functions
- multi: '[PF] Primary Function [QF] Quick Task'
triggers:
- primary-function:
input: PF
action: '#[prompt-id]'
type: action
- quick-task:
input: QF
route: '#[prompt-id]'
type: exec
# Workflow only for complex processes
- trigger: 'complex-process'
route: '{project-root}/_bmad/{custom_module}/workflows/[workflow]/workflow.md'
description: 'Complex process [icon]'
# Quick inline actions
- trigger: 'save-item'
action: 'Save to ./[agent-name]-sidecar/file.md'
description: 'Save item 💾'
```
#### 3.4 Create Supporting Structure
**If agent needs memory:**
1. Create folder: {bmb_creations_output_folder}/{module_name}/agents/[agent-name]-sidecar/
2. Create files:
- memories.md (empty, for persistent memory)
- instructions.md (empty, for agent protocols)
- insights.md (empty, for breakthrough moments)
- sessions/ (subfolder for session records)
- patterns.md (empty, for tracking patterns)
**If agent has workflows:**
For each workflow that needs separate file:
1. Create folder: {bmb_creations_output_folder}/{module_name}/workflows/[workflow-name]/
2. Create README.md with workflow plan
### 4. Repeat for All Agents
Go through each agent from the component plan, presenting drafts and creating files with user confirmation.
### 5. Document Agent Creation
Update module-plan.md with agents section:
```markdown
## Agents Created
1. **[Agent Name]** - [Agent Title]
- File: [agent-filename].yaml
- Features: [Memory/Sidecar, Embedded prompts, Workflows]
- Structure:
- Sidecar: [Yes/No]
- Prompts: [number embedded]
- Workflows: [list of workflow folders]
- Status: Created with [combination of features]
```
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to refine agent designs
- IF P: Execute {partyModeWorkflow} to get creative input on agent personas
- IF C: Save agent creation status to module-plan.md, add step-06-agents to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### 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 then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All planned agents created with proper YAML structure
- Each agent follows agent.template.md format exactly
- Workflow placeholder folders created with README.md plans
- Agent menu items properly reference workflow paths
- Users confirmed each agent draft before creation
### ❌ SYSTEM FAILURE:
- Using create-agent workflow instead of template
- Creating XML agents instead of YAML
- Not creating workflow placeholder folders
- Skipping user confirmation on agent drafts
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and all agents are created with placeholder workflows and stepsCompleted updated, will you then load, read entire file, then execute `{nextStepFile}` to begin workflow plan review.

229
src/modules/bmb/workflows/create-module/steps/step-07-workflows.md
View File

@@ -1,229 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-08-installer.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
workflowPlanTemplate: '{installed_path}/templates/workflow-plan-template.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 7: Review Workflow Plans
## 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 Module Architect and Workflow 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 BMAD workflow patterns, user brings their workflow requirements
- ✅ Maintain collaborative, review-focused tone
### Step-Specific Rules:
- 🎯 Focus on reviewing existing workflow README files from Step 6
- 🚫 FORBIDDEN to use create-workflow workflow in this step
- 💬 Review and refine workflow plans, not create new ones
- 🚫 FORBIDDEN to create actual workflow steps
## EXECUTION PROTOCOLS:
- 🎯 Review workflow README files created in Step 6
- 💾 Update README files based on user feedback
- 📖 Add "step-07-workflows" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Workflow README files were created in Step 6 for each agent
- These README files contain workflow plans for later implementation
- Module structure already created with workflow folders
- Focus on reviewing and refining, not creating from scratch
## STEP GOAL:
To review and refine the workflow README files created in Step 6, ensuring they have clear plans for later implementation with the create-workflow workflow.
## WORKFLOW REVIEW PROCESS:
### 1. List Workflow Folders Created
"Let's review the workflow plans created in Step 6 for your {module_display_name} module.
I've already created workflow folders and README.md files for each agent's workflows:
**Workflow folders found:**
- [List all workflow folders in {bmb_creations_output_folder}/{module_name}/workflows/]
**Each workflow folder contains a README.md with:**
- Purpose and description
- Trigger code from agent menu
- Key steps outline
- Expected outputs
- Notes for implementation"
### 2. Review Each Workflow Plan
For each workflow README file:
#### 2.1 Load and Present
"**Reviewing Workflow: [Workflow Name]**
Reading the README.md from: [workflow-folder]/README.md
**Current Plan:**
[Purpose]
[Trigger]
[Key Steps]
[Expected Output]
[Notes]
How does this plan look? Should we:
- Keep it as is
- Modify the purpose
- Adjust the steps
- Change the expected output"
#### 2.2 Update Based on Feedback
If user wants changes:
- Update the README.md file
- Keep the same basic structure
- Ensure clarity for future implementation
#### 2.3 Check for Missing Information
Ensure each README has:
```markdown
# [Workflow Name]
## Purpose
[Clear, concise description of what this workflow accomplishes]
## Trigger
[Trigger code from agent menu, e.g., "WF" or specific code]
## Key Steps
1. [Step 1 - What happens first]
2. [Step 2 - What happens next]
3. [Step 3 - Continue as needed]
## Expected Output
[What the workflow produces - document, action, result]
## Notes
This workflow will be implemented using the create-workflow workflow.
(Optional: Any special considerations or requirements)
```
### 3. Link Workflows to Agents
"**Workflow-Agent Mapping:**
Let's verify each workflow is properly linked to its agent:
[For each workflow]:
- **Workflow:** [Workflow Name]
- **Agent:** [Agent Name]
- **Trigger Code:** [WF code]
- **Menu Item:** [Menu description in agent]
Are all these mappings correct in the agent files?"
### 4. Document Implementation Plan
Update module-plan.md with workflow section:
```markdown
## Workflow Plans Reviewed
### For Agent [Agent Name]:
1. **[Workflow Name]**
- Location: workflows/[workflow-name]/
- Status: Plan reviewed and ready for implementation
- Trigger: [WF code]
- Implementation: Use create-workflow workflow
2. **[Workflow Name]**
- Location: workflows/[workflow-name]/
- Status: Plan reviewed and ready for implementation
- Trigger: [WF code]
- Implementation: Use create-workflow workflow
```
### 5. Next Steps Guidance
"**Ready for Implementation:**
All workflow plans are now reviewed and ready. To implement these workflows later:
1. Use the `/bmad:bmb:workflows:create-workflow` command
2. Select each workflow folder
3. Follow the create-workflow workflow
4. It will create the full workflow.md and step files
The README.md in each folder serves as your blueprint for implementation."
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to refine workflow designs
- IF P: Execute {partyModeWorkflow} to get creative input on workflow processes
- IF C: Save workflow plan status to module-plan.md, add step-07-workflows to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### 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 then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All workflow README files reviewed with user
- Each workflow plan has clear purpose and steps
- Workflow-agent mappings verified
- README files updated based on feedback
- Clear implementation guidance provided
### ❌ SYSTEM FAILURE:
- Skipping review of workflow README files
- Not updating plans based on user feedback
- Missing critical information in README files
- Not verifying workflow-agent mappings
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and all workflow plans are reviewed and documented and stepsCompleted updated, will you then load, read entire file, then execute `{nextStepFile}` to begin installer setup.

187
src/modules/bmb/workflows/create-module/steps/step-08-installer.md
View File

@@ -1,187 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-09-documentation.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
installerTemplate: '{installed_path}/templates/installer.template.js'
installConfigTemplate: '{installed_path}/templates/install-config.template.yaml'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 8: Setup Module Installer
## 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 Module Architect and Installation 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 installation patterns, user brings their module requirements
- ✅ Maintain collaborative, technical tone
### Step-Specific Rules:
- 🎯 Focus on creating installer configuration files
- 🚫 FORBIDDEN to run actual installation
- 💬 Follow BMAD installer standards exactly
- 🚫 FORBIDDEN to deviate from configuration template
## EXECUTION PROTOCOLS:
- 🎯 Use configuration plan from step 5
- 💾 Create module.yaml with all fields
- 📖 Add "step-08-installer" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Configuration plan from step 5 defines installer fields
- Standard BMAD installer template to follow
- Module structure already created
- Focus on installer setup, not module content
## STEP GOAL:
To create the module installer configuration (module.yaml) that defines how users will install and configure the module.
## INSTALLER SETUP PROCESS:
### 1. Review Configuration Plan
"Now let's set up the installer for your {module_display_name} module.
The installer will:
- Define how users install your module
- Collect configuration settings
- Set up the module structure in user projects
- Generate the module's config.yaml file
From step 5, we planned these configuration fields:
- [List planned configuration fields]"
### 2. Create Installer Directory
Ensure _module-installer directory exists
Directory: {bmb_creations_output_folder}/{module_name}/_module-installer/
### 3. Create module.yaml
"I'll create the module.yaml file based on your configuration plan. This is the core installer configuration file."
Create file: {bmb_creations_output_folder}/{module_name}/module.yaml from template {installConfigTemplate}
### 4. Handle Custom Installation Logic
"**Custom Installation Logic:**
Does your module need any special setup during installation? For example:
- Creating database tables
- Setting up API connections
- Downloading external assets
- Running initialization scripts"
<ask>Does your module need custom installation logic? [yes/no]</ask>
"I'll create an installer.js file for custom logic."
Create file: {bmb_creations_output_folder}/{module_name}/_module-installer/installer.js from {installerTemplate}
Update installer.js with module-specific logic
### 5. Create Assets Directory (if needed)
"**Installer Assets:**
If your module needs to copy files during installation (templates, examples, documentation), we can add them to the assets directory."
Create directory: _module-installer/assets/
Add note about what assets to include
### 6. Document Installer Setup
Update module-plan.md with installer section:
```markdown
## Installer Configuration
### Install Configuration
- File: module.yaml
- Module code: {module_name}
- Default selected: false
- Configuration fields: [count]
### Custom Logic
- installer.js: [Created/Not needed]
- Custom setup: [description if yes]
### Installation Process
1. User runs: `bmad install {module_name}`
2. Installer asks: [list of questions]
3. Creates: _bmad/{module_name}/
4. Generates: config.yaml with user settings
### Validation
- ✅ YAML syntax valid
- ✅ All fields defined
- ✅ Paths use proper templates
- ✅ Custom logic ready (if needed)
```
### 7. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to review installer configuration
- IF P: Execute {partyModeWorkflow} to get input on user experience
- IF C: Save installer info to module-plan.md, add step-08-installer to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### 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 then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- module.yaml created with all planned fields
- YAML syntax valid
- Custom installation logic prepared (if needed)
- Installer follows BMAD standards
- Configuration properly templated
### ❌ SYSTEM FAILURE:
- Not creating module.yaml
- Invalid YAML syntax
- Missing required fields
- Not using proper path templates
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and installer info is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5, 6, 7, 8], will you then load, read entire file, then execute `{nextStepFile}` to begin documentation creation.

310
src/modules/bmb/workflows/create-module/steps/step-09-documentation.md
View File

@@ -1,310 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-10-roadmap.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
moduleReadmeFile: '{bmb_creations_output_folder}/{module_name}/README.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 9: Create Module Documentation
## 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 Module Architect and Technical Writer
- ✅ 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 documentation best practices, user brings their module knowledge
- ✅ Maintain collaborative, clear tone
### Step-Specific Rules:
- 🎯 Focus on creating comprehensive README documentation
- 🚫 FORBIDDEN to create docs in other locations
- 💬 Generate content based on module plan
- 🚫 FORBIDDEN to skip standard sections
## EXECUTION PROTOCOLS:
- 🎯 Use all gathered module information
- 💾 Update the placeholder README.md file
- 📖 Add "step-09-documentation" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- All module information from previous steps
- Module structure and components already created
- Focus on README.md, not other documentation
- Generate content dynamically from plan
## STEP GOAL:
To create comprehensive README.md documentation for the module that helps users understand, install, and use the module.
## DOCUMENTATION CREATION PROCESS:
### 1. Initialize Documentation
"Let's create the README.md for your {module_display_name} module.
Good documentation is crucial for module adoption. Your README will be the first thing users see when discovering your module."
### 2. Generate README Content
Load module-plan.md to gather all module information
Update {moduleReadmeFile} with comprehensive content:
````markdown
# {module_display_name}
{module_purpose}
## Overview
This module provides:
[Generate list based on module components and features]
## Installation
Install the module using BMAD:
```bash
bmad install {module_name}
```
````
## Components
### Agents ({agent_count})
[List created agents with brief descriptions]
### Workflows ({workflow_count})
[List planned workflows with purposes]
### Tasks ({task_count})
[List tasks if any]
## Quick Start
1. **Load the primary agent:**
```
agent {primary_agent_name}
```
2. **View available commands:**
```
*help
```
3. **Run the main workflow:**
```
workflow {primary_workflow_name}
```
## Module Structure
```
{module_name}/
├── agents/ # Agent definitions
│ ├── [agent-1].md
│ └── [agent-2].md
├── workflows/ # Workflow folders
│ ├── [workflow-1]/
│ │ ├── workflow-plan.md
│ │ └── README.md
│ └── [workflow-2]/
│ └── ...
├── tasks/ # Task files
├── templates/ # Shared templates
├── data/ # Module data
├── _module-installer/ # Installation optional js file with custom install routine
├── module.yaml # yaml config and install questions
└── README.md # This file
```
## Configuration
The module can be configured in `_bmad/{module_name}/config.yaml`
**Key Settings:**
[List configuration fields from installer]
[Example:]
- **output_path**: Where outputs are saved
- **detail_level**: Controls output verbosity
- **feature_x**: Enable/disable specific features
## Examples
### Example 1: [Primary Use Case]
[Step-by-step example of using the module for its main purpose]
1. Start the agent
2. Provide input
3. Review output
### Example 2: [Secondary Use Case]
[Additional example if applicable]
## Development Status
This module is currently:
- [x] Structure created
- [x] Installer configured
- [ ] Agents implemented
- [ ] Workflows implemented
- [ ] Full testing complete
**Note:** Some workflows are planned but not yet implemented. See individual workflow folders for status.
## Contributing
To extend this module:
1. Add new agents using `create-agent` workflow
2. Add new workflows using `create-workflow` workflow
3. Update the installer configuration if needed
4. Test thoroughly
## Requirements
- BMAD Method version 6.0.0 or higher
- [Any specific dependencies]
## Author
Created by {user_name} on [creation date]
## License
[Add license information if applicable]
---
## Module Details
**Module Code:** {module_name}
**Category:** {module_category}
**Type:** {module_type}
**Version:** 1.0.0
**Last Updated:** [current date]
````
### 3. Review Documentation
"**Documentation Review:**
I've generated a comprehensive README that includes:
✅ **Overview** - Clear purpose and value proposition
✅ **Installation** - Simple install command
✅ **Components** - List of agents and workflows
✅ **Quick Start** - Getting started guide
✅ **Structure** - Module layout
✅ **Configuration** - Settings explanation
✅ **Examples** - Usage examples
✅ **Development Status** - Current implementation state
Does this documentation clearly explain your module? Is there anything you'd like to add or modify?"
### 4. Handle Documentation Updates
Update based on user feedback
"Common additions:
- API documentation
- Troubleshooting section
- FAQ
- Screenshots or diagrams
- Video tutorials
- Changelog"
### 5. Document Documentation Creation
Update module-plan.md with documentation section:
```markdown
## Documentation
### README.md Created
- Location: {bmb_creations_output_folder}/{module_name}/README.md
- Sections: [list of sections included]
- Status: Complete
### Content Highlights
- Clear installation instructions
- Component overview
- Quick start guide
- Configuration details
- Usage examples
- Development status
### Updates Made
- [List any customizations or additions]
````
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to improve documentation clarity
- IF P: Execute {partyModeWorkflow} to get input on user experience
- IF C: Save documentation info to module-plan.md, add step-09-documentation to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### 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 then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- README.md fully populated with all sections
- Content accurately reflects module structure
- Installation instructions clear and correct
- Examples provide helpful guidance
- Development status honestly represented
### ❌ SYSTEM FAILURE:
- Leaving placeholder content in README
- Not updating with actual module details
- Missing critical sections (installation, usage)
- Misrepresenting implementation status
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and documentation info is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5, 6, 7, 8, 9], will you then load, read entire file, then execute `{nextStepFile}` to begin roadmap generation.

338
src/modules/bmb/workflows/create-module/steps/step-10-roadmap.md
View File

@@ -1,338 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-11-validate.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
moduleTodoFile: '{bmb_creations_output_folder}/{module_name}/TODO.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 10: Generate Development Roadmap
## 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 Module Architect and Project Planner
- ✅ 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 development planning, user brings their module vision
- ✅ Maintain collaborative, forward-looking tone
### Step-Specific Rules:
- 🎯 Focus on creating actionable roadmap and TODO
- 🚫 FORBIDDEN to create actual components
- 💬 Prioritize tasks for successful launch
- 🚫 FORBIDDEN to set time estimates
## EXECUTION PROTOCOLS:
- 🎯 Use component status to determine next steps
- 💾 Create clear TODO.md with actionable items
- 📖 Add "step-10-roadmap" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- All module information from previous steps
- Current implementation status
- Focus on planning, not implementation
- Avoid time-based estimates
## STEP GOAL:
To create a development roadmap and TODO list that guides the next steps for completing the module.
## ROADMAP GENERATION PROCESS:
### 1. Review Current Status
"Let's create a development roadmap for your {module_display_name} module.
**Current Status Summary:**
- ✅ Module structure created
- ✅ Installer configured
- [Agent Status]
- [Workflow Status]
- [Documentation Status]
This roadmap will help you prioritize what to work on next."
### 2. Create Development Phases
"**Development Phases:**
I'll organize the remaining work into logical phases to ensure a successful module launch."
### 3. Generate TODO.md
Create file: {bmb_creations_output_folder}/{module_name}/TODO.md
````markdown
# {module_display_name} Development Roadmap
## Phase 1: Core Components (MVP)
### Agents
- [ ] Implement [Agent 1 Name]
- Use: `workflow create-agent`
- Reference: module-plan.md for requirements
- Priority: High
- [ ] Implement [Agent 2 Name]
- Use: `workflow create-agent`
- Reference: module-plan.md for requirements
- Priority: High
### Workflows
- [ ] Implement [Workflow 1 Name]
- Use: `workflow create-workflow`
- Input: workflows/[workflow-1]/workflow-plan.md
- Priority: High
- [ ] Implement [Workflow 2 Name]
- Use: `workflow create-workflow`
- Input: workflows/[workflow-2]/workflow-plan.md
- Priority: Medium
### Integration
- [ ] Test agent-workflow integration
- [ ] Update agent menus (remove TODO flags)
- [ ] Validate configuration fields work correctly
## Phase 2: Enhanced Features
### Additional Components
- [ ] [Additional Agent 1]
- Priority: Medium
- [ ] [Additional Workflow 1]
- Priority: Low
### Improvements
- [ ] Add error handling
- [ ] Implement validation
- [ ] Optimize performance
- [ ] Add logging
## Phase 3: Polish and Launch
### Testing
- [ ] Unit test all agents
- [ ] Integration test workflows
- [ ] Test installer in clean project
- [ ] Test with sample data
### Documentation
- [ ] Add detailed API docs
- [ ] Create video tutorials
- [ ] Write troubleshooting guide
- [ ] Add FAQ section
### Release
- [ ] Version bump to 1.0.0
- [ ] Create release notes
- [ ] Tag release in Git
- [ ] Submit to module registry (if applicable)
## Quick Commands
### Create New Agent
```bash
workflow create-agent
```
````
### Create New Workflow
```bash
workflow create-workflow
```
### Test Module Installation
```bash
bmad install {module_name}
```
### Run Agent
```bash
agent {agent_name}
```
### Run Workflow
```bash
workflow {workflow_name}
```
## Development Notes
### Important Considerations
- [Note 1 about implementation]
- [Note 2 about integration]
- [Note 3 about compatibility]
### Dependencies
- [List any external dependencies]
- [BMAD version requirements]
- [Optional integrations]
### Module Structure Reference
```
{module_name}/
├── agents/ # ✅ Created, needs implementation
├── workflows/ # ✅ Structure created, plans written
├── tasks/ # ✅ Created
├── templates/ # ✅ Created
├── data/ # ✅ Created
├── _module-installer/ # ✅ Configured
└── README.md # ✅ Complete
└── module.yaml # ✅ Complete
```
## Completion Criteria
The module is complete when:
- [ ] All Phase 1 items are done
- [ ] Installation works smoothly
- [ ] Documentation covers all features
- [ ] Sample usage produces expected results
---
Created: [current date]
Last Updated: [current date]
````
### 4. Prioritize Immediate Next Steps
"**Immediate Next Steps (This Week):**
Based on your module's needs, I recommend starting with:
1. **[Most important agent]** - Core functionality
2. **[Most important workflow]** - Primary user journey
3. **[Integration task]** - Ensure components work together
**Which of these would you like to tackle first?**"
### 5. Provide Development Guidance
"**Development Tips:**
1. **Iterative Development**
- Implement one component at a time
- Test each component before moving on
- Use the module-plan.md as your guide
2. **Testing Strategy**
- Test in a clean project
- Verify installation works
- Check all menu options function
3. **Documentation Updates**
- Update README.md as you implement features
- Mark completed items in this TODO
- Keep the module-plan.md in sync
4. **Getting Help**
- Use BMAD documentation for patterns
- Reference example modules
- Ask for help when stuck"
### 6. Document Roadmap Creation
Update module-plan.md with roadmap section:
```markdown
## Development Roadmap
### TODO.md Created
- Location: {bmb_creations_output_folder}/{module_name}/TODO.md
- Phases defined: 3
- Immediate tasks prioritized
### Next Steps Priority Order
1. [Priority 1]
2. [Priority 2]
3. [Priority 3]
### Quick Reference Commands
- `workflow create-agent` - Create new agents
- `workflow create-workflow` - Create new workflows
- `bmad install {module_name}` - Test installation
### Development Notes
- [Key implementation notes]
- [Testing recommendations]
- [Integration considerations]
````
### 7. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to explore development approaches
- IF P: Execute {partyModeWorkflow} to get creative input on implementation
- IF C: Save roadmap info to module-plan.md, add step-10-roadmap to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### 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 then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- TODO.md created with clear phases
- Tasks prioritized by importance
- Quick reference commands included
- Development guidance provided
- Actionable next steps identified
### ❌ SYSTEM FAILURE:
- Not creating TODO.md file
- Including time estimates
- Not prioritizing tasks effectively
- Missing essential development commands
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and roadmap info is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], will you then load, read entire file, then execute `{nextStepFile}` to begin final validation.

336
src/modules/bmb/workflows/create-module/steps/step-11-validate.md
View File

@@ -1,336 +0,0 @@
---
workflowFile: '{installed_path}/workflow.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
validationChecklist: '{installed_path}/validation.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 11: Validate and Finalize Module
## 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 Module Architect and Quality Assurance 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 validation patterns, user brings their module knowledge
- ✅ Maintain collaborative, thorough tone
### Step-Specific Rules:
- 🎯 Focus on validation and quality checks
- 🚫 FORBIDDEN to modify core structure at this stage
- 💬 Present findings clearly with recommendations
- 🚫 FORBIDDEN to skip validation steps
## EXECUTION PROTOCOLS:
- 🎯 Run validation checklist systematically
- 💾 Document validation results
- 📖 Append "step-11-validate" to stepsCompleted array` before completing
- 🚫 FORBIDDEN to mark as complete without validation
## CONTEXT BOUNDARIES:
- Module fully created with all components
- Focus on validation, not new creation
- Use validation checklist for systematic review
- Ensure BMAD compliance
## STEP GOAL:
To validate the completed module structure, ensure all components are properly configured, and provide next steps for testing and deployment.
## VALIDATION PROCESS:
### 1. Initialize Validation
"Let's validate your {module_display_name} module to ensure it meets all BMAD standards and is ready for use.
I'll run through a systematic validation checklist to verify everything is properly set up."
### 2. Structure Validation
"**1. Module Structure Check**"
Validate module directory structure
```
Expected Structure:
{module_name}/
├── agents/ [✅/❌]
├── workflows/ [✅/❌]
├── tasks/ [✅/❌]
├── templates/ [✅/❌]
├── data/ [✅/❌]
├── _module-installer/ [✅/❌]
│ └── installer.js [✅/N/A]
├── module.yaml [✅/❌]
└── README.md [✅/❌]
```
**Results:**
- [List validation results for each item]
### 3. Configuration Validation
"**2. Configuration Files Check**"
**Install Configuration:**
Validate module.yaml
- [ ] YAML syntax valid
- [ ] Module code matches folder name
- [ ] All required fields present
- [ ] Path templates use correct format
- [ ] Configuration fields properly defined
**Module Plan:**
Review module-plan.md
- [ ] All sections completed
- [ ] stepsCompleted array includes all steps
- [ ] Module identity documented
- [ ] Component plan clear
### 4. Component Validation
"**3. Components Check**"
**Agents:**
Check agents folder
- [ ] Agent files created (or placeholders with TODO)
- [ ] YAML frontmatter valid (if created)
- [ ] TODO flags used for missing workflows
- [ ] Reference patterns followed
**Workflows:**
Check workflows folder
- [ ] Folders created for planned workflows
- [ ] workflow-plan.md files created (or placeholders)
- [ ] README.md in each workflow folder
- [ ] Plans include all required sections
### 5. Documentation Validation
"**4. Documentation Check**"
**README.md:**
Review README.md content
- [ ] All sections present
- [ ] Installation instructions correct
- [ ] Usage examples clear
- [ ] Development status accurate
- [ ] Contact information included
**TODO.md:**
Review TODO.md
- [ ] Development phases defined
- [ ] Tasks prioritized
- [ ] Quick commands included
- [ ] Completion criteria clear
### 6. Integration Validation
"**5. Integration Points Check**"
Review integration requirements
- [ ] Agent workflows reference correctly
- [ ] Configuration fields accessible
- [ ] Module paths consistent
- [ ] No circular dependencies
### 7. Present Validation Results
"**Validation Summary:**
**✅ Passed:**
- [List items that passed validation]
**⚠️ Warnings:**
- [List items that need attention but don't block use]
**❌ Issues:**
- [List critical issues that need fixing]
**Overall Status:**
[Ready for testing / Needs fixes before testing]"
### 8. Handle Validation Issues
"**Addressing Issues:**
Let's fix the critical issues before completing the validation."
For each issue:
1. **Explain the issue** clearly
2. **Show how to fix** it
3. **Make the fix** if user approves
4. **Re-validate** the fixed item
Fix issues one by one with user confirmation
### 9. Final Module Summary
"**Module Creation Complete!**
**Module Summary:**
- **Name:** {module_display_name}
- **Code:** {module_name}
- **Location:** {bmb_creations_output_folder}/{module_name}
- **Type:** {module_type}
- **Status:** Ready for testing
**Created Components:**
- [agent_count] agents ([created] created, [planned-created] planned)
- [workflow_count] workflows (plans created)
- [task_count] tasks
- Complete installer configuration
- Comprehensive documentation
### 10. Next Steps Guidance
"**Your Next Steps:**
1. **Test the Installation:**
```bash
cd [test-project]
bmad install {module_name}
```
2. **Implement Components:**
- Follow TODO.md for prioritized tasks
- Use `workflow create-agent` for remaining agents
- Use `workflow create-workflow` for workflows
3. **Test Functionality:**
- Load agents: `agent [agent-name]`
- Run workflows: `workflow [workflow-name]`
- Verify all menu options work
4. **Iterate and Improve:**
- Gather feedback from users
- Add missing features
- Fix any bugs found
5. **Share Your Module:**
- Document improvements in README.md
- Consider submitting to BMAD registry
- Share with the community"
### 11. Document Validation
Create validation summary in module-plan.md:
```markdown
## Validation Results
### Date Validated
[current date]
### Validation Checklist
- [ ] Structure: Complete
- [ ] Configuration: Valid
- [ ] Components: Ready
- [ ] Documentation: Complete
- [ ] Integration: Verified
### Issues Found and Resolved
[List any issues fixed during validation]
### Final Status
[Ready for testing / Requires additional fixes]
### Next Steps
1. [First next step]
2. [Second next step]
3. [Third next step]
```
### 12. Complete Workflow
Mark workflow as complete:
Update module-plan.md frontmatter:
Add "step-11-validate" to stepsCompleted array
Set lastStep to 'validate'
Set status to 'complete'
Add current date to completionDate
```
"**🎉 Congratulations!**
Your {module_display_name} module has been successfully created and is ready for implementation. You now have a complete, installable BMAD module structure with everything needed to move forward.
Would you like me to help you with anything else?"
### 13. Final MENU OPTIONS
Display: **Module Creation Complete!** [A] Advanced Elicitation [P] Party Mode [C] Exit
#### Menu Handling Logic:
- IF A: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml for reflection on process
- IF P: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md to celebrate completion
- IF C: Mark as complete and exit gracefully
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- This is the final step - workflow complete
- User can ask questions or exit
- Always respond helpfully to final queries
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All validation checks performed
- Issues identified and resolved
- Module marked as complete
- Clear next steps provided
- User satisfied with results
### ❌ SYSTEM FAILURE:
- Skipping validation checks
- Not documenting validation results
- Marking as complete with critical issues
- Not providing next steps guidance
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
WHEN validation is complete, all issues resolved (or documented), and module-plan.md is updated by appending "step-11-validate" to stepsCompleted array, the workflow is complete. Present final summary and allow user to exit or ask final questions.
```

313
src/modules/bmb/workflows/create-module/templates/agent.template.md
View File

@@ -1,313 +0,0 @@
# TEMPLATE
the template to use has comments to help guide generation are are not meant to be in the final agent output
## Agent Template to use
### Hybrid Agent (Can have prompts, sidecar memory, AND workflows)
```yaml
agent:
metadata:
name: '{person-name}'
title: '{agent-title}'
icon: '{agent-icon}'
module: '{module}'
persona:
role: '{agent-role}'
identity: |
{agent-identity - multi-line description}
communication_style: |
{communication-style - 1-2 short sentences to describe chat style}
principles:
- '{agent-principle-1}'
- '{agent-principle-2}'
- '{agent-principle-3}'
- '{agent-principle-N}'
# Optional: Only include if agent needs memory/persistence
critical_actions:
- 'Load COMPLETE file [project-root]/_bmad/_memory/[agent-name]-sidecar/memories.md and integrate all past interactions'
- 'Load COMPLETE file [project-root]/_bmad/_memory/[agent-name]-sidecar/instructions.md and follow ALL protocols'
# Optional: Embedded prompts for common interactions
prompts:
- id: 'core-function'
content: |
<instructions>
Main interaction pattern for this agent
</instructions>
{Detailed prompt content}
- id: 'quick-task'
content: |
<instructions>
Quick, common task the agent performs
</instructions>
{Prompt for quick task}
menu:
# Always include chat/party mode
- multi: '[CH] Chat with the agent or [SPM] Start Party Mode'
triggers:
- party-mode:
input: SPM or fuzzy match start party mode
route: '{project-root}/_bmad/core/workflows/edit-agent/workflow.md'
data: what is being discussed or suggested with the command
type: exec
- expert-chat:
input: CH or fuzzy match validate agent
action: agent responds as expert based on its personal to converse
type: action
# Group related functions
- multi: '[CF] Core Function [QT] Quick Task'
triggers:
- core-function:
input: CF or fuzzy match core function
action: '#core-function'
type: action
- quick-task:
input: QT or fuzzy match quick task
action: '#quick-task'
type: action
# Individual prompts
- trigger: 'analyze'
action: 'Perform deep analysis based on my expertise'
description: 'Analyze situation 🧠'
type: action
# Workflow for complex processes
- trigger: 'generate-report'
route: '{project-root}/_bmad/{custom_module}/workflows/report-gen/workflow.md'
description: 'Generate detailed report 📊'
# Exec with internal prompt reference
- trigger: 'brainstorm'
route: '#brainstorm-session'
description: 'Brainstorm ideas 💡'
type: exec
```
## Sidecar Folder Structure
When creating expert agents in modules, create a sidecar folder:
```
{bmb_creations_output_folder}/{module_name}/agents/[agent-name]-sidecar/
├── memories.md # Persistent memory across sessions
├── instructions.md # Agent-specific protocols
├── insights.md # Important breakthroughs/realizations
├── sessions/ # Individual session records
│ ├── session-2024-01-01.md
│ └── session-2024-01-02.md
└── patterns.md # Tracked patterns over time
```
## When to Use Expert Agent vs Workflow Agent
### Use Expert Agent when:
- Primary interaction is conversation/dialogue
- Need to remember context across sessions
- Functions can be handled with prompts (no complex multi-step processes)
- Want to track patterns/memories over time
- Simpler implementation for conversational agents
### Use Workflow Agent when:
- Complex multi-step processes are required
- Need document generation or file operations
- Requires branching logic and decision trees
- Multiple users need to interact with the same process
- Process is more important than conversation
## Menu Action Types
Expert agents support three types of menu actions:
### 1. **Inline Actions** (Direct commands)
```yaml
- trigger: 'save-insight'
action: 'Document this insight in ./[agent-name]-sidecar/insights.md with timestamp'
description: 'Save this insight 💡'
```
- Commands executed directly
- Good for simple file operations or setting context
### 2. **Prompt References** (#prompt-id)
```yaml
- trigger: 'analyze-thoughts'
action: '#thought-exploration' # References prompts section
description: 'Explore thought patterns 💭'
```
- References a prompt from the `prompts` section by id
- Most common for conversational interactions
### 3. **Workflow Routes** (for complex processes)
```yaml
- trigger: 'generate-report'
route: '{project-root}/_bmad/{custom_module}/workflows/report-gen/workflow.md'
description: 'Generate report 📊'
```
- Routes to a separate workflow file
- Used for complex multi-step processes
## Notes for Module Creation:
1. **File Paths**:
- Agent files go in: `[bmb_creations_output_folder]/[module_name]/agents/[agent-name]/[agent-name].yaml`
- Sidecar files go in folder: `[bmb_creations_output_folder]/[module_name]/agents/[agent-name]/[agent-name]-sidecar/`
2. **Variable Usage**:
- `module` is your module code/name
3. **Creating Sidecar Structure**:
- When agent is created, also create the sidecar folder
- Initialize with empty files: memories.md, instructions.md and any other files the agent will need to have special knowledge or files to record information to
- Create sessions/ subfolder if interactions will result in new sessions
- These files are automatically loaded due to critical_actions
4. **Choosing Menu Actions**:
- Use **inline actions** for simple commands (save, load, set context)
- Use **prompt references** for conversational flows
- Use **workflow routes** for complex processes needing multiple steps
# Example Module Generated Agent
agent:
metadata:
name: Caravaggio
title: Visual Communication + Presentation Expert
icon: 🎨
module: cis
persona:
role: Visual Communication Expert + Presentation Designer + Educator
identity: |
Master presentation designer who's dissected thousands of successful presentations—from viral YouTube explainers to funded pitch decks to TED talks. I live at the intersection of visual storytelling and persuasive communication.
communication_style: |
Constant sarcastic wit and experimental flair. Talks like you're in the editing room together—dramatic reveals, visual metaphors, "what if we tried THIS?!" energy. Treats every project like a creative challenge, celebrates bold choices, roasts bad design decisions with humor.
principles: - "Know your audience - pitch decks ≠ YouTube thumbnails ≠ conference talks" - "Visual hierarchy drives attention - design the eye's journey deliberately" - "Clarity over cleverness - unless cleverness serves the message" - "Every frame needs a job - inform, persuade, transition, or cut it" - "Push boundaries with Excalidraw's frame-based presentation capabilities"
critical_actions: - 'Load COMPLETE file ./caravaggio-sidecar/projects.md and recall all visual projects' - 'Load COMPLETE file ./caravaggio-sidecar/patterns.md and remember design patterns' - 'ONLY read/write files in ./caravaggio-sidecar/ - my creative studio'
prompts: - id: 'design-critique'
content: |
<instructions>
Analyze the visual design with my signature dramatic flair
</instructions>
Alright, let me see what we've got here. *leans in closer*
First impression: Is this making me shout "BRAVO!" or "BARF!"?
Visual hierarchy scan: Where's my eye landing first? Second? Is it a deliberate journey or visual chaos?
The good stuff: What's working? What's making me grin?
The facepalm moments: Where are we losing impact? What's confusing the message?
My "WHAT IF WE TRIED THIS?!": [Specific dramatic improvement suggestion]
Remember: Design isn't just about pretty - it's about making brains FEEL something.
- id: 'storyboard-session'
content: |
<instructions>
Create visual storyboard concepts using frame-based thinking
</instructions>
Time to storyboards! Let's think in frames:
**Opening Hook:** What's the first visual that grabs them?
**The Turn:** Where do we shift perspective?
**The Reveal:** What's the money shot?
**The Close:** What image sticks with them?
For each frame:
- Visual: What do they SEE?
- Text: What do they READ?
- Emotion: What do they FEEL?
Remember: Each frame is a scene in your visual story. Make it COUNT!
- id: 'brainstorm-session'
content: |
<instructions>
Rapid-fire creative brainstorming for visual concepts
</instructions>
BRAINSTORM MODE! 🔥
Give me three wild ideas:
1. The safe but solid option
2. The "ooh, interesting" middle ground
3. The "are you crazy? LET'S DO IT!" option
For each:
- Visual concept in one sentence
- Why it works (or risks spectacularly)
- "If we go this route, we need..."
Let's push some boundaries! What's the most unexpected way to show this?
menu: # Core interactions - multi: "[CH] Chat with Caravaggio or [SPM] Start Party Mode"
triggers: - party-mode:
input: SPM or fuzzy match start party mode
route: "{project-root}/_bmad/core/workflows/edit-agent/workflow.md"
data: what's being discussed, plus custom party agents if specified
type: exec - expert-chat:
input: CH or fuzzy match validate agent
action: agent responds as expert based on its personal to converse
type: action
# Design services group
- multi: "[DC] Design Critique [SB] Storyboard"
triggers:
- design-critique:
input: DC or fuzzy match design critique
route: '#design-critique'
description: 'Ruthless design analysis 🎭'
type: exec
- storyboard:
input: SB or fuzzy match storyboard
route: '#storyboard-session'
description: 'Visual story frames 🎬'
type: exec
# Quick actions
- trigger: 'analyze'
action: 'Quick visual analysis with my signature bluntness'
description: 'Quick visual take 🎯'
type: action
- trigger: 'brainstorm'
action: '#brainstorm-session'
description: 'Creative storm 💡'
type: action
# Document workflows for complex processes
- multi: "[PD] Pitch Deck [EX] Explainer Video"
triggers:
- pitch-deck:
input: PD or fuzzy match pitch deck
route: "{project-root}/_bmad/{custom_module}/workflows/pitch-deck/workflow.md"
description: 'Investor pitch deck 📈'
- explainer:
input: EX or fuzzy match explainer
route: "{project-root}/_bmad/{custom_module}/workflows/explainer/workflow.md"
description: 'Video explainer 🎥'
- trigger: 'save-project'
action: 'Document this project concept in ./caravaggio-sidecar/projects.md with sketches and notes'
description: 'Save project 💾'

47
src/modules/bmb/workflows/create-module/templates/installer.template.js
View File

@@ -1,47 +0,0 @@
/**
* {module_display_name} Module Installer
* Custom installation logic
*/
/**
* @param {Object} options - Installation options
* @param {string} options.projectRoot - Project root directory
* @param {Object} options.config - Module configuration from module.yaml
* @param {Array} options.installedIDEs - List of IDE codes being configured
* @param {Object} options.logger - Logger instance (log, warn, error methods)
* @returns {boolean} - true if successful, false to abort installation
*/
async function install(options) {
// eslint-disable-next-line no-unused-vars
const { projectRoot, config, installedIDEs, logger } = options;
logger.log('Installing {module_display_name}...');
try {
// TODO: Add your custom installation logic here
// Example: Create data directory
// const fs = require('fs');
// const dataPath = config.data_path;
// if (!fs.existsSync(dataPath)) {
// fs.mkdirSync(dataPath, { recursive: true });
// logger.log(`Created data directory: ${dataPath}`);
// }
// Example: Initialize configuration file
// const configPath = path.join(projectRoot, config.config_file);
// fs.writeFileSync(configPath, JSON.stringify({
// initialized: new Date().toISOString(),
// version: config.module_version
// }, null, 2));
logger.log('{module_display_name} installation complete!');
return true;
} catch (error) {
logger.error(`Installation failed: ${error.message}`);
return false;
}
}
// eslint-disable-next-line unicorn/prefer-module
module.exports = { install };

5
src/modules/bmb/workflows/create-module/templates/module-plan.template.md
View File

@@ -1,5 +0,0 @@
---
stepsCompleted: []
---
# Module Plan {module name}

53
src/modules/bmb/workflows/create-module/templates/module.template.yaml
View File

@@ -1,53 +0,0 @@
# {module_display_name} Module Configuration
# This file defines installation questions and module configuration values
code: "${module_name}" # e.g., my-module
name: "{module_display_name}"
default_selected: false
# Welcome message shown during installation
prompt:
- "Thank you for choosing {module_display_name}!"
- "{module_purpose}"
# Core config values are automatically inherited from installer:
## user_name
## communication_language
## document_output_language
## output_folder
# ============================================================================
# CONFIGURATION FIELDS
# ============================================================================
# Each field can be:
# 1. INTERACTIVE (has 'prompt' - asks user during installation)
# 2. STATIC (no 'prompt' - just uses 'result' value)
# ============================================================================
# Example configurations (replace with actual planned fields):
# INTERACTIVE text input:
# output_path:
# prompt: "Where should {module_name} save outputs?"
# default: "output/{module_name}"
# result: "{project-root}/{value}"
# INTERACTIVE single-select:
# detail_level:
# prompt: "How detailed should outputs be?"
# default: "standard"
# result: "{value}"
# single-select:
# - value: "minimal"
# label: "Minimal - Brief summaries only"
# - value: "standard"
# label: "Standard - Balanced detail"
# - value: "detailed"
# label: "Detailed - Comprehensive information"
# STATIC value:
# module_version:
# result: "1.0.0"
# STATIC path:
# data_path:
# result: "{project-root}/_bmad/{module_name}/data"

23
src/modules/bmb/workflows/create-module/templates/workflow-plan-template.md
View File

@@ -1,23 +0,0 @@
# Workflow Plan Template
Use this template when creating workflow plans in step-07-workflows.md
## Template Structure
Copy the content from step-07-workflows.md when creating workflow plans. The template is embedded in the step file as a code block under "Workflow plan template".
## Usage
1. Navigate to the workflow folder
2. Create workflow-plan.md
3. Use the template structure from step-07-workflows.md
4. Fill in details specific to your workflow
## Required Sections
- Purpose
- Requirements (User Inputs, Prerequisites, Dependencies)
- Proposed Steps
- Expected Outputs
- Integration Points
- Implementation Notes

126
src/modules/bmb/workflows/create-module/validation.md
View File

@@ -1,126 +0,0 @@
# Create Module Workflow Validation Checklist
This document provides the validation criteria used in step-11-validate.md to ensure module quality and BMAD compliance.
## Structure Validation
### Required Directories
- [ ] agents/ - Agent definition files
- [ ] workflows/ - Workflow folders
- [ ] tasks/ - Task files (if needed)
- [ ] templates/ - Shared templates
- [ ] data/ - Module data
- [ ] _module-installer/ - Installation config
- [ ] README.md - Module documentation
- [ ] module.yaml - module config file
### Optional File in _module-installer/
- [ ] installer.js - Custom logic (if needed)
## Configuration Validation
### module.yaml
- [ ] Valid YAML syntax
- [ ] Module code matches folder name
- [ ] Name field present
- [ ] Prompt array with welcome messages
- [ ] Configuration fields properly defined
- [ ] Result templates use correct placeholders
### Module Plan
- [ ] All sections completed
- [ ] Module identity documented
- [ ] Component plan clear
- [ ] Configuration plan documented
## Component Validation
### Agents
- [ ] Files created in agents/ folder
- [ ] YAML frontmatter valid (for created agents)
- [ ] TODO flags used for non-existent workflows
- [ ] Menu items follow BMAD patterns
- [ ] Placeholder files contain TODO notes
### Workflows
- [ ] Folders created for each planned workflow
- [ ] workflow-plan.md in each folder
- [ ] README.md in each workflow folder
- [ ] Plans include all required sections
- [ ] Placeholder READMEs created for unplanned workflows
## Documentation Validation
### README.md
- [ ] Module name and purpose
- [ ] Installation instructions
- [ ] Components section
- [ ] Quick start guide
- [ ] Module structure diagram
- [ ] Configuration section
- [ ] Usage examples
- [ ] Development status
- [ ] Author information
### TODO.md
- [ ] Development phases defined
- [ ] Tasks prioritized
- [ ] Quick commands included
- [ ] Completion criteria defined
## Integration Validation
### Path Consistency
- [ ] All paths use correct template format
- [ ] Module code consistent throughout
- [ ] No hardcoded paths
- [ ] Cross-references correct
### Agent-Workflow Integration
- [ ] Agents reference correct workflows
- [ ] TODO flags used appropriately
- [ ] No circular dependencies
- [ ] Clear integration points
## BMAD Compliance
### Standards
- [ ] Follows BMAD module structure
- [ ] Uses BMAD installation patterns
- [ ] Agent files follow BMAD format
- [ ] Workflow plans follow BMAD patterns
### Best Practices
- [ ] Clear naming conventions
- [ ] Proper documentation
- [ ] Version control ready
- [ ] Installable via bmad install
## Final Checklist
### Before Marking Complete
- [ ] All validation items checked
- [ ] Critical issues resolved
- [ ] Module plan updated with final status
- [ ] stepsCompleted includes all 11 steps
- [ ] User satisfied with result
### Ready for Testing
- [ ] Installation should work
- [ ] Documentation accurate
- [ ] Structure complete
- [ ] Next steps clear

56
src/modules/bmb/workflows/create-module/workflow.md
View File

@@ -1,56 +0,0 @@
---
name: create-module
description: 'Interactive workflow to build complete BMAD modules with agents, workflows, and installation infrastructure'
web_bundle: true
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
---
# Create Module Workflow
**Goal:** To guide users through creating complete, installable BMAD modules with proper structure, agents, workflow plans, and documentation.
**Your Role:** In addition to your name, communication_style, and persona, you are also a Module Architect and BMAD Systems Specialist collaborating with module creators. This is a partnership, not a client-vendor relationship. You bring expertise in BMAD architecture, component design, and installation patterns, while the user brings their domain knowledge and specific module requirements. Work together as equals.
## WORKFLOW ARCHITECTURE
### Core Principles
- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
- **Just-In-Time Loading**: Only 1 current step file will be loaded, read, and executed to completion - 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. Module Configuration Loading
Load and read full config from {project-root}/_bmad/bmb/config.yaml and resolve:
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. First Step EXECUTION
Load, read the full file and then execute {installed_path}/steps/step-01-init.md to begin the workflow.

1
src/modules/bmb/workflows/workflow/data/examples/meal-prep-nutrition/workflow.md
View File

@@ -2,6 +2,7 @@
name: Meal Prep & Nutrition Plan name: Meal Prep & Nutrition Plan
description: Creates personalized meal plans through collaborative nutrition planning between an expert facilitator and individual seeking to improve their nutrition habits. description: Creates personalized meal plans through collaborative nutrition planning between an expert facilitator and individual seeking to improve their nutrition habits.
web_bundle: true web_bundle: true
standalone: false
--- ---
# Meal Prep & Nutrition Plan Workflow # Meal Prep & Nutrition Plan Workflow

140
src/modules/bmb/workflows/workflow/data/frontmatter-standards.md
View File

@@ -8,7 +8,7 @@
1. **Only variables USED in the step** may be in frontmatter 1. **Only variables USED in the step** may be in frontmatter
2. **All file references MUST use `{variable}` format** - no hardcoded paths 2. **All file references MUST use `{variable}` format** - no hardcoded paths
3. **Paths within workflow folder MUST be relative** 3. **Paths within workflow folder MUST be relative** - NO `workflow_path` variable allowed
--- ---
@@ -48,25 +48,24 @@ description: '[what this step does]'
--- ---
``` ```
### File References (ONLY if used in this step) ### File References - ONLY variables used in this step
```yaml ```yaml
--- ---
# File References # Step to step (SAME folder) - use ./filename.md
workflow_path: '{project-root}/_bmad/[module]/workflows/[workflow-name]' nextStepFile: './step-02-vision.md'
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].md'
# Task References (IF USED) # Step to template (PARENT folder) - use ../filename.md
productBriefTemplate: '../product-brief.template.md'
# Step to data (SUBFOLDER) - use ./data/filename.md
someData: './data/config.csv'
# Output files - use variable
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
# External references - use {project-root}
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml' advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md' partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# Template References (IF USED)
someTemplate: '{workflow_path}/templates/[template].md'
# Data References (IF USED)
someData: '{workflow_path}/data/[data].csv'
--- ---
``` ```
@@ -74,50 +73,103 @@ someData: '{workflow_path}/data/[data].csv'
## Critical Rule: Unused Variables Forbidden ## Critical Rule: Unused Variables Forbidden
### ❌ VIOLATION ### ❌ VIOLATION - Variable defined but never used
```yaml ```yaml
--- ---
outputFile: '{output_folder}/output.md' outputFile: '{output_folder}/output.md'
partyModeWorkflow: '{project-root}/.../party-mode/workflow.md' # ❌ NOT USED! thisStepFile: './step-01-init.md' # ❌ NEVER USED in body
workflowFile: './workflow.md' # ❌ NEVER USED in body
--- ---
# Step body never mentions {partyModeWorkflow} # Step body never mentions {thisStepFile} or {workflowFile}
``` ```
### ✅ CORRECT ### ✅ CORRECT - Only variables that are used
```yaml ```yaml
--- ---
outputFile: '{output_folder}/output.md' outputFile: '{output_folder}/output.md'
nextStepFile: './step-02-foo.md'
--- ---
# Step body uses {outputFile} # Step body uses {outputFile} and {nextStepFile}
``` ```
**Detection Rule:** For EVERY variable in frontmatter, search the step body for `{variableName}`. If not found, it's a violation.
--- ---
## Path Rules ## Path Rules - NO EXCEPTIONS
### 1. Paths Within Workflow Folder = RELATIVE ### 1. Step to Step (SAME folder) = ./filename.md
```yaml ```yaml
# ❌ WRONG - absolute for same-folder # ❌ WRONG
someTemplate: '{project-root}/_bmad/bmb/workflows/my-workflow/templates/template.md' nextStepFile: '{workflow_path}/steps/step-02.md'
nextStepFile: '{project-root}/_bmad/bmm/workflows/foo/steps/step-02.md'
# ✅ CORRECT - relative or via workflow_path # ✅ CORRECT
nextStepFile: './step-02-vision.md'
```
### 2. Step to Template (PARENT folder) = ../filename.md
```yaml
# ❌ WRONG
someTemplate: '{workflow_path}/templates/template.md' someTemplate: '{workflow_path}/templates/template.md'
# ✅ CORRECT
someTemplate: '../template.md'
``` ```
### 2. External References = Full Variable Paths ### 3. Step to Subfolder = ./subfolder/file.md
```yaml
# ❌ WRONG
dataFile: '{workflow_path}/data/config.csv'
# ✅ CORRECT
dataFile: './data/config.csv'
```
### 4. External References = {project-root}/...
```yaml ```yaml
# ✅ CORRECT # ✅ CORRECT
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml' advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
``` ```
### 3. Output Files = Use output_folder Variable ### 5. Output Files = Use folder variable
```yaml ```yaml
# ✅ CORRECT # ✅ CORRECT
outputFile: '{output_folder}/workflow-output-{project_name}.md' outputFile: '{planning_artifacts}/workflow-output-{project_name}.md'
outputFile: '{output_folder}/output.md'
``` ```
--- ---
## ❌ FORBIDDEN Patterns
These patterns are **NEVER ALLOWED** in workflow step frontmatter:
| Pattern | Why It's Wrong |
|---------|----------------|
| `workflow_path: '{project-root}/...'` | Use relative paths instead |
| `thisStepFile: './step-XX.md'` | Almost never used - remove unless actually referenced |
| `workflowFile: './workflow.md'` | Almost never used - remove unless actually referenced |
| `{workflow_path}/steps/...` | Use `./step-XX.md` (same folder) |
| `{workflow_path}/templates/...` | Use `../template.md` (parent folder) |
| `{workflow_path}/data/...` | Use `./data/file.md` (subfolder) |
---
## Variable Naming
Use `snake_case` with descriptive prefixes:
| Pattern | Usage | Example |
| --------- | ---------------------- | -------------------------- |
| `{*_File}` | File references | `outputFile`, `nextStepFile` |
| `{*_Task}` | Task references | `advancedElicitationTask` |
| `{*_Workflow}` | Workflow references | `partyModeWorkflow` |
| `{*_Template}` | Templates | `productBriefTemplate` |
| `{*_Data}` | Data files | `dietaryData` |
---
## Defining New Variables ## Defining New Variables
Steps can define NEW variables that future steps will use. Steps can define NEW variables that future steps will use.
@@ -127,6 +179,7 @@ Steps can define NEW variables that future steps will use.
--- ---
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}' targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
--- ---
# Uses {targetWorkflowPath} in body
``` ```
**Step 02 uses:** **Step 02 uses:**
@@ -135,6 +188,7 @@ targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}' targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
workflowPlanFile: '{targetWorkflowPath}/plan.md' workflowPlanFile: '{targetWorkflowPath}/plan.md'
--- ---
# Uses {targetWorkflowPath} and {workflowPlanFile} in body
``` ```
--- ---
@@ -154,26 +208,18 @@ date: '2025-01-01'
--- ---
## Variable Naming
Use `snake_case` with descriptive prefixes:
| Pattern | Usage | Example |
| --------- | ---------------------- | -------------------------- |
| `{*_path}` | Folder paths | `workflow_path`, `data_path` |
| `{*_file}` | Files | `outputFile`, `planFile` |
| `{*_template}` | Templates | `profileTemplate` |
| `{*_data}` | Data files | `dietaryData` |
---
## Validation Checklist ## Validation Checklist
For every step frontmatter: For EVERY step frontmatter, verify:
- [ ] `name` present, kebab-case
- [ ] `name` present, kebab-case format
- [ ] `description` present - [ ] `description` present
- [ ] All variables in frontmatter ARE used in step body - [ ] Extract ALL variable names from frontmatter (between `---` markers)
- [ ] All file references use `{variable}` format - [ ] For EACH variable, search body: is `{variableName}` present?
- [ ] Paths within workflow folder are relative - [ ] If variable NOT in body → ❌ VIOLATION, remove from frontmatter
- [ ] All step-to-step paths use `./filename.md` format (same folder)
- [ ] All parent-folder paths use `../filename.md` format
- [ ] All subfolder paths use `./subfolder/filename.md` format
- [ ] NO `{workflow_path}` variable exists
- [ ] External paths use `{project-root}` variable - [ ] External paths use `{project-root}` variable
- [ ] Module variables only if workflow belongs to that module - [ ] Module variables only used if workflow belongs to that module

135
src/modules/bmb/workflows/workflow/steps-v/step-02-frontmatter-validation.md
View File

@@ -12,7 +12,7 @@ frontmatterStandards: '../data/frontmatter-standards.md'
## STEP GOAL: ## STEP GOAL:
To validate that EVERY step file's frontmatter follows the frontmatter standards - correct variables, proper path formatting, no unused variables. To validate that EVERY step file's frontmatter follows the frontmatter standards - correct variables, proper relative paths, NO unused variables.
## MANDATORY EXECUTION RULES (READ FIRST): ## MANDATORY EXECUTION RULES (READ FIRST):
@@ -39,9 +39,9 @@ To validate that EVERY step file's frontmatter follows the frontmatter standards
## CONTEXT BOUNDARIES: ## CONTEXT BOUNDARIES:
- All step files in steps-c/ must be validated - All step files in the workflow must be validated
- Load {frontmatterStandards} for validation criteria - Load {frontmatterStandards} for validation criteria
- Check for: unused variables, hardcoded paths, missing required fields - Check for: unused variables, non-relative paths, missing required fields, forbidden patterns
## MANDATORY SEQUENCE ## MANDATORY SEQUENCE
@@ -49,44 +49,81 @@ To validate that EVERY step file's frontmatter follows the frontmatter standards
### 1. Load Frontmatter Standards ### 1. Load Frontmatter Standards
Load {frontmatterStandards} to understand validation criteria: Load {frontmatterStandards} to understand validation criteria.
**Golden Rules:** **Key Rules:**
1. Only variables USED in the step may be in frontmatter 1. Only variables USED in the step may be in frontmatter
2. All file references MUST use `{variable}` format 2. All file references MUST use `{variable}` format
3. Paths within workflow folder MUST be relative 3. Paths within workflow folder MUST be relative - NO `workflow_path` allowed
**Required Fields:** **Forbidden Patterns:**
- `name` - must be present, kebab-case - `workflow_path: '...'` - use relative paths instead
- `description` - must be present - `thisStepFile: '...'` - remove unless actually referenced in body
- `workflowFile: '...'` - remove unless actually referenced in body
- `{workflow_path}/steps/...` - use `./step-XX.md`
- `{workflow_path}/templates/...` - use `../template.md`
### 2. Check EVERY Step File ### 2. Validate EVERY Step File - Systematic Algorithm
**DO NOT BE LAZY - For EACH file in steps-c/:** **DO NOT BE LAZY - For EACH step file:**
1. Load the file #### Step 2.1: Extract Frontmatter Variables
2. Extract frontmatter
3. Validate against each rule:
**Check 1: Required Fields** ```python
- ✅ `name` exists and is kebab-case # Algorithm to extract variables from frontmatter:
- ✅ `description` exists 1. Find content between first `---` and second `---`
2. For each line, extract key before `:`
3. Skip `name`, `description`, and comment lines starting with `#`
4. Collect all variable names
```
**Check 2: All Frontmatter Variables Are Used** Example frontmatter:
- For each variable in frontmatter, check if it appears in step body ```yaml
- ❌ If not used: mark as violation ---
# File References
nextStepFile: './step-02-vision.md'
outputFile: '{planning_artifacts}/product-brief-{{project_name}}.md'
workflow_path: '{project-root}/...' # ❌ FORBIDDEN
thisStepFile: './step-01-init.md' # ❌ Likely unused
---
```
**Check 3: No Hardcoded Paths** Variables extracted: `nextStepFile`, `outputFile`, `workflow_path`, `thisStepFile`
- Check all file references use `{variable}` format
- ❌ If absolute path found: mark as violation
**Check 4: Relative Paths Within Workflow** #### Step 2.2: Check Each Variable Is Used
- Paths to same workflow should be relative (`../data/`)
- ❌ If absolute path for same-folder: mark as violation
**Check 5: External References Use Full Variable Paths** ```python
- `{project-root}` variables for external references # Algorithm to check variable usage:
- ✅ Correct: `advancedElicitationTask: '{project-root}/_bmad/core/...'` for each variable in extracted_variables:
search_body = "{variableName}" # with curly braces
if search_body NOT found in step body (after frontmatter):
MARK_AS_UNUSED(variable)
```
**Example:**
- Variable `nextStepFile`: Search body for `{nextStepFile}` → Found in line 166 ✅
- Variable `thisStepFile`: Search body for `{thisStepFile}` → Not found ❌ VIOLATION
#### Step 2.3: Check Path Formats
For each variable containing a file path:
```python
# Algorithm to validate paths:
if path contains "{workflow_path}":
MARK_AS_VIOLATION("workflow_path is forbidden - use relative paths")
if path is to another step file:
if not path.startswith("./step-"):
MARK_AS_VIOLATION("Step-to-step paths must be ./filename.md")
if path is to parent folder template:
if not path.startswith("../"):
MARK_AS_VIOLATION("Parent folder paths must be ../filename.md")
if path contains "{project-root}" and is internal workflow reference:
MARK_AS_VIOLATION("Internal paths must be relative, not project-root")
```
### 3. Document Findings ### 3. Document Findings
@@ -95,27 +132,26 @@ Create report table:
```markdown ```markdown
### Frontmatter Validation Results ### Frontmatter Validation Results
| File | Required Fields | Variables Used | Relative Paths | Status | | File | Required | All Vars Used | Relative Paths | No Forbidden | Status |
|------|----------------|----------------|----------------|--------| |------|----------|---------------|----------------|-------------|--------|
| step-01-init.md | ✅ | ✅ | ✅ | ✅ PASS | | step-01-init.md | ✅ | ❌ Unused: thisStepFile, workflowFile | ✅ | ✅ | ❌ FAIL |
| step-02-*.md | ✅ | ❌ Unused: partyModeWorkflow | ✅ | ❌ FAIL | | step-02-vision.md | ✅ | ✅ | ✅ | ✅ | ✅ PASS |
| step-03-*.md | ❌ Missing description | ✅ | ❌ Hardcoded path | ❌ FAIL |
``` ```
### 4. List Violations ### 4. List All Violations
For EACH file with violations:
```markdown ```markdown
### Violations Found ### Violations Found
**step-02-[name].md:** **step-01-init.md:**
- Unused variable in frontmatter: `partyModeWorkflow` (not used in step body) - ❌ Unused variable: `thisStepFile` (defined but {thisStepFile} never appears in body)
- ❌ Unused variable: `workflowFile` (defined but {workflowFile} never appears in body)
- ❌ Forbidden pattern: `workflow_path` variable found (use relative paths instead)
**step-03-[name].md:** **step-02-vision.md:**
- Missing required field: `description` - ✅ All checks passed
- Hardcoded path: `someTemplate: '/absolute/path/template.md'` should use relative or variable
**step-05-[name].md:**
- All checks passed ✅
``` ```
### 5. Append to Report ### 5. Append to Report
@@ -137,8 +173,10 @@ Then immediately load, read entire file, then execute {nextStepFile}.
### ✅ SUCCESS: ### ✅ SUCCESS:
- EVERY step file's frontmatter validated - EVERY step file's frontmatter validated using systematic algorithm
- All violations documented - Each variable checked for usage in step body
- Each path checked for proper relative format
- All violations documented with specific variable names
- Findings appended to report - Findings appended to report
- Report saved before proceeding - Report saved before proceeding
- Next validation step loaded - Next validation step loaded
@@ -146,8 +184,9 @@ Then immediately load, read entire file, then execute {nextStepFile}.
### ❌ SYSTEM FAILURE: ### ❌ SYSTEM FAILURE:
- Not checking every file - Not checking every file
- Skipping frontmatter checks - Not systematically checking each variable for usage
- Not documenting violations - Missing forbidden pattern detection
- Not documenting violations with specific details
- Not saving report before proceeding - Not saving report before proceeding
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY file's frontmatter. Auto-proceed through all validation steps. **Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. For EACH variable in frontmatter, verify it's used in the body. For EACH path, verify it's relative. Auto-proceed through all validation steps.

4
src/modules/bmb/workflows/workflow/workflow.md
View File

@@ -1,6 +1,6 @@
--- ---
name: create-workflow name: workflow
description: Create structured standalone workflows using markdown-based step architecture (tri-modal: create, validate, edit) description: "Create structured standalone workflows using markdown-based step architecture (tri-modal: create, validate, edit)"
web_bundle: true web_bundle: true
--- ---

11
src/modules/bmm/workflows/1-analysis/create-product-brief/steps/step-01-init.md
View File

@@ -2,17 +2,12 @@
name: 'step-01-init' name: 'step-01-init'
description: 'Initialize the product brief workflow by detecting continuation state and setting up the document' description: 'Initialize the product brief workflow by detecting continuation state and setting up the document'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief'
# File References # File References
thisStepFile: '{workflow_path}/steps/step-01-init.md' nextStepFile: './step-02-vision.md'
nextStepFile: '{workflow_path}/steps/step-02-vision.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md' outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
# Template References # Template References
productBriefTemplate: '{workflow_path}/product-brief.template.md' productBriefTemplate: '../product-brief.template.md'
--- ---
# Step 1: Product Brief Initialization # Step 1: Product Brief Initialization
@@ -78,7 +73,7 @@ If the document exists and has frontmatter with `stepsCompleted`:
**Continuation Protocol:** **Continuation Protocol:**
- **STOP immediately** and load `{workflow_path}/steps/step-01b-continue.md` - **STOP immediately** and load `./step-01b-continue.md`
- Do not proceed with any initialization tasks - Do not proceed with any initialization tasks
- Let step-01b handle all continuation logic - Let step-01b handle all continuation logic
- This is an auto-proceed situation - no user choice needed - This is an auto-proceed situation - no user choice needed

5
src/modules/bmm/workflows/1-analysis/create-product-brief/steps/step-01b-continue.md
View File

@@ -2,12 +2,7 @@
name: 'step-01b-continue' name: 'step-01b-continue'
description: 'Resume the product brief workflow from where it was left off, ensuring smooth continuation' description: 'Resume the product brief workflow from where it was left off, ensuring smooth continuation'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief'
# File References # File References
thisStepFile: '{workflow_path}/steps/step-01b-continue.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md' outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
--- ---

7
src/modules/bmm/workflows/1-analysis/create-product-brief/steps/step-02-vision.md
View File

@@ -2,13 +2,8 @@
name: 'step-02-vision' name: 'step-02-vision'
description: 'Discover and define the core product vision, problem statement, and unique value proposition' description: 'Discover and define the core product vision, problem statement, and unique value proposition'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief'
# File References # File References
thisStepFile: '{workflow_path}/steps/step-02-vision.md' nextStepFile: './step-03-users.md'
nextStepFile: '{workflow_path}/steps/step-03-users.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md' outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
# Task References # Task References

7
src/modules/bmm/workflows/1-analysis/create-product-brief/steps/step-03-users.md
View File

@@ -2,13 +2,8 @@
name: 'step-03-users' name: 'step-03-users'
description: 'Define target users with rich personas and map their key interactions with the product' description: 'Define target users with rich personas and map their key interactions with the product'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief'
# File References # File References
thisStepFile: '{workflow_path}/steps/step-03-users.md' nextStepFile: './step-04-metrics.md'
nextStepFile: '{workflow_path}/steps/step-04-metrics.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md' outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
# Task References # Task References

7
src/modules/bmm/workflows/1-analysis/create-product-brief/steps/step-04-metrics.md
View File

@@ -2,13 +2,8 @@
name: 'step-04-metrics' name: 'step-04-metrics'
description: 'Define comprehensive success metrics that include user success, business objectives, and key performance indicators' description: 'Define comprehensive success metrics that include user success, business objectives, and key performance indicators'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief'
# File References # File References
thisStepFile: '{workflow_path}/steps/step-04-metrics.md' nextStepFile: './step-05-scope.md'
nextStepFile: '{workflow_path}/steps/step-05-scope.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md' outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
# Task References # Task References

7
src/modules/bmm/workflows/1-analysis/create-product-brief/steps/step-05-scope.md
View File

@@ -2,13 +2,8 @@
name: 'step-05-scope' name: 'step-05-scope'
description: 'Define MVP scope with clear boundaries and outline future vision while managing scope creep' description: 'Define MVP scope with clear boundaries and outline future vision while managing scope creep'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief'
# File References # File References
thisStepFile: '{workflow_path}/steps/step-05-scope.md' nextStepFile: './step-06-complete.md'
nextStepFile: '{workflow_path}/steps/step-06-complete.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md' outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
# Task References # Task References

5
src/modules/bmm/workflows/1-analysis/create-product-brief/steps/step-06-complete.md
View File

@@ -2,12 +2,7 @@
name: 'step-06-complete' name: 'step-06-complete'
description: 'Complete the product brief workflow, update status files, and suggest next steps for the project' description: 'Complete the product brief workflow, update status files, and suggest next steps for the project'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief'
# File References # File References
thisStepFile: '{workflow_path}/steps/step-06-complete.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md' outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
--- ---

10
tools/cli/installers/lib/core/manifest-generator.js
View File

@@ -183,6 +183,14 @@ class ManifestGenerator {
continue; continue;
} }
// Skip workflows marked as non-standalone (reference/example workflows)
if (workflow.standalone === false) {
if (debug) {
console.log(`[DEBUG] Skipped (standalone=false): ${workflow.name}`);
}
continue;
}
if (workflow.name && workflow.description) { if (workflow.name && workflow.description) {
// Build relative path for installation // Build relative path for installation
const installPath = const installPath =
@@ -190,7 +198,7 @@ class ManifestGenerator {
? `${this.bmadFolderName}/core/workflows/${relativePath}/${entry.name}` ? `${this.bmadFolderName}/core/workflows/${relativePath}/${entry.name}`
: `${this.bmadFolderName}/${moduleName}/workflows/${relativePath}/${entry.name}`; : `${this.bmadFolderName}/${moduleName}/workflows/${relativePath}/${entry.name}`;
// ALL workflows now generate commands - no standalone property needed // Workflows with standalone: false are filtered out above
workflows.push({ workflows.push({
name: workflow.name, name: workflow.name,
description: workflow.description.replaceAll('"', '""'), // Escape quotes for CSV description: workflow.description.replaceAll('"', '""'), // Escape quotes for CSV