bmad初始化

This commit is contained in:
2025-11-01 19:22:39 +08:00
parent 5b21dc0bd5
commit 426ae41f54
447 changed files with 80633 additions and 0 deletions

View File

@@ -0,0 +1,277 @@
# Build Workflow
## Overview
The Build Workflow is an interactive workflow builder that guides you through creating new BMAD workflows with proper structure, conventions, and validation. It ensures all workflows follow best practices for optimal human-AI collaboration and are fully compliant with the BMAD Core v6 workflow execution engine.
## Key Features
- **Optional Brainstorming Phase**: Creative exploration of workflow ideas before structured development
- **Comprehensive Guidance**: Step-by-step process with detailed instructions and examples
- **Template-Based**: Uses proven templates for all workflow components
- **Convention Enforcement**: Ensures adherence to BMAD workflow creation guide
- **README Generation**: Automatically creates comprehensive documentation
- **Validation Built-In**: Includes checklist generation for quality assurance
- **Type-Aware**: Adapts to document, action, interactive, autonomous, or meta-workflow types
## Usage
### Basic Invocation
```bash
workflow create-workflow
```
### Through BMad Builder Agent
```
*create-workflow
```
### What You'll Be Asked
1. **Optional**: Whether to brainstorm workflow ideas first (creative exploration phase)
2. Workflow name and target module
3. Workflow purpose and type (enhanced by brainstorming insights if used)
4. Metadata (description, author, outputs)
5. Step-by-step design (goals, variables, flow)
6. Whether to include optional components
## Workflow Structure
### Files Included
```
create-workflow/
├── workflow.yaml # Configuration and metadata
├── instructions.md # Step-by-step execution guide
├── checklist.md # Validation criteria
├── workflow-creation-guide.md # Comprehensive reference guide
├── README.md # This file
└── workflow-template/ # Templates for new workflows
├── workflow.yaml
├── instructions.md
├── template.md
├── checklist.md
└── README.md
```
## Understanding Instruction Styles
One of the most important decisions when creating a workflow is choosing the **instruction style** - how the workflow guides the AI's interaction with users.
### Intent-Based vs Prescriptive Instructions
**Intent-Based (Recommended for most workflows)**
Guides the LLM with goals and principles, allowing natural conversation adaptation.
- **More flexible and conversational** - AI adapts questions to context
- **Better for complex discovery** - Requirements gathering, creative exploration
- **Quality over consistency** - Focus on deep understanding
- **Example**: `<action>Guide user to define their target audience with specific demographics and needs</action>`
**Best for:**
- Complex discovery processes (user research, requirements)
- Creative brainstorming and ideation
- Iterative refinement workflows
- When adaptation to context matters
- Workflows requiring nuanced understanding
**Prescriptive**
Provides exact wording for questions and structured options.
- **More controlled and predictable** - Same questions every time
- **Better for simple data collection** - Platform choices, yes/no decisions
- **Consistency over quality** - Standardized execution
- **Example**: `<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>`
**Best for:**
- Simple data collection (platform, format, binary choices)
- Compliance verification and standards
- Configuration with finite options
- Quick setup wizards
- When consistency is critical
### Best Practice: Mix Both Styles
The most effective workflows use **both styles strategically**:
```xml
<!-- Intent-based workflow with prescriptive moments -->
<step n="1" goal="Understand user vision">
<action>Explore the user's vision, uncovering creative intent and target experience</action>
</step>
<step n="2" goal="Capture basic metadata">
<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>
</step>
<step n="3" goal="Deep dive into details">
<action>Guide user to articulate their core approach and unique aspects</action>
</step>
```
**During workflow creation**, you'll be asked to choose a **primary style preference** - this sets the default approach, but you can (and should) use the other style when it makes more sense for specific steps.
## Workflow Process
### Phase 0: Optional Brainstorming (Step -1)
- **Creative Exploration**: Option to brainstorm workflow ideas before structured development
- **Design Concept Development**: Generate multiple approaches and explore different possibilities
- **Requirement Clarification**: Use brainstorming output to inform workflow purpose, type, and structure
- **Enhanced Creativity**: Leverage AI brainstorming tools for innovative workflow design
The brainstorming phase invokes the CIS brainstorming workflow to:
- Explore workflow ideas and approaches
- Clarify requirements and use cases
- Generate creative solutions for complex automation needs
- Inform the structured workflow building process
### Phase 1: Planning (Steps 0-3)
- Load workflow creation guide and conventions
- Define workflow purpose, name, and type (informed by brainstorming if used)
- Gather metadata and configuration details
- Design step structure and flow
### Phase 2: Generation (Steps 4-8)
- Create workflow.yaml with proper configuration
- Generate instructions.md with XML-structured steps
- Create template.md (for document workflows)
- Generate validation checklist
- Create supporting data files (optional)
### Phase 3: Documentation and Validation (Steps 9-11)
- Create comprehensive README.md (MANDATORY)
- Test and validate workflow structure
- Provide usage instructions and next steps
## Output
### Generated Workflow Folder
Creates a complete workflow folder at:
`{project-root}/bmad/{{target_module}}/workflows/{{workflow_name}}/`
### Files Created
**Always Created:**
- `workflow.yaml` - Configuration with paths and variables
- `README.md` - Comprehensive documentation (MANDATORY as of v6)
- `instructions.md` - Execution steps (if not template-only workflow)
**Conditionally Created:**
- `template.md` - Document structure (for document workflows)
- `checklist.md` - Validation criteria (optional but recommended)
- Supporting data files (CSV, JSON, etc. as needed)
### Output Structure
For document workflows, the README documents:
- Workflow purpose and use cases
- Usage examples with actual commands
- Input expectations
- Output structure and location
- Best practices
## Requirements
- Access to workflow creation guide
- BMAD Core v6 project structure
- Module to host the new workflow (bmm, bmb, cis, or custom)
## Best Practices
### Before Starting
1. **Consider Brainstorming**: If you're unsure about the workflow approach, use the optional brainstorming phase
2. Review the workflow creation guide to understand conventions
3. Have a clear understanding of the workflow's purpose (or be ready to explore it creatively)
4. Know which type of workflow you're creating (document, action, etc.) or be open to discovery
5. Identify any data files or references needed
### Creative Workflow Design
The create-workflow now supports a **seamless transition from creative ideation to structured implementation**:
- **"I need a workflow for something..."** → Start with brainstorming to explore possibilities
- **Brainstorm** → Generate multiple approaches and clarify requirements
- **Structured workflow** → Build the actual workflow using insights from brainstorming
- **One seamless session** → Complete the entire process from idea to implementation
### During Execution
1. Follow kebab-case naming conventions
2. Be specific with step goals and instructions
3. Use descriptive variable names (snake_case)
4. Set appropriate limits ("3-5 items maximum")
5. Include examples where helpful
### After Completion
1. Test the newly created workflow
2. Validate against the checklist
3. Ensure README is comprehensive and accurate
4. Test all file paths and variable references
## Troubleshooting
### Issue: Generated workflow won't execute
- **Solution**: Verify all file paths in workflow.yaml use proper variable substitution
- **Check**: Ensure installed_path and project-root are correctly set
### Issue: Variables not replacing in template
- **Solution**: Ensure variable names match exactly between instructions `<template-output>` tags and template `{{variables}}`
- **Check**: Use snake_case consistently
### Issue: README has placeholder text
- **Solution**: This workflow now enforces README generation - ensure Step 10 completed fully
- **Check**: No {WORKFLOW_TITLE} or similar placeholders should remain
## Customization
To modify this workflow:
1. Edit `instructions.md` to adjust the creation process
2. Update templates in `workflow-template/` to change generated files
3. Modify `workflow-creation-guide.md` to update conventions
4. Edit `checklist.md` to change validation criteria
## Version History
- **v6.0.0** - README.md now MANDATORY for all workflows
- Added comprehensive README template
- Enhanced validation for documentation
- Improved Step 10 with detailed README requirements
- **v6.0.0** - Initial BMAD Core v6 compatible version
- Template-based workflow generation
- Convention enforcement
- Validation checklist support
## Support
For issues or questions:
- Review `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
- Check existing workflows in `/bmad/bmm/workflows/` for examples
- Validate against `/bmad/bmb/workflows/create-workflow/checklist.md`
- Consult BMAD Method v6 documentation
---
_Part of the BMad Method v6 - BMB (BMad Builder) Module_

View File

@@ -0,0 +1,197 @@
# Workflow Brainstorming Context
_Context provided to brainstorming workflow when creating a new BMAD workflow_
## Session Focus
You are brainstorming ideas for a **BMAD workflow** - a guided, multi-step process that helps users accomplish complex tasks with structure, consistency, and quality.
## What is a BMAD Workflow?
A workflow is a structured process that provides:
- **Clear Steps**: Sequential operations with defined goals
- **User Guidance**: Prompts, questions, and decisions at each phase
- **Quality Output**: Documents, artifacts, or completed actions
- **Repeatability**: Same process yields consistent results
- **Type**: Document (creates docs), Action (performs tasks), Interactive (guides sessions), Autonomous (runs automated), Meta (orchestrates other workflows)
## Brainstorming Goals
Explore and define:
### 1. Problem and Purpose
- **What task needs structure?** (specific process users struggle with)
- **Why is this hard manually?** (complexity, inconsistency, missing steps)
- **What would ideal process look like?** (steps, checkpoints, outputs)
- **Who needs this?** (target users and their pain points)
### 2. Process Flow
- **How many phases?** (typically 3-10 major steps)
- **What's the sequence?** (logical flow from start to finish)
- **What decisions are needed?** (user choices that affect path)
- **What's optional vs required?** (flexibility points)
- **What checkpoints matter?** (validation, review, approval points)
### 3. Inputs and Outputs
- **What inputs are needed?** (documents, data, user answers)
- **What outputs are generated?** (documents, code, configurations)
- **What format?** (markdown, XML, YAML, actions)
- **What quality criteria?** (how to validate success)
### 4. Workflow Type and Style
- **Document Workflow?** Creates structured documents (PRDs, specs, reports)
- **Action Workflow?** Performs operations (refactoring, deployment, analysis)
- **Interactive Workflow?** Guides creative process (brainstorming, planning)
- **Autonomous Workflow?** Runs without user input (batch processing, generation)
- **Meta Workflow?** Orchestrates other workflows (project setup, module creation)
## Creative Constraints
A great BMAD workflow should be:
- **Focused**: Solves one problem well (not everything)
- **Structured**: Clear phases with defined goals
- **Flexible**: Optional steps, branching paths where appropriate
- **Validated**: Checklist to verify completeness and quality
- **Documented**: README explains when and how to use it
## Workflow Architecture Questions
### Core Structure
1. **Workflow name** (kebab-case, e.g., "product-brief")
2. **Purpose** (one sentence)
3. **Type** (document/action/interactive/autonomous/meta)
4. **Major phases** (3-10 high-level steps)
5. **Output** (what gets created)
### Process Details
1. **Required inputs** (what user must provide)
2. **Optional inputs** (what enhances results)
3. **Decision points** (where user chooses path)
4. **Checkpoints** (where to pause for approval)
5. **Variables** (data passed between steps)
### Quality and Validation
1. **Success criteria** (what defines "done")
2. **Validation checklist** (measurable quality checks)
3. **Common issues** (troubleshooting guidance)
4. **Best practices** (tips for optimal results)
## Workflow Pattern Examples
### Document Generation Workflows
- **Product Brief**: Idea → Vision → Features → Market → Output
- **PRD**: Requirements → User Stories → Acceptance Criteria → Document
- **Architecture**: Requirements → Decisions → Design → Diagrams → ADRs
- **Technical Spec**: Epic → Implementation → Testing → Deployment → Doc
### Action Workflows
- **Code Refactoring**: Analyze → Plan → Refactor → Test → Commit
- **Deployment**: Build → Test → Stage → Validate → Deploy → Monitor
- **Migration**: Assess → Plan → Convert → Validate → Deploy
- **Analysis**: Collect → Process → Analyze → Report → Recommend
### Interactive Workflows
- **Brainstorming**: Setup → Generate → Expand → Evaluate → Prioritize
- **Planning**: Context → Goals → Options → Decisions → Plan
- **Review**: Load → Analyze → Critique → Suggest → Document
### Meta Workflows
- **Project Setup**: Plan → Architecture → Stories → Setup → Initialize
- **Module Creation**: Brainstorm → Brief → Agents → Workflows → Install
- **Sprint Planning**: Backlog → Capacity → Stories → Commit → Kickoff
## Workflow Design Patterns
### Linear Flow
Simple sequence: Step 1 → Step 2 → Step 3 → Done
**Good for:**
- Document generation
- Structured analysis
- Sequential builds
### Branching Flow
Conditional paths: Step 1 → [Decision] → Path A or Path B → Merge → Done
**Good for:**
- Different project types
- Optional deep dives
- Scale-adaptive processes
### Iterative Flow
Refinement loops: Step 1 → Step 2 → [Review] → (Repeat if needed) → Done
**Good for:**
- Creative processes
- Quality refinement
- Approval cycles
### Router Flow
Type selection: [Select Type] → Load appropriate instructions → Execute → Done
**Good for:**
- Multi-mode workflows
- Reusable frameworks
- Flexible tools
## Suggested Brainstorming Techniques
Particularly effective for workflow ideation:
1. **Process Mapping**: Draw current painful process, identify improvements
2. **Step Decomposition**: Break complex task into atomic steps
3. **Checkpoint Thinking**: Where do users need pause/review/decision?
4. **Pain Point Analysis**: What makes current process frustrating?
5. **Success Visualization**: What does perfect execution look like?
## Key Questions to Answer
1. What manual process needs structure and guidance?
2. What makes this process hard or inconsistent today?
3. What are the 3-10 major phases/steps?
4. What document or output gets created?
5. What inputs are required from the user?
6. What decisions or choices affect the flow?
7. What quality criteria define success?
8. Document, Action, Interactive, Autonomous, or Meta workflow?
9. What makes this workflow valuable vs doing it manually?
10. What would make this workflow delightful to use?
## Output Goals
Generate:
- **Workflow name**: Clear, describes the process
- **Purpose statement**: One sentence explaining value
- **Workflow type**: Classification with rationale
- **Phase outline**: 3-10 major steps with goals
- **Input/output description**: What goes in, what comes out
- **Key decisions**: Where user makes choices
- **Success criteria**: How to know it worked
- **Unique value**: Why this workflow beats manual process
- **Use cases**: 3-5 scenarios where this workflow shines
---
_This focused context helps create valuable, structured BMAD workflows_

View File

@@ -0,0 +1,94 @@
# Build Workflow - Validation Checklist
## Workflow Configuration (workflow.yaml)
- [ ] Name follows kebab-case convention
- [ ] Description clearly states workflow purpose
- [ ] All paths use proper variable substitution
- [ ] installed_path points to correct module location
- [ ] template/instructions paths are correct for workflow type
- [ ] Output file pattern is appropriate
- [ ] YAML syntax is valid (no parsing errors)
## Instructions Structure (instructions.md)
- [ ] Critical headers reference workflow engine
- [ ] All steps have sequential numbering
- [ ] Each step has a clear goal attribute
- [ ] Optional steps marked with optional="true"
- [ ] Repeating steps have appropriate repeat attributes
- [ ] All template-output tags have unique variable names
- [ ] Flow control (if any) has valid step references
## Template Structure (if document workflow)
- [ ] All sections have appropriate placeholders
- [ ] Variable names match template-output tags exactly
- [ ] Markdown formatting is valid
- [ ] Date and metadata fields included
- [ ] No unreferenced variables remain
## Content Quality
- [ ] Instructions are specific and actionable
- [ ] Examples provided where helpful
- [ ] Limits set for lists and content length
- [ ] User prompts are clear
- [ ] Step goals accurately describe outcomes
## Validation Checklist (if present)
- [ ] Criteria are measurable and specific
- [ ] Checks grouped logically by category
- [ ] Final validation summary included
- [ ] All critical requirements covered
## File System
- [ ] Workflow folder created in correct module
- [ ] All required files present based on workflow type
- [ ] File permissions allow execution
- [ ] No placeholder text remains (like {TITLE})
## Testing Readiness
- [ ] Workflow can be invoked without errors
- [ ] All required inputs are documented
- [ ] Output location is writable
- [ ] Dependencies (if any) are available
## Web Bundle Configuration (if applicable)
- [ ] web_bundle section present if needed
- [ ] Name, description, author copied from main config
- [ ] All file paths converted to bmad/-relative format
- [ ] NO {config_source} variables in web bundle
- [ ] NO {project-root} prefixes in paths
- [ ] Instructions path listed correctly
- [ ] Validation/checklist path listed correctly
- [ ] Template path listed (if document workflow)
- [ ] All data files referenced in instructions are listed
- [ ] All sub-workflows are included
- [ ] web_bundle_files array is complete:
- [ ] Instructions.md included
- [ ] Checklist.md included
- [ ] Template.md included (if applicable)
- [ ] All CSV/JSON data files included
- [ ] All referenced templates included
- [ ] All sub-workflow files included
- [ ] No external dependencies outside bundle
## Documentation
- [ ] README created (if requested)
- [ ] Usage instructions clear
- [ ] Example command provided
- [ ] Special requirements noted
- [ ] Web bundle deployment noted (if applicable)
## Final Validation
- [ ] Configuration: No issues
- [ ] Instructions: Complete and clear
- [ ] Template: Variables properly mapped
- [ ] Testing: Ready for test run

View File

@@ -0,0 +1,724 @@
# Build Workflow - Workflow Builder Instructions
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/bmad/bmb/workflows/create-workflow/workflow.yaml</critical>
<critical>You MUST fully understand the workflow creation guide at: {workflow_creation_guide}</critical>
<critical>Study the guide thoroughly to follow ALL conventions for optimal human-AI collaboration</critical>
<critical>Communicate in {communication_language} throughout the workflow creation process</critical>
<workflow>
<step n="-1" goal="Optional brainstorming phase" optional="true">
<ask>Do you want to brainstorm workflow ideas first? [y/n]</ask>
<action if="user_response == 'y' or user_response == 'yes'">
Invoke brainstorming workflow to explore ideas and design concepts:
- Workflow: {project-root}/bmad/core/workflows/brainstorming/workflow.yaml
- Context data: {installed_path}/brainstorm-context.md
- Purpose: Generate creative workflow ideas, explore different approaches, and clarify requirements
The brainstorming output will inform:
- Workflow purpose and goals
- Workflow type selection
- Step design and structure
- User experience considerations
- Technical requirements
</action>
<action if="user_response == 'n' or user_response == 'no'">
Skip brainstorming and proceed directly to workflow building process.
</action>
</step>
<step n="0" goal="Load and understand workflow conventions">
<action>Load the complete workflow creation guide from: {workflow_creation_guide}</action>
<action>Study all sections thoroughly including:
- Core concepts (tasks vs workflows, workflow types)
- Workflow structure (required/optional files, patterns)
- Writing instructions (step attributes, XML tags, flow control)
- Templates and variables (syntax, naming, sources)
- Validation best practices
- Common pitfalls to avoid
</action>
<action>Load template files from: {workflow_template_path}/</action>
<critical>You must follow ALL conventions from the guide to ensure optimal human-AI collaboration</critical>
</step>
<step n="1" goal="Define workflow purpose and type">
Ask the user:
- What is the workflow name? (kebab-case, e.g., "product-brief")
- What module will it belong to? (e.g., "bmm", "bmb", "cis")
- Store as {{target_module}} for output path determination
- What is the workflow's main purpose?
- What type of workflow is this?
- Document workflow (generates documents like PRDs, specs)
- Action workflow (performs actions like refactoring)
- Interactive workflow (guided sessions)
- Autonomous workflow (runs without user input)
- Meta-workflow (coordinates other workflows)
Based on type, determine which files are needed:
- Document: workflow.yaml + template.md + instructions.md + checklist.md
- Action: workflow.yaml + instructions.md
- Others: Varies based on requirements
<critical>Determine output location based on module assignment:</critical>
- If workflow belongs to module: Save to {module_output_folder}
- If standalone workflow: Save to {standalone_output_folder}
Store decisions for later use.
</step>
<step n="2" goal="Gather workflow metadata and invocation settings">
Collect essential configuration details:
- Description (clear purpose statement)
- Author name (default to user_name or "BMad")
- Output file naming pattern
- Any required input documents
- Any required tools or dependencies
<action>Determine standalone property - this controls how the workflow can be invoked:
Explain to the user:
**Standalone Property** controls whether the workflow can be invoked directly or only called by other workflows/agents.
**standalone: true (DEFAULT - Recommended for most workflows)**:
- Users can invoke directly via IDE commands or `/workflow-name`
- Shows up in IDE command palette
- Can also be called from agent menus or other workflows
- Use for: User-facing workflows, entry-point workflows, any workflow users run directly
**standalone: false (Use for helper/internal workflows)**:
- Cannot be invoked directly by users
- Only called via `<invoke-workflow>` from other workflows or agent menus
- Doesn't appear in IDE command palette
- Use for: Internal utilities, sub-workflows, helpers that don't make sense standalone
Most workflows should be `standalone: true` to give users direct access.
</action>
<ask>Should this workflow be directly invokable by users?
1. **Yes (Recommended)** - Users can run it directly (standalone: true)
2. **No** - Only called by other workflows/agents (standalone: false)
Most workflows choose option 1:
</ask>
<action>Store {{standalone_setting}} as true or false based on response</action>
Create the workflow name in kebab-case and verify it doesn't conflict with existing workflows.
</step>
<step n="3" goal="Understand workflow interaction style and design steps">
<critical>Instruction style and interactivity level fundamentally shape the user experience - choose thoughtfully</critical>
<action>Reference the comprehensive "Instruction Styles: Intent-Based vs Prescriptive" section from the loaded creation guide</action>
<action>Discuss instruction style collaboratively with the user:
Explain that there are two primary approaches:
**Intent-Based (RECOMMENDED as default)**:
- Gives AI goals and principles, lets it adapt conversation naturally
- More flexible, conversational, responsive to user context
- Better for: discovery, complex decisions, teaching, varied user skill levels
- Uses <action> tags with guiding instructions
- Example from architecture workflow: Facilitates decisions adapting to user_skill_level
**Prescriptive**:
- Provides exact questions and specific options
- More controlled, predictable, consistent across runs
- Better for: simple data collection, finite options, compliance, quick setup
- Uses <ask> tags with specific question text
- Example: Platform selection with 5 defined choices
Explain that **most workflows should default to intent-based** but use prescriptive for simple data points.
The architecture workflow is an excellent example of intent-based with prescriptive moments.
</action>
<ask>For this workflow's PRIMARY style:
1. **Intent-based (Recommended)** - Adaptive, conversational, responds to user context
2. **Prescriptive** - Structured, consistent, controlled interactions
3. **Mixed/Balanced** - I'll help you decide step-by-step
What feels right for your workflow's purpose?
</ask>
<action>Store {{instruction_style}} preference</action>
<action>Now discuss interactivity level:
Beyond style, consider **how interactive** this workflow should be:
**High Interactivity (Collaborative)**:
- Constant back-and-forth with user
- User guides direction, AI facilitates
- Iterative refinement and review
- Best for: creative work, complex decisions, learning experiences
- Example: Architecture workflow's collaborative decision-making
**Medium Interactivity (Guided)**:
- Key decision points have interaction
- AI proposes, user confirms or refines
- Validation checkpoints
- Best for: most document workflows, structured processes
- Example: PRD workflow with sections to review
**Low Interactivity (Autonomous)**:
- Minimal user input required
- AI works independently with guidelines
- User reviews final output
- Best for: automated generation, batch processing
- Example: Generating user stories from epics
</action>
<ask>What interactivity level suits this workflow?
1. **High** - Highly collaborative, user actively involved throughout (Recommended)
2. **Medium** - Guided with key decision points
3. **Low** - Mostly autonomous with final review
Select the level that matches your workflow's purpose:
</ask>
<action>Store {{interactivity_level}} preference</action>
<action>Explain how these choices will inform the workflow design:
- Intent-based + High interactivity: Conversational discovery with open questions
- Intent-based + Medium: Facilitated guidance with confirmation points
- Intent-based + Low: Principle-based autonomous generation
- Prescriptive + any level: Structured questions, but frequency varies
- Mixed: Strategic use of both styles where each works best
</action>
<action>Now work with user to outline workflow steps:
- How many major steps? (Recommend 3-7 for most workflows)
- What is the goal of each step?
- Which steps are optional?
- Which steps need heavy user collaboration vs autonomous execution?
- Which steps should repeat?
- What variables/outputs does each step produce?
Consider their instruction_style and interactivity_level choices when designing step flow:
- High interactivity: More granular steps with collaboration
- Low interactivity: Larger autonomous steps with review
- Intent-based: Focus on goals and principles in step descriptions
- Prescriptive: Define specific questions and options
</action>
<action>Create a step outline that matches the chosen style and interactivity level</action>
<action>Note which steps should be intent-based vs prescriptive (if mixed approach)</action>
<template-output>step_outline</template-output>
</step>
<step n="4" goal="Create workflow.yaml">
Load and use the template at: {template_workflow_yaml}
Replace all placeholders following the workflow creation guide conventions:
- {TITLE} → Proper case workflow name
- {WORKFLOW_CODE} → kebab-case name
- {WORKFLOW_DESCRIPTION} → Clear description
- {module-code} → Target module
- {file.md} → Output filename pattern
Include:
- All metadata from steps 1-2
- **Standalone property**: Use {{standalone_setting}} from step 2 (true or false)
- Proper paths for installed_path using variable substitution
- Template/instructions/validation paths based on workflow type:
- Document workflow: all files (template, instructions, validation)
- Action workflow: instructions only (template: false)
- Autonomous: set autonomous: true flag
- Required tools if any
- Recommended inputs if any
<critical>ALWAYS include the standard config block:</critical>
```yaml
# Critical variables from config
config_source: '{project-root}/bmad/{{target_module}}/config.yaml'
output_folder: '{config_source}:output_folder'
user_name: '{config_source}:user_name'
communication_language: '{config_source}:communication_language'
date: system-generated
```
<critical>This standard config ensures workflows can run autonomously and communicate properly with users</critical>
<critical>ALWAYS include the standalone property:</critical>
```yaml
standalone: { { standalone_setting } } # true or false from step 2
```
**Example complete workflow.yaml structure**:
```yaml
name: 'workflow-name'
description: 'Clear purpose statement'
# Paths
installed_path: '{project-root}/bmad/module/workflows/name'
template: '{installed_path}/template.md'
instructions: '{installed_path}/instructions.md'
validation: '{installed_path}/checklist.md'
# Critical variables from config
config_source: '{project-root}/bmad/module/config.yaml'
output_folder: '{config_source}:output_folder'
user_name: '{config_source}:user_name'
communication_language: '{config_source}:communication_language'
date: system-generated
# Output
default_output_file: '{output_folder}/document.md'
# Invocation control
standalone: true # or false based on step 2 decision
```
Follow path conventions from guide:
- Use {project-root} for absolute paths
- Use {installed_path} for workflow components
- Use {config_source} for config references
<critical>Determine save location:</critical>
- Use the output folder determined in Step 1 (module or standalone)
- Write to {{output_folder}}/workflow.yaml
</step>
<step n="5" goal="Create instructions.md" if="workflow_type != 'template-only'">
Load and use the template at: {template_instructions}
Generate the instructions.md file following the workflow creation guide:
1. ALWAYS include critical headers:
- Workflow engine reference: {project-root}/bmad/core/tasks/workflow.xml
- workflow.yaml reference: must be loaded and processed
2. Structure with <workflow> tags containing all steps
3. For each step from design phase, follow guide conventions:
- Step attributes: n="X" goal="clear goal statement"
- Optional steps: optional="true"
- Repeating: repeat="3" or repeat="for-each-X" or repeat="until-approved"
- Conditional: if="condition"
- Sub-steps: Use 3a, 3b notation
4. Use proper XML tags from guide:
- Execution: <action>, <check>, <ask>, <goto>, <invoke-workflow>
- Output: <template-output>, <invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>, <critical>, <example>
- Flow: <loop>, <break>, <continue>
5. Best practices from guide:
- Keep steps focused (single goal)
- Be specific ("Write 1-2 paragraphs" not "Write about")
- Provide examples where helpful
- Set limits ("3-5 items maximum")
- Save checkpoints with <template-output>
<critical>Standard config variable usage:</critical>
Instructions MUST use the standard config variables where appropriate:
- Communicate in {communication_language} throughout the workflow
- Address user as {user_name} in greetings and summaries
- Write all output files to {output_folder} or subdirectories
- Include {date} in generated document headers
Example usage in instructions:
```xml
<action>Write document to {output_folder}/output-file.md</action>
<critical>Communicate all responses in {communication_language}</critical>
<output>Hello {user_name}, the workflow is complete!</output>
```
<critical>Applying instruction style preference:</critical>
Based on the {{instruction_style}} preference from Step 3, generate instructions using these patterns:
**Intent-Based Instructions (Recommended for most workflows):**
Focus on goals, principles, and desired outcomes. Let the LLM adapt the conversation naturally.
**Good Examples:**
```xml
<!-- Discovery and exploration -->
<action>Guide user to define their target audience with specific demographics, psychographics, and behavioral characteristics</action>
<action>Explore the user's vision for the product, asking probing questions to uncover core motivations and success criteria</action>
<action>Help user identify and prioritize key features based on user value and technical feasibility</action>
<!-- Validation and refinement -->
<action>Validate that the technical approach aligns with project constraints and team capabilities</action>
<action>Challenge assumptions about user needs and market fit with thought-provoking questions</action>
<!-- Complex iterative work -->
<action>Collaborate with user to refine the architecture, iterating until they're satisfied with the design</action>
```
**Avoid (too prescriptive):**
```xml
<ask>What is your target audience age range? Choose: 18-24, 25-34, 35-44, 45+</ask>
<ask>List exactly 3 key features in priority order</ask>
```
**When to use Intent-Based:**
- Complex discovery processes (user research, requirements gathering)
- Creative brainstorming and ideation
- Iterative refinement workflows
- When user input quality matters more than consistency
- Workflows requiring adaptation to context
**Prescriptive Instructions (Use selectively):**
Provide exact wording, specific options, and controlled interactions.
**Good Examples:**
```xml
<!-- Simple data collection -->
<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>
<ask>Select monetization model: Premium, Free-to-Play, Subscription, Ad-Supported</ask>
<!-- Compliance and standards -->
<ask>Does this comply with GDPR requirements? [yes/no]</ask>
<ask>Choose documentation standard: JSDoc, TypeDoc, TSDoc</ask>
<!-- Binary decisions -->
<ask>Do you want to generate test cases? [yes/no]</ask>
<ask>Include performance benchmarks? [yes/no]</ask>
```
**Avoid (too rigid for complex tasks):**
```xml
<ask>What are your product goals? List exactly 5 goals, each 10-15 words</ask>
<ask>Describe your user persona in exactly 3 sentences</ask>
```
**When to use Prescriptive:**
- Simple data collection (platform, format, yes/no choices)
- Compliance verification and standards adherence
- Configuration with finite options
- When consistency is critical across all executions
- Quick setup wizards
**Mixing Both Styles (Best Practice):**
Even if user chose a primary style, use the other when appropriate:
```xml
<!-- Intent-based workflow with prescriptive moments -->
<step n="1" goal="Understand user vision">
<action>Explore the user's vision for their game, uncovering their creative intent and target experience</action>
<action>Ask probing questions about genre, themes, and emotional tone they want to convey</action>
</step>
<step n="2" goal="Capture basic metadata">
<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask> <!-- Prescriptive for simple choice -->
<ask>Select primary genre: Action, RPG, Strategy, Puzzle, Simulation, Other</ask>
</step>
<step n="3" goal="Deep dive into gameplay">
<action>Guide user to articulate their core gameplay loop, exploring mechanics and player agency</action> <!-- Back to intent-based -->
<action>Help them identify what makes their game unique and compelling</action>
</step>
```
**Guidelines for the chosen style:**
If user chose **Intent-Based**:
- Default to goal-oriented <action> tags
- Use open-ended guidance language
- Save prescriptive <ask> tags for simple data/choices
- Focus on "guide", "explore", "help user", "validate"
- Allow LLM to adapt questions to user responses
If user chose **Prescriptive**:
- Default to explicit <ask> tags with clear options
- Use precise wording for consistency
- Save intent-based <action> tags for complex discovery
- Focus on "choose", "select", "specify", "confirm"
- Provide structured choices when possible
**Remember:** The goal is optimal human-AI collaboration. Use whichever style best serves the user at each step.
<critical>Save location:</critical>
- Write to {{output_folder}}/instructions.md
</step>
<step n="6" goal="Create template.md" if="workflow_type == 'document'">
Load and use the template at: {template_template}
Generate the template.md file following guide conventions:
1. Document structure with clear sections
2. Variable syntax: {{variable_name}} using snake_case
3. Variable names MUST match <template-output> tags exactly from instructions
4. Include standard metadata header (optional - config variables available):
```markdown
# Document Title
**Date:** {{date}}
**Author:** {{user_name}}
```
Note: {{date}} and {{user_name}} are optional in headers. Primary purpose of these variables:
- {{date}} - Gives agent current date awareness (not confused with training cutoff)
- {{user_name}} - Optional author attribution
- {{communication_language}} - NOT for document output! Tells agent how to communicate during execution
5. Follow naming conventions from guide:
- Use descriptive names: {{primary_user_journey}} not {{puj}}
- Snake_case for all variables
- Match instruction outputs precisely
Variable sources as per guide:
- workflow.yaml config values (user_name, communication_language, date, output_folder)
- User input runtime values
- Step outputs via <template-output>
- System variables (date, paths)
<critical>Standard config variables in templates:</critical>
Templates CAN optionally use these config variables:
- {{user_name}} - Document author (optional)
- {{date}} - Generation date (optional)
IMPORTANT: {{communication_language}} is NOT for document headers!
- Purpose: Tells agent how to communicate with user during workflow execution
- NOT for: Document output language or template headers
- Future: {{document_output_language}} will handle multilingual document generation
These variables are automatically available from workflow.yaml config block.
<critical>Save location:</critical>
- Write to {{output_folder}}/template.md
</step>
<step n="7" goal="Create validation checklist" optional="true">
Ask if user wants a validation checklist. If yes:
Load and use the template at: {template_checklist}
Create checklist.md following guide best practices:
1. Make criteria MEASURABLE and SPECIFIC
❌ "- [ ] Good documentation"
✅ "- [ ] Each function has JSDoc comments with parameters and return types"
2. Group checks logically:
- Structure: All sections present, no placeholders, proper formatting
- Content Quality: Clear and specific, technically accurate, consistent terminology
- Completeness: Ready for next phase, dependencies documented, action items defined
3. Include workflow-specific validations based on type:
- Document workflows: Template variables mapped, sections complete
- Action workflows: Actions clearly defined, error handling specified
- Interactive: User prompts clear, decision points documented
4. Add final validation section with issue lists
<critical>Save location:</critical>
- Write to {{output_folder}}/checklist.md
</step>
<step n="8" goal="Create supporting files" optional="true">
Ask if any supporting data files are needed:
- CSV files with data
- Example documents
- Reference materials
If yes, create placeholder files or copy from templates.
</step>
<step n="9" goal="Test and validate workflow">
Review the created workflow:
**Basic Validation:**
1. Verify all file paths are correct
2. Check variable names match between files
3. Ensure step numbering is sequential
4. Validate YAML syntax
5. Confirm all placeholders are replaced
**Standard Config Validation:**
6. Verify workflow.yaml contains standard config block:
- config_source defined
- output_folder, user_name, communication_language pulled from config
- date set to system-generated
7. Check instructions use config variables where appropriate
8. Verify template includes config variables in metadata (if document workflow)
**YAML/Instruction/Template Alignment:**
9. Cross-check all workflow.yaml variables against instruction usage:
- Are all yaml variables referenced in instructions.md OR template.md?
- Are there hardcoded values that should be variables?
- Do template variables match <template-output> tags in instructions?
10. Identify any unused yaml fields (bloat detection)
Show user a summary of created files and their locations.
Ask if they want to:
- Test run the workflow
- Make any adjustments
- Add additional steps or features
</step>
<step n="9b" goal="Configure web bundle (optional)">
<ask>Will this workflow need to be deployable as a web bundle? [yes/no]</ask>
If yes:
<action>Explain web bundle requirements:</action>
- Web bundles are self-contained and cannot use config_source variables
- All files must be explicitly listed in web_bundle_files
- File paths use bmad/ root (not {project-root})
<action>Configure web_bundle section in workflow.yaml:</action>
1. Copy core workflow metadata (name, description, author)
2. Convert all file paths to bmad/-relative paths:
- Remove {project-root}/ prefix
- Remove {config_source} references (use hardcoded values)
- Example: "{project-root}/bmad/bmm/workflows/x" → "bmad/bmm/workflows/x"
3. List ALL referenced files by scanning:
**Scan instructions.md for:**
- File paths in <action> tags
- Data files (CSV, JSON, YAML, etc.)
- Validation/checklist files
- Any <invoke-workflow> calls → must include that workflow's yaml file
- Any <goto> tags that reference other workflows
- Shared templates or includes
**Scan template.md for:**
- Any includes or references to other files
- Shared template fragments
**Critical: Workflow Dependencies**
- If instructions call another workflow, that workflow's yaml MUST be in web_bundle_files
- Example: `<invoke-workflow>{project-root}/bmad/core/workflows/x/workflow.yaml</invoke-workflow>`
→ Add "bmad/core/workflows/x/workflow.yaml" to web_bundle_files
4. Create web_bundle_files array with complete list
Example:
```yaml
web_bundle:
name: '{workflow_name}'
description: '{workflow_description}'
author: '{author}'
instructions: 'bmad/{module}/workflows/{workflow}/instructions.md'
validation: 'bmad/{module}/workflows/{workflow}/checklist.md'
template: 'bmad/{module}/workflows/{workflow}/template.md'
# Any data files (no config_source)
data_file: 'bmad/{module}/workflows/{workflow}/data.csv'
web_bundle_files:
- 'bmad/{module}/workflows/{workflow}/instructions.md'
- 'bmad/{module}/workflows/{workflow}/checklist.md'
- 'bmad/{module}/workflows/{workflow}/template.md'
- 'bmad/{module}/workflows/{workflow}/data.csv'
# Add every single file referenced anywhere
# CRITICAL: If this workflow invokes other workflows, use existing_workflows
# This signals the bundler to recursively include those workflows' web_bundles
existing_workflows:
- workflow_variable_name: 'bmad/path/to/workflow.yaml'
```
**Example with existing_workflows:**
```yaml
web_bundle:
name: 'brainstorm-game'
description: 'Game brainstorming with CIS workflow'
author: 'BMad'
instructions: 'bmad/bmm/workflows/brainstorm-game/instructions.md'
template: false
web_bundle_files:
- 'bmad/bmm/workflows/brainstorm-game/instructions.md'
- 'bmad/mmm/workflows/brainstorm-game/game-context.md'
- 'bmad/core/workflows/brainstorming/workflow.yaml'
existing_workflows:
- core_brainstorming: 'bmad/core/workflows/brainstorming/workflow.yaml'
```
**What existing_workflows does:**
- Tells the bundler this workflow invokes another workflow
- Bundler recursively includes the invoked workflow's entire web_bundle
- Essential for meta-workflows that orchestrate other workflows
- Maps workflow variable names to their bmad/-relative paths
<action>Validate web bundle completeness:</action>
- Ensure no {config_source} variables remain
- Verify all file paths are listed
- Check that paths are bmad/-relative
- If workflow uses <invoke-workflow>, add to existing_workflows
<template-output>web_bundle_config</template-output>
</step>
<step n="10" goal="Document and finalize">
<action>Create a brief README for the workflow folder explaining purpose, how to invoke, expected inputs, generated outputs, and any special requirements</action>
<action>Provide {user_name} with workflow completion summary in {communication_language}:</action>
- Location of created workflow: {{output_folder}}
- Command to run it: `workflow {workflow_name}`
- Next steps:
- Run the BMAD Method installer to this project location
- Select 'Compile Agents (Quick rebuild of all agent .md files)' after confirming the folder
- This will compile the new workflow and make it available for use
</step>
</workflow>

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,24 @@
# {Title} Checklist Validation
## {Section Foo}
- [ ] Check 1
- [ ] Check 2
- [ ] ...
- [ ] Check n
...
## {Section Bar}
- [ ] Check 1
- [ ] Check 2
- [ ] ...
- [ ] Check n
## Final Validation
- [ ] Section Foo
- Issue List
- [ ] Section Bar
- Issue List

View File

@@ -0,0 +1,13 @@
# PRD Workflow Instructions
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-related}/bmad/{module-code}/workflows/{workflow}/workflow.yaml</critical>
<critical>Communicate in {communication_language} throughout the workflow process</critical>
<workflow>
<step n="1" goal="">
...
</step>
...
</workflow>

View File

@@ -0,0 +1,9 @@
# Title
**Date:** {{date}}
## {Section 1}
{{section_1_results}}
etc...

View File

@@ -0,0 +1,40 @@
# {TITLE} Workflow Template Configuration
name: "{WORKFLOW_CODE}"
description: "{WORKFLOW_DESCRIPTION}"
author: "BMad"
# Critical variables load from config_source
# Add Additional Config Pulled Variables Here
config_source: "{project-root}/{module-code}/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
date: system-generated
# Required Data Files - HALT if missing!
# optional, can be omitted
brain_techniques: "{installed_path}/{critical-data-file.csv}" # example, can be other formats or URLs
# Optional docs that if loaded on start to kickstart this workflow or used at some point, these are meant to be suggested inputs for the user
recommended_inputs: # optional, can be omitted
- example_input: "{project-root}/{path/to/file.md}"
# Module path and component files
installed_path: "{project-root}/bmad/{module-code}/workflows/{workflow-code}"
template: "{installed_path}/template.md" # optional, can be omitted
instructions: "{installed_path}/instructions.md" # optional, can be omitted
validation: "{installed_path}/checklist.md" # optional, can be omitted
# Output configuration
default_output_file: "{output_folder}/{file.md}" # optional, can be omitted
validation_output_file: "{output_folder}/{file-validation-report.md}" # optional, can be omitted
# Tool Requirements (MCP Required Tools or other tools needed to run this workflow)
required_tools: #optional, can be omitted
- "Tool Name": #example, can be omitted if none
description: "Description of why this tool is needed"
link: "https://link-to-tool.com"
# Web Bundle Configuration (optional - for web-deployable workflows)
# IMPORTANT: Web bundles are self-contained and cannot use config_source variables
# All referenced files must be listed in web_bundle_files

View File

@@ -0,0 +1,41 @@
# Build Workflow - Workflow Builder Configuration
name: create-workflow
description: "Interactive workflow builder that guides creation of new BMAD workflows with proper structure and validation for optimal human-AI collaboration. Includes optional brainstorming phase for workflow ideas and design."
author: "BMad Builder"
# Critical variables
config_source: "{project-root}/bmad/bmb/config.yaml"
custom_workflow_location: "{config_source}:custom_workflow_location"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
# Template files for new workflows
template_workflow_yaml: "{workflow_template_path}/workflow.yaml"
template_instructions: "{workflow_template_path}/instructions.md"
template_template: "{workflow_template_path}/template.md"
template_checklist: "{workflow_template_path}/checklist.md"
# Optional input docs
recommended_inputs:
- existing_workflows: "{project-root}/bmad/*/workflows/"
- bmm_workflows: "{project-root}/bmad/bmm/workflows/"
# Module path and component files
installed_path: "{project-root}/bmad/bmb/workflows/create-workflow"
template: false # This is an action workflow - no template needed
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Required data files - CRITICAL for workflow conventions
workflow_creation_guide: "{installed_path}/workflow-creation-guide.md"
workflow_template_path: "{installed_path}/workflow-template"
# Output configuration - Creates the new workflow folder with all files
# If workflow belongs to a module: Save to module's workflows folder
# If standalone workflow: Save to custom_workflow_location/{{workflow_name}}
module_output_folder: "{project-root}/bmad/{{target_module}}/workflows/{{workflow_name}}"
standalone_output_folder: "{custom_workflow_location}/{{workflow_name}}"
standalone: true
# Web bundle configuration