feat: L'Ami Fiduciaire V1.0.0 — full codebase with Story 0.1 complete
Initial commit of the L'Ami Fiduciaire SaaS platform built on Laravel 12, Vue 3, Inertia.js 2, and Tailwind CSS 4. Story 0.1 (rename folders to declarations in database) is implemented and code-reviewed: migration, rollback, and 6 Pest tests all passing. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
150
_bmad/bmb/workflows/workflow/data/architecture.md
Normal file
150
_bmad/bmb/workflows/workflow/data/architecture.md
Normal file
@@ -0,0 +1,150 @@
|
||||
# Workflow Architecture
|
||||
|
||||
**Purpose:** Core structural patterns for BMAD workflows.
|
||||
|
||||
---
|
||||
|
||||
## Structure
|
||||
|
||||
```
|
||||
workflow-folder/
|
||||
├── workflow.md # Entry point, configuration
|
||||
├── steps-c/ # Create flow steps
|
||||
│ ├── step-01-init.md
|
||||
│ ├── step-02-[name].md
|
||||
│ └── step-N-[name].md
|
||||
├── steps-e/ # Edit flow (if needed)
|
||||
├── steps-v/ # Validate flow (if needed)
|
||||
├── data/ # Shared reference files
|
||||
└── templates/ # Output templates (if needed)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## workflow.md Standards
|
||||
|
||||
**CRITICAL:** workflow.md MUST be lean — entry point only.
|
||||
|
||||
**❌ PROHIBITED:**
|
||||
- Listing all steps (defeats progressive disclosure)
|
||||
- Detailed step descriptions (steps are self-documenting)
|
||||
- Validation checklists (belong in steps-v/)
|
||||
- Implementation details (belong in step files)
|
||||
|
||||
**✅ REQUIRED:**
|
||||
- Frontmatter: name, description, web_bundle
|
||||
- Goal: What the workflow accomplishes
|
||||
- Role: Who the AI embodies
|
||||
- Meta-context: Architecture background (if pattern demo)
|
||||
- Core principles (step-file design, JIT loading, etc.)
|
||||
- Initialization/routing: How to start, which step first
|
||||
|
||||
**Progressive Disclosure:** Users ONLY know about current step. workflow.md routes to first step, each step routes to next. No step lists in workflow.md!
|
||||
|
||||
---
|
||||
|
||||
## Core Principles
|
||||
|
||||
### 1. Micro-File Design
|
||||
- Each step: ~80-200 lines, focused
|
||||
- One concept per step
|
||||
- Self-contained instructions
|
||||
|
||||
### 2. Just-In-Time Loading
|
||||
- Only current step in memory
|
||||
- Never load future steps until 'C' selected
|
||||
- Progressive disclosure = LLM focus
|
||||
|
||||
### 3. Sequential Enforcement
|
||||
- Steps execute in order
|
||||
- No skipping, no optimization
|
||||
- Each step completes before next loads
|
||||
|
||||
### 4. State Tracking
|
||||
For continuable workflows:
|
||||
```yaml
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather', 'step-03-design']
|
||||
lastStep: 'step-03-design'
|
||||
lastContinued: '2025-01-02'
|
||||
```
|
||||
Each step appends its name to `stepsCompleted` before loading next.
|
||||
|
||||
---
|
||||
|
||||
## Execution Flow
|
||||
|
||||
**Fresh Start:**
|
||||
```
|
||||
workflow.md → step-01-init.md → step-02-[name].md → ... → step-N-final.md
|
||||
```
|
||||
|
||||
**Continuation:**
|
||||
```
|
||||
workflow.md → step-01-init.md (detects existing) → step-01b-continue.md → [next step]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Variables
|
||||
|
||||
### Standard
|
||||
```yaml
|
||||
workflow_path: '{project-root}/_bmad/[module]/workflows/[name]'
|
||||
thisStepFile: './step-[N]-[name].md'
|
||||
nextStepFile: './step-[N+1]-[name].md'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
```
|
||||
|
||||
### Module-Specific
|
||||
```yaml
|
||||
bmb_creations_output_folder: '{project-root}/_bmad/bmb-creations'
|
||||
```
|
||||
|
||||
### Rules
|
||||
- ONLY variables used in step body go in frontmatter
|
||||
- All file references use `{variable}` format
|
||||
- Paths within workflow folder are relative
|
||||
|
||||
---
|
||||
|
||||
## Menu Pattern
|
||||
|
||||
```markdown
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] [action] [P] [action] [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {task}, then redisplay menu
|
||||
- IF P: Execute {task}, then redisplay menu
|
||||
- IF C: Save to {outputFile}, update frontmatter, then load {nextStepFile}
|
||||
- IF Any other: help user, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
```
|
||||
|
||||
**A/P not needed in:** Step 1 (init), validation sequences, simple data gathering
|
||||
|
||||
---
|
||||
|
||||
## Output Pattern
|
||||
|
||||
Every step writes BEFORE loading next:
|
||||
|
||||
1. **Plan-then-build:** Steps append to plan.md → build step consumes plan
|
||||
2. **Direct-to-final:** Steps append directly to final document
|
||||
|
||||
See: `output-format-standards.md`
|
||||
|
||||
---
|
||||
|
||||
## Critical Rules
|
||||
|
||||
- 🛑 NEVER load multiple step files simultaneously
|
||||
- 📖 ALWAYS read entire step file before execution
|
||||
- 🚫 NEVER skip steps or optimize the sequence
|
||||
- 💾 ALWAYS update frontmatter when step completes
|
||||
- ⏸️ ALWAYS halt at menus and wait for input
|
||||
- 📋 NEVER create mental todos from future steps
|
||||
150
_bmad/bmb/workflows/workflow/data/architecture.md.bak
Normal file
150
_bmad/bmb/workflows/workflow/data/architecture.md.bak
Normal file
@@ -0,0 +1,150 @@
|
||||
# Workflow Architecture
|
||||
|
||||
**Purpose:** Core structural patterns for BMAD workflows.
|
||||
|
||||
---
|
||||
|
||||
## Structure
|
||||
|
||||
```
|
||||
workflow-folder/
|
||||
├── workflow.md # Entry point, configuration
|
||||
├── steps-c/ # Create flow steps
|
||||
│ ├── step-01-init.md
|
||||
│ ├── step-02-[name].md
|
||||
│ └── step-N-[name].md
|
||||
├── steps-e/ # Edit flow (if needed)
|
||||
├── steps-v/ # Validate flow (if needed)
|
||||
├── data/ # Shared reference files
|
||||
└── templates/ # Output templates (if needed)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## workflow.md Standards
|
||||
|
||||
**CRITICAL:** workflow.md MUST be lean — entry point only.
|
||||
|
||||
**❌ PROHIBITED:**
|
||||
- Listing all steps (defeats progressive disclosure)
|
||||
- Detailed step descriptions (steps are self-documenting)
|
||||
- Validation checklists (belong in steps-v/)
|
||||
- Implementation details (belong in step files)
|
||||
|
||||
**✅ REQUIRED:**
|
||||
- Frontmatter: name, description, web_bundle
|
||||
- Goal: What the workflow accomplishes
|
||||
- Role: Who the AI embodies
|
||||
- Meta-context: Architecture background (if pattern demo)
|
||||
- Core principles (step-file design, JIT loading, etc.)
|
||||
- Initialization/routing: How to start, which step first
|
||||
|
||||
**Progressive Disclosure:** Users ONLY know about current step. workflow.md routes to first step, each step routes to next. No step lists in workflow.md!
|
||||
|
||||
---
|
||||
|
||||
## Core Principles
|
||||
|
||||
### 1. Micro-File Design
|
||||
- Each step: ~80-200 lines, focused
|
||||
- One concept per step
|
||||
- Self-contained instructions
|
||||
|
||||
### 2. Just-In-Time Loading
|
||||
- Only current step in memory
|
||||
- Never load future steps until 'C' selected
|
||||
- Progressive disclosure = LLM focus
|
||||
|
||||
### 3. Sequential Enforcement
|
||||
- Steps execute in order
|
||||
- No skipping, no optimization
|
||||
- Each step completes before next loads
|
||||
|
||||
### 4. State Tracking
|
||||
For continuable workflows:
|
||||
```yaml
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather', 'step-03-design']
|
||||
lastStep: 'step-03-design'
|
||||
lastContinued: '2025-01-02'
|
||||
```
|
||||
Each step appends its name to `stepsCompleted` before loading next.
|
||||
|
||||
---
|
||||
|
||||
## Execution Flow
|
||||
|
||||
**Fresh Start:**
|
||||
```
|
||||
workflow.md → step-01-init.md → step-02-[name].md → ... → step-N-final.md
|
||||
```
|
||||
|
||||
**Continuation:**
|
||||
```
|
||||
workflow.md → step-01-init.md (detects existing) → step-01b-continue.md → [next step]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Variables
|
||||
|
||||
### Standard
|
||||
```yaml
|
||||
workflow_path: '{project-root}/_bmad/[module]/workflows/[name]'
|
||||
thisStepFile: './step-[N]-[name].md'
|
||||
nextStepFile: './step-[N+1]-[name].md'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
```
|
||||
|
||||
### Module-Specific
|
||||
```yaml
|
||||
bmb_creations_output_folder: '{project-root}/_bmad/bmb-creations'
|
||||
```
|
||||
|
||||
### Rules
|
||||
- ONLY variables used in step body go in frontmatter
|
||||
- All file references use `{variable}` format
|
||||
- Paths within workflow folder are relative
|
||||
|
||||
---
|
||||
|
||||
## Menu Pattern
|
||||
|
||||
```markdown
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] [action] [P] [action] [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {task}, then redisplay menu
|
||||
- IF P: Execute {task}, then redisplay menu
|
||||
- IF C: Save to {outputFile}, update frontmatter, then load {nextStepFile}
|
||||
- IF Any other: help user, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
```
|
||||
|
||||
**A/P not needed in:** Step 1 (init), validation sequences, simple data gathering
|
||||
|
||||
---
|
||||
|
||||
## Output Pattern
|
||||
|
||||
Every step writes BEFORE loading next:
|
||||
|
||||
1. **Plan-then-build:** Steps append to plan.md → build step consumes plan
|
||||
2. **Direct-to-final:** Steps append directly to final document
|
||||
|
||||
See: `output-format-standards.md`
|
||||
|
||||
---
|
||||
|
||||
## Critical Rules
|
||||
|
||||
- 🛑 NEVER load multiple step files simultaneously
|
||||
- 📖 ALWAYS read entire step file before execution
|
||||
- 🚫 NEVER skip steps or optimize the sequence
|
||||
- 💾 ALWAYS update frontmatter when step completes
|
||||
- ⏸️ ALWAYS halt at menus and wait for input
|
||||
- 📋 NEVER create mental todos from future steps
|
||||
19
_bmad/bmb/workflows/workflow/data/common-workflow-tools.csv
Normal file
19
_bmad/bmb/workflows/workflow/data/common-workflow-tools.csv
Normal file
@@ -0,0 +1,19 @@
|
||||
propose,type,tool_name,description,url,requires_install
|
||||
always,workflow,party-mode,"Enables collaborative idea generation by managing turn-taking, summarizing contributions, and synthesizing ideas from multiple AI personas in structured conversation sessions.",{project-root}/_bmad/core/workflows/party-mode/workflow.md,no
|
||||
always,workflow,advanced-elicitation,"Employs diverse elicitation strategies such as Socratic questioning, role-playing, and counterfactual analysis to critically evaluate and enhance LLM outputs.",{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml,no
|
||||
always,task,brainstorming,"Facilitates idea generation by prompting users with targeted questions and synthesizing concepts into actionable insights.",{project-root}/_bmad/core/tasks/brainstorming.xml,no
|
||||
always,llm-tool-feature,web-browsing,"Provides LLM with capabilities to perform real-time web searches and incorporate current information.",,no
|
||||
always,llm-tool-feature,file-io,"Enables LLM to manage file operations such as creating, reading, updating, and deleting files.",,no
|
||||
always,llm-tool-feature,sub-agents,"Allows LLM to create and manage specialized sub-agents for parallel processing and modular task delegation.",,no
|
||||
always,llm-tool-feature,sub-processes,"Enables LLM to initiate and manage subprocesses for parallel processing of complex tasks.",,no
|
||||
always,tool-memory,sidecar-file,"Creates a persistent history file for session-to-session state management, enabling continuity through workflow initialization with previous context.",,no
|
||||
example,tool-memory,vector-database,"Stores and retrieves semantic information through embeddings for intelligent memory access based on meaning rather than exact matches.",https://github.com/modelcontextprotocol/servers/tree/main/src/rag-agent,yes
|
||||
example,mcp,context-7,"A curated knowledge base of API documentation and third-party tool references for integration and development tasks.",https://github.com/modelcontextprotocol/servers/tree/main/src/context-7,yes
|
||||
example,mcp,playwright,"Provides capabilities for web browser automation including navigation, form submission, and data extraction.",https://github.com/modelcontextprotocol/servers/tree/main/src/playwright,yes
|
||||
example,workflow,security-auditor,"Analyzes workflows and code for security vulnerabilities, compliance issues, and best practices violations.",,no
|
||||
example,task,code-review,"Performs systematic code analysis identifying bugs, performance issues, style violations, and architectural problems.",,no
|
||||
example,mcp,git-integration,"Enables direct Git repository operations including commits, branches, merges, and history analysis.",https://github.com/modelcontextprotocol/servers/tree/main/src/git,yes
|
||||
example,mcp,database-connector,"Provides direct database connectivity for querying, updating, and managing data across multiple database types.",https://github.com/modelcontextprotocol/servers/tree/main/src/postgres,yes
|
||||
example,task,api-testing,"Automated API endpoint testing with request/response validation and authentication handling for REST and GraphQL.",,no
|
||||
example,workflow,deployment-manager,"Orchestrates application deployment across multiple environments with rollback capabilities and health checks.",,no
|
||||
example,task,data-validator,"Validates data quality, schema compliance, and business rules through comprehensive data profiling.",,no
|
||||
|
@@ -0,0 +1,19 @@
|
||||
propose,type,tool_name,description,url,requires_install
|
||||
always,workflow,party-mode,"Enables collaborative idea generation by managing turn-taking, summarizing contributions, and synthesizing ideas from multiple AI personas in structured conversation sessions.",{project-root}/_bmad/core/workflows/party-mode/workflow.md,no
|
||||
always,workflow,advanced-elicitation,"Employs diverse elicitation strategies such as Socratic questioning, role-playing, and counterfactual analysis to critically evaluate and enhance LLM outputs.",{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml,no
|
||||
always,task,brainstorming,"Facilitates idea generation by prompting users with targeted questions and synthesizing concepts into actionable insights.",{project-root}/_bmad/core/tasks/brainstorming.xml,no
|
||||
always,llm-tool-feature,web-browsing,"Provides LLM with capabilities to perform real-time web searches and incorporate current information.",,no
|
||||
always,llm-tool-feature,file-io,"Enables LLM to manage file operations such as creating, reading, updating, and deleting files.",,no
|
||||
always,llm-tool-feature,sub-agents,"Allows LLM to create and manage specialized sub-agents for parallel processing and modular task delegation.",,no
|
||||
always,llm-tool-feature,sub-processes,"Enables LLM to initiate and manage subprocesses for parallel processing of complex tasks.",,no
|
||||
always,tool-memory,sidecar-file,"Creates a persistent history file for session-to-session state management, enabling continuity through workflow initialization with previous context.",,no
|
||||
example,tool-memory,vector-database,"Stores and retrieves semantic information through embeddings for intelligent memory access based on meaning rather than exact matches.",https://github.com/modelcontextprotocol/servers/tree/main/src/rag-agent,yes
|
||||
example,mcp,context-7,"A curated knowledge base of API documentation and third-party tool references for integration and development tasks.",https://github.com/modelcontextprotocol/servers/tree/main/src/context-7,yes
|
||||
example,mcp,playwright,"Provides capabilities for web browser automation including navigation, form submission, and data extraction.",https://github.com/modelcontextprotocol/servers/tree/main/src/playwright,yes
|
||||
example,workflow,security-auditor,"Analyzes workflows and code for security vulnerabilities, compliance issues, and best practices violations.",,no
|
||||
example,task,code-review,"Performs systematic code analysis identifying bugs, performance issues, style violations, and architectural problems.",,no
|
||||
example,mcp,git-integration,"Enables direct Git repository operations including commits, branches, merges, and history analysis.",https://github.com/modelcontextprotocol/servers/tree/main/src/git,yes
|
||||
example,mcp,database-connector,"Provides direct database connectivity for querying, updating, and managing data across multiple database types.",https://github.com/modelcontextprotocol/servers/tree/main/src/postgres,yes
|
||||
example,task,api-testing,"Automated API endpoint testing with request/response validation and authentication handling for REST and GraphQL.",,no
|
||||
example,workflow,deployment-manager,"Orchestrates application deployment across multiple environments with rollback capabilities and health checks.",,no
|
||||
example,task,data-validator,"Validates data quality, schema compliance, and business rules through comprehensive data profiling.",,no
|
||||
53
_bmad/bmb/workflows/workflow/data/csv-data-file-standards.md
Normal file
53
_bmad/bmb/workflows/workflow/data/csv-data-file-standards.md
Normal file
@@ -0,0 +1,53 @@
|
||||
# CSV Data File Standards
|
||||
|
||||
## When to Use CSV
|
||||
|
||||
Use for:
|
||||
- Domain-specific data not in training data
|
||||
- Too large for prompt context
|
||||
- Structured lookup/reference needs
|
||||
- Cross-session consistency required
|
||||
|
||||
**Don't use for:** Web-searchable info, common syntax, general knowledge, LLM-generatable content
|
||||
|
||||
## CSV Structure
|
||||
|
||||
```csv
|
||||
category,name,pattern,description
|
||||
"collaboration","Think Aloud Protocol","user speaks thoughts → facilitator captures","Make thinking visible during work"
|
||||
```
|
||||
|
||||
**Rules:**
|
||||
- Header row required, descriptive column names
|
||||
- Consistent data types per column
|
||||
- UTF-8 encoding
|
||||
- All columns must be used in workflow
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### Method Registry
|
||||
```csv
|
||||
category,name,pattern
|
||||
collaboration,Think Aloud,user speaks thoughts → facilitator captures
|
||||
advanced,Six Thinking Hats,view problem from 6 perspectives
|
||||
```
|
||||
|
||||
### Knowledge Base Index
|
||||
```csv
|
||||
keywords,document_path,section
|
||||
"nutrition,macros",data/nutrition-reference.md,## Daily Targets
|
||||
```
|
||||
|
||||
### Configuration Lookup
|
||||
```csv
|
||||
scenario,required_steps,output_sections
|
||||
"2D Platformer",step-01,step-03,step-07,movement,physics,collision
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Keep files small (<1MB preferred)
|
||||
- No unused columns
|
||||
- Use efficient encoding (codes vs full descriptions)
|
||||
- Document purpose
|
||||
- Validate data quality
|
||||
@@ -0,0 +1,53 @@
|
||||
# CSV Data File Standards
|
||||
|
||||
## When to Use CSV
|
||||
|
||||
Use for:
|
||||
- Domain-specific data not in training data
|
||||
- Too large for prompt context
|
||||
- Structured lookup/reference needs
|
||||
- Cross-session consistency required
|
||||
|
||||
**Don't use for:** Web-searchable info, common syntax, general knowledge, LLM-generatable content
|
||||
|
||||
## CSV Structure
|
||||
|
||||
```csv
|
||||
category,name,pattern,description
|
||||
"collaboration","Think Aloud Protocol","user speaks thoughts → facilitator captures","Make thinking visible during work"
|
||||
```
|
||||
|
||||
**Rules:**
|
||||
- Header row required, descriptive column names
|
||||
- Consistent data types per column
|
||||
- UTF-8 encoding
|
||||
- All columns must be used in workflow
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### Method Registry
|
||||
```csv
|
||||
category,name,pattern
|
||||
collaboration,Think Aloud,user speaks thoughts → facilitator captures
|
||||
advanced,Six Thinking Hats,view problem from 6 perspectives
|
||||
```
|
||||
|
||||
### Knowledge Base Index
|
||||
```csv
|
||||
keywords,document_path,section
|
||||
"nutrition,macros",data/nutrition-reference.md,## Daily Targets
|
||||
```
|
||||
|
||||
### Configuration Lookup
|
||||
```csv
|
||||
scenario,required_steps,output_sections
|
||||
"2D Platformer",step-01,step-03,step-07,movement,physics,collision
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Keep files small (<1MB preferred)
|
||||
- No unused columns
|
||||
- Use efficient encoding (codes vs full descriptions)
|
||||
- Document purpose
|
||||
- Validate data quality
|
||||
184
_bmad/bmb/workflows/workflow/data/frontmatter-standards.md
Normal file
184
_bmad/bmb/workflows/workflow/data/frontmatter-standards.md
Normal file
@@ -0,0 +1,184 @@
|
||||
# Frontmatter Standards
|
||||
|
||||
**Purpose:** Variables, paths, and frontmatter rules for workflow steps.
|
||||
|
||||
---
|
||||
|
||||
## Golden Rules
|
||||
|
||||
1. **Only variables USED in the step** may be in frontmatter
|
||||
2. **All file references MUST use `{variable}` format** - no hardcoded paths
|
||||
3. **Paths within workflow folder MUST be relative** - NO `workflow_path` variable allowed
|
||||
|
||||
---
|
||||
|
||||
## Standard Variables
|
||||
|
||||
| Variable | Example |
|
||||
|----------|---------|
|
||||
| `{project-root}` | `/Users/user/dev/BMAD-METHOD` <!-- validate-file-refs:ignore --> |
|
||||
| `{project_name}` | `my-project` |
|
||||
| `{output_folder}` | `/Users/user/dev/BMAD-METHOD/output` <!-- validate-file-refs:ignore --> |
|
||||
| `{user_name}` | `Brian` |
|
||||
| `{communication_language}` | `english` |
|
||||
| `{document_output_language}` | `english` |
|
||||
|
||||
---
|
||||
|
||||
## Module-Specific Variables
|
||||
|
||||
Workflows in a MODULE can access additional variables from its `module.yaml`.
|
||||
|
||||
**Example:**
|
||||
```yaml
|
||||
bmb_creations_output_folder: '{project-root}/_bmad/bmb-creations'
|
||||
```
|
||||
|
||||
**Standalone workflows:** Only have access to standard variables.
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Structure
|
||||
|
||||
### Required Fields
|
||||
```yaml
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
description: '[what this step does]'
|
||||
---
|
||||
```
|
||||
|
||||
### File References - ONLY variables used in this step
|
||||
```yaml
|
||||
---
|
||||
# Step to step (SAME folder) - use ./filename.md
|
||||
nextStepFile: './step-02-vision.md'
|
||||
|
||||
# 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'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Critical Rule: Unused Variables Forbidden
|
||||
|
||||
**Detection Rule:** For EVERY variable in frontmatter, search the step body for `{variableName}`. If not found, it's a violation.
|
||||
|
||||
### ❌ VIOLATION
|
||||
```yaml
|
||||
---
|
||||
outputFile: '{output_folder}/output.md'
|
||||
thisStepFile: './step-01-init.md' # ❌ NEVER USED
|
||||
workflowFile: './workflow.md' # ❌ NEVER USED
|
||||
---
|
||||
```
|
||||
|
||||
### ✅ CORRECT
|
||||
```yaml
|
||||
---
|
||||
outputFile: '{output_folder}/output.md'
|
||||
nextStepFile: './step-02-foo.md'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Path Rules
|
||||
|
||||
| Type | Format | Example |
|
||||
|------|--------|---------|
|
||||
| Step to Step (same folder) | `./filename.md` | `./step-02-vision.md` |
|
||||
| Step to Template (parent) | `../filename.md` | `../template.md` |
|
||||
| Step to Subfolder | `./subfolder/file.md` | `./data/config.csv` |
|
||||
| External References | `{project-root}/...` | `{project-root}/_bmad/core/workflows/...` |
|
||||
| Output Files | `{folder_variable}/...` | `{planning_artifacts}/output.md` |
|
||||
|
||||
---
|
||||
|
||||
## ❌ FORBIDDEN Patterns
|
||||
|
||||
| Pattern | Why |
|
||||
|---------|-----|
|
||||
| `workflow_path: '{project-root}/...'` | Use relative paths |
|
||||
| `thisStepFile: './step-XX.md'` | Remove unless referenced <!-- validate-file-refs:ignore --> |
|
||||
| `workflowFile: './workflow.md'` | Remove unless referenced <!-- validate-file-refs:ignore --> |
|
||||
| `{workflow_path}/templates/...` | Use `../template.md` |
|
||||
| `{workflow_path}/data/...` | Use `./data/file.md` |
|
||||
|
||||
---
|
||||
|
||||
## Variable Naming
|
||||
|
||||
Use `snake_case` with descriptive prefixes:
|
||||
|
||||
| Suffix | 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
|
||||
|
||||
Steps can define NEW variables for future steps.
|
||||
|
||||
**Step 01 defines:**
|
||||
```yaml
|
||||
---
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
|
||||
---
|
||||
```
|
||||
|
||||
**Step 02 uses:**
|
||||
```yaml
|
||||
---
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/plan.md'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Continuable Workflow Frontmatter
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather', 'step-03-design']
|
||||
lastStep: 'step-03-design'
|
||||
lastContinued: '2025-01-02'
|
||||
date: '2025-01-01'
|
||||
---
|
||||
```
|
||||
|
||||
**Step tracking:** Each step appends its NAME to `stepsCompleted`.
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For EVERY step frontmatter, verify:
|
||||
|
||||
- [ ] `name` present, kebab-case format
|
||||
- [ ] `description` present
|
||||
- [ ] Extract ALL variable names from frontmatter
|
||||
- [ ] For EACH variable, search body: is `{variableName}` present?
|
||||
- [ ] If variable NOT in body → ❌ VIOLATION, remove from frontmatter
|
||||
- [ ] All step-to-step paths use `./filename.md` format
|
||||
- [ ] 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
|
||||
- [ ] Module variables only used if workflow belongs to that module
|
||||
184
_bmad/bmb/workflows/workflow/data/frontmatter-standards.md.bak
Normal file
184
_bmad/bmb/workflows/workflow/data/frontmatter-standards.md.bak
Normal file
@@ -0,0 +1,184 @@
|
||||
# Frontmatter Standards
|
||||
|
||||
**Purpose:** Variables, paths, and frontmatter rules for workflow steps.
|
||||
|
||||
---
|
||||
|
||||
## Golden Rules
|
||||
|
||||
1. **Only variables USED in the step** may be in frontmatter
|
||||
2. **All file references MUST use `{variable}` format** - no hardcoded paths
|
||||
3. **Paths within workflow folder MUST be relative** - NO `workflow_path` variable allowed
|
||||
|
||||
---
|
||||
|
||||
## Standard Variables
|
||||
|
||||
| Variable | Example |
|
||||
|----------|---------|
|
||||
| `{project-root}` | `/Users/user/dev/BMAD-METHOD` <!-- validate-file-refs:ignore --> |
|
||||
| `{project_name}` | `my-project` |
|
||||
| `{output_folder}` | `/Users/user/dev/BMAD-METHOD/output` <!-- validate-file-refs:ignore --> |
|
||||
| `{user_name}` | `Brian` |
|
||||
| `{communication_language}` | `english` |
|
||||
| `{document_output_language}` | `english` |
|
||||
|
||||
---
|
||||
|
||||
## Module-Specific Variables
|
||||
|
||||
Workflows in a MODULE can access additional variables from its `module.yaml`.
|
||||
|
||||
**Example:**
|
||||
```yaml
|
||||
bmb_creations_output_folder: '{project-root}/_bmad/bmb-creations'
|
||||
```
|
||||
|
||||
**Standalone workflows:** Only have access to standard variables.
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Structure
|
||||
|
||||
### Required Fields
|
||||
```yaml
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
description: '[what this step does]'
|
||||
---
|
||||
```
|
||||
|
||||
### File References - ONLY variables used in this step
|
||||
```yaml
|
||||
---
|
||||
# Step to step (SAME folder) - use ./filename.md
|
||||
nextStepFile: './step-02-vision.md'
|
||||
|
||||
# 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'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Critical Rule: Unused Variables Forbidden
|
||||
|
||||
**Detection Rule:** For EVERY variable in frontmatter, search the step body for `{variableName}`. If not found, it's a violation.
|
||||
|
||||
### ❌ VIOLATION
|
||||
```yaml
|
||||
---
|
||||
outputFile: '{output_folder}/output.md'
|
||||
thisStepFile: './step-01-init.md' # ❌ NEVER USED
|
||||
workflowFile: './workflow.md' # ❌ NEVER USED
|
||||
---
|
||||
```
|
||||
|
||||
### ✅ CORRECT
|
||||
```yaml
|
||||
---
|
||||
outputFile: '{output_folder}/output.md'
|
||||
nextStepFile: './step-02-foo.md'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Path Rules
|
||||
|
||||
| Type | Format | Example |
|
||||
|------|--------|---------|
|
||||
| Step to Step (same folder) | `./filename.md` | `./step-02-vision.md` |
|
||||
| Step to Template (parent) | `../filename.md` | `../template.md` |
|
||||
| Step to Subfolder | `./subfolder/file.md` | `./data/config.csv` |
|
||||
| External References | `{project-root}/...` | `{project-root}/_bmad/core/workflows/...` |
|
||||
| Output Files | `{folder_variable}/...` | `{planning_artifacts}/output.md` |
|
||||
|
||||
---
|
||||
|
||||
## ❌ FORBIDDEN Patterns
|
||||
|
||||
| Pattern | Why |
|
||||
|---------|-----|
|
||||
| `workflow_path: '{project-root}/...'` | Use relative paths |
|
||||
| `thisStepFile: './step-XX.md'` | Remove unless referenced <!-- validate-file-refs:ignore --> |
|
||||
| `workflowFile: './workflow.md'` | Remove unless referenced <!-- validate-file-refs:ignore --> |
|
||||
| `{workflow_path}/templates/...` | Use `../template.md` |
|
||||
| `{workflow_path}/data/...` | Use `./data/file.md` |
|
||||
|
||||
---
|
||||
|
||||
## Variable Naming
|
||||
|
||||
Use `snake_case` with descriptive prefixes:
|
||||
|
||||
| Suffix | 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
|
||||
|
||||
Steps can define NEW variables for future steps.
|
||||
|
||||
**Step 01 defines:**
|
||||
```yaml
|
||||
---
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
|
||||
---
|
||||
```
|
||||
|
||||
**Step 02 uses:**
|
||||
```yaml
|
||||
---
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/plan.md'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Continuable Workflow Frontmatter
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather', 'step-03-design']
|
||||
lastStep: 'step-03-design'
|
||||
lastContinued: '2025-01-02'
|
||||
date: '2025-01-01'
|
||||
---
|
||||
```
|
||||
|
||||
**Step tracking:** Each step appends its NAME to `stepsCompleted`.
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For EVERY step frontmatter, verify:
|
||||
|
||||
- [ ] `name` present, kebab-case format
|
||||
- [ ] `description` present
|
||||
- [ ] Extract ALL variable names from frontmatter
|
||||
- [ ] For EACH variable, search body: is `{variableName}` present?
|
||||
- [ ] If variable NOT in body → ❌ VIOLATION, remove from frontmatter
|
||||
- [ ] All step-to-step paths use `./filename.md` format
|
||||
- [ ] 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
|
||||
- [ ] Module variables only used if workflow belongs to that module
|
||||
191
_bmad/bmb/workflows/workflow/data/input-discovery-standards.md
Normal file
191
_bmad/bmb/workflows/workflow/data/input-discovery-standards.md
Normal file
@@ -0,0 +1,191 @@
|
||||
# Input Document Discovery Standards
|
||||
|
||||
**Purpose:** Workflow input discovery, validation, and selection from prior workflows or external sources.
|
||||
|
||||
---
|
||||
|
||||
## Discovery Patterns
|
||||
|
||||
1. **Prior Workflow Output** - Sequential workflows (e.g., PRD → Architecture → Epics)
|
||||
2. **Module Folder Search** - Known project locations
|
||||
3. **User-Specified Paths** - User-provided document locations
|
||||
4. **Pattern-Based Discovery** - File naming pattern matching (e.g., `*-brief.md`)
|
||||
|
||||
---
|
||||
|
||||
## Discovery Step Pattern
|
||||
|
||||
**When:** Step 1 (init) or Step 2 (discovery)
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
# Input discovery variables
|
||||
inputDocuments: [] # Discovered docs
|
||||
requiredInputCount: 1 # Minimum required
|
||||
optionalInputCount: 0 # Additional optional docs
|
||||
moduleInputFolder: '{planning_artifacts}'
|
||||
inputFilePatterns:
|
||||
- '*-prd.md'
|
||||
- '*-ux.md'
|
||||
---
|
||||
```
|
||||
|
||||
**Discovery Logic:**
|
||||
```markdown
|
||||
## 1. Check Known Prior Workflow Outputs
|
||||
Search order:
|
||||
1. {module_output_folder}/[known-prior-workflow-output].md
|
||||
2. {project_folder}/[standard-locations]/
|
||||
3. {planning_artifacts}/
|
||||
4. User-provided paths
|
||||
|
||||
## 2. Pattern-Based Search
|
||||
If no known prior workflow: match {inputFilePatterns} in {moduleInputFolder} and {project_folder}/docs/
|
||||
|
||||
## 3. Present Findings
|
||||
"Found these documents:
|
||||
- [1] prd-my-project.md (3 days ago)
|
||||
- [2] ux-research.md (1 week ago)
|
||||
|
||||
Select multiple or provide additional paths."
|
||||
|
||||
## 4. Confirm and Load
|
||||
Add selections to {inputDocuments} array in output frontmatter
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Required vs Optional Inputs
|
||||
|
||||
**Required:** Workflow cannot proceed without these.
|
||||
```markdown
|
||||
## INPUT REQUIREMENT:
|
||||
Requires PRD to proceed.
|
||||
|
||||
Searching: {bmm_creations_output_folder}/prd-*.md, {planning_artifacts}/*-prd.md
|
||||
|
||||
[Found:] "Found PRD: prd-my-project.md. Use this?"
|
||||
[Missing:] "No PRD found. Run PRD workflow first or provide path."
|
||||
```
|
||||
|
||||
**Optional:** Workflow can proceed without these.
|
||||
```markdown
|
||||
## OPTIONAL INPUTS:
|
||||
Can incorporate research if available.
|
||||
|
||||
Searching: {bmm_creations_output_folder}/research-*.md, {project_folder}/research/
|
||||
|
||||
[Found:] "Found research documents. Include any? (None required)"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Module Workflow Chaining
|
||||
|
||||
**Frontmatter in workflow.md:**
|
||||
```yaml
|
||||
---
|
||||
## INPUT FROM PRIOR WORKFLOWS
|
||||
|
||||
### Required Inputs:
|
||||
- {module_output_folder}/prd-{project_name}.md
|
||||
|
||||
### Optional Inputs:
|
||||
- {module_output_folder}/ux-research-{project_name}.md
|
||||
---
|
||||
```
|
||||
|
||||
**Step 1 discovery:**
|
||||
```markdown
|
||||
## 1. Discover Prior Workflow Outputs
|
||||
|
||||
Check required: {module_output_folder}/prd-{project_name}.md
|
||||
- Missing → Error: "Run PRD workflow first"
|
||||
- Found → Confirm with user
|
||||
|
||||
Check optional: Search for patterns, present findings, add selections to {inputDocuments}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Input Validation
|
||||
|
||||
```markdown
|
||||
## INPUT VALIDATION:
|
||||
|
||||
For each discovered document:
|
||||
1. Load frontmatter
|
||||
2. Check workflowType matches expected
|
||||
3. Check stepsCompleted == complete
|
||||
4. Check date (warn if old)
|
||||
|
||||
[Fail:] "Document appears incomplete. Last step: step-06 (of 11). Proceed anyway?"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Multiple Input Selection
|
||||
|
||||
```markdown
|
||||
## Document Selection
|
||||
|
||||
"Found relevant documents:
|
||||
[1] prd-my-project.md (3 days ago) ✓ Recommended
|
||||
[2] prd-v1.md (2 months ago) ⚠ Older
|
||||
|
||||
Enter numbers (comma-separated): > 1, 3"
|
||||
```
|
||||
|
||||
**Track in frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
inputDocuments:
|
||||
- path: '{output_folder}/prd-my-project.md'
|
||||
type: 'prd'
|
||||
source: 'prior-workflow'
|
||||
selected: true
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Search Path Variables
|
||||
|
||||
| Variable | Purpose |
|
||||
| ------------------------ | -------------------------- |
|
||||
| `{module_output_folder}` | Prior workflow outputs |
|
||||
| `{planning_artifacts}` | General planning docs |
|
||||
| `{project_folder}/docs` | Project documentation |
|
||||
| `{product_knowledge}` | Product-specific knowledge |
|
||||
| `{user_documents}` | User-provided location |
|
||||
|
||||
---
|
||||
|
||||
## Discovery Step Template
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize and discover input documents'
|
||||
|
||||
# Input Discovery
|
||||
inputDocuments: []
|
||||
requiredInputCount: 1
|
||||
moduleInputFolder: '{module_output_folder}'
|
||||
inputFilePatterns:
|
||||
- '*-prd.md'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- [ ] Required inputs defined in step frontmatter
|
||||
- [ ] Search paths defined (module variables or patterns)
|
||||
- [ ] User confirmation before using documents
|
||||
- [ ] Validation of document completeness
|
||||
- [ ] Clear error messages when required inputs missing
|
||||
- [ ] Support for multiple document selection
|
||||
- [ ] Optional inputs clearly marked
|
||||
@@ -0,0 +1,191 @@
|
||||
# Input Document Discovery Standards
|
||||
|
||||
**Purpose:** Workflow input discovery, validation, and selection from prior workflows or external sources.
|
||||
|
||||
---
|
||||
|
||||
## Discovery Patterns
|
||||
|
||||
1. **Prior Workflow Output** - Sequential workflows (e.g., PRD → Architecture → Epics)
|
||||
2. **Module Folder Search** - Known project locations
|
||||
3. **User-Specified Paths** - User-provided document locations
|
||||
4. **Pattern-Based Discovery** - File naming pattern matching (e.g., `*-brief.md`)
|
||||
|
||||
---
|
||||
|
||||
## Discovery Step Pattern
|
||||
|
||||
**When:** Step 1 (init) or Step 2 (discovery)
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
# Input discovery variables
|
||||
inputDocuments: [] # Discovered docs
|
||||
requiredInputCount: 1 # Minimum required
|
||||
optionalInputCount: 0 # Additional optional docs
|
||||
moduleInputFolder: '{planning_artifacts}'
|
||||
inputFilePatterns:
|
||||
- '*-prd.md'
|
||||
- '*-ux.md'
|
||||
---
|
||||
```
|
||||
|
||||
**Discovery Logic:**
|
||||
```markdown
|
||||
## 1. Check Known Prior Workflow Outputs
|
||||
Search order:
|
||||
1. {module_output_folder}/[known-prior-workflow-output].md
|
||||
2. {project_folder}/[standard-locations]/
|
||||
3. {planning_artifacts}/
|
||||
4. User-provided paths
|
||||
|
||||
## 2. Pattern-Based Search
|
||||
If no known prior workflow: match {inputFilePatterns} in {moduleInputFolder} and {project_folder}/docs/
|
||||
|
||||
## 3. Present Findings
|
||||
"Found these documents:
|
||||
- [1] prd-my-project.md (3 days ago)
|
||||
- [2] ux-research.md (1 week ago)
|
||||
|
||||
Select multiple or provide additional paths."
|
||||
|
||||
## 4. Confirm and Load
|
||||
Add selections to {inputDocuments} array in output frontmatter
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Required vs Optional Inputs
|
||||
|
||||
**Required:** Workflow cannot proceed without these.
|
||||
```markdown
|
||||
## INPUT REQUIREMENT:
|
||||
Requires PRD to proceed.
|
||||
|
||||
Searching: {bmm_creations_output_folder}/prd-*.md, {planning_artifacts}/*-prd.md
|
||||
|
||||
[Found:] "Found PRD: prd-my-project.md. Use this?"
|
||||
[Missing:] "No PRD found. Run PRD workflow first or provide path."
|
||||
```
|
||||
|
||||
**Optional:** Workflow can proceed without these.
|
||||
```markdown
|
||||
## OPTIONAL INPUTS:
|
||||
Can incorporate research if available.
|
||||
|
||||
Searching: {bmm_creations_output_folder}/research-*.md, {project_folder}/research/
|
||||
|
||||
[Found:] "Found research documents. Include any? (None required)"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Module Workflow Chaining
|
||||
|
||||
**Frontmatter in workflow.md:**
|
||||
```yaml
|
||||
---
|
||||
## INPUT FROM PRIOR WORKFLOWS
|
||||
|
||||
### Required Inputs:
|
||||
- {module_output_folder}/prd-{project_name}.md
|
||||
|
||||
### Optional Inputs:
|
||||
- {module_output_folder}/ux-research-{project_name}.md
|
||||
---
|
||||
```
|
||||
|
||||
**Step 1 discovery:**
|
||||
```markdown
|
||||
## 1. Discover Prior Workflow Outputs
|
||||
|
||||
Check required: {module_output_folder}/prd-{project_name}.md
|
||||
- Missing → Error: "Run PRD workflow first"
|
||||
- Found → Confirm with user
|
||||
|
||||
Check optional: Search for patterns, present findings, add selections to {inputDocuments}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Input Validation
|
||||
|
||||
```markdown
|
||||
## INPUT VALIDATION:
|
||||
|
||||
For each discovered document:
|
||||
1. Load frontmatter
|
||||
2. Check workflowType matches expected
|
||||
3. Check stepsCompleted == complete
|
||||
4. Check date (warn if old)
|
||||
|
||||
[Fail:] "Document appears incomplete. Last step: step-06 (of 11). Proceed anyway?"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Multiple Input Selection
|
||||
|
||||
```markdown
|
||||
## Document Selection
|
||||
|
||||
"Found relevant documents:
|
||||
[1] prd-my-project.md (3 days ago) ✓ Recommended
|
||||
[2] prd-v1.md (2 months ago) ⚠ Older
|
||||
|
||||
Enter numbers (comma-separated): > 1, 3"
|
||||
```
|
||||
|
||||
**Track in frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
inputDocuments:
|
||||
- path: '{output_folder}/prd-my-project.md'
|
||||
type: 'prd'
|
||||
source: 'prior-workflow'
|
||||
selected: true
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Search Path Variables
|
||||
|
||||
| Variable | Purpose |
|
||||
| ------------------------ | -------------------------- |
|
||||
| `{module_output_folder}` | Prior workflow outputs |
|
||||
| `{planning_artifacts}` | General planning docs |
|
||||
| `{project_folder}/docs` | Project documentation |
|
||||
| `{product_knowledge}` | Product-specific knowledge |
|
||||
| `{user_documents}` | User-provided location |
|
||||
|
||||
---
|
||||
|
||||
## Discovery Step Template
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize and discover input documents'
|
||||
|
||||
# Input Discovery
|
||||
inputDocuments: []
|
||||
requiredInputCount: 1
|
||||
moduleInputFolder: '{module_output_folder}'
|
||||
inputFilePatterns:
|
||||
- '*-prd.md'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- [ ] Required inputs defined in step frontmatter
|
||||
- [ ] Search paths defined (module variables or patterns)
|
||||
- [ ] User confirmation before using documents
|
||||
- [ ] Validation of document completeness
|
||||
- [ ] Clear error messages when required inputs missing
|
||||
- [ ] Support for multiple document selection
|
||||
- [ ] Optional inputs clearly marked
|
||||
@@ -0,0 +1,44 @@
|
||||
# Intent vs Prescriptive Spectrum
|
||||
|
||||
**Principle:** Workflows lean toward **intent** (goals) not **prescription** (exact wording). The more intent-based, the more adaptive and creative the LLM can be.
|
||||
|
||||
## When to Use Each
|
||||
|
||||
### Intent-Based (Default)
|
||||
**Use for:** Most workflows - creative, exploratory, collaborative
|
||||
**Step instruction:** "Help the user understand X using multi-turn conversation. Probe to get good answers. Ask 1-2 questions at a time, not a laundry list."
|
||||
**LLM figures out:** Exact wording, question order, how to respond
|
||||
|
||||
### Prescriptive (Exception)
|
||||
**Use for:** Compliance, safety, legal, medical, regulated industries
|
||||
**Step instruction:** "Say exactly: 'Do you currently experience fever, cough, or fatigue?' Wait for response. Then ask exactly: 'When did symptoms begin?'"
|
||||
**LLM follows:** Exact script, specific order, no deviation
|
||||
|
||||
## Examples
|
||||
|
||||
### Intent-Based (Good for most)
|
||||
```
|
||||
"Guide the user through discovering their ideal nutrition plan.
|
||||
Use multi-turn conversation. Ask 1-2 questions at a time.
|
||||
Think about their responses before asking follow-ups.
|
||||
Probe to understand preferences, restrictions, goals."
|
||||
```
|
||||
|
||||
### Prescriptive (Only when required)
|
||||
```
|
||||
"Medical intake - ask exactly:
|
||||
1. 'Do you have any of these symptoms: fever, cough, fatigue?'
|
||||
2. 'When did symptoms begin?'
|
||||
3. 'Have you traveled recently in the last 14 days?'
|
||||
Follow sequence precisely. Do not deviate."
|
||||
```
|
||||
|
||||
## Step Writing Tips
|
||||
|
||||
- **Default to intent** - give goals, not scripts
|
||||
- **Use "think"** - "Think about their response before..."
|
||||
- **Multi-turn** - "Use conversation, not interrogation"
|
||||
- **Progressive** - "Ask 1-2 questions at a time"
|
||||
- **Probe** - "Ask follow-ups to understand deeper"
|
||||
|
||||
Only use prescriptive when compliance/regulation requires it.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Intent vs Prescriptive Spectrum
|
||||
|
||||
**Principle:** Workflows lean toward **intent** (goals) not **prescription** (exact wording). The more intent-based, the more adaptive and creative the LLM can be.
|
||||
|
||||
## When to Use Each
|
||||
|
||||
### Intent-Based (Default)
|
||||
**Use for:** Most workflows - creative, exploratory, collaborative
|
||||
**Step instruction:** "Help the user understand X using multi-turn conversation. Probe to get good answers. Ask 1-2 questions at a time, not a laundry list."
|
||||
**LLM figures out:** Exact wording, question order, how to respond
|
||||
|
||||
### Prescriptive (Exception)
|
||||
**Use for:** Compliance, safety, legal, medical, regulated industries
|
||||
**Step instruction:** "Say exactly: 'Do you currently experience fever, cough, or fatigue?' Wait for response. Then ask exactly: 'When did symptoms begin?'"
|
||||
**LLM follows:** Exact script, specific order, no deviation
|
||||
|
||||
## Examples
|
||||
|
||||
### Intent-Based (Good for most)
|
||||
```
|
||||
"Guide the user through discovering their ideal nutrition plan.
|
||||
Use multi-turn conversation. Ask 1-2 questions at a time.
|
||||
Think about their responses before asking follow-ups.
|
||||
Probe to understand preferences, restrictions, goals."
|
||||
```
|
||||
|
||||
### Prescriptive (Only when required)
|
||||
```
|
||||
"Medical intake - ask exactly:
|
||||
1. 'Do you have any of these symptoms: fever, cough, fatigue?'
|
||||
2. 'When did symptoms begin?'
|
||||
3. 'Have you traveled recently in the last 14 days?'
|
||||
Follow sequence precisely. Do not deviate."
|
||||
```
|
||||
|
||||
## Step Writing Tips
|
||||
|
||||
- **Default to intent** - give goals, not scripts
|
||||
- **Use "think"** - "Think about their response before..."
|
||||
- **Multi-turn** - "Use conversation, not interrogation"
|
||||
- **Progressive** - "Ask 1-2 questions at a time"
|
||||
- **Probe** - "Ask follow-ups to understand deeper"
|
||||
|
||||
Only use prescriptive when compliance/regulation requires it.
|
||||
133
_bmad/bmb/workflows/workflow/data/menu-handling-standards.md
Normal file
133
_bmad/bmb/workflows/workflow/data/menu-handling-standards.md
Normal file
@@ -0,0 +1,133 @@
|
||||
# Menu Handling Standards
|
||||
|
||||
**CRITICAL:** Every menu MUST have a handler section. No exceptions.
|
||||
|
||||
## Reserved Letters
|
||||
|
||||
| Letter | Purpose | After Execution |
|
||||
| ------ | -------------------- | ------------------------------ |
|
||||
| **A** | Advanced Elicitation | Redisplay menu |
|
||||
| **P** | Party Mode | Redisplay menu |
|
||||
| **C** | Continue/Accept | Save → update → load next step |
|
||||
| **X** | Exit/Cancel | End workflow |
|
||||
|
||||
**Custom letters** allowed (L/R/F/etc.) but don't conflict with reserved.
|
||||
|
||||
## Required Structure
|
||||
|
||||
### Section 1: Display
|
||||
```markdown
|
||||
### N. Present MENU OPTIONS
|
||||
Display: "**Select:** [A] [action] [P] [action] [C] Continue"
|
||||
```
|
||||
|
||||
### Section 2: Handler (MANDATORY)
|
||||
```markdown
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
```
|
||||
|
||||
### Section 3: Execution Rules
|
||||
```markdown
|
||||
#### 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
|
||||
```
|
||||
|
||||
## When To Include A/P
|
||||
|
||||
**DON'T Include A/P:** Step 1 (init), Step 2 if only loading documents, validation sequences, simple data gathering
|
||||
|
||||
**DO Include A/P:** Collaborative content creation, user might want alternatives, quality gate before proceeding, creative exploration valuable
|
||||
|
||||
## Menu Patterns
|
||||
|
||||
### Pattern 1: Standard A/P/C
|
||||
```markdown
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
```
|
||||
|
||||
### Pattern 2: C Only (No A/P)
|
||||
```markdown
|
||||
Display: "**Select:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
```
|
||||
|
||||
**Use for:** Step 1, document discovery, simple progression
|
||||
|
||||
### Pattern 3: Auto-Proceed (No Menu)
|
||||
```markdown
|
||||
Display: "**Proceeding to [next step]...**"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- After [completion condition], immediately load, read entire file, then execute {nextStepFile}
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- This is an [auto-proceed reason] step with no user choices
|
||||
- Proceed directly to next step after setup
|
||||
```
|
||||
|
||||
**Use for:** Init steps, validation sequences
|
||||
|
||||
### Pattern 4: Branching
|
||||
```markdown
|
||||
Display: "**Select:** [L] Load Existing [N] Create New [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF L: Load existing document, then load, read entire file, then execute {stepForExisting}
|
||||
- IF N: Create new document, then load, read entire file, then execute {stepForNew}
|
||||
- IF C: Save content to {outputFile}, update frontmatter, check {condition}, then load appropriate step
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- Branching options load different steps based on user choice
|
||||
```
|
||||
|
||||
## Critical Rules
|
||||
|
||||
### ❌ DON'T:
|
||||
- Omit handler section after Display
|
||||
- Include A/P in Step 1 (no content to refine)
|
||||
- Forget "redisplay menu" for non-C options
|
||||
- Miss "halt and wait" in EXECUTION RULES
|
||||
|
||||
### ✅ DO:
|
||||
- Handler section immediately follows Display
|
||||
- "Halt and wait" in EXECUTION RULES
|
||||
- Non-C options specify "redisplay menu"
|
||||
- A/P only when appropriate for step type
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For every menu:
|
||||
- [ ] Display section present
|
||||
- [ ] Handler section immediately follows
|
||||
- [ ] EXECUTION RULES section present
|
||||
- [ ] "Halt and wait" instruction included
|
||||
- [ ] A/P options appropriate for step type
|
||||
- [ ] Non-C options redisplay menu
|
||||
- [ ] C option: save → update → load next
|
||||
- [ ] All file references use variables
|
||||
133
_bmad/bmb/workflows/workflow/data/menu-handling-standards.md.bak
Normal file
133
_bmad/bmb/workflows/workflow/data/menu-handling-standards.md.bak
Normal file
@@ -0,0 +1,133 @@
|
||||
# Menu Handling Standards
|
||||
|
||||
**CRITICAL:** Every menu MUST have a handler section. No exceptions.
|
||||
|
||||
## Reserved Letters
|
||||
|
||||
| Letter | Purpose | After Execution |
|
||||
| ------ | -------------------- | ------------------------------ |
|
||||
| **A** | Advanced Elicitation | Redisplay menu |
|
||||
| **P** | Party Mode | Redisplay menu |
|
||||
| **C** | Continue/Accept | Save → update → load next step |
|
||||
| **X** | Exit/Cancel | End workflow |
|
||||
|
||||
**Custom letters** allowed (L/R/F/etc.) but don't conflict with reserved.
|
||||
|
||||
## Required Structure
|
||||
|
||||
### Section 1: Display
|
||||
```markdown
|
||||
### N. Present MENU OPTIONS
|
||||
Display: "**Select:** [A] [action] [P] [action] [C] Continue"
|
||||
```
|
||||
|
||||
### Section 2: Handler (MANDATORY)
|
||||
```markdown
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
```
|
||||
|
||||
### Section 3: Execution Rules
|
||||
```markdown
|
||||
#### 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
|
||||
```
|
||||
|
||||
## When To Include A/P
|
||||
|
||||
**DON'T Include A/P:** Step 1 (init), Step 2 if only loading documents, validation sequences, simple data gathering
|
||||
|
||||
**DO Include A/P:** Collaborative content creation, user might want alternatives, quality gate before proceeding, creative exploration valuable
|
||||
|
||||
## Menu Patterns
|
||||
|
||||
### Pattern 1: Standard A/P/C
|
||||
```markdown
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
```
|
||||
|
||||
### Pattern 2: C Only (No A/P)
|
||||
```markdown
|
||||
Display: "**Select:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
```
|
||||
|
||||
**Use for:** Step 1, document discovery, simple progression
|
||||
|
||||
### Pattern 3: Auto-Proceed (No Menu)
|
||||
```markdown
|
||||
Display: "**Proceeding to [next step]...**"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- After [completion condition], immediately load, read entire file, then execute {nextStepFile}
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- This is an [auto-proceed reason] step with no user choices
|
||||
- Proceed directly to next step after setup
|
||||
```
|
||||
|
||||
**Use for:** Init steps, validation sequences
|
||||
|
||||
### Pattern 4: Branching
|
||||
```markdown
|
||||
Display: "**Select:** [L] Load Existing [N] Create New [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF L: Load existing document, then load, read entire file, then execute {stepForExisting}
|
||||
- IF N: Create new document, then load, read entire file, then execute {stepForNew}
|
||||
- IF C: Save content to {outputFile}, update frontmatter, check {condition}, then load appropriate step
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- Branching options load different steps based on user choice
|
||||
```
|
||||
|
||||
## Critical Rules
|
||||
|
||||
### ❌ DON'T:
|
||||
- Omit handler section after Display
|
||||
- Include A/P in Step 1 (no content to refine)
|
||||
- Forget "redisplay menu" for non-C options
|
||||
- Miss "halt and wait" in EXECUTION RULES
|
||||
|
||||
### ✅ DO:
|
||||
- Handler section immediately follows Display
|
||||
- "Halt and wait" in EXECUTION RULES
|
||||
- Non-C options specify "redisplay menu"
|
||||
- A/P only when appropriate for step type
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For every menu:
|
||||
- [ ] Display section present
|
||||
- [ ] Handler section immediately follows
|
||||
- [ ] EXECUTION RULES section present
|
||||
- [ ] "Halt and wait" instruction included
|
||||
- [ ] A/P options appropriate for step type
|
||||
- [ ] Non-C options redisplay menu
|
||||
- [ ] C option: save → update → load next
|
||||
- [ ] All file references use variables
|
||||
135
_bmad/bmb/workflows/workflow/data/output-format-standards.md
Normal file
135
_bmad/bmb/workflows/workflow/data/output-format-standards.md
Normal file
@@ -0,0 +1,135 @@
|
||||
# Output Format Standards
|
||||
|
||||
## Golden Rule
|
||||
|
||||
**Every step MUST output to a document BEFORE loading the next step.**
|
||||
|
||||
Two patterns:
|
||||
1. **Direct-to-Final:** Steps append to final document
|
||||
2. **Plan-then-Build:** Steps append to plan → build step consumes plan
|
||||
|
||||
## Menu C Option Sequence
|
||||
|
||||
When user selects **C (Continue)**:
|
||||
1. **Append/Write** to document (plan or final)
|
||||
2. **Update frontmatter** (append this step to `stepsCompleted`)
|
||||
3. **THEN** load next step
|
||||
|
||||
```markdown
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
```
|
||||
|
||||
## Output Patterns
|
||||
|
||||
### Pattern 1: Plan-then-Build
|
||||
|
||||
```
|
||||
Step 1 (init) → Creates plan.md from template
|
||||
Step 2 (gather) → Appends requirements to plan.md
|
||||
Step 3 (design) → Appends design decisions to plan.md
|
||||
Step 4 (review) → Appends review/approval to plan.md
|
||||
Step 5 (build) → READS plan.md, CREATES final artifacts
|
||||
```
|
||||
|
||||
**Plan frontmatter:**
|
||||
```yaml
|
||||
workflowName: [name]
|
||||
creationDate: [date]
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather']
|
||||
status: PLANNING_COMPLETE
|
||||
```
|
||||
|
||||
### Pattern 2: Direct-to-Final
|
||||
|
||||
```
|
||||
Step 1 (init) → Creates final-doc.md from minimal template
|
||||
Step 2 (section) → Appends Section 1
|
||||
Step 3 (section) → Appends Section 2
|
||||
Step 4 (section) → Appends Section 3
|
||||
Step 5 (polish) → Optimizes entire document
|
||||
```
|
||||
|
||||
## Four Template Types
|
||||
|
||||
### 1. Free-Form (RECOMMENDED)
|
||||
- Minimal template, progressive append, final polish
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: []
|
||||
lastStep: ''
|
||||
date: ''
|
||||
user_name: ''
|
||||
---
|
||||
|
||||
# {{document_title}}
|
||||
|
||||
[Content appended progressively by workflow steps]
|
||||
```
|
||||
|
||||
### 2. Structured
|
||||
- Single template with placeholders, clear sections
|
||||
|
||||
```markdown
|
||||
# {{title}}
|
||||
|
||||
## {{section_1}}
|
||||
[Content to be filled]
|
||||
|
||||
## {{section_2}}
|
||||
[Content to be filled]
|
||||
```
|
||||
|
||||
### 3. Semi-Structured
|
||||
- Core required sections + optional additions
|
||||
|
||||
### 4. Strict
|
||||
- Multiple templates, exact field definitions
|
||||
- Use for: compliance, legal, regulated
|
||||
|
||||
## Template Syntax
|
||||
|
||||
```markdown
|
||||
{{variable}} # Handlebars style (preferred)
|
||||
[variable] # Bracket style (also supported)
|
||||
```
|
||||
|
||||
Keep templates lean - structure only, not content.
|
||||
|
||||
## Step-to-Output Mapping
|
||||
|
||||
Steps should be in ORDER of document appearance:
|
||||
|
||||
```
|
||||
Step 1: Init (creates doc)
|
||||
Step 2: → ## Section 1
|
||||
Step 3: → ## Section 2
|
||||
Step 4: → ## Section 3
|
||||
Step 5: → ## Section 4
|
||||
Step 6: Polish (optimizes entire doc)
|
||||
```
|
||||
|
||||
**Critical:** Use ## Level 2 headers for main sections - allows document splitting if needed.
|
||||
|
||||
## Final Polish Step
|
||||
|
||||
For free-form workflows, include a polish step that:
|
||||
1. Loads entire document
|
||||
2. Reviews for flow and coherence
|
||||
3. Reduces duplication
|
||||
4. Ensures proper ## Level 2 headers
|
||||
5. Improves transitions
|
||||
6. Keeps general order but optimizes readability
|
||||
|
||||
## Output File Patterns
|
||||
|
||||
```yaml
|
||||
# Single output
|
||||
outputFile: '{output_folder}/document-{project_name}.md'
|
||||
|
||||
# Time-stamped
|
||||
outputFile: '{output_folder}/document-{project_name}-{timestamp}.md'
|
||||
|
||||
# User-specific
|
||||
outputFile: '{output_folder}/document-{user_name}-{project_name}.md'
|
||||
```
|
||||
135
_bmad/bmb/workflows/workflow/data/output-format-standards.md.bak
Normal file
135
_bmad/bmb/workflows/workflow/data/output-format-standards.md.bak
Normal file
@@ -0,0 +1,135 @@
|
||||
# Output Format Standards
|
||||
|
||||
## Golden Rule
|
||||
|
||||
**Every step MUST output to a document BEFORE loading the next step.**
|
||||
|
||||
Two patterns:
|
||||
1. **Direct-to-Final:** Steps append to final document
|
||||
2. **Plan-then-Build:** Steps append to plan → build step consumes plan
|
||||
|
||||
## Menu C Option Sequence
|
||||
|
||||
When user selects **C (Continue)**:
|
||||
1. **Append/Write** to document (plan or final)
|
||||
2. **Update frontmatter** (append this step to `stepsCompleted`)
|
||||
3. **THEN** load next step
|
||||
|
||||
```markdown
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
```
|
||||
|
||||
## Output Patterns
|
||||
|
||||
### Pattern 1: Plan-then-Build
|
||||
|
||||
```
|
||||
Step 1 (init) → Creates plan.md from template
|
||||
Step 2 (gather) → Appends requirements to plan.md
|
||||
Step 3 (design) → Appends design decisions to plan.md
|
||||
Step 4 (review) → Appends review/approval to plan.md
|
||||
Step 5 (build) → READS plan.md, CREATES final artifacts
|
||||
```
|
||||
|
||||
**Plan frontmatter:**
|
||||
```yaml
|
||||
workflowName: [name]
|
||||
creationDate: [date]
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather']
|
||||
status: PLANNING_COMPLETE
|
||||
```
|
||||
|
||||
### Pattern 2: Direct-to-Final
|
||||
|
||||
```
|
||||
Step 1 (init) → Creates final-doc.md from minimal template
|
||||
Step 2 (section) → Appends Section 1
|
||||
Step 3 (section) → Appends Section 2
|
||||
Step 4 (section) → Appends Section 3
|
||||
Step 5 (polish) → Optimizes entire document
|
||||
```
|
||||
|
||||
## Four Template Types
|
||||
|
||||
### 1. Free-Form (RECOMMENDED)
|
||||
- Minimal template, progressive append, final polish
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: []
|
||||
lastStep: ''
|
||||
date: ''
|
||||
user_name: ''
|
||||
---
|
||||
|
||||
# {{document_title}}
|
||||
|
||||
[Content appended progressively by workflow steps]
|
||||
```
|
||||
|
||||
### 2. Structured
|
||||
- Single template with placeholders, clear sections
|
||||
|
||||
```markdown
|
||||
# {{title}}
|
||||
|
||||
## {{section_1}}
|
||||
[Content to be filled]
|
||||
|
||||
## {{section_2}}
|
||||
[Content to be filled]
|
||||
```
|
||||
|
||||
### 3. Semi-Structured
|
||||
- Core required sections + optional additions
|
||||
|
||||
### 4. Strict
|
||||
- Multiple templates, exact field definitions
|
||||
- Use for: compliance, legal, regulated
|
||||
|
||||
## Template Syntax
|
||||
|
||||
```markdown
|
||||
{{variable}} # Handlebars style (preferred)
|
||||
[variable] # Bracket style (also supported)
|
||||
```
|
||||
|
||||
Keep templates lean - structure only, not content.
|
||||
|
||||
## Step-to-Output Mapping
|
||||
|
||||
Steps should be in ORDER of document appearance:
|
||||
|
||||
```
|
||||
Step 1: Init (creates doc)
|
||||
Step 2: → ## Section 1
|
||||
Step 3: → ## Section 2
|
||||
Step 4: → ## Section 3
|
||||
Step 5: → ## Section 4
|
||||
Step 6: Polish (optimizes entire doc)
|
||||
```
|
||||
|
||||
**Critical:** Use ## Level 2 headers for main sections - allows document splitting if needed.
|
||||
|
||||
## Final Polish Step
|
||||
|
||||
For free-form workflows, include a polish step that:
|
||||
1. Loads entire document
|
||||
2. Reviews for flow and coherence
|
||||
3. Reduces duplication
|
||||
4. Ensures proper ## Level 2 headers
|
||||
5. Improves transitions
|
||||
6. Keeps general order but optimizes readability
|
||||
|
||||
## Output File Patterns
|
||||
|
||||
```yaml
|
||||
# Single output
|
||||
outputFile: '{output_folder}/document-{project_name}.md'
|
||||
|
||||
# Time-stamped
|
||||
outputFile: '{output_folder}/document-{project_name}-{timestamp}.md'
|
||||
|
||||
# User-specific
|
||||
outputFile: '{output_folder}/document-{user_name}-{project_name}.md'
|
||||
```
|
||||
235
_bmad/bmb/workflows/workflow/data/step-file-rules.md
Normal file
235
_bmad/bmb/workflows/workflow/data/step-file-rules.md
Normal file
@@ -0,0 +1,235 @@
|
||||
# Step File Rules
|
||||
|
||||
**Purpose:** Quick reference for step structure and compliance. See linked data files for detailed standards.
|
||||
|
||||
---
|
||||
|
||||
## File Size Limits
|
||||
|
||||
| Metric | Value |
|
||||
| ----------- | -------- |
|
||||
| Recommended | < 200 lines |
|
||||
| Absolute Maximum | 250 lines |
|
||||
|
||||
**If exceeded:** Split into multiple steps or extract to `/data/` files.
|
||||
|
||||
---
|
||||
|
||||
## Required Step Structure
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
description: '[what this step does]'
|
||||
|
||||
# File References (ONLY variables used in this step!)
|
||||
[file references in {variable} format
|
||||
---
|
||||
|
||||
# Step [N]: [Name]
|
||||
|
||||
## STEP GOAL:
|
||||
[Single sentence: what this step accomplishes]
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
### Universal Rules:
|
||||
- NEVER generate content without user input
|
||||
- CRITICAL: Read complete step file before taking action
|
||||
- CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- YOU ARE A FACILITATOR, not a content generator
|
||||
|
||||
### Role Reinforcement:
|
||||
- You are a [specific role]
|
||||
- We engage in collaborative dialogue, not command-response
|
||||
- You bring [expertise], user brings [theirs]
|
||||
- Together we produce something better
|
||||
|
||||
### Step-Specific Rules:
|
||||
- Focus only on [specific task]
|
||||
- FORBIDDEN to [prohibited action]
|
||||
- Approach: [how to engage]
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
- [Protocol 1]
|
||||
- [Protocol 2 - save/update]
|
||||
- [Protocol 3 - tracking]
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
- Available context: [what's available]
|
||||
- Focus: [what to focus on]
|
||||
- Limits: [boundaries]
|
||||
- Dependencies: [what this depends on]
|
||||
|
||||
## Sequence of Instructions:
|
||||
### 1. [Action]
|
||||
[Instructions]
|
||||
|
||||
### N. Present MENU OPTIONS
|
||||
[Menu section - see menu-handling-standards.md]
|
||||
|
||||
## SYSTEM SUCCESS/FAILURE METRICS:
|
||||
### SUCCESS:
|
||||
[Success criteria]
|
||||
### SYSTEM FAILURE:
|
||||
[Failure criteria]
|
||||
**Master Rule:** Skipping steps is FORBIDDEN.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Critical Rules (Quick Reference)
|
||||
|
||||
### Frontmatter
|
||||
- Only variables USED in step body
|
||||
- All file references use `{variable}` format
|
||||
- Relative paths within workflow folder
|
||||
- See: `frontmatter-standards.md`
|
||||
|
||||
### Menus
|
||||
- Handler section MUST follow display
|
||||
- "Halt and wait" in execution rules
|
||||
- A/P options only when appropriate
|
||||
- Non-C options redisplay menu
|
||||
- See: `menu-handling-standards.md`
|
||||
|
||||
### Progressive Disclosure
|
||||
- Only load next step when user selects 'C'
|
||||
- Read entire step file before execution
|
||||
- Don't create mental todos from future steps
|
||||
|
||||
### Continuable Workflows
|
||||
- Append step number to `stepsCompleted`
|
||||
- Don't hardcode full array
|
||||
- See: `workflow-type-criteria.md`
|
||||
|
||||
---
|
||||
|
||||
## Data Files Reference
|
||||
|
||||
| File | Purpose |
|
||||
| --- | --- |
|
||||
| `frontmatter-standards.md` | Variables, paths, frontmatter rules |
|
||||
| `menu-handling-standards.md` | Menu patterns, handler requirements |
|
||||
| `output-format-standards.md` | Document output, template types |
|
||||
| `workflow-type-criteria.md` | Continuable, module, tri-modal decisions |
|
||||
| `step-type-patterns.md` | Templates for init/middle/final/branch steps |
|
||||
| `trimodal-workflow-structure.md` | Create/Edit/Validate folder structure |
|
||||
|
||||
---
|
||||
|
||||
## Step Type Reference
|
||||
|
||||
| Step Type | Template/Reference |
|
||||
| --- | --- |
|
||||
| Init (non-continuable) | Auto-proceed, no continuation logic |
|
||||
| Init (continuable) | `step-01-init-continuable-template.md` |
|
||||
| Continuation (01b) | `step-1b-template.md` |
|
||||
| Middle (standard) | A/P/C menu, collaborative content |
|
||||
| Middle (simple) | C only menu, no A/P |
|
||||
| Branch/Conditional | Custom menu options, routing to different steps |
|
||||
| Validation sequence | Auto-proceed through checks |
|
||||
| Final | No next step, completion message |
|
||||
|
||||
See: `step-type-patterns.md`
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Variables
|
||||
|
||||
### Standard (Always Available)
|
||||
- `{project-root}`
|
||||
- `{project_name}`
|
||||
- `{output_folder}`
|
||||
- `{user_name}`
|
||||
- `{communication_language}`
|
||||
- `{document_output_language}`
|
||||
|
||||
### Module-Specific (e.g., BMB)
|
||||
- `{bmb_creations_output_folder}`
|
||||
|
||||
### User-Defined
|
||||
- New variables can be defined in steps for future steps
|
||||
|
||||
See: `frontmatter-standards.md`
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For every step file:
|
||||
|
||||
- [ ] File < 200 lines (250 max)
|
||||
- [ ] `name` and `description` in frontmatter
|
||||
- [ ] All frontmatter variables are used
|
||||
- [ ] File references use `{variable}` format
|
||||
- [ ] Relative paths within workflow folder
|
||||
- [ ] Handler section follows menu display
|
||||
- [ ] "Halt and wait" in execution rules
|
||||
- [ ] A/P options appropriate for step type
|
||||
- [ ] C option saves and loads next step
|
||||
- [ ] Non-C options redisplay menu
|
||||
- [ ] StepsCompleted appended (if continuable)
|
||||
- [ ] Success/failure metrics present
|
||||
|
||||
---
|
||||
|
||||
## Quick Menu Reference
|
||||
|
||||
```markdown
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] [action A] [P] [action P] [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Violations
|
||||
|
||||
| Violation | Fix |
|
||||
| --- | --- |
|
||||
| Unused variable in frontmatter | Remove unused variables |
|
||||
| Hardcoded file path | Use `{variable}` format |
|
||||
| A/P menu in step 1 | Remove A/P (inappropriate for init) |
|
||||
| Missing handler section | Add handler after menu display |
|
||||
| No "halt and wait" instruction | Add to EXECUTION RULES |
|
||||
| Hardcoded `stepsCompleted: [1,2,3]` | Append: "update stepsCompleted to add this step" |
|
||||
| File > 250 lines | Split into multiple steps or extract to /data/ |
|
||||
| Absolute path for same-folder ref | Use relative path or `{workflow_path}` |
|
||||
|
||||
---
|
||||
|
||||
## When to Extract to Data Files
|
||||
|
||||
Extract step content to `/data/` when:
|
||||
- Step file exceeds 200 lines
|
||||
- Content is reference material
|
||||
- Content is reused across steps
|
||||
- Content is domain-specific (examples, patterns)
|
||||
|
||||
**Data file types:**
|
||||
- `.md` - Reference documentation
|
||||
- `.csv` - Structured data for lookup
|
||||
- `examples/` - Reference implementations
|
||||
|
||||
---
|
||||
|
||||
## Tri-Modal Workflow Note
|
||||
|
||||
For Create/Edit/Validate workflows:
|
||||
- Each mode has its own `steps-c/`, `steps-e/`, `steps-v/` folder
|
||||
- NO shared step files (`s-*.md`) between modes
|
||||
- All modes share `/data/` folder
|
||||
- This prevents confusion and routing errors
|
||||
|
||||
See: `trimodal-workflow-structure.md`
|
||||
235
_bmad/bmb/workflows/workflow/data/step-file-rules.md.bak
Normal file
235
_bmad/bmb/workflows/workflow/data/step-file-rules.md.bak
Normal file
@@ -0,0 +1,235 @@
|
||||
# Step File Rules
|
||||
|
||||
**Purpose:** Quick reference for step structure and compliance. See linked data files for detailed standards.
|
||||
|
||||
---
|
||||
|
||||
## File Size Limits
|
||||
|
||||
| Metric | Value |
|
||||
| ----------- | -------- |
|
||||
| Recommended | < 200 lines |
|
||||
| Absolute Maximum | 250 lines |
|
||||
|
||||
**If exceeded:** Split into multiple steps or extract to `/data/` files.
|
||||
|
||||
---
|
||||
|
||||
## Required Step Structure
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
description: '[what this step does]'
|
||||
|
||||
# File References (ONLY variables used in this step!)
|
||||
[file references in {variable} format
|
||||
---
|
||||
|
||||
# Step [N]: [Name]
|
||||
|
||||
## STEP GOAL:
|
||||
[Single sentence: what this step accomplishes]
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
### Universal Rules:
|
||||
- NEVER generate content without user input
|
||||
- CRITICAL: Read complete step file before taking action
|
||||
- CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- YOU ARE A FACILITATOR, not a content generator
|
||||
|
||||
### Role Reinforcement:
|
||||
- You are a [specific role]
|
||||
- We engage in collaborative dialogue, not command-response
|
||||
- You bring [expertise], user brings [theirs]
|
||||
- Together we produce something better
|
||||
|
||||
### Step-Specific Rules:
|
||||
- Focus only on [specific task]
|
||||
- FORBIDDEN to [prohibited action]
|
||||
- Approach: [how to engage]
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
- [Protocol 1]
|
||||
- [Protocol 2 - save/update]
|
||||
- [Protocol 3 - tracking]
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
- Available context: [what's available]
|
||||
- Focus: [what to focus on]
|
||||
- Limits: [boundaries]
|
||||
- Dependencies: [what this depends on]
|
||||
|
||||
## Sequence of Instructions:
|
||||
### 1. [Action]
|
||||
[Instructions]
|
||||
|
||||
### N. Present MENU OPTIONS
|
||||
[Menu section - see menu-handling-standards.md]
|
||||
|
||||
## SYSTEM SUCCESS/FAILURE METRICS:
|
||||
### SUCCESS:
|
||||
[Success criteria]
|
||||
### SYSTEM FAILURE:
|
||||
[Failure criteria]
|
||||
**Master Rule:** Skipping steps is FORBIDDEN.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Critical Rules (Quick Reference)
|
||||
|
||||
### Frontmatter
|
||||
- Only variables USED in step body
|
||||
- All file references use `{variable}` format
|
||||
- Relative paths within workflow folder
|
||||
- See: `frontmatter-standards.md`
|
||||
|
||||
### Menus
|
||||
- Handler section MUST follow display
|
||||
- "Halt and wait" in execution rules
|
||||
- A/P options only when appropriate
|
||||
- Non-C options redisplay menu
|
||||
- See: `menu-handling-standards.md`
|
||||
|
||||
### Progressive Disclosure
|
||||
- Only load next step when user selects 'C'
|
||||
- Read entire step file before execution
|
||||
- Don't create mental todos from future steps
|
||||
|
||||
### Continuable Workflows
|
||||
- Append step number to `stepsCompleted`
|
||||
- Don't hardcode full array
|
||||
- See: `workflow-type-criteria.md`
|
||||
|
||||
---
|
||||
|
||||
## Data Files Reference
|
||||
|
||||
| File | Purpose |
|
||||
| --- | --- |
|
||||
| `frontmatter-standards.md` | Variables, paths, frontmatter rules |
|
||||
| `menu-handling-standards.md` | Menu patterns, handler requirements |
|
||||
| `output-format-standards.md` | Document output, template types |
|
||||
| `workflow-type-criteria.md` | Continuable, module, tri-modal decisions |
|
||||
| `step-type-patterns.md` | Templates for init/middle/final/branch steps |
|
||||
| `trimodal-workflow-structure.md` | Create/Edit/Validate folder structure |
|
||||
|
||||
---
|
||||
|
||||
## Step Type Reference
|
||||
|
||||
| Step Type | Template/Reference |
|
||||
| --- | --- |
|
||||
| Init (non-continuable) | Auto-proceed, no continuation logic |
|
||||
| Init (continuable) | `step-01-init-continuable-template.md` |
|
||||
| Continuation (01b) | `step-1b-template.md` |
|
||||
| Middle (standard) | A/P/C menu, collaborative content |
|
||||
| Middle (simple) | C only menu, no A/P |
|
||||
| Branch/Conditional | Custom menu options, routing to different steps |
|
||||
| Validation sequence | Auto-proceed through checks |
|
||||
| Final | No next step, completion message |
|
||||
|
||||
See: `step-type-patterns.md`
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Variables
|
||||
|
||||
### Standard (Always Available)
|
||||
- `{project-root}`
|
||||
- `{project_name}`
|
||||
- `{output_folder}`
|
||||
- `{user_name}`
|
||||
- `{communication_language}`
|
||||
- `{document_output_language}`
|
||||
|
||||
### Module-Specific (e.g., BMB)
|
||||
- `{bmb_creations_output_folder}`
|
||||
|
||||
### User-Defined
|
||||
- New variables can be defined in steps for future steps
|
||||
|
||||
See: `frontmatter-standards.md`
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For every step file:
|
||||
|
||||
- [ ] File < 200 lines (250 max)
|
||||
- [ ] `name` and `description` in frontmatter
|
||||
- [ ] All frontmatter variables are used
|
||||
- [ ] File references use `{variable}` format
|
||||
- [ ] Relative paths within workflow folder
|
||||
- [ ] Handler section follows menu display
|
||||
- [ ] "Halt and wait" in execution rules
|
||||
- [ ] A/P options appropriate for step type
|
||||
- [ ] C option saves and loads next step
|
||||
- [ ] Non-C options redisplay menu
|
||||
- [ ] StepsCompleted appended (if continuable)
|
||||
- [ ] Success/failure metrics present
|
||||
|
||||
---
|
||||
|
||||
## Quick Menu Reference
|
||||
|
||||
```markdown
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] [action A] [P] [action P] [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Violations
|
||||
|
||||
| Violation | Fix |
|
||||
| --- | --- |
|
||||
| Unused variable in frontmatter | Remove unused variables |
|
||||
| Hardcoded file path | Use `{variable}` format |
|
||||
| A/P menu in step 1 | Remove A/P (inappropriate for init) |
|
||||
| Missing handler section | Add handler after menu display |
|
||||
| No "halt and wait" instruction | Add to EXECUTION RULES |
|
||||
| Hardcoded `stepsCompleted: [1,2,3]` | Append: "update stepsCompleted to add this step" |
|
||||
| File > 250 lines | Split into multiple steps or extract to /data/ |
|
||||
| Absolute path for same-folder ref | Use relative path or `{workflow_path}` |
|
||||
|
||||
---
|
||||
|
||||
## When to Extract to Data Files
|
||||
|
||||
Extract step content to `/data/` when:
|
||||
- Step file exceeds 200 lines
|
||||
- Content is reference material
|
||||
- Content is reused across steps
|
||||
- Content is domain-specific (examples, patterns)
|
||||
|
||||
**Data file types:**
|
||||
- `.md` - Reference documentation
|
||||
- `.csv` - Structured data for lookup
|
||||
- `examples/` - Reference implementations
|
||||
|
||||
---
|
||||
|
||||
## Tri-Modal Workflow Note
|
||||
|
||||
For Create/Edit/Validate workflows:
|
||||
- Each mode has its own `steps-c/`, `steps-e/`, `steps-v/` folder
|
||||
- NO shared step files (`s-*.md`) between modes
|
||||
- All modes share `/data/` folder
|
||||
- This prevents confusion and routing errors
|
||||
|
||||
See: `trimodal-workflow-structure.md`
|
||||
257
_bmad/bmb/workflows/workflow/data/step-type-patterns.md
Normal file
257
_bmad/bmb/workflows/workflow/data/step-type-patterns.md
Normal file
@@ -0,0 +1,257 @@
|
||||
# Step Type Patterns
|
||||
|
||||
## Core Skeleton
|
||||
```markdown
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
description: '[action]'
|
||||
[file refs only if used]
|
||||
---
|
||||
|
||||
# Step [N]: [Name]
|
||||
|
||||
## STEP GOAL:
|
||||
[single sentence]
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
### Universal:
|
||||
- 🛑 NEVER generate without user input
|
||||
- 📖 Read complete step file before action
|
||||
- 🔄 When loading with 'C', read entire file
|
||||
- 📋 Facilitator, not generator
|
||||
|
||||
### Role:
|
||||
- ✅ Role: [specific]
|
||||
- ✅ Collaborative dialogue
|
||||
- ✅ You bring [expertise], user brings [theirs]
|
||||
|
||||
### Step-Specific:
|
||||
- 🎯 Focus: [task]
|
||||
- 🚫 Forbidden: [action]
|
||||
- 💬 Approach: [method]
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
- 🎯 Follow MANDATORY SEQUENCE exactly
|
||||
- 💾 [protocol]
|
||||
- 📖 [protocol]
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
- Available: [context]
|
||||
- Focus: [scope]
|
||||
- Limits: [bounds]
|
||||
- Dependencies: [reqs]
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
**Follow exactly. No skip/reorder without user request.**
|
||||
|
||||
### 1. [action]
|
||||
[instructions]
|
||||
|
||||
### N. MENU OPTIONS
|
||||
[see menu-handling-standards.md]
|
||||
|
||||
## 🚨 SUCCESS/FAILURE:
|
||||
### ✅ SUCCESS: [criteria]
|
||||
### ❌ FAILURE: [criteria]
|
||||
**Master Rule:** Skipping steps FORBIDDEN.
|
||||
```
|
||||
|
||||
## Step Types
|
||||
|
||||
### 1. Init (Non-Continuable)
|
||||
**Use:** Single-session workflow
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize [workflow]'
|
||||
nextStepFile: './step-02-[name].md'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
templateFile: '../templates/[template].md'
|
||||
---
|
||||
```
|
||||
- No continuation detection
|
||||
- Auto-proceeds to step 2
|
||||
- No A/P menu
|
||||
- Creates output from template
|
||||
|
||||
### 2. Init (Continuable)
|
||||
**Use:** Multi-session workflow
|
||||
|
||||
**Frontmatter:** Add `continueFile: './step-01b-continue.md'` <!-- validate-file-refs:ignore -->
|
||||
|
||||
**Logic:**
|
||||
```markdown
|
||||
## 1. Check Existing Workflow
|
||||
- Look for {outputFile}
|
||||
- If exists + has stepsCompleted → load {continueFile}
|
||||
- If not → continue to setup
|
||||
```
|
||||
**Ref:** `step-01-init-continuable-template.md`
|
||||
|
||||
### 3. Continuation (01b)
|
||||
**Use:** Paired with continuable init
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-01b-continue'
|
||||
description: 'Handle workflow continuation'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
---
|
||||
```
|
||||
**Logic:**
|
||||
1. Read `stepsCompleted` from output
|
||||
2. Read last completed step file to find nextStep
|
||||
3. Welcome user back
|
||||
4. Route to appropriate step
|
||||
|
||||
**Ref:** `step-1b-template.md`
|
||||
|
||||
### 4. Middle (Standard)
|
||||
**Use:** Collaborative content generation
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
nextStepFile: './step-[N+1]-[name].md'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
advancedElicitationTask: '{project-root}/.../advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/.../party-mode/workflow.md'
|
||||
---
|
||||
```
|
||||
**Menu:** A/P/C
|
||||
|
||||
### 5. Middle (Simple)
|
||||
**Use:** Data gathering, no refinement
|
||||
|
||||
**Menu:** C only
|
||||
|
||||
### 6. Branch Step
|
||||
**Use:** User choice determines path
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
nextStepFile: './step-[default].md'
|
||||
altStepFile: './step-[alternate].md'
|
||||
```
|
||||
**Menu:** Custom letters (L/R/etc.)
|
||||
|
||||
### 7. Validation Sequence
|
||||
**Use:** Multiple checks without interruption
|
||||
|
||||
**Menu:** Auto-proceed
|
||||
|
||||
**Pattern:**
|
||||
```markdown
|
||||
## 1. Perform validation check
|
||||
[logic]
|
||||
|
||||
## 2. Write results to {outputFile}
|
||||
Append findings
|
||||
|
||||
## 3. Proceed to next validation
|
||||
"**Proceeding to next check...**"
|
||||
→ Load {nextValidationStep}
|
||||
```
|
||||
|
||||
### 8. Init (With Input Discovery)
|
||||
**Use:** Requires documents from prior workflows/external sources
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize and discover input documents'
|
||||
inputDocuments: []
|
||||
requiredInputCount: 1
|
||||
moduleInputFolder: '{module_output_folder}'
|
||||
inputFilePatterns:
|
||||
- '*-prd.md'
|
||||
- '*-ux.md'
|
||||
---
|
||||
```
|
||||
**Logic:**
|
||||
```markdown
|
||||
## 1. Discover Inputs
|
||||
Search {moduleInputFolder} + {project_folder}/docs/ for {inputFilePatterns}
|
||||
|
||||
## 2. Present Findings
|
||||
"Found these documents:
|
||||
[1] prd-my-project.md (3 days ago) ✓
|
||||
[2] ux-research.md (1 week ago)
|
||||
Which would you like to use?"
|
||||
|
||||
## 3. Validate and Load
|
||||
Check workflowType, stepsCompleted, date
|
||||
Load selected docs
|
||||
Add to {inputDocuments}
|
||||
|
||||
## 4. Auto-Proceed
|
||||
If all required inputs → step 2
|
||||
If missing → Error with guidance
|
||||
```
|
||||
**Ref:** `input-discovery-standards.md`
|
||||
|
||||
### 9. Final Polish
|
||||
**Use:** Optimizes document section-by-section
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-[N]-polish'
|
||||
description: 'Optimize and finalize document'
|
||||
outputFile: '{output_folder}/[document].md'
|
||||
---
|
||||
```
|
||||
**Logic:**
|
||||
```markdown
|
||||
## 1. Load Complete Document
|
||||
Read {outputFile}
|
||||
|
||||
## 2. Document Optimization
|
||||
Review for:
|
||||
1. Flow/coherence
|
||||
2. Duplication (remove, preserve essential)
|
||||
3. Proper ## Level 2 headers
|
||||
4. Smooth transitions
|
||||
5. Readability
|
||||
|
||||
## 3. Optimize
|
||||
Maintain:
|
||||
- General order
|
||||
- Essential info
|
||||
- User's voice
|
||||
|
||||
## 4. Final Output
|
||||
Save, mark complete
|
||||
```
|
||||
**Use for:** Free-form output workflows
|
||||
|
||||
### 10. Final Step
|
||||
**Use:** Last step, completion
|
||||
|
||||
**Frontmatter:** No `nextStepFile`
|
||||
|
||||
**Logic:**
|
||||
- Update frontmatter (mark complete)
|
||||
- Final summary
|
||||
- No next step
|
||||
|
||||
## Step Size Limits
|
||||
| Type | Max |
|
||||
| --------------------- | ------ |
|
||||
| Init | 150 |
|
||||
| Init (with discovery) | 200 |
|
||||
| Continuation | 200 |
|
||||
| Middle (simple) | 200 |
|
||||
| Middle (complex) | 250 |
|
||||
| Branch | 200 |
|
||||
| Validation sequence | 150 |
|
||||
| Final polish | 200 |
|
||||
| Final | 200 |
|
||||
|
||||
**If exceeded:** Split steps or extract to `/data/`.
|
||||
257
_bmad/bmb/workflows/workflow/data/step-type-patterns.md.bak
Normal file
257
_bmad/bmb/workflows/workflow/data/step-type-patterns.md.bak
Normal file
@@ -0,0 +1,257 @@
|
||||
# Step Type Patterns
|
||||
|
||||
## Core Skeleton
|
||||
```markdown
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
description: '[action]'
|
||||
[file refs only if used]
|
||||
---
|
||||
|
||||
# Step [N]: [Name]
|
||||
|
||||
## STEP GOAL:
|
||||
[single sentence]
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
### Universal:
|
||||
- 🛑 NEVER generate without user input
|
||||
- 📖 Read complete step file before action
|
||||
- 🔄 When loading with 'C', read entire file
|
||||
- 📋 Facilitator, not generator
|
||||
|
||||
### Role:
|
||||
- ✅ Role: [specific]
|
||||
- ✅ Collaborative dialogue
|
||||
- ✅ You bring [expertise], user brings [theirs]
|
||||
|
||||
### Step-Specific:
|
||||
- 🎯 Focus: [task]
|
||||
- 🚫 Forbidden: [action]
|
||||
- 💬 Approach: [method]
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
- 🎯 Follow MANDATORY SEQUENCE exactly
|
||||
- 💾 [protocol]
|
||||
- 📖 [protocol]
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
- Available: [context]
|
||||
- Focus: [scope]
|
||||
- Limits: [bounds]
|
||||
- Dependencies: [reqs]
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
**Follow exactly. No skip/reorder without user request.**
|
||||
|
||||
### 1. [action]
|
||||
[instructions]
|
||||
|
||||
### N. MENU OPTIONS
|
||||
[see menu-handling-standards.md]
|
||||
|
||||
## 🚨 SUCCESS/FAILURE:
|
||||
### ✅ SUCCESS: [criteria]
|
||||
### ❌ FAILURE: [criteria]
|
||||
**Master Rule:** Skipping steps FORBIDDEN.
|
||||
```
|
||||
|
||||
## Step Types
|
||||
|
||||
### 1. Init (Non-Continuable)
|
||||
**Use:** Single-session workflow
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize [workflow]'
|
||||
nextStepFile: './step-02-[name].md'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
templateFile: '../templates/[template].md'
|
||||
---
|
||||
```
|
||||
- No continuation detection
|
||||
- Auto-proceeds to step 2
|
||||
- No A/P menu
|
||||
- Creates output from template
|
||||
|
||||
### 2. Init (Continuable)
|
||||
**Use:** Multi-session workflow
|
||||
|
||||
**Frontmatter:** Add `continueFile: './step-01b-continue.md'` <!-- validate-file-refs:ignore -->
|
||||
|
||||
**Logic:**
|
||||
```markdown
|
||||
## 1. Check Existing Workflow
|
||||
- Look for {outputFile}
|
||||
- If exists + has stepsCompleted → load {continueFile}
|
||||
- If not → continue to setup
|
||||
```
|
||||
**Ref:** `step-01-init-continuable-template.md`
|
||||
|
||||
### 3. Continuation (01b)
|
||||
**Use:** Paired with continuable init
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-01b-continue'
|
||||
description: 'Handle workflow continuation'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
---
|
||||
```
|
||||
**Logic:**
|
||||
1. Read `stepsCompleted` from output
|
||||
2. Read last completed step file to find nextStep
|
||||
3. Welcome user back
|
||||
4. Route to appropriate step
|
||||
|
||||
**Ref:** `step-1b-template.md`
|
||||
|
||||
### 4. Middle (Standard)
|
||||
**Use:** Collaborative content generation
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
nextStepFile: './step-[N+1]-[name].md'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
advancedElicitationTask: '{project-root}/.../advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/.../party-mode/workflow.md'
|
||||
---
|
||||
```
|
||||
**Menu:** A/P/C
|
||||
|
||||
### 5. Middle (Simple)
|
||||
**Use:** Data gathering, no refinement
|
||||
|
||||
**Menu:** C only
|
||||
|
||||
### 6. Branch Step
|
||||
**Use:** User choice determines path
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
nextStepFile: './step-[default].md'
|
||||
altStepFile: './step-[alternate].md'
|
||||
```
|
||||
**Menu:** Custom letters (L/R/etc.)
|
||||
|
||||
### 7. Validation Sequence
|
||||
**Use:** Multiple checks without interruption
|
||||
|
||||
**Menu:** Auto-proceed
|
||||
|
||||
**Pattern:**
|
||||
```markdown
|
||||
## 1. Perform validation check
|
||||
[logic]
|
||||
|
||||
## 2. Write results to {outputFile}
|
||||
Append findings
|
||||
|
||||
## 3. Proceed to next validation
|
||||
"**Proceeding to next check...**"
|
||||
→ Load {nextValidationStep}
|
||||
```
|
||||
|
||||
### 8. Init (With Input Discovery)
|
||||
**Use:** Requires documents from prior workflows/external sources
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize and discover input documents'
|
||||
inputDocuments: []
|
||||
requiredInputCount: 1
|
||||
moduleInputFolder: '{module_output_folder}'
|
||||
inputFilePatterns:
|
||||
- '*-prd.md'
|
||||
- '*-ux.md'
|
||||
---
|
||||
```
|
||||
**Logic:**
|
||||
```markdown
|
||||
## 1. Discover Inputs
|
||||
Search {moduleInputFolder} + {project_folder}/docs/ for {inputFilePatterns}
|
||||
|
||||
## 2. Present Findings
|
||||
"Found these documents:
|
||||
[1] prd-my-project.md (3 days ago) ✓
|
||||
[2] ux-research.md (1 week ago)
|
||||
Which would you like to use?"
|
||||
|
||||
## 3. Validate and Load
|
||||
Check workflowType, stepsCompleted, date
|
||||
Load selected docs
|
||||
Add to {inputDocuments}
|
||||
|
||||
## 4. Auto-Proceed
|
||||
If all required inputs → step 2
|
||||
If missing → Error with guidance
|
||||
```
|
||||
**Ref:** `input-discovery-standards.md`
|
||||
|
||||
### 9. Final Polish
|
||||
**Use:** Optimizes document section-by-section
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-[N]-polish'
|
||||
description: 'Optimize and finalize document'
|
||||
outputFile: '{output_folder}/[document].md'
|
||||
---
|
||||
```
|
||||
**Logic:**
|
||||
```markdown
|
||||
## 1. Load Complete Document
|
||||
Read {outputFile}
|
||||
|
||||
## 2. Document Optimization
|
||||
Review for:
|
||||
1. Flow/coherence
|
||||
2. Duplication (remove, preserve essential)
|
||||
3. Proper ## Level 2 headers
|
||||
4. Smooth transitions
|
||||
5. Readability
|
||||
|
||||
## 3. Optimize
|
||||
Maintain:
|
||||
- General order
|
||||
- Essential info
|
||||
- User's voice
|
||||
|
||||
## 4. Final Output
|
||||
Save, mark complete
|
||||
```
|
||||
**Use for:** Free-form output workflows
|
||||
|
||||
### 10. Final Step
|
||||
**Use:** Last step, completion
|
||||
|
||||
**Frontmatter:** No `nextStepFile`
|
||||
|
||||
**Logic:**
|
||||
- Update frontmatter (mark complete)
|
||||
- Final summary
|
||||
- No next step
|
||||
|
||||
## Step Size Limits
|
||||
| Type | Max |
|
||||
| --------------------- | ------ |
|
||||
| Init | 150 |
|
||||
| Init (with discovery) | 200 |
|
||||
| Continuation | 200 |
|
||||
| Middle (simple) | 200 |
|
||||
| Middle (complex) | 250 |
|
||||
| Branch | 200 |
|
||||
| Validation sequence | 150 |
|
||||
| Final polish | 200 |
|
||||
| Final | 200 |
|
||||
|
||||
**If exceeded:** Split steps or extract to `/data/`.
|
||||
@@ -0,0 +1,188 @@
|
||||
# Subprocess Optimization Patterns
|
||||
|
||||
**Purpose:** Context-saving and performance patterns for subprocess/subagent usage in BMAD workflows.
|
||||
|
||||
---
|
||||
|
||||
## Golden Rules
|
||||
|
||||
1. **Subprocess when operations benefit from parallelization or context isolation**
|
||||
2. **Return ONLY findings to parent, not full file contents**
|
||||
3. **Always provide graceful fallback** for LLMs without subprocess capability
|
||||
4. **Match pattern to operation type** - grep/regex, deep analysis, or data operations
|
||||
|
||||
---
|
||||
|
||||
## Pattern 1: Single Subprocess for Grep/Regex Across Many Files
|
||||
|
||||
**Use when:** One command across many files, only need matches/failures
|
||||
**Context savings:** Massive (1000:1 ratio)
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
Launch a subprocess that:
|
||||
1. Runs grep/regex across all target files
|
||||
2. Extracts only matching lines or failures
|
||||
3. Returns structured findings to parent
|
||||
```
|
||||
|
||||
**Good:** "Launch subprocess to grep all files for pattern, return only matches"
|
||||
**Bad:** "For EACH file, load the file and search for pattern"
|
||||
|
||||
**Example return:**
|
||||
```json
|
||||
{"violations": [{"file": "step-02.md", "line": 45, "match": "..."}], "summary": {"total_files_checked": 10, "violations_found": 3}}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Pattern 2: Separate Subprocess Per File for Deep Analysis
|
||||
|
||||
**Use when:** Reading prose, logic, quality, or flow of each file
|
||||
**Context savings:** High (10:1 ratio)
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
DO NOT BE LAZY - For EACH file, launch a subprocess that:
|
||||
1. Loads that file
|
||||
2. Reads and analyzes content deeply
|
||||
3. Returns structured analysis findings to parent
|
||||
```
|
||||
|
||||
**Good:** "DO NOT BE LAZY - For EACH step file, launch subprocess to analyze instruction style, return findings"
|
||||
**Bad:** "Load every step file and analyze its instruction style"
|
||||
|
||||
**Use cases:** Instruction style validation, collaborative quality assessment, frontmatter compliance, step type validation
|
||||
|
||||
---
|
||||
|
||||
## Pattern 3: Subprocess for Data File Operations
|
||||
|
||||
**Use when:** Loading reference data, fuzzy/best matching, summarizing large datasets
|
||||
**Context savings:** Massive (100:1 ratio)
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
Launch a subprocess that:
|
||||
1. Loads the data file (reference docs, CSV, knowledge base)
|
||||
2. Performs lookup, matching, or summarization
|
||||
3. Returns ONLY relevant rows or key findings to parent
|
||||
```
|
||||
|
||||
**Good:** "Launch subprocess to load {dataFile}, find applicable rules, return only those"
|
||||
**Bad:** "Load {dataFile} with 500 rules and find applicable ones"
|
||||
|
||||
**Use cases:** Reference rules lookup, CSV fuzzy matching, document summarization, knowledge base search
|
||||
|
||||
---
|
||||
|
||||
## Pattern 4: Parallel Execution Opportunities
|
||||
|
||||
**Use when:** Multiple independent operations could run simultaneously
|
||||
**Performance gain:** Reduced total execution time
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
Launch subprocesses in parallel that:
|
||||
1. Each handles one independent operation
|
||||
2. All run simultaneously
|
||||
3. Parent aggregates results when complete
|
||||
```
|
||||
|
||||
**Example:** Instead of sequential checks, launch 3 subprocesses in parallel (frontmatter, menu, step types), then aggregate.
|
||||
|
||||
---
|
||||
|
||||
## Graceful Fallback Pattern (CRITICAL)
|
||||
|
||||
**Universal Rule:**
|
||||
```markdown
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
|
||||
```
|
||||
|
||||
**Implementation:**
|
||||
```markdown
|
||||
### Step-Specific Rules:
|
||||
- 🎯 Use subprocess optimization when available - [pattern description]
|
||||
- 💬 If subprocess unavailable, perform operations in main thread
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Return Pattern for Subprocesses
|
||||
|
||||
**Subprocesses must either:**
|
||||
|
||||
**Option A: Update report directly** - "Subprocess loads validation report, appends findings, saves"
|
||||
|
||||
**Option B: Return structured findings to parent** - "Subprocess returns JSON findings to parent for aggregation"
|
||||
|
||||
**Good return:** `{"file": "step-02.md", "violations": ["..."], "opportunities": ["..."], "priority": "HIGH"}`
|
||||
**Bad:** "Subprocess loads file and returns full content to parent"
|
||||
|
||||
---
|
||||
|
||||
## When to Use Each Pattern
|
||||
|
||||
| Pattern | Use When | Context Savings |
|
||||
| -------- | -------- | --------------- |
|
||||
| Pattern 1: Grep/regex | Finding patterns across many files | Massive (1000:1) |
|
||||
| Pattern 2: Per-file analysis | Understanding prose, logic, quality | High (10:1) |
|
||||
| Pattern 3: Data operations | Reference data, matching, summarizing | Massive (100:1) |
|
||||
| Pattern 4: Parallel execution | Independent operations | Performance gain |
|
||||
|
||||
---
|
||||
|
||||
## Step File Integration
|
||||
|
||||
### Universal Rule (all steps)
|
||||
```markdown
|
||||
### Universal Rules:
|
||||
- ⚙️ TOOL/SUBPROCESS FALLBACK: If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
|
||||
```
|
||||
|
||||
### Step-Specific Rules
|
||||
```markdown
|
||||
### Step-Specific Rules:
|
||||
- 🎯 [which pattern applies]
|
||||
- 💬 Subprocess must either update report OR return findings to parent
|
||||
- 🚫 DO NOT BE LAZY - [specific guidance for Pattern 2]
|
||||
```
|
||||
|
||||
### Command Directives
|
||||
- Pattern 1: "Launch subprocess that runs [command] across all files, returns [results]"
|
||||
- Pattern 2: "DO NOT BE LAZY - For EACH file, launch subprocess that [analyzes], returns [findings]"
|
||||
- Pattern 3: "Launch subprocess that loads [data file], performs [operation], returns [results]"
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- [ ] Universal fallback rule present
|
||||
- [ ] Step-specific rules mention which pattern applies
|
||||
- [ ] Command sequence uses appropriate subprocess directive
|
||||
- [ ] "DO NOT BE LAZY" language included for Pattern 2
|
||||
- [ ] Return pattern specified (update report OR return to parent)
|
||||
- [ ] Graceful fallback addressed
|
||||
- [ ] Pattern matches operation type (grep/regex, deep analysis, or data ops)
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns to Avoid
|
||||
|
||||
| ❌ Anti-Pattern | ✅ Correct Approach |
|
||||
| --------------- | ------------------- |
|
||||
| "For EACH file, load the file, analyze it" | "Launch subprocess per file that returns analysis" |
|
||||
| "Subprocess loads file and returns content" | "Subprocess returns structured findings only" |
|
||||
| "Use subprocess to [operation]" (no fallback) | Include fallback rule for non-subprocess LLMs |
|
||||
| "Launch subprocess per file to grep" | Use Pattern 1 (single subprocess for grep) |
|
||||
| "Launch subprocess to analyze files" | Specify what subprocess returns |
|
||||
|
||||
---
|
||||
|
||||
## See Also
|
||||
|
||||
- `step-file-rules.md` - When to extract content to data files
|
||||
- `step-08b-subprocess-optimization.md` - Validation step for optimization opportunities
|
||||
- `../steps-v/step-02b-path-violations.md` - Example of Pattern 1
|
||||
- `../steps-v/step-08b-subprocess-optimization.md` - Example of Pattern 2
|
||||
@@ -0,0 +1,188 @@
|
||||
# Subprocess Optimization Patterns
|
||||
|
||||
**Purpose:** Context-saving and performance patterns for subprocess/subagent usage in BMAD workflows.
|
||||
|
||||
---
|
||||
|
||||
## Golden Rules
|
||||
|
||||
1. **Subprocess when operations benefit from parallelization or context isolation**
|
||||
2. **Return ONLY findings to parent, not full file contents**
|
||||
3. **Always provide graceful fallback** for LLMs without subprocess capability
|
||||
4. **Match pattern to operation type** - grep/regex, deep analysis, or data operations
|
||||
|
||||
---
|
||||
|
||||
## Pattern 1: Single Subprocess for Grep/Regex Across Many Files
|
||||
|
||||
**Use when:** One command across many files, only need matches/failures
|
||||
**Context savings:** Massive (1000:1 ratio)
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
Launch a subprocess that:
|
||||
1. Runs grep/regex across all target files
|
||||
2. Extracts only matching lines or failures
|
||||
3. Returns structured findings to parent
|
||||
```
|
||||
|
||||
**Good:** "Launch subprocess to grep all files for pattern, return only matches"
|
||||
**Bad:** "For EACH file, load the file and search for pattern"
|
||||
|
||||
**Example return:**
|
||||
```json
|
||||
{"violations": [{"file": "step-02.md", "line": 45, "match": "..."}], "summary": {"total_files_checked": 10, "violations_found": 3}}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Pattern 2: Separate Subprocess Per File for Deep Analysis
|
||||
|
||||
**Use when:** Reading prose, logic, quality, or flow of each file
|
||||
**Context savings:** High (10:1 ratio)
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
DO NOT BE LAZY - For EACH file, launch a subprocess that:
|
||||
1. Loads that file
|
||||
2. Reads and analyzes content deeply
|
||||
3. Returns structured analysis findings to parent
|
||||
```
|
||||
|
||||
**Good:** "DO NOT BE LAZY - For EACH step file, launch subprocess to analyze instruction style, return findings"
|
||||
**Bad:** "Load every step file and analyze its instruction style"
|
||||
|
||||
**Use cases:** Instruction style validation, collaborative quality assessment, frontmatter compliance, step type validation
|
||||
|
||||
---
|
||||
|
||||
## Pattern 3: Subprocess for Data File Operations
|
||||
|
||||
**Use when:** Loading reference data, fuzzy/best matching, summarizing large datasets
|
||||
**Context savings:** Massive (100:1 ratio)
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
Launch a subprocess that:
|
||||
1. Loads the data file (reference docs, CSV, knowledge base)
|
||||
2. Performs lookup, matching, or summarization
|
||||
3. Returns ONLY relevant rows or key findings to parent
|
||||
```
|
||||
|
||||
**Good:** "Launch subprocess to load {dataFile}, find applicable rules, return only those"
|
||||
**Bad:** "Load {dataFile} with 500 rules and find applicable ones"
|
||||
|
||||
**Use cases:** Reference rules lookup, CSV fuzzy matching, document summarization, knowledge base search
|
||||
|
||||
---
|
||||
|
||||
## Pattern 4: Parallel Execution Opportunities
|
||||
|
||||
**Use when:** Multiple independent operations could run simultaneously
|
||||
**Performance gain:** Reduced total execution time
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
Launch subprocesses in parallel that:
|
||||
1. Each handles one independent operation
|
||||
2. All run simultaneously
|
||||
3. Parent aggregates results when complete
|
||||
```
|
||||
|
||||
**Example:** Instead of sequential checks, launch 3 subprocesses in parallel (frontmatter, menu, step types), then aggregate.
|
||||
|
||||
---
|
||||
|
||||
## Graceful Fallback Pattern (CRITICAL)
|
||||
|
||||
**Universal Rule:**
|
||||
```markdown
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
|
||||
```
|
||||
|
||||
**Implementation:**
|
||||
```markdown
|
||||
### Step-Specific Rules:
|
||||
- 🎯 Use subprocess optimization when available - [pattern description]
|
||||
- 💬 If subprocess unavailable, perform operations in main thread
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Return Pattern for Subprocesses
|
||||
|
||||
**Subprocesses must either:**
|
||||
|
||||
**Option A: Update report directly** - "Subprocess loads validation report, appends findings, saves"
|
||||
|
||||
**Option B: Return structured findings to parent** - "Subprocess returns JSON findings to parent for aggregation"
|
||||
|
||||
**Good return:** `{"file": "step-02.md", "violations": ["..."], "opportunities": ["..."], "priority": "HIGH"}`
|
||||
**Bad:** "Subprocess loads file and returns full content to parent"
|
||||
|
||||
---
|
||||
|
||||
## When to Use Each Pattern
|
||||
|
||||
| Pattern | Use When | Context Savings |
|
||||
| -------- | -------- | --------------- |
|
||||
| Pattern 1: Grep/regex | Finding patterns across many files | Massive (1000:1) |
|
||||
| Pattern 2: Per-file analysis | Understanding prose, logic, quality | High (10:1) |
|
||||
| Pattern 3: Data operations | Reference data, matching, summarizing | Massive (100:1) |
|
||||
| Pattern 4: Parallel execution | Independent operations | Performance gain |
|
||||
|
||||
---
|
||||
|
||||
## Step File Integration
|
||||
|
||||
### Universal Rule (all steps)
|
||||
```markdown
|
||||
### Universal Rules:
|
||||
- ⚙️ TOOL/SUBPROCESS FALLBACK: If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
|
||||
```
|
||||
|
||||
### Step-Specific Rules
|
||||
```markdown
|
||||
### Step-Specific Rules:
|
||||
- 🎯 [which pattern applies]
|
||||
- 💬 Subprocess must either update report OR return findings to parent
|
||||
- 🚫 DO NOT BE LAZY - [specific guidance for Pattern 2]
|
||||
```
|
||||
|
||||
### Command Directives
|
||||
- Pattern 1: "Launch subprocess that runs [command] across all files, returns [results]"
|
||||
- Pattern 2: "DO NOT BE LAZY - For EACH file, launch subprocess that [analyzes], returns [findings]"
|
||||
- Pattern 3: "Launch subprocess that loads [data file], performs [operation], returns [results]"
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- [ ] Universal fallback rule present
|
||||
- [ ] Step-specific rules mention which pattern applies
|
||||
- [ ] Command sequence uses appropriate subprocess directive
|
||||
- [ ] "DO NOT BE LAZY" language included for Pattern 2
|
||||
- [ ] Return pattern specified (update report OR return to parent)
|
||||
- [ ] Graceful fallback addressed
|
||||
- [ ] Pattern matches operation type (grep/regex, deep analysis, or data ops)
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns to Avoid
|
||||
|
||||
| ❌ Anti-Pattern | ✅ Correct Approach |
|
||||
| --------------- | ------------------- |
|
||||
| "For EACH file, load the file, analyze it" | "Launch subprocess per file that returns analysis" |
|
||||
| "Subprocess loads file and returns content" | "Subprocess returns structured findings only" |
|
||||
| "Use subprocess to [operation]" (no fallback) | Include fallback rule for non-subprocess LLMs |
|
||||
| "Launch subprocess per file to grep" | Use Pattern 1 (single subprocess for grep) |
|
||||
| "Launch subprocess to analyze files" | Specify what subprocess returns |
|
||||
|
||||
---
|
||||
|
||||
## See Also
|
||||
|
||||
- `step-file-rules.md` - When to extract content to data files
|
||||
- `step-08b-subprocess-optimization.md` - Validation step for optimization opportunities
|
||||
- `../steps-v/step-02b-path-violations.md` - Example of Pattern 1
|
||||
- `../steps-v/step-08b-subprocess-optimization.md` - Example of Pattern 2
|
||||
164
_bmad/bmb/workflows/workflow/data/trimodal-workflow-structure.md
Normal file
164
_bmad/bmb/workflows/workflow/data/trimodal-workflow-structure.md
Normal file
@@ -0,0 +1,164 @@
|
||||
# Tri-Modal Workflow Structure
|
||||
|
||||
## Golden Rule
|
||||
|
||||
**For complex critical workflows: Implement tri-modal structure (create/validate/edit) with cross-mode integration.**
|
||||
|
||||
**Cross-mode integration patterns:**
|
||||
- Create → Validation (handoff after build)
|
||||
- Edit → Validation (verify changes)
|
||||
- Edit → Create/conversion (for non-compliant input)
|
||||
- Validation → Edit (fix issues found)
|
||||
- All modes run standalone via workflow.md routing
|
||||
|
||||
## Directory Structure
|
||||
|
||||
```
|
||||
workflow-name/
|
||||
├── workflow.md # Entry point with mode routing
|
||||
├── data/ # SHARED standards and reference
|
||||
│ ├── [domain]-standards.md
|
||||
│ └── [domain]-patterns.md
|
||||
├── steps-c/ # Create (self-contained)
|
||||
│ ├── step-00-conversion.md # Entry for non-compliant input
|
||||
│ ├── step-01-init.md
|
||||
│ └── step-N-complete.md
|
||||
├── steps-e/ # Edit (self-contained)
|
||||
│ ├── step-01-assess.md # Checks compliance, routes if needed
|
||||
│ └── step-N-complete.md
|
||||
└── steps-v/ # Validate (self-contained, runs standalone)
|
||||
└── step-01-validate.md
|
||||
```
|
||||
|
||||
## Mode Responsibilities
|
||||
|
||||
### Create Mode (steps-c/)
|
||||
- **Primary:** Build new entities from scratch
|
||||
- **Secondary:** Convert non-compliant input via step-00-conversion
|
||||
|
||||
**Key patterns:**
|
||||
- step-00-conversion: Loads non-compliant input, extracts essence, creates plan with `conversionFrom` metadata
|
||||
- Final step routes to validation (optional but recommended)
|
||||
- Confirmation step checks `conversionFrom` to verify coverage vs new workflow
|
||||
|
||||
### Edit Mode (steps-e/)
|
||||
- **Primary:** Modify existing compliant entities
|
||||
- **Secondary:** Detect non-compliance and route to conversion
|
||||
|
||||
**Key patterns:**
|
||||
- step-01-assess: Checks compliance first
|
||||
- Non-compliant → Offer route to step-00-conversion (not step-01-discovery)
|
||||
- Post-edit → Offer validation (reuse validation workflow)
|
||||
- During edits → Check standards, offer to fix non-compliance
|
||||
|
||||
### Validate Mode (steps-v/)
|
||||
- **Primary:** Standalone validation against standards
|
||||
- **Secondary:** Generates actionable reports
|
||||
|
||||
**Key patterns:**
|
||||
- Runs standalone (invoked via -v flag or direct call)
|
||||
- Auto-proceeds through all checks
|
||||
- Generates report with issue severity
|
||||
- Report consumed by edit mode for fixes
|
||||
|
||||
## workflow.md Routing Pattern
|
||||
|
||||
```yaml
|
||||
## INITIALIZATION SEQUENCE
|
||||
|
||||
### 1. Mode Determination
|
||||
|
||||
**Check invocation:**
|
||||
- "create" / -c → mode = create
|
||||
- "validate" / -v → mode = validate
|
||||
- "edit" / -e → mode = edit
|
||||
|
||||
**If create mode:** Ask "From scratch or convert existing?"
|
||||
- From scratch → steps-c/step-01-init.md
|
||||
- Convert → steps-c/step-00-conversion.md
|
||||
|
||||
**If unclear:** Ask user to select mode
|
||||
|
||||
### 2. Route to First Step
|
||||
|
||||
**IF mode == create:**
|
||||
Route to appropriate create entry (init or conversion)
|
||||
|
||||
**IF mode == validate:**
|
||||
Prompt for path → load steps-v/step-01-validate.md
|
||||
|
||||
**IF mode == edit:**
|
||||
Prompt for path → load steps-e/step-01-assess.md
|
||||
```
|
||||
|
||||
**Critical:** workflow.md is lean. No step listings. Only routing logic.
|
||||
|
||||
## Cross-Mode Integration Points
|
||||
|
||||
### 1. Edit → Create (Non-Compliant Detection)
|
||||
```yaml
|
||||
Check workflow compliance:
|
||||
- Compliant → Continue to edit steps
|
||||
- Non-compliant → Offer conversion
|
||||
- IF user accepts: Load steps-c/step-00-conversion.md with sourceWorkflowPath
|
||||
```
|
||||
|
||||
### 2. Create/Edit → Validation
|
||||
```yaml
|
||||
# In create final step or edit post-edit step
|
||||
Offer: "Run validation?"
|
||||
- IF yes: Load ../steps-v/step-01-validate.md
|
||||
- Validation runs standalone, returns report
|
||||
- Resume create/edit with validation results
|
||||
```
|
||||
|
||||
### 3. Validation → Edit
|
||||
```yaml
|
||||
# User can invoke edit mode with report as input
|
||||
"Fix issues found?"
|
||||
- IF yes: Load steps-e/step-01-assess.md with validationReport path
|
||||
```
|
||||
|
||||
### 4. Conversion Coverage Tracking
|
||||
```yaml
|
||||
# In create step-10-confirmation
|
||||
Check workflowPlan metadata:
|
||||
- IF conversionFrom exists:
|
||||
- Load original workflow
|
||||
- Compare each step/instruction
|
||||
- Report coverage percentage
|
||||
- ELSE (new workflow):
|
||||
- Validate all plan requirements implemented
|
||||
```
|
||||
|
||||
## When to Use Tri-Modal
|
||||
|
||||
**Use Tri-Modal for:**
|
||||
- Complex workflows requiring quality assurance
|
||||
- Workflows that will be maintained over time
|
||||
- Workflows where non-compliant input may be offered
|
||||
- Critical workflows where standards compliance matters
|
||||
|
||||
**Use Create-Only for:**
|
||||
- Simple one-off workflows
|
||||
- Experimental workflows
|
||||
- Workflows unlikely to need editing or validation
|
||||
|
||||
## Frontmatter Standards for Cross-Mode References
|
||||
|
||||
Never inline file paths. Always use frontmatter variables:
|
||||
|
||||
```yaml
|
||||
---
|
||||
# Create mode step calling validation
|
||||
validationWorkflow: '../steps-v/step-01-validate.md'
|
||||
---
|
||||
|
||||
# Edit mode step routing to conversion
|
||||
conversionStep: '../steps-c/step-00-conversion.md'
|
||||
---
|
||||
|
||||
# Create conversion step receiving from edit
|
||||
sourceWorkflowPath: '{targetWorkflowPath}' # Passed from edit
|
||||
---
|
||||
```
|
||||
@@ -0,0 +1,164 @@
|
||||
# Tri-Modal Workflow Structure
|
||||
|
||||
## Golden Rule
|
||||
|
||||
**For complex critical workflows: Implement tri-modal structure (create/validate/edit) with cross-mode integration.**
|
||||
|
||||
**Cross-mode integration patterns:**
|
||||
- Create → Validation (handoff after build)
|
||||
- Edit → Validation (verify changes)
|
||||
- Edit → Create/conversion (for non-compliant input)
|
||||
- Validation → Edit (fix issues found)
|
||||
- All modes run standalone via workflow.md routing
|
||||
|
||||
## Directory Structure
|
||||
|
||||
```
|
||||
workflow-name/
|
||||
├── workflow.md # Entry point with mode routing
|
||||
├── data/ # SHARED standards and reference
|
||||
│ ├── [domain]-standards.md
|
||||
│ └── [domain]-patterns.md
|
||||
├── steps-c/ # Create (self-contained)
|
||||
│ ├── step-00-conversion.md # Entry for non-compliant input
|
||||
│ ├── step-01-init.md
|
||||
│ └── step-N-complete.md
|
||||
├── steps-e/ # Edit (self-contained)
|
||||
│ ├── step-01-assess.md # Checks compliance, routes if needed
|
||||
│ └── step-N-complete.md
|
||||
└── steps-v/ # Validate (self-contained, runs standalone)
|
||||
└── step-01-validate.md
|
||||
```
|
||||
|
||||
## Mode Responsibilities
|
||||
|
||||
### Create Mode (steps-c/)
|
||||
- **Primary:** Build new entities from scratch
|
||||
- **Secondary:** Convert non-compliant input via step-00-conversion
|
||||
|
||||
**Key patterns:**
|
||||
- step-00-conversion: Loads non-compliant input, extracts essence, creates plan with `conversionFrom` metadata
|
||||
- Final step routes to validation (optional but recommended)
|
||||
- Confirmation step checks `conversionFrom` to verify coverage vs new workflow
|
||||
|
||||
### Edit Mode (steps-e/)
|
||||
- **Primary:** Modify existing compliant entities
|
||||
- **Secondary:** Detect non-compliance and route to conversion
|
||||
|
||||
**Key patterns:**
|
||||
- step-01-assess: Checks compliance first
|
||||
- Non-compliant → Offer route to step-00-conversion (not step-01-discovery)
|
||||
- Post-edit → Offer validation (reuse validation workflow)
|
||||
- During edits → Check standards, offer to fix non-compliance
|
||||
|
||||
### Validate Mode (steps-v/)
|
||||
- **Primary:** Standalone validation against standards
|
||||
- **Secondary:** Generates actionable reports
|
||||
|
||||
**Key patterns:**
|
||||
- Runs standalone (invoked via -v flag or direct call)
|
||||
- Auto-proceeds through all checks
|
||||
- Generates report with issue severity
|
||||
- Report consumed by edit mode for fixes
|
||||
|
||||
## workflow.md Routing Pattern
|
||||
|
||||
```yaml
|
||||
## INITIALIZATION SEQUENCE
|
||||
|
||||
### 1. Mode Determination
|
||||
|
||||
**Check invocation:**
|
||||
- "create" / -c → mode = create
|
||||
- "validate" / -v → mode = validate
|
||||
- "edit" / -e → mode = edit
|
||||
|
||||
**If create mode:** Ask "From scratch or convert existing?"
|
||||
- From scratch → steps-c/step-01-init.md
|
||||
- Convert → steps-c/step-00-conversion.md
|
||||
|
||||
**If unclear:** Ask user to select mode
|
||||
|
||||
### 2. Route to First Step
|
||||
|
||||
**IF mode == create:**
|
||||
Route to appropriate create entry (init or conversion)
|
||||
|
||||
**IF mode == validate:**
|
||||
Prompt for path → load steps-v/step-01-validate.md
|
||||
|
||||
**IF mode == edit:**
|
||||
Prompt for path → load steps-e/step-01-assess.md
|
||||
```
|
||||
|
||||
**Critical:** workflow.md is lean. No step listings. Only routing logic.
|
||||
|
||||
## Cross-Mode Integration Points
|
||||
|
||||
### 1. Edit → Create (Non-Compliant Detection)
|
||||
```yaml
|
||||
Check workflow compliance:
|
||||
- Compliant → Continue to edit steps
|
||||
- Non-compliant → Offer conversion
|
||||
- IF user accepts: Load steps-c/step-00-conversion.md with sourceWorkflowPath
|
||||
```
|
||||
|
||||
### 2. Create/Edit → Validation
|
||||
```yaml
|
||||
# In create final step or edit post-edit step
|
||||
Offer: "Run validation?"
|
||||
- IF yes: Load ../steps-v/step-01-validate.md
|
||||
- Validation runs standalone, returns report
|
||||
- Resume create/edit with validation results
|
||||
```
|
||||
|
||||
### 3. Validation → Edit
|
||||
```yaml
|
||||
# User can invoke edit mode with report as input
|
||||
"Fix issues found?"
|
||||
- IF yes: Load steps-e/step-01-assess.md with validationReport path
|
||||
```
|
||||
|
||||
### 4. Conversion Coverage Tracking
|
||||
```yaml
|
||||
# In create step-10-confirmation
|
||||
Check workflowPlan metadata:
|
||||
- IF conversionFrom exists:
|
||||
- Load original workflow
|
||||
- Compare each step/instruction
|
||||
- Report coverage percentage
|
||||
- ELSE (new workflow):
|
||||
- Validate all plan requirements implemented
|
||||
```
|
||||
|
||||
## When to Use Tri-Modal
|
||||
|
||||
**Use Tri-Modal for:**
|
||||
- Complex workflows requiring quality assurance
|
||||
- Workflows that will be maintained over time
|
||||
- Workflows where non-compliant input may be offered
|
||||
- Critical workflows where standards compliance matters
|
||||
|
||||
**Use Create-Only for:**
|
||||
- Simple one-off workflows
|
||||
- Experimental workflows
|
||||
- Workflows unlikely to need editing or validation
|
||||
|
||||
## Frontmatter Standards for Cross-Mode References
|
||||
|
||||
Never inline file paths. Always use frontmatter variables:
|
||||
|
||||
```yaml
|
||||
---
|
||||
# Create mode step calling validation
|
||||
validationWorkflow: '../steps-v/step-01-validate.md'
|
||||
---
|
||||
|
||||
# Edit mode step routing to conversion
|
||||
conversionStep: '../steps-c/step-00-conversion.md'
|
||||
---
|
||||
|
||||
# Create conversion step receiving from edit
|
||||
sourceWorkflowPath: '{targetWorkflowPath}' # Passed from edit
|
||||
---
|
||||
```
|
||||
222
_bmad/bmb/workflows/workflow/data/workflow-chaining-standards.md
Normal file
222
_bmad/bmb/workflows/workflow/data/workflow-chaining-standards.md
Normal file
@@ -0,0 +1,222 @@
|
||||
# Workflow Chaining Standards
|
||||
|
||||
## Module Workflow Pipeline
|
||||
|
||||
**Example:** BMM Module - Idea to Implementation
|
||||
|
||||
```
|
||||
brainstorming → research → brief → PRD → UX → architecture → epics → sprint-planning
|
||||
↓
|
||||
implement-story → review → repeat
|
||||
```
|
||||
|
||||
Each workflow:
|
||||
1. Checks for required inputs from prior workflows
|
||||
2. Validates inputs are complete
|
||||
3. Produces output for next workflow
|
||||
4. Recommends next workflow in sequence
|
||||
|
||||
## Input/Output Contract
|
||||
|
||||
### Output Contract
|
||||
|
||||
**Every workflow should:**
|
||||
1. Create output document with predictable filename
|
||||
2. Include `workflowType` in frontmatter for identification
|
||||
3. Mark `stepsCompleted: [all steps]` when complete
|
||||
4. Store in known location (`{module_output_folder}`)
|
||||
|
||||
**Example frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
workflowType: 'prd'
|
||||
stepsCompleted: ['step-01-init', ..., 'step-11-complete']
|
||||
project_name: 'my-project'
|
||||
date: '2025-01-02'
|
||||
nextWorkflow: 'create-ux'
|
||||
previousWorkflow: 'create-brief'
|
||||
---
|
||||
```
|
||||
|
||||
### Input Contract
|
||||
|
||||
**Every workflow should:**
|
||||
1. Define required inputs in Step 1
|
||||
2. Search in `{module_output_folder}` for prior outputs
|
||||
3. Validate inputs are complete
|
||||
4. Allow user to select from discovered documents
|
||||
|
||||
## Step 1: Input Discovery Pattern
|
||||
|
||||
```markdown
|
||||
## 1. Discover Required Inputs
|
||||
|
||||
### Required Inputs:
|
||||
- {module_output_folder}/prd-{project_name}.md
|
||||
|
||||
### Search:
|
||||
1. Look for prd-{project_name}.md in {module_output_folder}
|
||||
2. If found → validate completeness
|
||||
3. If missing or incomplete → error with guidance
|
||||
|
||||
"Error: This workflow requires a completed PRD.
|
||||
Expected location: {module_output_folder}/prd-{project_name}.md
|
||||
To fix: Run the PRD workflow first, or provide the path to your PRD."
|
||||
```
|
||||
|
||||
## Final Step: Next Workflow Recommendation
|
||||
|
||||
```markdown
|
||||
## Next Steps
|
||||
|
||||
Based on your completed [workflow], recommended next workflows:
|
||||
|
||||
1. **[next-workflow-name]** - [why it's next]
|
||||
2. **[alternative-workflow]** - [when to use this instead]
|
||||
|
||||
Would you like to:
|
||||
- Run [next-workflow-name] now?
|
||||
- Run a different workflow?
|
||||
- Exit for now?
|
||||
```
|
||||
|
||||
**Update output frontmatter:**
|
||||
```yaml
|
||||
nextWorkflow: 'create-ux'
|
||||
nextWorkflowRecommended: true
|
||||
```
|
||||
|
||||
## Cross-Workflow Status Tracking
|
||||
|
||||
**Optional:** Module can maintain `workflow-status.yaml`:
|
||||
|
||||
```yaml
|
||||
---
|
||||
current_workflow: 'create-prd'
|
||||
completed_workflows:
|
||||
- brainstorming
|
||||
- research
|
||||
- brief
|
||||
pending_workflows:
|
||||
- create-ux
|
||||
- create-architecture
|
||||
- create-epics
|
||||
- sprint-planning
|
||||
outputs:
|
||||
brief: '{module_output_folder}/brief-{project_name}.md'
|
||||
prd: '{module_output_folder}/prd-{project_name}.md'
|
||||
---
|
||||
```
|
||||
|
||||
**Workflow checks this file to:**
|
||||
- Validate sequence (don't run UX before PRD)
|
||||
- Find output locations
|
||||
- Track overall progress
|
||||
|
||||
## Branching Workflows
|
||||
|
||||
```markdown
|
||||
## Next Steps
|
||||
|
||||
Based on your project type:
|
||||
|
||||
**For software projects:**
|
||||
- create-architecture - Technical architecture
|
||||
- create-epics - Break down into epics
|
||||
|
||||
**For data projects:**
|
||||
- data-modeling - Database schema design
|
||||
- etl-pipeline - Data pipeline design
|
||||
|
||||
Which workflow would you like to run next?
|
||||
```
|
||||
|
||||
## Required vs Optional Sequences
|
||||
|
||||
### Required Sequence
|
||||
**PRD must come before Architecture:**
|
||||
|
||||
```yaml
|
||||
# In architecture workflow.md
|
||||
## PREREQUISITE:
|
||||
This workflow requires a completed PRD.
|
||||
|
||||
## INITIALIZATION:
|
||||
IF prd-{project_name}.md exists AND is complete:
|
||||
→ Proceed with architecture workflow
|
||||
ELSE:
|
||||
→ Error: "Please complete PRD workflow first"
|
||||
```
|
||||
|
||||
### Optional Sequence
|
||||
**UX research helps Architecture but isn't required:**
|
||||
|
||||
```yaml
|
||||
# In architecture workflow.md
|
||||
## OPTIONAL INPUTS:
|
||||
UX research documents can inform technical decisions.
|
||||
|
||||
IF ux-research-{project_name}.md exists:
|
||||
→ "Found UX research. Include findings in architecture design?"
|
||||
ELSE:
|
||||
→ "No UX research found. Continuing without it."
|
||||
```
|
||||
|
||||
## Filename Conventions for Chaining
|
||||
|
||||
**Standard pattern:** `{workflow-name}-{project-name}.md`
|
||||
|
||||
| Workflow | Output Filename Pattern |
|
||||
|----------| ---------------------- |
|
||||
| brainstorming | `brainstorming-{project_name}.md` |
|
||||
| brief | `brief-{project_name}.md` |
|
||||
| PRD | `prd-{project_name}.md` |
|
||||
| UX | `ux-design-{project_name}.md` |
|
||||
| architecture | `architecture-{project_name}.md` |
|
||||
| epics | `epics-{project_name}.md` |
|
||||
|
||||
## Module-Level Workflow Registry
|
||||
|
||||
**Module can define `workflows.yaml`:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
module: 'bmm'
|
||||
workflows:
|
||||
brainstorming:
|
||||
output: 'brainstorming-{project_name}.md'
|
||||
next: ['research']
|
||||
research:
|
||||
output: 'research-{project_name}.md'
|
||||
next: ['brief']
|
||||
brief:
|
||||
output: 'brief-{project_name}.md'
|
||||
next: ['prd']
|
||||
prd:
|
||||
output: 'prd-{project_name}.md'
|
||||
next: ['create-ux', 'create-architecture']
|
||||
create-ux:
|
||||
output: 'ux-design-{project_name}.md'
|
||||
next: ['create-architecture']
|
||||
create-architecture:
|
||||
output: 'architecture-{project_name}.md'
|
||||
next: ['create-epics']
|
||||
create-epics:
|
||||
output: 'epics-{project_name}.md'
|
||||
next: ['sprint-planning']
|
||||
---
|
||||
```
|
||||
|
||||
## Cross-Module Dependencies
|
||||
|
||||
```yaml
|
||||
# In BMGD narrative workflow
|
||||
## INPUT REQUIREMENTS:
|
||||
|
||||
### Required:
|
||||
- {bmm_output_folder}/prd-{project_name}.md
|
||||
- {bmm_output_folder}/architecture-{project_name}.md
|
||||
|
||||
### From BMGD:
|
||||
- {bmgd_output_folder}/gdd-{project_name}.md (Game Design Document)
|
||||
```
|
||||
@@ -0,0 +1,222 @@
|
||||
# Workflow Chaining Standards
|
||||
|
||||
## Module Workflow Pipeline
|
||||
|
||||
**Example:** BMM Module - Idea to Implementation
|
||||
|
||||
```
|
||||
brainstorming → research → brief → PRD → UX → architecture → epics → sprint-planning
|
||||
↓
|
||||
implement-story → review → repeat
|
||||
```
|
||||
|
||||
Each workflow:
|
||||
1. Checks for required inputs from prior workflows
|
||||
2. Validates inputs are complete
|
||||
3. Produces output for next workflow
|
||||
4. Recommends next workflow in sequence
|
||||
|
||||
## Input/Output Contract
|
||||
|
||||
### Output Contract
|
||||
|
||||
**Every workflow should:**
|
||||
1. Create output document with predictable filename
|
||||
2. Include `workflowType` in frontmatter for identification
|
||||
3. Mark `stepsCompleted: [all steps]` when complete
|
||||
4. Store in known location (`{module_output_folder}`)
|
||||
|
||||
**Example frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
workflowType: 'prd'
|
||||
stepsCompleted: ['step-01-init', ..., 'step-11-complete']
|
||||
project_name: 'my-project'
|
||||
date: '2025-01-02'
|
||||
nextWorkflow: 'create-ux'
|
||||
previousWorkflow: 'create-brief'
|
||||
---
|
||||
```
|
||||
|
||||
### Input Contract
|
||||
|
||||
**Every workflow should:**
|
||||
1. Define required inputs in Step 1
|
||||
2. Search in `{module_output_folder}` for prior outputs
|
||||
3. Validate inputs are complete
|
||||
4. Allow user to select from discovered documents
|
||||
|
||||
## Step 1: Input Discovery Pattern
|
||||
|
||||
```markdown
|
||||
## 1. Discover Required Inputs
|
||||
|
||||
### Required Inputs:
|
||||
- {module_output_folder}/prd-{project_name}.md
|
||||
|
||||
### Search:
|
||||
1. Look for prd-{project_name}.md in {module_output_folder}
|
||||
2. If found → validate completeness
|
||||
3. If missing or incomplete → error with guidance
|
||||
|
||||
"Error: This workflow requires a completed PRD.
|
||||
Expected location: {module_output_folder}/prd-{project_name}.md
|
||||
To fix: Run the PRD workflow first, or provide the path to your PRD."
|
||||
```
|
||||
|
||||
## Final Step: Next Workflow Recommendation
|
||||
|
||||
```markdown
|
||||
## Next Steps
|
||||
|
||||
Based on your completed [workflow], recommended next workflows:
|
||||
|
||||
1. **[next-workflow-name]** - [why it's next]
|
||||
2. **[alternative-workflow]** - [when to use this instead]
|
||||
|
||||
Would you like to:
|
||||
- Run [next-workflow-name] now?
|
||||
- Run a different workflow?
|
||||
- Exit for now?
|
||||
```
|
||||
|
||||
**Update output frontmatter:**
|
||||
```yaml
|
||||
nextWorkflow: 'create-ux'
|
||||
nextWorkflowRecommended: true
|
||||
```
|
||||
|
||||
## Cross-Workflow Status Tracking
|
||||
|
||||
**Optional:** Module can maintain `workflow-status.yaml`:
|
||||
|
||||
```yaml
|
||||
---
|
||||
current_workflow: 'create-prd'
|
||||
completed_workflows:
|
||||
- brainstorming
|
||||
- research
|
||||
- brief
|
||||
pending_workflows:
|
||||
- create-ux
|
||||
- create-architecture
|
||||
- create-epics
|
||||
- sprint-planning
|
||||
outputs:
|
||||
brief: '{module_output_folder}/brief-{project_name}.md'
|
||||
prd: '{module_output_folder}/prd-{project_name}.md'
|
||||
---
|
||||
```
|
||||
|
||||
**Workflow checks this file to:**
|
||||
- Validate sequence (don't run UX before PRD)
|
||||
- Find output locations
|
||||
- Track overall progress
|
||||
|
||||
## Branching Workflows
|
||||
|
||||
```markdown
|
||||
## Next Steps
|
||||
|
||||
Based on your project type:
|
||||
|
||||
**For software projects:**
|
||||
- create-architecture - Technical architecture
|
||||
- create-epics - Break down into epics
|
||||
|
||||
**For data projects:**
|
||||
- data-modeling - Database schema design
|
||||
- etl-pipeline - Data pipeline design
|
||||
|
||||
Which workflow would you like to run next?
|
||||
```
|
||||
|
||||
## Required vs Optional Sequences
|
||||
|
||||
### Required Sequence
|
||||
**PRD must come before Architecture:**
|
||||
|
||||
```yaml
|
||||
# In architecture workflow.md
|
||||
## PREREQUISITE:
|
||||
This workflow requires a completed PRD.
|
||||
|
||||
## INITIALIZATION:
|
||||
IF prd-{project_name}.md exists AND is complete:
|
||||
→ Proceed with architecture workflow
|
||||
ELSE:
|
||||
→ Error: "Please complete PRD workflow first"
|
||||
```
|
||||
|
||||
### Optional Sequence
|
||||
**UX research helps Architecture but isn't required:**
|
||||
|
||||
```yaml
|
||||
# In architecture workflow.md
|
||||
## OPTIONAL INPUTS:
|
||||
UX research documents can inform technical decisions.
|
||||
|
||||
IF ux-research-{project_name}.md exists:
|
||||
→ "Found UX research. Include findings in architecture design?"
|
||||
ELSE:
|
||||
→ "No UX research found. Continuing without it."
|
||||
```
|
||||
|
||||
## Filename Conventions for Chaining
|
||||
|
||||
**Standard pattern:** `{workflow-name}-{project-name}.md`
|
||||
|
||||
| Workflow | Output Filename Pattern |
|
||||
|----------| ---------------------- |
|
||||
| brainstorming | `brainstorming-{project_name}.md` |
|
||||
| brief | `brief-{project_name}.md` |
|
||||
| PRD | `prd-{project_name}.md` |
|
||||
| UX | `ux-design-{project_name}.md` |
|
||||
| architecture | `architecture-{project_name}.md` |
|
||||
| epics | `epics-{project_name}.md` |
|
||||
|
||||
## Module-Level Workflow Registry
|
||||
|
||||
**Module can define `workflows.yaml`:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
module: 'bmm'
|
||||
workflows:
|
||||
brainstorming:
|
||||
output: 'brainstorming-{project_name}.md'
|
||||
next: ['research']
|
||||
research:
|
||||
output: 'research-{project_name}.md'
|
||||
next: ['brief']
|
||||
brief:
|
||||
output: 'brief-{project_name}.md'
|
||||
next: ['prd']
|
||||
prd:
|
||||
output: 'prd-{project_name}.md'
|
||||
next: ['create-ux', 'create-architecture']
|
||||
create-ux:
|
||||
output: 'ux-design-{project_name}.md'
|
||||
next: ['create-architecture']
|
||||
create-architecture:
|
||||
output: 'architecture-{project_name}.md'
|
||||
next: ['create-epics']
|
||||
create-epics:
|
||||
output: 'epics-{project_name}.md'
|
||||
next: ['sprint-planning']
|
||||
---
|
||||
```
|
||||
|
||||
## Cross-Module Dependencies
|
||||
|
||||
```yaml
|
||||
# In BMGD narrative workflow
|
||||
## INPUT REQUIREMENTS:
|
||||
|
||||
### Required:
|
||||
- {bmm_output_folder}/prd-{project_name}.md
|
||||
- {bmm_output_folder}/architecture-{project_name}.md
|
||||
|
||||
### From BMGD:
|
||||
- {bmgd_output_folder}/gdd-{project_name}.md (Game Design Document)
|
||||
```
|
||||
232
_bmad/bmb/workflows/workflow/data/workflow-examples.md
Normal file
232
_bmad/bmb/workflows/workflow/data/workflow-examples.md
Normal file
@@ -0,0 +1,232 @@
|
||||
# Novel Workflow Examples
|
||||
|
||||
**Purpose:** Illustrative examples across diverse domains.
|
||||
|
||||
---
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
**Each arrow (→) = one step file. Each step file contains:**
|
||||
- STEP GOAL
|
||||
- MANDATORY EXECUTION RULES
|
||||
- EXECUTION PROTOCOLS
|
||||
- MANDATORY SEQUENCE (numbered sub-steps)
|
||||
- Menu options
|
||||
- Success/failure metrics
|
||||
|
||||
**Simple workflow:** 3-4 step files. **Complex workflow:** 10+ step files.
|
||||
|
||||
---
|
||||
|
||||
## Example 1: Personalized Meal Plan Generator
|
||||
|
||||
**Domain:** Health & Fitness
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Discovery → Assessment → Strategy → Shopping List → Prep Schedule |
|
||||
| **Step Files** | ~5: step-01-discovery, step-02-assessment, step-03-strategy, step-04-shopping, step-05-prep |
|
||||
| **Output** | Direct-to-final document, each step appends section |
|
||||
| **Intent/Prescriptive** | Intent-based - Facilitates discovery |
|
||||
| **Planning** | No - builds directly |
|
||||
| **Continuable** | Yes - 200+ tokens possible |
|
||||
| **Structure** | Linear, 5 steps |
|
||||
| **Conversation** | Open-ended, progressive questioning (1-2 at a time) |
|
||||
|
||||
---
|
||||
|
||||
## Example 2: Year-End Tax Organizer
|
||||
|
||||
**Domain:** Finance
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Input Discovery → Document Categorization → Missing Document Alert → Final Summary |
|
||||
| **Step Files** | 4: step-01-input-discovery, step-02-categorize, step-03-missing-alerts, step-04-summary |
|
||||
| **Output** | Analysis-only + checklist |
|
||||
| **Intent/Prescriptive** | Highly Prescriptive - Tax compliance, exact categories |
|
||||
| **Planning** | N/A |
|
||||
| **Continuable** | No - single-session |
|
||||
| **Structure** | Linear, 4 steps |
|
||||
| **Conversation** | Focused - specific questions, document what provided |
|
||||
|
||||
---
|
||||
|
||||
## Example 3: Employee Termination Checklist
|
||||
|
||||
**Domain:** Legal / HR / Compliance
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Context → Regulatory Check → Document Requirements → Notification Timeline → Final Checklist |
|
||||
| **Step Files** | 5: step-01-context, step-02-regulatory, step-03-documents, step-04-timeline, step-05-checklist |
|
||||
| **Output** | Direct-to-final compliance checklist |
|
||||
| **Intent/Prescriptive** | Highly Prescriptive - Legal compliance, state-specific |
|
||||
| **Planning** | No |
|
||||
| **Continuable** | No - single-session |
|
||||
| **Structure** | Branching within steps by: reason, location, employee count |
|
||||
| **Conversation** | Focused - classification questions, present requirements |
|
||||
|
||||
---
|
||||
|
||||
## Example 4: Tabletop RPG Campaign Builder
|
||||
|
||||
**Domain:** Entertainment / Games
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Session Concept → NPC Creation → Scene Setup → Key Beats → Generate → [Repeat per session] |
|
||||
| **Step Files** | 4 core files reused each session: step-01-concept, step-02-npc, step-03-scene, step-04-beats, step-05-generate |
|
||||
| **Output** | Per-session document, maintains campaign continuity |
|
||||
| **Intent/Prescriptive** | Intent-based - Creative facilitation |
|
||||
| **Planning** | No - builds directly |
|
||||
| **Continuable** | Yes - months-long campaigns |
|
||||
| **Structure** | Repeating loop - same steps, new content |
|
||||
| **Conversation** | Open-ended creative facilitation, "What if..." prompts |
|
||||
|
||||
---
|
||||
|
||||
## Example 5: Course Syllabus Creator
|
||||
|
||||
**Domain:** Education
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Course Type → Learning Objectives → Module Breakdown → Assessment → [Branch: academic] → Accreditation → [Branch: vocational] → Certification → Final |
|
||||
| **Output** | Direct-to-final syllabus |
|
||||
| **Intent/Prescriptive** | Balanced - Framework prescriptive, content flexible |
|
||||
| **Planning** | No |
|
||||
| **Continuable** | Yes - complex syllabi |
|
||||
| **Structure** | Branching by course type |
|
||||
| **Conversation** | Mixed - framework (prescriptive) + content discovery (intent) |
|
||||
|
||||
---
|
||||
|
||||
## Example 6: SOP Writer
|
||||
|
||||
**Domain:** Business Process
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Process Selection → Scope Definition → Documentation → Review → [Generate] → "Create another?" → If yes, repeat |
|
||||
| **Output** | Independent SOPs stored in `{sop_folder}/` |
|
||||
| **Intent/Prescriptive** | Prescriptive - SOPs must be exact |
|
||||
| **Planning** | No - direct generation |
|
||||
| **Continuable** | No - single SOP per run, repeatable workflow |
|
||||
| **Structure** | Repeating - multiple SOPs per session |
|
||||
| **Conversation** | Focused on process details - "Walk me through step 1" |
|
||||
|
||||
---
|
||||
|
||||
## Example 7: Novel Outliner
|
||||
|
||||
**Domain:** Creative Writing
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Structure Selection → Character Arcs → Beat Breakdown → Pacing Review → Final Polish |
|
||||
| **Output** | Free-form with Final Polish for coherence |
|
||||
| **Intent/Prescriptive** | Intent-based - "What does your character want?" |
|
||||
| **Planning** | No - builds directly |
|
||||
| **Continuable** | Yes - weeks-long sessions |
|
||||
| **Structure** | Branching by structure choice |
|
||||
| **Conversation** | Open-ended creative coaching, provocations |
|
||||
|
||||
---
|
||||
|
||||
## Example 8: Wedding Itinerary Coordinator
|
||||
|
||||
**Domain:** Event Planning
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Venue Type → Vendor Coordination → Timeline → Guest Experience → [Branch: hybrid] → Virtual Setup → Day-of Schedule |
|
||||
| **Output** | Direct-to-final itinerary |
|
||||
| **Intent/Prescriptive** | Intent-based - Facilitates vision |
|
||||
| **Planning** | No |
|
||||
| **Continuable** | Yes - months-long planning |
|
||||
| **Structure** | Branching by venue type |
|
||||
| **Conversation** | Open-ended discovery of preferences, budget, constraints |
|
||||
|
||||
---
|
||||
|
||||
## Example 9: Annual Life Review
|
||||
|
||||
**Domain:** Personal Development
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Input Discovery (prior goals) → Life Areas Assessment → Reflections → Goal Setting → Action Planning → Final Polish |
|
||||
| **Output** | Free-form with Final Polish, discovers prior review first |
|
||||
| **Intent/Prescriptive** | Intent-based - Coaching questions |
|
||||
| **Planning** | No - direct to life plan |
|
||||
| **Continuable** | Yes - deep reflection |
|
||||
| **Structure** | Linear with Input Discovery |
|
||||
| **Conversation** | Open-ended coaching, progressive questioning |
|
||||
|
||||
---
|
||||
|
||||
## Example 10: Room Renovation Planner
|
||||
|
||||
**Domain:** Home Improvement
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Room Type → Budget Assessment → Phase Planning → Materials → Contractor Timeline → [Branch: DIY] → Instructions |
|
||||
| **Output** | Direct-to-final renovation plan |
|
||||
| **Intent/Prescriptive** | Balanced - Code compliance prescriptive, design intent-based |
|
||||
| **Planning** | No |
|
||||
| **Continuable** | Yes - complex planning |
|
||||
| **Structure** | Branching by room type and DIY vs pro |
|
||||
| **Conversation** | Mixed - budget questions + vision discovery |
|
||||
|
||||
---
|
||||
|
||||
## Pattern Analysis
|
||||
|
||||
### Structure Types
|
||||
|
||||
| Type | Count | Examples |
|
||||
|------|-------|----------|
|
||||
| Linear | 5 | Meal Plan, Tax, Termination, Life Review, Renovation |
|
||||
| Branching | 5 | Termination, Syllabus, Novel, Wedding, Renovation |
|
||||
| Repeating Loop | 2 | RPG Campaign, SOP Writer |
|
||||
|
||||
### Intent Spectrum
|
||||
|
||||
| Type | Count | Examples |
|
||||
|------|-------|----------|
|
||||
| Intent-based | 7 | Meal Plan, RPG, Syllabus (partial), Novel, Wedding, Life Review, Renovation (partial) |
|
||||
| Prescriptive | 3 | Tax, Termination, SOP |
|
||||
| Balanced | 2 | Syllabus, Renovation |
|
||||
|
||||
### Continuable vs Single-Session
|
||||
|
||||
| Type | Count | Examples |
|
||||
|------|-------|----------|
|
||||
| Continuable | 7 | Meal Plan, RPG, Syllabus, Novel, Wedding, Life Review, Renovation |
|
||||
| Single-Session | 3 | Tax, Termination, SOP |
|
||||
|
||||
### Output Patterns
|
||||
|
||||
| Type | Count | Examples |
|
||||
|------|-------|----------|
|
||||
| Direct-to-Final | 9 | All except Tax |
|
||||
| Analysis Only | 1 | Tax |
|
||||
| With Final Polish | 2 | Novel, Life Review |
|
||||
| Repeating Output | 2 | RPG (sessions), SOP (multiple) |
|
||||
|
||||
---
|
||||
|
||||
## Design Questions
|
||||
|
||||
1. **Domain:** Problem space?
|
||||
2. **Output:** What is produced? (Document, checklist, analysis, physical?)
|
||||
3. **Intent:** Prescriptive (compliance) or intent-based (creative)?
|
||||
4. **Planning:** Plan-then-build or direct-to-final?
|
||||
5. **Continuable:** Multiple sessions or high token count?
|
||||
6. **Structure:** Linear, branching, or repeating loop?
|
||||
7. **Inputs:** Requires prior workflow documents or external sources?
|
||||
8. **Chaining:** Part of module sequence? What comes before/after?
|
||||
9. **Polish:** Final output need optimization for flow/coherence?
|
||||
10. **Conversation:** Focused questions or open-ended facilitation?
|
||||
232
_bmad/bmb/workflows/workflow/data/workflow-examples.md.bak
Normal file
232
_bmad/bmb/workflows/workflow/data/workflow-examples.md.bak
Normal file
@@ -0,0 +1,232 @@
|
||||
# Novel Workflow Examples
|
||||
|
||||
**Purpose:** Illustrative examples across diverse domains.
|
||||
|
||||
---
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
**Each arrow (→) = one step file. Each step file contains:**
|
||||
- STEP GOAL
|
||||
- MANDATORY EXECUTION RULES
|
||||
- EXECUTION PROTOCOLS
|
||||
- MANDATORY SEQUENCE (numbered sub-steps)
|
||||
- Menu options
|
||||
- Success/failure metrics
|
||||
|
||||
**Simple workflow:** 3-4 step files. **Complex workflow:** 10+ step files.
|
||||
|
||||
---
|
||||
|
||||
## Example 1: Personalized Meal Plan Generator
|
||||
|
||||
**Domain:** Health & Fitness
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Discovery → Assessment → Strategy → Shopping List → Prep Schedule |
|
||||
| **Step Files** | ~5: step-01-discovery, step-02-assessment, step-03-strategy, step-04-shopping, step-05-prep |
|
||||
| **Output** | Direct-to-final document, each step appends section |
|
||||
| **Intent/Prescriptive** | Intent-based - Facilitates discovery |
|
||||
| **Planning** | No - builds directly |
|
||||
| **Continuable** | Yes - 200+ tokens possible |
|
||||
| **Structure** | Linear, 5 steps |
|
||||
| **Conversation** | Open-ended, progressive questioning (1-2 at a time) |
|
||||
|
||||
---
|
||||
|
||||
## Example 2: Year-End Tax Organizer
|
||||
|
||||
**Domain:** Finance
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Input Discovery → Document Categorization → Missing Document Alert → Final Summary |
|
||||
| **Step Files** | 4: step-01-input-discovery, step-02-categorize, step-03-missing-alerts, step-04-summary |
|
||||
| **Output** | Analysis-only + checklist |
|
||||
| **Intent/Prescriptive** | Highly Prescriptive - Tax compliance, exact categories |
|
||||
| **Planning** | N/A |
|
||||
| **Continuable** | No - single-session |
|
||||
| **Structure** | Linear, 4 steps |
|
||||
| **Conversation** | Focused - specific questions, document what provided |
|
||||
|
||||
---
|
||||
|
||||
## Example 3: Employee Termination Checklist
|
||||
|
||||
**Domain:** Legal / HR / Compliance
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Context → Regulatory Check → Document Requirements → Notification Timeline → Final Checklist |
|
||||
| **Step Files** | 5: step-01-context, step-02-regulatory, step-03-documents, step-04-timeline, step-05-checklist |
|
||||
| **Output** | Direct-to-final compliance checklist |
|
||||
| **Intent/Prescriptive** | Highly Prescriptive - Legal compliance, state-specific |
|
||||
| **Planning** | No |
|
||||
| **Continuable** | No - single-session |
|
||||
| **Structure** | Branching within steps by: reason, location, employee count |
|
||||
| **Conversation** | Focused - classification questions, present requirements |
|
||||
|
||||
---
|
||||
|
||||
## Example 4: Tabletop RPG Campaign Builder
|
||||
|
||||
**Domain:** Entertainment / Games
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Session Concept → NPC Creation → Scene Setup → Key Beats → Generate → [Repeat per session] |
|
||||
| **Step Files** | 4 core files reused each session: step-01-concept, step-02-npc, step-03-scene, step-04-beats, step-05-generate |
|
||||
| **Output** | Per-session document, maintains campaign continuity |
|
||||
| **Intent/Prescriptive** | Intent-based - Creative facilitation |
|
||||
| **Planning** | No - builds directly |
|
||||
| **Continuable** | Yes - months-long campaigns |
|
||||
| **Structure** | Repeating loop - same steps, new content |
|
||||
| **Conversation** | Open-ended creative facilitation, "What if..." prompts |
|
||||
|
||||
---
|
||||
|
||||
## Example 5: Course Syllabus Creator
|
||||
|
||||
**Domain:** Education
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Course Type → Learning Objectives → Module Breakdown → Assessment → [Branch: academic] → Accreditation → [Branch: vocational] → Certification → Final |
|
||||
| **Output** | Direct-to-final syllabus |
|
||||
| **Intent/Prescriptive** | Balanced - Framework prescriptive, content flexible |
|
||||
| **Planning** | No |
|
||||
| **Continuable** | Yes - complex syllabi |
|
||||
| **Structure** | Branching by course type |
|
||||
| **Conversation** | Mixed - framework (prescriptive) + content discovery (intent) |
|
||||
|
||||
---
|
||||
|
||||
## Example 6: SOP Writer
|
||||
|
||||
**Domain:** Business Process
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Process Selection → Scope Definition → Documentation → Review → [Generate] → "Create another?" → If yes, repeat |
|
||||
| **Output** | Independent SOPs stored in `{sop_folder}/` |
|
||||
| **Intent/Prescriptive** | Prescriptive - SOPs must be exact |
|
||||
| **Planning** | No - direct generation |
|
||||
| **Continuable** | No - single SOP per run, repeatable workflow |
|
||||
| **Structure** | Repeating - multiple SOPs per session |
|
||||
| **Conversation** | Focused on process details - "Walk me through step 1" |
|
||||
|
||||
---
|
||||
|
||||
## Example 7: Novel Outliner
|
||||
|
||||
**Domain:** Creative Writing
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Structure Selection → Character Arcs → Beat Breakdown → Pacing Review → Final Polish |
|
||||
| **Output** | Free-form with Final Polish for coherence |
|
||||
| **Intent/Prescriptive** | Intent-based - "What does your character want?" |
|
||||
| **Planning** | No - builds directly |
|
||||
| **Continuable** | Yes - weeks-long sessions |
|
||||
| **Structure** | Branching by structure choice |
|
||||
| **Conversation** | Open-ended creative coaching, provocations |
|
||||
|
||||
---
|
||||
|
||||
## Example 8: Wedding Itinerary Coordinator
|
||||
|
||||
**Domain:** Event Planning
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Venue Type → Vendor Coordination → Timeline → Guest Experience → [Branch: hybrid] → Virtual Setup → Day-of Schedule |
|
||||
| **Output** | Direct-to-final itinerary |
|
||||
| **Intent/Prescriptive** | Intent-based - Facilitates vision |
|
||||
| **Planning** | No |
|
||||
| **Continuable** | Yes - months-long planning |
|
||||
| **Structure** | Branching by venue type |
|
||||
| **Conversation** | Open-ended discovery of preferences, budget, constraints |
|
||||
|
||||
---
|
||||
|
||||
## Example 9: Annual Life Review
|
||||
|
||||
**Domain:** Personal Development
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Input Discovery (prior goals) → Life Areas Assessment → Reflections → Goal Setting → Action Planning → Final Polish |
|
||||
| **Output** | Free-form with Final Polish, discovers prior review first |
|
||||
| **Intent/Prescriptive** | Intent-based - Coaching questions |
|
||||
| **Planning** | No - direct to life plan |
|
||||
| **Continuable** | Yes - deep reflection |
|
||||
| **Structure** | Linear with Input Discovery |
|
||||
| **Conversation** | Open-ended coaching, progressive questioning |
|
||||
|
||||
---
|
||||
|
||||
## Example 10: Room Renovation Planner
|
||||
|
||||
**Domain:** Home Improvement
|
||||
|
||||
| Aspect | Details |
|
||||
|--------|---------|
|
||||
| **Flow** | Room Type → Budget Assessment → Phase Planning → Materials → Contractor Timeline → [Branch: DIY] → Instructions |
|
||||
| **Output** | Direct-to-final renovation plan |
|
||||
| **Intent/Prescriptive** | Balanced - Code compliance prescriptive, design intent-based |
|
||||
| **Planning** | No |
|
||||
| **Continuable** | Yes - complex planning |
|
||||
| **Structure** | Branching by room type and DIY vs pro |
|
||||
| **Conversation** | Mixed - budget questions + vision discovery |
|
||||
|
||||
---
|
||||
|
||||
## Pattern Analysis
|
||||
|
||||
### Structure Types
|
||||
|
||||
| Type | Count | Examples |
|
||||
|------|-------|----------|
|
||||
| Linear | 5 | Meal Plan, Tax, Termination, Life Review, Renovation |
|
||||
| Branching | 5 | Termination, Syllabus, Novel, Wedding, Renovation |
|
||||
| Repeating Loop | 2 | RPG Campaign, SOP Writer |
|
||||
|
||||
### Intent Spectrum
|
||||
|
||||
| Type | Count | Examples |
|
||||
|------|-------|----------|
|
||||
| Intent-based | 7 | Meal Plan, RPG, Syllabus (partial), Novel, Wedding, Life Review, Renovation (partial) |
|
||||
| Prescriptive | 3 | Tax, Termination, SOP |
|
||||
| Balanced | 2 | Syllabus, Renovation |
|
||||
|
||||
### Continuable vs Single-Session
|
||||
|
||||
| Type | Count | Examples |
|
||||
|------|-------|----------|
|
||||
| Continuable | 7 | Meal Plan, RPG, Syllabus, Novel, Wedding, Life Review, Renovation |
|
||||
| Single-Session | 3 | Tax, Termination, SOP |
|
||||
|
||||
### Output Patterns
|
||||
|
||||
| Type | Count | Examples |
|
||||
|------|-------|----------|
|
||||
| Direct-to-Final | 9 | All except Tax |
|
||||
| Analysis Only | 1 | Tax |
|
||||
| With Final Polish | 2 | Novel, Life Review |
|
||||
| Repeating Output | 2 | RPG (sessions), SOP (multiple) |
|
||||
|
||||
---
|
||||
|
||||
## Design Questions
|
||||
|
||||
1. **Domain:** Problem space?
|
||||
2. **Output:** What is produced? (Document, checklist, analysis, physical?)
|
||||
3. **Intent:** Prescriptive (compliance) or intent-based (creative)?
|
||||
4. **Planning:** Plan-then-build or direct-to-final?
|
||||
5. **Continuable:** Multiple sessions or high token count?
|
||||
6. **Structure:** Linear, branching, or repeating loop?
|
||||
7. **Inputs:** Requires prior workflow documents or external sources?
|
||||
8. **Chaining:** Part of module sequence? What comes before/after?
|
||||
9. **Polish:** Final output need optimization for flow/coherence?
|
||||
10. **Conversation:** Focused questions or open-ended facilitation?
|
||||
134
_bmad/bmb/workflows/workflow/data/workflow-type-criteria.md
Normal file
134
_bmad/bmb/workflows/workflow/data/workflow-type-criteria.md
Normal file
@@ -0,0 +1,134 @@
|
||||
# Workflow Type Criteria
|
||||
|
||||
## Key Decisions
|
||||
|
||||
1. **Module affiliation** - Standalone or part of a module?
|
||||
2. **Continuable** - Can it span multiple sessions?
|
||||
3. **Edit/Validate support** - Will it have edit and validate flows?
|
||||
4. **Document output** - Does it produce a document?
|
||||
|
||||
## 1. Module Affiliation
|
||||
|
||||
### Standalone Workflow
|
||||
- NOT part of any module
|
||||
- Stored in user's custom location
|
||||
- Only standard variables available
|
||||
|
||||
### Module-Based Workflow
|
||||
- Part of a specific module (e.g., BMB)
|
||||
- Has access to module-specific variables
|
||||
- Stored in module's workflows directory
|
||||
|
||||
**BMB additional variable:** `{bmb_creations_output_folder}`
|
||||
|
||||
## 2. Continuable or Single-Session?
|
||||
|
||||
### Continuable (Multi-Session)
|
||||
**Use when:** Workflow might consume MASSIVE tokens, complex, many steps
|
||||
|
||||
**Required:**
|
||||
- `step-01-init.md` with continuation detection
|
||||
- `step-01b-continue.md` for resuming
|
||||
- `stepsCompleted` tracking in output frontmatter
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather']
|
||||
lastStep: 'step-02-gather'
|
||||
lastContinued: '2025-01-02'
|
||||
```
|
||||
|
||||
**Rule:** Each step appends its NAME to `stepsCompleted`
|
||||
|
||||
### Single-Session
|
||||
**Use when:** Simple, quick (<15 min), token-efficient
|
||||
|
||||
**Required:**
|
||||
- Standard `step-01-init.md` (no continuation logic)
|
||||
- No `stepsCompleted` tracking needed
|
||||
|
||||
## 3. Edit/Validate Support
|
||||
|
||||
### Create-Only
|
||||
```
|
||||
workflow-folder/
|
||||
├── workflow.md
|
||||
├── data/
|
||||
└── steps-c/
|
||||
├── step-01-init.md
|
||||
└── step-N-final.md
|
||||
```
|
||||
|
||||
**Use when:** Simple workflows, experimental, one-off
|
||||
|
||||
### Create + Edit + Validate (Tri-Modal)
|
||||
```
|
||||
workflow-folder/
|
||||
├── workflow.md
|
||||
├── data/ # SHARED
|
||||
├── steps-c/ # Create
|
||||
├── steps-e/ # Edit
|
||||
└── steps-v/ # Validate
|
||||
```
|
||||
|
||||
**Key:**
|
||||
- Each mode is SELF-CONTAINED
|
||||
- NO shared step files between modes
|
||||
- DATA folder is SHARED (prevents drift)
|
||||
- Duplicative steps OK (better than confusion)
|
||||
|
||||
**Use when:** Complex workflows that will be maintained
|
||||
|
||||
## 4. Document Output
|
||||
|
||||
### Document-Producing
|
||||
- Creates persistent output file
|
||||
- Uses templates for structure
|
||||
- Each step contributes to document
|
||||
- Consider final polish step
|
||||
|
||||
### Non-Document
|
||||
- Performs actions without persistent output
|
||||
- May produce temporary files
|
||||
- Focus on execution, not creation
|
||||
|
||||
## Decision Tree
|
||||
|
||||
```
|
||||
START: Creating a workflow
|
||||
│
|
||||
├─ Part of a module?
|
||||
│ ├─ YES → Module-based (include module variables)
|
||||
│ └─ NO → Standalone (standard variables only)
|
||||
│
|
||||
├─ Could this take multiple sessions / lots of tokens?
|
||||
│ ├─ YES → Continuable (add step-01b-continue.md)
|
||||
│ └─ NO → Single-session (simpler init)
|
||||
│
|
||||
└─ Will users need to edit/validate this workflow?
|
||||
├─ YES → Tri-modal (steps-c/, steps-e/, steps-v/)
|
||||
└─ NO → Create-only (steps-c/ only)
|
||||
```
|
||||
|
||||
## Output Format Decision
|
||||
|
||||
| Workflow Type | Init Template | Output Format |
|
||||
| ----------------------- | ------------------------ | ------------- |
|
||||
| Continuable + Document | step-01-init-continuable | Free-form |
|
||||
| Single-Session + Document| Standard init | Free-form |
|
||||
| Continuable + No Doc | step-01-init-continuable | N/A |
|
||||
| Single-Session + No Doc | Standard init | N/A |
|
||||
|
||||
**Free-form template** (recommended):
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: []
|
||||
lastStep: ''
|
||||
date: ''
|
||||
user_name: ''
|
||||
---
|
||||
|
||||
# {{document_title}}
|
||||
|
||||
[Content appended progressively]
|
||||
```
|
||||
134
_bmad/bmb/workflows/workflow/data/workflow-type-criteria.md.bak
Normal file
134
_bmad/bmb/workflows/workflow/data/workflow-type-criteria.md.bak
Normal file
@@ -0,0 +1,134 @@
|
||||
# Workflow Type Criteria
|
||||
|
||||
## Key Decisions
|
||||
|
||||
1. **Module affiliation** - Standalone or part of a module?
|
||||
2. **Continuable** - Can it span multiple sessions?
|
||||
3. **Edit/Validate support** - Will it have edit and validate flows?
|
||||
4. **Document output** - Does it produce a document?
|
||||
|
||||
## 1. Module Affiliation
|
||||
|
||||
### Standalone Workflow
|
||||
- NOT part of any module
|
||||
- Stored in user's custom location
|
||||
- Only standard variables available
|
||||
|
||||
### Module-Based Workflow
|
||||
- Part of a specific module (e.g., BMB)
|
||||
- Has access to module-specific variables
|
||||
- Stored in module's workflows directory
|
||||
|
||||
**BMB additional variable:** `{bmb_creations_output_folder}`
|
||||
|
||||
## 2. Continuable or Single-Session?
|
||||
|
||||
### Continuable (Multi-Session)
|
||||
**Use when:** Workflow might consume MASSIVE tokens, complex, many steps
|
||||
|
||||
**Required:**
|
||||
- `step-01-init.md` with continuation detection
|
||||
- `step-01b-continue.md` for resuming
|
||||
- `stepsCompleted` tracking in output frontmatter
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather']
|
||||
lastStep: 'step-02-gather'
|
||||
lastContinued: '2025-01-02'
|
||||
```
|
||||
|
||||
**Rule:** Each step appends its NAME to `stepsCompleted`
|
||||
|
||||
### Single-Session
|
||||
**Use when:** Simple, quick (<15 min), token-efficient
|
||||
|
||||
**Required:**
|
||||
- Standard `step-01-init.md` (no continuation logic)
|
||||
- No `stepsCompleted` tracking needed
|
||||
|
||||
## 3. Edit/Validate Support
|
||||
|
||||
### Create-Only
|
||||
```
|
||||
workflow-folder/
|
||||
├── workflow.md
|
||||
├── data/
|
||||
└── steps-c/
|
||||
├── step-01-init.md
|
||||
└── step-N-final.md
|
||||
```
|
||||
|
||||
**Use when:** Simple workflows, experimental, one-off
|
||||
|
||||
### Create + Edit + Validate (Tri-Modal)
|
||||
```
|
||||
workflow-folder/
|
||||
├── workflow.md
|
||||
├── data/ # SHARED
|
||||
├── steps-c/ # Create
|
||||
├── steps-e/ # Edit
|
||||
└── steps-v/ # Validate
|
||||
```
|
||||
|
||||
**Key:**
|
||||
- Each mode is SELF-CONTAINED
|
||||
- NO shared step files between modes
|
||||
- DATA folder is SHARED (prevents drift)
|
||||
- Duplicative steps OK (better than confusion)
|
||||
|
||||
**Use when:** Complex workflows that will be maintained
|
||||
|
||||
## 4. Document Output
|
||||
|
||||
### Document-Producing
|
||||
- Creates persistent output file
|
||||
- Uses templates for structure
|
||||
- Each step contributes to document
|
||||
- Consider final polish step
|
||||
|
||||
### Non-Document
|
||||
- Performs actions without persistent output
|
||||
- May produce temporary files
|
||||
- Focus on execution, not creation
|
||||
|
||||
## Decision Tree
|
||||
|
||||
```
|
||||
START: Creating a workflow
|
||||
│
|
||||
├─ Part of a module?
|
||||
│ ├─ YES → Module-based (include module variables)
|
||||
│ └─ NO → Standalone (standard variables only)
|
||||
│
|
||||
├─ Could this take multiple sessions / lots of tokens?
|
||||
│ ├─ YES → Continuable (add step-01b-continue.md)
|
||||
│ └─ NO → Single-session (simpler init)
|
||||
│
|
||||
└─ Will users need to edit/validate this workflow?
|
||||
├─ YES → Tri-modal (steps-c/, steps-e/, steps-v/)
|
||||
└─ NO → Create-only (steps-c/ only)
|
||||
```
|
||||
|
||||
## Output Format Decision
|
||||
|
||||
| Workflow Type | Init Template | Output Format |
|
||||
| ----------------------- | ------------------------ | ------------- |
|
||||
| Continuable + Document | step-01-init-continuable | Free-form |
|
||||
| Single-Session + Document| Standard init | Free-form |
|
||||
| Continuable + No Doc | step-01-init-continuable | N/A |
|
||||
| Single-Session + No Doc | Standard init | N/A |
|
||||
|
||||
**Free-form template** (recommended):
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: []
|
||||
lastStep: ''
|
||||
date: ''
|
||||
user_name: ''
|
||||
---
|
||||
|
||||
# {{document_title}}
|
||||
|
||||
[Content appended progressively]
|
||||
```
|
||||
Reference in New Issue
Block a user