Ignore and untrack BMad directories
This commit is contained in:
Max
@@ -1,329 +0,0 @@
|
||||
---
|
||||
name: 'step-06-design'
|
||||
description: 'Design the workflow structure and step sequence based on gathered requirements, tools configuration, and output format'
|
||||
|
||||
nextStepFile: './step-07-foundation.md'
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
stepTemplate: '../templates/step-template.md'
|
||||
stepTypePatterns: '../data/step-type-patterns.md'
|
||||
menuHandlingStandards: '../data/menu-handling-standards.md'
|
||||
frontmatterStandards: '../data/frontmatter-standards.md'
|
||||
outputFormatStandards: '../data/output-format-standards.md'
|
||||
inputDiscoveryStandards: '../data/input-discovery-standards.md'
|
||||
workflowChainingStandards: '../data/workflow-chaining-standards.md'
|
||||
trimodalWorkflowStructure: '../data/trimodal-workflow-structure.md'
|
||||
subprocessPatterns: '../data/subprocess-optimization-patterns.md'
|
||||
---
|
||||
|
||||
# Step 6: Workflow Structure Design
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To collaboratively design the workflow structure, step sequence, and interaction patterns based on the approved plan and output format requirements.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow architect and systems designer
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring workflow design patterns and architectural expertise
|
||||
- ✅ User brings their domain requirements and workflow preferences
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on designing structure, not implementation details
|
||||
- 🚫 FORBIDDEN to write actual step content or code in this step
|
||||
- 💬 Collaboratively design the flow and sequence
|
||||
- 🚫 DO NOT finalize design without user agreement
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Guide collaborative design process
|
||||
- 💾 After completing design, append to {workflowPlanFile}
|
||||
- 📖 Update frontmatter stepsCompleted to add this step when completed.
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and design is saved
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Approved plan from step 4 is available and should inform design
|
||||
- Output format design from step 5 (if completed) guides structure
|
||||
- Load architecture documentation when needed for guidance
|
||||
- Focus ONLY on structure and flow design
|
||||
- Don't implement actual files in this step
|
||||
- This is about designing the blueprint, not building
|
||||
|
||||
## DESIGN REFERENCE MATERIALS:
|
||||
|
||||
When designing, you will load these data standards as needed (ideally within subprocesses that can return the relevant insights during the design step):
|
||||
|
||||
- {stepTemplate} - Step file structure template
|
||||
- {stepTypePatterns} - Templates for different step types (init, middle, branch, validation, final)
|
||||
- {menuHandlingStandards} - Menu patterns and handler rules
|
||||
- {frontmatterStandards} - Variable definitions and path rules
|
||||
- {outputFormatStandards} - Output document patterns
|
||||
- {inputDiscoveryStandards} - How to discover documents from prior workflows
|
||||
- {workflowChainingStandards} - How workflows connect in sequences
|
||||
- {trimodalWorkflowStructure} - Tri-modal workflow patterns (if applicable)
|
||||
|
||||
Example [Workflow.md](../workflow.md) for reference of a perfect workflow.md with some complex options (not all workflows will offer multiple next step options like this one - most will just auto route right to a step 1 file)
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Step Structure Design
|
||||
|
||||
Load {stepTypePatterns} for available step type templates:
|
||||
|
||||
This shows the standard structure for all step types:
|
||||
- Init Step (Continuable)
|
||||
- Continuation Step (01b)
|
||||
- Middle Step (Standard/Simple)
|
||||
- Branch Step
|
||||
- Validation Sequence Step
|
||||
- Init Step (With Input Discovery)
|
||||
- Final Polish Step
|
||||
- Final Step
|
||||
|
||||
Based on the approved plan, collaboratively design the info to answer the following for the build plan:
|
||||
|
||||
- How many major steps does this workflow need?
|
||||
- What is the goal of each step?
|
||||
- Which steps are optional vs required?
|
||||
- Should any steps repeat or loop?
|
||||
- What are the decision points within steps?
|
||||
|
||||
### 1a. Continuation Support Assessment
|
||||
|
||||
**Ask the user:**
|
||||
"Will this workflow potentially take multiple sessions to complete? Consider:
|
||||
|
||||
- Does this workflow generate a document/output file?
|
||||
- Might users need to pause and resume the workflow?
|
||||
- Does the workflow involve extensive data collection or analysis?
|
||||
- Are there complex decisions that might require multiple sessions?
|
||||
|
||||
If **YES** to any of these, we should include continuation support using step-01b-continue.md."
|
||||
|
||||
**If continuation support is needed:**
|
||||
|
||||
- Include step-01-init.md (with continuation detection logic)
|
||||
- Include step-01b-continue.md (for resuming workflows)
|
||||
- Ensure every step updates `stepsCompleted` in output frontmatter
|
||||
- Design the workflow to persist state between sessions
|
||||
|
||||
### 2. Interaction Pattern Design
|
||||
|
||||
Load {menuHandlingStandards} for menu pattern options:
|
||||
|
||||
Design how users will interact with the workflow:
|
||||
- Where should users provide input vs where the AI works autonomously?
|
||||
- What menu pattern does each step need? (Standard A/P/C, Auto-proceed, Custom, Conditional)
|
||||
- Should there be Advanced Elicitation or Party Mode options?
|
||||
- How will users know their progress?
|
||||
- What confirmation points are needed?
|
||||
|
||||
### 3. Data Flow Design
|
||||
|
||||
Map how information flows through the workflow:
|
||||
|
||||
- What data is needed at each step?
|
||||
- What outputs does each step produce?
|
||||
- How is state tracked between steps?
|
||||
- Where are checkpoints and saves needed?
|
||||
- How are errors or exceptions handled?
|
||||
|
||||
### 4. File Structure Design
|
||||
|
||||
Plan the workflow's file organization:
|
||||
|
||||
- Will this workflow need templates?
|
||||
- Are there data files required?
|
||||
- Is a validation checklist needed?
|
||||
- What supporting files will be useful?
|
||||
- How will variables be managed?
|
||||
|
||||
### 5. Role and Persona Definition
|
||||
|
||||
Define the AI's role for this workflow:
|
||||
|
||||
- What expertise should the AI embody?
|
||||
- How should the AI communicate with users?
|
||||
- What tone and style is appropriate?
|
||||
- How collaborative vs prescriptive should the AI be?
|
||||
|
||||
### 6. Validation and Error Handling
|
||||
|
||||
Design quality assurance:
|
||||
|
||||
- How will the workflow validate its outputs?
|
||||
- What happens if a user provides invalid input?
|
||||
- Are there checkpoints for review?
|
||||
- How can users recover from errors?
|
||||
- What constitutes successful completion?
|
||||
|
||||
### 6a. Subprocess Optimization Design
|
||||
|
||||
Load {subprocessPatterns} to understand subprocess optimization patterns that can save context and improve performance during workflow execution.
|
||||
|
||||
Ask the user:
|
||||
|
||||
"**Should we design this workflow to leverage subprocess optimization patterns?** Consider:
|
||||
|
||||
- **Pattern 1 (Grep/Regex):** Will any step search across many files or documents for patterns?
|
||||
- **Pattern 2 (Deep Analysis):** Will any step analyze multiple files for prose, logic, quality, or flow?
|
||||
- **Pattern 3 (Data Operations):** Will any step load large reference data, knowledge bases, or datasets?
|
||||
- **Pattern 4 (Parallel Execution):** Can any validation or analysis checks run in parallel instead of sequentially?
|
||||
|
||||
If **YES** to any of these, we should design those steps with subprocess optimization in mind."
|
||||
|
||||
**If subprocess optimization is applicable:**
|
||||
|
||||
For each step that could benefit from subprocesses:
|
||||
- Identify which pattern(s) apply (Pattern 1, 2, 3, or 4)
|
||||
- Design what the subprocess should return (findings only, not full content)
|
||||
- Plan graceful fallback for LLMs without subprocess capability
|
||||
- Document optimization strategy in the build plan
|
||||
|
||||
**Example subprocess integration:**
|
||||
|
||||
```markdown
|
||||
### Step-Specific Rules:
|
||||
- 🎯 Analyze X files for Y - use subprocess per file (Pattern 2)
|
||||
- 💬 Subprocess returns structured findings, not full content
|
||||
- ⚙️ If subprocess unavailable: Perform analysis in main thread
|
||||
```
|
||||
|
||||
**Document in the plan:**
|
||||
|
||||
For each step identified for subprocess optimization, record:
|
||||
- Step number and name
|
||||
- Pattern type(s) to apply
|
||||
- What the subprocess will analyze
|
||||
- Expected return structure
|
||||
- Fallback approach
|
||||
|
||||
### 7. Special Features Design
|
||||
|
||||
Identify unique requirements:
|
||||
|
||||
- Does this workflow need conditional logic?
|
||||
- Are there branch points based on user choices?
|
||||
- Should it integrate with other workflows?
|
||||
- Does it need to handle multiple scenarios?
|
||||
|
||||
**Input Discovery:**
|
||||
|
||||
If this workflow depends on documents from prior workflows, load {inputDiscoveryStandards}:
|
||||
- What prior workflow outputs does this workflow need?
|
||||
- Are these required or optional inputs?
|
||||
- How will the workflow discover these documents?
|
||||
|
||||
**Workflow Chaining:**
|
||||
|
||||
If this workflow is part of a sequence, load {workflowChainingStandards}:
|
||||
- What workflow comes before this one?
|
||||
- What workflow comes after this one?
|
||||
- What outputs does this workflow produce for the next?
|
||||
|
||||
### 8. Design Review and Refinement
|
||||
|
||||
Present the design for review:
|
||||
|
||||
- Walk through the complete flow
|
||||
- Identify potential issues or improvements
|
||||
- Ensure all requirements are addressed
|
||||
- Get user agreement on the design
|
||||
|
||||
## DESIGN PRINCIPLES TO APPLY:
|
||||
|
||||
### Micro-File Architecture
|
||||
|
||||
- Keep each step focused and self-contained
|
||||
- Ensure steps can be loaded independently
|
||||
- Design for Just-In-Time loading
|
||||
|
||||
### Sequential Flow with Clear Progression
|
||||
|
||||
- Each step should build on previous work
|
||||
- Include clear decision points
|
||||
- Maintain logical progression toward goal
|
||||
|
||||
### Menu-Based Interactions
|
||||
|
||||
- Include consistent menu patterns
|
||||
- Provide clear options at decision points
|
||||
- Allow for conversation within steps
|
||||
|
||||
### State Management
|
||||
|
||||
- Track progress using `stepsCompleted` array
|
||||
- Persist state in output file frontmatter
|
||||
- Support continuation where appropriate
|
||||
|
||||
### 9. Document Design in Plan
|
||||
|
||||
Append to {workflowPlanFile}:
|
||||
|
||||
- Complete step outline with names and purposes
|
||||
- Flow diagram or sequence description
|
||||
- Interaction patterns
|
||||
- File structure requirements
|
||||
- Special features and handling
|
||||
|
||||
### 10. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save design to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#10-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and design is saved will you load {nextStepFile} to begin implementation.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Workflow structure designed collaboratively
|
||||
- All steps clearly defined and sequenced
|
||||
- Interaction patterns established
|
||||
- File structure planned
|
||||
- User agreement on design
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Designing without user collaboration
|
||||
- Skipping design principles
|
||||
- Not documenting design in plan
|
||||
- Proceeding without user agreement
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
Reference in New Issue
Block a user