Merge branch 'main' into feature/enhanced-toolkit-capabilities
This commit is contained in:
elsahafy
GitHub
commit
ec85240998
|
|
@ -161,7 +161,7 @@ BMGD Documentation
|
|||
|
||||
### Related Documentation
|
||||
|
||||
- **[BMM Documentation](../../bmm/docs/index.md)** - Core BMad Method documentation
|
||||
- **[BMM Documentation](../bmm/index.md)** - Core BMad Method documentation
|
||||
|
||||
## Tips for Using This Documentation
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Complete reference for all BMGD workflows organized by development phase.
|
|||
|
||||
BMGD workflows are organized into four phases:
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -161,7 +161,7 @@ Production workflows inherit from BMM and add game-specific overrides.
|
|||
**Command:** `sprint-planning`
|
||||
**Agent:** Game Scrum Master
|
||||
**Input:** GDD with epics
|
||||
**Output:** `{output_folder}/sprint-status.yaml`
|
||||
**Output:** `{implementation_artifacts}/sprint-status.yaml`
|
||||
|
||||
**Description:**
|
||||
Generates or updates sprint tracking from epic files. Sets up the sprint backlog and tracking.
|
||||
|
|
|
|||
|
|
@ -510,7 +510,7 @@ Trust your expertise - BMM supports your decisions.
|
|||
|
||||
**A:**
|
||||
|
||||
1. Search [Complete Documentation](./README.md) for related topics
|
||||
1. Search [Complete Documentation](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/README.md) for related topics
|
||||
2. Ask in [Discord Community](https://discord.gg/gk8jAdXWmj) (#general-dev)
|
||||
3. Open a [GitHub Issue](https://github.com/bmad-code-org/BMAD-METHOD/issues)
|
||||
4. Watch [YouTube Tutorials](https://www.youtube.com/@BMadCode)
|
||||
|
|
|
|||
|
|
@ -40,6 +40,8 @@ First know there is the full BMad Method Process and then there is a Quick Flow
|
|||
- Implementation in minutes, not days
|
||||
- Has a specialized single agent that does all of this: **[Quick Flow Solo Dev Agent](./quick-flow-solo-dev.md)**
|
||||
|
||||
- **TEA engagement (optional)** - Choose TEA engagement: none, TEA-only (standalone), or integrated by track. See **[Test Architect Guide](./test-architecture.md)**.
|
||||
|
||||
## 🤖 Agents and Collaboration
|
||||
|
||||
Complete guide to BMM's AI agent team:
|
||||
|
|
|
|||
|
|
@ -179,6 +179,16 @@ Once epics and stories are created:
|
|||
|
||||
**Why run this?** It ensures all your planning assets align properly before you start building.
|
||||
|
||||
#### Optional: TEA Engagement
|
||||
|
||||
Testing is not mandated by BMad. Decide how you want to engage TEA:
|
||||
|
||||
- **No TEA** - Use your existing team testing approach
|
||||
- **TEA-only (Standalone)** - Use TEA workflows with your own requirements and environment
|
||||
- **TEA-integrated** - Use TEA as part of the BMad Method or Enterprise flow
|
||||
|
||||
See the [Test Architect Guide](./test-architecture.md) for the five TEA engagement models and recommended sequences.
|
||||
|
||||
#### Context Management Tips
|
||||
|
||||
- **Use 200k+ context models** for best results (Claude Sonnet 4.5, GPT-4, etc.)
|
||||
|
|
@ -211,7 +221,14 @@ Once planning and architecture are complete, you'll move to Phase 4. **Important
|
|||
3. Tell the agent: "Run dev-story"
|
||||
4. The DEV agent will implement the story and update the sprint status
|
||||
|
||||
#### 3.4 Review the Code (Optional but Recommended)
|
||||
#### 3.4 Generate Guardrail Tests (Optional)
|
||||
|
||||
1. **Start a new chat** with the **TEA agent**
|
||||
2. Wait for the menu
|
||||
3. Tell the agent: "Run automate"
|
||||
4. The TEA agent generates or expands tests to act as guardrails
|
||||
|
||||
#### 3.5 Review the Code (Optional but Recommended)
|
||||
|
||||
1. **Start a new chat** with the **DEV agent**
|
||||
2. Wait for the menu
|
||||
|
|
@ -224,7 +241,8 @@ For each subsequent story, repeat the cycle using **fresh chats** for each workf
|
|||
|
||||
1. **New chat** → SM agent → "Run create-story"
|
||||
2. **New chat** → DEV agent → "Run dev-story"
|
||||
3. **New chat** → DEV agent → "Run code-review" (optional but recommended)
|
||||
3. **New chat** → TEA agent → "Run automate" (optional)
|
||||
4. **New chat** → DEV agent → "Run code-review" (optional but recommended)
|
||||
|
||||
After completing all stories in an epic:
|
||||
|
||||
|
|
|
|||
|
|
@ -6,6 +6,38 @@
|
|||
- **Mission:** Deliver actionable quality strategies, automation coverage, and gate decisions that scale with project complexity and compliance demands.
|
||||
- **Use When:** BMad Method or Enterprise track projects, integration risk is non-trivial, brownfield regression risk exists, or compliance/NFR evidence is required. (Quick Flow projects typically don't require TEA)
|
||||
|
||||
## Choose Your TEA Engagement Model
|
||||
|
||||
BMad does not mandate TEA. There are five valid ways to use it (or skip it). Pick one intentionally.
|
||||
|
||||
1. **No TEA**
|
||||
- Skip all TEA workflows. Use your existing team testing approach.
|
||||
|
||||
2. **TEA-only (Standalone)**
|
||||
- Use TEA on a non-BMad project. Bring your own requirements, acceptance criteria, and environments.
|
||||
- Typical sequence: `*test-design` (system or epic) -> `*atdd` and/or `*automate` -> optional `*test-review` -> `*trace` for coverage and gate decisions.
|
||||
- Run `*framework` or `*ci` only if you want TEA to scaffold the harness or pipeline.
|
||||
|
||||
3. **Integrated: Greenfield - BMad Method (Simple/Standard Work)**
|
||||
- Phase 3: system-level `*test-design`, then `*framework` and `*ci`.
|
||||
- Phase 4: per-epic `*test-design`, optional `*atdd`, then `*automate` and optional `*test-review`.
|
||||
- Gate (Phase 2): `*trace`.
|
||||
|
||||
4. **Integrated: Brownfield - BMad Method or Enterprise (Simple or Complex)**
|
||||
- Phase 2: baseline `*trace`.
|
||||
- Phase 3: system-level `*test-design`, then `*framework` and `*ci`.
|
||||
- Phase 4: per-epic `*test-design` focused on regression and integration risks.
|
||||
- Gate (Phase 2): `*trace`; `*nfr-assess` (if not done earlier).
|
||||
- For brownfield BMad Method, follow the same flow with `*nfr-assess` optional.
|
||||
|
||||
5. **Integrated: Greenfield - Enterprise Method (Enterprise/Compliance Work)**
|
||||
- Phase 2: `*nfr-assess`.
|
||||
- Phase 3: system-level `*test-design`, then `*framework` and `*ci`.
|
||||
- Phase 4: per-epic `*test-design`, plus `*atdd`/`*automate`/`*test-review`.
|
||||
- Gate (Phase 2): `*trace`; archive artifacts as needed.
|
||||
|
||||
If you are unsure, default to the integrated path for your track and adjust later.
|
||||
|
||||
## TEA Workflow Lifecycle
|
||||
|
||||
TEA integrates into the BMad development lifecycle during Solutioning (Phase 3) and Implementation (Phase 4):
|
||||
|
|
@ -16,6 +48,9 @@ graph TB
|
|||
subgraph Phase2["<b>Phase 2: PLANNING</b>"]
|
||||
PM["<b>PM: *prd (creates PRD with FRs/NFRs)</b>"]
|
||||
PlanNote["<b>Business requirements phase</b>"]
|
||||
NFR2["<b>TEA: *nfr-assess (optional, enterprise)</b>"]
|
||||
PM -.-> NFR2
|
||||
NFR2 -.-> PlanNote
|
||||
PM -.-> PlanNote
|
||||
end
|
||||
|
||||
|
|
@ -23,8 +58,8 @@ graph TB
|
|||
Architecture["<b>Architect: *architecture</b>"]
|
||||
EpicsStories["<b>PM/Architect: *create-epics-and-stories</b>"]
|
||||
TestDesignSys["<b>TEA: *test-design (system-level)</b>"]
|
||||
Framework["<b>TEA: *framework</b>"]
|
||||
CI["<b>TEA: *ci</b>"]
|
||||
Framework["<b>TEA: *framework (optional if needed)</b>"]
|
||||
CI["<b>TEA: *ci (optional if needed)</b>"]
|
||||
GateCheck["<b>Architect: *implementation-readiness</b>"]
|
||||
Architecture --> EpicsStories
|
||||
Architecture --> TestDesignSys
|
||||
|
|
@ -174,7 +209,7 @@ npm install -D @seontechnologies/playwright-utils
|
|||
|
||||
**Enable during BMAD installation** by answering "Yes" when prompted.
|
||||
|
||||
**Supported utilities (11 total):**
|
||||
**Supported utilities (10 total):**
|
||||
|
||||
- api-request, network-recorder, auth-session, intercept-network-call, recurse
|
||||
- log, file-utils, burn-in, network-error-monitor
|
||||
|
|
@ -429,7 +464,7 @@ Provides fixture-based utilities that integrate into TEA's test generation and r
|
|||
|
||||
Benefit: Faster CI feedback, HTTP error detection
|
||||
|
||||
**Utilities available** (11 total): api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor, fixtures-composition
|
||||
**Utilities available** (10 total): api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor, fixtures-composition
|
||||
|
||||
**Enable during BMAD installation** by answering "Yes" when prompted, or manually set `tea_use_playwright_utils: true` in `_bmad/bmm/config.yaml`.
|
||||
|
||||
|
|
|
|||
|
|
@ -98,8 +98,9 @@ Stories move through these states in the sprint status file:
|
|||
|
||||
1. SM runs `create-story`
|
||||
2. DEV runs `dev-story`
|
||||
3. DEV runs `code-review`
|
||||
4. If code review fails: DEV fixes issues in `dev-story`, then re-runs `code-review`
|
||||
3. (Optional) TEA runs `*automate` to generate or expand guardrail tests
|
||||
4. DEV runs `code-review`
|
||||
5. If code review fails: DEV fixes issues in `dev-story`, then re-runs `code-review`
|
||||
|
||||
**After Epic Complete:**
|
||||
|
||||
|
|
|
|||
|
|
@ -434,7 +434,7 @@ Architecture documents are living. Update them as you learn during implementatio
|
|||
|
||||
**Key Difference:** Enterprise adds optional extended workflows AFTER architecture but BEFORE create-epics-and-stories. Everything else is identical to BMad Method.
|
||||
|
||||
**Note:** TEA (Test Architect) operates across all phases and validates architecture testability but is not a Phase 3-specific workflow. See [Test Architecture Guide](../../../../docs/modules/bmm-bmad-method/test-architecture.md) for TEA's full lifecycle integration.
|
||||
**Note:** TEA (Test Architect) operates across all phases and validates architecture testability but is not a Phase 3-specific workflow. See [Test Architecture Guide](./test-architecture.md) for TEA's full lifecycle integration.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ CIS workflows integrate with:
|
|||
|
||||
## Related Documentation
|
||||
|
||||
- **[BMM Documentation](../../bmm/docs/index.md)** - Core BMad Method documentation
|
||||
- **[BMM Documentation](../bmm/index.md)** - Core BMad Method documentation
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -28,22 +28,18 @@ agent:
|
|||
- modules: "{project-root}/_bmad/bmb/docs/modules/kb.csv"
|
||||
|
||||
menu:
|
||||
- trigger: BM or fuzzy match on brainstorm-module
|
||||
exec: "{project-root}/_bmad/bmb/workflows/brainstorm-module/workflow.md"
|
||||
description: "[BM] Brainstorm and conceptualize new BMAD modules"
|
||||
|
||||
- trigger: PB or fuzzy match on product-brief
|
||||
exec: "{project-root}/_bmad/bmb/workflows/product-brief-module/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
|
||||
description: "[PB] Create product brief for BMAD module development"
|
||||
|
||||
- trigger: CM or fuzzy match on create-module
|
||||
exec: "{project-root}/_bmad/bmb/workflows/create-module/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
|
||||
description: "[CM] Create a complete BMAD module with agents, workflows, and infrastructure"
|
||||
|
||||
- trigger: EM or fuzzy match on edit-module
|
||||
exec: "{project-root}/_bmad/bmb/workflows/edit-module/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
|
||||
description: "[EM] Edit existing BMAD modules while maintaining coherence"
|
||||
|
||||
- trigger: VM or fuzzy match on validate-module
|
||||
exec: "{project-root}/_bmad/bmb/workflows/module-compliance-check/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
|
||||
description: "[VM] Run compliance check on BMAD modules against best practices"
|
||||
|
|
|
|||
|
|
@ -29,13 +29,17 @@ agent:
|
|||
|
||||
menu:
|
||||
- trigger: CW or fuzzy match on create-workflow
|
||||
exec: "{project-root}/_bmad/bmb/workflows/create-workflow/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
|
||||
description: "[CW] Create a new BMAD workflow with proper structure and best practices"
|
||||
|
||||
# - trigger: EW or fuzzy match on edit-workflow
|
||||
# exec: "{project-root}/_bmad/bmb/workflows/edit-workflow/workflow.md"
|
||||
# description: "[EW] Edit existing BMAD workflows while maintaining integrity"
|
||||
- trigger: EW or fuzzy match on edit-workflow
|
||||
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
|
||||
description: "[EW] Edit existing BMAD workflows while maintaining integrity"
|
||||
|
||||
# - trigger: VW or fuzzy match on validate-workflow
|
||||
# exec: "{project-root}/_bmad/bmb/workflows/workflow-compliance-check/workflow.md"
|
||||
# description: "[VW] Run compliance check on BMAD workflows against best practices"
|
||||
- trigger: VW or fuzzy match on validate-workflow
|
||||
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
|
||||
description: "[VW] Run validation check on BMAD workflows against best practices"
|
||||
|
||||
- trigger: RW or fuzzy match on convert-or-rework-workflow
|
||||
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
|
||||
description: "[RW] Rework a Workflow to a V6 Compliant Version"
|
||||
|
|
|
|||
|
|
@ -1,220 +0,0 @@
|
|||
# Standalone Workflow Builder Architecture
|
||||
|
||||
This document describes the architecture of the standalone workflow builder system - a pure markdown approach to creating structured workflows.
|
||||
|
||||
## Core Architecture Principles
|
||||
|
||||
### 1. Micro-File Design
|
||||
|
||||
Each workflow consists of multiple focused, self-contained files, driven from a workflow.md file that is initially loaded:
|
||||
|
||||
```
|
||||
workflow-folder/
|
||||
├── workflow.md # Main workflow configuration
|
||||
├── steps/ # Step instruction files (focused, self-contained)
|
||||
│ ├── step-01-init.md
|
||||
│ ├── step-02-profile.md
|
||||
│ └── step-N-[name].md
|
||||
├── templates/ # Content templates
|
||||
│ ├── profile-section.md
|
||||
│ └── [other-sections].md
|
||||
└── data/ # Optional data files
|
||||
└── [data-files].csv/.json
|
||||
```
|
||||
|
||||
### 2. Just-In-Time (JIT) Loading
|
||||
|
||||
- **Single File in Memory**: Only the current step file is loaded
|
||||
- **No Future Peeking**: Step files must not reference future steps
|
||||
- **Sequential Processing**: Steps execute in strict order
|
||||
- **On-Demand Loading**: Templates load only when needed
|
||||
|
||||
### 3. State Management
|
||||
|
||||
- **Frontmatter Tracking**: Workflow state stored in output document frontmatter
|
||||
- **Progress Array**: `stepsCompleted` tracks completed steps
|
||||
- **Last Step Marker**: `lastStep` indicates where to resume
|
||||
- **Append-Only Building**: Documents grow by appending content
|
||||
|
||||
### 4. Execution Model
|
||||
|
||||
```
|
||||
1. Load workflow.md → Read configuration
|
||||
2. Execute step-01-init.md → Initialize or detect continuation
|
||||
3. For each step:
|
||||
a. Load step file completely
|
||||
b. Execute instructions sequentially
|
||||
c. Wait for user input at menu points
|
||||
d. Only proceed with 'C' (Continue)
|
||||
e. Update document/frontmatter
|
||||
f. Load next step
|
||||
```
|
||||
|
||||
## Key Components
|
||||
|
||||
### Workflow File (workflow.md)
|
||||
|
||||
- **Purpose**: Entry point and configuration
|
||||
- **Content**: Role definition, goal, architecture rules
|
||||
- **Action**: Points to step-01-init.md
|
||||
|
||||
### Step Files (step-NN-[name].md)
|
||||
|
||||
- **Size**: Focused and concise (typically 5-10KB)
|
||||
- **Structure**: Frontmatter + sequential instructions
|
||||
- **Features**: Self-contained rules, menu handling, state updates
|
||||
|
||||
### Frontmatter Variables
|
||||
|
||||
Standard variables in step files:
|
||||
|
||||
```yaml
|
||||
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/[workflow-name]'
|
||||
thisStepFile: '{workflow_path}/steps/step-[N]-[name].md'
|
||||
nextStepFile: '{workflow_path}/steps/step-[N+1]-[name].md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/[output-name]-{project_name}.md'
|
||||
```
|
||||
|
||||
## Execution Flow
|
||||
|
||||
### Fresh Workflow
|
||||
|
||||
```
|
||||
workflow.md
|
||||
↓
|
||||
step-01-init.md (creates document)
|
||||
↓
|
||||
step-02-[name].md
|
||||
↓
|
||||
step-03-[name].md
|
||||
↓
|
||||
...
|
||||
↓
|
||||
step-N-[final].md (completes workflow)
|
||||
```
|
||||
|
||||
### Continuation Workflow
|
||||
|
||||
```
|
||||
workflow.md
|
||||
↓
|
||||
step-01-init.md (detects existing document)
|
||||
↓
|
||||
step-01b-continue.md (analyzes state)
|
||||
↓
|
||||
step-[appropriate-next].md
|
||||
```
|
||||
|
||||
## Menu System
|
||||
|
||||
### Standard Menu Pattern
|
||||
|
||||
```
|
||||
Display: **Select an Option:** [A] [Action] [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save content, update frontmatter, load next step
|
||||
```
|
||||
|
||||
### Menu Rules
|
||||
|
||||
- **Halt Required**: Always wait for user input
|
||||
- **Continue Only**: Only proceed with 'C' selection
|
||||
- **State Persistence**: Save before loading next step
|
||||
- **Loop Back**: Return to menu after other actions
|
||||
|
||||
## Collaborative Dialogue Model
|
||||
|
||||
### Not Command-Response
|
||||
|
||||
- **Facilitator Role**: AI guides, user decides
|
||||
- **Equal Partnership**: Both parties contribute
|
||||
- **No Assumptions**: Don't assume user wants next step
|
||||
- **Explicit Consent**: Always ask for input
|
||||
|
||||
### Example Pattern
|
||||
|
||||
```
|
||||
AI: "Tell me about your dietary preferences."
|
||||
User: [provides information]
|
||||
AI: "Thank you. Now let's discuss your cooking habits."
|
||||
[Continue conversation]
|
||||
AI: **Menu Options**
|
||||
```
|
||||
|
||||
## CSV Intelligence (Optional)
|
||||
|
||||
### Data-Driven Behavior
|
||||
|
||||
- Configuration in CSV files
|
||||
- Dynamic menu options
|
||||
- Variable substitution
|
||||
- Conditional logic
|
||||
|
||||
### Example Structure
|
||||
|
||||
```csv
|
||||
variable,type,value,description
|
||||
cooking_frequency,choice,"daily|weekly|occasionally","How often user cooks"
|
||||
meal_type,multi,"breakfast|lunch|dinner|snacks","Types of meals to plan"
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### File Size Limits
|
||||
|
||||
- **Step Files**: Keep focused and reasonably sized (5-10KB typical)
|
||||
- **Templates**: Keep focused and reusable
|
||||
- **Workflow File**: Keep lean, no implementation details
|
||||
|
||||
### Sequential Enforcement
|
||||
|
||||
- **Numbered Steps**: Use sequential numbering (1, 2, 3...)
|
||||
- **No Skipping**: Each step must complete
|
||||
- **State Updates**: Mark completion in frontmatter
|
||||
|
||||
### Error Prevention
|
||||
|
||||
- **Path Variables**: Use frontmatter variables, never hardcode
|
||||
- **Complete Loading**: Always read entire file before execution
|
||||
- **Menu Halts**: Never proceed without 'C' selection
|
||||
|
||||
## Migration from XML
|
||||
|
||||
### Advantages
|
||||
|
||||
- **No Dependencies**: Pure markdown, no XML parsing
|
||||
- **Human Readable**: Files are self-documenting
|
||||
- **Git Friendly**: Clean diffs and merges
|
||||
- **Flexible**: Easier to modify and extend
|
||||
|
||||
### Key Differences
|
||||
|
||||
| XML Workflows | Standalone Workflows |
|
||||
| ----------------- | ----------------------- |
|
||||
| Single large file | Multiple micro-files |
|
||||
| Complex structure | Simple sequential steps |
|
||||
| Parser required | Any markdown viewer |
|
||||
| Rigid format | Flexible organization |
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
### Critical Rules
|
||||
|
||||
- **NEVER** load multiple step files
|
||||
- **ALWAYS** read complete step file first
|
||||
- **NEVER** skip steps or optimize
|
||||
- **ALWAYS** update frontmatter of the output file when a step is complete
|
||||
- **NEVER** proceed without user consent
|
||||
|
||||
### Success Metrics
|
||||
|
||||
- Documents created correctly
|
||||
- All steps completed sequentially
|
||||
- User satisfied with collaborative process
|
||||
- Clean, maintainable file structure
|
||||
|
||||
This architecture ensures disciplined, predictable workflow execution while maintaining flexibility for different use cases.
|
||||
|
|
@ -1,206 +0,0 @@
|
|||
# CSV Data File Standards for BMAD Workflows
|
||||
|
||||
## Purpose and Usage
|
||||
|
||||
CSV data files in BMAD workflows serve specific purposes for different workflow types:
|
||||
|
||||
**For Agents:** Provide structured data that agents need to reference but cannot realistically generate (such as specific configurations, domain-specific data, or structured knowledge bases).
|
||||
|
||||
**For Expert Agents:** Supply specialized knowledge bases, reference data, or persistent information that the expert agent needs to access consistently across sessions.
|
||||
|
||||
**For Workflows:** Include reference data, configuration parameters, or structured inputs that guide workflow execution and decision-making.
|
||||
|
||||
**Key Principle:** CSV files should contain data that is essential, structured, and not easily generated by LLMs during execution.
|
||||
|
||||
## Intent-Based Design Principle
|
||||
|
||||
**Core Philosophy:** The closer workflows stay to **intent** rather than **prescriptive** instructions, the more creative and adaptive the LLM experience becomes.
|
||||
|
||||
**CSV Enables Intent-Based Design:**
|
||||
|
||||
- **Instead of:** Hardcoded scripts with exact phrases LLM must say
|
||||
- **CSV Provides:** Clear goals and patterns that LLM adapts creatively to context
|
||||
- **Result:** Natural, contextual conversations rather than rigid scripts
|
||||
|
||||
**Example - Advanced Elicitation:**
|
||||
|
||||
- **Prescriptive Alternative:** 50 separate files with exact conversation scripts
|
||||
- **Intent-Based Reality:** One CSV row with method goal + pattern → LLM adapts to user
|
||||
- **Benefit:** Same method works differently for different users while maintaining essence
|
||||
|
||||
**Intent vs Prescriptive Spectrum:**
|
||||
|
||||
- **Highly Prescriptive:** "Say exactly: 'Based on my analysis, I recommend...'"
|
||||
- **Balanced Intent:** "Help the user understand the implications using your professional judgment"
|
||||
- **CSV Goal:** Provide just enough guidance to enable creative, context-aware execution
|
||||
|
||||
## Primary Use Cases
|
||||
|
||||
### 1. Knowledge Base Indexing (Document Lookup Optimization)
|
||||
|
||||
**Problem:** Large knowledge bases with hundreds of documents cause context blowup and missed details when LLMs try to process them all.
|
||||
|
||||
**CSV Solution:** Create a knowledge base index with:
|
||||
|
||||
- **Column 1:** Keywords and topics
|
||||
- **Column 2:** Document file path/location
|
||||
- **Column 3:** Section or line number where relevant content starts
|
||||
- **Column 4:** Content type or summary (optional)
|
||||
|
||||
**Result:** Transform from context-blowing document loads to surgical precision lookups, creating agents with near-infinite knowledge bases while maintaining optimal context usage.
|
||||
|
||||
### 2. Workflow Sequence Optimization
|
||||
|
||||
**Problem:** Complex workflows (e.g., game development) with hundreds of potential steps for different scenarios become unwieldy and context-heavy.
|
||||
|
||||
**CSV Solution:** Create a workflow routing table:
|
||||
|
||||
- **Column 1:** Scenario type (e.g., "2D Platformer", "RPG", "Puzzle Game")
|
||||
- **Column 2:** Required step sequence (e.g., "step-01,step-03,step-07,step-12")
|
||||
- **Column 3:** Document sections to include
|
||||
- **Column 4:** Specialized parameters or configurations
|
||||
|
||||
**Result:** Step 1 determines user needs, finds closest match in CSV, confirms with user, then follows optimized sequence - truly optimal for context usage.
|
||||
|
||||
### 3. Method Registry (Dynamic Technique Selection)
|
||||
|
||||
**Problem:** Tasks need to select optimal techniques from dozens of options based on context, without hardcoding selection logic.
|
||||
|
||||
**CSV Solution:** Create a method registry with:
|
||||
|
||||
- **Column 1:** Category (collaboration, advanced, technical, creative, etc.)
|
||||
- **Column 2:** Method name and rich description
|
||||
- **Column 3:** Execution pattern or flow guide (e.g., "analysis → insights → action")
|
||||
- **Column 4:** Complexity level or use case indicators
|
||||
|
||||
**Example:** Advanced Elicitation task analyzes content context, selects 5 best-matched methods from 50 options, then executes dynamically using CSV descriptions.
|
||||
|
||||
**Result:** Smart, context-aware technique selection without hardcoded logic - infinitely extensible method libraries.
|
||||
|
||||
### 4. Configuration Management
|
||||
|
||||
**Problem:** Complex systems with many configuration options that vary by use case.
|
||||
|
||||
**CSV Solution:** Configuration lookup tables mapping scenarios to specific parameter sets.
|
||||
|
||||
## What NOT to Include in CSV Files
|
||||
|
||||
**Avoid Web-Searchable Data:** Do not include information that LLMs can readily access through web search or that exists in their training data, such as:
|
||||
|
||||
- Common programming syntax or standard library functions
|
||||
- General knowledge about widely used technologies
|
||||
- Historical facts or commonly available information
|
||||
- Basic terminology or standard definitions
|
||||
|
||||
**Include Specialized Data:** Focus on data that is:
|
||||
|
||||
- Specific to your project or domain
|
||||
- Not readily available through web search
|
||||
- Essential for consistent workflow execution
|
||||
- Too voluminous for LLM context windows
|
||||
|
||||
## CSV Data File Standards
|
||||
|
||||
### 1. Purpose Validation
|
||||
|
||||
- **Essential Data Only:** CSV must contain data that cannot be reasonably generated by LLMs
|
||||
- **Domain Specific:** Data should be specific to the workflow's domain or purpose
|
||||
- **Consistent Usage:** All columns and data must be referenced and used somewhere in the workflow
|
||||
- **No Redundancy:** Avoid data that duplicates functionality already available to LLMs
|
||||
|
||||
### 2. Structural Standards
|
||||
|
||||
- **Valid CSV Format:** Proper comma-separated values with quoted fields where needed
|
||||
- **Consistent Columns:** All rows must have the same number of columns
|
||||
- **No Missing Data:** Empty values should be explicitly marked (e.g., "", "N/A", or NULL)
|
||||
- **Header Row:** First row must contain clear, descriptive column headers
|
||||
- **Proper Encoding:** UTF-8 encoding required for special characters
|
||||
|
||||
### 3. Content Standards
|
||||
|
||||
- **No LLM-Generated Content:** Avoid data that LLMs can easily generate (e.g., generic phrases, common knowledge)
|
||||
- **Specific and Concrete:** Use specific values rather than vague descriptions
|
||||
- **Verifiable Data:** Data should be factual and verifiable when possible
|
||||
- **Consistent Formatting:** Date formats, numbers, and text should follow consistent patterns
|
||||
|
||||
### 4. Column Standards
|
||||
|
||||
- **Clear Headers:** Column names must be descriptive and self-explanatory
|
||||
- **Consistent Data Types:** Each column should contain consistent data types
|
||||
- **No Unused Columns:** Every column must be referenced and used in the workflow
|
||||
- **Appropriate Width:** Columns should be reasonably narrow and focused
|
||||
|
||||
### 5. File Size Standards
|
||||
|
||||
- **Efficient Structure:** CSV files should be as small as possible while maintaining functionality
|
||||
- **No Redundant Rows:** Avoid duplicate or nearly identical rows
|
||||
- **Compressed Data:** Use efficient data representation (e.g., codes instead of full descriptions)
|
||||
- **Maximum Size:** Individual CSV files should not exceed 1MB unless absolutely necessary
|
||||
|
||||
### 6. Documentation Standards
|
||||
|
||||
- **Documentation Required:** Each CSV file should have documentation explaining its purpose
|
||||
- **Column Descriptions:** Each column must be documented with its usage and format
|
||||
- **Data Sources:** Source of data should be documented when applicable
|
||||
- **Update Procedures:** Process for updating CSV data should be documented
|
||||
|
||||
### 7. Integration Standards
|
||||
|
||||
- **File References:** CSV files must be properly referenced in workflow configuration
|
||||
- **Access Patterns:** Workflow must clearly define how and when CSV data is accessed
|
||||
- **Error Handling:** Workflow must handle cases where CSV files are missing or corrupted
|
||||
- **Version Control:** CSV files should be versioned when changes occur
|
||||
|
||||
### 8. Quality Assurance
|
||||
|
||||
- **Data Validation:** CSV data should be validated for correctness and completeness
|
||||
- **Format Consistency:** Consistent formatting across all rows and columns
|
||||
- **No Ambiguity:** Data entries should be clear and unambiguous
|
||||
- **Regular Review:** CSV content should be reviewed periodically for relevance
|
||||
|
||||
### 9. Security Considerations
|
||||
|
||||
- **No Sensitive Data:** Avoid including sensitive, personal, or confidential information
|
||||
- **Data Sanitization:** CSV data should be sanitized for security issues
|
||||
- **Access Control:** Access to CSV files should be controlled when necessary
|
||||
- **Audit Trail:** Changes to CSV files should be logged when appropriate
|
||||
|
||||
### 10. Performance Standards
|
||||
|
||||
- **Fast Loading:** CSV files must load quickly within workflow execution
|
||||
- **Memory Efficient:** Structure should minimize memory usage during processing
|
||||
- **Optimized Queries:** If data lookup is needed, optimize for efficient access
|
||||
- **Caching Strategy**: Consider whether data can be cached for performance
|
||||
|
||||
## Implementation Guidelines
|
||||
|
||||
When creating CSV data files for BMAD workflows:
|
||||
|
||||
1. **Start with Purpose:** Clearly define why CSV is needed instead of LLM generation
|
||||
2. **Design Structure:** Plan columns and data types before creating the file
|
||||
3. **Test Integration:** Ensure workflow properly accesses and uses CSV data
|
||||
4. **Document Thoroughly:** Provide complete documentation for future maintenance
|
||||
5. **Validate Quality:** Check data quality, format consistency, and integration
|
||||
6. **Monitor Usage:** Track how CSV data is used and optimize as needed
|
||||
|
||||
## Common Anti-Patterns to Avoid
|
||||
|
||||
- **Generic Phrases:** CSV files containing common phrases or LLM-generated content
|
||||
- **Redundant Data:** Duplicating information easily available to LLMs
|
||||
- **Overly Complex:** Unnecessarily complex CSV structures when simple data suffices
|
||||
- **Unused Columns:** Columns that are defined but never referenced in workflows
|
||||
- **Poor Formatting:** Inconsistent data formats, missing values, or structural issues
|
||||
- **No Documentation:** CSV files without clear purpose or usage documentation
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For each CSV file, verify:
|
||||
|
||||
- [ ] Purpose is essential and cannot be replaced by LLM generation
|
||||
- [ ] All columns are used in the workflow
|
||||
- [ ] Data is properly formatted and consistent
|
||||
- [ ] File is efficiently sized and structured
|
||||
- [ ] Documentation is complete and clear
|
||||
- [ ] Integration with workflow is tested and working
|
||||
- [ ] Security considerations are addressed
|
||||
- [ ] Performance requirements are met
|
||||
|
|
@ -1,220 +0,0 @@
|
|||
# Intent vs Prescriptive Spectrum
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
The **Intent vs Prescriptive Spectrum** is a fundamental design principle for BMAD workflows and agents. It determines how much creative freedom an LLM has versus how strictly it must follow predefined instructions.
|
||||
|
||||
**Key Principle:** The closer workflows stay to **intent**, the more creative and adaptive the LLM experience becomes. The closer they stay to **prescriptive**, the more consistent and controlled the output becomes.
|
||||
|
||||
## Understanding the Spectrum
|
||||
|
||||
### **Intent-Based Design** (Creative Freedom)
|
||||
|
||||
**Focus**: What goal should be achieved
|
||||
**Approach**: Trust the LLM to determine the best method
|
||||
**Result**: Creative, adaptive, context-aware interactions
|
||||
**Best For**: Creative exploration, problem-solving, personalized experiences
|
||||
|
||||
### **Prescriptive Design** (Structured Control)
|
||||
|
||||
**Focus**: Exactly what to say and do
|
||||
**Approach**: Detailed scripts and specific instructions
|
||||
**Result**: Consistent, predictable, controlled outcomes
|
||||
**Best For**: Compliance, safety-critical, standardized processes
|
||||
|
||||
## Spectrum Examples
|
||||
|
||||
### **Highly Intent-Based** (Creative End)
|
||||
|
||||
```markdown
|
||||
**Example:** Story Exploration Workflow
|
||||
**Instruction:** "Help the user explore their dream imagery to craft compelling narratives, use multiple turns of conversation to really push users to develop their ideas, giving them hints and ideas also to prime them effectively to bring out their creativity"
|
||||
**LLM Freedom:** Adapts questions, explores tangents, follows creative inspiration
|
||||
**Outcome:** Unique, personalized storytelling experiences
|
||||
```
|
||||
|
||||
### **Balanced Middle** (Professional Services)
|
||||
|
||||
```markdown
|
||||
**Example:** Business Strategy Workflow
|
||||
**Instruction:** "Guide the user through SWOT analysis using your business expertise. when complete tell them 'here is your final report {report output}'
|
||||
**LLM Freedom:** Professional judgment in analysis, structured but adaptive approach
|
||||
**Outcome:** Professional, consistent yet tailored business insights
|
||||
```
|
||||
|
||||
### **Highly Prescriptive** (Control End)
|
||||
|
||||
```markdown
|
||||
**Example:** Medical Intake Form
|
||||
**Instruction:** "Ask exactly: 'Do you currently experience any of the following symptoms: fever, cough, fatigue?' Wait for response, then ask exactly: 'When did these symptoms begin?'"
|
||||
**LLM Freedom:** Minimal - must follow exact script for medical compliance
|
||||
**Outcome:** Consistent, medically compliant patient data collection
|
||||
```
|
||||
|
||||
## Spectrum Positioning Guide
|
||||
|
||||
### **Choose Intent-Based When:**
|
||||
|
||||
- ✅ Creative exploration and innovation are goals
|
||||
- ✅ Personalization and adaptation to user context are important
|
||||
- ✅ Human-like conversation and natural interaction are desired
|
||||
- ✅ Problem-solving requires flexible thinking
|
||||
- ✅ User experience and engagement are priorities
|
||||
|
||||
**Examples:**
|
||||
|
||||
- Creative brainstorming sessions
|
||||
- Personal coaching or mentoring
|
||||
- Exploratory research and discovery
|
||||
- Artistic content creation
|
||||
- Collaborative problem-solving
|
||||
|
||||
### **Choose Prescriptive When:**
|
||||
|
||||
- ✅ Compliance with regulations or standards is required
|
||||
- ✅ Safety or legal considerations are paramount
|
||||
- ✅ Exact consistency across multiple sessions is essential
|
||||
- ✅ Training new users on specific procedures
|
||||
- ✅ Data collection must follow specific protocols
|
||||
|
||||
**Examples:**
|
||||
|
||||
- Medical intake and symptom assessment
|
||||
- Legal compliance questionnaires
|
||||
- Safety checklists and procedures
|
||||
- Standardized testing protocols
|
||||
- Regulatory data collection
|
||||
|
||||
### **Choose Balanced When:**
|
||||
|
||||
- ✅ Professional expertise is required but adaptation is beneficial
|
||||
- ✅ Consistent quality with flexible application is needed
|
||||
- ✅ Domain expertise should guide but not constrain interactions
|
||||
- ✅ User trust and professional credibility are important
|
||||
- ✅ Complex processes require both structure and judgment
|
||||
|
||||
**Examples:**
|
||||
|
||||
- Business consulting and advisory
|
||||
- Technical support and troubleshooting
|
||||
- Educational tutoring and instruction
|
||||
- Financial planning and advice
|
||||
- Project management facilitation
|
||||
|
||||
## Implementation Guidelines
|
||||
|
||||
### **For Workflow Designers:**
|
||||
|
||||
1. **Early Spectrum Decision**: Determine spectrum position during initial design
|
||||
2. **User Education**: Explain spectrum choice and its implications to users
|
||||
3. **Consistent Application**: Maintain chosen spectrum throughout workflow
|
||||
4. **Context Awareness**: Adjust spectrum based on specific use case requirements
|
||||
|
||||
### **For Workflow Implementation:**
|
||||
|
||||
**Intent-Based Patterns:**
|
||||
|
||||
```markdown
|
||||
- "Help the user understand..." (vs "Explain that...")
|
||||
- "Guide the user through..." (vs "Follow these steps...")
|
||||
- "Use your professional judgment to..." (vs "Apply this specific method...")
|
||||
- "Adapt your approach based on..." (vs "Regardless of situation, always...")
|
||||
```
|
||||
|
||||
**Prescriptive Patterns:**
|
||||
|
||||
```markdown
|
||||
- "Say exactly: '...'" (vs "Communicate that...")
|
||||
- "Follow this script precisely: ..." (vs "Cover these points...")
|
||||
- "Do not deviate from: ..." (vs "Consider these options...")
|
||||
- "Must ask in this order: ..." (vs "Ensure you cover...")
|
||||
```
|
||||
|
||||
### **For Agents:**
|
||||
|
||||
**Intent-Based Agent Design:**
|
||||
|
||||
```yaml
|
||||
persona:
|
||||
communication_style: 'Adaptive professional who adjusts approach based on user context'
|
||||
guiding_principles:
|
||||
- 'Use creative problem-solving within professional boundaries'
|
||||
- 'Personalize approach while maintaining expertise'
|
||||
- 'Adapt conversation flow to user needs'
|
||||
```
|
||||
|
||||
**Prescriptive Agent Design:**
|
||||
|
||||
```yaml
|
||||
persona:
|
||||
communication_style: 'Follows standardized protocols exactly'
|
||||
governing_rules:
|
||||
- 'Must use approved scripts without deviation'
|
||||
- 'Follow sequence precisely as defined'
|
||||
- 'No adaptation of prescribed procedures'
|
||||
```
|
||||
|
||||
## Spectrum Calibration Questions
|
||||
|
||||
**Ask these during workflow design:**
|
||||
|
||||
1. **Consequence of Variation**: What happens if the LLM says something different?
|
||||
2. **User Expectation**: Does the user expect consistency or creativity?
|
||||
3. **Risk Level**: What are the risks of creative deviation vs. rigid adherence?
|
||||
4. **Expertise Required**: Is domain expertise application more important than consistency?
|
||||
5. **Regulatory Requirements**: Are there external compliance requirements?
|
||||
|
||||
## Best Practices
|
||||
|
||||
### **DO:**
|
||||
|
||||
- ✅ Make conscious spectrum decisions during design
|
||||
- ✅ Explain spectrum choices to users
|
||||
- ✅ Use intent-based design for creative and adaptive experiences
|
||||
- ✅ Use prescriptive design for compliance and consistency requirements
|
||||
- ✅ Consider balanced approaches for professional services
|
||||
- ✅ Document spectrum rationale for future reference
|
||||
|
||||
### **DON'T:**
|
||||
|
||||
- ❌ Mix spectrum approaches inconsistently within workflows
|
||||
- ❌ Default to prescriptive when intent-based would be more effective
|
||||
- ❌ Use creative freedom when compliance is required
|
||||
- ❌ Forget to consider user expectations and experience
|
||||
- ❌ Overlook risk assessment in spectrum selection
|
||||
|
||||
## Quality Assurance
|
||||
|
||||
**When validating workflows:**
|
||||
|
||||
- Check if spectrum position is intentional and consistent
|
||||
- Verify prescriptive elements are necessary and justified
|
||||
- Ensure intent-based elements have sufficient guidance
|
||||
- Confirm spectrum alignment with user needs and expectations
|
||||
- Validate that risks are appropriately managed
|
||||
|
||||
## Examples in Practice
|
||||
|
||||
### **Medical Intake (Highly Prescriptive):**
|
||||
|
||||
- **Why**: Patient safety, regulatory compliance, consistent data collection
|
||||
- **Implementation**: Exact questions, specific order, no deviation permitted
|
||||
- **Benefit**: Reliable, medically compliant patient information
|
||||
|
||||
### **Creative Writing Workshop (Highly Intent):**
|
||||
|
||||
- **Why**: Creative exploration, personalized inspiration, artistic expression
|
||||
- **Implementation**: Goal guidance, creative freedom, adaptive prompts
|
||||
- **Benefit**: Unique, personalized creative works
|
||||
|
||||
### **Business Strategy (Balanced):**
|
||||
|
||||
- **Why**: Professional expertise with adaptive application
|
||||
- **Implementation**: Structured framework with professional judgment
|
||||
- **Benefit**: Professional, consistent yet tailored business insights
|
||||
|
||||
## Conclusion
|
||||
|
||||
The Intent vs Prescriptive Spectrum is not about good vs. bad - it's about **appropriate design choices**. The best workflows make conscious decisions about where they fall on this spectrum based on their specific requirements, user needs, and risk considerations.
|
||||
|
||||
**Key Success Factor**: Choose your spectrum position intentionally, implement it consistently, and align it with your specific use case requirements.
|
||||
|
|
@ -1,469 +0,0 @@
|
|||
# BMAD Step File Guidelines
|
||||
|
||||
**Version:** 1.0
|
||||
**Module:** bmb (BMAD Builder)
|
||||
**Purpose:** Definitive guide for creating BMAD workflow step files
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
BMAD workflow step files follow a strict structure to ensure consistency, progressive disclosure, and mode-aware routing. Every step file MUST adhere to these guidelines.
|
||||
|
||||
---
|
||||
|
||||
## File Size Optimization
|
||||
|
||||
**CRITICAL:** Keep step files **LT 200 lines** (250 lines absolute maximum).
|
||||
|
||||
If a step exceeds this limit:
|
||||
- Consider splitting into multiple steps
|
||||
- Extract content to `/data/` reference files
|
||||
- Optimize verbose explanations
|
||||
|
||||
---
|
||||
|
||||
## Required Frontmatter Structure
|
||||
|
||||
CRITICAL: Frontmatter should only have items that are used in the step file!
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: 'step-2-foo.md'
|
||||
description: 'Brief description of what this step accomplishes'
|
||||
|
||||
# File References ## CRITICAL: Frontmatter references or variables should only have items that are used in the step file!
|
||||
outputFile: {bmb_creations_output_folder}/output-file-name.md
|
||||
nextStepFile: './step-3-bar.md'
|
||||
|
||||
# Task References (as needed)
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
# ... other task-specific references
|
||||
---
|
||||
```
|
||||
|
||||
### Frontmatter Field Descriptions
|
||||
|
||||
| Field | Required | Description |
|
||||
| --------------- | --------- | --------------------------------- |
|
||||
| `name` | Yes | Step identifier (kebab-case) |
|
||||
| `description` | Yes | One-line summary of step purpose |
|
||||
| `outputFile` | Yes | Where results are documented |
|
||||
| Task references | As needed | Paths to external workflows/tasks |
|
||||
|
||||
---
|
||||
|
||||
## Document Structure
|
||||
|
||||
### 1. Title
|
||||
|
||||
```markdown
|
||||
# Step X: [Step Name]
|
||||
```
|
||||
|
||||
### 2. STEP GOAL
|
||||
|
||||
```markdown
|
||||
## STEP GOAL:
|
||||
|
||||
[Single sentence stating what this step accomplishes]
|
||||
```
|
||||
|
||||
### 3. Role Reinforcement
|
||||
|
||||
```markdown
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a [specific role] who [does what]
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring [your expertise], user brings [their expertise], together we [achieve goal]
|
||||
- ✅ Maintain [tone/approach] throughout
|
||||
```
|
||||
|
||||
### 4. Language Preference
|
||||
|
||||
```markdown
|
||||
### Language Preference:
|
||||
The user has chosen to communicate in the **{language}** language.
|
||||
You MUST respond in **{language}** throughout this step.
|
||||
```
|
||||
|
||||
**IMPORTANT:** Read `userPreferences.language` from tracking file (agentPlan, validationReport, etc.) and enforce it.
|
||||
|
||||
### 5. Step-Specific Rules
|
||||
|
||||
```markdown
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on [specific scope]
|
||||
- 🚫 FORBIDDEN to [prohibited action]
|
||||
- 💬 Approach: [how to engage]
|
||||
- 📋 Ensure [specific outcome]
|
||||
```
|
||||
|
||||
### 6. EXECUTION PROTOCOLS
|
||||
|
||||
```markdown
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- [What to do - use verbs]
|
||||
- [Another action]
|
||||
- 🚫 FORBIDDEN to [prohibited action]
|
||||
```
|
||||
|
||||
### 7. CONTEXT BOUNDARIES
|
||||
|
||||
```markdown
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: [what's available]
|
||||
- Focus: [what to focus on]
|
||||
- Limits: [boundaries]
|
||||
- Dependencies: [what this step depends on]
|
||||
```
|
||||
|
||||
### 8. Sequence of Instructions
|
||||
|
||||
```markdown
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. [First Action]
|
||||
|
||||
**[Action Description]**
|
||||
|
||||
### 2. [Second Action]
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
### 9. MENU OPTIONS
|
||||
|
||||
```markdown
|
||||
### X. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] [menu item A] [P] [menu item P] [C] [menu item C]"
|
||||
|
||||
#### 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](#x-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
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
ONLY WHEN [C continue option] is selected and [completion conditions], will you then load and read fully `{nextStepFile}`...
|
||||
```
|
||||
|
||||
### 10. SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
```markdown
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- [Success criterion 1]
|
||||
- [Success criterion 2]
|
||||
- ...
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- [Failure criterion 1]
|
||||
- [Failure criterion 2]
|
||||
- ...
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## A/P/C Menu Convention
|
||||
|
||||
BMAD workflows use a fixed menu structure:
|
||||
|
||||
| Option | Meaning | Behavior |
|
||||
| ------ | -------------------- | ---------------------------------------------------- |
|
||||
| **A** | Advanced Elicitation | Execute advancedElicitationTask, then redisplay menu |
|
||||
| **P** | Party Mode | Execute partyModeWorkflow, then redisplay menu |
|
||||
| **C** | Continue/Accept | Save output, update frontmatter, load nextStepFile |
|
||||
| Other | Custom | Defined per step (e.g., F = Fix, X = Exit) |
|
||||
|
||||
**Rules:**
|
||||
- A and P MUST always be present
|
||||
- C MUST be present except in final step (use X or similar for exit)
|
||||
- After A/P → redisplay menu
|
||||
- After C → proceed to next step
|
||||
- Custom letters can be used for step-specific options
|
||||
|
||||
---
|
||||
|
||||
## Progressive Disclosure
|
||||
|
||||
**Core Principle:** Each step only knows about its immediate next step.
|
||||
|
||||
### Implementation
|
||||
|
||||
1. **Never pre-load future steps** - Only load `nextStepFile` when user selects [C]
|
||||
|
||||
2. **Mode-aware routing** (for shared steps):
|
||||
```markdown
|
||||
## MODE-AWARE ROUTING:
|
||||
### If entered from CREATE mode:
|
||||
Load ./s-next-step.md
|
||||
|
||||
### If entered from EDIT mode:
|
||||
Load ./e-next-step.md
|
||||
|
||||
### If entered from VALIDATE mode:
|
||||
Load ./v-next-step.md
|
||||
```
|
||||
|
||||
3. **Read tracking file first** - Always read the tracking file (agentPlan, validationReport, etc.) to determine current mode and routing
|
||||
|
||||
---
|
||||
|
||||
## Mode-Aware Routing (Shared Steps)
|
||||
|
||||
Shared steps (`s-*.md`) must route based on the mode stored in the tracking file.
|
||||
|
||||
### Tracking File Frontmatter
|
||||
|
||||
```yaml
|
||||
---
|
||||
mode: create # or edit | validate
|
||||
stepsCompleted:
|
||||
- c-01-brainstorm.md
|
||||
- s-01-discovery.md
|
||||
# ... other tracking fields
|
||||
---
|
||||
```
|
||||
|
||||
### Routing Implementation
|
||||
|
||||
```markdown
|
||||
## COMPLETION ROUTING:
|
||||
|
||||
1. Append `./this-step-name.md` to {trackingFile}.stepsCompleted
|
||||
2. Save content to {trackingFile}
|
||||
3. Read {trackingFile}.mode
|
||||
4. Route based on mode:
|
||||
|
||||
### IF mode == create:
|
||||
Load ./s-next-create-step.md
|
||||
|
||||
### IF mode == edit:
|
||||
Load ./e-next-edit-step.md
|
||||
|
||||
### IF mode == validate:
|
||||
Load ./s-next-validate-step.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## File Naming Conventions
|
||||
|
||||
### Tri-Modal Workflows
|
||||
|
||||
| Prefix | Meaning | Example |
|
||||
| ------ | ------------------ | ---------------------- |
|
||||
| `c-` | Create-specific | `c-01-brainstorm.md` |
|
||||
| `e-` | Edit-specific | `e-01-load-analyze.md` |
|
||||
| `v-` | Validate-specific | `v-01-load-review.md` |
|
||||
| `s-` | Shared by 2+ modes | `s-05-activation.md` |
|
||||
|
||||
### Numbering
|
||||
|
||||
- Within each prefix type, number sequentially
|
||||
- Restart numbering for each prefix type (c-01, e-01, v-01, s-01)
|
||||
- Use letters for sub-steps (s-06a, s-06b, s-06c)
|
||||
|
||||
---
|
||||
|
||||
## Language Preference Enforcement
|
||||
|
||||
**CRITICAL:** Every step MUST respect the user's chosen language.
|
||||
|
||||
### Implementation
|
||||
|
||||
```markdown
|
||||
### Language Preference:
|
||||
The user has chosen to communicate in the **{language}** language.
|
||||
You MUST respond in **{language}** throughout this step.
|
||||
```
|
||||
|
||||
### Reading Language Preference
|
||||
|
||||
From tracking file frontmatter:
|
||||
```yaml
|
||||
---
|
||||
userPreferences:
|
||||
language: spanish # or any language
|
||||
---
|
||||
```
|
||||
|
||||
### Rules
|
||||
|
||||
- **MUST** read language preference from tracking file at step start
|
||||
- **MUST** respond in user's chosen language for ALL content
|
||||
- **MUST** include menu options in user's chosen language
|
||||
- **EXCEPTION:** Technical terms, file names, and code remain in English
|
||||
|
||||
---
|
||||
|
||||
## Data File References
|
||||
|
||||
When step content becomes too large (>200 lines), extract to `/data/` files:
|
||||
|
||||
### When to Extract
|
||||
|
||||
- Step file exceeds 200 lines
|
||||
- Content is reference material (rules, examples, patterns)
|
||||
- Content is reused across multiple steps
|
||||
|
||||
### How to Reference
|
||||
|
||||
```markdown
|
||||
## Reference Material:
|
||||
|
||||
Load and reference: `../data/{data-file-name}.md`
|
||||
|
||||
Key points from that file:
|
||||
- [Point 1]
|
||||
- [Point 2]
|
||||
```
|
||||
|
||||
### Data File Best Practices
|
||||
|
||||
- Keep data files focused on single topic
|
||||
- Use clear, descriptive names
|
||||
- Include examples and non-examples
|
||||
- Optimize for LLM usage (concise, structured)
|
||||
|
||||
---
|
||||
|
||||
## Common Pitfalls to Avoid
|
||||
|
||||
### ❌ DON'T:
|
||||
|
||||
- Pre-load future steps (violates progressive disclosure)
|
||||
- Exceed 250 lines without splitting
|
||||
- Forget to update `stepsCompleted` array
|
||||
- Ignore user's language preference
|
||||
- Skip mode checking in shared steps
|
||||
- Use vague menu option letters (stick to A/P/C plus 1-2 custom)
|
||||
|
||||
### ✅ DO:
|
||||
|
||||
- Keep files under 200 lines
|
||||
- Read tracking file first thing
|
||||
- Route based on `mode` field
|
||||
- Include A/P in every menu
|
||||
- Use descriptive step names
|
||||
- Extract complex content to data files
|
||||
|
||||
---
|
||||
|
||||
## Template: New Step File
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: 'step-name'
|
||||
description: 'What this step does'
|
||||
|
||||
# File References
|
||||
thisStepFile: ./step-name.md
|
||||
workflowFile: ../workflow.md
|
||||
outputFile: {bmb_creations_output_folder}/output.md
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step X: [Step Name]
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
[Single sentence goal]
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a [role] who [does what]
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring [expertise], user brings [expertise], together we [achieve]
|
||||
- ✅ Maintain [tone] throughout
|
||||
|
||||
### Language Preference:
|
||||
The user has chosen to communicate in the **{language}** language.
|
||||
You MUST respond in **{language}** throughout this step.
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on [scope]
|
||||
- 🚫 FORBIDDEN to [prohibited action]
|
||||
- 💬 Approach: [how to engage]
|
||||
- 📋 Ensure [outcome]
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- [Action 1]
|
||||
- [Action 2]
|
||||
- 🚫 FORBIDDEN to [prohibited action]
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: [what's available]
|
||||
- Focus: [what to focus on]
|
||||
- Limits: [boundaries]
|
||||
- Dependencies: [what depends on what]
|
||||
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. [First Action]
|
||||
|
||||
**Description of first action**
|
||||
|
||||
### 2. [Second Action]
|
||||
|
||||
**Description of second action**
|
||||
|
||||
...
|
||||
|
||||
### X. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [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 comments or queries: help user respond then [Redisplay Menu Options](#x-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
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
ONLY WHEN [C continue option] is selected and [conditions], will you then load and read fully `{nextStepFile}`...
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- [Success criteria]
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- [Failure criteria]
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**End of Guidelines**
|
||||
|
|
@ -1,139 +0,0 @@
|
|||
---
|
||||
name: "step-{{stepNumber}}-{{stepName}}"
|
||||
description: "{{stepDescription}}"
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: "{project-root}/_bmad/{{targetModule}}/workflows/{{workflowName}}"
|
||||
|
||||
# File References
|
||||
thisStepFile: "{workflow_path}/steps/step-{{stepNumber}}-{{stepName}}.md"
|
||||
{{#hasNextStep}}
|
||||
nextStepFile: "{workflow_path}/steps/step-{{nextStepNumber}}-{{nextStepName}}.md"
|
||||
{{/hasNextStep}}
|
||||
workflowFile: "{workflow_path}/workflow.md"
|
||||
{{#hasOutput}}
|
||||
outputFile: "{output_folder}/{{outputFileName}}-{project_name}.md"
|
||||
{{/hasOutput}}
|
||||
|
||||
# Task References (list only if used in THIS step file instance and only the ones used, there might be others)
|
||||
advancedElicitationTask: "{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml"
|
||||
partyModeWorkflow: "{project-root}/_bmad/core/workflows/party-mode/workflow.md"
|
||||
|
||||
{{#hasTemplates}}
|
||||
# Template References
|
||||
{{#templates}}
|
||||
{{name}}: "{workflow_path}/templates/{{file}}"
|
||||
{{/templates}}
|
||||
{{/hasTemplates}}
|
||||
---
|
||||
|
||||
# Step {{stepNumber}}: {{stepTitle}}
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
{{stepGoal}}
|
||||
|
||||
## 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
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a {{aiRole}}
|
||||
- ✅ 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 {{aiExpertise}}, user brings {{userExpertise}}
|
||||
- ✅ Maintain collaborative {{collaborationStyle}} tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on {{stepFocus}}
|
||||
- 🚫 FORBIDDEN to {{forbiddenAction}}
|
||||
- 💬 Approach: {{stepApproach}}
|
||||
- 📋 {{additionalRule}}
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
{{#executionProtocols}}
|
||||
|
||||
- 🎯 {{.}}
|
||||
{{/executionProtocols}}
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: {{availableContext}}
|
||||
- Focus: {{contextFocus}}
|
||||
- Limits: {{contextLimits}}
|
||||
- Dependencies: {{contextDependencies}}
|
||||
|
||||
## SEQUENCE OF INSTRUCTIONS (Do not deviate, skip, or optimize)
|
||||
|
||||
{{#instructions}}
|
||||
|
||||
### {{number}}. {{title}}
|
||||
|
||||
{{content}}
|
||||
|
||||
{{#hasContentToAppend}}
|
||||
|
||||
#### Content to Append (if applicable):
|
||||
|
||||
```markdown
|
||||
{{contentToAppend}}
|
||||
```
|
||||
|
||||
{{/hasContentToAppend}}
|
||||
|
||||
{{/instructions}}
|
||||
|
||||
{{#hasMenu}}
|
||||
|
||||
### {{menuNumber}}. Present MENU OPTIONS
|
||||
|
||||
Display: **{{menuDisplay}}**
|
||||
|
||||
#### 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:
|
||||
|
||||
{{#menuOptions}}
|
||||
|
||||
- IF {{key}}: {{action}}
|
||||
{{/menuOptions}}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#{{menuNumber}}-present-menu-options)
|
||||
{{/hasMenu}}
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
{{completionNote}}
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
{{#successCriteria}}
|
||||
|
||||
- {{.}}
|
||||
{{/successCriteria}}
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
{{#failureModes}}
|
||||
|
||||
- {{.}}
|
||||
{{/failureModes}}
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
---
|
||||
name: { { workflowDisplayName } }
|
||||
description: { { workflowDescription } }
|
||||
web_bundle: { { webBundleFlag } }
|
||||
---
|
||||
|
||||
# {{workflowDisplayName}}
|
||||
|
||||
**Goal:** {{workflowGoal}}
|
||||
|
||||
**Your Role:** In addition to your name, communication_style, and persona, you are also a {{aiRole}} collaborating with {{userType}}. This is a partnership, not a client-vendor relationship. You bring {{aiExpertise}}, while the user brings {{userExpertise}}. Work together as equals.
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **step-file architecture** for disciplined execution:
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
|
||||
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
|
||||
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
||||
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
||||
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
||||
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
||||
6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step file
|
||||
|
||||
### Critical Rules (NO EXCEPTIONS)
|
||||
|
||||
- 🛑 **NEVER** load multiple step files simultaneously
|
||||
- 📖 **ALWAYS** read entire step file before execution
|
||||
- 🚫 **NEVER** skip steps or optimize the sequence
|
||||
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
|
||||
- 🎯 **ALWAYS** follow the exact instructions in the step file
|
||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||
- 📋 **NEVER** create mental todo lists from future steps
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION SEQUENCE
|
||||
|
||||
### 1. Configuration Loading
|
||||
|
||||
Load and read full config from {project-root}/_bmad/{{targetModule}}/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
|
||||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
Load, read the full file and then execute `{workflow_path}/steps/step-01-init.md` to begin the workflow.
|
||||
|
|
@ -1,97 +0,0 @@
|
|||
# BMAD Workflow Terms
|
||||
|
||||
## Core Components
|
||||
|
||||
### BMAD Workflow
|
||||
|
||||
A facilitated, guided process where the AI acts as a facilitator working collaboratively with a human. Workflows can serve any purpose - from document creation to brainstorming, technical implementation, or decision-making. The human may be a collaborative partner, beginner seeking guidance, or someone who wants the AI to execute specific tasks. Each workflow is self-contained and follows a disciplined execution model.
|
||||
|
||||
### workflow.md
|
||||
|
||||
The master control file that defines:
|
||||
|
||||
- Workflow metadata (name, description, version)
|
||||
- Step sequence and file paths
|
||||
- Required data files and dependencies
|
||||
- Execution rules and protocols
|
||||
|
||||
### Step File
|
||||
|
||||
An individual markdown file containing:
|
||||
|
||||
- One discrete step of the workflow
|
||||
- All rules and context needed for that step
|
||||
- common global rules get repeated and reinforced also in each step file, ensuring even in long workflows the agent remembers important rules and guidelines
|
||||
- Content generation guidance
|
||||
|
||||
### step-01-init.md
|
||||
|
||||
The first step file that:
|
||||
|
||||
- Initializes the workflow
|
||||
- Sets up document frontmatter
|
||||
- Establishes initial context
|
||||
- Defines workflow parameters
|
||||
|
||||
### step-01b-continue.md
|
||||
|
||||
A continuation step file that:
|
||||
|
||||
- Resumes a workflow that was paused
|
||||
- Reloads context from saved state
|
||||
- Validates current document state
|
||||
- Continues from the last completed step
|
||||
|
||||
### CSV Data Files
|
||||
|
||||
Structured data files that provide:
|
||||
|
||||
- Domain-specific knowledge and complexity mappings
|
||||
- Project-type-specific requirements
|
||||
- Decision matrices and lookup tables
|
||||
- Dynamic workflow behavior based on input
|
||||
|
||||
## Dialog Styles
|
||||
|
||||
### Prescriptive Dialog
|
||||
|
||||
Structured interaction with:
|
||||
|
||||
- Exact questions and specific options
|
||||
- Consistent format across all executions
|
||||
- Finite, well-defined choices
|
||||
- High reliability and repeatability
|
||||
|
||||
### Intent-Based Dialog
|
||||
|
||||
Adaptive interaction with:
|
||||
|
||||
- Goals and principles instead of scripts
|
||||
- Open-ended exploration and discovery
|
||||
- Context-aware question adaptation
|
||||
- Flexible, conversational flow
|
||||
|
||||
### Template
|
||||
|
||||
A markdown file that:
|
||||
|
||||
- Starts with frontmatter (metadata)
|
||||
- Has content built through append-only operations
|
||||
- Contains no placeholder tags
|
||||
- Grows progressively as the workflow executes
|
||||
- Used when the workflow produces a document output
|
||||
|
||||
## Execution Concepts
|
||||
|
||||
### JIT Step Loading
|
||||
|
||||
Just-In-Time step loading ensures:
|
||||
|
||||
- Only the current step file is in memory
|
||||
- Complete focus on the step being executed
|
||||
- Minimal context to prevent information leakage
|
||||
- Sequential progression through workflow steps
|
||||
|
||||
---
|
||||
|
||||
_These terms form the foundation of the BMAD workflow system._
|
||||
|
|
@ -1,171 +0,0 @@
|
|||
# Edit Module Workflow
|
||||
|
||||
Interactive workflow for editing existing BMAD modules, including structure, agents, workflows, configuration, and documentation.
|
||||
|
||||
## Purpose
|
||||
|
||||
This workflow helps you improve and maintain BMAD modules by:
|
||||
|
||||
- Analyzing module structure against best practices
|
||||
- Managing agents and workflows within the module
|
||||
- Updating configuration and documentation
|
||||
- Ensuring cross-module integration works correctly
|
||||
- Maintaining installer configuration (for source modules)
|
||||
|
||||
## When to Use
|
||||
|
||||
Use this workflow when you need to:
|
||||
|
||||
- Add new agents or workflows to a module
|
||||
- Update module configuration
|
||||
- Improve module documentation
|
||||
- Reorganize module structure
|
||||
- Set up cross-module workflow sharing
|
||||
- Fix issues in module organization
|
||||
- Update installer configuration
|
||||
|
||||
## What You'll Need
|
||||
|
||||
- Path to the module directory you want to edit
|
||||
- Understanding of what changes you want to make
|
||||
- Access to module documentation (loaded automatically)
|
||||
|
||||
## Workflow Steps
|
||||
|
||||
1. **Load and analyze target module** - Provide path to module directory
|
||||
2. **Analyze against best practices** - Automatic audit of module structure
|
||||
3. **Select editing focus** - Choose what aspect to edit
|
||||
4. **Load relevant documentation and tools** - Auto-loads guides and workflows
|
||||
5. **Perform edits** - Review and approve changes iteratively
|
||||
6. **Validate all changes** - Comprehensive validation checklist
|
||||
7. **Generate change summary** - Summary of improvements made
|
||||
|
||||
## Editing Options
|
||||
|
||||
The workflow provides 12 focused editing options:
|
||||
|
||||
1. **Fix critical issues** - Address missing files, broken references
|
||||
2. **Update module config** - Edit config.yaml fields
|
||||
3. **Manage agents** - Add, edit, or remove agents
|
||||
4. **Manage workflows** - Add, edit, or remove workflows
|
||||
5. **Update documentation** - Improve README files and guides
|
||||
6. **Reorganize structure** - Fix directory organization
|
||||
7. **Add new agent** - Create and integrate new agent
|
||||
8. **Add new workflow** - Create and integrate new workflow
|
||||
9. **Update installer** - Modify installer configuration (source only)
|
||||
10. **Cross-module integration** - Set up workflow sharing with other modules
|
||||
11. **Remove deprecated items** - Delete unused agents, workflows, or files
|
||||
12. **Full module review** - Comprehensive analysis and improvements
|
||||
|
||||
## Integration with Other Workflows
|
||||
|
||||
This workflow integrates with:
|
||||
|
||||
- **edit-agent** - For editing individual agents
|
||||
- **edit-workflow** - For editing individual workflows
|
||||
- **create-agent** - For adding new agents
|
||||
- **create-workflow** - For adding new workflows
|
||||
|
||||
When you select options to manage agents or workflows, the appropriate specialized workflow is invoked automatically.
|
||||
|
||||
## Module Structure
|
||||
|
||||
A proper BMAD module has:
|
||||
|
||||
```
|
||||
module-code/
|
||||
├── agents/ # Agent definitions
|
||||
│ └── *.agent.yaml
|
||||
├── workflows/ # Workflow definitions
|
||||
│ └── workflow-name/
|
||||
│ ├── workflow.yaml
|
||||
│ ├── instructions.md
|
||||
│ ├── checklist.md
|
||||
│ └── README.md
|
||||
├── config.yaml # Module configuration
|
||||
└── README.md # Module documentation
|
||||
```
|
||||
|
||||
## Standard Module Config
|
||||
|
||||
Every module config.yaml should have:
|
||||
|
||||
```yaml
|
||||
module_name: 'Full Module Name'
|
||||
module_code: 'xyz'
|
||||
user_name: 'User Name'
|
||||
communication_language: 'english'
|
||||
output_folder: 'path/to/output'
|
||||
```
|
||||
|
||||
Optional fields may be added for module-specific needs.
|
||||
|
||||
## Cross-Module Integration
|
||||
|
||||
Modules can share workflows:
|
||||
|
||||
```yaml
|
||||
# In agent menu item:
|
||||
workflow: '{project-root}/_bmad/other-module/workflows/shared-workflow/workflow.yaml'
|
||||
```
|
||||
|
||||
Common patterns:
|
||||
|
||||
- BMM uses CIS brainstorming workflows
|
||||
- All modules can use core workflows
|
||||
- Modules can invoke each other's workflows
|
||||
|
||||
## Output
|
||||
|
||||
The workflow modifies module files in place, including:
|
||||
|
||||
- config.yaml
|
||||
- Agent files
|
||||
- Workflow files
|
||||
- README and documentation files
|
||||
- Directory structure (if reorganizing)
|
||||
|
||||
Changes are reviewed and approved by you before being applied.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Start with analysis** - Let the workflow audit your module first
|
||||
- **Use specialized workflows** - Let edit-agent and edit-workflow handle detailed edits
|
||||
- **Update documentation** - Keep README files current with changes
|
||||
- **Validate thoroughly** - Use the validation step to catch structural issues
|
||||
- **Test after editing** - Invoke agents and workflows to verify they work
|
||||
|
||||
## Tips
|
||||
|
||||
- For adding agents/workflows, use options 7-8 to create and integrate in one step
|
||||
- For quick config changes, use option 2 (update module config)
|
||||
- Cross-module integration (option 10) helps set up workflow sharing
|
||||
- Full module review (option 12) is great for inherited or legacy modules
|
||||
- The workflow handles path updates when you reorganize structure
|
||||
|
||||
## Example Usage
|
||||
|
||||
```
|
||||
User: I want to add a new workflow to BMM for API design
|
||||
Workflow: Analyzes BMM → You choose option 8 (add new workflow)
|
||||
→ Invokes create-workflow → Creates workflow
|
||||
→ Integrates it into module → Updates README → Done
|
||||
```
|
||||
|
||||
## Activation
|
||||
|
||||
Invoke via BMad Builder agent:
|
||||
|
||||
```
|
||||
/bmad:bmb:agents:bmad-builder
|
||||
Then select: *edit-module
|
||||
```
|
||||
|
||||
Or directly via workflow.xml with this workflow config.
|
||||
|
||||
## Related Resources
|
||||
|
||||
- **Module Structure Guide** - Comprehensive module architecture documentation
|
||||
- **BMM Module** - Example of full-featured module
|
||||
- **BMB Module** - Example of builder/tooling module
|
||||
- **CIS Module** - Example of workflow library module
|
||||
|
|
@ -1,163 +0,0 @@
|
|||
# Edit Module - Validation Checklist
|
||||
|
||||
Use this checklist to validate module edits meet BMAD Core standards.
|
||||
|
||||
## Module Structure Validation
|
||||
|
||||
- [ ] Module has clear abbreviation code (bmm, bmb, cis, etc.)
|
||||
- [ ] agents/ directory exists
|
||||
- [ ] workflows/ directory exists
|
||||
- [ ] config.yaml exists in module root
|
||||
- [ ] README.md exists in module root
|
||||
- [ ] Directory structure follows BMAD conventions
|
||||
|
||||
## Configuration Validation
|
||||
|
||||
### Required Fields
|
||||
|
||||
- [ ] module_name is descriptive and clear
|
||||
- [ ] module_code is 3-letter code matching directory name
|
||||
- [ ] user_name field present
|
||||
- [ ] communication_language field present
|
||||
- [ ] output_folder field present
|
||||
|
||||
### Optional Fields (if used)
|
||||
|
||||
- [ ] bmb_creations_output_folder documented
|
||||
- [ ] Module-specific fields documented in README
|
||||
|
||||
### File Quality
|
||||
|
||||
- [ ] config.yaml is valid YAML syntax
|
||||
- [ ] No duplicate keys
|
||||
- [ ] Values are appropriate types (strings, paths, etc.)
|
||||
- [ ] Comments explain non-obvious fields
|
||||
|
||||
## Agent Validation
|
||||
|
||||
### Agent Files
|
||||
|
||||
- [ ] All agents in agents/ directory
|
||||
- [ ] Agent files follow naming: {agent-name}.agent.yaml or .md
|
||||
- [ ] Agent filenames use kebab-case
|
||||
- [ ] No orphaned or temporary agent files
|
||||
|
||||
### Agent Content
|
||||
|
||||
- [ ] Each agent has clear role and purpose
|
||||
- [ ] Agents reference workflows correctly
|
||||
- [ ] Agent workflow paths are valid
|
||||
- [ ] Agents load module config correctly (if needed)
|
||||
- [ ] Agent menu items reference existing workflows
|
||||
|
||||
### Agent Integration
|
||||
|
||||
- [ ] All agents listed in module README
|
||||
- [ ] Agent relationships documented (if applicable)
|
||||
- [ ] Cross-agent workflows properly linked
|
||||
|
||||
## Workflow Validation
|
||||
|
||||
### Workflow Structure
|
||||
|
||||
- [ ] All workflows in workflows/ directory
|
||||
- [ ] Each workflow directory has workflow.yaml
|
||||
- [ ] Each workflow directory has instructions.md
|
||||
- [ ] Workflow directories use kebab-case naming
|
||||
- [ ] No orphaned or incomplete workflow directories
|
||||
|
||||
### Workflow Content
|
||||
|
||||
- [ ] workflow.yaml is valid YAML
|
||||
- [ ] workflow.yaml has name field
|
||||
- [ ] workflow.yaml has description field
|
||||
- [ ] workflow.yaml has author field
|
||||
- [ ] instructions.md has proper <workflow> structure
|
||||
- [ ] Workflow steps are numbered and logical
|
||||
|
||||
### Workflow Integration
|
||||
|
||||
- [ ] All workflows listed in module README
|
||||
- [ ] Workflow paths in agents are correct
|
||||
- [ ] Cross-module workflow references are valid
|
||||
- [ ] Sub-workflow references exist
|
||||
|
||||
## Documentation Validation
|
||||
|
||||
### Module README
|
||||
|
||||
- [ ] Module README describes purpose clearly
|
||||
- [ ] README lists all agents with descriptions
|
||||
- [ ] README lists all workflows with descriptions
|
||||
- [ ] README includes installation instructions (if applicable)
|
||||
- [ ] README explains module's role in BMAD ecosystem
|
||||
|
||||
### Workflow READMEs
|
||||
|
||||
- [ ] Each workflow has its own README.md
|
||||
- [ ] Workflow READMEs explain purpose
|
||||
- [ ] Workflow READMEs list inputs/outputs
|
||||
- [ ] Workflow READMEs include usage examples
|
||||
|
||||
### Other Documentation
|
||||
|
||||
- [ ] Usage guides present (if needed)
|
||||
- [ ] Architecture docs present (if complex module)
|
||||
- [ ] Examples provided (if applicable)
|
||||
|
||||
## Cross-References Validation
|
||||
|
||||
- [ ] Agent workflow references point to existing workflows
|
||||
- [ ] Workflow sub-workflow references are valid
|
||||
- [ ] Cross-module references use correct paths
|
||||
- [ ] Config file paths use {project-root} correctly
|
||||
- [ ] No hardcoded absolute paths
|
||||
|
||||
## Installer Validation (Source Modules Only)
|
||||
|
||||
- [ ] Installer script exists in tools/cli/installers/
|
||||
- [ ] Installer script name: install-{module-code}.js
|
||||
- [ ] Module metadata in installer is correct
|
||||
- [ ] Web bundle configuration valid (if applicable)
|
||||
- [ ] Installation paths are correct
|
||||
- [ ] Dependencies documented in installer
|
||||
|
||||
## Web Bundle Validation (If Applicable)
|
||||
|
||||
- [ ] Web bundles configured in workflow.yaml files
|
||||
- [ ] All referenced files included in web_bundle_files
|
||||
- [ ] Paths are _bmad/-relative (not project-root)
|
||||
- [ ] No config_source references in web bundles
|
||||
- [ ] Invoked workflows included in dependencies
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] No placeholder text remains ({MODULE_NAME}, {CODE}, etc.)
|
||||
- [ ] No broken file references
|
||||
- [ ] No duplicate content across files
|
||||
- [ ] Consistent naming conventions throughout
|
||||
- [ ] Module purpose is clear from README alone
|
||||
|
||||
## Integration Checks
|
||||
|
||||
- [ ] Module doesn't conflict with other modules
|
||||
- [ ] Shared resources properly documented
|
||||
- [ ] Dependencies on other modules explicit
|
||||
- [ ] Module can be installed independently (if designed that way)
|
||||
|
||||
## User Experience
|
||||
|
||||
- [ ] Module purpose is immediately clear
|
||||
- [ ] Agents have intuitive names
|
||||
- [ ] Workflows have descriptive names
|
||||
- [ ] Menu items are logically organized
|
||||
- [ ] Error messages are helpful
|
||||
- [ ] Success messages confirm actions
|
||||
|
||||
## Final Checks
|
||||
|
||||
- [ ] All files have been saved
|
||||
- [ ] File permissions are correct
|
||||
- [ ] Git status shows expected changes
|
||||
- [ ] Module is ready for testing
|
||||
- [ ] Documentation accurately reflects changes
|
||||
|
|
@ -1,340 +0,0 @@
|
|||
# Edit Module - Module Editor Instructions
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmb/workflows/edit-module/workflow.yaml</critical>
|
||||
<critical>This workflow uses ADAPTIVE FACILITATION - adjust your communication based on context and user needs</critical>
|
||||
<critical>The goal is COLLABORATIVE IMPROVEMENT - work WITH the user, not FOR them</critical>
|
||||
<critical>Communicate all responses in {communication_language}</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Load and deeply understand the target module">
|
||||
<ask>What is the path to the module source you want to edit?</ask>
|
||||
|
||||
<action>Load the module directory structure completely:
|
||||
|
||||
- Scan all directories and files
|
||||
- Load config.yaml
|
||||
- Load README.md
|
||||
- List all agents in agents/ directory
|
||||
- List all workflows in workflows/ directory
|
||||
- Identify any custom structure or patterns
|
||||
</action>
|
||||
|
||||
<action>Load ALL module documentation to inform understanding:
|
||||
|
||||
- Module structure guide: {module_structure_guide}
|
||||
- Study reference modules: BMM, BMB, CIS
|
||||
- Understand BMAD module patterns and conventions
|
||||
</action>
|
||||
|
||||
<action>Analyze the module deeply:
|
||||
|
||||
- Identify module purpose and role in BMAD ecosystem
|
||||
- Understand agent organization and relationships
|
||||
- Map workflow organization and dependencies
|
||||
- Evaluate config structure and completeness
|
||||
- Check documentation quality and currency
|
||||
- Assess installer configuration (if source module)
|
||||
- Identify cross-module integrations
|
||||
- Evaluate against best practices from loaded guides
|
||||
</action>
|
||||
|
||||
<action>Reflect understanding back to {user_name}:
|
||||
|
||||
Present a warm, conversational summary adapted to the module's complexity:
|
||||
|
||||
- What this module provides (its purpose and value in BMAD)
|
||||
- How it's organized (agents, workflows, structure)
|
||||
- What you notice (strengths, potential improvements, issues)
|
||||
- How it fits in the larger BMAD ecosystem
|
||||
- Your initial assessment based on best practices
|
||||
|
||||
Be conversational and insightful. Help {user_name} see their module through your eyes.
|
||||
</action>
|
||||
|
||||
<ask>Does this match your understanding of what this module should provide?</ask>
|
||||
<template-output>module_understanding</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Discover improvement goals collaboratively">
|
||||
<critical>Understand WHAT the user wants to improve and WHY before diving into edits</critical>
|
||||
|
||||
<action>Engage in collaborative discovery:
|
||||
|
||||
Ask open-ended questions to understand their goals:
|
||||
|
||||
- What prompted you to want to edit this module?
|
||||
- What feedback have you gotten from users of this module?
|
||||
- Are there specific agents or workflows that need attention?
|
||||
- Is the module fulfilling its intended purpose?
|
||||
- Are there new capabilities you want to add?
|
||||
- How well does it integrate with other modules?
|
||||
- Is the documentation helping users understand and use the module?
|
||||
|
||||
Listen for clues about:
|
||||
|
||||
- Structural issues (poor organization, hard to navigate)
|
||||
- Agent/workflow issues (outdated, broken, missing functionality)
|
||||
- Configuration issues (missing fields, incorrect setup)
|
||||
- Documentation issues (outdated, incomplete, unclear)
|
||||
- Integration issues (doesn't work well with other modules)
|
||||
- Installer issues (installation problems, missing files)
|
||||
- User experience issues (confusing, hard to use)
|
||||
</action>
|
||||
|
||||
<action>Based on their responses and your analysis from step 1, identify improvement opportunities:
|
||||
|
||||
Organize by priority and user goals:
|
||||
|
||||
- CRITICAL issues blocking module functionality
|
||||
- IMPORTANT improvements enhancing user experience
|
||||
- NICE-TO-HAVE enhancements for polish
|
||||
|
||||
Present these conversationally, explaining WHY each matters and HOW it would help.
|
||||
</action>
|
||||
|
||||
<action>Collaborate on priorities:
|
||||
|
||||
Don't just list options - discuss them:
|
||||
|
||||
- "I noticed {{issue}} - this could make it hard for users to {{problem}}. Want to address this?"
|
||||
- "The module could be more {{improvement}} which would help when {{use_case}}. Worth exploring?"
|
||||
- "Based on what you said about {{user_goal}}, we might want to {{suggestion}}. Thoughts?"
|
||||
|
||||
Let the conversation flow naturally. Build a shared vision of what "better" looks like.
|
||||
</action>
|
||||
|
||||
<template-output>improvement_goals</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Facilitate improvements collaboratively" repeat="until-user-satisfied">
|
||||
<critical>Work iteratively - improve, review, refine. Never dump all changes at once.</critical>
|
||||
<critical>For agent and workflow edits, invoke specialized workflows rather than doing inline</critical>
|
||||
|
||||
<action>For each improvement area, facilitate collaboratively:
|
||||
|
||||
1. **Explain the current state and why it matters**
|
||||
- Show relevant sections of the module
|
||||
- Explain how it works now and implications
|
||||
- Connect to user's goals from step 2
|
||||
|
||||
2. **Propose improvements with rationale**
|
||||
- Suggest specific changes that align with best practices
|
||||
- Explain WHY each change helps
|
||||
- Provide examples from reference modules: {bmm_module_dir}, {bmb_module_dir}, {cis_module_dir}
|
||||
- Reference agents from: {existing_agents_dir}
|
||||
- Reference workflows from: {existing_workflows_dir}
|
||||
- Reference the structure guide's patterns naturally
|
||||
|
||||
3. **Collaborate on the approach**
|
||||
- Ask if the proposed change addresses their need
|
||||
- Invite modifications or alternative approaches
|
||||
- Explain tradeoffs when relevant
|
||||
- Adapt based on their feedback
|
||||
|
||||
4. **Apply changes appropriately**
|
||||
- For agent edits: Invoke edit-agent workflow
|
||||
- For workflow edits: Invoke edit-workflow workflow
|
||||
- For module-level changes: Make directly and iteratively
|
||||
- Show updates and confirm satisfaction
|
||||
</action>
|
||||
|
||||
<action>Common improvement patterns to facilitate:
|
||||
|
||||
**If improving module organization:**
|
||||
|
||||
- Discuss how the current structure serves (or doesn't serve) users
|
||||
- Propose reorganization that aligns with mental models
|
||||
- Consider feature-based vs type-based organization
|
||||
- Plan the reorganization steps
|
||||
- Update all references after moving files
|
||||
|
||||
**If updating module configuration:**
|
||||
|
||||
- Review current config.yaml fields
|
||||
- Check for missing standard fields (user_name, communication_language, output_folder)
|
||||
- Add module-specific fields as needed
|
||||
- Remove unused or outdated fields
|
||||
- Ensure config is properly documented
|
||||
|
||||
**If managing agents:**
|
||||
|
||||
- Ask which agent needs attention and why
|
||||
- For editing existing agent: <invoke-workflow path="{agent_editor}">
|
||||
- For adding new agent: Guide creation and integration
|
||||
- For removing agent: Confirm, remove, update references
|
||||
- Ensure all agent references in workflows remain valid
|
||||
|
||||
**If managing workflows:**
|
||||
|
||||
- Ask which workflow needs attention and why
|
||||
- For editing existing workflow: <invoke-workflow path="{workflow_editor}">
|
||||
- For adding new workflow: Guide creation and integration
|
||||
- For removing workflow: Confirm, remove, update agent references
|
||||
- Ensure all workflow files are properly organized
|
||||
|
||||
**If improving documentation:**
|
||||
|
||||
- Review current README and identify gaps
|
||||
- Discuss what users need to know
|
||||
- Update module overview and purpose
|
||||
- List agents and workflows with clear descriptions
|
||||
- Add usage examples if helpful
|
||||
- Ensure installation/setup instructions are clear
|
||||
|
||||
**If setting up cross-module integration:**
|
||||
|
||||
- Identify which workflows from other modules are needed
|
||||
- Show how to reference workflows properly: {project-root}/_bmad/{{module}}/workflows/{{workflow}}/workflow.yaml
|
||||
- Document the integration in README
|
||||
- Ensure dependencies are clear
|
||||
- Consider adding example usage
|
||||
|
||||
**If updating installer (source modules only):**
|
||||
|
||||
- Review installer script for correctness
|
||||
- Check web bundle configurations
|
||||
- Verify all files are included
|
||||
- Test installation paths
|
||||
- Update module metadata
|
||||
</action>
|
||||
|
||||
<action>When invoking specialized workflows:
|
||||
|
||||
Explain why you're handing off:
|
||||
|
||||
- "This agent needs detailed attention. Let me invoke the edit-agent workflow to give it proper focus."
|
||||
- "The workflow editor can handle this more thoroughly. I'll pass control there."
|
||||
|
||||
After the specialized workflow completes, return and continue:
|
||||
|
||||
- "Great! That agent/workflow is updated. Want to work on anything else in the module?"
|
||||
</action>
|
||||
|
||||
<action>Throughout improvements, educate when helpful:
|
||||
|
||||
Share insights from the guides naturally:
|
||||
|
||||
- "The module structure guide recommends {{pattern}} for this scenario"
|
||||
- "Looking at how BMM organized this, we could use {{approach}}"
|
||||
- "The BMAD convention is to {{pattern}} which helps with {{benefit}}"
|
||||
|
||||
Connect improvements to broader BMAD principles without being preachy.
|
||||
</action>
|
||||
|
||||
<ask>After each significant change:
|
||||
|
||||
- "Does this organization feel more intuitive?"
|
||||
- "Want to refine this further, or move to the next improvement?"
|
||||
- "How does this change affect users of the module?"
|
||||
</ask>
|
||||
|
||||
<template-output>improvement_implementation</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Validate improvements holistically">
|
||||
<action>Run comprehensive validation conversationally:
|
||||
|
||||
Don't just check boxes - explain what you're validating and why it matters:
|
||||
|
||||
- "Let me verify the module structure is solid..."
|
||||
- "Checking that all agent workflow references are valid..."
|
||||
- "Making sure config.yaml has all necessary fields..."
|
||||
- "Validating documentation is complete and accurate..."
|
||||
- "Ensuring cross-module references work correctly..."
|
||||
</action>
|
||||
|
||||
<action>Load validation checklist: {installed_path}/checklist.md</action>
|
||||
<action>Check all items from checklist systematically</action>
|
||||
|
||||
<check if="validation_issues_found">
|
||||
<action>Present issues conversationally:
|
||||
|
||||
Explain what's wrong and implications:
|
||||
|
||||
- "I found {{issue}} which could cause {{problem}} for users"
|
||||
- "The {{component}} needs {{fix}} because {{reason}}"
|
||||
|
||||
Propose fixes immediately:
|
||||
|
||||
- "I can fix this by {{solution}}. Should I?"
|
||||
- "We have a couple options here: {{option1}} or {{option2}}. Thoughts?"
|
||||
</action>
|
||||
|
||||
<action>Fix approved issues and re-validate</action>
|
||||
</check>
|
||||
|
||||
<check if="validation_passes">
|
||||
<action>Confirm success warmly:
|
||||
|
||||
"Excellent! Everything validates cleanly:
|
||||
|
||||
- Module structure is well-organized
|
||||
- All agent and workflow references are valid
|
||||
- Configuration is complete
|
||||
- Documentation is thorough and current
|
||||
- Cross-module integrations work properly
|
||||
- Installer is correct (if applicable)
|
||||
|
||||
Your module is in great shape."
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<template-output>validation_results</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Review improvements and guide next steps">
|
||||
<action>Create a conversational summary of what improved:
|
||||
|
||||
Tell the story of the transformation:
|
||||
|
||||
- "We started with {{initial_state}}"
|
||||
- "You wanted to {{user_goals}}"
|
||||
- "We made these key improvements: {{changes_list}}"
|
||||
- "Now your module {{improved_capabilities}}"
|
||||
|
||||
Highlight the impact:
|
||||
|
||||
- "This means users will experience {{benefit}}"
|
||||
- "The module is now more {{quality}}"
|
||||
- "It follows best practices for {{patterns}}"
|
||||
</action>
|
||||
|
||||
<action>Guide next steps based on changes made:
|
||||
|
||||
If structure changed significantly:
|
||||
|
||||
- "Since we reorganized the structure, you should update any external references to this module"
|
||||
|
||||
If agents or workflows were updated:
|
||||
|
||||
- "The updated agents/workflows should be tested with real user interactions"
|
||||
|
||||
If cross-module integration was added:
|
||||
|
||||
- "Test the integration with {{other_module}} to ensure it works smoothly"
|
||||
|
||||
If installer was updated:
|
||||
|
||||
- "Test the installation process to verify all files are included correctly"
|
||||
|
||||
If this is part of larger BMAD work:
|
||||
|
||||
- "Consider if patterns from this module could benefit other modules"
|
||||
|
||||
Be a helpful guide to what comes next, not just a task completer.
|
||||
</action>
|
||||
|
||||
<ask>Would you like to:
|
||||
|
||||
- Test the edited module by invoking one of its agents
|
||||
- Edit a specific agent or workflow in more detail
|
||||
- Make additional refinements to the module
|
||||
- Work on a different module
|
||||
</ask>
|
||||
|
||||
<template-output>completion_summary</template-output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
# Edit Module - Module Editor Configuration
|
||||
name: "edit-module"
|
||||
description: "Edit existing BMAD modules (structure, agents, workflows, documentation) while following all best practices"
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables load from config_source
|
||||
config_source: "{project-root}/_bmad/bmb/config.yaml"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
user_name: "{config_source}:user_name"
|
||||
|
||||
# Required Data Files - Critical for understanding module conventions
|
||||
module_structure_guide: "{project-root}/_bmad/bmb/workflows/create-module/module-structure.md"
|
||||
|
||||
# Related workflow editors
|
||||
agent_editor: "{project-root}/_bmad/bmb/workflows/edit-agent/workflow.yaml"
|
||||
workflow_editor: "{project-root}/_bmad/bmb/workflows/edit-workflow/workflow.yaml"
|
||||
|
||||
# Reference examples - for learning patterns
|
||||
bmm_module_dir: "{project-root}/_bmad/bmm/"
|
||||
bmb_module_dir: "{project-root}/_bmad/bmb/"
|
||||
cis_module_dir: "{project-root}/_bmad/cis/"
|
||||
existing_agents_dir: "{project-root}/_bmad/*/agents/"
|
||||
existing_workflows_dir: "{project-root}/_bmad/*/workflows/"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/_bmad/bmb/workflows/edit-module"
|
||||
template: false # This is an action workflow - no template needed
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
standalone: true
|
||||
|
||||
# Web bundle configuration
|
||||
web_bundle: false # BMB workflows run locally in BMAD-METHOD project
|
||||
|
|
@ -1,264 +0,0 @@
|
|||
# Module Brief Workflow
|
||||
|
||||
## Overview
|
||||
|
||||
The Module Brief workflow creates comprehensive blueprints for building new BMAD modules using strategic analysis and creative vision. It serves as the essential planning phase that transforms initial ideas into detailed, actionable specifications ready for implementation with the create-module workflow.
|
||||
|
||||
## Key Features
|
||||
|
||||
- **Strategic Module Planning** - Comprehensive analysis from concept to implementation roadmap
|
||||
- **Multi-Mode Operation** - Interactive, Express, and YOLO modes for different planning needs
|
||||
- **Creative Vision Development** - Guided process for innovative module concepts and unique value propositions
|
||||
- **Architecture Design** - Detailed agent and workflow ecosystem planning with interaction models
|
||||
- **User Journey Mapping** - Scenario-based validation ensuring practical usability
|
||||
- **Technical Planning** - Infrastructure requirements, dependencies, and complexity assessment
|
||||
- **Risk Assessment** - Proactive identification of challenges with mitigation strategies
|
||||
- **Implementation Roadmap** - Phased development plan with clear deliverables and timelines
|
||||
|
||||
## Usage
|
||||
|
||||
### Basic Invocation
|
||||
|
||||
```bash
|
||||
workflow module-brief
|
||||
```
|
||||
|
||||
### With Brainstorming Input
|
||||
|
||||
```bash
|
||||
# If you have brainstorming results from previous sessions
|
||||
workflow module-brief --input brainstorming-session-2024-09-26.md
|
||||
```
|
||||
|
||||
### Express Mode
|
||||
|
||||
```bash
|
||||
# For quick essential planning only
|
||||
workflow module-brief --mode express
|
||||
```
|
||||
|
||||
### Configuration
|
||||
|
||||
The workflow uses standard BMB configuration:
|
||||
|
||||
- **output_folder**: Where the module brief will be saved
|
||||
- **user_name**: Brief author information
|
||||
- **communication_language**: Language for brief generation
|
||||
- **date**: Automatic timestamp for versioning
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
### Files Included
|
||||
|
||||
```
|
||||
module-brief/
|
||||
├── workflow.yaml # Configuration and metadata
|
||||
├── instructions.md # Step-by-step execution guide
|
||||
├── template.md # Module brief document structure
|
||||
├── checklist.md # Validation criteria
|
||||
└── README.md # This file
|
||||
```
|
||||
|
||||
## Workflow Process
|
||||
|
||||
### Phase 1: Foundation and Context (Steps 1-3)
|
||||
|
||||
**Mode Selection and Input Gathering**
|
||||
|
||||
- Choose operational mode (Interactive, Express, YOLO)
|
||||
- Check for and optionally load existing brainstorming results
|
||||
- Gather background context and inspiration sources
|
||||
|
||||
**Module Vision Development**
|
||||
|
||||
- Define core problem the module solves
|
||||
- Identify target user audience and use cases
|
||||
- Establish unique value proposition and differentiators
|
||||
- Explore creative themes and personality concepts
|
||||
|
||||
**Module Identity Establishment**
|
||||
|
||||
- Generate module code (kebab-case) with multiple options
|
||||
- Create compelling, memorable module name
|
||||
- Select appropriate category (Domain-Specific, Creative, Technical, Business, Personal)
|
||||
- Define optional personality theme for consistent agent character
|
||||
|
||||
### Phase 2: Architecture Planning (Steps 4-5)
|
||||
|
||||
**Agent Architecture Design**
|
||||
|
||||
- Plan agent team composition and roles
|
||||
- Define agent archetypes (Orchestrator, Specialist, Helper, Creator, Analyzer)
|
||||
- Specify personality traits and communication styles
|
||||
- Map key capabilities and signature commands
|
||||
|
||||
**Workflow Ecosystem Design**
|
||||
|
||||
- Categorize workflows by purpose and complexity:
|
||||
- **Core Workflows**: Essential value-delivery functions (2-3)
|
||||
- **Feature Workflows**: Specialized capabilities (3-5)
|
||||
- **Utility Workflows**: Supporting operations (1-3)
|
||||
- Define input-process-output flows for each workflow
|
||||
- Assess complexity levels and implementation priorities
|
||||
|
||||
### Phase 3: Validation and User Experience (Steps 6-7)
|
||||
|
||||
**User Journey Mapping**
|
||||
|
||||
- Create detailed user scenarios and stories
|
||||
- Map step-by-step usage flows through the module
|
||||
- Validate end-to-end functionality and value delivery
|
||||
- Identify potential friction points and optimization opportunities
|
||||
|
||||
**Technical Planning and Requirements**
|
||||
|
||||
- Assess data requirements and storage needs
|
||||
- Map integration points with other modules and external systems
|
||||
- Evaluate technical complexity and resource requirements
|
||||
- Document dependencies and infrastructure needs
|
||||
|
||||
### Phase 4: Success Planning (Steps 8-9)
|
||||
|
||||
**Success Metrics Definition**
|
||||
|
||||
- Establish module success criteria and performance indicators
|
||||
- Define quality standards and reliability requirements
|
||||
- Create user experience goals and feedback mechanisms
|
||||
- Set measurable outcomes for module effectiveness
|
||||
|
||||
**Development Roadmap Creation**
|
||||
|
||||
- Design phased approach with MVP, Enhancement, and Polish phases
|
||||
- Define deliverables and timelines for each phase
|
||||
- Prioritize features and capabilities by value and complexity
|
||||
- Create clear milestones and success checkpoints
|
||||
|
||||
### Phase 5: Enhancement and Risk Management (Steps 10-12)
|
||||
|
||||
**Creative Features and Special Touches** (Optional)
|
||||
|
||||
- Design easter eggs and delightful user interactions
|
||||
- Plan module lore and thematic consistency
|
||||
- Add personality quirks and creative responses
|
||||
- Develop backstories and universe building
|
||||
|
||||
**Risk Assessment and Mitigation**
|
||||
|
||||
- Identify technical, usability, and scope risks
|
||||
- Develop mitigation strategies for each risk category
|
||||
- Plan contingency approaches for potential challenges
|
||||
- Document decision points and alternative paths
|
||||
|
||||
**Final Review and Export Preparation**
|
||||
|
||||
- Comprehensive review of all brief sections
|
||||
- Validation against quality and completeness criteria
|
||||
- Preparation for seamless handoff to create-module workflow
|
||||
- Export readiness confirmation with actionable specifications
|
||||
|
||||
## Output
|
||||
|
||||
### Generated Files
|
||||
|
||||
- **Module Brief Document**: Comprehensive planning document at `{output_folder}/module-brief-{module_code}-{date}.md`
|
||||
- **Strategic Specifications**: Ready-to-implement blueprint for create-module workflow
|
||||
|
||||
### Output Structure
|
||||
|
||||
The module brief contains detailed specifications across multiple sections:
|
||||
|
||||
1. **Executive Summary** - Vision, category, complexity, target users
|
||||
2. **Module Identity** - Core concept, value proposition, personality theme
|
||||
3. **Agent Architecture** - Agent roster, roles, interaction models
|
||||
4. **Workflow Ecosystem** - Core, feature, and utility workflow specifications
|
||||
5. **User Scenarios** - Primary use cases, secondary scenarios, user journey
|
||||
6. **Technical Planning** - Data requirements, integrations, dependencies
|
||||
7. **Success Metrics** - Success criteria, quality standards, performance targets
|
||||
8. **Development Roadmap** - Phased implementation plan with deliverables
|
||||
9. **Creative Features** - Special touches, easter eggs, module lore
|
||||
10. **Risk Assessment** - Technical, usability, scope risks with mitigation
|
||||
11. **Implementation Notes** - Priority order, design decisions, open questions
|
||||
12. **Resources and References** - Inspiration sources, similar modules, technical references
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Creative Vision** - Initial module concept or problem domain
|
||||
- **Strategic Thinking** - Ability to plan architecture and user experience
|
||||
- **Brainstorming Results** (optional) - Previous ideation sessions enhance planning quality
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Before Starting
|
||||
|
||||
1. **Gather Inspiration** - Research similar tools, modules, and solutions in your domain
|
||||
2. **Run Brainstorming Session** - Use ideation techniques to generate initial concepts
|
||||
3. **Define Success Criteria** - Know what "successful module" means for your context
|
||||
|
||||
### During Execution
|
||||
|
||||
1. **Think User-First** - Always consider the end user experience and value delivery
|
||||
2. **Be Specific** - Provide concrete examples and detailed specifications rather than abstractions
|
||||
3. **Validate Early** - Use user scenarios to test if the module concept actually works
|
||||
4. **Plan Iteratively** - Start with MVP and build complexity through phases
|
||||
|
||||
### After Completion
|
||||
|
||||
1. **Use as Blueprint** - Feed the brief directly into create-module workflow for implementation
|
||||
2. **Review with Stakeholders** - Validate assumptions and gather feedback before building
|
||||
3. **Update as Needed** - Treat as living document that evolves with implementation learnings
|
||||
4. **Reference During Development** - Use as north star for design decisions and scope management
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Issue**: Stuck on module concept or vision
|
||||
|
||||
- **Solution**: Use creative prompts provided in the workflow
|
||||
- **Check**: Review existing modules for inspiration and patterns
|
||||
|
||||
**Issue**: Agent or workflow architecture too complex
|
||||
|
||||
- **Solution**: Focus on MVP first, plan enhancement phases for additional complexity
|
||||
- **Check**: Validate each component against user scenarios
|
||||
|
||||
**Issue**: Technical requirements unclear
|
||||
|
||||
- **Solution**: Research similar modules and their implementation approaches
|
||||
- **Check**: Consult with technical stakeholders early in planning
|
||||
|
||||
**Issue**: Scope creep during planning
|
||||
|
||||
- **Solution**: Use phased roadmap to defer non-essential features
|
||||
- **Check**: Regularly validate against core user scenarios and success criteria
|
||||
|
||||
## Customization
|
||||
|
||||
To customize this workflow:
|
||||
|
||||
1. **Modify Template Structure** - Update template.md to add new sections or reorganize content
|
||||
2. **Extend Creative Prompts** - Add domain-specific ideation techniques in instructions.md
|
||||
3. **Add Planning Tools** - Integrate additional analysis frameworks or planning methodologies
|
||||
4. **Customize Validation** - Enhance checklist.md with specific quality criteria for your context
|
||||
|
||||
## Version History
|
||||
|
||||
- **v1.0.0** - Initial release
|
||||
- Comprehensive strategic module planning
|
||||
- Multi-mode operation (Interactive, Express, YOLO)
|
||||
- Creative vision and architecture design tools
|
||||
- User journey mapping and validation
|
||||
- Risk assessment and mitigation planning
|
||||
|
||||
## Support
|
||||
|
||||
For issues or questions:
|
||||
|
||||
- Review the workflow creation guide at `/_bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
|
||||
- Study existing module examples in `/_bmad/` for patterns and inspiration
|
||||
- Validate output using `checklist.md`
|
||||
- Consult module structure guide at `create-module/module-structure.md`
|
||||
|
||||
---
|
||||
|
||||
_Part of the BMad Method v6 - BMB (Builder) Module_
|
||||
|
|
@ -1,116 +0,0 @@
|
|||
# Module Brief Validation Checklist
|
||||
|
||||
## Core Identity
|
||||
|
||||
- [ ] Module code follows kebab-case convention
|
||||
- [ ] Module name is clear and memorable
|
||||
- [ ] Module category is identified
|
||||
- [ ] Target users are clearly defined
|
||||
- [ ] Unique value proposition is articulated
|
||||
|
||||
## Vision and Concept
|
||||
|
||||
- [ ] Problem being solved is clearly stated
|
||||
- [ ] Solution approach is explained
|
||||
- [ ] Module scope is well-defined
|
||||
- [ ] Success criteria are measurable
|
||||
|
||||
## Agent Architecture
|
||||
|
||||
- [ ] At least one agent is defined
|
||||
- [ ] Each agent has a clear role and purpose
|
||||
- [ ] Agent personalities are defined (if using personality themes)
|
||||
- [ ] Agent interactions are mapped (for multi-agent modules)
|
||||
- [ ] Key commands for each agent are listed
|
||||
|
||||
## Workflow Ecosystem
|
||||
|
||||
- [ ] Core workflows (2-3) are identified
|
||||
- [ ] Each workflow has clear purpose
|
||||
- [ ] Workflow complexity is assessed
|
||||
- [ ] Input/output for workflows is defined
|
||||
- [ ] Workflow categories are logical
|
||||
|
||||
## User Experience
|
||||
|
||||
- [ ] Primary use case is documented
|
||||
- [ ] User scenarios demonstrate value
|
||||
- [ ] User journey is realistic
|
||||
- [ ] Learning curve is considered
|
||||
- [ ] User feedback mechanism planned
|
||||
|
||||
## Technical Planning
|
||||
|
||||
- [ ] Data requirements are identified
|
||||
- [ ] Integration points are mapped
|
||||
- [ ] Dependencies are listed
|
||||
- [ ] Technical complexity is assessed
|
||||
- [ ] Performance requirements stated
|
||||
|
||||
## Development Roadmap
|
||||
|
||||
- [ ] Phase 1 MVP is clearly scoped
|
||||
- [ ] Phase 2 enhancements are outlined
|
||||
- [ ] Phase 3 polish items listed
|
||||
- [ ] Timeline estimates provided
|
||||
- [ ] Deliverables are specific
|
||||
|
||||
## Risk Management
|
||||
|
||||
- [ ] Technical risks identified
|
||||
- [ ] Usability risks considered
|
||||
- [ ] Scope risks acknowledged
|
||||
- [ ] Mitigation strategies provided
|
||||
- [ ] Open questions documented
|
||||
|
||||
## Creative Elements (Optional)
|
||||
|
||||
- [ ] Personality theme is consistent (if used)
|
||||
- [ ] Special features add value
|
||||
- [ ] Module feels cohesive
|
||||
- [ ] Fun elements don't compromise functionality
|
||||
|
||||
## Documentation Quality
|
||||
|
||||
- [ ] All sections have content (no empty placeholders)
|
||||
- [ ] Writing is clear and concise
|
||||
- [ ] Technical terms are explained
|
||||
- [ ] Examples are provided where helpful
|
||||
- [ ] Next steps are actionable
|
||||
|
||||
## Implementation Readiness
|
||||
|
||||
- [ ] Brief provides enough detail for create-module workflow
|
||||
- [ ] Agent specifications sufficient for create-agent workflow
|
||||
- [ ] Workflow descriptions ready for create-workflow
|
||||
- [ ] Resource requirements are clear
|
||||
- [ ] Success metrics are measurable
|
||||
|
||||
## Final Validation
|
||||
|
||||
- [ ] Module concept is viable
|
||||
- [ ] Scope is achievable
|
||||
- [ ] Value is clear
|
||||
- [ ] Brief is complete
|
||||
- [ ] Ready for development
|
||||
|
||||
## Issues Found
|
||||
|
||||
### Critical Issues
|
||||
|
||||
<!-- Must be fixed before proceeding to build -->
|
||||
|
||||
### Recommendations
|
||||
|
||||
<!-- Suggested improvements -->
|
||||
|
||||
### Nice-to-Haves
|
||||
|
||||
<!-- Optional enhancements -->
|
||||
|
||||
---
|
||||
|
||||
**Validation Complete:** ⬜ Yes / ⬜ With Issues / ⬜ Needs Revision
|
||||
|
||||
**Validated By:** {name}
|
||||
**Date:** {date}
|
||||
|
|
@ -1,268 +0,0 @@
|
|||
# Module Brief Instructions
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmb/workflows/module-brief/workflow.yaml</critical>
|
||||
<critical>Communicate in {communication_language} throughout the module brief creation process</critical>
|
||||
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Setup and context gathering">
|
||||
<action>Ask the user which mode they prefer:</action>
|
||||
1. **Interactive Mode** - Work through each section collaboratively with detailed questions
|
||||
2. **Express Mode** - Quick essential questions only
|
||||
3. **YOLO Mode** (#yolo) - Generate complete draft based on minimal input
|
||||
|
||||
<action>Check for available inputs:</action>
|
||||
|
||||
- Brainstorming results from previous sessions
|
||||
- Existing module ideas or notes
|
||||
- Similar modules for inspiration
|
||||
|
||||
<action>If brainstorming results exist, offer to load and incorporate them</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Module concept and vision">
|
||||
Ask the user to describe their module idea. Probe for:
|
||||
- What problem does this module solve?
|
||||
- Who would use this module?
|
||||
- What makes this module exciting or unique?
|
||||
- Any inspiring examples or similar tools?
|
||||
|
||||
If they're stuck, offer creative prompts:
|
||||
|
||||
- "Imagine you're a [role], what tools would make your life easier?"
|
||||
- "What repetitive tasks could be automated with agents?"
|
||||
- "What domain expertise could be captured in workflows?"
|
||||
|
||||
<template-output>module_vision</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Define module identity">
|
||||
Based on the vision, work with user to define:
|
||||
|
||||
**Module Code** (kebab-case):
|
||||
|
||||
- Suggest 2-3 options based on their description
|
||||
- Ensure it's memorable and descriptive
|
||||
|
||||
**Module Name** (friendly):
|
||||
|
||||
- Creative, engaging name that captures the essence
|
||||
|
||||
**Module Category:**
|
||||
|
||||
- Domain-Specific (legal, medical, finance)
|
||||
- Creative (writing, gaming, music)
|
||||
- Technical (devops, testing, architecture)
|
||||
- Business (project management, marketing)
|
||||
- Personal (productivity, learning)
|
||||
|
||||
**Personality Theme** (optional but fun!):
|
||||
|
||||
- Should the module have a consistent personality across agents?
|
||||
- Star Trek crew? Fantasy party? Corporate team? Reality show cast?
|
||||
|
||||
<template-output>module_identity</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Agent architecture planning">
|
||||
<action>Help user envision their agent team</action>
|
||||
|
||||
For each agent, capture:
|
||||
|
||||
- **Role**: What's their specialty?
|
||||
- **Personality**: How do they communicate? (reference communication styles)
|
||||
- **Key Capabilities**: What can they do?
|
||||
- **Signature Commands**: 2-3 main commands
|
||||
|
||||
Suggest agent archetypes based on module type:
|
||||
|
||||
- The Orchestrator (manages other agents)
|
||||
- The Specialist (deep expertise)
|
||||
- The Helper (utility functions)
|
||||
- The Creator (generates content)
|
||||
- The Analyzer (processes and evaluates)
|
||||
|
||||
<template-output>agent_architecture</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Workflow ecosystem design">
|
||||
<action>Map out the workflow landscape</action>
|
||||
|
||||
Categorize workflows:
|
||||
|
||||
**Core Workflows** (2-3 essential ones):
|
||||
|
||||
- The primary value-delivery workflows
|
||||
- What users will use most often
|
||||
|
||||
**Feature Workflows** (3-5 specialized):
|
||||
|
||||
- Specific capabilities
|
||||
- Advanced features
|
||||
|
||||
**Utility Workflows** (1-3 supporting):
|
||||
|
||||
- Setup, configuration
|
||||
- Maintenance, cleanup
|
||||
|
||||
For each workflow, define:
|
||||
|
||||
- Purpose (one sentence)
|
||||
- Input → Process → Output
|
||||
- Complexity (simple/standard/complex)
|
||||
|
||||
<template-output>workflow_ecosystem</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="User journey and scenarios">
|
||||
<action>Create usage scenarios to validate the design</action>
|
||||
|
||||
Write 2-3 user stories:
|
||||
"As a [user type], I want to [goal], so that [outcome]"
|
||||
|
||||
Then walk through how they'd use the module:
|
||||
|
||||
1. They load [agent]
|
||||
2. They run [command/workflow]
|
||||
3. They get [result]
|
||||
4. This helps them [achievement]
|
||||
|
||||
This validates the module makes sense end-to-end.
|
||||
|
||||
<template-output>user_scenarios</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Technical and resource planning">
|
||||
Assess technical requirements:
|
||||
|
||||
**Data Requirements:**
|
||||
|
||||
- What data/files does the module need?
|
||||
- Any external APIs or services?
|
||||
- Storage or state management needs?
|
||||
|
||||
**Integration Points:**
|
||||
|
||||
- Other BMAD modules it might use
|
||||
- External tools or platforms
|
||||
- Import/export formats
|
||||
|
||||
**Complexity Assessment:**
|
||||
|
||||
- Simple (standalone, no dependencies)
|
||||
- Standard (some integrations, moderate complexity)
|
||||
- Complex (multiple systems, advanced features)
|
||||
|
||||
<template-output>technical_planning</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Success metrics and validation">
|
||||
Define what success looks like:
|
||||
|
||||
**Module Success Criteria:**
|
||||
|
||||
- What indicates the module is working well?
|
||||
- How will users measure value?
|
||||
- What feedback mechanisms?
|
||||
|
||||
**Quality Standards:**
|
||||
|
||||
- Performance expectations
|
||||
- Reliability requirements
|
||||
- User experience goals
|
||||
|
||||
<template-output>success_metrics</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Development roadmap">
|
||||
Create a phased approach:
|
||||
|
||||
**Phase 1 - MVP (Minimum Viable Module):**
|
||||
|
||||
- 1 primary agent
|
||||
- 2-3 core workflows
|
||||
- Basic functionality
|
||||
|
||||
**Phase 2 - Enhancement:**
|
||||
|
||||
- Additional agents
|
||||
- More workflows
|
||||
- Refined features
|
||||
|
||||
**Phase 3 - Polish:**
|
||||
|
||||
- Advanced features
|
||||
- Optimizations
|
||||
- Nice-to-haves
|
||||
|
||||
<template-output>development_roadmap</template-output>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Creative flourishes and special features" optional="true">
|
||||
<action>If user wants to add special touches:</action>
|
||||
|
||||
**Easter Eggs:**
|
||||
|
||||
- Hidden commands or responses
|
||||
- Fun interactions between agents
|
||||
|
||||
**Delighters:**
|
||||
|
||||
- Unexpected helpful features
|
||||
- Personality quirks
|
||||
- Creative responses
|
||||
|
||||
**Module Lore:**
|
||||
|
||||
- Backstory for agents
|
||||
- Thematic elements
|
||||
- Consistent universe
|
||||
|
||||
<template-output>creative_features</template-output>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Risk assessment and mitigation">
|
||||
Identify potential challenges:
|
||||
|
||||
**Technical Risks:**
|
||||
|
||||
- Complex integrations
|
||||
- Performance concerns
|
||||
- Dependency issues
|
||||
|
||||
**Usability Risks:**
|
||||
|
||||
- Learning curve
|
||||
- Complexity creep
|
||||
- User confusion
|
||||
|
||||
**Scope Risks:**
|
||||
|
||||
- Feature bloat
|
||||
- Timeline expansion
|
||||
- Resource constraints
|
||||
|
||||
For each risk, note mitigation strategy.
|
||||
|
||||
<template-output>risk_assessment</template-output>
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Final review and export readiness">
|
||||
<action>Review all sections with {user_name}</action>
|
||||
<action>Ensure module brief is ready for create-module workflow</action>
|
||||
|
||||
<ask>Would {user_name} like to:
|
||||
|
||||
1. Proceed directly to create-module workflow
|
||||
2. Save and refine later
|
||||
3. Generate additional planning documents
|
||||
</ask>
|
||||
|
||||
<action>Inform {user_name} in {communication_language} that this brief can be fed directly into create-module workflow</action>
|
||||
|
||||
<template-output>final_brief</template-output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -1,275 +0,0 @@
|
|||
# Module Brief: {{module_name}}
|
||||
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
**Module Code:** {{module_code}}
|
||||
**Status:** Ready for Development
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{module_vision}}
|
||||
|
||||
**Module Category:** {{module_category}}
|
||||
**Complexity Level:** {{complexity_level}}
|
||||
**Target Users:** {{target_users}}
|
||||
|
||||
---
|
||||
|
||||
## Module Identity
|
||||
|
||||
### Core Concept
|
||||
|
||||
{{module_identity}}
|
||||
|
||||
### Unique Value Proposition
|
||||
|
||||
What makes this module special:
|
||||
{{unique_value}}
|
||||
|
||||
### Personality Theme
|
||||
|
||||
{{personality_theme}}
|
||||
|
||||
---
|
||||
|
||||
## Agent Architecture
|
||||
|
||||
{{agent_architecture}}
|
||||
|
||||
### Agent Roster
|
||||
|
||||
{{agent_roster}}
|
||||
|
||||
### Agent Interaction Model
|
||||
|
||||
How agents work together:
|
||||
{{agent_interactions}}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Ecosystem
|
||||
|
||||
{{workflow_ecosystem}}
|
||||
|
||||
### Core Workflows
|
||||
|
||||
Essential functionality that delivers primary value:
|
||||
{{core_workflows}}
|
||||
|
||||
### Feature Workflows
|
||||
|
||||
Specialized capabilities that enhance the module:
|
||||
{{feature_workflows}}
|
||||
|
||||
### Utility Workflows
|
||||
|
||||
Supporting operations and maintenance:
|
||||
{{utility_workflows}}
|
||||
|
||||
---
|
||||
|
||||
## User Scenarios
|
||||
|
||||
### Primary Use Case
|
||||
|
||||
{{primary_scenario}}
|
||||
|
||||
### Secondary Use Cases
|
||||
|
||||
{{secondary_scenarios}}
|
||||
|
||||
### User Journey
|
||||
|
||||
Step-by-step walkthrough of typical usage:
|
||||
{{user_journey}}
|
||||
|
||||
---
|
||||
|
||||
## Technical Planning
|
||||
|
||||
### Data Requirements
|
||||
|
||||
{{data_requirements}}
|
||||
|
||||
### Integration Points
|
||||
|
||||
{{integration_points}}
|
||||
|
||||
### Dependencies
|
||||
|
||||
{{dependencies}}
|
||||
|
||||
### Technical Complexity Assessment
|
||||
|
||||
{{technical_planning}}
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Module Success Criteria
|
||||
|
||||
How we'll know the module is successful:
|
||||
{{success_criteria}}
|
||||
|
||||
### Quality Standards
|
||||
|
||||
{{quality_standards}}
|
||||
|
||||
### Performance Targets
|
||||
|
||||
{{performance_targets}}
|
||||
|
||||
---
|
||||
|
||||
## Development Roadmap
|
||||
|
||||
### Phase 1: MVP (Minimum Viable Module)
|
||||
|
||||
**Timeline:** {{phase1_timeline}}
|
||||
|
||||
{{phase1_components}}
|
||||
|
||||
**Deliverables:**
|
||||
{{phase1_deliverables}}
|
||||
|
||||
### Phase 2: Enhancement
|
||||
|
||||
**Timeline:** {{phase2_timeline}}
|
||||
|
||||
{{phase2_components}}
|
||||
|
||||
**Deliverables:**
|
||||
{{phase2_deliverables}}
|
||||
|
||||
### Phase 3: Polish and Optimization
|
||||
|
||||
**Timeline:** {{phase3_timeline}}
|
||||
|
||||
{{phase3_components}}
|
||||
|
||||
**Deliverables:**
|
||||
{{phase3_deliverables}}
|
||||
|
||||
---
|
||||
|
||||
## Creative Features
|
||||
|
||||
### Special Touches
|
||||
|
||||
{{creative_features}}
|
||||
|
||||
### Easter Eggs and Delighters
|
||||
|
||||
{{easter_eggs}}
|
||||
|
||||
### Module Lore and Theming
|
||||
|
||||
{{module_lore}}
|
||||
|
||||
---
|
||||
|
||||
## Risk Assessment
|
||||
|
||||
### Technical Risks
|
||||
|
||||
{{technical_risks}}
|
||||
|
||||
### Usability Risks
|
||||
|
||||
{{usability_risks}}
|
||||
|
||||
### Scope Risks
|
||||
|
||||
{{scope_risks}}
|
||||
|
||||
### Mitigation Strategies
|
||||
|
||||
{{risk_mitigation}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
### Priority Order
|
||||
|
||||
1. {{priority_1}}
|
||||
2. {{priority_2}}
|
||||
3. {{priority_3}}
|
||||
|
||||
### Key Design Decisions
|
||||
|
||||
{{design_decisions}}
|
||||
|
||||
### Open Questions
|
||||
|
||||
{{open_questions}}
|
||||
|
||||
---
|
||||
|
||||
## Resources and References
|
||||
|
||||
### Inspiration Sources
|
||||
|
||||
{{inspiration_sources}}
|
||||
|
||||
### Similar Modules
|
||||
|
||||
{{similar_modules}}
|
||||
|
||||
### Technical References
|
||||
|
||||
{{technical_references}}
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
### A. Detailed Agent Specifications
|
||||
|
||||
{{detailed_agent_specs}}
|
||||
|
||||
### B. Workflow Detailed Designs
|
||||
|
||||
{{detailed_workflow_specs}}
|
||||
|
||||
### C. Data Structures and Schemas
|
||||
|
||||
{{data_schemas}}
|
||||
|
||||
### D. Integration Specifications
|
||||
|
||||
{{integration_specs}}
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Review this brief** with stakeholders
|
||||
2. **Run create-module workflow** using this brief as input
|
||||
3. **Create first agent** using create-agent workflow
|
||||
4. **Develop initial workflows** using create-workflow
|
||||
5. **Test MVP** with target users
|
||||
|
||||
---
|
||||
|
||||
_This Module Brief is ready to be fed directly into the create-module workflow for scaffolding and implementation._
|
||||
|
||||
**Module Viability Score:** {{viability_score}}/10
|
||||
**Estimated Development Effort:** {{effort_estimate}}
|
||||
**Confidence Level:** {{confidence_level}}
|
||||
|
||||
---
|
||||
|
||||
**Approval for Development:**
|
||||
|
||||
- [ ] Concept Approved
|
||||
- [ ] Scope Defined
|
||||
- [ ] Resources Available
|
||||
- [ ] Ready to Build
|
||||
|
||||
---
|
||||
|
||||
_Generated on {{date}} by {{user_name}} using the BMAD Method Module Brief workflow_
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
# Module Brief Workflow Configuration
|
||||
name: module-brief
|
||||
description: "Create a comprehensive Module Brief that serves as the blueprint for building new BMAD modules using strategic analysis and creative vision"
|
||||
author: "BMad Builder"
|
||||
|
||||
# Critical variables
|
||||
config_source: "{project-root}/_bmad/bmb/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
|
||||
# Reference examples and documentation
|
||||
existing_modules_dir: "{project-root}/_bmad/"
|
||||
module_structure_guide: "{project-root}/_bmad/bmb/workflows/create-module/module-structure.md"
|
||||
|
||||
# Optional user inputs - discovered if they exist
|
||||
input_file_patterns:
|
||||
brainstorming:
|
||||
description: "Brainstorming session outputs (optional)"
|
||||
whole: "{output_folder}/brainstorming-*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/_bmad/bmb/workflows/module-brief"
|
||||
template: "{installed_path}/template.md"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/module-brief-{{module_code}}-{{date}}.md"
|
||||
|
||||
standalone: true
|
||||
|
||||
# Web bundle configuration
|
||||
web_bundle: false # BMB workflows run locally in BMAD-METHOD project
|
||||
|
|
@ -31,8 +31,8 @@ critical_actions:
|
|||
|
||||
**CRITICAL Path Format:**
|
||||
- `{project-root}` = literal text (not replaced)
|
||||
- Sidecar copied to `_memory/` at build time
|
||||
- Use `{project-root}/_bmad/_memory/{sidecar-folder}/` format
|
||||
- Sidecar created next to agent.yaml during BUILD, then copied to `_memory/` during BMAD INSTALLATION
|
||||
- Use `{project-root}/_bmad/_memory/{sidecar-folder}/` format for RUNTIME paths in agent YAML
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ Agents with a sidecar folder for persistent memory, custom workflows, and restri
|
|||
|
||||
## CRITICAL: Sidecar Path Format
|
||||
|
||||
At build/install, sidecar is copied to `{project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
During BMAD INSTALLATION, sidecar folder is copied from the agent location to `{project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
|
||||
**ALL agent YAML references MUST use:**
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,9 @@ Optional creative exploration to generate agent ideas through structured brainst
|
|||
- Limits: No mandatory brainstorming, no pressure tactics
|
||||
- Dependencies: User choice to participate or skip brainstorming
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Present Brainstorming Opportunity
|
||||
|
||||
|
|
|
|||
|
|
@ -108,7 +108,9 @@ After documentation, present menu:
|
|||
- Clear articulation of value proposition
|
||||
- Comprehensive capability mapping
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
1. **Load Previous Context**
|
||||
- Check for brainstormContext file
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: 'step-02-type-metadata'
|
||||
name: 'step-03-type-metadata'
|
||||
description: 'Determine agent type and define metadata'
|
||||
|
||||
# File References
|
||||
|
|
@ -27,7 +27,7 @@ Determine the agent's classification (Simple/Expert/Module) and define all manda
|
|||
# MANDATORY EXECUTION RULES
|
||||
|
||||
## Universal Rules
|
||||
- ALWAYS use `{agent-language}` for all conversational text
|
||||
- ALWAYS use `{communication_language}` for all conversational text
|
||||
- MAINTAIN step boundaries - complete THIS step only
|
||||
- DOCUMENT all decisions to agent plan file
|
||||
- HONOR user's creative control throughout
|
||||
|
|
@ -125,7 +125,9 @@ Present structured options:
|
|||
|
||||
---
|
||||
|
||||
# INSTRUCTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
## 1. Load Documentation
|
||||
Read and internalize:
|
||||
|
|
@ -134,7 +136,7 @@ Read and internalize:
|
|||
- Keep examples accessible for reference
|
||||
|
||||
## 2. Purpose Discovery Conversation
|
||||
Engage user with questions in `{agent-language}`:
|
||||
Engage user with questions in `{communication_language}`:
|
||||
- "What is the primary function this agent will perform?"
|
||||
- "How complex are the tasks this agent will handle?"
|
||||
- "Will this agent need to manage workflows or other agents?"
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: 'step-03-persona'
|
||||
name: 'step-04-persona'
|
||||
description: 'Shape the agent personality through four-field persona system'
|
||||
|
||||
# File References
|
||||
|
|
@ -156,7 +156,9 @@ principles:
|
|||
- Workflow steps (belongs in orchestration)
|
||||
- Data structures (belongs in implementation)
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
1. **LOAD** personaProperties.md and principlesCrafting.md
|
||||
2. **EXPLAIN** four-field system with clear examples
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: 'step-04-commands-menu'
|
||||
name: 'step-05-commands-menu'
|
||||
description: 'Build capabilities and command structure'
|
||||
|
||||
# File References
|
||||
|
|
@ -121,7 +121,9 @@ menu:
|
|||
- **User-facing perspective** - triggers should feel natural
|
||||
- **Capability alignment** - every command maps to a capability
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
1. Load agent-menu-patterns.md to understand structure
|
||||
2. Review capabilities from agent-plan step 3
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: 'step-05-activation'
|
||||
name: 'step-06-activation'
|
||||
description: 'Plan activation behavior and route to build'
|
||||
|
||||
# File References
|
||||
|
|
@ -30,7 +30,7 @@ Define activation behavior through critical_actions and route to the appropriate
|
|||
- These are non-negotiable prerequisites
|
||||
|
||||
2. **MUST Determine Route Before Activation Discussion**
|
||||
- Check hasSidecar from plan metadata
|
||||
- Check `module` and `hasSidecar` from plan metadata
|
||||
- Determine destination build step FIRST
|
||||
- Inform user of routing decision
|
||||
|
||||
|
|
@ -41,10 +41,12 @@ Define activation behavior through critical_actions and route to the appropriate
|
|||
|
||||
4. **MUST Follow Routing Logic Exactly**
|
||||
```yaml
|
||||
# Route determination based on hasSidecar and module
|
||||
hasSidecar: false → step-06-build-simple.md
|
||||
hasSidecar: true + module: "stand-alone" → step-06-build-expert.md
|
||||
hasSidecar: true + module: ≠ "stand-alone" → step-06-build-module.md
|
||||
# Route determination based on module and hasSidecar
|
||||
# Module agents: any module value other than "stand-alone"
|
||||
module ≠ "stand-alone" → step-07c-build-module.md
|
||||
# Stand-alone agents: determined by hasSidecar
|
||||
module = "stand-alone" + hasSidecar: true → step-07b-build-expert.md
|
||||
module = "stand-alone" + hasSidecar: false → step-07a-build-simple.md
|
||||
```
|
||||
|
||||
5. **NEVER Skip Documentation**
|
||||
|
|
@ -129,7 +131,9 @@ routing:
|
|||
- Expert agents: Sidecar + stand-alone module
|
||||
- Module agents: Sidecar + parent module integration
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
## 1. Load Reference Documents
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
name: 'step-06-build-simple'
|
||||
name: 'step-07a-build-simple'
|
||||
description: 'Generate Simple agent YAML from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08a-plan-traceability.md'
|
||||
nextStepFile: './step-08-celebrate.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}.agent.yaml'
|
||||
|
||||
|
|
@ -60,7 +60,9 @@ Assemble the agent plan content into a Simple agent YAML configuration using the
|
|||
- Template placeholders (replace with actual content)
|
||||
- Comments or notes in final YAML
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Template and Architecture Files
|
||||
|
||||
|
|
@ -141,7 +143,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
### 6. Route Based on User Choice
|
||||
|
||||
**If user chooses "one-at-a-time":**
|
||||
- Proceed to `nextStepFile` (step-07a-plan-traceability.md)
|
||||
- Proceed to `nextStepFile` (step-08-celebrate.md)
|
||||
- Continue through each validation step sequentially
|
||||
- Allow review between each validation
|
||||
|
||||
|
|
@ -153,7 +155,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ name: 'step-06-build-expert'
|
|||
description: 'Generate Expert agent YAML with sidecar from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08a-plan-traceability.md'
|
||||
nextStepFile: './step-08-celebrate.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
|
||||
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
|
@ -21,12 +21,12 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
|||
|
||||
# STEP GOAL
|
||||
|
||||
Assemble the agent plan content into a complete Expert agent YAML file with sidecar folder structure. Expert agents require persistent memory storage for specialized operations, accessed via `{project-root}/_bmad/_memory/{sidecar-folder}/` paths in critical_actions.
|
||||
Assemble the agent plan content into a complete Expert agent YAML file with sidecar folder structure. Expert agents require persistent memory storage, so the build creates a sidecar folder next to the agent.yaml (which gets installed to `_bmad/_memory/` during BMAD installation).
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
1. **EXPERT AGENT = SIDECAR REQUIRED**: Every Expert agent MUST have a sidecar folder created under `_bmad/_memory/`
|
||||
2. **CRITICAL_ACTIONS FORMAT**: All critical_actions MUST use `{project-root}/_bmad/_memory/{sidecar-folder}/` for file operations
|
||||
1. **EXPERT AGENT = SIDECAR REQUIRED**: Every Expert agent MUST have a sidecar folder created next to agent.yaml (build location), which will be installed to `_bmad/_memory/` during BMAD installation
|
||||
2. **CRITICAL_ACTIONS FORMAT**: All critical_actions MUST use `{project-root}/_bmad/_memory/{sidecar-folder}/` for file operations (runtime path)
|
||||
3. **TEMPLATE COMPLIANCE**: Follow expert-agent-template.md structure exactly
|
||||
4. **YAML VALIDATION**: Ensure valid YAML syntax with proper indentation (2-space)
|
||||
5. **EXISTING CHECK**: If agentYamlOutput exists, ask user before overwriting
|
||||
|
|
@ -55,8 +55,6 @@ Using expertTemplate as structure:
|
|||
```yaml
|
||||
name: '{agent-name}'
|
||||
description: '{short-description}'
|
||||
type: 'expert'
|
||||
version: '1.0.0'
|
||||
|
||||
author:
|
||||
name: '{author}'
|
||||
|
|
@ -109,19 +107,20 @@ metadata:
|
|||
|
||||
### Phase 4: Create Sidecar Structure
|
||||
|
||||
1. **Create Sidecar Directory**:
|
||||
- Path: `{project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
1. **Create Sidecar Directory** (NEXT TO agent.yaml):
|
||||
- Path: `{agentBuildOutput}/{agent-name}-sidecar/`
|
||||
- Use `mkdir -p` to create full path
|
||||
- Note: This folder gets installed to `_bmad/_memory/` during BMAD installation
|
||||
|
||||
2. **Create Starter Files** (if specified in critical_actions):
|
||||
```bash
|
||||
touch _bmad/_memory/{sidecar-folder}/{file1}.md
|
||||
touch _bmad/_memory/{sidecar-folder}/{file2}.md
|
||||
touch {agentBuildOutput}/{agent-name}-sidecar/{file1}.md
|
||||
touch {agentBuildOutput}/{agent-name}-sidecar/{file2}.md
|
||||
```
|
||||
|
||||
3. **Add README to Sidecar**:
|
||||
```markdown
|
||||
# {sidecar-folder} Memory
|
||||
# {sidecar-folder} Sidecar
|
||||
|
||||
This folder stores persistent memory for the **{agent-name}** Expert agent.
|
||||
|
||||
|
|
@ -132,8 +131,9 @@ metadata:
|
|||
- {file1}.md: {description}
|
||||
- {file2}.md: {description}
|
||||
|
||||
## Access Pattern
|
||||
Agent accesses these files via: `{project-root}/_bmad/_memory/{sidecar-folder}/{filename}.md`
|
||||
## Runtime Access
|
||||
After BMAD installation, this folder will be accessible at:
|
||||
`{project-root}/_bmad/_memory/{sidecar-folder}/{filename}.md`
|
||||
```
|
||||
|
||||
### Phase 5: Write Agent YAML
|
||||
|
|
@ -171,11 +171,11 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
|
||||
This step produces TWO artifacts:
|
||||
1. **Agent YAML**: Complete expert agent definition at `{agentYamlOutput}`
|
||||
2. **Sidecar Structure**: Folder and files at `{project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
2. **Sidecar Structure**: Folder and files at `{agentBuildOutput}/{agent-name}-sidecar/` (build location, installs to `_bmad/_memory/` during BMAD installation)
|
||||
|
||||
Both must exist before proceeding to validation.
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ Both must exist before proceeding to validation.
|
|||
✅ Agent YAML file created at expected location
|
||||
✅ Valid YAML syntax (no parse errors)
|
||||
✅ All template fields populated
|
||||
✅ Sidecar folder created under `_bmad/_memory/`
|
||||
✅ Sidecar folder created at `{agentBuildOutput}/{agent-name}-sidecar/` (build location)
|
||||
✅ Sidecar folder contains starter files from critical_actions
|
||||
✅ critical_actions reference `{project-root}/_bmad/_memory/{sidecar-folder}/` paths
|
||||
✅ metadata.sidecar-folder populated
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ name: 'step-06-build-module'
|
|||
description: 'Generate Module agent YAML from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08a-plan-traceability.md'
|
||||
nextStepFile: './step-08-celebrate.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
|
||||
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
|
@ -205,7 +205,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
|
||||
**THIS STEP IS COMPLETE WHEN:**
|
||||
1. Module agent YAML file exists at agentYamlOutput path
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
name: 'step-09-celebrate'
|
||||
name: 'step-08-celebrate'
|
||||
description: 'Celebrate completion and guide next steps for using the agent'
|
||||
|
||||
# File References
|
||||
thisStepFile: ./step-09-celebrate.md
|
||||
thisStepFile: ./step-08-celebrate.md
|
||||
workflowFile: ../workflow.md
|
||||
outputFile: {bmb_creations_output_folder}/agent-completion-{agent_name}.md
|
||||
|
||||
|
|
@ -11,9 +11,10 @@ outputFile: {bmb_creations_output_folder}/agent-completion-{agent_name}.md
|
|||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
installationDocs: 'https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/modules/bmb-bmad-builder/custom-content-installation.md#standalone-content-agents-workflows-tasks-tools-templates-prompts'
|
||||
validationWorkflow: '{project-root}/src/modules/bmb/workflows/agent/steps-v/v-01-load-review.md'
|
||||
---
|
||||
|
||||
# Step 9: Celebration and Installation Guidance
|
||||
# Step 8: Celebration and Installation Guidance
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
|
|
@ -59,7 +60,9 @@ Celebrate the successful agent creation, recap the agent's capabilities, provide
|
|||
- Limits: No agent modifications, only installation guidance and celebration
|
||||
- Dependencies: Complete agent ready for installation
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change. (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Grand Celebration
|
||||
|
||||
|
|
@ -196,25 +199,27 @@ Save this content to `{outputFile}` for reference.
|
|||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [X] Exit Workflow"
|
||||
Display: "**✅ Agent Build Complete! Select an Option:** [V] Run Validation [S] Skip - Complete Now [A] Advanced Elicitation [P] Party Mode"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF V: "Loading validation phase..." → Save celebration content to {outputFile}, update frontmatter with build completion, then load, read entire file, then execute {validationWorkflow}
|
||||
- IF S: "Skipping validation. Completing workflow..." → Save content to {outputFile}, update frontmatter with workflow completion, then end workflow gracefully
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF X: Save content to {outputFile}, update frontmatter with workflow completion, then end workflow gracefully
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY complete workflow when user selects 'X'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can choose validation (V), skip to complete (S), or use advanced elicitation (A) or party mode (P)
|
||||
- After other menu items execution (A/P), return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [X exit option] is selected and [workflow completion marked in frontmatter], will the workflow end gracefully with agent ready for installation.
|
||||
ONLY WHEN [S skip option] is selected and [workflow completion marked in frontmatter], will the workflow end gracefully with agent ready for installation.
|
||||
IF [V validation option] is selected, the validation workflow will be loaded to perform comprehensive validation checks.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -1,203 +0,0 @@
|
|||
---
|
||||
name: 'step-07a-plan-traceability'
|
||||
description: 'Verify build matches original plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08b-metadata-validation.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
Verify that the built agent YAML file contains all elements specified in the original agent plan. This step ensures plan traceability - confirming that what we planned is what we actually built.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
- MUST load both agentPlan and builtYaml files before comparison
|
||||
- MUST compare ALL planned elements against built implementation
|
||||
- MUST report specific missing items, not just "something is missing"
|
||||
- MUST offer fix option before proceeding to next validation
|
||||
- MUST handle missing files gracefully (report clearly, don't crash)
|
||||
- MUST respect YOLO mode behavior (part of combined validation report)
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## File Loading Protocol
|
||||
1. Load agentPlan from `{bmb_creations_output_folder}/agent-plan-{agent_name}.md`
|
||||
2. Load builtYaml from `{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml`
|
||||
3. If either file is missing, report the specific missing file and stop comparison
|
||||
4. Use Read tool to access both files with absolute paths
|
||||
|
||||
## Comparison Protocol
|
||||
Compare the following categories systematically:
|
||||
|
||||
### 1. Metadata Comparison
|
||||
- Agent name
|
||||
- Description
|
||||
- Version
|
||||
- Author/creator information
|
||||
- Location/module path
|
||||
- Language settings (if specified in plan)
|
||||
|
||||
### 2. Persona Field Comparison
|
||||
For each field in persona section:
|
||||
- Check presence in built YAML
|
||||
- Verify field content matches planned intent
|
||||
- Note any significant deviations (minor wording differences ok)
|
||||
|
||||
### 3. Commands Comparison
|
||||
- Verify all planned commands are present
|
||||
- Check command names match
|
||||
- Verify command descriptions are present
|
||||
- Confirm critical actions are referenced
|
||||
|
||||
### 4. Critical Actions Comparison
|
||||
- Verify all planned critical_actions are present
|
||||
- Check action names match exactly
|
||||
- Verify action descriptions are present
|
||||
- Confirm each action has required fields
|
||||
|
||||
### 5. Additional Elements
|
||||
- Dependencies (if planned)
|
||||
- Configuration (if planned)
|
||||
- Installation instructions (if planned)
|
||||
|
||||
## Reporting Protocol
|
||||
Present findings in clear, structured format:
|
||||
|
||||
```
|
||||
PLAN TRACEABILITY REPORT
|
||||
========================
|
||||
|
||||
Agent: {agent_name}
|
||||
Plan File: {path to agent plan}
|
||||
Build File: {path to built YAML}
|
||||
|
||||
COMPARISON RESULTS:
|
||||
-------------------
|
||||
|
||||
✅ Metadata: All present / Missing: {list}
|
||||
✅ Persona Fields: All present / Missing: {list}
|
||||
✅ Commands: All present / Missing: {list}
|
||||
✅ Critical Actions: All present / Missing: {list}
|
||||
✅ Other Elements: All present / Missing: {list}
|
||||
|
||||
OVERALL STATUS: [PASS / FAIL]
|
||||
|
||||
```
|
||||
|
||||
If ANY elements are missing:
|
||||
- List each missing element with category
|
||||
- Provide specific location reference (what was planned)
|
||||
- Ask if user wants to fix items or continue anyway
|
||||
|
||||
## Menu Protocol
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified missing elements, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-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
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
If YOLO mode:
|
||||
- Include this report in combined validation report
|
||||
- Auto-select [C] Continue if all elements present
|
||||
- Auto-select [F] Fix if missing critical elements (name, commands)
|
||||
- Flag non-critical missing items in summary
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
- ONLY compare plan vs build - do NOT evaluate quality or correctness
|
||||
- Do NOT suggest improvements or changes beyond planned elements
|
||||
- Do NOT re-open persona/commands discovery - this is verification only
|
||||
- Fix option should return to step-06-build, not earlier steps
|
||||
- If plan file is ambiguous, note ambiguity but use reasonable interpretation
|
||||
|
||||
# SEQUENCE
|
||||
|
||||
## 1. Load Required Files
|
||||
```yaml
|
||||
action: read
|
||||
target:
|
||||
- agentPlan
|
||||
- builtYaml
|
||||
on_failure: report which file is missing and suggest resolution
|
||||
```
|
||||
|
||||
## 2. Perform Structured Comparison
|
||||
```yaml
|
||||
action: compare
|
||||
categories:
|
||||
- metadata
|
||||
- persona_fields
|
||||
- commands
|
||||
- critical_actions
|
||||
- other_elements
|
||||
method: systematic category-by-category check
|
||||
```
|
||||
|
||||
## 3. Generate Comparison Report
|
||||
```yaml
|
||||
action: report
|
||||
format: structured pass/fail with specific missing items
|
||||
output: console display + optional save to validation log
|
||||
```
|
||||
|
||||
## 4. Present Menu Options
|
||||
```yaml
|
||||
action: menu
|
||||
options:
|
||||
- F: Fix missing items
|
||||
- C: Continue to metadata validation
|
||||
- V: View detailed comparison (optional)
|
||||
default: C if pass, F if fail
|
||||
```
|
||||
|
||||
## 5. Handle User Choice
|
||||
- **[F] Fix Findings**: Apply auto-fixes to {builtYaml} for identified missing elements, then re-present menu
|
||||
- **[C] Continue**: Proceed to step-07b-metadata-validation
|
||||
- **[A] Advanced Elicitation**: Execute advanced elicitation workflow, then re-present menu
|
||||
- **[P] Party Mode**: Execute party mode workflow, then re-present menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [metadata validation].
|
||||
|
||||
# SUCCESS/FAILURE METRICS
|
||||
|
||||
## Success Criteria
|
||||
- All planned elements present in built YAML: **COMPLETE PASS**
|
||||
- Minor deviations (wording, formatting) but all core elements present: **PASS**
|
||||
- Missing elements identified and user chooses to continue: **PASS WITH NOTED DEFICIENCIES**
|
||||
|
||||
## Failure Criteria
|
||||
- Unable to load plan or build file: **BLOCKING FAILURE**
|
||||
- Critical elements missing (name, commands, or critical_actions): **FAIL**
|
||||
- Comparison cannot be completed due to file corruption: **BLOCKING FAILURE**
|
||||
|
||||
## Next Step Triggers
|
||||
- **PASS → step-07b-metadata-validation**
|
||||
- **PASS WITH DEFICIENCIES → step-07b-metadata-validation** (user choice)
|
||||
- **FAIL → step-06-build** (with specific fix instructions)
|
||||
- **BLOCKING FAILURE → STOP** (resolve file access issues first)
|
||||
|
||||
## YOLO Mode Behavior
|
||||
- Auto-fix missing critical elements by returning to build step
|
||||
- Log non-critical missing items for review but continue validation
|
||||
- Include traceability report in final YOLO summary
|
||||
- Do NOT stop for user confirmation unless plan file is completely missing
|
||||
|
|
@ -1,130 +0,0 @@
|
|||
---
|
||||
name: 'step-07b-metadata-validation'
|
||||
description: 'Validate agent metadata properties'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08c-persona-validation.md'
|
||||
agentMetadata: ../data/agent-metadata.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate that the agent's metadata properties (name, description, version, tags, category, etc.) are properly formatted, complete, and follow BMAD standards.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All metadata fields must be verified
|
||||
- **ALWAYS load both reference documents** - agentMetadata.md AND the builtYaml
|
||||
- **NEVER modify files without user approval** - Report findings first, await menu selection
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** This is a validation step, not an editing step
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the metadata validation reference from `{agentMetadata}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Extract the metadata section from the builtYaml
|
||||
4. Compare actual metadata against validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
Perform these checks systematically:
|
||||
|
||||
1. **Required Fields Existence**
|
||||
- [ ] name: Present and non-empty
|
||||
- [ ] description: Present and non-empty
|
||||
- [ ] category: Present and matches valid category
|
||||
- [ ] tags: Present as array, not empty
|
||||
|
||||
2. **Format Validation**
|
||||
- [ ] name: Uses kebab-case, no spaces
|
||||
- [ ] description: 50-200 characters (unless intentionally brief)
|
||||
- [ ] tags: Array of lowercase strings with hyphens
|
||||
- [ ] category: Matches one of the allowed categories
|
||||
|
||||
3. **Content Quality**
|
||||
- [ ] description: Clear and concise, explains what the agent does
|
||||
- [ ] tags: Relevant to agent's purpose (3-7 tags recommended)
|
||||
- [ ] category: Most appropriate classification
|
||||
|
||||
4. **Standards Compliance**
|
||||
- [ ] No prohibited characters in fields
|
||||
- [ ] No redundant or conflicting information
|
||||
- [ ] Consistent formatting with other agents
|
||||
|
||||
### Protocol 3: Report Findings
|
||||
Organize your report into three sections:
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Required fields present
|
||||
✓ Name follows kebab-case convention
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Description is brief (45 chars, recommended 50-200)
|
||||
⚠ Only 2 tags provided, 3-7 recommended
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Category "custom-type" not in allowed list
|
||||
```
|
||||
|
||||
### Protocol 4: Menu System
|
||||
|
||||
#### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-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
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Metadata section of agent.yaml (name, description, version, tags, category, author, license, etc.)
|
||||
- Referencing the agentMetadata.md validation rules
|
||||
- Comparing against BMAD standards
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Persona fields (handled in step-07c)
|
||||
- Menu items (handled in step-07d)
|
||||
- System architecture (handled in step-07e)
|
||||
- Capability implementation (handled in step-07f)
|
||||
|
||||
**DO NOT:**
|
||||
- Validate persona properties in this step
|
||||
- Suggest major feature additions
|
||||
- Question the agent's core purpose
|
||||
- Modify fields beyond metadata
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [persona validation].
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✓ **Complete Success:** All checks pass, no failures, warnings are optional
|
||||
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
|
||||
✓ **Failure:** Blocking failures remain when user selects [C]
|
||||
|
||||
**CRITICAL:** Never proceed to next step if blocking failures exist and user hasn't acknowledged them.
|
||||
|
|
@ -1,161 +0,0 @@
|
|||
---
|
||||
name: 'step-07c-persona-validation'
|
||||
description: 'Validate persona fields and principles'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08d-menu-validation.md'
|
||||
personaProperties: ../data/persona-properties.md
|
||||
principlesCrafting: ../data/principles-crafting.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate that the agent's persona (role, tone, expertise, principles, constraints) is well-defined, consistent, and aligned with its purpose.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All persona fields must be verified
|
||||
- **ALWAYS load both reference documents** - personaProperties.md AND principlesCrafting.md
|
||||
- **NEVER modify files without user approval** - Report findings first, await menu selection
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** This is a validation step, not an editing step
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the persona validation reference from `{personaProperties}`
|
||||
2. Read the principles crafting guide from `{principlesCrafting}`
|
||||
3. Read the built agent YAML from `{builtYaml}`
|
||||
4. Extract the persona section from the builtYaml
|
||||
5. Compare actual persona against validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
Perform these checks systematically:
|
||||
|
||||
1. **Required Fields Existence**
|
||||
- [ ] role: Present, clear, and specific
|
||||
- [ ] tone: Present and appropriate to role
|
||||
- [ ] expertise: Present and relevant to agent's purpose
|
||||
- [ ] principles: Present as array, not empty (if applicable)
|
||||
- [ ] constraints: Present as array, not empty (if applicable)
|
||||
|
||||
2. **Content Quality - Role**
|
||||
- [ ] Role is specific (not generic like "assistant")
|
||||
- [ ] Role aligns with agent's purpose and menu items
|
||||
- [ ] Role is achievable within LLM capabilities
|
||||
- [ ] Role scope is appropriate (not too broad/narrow)
|
||||
|
||||
3. **Content Quality - Tone**
|
||||
- [ ] Tone is clearly defined (professional, friendly, authoritative, etc.)
|
||||
- [ ] Tone matches the role and target users
|
||||
- [ ] Tone is consistent throughout the definition
|
||||
- [ ] Tone examples or guidance provided if nuanced
|
||||
|
||||
4. **Content Quality - Expertise**
|
||||
- [ ] Expertise areas are relevant to role
|
||||
- [ ] Expertise claims are realistic for LLM
|
||||
- [ ] Expertise domains are specific (not just "knowledgeable")
|
||||
- [ ] Expertise supports the menu capabilities
|
||||
|
||||
5. **Content Quality - Principles**
|
||||
- [ ] Principles are actionable (not vague platitudes)
|
||||
- [ ] Principles guide behavior and decisions
|
||||
- [ ] Principles are consistent with role
|
||||
- [ ] 3-7 principles recommended (not overwhelming)
|
||||
- [ ] Each principle is clear and specific
|
||||
|
||||
6. **Content Quality - Constraints**
|
||||
- [ ] Constraints define boundaries clearly
|
||||
- [ ] Constraints are enforceable (measurable/observable)
|
||||
- [ ] Constraints prevent undesirable behaviors
|
||||
- [ ] Constraints don't contradict principles
|
||||
|
||||
7. **Consistency Checks**
|
||||
- [ ] Role, tone, expertise, principles all align
|
||||
- [ ] No contradictions between principles and constraints
|
||||
- [ ] Persona supports the menu items defined
|
||||
- [ ] Language and terminology consistent
|
||||
|
||||
### Protocol 3: Report Findings
|
||||
Organize your report into three sections:
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Role is specific and well-defined
|
||||
✓ Tone clearly articulated and appropriate
|
||||
✓ Expertise aligns with agent purpose
|
||||
✓ Principles are actionable and clear
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Only 2 principles provided, 3-7 recommended for richer guidance
|
||||
⚠ No constraints defined - consider adding boundaries
|
||||
⚠ Expertise areas are broad, could be more specific
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Role is generic ("assistant") - needs specificity
|
||||
✗ Tone undefined - creates inconsistent behavior
|
||||
✗ Principles are vague ("be helpful" - not actionable)
|
||||
✗ Contradiction: Principle says "be creative", constraint says "follow strict rules"
|
||||
```
|
||||
|
||||
### Protocol 4: Menu System
|
||||
|
||||
#### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-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
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Persona section of agent.yaml (role, tone, expertise, principles, constraints)
|
||||
- Referencing personaProperties.md and principlesCrafting.md
|
||||
- Evaluating persona clarity, specificity, and consistency
|
||||
- Checking alignment between persona elements
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Metadata fields (handled in step-07b)
|
||||
- Menu items (handled in step-07d)
|
||||
- System architecture (handled in step-07e)
|
||||
- Technical implementation details
|
||||
|
||||
**DO NOT:**
|
||||
- Validate metadata properties in this step
|
||||
- Question the agent's core purpose (that's for earlier steps)
|
||||
- Suggest additional menu items
|
||||
- Modify fields beyond persona
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [menu validation].
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✓ **Complete Success:** All checks pass, persona is well-defined and consistent
|
||||
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
|
||||
✓ **Failure:** Blocking failures remain when user selects [C]
|
||||
|
||||
**CRITICAL:** A weak or generic persona is a blocking issue that should be fixed before proceeding.
|
||||
|
|
@ -1,175 +0,0 @@
|
|||
---
|
||||
name: 'step-07d-menu-validation'
|
||||
description: 'Validate menu items and patterns'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08e-structure-validation.md'
|
||||
agentMenuPatterns: ../data/agent-menu-patterns.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate that the agent's menu (commands/tools) follows BMAD patterns, is well-structured, properly documented, and aligns with the agent's persona and purpose.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All menu items must be verified
|
||||
- **ALWAYS load the reference document** - agentMenuPatterns.md
|
||||
- **NEVER modify files without user approval** - Report findings first, await menu selection
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** This is a validation step, not an editing step
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the menu patterns reference from `{agentMenuPatterns}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Extract the menu/commands section from the builtYaml
|
||||
4. Compare actual menu against validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
Perform these checks systematically:
|
||||
|
||||
1. **Menu Structure**
|
||||
- [ ] Menu section exists and is properly formatted
|
||||
- [ ] At least one menu item defined (unless intentionally tool-less)
|
||||
- [ ] Menu items follow proper YAML structure
|
||||
- [ ] Each item has required fields (name, description, pattern)
|
||||
|
||||
2. **Menu Item Requirements**
|
||||
For each menu item:
|
||||
- [ ] name: Present, unique, uses kebab-case
|
||||
- [ ] description: Clear and concise
|
||||
- [ ] pattern: Valid regex pattern or tool reference
|
||||
- [ ] scope: Appropriate scope defined (if applicable)
|
||||
|
||||
3. **Pattern Quality**
|
||||
- [ ] Patterns are valid and testable
|
||||
- [ ] Patterns are specific enough to match intended inputs
|
||||
- [ ] Patterns are not overly restrictive
|
||||
- [ ] Patterns use appropriate regex syntax
|
||||
|
||||
4. **Description Quality**
|
||||
- [ ] Each item has clear description
|
||||
- [ ] Descriptions explain what the item does
|
||||
- [ ] Descriptions are consistent in style
|
||||
- [ ] Descriptions help users understand when to use
|
||||
|
||||
5. **Alignment Checks**
|
||||
- [ ] Menu items align with agent's role/purpose
|
||||
- [ ] Menu items are supported by agent's expertise
|
||||
- [ ] Menu items fit within agent's constraints
|
||||
- [ ] Menu items are appropriate for target users
|
||||
|
||||
6. **Completeness**
|
||||
- [ ] Core capabilities for this role are covered
|
||||
- [ ] No obvious missing functionality
|
||||
- [ ] Menu scope is appropriate (not too sparse/overloaded)
|
||||
- [ ] Related functionality is grouped logically
|
||||
|
||||
7. **Standards Compliance**
|
||||
- [ ] No prohibited patterns or commands
|
||||
- [ ] No security vulnerabilities in patterns
|
||||
- [ ] No ambiguous or conflicting items
|
||||
- [ ] Consistent naming conventions
|
||||
|
||||
8. **Menu Link Validation (Agent Type Specific)**
|
||||
- [ ] Determine agent type: Simple (no sidecar), Expert (hasSidecar: true), or Module agent
|
||||
- [ ] For Expert agents (hasSidecar: true):
|
||||
- Menu handlers SHOULD reference external sidecar files (e.g., `./{agent-name}-sidecar/...`)
|
||||
- OR have inline prompts defined directly in the handler
|
||||
- [ ] For Module agents (module property is a code like 'bmm', 'bmb', etc.):
|
||||
- Menu handlers SHOULD reference external module files under the module path
|
||||
- Exec paths must start with `{project-root}/_bmad/{module}/...`
|
||||
- Referenced files must exist under the module directory
|
||||
- [ ] For Simple agents (stand-alone module, no sidecar):
|
||||
- Menu handlers MUST NOT have external file links
|
||||
- Menu handlers SHOULD only use relative links within the same file (e.g., `#section-name`)
|
||||
- OR have inline prompts defined directly in the handler
|
||||
|
||||
### Protocol 3: Report Findings
|
||||
Organize your report into three sections:
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Menu structure properly formatted
|
||||
✓ 5 menu items defined, all with required fields
|
||||
✓ All patterns are valid regex
|
||||
✓ Menu items align with agent role
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Item "analyze-data" description is vague
|
||||
⚠ No menu item for [common capability X]
|
||||
⚠ Pattern for "custom-command" very broad, may over-match
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Duplicate menu item name: "process" appears twice
|
||||
✗ Invalid regex pattern: "[unclosed bracket"
|
||||
✗ Menu item "system-admin" violates security guidelines
|
||||
✗ No menu items defined for agent type that requires tools
|
||||
✗ Simple agent has external link in menu handler (should be relative # or inline)
|
||||
✗ Expert agent with sidecar has no external file links or inline prompts defined
|
||||
✗ Module agent exec path doesn't start with {project-root}/_bmad/{module}/...
|
||||
```
|
||||
|
||||
### Protocol 4: Menu System
|
||||
|
||||
#### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-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
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Menu/commands section of agent.yaml
|
||||
- Referencing agentMenuPatterns.md
|
||||
- Menu structure, patterns, and alignment
|
||||
- Individual menu item validation
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Metadata fields (handled in step-07b)
|
||||
- Persona fields (handled in step-07c)
|
||||
- System architecture (handled in step-07e)
|
||||
- Workflow/capability implementation (handled in step-07f)
|
||||
|
||||
**DO NOT:**
|
||||
- Validate metadata or persona in this step
|
||||
- Suggest entirely new capabilities (that's for earlier steps)
|
||||
- Question whether menu items are "good enough" qualitatively beyond standards
|
||||
- Modify fields beyond menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [structure validation].
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✓ **Complete Success:** All checks pass, menu is well-structured and aligned
|
||||
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
|
||||
✓ **Failure:** Blocking failures remain when user selects [C]
|
||||
|
||||
**CRITICAL:** Invalid regex patterns or security vulnerabilities in menu items are blocking issues.
|
||||
|
|
@ -1,306 +0,0 @@
|
|||
---
|
||||
name: 'step-07e-structure-validation'
|
||||
description: 'Validate YAML structure and completeness'
|
||||
|
||||
# File References
|
||||
# Routes to 8F if Expert, else to 9
|
||||
nextStepFileExpert: './step-08f-sidecar-validation.md'
|
||||
nextStepFileSimple: './step-09-celebrate.md'
|
||||
simpleValidation: ../data/simple-agent-validation.md
|
||||
expertValidation: ../data/expert-agent-validation.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate the built agent YAML file for structural completeness and correctness against the appropriate validation checklist (simple or expert), then route to sidecar validation if needed or proceed to celebration.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
|
||||
1. **NEVER skip validation** - All agents must pass structural validation before completion
|
||||
2. **ALWAYS use the correct validation checklist** based on agent type (simple vs expert)
|
||||
3. **NEVER auto-fix without user consent** - Report issues and ask for permission
|
||||
4. **ALWAYS check hasSidecar flag** before determining next step routing
|
||||
5. **MUST load and parse the actual built YAML** - Not just show it, but validate it
|
||||
6. **ALWAYS provide clear, actionable feedback** for any validation failures
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## Context Awareness
|
||||
|
||||
- User is in the final validation phase
|
||||
- Agent has been built and written to disk
|
||||
- This is the "quality gate" before completion
|
||||
- User expects thorough but fair validation
|
||||
- Route depends on agent type (expert vs simple)
|
||||
|
||||
## User Expectations
|
||||
|
||||
- Clear validation results with specific issues identified
|
||||
- Line-number references for YAML problems
|
||||
- Option to fix issues or continue (if minor)
|
||||
- Logical routing based on agent type
|
||||
- Professional, constructive feedback tone
|
||||
|
||||
## Tone and Style
|
||||
|
||||
- Professional and thorough
|
||||
- Constructive, not pedantic
|
||||
- Clear prioritization of issues (critical vs optional)
|
||||
- Encouraging when validation passes
|
||||
- Actionable when issues are found
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
|
||||
## What to Validate
|
||||
|
||||
- YAML syntax and structure
|
||||
- Required frontmatter fields presence
|
||||
- Required sections completeness
|
||||
- Field format correctness
|
||||
- Path validity (for references)
|
||||
- Agent type consistency (simple vs expert requirements)
|
||||
|
||||
## What NOT to Validate
|
||||
|
||||
- Artistic choices in descriptions
|
||||
- Persona writing style
|
||||
- Command naming creativity
|
||||
- Feature scope decisions
|
||||
|
||||
## When to Escalate
|
||||
|
||||
- Critical structural errors that break agent loading
|
||||
- Missing required fields
|
||||
- YAML syntax errors preventing file parsing
|
||||
- Path references that don't exist
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
## 1. Load Validation Context
|
||||
|
||||
```bash
|
||||
# Load the appropriate validation checklist based on agent type
|
||||
if agentType == "expert":
|
||||
validationFile = expertValidation
|
||||
else:
|
||||
validationFile = simpleValidation
|
||||
|
||||
# Load the built agent YAML
|
||||
builtAgent = read(builtYaml)
|
||||
|
||||
# Load compilation rules for reference
|
||||
compilationRules = read(agentCompilation)
|
||||
```
|
||||
|
||||
**Action:** Present a brief status message:
|
||||
```
|
||||
🔍 LOADING VALIDATION FRAMEWORK
|
||||
Agent Type: {detected type}
|
||||
Validation Standard: {simple|expert}
|
||||
Built File: {builtYaml path}
|
||||
```
|
||||
|
||||
## 2. Execute Structural Validation
|
||||
|
||||
Run systematic checks against the validation checklist:
|
||||
|
||||
### A. YAML Syntax Validation
|
||||
- Parse YAML without errors
|
||||
- Check indentation consistency
|
||||
- Validate proper escaping of special characters
|
||||
- Verify no duplicate keys
|
||||
|
||||
### B. Frontmatter Validation
|
||||
- All required fields present
|
||||
- Field values correct type (string, boolean, array)
|
||||
- No empty required fields
|
||||
- Proper array formatting
|
||||
|
||||
### C. Section Completeness
|
||||
- All required sections present (based on agent type)
|
||||
- Sections not empty unless explicitly optional
|
||||
- Proper markdown heading hierarchy
|
||||
|
||||
### D. Field-Level Validation
|
||||
- Path references exist and are valid
|
||||
- Boolean fields are actual booleans (not strings)
|
||||
- Array fields properly formatted
|
||||
- No malformed YAML structures
|
||||
|
||||
### E. Agent Type Specific Checks
|
||||
|
||||
**For Simple Agents:**
|
||||
- No sidecar requirements
|
||||
- Basic fields complete
|
||||
- No advanced configuration
|
||||
|
||||
**For Expert Agents:**
|
||||
- Sidecar flag set correctly
|
||||
- Sidecar folder path specified
|
||||
- All expert fields present
|
||||
- Advanced features properly configured
|
||||
|
||||
## 3. Generate Validation Report
|
||||
|
||||
Present findings in structured format:
|
||||
|
||||
```markdown
|
||||
# 🎯 STRUCTURAL VALIDATION REPORT
|
||||
|
||||
## Agent: {agent-name}
|
||||
Type: {simple|expert}
|
||||
File: {builtYaml}
|
||||
|
||||
---
|
||||
|
||||
## ✅ PASSED CHECKS ({count})
|
||||
{List of all validations that passed}
|
||||
|
||||
## ⚠️ ISSUES FOUND ({count})
|
||||
{If any issues, list each with:}
|
||||
### Issue #{number}: {type}
|
||||
**Severity:** [CRITICAL|MODERATE|MINOR]
|
||||
**Location:** Line {line} or Section {section}
|
||||
**Problem:** {clear description}
|
||||
**Impact:** {what this breaks}
|
||||
**Suggested Fix:** {specific action}
|
||||
|
||||
---
|
||||
|
||||
## 📊 VALIDATION SUMMARY
|
||||
**Overall Status:** [PASSED|FAILED|CONDITIONAL]
|
||||
**Critical Issues:** {count}
|
||||
**Moderate Issues:** {count}
|
||||
**Minor Issues:** {count}
|
||||
**Can Load Safely:** [YES|NO]
|
||||
|
||||
---
|
||||
|
||||
{If PASSED}
|
||||
## 🎉 VALIDATION SUCCESSFUL
|
||||
Your agent YAML is structurally sound and ready for use!
|
||||
All required fields present and correctly formatted.
|
||||
|
||||
{If ISSUES FOUND}
|
||||
## 🔧 RECOMMENDED ACTIONS
|
||||
1. Address critical issues first
|
||||
2. Review moderate issues
|
||||
3. Minor issues can be deferred
|
||||
```
|
||||
|
||||
## 4. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFileExpert} or {nextStepFileSimple}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-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
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
If [F] selected: Work through issues systematically
|
||||
- Load specific section needing fix
|
||||
- Present current state
|
||||
- Apply auto-fixes or guide user through corrections
|
||||
- Re-validate after each fix
|
||||
- Confirm resolution and re-present menu
|
||||
|
||||
If [C] selected:
|
||||
- Warn about implications if issues exist
|
||||
- Get explicit confirmation if critical issues
|
||||
- Document acceptance of issues
|
||||
- Proceed to routing
|
||||
|
||||
## 5. Route to Next Step
|
||||
|
||||
After validation passes or user chooses to continue:
|
||||
|
||||
### Check Agent Type and Route
|
||||
|
||||
```yaml
|
||||
# Check for sidecar requirement
|
||||
hasSidecar = checkBuiltYamlForSidecarFlag()
|
||||
|
||||
if hasSidecar == true:
|
||||
# Expert agent with sidecar
|
||||
nextStep = nextStepFileExpert
|
||||
routeMessage = """
|
||||
📦 Expert agent detected with sidecar configuration.
|
||||
→ Proceeding to sidecar validation (Step 7F)
|
||||
"""
|
||||
else:
|
||||
# Simple agent or expert without sidecar
|
||||
nextStep = nextStepFileSimple
|
||||
routeMessage = """
|
||||
✅ Simple agent validation complete.
|
||||
→ Proceeding to celebration (Step 8)
|
||||
"""
|
||||
```
|
||||
|
||||
**Action:** Present routing decision and transition:
|
||||
```markdown
|
||||
# 🚀 VALIDATION COMPLETE - ROUTING DECISION
|
||||
|
||||
{routeMessage}
|
||||
|
||||
**Next Step:** {nextStep filename}
|
||||
**Reason:** Agent type {simple|expert} with sidecar={hasSidecar}
|
||||
|
||||
Press [Enter] to continue to {next step description}...
|
||||
```
|
||||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFileExpert}` or `{nextStepFileSimple}` to execute and begin [sidecar validation or celebration].
|
||||
|
||||
**BEFORE proceeding to next step:**
|
||||
|
||||
1. ✅ Validation checklist executed completely
|
||||
2. ✅ All critical issues resolved or explicitly accepted
|
||||
3. ✅ User informed of routing decision
|
||||
4. ✅ Next step file path determined correctly
|
||||
5. ⚠️ **CRITICAL:** For expert agents, verify hasSidecar is TRUE before routing to 7F
|
||||
6. ⚠️ **CRITICAL:** For simple agents, verify hasSidecar is FALSE before routing to 8
|
||||
|
||||
**DO NOT PROCEED IF:**
|
||||
- YAML has critical syntax errors preventing loading
|
||||
- User has not acknowledged validation results
|
||||
- Routing logic is unclear or conflicting
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
## Step Complete When:
|
||||
- [ ] Validation report generated and presented
|
||||
- [ ] User has reviewed findings
|
||||
- [ ] Critical issues resolved or accepted
|
||||
- [ ] Routing decision communicated and confirmed
|
||||
- [ ] Next step path verified and ready
|
||||
|
||||
## Quality Indicators:
|
||||
- Validation thoroughness (all checklist items covered)
|
||||
- Issue identification clarity and specificity
|
||||
- User satisfaction with resolution process
|
||||
- Correct routing logic applied
|
||||
- Clear transition to next step
|
||||
|
||||
## Failure Modes:
|
||||
- Skipping validation checks
|
||||
- Auto-fixing without permission
|
||||
- Incorrect routing (simple→7F or expert→8 with sidecar)
|
||||
- Unclear or missing validation report
|
||||
- Proceeding with critical YAML errors
|
||||
|
|
@ -1,462 +0,0 @@
|
|||
---
|
||||
name: 'step-07f-sidecar-validation'
|
||||
description: 'Validate sidecar structure and paths'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-09-celebrate.md'
|
||||
criticalActions: ../data/critical-actions.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
sidecarFolder: '{bmb_creations_output_folder}/{agent-name}/{agent-name}-sidecar/'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
# STEP GOAL
|
||||
|
||||
Validate the sidecar folder structure and referenced paths for Expert agents to ensure all sidecar files exist, are properly structured, and paths in the main agent YAML correctly reference them.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
|
||||
1. **ONLY runs for Expert agents** - Simple agents should never reach this step
|
||||
2. **MUST verify sidecar folder exists** before proceeding
|
||||
3. **ALWAYS cross-reference YAML paths** with actual files
|
||||
4. **NEVER create missing sidecar files** - Report issues, don't auto-fix
|
||||
5. **MUST validate sidecar file structure** for completeness
|
||||
6. **ALWAYS check critical actions file** if referenced
|
||||
7. **PROVIDE clear remediation steps** for any missing or malformed files
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## Context Awareness
|
||||
|
||||
- User has an Expert agent with sidecar configuration
|
||||
- Structural validation (7E) already passed
|
||||
- Sidecar folder should have been created during build
|
||||
- This is the final validation before celebration
|
||||
- Missing sidecar components may break agent functionality
|
||||
|
||||
## User Expectations
|
||||
|
||||
- Comprehensive sidecar structure validation
|
||||
- Clear identification of missing files
|
||||
- Path reference verification
|
||||
- Actionable remediation guidance
|
||||
- Professional but approachable tone
|
||||
|
||||
## Tone and Style
|
||||
|
||||
- Thorough and systematic
|
||||
- Clear and specific about issues
|
||||
- Solution-oriented (focus on how to fix)
|
||||
- Encouraging when sidecar is complete
|
||||
- Not pedantic about minor formatting issues
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
|
||||
## What to Validate
|
||||
|
||||
- Sidecar folder existence and location
|
||||
- All referenced files exist in sidecar
|
||||
- Sidecar file structure completeness
|
||||
- Path references in main YAML accuracy
|
||||
- Critical actions file if referenced
|
||||
- File naming conventions
|
||||
- File content completeness (not empty)
|
||||
|
||||
## What NOT to Validate
|
||||
|
||||
- Content quality of sidecar files
|
||||
- Artistic choices in sidecar documentation
|
||||
- Optional sidecar components
|
||||
- File formatting preferences
|
||||
|
||||
## When to Escalate
|
||||
|
||||
- Sidecar folder completely missing
|
||||
- Critical files missing (actions, core modules)
|
||||
- Path references pointing to non-existent files
|
||||
- Empty sidecar files that should have content
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
## 1. Load Sidecar Context
|
||||
|
||||
```bash
|
||||
# Verify main agent YAML exists
|
||||
agentYaml = read(builtYaml)
|
||||
|
||||
# Extract sidecar path from YAML or use template default
|
||||
sidecarPath = extractSidecarPath(agentYaml) or sidecarFolder
|
||||
|
||||
# Check if sidecar folder exists
|
||||
sidecarExists = directoryExists(sidecarPath)
|
||||
|
||||
# Load critical actions reference if needed
|
||||
criticalActionsRef = read(criticalActions)
|
||||
```
|
||||
|
||||
**Action:** Present discovery status:
|
||||
```markdown
|
||||
🔍 SIDECAR VALIDATION INITIALIZED
|
||||
|
||||
Agent: {agent-name}
|
||||
Type: Expert (requires sidecar)
|
||||
|
||||
Main YAML: {builtYaml}
|
||||
Sidecar Path: {sidecarPath}
|
||||
|
||||
Status: {✅ Folder Found | ❌ Folder Missing}
|
||||
```
|
||||
|
||||
## 2. Validate Sidecar Structure
|
||||
|
||||
### A. Folder Existence Check
|
||||
|
||||
```markdown
|
||||
## 📁 FOLDER STRUCTURE VALIDATION
|
||||
|
||||
**Sidecar Location:** {sidecarPath}
|
||||
**Status:** [EXISTS | MISSING | WRONG LOCATION]
|
||||
```
|
||||
|
||||
If missing:
|
||||
```markdown
|
||||
❌ **CRITICAL ISSUE:** Sidecar folder not found!
|
||||
|
||||
**Expected Location:** {sidecarPath}
|
||||
|
||||
**Possible Causes:**
|
||||
1. Build process didn't create sidecar
|
||||
2. Sidecar path misconfigured in agent YAML
|
||||
3. Folder moved or deleted after build
|
||||
|
||||
**Required Action:**
|
||||
[ ] Re-run build process with sidecar enabled
|
||||
[ ] Verify sidecar configuration in agent YAML
|
||||
[ ] Check folder was created in correct location
|
||||
```
|
||||
|
||||
### B. Sidecar File Inventory
|
||||
|
||||
If folder exists, list all files:
|
||||
```bash
|
||||
sidecarFiles = listFiles(sidecarPath)
|
||||
```
|
||||
|
||||
```markdown
|
||||
## 📄 SIDECAR FILE INVENTORY
|
||||
|
||||
Found {count} files in sidecar:
|
||||
|
||||
{For each file:}
|
||||
- {filename} ({size} bytes)
|
||||
```
|
||||
|
||||
### C. Cross-Reference Validation
|
||||
|
||||
Extract all sidecar path references from agent YAML:
|
||||
```yaml
|
||||
# Common sidecar reference patterns
|
||||
sidecar:
|
||||
critical-actions: './{agent-name}-sidecar/critical-actions.md'
|
||||
modules:
|
||||
- path: './{agent-name}-sidecar/modules/module-01.md'
|
||||
```
|
||||
|
||||
Validate each reference:
|
||||
```markdown
|
||||
## 🔗 PATH REFERENCE VALIDATION
|
||||
|
||||
**Checked {count} references from agent YAML:**
|
||||
|
||||
{For each reference:}
|
||||
**Source:** {field in agent YAML}
|
||||
**Expected Path:** {referenced path}
|
||||
**Status:** [✅ Found | ❌ Missing | ⚠️ Wrong Location]
|
||||
```
|
||||
|
||||
## 3. Validate Sidecar File Contents
|
||||
|
||||
For each sidecar file found, check:
|
||||
|
||||
### A. File Completeness
|
||||
```markdown
|
||||
## 📋 FILE CONTENT VALIDATION
|
||||
|
||||
{For each file:}
|
||||
### {filename}
|
||||
**Size:** {bytes}
|
||||
**Status:** [✅ Complete | ⚠️ Empty | ❌ Too Small]
|
||||
**Last Modified:** {timestamp}
|
||||
```
|
||||
|
||||
### B. Critical Actions File (if present)
|
||||
|
||||
Special validation for critical-actions.md:
|
||||
```markdown
|
||||
## 🎯 CRITICAL ACTIONS VALIDATION
|
||||
|
||||
**File:** {sidecarPath}/critical-actions.md
|
||||
**Status:** [PRESENT | MISSING | EMPTY]
|
||||
|
||||
{If Present:}
|
||||
**Sections Found:**
|
||||
{List sections detected}
|
||||
|
||||
**Completeness:**
|
||||
[ ] Header/metadata present
|
||||
[ ] Actions defined
|
||||
[ ] No critical sections missing
|
||||
```
|
||||
|
||||
### C. Module Files (if present)
|
||||
|
||||
If sidecar contains modules:
|
||||
```markdown
|
||||
## 📚 MODULE VALIDATION
|
||||
|
||||
**Modules Found:** {count}
|
||||
|
||||
{For each module:}
|
||||
### {module-filename}
|
||||
**Status:** [✅ Valid | ⚠️ Issues Found]
|
||||
**Checks:**
|
||||
[ ] Frontmatter complete
|
||||
[ ] Content present
|
||||
[ ] References valid
|
||||
```
|
||||
|
||||
## 4. Generate Validation Report
|
||||
|
||||
```markdown
|
||||
# 🎯 SIDECAR VALIDATION REPORT
|
||||
|
||||
## Agent: {agent-name}
|
||||
Sidecar Path: {sidecarPath}
|
||||
Validation Date: {timestamp}
|
||||
|
||||
---
|
||||
|
||||
## ✅ VALIDATION CHECKS PASSED
|
||||
|
||||
**Folder Structure:**
|
||||
- [x] Sidecar folder exists
|
||||
- [x] Located at expected path
|
||||
- [x] Accessible and readable
|
||||
|
||||
**File Completeness:**
|
||||
- [x] All referenced files present
|
||||
- [x] No broken path references
|
||||
- [x] Files have content (not empty)
|
||||
|
||||
**Content Quality:**
|
||||
- [x] Critical actions complete
|
||||
- [x] Module files structured
|
||||
- [x] No obvious corruption
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ ISSUES IDENTIFIED ({count})
|
||||
|
||||
{If issues:}
|
||||
### Issue #{number}: {issue type}
|
||||
**Severity:** [CRITICAL|MODERATE|MINOR]
|
||||
**Component:** {file or folder}
|
||||
**Problem:** {clear description}
|
||||
**Impact:** {what this breaks}
|
||||
**Remediation:**
|
||||
1. {specific step 1}
|
||||
2. {specific step 2}
|
||||
3. {specific step 3}
|
||||
|
||||
{If no issues:}
|
||||
### 🎉 NO ISSUES FOUND
|
||||
Your agent's sidecar is complete and properly structured!
|
||||
All path references are valid and files are in place.
|
||||
|
||||
---
|
||||
|
||||
## 📊 SUMMARY
|
||||
|
||||
**Overall Status:** [PASSED|FAILED|CONDITIONAL]
|
||||
**Files Validated:** {count}
|
||||
**Issues Found:** {count}
|
||||
**Critical Issues:** {count}
|
||||
**Sidecar Ready:** [YES|NO]
|
||||
|
||||
---
|
||||
|
||||
## 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} or sidecar files for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to celebration step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-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
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## 6. Issue Resolution (if [F] selected)
|
||||
|
||||
Work through each issue systematically:
|
||||
|
||||
**For Missing Files:**
|
||||
```markdown
|
||||
### 🔧 FIXING: Missing {filename}
|
||||
|
||||
**Required File:** {path}
|
||||
**Purpose:** {why it's needed}
|
||||
|
||||
**Option 1:** Re-run Build
|
||||
- Sidecar may not have been created completely
|
||||
- Return to build step and re-execute
|
||||
|
||||
**Option 2:** Manual Creation
|
||||
- Create file at: {full path}
|
||||
- Use template from: {template reference}
|
||||
- Minimum required content: {specification}
|
||||
|
||||
**Option 3:** Update References
|
||||
- Remove reference from agent YAML if not truly needed
|
||||
- Update path if file exists in different location
|
||||
|
||||
Which option? [1/2/3]:
|
||||
```
|
||||
|
||||
**For Broken Path References:**
|
||||
```markdown
|
||||
### 🔧 FIXING: Invalid Path Reference
|
||||
|
||||
**Reference Location:** {agent YAML field}
|
||||
**Current Path:** {incorrect path}
|
||||
**Expected File:** {filename}
|
||||
**Actual Location:** {where file actually is}
|
||||
|
||||
**Fix Options:**
|
||||
1. Update path in agent YAML to: {correct path}
|
||||
2. Move file to expected location: {expected path}
|
||||
3. Remove reference if file not needed
|
||||
|
||||
Which option? [1/2/3]:
|
||||
```
|
||||
|
||||
**For Empty/Malformed Files:**
|
||||
```markdown
|
||||
### 🔧 FIXING: {filename} - {Issue}
|
||||
|
||||
**Problem:** {empty/too small/malformed}
|
||||
**Location:** {full path}
|
||||
|
||||
**Remediation:**
|
||||
- View current content
|
||||
- Compare to template/standard
|
||||
- Add missing sections
|
||||
- Correct formatting
|
||||
|
||||
Ready to view and fix? [Y/N]:
|
||||
```
|
||||
|
||||
After each fix:
|
||||
- Re-validate the specific component
|
||||
- Confirm resolution
|
||||
- Move to next issue
|
||||
- Final re-validation when all complete
|
||||
|
||||
## 6. Route to Celebration
|
||||
|
||||
When validation passes or user chooses to continue:
|
||||
|
||||
```markdown
|
||||
# 🚀 SIDECAR VALIDATION COMPLETE
|
||||
|
||||
## Expert Agent: {agent-name}
|
||||
|
||||
✅ **Sidecar Structure:** Validated
|
||||
✅ **Path References:** All correct
|
||||
✅ **File Contents:** Complete
|
||||
|
||||
---
|
||||
|
||||
## 🎯 READY FOR CELEBRATION
|
||||
|
||||
Your Expert agent with sidecar is fully validated and ready!
|
||||
|
||||
**Next Step:** Celebration (Step 8)
|
||||
**Final Status:** All checks passed
|
||||
|
||||
Press [Enter] to proceed to celebration...
|
||||
```
|
||||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [celebration].
|
||||
|
||||
**BEFORE proceeding to Step 8:**
|
||||
|
||||
1. ✅ Sidecar folder exists and is accessible
|
||||
2. ✅ All referenced files present
|
||||
3. ✅ Path references validated
|
||||
4. ✅ File contents checked for completeness
|
||||
5. ✅ User informed of validation status
|
||||
6. ✅ Issues resolved or explicitly accepted
|
||||
7. ⚠️ **CRITICAL:** Only Expert agents should reach this step
|
||||
8. ⚠️ **CRITICAL:** Sidecar must be complete for agent to function
|
||||
|
||||
**DO NOT PROCEED IF:**
|
||||
- Sidecar folder completely missing
|
||||
- Critical files absent (actions, core modules)
|
||||
- User unaware of sidecar issues
|
||||
- Validation not completed
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
## Step Complete When:
|
||||
- [ ] Sidecar folder validated
|
||||
- [ ] All path references checked
|
||||
- [ ] File contents verified
|
||||
- [ ] Validation report presented
|
||||
- [ ] Issues resolved or accepted
|
||||
- [ ] User ready to proceed
|
||||
|
||||
## Quality Indicators:
|
||||
- Thoroughness of file inventory
|
||||
- Accuracy of path reference validation
|
||||
- Clarity of issue identification
|
||||
- Actionability of remediation steps
|
||||
- User confidence in sidecar completeness
|
||||
|
||||
## Failure Modes:
|
||||
- Missing sidecar folder completely
|
||||
- Skipping file existence checks
|
||||
- Not validating path references
|
||||
- Proceeding with critical files missing
|
||||
- Unclear validation report
|
||||
- Not providing remediation guidance
|
||||
|
||||
---
|
||||
|
||||
## 🎓 NOTE: Expert Agent Sidecars
|
||||
|
||||
Sidecars are what make Expert agents powerful. They enable:
|
||||
- Modular architecture
|
||||
- Separation of concerns
|
||||
- Easier updates and maintenance
|
||||
- Shared components across agents
|
||||
|
||||
A validated sidecar ensures your Expert agent will:
|
||||
- Load correctly at runtime
|
||||
- Find all referenced resources
|
||||
- Execute critical actions as defined
|
||||
- Provide the advanced capabilities designed
|
||||
|
||||
Take the time to validate thoroughly - it pays off in agent reliability!
|
||||
|
|
@ -59,7 +59,9 @@ Load the existing agent file, parse its structure, and create an edit plan track
|
|||
- Limits: Analysis only, no modifications
|
||||
- Dependencies: Agent file must exist and be valid YAML
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Agent File
|
||||
|
||||
|
|
@ -86,9 +88,8 @@ If a module agent also hasSidecar: true - this means it is a modules expert agen
|
|||
# Basic Metadata
|
||||
- name: {agent-name}
|
||||
- description: {agent-description}
|
||||
- type: {simple|expert|module}
|
||||
- module: {stand-alone|bmm|cis|bmgd|custom}
|
||||
- hasSidecar: {true|false}
|
||||
- version: {version}
|
||||
|
||||
# Persona
|
||||
- persona: {full persona text}
|
||||
|
|
@ -111,7 +112,7 @@ If a module agent also hasSidecar: true - this means it is a modules expert agen
|
|||
```markdown
|
||||
## Agent Analysis: {agent-name}
|
||||
|
||||
**Type:** {simple|expert|module}
|
||||
**Type:** {simple|expert|module} (derived from module + hasSidecar)
|
||||
**Status:** ready-for-edit
|
||||
|
||||
### Current Structure:
|
||||
|
|
|
|||
|
|
@ -54,7 +54,9 @@ Conduct targeted discovery to understand exactly what the user wants to change a
|
|||
- Limits: Discovery and documentation only, no implementation
|
||||
- Dependencies: Agent must be loaded in editPlan
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Read Edit Plan Context
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
# Placeholder - do not load this step.
|
||||
|
|
@ -36,7 +36,9 @@ Review the agent's type and metadata, and plan any changes. If edits involve typ
|
|||
- 💾 Document planned metadata changes
|
||||
- 🚫 FORBIDDEN to proceed without documenting changes
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,9 @@ Review the agent's persona and plan any changes using the four-field persona sys
|
|||
- 💾 Document planned persona changes
|
||||
- 🚫 FORBIDDEN to proceed without documenting changes
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,9 @@ Review the agent's command menu and plan any additions, modifications, or remova
|
|||
- 💾 Document planned command changes
|
||||
- 🚫 FORBIDDEN to proceed without documenting changes
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,9 @@ Review critical_actions and route to the appropriate type-specific edit step (Si
|
|||
- 💾 Route to appropriate type-specific edit step
|
||||
- ➡️ Auto-advance to type-specific edit on [C]
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
@ -56,12 +58,13 @@ If user wants to add/modify critical_actions:
|
|||
|
||||
### 3. Determine Routing
|
||||
|
||||
Check `{editPlan}` metadataEdits.typeConversion.to or current agentType:
|
||||
Check `{editPlan}` for agent metadata (module and hasSidecar):
|
||||
|
||||
```yaml
|
||||
agentType: simple → route to e-08a-edit-simple.md
|
||||
agentType: expert → route to e-08b-edit-expert.md
|
||||
agentType: module → route to e-08c-edit-module.md
|
||||
# Determine agent type from module + hasSidecar combination
|
||||
module ≠ "stand-alone" → route to e-08c-edit-module.md
|
||||
module = "stand-alone" + hasSidecar: true → route to e-08b-edit-expert.md
|
||||
module = "stand-alone" + hasSidecar: false → route to e-08a-edit-simple.md
|
||||
```
|
||||
|
||||
### 4. Document to Edit Plan
|
||||
|
|
@ -75,7 +78,7 @@ activationEdits:
|
|||
modifications: []
|
||||
routing:
|
||||
destinationEdit: {e-08a|e-08b|e-08c}
|
||||
targetType: {simple|expert|module}
|
||||
sourceType: {simple|expert|module} # Derived from module + hasSidecar
|
||||
```
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
|
@ -86,7 +89,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save to {editPlan}, determine routing based on targetType, then only then load and execute the appropriate type-specific edit step
|
||||
- IF C: Save to {editPlan}, determine routing based on module + hasSidecar, then only then load and execute the appropriate type-specific edit step
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
|
@ -99,9 +102,9 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
|
||||
This is the **ROUTING HUB** for edit flow. ONLY WHEN [C continue option] is selected and [routing determined], load and execute the appropriate type-specific edit step:
|
||||
|
||||
- targetType: simple → e-08a-edit-simple.md
|
||||
- targetType: expert → e-08b-edit-expert.md
|
||||
- targetType: module → e-08c-edit-module.md
|
||||
- module ≠ "stand-alone" → e-08c-edit-module.md (Module agent)
|
||||
- module = "stand-alone" + hasSidecar: true → e-08b-edit-expert.md (Expert agent)
|
||||
- module = "stand-alone" + hasSidecar: false → e-08a-edit-simple.md (Simple agent)
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
name: 'e-08a-edit-simple'
|
||||
description: 'Apply edits to Simple agent'
|
||||
|
||||
nextStepFile: './e-09a-validate-metadata.md'
|
||||
nextStepFile: './e-09-celebrate.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
agentFile: '{original-agent-path}'
|
||||
agentBackup: '{original-agent-path}.backup'
|
||||
|
|
@ -47,7 +47,9 @@ Apply all planned edits to the Simple agent YAML file using templates and archit
|
|||
- ✅ Validate YAML syntax
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
@ -74,9 +76,10 @@ Confirm: "Backup created at: `{agentBackup}`"
|
|||
|
||||
For each planned edit:
|
||||
|
||||
**Type Conversion:**
|
||||
- Update `type:` field if converting
|
||||
- Add/remove type-specific fields
|
||||
**Type Conversion (Simple ← Expert/Module):**
|
||||
- Converting TO Simple: Remove `metadata.sidecar-folder`, remove all sidecar references
|
||||
- Set `module: stand-alone` and `hasSidecar: false`
|
||||
- Remove type-specific fields from source type
|
||||
|
||||
**Metadata Edits:**
|
||||
- Apply each field change from metadataEdits
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
name: 'e-08b-edit-expert'
|
||||
description: 'Apply edits to Expert agent'
|
||||
|
||||
nextStepFile: './e-09a-validate-metadata.md'
|
||||
nextStepFile: './e-09-celebrate.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
agentFile: '{original-agent-path}'
|
||||
agentBackup: '{original-agent-path}.backup'
|
||||
|
|
@ -48,7 +48,9 @@ Apply all planned edits to the Expert agent YAML file and manage sidecar structu
|
|||
- ✅ Validate YAML and sidecar paths
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
@ -70,10 +72,10 @@ ALWAYS backup before editing:
|
|||
|
||||
### 4. Apply Edits in Sequence
|
||||
|
||||
**Type Conversion to Expert:**
|
||||
- Update `type: expert`
|
||||
**Type Conversion TO Expert:**
|
||||
- Set `module: stand-alone` and `hasSidecar: true`
|
||||
- Add `metadata.sidecar-folder` if not present
|
||||
- Create sidecar directory: `mkdir -p {project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
- Create sidecar directory next to agent.yaml: `{agent-folder}/{agent-name}-sidecar/`
|
||||
|
||||
**Sidecar Management:**
|
||||
- If changing sidecar-folder: update all critical_actions references
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
name: 'e-08c-edit-module'
|
||||
description: 'Apply edits to Module agent'
|
||||
|
||||
nextStepFile: './e-09a-validate-metadata.md'
|
||||
nextStepFile: './e-09-celebrate.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
agentFile: '{original-agent-path}'
|
||||
agentBackup: '{original-agent-path}.backup'
|
||||
|
|
@ -48,7 +48,9 @@ Apply all planned edits to the Module agent YAML file and manage workflow integr
|
|||
- ✅ Validate YAML and workflow paths
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
@ -70,9 +72,10 @@ ALWAYS backup before editing:
|
|||
|
||||
### 4. Apply Edits in Sequence
|
||||
|
||||
**Type Conversion to Module:**
|
||||
- Update `type: module`
|
||||
**Type Conversion TO Module:**
|
||||
- Set `module` to module code (e.g., `bmm`, `cis`, `bmgd`, or custom)
|
||||
- Add workflow integration paths
|
||||
- Optionally set `hasSidecar: true` if complex multi-workflow module
|
||||
|
||||
**Workflow Path Management:**
|
||||
- Add: `skills: - workflow: {path}`
|
||||
|
|
|
|||
|
|
@ -1,14 +1,15 @@
|
|||
---
|
||||
name: 'e-10-celebrate'
|
||||
name: 'e-09-celebrate'
|
||||
description: 'Celebrate successful agent edit completion'
|
||||
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
validationWorkflow: '{project-root}/src/modules/bmb/workflows/agent/steps-v/v-01-load-review.md'
|
||||
---
|
||||
|
||||
# Edit Step 10: Celebration
|
||||
# Edit Step 9: Celebration
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
|
|
@ -48,7 +49,9 @@ Celebrate the successful agent edit, provide summary of changes, and mark edit w
|
|||
- Limits: No more edits, only acknowledgment
|
||||
- Dependencies: All edits successfully applied
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.:
|
||||
|
||||
### 1. Read Edit Plan
|
||||
|
||||
|
|
@ -110,24 +113,26 @@ Append to editPlan:
|
|||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [X] Exit Workflow"
|
||||
Display: "**✅ Agent Edit Complete! Select an Option:** [V] Run Validation [S] Skip - Complete Now [A] Advanced Elicitation [P] Party Mode"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF V: "Loading validation phase..." → Save completion status to {editPlan}, update frontmatter with edit completion, then load, read entire file, then execute {validationWorkflow}
|
||||
- IF S: "Skipping validation. Completing workflow..." → Save completion status to {editPlan} and end workflow gracefully
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF X: Save completion status to {editPlan} and end workflow gracefully
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY complete workflow when user selects 'X'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can choose validation (V), skip to complete (S), or use advanced elicitation (A) or party mode (P)
|
||||
- After other menu items execution (A/P), return to this menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [X exit option] is selected and [completion documented], will the workflow end gracefully with agent edit complete.
|
||||
ONLY WHEN [S skip option] is selected and [completion documented], will the workflow end gracefully with agent edit complete.
|
||||
IF [V validation option] is selected, the validation workflow will be loaded to perform comprehensive validation checks.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -1,128 +0,0 @@
|
|||
---
|
||||
name: 'e-09a-validate-metadata'
|
||||
description: 'Validate metadata (after edit) - no menu, auto-advance'
|
||||
|
||||
nextStepFile: './e-09b-validate-persona.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
agentMetadata: ../data/agent-metadata.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9a: Validate Metadata (After Edit)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate that the agent's metadata properties (id, name, title, icon, module, hasSidecar, etc.) are properly formatted, complete, and follow BMAD standards as defined in agentMetadata.md. Record findings to editPlan and auto-advance.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All metadata fields must be verified
|
||||
- **ALWAYS load both reference documents** - agentMetadata.md AND the builtYaml
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** Load and validate EVERYTHING specified in the agentMetadata.md file
|
||||
- **🚫 NO MENU in this step** - record findings and auto-advance
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the metadata validation reference from `{agentMetadata}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Read the edit plan from `{editPlan}`
|
||||
4. Extract the metadata section from the builtYaml
|
||||
5. Compare actual metadata against ALL validation rules in agentMetadata.md
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
|
||||
Perform these checks systematically - validate EVERY rule specified in agentMetadata.md:
|
||||
|
||||
1. **Required Fields Existence**
|
||||
- [ ] id: Present and non-empty
|
||||
- [ ] name: Present and non-empty (display name)
|
||||
- [ ] title: Present and non-empty
|
||||
- [ ] icon: Present (emoji or symbol)
|
||||
- [ ] module: Present and valid format
|
||||
- [ ] hasSidecar: Present (boolean, if applicable)
|
||||
|
||||
2. **Format Validation**
|
||||
- [ ] id: Uses kebab-case, no spaces, unique identifier
|
||||
- [ ] name: Clear display name for UI
|
||||
- [ ] title: Concise functional description
|
||||
- [ ] icon: Appropriate emoji or unicode symbol
|
||||
- [ ] module: Either a 3-4 letter module code (e.g., 'bmm', 'bmb') OR 'stand-alone'
|
||||
- [ ] hasSidecar: Boolean value, matches actual agent structure
|
||||
|
||||
3. **Content Quality**
|
||||
- [ ] id: Unique and descriptive
|
||||
- [ ] name: Clear and user-friendly
|
||||
- [ ] title: Accurately describes agent's function
|
||||
- [ ] icon: Visually representative of agent's purpose
|
||||
- [ ] module: Correctly identifies module membership
|
||||
- [ ] hasSidecar: Correctly indicates if agent uses sidecar files
|
||||
|
||||
4. **Agent Type Consistency**
|
||||
- [ ] If hasSidecar: true, sidecar folder path must be specified
|
||||
- [ ] If module is a module code, agent is a module agent
|
||||
- [ ] If module is 'stand-alone', agent is not part of a module
|
||||
- [ ] No conflicting type indicators
|
||||
|
||||
5. **Standards Compliance**
|
||||
- [ ] No prohibited characters in fields
|
||||
- [ ] No redundant or conflicting information
|
||||
- [ ] Consistent formatting with other agents
|
||||
- [ ] All required BMAD metadata fields present
|
||||
|
||||
### Protocol 3: Record Findings
|
||||
|
||||
Organize findings into three sections and append to editPlan frontmatter under `validationAfter.metadata`:
|
||||
|
||||
```yaml
|
||||
validationAfter:
|
||||
metadata:
|
||||
status: [pass|fail|warning]
|
||||
passing:
|
||||
- "{check description}"
|
||||
- "{check description}"
|
||||
warnings:
|
||||
- "{non-blocking issue}"
|
||||
failures:
|
||||
- "{blocking issue that must be fixed}"
|
||||
```
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ All required fields present
|
||||
✓ id follows kebab-case convention
|
||||
✓ module value is valid
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Description is brief
|
||||
⚠ Only 2 tags provided, 3-7 recommended
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ id field is empty
|
||||
✗ module value is invalid
|
||||
✗ hasSidecar is true but no sidecar-folder specified
|
||||
```
|
||||
|
||||
### Protocol 4: Auto-Advance
|
||||
|
||||
**🚫 NO MENU PRESENTED** - After recording findings, immediately load and execute `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
**Auto-advancing to persona validation...**
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ All metadata checks from agentMetadata.md performed
|
||||
✅ All checks validated against the actual builtYaml
|
||||
✅ Findings saved to editPlan with detailed status
|
||||
✅ Auto-advanced to next step
|
||||
|
|
@ -1,138 +0,0 @@
|
|||
---
|
||||
name: 'e-09b-validate-persona'
|
||||
description: 'Validate persona (after edit) - no menu, auto-advance'
|
||||
|
||||
nextStepFile: './e-09c-validate-menu.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
personaProperties: ../data/persona-properties.md
|
||||
principlesCrafting: ../data/principles-crafting.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9b: Validate Persona (After Edit)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate that the agent's persona (role, identity, communication_style, principles) is well-defined, consistent, and aligned with its purpose as defined in personaProperties.md and principlesCrafting.md. Record findings to editPlan and auto-advance.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All persona fields must be verified
|
||||
- **ALWAYS load both reference documents** - personaProperties.md AND principlesCrafting.md
|
||||
- **ALWAYS load the builtYaml** for actual persona content validation
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** Load and validate EVERYTHING specified in the personaProperties.md file
|
||||
- **🚫 NO MENU in this step** - record findings and auto-advance
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the persona validation reference from `{personaProperties}`
|
||||
2. Read the principles crafting guide from `{principlesCrafting}`
|
||||
3. Read the built agent YAML from `{builtYaml}`
|
||||
4. Read the edit plan from `{editPlan}`
|
||||
5. Extract the persona section from the builtYaml
|
||||
6. Compare actual persona against ALL validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
|
||||
Perform these checks systematically - validate EVERY rule specified in personaProperties.md:
|
||||
|
||||
1. **Required Fields Existence**
|
||||
- [ ] role: Present, clear, and specific
|
||||
- [ ] identity: Present and defines who the agent is
|
||||
- [ ] communication_style: Present and appropriate to role
|
||||
- [ ] principles: Present as array, not empty (if applicable)
|
||||
|
||||
2. **Content Quality - Role**
|
||||
- [ ] Role is specific (not generic like "assistant")
|
||||
- [ ] Role aligns with agent's purpose and menu items
|
||||
- [ ] Role is achievable within LLM capabilities
|
||||
- [ ] Role scope is appropriate (not too broad/narrow)
|
||||
|
||||
3. **Content Quality - Identity**
|
||||
- [ ] Identity clearly defines the agent's character
|
||||
- [ ] Identity is consistent with the role
|
||||
- [ ] Identity provides context for behavior
|
||||
- [ ] Identity is not generic or cliché
|
||||
|
||||
4. **Content Quality - Communication Style**
|
||||
- [ ] Communication style is clearly defined
|
||||
- [ ] Style matches the role and target users
|
||||
- [ ] Style is consistent throughout the definition
|
||||
- [ ] Style examples or guidance provided if nuanced
|
||||
- [ ] Style focuses on speech patterns only (not behavior)
|
||||
|
||||
5. **Content Quality - Principles**
|
||||
- [ ] Principles are actionable (not vague platitudes)
|
||||
- [ ] Principles guide behavior and decisions
|
||||
- [ ] Principles are consistent with role
|
||||
- [ ] 3-7 principles recommended (not overwhelming)
|
||||
- [ ] Each principle is clear and specific
|
||||
- [ ] First principle activates expert knowledge domain
|
||||
|
||||
6. **Consistency Checks**
|
||||
- [ ] Role, identity, communication_style, principles all align
|
||||
- [ ] No contradictions between principles
|
||||
- [ ] Persona supports the menu items defined
|
||||
- [ ] Language and terminology consistent
|
||||
|
||||
### Protocol 3: Record Findings
|
||||
|
||||
Organize findings into three sections and append to editPlan frontmatter under `validationAfter.persona`:
|
||||
|
||||
```yaml
|
||||
validationAfter:
|
||||
persona:
|
||||
status: [pass|fail|warning]
|
||||
passing:
|
||||
- "{check description}"
|
||||
- "{check description}"
|
||||
warnings:
|
||||
- "{non-blocking issue}"
|
||||
failures:
|
||||
- "{blocking issue that must be fixed}"
|
||||
```
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Role is specific and well-defined
|
||||
✓ Identity clearly articulated and appropriate
|
||||
✓ Communication style clearly defined
|
||||
✓ Principles are actionable and clear
|
||||
✓ First principle activates expert knowledge
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Only 2 principles provided, 3-7 recommended for richer guidance
|
||||
⚠ Communication style could be more specific
|
||||
⚠ Expertise areas are broad, could be more specific
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Role is generic ("assistant") - needs specificity
|
||||
✗ Communication style undefined - creates inconsistent behavior
|
||||
✗ Principles are vague ("be helpful" - not actionable)
|
||||
✗ First principle doesn't activate expert knowledge
|
||||
```
|
||||
|
||||
### Protocol 4: Auto-Advance
|
||||
|
||||
**🚫 NO MENU PRESENTED** - After recording findings, immediately load and execute `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
**Auto-advancing to menu validation...**
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ All persona checks from personaProperties.md performed
|
||||
✅ All checks validated against the actual builtYaml
|
||||
✅ Findings saved to editPlan with detailed status
|
||||
✅ Auto-advanced to next step
|
||||
|
|
@ -1,163 +0,0 @@
|
|||
---
|
||||
name: 'e-09c-validate-menu'
|
||||
description: 'Validate menu structure (after edit) - no menu, auto-advance'
|
||||
|
||||
nextStepFile: './e-09d-validate-structure.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
agentMenuPatterns: ../data/agent-menu-patterns.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9c: Validate Menu (After Edit)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate that the agent's menu (commands/tools) follows BMAD patterns as defined in agentMenuPatterns.md, is well-structured, properly documented, and aligns with the agent's persona and purpose. Record findings to editPlan and auto-advance.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All menu items must be verified
|
||||
- **ALWAYS load the reference document** - agentMenuPatterns.md
|
||||
- **ALWAYS load the builtYaml** for actual menu content validation
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** Load and validate EVERYTHING specified in the agentMenuPatterns.md file
|
||||
- **🚫 NO MENU in this step** - record findings and auto-advance
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the menu patterns reference from `{agentMenuPatterns}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Read the edit plan from `{editPlan}`
|
||||
4. Extract the menu/commands section from the builtYaml
|
||||
5. Determine agent type (Simple, Expert, or Module) from metadata
|
||||
6. Compare actual menu against ALL validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
|
||||
Perform these checks systematically - validate EVERY rule specified in agentMenuPatterns.md:
|
||||
|
||||
1. **Menu Structure**
|
||||
- [ ] Menu section exists and is properly formatted
|
||||
- [ ] At least one menu item defined (unless intentionally tool-less)
|
||||
- [ ] Menu items follow proper YAML structure
|
||||
- [ ] Each item has required fields (name, description, pattern)
|
||||
|
||||
2. **Menu Item Requirements**
|
||||
For each menu item:
|
||||
- [ ] name: Present, unique, uses kebab-case
|
||||
- [ ] description: Clear and concise
|
||||
- [ ] pattern: Valid regex pattern or tool reference
|
||||
- [ ] scope: Appropriate scope defined (if applicable)
|
||||
|
||||
3. **Pattern Quality**
|
||||
- [ ] Patterns are valid and testable
|
||||
- [ ] Patterns are specific enough to match intended inputs
|
||||
- [ ] Patterns are not overly restrictive
|
||||
- [ ] Patterns use appropriate regex syntax
|
||||
|
||||
4. **Description Quality**
|
||||
- [ ] Each item has clear description
|
||||
- [ ] Descriptions explain what the item does
|
||||
- [ ] Descriptions are consistent in style
|
||||
- [ ] Descriptions help users understand when to use
|
||||
|
||||
5. **Alignment Checks**
|
||||
- [ ] Menu items align with agent's role/purpose
|
||||
- [ ] Menu items are supported by agent's expertise
|
||||
- [ ] Menu items fit within agent's constraints
|
||||
- [ ] Menu items are appropriate for target users
|
||||
|
||||
6. **Completeness**
|
||||
- [ ] Core capabilities for this role are covered
|
||||
- [ ] No obvious missing functionality
|
||||
- [ ] Menu scope is appropriate (not too sparse/overloaded)
|
||||
- [ ] Related functionality is grouped logically
|
||||
|
||||
7. **Standards Compliance**
|
||||
- [ ] No prohibited patterns or commands
|
||||
- [ ] No security vulnerabilities in patterns
|
||||
- [ ] No ambiguous or conflicting items
|
||||
- [ ] Consistent naming conventions
|
||||
|
||||
8. **Menu Link Validation (Agent Type Specific)**
|
||||
- [ ] Determine agent type from metadata:
|
||||
- Simple: module property is 'stand-alone' AND hasSidecar is false/absent
|
||||
- Expert: hasSidecar is true
|
||||
- Module: module property is a module code (e.g., 'bmm', 'bmb', 'bmgd', 'bmad')
|
||||
- [ ] For Expert agents (hasSidecar: true):
|
||||
- Menu handlers SHOULD reference external sidecar files (e.g., `./{agent-name}-sidecar/...`)
|
||||
- OR have inline prompts defined directly in the handler
|
||||
- [ ] For Module agents (module property is a module code):
|
||||
- Menu handlers SHOULD reference external module files under the module path
|
||||
- Exec paths must start with `{project-root}/_bmad/{module}/...`
|
||||
- Verify referenced files exist under the module directory
|
||||
- [ ] For Simple agents (stand-alone, no sidecar):
|
||||
- Menu handlers MUST NOT have external file links
|
||||
- Menu handlers SHOULD only use relative links within the same file (e.g., `#section-name`)
|
||||
- OR have inline prompts defined directly in the handler
|
||||
|
||||
### Protocol 3: Record Findings
|
||||
|
||||
Organize findings into three sections and append to editPlan frontmatter under `validationAfter.menu`:
|
||||
|
||||
```yaml
|
||||
validationAfter:
|
||||
menu:
|
||||
status: [pass|fail|warning]
|
||||
passing:
|
||||
- "{check description}"
|
||||
- "{check description}"
|
||||
warnings:
|
||||
- "{non-blocking issue}"
|
||||
failures:
|
||||
- "{blocking issue that must be fixed}"
|
||||
```
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Menu structure properly formatted
|
||||
✓ 5 menu items defined, all with required fields
|
||||
✓ All patterns are valid regex
|
||||
✓ Menu items align with agent role
|
||||
✓ Agent type appropriate menu links verified
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Item "analyze-data" description is vague
|
||||
⚠ No menu item for [common capability X]
|
||||
⚠ Pattern for "custom-command" very broad, may over-match
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Duplicate menu item name: "process" appears twice
|
||||
✗ Invalid regex pattern: "[unclosed bracket"
|
||||
✗ Menu item "system-admin" violates security guidelines
|
||||
✗ No menu items defined for agent type that requires tools
|
||||
✗ Simple agent has external link in menu handler (should be relative # or inline)
|
||||
✗ Expert agent with sidecar has no external file links or inline prompts defined
|
||||
✗ Module agent exec path doesn't start with {project-root}/_bmad/{module}/...
|
||||
✗ Module agent references file that doesn't exist in module directory
|
||||
```
|
||||
|
||||
### Protocol 4: Auto-Advance
|
||||
|
||||
**🚫 NO MENU PRESENTED** - After recording findings, immediately load and execute `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
**Auto-advancing to structure validation...**
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ All menu checks from agentMenuPatterns.md performed
|
||||
✅ All checks validated against the actual builtYaml
|
||||
✅ Agent type-specific link validation performed
|
||||
✅ Findings saved to editPlan with detailed status
|
||||
✅ Auto-advanced to next step
|
||||
|
|
@ -1,154 +0,0 @@
|
|||
---
|
||||
name: 'e-09d-validate-structure'
|
||||
description: 'Validate YAML structure (after edit) - no menu, auto-advance'
|
||||
|
||||
nextStepFile: './e-09e-validate-sidecar.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
simpleValidation: ../data/simple-agent-validation.md
|
||||
expertValidation: ../data/expert-agent-validation.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9d: Validate Structure (After Edit)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate the built agent YAML file for structural completeness and correctness against the appropriate validation checklist (simple or expert) from agentCompilation.md. Record findings to editPlan and auto-advance.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation** - All agents must pass structural validation
|
||||
- **ALWAYS use the correct validation checklist** based on agent type (simple vs expert)
|
||||
- **ALWAYS load the builtYaml** for actual structure validation
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** Load and validate EVERYTHING specified in the agentCompilation.md file
|
||||
- **MUST check hasSidecar flag** to determine correct validation standard
|
||||
- **🚫 NO MENU in this step** - record findings and auto-advance
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the agent compilation reference from `{agentCompilation}`
|
||||
2. Read the simple validation checklist from `{simpleValidation}`
|
||||
3. Read the expert validation checklist from `{expertValidation}`
|
||||
4. Read the built agent YAML from `{builtYaml}`
|
||||
5. Read the edit plan from `{editPlan}`
|
||||
6. Determine agent type (simple vs expert) to select correct checklist
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
|
||||
Perform these checks systematically - validate EVERY rule specified in agentCompilation.md:
|
||||
|
||||
#### A. YAML Syntax Validation
|
||||
- [ ] Parse YAML without errors
|
||||
- [ ] Check indentation consistency (2-space standard)
|
||||
- [ ] Validate proper escaping of special characters
|
||||
- [ ] Verify no duplicate keys in any section
|
||||
|
||||
#### B. Frontmatter Validation
|
||||
- [ ] All required fields present (name, description, version, etc.)
|
||||
- [ ] Field values are correct type (string, boolean, array)
|
||||
- [ ] No empty required fields
|
||||
- [ ] Proper array formatting with dashes
|
||||
- [ ] Boolean fields are actual booleans (not strings)
|
||||
|
||||
#### C. Section Completeness
|
||||
- [ ] All required sections present based on agent type
|
||||
- [ ] Sections not empty unless explicitly optional
|
||||
- [ ] Proper markdown heading hierarchy (##, ###)
|
||||
- [ ] No orphaned content without section headers
|
||||
|
||||
#### D. Field-Level Validation
|
||||
- [ ] Path references exist and are valid
|
||||
- [ ] Array fields properly formatted
|
||||
- [ ] No malformed YAML structures
|
||||
- [ ] File references use correct path format
|
||||
|
||||
#### E. Agent Type Specific Checks
|
||||
|
||||
**For Simple Agents (hasSidecar is false/absent, module is 'stand-alone'):**
|
||||
- [ ] No sidecar requirements
|
||||
- [ ] No sidecar-folder path in metadata
|
||||
- [ ] Basic fields complete
|
||||
- [ ] No expert-only configuration present
|
||||
- [ ] Menu handlers use only internal references (#) or inline prompts
|
||||
|
||||
**For Expert Agents (hasSidecar is true):**
|
||||
- [ ] Sidecar flag set correctly in metadata
|
||||
- [ ] Sidecar folder path specified in metadata
|
||||
- [ ] All expert fields present
|
||||
- [ ] Advanced features properly configured
|
||||
- [ ] Menu handlers reference sidecar files or have inline prompts
|
||||
|
||||
**For Module Agents (module is a module code like 'bmm', 'bmb', etc.):**
|
||||
- [ ] Module property is valid module code
|
||||
- [ ] Exec paths for menu handlers start with `{project-root}/_bmad/{module}/...`
|
||||
- [ ] Referenced files exist under the module directory
|
||||
- [ ] If also hasSidecar: true, sidecar configuration is valid
|
||||
|
||||
### Protocol 3: Record Findings
|
||||
|
||||
Organize findings into three sections and append to editPlan frontmatter under `validationAfter.structure`:
|
||||
|
||||
```yaml
|
||||
validationAfter:
|
||||
structure:
|
||||
agentType: [simple|expert|module]
|
||||
status: [pass|fail|warning]
|
||||
passing:
|
||||
- "{check description}"
|
||||
- "{check description}"
|
||||
warnings:
|
||||
- "{non-blocking issue}"
|
||||
failures:
|
||||
- "{blocking issue that must be fixed}"
|
||||
```
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Valid YAML syntax, no parse errors
|
||||
✓ All required frontmatter fields present
|
||||
✓ Proper 2-space indentation throughout
|
||||
✓ All required sections complete for agent type
|
||||
✓ Path references are valid
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Some optional sections are empty
|
||||
⚠ Minor formatting inconsistencies
|
||||
⚠ Some descriptions are brief
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ YAML syntax error preventing parsing
|
||||
✗ Duplicate key 'name' in metadata
|
||||
✗ Required field 'description' is empty
|
||||
✗ Invalid boolean value 'yes' (should be true/false)
|
||||
✗ Path reference points to non-existent file
|
||||
✗ Simple agent has sidecar-folder specified
|
||||
✗ Expert agent missing sidecar-folder path
|
||||
```
|
||||
|
||||
### Protocol 4: Auto-Advance
|
||||
|
||||
**🚫 NO MENU PRESENTED** - After recording findings, immediately load and execute `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
**Auto-advancing to sidecar validation...**
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ All structure checks from agentCompilation.md performed
|
||||
✅ Correct validation checklist used based on agent type
|
||||
✅ All checks validated against the actual builtYaml
|
||||
✅ Findings saved to editPlan with detailed status
|
||||
✅ Agent type correctly identified and validated
|
||||
✅ Auto-advanced to next step
|
||||
|
|
@ -1,160 +0,0 @@
|
|||
---
|
||||
name: 'e-09e-validate-sidecar'
|
||||
description: 'Validate sidecar structure (after edit) - no menu, auto-advance'
|
||||
|
||||
nextStepFile: './e-09f-validation-summary.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
expertValidation: ../data/expert-agent-validation.md
|
||||
criticalActions: ../data/critical-actions.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
sidecarFolder: '{bmb_creations_output_folder}/{agent-name}/{agent-name}-sidecar/'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9e: Validate Sidecar (After Edit)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate the sidecar folder structure and referenced paths for Expert agents to ensure all sidecar files exist, are properly structured, and paths in the main agent YAML correctly reference them. Record findings to editPlan and auto-advance. For Simple agents without sidecar, mark as N/A.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **ONLY validates for Expert agents** - Simple agents should have no sidecar
|
||||
- **MUST verify sidecar folder exists** before validating contents
|
||||
- **ALWAYS cross-reference YAML paths** with actual files
|
||||
- **ALWAYS load the builtYaml** to get sidecar configuration
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** Load and validate EVERYTHING specified in the expertValidation.md file
|
||||
- **PROVIDE clear remediation steps** for any missing or malformed files
|
||||
- **🚫 NO MENU in this step** - record findings and auto-advance
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the expert validation reference from `{expertValidation}`
|
||||
2. Read the critical actions reference from `{criticalActions}`
|
||||
3. Read the built agent YAML from `{builtYaml}`
|
||||
4. Read the edit plan from `{editPlan}`
|
||||
5. Determine if agent has sidecar from metadata
|
||||
|
||||
### Protocol 2: Conditional Validation
|
||||
|
||||
**IF agent has hasSidecar: false OR agent is Simple:**
|
||||
- [ ] Mark sidecar validation as N/A
|
||||
- [ ] Confirm no sidecar-folder path in metadata
|
||||
- [ ] Confirm no sidecar references in menu handlers
|
||||
|
||||
**IF agent has hasSidecar: true OR agent is Expert/Module with sidecar:**
|
||||
- [ ] Proceed with full sidecar validation
|
||||
|
||||
### Protocol 3: Sidecar Validation Checks (For Expert Agents)
|
||||
|
||||
Perform these checks systematically - validate EVERY rule specified in expertValidation.md:
|
||||
|
||||
#### A. Sidecar Folder Validation
|
||||
- [ ] Sidecar folder exists at specified path
|
||||
- [ ] Sidecar folder is accessible and readable
|
||||
- [ ] Sidecar folder path in metadata matches actual location
|
||||
- [ ] Folder naming follows convention: `{agent-name}-sidecar`
|
||||
|
||||
#### B. Sidecar File Inventory
|
||||
- [ ] List all files in sidecar folder
|
||||
- [ ] Verify expected files are present
|
||||
- [ ] Check for unexpected files
|
||||
- [ ] Validate file names follow conventions
|
||||
|
||||
#### C. Path Reference Validation
|
||||
For each sidecar path reference in agent YAML:
|
||||
- [ ] Extract path from YAML reference
|
||||
- [ ] Verify file exists at referenced path
|
||||
- [ ] Check path format is correct (relative/absolute as expected)
|
||||
- [ ] Validate no broken path references
|
||||
|
||||
#### D. Critical Actions File Validation (if present)
|
||||
- [ ] critical-actions.md file exists
|
||||
- [ ] File has proper frontmatter
|
||||
- [ ] Actions section is present and not empty
|
||||
- [ ] No critical sections missing
|
||||
- [ ] File content is complete (not just placeholder)
|
||||
|
||||
#### E. Module Files Validation (if present)
|
||||
- [ ] Module files exist at referenced paths
|
||||
- [ ] Each module file has proper frontmatter
|
||||
- [ ] Module file content is complete
|
||||
- [ ] No empty or placeholder module files
|
||||
|
||||
#### F. Sidecar Structure Completeness
|
||||
- [ ] All referenced sidecar files present
|
||||
- [ ] No orphaned references (files referenced but not present)
|
||||
- [ ] No unreferenced files (files present but not referenced)
|
||||
- [ ] File structure matches expert agent requirements
|
||||
|
||||
### Protocol 4: Record Findings
|
||||
|
||||
Organize findings into three sections and append to editPlan frontmatter under `validationAfter.sidecar`:
|
||||
|
||||
```yaml
|
||||
validationAfter:
|
||||
sidecar:
|
||||
hasSidecar: [true|false]
|
||||
status: [pass|fail|warning|n/a]
|
||||
passing:
|
||||
- "{check description}"
|
||||
- "{check description}"
|
||||
warnings:
|
||||
- "{non-blocking issue}"
|
||||
failures:
|
||||
- "{blocking issue that must be fixed}"
|
||||
```
|
||||
|
||||
**PASSING CHECKS** (List what passed - for Expert agents)**
|
||||
```
|
||||
✓ Sidecar folder exists at expected path
|
||||
✓ All referenced files present
|
||||
✓ No broken path references
|
||||
✓ Critical actions file complete
|
||||
✓ Module files properly structured
|
||||
✓ File structure matches expert requirements
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Additional files in sidecar not referenced
|
||||
⚠ Some module files are minimal
|
||||
⚠ Sidecar has no modules (may be intentional)
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Sidecar folder completely missing
|
||||
✗ Sidecar folder path in metadata doesn't match actual location
|
||||
✗ Critical file missing: critical-actions.md
|
||||
✗ Broken path reference: {path} not found
|
||||
✗ Referenced file is empty or placeholder
|
||||
✗ Module file missing frontmatter
|
||||
✗ Simple agent has sidecar configuration (should not)
|
||||
```
|
||||
|
||||
**N/A FOR SIMPLE AGENTS:**
|
||||
```
|
||||
N/A - Agent is Simple type (hasSidecar: false, no sidecar required)
|
||||
```
|
||||
|
||||
### Protocol 5: Auto-Advance
|
||||
|
||||
**🚫 NO MENU PRESENTED** - After recording findings, immediately load and execute `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
**Auto-advancing to validation summary...**
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ All sidecar checks from expertValidation.md performed (or N/A for Simple)
|
||||
✅ All checks validated against the actual builtYaml and file system
|
||||
✅ Findings saved to editPlan with detailed status
|
||||
✅ Agent type correctly identified (sidecar vs non-sidecar)
|
||||
✅ Auto-advanced to next step
|
||||
|
|
@ -1,111 +0,0 @@
|
|||
---
|
||||
name: 'e-09f-validation-summary'
|
||||
description: 'Display all validation findings after edit'
|
||||
|
||||
nextStepFile: './e-10-celebrate.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9f: Validation Summary (After Edit)
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Display all post-edit validation findings and compare with pre-edit state. Present findings and await confirmation to proceed to celebration.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: Read editPlan to collect all validation findings
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Display all validation findings clearly organized
|
||||
- 📊 Compare before/after states
|
||||
- 💬 Present options for handling any remaining issues
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Read editPlan to get validation findings
|
||||
- 📊 Display organized summary with before/after comparison
|
||||
- 💾 Allow user to decide how to proceed
|
||||
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Validation Findings
|
||||
|
||||
Read `{editPlan}` frontmatter to collect validationBefore and validationAfter findings.
|
||||
|
||||
### 2. Display Validation Summary
|
||||
|
||||
```markdown
|
||||
## Post-Edit Validation Report for {agent-name}
|
||||
|
||||
### Before vs After Comparison
|
||||
|
||||
| Component | Before | After | Status |
|
||||
|-----------|--------|-------|--------|
|
||||
| Metadata | {status} | {status} | {Δ} |
|
||||
| Persona | {status} | {status} | {Δ} |
|
||||
| Menu | {status} | {status} | {Δ} |
|
||||
| Structure | {status} | {status} | {Δ} |
|
||||
| Sidecar | {status} | {status} | {Δ} |
|
||||
|
||||
### Detailed Findings (After Edit)
|
||||
|
||||
**Metadata:** {summary}
|
||||
**Persona:** {summary}
|
||||
**Menu:** {summary}
|
||||
**Structure:** {summary}
|
||||
**Sidecar:** {summary}
|
||||
```
|
||||
|
||||
### 3. Present Options
|
||||
|
||||
"How do the edits look?
|
||||
|
||||
**[R]eview** - Show detailed before/after for any component
|
||||
**[F]ix** - Address any remaining issues
|
||||
**[A]ccept** - Proceed to celebration"
|
||||
|
||||
### 4. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Celebration"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF R: Show detailed before/after comparison, then redisplay menu
|
||||
- IF C: Save validation summary to {editPlan}, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-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
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation summary displayed], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All validation findings displayed clearly
|
||||
- Before/after comparison shown
|
||||
- User given options for handling issues
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Findings not displayed to user
|
||||
- Proceeding without user acknowledgment
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -34,7 +34,9 @@ Load the existing agent file and initialize a validation report to track all fin
|
|||
- 💾 Create validation report document
|
||||
- 🚫 FORBIDDEN to proceed without user confirmation
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Agent File
|
||||
|
||||
|
|
@ -68,7 +70,7 @@ Initialize the validation report:
|
|||
```markdown
|
||||
---
|
||||
agentName: '{agent-name}'
|
||||
agentType: '{simple|expert|module}'
|
||||
agentType: '{simple|expert|module}' # Derived from module + hasSidecar
|
||||
agentFile: '{agent-file-path}'
|
||||
validationDate: '{YYYY-MM-DD}'
|
||||
stepsCompleted:
|
||||
|
|
@ -80,8 +82,9 @@ stepsCompleted:
|
|||
## Agent Overview
|
||||
|
||||
**Name:** {agent-name}
|
||||
**Type:** {simple|expert|module}
|
||||
**Version:** {version}
|
||||
**Type:** {simple|expert|module} # Derived from: module + hasSidecar
|
||||
**module:** {module-value}
|
||||
**hasSidecar:** {true|false}
|
||||
**File:** {agent-file-path}
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -36,7 +36,9 @@ Validate the agent's metadata properties against BMAD standards as defined in ag
|
|||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,9 @@ Validate the agent's persona against BMAD standards as defined in personaPropert
|
|||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,9 @@ Validate the agent's command menu structure against BMAD standards as defined in
|
|||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,9 @@ Validate the agent's YAML structure and completeness against BMAD standards as d
|
|||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,9 @@ Validate the agent's sidecar structure (if Expert type) against BMAD standards a
|
|||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to summary step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
|
@ -46,7 +48,7 @@ Read `{expertValidation}`, `{criticalActions}`, `{validationReport}`, and `{agen
|
|||
|
||||
### 2. Conditional Validation
|
||||
|
||||
**IF agentType == expert OR (agentType == module AND hasSidecar == true):**
|
||||
**IF (module = "stand-alone" AND hasSidecar = true) OR (module ≠ "stand-alone" AND hasSidecar = true):**
|
||||
Perform these checks systematically - validate EVERY rule specified in expertValidation.md:
|
||||
|
||||
#### A. Sidecar Folder Validation
|
||||
|
|
@ -87,7 +89,7 @@ For each sidecar path reference in agent YAML:
|
|||
- [ ] No unreferenced files (files present but not referenced)
|
||||
- [ ] File structure matches expert agent requirements
|
||||
|
||||
**IF agentType is Simple (no sidecar):**
|
||||
**IF (module = "stand-alone" AND hasSidecar = false):**
|
||||
- [ ] Mark sidecar validation as N/A
|
||||
- [ ] Confirm no sidecar-folder path in metadata
|
||||
- [ ] Confirm no sidecar references in menu handlers
|
||||
|
|
@ -122,7 +124,7 @@ Append to `{validationReport}`:
|
|||
{List of blocking issues that must be fixed}
|
||||
|
||||
*N/A (for Simple agents):*
|
||||
N/A - Agent is Simple type (hasSidecar: false, no sidecar required)
|
||||
N/A - Agent is Simple type (module = "stand-alone" + hasSidecar: false, no sidecar required)
|
||||
```
|
||||
|
||||
### 4. Auto-Advance
|
||||
|
|
|
|||
|
|
@ -32,7 +32,9 @@ Display the complete validation report to the user and offer options for fixing
|
|||
- 📊 Display organized summary
|
||||
- 💾 Allow user to decide next steps
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Validation Report
|
||||
|
||||
|
|
|
|||
|
|
@ -1,158 +0,0 @@
|
|||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize workflow creation session by gathering project information and setting up unique workflow folder'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-01-init.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-gather.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
# Template References
|
||||
# No workflow plan template needed - will create plan file directly
|
||||
---
|
||||
|
||||
# Step 1: Workflow Creation Initialization
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To initialize the workflow creation process by understanding project context, determining a unique workflow name, and preparing for collaborative workflow design.
|
||||
|
||||
## 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 expertise, user brings their specific requirements
|
||||
- ✅ Together we will create a structured, repeatable workflow
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on initialization and project understanding
|
||||
- 🚫 FORBIDDEN to start designing workflow steps in this step
|
||||
- 💬 Ask questions conversationally to understand context
|
||||
- 🚪 ENSURE unique workflow naming to avoid conflicts
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show analysis before taking any action
|
||||
- 💾 Initialize document and update frontmatter
|
||||
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until initialization is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Variables from workflow.md are available in memory
|
||||
- Previous context = what's in output document + frontmatter
|
||||
- Don't assume knowledge from other steps
|
||||
- Input discovery happens in this step
|
||||
|
||||
## INITIALIZATION SEQUENCE:
|
||||
|
||||
### 1. Project Discovery
|
||||
|
||||
Welcome the user and understand their needs:
|
||||
"Welcome! I'm excited to help you create a new workflow. Let's start by understanding what you want to build."
|
||||
|
||||
Ask conversationally:
|
||||
|
||||
- What type of workflow are you looking to create?
|
||||
- What problem will this workflow solve?
|
||||
- Who will use this workflow?
|
||||
- What module will it belong to (bmb, bmm, cis, custom, stand-alone)?
|
||||
|
||||
Also, Ask / suggest a workflow name / folder: (kebab-case, e.g., "user-story-generator")
|
||||
|
||||
### 2. Ensure Unique Workflow Name
|
||||
|
||||
After getting the workflow name:
|
||||
|
||||
**Check for existing workflows:**
|
||||
|
||||
- Look for folder at `{bmb_creations_output_folder}/workflows/{new_workflow_name}/`
|
||||
- If it exists, inform the user and suggest or get from them a unique name or postfix
|
||||
|
||||
**Example alternatives:**
|
||||
|
||||
- Original: "user-story-generator"
|
||||
- Alternatives: "user-story-creator", "user-story-generator-2025", "user-story-generator-enhanced"
|
||||
|
||||
**Loop until we have a unique name that doesn't conflict.**
|
||||
|
||||
### 3. Determine Target Location
|
||||
|
||||
Based on the module selection, confirm the target location:
|
||||
|
||||
- For bmb module: `{custom_workflow_location}` (defaults to `_bmad/custom/src/workflows`)
|
||||
- For other modules: Check their module.yaml for custom workflow locations
|
||||
- Confirm the exact folder path where the workflow will be created
|
||||
- Store the confirmed path as `{targetWorkflowPath}`
|
||||
|
||||
### 4. Create Workflow Plan Document
|
||||
|
||||
Create the workflow plan document at `{workflowPlanFile}` with the following initial content:
|
||||
|
||||
```markdown
|
||||
---
|
||||
stepsCompleted: [1]
|
||||
---
|
||||
|
||||
# Workflow Creation Plan: {new_workflow_name}
|
||||
|
||||
## Initial Project Context
|
||||
|
||||
- **Module:** [module from user]
|
||||
- **Target Location:** {targetWorkflowPath}
|
||||
- **Created:** [current date]
|
||||
```
|
||||
|
||||
This plan will capture all requirements and design details before building the actual workflow.
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **Proceeding to requirements gathering...**
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- This is an initialization step with no user choices
|
||||
- Proceed directly to next step after setup
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- After setup completion and the workflow folder with the workflow plan file created already, only then immediately load, read entire file, and then execute `{workflow_path}/steps/step-02-gather.md` to begin requirements gathering
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Workflow name confirmed and validated
|
||||
- Target folder location determined
|
||||
- User welcomed and project context understood
|
||||
- Ready to proceed to step 2
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding with step 2 without workflow name
|
||||
- Not checking for existing workflow folders
|
||||
- Not determining target location properly
|
||||
- Skipping welcome message
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,212 +0,0 @@
|
|||
---
|
||||
name: 'step-02-gather'
|
||||
description: 'Gather comprehensive requirements for the workflow being created'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-02-gather.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-03-tools-configuration.md'
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
# Template References
|
||||
# No template needed - will append requirements directly to workflow plan
|
||||
---
|
||||
|
||||
# Step 2: Requirements Gathering
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To gather comprehensive requirements through collaborative conversation that will inform the design of a structured workflow tailored to the user's needs and use case.
|
||||
|
||||
## 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 expertise and best practices
|
||||
- ✅ User brings their domain knowledge and specific requirements
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on collecting requirements and understanding needs
|
||||
- 🚫 FORBIDDEN to propose workflow solutions or step designs in this step
|
||||
- 💬 Ask questions conversationally, not like a form
|
||||
- 🚫 DO NOT skip any requirement area - each affects workflow design
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Engage in natural conversation to gather requirements
|
||||
- 💾 Store all requirements information for workflow design
|
||||
- 📖 Proceed to next step with 'C' selection
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Workflow name and target location from initialization
|
||||
- Focus ONLY on collecting requirements and understanding needs
|
||||
- Don't provide workflow designs in this step
|
||||
- This is about understanding, not designing
|
||||
|
||||
## REQUIREMENTS GATHERING PROCESS:
|
||||
|
||||
### 1. Workflow Purpose and Scope
|
||||
|
||||
Explore through conversation:
|
||||
|
||||
- What specific problem will this workflow solve?
|
||||
- Who is the primary user of this workflow?
|
||||
- What is the main outcome or deliverable?
|
||||
|
||||
### 2. Workflow Type Classification
|
||||
|
||||
Help determine the workflow type:
|
||||
|
||||
- **Document Workflow**: Generates documents (PRDs, specs, plans)
|
||||
- **Action Workflow**: Performs actions (refactoring, tools orchestration)
|
||||
- **Interactive Workflow**: Guided sessions (brainstorming, coaching, training, practice)
|
||||
- **Autonomous Workflow**: Runs without human input (batch processing, multi-step tasks)
|
||||
- **Meta-Workflow**: Coordinates other workflows
|
||||
|
||||
### 3. Workflow Flow and Step Structure
|
||||
|
||||
Let's load some examples to help you decide the workflow pattern:
|
||||
|
||||
Load and reference the Meal Prep & Nutrition Plan workflow as an example:
|
||||
|
||||
```
|
||||
Read: {project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/workflow.md
|
||||
```
|
||||
|
||||
This shows a linear workflow structure. Now let's explore your desired pattern:
|
||||
|
||||
- Should this be a linear workflow (step 1 → step 2 → step 3 → finish)?
|
||||
- Or should it have loops/repeats (e.g., keep generating items until user says done)?
|
||||
- Are there branching points based on user choices?
|
||||
- Should some steps be optional?
|
||||
- How many logical phases does this workflow need? (e.g., Gather → Design → Validate → Generate)
|
||||
|
||||
**Based on our reference examples:**
|
||||
|
||||
- **Linear**: Like Meal Prep Plan (Init → Profile → Assessment → Strategy → Shopping → Prep)
|
||||
- See: `{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/`
|
||||
- **Looping**: User Story Generator (Generate → Review → Refine → Generate more... until done)
|
||||
- **Branching**: Architecture Decision (Analyze → Choose pattern → Implement based on choice)
|
||||
- **Iterative**: Document Review (Load → Analyze → Suggest changes → Implement → Repeat until approved)
|
||||
|
||||
### 4. User Interaction Style
|
||||
|
||||
Understand the desired interaction level:
|
||||
|
||||
- How much user input is needed during execution?
|
||||
- Should it be highly collaborative or mostly autonomous?
|
||||
- Are there specific decision points where user must choose?
|
||||
- Should the workflow adapt to user responses?
|
||||
|
||||
### 5. Instruction Style (Intent-Based vs Prescriptive)
|
||||
|
||||
Determine how the AI should execute in this workflow:
|
||||
|
||||
**Intent-Based (Recommended for most workflows)**:
|
||||
|
||||
- Steps describe goals and principles, letting the AI adapt conversation naturally
|
||||
- More flexible, conversational, responsive to user context
|
||||
- Example: "Guide user to define their requirements through open-ended discussion"
|
||||
|
||||
**Prescriptive**:
|
||||
|
||||
- Steps provide exact instructions and specific text to use
|
||||
- More controlled, predictable, consistent across runs
|
||||
- Example: "Ask: 'What is your primary goal? Choose from: A) Growth B) Efficiency C) Quality'"
|
||||
|
||||
Which style does this workflow need, or should it be a mix of both?
|
||||
|
||||
### 6. Input Requirements
|
||||
|
||||
Identify what the workflow needs:
|
||||
|
||||
- What documents or data does the workflow need to start?
|
||||
- Are there prerequisites or dependencies?
|
||||
- Will users need to provide specific information?
|
||||
- Are there optional inputs that enhance the workflow?
|
||||
|
||||
### 7. Output Specifications
|
||||
|
||||
Define what the workflow produces:
|
||||
|
||||
- What is the primary output (document, action, decision)?
|
||||
- Are there intermediate outputs or checkpoints?
|
||||
- Should outputs be saved automatically?
|
||||
- What format should outputs be in?
|
||||
|
||||
### 8. Success Criteria
|
||||
|
||||
Define what makes the workflow successful:
|
||||
|
||||
- How will you know the workflow achieved its goal?
|
||||
- What are the quality criteria for outputs?
|
||||
- Are there measurable outcomes?
|
||||
- What would make a user satisfied with the result?
|
||||
|
||||
#### STORE REQUIREMENTS:
|
||||
|
||||
After collecting all requirements, append them to {workflowPlanFile} in a format that will be be used later to design in more detail and create the workflow structure.
|
||||
|
||||
### 9. 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: Append requirements 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](#8-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and requirements are stored in the output file, will you then load, read entire file, then execute {nextStepFile} to execute and begin workflow structure design step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Requirements collected through conversation (not interrogation)
|
||||
- All workflow aspects documented
|
||||
- Requirements stored using template
|
||||
- Menu presented and user input handled correctly
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating workflow designs without requirements
|
||||
- Skipping requirement areas
|
||||
- Proceeding to next step without 'C' selection
|
||||
- Not storing requirements properly
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,251 +0,0 @@
|
|||
---
|
||||
name: 'step-03-tools-configuration'
|
||||
description: 'Configure all required tools (core, memory, external) and installation requirements in one comprehensive step'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-03-tools-configuration.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-04-plan-review.md'
|
||||
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Documentation References
|
||||
commonToolsCsv: '{project-root}/_bmad/bmb/docs/workflows/common-workflow-tools.csv'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
# Template References
|
||||
# No template needed - will append tools configuration directly to workflow plan
|
||||
---
|
||||
|
||||
# Step 3: Tools Configuration
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To comprehensively configure all tools needed for the workflow (core tools, memory, external tools) and determine installation 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 integration specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in BMAD tools and integration patterns
|
||||
- ✅ User brings their workflow requirements and preferences
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on configuring tools based on workflow requirements
|
||||
- 🚫 FORBIDDEN to skip tool categories - each affects workflow design
|
||||
- 💬 Present options clearly, let user make informed choices
|
||||
- 🚫 DO NOT hardcode tool descriptions - reference CSV
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load tools dynamically from CSV, not hardcoded
|
||||
- 💾 Document all tool choices in workflow plan
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Requirements from step 2 inform tool selection
|
||||
- All tool choices affect workflow design
|
||||
- This is the ONLY tools configuration step
|
||||
- Installation requirements affect implementation decisions
|
||||
|
||||
## TOOLS CONFIGURATION PROCESS:
|
||||
|
||||
### 1. Initialize Tools Configuration
|
||||
|
||||
"Configuring **Tools and Integrations**
|
||||
|
||||
Based on your workflow requirements, let's configure all the tools your workflow will need. This includes core BMAD tools, memory systems, and any external integrations."
|
||||
|
||||
### 2. Load and Present Available Tools
|
||||
|
||||
Load `{commonToolsCsv}` and present tools by category:
|
||||
|
||||
"**Available BMAD Tools and Integrations:**
|
||||
|
||||
**Core Tools (Always Available):**
|
||||
|
||||
- [List tools from CSV where propose='always', with descriptions]
|
||||
|
||||
**Optional Tools (Available When Needed):**
|
||||
|
||||
- [List tools from CSV where propose='example', with descriptions]
|
||||
|
||||
_Note: I'm loading these dynamically from our tools database to ensure you have the most current options._"
|
||||
|
||||
### 3. Configure Core BMAD Tools
|
||||
|
||||
"**Core BMAD Tools Configuration:**
|
||||
|
||||
These tools significantly enhance workflow quality and user experience:"
|
||||
|
||||
For each core tool from CSV (`propose='always'`):
|
||||
|
||||
1. **Party-Mode**
|
||||
- Use case: [description from CSV]
|
||||
- Where to integrate: [ask user for decision points, creative phases]
|
||||
|
||||
2. **Advanced Elicitation**
|
||||
- Use case: [description from CSV]
|
||||
- Where to integrate: [ask user for quality gates, review points]
|
||||
|
||||
3. **Brainstorming**
|
||||
- Use case: [description from CSV]
|
||||
- Where to integrate: [ask user for idea generation, innovation points]
|
||||
|
||||
### 4. Configure LLM Features
|
||||
|
||||
"**LLM Feature Integration:**
|
||||
|
||||
These capabilities enhance what your workflow can do:"
|
||||
|
||||
From CSV (`propose='always'` LLM features):
|
||||
|
||||
4. **Web-Browsing**
|
||||
- Capability: [description from CSV]
|
||||
- When needed: [ask user about real-time data needs]
|
||||
|
||||
5. **File I/O**
|
||||
- Capability: [description from CSV]
|
||||
- Operations: [ask user about file operations needed]
|
||||
|
||||
6. **Sub-Agents**
|
||||
- Capability: [description from CSV]
|
||||
- Use cases: [ask user about delegation needs]
|
||||
|
||||
7. **Sub-Processes**
|
||||
- Capability: [description from CSV]
|
||||
- Use cases: [ask user about parallel processing needs]
|
||||
|
||||
### 5. Configure Memory Systems
|
||||
|
||||
"**Memory and State Management:**
|
||||
|
||||
Determine if your workflow needs to maintain state between sessions:"
|
||||
|
||||
From CSV memory tools:
|
||||
|
||||
8. **Sidecar File**
|
||||
- Use case: [description from CSV]
|
||||
- Needed when: [ask about session continuity, agent initialization]
|
||||
|
||||
### 6. Configure External Tools (Optional)
|
||||
|
||||
"**External Integrations (Optional):**
|
||||
|
||||
These tools connect your workflow to external systems:"
|
||||
|
||||
From CSV (`propose='example'`):
|
||||
|
||||
- MCP integrations, database connections, APIs, etc.
|
||||
- For each relevant tool: present description and ask if needed
|
||||
- Note any installation requirements
|
||||
|
||||
### 7. Installation Requirements Assessment
|
||||
|
||||
"**Installation and Dependencies:**
|
||||
|
||||
Some tools require additional setup:"
|
||||
|
||||
Based on selected tools:
|
||||
|
||||
- Identify tools requiring installation
|
||||
- Assess user's comfort level with installations
|
||||
- Document installation requirements
|
||||
|
||||
### 8. Document Complete Tools Configuration
|
||||
|
||||
Append to {workflowPlanFile}:
|
||||
|
||||
```markdown
|
||||
## Tools Configuration
|
||||
|
||||
### Core BMAD Tools
|
||||
|
||||
- **Party-Mode**: [included/excluded] - Integration points: [specific phases]
|
||||
- **Advanced Elicitation**: [included/excluded] - Integration points: [specific phases]
|
||||
- **Brainstorming**: [included/excluded] - Integration points: [specific phases]
|
||||
|
||||
### LLM Features
|
||||
|
||||
- **Web-Browsing**: [included/excluded] - Use cases: [specific needs]
|
||||
- **File I/O**: [included/excluded] - Operations: [file management needs]
|
||||
- **Sub-Agents**: [included/excluded] - Use cases: [delegation needs]
|
||||
- **Sub-Processes**: [included/excluded] - Use cases: [parallel processing needs]
|
||||
|
||||
### Memory Systems
|
||||
|
||||
- **Sidecar File**: [included/excluded] - Purpose: [state management needs]
|
||||
|
||||
### External Integrations
|
||||
|
||||
- [List selected external tools with purposes]
|
||||
|
||||
### Installation Requirements
|
||||
|
||||
- [List tools requiring installation]
|
||||
- **User Installation Preference**: [willing/not willing]
|
||||
- **Alternative Options**: [if not installing certain tools]
|
||||
```
|
||||
|
||||
### 9. 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 tools configuration 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](#9-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and tools configuration is saved will you load {nextStepFile} to review the complete plan.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All tool categories configured based on requirements
|
||||
- User made informed choices for each tool
|
||||
- Complete configuration documented in plan
|
||||
- Installation requirements identified
|
||||
- Ready to proceed to plan review
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping tool categories
|
||||
- Hardcoding tool descriptions instead of using CSV
|
||||
- Not documenting user choices
|
||||
- Proceeding without user confirmation
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,217 +0,0 @@
|
|||
---
|
||||
name: 'step-04-plan-review'
|
||||
description: 'Review complete workflow plan (requirements + tools) and get user approval before design'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-04-plan-review.md'
|
||||
nextStepFormDesign: '{workflow_path}/steps/step-05-output-format-design.md'
|
||||
nextStepDesign: '{workflow_path}/steps/step-06-design.md'
|
||||
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
# Template References
|
||||
# No template needed - will append review summary directly to workflow plan
|
||||
---
|
||||
|
||||
# Step 4: Plan Review and Approval
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To present the complete workflow plan (requirements and tools configuration) for user review and approval before proceeding to design.
|
||||
|
||||
## 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 expertise in workflow design review and quality assurance
|
||||
- ✅ User brings their specific requirements and approval authority
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on reviewing and refining the plan
|
||||
- 🚫 FORBIDDEN to start designing workflow steps in this step
|
||||
- 💬 Present plan clearly and solicit feedback
|
||||
- 🚫 DO NOT proceed to design without user approval
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Present complete plan summary from {workflowPlanFile}
|
||||
- 💾 Capture any modifications or refinements
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user approves plan
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All requirements from step 2 are available
|
||||
- Tools configuration from step 3 is complete
|
||||
- Focus ONLY on review and approval
|
||||
- This is the final check before design phase
|
||||
|
||||
## PLAN REVIEW PROCESS:
|
||||
|
||||
### 1. Initialize Plan Review
|
||||
|
||||
"**Workflow Plan Review**
|
||||
|
||||
We've gathered all requirements and configured tools for your workflow. Let's review the complete plan to ensure it meets your needs before we start designing the workflow structure."
|
||||
|
||||
### 2. Present Complete Plan Summary
|
||||
|
||||
Load and present from {workflowPlanFile}:
|
||||
|
||||
"**Complete Workflow Plan: {new_workflow_name}**
|
||||
|
||||
**1. Project Overview:**
|
||||
|
||||
- [Present workflow purpose, user type, module from plan]
|
||||
|
||||
**2. Workflow Requirements:**
|
||||
|
||||
- [Present all gathered requirements]
|
||||
|
||||
**3. Tools Configuration:**
|
||||
|
||||
- [Present selected tools and integration points]
|
||||
|
||||
**4. Technical Specifications:**
|
||||
|
||||
- [Present technical constraints and requirements]
|
||||
|
||||
**5. Success Criteria:**
|
||||
|
||||
- [Present success metrics from requirements]"
|
||||
|
||||
### 3. Detailed Review by Category
|
||||
|
||||
"**Detailed Review:**
|
||||
|
||||
**A. Workflow Scope and Purpose**
|
||||
|
||||
- Is the workflow goal clearly defined?
|
||||
- Are the boundaries appropriate?
|
||||
- Any missing requirements?
|
||||
|
||||
**B. User Interaction Design**
|
||||
|
||||
- Does the interaction style match your needs?
|
||||
- Are collaboration points clear?
|
||||
- Any adjustments needed?
|
||||
|
||||
**C. Tools Integration**
|
||||
|
||||
- Are selected tools appropriate for your workflow?
|
||||
- Are integration points logical?
|
||||
- Any additional tools needed?
|
||||
|
||||
**D. Technical Feasibility**
|
||||
|
||||
- Are all requirements achievable?
|
||||
- Any technical constraints missing?
|
||||
- Installation requirements acceptable?"
|
||||
|
||||
### 4. Collect Feedback and Refinements
|
||||
|
||||
"**Review Feedback:**
|
||||
|
||||
Please review each section and provide feedback:
|
||||
|
||||
1. What looks good and should stay as-is?
|
||||
2. What needs modification or refinement?
|
||||
3. What's missing that should be added?
|
||||
4. Anything unclear or confusing?"
|
||||
|
||||
For each feedback item:
|
||||
|
||||
- Document the requested change
|
||||
- Discuss implications on workflow design
|
||||
- Confirm the refinement with user
|
||||
|
||||
### 5. Update Plan with Refinements
|
||||
|
||||
Update {workflowPlanFile} with any approved changes:
|
||||
|
||||
- Modify requirements section as needed
|
||||
- Update tools configuration if changed
|
||||
- Add any missing specifications
|
||||
- Ensure all changes are clearly documented
|
||||
|
||||
### 6. Output Document Check
|
||||
|
||||
"**Output Document Check:**
|
||||
|
||||
Before we proceed to design, does your workflow produce any output documents or files?
|
||||
|
||||
Based on your requirements:
|
||||
|
||||
- [Analyze if workflow produces documents/files]
|
||||
- Consider: Does it create reports, forms, stories, or any persistent output?"
|
||||
|
||||
**If NO:**
|
||||
"Great! Your workflow focuses on actions/interactions without document output. We'll proceed directly to designing the workflow steps."
|
||||
|
||||
**If YES:**
|
||||
"Perfect! Let's design your output format to ensure your workflow produces exactly what you need."
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Design
|
||||
|
||||
#### 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: Check if workflow produces documents:
|
||||
- If YES: Update frontmatter, then load nextStepFormDesign
|
||||
- If NO: Update frontmatter, then load nextStepDesign
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected AND the user has explicitly approved the plan and the plan document is updated as needed, then you load either {nextStepFormDesign} or {nextStepDesign}
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Complete plan presented clearly from {workflowPlanFile}
|
||||
- User feedback collected and documented
|
||||
- All refinements incorporated
|
||||
- User explicitly approves the plan
|
||||
- Plan ready for design phase
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not loading plan from {workflowPlanFile}
|
||||
- Skipping review categories
|
||||
- Proceeding without user approval
|
||||
- Not documenting refinements
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,290 +0,0 @@
|
|||
---
|
||||
name: 'step-05-output-format-design'
|
||||
description: 'Design the output format for workflows that produce documents or files'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-05-output-format-design.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-06-design.md'
|
||||
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Output Format Design
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To design and document the output format for workflows that produce documents or files, determining whether they need strict templates or flexible formatting.
|
||||
|
||||
## 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 output format specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in document design and template creation
|
||||
- ✅ User brings their specific output requirements and preferences
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on output format design
|
||||
- 🚫 FORBIDDEN to design workflow steps in this step
|
||||
- 💬 Help user understand the format spectrum
|
||||
- 🚫 DO NOT proceed without clear format requirements
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Guide user through format spectrum with examples
|
||||
- 💾 Document format decisions in workflow plan
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Approved plan from step 4 is available
|
||||
- Focus ONLY on output document formatting
|
||||
- Skip this step if workflow produces no documents
|
||||
- This step only runs when documents need structure
|
||||
|
||||
## OUTPUT FORMAT DESIGN PROCESS:
|
||||
|
||||
### 1. Initialize Output Format Discussion
|
||||
|
||||
"**Designing Your Output Format**
|
||||
|
||||
Based on your approved plan, your workflow will produce output documents. Let's design how these outputs should be formatted."
|
||||
|
||||
### 2. Present the Format Spectrum
|
||||
|
||||
"**Output Format Spectrum - Where does your workflow fit?**
|
||||
|
||||
**Strictly Structured Examples:**
|
||||
|
||||
- Government forms - exact fields, precise positions
|
||||
- Legal documents - must follow specific templates
|
||||
- Technical specifications - required sections, specific formats
|
||||
- Compliance reports - mandatory fields, validation rules
|
||||
|
||||
**Structured Examples:**
|
||||
|
||||
- Project reports - required sections, flexible content
|
||||
- Business proposals - consistent format, customizable sections
|
||||
- Technical documentation - standard structure, adaptable content
|
||||
- Research papers - IMRAD format, discipline-specific variations
|
||||
|
||||
**Semi-structured Examples:**
|
||||
|
||||
- Character sheets (D&D) - core stats + flexible background
|
||||
- Lesson plans - required components, flexible delivery
|
||||
- Recipes - ingredients/method format, flexible descriptions
|
||||
- Meeting minutes - agenda/attendees/actions, flexible details
|
||||
|
||||
**Free-form Examples:**
|
||||
|
||||
- Creative stories - narrative flow, minimal structure
|
||||
- Blog posts - title/body, organic organization
|
||||
- Personal journals - date/entry, free expression
|
||||
- Brainstorming outputs - ideas, flexible organization"
|
||||
|
||||
### 3. Determine Format Type
|
||||
|
||||
"**Which format type best fits your workflow?**
|
||||
|
||||
1. **Strict Template** - Must follow exact format with specific fields
|
||||
2. **Structured** - Required sections but flexible within each
|
||||
3. **Semi-structured** - Core sections plus optional additions
|
||||
4. **Free-form** - Content-driven with minimal structure
|
||||
|
||||
Please choose 1-4:"
|
||||
|
||||
### 4. Deep Dive Based on Choice
|
||||
|
||||
#### IF Strict Template (Choice 1):
|
||||
|
||||
"**Strict Template Design**
|
||||
|
||||
You need exact formatting. Let's define your requirements:
|
||||
|
||||
**Template Source Options:**
|
||||
A. Upload existing template/image to follow
|
||||
B. Create new template from scratch
|
||||
C. Use standard form (e.g., government, industry)
|
||||
D. AI proposes template based on your needs
|
||||
|
||||
**Template Requirements:**
|
||||
|
||||
- Exact field names and positions
|
||||
- Required vs optional fields
|
||||
- Validation rules
|
||||
- File format (PDF, DOCX, etc.)
|
||||
- Any legal/compliance considerations"
|
||||
|
||||
#### IF Structured (Choice 2):
|
||||
|
||||
"**Structured Document Design**
|
||||
|
||||
You need consistent sections with flexibility:
|
||||
|
||||
**Section Definition:**
|
||||
|
||||
- What sections are required?
|
||||
- Any optional sections?
|
||||
- Section ordering rules?
|
||||
- Cross-document consistency needs?
|
||||
|
||||
**Format Guidelines:**
|
||||
|
||||
- Any formatting standards (APA, MLA, corporate)?
|
||||
- Section header styles?
|
||||
- Content organization principles?"
|
||||
|
||||
#### IF Semi-structured (Choice 3):
|
||||
|
||||
"**Semi-structured Design**
|
||||
|
||||
Core sections with flexibility:
|
||||
|
||||
**Core Components:**
|
||||
|
||||
- What information must always appear?
|
||||
- Which parts can vary?
|
||||
- Any organizational preferences?
|
||||
|
||||
**Polishing Options:**
|
||||
|
||||
- Would you like automatic TOC generation?
|
||||
- Summary section at the end?
|
||||
- Consistent formatting options?"
|
||||
|
||||
#### IF Free-form (Choice 4):
|
||||
|
||||
"**Free-form Content Design**
|
||||
|
||||
Focus on content with minimal structure:
|
||||
|
||||
**Organization Needs:**
|
||||
|
||||
- Basic headers for readability?
|
||||
- Date/title information?
|
||||
- Any categorization needs?
|
||||
|
||||
**Final Polish Options:**
|
||||
|
||||
- Auto-generated summary?
|
||||
- TOC based on content?
|
||||
- Formatting for readability?"
|
||||
|
||||
### 5. Template Creation (if applicable)
|
||||
|
||||
For Strict/Structured workflows:
|
||||
|
||||
"**Template Creation Approach:**
|
||||
|
||||
A. **Design Together** - We'll create the template step by step
|
||||
B. **AI Proposes** - I'll suggest a structure based on your needs
|
||||
C. **Import Existing** - Use/upload your existing template
|
||||
|
||||
Which approach would you prefer?"
|
||||
|
||||
If A or B:
|
||||
|
||||
- Design/create template sections
|
||||
- Define placeholders
|
||||
- Specify field types and validation
|
||||
- Document template structure in plan
|
||||
|
||||
If C:
|
||||
|
||||
- Request file upload or detailed description
|
||||
- Analyze template structure
|
||||
- Document requirements
|
||||
|
||||
### 6. Document Format Decisions
|
||||
|
||||
Append to {workflowPlanFile}:
|
||||
|
||||
```markdown
|
||||
## Output Format Design
|
||||
|
||||
**Format Type**: [Strict/Structured/Semi-structured/Free-form]
|
||||
|
||||
**Output Requirements**:
|
||||
|
||||
- Document type: [report/form/story/etc]
|
||||
- File format: [PDF/MD/DOCX/etc]
|
||||
- Frequency: [single/batch/continuous]
|
||||
|
||||
**Structure Specifications**:
|
||||
[Detailed structure based on format type]
|
||||
|
||||
**Template Information**:
|
||||
|
||||
- Template source: [created/imported/standard]
|
||||
- Template file: [path if applicable]
|
||||
- Placeholders: [list if applicable]
|
||||
|
||||
**Special Considerations**:
|
||||
|
||||
- Legal/compliance requirements
|
||||
- Validation needs
|
||||
- Accessibility requirements
|
||||
```
|
||||
|
||||
### 7. 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 output format 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](#7-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and output format is documented will you load {nextStepFile} to begin workflow step design.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- User understands format spectrum
|
||||
- Format type clearly identified
|
||||
- Template requirements documented (if applicable)
|
||||
- Output format saved in plan
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not showing format examples
|
||||
- Skipping format requirements
|
||||
- Not documenting decisions in plan
|
||||
- Assuming format without asking
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,323 +0,0 @@
|
|||
---
|
||||
name: 'step-07-build'
|
||||
description: 'Generate all workflow files based on the approved plan'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-07-build.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-08-review.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Template References
|
||||
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
|
||||
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
|
||||
stepInitContinuableTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-01-init-continuable-template.md'
|
||||
step1bTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-1b-template.md'
|
||||
# No content templates needed - will create content as needed during build
|
||||
# No build summary template needed - will append summary directly to workflow plan
|
||||
---
|
||||
|
||||
# Step 7: Workflow File Generation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To generate all the workflow files (workflow.md, step files, templates, and supporting files) based on the approved plan from the previous design step.
|
||||
|
||||
## 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 implementation expertise and best practices
|
||||
- ✅ User brings their specific requirements and design approvals
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on generating files based on approved design
|
||||
- 🚫 FORBIDDEN to modify the design without user consent
|
||||
- 💬 Generate files collaboratively, getting approval at each stage
|
||||
- 🚪 CREATE files in the correct target location
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Generate files systematically from design
|
||||
- 💾 Document all generated files and their locations
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and build is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Approved plan from step 6 guides implementation
|
||||
- Generate files in target workflow location
|
||||
- Load templates and documentation as needed during build
|
||||
- Follow step-file architecture principles
|
||||
|
||||
## BUILD REFERENCE MATERIALS:
|
||||
|
||||
- When building each step file, you must follow template `{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md`
|
||||
- When building continuable step-01-init.md files, use template `{project-root}/_bmad/bmb/docs/workflows/templates/step-01-init-continuable-template.md`
|
||||
- When building continuation steps, use template `{project-root}/_bmad/bmb/docs/workflows/templates/step-1b-template.md`
|
||||
- When building the main workflow.md file, you must follow template `{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md`
|
||||
- Example step files from {project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/workflow.md for patterns - this is an idealized workflow so all files can give good insight into format and structure to be followed
|
||||
|
||||
## FILE GENERATION SEQUENCE:
|
||||
|
||||
### 1. Confirm Build Readiness
|
||||
|
||||
Based on the approved plan, confirm:
|
||||
"I have your approved plan and I'm ready to generate the workflow files. The plan specifies creating:
|
||||
|
||||
- Main workflow.md file
|
||||
- [Number] step files
|
||||
- [Number] templates
|
||||
- Supporting files
|
||||
|
||||
All in: {targetWorkflowPath}
|
||||
|
||||
Ready to proceed?"
|
||||
|
||||
### 2. Create Directory Structure
|
||||
|
||||
Create the workflow folder structure in the target location:
|
||||
|
||||
```
|
||||
{bmb_creations_output_folder}/workflows/{workflow_name}/
|
||||
├── workflow.md
|
||||
├── steps/
|
||||
│ ├── step-01-init.md
|
||||
│ ├── step-01b-continue.md (if continuation support needed)
|
||||
│ ├── step-02-[name].md
|
||||
│ └── ...
|
||||
├── templates/
|
||||
│ └── [as needed]
|
||||
└── data/
|
||||
└── [as needed]
|
||||
```
|
||||
|
||||
For bmb module, this will be: `_bmad/custom/src/workflows/{workflow_name}/`
|
||||
For other modules, check their module.yaml for custom_workflow_location
|
||||
|
||||
### 3. Generate workflow.md
|
||||
|
||||
Load and follow {workflowTemplate}:
|
||||
|
||||
- Create workflow.md using template structure
|
||||
- Insert workflow name and description
|
||||
- Configure all path variables ({project-root}, _bmad, {workflow_path})
|
||||
- Set web_bundle flag to true unless user has indicated otherwise
|
||||
- Define role and goal
|
||||
- Include initialization path to step-01
|
||||
|
||||
### 4. Generate Step Files
|
||||
|
||||
#### 4a. Check for Continuation Support
|
||||
|
||||
**Check the workflow plan for continuation support:**
|
||||
|
||||
- Look for "continuation support: true" or similar flag
|
||||
- Check if step-01b-continue.md was included in the design
|
||||
- If workflow generates output documents, continuation is typically needed
|
||||
|
||||
#### 4b. Generate step-01-init.md (with continuation logic)
|
||||
|
||||
If continuation support is needed:
|
||||
|
||||
- Load and follow {stepInitContinuableTemplate}
|
||||
- This template automatically includes all required continuation detection logic
|
||||
- Customize with workflow-specific information:
|
||||
- Update workflow_path references
|
||||
- Set correct outputFile and templateFile paths
|
||||
- Adjust role and persona to match workflow type
|
||||
- Customize welcome message for workflow context
|
||||
- Configure input document discovery patterns (if any)
|
||||
- Template automatically handles:
|
||||
- continueFile reference in frontmatter
|
||||
- Logic to check for existing output files with stepsCompleted
|
||||
- Routing to step-01b-continue.md for continuation
|
||||
- Fresh workflow initialization
|
||||
|
||||
#### 4c. Generate step-01b-continue.md (if needed)
|
||||
|
||||
**If continuation support is required:**
|
||||
|
||||
- Load and follow {step1bTemplate}
|
||||
- Customize with workflow-specific information:
|
||||
- Update workflow_path references
|
||||
- Set correct outputFile path
|
||||
- Adjust role and persona to match workflow type
|
||||
- Customize welcome back message for workflow context
|
||||
- Ensure proper nextStep detection logic based on step numbers
|
||||
|
||||
#### 4d. Generate Remaining Step Files
|
||||
|
||||
For each remaining step in the design:
|
||||
|
||||
- Load and follow {stepTemplate}
|
||||
- Create step file using template structure
|
||||
- Customize with step-specific content
|
||||
- Ensure proper frontmatter with path references
|
||||
- Include appropriate menu handling and universal rules
|
||||
- Follow all mandatory rules and protocols from template
|
||||
- **Critical**: Ensure each step updates `stepsCompleted` array when completing
|
||||
|
||||
### 5. Generate Templates (If Needed)
|
||||
|
||||
For document workflows:
|
||||
|
||||
- Create template.md with proper structure
|
||||
- Include all variables from design
|
||||
- Ensure variable naming consistency
|
||||
|
||||
Remember that the output format design we aligned on chose one of the following - and what it means practically when creating the workflow steps:
|
||||
1. **Strict Template** - Must follow exact format with specific fields
|
||||
1. This is similar to the example where there are multiple template fragements that are specific with all fields to be in the final output.
|
||||
2. generally there will be 1 fragment to a step to complete in the overall template.
|
||||
2. **Structured** - Required sections but flexible within each
|
||||
1. Usually there will just be one template file - and in this mode it lists out all the section headings (generally level 2 sections in the md) with a handlebars style placeholder for each section.
|
||||
2. Step files responsible for a specific section will upon user Continue of that step ensure output is written to the templates proper section
|
||||
3. **Semi-structured** - Core sections plus optional additions
|
||||
1. Similar to the prior 2, but not all sections or content are listed in the template, some steps might offer various paths or options to go to different steps (or variance within a step) that can determine what sections end up in the final document
|
||||
4. **Free-form** - Content-driven with minimal structure
|
||||
1. These are the easiest and most flexible. The single template usually only has the front matter fence with a stepsCompleted array and maybe some other fields, and outside of the front matter just the level 1 doc title
|
||||
2. With free form, any step that could produce content just appends to the end of the document, so its progressively build in the order of ste[s completed.
|
||||
3. Its good to have in this type of workflow a final polish output doc type step that cohesively can update the doc built up in this progressive manner, improving flow, reducing duplication, and ensure all information is aligned and where it belongs.
|
||||
|
||||
### 6. Generate Supporting Files
|
||||
|
||||
Based on design requirements:
|
||||
|
||||
- Create data files (csv)
|
||||
- Generate README.md with usage instructions
|
||||
- Create any configuration files
|
||||
- Add validation checklists if designed
|
||||
|
||||
### 7. Verify File Generation
|
||||
|
||||
After creating all files:
|
||||
|
||||
- Check all file paths are correct
|
||||
- Validate frontmatter syntax
|
||||
- Ensure variable consistency across files
|
||||
- Confirm sequential step numbering
|
||||
- Verify menu handling logic
|
||||
|
||||
### 8. Document Generated Files
|
||||
|
||||
Create a summary of what was generated:
|
||||
|
||||
- List all files created with full paths
|
||||
- Note any customizations from templates
|
||||
- Identify any manual steps needed
|
||||
- Provide next steps for testing
|
||||
|
||||
## QUALITY CHECKS DURING BUILD:
|
||||
|
||||
### Frontmatter Validation
|
||||
|
||||
- All YAML syntax is correct
|
||||
- Required fields are present
|
||||
- Path variables use correct format
|
||||
- No hardcoded paths exist
|
||||
|
||||
### Step File Compliance
|
||||
|
||||
- Each step follows the template structure
|
||||
- All mandatory rules are included
|
||||
- Menu handling is properly implemented
|
||||
- Step numbering is sequential
|
||||
|
||||
### Cross-File Consistency
|
||||
|
||||
- Variable names match across files
|
||||
- Path references are consistent
|
||||
- Dependencies are correctly defined
|
||||
- No orphaned references exist
|
||||
|
||||
## BUILD PRINCIPLES:
|
||||
|
||||
### Follow Design Exactly
|
||||
|
||||
- Implement the design as approved
|
||||
- Don't add or remove steps without consultation
|
||||
- Maintain the interaction patterns designed
|
||||
- Preserve the data flow architecture
|
||||
|
||||
### Maintain Best Practices
|
||||
|
||||
- Keep step files focused and reasonably sized (typically 5-10KB)
|
||||
- Use collaborative dialogue patterns
|
||||
- Include proper error handling
|
||||
- Follow naming conventions
|
||||
|
||||
### Ensure Extensibility
|
||||
|
||||
- Design for future modifications
|
||||
- Include clear documentation
|
||||
- Make code readable and maintainable
|
||||
- Provide examples where helpful
|
||||
|
||||
## CONTENT TO APPEND TO PLAN:
|
||||
|
||||
After generating all files, append to {workflowPlanFile}:
|
||||
|
||||
Create a build summary including:
|
||||
|
||||
- List of all files created with full paths
|
||||
- Any customizations from templates
|
||||
- Manual steps needed
|
||||
- Next steps for testing
|
||||
|
||||
### 9. Present MENU OPTIONS
|
||||
|
||||
Display: **Build Complete - Select an Option:** [C] Continue to Review
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- Build complete - all files generated
|
||||
- Present simple completion status
|
||||
- User selects [C] to continue to review step
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save build summary to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: respond and redisplay menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and content is saved to plan and frontmatter is updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin workflow review step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All workflow files generated in correct locations
|
||||
- Files follow step-file architecture principles
|
||||
- Plan implemented exactly as approved
|
||||
- Build documented in {workflowPlanFile}
|
||||
- Frontmatter updated with step completion
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating files without user approval
|
||||
- Deviating from approved plan
|
||||
- Creating files with incorrect paths
|
||||
- Not updating plan frontmatter
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,285 +0,0 @@
|
|||
---
|
||||
name: 'step-08-review'
|
||||
description: 'Review the generated workflow and provide final validation and next steps'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-08-review.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
# No review template needed - will append review summary directly to workflow plan
|
||||
# No completion template needed - will append completion details directly
|
||||
|
||||
# Next step reference
|
||||
nextStepFile: '{workflow_path}/steps/step-09-complete.md'
|
||||
---
|
||||
|
||||
# Step 8: Workflow Review and Completion
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To review the generated workflow for completeness, accuracy, and adherence to best practices, then provide next steps for deployment and usage.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: Always read the complete step file before taking any action
|
||||
- 📋 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 quality assurance expertise and validation knowledge
|
||||
- ✅ User provides final approval and feedback
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on reviewing and validating generated workflow
|
||||
- 🚫 FORBIDDEN to make changes without user approval
|
||||
- 💬 Guide review process collaboratively
|
||||
- 🚪 COMPLETE the workflow creation process
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Conduct thorough review of generated workflow
|
||||
- 💾 Document review findings and completion status
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]` and mark complete
|
||||
- 🚫 This is the final step - no next step to load
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Generated workflow files are available for review
|
||||
- Focus on validation and quality assurance
|
||||
- This step completes the workflow creation process
|
||||
- No file modifications without explicit user approval
|
||||
|
||||
## WORKFLOW REVIEW PROCESS:
|
||||
|
||||
### 1. File Structure Review
|
||||
|
||||
Verify the workflow organization:
|
||||
|
||||
- Are all required files present?
|
||||
- Is the directory structure correct?
|
||||
- Are file names following conventions?
|
||||
- Are paths properly configured?
|
||||
|
||||
### 2. Configuration Validation
|
||||
|
||||
Check workflow.yaml:
|
||||
|
||||
- Is all metadata correctly filled?
|
||||
- Are path variables properly formatted?
|
||||
- Is the standalone property set correctly?
|
||||
- Are all dependencies declared?
|
||||
|
||||
### 3. Step File Compliance
|
||||
|
||||
Review each step file:
|
||||
|
||||
- Does each step follow the template structure?
|
||||
- Are all mandatory rules included?
|
||||
- Is menu handling properly implemented?
|
||||
- Are frontmatter variables correct?
|
||||
- Are steps properly numbered?
|
||||
|
||||
### 4. Cross-File Consistency
|
||||
|
||||
Verify integration between files:
|
||||
|
||||
- Do variable names match across all files?
|
||||
- Are path references consistent?
|
||||
- Is the step sequence logical?
|
||||
- Are there any broken references?
|
||||
|
||||
### 5. Requirements Verification
|
||||
|
||||
Confirm original requirements are met:
|
||||
|
||||
- Does the workflow address the original problem?
|
||||
- Are all user types supported?
|
||||
- Are inputs and outputs as specified?
|
||||
- Is the interaction style as designed?
|
||||
|
||||
### 6. Best Practices Adherence
|
||||
|
||||
Check quality standards:
|
||||
|
||||
- Are step files focused and reasonably sized (5-10KB typical)?
|
||||
- Is collaborative dialogue implemented?
|
||||
- Is error handling included?
|
||||
- Are naming conventions followed?
|
||||
|
||||
### 7. Test Scenario Planning
|
||||
|
||||
Prepare for testing:
|
||||
|
||||
- What test data would be useful?
|
||||
- What scenarios should be tested?
|
||||
- How can the workflow be invoked?
|
||||
- What would indicate successful execution?
|
||||
|
||||
### 8. Deployment Preparation
|
||||
|
||||
Provide next steps:
|
||||
|
||||
- Installation requirements
|
||||
- Invocation commands
|
||||
- Testing procedures
|
||||
- Documentation needs
|
||||
|
||||
## REVIEW FINDINGS DOCUMENTATION:
|
||||
|
||||
### Issues Found
|
||||
|
||||
Document any issues discovered:
|
||||
|
||||
- **Critical Issues**: Must fix before use
|
||||
- **Warnings**: Should fix for better experience
|
||||
- **Suggestions**: Nice to have improvements
|
||||
|
||||
### Validation Results
|
||||
|
||||
Record validation outcomes:
|
||||
|
||||
- Configuration validation: PASSED/FAILED
|
||||
- Step compliance: PASSED/FAILED
|
||||
- Cross-file consistency: PASSED/FAILED
|
||||
- Requirements verification: PASSED/FAILED
|
||||
|
||||
### Recommendations
|
||||
|
||||
Provide specific recommendations:
|
||||
|
||||
- Immediate actions needed
|
||||
- Future improvements
|
||||
- Training needs
|
||||
- Maintenance considerations
|
||||
|
||||
## COMPLETION CHECKLIST:
|
||||
|
||||
### Final Validations
|
||||
|
||||
- [ ] All files generated successfully
|
||||
- [ ] No syntax errors in YAML
|
||||
- [ ] All paths are correct
|
||||
- [ ] Variables are consistent
|
||||
- [ ] Design requirements met
|
||||
- [ ] Best practices followed
|
||||
|
||||
### User Acceptance
|
||||
|
||||
- [ ] User has reviewed generated workflow
|
||||
- [ ] User approves of the implementation
|
||||
- [ ] User understands next steps
|
||||
- [ ] User satisfied with the result
|
||||
|
||||
### Documentation
|
||||
|
||||
- [ ] Build summary complete
|
||||
- [ ] Review findings documented
|
||||
- [ ] Next steps provided
|
||||
- [ ] Contact information for support
|
||||
|
||||
## CONTENT TO APPEND TO PLAN:
|
||||
|
||||
After completing review, append to {workflowPlanFile}:
|
||||
|
||||
Append review findings to {workflowPlanFile}:
|
||||
|
||||
Create a review summary including:
|
||||
|
||||
- Completeness check results
|
||||
- Accuracy validation
|
||||
- Compliance with best practices
|
||||
- Any issues found
|
||||
|
||||
Then append completion details:
|
||||
|
||||
- Final approval status
|
||||
- Deployment recommendations
|
||||
- Usage guidance
|
||||
|
||||
### 10. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [C] Continue to Completion
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- 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 C: Save review 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)
|
||||
|
||||
## COMPLIANCE CHECK INSTRUCTIONS
|
||||
|
||||
When user selects [C], provide these instructions:
|
||||
|
||||
**🎯 Workflow Creation Complete! Your new workflow is ready at:**
|
||||
`{target_workflow_path}`
|
||||
|
||||
**⚠️ IMPORTANT - Run Compliance Check in New Context:**
|
||||
To validate your workflow meets BMAD standards:
|
||||
|
||||
1. **Start a new Claude conversation** (fresh context)
|
||||
2. **Use this command:** `/bmad:bmm:workflows:workflow-compliance-check`
|
||||
3. **Provide the path:** `{target_workflow_path}/workflow.md`
|
||||
4. **Follow the validation process** to identify and fix any violations
|
||||
|
||||
**Why New Context?**
|
||||
|
||||
- Compliance checking requires fresh analysis without workflow creation context
|
||||
- Ensures objective validation against template standards
|
||||
- Provides detailed violation reporting with specific fix recommendations
|
||||
|
||||
**Your workflow will be checked for:**
|
||||
|
||||
- Template compliance and structure
|
||||
- Step-by-step validation standards
|
||||
- File optimization and formatting
|
||||
- Meta-workflow best practices
|
||||
|
||||
Ready to validate when you are! [Start new context and run compliance check]
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Generated workflow thoroughly reviewed
|
||||
- All validations performed
|
||||
- Issues documented with solutions
|
||||
- User approves final workflow
|
||||
- Complete documentation provided
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping review steps
|
||||
- Not documenting findings
|
||||
- Ending without user approval
|
||||
- Not providing next steps
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,188 +0,0 @@
|
|||
---
|
||||
name: 'step-09-complete'
|
||||
description: 'Final completion and wrap-up of workflow creation process'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-09-complete.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
completionFile: '{targetWorkflowPath}/completion-summary-{new_workflow_name}.md'
|
||||
---
|
||||
|
||||
# Step 9: Workflow Creation Complete
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To complete the workflow creation process with a final summary, confirmation, and next steps for using the new workflow.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 📋 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 expertise in workflow deployment and usage guidance
|
||||
- ✅ User brings their specific workflow needs
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on completion and next steps
|
||||
- 🚫 FORBIDDEN to modify the generated workflow
|
||||
- 💬 Provide clear guidance on how to use the workflow
|
||||
- 🚫 This is the final step - no next step to load
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Present completion summary
|
||||
- 💾 Create final completion documentation
|
||||
- 📖 Update plan frontmatter with completion status
|
||||
- 🚫 This is the final step
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All previous steps are complete
|
||||
- Workflow has been generated and reviewed
|
||||
- Focus ONLY on completion and next steps
|
||||
- This step concludes the create-workflow process
|
||||
|
||||
## COMPLETION PROCESS:
|
||||
|
||||
### 1. Initialize Completion
|
||||
|
||||
"**Workflow Creation Complete!**
|
||||
|
||||
Congratulations! We've successfully created your new workflow. Let's finalize everything and ensure you have everything you need to start using it."
|
||||
|
||||
### 2. Final Summary
|
||||
|
||||
Present a complete summary of what was created:
|
||||
|
||||
**Workflow Created:** {new_workflow_name}
|
||||
**Location:** {targetWorkflowPath}
|
||||
**Files Generated:** [list from build step]
|
||||
|
||||
### 3. Create Completion Summary
|
||||
|
||||
Create {completionFile} with:
|
||||
|
||||
```markdown
|
||||
---
|
||||
workflowName: { new_workflow_name }
|
||||
creationDate: [current date]
|
||||
module: [module from plan]
|
||||
status: COMPLETE
|
||||
stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9]
|
||||
---
|
||||
|
||||
# Workflow Creation Summary
|
||||
|
||||
## Workflow Information
|
||||
|
||||
- **Name:** {new_workflow_name}
|
||||
- **Module:** [module]
|
||||
- **Created:** [date]
|
||||
- **Location:** {targetWorkflowPath}
|
||||
|
||||
## Generated Files
|
||||
|
||||
[List all files created]
|
||||
|
||||
## Quick Start Guide
|
||||
|
||||
[How to run the new workflow]
|
||||
|
||||
## Next Steps
|
||||
|
||||
[Post-creation recommendations]
|
||||
```
|
||||
|
||||
### 4. Usage Guidance
|
||||
|
||||
Provide clear instructions on how to use the new workflow:
|
||||
|
||||
**How to Use Your New Workflow:**
|
||||
|
||||
1. **Running the Workflow:**
|
||||
- [Instructions based on workflow type]
|
||||
- [Initial setup if needed]
|
||||
|
||||
2. **Common Use Cases:**
|
||||
- [Typical scenarios for using the workflow]
|
||||
- [Expected inputs and outputs]
|
||||
|
||||
3. **Tips for Success:**
|
||||
- [Best practices for this specific workflow]
|
||||
- [Common pitfalls to avoid]
|
||||
|
||||
### 5. Post-Creation Recommendations
|
||||
|
||||
"**Next Steps:**
|
||||
|
||||
1. **Test the Workflow:** Run it with sample data to ensure it works as expected
|
||||
2. **Customize if Needed:** You can modify the workflow based on your specific needs
|
||||
3. **Share with Team:** If others will use this workflow, provide them with the location and instructions
|
||||
4. **Monitor Usage:** Keep track of how well the workflow meets your needs"
|
||||
|
||||
### 6. Final Confirmation
|
||||
|
||||
"**Is there anything else you need help with regarding your new workflow?**
|
||||
|
||||
- I can help you test it
|
||||
- We can make adjustments if needed
|
||||
- I can help you create documentation for users
|
||||
- Or any other support you need"
|
||||
|
||||
### 7. Update Final Status
|
||||
|
||||
Update {workflowPlanFile} frontmatter:
|
||||
|
||||
- Set status to COMPLETE
|
||||
- Set completion date
|
||||
- Add stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9]
|
||||
|
||||
## MENU OPTIONS
|
||||
|
||||
Display: **Workflow Creation Complete!** [T] Test Workflow [M] Make Adjustments [D] Get Help
|
||||
|
||||
### Menu Handling Logic:
|
||||
|
||||
- IF T: Offer to run the newly created workflow with sample data
|
||||
- IF M: Offer to make specific adjustments to the workflow
|
||||
- IF D: Provide additional help and resources
|
||||
- IF Any other: Respond to user needs
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final step. When the user is satisfied, the workflow creation process is complete.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Workflow fully created and reviewed
|
||||
- Completion summary generated
|
||||
- User understands how to use the workflow
|
||||
- All documentation is in place
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not providing clear usage instructions
|
||||
- Not creating completion summary
|
||||
- Leaving user without next steps
|
||||
|
||||
**Master Rule:** Ensure the user has everything needed to successfully use their new workflow.
|
||||
|
|
@ -1,217 +0,0 @@
|
|||
---
|
||||
name: 'step-01-analyze'
|
||||
description: 'Load and deeply understand the target workflow'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-01-analyze.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-discover.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
|
||||
|
||||
# Template References
|
||||
analysisTemplate: '{workflow_path}/templates/workflow-analysis.md'
|
||||
---
|
||||
|
||||
# Step 1: Workflow Analysis
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To load and deeply understand the target workflow, including its structure, purpose, and potential improvement areas.
|
||||
|
||||
## 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 editor and improvement specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring workflow analysis expertise and best practices knowledge
|
||||
- ✅ User brings their workflow context and improvement needs
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on analysis and understanding, not editing yet
|
||||
- 🚫 FORBIDDEN to suggest specific changes in this step
|
||||
- 💬 Ask questions to understand the workflow path
|
||||
- 🚪 DETECT if this is a new format (standalone) or old format workflow
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Analyze workflow thoroughly and systematically
|
||||
- 💾 Document analysis findings in {outputFile}
|
||||
- 📖 Update frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and analysis is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- User provides the workflow path to analyze
|
||||
- Load all workflow documentation for reference
|
||||
- Focus on understanding current state, not improvements yet
|
||||
- This is about discovery and analysis
|
||||
|
||||
## WORKFLOW ANALYSIS PROCESS:
|
||||
|
||||
### 1. Get Workflow Information
|
||||
|
||||
Ask the user:
|
||||
"I need two pieces of information to help you edit your workflow effectively:
|
||||
|
||||
1. **What is the path to the workflow you want to edit?**
|
||||
- Path to workflow.md file (new format)
|
||||
- Path to workflow.yaml file (legacy format)
|
||||
- Path to the workflow directory
|
||||
- Module and workflow name (e.g., 'bmb/workflows/create-workflow')
|
||||
|
||||
2. **What do you want to edit or improve in this workflow?**
|
||||
- Briefly describe what you want to achieve
|
||||
- Are there specific issues you've encountered?
|
||||
- Any user feedback you've received?
|
||||
- New features you want to add?
|
||||
|
||||
This will help me focus my analysis on what matters most to you."
|
||||
|
||||
### 2. Load Workflow Files
|
||||
|
||||
Load the target workflow completely:
|
||||
|
||||
- workflow.md (or workflow.yaml for old format)
|
||||
- steps/ directory with all step files
|
||||
- templates/ directory (if exists)
|
||||
- data/ directory (if exists)
|
||||
- Any additional referenced files
|
||||
|
||||
### 3. Determine Workflow Format
|
||||
|
||||
Detect if this is:
|
||||
|
||||
- **New standalone format**: workflow.md with steps/ subdirectory
|
||||
- **Legacy XML format**: workflow.yaml with instructions.md
|
||||
- **Mixed format**: Partial migration
|
||||
|
||||
### 4. Focused Analysis
|
||||
|
||||
Analyze the workflow with attention to the user's stated goals:
|
||||
|
||||
#### Initial Goal-Focused Analysis
|
||||
|
||||
Based on what the user wants to edit:
|
||||
|
||||
- If **user experience issues**: Focus on step clarity, menu patterns, instruction style
|
||||
- If **functional problems**: Focus on broken references, missing files, logic errors
|
||||
- If **new features**: Focus on integration points, extensibility, structure
|
||||
- If **compliance issues**: Focus on best practices, standards, validation
|
||||
|
||||
#### Structure Analysis
|
||||
|
||||
- Identify workflow type (document, action, interactive, autonomous, meta)
|
||||
- Count and examine all steps
|
||||
- Map out step flow and dependencies
|
||||
- Check for proper frontmatter in all files
|
||||
|
||||
#### Content Analysis
|
||||
|
||||
- Understand purpose and user journey
|
||||
- Evaluate instruction style (intent-based vs prescriptive)
|
||||
- Review menu patterns and user interaction points
|
||||
- Check variable consistency across files
|
||||
|
||||
#### Compliance Analysis
|
||||
|
||||
Load reference documentation to understand what ideal workflow files sound be when doing the review:
|
||||
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/architecture.md`
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md`
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md`
|
||||
|
||||
Check against best practices:
|
||||
|
||||
- Step file size and structure (each step file 80-250 lines)
|
||||
- Menu handling implementation (every menu item has a handler, and continue will only proceed after writes to output if applicable have completed)
|
||||
- Frontmatter variable usage - no unused variables in the specific step front matter, and all files referenced in the file are done through a variable in the front matter
|
||||
|
||||
### 5. Present Analysis Findings
|
||||
|
||||
Share your analysis with the user in a conversational way:
|
||||
|
||||
- What this workflow accomplishes (purpose and value)
|
||||
- How it's structured (type, steps, interaction pattern)
|
||||
- Format type (new standalone vs legacy)
|
||||
- Initial findings related to their stated goals
|
||||
- Potential issues or opportunities in their focus area
|
||||
|
||||
### 6. Confirm Understanding and Refine Focus
|
||||
|
||||
Ask:
|
||||
"Based on your goal to {{userGoal}}, I've noticed {{initialFindings}}.
|
||||
Does this align with what you were expecting? Are there other areas you'd like me to focus on in my analysis?"
|
||||
|
||||
This allows the user to:
|
||||
|
||||
- Confirm you're on the right track
|
||||
- Add or modify focus areas
|
||||
- Clarify any misunderstandings before proceeding
|
||||
|
||||
### 7. Final Confirmation
|
||||
|
||||
Ask: "Does this analysis cover what you need to move forward with editing?"
|
||||
|
||||
## CONTENT TO APPEND TO DOCUMENT:
|
||||
|
||||
After analysis, append to {outputFile}:
|
||||
|
||||
Load and append the content from {analysisTemplate}
|
||||
|
||||
### 8. 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 analysis to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and analysis is saved to document and frontmatter is updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin improvement discovery step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Target workflow loaded completely
|
||||
- Analysis performed systematically
|
||||
- Findings documented clearly
|
||||
- User confirms understanding
|
||||
- Analysis saved to {outputFile}
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping analysis steps
|
||||
- Not loading all workflow files
|
||||
- Making suggestions without understanding
|
||||
- Not saving analysis findings
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,254 +0,0 @@
|
|||
---
|
||||
name: 'step-02-discover'
|
||||
description: 'Discover improvement goals collaboratively'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-02-discover.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-03-improve.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
goalsTemplate: '{workflow_path}/templates/improvement-goals.md'
|
||||
---
|
||||
|
||||
# Step 2: Discover Improvement Goals
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To collaboratively discover what the user wants to improve and why, before diving into any edits.
|
||||
|
||||
## 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 editor and improvement specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You guide discovery with thoughtful questions
|
||||
- ✅ User brings their context, feedback, and goals
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on understanding improvement goals
|
||||
- 🚫 FORBIDDEN to suggest specific solutions yet
|
||||
- 💬 Ask open-ended questions to understand needs
|
||||
- 🚪 ORGANIZE improvements by priority and impact
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Guide collaborative discovery conversation
|
||||
- 💾 Document goals in {outputFile}
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and goals are documented
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Analysis from step 1 is available and informs discovery
|
||||
- Focus areas identified in step 1 guide deeper exploration
|
||||
- Focus on WHAT to improve and WHY
|
||||
- Don't discuss HOW to improve yet
|
||||
- This is about detailed needs assessment, not solution design
|
||||
|
||||
## DISCOVERY PROCESS:
|
||||
|
||||
### 1. Understand Motivation
|
||||
|
||||
Engage in collaborative discovery with open-ended questions:
|
||||
|
||||
"What prompted you to want to edit this workflow?"
|
||||
|
||||
Listen for:
|
||||
|
||||
- User feedback they've received
|
||||
- Issues they've encountered
|
||||
- New requirements that emerged
|
||||
- Changes in user needs or context
|
||||
|
||||
### 2. Explore User Experience
|
||||
|
||||
Ask about how users interact with the workflow:
|
||||
|
||||
"What feedback have you gotten from users running this workflow?"
|
||||
|
||||
Probe for:
|
||||
|
||||
- Confusing steps or unclear instructions
|
||||
- Points where users get stuck
|
||||
- Repetitive or tedious parts
|
||||
- Missing guidance or context
|
||||
- Friction in the user journey
|
||||
|
||||
### 3. Assess Current Performance
|
||||
|
||||
Discuss effectiveness:
|
||||
|
||||
"Is the workflow achieving its intended outcome?"
|
||||
|
||||
Explore:
|
||||
|
||||
- Are users successful with this workflow?
|
||||
- What are the success/failure rates?
|
||||
- Where do most users drop off?
|
||||
- Are there quality issues with outputs?
|
||||
|
||||
### 4. Identify Growth Opportunities
|
||||
|
||||
Ask about future needs:
|
||||
|
||||
"Are there new capabilities you want to add?"
|
||||
|
||||
Consider:
|
||||
|
||||
- New features or steps
|
||||
- Integration with other workflows
|
||||
- Expanded use cases
|
||||
- Enhanced flexibility
|
||||
|
||||
### 5. Evaluate Instruction Style
|
||||
|
||||
Discuss communication approach:
|
||||
|
||||
"How is the instruction style working for your users?"
|
||||
|
||||
Explore:
|
||||
|
||||
- Is it too rigid or too loose?
|
||||
- Should certain steps be more adaptive?
|
||||
- Do some steps need more specificity?
|
||||
- Does the style match the workflow's purpose?
|
||||
|
||||
### 6. Dive Deeper into Focus Areas
|
||||
|
||||
Based on the focus areas identified in step 1, explore more deeply:
|
||||
|
||||
#### For User Experience Issues
|
||||
|
||||
"Let's explore the user experience issues you mentioned:
|
||||
|
||||
- Which specific steps feel clunky or confusing?
|
||||
- At what points do users get stuck?
|
||||
- What kind of guidance would help them most?"
|
||||
|
||||
#### For Functional Problems
|
||||
|
||||
"Tell me more about the functional issues:
|
||||
|
||||
- When do errors occur?
|
||||
- What specific functionality isn't working?
|
||||
- Are these consistent issues or intermittent?"
|
||||
|
||||
#### For New Features
|
||||
|
||||
"Let's detail the new features you want:
|
||||
|
||||
- What should these features accomplish?
|
||||
- How should users interact with them?
|
||||
- Are there examples of similar workflows to reference?"
|
||||
|
||||
#### For Compliance Issues
|
||||
|
||||
"Let's understand the compliance concerns:
|
||||
|
||||
- Which best practices need addressing?
|
||||
- Are there specific standards to meet?
|
||||
- What validation would be most valuable?"
|
||||
|
||||
### 7. Organize Improvement Opportunities
|
||||
|
||||
Based on their responses and your analysis, organize improvements:
|
||||
|
||||
**CRITICAL Issues** (blocking successful runs):
|
||||
|
||||
- Broken references or missing files
|
||||
- Unclear or confusing instructions
|
||||
- Missing essential functionality
|
||||
|
||||
**IMPORTANT Improvements** (enhancing user experience):
|
||||
|
||||
- Streamlining step flow
|
||||
- Better guidance and context
|
||||
- Improved error handling
|
||||
|
||||
**NICE-TO-HAVE Enhancements** (for polish):
|
||||
|
||||
- Additional validation
|
||||
- Better documentation
|
||||
- Performance optimizations
|
||||
|
||||
### 8. Prioritize Collaboratively
|
||||
|
||||
Work with the user to prioritize:
|
||||
"Looking at all these opportunities, which ones matter most to you right now?"
|
||||
|
||||
Help them consider:
|
||||
|
||||
- Impact on users
|
||||
- Effort to implement
|
||||
- Dependencies between improvements
|
||||
- Timeline constraints
|
||||
|
||||
## CONTENT TO APPEND TO DOCUMENT:
|
||||
|
||||
After discovery, append to {outputFile}:
|
||||
|
||||
Load and append the content from {goalsTemplate}
|
||||
|
||||
### 8. 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 goals to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and goals are saved to document and frontmatter is updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin collaborative improvement step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- User improvement goals clearly understood
|
||||
- Issues and opportunities identified
|
||||
- Priorities established collaboratively
|
||||
- Goals documented in {outputFile}
|
||||
- User ready to proceed with improvements
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping discovery dialogue
|
||||
- Making assumptions about user needs
|
||||
- Not documenting discovered goals
|
||||
- Rushing to solutions without understanding
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,218 +0,0 @@
|
|||
---
|
||||
name: 'step-03-improve'
|
||||
description: 'Facilitate collaborative improvements to the workflow'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-03-improve.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-04-validate.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
improvementLogTemplate: '{workflow_path}/templates/improvement-log.md'
|
||||
---
|
||||
|
||||
# Step 3: Collaborative Improvement
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To facilitate collaborative improvements to the workflow, working iteratively on each identified issue.
|
||||
|
||||
## 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 editor and improvement specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You guide improvements with explanations and options
|
||||
- ✅ User makes decisions and approves changes
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Work on ONE improvement at a time
|
||||
- 🚫 FORBIDDEN to make changes without user approval
|
||||
- 💬 Explain the rationale for each proposed change
|
||||
- 🚪 ITERATE: improve, review, refine
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Facilitate improvements collaboratively and iteratively
|
||||
- 💾 Document all changes in improvement log
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and improvements are complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Analysis and goals from previous steps guide improvements
|
||||
- Load workflow creation documentation as needed
|
||||
- Focus on improvements prioritized in step 2
|
||||
- This is about collaborative implementation, not solo editing
|
||||
|
||||
## IMPROVEMENT PROCESS:
|
||||
|
||||
### 1. Load Reference Materials
|
||||
|
||||
Load documentation as needed for specific improvements:
|
||||
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md`
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md`
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/architecture.md`
|
||||
|
||||
### 2. Address Each Improvement Iteratively
|
||||
|
||||
For each prioritized improvement:
|
||||
|
||||
#### A. Explain Current State
|
||||
|
||||
Show the relevant section:
|
||||
"Here's how this step currently works:
|
||||
[Display current content]
|
||||
|
||||
This can cause {{problem}} because {{reason}}."
|
||||
|
||||
#### B. Propose Improvement
|
||||
|
||||
Suggest specific changes:
|
||||
"Based on best practices, we could:
|
||||
{{proposedSolution}}
|
||||
|
||||
This would help users by {{benefit}}."
|
||||
|
||||
#### C. Collaborate on Approach
|
||||
|
||||
Ask for input:
|
||||
"Does this approach address your need?"
|
||||
"Would you like to modify this suggestion?"
|
||||
"What concerns do you have about this change?"
|
||||
|
||||
#### D. Get Explicit Approval
|
||||
|
||||
"Should I apply this change?"
|
||||
|
||||
#### E. Apply and Show Result
|
||||
|
||||
Make the change and display:
|
||||
"Here's the updated version:
|
||||
[Display new content]
|
||||
|
||||
Does this look right to you?"
|
||||
|
||||
### 3. Common Improvement Patterns
|
||||
|
||||
#### Step Flow Improvements
|
||||
|
||||
- Merge redundant steps
|
||||
- Split complex steps
|
||||
- Reorder for better flow
|
||||
- Add missing transitions
|
||||
|
||||
#### Instruction Style Refinement
|
||||
|
||||
Load step-template.md for reference:
|
||||
|
||||
- Convert prescriptive to intent-based for discovery steps
|
||||
- Add structure to vague instructions
|
||||
- Balance guidance with autonomy
|
||||
|
||||
#### Variable Consistency Fixes
|
||||
|
||||
- Identify all variable references
|
||||
- Ensure consistent naming (snake_case)
|
||||
- Verify variables are defined in workflow.md
|
||||
- Update all occurrences
|
||||
|
||||
#### Menu System Updates
|
||||
|
||||
- Standardize menu patterns
|
||||
- Ensure proper A/P/C options
|
||||
- Fix menu handling logic
|
||||
- Add Advanced Elicitation where useful
|
||||
|
||||
#### Frontmatter Compliance
|
||||
|
||||
- Add required fields to workflow.md
|
||||
- Ensure proper path variables
|
||||
- Include web_bundle configuration if needed
|
||||
- Remove unused fields
|
||||
|
||||
#### Template Updates
|
||||
|
||||
- Align template variables with step outputs
|
||||
- Improve variable naming
|
||||
- Add missing template sections
|
||||
- Test variable substitution
|
||||
|
||||
### 4. Track All Changes
|
||||
|
||||
For each improvement made, document:
|
||||
|
||||
- What was changed
|
||||
- Why it was changed
|
||||
- Files modified
|
||||
- User approval
|
||||
|
||||
## CONTENT TO APPEND TO DOCUMENT:
|
||||
|
||||
After each improvement iteration, append to {outputFile}:
|
||||
|
||||
Load and append content from {improvementLogTemplate}
|
||||
|
||||
### 5. 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 improvement log to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all prioritized improvements are complete and documented, will you then load, read entire file, then execute {nextStepFile} to execute and begin validation step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All prioritized improvements addressed
|
||||
- User approved each change
|
||||
- Changes documented clearly
|
||||
- Workflow follows best practices
|
||||
- Improvement log updated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Making changes without user approval
|
||||
- Not documenting changes
|
||||
- Skipping prioritized improvements
|
||||
- Breaking workflow functionality
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,194 +0,0 @@
|
|||
---
|
||||
name: 'step-04-validate'
|
||||
description: 'Validate improvements and prepare for completion'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-04-validate.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-05-compliance-check.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
validationTemplate: '{workflow_path}/templates/validation-results.md'
|
||||
completionTemplate: '{workflow_path}/templates/completion-summary.md'
|
||||
---
|
||||
|
||||
# Step 4: Validation and Completion
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To validate all improvements and prepare a completion summary of the workflow editing process.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: Always read the complete step file before taking any action
|
||||
- 📋 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 editor and improvement specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You ensure quality and completeness
|
||||
- ✅ User confirms final state
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on validation and completion
|
||||
- 🚫 FORBIDDEN to make additional edits at this stage
|
||||
- 💬 Explain validation results clearly
|
||||
- 🚪 PREPARE final summary and next steps
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Validate all changes systematically
|
||||
- 💾 Document validation results
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and validation is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All improvements from step 3 should be implemented
|
||||
- Focus on validation, not additional changes
|
||||
- Reference best practices for validation criteria
|
||||
- This completes the editing process
|
||||
|
||||
## VALIDATION PROCESS:
|
||||
|
||||
### 1. Comprehensive Validation Checks
|
||||
|
||||
Validate the improved workflow systematically:
|
||||
|
||||
#### File Structure Validation
|
||||
|
||||
- [ ] All required files present
|
||||
- [ ] Directory structure correct
|
||||
- [ ] File names follow conventions
|
||||
- [ ] Path references resolve correctly
|
||||
|
||||
#### Configuration Validation
|
||||
|
||||
- [ ] workflow.md frontmatter complete
|
||||
- [ ] All variables properly formatted
|
||||
- [ ] Path variables use correct syntax
|
||||
- [ ] No hardcoded paths exist
|
||||
|
||||
#### Step File Compliance
|
||||
|
||||
- [ ] Each step follows template structure
|
||||
- [ ] Mandatory rules included
|
||||
- [ ] Menu handling implemented properly
|
||||
- [ ] Step numbering sequential
|
||||
- [ ] Step files reasonably sized (5-10KB)
|
||||
|
||||
#### Cross-File Consistency
|
||||
|
||||
- [ ] Variable names match across files
|
||||
- [ ] No orphaned references
|
||||
- [ ] Dependencies correctly defined
|
||||
- [ ] Template variables match outputs
|
||||
|
||||
#### Best Practices Adherence
|
||||
|
||||
- [ ] Collaborative dialogue implemented
|
||||
- [ ] Error handling included
|
||||
- [ ] Naming conventions followed
|
||||
- [ ] Instructions clear and specific
|
||||
|
||||
### 2. Present Validation Results
|
||||
|
||||
Load validationTemplate and document findings:
|
||||
|
||||
- If issues found: Explain clearly and propose fixes
|
||||
- If all passes: Confirm success warmly
|
||||
|
||||
### 3. Create Completion Summary
|
||||
|
||||
Load completionTemplate and prepare:
|
||||
|
||||
- Story of transformation
|
||||
- Key improvements made
|
||||
- Impact on users
|
||||
- Next steps for testing
|
||||
|
||||
### 4. Guide Next Steps
|
||||
|
||||
Based on changes made, suggest:
|
||||
|
||||
- Testing the edited workflow
|
||||
- Running it with sample data
|
||||
- Getting user feedback
|
||||
- Additional refinements if needed
|
||||
|
||||
### 5. Document Final State
|
||||
|
||||
Update {outputFile} with:
|
||||
|
||||
- Validation results
|
||||
- Completion summary
|
||||
- Change log summary
|
||||
- Recommendations
|
||||
|
||||
## CONTENT TO APPEND TO DOCUMENT:
|
||||
|
||||
After validation, append to {outputFile}:
|
||||
|
||||
Load and append content from {validationTemplate}
|
||||
|
||||
Then load and append content from {completionTemplate}
|
||||
|
||||
## FINAL 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 content to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#final-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and content is saved to {outputFile} with frontmatter updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin compliance validation step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All improvements validated successfully
|
||||
- No critical issues remain
|
||||
- Completion summary provided
|
||||
- Next steps clearly outlined
|
||||
- User satisfied with results
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping validation steps
|
||||
- Not documenting final state
|
||||
- Ending without user confirmation
|
||||
- Leaving issues unresolved
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,246 +0,0 @@
|
|||
---
|
||||
name: 'step-05-compliance-check'
|
||||
description: 'Run comprehensive compliance validation on the edited workflow'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-05-compliance-check.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
editedWorkflowPath: '{target_workflow_path}'
|
||||
complianceCheckWorkflow: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check/workflow.md'
|
||||
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
complianceCheckTask: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check/workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Compliance Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Run comprehensive compliance validation on the edited workflow using the workflow-compliance-check workflow to ensure it meets all BMAD standards before completion.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 📋 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 editor and quality assurance specialist
|
||||
- ✅ If you already have been given a name, communication_style, and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in BMAD standards and workflow validation
|
||||
- ✅ User brings their edited workflow and needs quality assurance
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on running compliance validation on the edited workflow
|
||||
- 🚫 FORBIDDEN to skip compliance validation or declare workflow complete without it
|
||||
- 💬 Approach: Quality-focused, thorough, and collaborative
|
||||
- 📋 Ensure user understands compliance results and next steps
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Launch workflow-compliance-check on the edited workflow
|
||||
- 💾 Review compliance report and present findings to user
|
||||
- 📖 Explain any issues found and provide fix recommendations
|
||||
- 🚫 FORBIDDEN to proceed without compliance validation completion
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Edited workflow files from previous improve step
|
||||
- Focus: Compliance validation using workflow-compliance-check workflow
|
||||
- Limits: Validation and reporting only, no further workflow modifications
|
||||
- Dependencies: Successful workflow improvements in previous step
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Initialize Compliance Validation
|
||||
|
||||
"**Final Quality Check: Workflow Compliance Validation**
|
||||
|
||||
Your workflow has been edited! Now let's run a comprehensive compliance check to ensure it meets all BMAD standards and follows best practices.
|
||||
|
||||
This validation will check:
|
||||
|
||||
- Template compliance (workflow-template.md and step-template.md)
|
||||
- File size optimization and markdown formatting
|
||||
- CSV data file standards (if applicable)
|
||||
- Intent vs Prescriptive spectrum alignment
|
||||
- Web search and subprocess optimization
|
||||
- Overall workflow flow and goal alignment"
|
||||
|
||||
### 2. Launch Compliance Check Workflow
|
||||
|
||||
**A. Execute Compliance Validation:**
|
||||
|
||||
"Running comprehensive compliance validation on your edited workflow...
|
||||
Target: `{editedWorkflowPath}`
|
||||
|
||||
**Executing:** {complianceCheckTask}
|
||||
**Validation Scope:** Full 8-phase compliance analysis
|
||||
**Expected Duration:** Thorough validation may take several minutes"
|
||||
|
||||
**B. Monitor Validation Progress:**
|
||||
|
||||
Provide updates as the validation progresses:
|
||||
|
||||
- "✅ Workflow.md validation in progress..."
|
||||
- "✅ Step-by-step compliance checking..."
|
||||
- "✅ File size and formatting analysis..."
|
||||
- "✅ Intent spectrum assessment..."
|
||||
- "✅ Web search optimization analysis..."
|
||||
- "✅ Generating comprehensive compliance report..."
|
||||
|
||||
### 3. Compliance Report Analysis
|
||||
|
||||
**A. Review Validation Results:**
|
||||
|
||||
"**Compliance Validation Complete!**
|
||||
|
||||
**Overall Assessment:** [PASS/PARTIAL/FAIL - based on compliance report]
|
||||
|
||||
- **Critical Issues:** [number found]
|
||||
- **Major Issues:** [number found]
|
||||
- **Minor Issues:** [number found]
|
||||
- **Compliance Score:** [percentage]%"
|
||||
|
||||
**B. Present Key Findings:**
|
||||
|
||||
"**Key Compliance Results:**
|
||||
|
||||
- **Template Adherence:** [summary of template compliance]
|
||||
- **File Optimization:** [file size and formatting issues]
|
||||
- **Intent Spectrum:** [spectrum positioning validation]
|
||||
- **Performance Optimization:** [web search and subprocess findings]
|
||||
- **Overall Flow:** [workflow structure and completion validation]"
|
||||
|
||||
### 4. Issue Resolution Options
|
||||
|
||||
**A. Review Compliance Issues:**
|
||||
|
||||
If issues are found:
|
||||
"**Issues Requiring Attention:**
|
||||
|
||||
**Critical Issues (Must Fix):**
|
||||
[List any critical violations that prevent workflow functionality]
|
||||
|
||||
**Major Issues (Should Fix):**
|
||||
[List major issues that impact quality or maintainability]
|
||||
|
||||
**Minor Issues (Nice to Fix):**
|
||||
[List minor standards compliance issues]"
|
||||
|
||||
**B. Resolution Options:**
|
||||
|
||||
"**Resolution Options:**
|
||||
|
||||
1. **Automatic Fixes** - I can apply automated fixes where possible
|
||||
2. **Manual Guidance** - I'll guide you through manual fixes step by step
|
||||
3. **Return to Edit** - Go back to step 3 for additional improvements
|
||||
4. **Accept as Is** - Proceed with current state (if no critical issues)
|
||||
5. **Detailed Review** - Review full compliance report in detail"
|
||||
|
||||
### 5. Final Validation Confirmation
|
||||
|
||||
**A. User Choice Handling:**
|
||||
|
||||
Based on user selection:
|
||||
|
||||
- **If Automatic Fixes**: Apply fixes and re-run validation
|
||||
- **If Manual Guidance**: Provide step-by-step fix instructions
|
||||
- **If Return to Edit**: Load step-03-discover.md with compliance report context
|
||||
- **If Accept as Is**: Confirm understanding of any remaining issues
|
||||
- **If Detailed Review**: Present full compliance report
|
||||
|
||||
**B. Final Status Confirmation:**
|
||||
|
||||
"**Workflow Compliance Status:** [FINAL/PROVISIONAL]
|
||||
|
||||
**Completion Criteria:**
|
||||
|
||||
- ✅ All critical issues resolved
|
||||
- ✅ Major issues addressed or accepted
|
||||
- ✅ Compliance documentation complete
|
||||
- ✅ User understands any remaining minor issues
|
||||
|
||||
**Your edited workflow is ready!**"
|
||||
|
||||
### 6. Completion Documentation
|
||||
|
||||
**A. Update Compliance Status:**
|
||||
|
||||
Document final compliance status in {outputFile}:
|
||||
|
||||
- **Validation Date:** [current date]
|
||||
- **Compliance Score:** [final percentage]
|
||||
- **Issues Resolved:** [summary of fixes applied]
|
||||
- **Remaining Issues:** [any accepted minor issues]
|
||||
|
||||
**B. Final User Guidance:**
|
||||
|
||||
"**Next Steps for Your Edited Workflow:**
|
||||
|
||||
1. **Test the workflow** with real users to validate functionality
|
||||
2. **Monitor performance** and consider optimization opportunities
|
||||
3. **Gather feedback** for potential future improvements
|
||||
4. **Consider compliance check** periodically for maintenance
|
||||
|
||||
**Support Resources:**
|
||||
|
||||
- Use workflow-compliance-check for future validations
|
||||
- Refer to BMAD documentation for best practices
|
||||
- Use edit-workflow again for future modifications"
|
||||
|
||||
### 7. Final Menu Options
|
||||
|
||||
"**Workflow Edit and Compliance Complete!**
|
||||
|
||||
**Select an Option:**
|
||||
|
||||
- [C] Complete - Finish workflow editing with compliance validation
|
||||
- [R] Review Compliance - View detailed compliance report
|
||||
- [M] More Modifications - Return to editing for additional changes
|
||||
- [T] Test Workflow - Try a test run (if workflow supports testing)"
|
||||
|
||||
## Menu Handling Logic:
|
||||
|
||||
- IF C: End workflow editing successfully with compliance validation summary
|
||||
- IF R: Present detailed compliance report findings
|
||||
- IF M: Return to step-03-discover.md for additional improvements
|
||||
- IF T: If workflow supports testing, suggest test execution method
|
||||
- IF Any other comments or queries: respond and redisplay completion options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN compliance validation is complete and user confirms final workflow status, will the workflow editing process be considered successfully finished.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Comprehensive compliance validation executed on edited workflow
|
||||
- All compliance issues identified and documented with severity rankings
|
||||
- User provided with clear understanding of validation results
|
||||
- Appropriate resolution options offered and implemented
|
||||
- Final edited workflow meets BMAD standards and is ready for production
|
||||
- User satisfaction with workflow quality and compliance
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping compliance validation before workflow completion
|
||||
- Not addressing critical compliance issues found during validation
|
||||
- Failing to provide clear guidance on issue resolution
|
||||
- Declaring workflow complete without ensuring standards compliance
|
||||
- Not documenting final compliance status for future reference
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,75 +0,0 @@
|
|||
## Workflow Edit Complete!
|
||||
|
||||
### Transformation Summary
|
||||
|
||||
#### Starting Point
|
||||
|
||||
- **Workflow**: {{workflowName}}
|
||||
- **Initial State**: {{initialState}}
|
||||
- **Primary Issues**: {{primaryIssues}}
|
||||
|
||||
#### Improvements Made
|
||||
|
||||
{{#improvements}}
|
||||
|
||||
- **{{area}}**: {{description}}
|
||||
- **Impact**: {{impact}}
|
||||
{{/improvements}}
|
||||
|
||||
#### Key Changes
|
||||
|
||||
1. {{change1}}
|
||||
2. {{change2}}
|
||||
3. {{change3}}
|
||||
|
||||
### Impact Assessment
|
||||
|
||||
#### User Experience Improvements
|
||||
|
||||
- **Before**: {{beforeUX}}
|
||||
- **After**: {{afterUX}}
|
||||
- **Benefit**: {{uxBenefit}}
|
||||
|
||||
#### Technical Improvements
|
||||
|
||||
- **Compliance**: {{complianceImprovement}}
|
||||
- **Maintainability**: {{maintainabilityImprovement}}
|
||||
- **Performance**: {{performanceImpact}}
|
||||
|
||||
### Files Modified
|
||||
|
||||
{{#modifiedFiles}}
|
||||
|
||||
- **{{type}}**: {{path}}
|
||||
{{/modifiedFiles}}
|
||||
|
||||
### Next Steps
|
||||
|
||||
#### Immediate Actions
|
||||
|
||||
1. {{immediateAction1}}
|
||||
2. {{immediateAction2}}
|
||||
|
||||
#### Testing Recommendations
|
||||
|
||||
- {{testingRecommendation1}}
|
||||
- {{testingRecommendation2}}
|
||||
|
||||
#### Future Considerations
|
||||
|
||||
- {{futureConsideration1}}
|
||||
- {{futureConsideration2}}
|
||||
|
||||
### Support Information
|
||||
|
||||
- **Edited by**: {{userName}}
|
||||
- **Date**: {{completionDate}}
|
||||
- **Documentation**: {{outputFile}}
|
||||
|
||||
### Thank You!
|
||||
|
||||
Thank you for collaboratively improving this workflow. Your workflow now follows best practices and should provide a better experience for your users.
|
||||
|
||||
---
|
||||
|
||||
_Edit workflow completed successfully on {{completionDate}}_
|
||||
|
|
@ -1,68 +0,0 @@
|
|||
## Improvement Goals
|
||||
|
||||
### Motivation
|
||||
|
||||
- **Trigger**: {{editTrigger}}
|
||||
- **User Feedback**: {{userFeedback}}
|
||||
- **Success Issues**: {{successIssues}}
|
||||
|
||||
### User Experience Issues
|
||||
|
||||
{{#uxIssues}}
|
||||
|
||||
- {{.}}
|
||||
{{/uxIssues}}
|
||||
|
||||
### Performance Gaps
|
||||
|
||||
{{#performanceGaps}}
|
||||
|
||||
- {{.}}
|
||||
{{/performanceGaps}}
|
||||
|
||||
### Growth Opportunities
|
||||
|
||||
{{#growthOpportunities}}
|
||||
|
||||
- {{.}}
|
||||
{{/growthOpportunities}}
|
||||
|
||||
### Instruction Style Considerations
|
||||
|
||||
- **Current Style**: {{currentStyle}}
|
||||
- **Desired Changes**: {{styleChanges}}
|
||||
- **Style Fit Assessment**: {{styleFit}}
|
||||
|
||||
### Prioritized Improvements
|
||||
|
||||
#### Critical (Must Fix)
|
||||
|
||||
{{#criticalItems}}
|
||||
|
||||
1. {{.}}
|
||||
{{/criticalItems}}
|
||||
|
||||
#### Important (Should Fix)
|
||||
|
||||
{{#importantItems}}
|
||||
|
||||
1. {{.}}
|
||||
{{/importantItems}}
|
||||
|
||||
#### Nice-to-Have (Could Fix)
|
||||
|
||||
{{#niceItems}}
|
||||
|
||||
1. {{.}}
|
||||
{{/niceItems}}
|
||||
|
||||
### Focus Areas for Next Step
|
||||
|
||||
{{#focusAreas}}
|
||||
|
||||
- {{.}}
|
||||
{{/focusAreas}}
|
||||
|
||||
---
|
||||
|
||||
_Goals identified on {{date}}_
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
## Improvement Log
|
||||
|
||||
### Change Summary
|
||||
|
||||
- **Date**: {{date}}
|
||||
- **Improvement Area**: {{improvementArea}}
|
||||
- **User Goal**: {{userGoal}}
|
||||
|
||||
### Changes Made
|
||||
|
||||
#### Change #{{changeNumber}}
|
||||
|
||||
**Issue**: {{issueDescription}}
|
||||
**Solution**: {{solutionDescription}}
|
||||
**Rationale**: {{changeRationale}}
|
||||
|
||||
**Files Modified**:
|
||||
{{#modifiedFiles}}
|
||||
|
||||
- {{.}}
|
||||
{{/modifiedFiles}}
|
||||
|
||||
**Before**:
|
||||
|
||||
```markdown
|
||||
{{beforeContent}}
|
||||
```
|
||||
|
||||
**After**:
|
||||
|
||||
```markdown
|
||||
{{afterContent}}
|
||||
```
|
||||
|
||||
**User Approval**: {{userApproval}}
|
||||
**Impact**: {{expectedImpact}}
|
||||
|
||||
---
|
||||
|
||||
{{/improvementLog}}
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
## Validation Results
|
||||
|
||||
### Overall Status
|
||||
|
||||
**Result**: {{validationResult}}
|
||||
**Date**: {{date}}
|
||||
**Validator**: {{validator}}
|
||||
|
||||
### Validation Categories
|
||||
|
||||
#### File Structure
|
||||
|
||||
- **Status**: {{fileStructureStatus}}
|
||||
- **Details**: {{fileStructureDetails}}
|
||||
|
||||
#### Configuration
|
||||
|
||||
- **Status**: {{configurationStatus}}
|
||||
- **Details**: {{configurationDetails}}
|
||||
|
||||
#### Step Compliance
|
||||
|
||||
- **Status**: {{stepComplianceStatus}}
|
||||
- **Details**: {{stepComplianceDetails}}
|
||||
|
||||
#### Cross-File Consistency
|
||||
|
||||
- **Status**: {{consistencyStatus}}
|
||||
- **Details**: {{consistencyDetails}}
|
||||
|
||||
#### Best Practices
|
||||
|
||||
- **Status**: {{bestPracticesStatus}}
|
||||
- **Details**: {{bestPracticesDetails}}
|
||||
|
||||
### Issues Found
|
||||
|
||||
{{#validationIssues}}
|
||||
|
||||
- **{{severity}}**: {{description}}
|
||||
- **Impact**: {{impact}}
|
||||
- **Recommendation**: {{recommendation}}
|
||||
{{/validationIssues}}
|
||||
|
||||
### Validation Summary
|
||||
|
||||
{{validationSummary}}
|
||||
|
||||
---
|
||||
|
||||
_Validation completed on {{date}}_
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
## Workflow Analysis
|
||||
|
||||
### Target Workflow
|
||||
|
||||
- **Path**: {{workflowPath}}
|
||||
- **Name**: {{workflowName}}
|
||||
- **Module**: {{workflowModule}}
|
||||
- **Format**: {{workflowFormat}} (Standalone/Legacy)
|
||||
|
||||
### Structure Analysis
|
||||
|
||||
- **Type**: {{workflowType}}
|
||||
- **Total Steps**: {{stepCount}}
|
||||
- **Step Flow**: {{stepFlowPattern}}
|
||||
- **Files**: {{fileStructure}}
|
||||
|
||||
### Content Characteristics
|
||||
|
||||
- **Purpose**: {{workflowPurpose}}
|
||||
- **Instruction Style**: {{instructionStyle}}
|
||||
- **User Interaction**: {{interactionPattern}}
|
||||
- **Complexity**: {{complexityLevel}}
|
||||
|
||||
### Initial Assessment
|
||||
|
||||
#### Strengths
|
||||
|
||||
{{#strengths}}
|
||||
|
||||
- {{.}}
|
||||
{{/strengths}}
|
||||
|
||||
#### Potential Issues
|
||||
|
||||
{{#issues}}
|
||||
|
||||
- {{.}}
|
||||
{{/issues}}
|
||||
|
||||
#### Format-Specific Notes
|
||||
|
||||
{{#formatNotes}}
|
||||
|
||||
- {{.}}
|
||||
{{/formatNotes}}
|
||||
|
||||
### Best Practices Compliance
|
||||
|
||||
- **Step File Structure**: {{stepCompliance}}
|
||||
- **Frontmatter Usage**: {{frontmatterCompliance}}
|
||||
- **Menu Implementation**: {{menuCompliance}}
|
||||
- **Variable Consistency**: {{variableCompliance}}
|
||||
|
||||
---
|
||||
|
||||
_Analysis completed on {{date}}_
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
---
|
||||
name: edit-workflow
|
||||
description: Intelligent workflow editor that helps modify existing workflows while following best practices
|
||||
web_bundle: true
|
||||
---
|
||||
|
||||
# Edit Workflow
|
||||
|
||||
**Goal:** Collaboratively edit and improve existing workflows, ensuring they follow best practices and meet user needs effectively.
|
||||
|
||||
**Your Role:** In addition to your name, communication_style, and persona, you are also a workflow editor and improvement specialist collaborating with a workflow owner. This is a partnership, not a client-vendor relationship. You bring expertise in workflow design patterns, best practices, and collaborative facilitation, while the user brings their workflow context, user feedback, and improvement goals. Work together as equals.
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **step-file architecture** for disciplined execution:
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
|
||||
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
|
||||
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
||||
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
||||
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
||||
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
||||
6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step file
|
||||
|
||||
### Critical Rules (NO EXCEPTIONS)
|
||||
|
||||
- 🛑 **NEVER** load multiple step files simultaneously
|
||||
- 📖 **ALWAYS** read entire step file before execution
|
||||
- 🚫 **NEVER** skip steps or optimize the sequence
|
||||
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
|
||||
- 🎯 **ALWAYS** follow the exact instructions in the step file
|
||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||
- 📋 **NEVER** create mental todo lists from future steps
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION SEQUENCE
|
||||
|
||||
### 1. Configuration Loading
|
||||
|
||||
Load and read full config from {project-root}/_bmad/bmb/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
Load, read the full file and then execute `{workflow_path}/steps/step-01-analyze.md` to begin the workflow.
|
||||
|
|
@ -0,0 +1,179 @@
|
|||
# Agent Architecture for Modules
|
||||
|
||||
**Purpose:** High-level guidance for planning agents in your module — not implementation details (that's what the agent-builder workflow is for).
|
||||
|
||||
---
|
||||
|
||||
## Single Agent vs. Multi-Agent Module
|
||||
|
||||
### Single Agent Module
|
||||
|
||||
**Use when:** One persona can handle the module's purpose.
|
||||
|
||||
**Characteristics:**
|
||||
- Simpler, focused
|
||||
- Clear single point of contact
|
||||
- Good for narrow domains
|
||||
|
||||
**Question:** Could one expert agent with a sidecar handle this entire module?
|
||||
|
||||
---
|
||||
|
||||
### Multi-Agent Module
|
||||
|
||||
**Use when:** Different expertise areas justify specialized personas.
|
||||
|
||||
**Characteristics:**
|
||||
- Each agent has a distinct role and expertise
|
||||
- Agents form a cohesive team around the module's theme
|
||||
- Menus coordinate to guide users to the right agent
|
||||
|
||||
**Why multi-agent?**
|
||||
- Different workflows need different expert perspectives
|
||||
- Users expect to talk to "the right expert" for each task
|
||||
- The module covers a domain too broad for one persona
|
||||
|
||||
---
|
||||
|
||||
## Flagship Example: BMM Agent Team
|
||||
|
||||
BMM demonstrates a multi-agent module with **9 specialized agents** forming a complete software development team.
|
||||
|
||||
### The BMM Theme
|
||||
|
||||
**"Agile software delivery, AI-driven"**
|
||||
|
||||
Every agent serves this theme — they're a complete team working together.
|
||||
|
||||
### BMM Agent Overview
|
||||
|
||||
| Agent | Name | Role | Responsible For |
|
||||
|-------|------|------|-----------------|
|
||||
| PM | John | Product Manager | PRDs, requirements, user stories |
|
||||
| Architect | Winston | System Architect | Technical design, architecture |
|
||||
| UX | | UX Designer | User research, UX design |
|
||||
| Dev | | Developer | Implementation, coding |
|
||||
| TEA | | Test Engineer Architect | Test architecture, QA |
|
||||
| SM | | Scrum Master | Sprint planning, workflow status |
|
||||
| Tech Writer | | Technical Writer | Documentation |
|
||||
| Analyst | | Business Analyst | Analysis, metrics |
|
||||
| Quick Flow | | Solo Developer | Quick standalone work |
|
||||
|
||||
### Key Patterns
|
||||
|
||||
1. **Shared commands** — All agents have `[WS]` Workflow Status
|
||||
2. **Specialty commands** — Each agent has unique commands (PM→PRD, Architect→Architecture)
|
||||
3. **No overlap** — Each command has one clear owner
|
||||
4. **Collaboration** — Agents reference each other's work (PRD → Architecture → Implementation)
|
||||
|
||||
---
|
||||
|
||||
## Planning Your Agents
|
||||
|
||||
### For Each Agent, Document:
|
||||
|
||||
1. **Role** — What is this agent responsible for?
|
||||
2. **Workflows** — Which workflows will this agent trigger/own?
|
||||
3. **Human Name** — What's their persona name? (e.g., "John", "Winston")
|
||||
4. **Communication Style** — How do they talk? (e.g., "Direct and data-sharp", "Calm and pragmatic")
|
||||
5. **Skills/Expertise** — What knowledge does this agent bring?
|
||||
6. **Memory/Learning** — Does this agent need to remember things over time? (hasSidecar)
|
||||
|
||||
That's it! The agent-builder workflow will handle the detailed implementation.
|
||||
|
||||
---
|
||||
|
||||
## Agent Memory & Learning
|
||||
|
||||
### Sidecar Agents (hasSidecar: true)
|
||||
|
||||
**Use when:** The agent needs to remember context across sessions.
|
||||
|
||||
**Characteristics:**
|
||||
- Has a sidecar file that persists between conversations
|
||||
- Learns from user interactions
|
||||
- Remembers project details, preferences, past work
|
||||
|
||||
**Examples:**
|
||||
- An agent that tracks project decisions over time
|
||||
- An agent that learns user preferences
|
||||
- An agent that maintains ongoing project context
|
||||
|
||||
### Stateless Agents (hasSidecar: false)
|
||||
|
||||
**Use when:** The agent doesn't need persistent memory.
|
||||
|
||||
**Characteristics:**
|
||||
- Each conversation starts fresh
|
||||
- Relies on shared context files (like project-context.md)
|
||||
- Simpler, more predictable
|
||||
|
||||
**Most module agents are stateless** — they reference shared project context rather than maintaining their own memory.
|
||||
|
||||
---
|
||||
|
||||
## Agent-Workflow Coordination
|
||||
|
||||
### Menu Triggers
|
||||
|
||||
Each agent has menu items that trigger workflows:
|
||||
|
||||
| Trigger Type | Pattern | Example |
|
||||
|--------------|---------|---------|
|
||||
| Shared | Same across all agents | `[WS]` Workflow Status |
|
||||
| Specialty | Unique to this agent | `[PR]` Create PRD (PM only) |
|
||||
| Cross-reference | Points to another agent's workflow | "See architecture" |
|
||||
|
||||
### Simple Planning Format
|
||||
|
||||
For each agent, just document:
|
||||
|
||||
```
|
||||
Agent: PM (John)
|
||||
Role: Product Manager, requirements, PRDs
|
||||
Triggers:
|
||||
- WS → Workflow Status (shared)
|
||||
- PR → Create PRD (specialty)
|
||||
- ES → Epics and Stories (specialty)
|
||||
Memory: No (uses shared project-context)
|
||||
```
|
||||
|
||||
The agent-builder workflow will convert this into the proper format.
|
||||
|
||||
---
|
||||
|
||||
## When to Use Multiple Agents
|
||||
|
||||
**Consider multiple agents when:**
|
||||
- Different workflows require different expertise
|
||||
- The domain has clear specialization areas
|
||||
- Users would expect to talk to different "experts"
|
||||
- The module covers a broad process (like software development)
|
||||
|
||||
**Use a single agent when:**
|
||||
- The domain is focused and narrow
|
||||
- One expertise area covers all workflows
|
||||
- Simplicity is preferred
|
||||
- The agent could reasonably handle everything with a sidecar
|
||||
|
||||
---
|
||||
|
||||
## Quick Agent Planning Checklist
|
||||
|
||||
For each agent in your module:
|
||||
|
||||
- [ ] Role defined (what they're responsible for)
|
||||
- [ ] Workflows assigned (which workflows they trigger)
|
||||
- [ ] Human name chosen (persona)
|
||||
- [ ] Communication style described
|
||||
- [ ] Skills/expertise identified
|
||||
- [ ] Memory decision (hasSidecar: true/false)
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- **Don't worry about the exact YAML format** — agent-builder handles that
|
||||
- **Focus on the planning** — who does what, how they work together
|
||||
- **Keep it high-level** — this is about the module's agent architecture, not implementation details
|
||||
- **BMM is the reference** — look at how their agents form a cohesive team
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
# Agent Specification: {agent_name}
|
||||
|
||||
**Module:** {module_code}
|
||||
**Status:** Placeholder — To be created via create-agent workflow
|
||||
**Created:** {date}
|
||||
|
||||
---
|
||||
|
||||
## Agent Metadata
|
||||
|
||||
```yaml
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/{module_code}/agents/{agent_file_name}.md"
|
||||
name: {agent_human_name}
|
||||
title: {agent_title}
|
||||
icon: {agent_icon}
|
||||
module: {module_code}
|
||||
hasSidecar: false
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent Persona
|
||||
|
||||
### Role
|
||||
|
||||
{agent_role}
|
||||
|
||||
### Identity
|
||||
|
||||
{agent_identity}
|
||||
|
||||
### Communication Style
|
||||
|
||||
{agent_communication_style}
|
||||
|
||||
### Principles
|
||||
|
||||
{agent_principles}
|
||||
|
||||
---
|
||||
|
||||
## Agent Menu
|
||||
|
||||
### Planned Commands
|
||||
|
||||
| Trigger | Command | Description | Workflow |
|
||||
|---------|---------|-------------|----------|
|
||||
{agent_menu_table}
|
||||
|
||||
---
|
||||
|
||||
## Agent Integration
|
||||
|
||||
### Shared Context
|
||||
|
||||
- References: `{shared_context_files}`
|
||||
- Collaboration with: {collaborating_agents}
|
||||
|
||||
### Workflow References
|
||||
|
||||
{workflow_references}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
**Use the create-agent workflow to build this agent.**
|
||||
|
||||
Inputs needed:
|
||||
- Agent name and human name
|
||||
- Role and expertise area
|
||||
- Communication style preferences
|
||||
- Menu commands and workflow mappings
|
||||
|
||||
---
|
||||
|
||||
_Spec created on {date} via BMAD Module workflow_
|
||||
|
|
@ -0,0 +1,348 @@
|
|||
# Module Installer Standards
|
||||
|
||||
**Purpose:** How the `_module-installer` folder works, including installer.js patterns and platform-specific configuration.
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The `_module-installer` folder contains optional installation logic for your module. It runs AFTER the IDE installations and can:
|
||||
- Create directories specified in module.yaml
|
||||
- Copy assets or templates
|
||||
- Configure IDE-specific settings
|
||||
- Set up platform-specific integrations
|
||||
|
||||
---
|
||||
|
||||
## When Do You Need an Installer?
|
||||
|
||||
### Use an Installer When:
|
||||
|
||||
- Creating directories based on user configuration
|
||||
- Copying template files to the user's project
|
||||
- IDE-specific setup (Claude Code, Windsurf, Cursor, etc.)
|
||||
- Platform-specific integrations
|
||||
|
||||
### Skip the Installer When:
|
||||
|
||||
- Module only provides agents and workflows
|
||||
- No file operations needed
|
||||
- No IDE-specific configuration
|
||||
|
||||
---
|
||||
|
||||
## Folder Structure
|
||||
|
||||
```
|
||||
_module-installer/
|
||||
├── installer.js # Main installer (REQUIRED if folder exists)
|
||||
└── platform-specifics/ # IDE-specific handlers (optional)
|
||||
├── claude-code.js
|
||||
├── windsurf.js
|
||||
├── cursor.js
|
||||
└── ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## installer.js Pattern
|
||||
|
||||
### Function Signature
|
||||
|
||||
```javascript
|
||||
/**
|
||||
* Module Installer
|
||||
*
|
||||
* @param {Object} options - Installation options
|
||||
* @param {string} options.projectRoot - The root directory of the target project
|
||||
* @param {Object} options.config - Module configuration from module.yaml (resolved variables)
|
||||
* @param {Array<string>} options.installedIDEs - Array of IDE codes that were installed
|
||||
* @param {Object} options.logger - Logger instance for output
|
||||
* @returns {Promise<boolean>} - Success status (true = success, false = failure)
|
||||
*/
|
||||
async function install(options) {
|
||||
const { projectRoot, config, installedIDEs, logger } = options;
|
||||
|
||||
try {
|
||||
// Installation logic here
|
||||
logger.log(chalk.blue('Installing {Module Name}...'));
|
||||
|
||||
// ... your logic ...
|
||||
|
||||
logger.log(chalk.green('✓ {Module Name} installation complete'));
|
||||
return true;
|
||||
} catch (error) {
|
||||
logger.error(chalk.red(`Error installing module: ${error.message}`));
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
module.exports = { install };
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### What You Receive
|
||||
|
||||
| Parameter | Type | Description |
|
||||
|-----------|------|-------------|
|
||||
| `projectRoot` | string | Absolute path to the user's project root |
|
||||
| `config` | object | Resolved module.yaml variables |
|
||||
| `installedIDEs` | array | List of IDE codes installed (e.g., `['claude-code', 'windsurf']`) |
|
||||
| `logger` | object | Logger with `.log()`, `.warn()`, `.error()` methods |
|
||||
|
||||
The `config` object contains your module.yaml variables **after** user input:
|
||||
|
||||
```javascript
|
||||
// If module.yaml defined:
|
||||
// project_name:
|
||||
// prompt: "What is your project name?"
|
||||
// result: "{value}"
|
||||
|
||||
config.project_name // = user's input
|
||||
config.planning_artifacts // = resolved path
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Installation Tasks
|
||||
|
||||
### 1. Create Directories
|
||||
|
||||
```javascript
|
||||
const fs = require('fs-extra');
|
||||
const path = require('node:path');
|
||||
|
||||
// Create directory from config
|
||||
if (config['planning_artifacts']) {
|
||||
const dirConfig = config['planning_artifacts'].replace('{project-root}/', '');
|
||||
const dirPath = path.join(projectRoot, dirConfig);
|
||||
|
||||
if (!(await fs.pathExists(dirPath))) {
|
||||
logger.log(chalk.yellow(`Creating directory: ${dirConfig}`));
|
||||
await fs.ensureDir(dirPath);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Copy Assets
|
||||
|
||||
```javascript
|
||||
const assetsSource = path.join(__dirname, 'assets');
|
||||
const assetsDest = path.join(projectRoot, 'docs');
|
||||
|
||||
if (await fs.pathExists(assetsSource)) {
|
||||
await fs.copy(assetsSource, assetsDest);
|
||||
logger.log(chalk.green('✓ Copied assets to docs/'));
|
||||
}
|
||||
```
|
||||
|
||||
### 3. IDE-Specific Configuration
|
||||
|
||||
```javascript
|
||||
// Handle IDE-specific configurations
|
||||
if (installedIDEs && installedIDEs.length > 0) {
|
||||
logger.log(chalk.cyan(`Configuring for IDEs: ${installedIDEs.join(', ')}`));
|
||||
|
||||
for (const ide of installedIDEs) {
|
||||
await configureForIDE(ide, projectRoot, config, logger);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Platform-Specific Handlers
|
||||
|
||||
### Pattern
|
||||
|
||||
Create files in `platform-specifics/{ide-code}.js`:
|
||||
|
||||
```javascript
|
||||
// platform-specifics/claude-code.js
|
||||
|
||||
/**
|
||||
* Configure module for Claude Code
|
||||
*/
|
||||
async function install(options) {
|
||||
const { projectRoot, config, logger, platformInfo } = options;
|
||||
|
||||
try {
|
||||
// Claude Code specific configuration
|
||||
logger.log(chalk.dim(' Configuring Claude Code integration...'));
|
||||
|
||||
// Your logic here
|
||||
|
||||
return true;
|
||||
} catch (error) {
|
||||
logger.warn(chalk.yellow(` Warning: ${error.message}`));
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
module.exports = { install };
|
||||
```
|
||||
|
||||
### Load from Main Installer
|
||||
|
||||
```javascript
|
||||
// installer.js
|
||||
const platformCodes = require(path.join(__dirname, '../../../../tools/cli/lib/platform-codes'));
|
||||
|
||||
async function configureForIDE(ide, projectRoot, config, logger) {
|
||||
// Validate platform code
|
||||
if (!platformCodes.isValidPlatform(ide)) {
|
||||
logger.warn(chalk.yellow(` Unknown platform: '${ide}'. Skipping.`));
|
||||
return;
|
||||
}
|
||||
|
||||
const platformName = platformCodes.getDisplayName(ide);
|
||||
const platformSpecificPath = path.join(__dirname, 'platform-specifics', `${ide}.js`);
|
||||
|
||||
try {
|
||||
if (await fs.pathExists(platformSpecificPath)) {
|
||||
const platformHandler = require(platformSpecificPath);
|
||||
|
||||
if (typeof platformHandler.install === 'function') {
|
||||
await platformHandler.install({ projectRoot, config, logger });
|
||||
logger.log(chalk.green(` ✓ Configured for ${platformName}`));
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
logger.warn(chalk.yellow(` Warning: Could not configure ${platformName}: ${error.message}`));
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Complete Example: BMM Installer
|
||||
|
||||
```javascript
|
||||
const fs = require('fs-extra');
|
||||
const path = require('node:path');
|
||||
const chalk = require('chalk');
|
||||
const platformCodes = require(path.join(__dirname, '../../../../tools/cli/lib/platform-codes'));
|
||||
|
||||
/**
|
||||
* BMM Module Installer
|
||||
*/
|
||||
async function install(options) {
|
||||
const { projectRoot, config, installedIDEs, logger } = options;
|
||||
|
||||
try {
|
||||
logger.log(chalk.blue('🚀 Installing BMM Module...'));
|
||||
|
||||
// Create output directory
|
||||
if (config['output_folder']) {
|
||||
const outputConfig = config['output_folder'].replace('{project-root}/', '');
|
||||
const outputPath = path.join(projectRoot, outputConfig);
|
||||
if (!(await fs.pathExists(outputPath))) {
|
||||
logger.log(chalk.yellow(`Creating output directory: ${outputConfig}`));
|
||||
await fs.ensureDir(outputPath);
|
||||
}
|
||||
}
|
||||
|
||||
// Create implementation artifacts directory
|
||||
if (config['implementation_artifacts']) {
|
||||
const storyConfig = config['implementation_artifacts'].replace('{project-root}/', '');
|
||||
const storyPath = path.join(projectRoot, storyConfig);
|
||||
if (!(await fs.pathExists(storyPath))) {
|
||||
logger.log(chalk.yellow(`Creating story directory: ${storyConfig}`));
|
||||
await fs.ensureDir(storyPath);
|
||||
}
|
||||
}
|
||||
|
||||
// IDE-specific configuration
|
||||
if (installedIDEs && installedIDEs.length > 0) {
|
||||
logger.log(chalk.cyan(`Configuring BMM for IDEs: ${installedIDEs.join(', ')}`));
|
||||
|
||||
for (const ide of installedIDEs) {
|
||||
await configureForIDE(ide, projectRoot, config, logger);
|
||||
}
|
||||
}
|
||||
|
||||
logger.log(chalk.green('✓ BMM Module installation complete'));
|
||||
return true;
|
||||
} catch (error) {
|
||||
logger.error(chalk.red(`Error installing BMM: ${error.message}`));
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
async function configureForIDE(ide, projectRoot, config, logger) {
|
||||
if (!platformCodes.isValidPlatform(ide)) {
|
||||
logger.warn(chalk.yellow(` Warning: Unknown platform '${ide}'. Skipping.`));
|
||||
return;
|
||||
}
|
||||
|
||||
const platformSpecificPath = path.join(__dirname, 'platform-specifics', `${ide}.js`);
|
||||
|
||||
try {
|
||||
if (await fs.pathExists(platformSpecificPath)) {
|
||||
const platformHandler = require(platformSpecificPath);
|
||||
|
||||
if (typeof platformHandler.install === 'function') {
|
||||
await platformHandler.install({ projectRoot, config, logger });
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
logger.warn(chalk.yellow(` Warning: Could not load handler for ${ide}: ${error.message}`));
|
||||
}
|
||||
}
|
||||
|
||||
module.exports = { install };
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO:
|
||||
- Return `true` for success, `false` for failure
|
||||
- Use chalk for colored output
|
||||
- Log what you're doing (create, copy, configure)
|
||||
- Handle errors gracefully with try/catch
|
||||
- Validate paths before creating directories
|
||||
|
||||
### DON'T:
|
||||
- Assume paths exist — check with `fs.pathExists()`
|
||||
- Overwrite user files without asking
|
||||
- Fail silently — log errors
|
||||
- Use absolute paths — build from `projectRoot`
|
||||
|
||||
---
|
||||
|
||||
## Available Platform Codes
|
||||
|
||||
Common IDE codes:
|
||||
- `claude-code` — Anthropic's Claude Code
|
||||
- `windsurf` — Windsurf IDE
|
||||
- `cursor` — Cursor AI IDE
|
||||
- `vscode` — Visual Studio Code
|
||||
|
||||
Use `platformCodes.isValidPlatform(ide)` to validate.
|
||||
|
||||
---
|
||||
|
||||
## Testing Your Installer
|
||||
|
||||
1. Create a test project
|
||||
2. Run `bmad install {your-module}`
|
||||
3. Verify directories are created
|
||||
4. Check that config variables are resolved correctly
|
||||
5. Test platform-specific handlers
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Task | Code Pattern |
|
||||
|------|--------------|
|
||||
| Create directory | `await fs.ensureDir(path)` |
|
||||
| Check if exists | `await fs.pathExists(path)` |
|
||||
| Copy files | `await fs.copy(src, dest)` |
|
||||
| Log info | `logger.log(chalk.blue('message'))` |
|
||||
| Log success | `logger.log(chalk.green('✓ message'))` |
|
||||
| Log warning | `logger.warn(chalk.yellow('warning'))` |
|
||||
| Log error | `logger.error(chalk.red('error'))` |
|
||||
|
|
@ -0,0 +1,280 @@
|
|||
# Module Standards
|
||||
|
||||
**Purpose:** Defines what a BMAD module is, its structure, and the three types of modules.
|
||||
|
||||
---
|
||||
|
||||
## What is a BMAD Module?
|
||||
|
||||
A **BMAD module** is a self-contained package of functionality that extends the BMAD framework. Modules provide:
|
||||
- **Agents** — AI personas with specialized expertise and menu-driven commands
|
||||
- **Workflows** — Structured processes for accomplishing complex tasks
|
||||
- **Configuration** — module.yaml for user customization
|
||||
- **Installation** — Optional installer.js for setup logic
|
||||
|
||||
---
|
||||
|
||||
## Module Types
|
||||
|
||||
### 1. Standalone Module
|
||||
|
||||
A new, independent module focused on a specific domain.
|
||||
|
||||
**Characteristics:**
|
||||
- Own module code (e.g., `healthcare-ai`, `legal-assist`)
|
||||
- Independent of other modules
|
||||
- Can be installed alongside any other modules
|
||||
- Has its own agents, workflows, configuration
|
||||
|
||||
**Location:** `src/modules/{module-code}/`
|
||||
|
||||
**Example:** CIS (Creative Innovation Suite) — a standalone module for innovation workflows
|
||||
|
||||
---
|
||||
|
||||
### 2. Extension Module
|
||||
|
||||
Extends an existing BMAD module with additional functionality.
|
||||
|
||||
**Characteristics:**
|
||||
- Builds upon an existing module's agents and workflows
|
||||
- May add new agents or workflows that complement the base module
|
||||
- Shares configuration context with the extended module
|
||||
- Typically installed alongside the module it extends
|
||||
|
||||
**Location:** `src/modules/{base-module}/extensions/{extension-code}/`
|
||||
|
||||
**Example:** An extension to BMM that adds specialized security review workflows
|
||||
|
||||
---
|
||||
|
||||
### Extension Module: Override & Merge Pattern
|
||||
|
||||
When an extension module is installed, its files merge with the base module following these rules:
|
||||
|
||||
#### Code Matching
|
||||
|
||||
The extension's `module.yaml` `code:` field matches the base module's code:
|
||||
|
||||
```yaml
|
||||
# Base module: src/modules/bmm/module.yaml
|
||||
code: bmm
|
||||
|
||||
# Extension: src/modules/bmm/extensions/security/module.yaml
|
||||
code: bmm # SAME CODE — extends BMM
|
||||
```
|
||||
|
||||
The **folder name** is unique (e.g., `bmm-security`) but the `code:` matches the base module.
|
||||
|
||||
#### File Merge Rules
|
||||
|
||||
| File Type | Same Name | Different Name |
|
||||
|-----------|-----------|----------------|
|
||||
| Agent file | **OVERRIDE** — replaces the base agent | **ADD** — new agent added |
|
||||
| Workflow folder | **OVERRIDE** — replaces the base workflow | **ADD** — new workflow added |
|
||||
| Other files | **OVERRIDE** — replaces base file | **ADD** — new file added |
|
||||
|
||||
#### Examples
|
||||
|
||||
**Override scenario:**
|
||||
```
|
||||
Base module (BMM):
|
||||
├── agents/
|
||||
│ └── pm.agent.yaml # Original PM agent
|
||||
|
||||
Extension (bmm-security):
|
||||
├── agents/
|
||||
│ └── pm.agent.yaml # Security-focused PM — REPLACES original
|
||||
|
||||
Result after installation:
|
||||
├── agents/
|
||||
│ └── pm.agent.yaml # Now the security version
|
||||
```
|
||||
|
||||
**Add scenario:**
|
||||
```
|
||||
Base module (BMM):
|
||||
├── agents/
|
||||
│ ├── pm.agent.yaml
|
||||
│ └── architect.agent.yaml
|
||||
|
||||
Extension (bmm-security):
|
||||
├── agents/
|
||||
│ └── security-auditor.agent.yaml # NEW agent
|
||||
|
||||
Result after installation:
|
||||
├── agents/
|
||||
│ ├── pm.agent.yaml
|
||||
│ ├── architect.agent.yaml
|
||||
│ └── security-auditor.agent.yaml # ADDED
|
||||
```
|
||||
|
||||
**Mixed scenario:**
|
||||
```
|
||||
Extension contains both overrides and new files — applies rules per file
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Global Module
|
||||
|
||||
Affects the entire BMAD framework and all modules.
|
||||
|
||||
**Characteristics:**
|
||||
- Core functionality that impacts all modules
|
||||
- Often provides foundational services or utilities
|
||||
- Installed at the framework level
|
||||
- Use sparingly — only for truly global concerns
|
||||
|
||||
**Location:** `src/modules/{module-code}/` with `global: true` in module.yaml
|
||||
|
||||
**Example:** A module that provides universal logging or telemetry across BMAD
|
||||
|
||||
---
|
||||
|
||||
## Required Module Structure
|
||||
|
||||
```
|
||||
{module-code}/
|
||||
├── module.yaml # Module configuration (REQUIRED)
|
||||
├── README.md # Module documentation (REQUIRED)
|
||||
├── agents/ # Agent definitions (if any)
|
||||
│ └── {agent-name}.agent.yaml
|
||||
├── workflows/ # Workflow definitions (if any)
|
||||
│ └── {workflow-name}/
|
||||
│ └── workflow.md
|
||||
├── _module-installer/ # Installation logic (optional)
|
||||
│ ├── installer.js
|
||||
│ └── platform-specifics/
|
||||
│ ├── claude-code.js
|
||||
│ ├── windsurf.js
|
||||
│ └── ...
|
||||
└── {other folders} # Tasks, templates, data as needed
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Required Files
|
||||
|
||||
### module.yaml (REQUIRED)
|
||||
|
||||
Every module MUST have a `module.yaml` file with at minimum:
|
||||
|
||||
```yaml
|
||||
code: {module-code}
|
||||
name: "Module Display Name"
|
||||
header: "Brief module description"
|
||||
subheader: "Additional context"
|
||||
default_selected: false
|
||||
```
|
||||
|
||||
See: `module-yaml-conventions.md` for full specification.
|
||||
|
||||
---
|
||||
|
||||
### README.md (REQUIRED)
|
||||
|
||||
Every module MUST have a README.md with:
|
||||
- Module name and purpose
|
||||
- Installation instructions
|
||||
- Components section (agents, workflows)
|
||||
- Quick start guide
|
||||
- Module structure diagram
|
||||
- Configuration section
|
||||
- Usage examples
|
||||
- Author information
|
||||
|
||||
---
|
||||
|
||||
## Optional Components
|
||||
|
||||
### Agents
|
||||
|
||||
Agents are AI personas with:
|
||||
- Metadata (id, name, title, icon, module)
|
||||
- Persona (role, identity, communication_style, principles)
|
||||
- Menu (trigger → workflow/exec mappings)
|
||||
|
||||
See: `agent-architecture.md` for design guidance.
|
||||
|
||||
---
|
||||
|
||||
### Workflows
|
||||
|
||||
Workflows are structured processes with:
|
||||
- workflow.md (entry point)
|
||||
- steps/ folder with step files
|
||||
- data/ folder with shared reference
|
||||
- templates/ folder if needed
|
||||
|
||||
---
|
||||
|
||||
### _module-installer/
|
||||
|
||||
Optional installation logic for:
|
||||
- Creating directories
|
||||
- Copying assets
|
||||
- IDE-specific configuration
|
||||
- Platform-specific setup
|
||||
|
||||
See: `module-installer-standards.md` for patterns.
|
||||
|
||||
---
|
||||
|
||||
## Module Type Decision Tree
|
||||
|
||||
```
|
||||
START: Creating a module
|
||||
│
|
||||
├─ Is this a brand new independent domain?
|
||||
│ └─ YES → Standalone Module
|
||||
│
|
||||
├─ Does this extend an existing module?
|
||||
│ └─ YES → Extension Module
|
||||
│
|
||||
└─ Does this affect all modules globally?
|
||||
└─ YES → Global Module (use sparingly)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
### Module Code
|
||||
|
||||
- **kebab-case** (e.g., `bmm`, `cis`, `bmgd`, `healthcare-ai`)
|
||||
- Short, memorable, descriptive
|
||||
- 2-20 characters
|
||||
- Lowercase letters, numbers, hyphens only
|
||||
|
||||
### Agent Files
|
||||
|
||||
- Format: `{role-name}.agent.yaml`
|
||||
- Example: `pm.agent.yaml`, `architect.agent.yaml`
|
||||
|
||||
### Workflow Folders
|
||||
|
||||
- Format: `{workflow-name}/`
|
||||
- Example: `prd/`, `create-architecture/`
|
||||
|
||||
---
|
||||
|
||||
## Module Dependencies
|
||||
|
||||
Modules can depend on:
|
||||
- **Core BMAD** — Always available
|
||||
- **Other modules** — Specify in module.yaml as `dependencies:`
|
||||
- **External tools** — Document in README, handle in installer
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Question | Answer |
|
||||
|----------|--------|
|
||||
| What's a module? | Self-contained package of agents, workflows, config |
|
||||
| What are the types? | Standalone, Extension, Global |
|
||||
| What's required? | module.yaml, README.md |
|
||||
| Where do modules live? | `src/modules/{code}/` |
|
||||
| How do agents work? | Menu triggers → workflow/exec |
|
||||
| How does installation work? | module.yaml prompts + optional installer.js |
|
||||
|
|
@ -0,0 +1,392 @@
|
|||
# module.yaml Conventions
|
||||
|
||||
**Purpose:** Defines how module.yaml works, including variables, templates, and how they provide context to agents and workflows.
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
`module.yaml` is the configuration file for a BMAD module. It:
|
||||
- Defines module metadata (code, name, description)
|
||||
- Collects user input via prompts during installation
|
||||
- Makes those inputs available to agents and workflows as variables
|
||||
- Specifies which module should be selected by default
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Fields
|
||||
|
||||
### Required Fields
|
||||
|
||||
```yaml
|
||||
code: {module-code} # kebab-case identifier
|
||||
name: "Display Name" # Human-readable name
|
||||
header: "Brief description" # One-line summary
|
||||
subheader: "Additional context" # More detail
|
||||
default_selected: false # Auto-select on install?
|
||||
```
|
||||
|
||||
### `default_selected` Guidelines
|
||||
|
||||
| Module Type | default_selected | Example |
|
||||
|-------------|------------------|---------|
|
||||
| Core/Primary | `true` | BMM (agile software delivery) |
|
||||
| Specialized | `false` | CIS (creative innovation), BMGD (game dev) |
|
||||
| Experimental | `false` | New modules in development |
|
||||
|
||||
---
|
||||
|
||||
## Variables System
|
||||
|
||||
### Core Config Variables (Always Available)
|
||||
|
||||
These variables are automatically available to ALL modules:
|
||||
|
||||
```yaml
|
||||
# Variables from Core Config inserted:
|
||||
## user_name # User's name
|
||||
## communication_language # Preferred language
|
||||
## document_output_language # Output document language
|
||||
## output_folder # Default output location
|
||||
```
|
||||
|
||||
No need to define these — they're injected automatically.
|
||||
|
||||
---
|
||||
|
||||
### Custom Variables
|
||||
|
||||
Define custom variables for user input:
|
||||
|
||||
```yaml
|
||||
variable_name:
|
||||
prompt: "Question to ask the user?"
|
||||
default: "{default_value}"
|
||||
result: "{template_for_final_value}"
|
||||
```
|
||||
|
||||
**Example:**
|
||||
|
||||
```yaml
|
||||
project_name:
|
||||
prompt: "What is the title of your project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
### Variable Templates
|
||||
|
||||
In `prompt` and `result`, you can use templates:
|
||||
|
||||
| Template | Expands To |
|
||||
|----------|------------|
|
||||
| `{value}` | The user's input |
|
||||
| `{directory_name}` | Current directory name |
|
||||
| `{output_folder}` | Output folder from core config |
|
||||
| `{project-root}` | Project root path |
|
||||
| `{variable_name}` | Another variable's value |
|
||||
|
||||
---
|
||||
|
||||
## Variable Types
|
||||
|
||||
### 1. Simple Text Input
|
||||
|
||||
```yaml
|
||||
project_name:
|
||||
prompt: "What is the title of your project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Boolean/Flag
|
||||
|
||||
```yaml
|
||||
enable_feature:
|
||||
prompt: "Enable this feature?"
|
||||
default: false
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Single Select
|
||||
|
||||
```yaml
|
||||
skill_level:
|
||||
prompt: "What is your experience level?"
|
||||
default: "intermediate"
|
||||
result: "{value}"
|
||||
single-select:
|
||||
- value: "beginner"
|
||||
label: "Beginner - Explains concepts clearly"
|
||||
- value: "intermediate"
|
||||
label: "Intermediate - Balanced approach"
|
||||
- value: "expert"
|
||||
label: "Expert - Direct and technical"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. Multi Select
|
||||
|
||||
```yaml
|
||||
platforms:
|
||||
prompt: "Which platforms do you need?"
|
||||
default: ["unity", "unreal"]
|
||||
result: "{value}"
|
||||
multi-select:
|
||||
- value: "unity"
|
||||
label: "Unity"
|
||||
- value: "unreal"
|
||||
label: "Unreal Engine"
|
||||
- value: "godot"
|
||||
label: "Godot"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. Multi-Line Prompt
|
||||
|
||||
```yaml
|
||||
complex_variable:
|
||||
prompt:
|
||||
- "First question?"
|
||||
- "Second context?"
|
||||
- "Third detail?"
|
||||
default: "default_value"
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6. Required Variable
|
||||
|
||||
```yaml
|
||||
critical_variable:
|
||||
prompt: "Required information:"
|
||||
required: true
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7. Path Variable
|
||||
|
||||
```yaml
|
||||
artifacts_folder:
|
||||
prompt: "Where should artifacts be stored?"
|
||||
default: "{output_folder}/artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Variable Inheritance / Aliasing
|
||||
|
||||
Create an alias for another variable:
|
||||
|
||||
```yaml
|
||||
primary_artifacts:
|
||||
prompt: "Where should primary artifacts be stored?"
|
||||
default: "{output_folder}/artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
# Alias for workflow compatibility
|
||||
sprint_artifacts:
|
||||
inherit: "primary_artifacts"
|
||||
```
|
||||
|
||||
Now `sprint_artifacts` and `primary_artifacts` reference the same value.
|
||||
|
||||
---
|
||||
|
||||
## How Variables Become Available
|
||||
|
||||
### To Agents
|
||||
|
||||
After installation, variables are available in agent frontmatter/context:
|
||||
|
||||
```yaml
|
||||
# In agent.agent.yaml or workflow execution
|
||||
{variable_name} # Expands to the user's configured value
|
||||
```
|
||||
|
||||
**Example:** If the user configured `project_name: "MyApp"`, agents can reference `{project_name}` and it will expand to `"MyApp"`.
|
||||
|
||||
### To Workflows
|
||||
|
||||
Workflows can reference module variables in their step files:
|
||||
|
||||
```yaml
|
||||
---
|
||||
outputFile: '{implementation_artifacts}/my-output.md'
|
||||
---
|
||||
```
|
||||
|
||||
This expands the `implementation_artifacts` variable from module.yaml.
|
||||
|
||||
---
|
||||
|
||||
## Real-World Examples
|
||||
|
||||
### BMM (BMad Method) — Complex Configuration
|
||||
|
||||
```yaml
|
||||
code: bmm
|
||||
name: "BMM: BMad Method Agile-AI Driven-Development"
|
||||
header: "BMad Method™: Breakthrough Method of Agile-Ai Driven-Dev"
|
||||
subheader: "Agent and Workflow Configuration for this module"
|
||||
default_selected: true
|
||||
|
||||
# Variables from Core Config inserted:
|
||||
## user_name
|
||||
## communication_language
|
||||
## document_output_language
|
||||
## output_folder
|
||||
|
||||
project_name:
|
||||
prompt: "What is the title of your project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
|
||||
user_skill_level:
|
||||
prompt:
|
||||
- "What is your development experience level?"
|
||||
- "This affects how agents explain concepts."
|
||||
default: "intermediate"
|
||||
result: "{value}"
|
||||
single-select:
|
||||
- value: "beginner"
|
||||
label: "Beginner - Explain concepts clearly"
|
||||
- value: "intermediate"
|
||||
label: "Intermediate - Balanced approach"
|
||||
- value: "expert"
|
||||
label: "Expert - Direct and technical"
|
||||
|
||||
planning_artifacts:
|
||||
prompt: "Where should planning artifacts be stored?"
|
||||
default: "{output_folder}/planning-artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
implementation_artifacts:
|
||||
prompt: "Where should implementation artifacts be stored?"
|
||||
default: "{output_folder}/implementation-artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
project_knowledge:
|
||||
prompt: "Where should project knowledge be stored?"
|
||||
default: "docs"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
tea_use_mcp_enhancements:
|
||||
prompt: "Enable MCP enhancements in Test Architect?"
|
||||
default: false
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### CIS (Creative Innovation Suite) — Minimal Configuration
|
||||
|
||||
```yaml
|
||||
code: cis
|
||||
name: "CIS: Creative Innovation Suite"
|
||||
header: "Creative Innovation Suite (CIS) Module"
|
||||
subheader: "No custom configuration - uses Core settings only"
|
||||
default_selected: false
|
||||
|
||||
# Variables from Core Config inserted:
|
||||
## user_name
|
||||
## communication_language
|
||||
## document_output_language
|
||||
## output_folder
|
||||
```
|
||||
|
||||
Some modules don't need custom variables — core config is enough!
|
||||
|
||||
---
|
||||
|
||||
### BMGD (Game Development) — Multi-Select Example
|
||||
|
||||
```yaml
|
||||
code: bmgd
|
||||
name: "BMGD: BMad Game Development"
|
||||
header: "BMad Game Development Module"
|
||||
subheader: "Configure game development settings"
|
||||
default_selected: false
|
||||
|
||||
project_name:
|
||||
prompt: "What is the name of your game project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
|
||||
primary_platform:
|
||||
prompt: "Which game engine do you use?"
|
||||
default: ["unity", "unreal"]
|
||||
required: true
|
||||
result: "{value}"
|
||||
multi-select:
|
||||
- value: "unity"
|
||||
label: "Unity"
|
||||
- value: "unreal"
|
||||
label: "Unreal Engine"
|
||||
- value: "godot"
|
||||
label: "Godot"
|
||||
- value: "other"
|
||||
label: "Custom / Other"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO:
|
||||
- Keep prompts clear and concise
|
||||
- Provide sensible defaults
|
||||
- Use `result: "{project-root}/{value}"` for paths
|
||||
- Use single/multi-select for structured choices
|
||||
- Group related variables logically
|
||||
|
||||
### DON'T:
|
||||
- Overwhelm users with too many questions
|
||||
- Ask for information that could be inferred
|
||||
- Use technical jargon in prompts
|
||||
- Create variables that are never used
|
||||
|
||||
---
|
||||
|
||||
## Variable Naming
|
||||
|
||||
- **kebab-case** (e.g., `planning_artifacts`, `user_skill_level`)
|
||||
- Descriptive but concise
|
||||
- Avoid conflicts with core variables
|
||||
|
||||
---
|
||||
|
||||
## Testing Your module.yaml
|
||||
|
||||
After creating module.yaml, test it:
|
||||
|
||||
1. Run `bmad install` in a test project
|
||||
2. Verify prompts appear correctly
|
||||
3. Check that variables expand in agents/workflows
|
||||
4. Test default values
|
||||
5. Validate path templates resolve correctly
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Pattern | Use Case |
|
||||
|---------|----------|
|
||||
| Simple text input | Names, titles, descriptions |
|
||||
| Boolean/Flag | Enable/disable features |
|
||||
| Single select | Experience levels, categories |
|
||||
| Multi select | Platforms, frameworks, options |
|
||||
| Multi-line prompt | Complex questions needing context |
|
||||
| Required | Must-have information |
|
||||
| Path variable | Directory locations |
|
||||
| Inherit/Alias | Compatibility, references |
|
||||
|
|
@ -0,0 +1,147 @@
|
|||
---
|
||||
name: 'step-01-welcome'
|
||||
description: 'Welcome user, select mode (Interactive/Express/YOLO), gather initial idea'
|
||||
|
||||
nextStepFile: './step-02-spark.md'
|
||||
briefTemplateFile: '../templates/brief-template.md'
|
||||
moduleStandardsFile: '../data/module-standards.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 1: Welcome & Mode Selection
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Welcome the user to the Module Brief workflow, select the collaboration mode (Interactive/Express/YOLO), and gather their initial module idea.
|
||||
|
||||
## 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 with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Architect** — creative, inspiring, helping users discover amazing module ideas
|
||||
- ✅ This is explorative and collaborative — not a template-filling exercise
|
||||
- ✅ Help users clarify and expand their vision
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Set the creative tone — this is about discovering possibilities
|
||||
- 🚫 FORBIDDEN to jump straight to technical details
|
||||
- 💬 Ask questions that spark imagination
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 💾 No output file yet — gathering initial context
|
||||
- 📖 Load next step when user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available: module standards, brief template
|
||||
- Focus: Initial idea gathering and mode selection
|
||||
- No existing brief — this is a fresh start
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
|
||||
|
||||
### 1. Welcome with Enthusiasm
|
||||
|
||||
"**Welcome to the Module Brief workflow!** 🚀
|
||||
|
||||
I'm here to help you create an amazing BMAD module. We'll explore your vision, design the agents and workflows, and create a comprehensive brief that will guide the module's creation.
|
||||
|
||||
Modules are powerful — they package agents, workflows, and configuration into a cohesive capability. Let's make something great!"
|
||||
|
||||
### 2. Select Collaboration Mode
|
||||
|
||||
"**How would you like to work?**"
|
||||
|
||||
- **[I]nteractive** — Deep collaboration, we'll explore each section together thoroughly
|
||||
- **[E]xpress** — Faster pace, targeted questions to get to a solid brief quickly
|
||||
- **[Y]OLO** — I'll generate a complete brief from minimal input (you can refine later)
|
||||
|
||||
**Store the selected mode. This affects how we proceed through subsequent steps.**
|
||||
|
||||
### 3. Gather the Initial Idea
|
||||
|
||||
"**Tell me about your module idea.**"
|
||||
|
||||
Encourage them to share:
|
||||
- What problem does it solve?
|
||||
- Who would use it?
|
||||
- What excites you about it?
|
||||
|
||||
**If they're stuck**, offer creative prompts:
|
||||
- "What domain do you work in? What tasks feel repetitive or could be AI-powered?"
|
||||
- "Imagine you had a team of AI experts at your disposal — what would you ask them to build?"
|
||||
- "Is there a module you wish existed?"
|
||||
|
||||
**Capture their initial idea.** We'll explore and expand it in the next steps.
|
||||
|
||||
### 4. Preview the Journey Ahead
|
||||
|
||||
"**Here's where we're going together:**"
|
||||
|
||||
1. Spark — Explore and clarify your idea
|
||||
2. Module Type — Standalone, Extension, or Global?
|
||||
3. Vision — What would make this extraordinary?
|
||||
4. Identity — Name, code, personality
|
||||
5. Users — Who is this for?
|
||||
6. Value — What makes it special?
|
||||
7. Agents — Who's on your team?
|
||||
8. Workflows — What can we do?
|
||||
9. Tools — MCP tools, integrations?
|
||||
10. Scenarios — How will people use it?
|
||||
11. Creative — Easter eggs, lore, magic ✨
|
||||
12. Review — Read through together
|
||||
13. Finalize — Your complete brief
|
||||
|
||||
"**This is about discovery and creativity. We're not filling out forms — we're designing something amazing together.**"
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can chat or ask questions — always respond and redisplay menu
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}` for deeper idea exploration, then redisplay menu
|
||||
- IF P: Execute `{partyModeWorkflow}` for creative brainstorming, then redisplay menu
|
||||
- IF C: Store the mode and initial idea, then load `{nextStepFile}`
|
||||
- IF Any other: Help user, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- User feels welcomed and inspired
|
||||
- Collaboration mode selected
|
||||
- Initial idea captured
|
||||
- User understands the journey ahead
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping to technical details prematurely
|
||||
- Not capturing the initial idea
|
||||
- Not setting the creative tone
|
||||
- Rushing through mode selection
|
||||
|
||||
**Master Rule:** This step sets the tone for the entire brief — make it inspiring and collaborative.
|
||||
|
|
@ -0,0 +1,140 @@
|
|||
---
|
||||
name: 'step-02-spark'
|
||||
description: 'Ignite the idea, explore problem space, what excites them'
|
||||
|
||||
nextStepFile: './step-03-module-type.md'
|
||||
moduleStandardsFile: '../data/module-standards.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 2: Spark
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Ignite and explore the user's idea — dig into the problem space, understand what excites them, and help clarify the vision.
|
||||
|
||||
## 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 with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Architect** — curious, explorative, helping ideas grow
|
||||
- ✅ Ask open-ended questions that reveal depth
|
||||
- ✅ Listen more than you speak
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 This is about understanding the problem space, not solving it yet
|
||||
- 🚫 FORBIDDEN to jump to implementation
|
||||
- 💬 Ask "why" and "what if" questions
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 📖 Reference module standards to understand types
|
||||
- 📖 Load next step when user selects 'C'
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly.
|
||||
|
||||
### 1. Connect to Their Idea
|
||||
|
||||
"**Let's explore your idea together.**"
|
||||
|
||||
Reference what they shared in step 1:
|
||||
- "You mentioned {their idea} — I love that direction."
|
||||
- "Tell me more about the problem you're solving."
|
||||
|
||||
### 2. Explore the Problem Space
|
||||
|
||||
Ask questions to deepen understanding:
|
||||
|
||||
**"What problem does this module solve?"**
|
||||
|
||||
- Who feels this problem right now?
|
||||
- What do they currently do without this module?
|
||||
- What would change if this existed?
|
||||
|
||||
**"What excites you about this idea?"**
|
||||
|
||||
- Why THIS module? Why now?
|
||||
- What's the vision — the dream outcome?
|
||||
- If this module succeeds wildly, what does that look like?
|
||||
|
||||
### 3. Identify the Users
|
||||
|
||||
**"Who is this module for?"**
|
||||
|
||||
Help them think about:
|
||||
- Primary users — who will use this most?
|
||||
- Secondary users — who else benefits?
|
||||
- What do these users care about?
|
||||
|
||||
### 4. Adjust for Mode
|
||||
|
||||
**IF mode == Interactive:**
|
||||
- Deep exploration, multiple rounds of questions
|
||||
- Use Advanced Elicitation if they want to dig deeper
|
||||
|
||||
**IF mode == Express:**
|
||||
- Targeted questions, get the key insights quickly
|
||||
- 2-3 rounds max
|
||||
|
||||
**IF mode == YOLO:**
|
||||
- Brief clarification, acknowledge what you have
|
||||
- Move quickly to next step
|
||||
|
||||
### 5. Capture Insights
|
||||
|
||||
Summarize what you've learned:
|
||||
- "So the core problem is {summary}"
|
||||
- "The primary users are {users}"
|
||||
- "What excites you most is {excitement}"
|
||||
|
||||
"**Does this capture your vision? Anything to add or refine?**"
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}` for deeper exploration
|
||||
- IF P: Execute `{partyModeWorkflow}` for creative ideation
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help user, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Problem space clearly understood
|
||||
- User excitement identified
|
||||
- Target users clarified
|
||||
- Vision feels solid
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping to solutions too quickly
|
||||
- Not understanding the problem
|
||||
- Not capturing what excites them
|
||||
|
||||
**Master Rule:** Understand before you build. This step is about clarity, not solutions.
|
||||
|
|
@ -0,0 +1,148 @@
|
|||
---
|
||||
name: 'step-03-module-type'
|
||||
description: 'EARLY decision: Standalone, Extension, or Global module?'
|
||||
|
||||
nextStepFile: './step-04-vision.md'
|
||||
moduleStandardsFile: '../data/module-standards.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 3: Module Type
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Make the EARLY key decision: Is this a Standalone, Extension, or Global module? This decision affects everything that follows.
|
||||
|
||||
## 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 with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Architect** — you understand module types and their implications
|
||||
- ✅ Help the user make an informed decision
|
||||
- ✅ This is a commitment — get it right
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 This decision MUST happen early
|
||||
- 🚫 FORBIDDEN to proceed without clarity on module type
|
||||
- 💬 Explain the trade-offs clearly
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load `{moduleStandardsFile}` to reference module types
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 📖 Load next step when user selects 'C'
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly.
|
||||
|
||||
### 1. Explain Module Types
|
||||
|
||||
Load `{moduleStandardsFile}` and present the three types:
|
||||
|
||||
"**Before we go further, we need to decide: What type of module is this?** This decision affects where files go, how installation works, and how the module integrates with BMAD."
|
||||
|
||||
**Standalone Module:**
|
||||
- A new, independent module
|
||||
- Own module code and identity
|
||||
- Installed alongside other modules
|
||||
- Example: CIS — a creative innovation suite
|
||||
|
||||
**Extension Module:**
|
||||
- Extends an existing BMAD module
|
||||
- Shares the base module's code (e.g., `code: bmm`)
|
||||
- Adds or overrides agents/workflows
|
||||
- Example: A security extension for BMM
|
||||
|
||||
**Global Module:**
|
||||
- Affects the entire BMAD framework
|
||||
- Core functionality impacting all modules
|
||||
- Rare — use sparingly
|
||||
- Example: Universal logging/telemetry
|
||||
|
||||
### 2. Determine Type Together
|
||||
|
||||
**"Based on your idea, what type makes sense?"**
|
||||
|
||||
Help them think through:
|
||||
- **"Is this a brand new domain?"** → Likely Standalone
|
||||
- **"Does this build on an existing module?"** → Likely Extension
|
||||
- **"Does this affect all modules?"** → Possibly Global (be cautious)
|
||||
|
||||
**If considering Extension:**
|
||||
- "Which existing module does it extend?"
|
||||
- "Are you adding new agents/workflows, or modifying existing ones?"
|
||||
- "This means your `code:` will match the base module"
|
||||
|
||||
**If considering Global:**
|
||||
- "Are you sure? Global modules are rare."
|
||||
- "Could this be a standalone module instead?"
|
||||
|
||||
### 3. Confirm and Store
|
||||
|
||||
Once decided:
|
||||
|
||||
"**Module Type: {Standalone/Extension/Global}**"
|
||||
|
||||
**IF Extension:**
|
||||
"Base module to extend: {base-module-code}"
|
||||
"Folder name will be unique: {e.g., bmm-security}"
|
||||
|
||||
**Store this decision.** It affects:
|
||||
- Where files are created
|
||||
- What `code:` goes in module.yaml
|
||||
- Installation behavior
|
||||
|
||||
### 4. Preview Implications
|
||||
|
||||
Briefly explain what this means:
|
||||
- "As a {type}, your module will {implications}"
|
||||
- "When we build, files will go to {location}"
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
- User can change their mind before proceeding
|
||||
- ONLY proceed to next step when user selects 'C' and confirms the type
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}` for deeper exploration of the decision
|
||||
- IF P: Execute `{partyModeWorkflow}` for brainstorming the approach
|
||||
- IF C: Confirm the decision, then load `{nextStepFile}`
|
||||
- IF Any other: Help user, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Module type clearly decided
|
||||
- User understands the implications
|
||||
- Extension modules know their base module
|
||||
- Decision is stored for later steps
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding without clear module type
|
||||
- User doesn't understand the implications
|
||||
- Extension module without clear base
|
||||
|
||||
**Master Rule:** This is a gateway decision. Get clarity before moving forward.
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
---
|
||||
name: 'step-04-vision'
|
||||
description: 'Deep dive into the vision — what would make this module extraordinary?'
|
||||
|
||||
nextStepFile: './step-05-identity.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 4: Vision
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Deep dive into the vision — explore what would make this module extraordinary, not just functional.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — visioning, dreaming big
|
||||
- ✅ Push beyond "good enough" to "extraordinary"
|
||||
- 💬 Ask "what would make this amazing?"
|
||||
|
||||
### Step-Specific Rules:
|
||||
- 🎯 This is about the vision, not the details
|
||||
- 🚫 FORBIDDEN to jump to implementation
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Set the Visioning Tone
|
||||
|
||||
"**Let's dream big. What would make this module extraordinary?**"
|
||||
|
||||
"Good modules solve problems. Great modules inspire people. Let's make yours great."
|
||||
|
||||
### 2. Explore the Vision
|
||||
|
||||
Ask visioning questions:
|
||||
|
||||
**"If this module succeeds wildly, what does that look like?"**
|
||||
- How are people using it?
|
||||
- What are they able to do that they couldn't before?
|
||||
- What's the feeling when they use it?
|
||||
|
||||
**"What would make someone say 'I love this module'?"**
|
||||
- Delightful features?
|
||||
- Surprising capabilities?
|
||||
- The way it makes them feel?
|
||||
|
||||
**"What's the 'secret sauce' — the thing that makes this special?"**
|
||||
|
||||
### 3. Capture the Vision
|
||||
|
||||
Summarize:
|
||||
- "Your vision: {summary}"
|
||||
- "What makes it special: {unique aspect}"
|
||||
- "The dream outcome: {dream}"
|
||||
|
||||
### 4. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Vision feels inspiring and clear
|
||||
✅ "Extraordinary" elements identified
|
||||
✅ User excited about the possibility
|
||||
|
|
@ -0,0 +1,96 @@
|
|||
---
|
||||
name: 'step-05-identity'
|
||||
description: 'Module code, name, and personality/theme'
|
||||
|
||||
nextStepFile: './step-06-users.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Identity
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define the module's identity — code, name, and personality/theme.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — naming, branding, theming
|
||||
- ✅ This is where personality comes in
|
||||
- 💬 Have fun with this!
|
||||
|
||||
### Step-Specific Rules:
|
||||
- 🎯 Module code follows conventions (kebab-case, 2-20 chars)
|
||||
- 🚫 FORBIDDEN to use reserved codes or existing module codes (for standalone)
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Module Code
|
||||
|
||||
"**Let's give your module a code.**"
|
||||
|
||||
Explain:
|
||||
- kebab-case (e.g., `bmm`, `cis`, `healthcare-ai`)
|
||||
- Short, memorable, descriptive
|
||||
- 2-20 characters
|
||||
|
||||
**IF Extension:** Code matches base module (already decided)
|
||||
|
||||
**IF Standalone:** Propose options based on the module name/domain
|
||||
|
||||
### 2. Module Name
|
||||
|
||||
"**What's the display name?**"
|
||||
|
||||
This is the human-facing name in module.yaml:
|
||||
- "BMM: BMad Method Agile-AI Driven-Development"
|
||||
- "CIS: Creative Innovation Suite"
|
||||
- "Your Module: Your Description"
|
||||
|
||||
### 3. Personality Theme
|
||||
|
||||
"**Does your module have a personality or theme?**"
|
||||
|
||||
Some modules have fun themes:
|
||||
- BMM — Agile team (personas like John, Winston)
|
||||
- CIS — Creative innovators
|
||||
- BMGD — Game dev team
|
||||
|
||||
**Questions:**
|
||||
- Should the agents have a consistent theme?
|
||||
- Any personality vibes? (Corporate team, fantasy party, reality show cast?)
|
||||
- Or keep it professional/focused?
|
||||
|
||||
### 4. Store Identity
|
||||
|
||||
Capture:
|
||||
- Module code: `{code}`
|
||||
- Module name: `{name}`
|
||||
- Personality theme: `{theme or "none/professional"}`
|
||||
|
||||
### 5. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Module code decided and validated
|
||||
✅ Module name defined
|
||||
✅ Personality theme decided (even if "none")
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
---
|
||||
name: 'step-06-users'
|
||||
description: 'Who + How — personas AND user journey combined'
|
||||
|
||||
nextStepFile: './step-07-value.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 6: Users
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define who the module is for AND how they'll use it — personas and user journey combined.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — user-centric, empathetic
|
||||
- ✅ Help the user walk in their users' shoes
|
||||
- 💬 Tell the story of how this will be used
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Define the Users
|
||||
|
||||
"**Let's get specific about who this is for.**"
|
||||
|
||||
**Primary Users:**
|
||||
- Who will use this module most often?
|
||||
- What's their role? (developer, designer, analyst, etc.)
|
||||
- What's their skill level? (beginner, intermediate, expert)
|
||||
|
||||
**Secondary Users:**
|
||||
- Who else might use it?
|
||||
- How is their experience different?
|
||||
|
||||
### 2. Build User Personas
|
||||
|
||||
Create 1-2 brief personas:
|
||||
|
||||
**Persona 1:**
|
||||
- Name/role: {e.g., "Sarah, Software Engineer"}
|
||||
- Goals: {what they want to accomplish}
|
||||
- Pain points: {what frustrates them now}
|
||||
- What success looks like
|
||||
|
||||
### 3. Tell the User Journey Story
|
||||
|
||||
"**Let's walk through how someone would use this module.**"
|
||||
|
||||
Tell a story:
|
||||
1. User has a problem → {their situation}
|
||||
2. They load the module → {what they expect}
|
||||
3. They run an agent/workflow → {what happens}
|
||||
4. They get a result → {the outcome}
|
||||
5. This helps them → {the achievement}
|
||||
|
||||
"**Can you see this flow? Does it match what you envision?**"
|
||||
|
||||
### 4. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ User personas defined
|
||||
✅ User journey story told
|
||||
✅ User can visualize how their module will be used
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
---
|
||||
name: 'step-07-value'
|
||||
description: 'Unique Value Proposition — what makes this module special?'
|
||||
|
||||
nextStepFile: './step-08-agents.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 7: Value
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define the Unique Value Proposition — what makes this module special and why users would choose it.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — focused on differentiation
|
||||
- ✅ Help identify what makes this unique
|
||||
- 💬 Ask "why this and not something else?"
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Explore Differentiation
|
||||
|
||||
"**What makes your module special? Why would someone choose it?**"
|
||||
|
||||
Ask:
|
||||
- **What can users do with your module that they can't do otherwise?**
|
||||
- **What's the 'aha!' moment — when they realize this is exactly what they need?**
|
||||
- **What problem does this solve better than anything else?**
|
||||
|
||||
### 2. Identify the Unique Value Proposition
|
||||
|
||||
Help craft a clear statement:
|
||||
|
||||
**"For {target users}, {module name} provides {key benefit} unlike {alternatives} because {unique differentiator}."**
|
||||
|
||||
Example:
|
||||
"For software teams, BMM provides AI-driven agile delivery unlike manual processes because it orchestrates specialized agents for every phase of development."
|
||||
|
||||
### 3. Competitive Context
|
||||
|
||||
**"What else exists in this space? How is yours different?"**
|
||||
|
||||
- Similar modules?
|
||||
- Manual approaches?
|
||||
- Why is yours better?
|
||||
|
||||
### 4. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Unique value proposition articulated
|
||||
✅ Differentiation from alternatives clear
|
||||
✅ User can explain why someone would choose this module
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue