Initial commit: BMAD framework + Story 1.1 Component Trait Definition
Features: - BMAD (Build Modular AI-driven Development) framework setup - BMM, BMB, CIS, Core modules configured - Story 1.1: Component trait with error handling - Workspace Cargo.toml with components crate - 31 tests passing (19 unit + 12 doc tests) Technical: - Component trait with compute_residuals, jacobian_entries, n_equations - ComponentError enum with thiserror - JacobianBuilder for sparse matrix construction - Object-safe trait supporting Box<dyn Component> - Comprehensive documentation and examples
This commit is contained in:
Sepehr
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
|
||||
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
|
||||
|
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
|
||||
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
|
||||
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,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
|
||||
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'
|
||||
```
|
||||
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`
|
||||
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/`.
|
||||
@@ -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
|
||||
---
|
||||
```
|
||||
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)
|
||||
```
|
||||
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?
|
||||
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]
|
||||
```
|
||||
Reference in New Issue
Block a user