mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00:00
installer updates working with basic flow
This commit is contained in:
Brian Madison
@@ -17,15 +17,15 @@ subheader: "Configure the settings for the BoMB Factory!\nThe agent, workflow an
|
||||
|
||||
custom_agent_location:
|
||||
prompt: "Where do custom agents get created?"
|
||||
default: "{bmad_folder}/custom/src/agents"
|
||||
default: "bmad-custom-src/agents"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
custom_workflow_location:
|
||||
prompt: "Where do custom workflows get stored?"
|
||||
default: "{bmad_folder}/custom/src/workflows"
|
||||
default: "bmad-custom-src/workflows"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
custom_module_location:
|
||||
prompt: "Where do custom modules get stored?"
|
||||
default: "{bmad_folder}/custom/src/modules"
|
||||
default: "bmad-custom-src/modules"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
@@ -29,22 +29,25 @@ agent:
|
||||
- modules: "{project-root}/{bmad_folder}/bmb/docs/modules/kb.csv"
|
||||
|
||||
menu:
|
||||
- multi: "[CA] Create, [EA] Edit, or [VA] Validate BMAD agents with best practices"
|
||||
- multi: "[CA] Create, [EA] Edit, or [VA] Validate with Compliance CheckBMAD agents with best practices"
|
||||
triggers:
|
||||
- create-agent:
|
||||
- input: CA or fuzzy match create agent
|
||||
- route: "{project-root}/{bmad_folder}/bmb/workflows/create-agent/workflow.md"
|
||||
- data: null
|
||||
- type: exec
|
||||
- edit-agent:
|
||||
- input: EA or fuzzy match edit agent
|
||||
- route: "{project-root}/{bmad_folder}/bmb/workflows/edit-agent/workflow.md"
|
||||
- data: null
|
||||
- type: exec
|
||||
- run-agent-compliance-check:
|
||||
- input: VA or fuzzy match validate agent
|
||||
- route: "{project-root}/{bmad_folder}/bmb/workflows/agent-compliance-check/workflow.md"
|
||||
- data: null
|
||||
- type: exec
|
||||
|
||||
- multi: "[CW] Create, [EW] Edit, or [VW] Validate BMAD workflows with best practices"
|
||||
- multi: "[CW] Create, [EW] Edit, or [VW] Validate with Compliance CheckBMAD workflows with best practices"
|
||||
triggers:
|
||||
- create-workflow:
|
||||
- input: CW or fuzzy match create workflow
|
||||
@@ -62,10 +65,30 @@ agent:
|
||||
- data: null
|
||||
- type: exec
|
||||
|
||||
- trigger: create-module
|
||||
workflow: "{project-root}/{bmad_folder}/bmb/workflows/create-module/workflow.yaml"
|
||||
description: Create a complete BMAD compatible module (custom agents and workflows)
|
||||
|
||||
- trigger: edit-module
|
||||
workflow: "{project-root}/{bmad_folder}/bmb/workflows/edit-module/workflow.yaml"
|
||||
description: Edit existing modules (structure, agents, workflows, documentation)
|
||||
- multi: "[BM] Brainstorm, [PBM] Product Brief, [CM] Create, [EM] Edit or [VM] Validate with Compliance Check BMAD modules with best practices"
|
||||
triggers:
|
||||
- brainstorm-module:
|
||||
- input: BM or fuzzy match brainstorm module
|
||||
- route: "{project-root}/{bmad_folder}/bmb/workflows/brainstorm-module/workflow.md"
|
||||
- data: null
|
||||
- type: exec
|
||||
- product-brief-module:
|
||||
- input: PBM or fuzzy match product brief module
|
||||
- route: "{project-root}/{bmad_folder}/bmb/workflows/product-brief-module/workflow.md"
|
||||
- data: null
|
||||
- type: exec
|
||||
- create-module:
|
||||
- input: CM or fuzzy match create module
|
||||
- route: "{project-root}/{bmad_folder}/bmb/workflows/create-module/workflow.md"
|
||||
- data: null
|
||||
- type: exec
|
||||
- edit-module:
|
||||
- input: EM or fuzzy match edit module
|
||||
- route: "{project-root}/{bmad_folder}/bmb/workflows/edit-module/workflow.md"
|
||||
- data: null
|
||||
- type: exec
|
||||
- run-module-compliance-check:
|
||||
- input: VM or fuzzy match validate module
|
||||
- route: "{project-root}/{bmad_folder}/bmb/workflows/module-compliance-check/workflow.md"
|
||||
- data: null
|
||||
- type: exec
|
||||
|
||||
@@ -27,7 +27,7 @@ Compiles to:
|
||||
```yaml
|
||||
agent:
|
||||
metadata:
|
||||
id: '{bmad_folder}/{module-code}/agents/{agent-name}.md'
|
||||
id: '{*bmad_folder*}/{module-code}/agents/{agent-name}.md'
|
||||
name: 'Persona Name'
|
||||
title: 'Professional Title'
|
||||
icon: 'emoji'
|
||||
@@ -41,29 +41,29 @@ agent:
|
||||
|
||||
menu:
|
||||
- trigger: workflow-action
|
||||
workflow: '{project-root}/{bmad_folder}/{module-code}/workflows/{workflow-name}/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/{module-code}/workflows/{workflow-name}/workflow.yaml'
|
||||
description: 'Execute module workflow'
|
||||
|
||||
- trigger: another-workflow
|
||||
workflow: '{project-root}/{bmad_folder}/core/workflows/{workflow-name}/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/core/workflows/{workflow-name}/workflow.yaml'
|
||||
description: 'Execute core workflow'
|
||||
|
||||
- trigger: task-action
|
||||
exec: '{project-root}/{bmad_folder}/{module-code}/tasks/{task-name}.xml'
|
||||
exec: '{project-root}/{*bmad_folder*}/{module-code}/tasks/{task-name}.xml'
|
||||
description: 'Execute module task'
|
||||
|
||||
- trigger: cross-module
|
||||
workflow: '{project-root}/{bmad_folder}/other-module/workflows/{workflow-name}/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/other-module/workflows/{workflow-name}/workflow.yaml'
|
||||
description: 'Execute workflow from another module'
|
||||
|
||||
- trigger: with-template
|
||||
exec: '{project-root}/{bmad_folder}/core/tasks/create-doc.xml'
|
||||
tmpl: '{project-root}/{bmad_folder}/{module-code}/templates/{template-name}.md'
|
||||
exec: '{project-root}/{*bmad_folder*}/core/tasks/create-doc.xml'
|
||||
tmpl: '{project-root}/{*bmad_folder*}/{module-code}/templates/{template-name}.md'
|
||||
description: 'Create document from template'
|
||||
|
||||
- trigger: with-data
|
||||
exec: '{project-root}/{bmad_folder}/{module-code}/tasks/{task-name}.xml'
|
||||
data: '{project-root}/{bmad_folder}/_cfg/agent-manifest.csv'
|
||||
exec: '{project-root}/{*bmad_folder*}/{module-code}/tasks/{task-name}.xml'
|
||||
data: '{project-root}/{*bmad_folder*}/_cfg/agent-manifest.csv'
|
||||
description: 'Execute task with data file'
|
||||
```
|
||||
|
||||
@@ -71,7 +71,7 @@ agent:
|
||||
|
||||
### Metadata
|
||||
|
||||
- **id**: Path with `{bmad_folder}` variable (resolved at install time)
|
||||
- **id**: Path with `{*bmad_folder*}` variable (resolved at install time)
|
||||
- **name**: Agent persona name
|
||||
- **title**: Professional role
|
||||
- **icon**: Single emoji
|
||||
@@ -101,7 +101,7 @@ persona:
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: create-prd
|
||||
workflow: '{project-root}/{bmad_folder}/bmm/workflows/prd/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/bmm/workflows/prd/workflow.yaml'
|
||||
description: 'Create Product Requirements Document'
|
||||
```
|
||||
|
||||
@@ -112,7 +112,7 @@ Invokes BMAD workflow engine to execute multi-step processes.
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: validate
|
||||
exec: '{project-root}/{bmad_folder}/core/tasks/validate-workflow.xml'
|
||||
exec: '{project-root}/{*bmad_folder*}/core/tasks/validate-workflow.xml'
|
||||
description: 'Validate document structure'
|
||||
```
|
||||
|
||||
@@ -123,8 +123,8 @@ Executes single-operation tasks.
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: create-brief
|
||||
exec: '{project-root}/{bmad_folder}/core/tasks/create-doc.xml'
|
||||
tmpl: '{project-root}/{bmad_folder}/bmm/templates/brief.md'
|
||||
exec: '{project-root}/{*bmad_folder*}/core/tasks/create-doc.xml'
|
||||
tmpl: '{project-root}/{*bmad_folder*}/bmm/templates/brief.md'
|
||||
description: 'Create a Product Brief from template'
|
||||
```
|
||||
|
||||
@@ -135,8 +135,8 @@ Combines task execution with template file.
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: team-standup
|
||||
exec: '{project-root}/{bmad_folder}/bmm/tasks/standup.xml'
|
||||
data: '{project-root}/{bmad_folder}/_cfg/agent-manifest.csv'
|
||||
exec: '{project-root}/{*bmad_folder*}/bmm/tasks/standup.xml'
|
||||
data: '{project-root}/{*bmad_folder*}/_cfg/agent-manifest.csv'
|
||||
description: 'Run team standup with agent roster'
|
||||
```
|
||||
|
||||
@@ -160,12 +160,12 @@ Control visibility based on platform:
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: advanced-elicitation
|
||||
exec: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
exec: '{project-root}/{*bmad_folder*}/core/tasks/advanced-elicitation.xml'
|
||||
description: 'Advanced elicitation techniques'
|
||||
web-only: true # Only shows in web bundle
|
||||
|
||||
- trigger: git-operations
|
||||
exec: '{project-root}/{bmad_folder}/bmm/tasks/git-flow.xml'
|
||||
exec: '{project-root}/{*bmad_folder*}/bmm/tasks/git-flow.xml'
|
||||
description: 'Git workflow operations'
|
||||
ide-only: true # Only shows in IDE environments
|
||||
```
|
||||
@@ -175,7 +175,7 @@ menu:
|
||||
### Core Variables
|
||||
|
||||
- `{project-root}` - Root directory of installed project
|
||||
- `{bmad_folder}` - BMAD installation folder (usually `.bmad`)
|
||||
- `{*bmad_folder*}` - BMAD installation folder (usually `.bmad`)
|
||||
- `{user_name}` - User's name from module config
|
||||
- `{communication_language}` - Language preference
|
||||
- `{output_folder}` - Document output directory
|
||||
@@ -186,7 +186,7 @@ menu:
|
||||
|
||||
```yaml
|
||||
# GOOD
|
||||
workflow: "{project-root}/{bmad_folder}/bmm/workflows/prd/workflow.yaml"
|
||||
workflow: "{project-root}/{*bmad_folder*}/bmm/workflows/prd/workflow.yaml"
|
||||
|
||||
# BAD
|
||||
workflow: "/Users/john/project/.bmad/bmm/workflows/prd/workflow.yaml"
|
||||
@@ -208,7 +208,7 @@ Module agents use the same injection process as simple agents:
|
||||
**Key difference:** Module agents load **module-specific config** instead of core config:
|
||||
|
||||
```xml
|
||||
<step n="2">Load and read {project-root}/{bmad_folder}/{module}/config.yaml...</step>
|
||||
<step n="2">Load and read {project-root}/{*bmad_folder*}/{module}/config.yaml...</step>
|
||||
```
|
||||
|
||||
## Reference Examples
|
||||
@@ -252,15 +252,15 @@ Agents load this at activation for consistent behavior.
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: init
|
||||
workflow: '{project-root}/{bmad_folder}/bmm/workflows/workflow-init/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/bmm/workflows/workflow-init/workflow.yaml'
|
||||
description: 'Initialize workflow path (START HERE)'
|
||||
|
||||
- trigger: status
|
||||
workflow: '{project-root}/{bmad_folder}/bmm/workflows/workflow-status/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/bmm/workflows/workflow-status/workflow.yaml'
|
||||
description: 'Check current workflow status'
|
||||
|
||||
- trigger: next-step
|
||||
workflow: '{project-root}/{bmad_folder}/bmm/workflows/next-step/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/bmm/workflows/next-step/workflow.yaml'
|
||||
description: 'Execute next workflow in sequence'
|
||||
```
|
||||
|
||||
@@ -270,20 +270,20 @@ menu:
|
||||
menu:
|
||||
# Phase 1: Analysis
|
||||
- trigger: brainstorm
|
||||
workflow: '{project-root}/{bmad_folder}/bmm/workflows/1-analysis/brainstorm/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/bmm/workflows/1-analysis/brainstorm/workflow.yaml'
|
||||
description: 'Guided brainstorming session'
|
||||
|
||||
- trigger: research
|
||||
workflow: '{project-root}/{bmad_folder}/bmm/workflows/1-analysis/research/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/bmm/workflows/1-analysis/research/workflow.yaml'
|
||||
description: 'Market and technical research'
|
||||
|
||||
# Phase 2: Planning
|
||||
- trigger: prd
|
||||
workflow: '{project-root}/{bmad_folder}/bmm/workflows/2-planning/prd/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/bmm/workflows/2-planning/prd/workflow.yaml'
|
||||
description: 'Create PRD'
|
||||
|
||||
- trigger: architecture
|
||||
workflow: '{project-root}/{bmad_folder}/bmm/workflows/2-planning/architecture/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/bmm/workflows/2-planning/architecture/workflow.yaml'
|
||||
description: 'Design architecture'
|
||||
```
|
||||
|
||||
@@ -292,17 +292,17 @@ menu:
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: party-mode
|
||||
workflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/core/workflows/party-mode/workflow.yaml'
|
||||
description: 'Bring all agents together'
|
||||
|
||||
- trigger: brainstorm
|
||||
workflow: '{project-root}/{bmad_folder}/cis/workflows/brainstorming/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/cis/workflows/brainstorming/workflow.yaml'
|
||||
description: 'Use CIS brainstorming techniques'
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Use {bmad_folder} paths** - Portable across installations
|
||||
1. **Use {_bmad_folder_} paths** - Portable across installations
|
||||
2. **Organize workflows by phase** - Clear progression for users
|
||||
3. **Include workflow-status** - Help users track progress
|
||||
4. **Reference module config** - Consistent behavior
|
||||
@@ -318,7 +318,7 @@ menu:
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: start
|
||||
workflow: '{project-root}/{bmad_folder}/{module}/workflows/init/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/{module}/workflows/init/workflow.yaml'
|
||||
description: 'Start new project (BEGIN HERE)'
|
||||
```
|
||||
|
||||
@@ -327,7 +327,7 @@ menu:
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: status
|
||||
workflow: '{project-root}/{bmad_folder}/{module}/workflows/status/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/{module}/workflows/status/workflow.yaml'
|
||||
description: 'Check workflow progress'
|
||||
```
|
||||
|
||||
@@ -336,27 +336,27 @@ menu:
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: party
|
||||
workflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.yaml'
|
||||
workflow: '{project-root}/{*bmad_folder*}/core/workflows/party-mode/workflow.yaml'
|
||||
description: 'Multi-agent discussion'
|
||||
```
|
||||
|
||||
## Module Agent vs Simple/Expert
|
||||
|
||||
| Aspect | Module Agent | Simple/Expert Agent |
|
||||
| ------------- | -------------------------------- | ------------------------------- |
|
||||
| Location | `{bmad_folder}/{module}/agents/` | `{bmad_folder}/custom/agents/` |
|
||||
| Persona | Fixed, professional | Customizable via install_config |
|
||||
| Handlebars | No templating | Yes, extensive |
|
||||
| Menu actions | Workflows, tasks, templates | Prompts, inline actions |
|
||||
| Configuration | Module config.yaml | Core config or none |
|
||||
| Purpose | Professional tooling | Personal utilities |
|
||||
| Aspect | Module Agent | Simple/Expert Agent |
|
||||
| ------------- | ---------------------------------- | -------------------------------- |
|
||||
| Location | `{*bmad_folder*}/{module}/agents/` | `{*bmad_folder*}/custom/agents/` |
|
||||
| Persona | Fixed, professional | Customizable via install_config |
|
||||
| Handlebars | No templating | Yes, extensive |
|
||||
| Menu actions | Workflows, tasks, templates | Prompts, inline actions |
|
||||
| Configuration | Module config.yaml | Core config or none |
|
||||
| Purpose | Professional tooling | Personal utilities |
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- [ ] Valid YAML syntax
|
||||
- [ ] Metadata includes `module: "{module-code}"`
|
||||
- [ ] id uses `{bmad_folder}/{module}/agents/{name}.md`
|
||||
- [ ] All workflow paths use `{project-root}/{bmad_folder}/` prefix
|
||||
- [ ] id uses `{*bmad_folder*}/{module}/agents/{name}.md`
|
||||
- [ ] All workflow paths use `{project-root}/{*bmad_folder*}/` prefix
|
||||
- [ ] No hardcoded paths
|
||||
- [ ] No duplicate triggers
|
||||
- [ ] Each menu item has description
|
||||
|
||||
@@ -133,7 +133,7 @@ agent:
|
||||
|
||||
- trigger: gratitude
|
||||
action: "#gratitude-moment"
|
||||
description: "Capture today's gratitudes"
|
||||
description: "Capture today's gratitude"
|
||||
|
||||
- trigger: weekly
|
||||
action: "#weekly-reflection"
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: "{bmad_folder}/bmm/agents/security-engineer.md"
|
||||
id: "{*bmad_folder*}/bmm/agents/security-engineer.md"
|
||||
name: "Sam"
|
||||
title: "Security Engineer"
|
||||
icon: "🔐"
|
||||
@@ -32,22 +32,22 @@ agent:
|
||||
menu:
|
||||
# NOTE: These workflows are hypothetical examples assuming add to a module called bmm - not implemented
|
||||
- trigger: threat-model
|
||||
workflow: "{project-root}/{bmad_folder}/bmm/workflows/threat-model/workflow.yaml"
|
||||
exec: "{project-root}/{*bmad_folder*}/bmm/workflows/threat-model/workflow.md"
|
||||
description: "Create STRIDE threat model for architecture"
|
||||
|
||||
- trigger: security-review
|
||||
workflow: "{project-root}/{bmad_folder}/bmm/workflows/security-review/workflow.yaml"
|
||||
exec: "{project-root}/{*bmad_folder*}/bmm/workflows/security-review/workflow.md"
|
||||
description: "Review code/design for security issues"
|
||||
|
||||
- trigger: owasp-check
|
||||
exec: "{project-root}/{bmad_folder}/bmm/tasks/owasp-top-10.xml"
|
||||
TODO: true
|
||||
description: "Check against OWASP Top 10"
|
||||
|
||||
- trigger: compliance
|
||||
workflow: "{project-root}/{bmad_folder}/bmm/workflows/compliance-check/workflow.yaml"
|
||||
exec: "{project-root}/{*bmad_folder*}/bmm/workflows/compliance-check/workflow.md"
|
||||
description: "Verify compliance requirements (SOC2, GDPR, etc.)"
|
||||
|
||||
# Core workflow that exists
|
||||
- trigger: party-mode
|
||||
exec: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md"
|
||||
exec: "{project-root}/{*bmad_folder*}/core/workflows/party-mode/workflow.md"
|
||||
description: "Multi-agent security discussion"
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: "{bmad_folder}/cis/agents/trend-analyst.md"
|
||||
id: "{*bmad_folder*}/cis/agents/trend-analyst.md"
|
||||
name: "Nova"
|
||||
title: "Trend Analyst"
|
||||
icon: "📈"
|
||||
@@ -32,26 +32,26 @@ agent:
|
||||
menu:
|
||||
# NOTE: These workflows are hypothetical examples - not implemented
|
||||
- trigger: scan-trends
|
||||
workflow: "{project-root}/{bmad_folder}/cis/workflows/trend-scan/workflow.yaml"
|
||||
exec: "{project-root}/{*bmad_folder*}/cis/workflows/trend-scan/workflow.md"
|
||||
description: "Scan for emerging trends in a domain"
|
||||
|
||||
- trigger: analyze-trend
|
||||
workflow: "{project-root}/{bmad_folder}/cis/workflows/trend-analysis/workflow.yaml"
|
||||
exec: "{project-root}/{*bmad_folder*}/cis/workflows/trend-analysis/workflow.md"
|
||||
description: "Deep dive on a specific trend"
|
||||
|
||||
- trigger: opportunity-map
|
||||
workflow: "{project-root}/{bmad_folder}/cis/workflows/opportunity-mapping/workflow.yaml"
|
||||
exec: "{project-root}/{*bmad_folder*}/cis/workflows/opportunity-mapping/workflow.md"
|
||||
description: "Map trend to strategic opportunities"
|
||||
|
||||
- trigger: competitor-trends
|
||||
exec: "{project-root}/{bmad_folder}/cis/tasks/competitor-trend-watch.xml"
|
||||
exec: "{project-root}/{*bmad_folder*}/cis/tasks/competitor-trend-watch.xml"
|
||||
description: "Monitor competitor trend adoption"
|
||||
|
||||
# Core workflows that exist
|
||||
- trigger: brainstorm
|
||||
workflow: "{project-root}/{bmad_folder}/core/workflows/brainstorming/workflow.yaml"
|
||||
exec: "{project-root}/{*bmad_folder*}/core/workflows/brainstorming/workflow.md"
|
||||
description: "Brainstorm trend implications"
|
||||
|
||||
- trigger: party-mode
|
||||
exec: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md"
|
||||
exec: "{project-root}/{*bmad_folder*}/core/workflows/party-mode/workflow.md"
|
||||
description: "Discuss trends with other agents"
|
||||
|
||||
@@ -1,235 +0,0 @@
|
||||
# Build Module Validation Checklist
|
||||
|
||||
## Module Identity and Metadata
|
||||
|
||||
### Basic Information
|
||||
|
||||
- [ ] Module code follows kebab-case convention (e.g., "rpg-toolkit")
|
||||
- [ ] Module name is descriptive and title-cased
|
||||
- [ ] Module purpose is clearly defined (1-2 sentences)
|
||||
- [ ] Target audience is identified
|
||||
- [ ] Version number follows semantic versioning (e.g., "1.0.0")
|
||||
- [ ] Author information is present
|
||||
|
||||
### Naming Consistency
|
||||
|
||||
- [ ] Module code used consistently throughout all files
|
||||
- [ ] No naming conflicts with existing modules
|
||||
- [ ] All paths use consistent module code references
|
||||
|
||||
## Directory Structure
|
||||
|
||||
### Source Directories ({bmad_folder}/{module-code}/)
|
||||
|
||||
- [ ] `/agents` directory created (even if empty)
|
||||
- [ ] `/workflows` directory created (even if empty)
|
||||
- [ ] `/tasks` directory exists (if tasks planned)
|
||||
- [ ] `/templates` directory exists (if templates used)
|
||||
- [ ] `/data` directory exists (if data files needed)
|
||||
- [ ] `/_module-installer/install-config.yaml` present (defines configuration questions)
|
||||
- [ ] `README.md` present with documentation
|
||||
|
||||
### Installed Module Structure (generated in target after installation)
|
||||
|
||||
- [ ] `/agents` directory for compiled agents
|
||||
- [ ] `/workflows` directory for workflow instances
|
||||
- [ ] `/data` directory for user data
|
||||
- [ ] `config.yaml` generated from install-config.yaml during installation
|
||||
|
||||
## Component Planning
|
||||
|
||||
### Agents
|
||||
|
||||
- [ ] At least one agent defined or planned
|
||||
- [ ] Agent purposes are distinct and clear
|
||||
- [ ] Agent types (Simple/Expert/Module) identified
|
||||
- [ ] No significant overlap between agents
|
||||
- [ ] Primary agent is identified
|
||||
|
||||
### Workflows
|
||||
|
||||
- [ ] At least one workflow defined or planned
|
||||
- [ ] Workflow purposes are clear
|
||||
- [ ] Workflow types identified (Document/Action/Interactive)
|
||||
- [ ] Primary workflow is identified
|
||||
- [ ] Workflow complexity is appropriate
|
||||
|
||||
### Tasks (if applicable)
|
||||
|
||||
- [ ] Tasks have single, clear purposes
|
||||
- [ ] Tasks don't duplicate workflow functionality
|
||||
- [ ] Task files follow naming conventions
|
||||
|
||||
## Configuration Files
|
||||
|
||||
### Installation Configuration (install-config.yaml)
|
||||
|
||||
- [ ] `install-config.yaml` exists in `_module-installer`
|
||||
- [ ] Module metadata present (code, name, version)
|
||||
- [ ] Configuration questions defined for user input
|
||||
- [ ] Default values provided for all questions
|
||||
- [ ] Prompt text is clear and helpful
|
||||
- [ ] Result templates use proper variable substitution
|
||||
- [ ] Paths use proper variables ({project-root}, {value}, etc.)
|
||||
|
||||
### Generated Config (config.yaml in target)
|
||||
|
||||
- [ ] Generated during installation from install-config.yaml
|
||||
- [ ] Contains all user-provided configuration values
|
||||
- [ ] Module metadata included
|
||||
- [ ] No config.yaml should exist in source module
|
||||
|
||||
## Installation Infrastructure
|
||||
|
||||
### Installer Files
|
||||
|
||||
- [ ] Install configuration validates against schema
|
||||
- [ ] All source paths exist or are marked as templates
|
||||
- [ ] Destination paths use correct variables
|
||||
- [ ] Optional vs required steps clearly marked
|
||||
|
||||
### installer.js (if present)
|
||||
|
||||
- [ ] Main `installModule` function exists
|
||||
- [ ] Error handling implemented
|
||||
- [ ] Console logging for user feedback
|
||||
- [ ] Exports correct function names
|
||||
- [ ] Placeholder code replaced with actual logic (or logged as TODO)
|
||||
|
||||
### External Assets (if any)
|
||||
|
||||
- [ ] Asset files exist in assets directory
|
||||
- [ ] Copy destinations are valid
|
||||
- [ ] Permissions requirements documented
|
||||
|
||||
## Documentation
|
||||
|
||||
### README.md
|
||||
|
||||
- [ ] Module overview section present
|
||||
- [ ] Installation instructions included
|
||||
- [ ] Component listing with descriptions
|
||||
- [ ] Quick start guide provided
|
||||
- [ ] Configuration options documented
|
||||
- [ ] At least one usage example
|
||||
- [ ] Directory structure shown
|
||||
- [ ] Author and date information
|
||||
|
||||
### Component Documentation
|
||||
|
||||
- [ ] Each agent has purpose documentation
|
||||
- [ ] Each workflow has description
|
||||
- [ ] Tasks are documented (if present)
|
||||
- [ ] Examples demonstrate typical usage
|
||||
|
||||
### Development Roadmap
|
||||
|
||||
- [ ] TODO.md or roadmap section exists
|
||||
- [ ] Planned components listed
|
||||
- [ ] Development phases identified
|
||||
- [ ] Quick commands for adding components
|
||||
|
||||
## Integration
|
||||
|
||||
### Cross-component References
|
||||
|
||||
- [ ] Agents reference correct workflow paths
|
||||
- [ ] Workflows reference correct task paths
|
||||
- [ ] All internal paths use module variables
|
||||
- [ ] External dependencies declared
|
||||
|
||||
### Module Boundaries
|
||||
|
||||
- [ ] Module scope is well-defined
|
||||
- [ ] No feature creep into other domains
|
||||
- [ ] Clear separation from other modules
|
||||
|
||||
## Quality Checks
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] At least one functional component (not all placeholders)
|
||||
- [ ] Core functionality is implementable
|
||||
- [ ] Module provides clear value
|
||||
|
||||
### Consistency
|
||||
|
||||
- [ ] Formatting consistent across files
|
||||
- [ ] Variable naming follows conventions
|
||||
- [ ] Communication style appropriate for domain
|
||||
|
||||
### Scalability
|
||||
|
||||
- [ ] Structure supports future growth
|
||||
- [ ] Component organization is logical
|
||||
- [ ] No hard-coded limits
|
||||
|
||||
## Testing and Validation
|
||||
|
||||
### Structural Validation
|
||||
|
||||
- [ ] YAML files parse without errors
|
||||
- [ ] JSON files (if any) are valid
|
||||
- [ ] XML files (if any) are well-formed
|
||||
- [ ] No syntax errors in JavaScript files
|
||||
|
||||
### Path Validation
|
||||
|
||||
- [ ] All referenced paths exist or are clearly marked as TODO
|
||||
- [ ] Variable substitutions are correct
|
||||
- [ ] No absolute paths (unless intentional)
|
||||
|
||||
### Installation Testing
|
||||
|
||||
- [ ] Installation steps can be simulated
|
||||
- [ ] No circular dependencies
|
||||
- [ ] Uninstall process defined (if complex)
|
||||
|
||||
## Final Checks
|
||||
|
||||
### Ready for Use
|
||||
|
||||
- [ ] Module can be installed without errors
|
||||
- [ ] At least one component is functional
|
||||
- [ ] User can understand how to get started
|
||||
- [ ] Next steps are clear
|
||||
|
||||
### Professional Quality
|
||||
|
||||
- [ ] No placeholder text remains (unless marked TODO)
|
||||
- [ ] No obvious typos or grammar issues
|
||||
- [ ] Professional tone throughout
|
||||
- [ ] Contact/support information provided
|
||||
|
||||
## Issues Found
|
||||
|
||||
### Critical Issues
|
||||
|
||||
<!-- List any issues that MUST be fixed before module can be used -->
|
||||
|
||||
### Warnings
|
||||
|
||||
<!-- List any issues that should be addressed but won't prevent basic usage -->
|
||||
|
||||
### Improvements
|
||||
|
||||
<!-- List any optional enhancements that would improve the module -->
|
||||
|
||||
### Missing Components
|
||||
|
||||
<!-- List any planned components not yet implemented -->
|
||||
|
||||
## Module Complexity Assessment
|
||||
|
||||
### Complexity Rating
|
||||
|
||||
- [ ] Simple (1-2 agents, 2-3 workflows)
|
||||
- [ ] Standard (3-5 agents, 5-10 workflows)
|
||||
- [ ] Complex (5+ agents, 10+ workflows)
|
||||
|
||||
### Readiness Level
|
||||
|
||||
- [ ] Prototype (Basic structure, mostly placeholders)
|
||||
- [ ] Alpha (Core functionality works)
|
||||
- [ ] Beta (Most features complete, needs testing)
|
||||
- [ ] Release (Full functionality, documented)
|
||||
@@ -145,8 +145,8 @@ For modules that need workflows from other modules but want to remain standalone
|
||||
```yaml
|
||||
menu:
|
||||
- trigger: command-name
|
||||
workflow: '{project-root}/{bmad_folder}/SOURCE_MODULE/workflows/path/workflow.yaml'
|
||||
workflow-install: '{project-root}/{bmad_folder}/THIS_MODULE/workflows/vendored/workflow.yaml'
|
||||
exec: '{project-root}/{bmad_folder}/SOURCE_MODULE/workflows/path/workflow.md'
|
||||
workflow-install: '{project-root}/{bmad_folder}/THIS_MODULE/workflows/vendored/workflow.md'
|
||||
description: 'Command description'
|
||||
```
|
||||
|
||||
|
||||
155
src/modules/bmb/workflows/create-module/steps/step-01-init.md
Normal file
155
src/modules/bmb/workflows/create-module/steps/step-01-init.md
Normal file
@@ -0,0 +1,155 @@
|
||||
---
|
||||
nextStepFile: '{installed_path}/steps/step-02-concept.md'
|
||||
continueFile: '{installed_path}/steps/step-01b-continue.md'
|
||||
modulePlanTemplate: '{installed_path}/templates/module-plan.template.md'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
customModuleLocation: '{custom_module_location}'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
---
|
||||
|
||||
# Step 1: Workflow Initialization
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To initialize the create-module workflow by getting the module name from the user, checking for existing work, handling continuation if needed, and creating the initial module plan document.
|
||||
|
||||
## 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 Module Architect and BMAD Systems Specialist
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in BMAD architecture and module creation, user brings their module requirements
|
||||
- ✅ Maintain collaborative, guiding tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on initialization, getting module name, and setting up tracking
|
||||
- 🚫 FORBIDDEN to look ahead to future steps
|
||||
- 💬 Handle initialization professionally
|
||||
- 🚪 DETECT existing workflow state and handle continuation properly
|
||||
|
||||
## 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 setup 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
|
||||
- Module brief discovery happens in this step
|
||||
|
||||
## SEQUENCE OF INSTRUCTIONS:
|
||||
|
||||
### 1. Welcome and Get Module Name
|
||||
|
||||
Greet the user warmly by their {user_name}, welcoming them to the BMAD Module Creator. Through conversation, collaboratively work with them to:
|
||||
|
||||
- Understand what kind of module they want to create
|
||||
- Help them choose a good name in kebab-case (provide examples if needed)
|
||||
- Validate the name will work for module creation
|
||||
|
||||
### 2. Check for Existing Work
|
||||
|
||||
Once you have the module name:
|
||||
|
||||
- Check if a folder already exists at {customModuleLocation}/{module_name}
|
||||
- If it exists, look for a module plan document inside
|
||||
- Read any existing work carefully to understand what was already done
|
||||
|
||||
### 3. Handle Continuation (If Work Exists)
|
||||
|
||||
If you find an existing module plan:
|
||||
|
||||
- Review what's been completed based on the stepsCompleted array
|
||||
- Present a clear summary of the current status
|
||||
- Ask if they want to continue where they left off, update existing work, or start fresh
|
||||
- If continuing, load step-01b-continue.md
|
||||
|
||||
### 4. Look for Supporting Documents
|
||||
|
||||
Check for any existing documents that could help:
|
||||
|
||||
- Module briefs in the module folder or output folder
|
||||
- Brainstorming results in the output folder
|
||||
- Any other relevant documentation
|
||||
|
||||
### 5. Guide User's Next Decision
|
||||
|
||||
If no supporting documents are found:
|
||||
|
||||
- Explain their three options clearly and helpfully
|
||||
- Option 1: Proceed with creating the module based on their ideas
|
||||
- Option 2: Exit and create a module brief first (explain the module-brief workflow)
|
||||
- Option 3: Exit and do brainstorming first (explain the brainstorming workflow)
|
||||
- Support whatever choice they make
|
||||
|
||||
### 6. Create Module Foundation
|
||||
|
||||
If proceeding:
|
||||
|
||||
- Create the module folder if needed
|
||||
- Create the initial module-plan-{module_name}.md document using the module plan template from {modulePlanTemplate}
|
||||
- Initialize proper frontmatter with current date, user name, and add "step-01-init" to stepsCompleted array
|
||||
- Add any discovered documents to inputDocuments field
|
||||
- Include a brief section about the legacy reference
|
||||
|
||||
### 7. Prepare for Next Step
|
||||
|
||||
- Confirm everything is set up properly
|
||||
- Let the user know what you've accomplished
|
||||
- Transition smoothly to the next phase of defining the module concept
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: **Proceeding to define your module concept...**
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- This is an initialization step with no user choices (after inputs handled)
|
||||
- Proceed directly to next step after setup
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- After setup completion, add step-01-init to the end of the stepsCompleted array in module plan frontmatter, then load, read entire file, then execute `{nextStepFile}` to define the module concept
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Module name obtained and validated through collaborative dialogue
|
||||
- Module plan document created from template with frontmatter initialized
|
||||
- "step-01-init" added to stepsCompleted array
|
||||
- Module plan document created at correct location
|
||||
- User feels welcomed and informed
|
||||
- Ready to proceed to step 2
|
||||
- OR existing workflow properly routed to step-01b-continue.md
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding with step 2 without module plan creation
|
||||
- Not checking for existing documents properly
|
||||
- Creating module without user input on name
|
||||
- Skipping folder creation
|
||||
- Not routing to step-01b-continue.md when appropriate
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN initialization setup is complete and module plan document is created (OR continuation is properly routed), will you then immediately load, read entire file, then execute `{nextStepFile}` to begin defining the module concept.
|
||||
@@ -0,0 +1,169 @@
|
||||
---
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
---
|
||||
|
||||
# Step 1b: Continue Module Creation
|
||||
|
||||
## 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 Module Architect and BMAD Systems Specialist
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in BMAD architecture and module creation, user brings their module requirements
|
||||
- ✅ Maintain collaborative, guiding tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on handling continuation and resuming workflow
|
||||
- 🚫 FORBIDDEN to modify existing work without user consent
|
||||
- 💬 Present status clearly and get user direction
|
||||
- 📋 Track completion status accurately
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load and analyze existing module plan
|
||||
- 💾 Update frontmatter with continuation status
|
||||
- 📖 Route to appropriate next step based on progress
|
||||
- 🚫 FORBIDDEN to skip steps just because they exist
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Module plan document exists with previous work
|
||||
- Focus on understanding what's been done and what remains
|
||||
- Don't assume completion without verification
|
||||
- User direction guides next actions
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To resume module creation by presenting current status, understanding what's been accomplished, and determining the next step in the process.
|
||||
|
||||
## CONTINUATION HANDLING SEQUENCE:
|
||||
|
||||
### 1. Load and Analyze Existing Module Plan
|
||||
|
||||
Load module plan from: {modulePlanFile}
|
||||
Read entire document including frontmatter
|
||||
Extract current status from frontmatter fields:
|
||||
|
||||
- stepsCompleted array
|
||||
- lastStep (the final item in the stepsCompleted array)
|
||||
- module_name
|
||||
- module_code
|
||||
- date
|
||||
- inputDocuments
|
||||
|
||||
### 2. Present Current Status
|
||||
|
||||
"Welcome back! I found your in-progress module creation for **{module_name}**.
|
||||
|
||||
**Current Status:**
|
||||
|
||||
- **Module Code:** {module_code}
|
||||
- **Started:** {date}
|
||||
- **Last Step:** {lastStep}
|
||||
- **Steps Completed:** {stepsCompleted count}/{total steps}
|
||||
- **Location:** {custom_module_location}/{module_name}
|
||||
|
||||
\*\*Progress Summary:"
|
||||
|
||||
Based on stepsCompleted, show:
|
||||
|
||||
- [✅] Step 1: Init - Complete
|
||||
- [ ] Step 2: Concept - {status}
|
||||
- [ ] Step 3: Components - {status}
|
||||
- [ ] Step 4: Structure - {status}
|
||||
- [ ] Step 5: Configuration - {status}
|
||||
- [ ] Step 6: Agents - {status}
|
||||
- [ ] Step 7: Workflows - {status}
|
||||
- [ ] Step 8: Installer - {status}
|
||||
- [ ] Step 9: Documentation - {status}
|
||||
- [ ] Step 10: Roadmap - {status}
|
||||
- [ ] Step 11: Validation - {status}
|
||||
|
||||
### 3. Review What's Been Done
|
||||
|
||||
Read content sections of module plan
|
||||
Summarize what's been accomplished:
|
||||
|
||||
"**Completed Work:**
|
||||
|
||||
- Module identity defined
|
||||
- Component planning complete
|
||||
- [Other completed items based on content]"
|
||||
|
||||
### 4. Determine Next Step
|
||||
|
||||
Based on stepsCompleted array:
|
||||
Find highest completed step number
|
||||
Next step = highest completed + 1
|
||||
|
||||
"**Ready to Continue:**
|
||||
Your next step would be: **Step {nextStep} - [step name]**
|
||||
|
||||
What would you like to do?
|
||||
|
||||
1. **Continue** from where you left off
|
||||
2. **Review** what's been done so far
|
||||
3. **Modify** previous work
|
||||
4. **Start over** with a new plan"
|
||||
|
||||
### 5. Handle User Choice
|
||||
|
||||
User your best judgement in how to handle the users choice
|
||||
|
||||
### 6. Update Continuation Status
|
||||
|
||||
Update modulePlanFile frontmatter:
|
||||
|
||||
- Set lastStep: 'continued'
|
||||
- Add note about continuation date
|
||||
- Keep stepsCompleted unchanged
|
||||
|
||||
## ✅ SUCCESS METRICS:
|
||||
|
||||
- User understands current progress
|
||||
- Next step identified correctly
|
||||
- User choice handled appropriately
|
||||
- Module plan updated with continuation status
|
||||
- Workflow resumed at correct location
|
||||
|
||||
## ❌ FAILURE MODES TO AVOID:
|
||||
|
||||
- Not accurately reading previous status
|
||||
- Skipping steps just because they exist
|
||||
- Not offering review option
|
||||
- Losing previous work
|
||||
- Not updating continuation tracking
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Existing work properly loaded and analyzed
|
||||
- User clearly understands current status
|
||||
- Continuation options presented clearly
|
||||
- Next step determined correctly
|
||||
- Module plan updated with continuation information
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not reading existing plan completely
|
||||
- Misrepresenting progress status
|
||||
- Losing track of what's been done
|
||||
- Not offering appropriate continuation options
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN user selects 'C' (Continue) and appropriate updates are saved to modulePlanFile, will you then load, read entire file, then execute the determined next step file to resume the module creation workflow.
|
||||
217
src/modules/bmb/workflows/create-module/steps/step-02-concept.md
Normal file
217
src/modules/bmb/workflows/create-module/steps/step-02-concept.md
Normal file
@@ -0,0 +1,217 @@
|
||||
---
|
||||
installed_path: '{project-root}/{bmad_folder}/bmb/workflows/create-module'
|
||||
nextStepFile: '{installed_path}/steps/step-03-components.md'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
moduleStructureGuide: '{project-root}/src/modules/bmb/workflows-legacy/create-module/module-structure.md'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 2: Define Module Concept and Scope
|
||||
|
||||
## 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 Module Architect and Business Analyst
|
||||
- ✅ 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 module design and BMAD patterns, user brings their domain knowledge
|
||||
- ✅ Maintain collaborative, educational tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on defining the module concept and scope
|
||||
- 🚫 FORBIDDEN to start designing components in this step
|
||||
- 💬 Ask questions conversationally to understand vision
|
||||
- 🚫 FORBIDDEN to proceed without clear module identity
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load and study module structure guide for context
|
||||
- 💾 Document all module identity details in plan
|
||||
- 📖 Add "step-02-concept" to stepsCompleted array` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Module name and location from step 1
|
||||
- Input documents (brief/brainstorming) if any
|
||||
- Focus ONLY on concept and scope definition
|
||||
- Don't assume module details beyond what user provides
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To articulate the module's vision, define its identity, and establish clear boundaries for what it will and won't do.
|
||||
|
||||
## MODULE CONCEPT DEFINITION PROCESS:
|
||||
|
||||
### 1. Load Context and Briefs
|
||||
|
||||
"Let's define your module's concept and identity. This will guide all the decisions we make about agents, workflows, and features."
|
||||
|
||||
Load module-plan.md and check inputDocuments field
|
||||
|
||||
Read the module brief completely
|
||||
"I see you have a module brief. Let me review that to understand your vision..."
|
||||
Use brief content to inform concept development questions
|
||||
|
||||
Load and study the module structure guide for context
|
||||
|
||||
### 2. Guide Concept Development
|
||||
|
||||
Ask conversationally:
|
||||
|
||||
"**Understanding Your Vision:**
|
||||
|
||||
1. **What problem will this module solve?** - What pain point or need are you addressing?
|
||||
|
||||
2. **Who is the primary user?** - Who will benefit most from this module?
|
||||
|
||||
3. **What's the main outcome?** - What will users be able to do after using your module?
|
||||
|
||||
4. **Why is this important?** - What makes this module valuable or unique?"
|
||||
|
||||
### 3. Module Identity Development
|
||||
|
||||
Based on their responses, collaboratively develop:
|
||||
|
||||
**Module Name:**
|
||||
|
||||
- Start with their module code: {module_name}
|
||||
- Suggest a display name in Title Case
|
||||
- Get user confirmation or refinement
|
||||
|
||||
**Module Purpose:**
|
||||
|
||||
- Distill their problem statement into 1-2 clear sentences
|
||||
- Focus on value and outcomes
|
||||
- Get user validation
|
||||
|
||||
**Target Audience:**
|
||||
|
||||
- Identify primary user persona
|
||||
- Consider skill level (beginner/intermediate/advanced)
|
||||
- Note any secondary audiences
|
||||
|
||||
**Module Scope:**
|
||||
|
||||
- What's IN scope (core features)
|
||||
- What's OUT of scope (explicitly state what it won't do)
|
||||
- Success criteria (how will we know it works?)
|
||||
|
||||
### 4. Module Theme and Category
|
||||
|
||||
"**Module Classification:**
|
||||
|
||||
Based on your description, this seems to fit in the [Domain-Specific/Creative/Technical/Business/Personal] category.
|
||||
|
||||
Does this sound right? Or would you categorize it differently?
|
||||
|
||||
**Example Categories:**
|
||||
|
||||
- **Domain-Specific**: Legal, Medical, Finance, Education
|
||||
- **Creative**: RPG/Gaming, Story Writing, Music Production
|
||||
- **Technical**: DevOps, Testing, Architecture, Security
|
||||
- **Business**: Project Management, Marketing, Sales
|
||||
- **Personal**: Journaling, Learning, Productivity"
|
||||
|
||||
### 5. Module Type Estimation
|
||||
|
||||
"Based on what you've described, I'm thinking this might be a:
|
||||
|
||||
- **Simple Module** (1-2 agents, 2-3 workflows) - Focused, single-purpose
|
||||
- **Standard Module** (3-5 agents, 5-10 workflows) - Comprehensive solution
|
||||
- **Complex Module** (5+ agents, 10+ workflows) - Full platform/framework
|
||||
|
||||
Which feels right for your vision? We'll confirm this after planning components."
|
||||
|
||||
### 6. Document Module Concept
|
||||
|
||||
Update module-plan.md with concept section:
|
||||
|
||||
```markdown
|
||||
## Module Concept
|
||||
|
||||
**Module Name:** {module_display_name}
|
||||
**Module Code:** {module_name}
|
||||
**Category:** [category]
|
||||
**Type:** [estimated type]
|
||||
|
||||
**Purpose Statement:**
|
||||
[1-2 sentence clear purpose]
|
||||
|
||||
**Target Audience:**
|
||||
|
||||
- Primary: [description]
|
||||
- Secondary: [if any]
|
||||
|
||||
**Scope Definition:**
|
||||
|
||||
**In Scope:**
|
||||
|
||||
- [core feature 1]
|
||||
- [core feature 2]
|
||||
- [core feature 3]
|
||||
|
||||
**Out of Scope:**
|
||||
|
||||
- [explicitly excluded item 1]
|
||||
- [explicitly excluded item 2]
|
||||
|
||||
**Success Criteria:**
|
||||
|
||||
- [measurable outcome 1]
|
||||
- [measurable outcome 2]
|
||||
- [user satisfaction indicator]
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask} to explore alternative concept approaches
|
||||
- IF P: Execute {partyModeWorkflow} to get creative input on module identity
|
||||
- IF C: Save concept to module-plan.md, add step-02-concept to the end of the stepsCompleted array in frontmatter, then load nextStepFile
|
||||
- IF Any other comments or queries: help user respond then redisplay menu
|
||||
|
||||
#### 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 then end with display again of the menu options
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Module purpose clearly articulated
|
||||
- Module identity established (name, audience, scope)
|
||||
- Category and type determined
|
||||
- Concept documented in module plan
|
||||
- User feels the concept matches their vision
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding without clear module purpose
|
||||
- Not defining scope boundaries
|
||||
- Skipping user validation of concept
|
||||
- Not documenting concept details
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and module concept is saved to module-plan.md with stepsCompleted updated to [1, 2], will you then load, read entire file, then execute `{nextStepFile}` to begin component planning.
|
||||
@@ -0,0 +1,267 @@
|
||||
---
|
||||
installed_path: '{project-root}/{bmad_folder}/bmb/workflows/create-module'
|
||||
nextStepFile: '{installed_path}/steps/step-04-structure.md'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
agent_examples_path: '{project-root}/src/modules/bmb/reference/agents/module-examples'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 3: Plan Module Components
|
||||
|
||||
## 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 Module 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 BMAD component design patterns, user brings their domain requirements
|
||||
- ✅ Maintain collaborative, design-focused tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on planning component architecture
|
||||
- 🚫 FORBIDDEN to create actual components in this step
|
||||
- 💬 Present component options with reasoning
|
||||
- 🚫 FORBIDDEN to finalize component list without user agreement
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Reference agent examples for patterns
|
||||
- 💾 Document component plan in detail
|
||||
- 📖 Add "step-03-components" to stepsCompleted array` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Module concept from step 2 is available
|
||||
- Focus on planning, not implementation
|
||||
- Consider BMAD patterns and best practices
|
||||
- Reference examples but don't copy exactly
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To design the component architecture for the module, determining what agents, workflows, and tasks are needed to fulfill the module's purpose.
|
||||
|
||||
## COMPONENT PLANNING PROCESS:
|
||||
|
||||
### 1. Initialize Component Planning
|
||||
|
||||
"Now that we have a clear module concept, let's plan the components that will bring it to life.
|
||||
|
||||
Based on your module's purpose and scope, we'll design:
|
||||
|
||||
- **Agents** - The AI personas that will help users
|
||||
- **Workflows** - The step-by-step processes for accomplishing tasks
|
||||
- **Tasks** - Quick utilities and supporting functions"
|
||||
|
||||
### 2. Agent Planning
|
||||
|
||||
"**Agent Architecture:**
|
||||
|
||||
Think about the different roles or perspectives needed to accomplish your module's goals. Each agent should have a clear, distinct purpose."
|
||||
|
||||
Reference agent examples for patterns
|
||||
Load and browse agent examples: {agent_examples_path}
|
||||
|
||||
"**Common Agent Patterns:**
|
||||
|
||||
- **Primary Agent** - The main interface/orchestrator
|
||||
- **Specialist Agents** - Domain-specific experts
|
||||
- **Utility Agents** - Helper/support functions
|
||||
|
||||
**Example by Module Type:**
|
||||
|
||||
**Technical Modules (e.g., DevOps, Testing):**
|
||||
|
||||
- Implementation Specialist
|
||||
- Reviewer/Auditor
|
||||
- Documentation Expert
|
||||
|
||||
**Creative Modules (e.g., Story Writing, Game Design):**
|
||||
|
||||
- Creative Director
|
||||
- World Builder
|
||||
- Content Generator
|
||||
|
||||
**Business Modules (e.g., Project Management):**
|
||||
|
||||
- Project Coordinator
|
||||
- Facilitator
|
||||
- Analyst"
|
||||
|
||||
"**For your {module_category} module, I suggest considering:**
|
||||
|
||||
[Suggest 2-4 specific agent types based on module concept]
|
||||
|
||||
**What resonates with your vision?** Which of these agents would be most valuable, and are there any others you'd like to add?"
|
||||
|
||||
### 3. Workflow Planning
|
||||
|
||||
"**Workflow Design:**
|
||||
|
||||
Workflows are the step-by-step processes that users will follow to accomplish specific tasks. Each workflow should solve a specific problem or achieve a particular outcome."
|
||||
|
||||
**Types of Workflows:**
|
||||
|
||||
- **Document Workflows** - Generate reports, plans, specifications
|
||||
- **Action Workflows** - Perform operations, create structures
|
||||
- **Interactive Workflows** - Guided sessions, coaching, training
|
||||
|
||||
**Example Workflow Patterns:**
|
||||
|
||||
"For your module's purpose, consider these potential workflows:
|
||||
|
||||
1. **[Primary Workflow Name]** - Main workflow for core functionality
|
||||
2. **[Supporting Workflow 1]** - For specific use case
|
||||
3. **[Supporting Workflow 2]** - For another use case
|
||||
|
||||
Remember: We'll create workflow PLANS first, not full implementations. These plans can be used later with the create-workflow workflow."
|
||||
|
||||
### 4. Task Planning (Optional)
|
||||
|
||||
"**Task Planning (if needed):**
|
||||
|
||||
Tasks are single-operation utilities that don't need full workflows. They're good for:
|
||||
|
||||
- Quick actions
|
||||
- Shared subroutines
|
||||
- Helper functions
|
||||
|
||||
Does your module need any tasks? For example:
|
||||
|
||||
- Status checking
|
||||
- Quick formatting
|
||||
- Validation utilities"
|
||||
|
||||
### 5. Component Integration Planning
|
||||
|
||||
"**How Components Work Together:**
|
||||
|
||||
Let's think about how your components will interact:
|
||||
|
||||
- **Agent Collaboration**: Will agents work together or independently?
|
||||
- **Workflow Dependencies**: Do workflows need to call each other?
|
||||
- **Task Usage**: Which workflows will use which tasks?"
|
||||
|
||||
### 6. Component Priority and MVP
|
||||
|
||||
"**Starting Point (MVP):**
|
||||
|
||||
To ensure success, let's identify the minimum viable set:
|
||||
|
||||
**Must Have (Phase 1):**
|
||||
|
||||
- [List essential agents]
|
||||
- [List essential workflows]
|
||||
|
||||
**Nice to Have (Phase 2):**
|
||||
|
||||
- [Additional agents]
|
||||
- [Additional workflows]
|
||||
- [Tasks if any]
|
||||
|
||||
This approach lets you launch with core functionality and expand later."
|
||||
|
||||
### 7. Document Component Plan
|
||||
|
||||
Update module-plan.md with component section:
|
||||
|
||||
```markdown
|
||||
## Component Architecture
|
||||
|
||||
### Agents (N planned)
|
||||
|
||||
1. **[Agent Name]** - [Brief purpose]
|
||||
- Type: [Primary/Specialist/Utility]
|
||||
- Role: [Specific role description]
|
||||
|
||||
2. **[Agent Name]** - [Brief purpose]
|
||||
- Type: [Primary/Specialist/Utility]
|
||||
- Role: [Specific role description]
|
||||
|
||||
### Workflows (N planned)
|
||||
|
||||
1. **[Workflow Name]** - [Purpose]
|
||||
- Type: [Document/Action/Interactive]
|
||||
- Primary user: [Who uses this]
|
||||
- Key output: [What it produces]
|
||||
|
||||
2. **[Workflow Name]** - [Purpose]
|
||||
- Type: [Document/Action/Interactive]
|
||||
- Primary user: [Who uses this]
|
||||
- Key output: [What it produces]
|
||||
|
||||
### Tasks (N planned)
|
||||
|
||||
1. **[Task Name]** - [Single-purpose function]
|
||||
- Used by: [Which workflows/agents]
|
||||
|
||||
### Component Integration
|
||||
|
||||
- Agents collaborate via: [description]
|
||||
- Workflow dependencies: [description]
|
||||
- Task usage patterns: [description]
|
||||
|
||||
### Development Priority
|
||||
|
||||
**Phase 1 (MVP):**
|
||||
|
||||
- [List of components to create first]
|
||||
|
||||
**Phase 2 (Enhancement):**
|
||||
|
||||
- [List of components for later]
|
||||
```
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask} to explore alternative component architectures
|
||||
- IF P: Execute {partyModeWorkflow} to get creative input on component design
|
||||
- IF C: Save component plan to module-plan.md, add step-03-components to the end of the stepsCompleted array in frontmatter, then load nextStepFile
|
||||
- IF Any other comments or queries: help user respond then redisplay menu
|
||||
|
||||
#### 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 then end with display again of the menu options
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Component architecture planned and documented
|
||||
- Agent types and purposes clearly defined
|
||||
- Workflow requirements identified
|
||||
- Integration patterns established
|
||||
- Development priority set (MVP vs enhancements)
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Planning components without module purpose context
|
||||
- Not considering BMAD patterns and examples
|
||||
- Over-engineering (too many components)
|
||||
- Under-planning (missing essential components)
|
||||
- Not establishing development priorities
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and component plan is saved to module-plan.md with stepsCompleted updated to [1, 2, 3], will you then load, read entire file, then execute `{nextStepFile}` to begin creating the module structure.
|
||||
@@ -0,0 +1,228 @@
|
||||
---
|
||||
installed_path: '{project-root}/{bmad_folder}/bmb/workflows/create-module'
|
||||
nextStepFile: '{installed_path}/steps/step-05-config.md'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 4: Create Module Structure
|
||||
|
||||
## 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 Module Architect and Systems Organizer
|
||||
- ✅ 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 structure patterns, user brings their component requirements
|
||||
- ✅ Maintain collaborative, organized tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on creating directory structure and determining complexity
|
||||
- 🚫 FORBIDDEN to create actual component files in this step
|
||||
- 💬 Explain structure decisions clearly
|
||||
- 🚫 FORBIDDEN to proceed without confirming structure
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Use component count to determine module type
|
||||
- 💾 Create all required directories
|
||||
- 📖 Add "step-04-structure" to stepsCompleted array` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Component plan from step 3 is available
|
||||
- Standard BMAD module structure to follow
|
||||
- Focus on structure creation, not content
|
||||
- Module folder already exists from step 1
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To determine the module's complexity type and create the complete directory structure for the module.
|
||||
|
||||
## MODULE STRUCTURE CREATION PROCESS:
|
||||
|
||||
### 1. Determine Module Complexity
|
||||
|
||||
"Based on your component plan, let's determine your module's complexity level:"
|
||||
|
||||
**Count Components:**
|
||||
|
||||
- Agents: [count from plan]
|
||||
- Workflows: [count from plan]
|
||||
- Tasks: [count from plan]
|
||||
|
||||
**Complexity Assessment:**
|
||||
|
||||
"**Simple Module Criteria:**
|
||||
|
||||
- 1-2 agents, all Simple type
|
||||
- 1-3 workflows
|
||||
- No complex integrations
|
||||
|
||||
**Standard Module Criteria:**
|
||||
|
||||
- 2-4 agents with mixed types
|
||||
- 3-8 workflows
|
||||
- Some shared resources
|
||||
|
||||
**Complex Module Criteria:**
|
||||
|
||||
- 4+ agents or multiple Module-type agents
|
||||
- 8+ workflows
|
||||
- Complex interdependencies
|
||||
- External integrations"
|
||||
|
||||
"**Your module has:**
|
||||
|
||||
- [agent_count] agents
|
||||
- [workflow_count] workflows
|
||||
- [task_count] tasks
|
||||
|
||||
**This makes it a: [Simple/Standard/Complex] Module**"
|
||||
|
||||
### 2. Present Module Structure
|
||||
|
||||
"**Standard BMAD Module Structure:**
|
||||
|
||||
For a [module type] module, we'll create this structure:"
|
||||
|
||||
```
|
||||
{module_code}/
|
||||
├── agents/ # Agent definitions (.md)
|
||||
│ ├── [agent-name].md
|
||||
│ └── ...
|
||||
├── workflows/ # Workflow folders
|
||||
│ ├── [workflow-name]/
|
||||
│ │ ├── workflow-plan.md # Descriptive plan
|
||||
│ │ └── README.md # Workflow documentation
|
||||
│ └── ...
|
||||
├── tasks/ # Task files (if any)
|
||||
│ └── [task-name].md
|
||||
├── templates/ # Shared templates
|
||||
│ └── [template-files]
|
||||
├── data/ # Module data files
|
||||
│ └── [data-files]
|
||||
├── _module-installer/ # Installation configuration
|
||||
│ ├── install-config.yaml # Required
|
||||
│ ├── installer.js # Optional
|
||||
│ └── assets/ # Optional install assets
|
||||
└── README.md # Module documentation
|
||||
```
|
||||
|
||||
### 3. Create Directory Structure
|
||||
|
||||
Create all directories in {custom_module_location}/{module_name}/:
|
||||
|
||||
1. **agents/** - For agent definition files
|
||||
2. **workflows/** - For workflow folders
|
||||
3. **tasks/** - For task files (if tasks planned)
|
||||
4. **templates/** - For shared templates
|
||||
5. **data/** - For module data
|
||||
6. **\_module-installer/** - For installation configuration
|
||||
|
||||
### 4. Create Placeholder README
|
||||
|
||||
Create initial README.md with basic structure:
|
||||
|
||||
````markdown
|
||||
# {module_display_name}
|
||||
|
||||
{module_purpose}
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
bmad install {module_code}
|
||||
```
|
||||
````
|
||||
|
||||
## Components
|
||||
|
||||
_Module documentation will be completed in Step 9_
|
||||
|
||||
## Quick Start
|
||||
|
||||
_Getting started guide will be added in Step 9_
|
||||
|
||||
---
|
||||
|
||||
_This module is currently under construction_
|
||||
|
||||
````
|
||||
|
||||
### 5. Document Structure Creation
|
||||
|
||||
Update module-plan.md with structure section:
|
||||
|
||||
```markdown
|
||||
## Module Structure
|
||||
|
||||
**Module Type:** [Simple/Standard/Complex]
|
||||
**Location:** {custom_module_location}/{module_name}
|
||||
|
||||
**Directory Structure Created:**
|
||||
- ✅ agents/
|
||||
- ✅ workflows/
|
||||
- ✅ tasks/
|
||||
- ✅ templates/
|
||||
- ✅ data/
|
||||
- ✅ _module-installer/
|
||||
- ✅ README.md (placeholder)
|
||||
|
||||
**Rationale for Type:**
|
||||
[Explain why it's Simple/Standard/Complex based on component counts]
|
||||
````
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask} to explore alternative structure approaches
|
||||
- IF P: Execute {partyModeWorkflow} to get creative input on organization
|
||||
- IF C: Save structure info to module-plan.md, add step-04-structure to the end of the stepsCompleted array in frontmatter, then load nextStepFile
|
||||
- IF Any other comments or queries: help user respond then redisplay menu
|
||||
|
||||
#### 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 then end with display again of the menu options
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Module complexity correctly determined
|
||||
- All required directories created
|
||||
- Structure follows BMAD standards
|
||||
- Placeholder README created
|
||||
- Structure documented in plan
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not creating all required directories
|
||||
- Incorrectly categorizing module complexity
|
||||
- Not following BMAD structure patterns
|
||||
- Creating component files prematurely
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and structure is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4], will you then load, read entire file, then execute `{nextStepFile}` to begin configuration planning.
|
||||
233
src/modules/bmb/workflows/create-module/steps/step-05-config.md
Normal file
233
src/modules/bmb/workflows/create-module/steps/step-05-config.md
Normal file
@@ -0,0 +1,233 @@
|
||||
---
|
||||
installed_path: '{project-root}/{bmad_folder}/bmb/workflows/create-module'
|
||||
nextStepFile: '{installed_path}/steps/step-06-agents.md'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Plan Module Configuration
|
||||
|
||||
## 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 Module Architect and Configuration 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 installation patterns, user brings their module requirements
|
||||
- ✅ Maintain collaborative, planning-focused tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on planning configuration fields
|
||||
- 🚫 FORBIDDEN to create installer files in this step
|
||||
- 💬 Present configuration options clearly
|
||||
- 🚫 FORBIDDEN to finalize without user input
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Consider what users might want to configure
|
||||
- 💾 Document all configuration field plans
|
||||
- 📖 Add "step-05-config" to stepsCompleted array` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Module concept and components from previous steps
|
||||
- Standard BMAD installer configuration patterns
|
||||
- Focus on planning, not implementation
|
||||
- Consider user customization needs
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To determine what configuration settings the module needs and plan how they'll be implemented in the installer.
|
||||
|
||||
## CONFIGURATION PLANNING PROCESS:
|
||||
|
||||
### 1. Initialize Configuration Planning
|
||||
|
||||
"Now let's plan the configuration for your module's installer. This determines what users can customize when they install your module."
|
||||
|
||||
**Configuration allows users to:**
|
||||
|
||||
- Set up file locations
|
||||
- Choose features or behavior
|
||||
- Provide API keys or credentials
|
||||
- Adjust output formats
|
||||
- Configure integrations
|
||||
|
||||
### 2. Assess Configuration Needs
|
||||
|
||||
"**Configuration Assessment:**
|
||||
|
||||
Does your {module_display_name} module need any user-configurable settings during installation?"
|
||||
|
||||
**Common Configuration Categories:**
|
||||
|
||||
**1. Output/Data Paths**
|
||||
|
||||
- Where should outputs be saved?
|
||||
- What's the default data directory?
|
||||
- Any special folder structures needed?
|
||||
|
||||
**2. Feature Toggles**
|
||||
|
||||
- Enable/disable specific features
|
||||
- Choose between behavior modes
|
||||
- Set verbosity levels
|
||||
|
||||
**3. Integration Settings**
|
||||
|
||||
- API keys (for external services)
|
||||
- Service endpoints
|
||||
- Authentication credentials
|
||||
|
||||
**4. User Preferences**
|
||||
|
||||
- Default language
|
||||
- Time zone
|
||||
- Skill level (beginner/advanced)
|
||||
- Detail level (minimal/standard/verbose)"
|
||||
|
||||
### 3. Plan Configuration Fields
|
||||
|
||||
"**For each configuration need, let's define:**
|
||||
|
||||
1. **Field Name** (snake_case, e.g., 'output_path')
|
||||
2. **Type** - INTERACTIVE (asks user) or STATIC (hardcoded)
|
||||
3. **Prompt** (what to ask user, if interactive)
|
||||
4. **Default Value** (sensible default)
|
||||
5. **Input Type** - text, single-select, multi-select
|
||||
6. **Result Template** - how to store the value"
|
||||
|
||||
**Examples:**
|
||||
|
||||
"**INTERACTIVE Text Input:**
|
||||
|
||||
```yaml
|
||||
output_path:
|
||||
prompt: 'Where should {module_name} save outputs?'
|
||||
default: 'output/{module_name}'
|
||||
result: '{project-root}/{value}'
|
||||
```
|
||||
|
||||
**INTERACTIVE Single-Select:**
|
||||
|
||||
```yaml
|
||||
detail_level:
|
||||
prompt: 'How detailed should outputs be?'
|
||||
default: 'standard'
|
||||
result: '{value}'
|
||||
single-select:
|
||||
- value: 'minimal'
|
||||
label: 'Minimal - Brief summaries only'
|
||||
- value: 'standard'
|
||||
label: 'Standard - Balanced detail'
|
||||
- value: 'detailed'
|
||||
label: 'Detailed - Comprehensive information'
|
||||
```
|
||||
|
||||
**STATIC Value:**
|
||||
|
||||
````yaml
|
||||
module_version:
|
||||
result: "1.0.0"
|
||||
```"
|
||||
|
||||
### 4. Design Configuration for Your Module
|
||||
|
||||
"**Based on your module's purpose, consider these potential configurations:"
|
||||
|
||||
[Suggest relevant configurations based on module type and purpose]
|
||||
|
||||
"**Which of these apply to your module?**
|
||||
- [Present options relevant to the specific module]
|
||||
|
||||
**Any additional configurations needed?**"
|
||||
|
||||
### 5. Document Configuration Plan
|
||||
|
||||
Update module-plan.md with configuration section:
|
||||
|
||||
```markdown
|
||||
## Configuration Planning
|
||||
|
||||
### Required Configuration Fields
|
||||
|
||||
1. **[field_name]**
|
||||
- Type: [INTERACTIVE/STATIC]
|
||||
- Purpose: [what it controls]
|
||||
- Default: [default value]
|
||||
- Input Type: [text/single-select/multi-select]
|
||||
- Prompt: [user prompt if interactive]
|
||||
|
||||
2. **[field_name]**
|
||||
- Type: [INTERACTIVE/STATIC]
|
||||
- Purpose: [what it controls]
|
||||
- Default: [default value]
|
||||
- Input Type: [text/single-select/multi-select]
|
||||
- Prompt: [user prompt if interactive]
|
||||
|
||||
### Installation Questions Flow
|
||||
|
||||
1. [First question]
|
||||
2. [Second question]
|
||||
3. [Additional questions...]
|
||||
|
||||
### Result Configuration Structure
|
||||
|
||||
The install-config.yaml will generate:
|
||||
- Module configuration at: {bmad_folder}/{module_code}/config.yaml
|
||||
- User settings stored as: [describe structure]
|
||||
````
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask} to explore additional configuration options
|
||||
- IF P: Execute {partyModeWorkflow} to get input on user experience
|
||||
- IF C: Save configuration plan to module-plan.md, add step-05-config to the end of the stepsCompleted array in frontmatter, then load nextStepFile
|
||||
- IF Any other comments or queries: help user respond then redisplay menu
|
||||
|
||||
#### 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 then end with display again of the menu options
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All necessary configuration fields identified
|
||||
- Field types and prompts clearly defined
|
||||
- User interaction flow planned
|
||||
- Configuration structure documented
|
||||
- Ready for installer implementation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping configuration planning for modules that need it
|
||||
- Over-configuring (too many options)
|
||||
- Not considering user experience
|
||||
- Not documenting configuration plans
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and configuration plan is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5], will you then load, read entire file, then execute `{nextStepFile}` to begin agent creation.
|
||||
296
src/modules/bmb/workflows/create-module/steps/step-06-agents.md
Normal file
296
src/modules/bmb/workflows/create-module/steps/step-06-agents.md
Normal file
@@ -0,0 +1,296 @@
|
||||
---
|
||||
installed_path: '{project-root}/{bmad_folder}/bmb/workflows/create-module'
|
||||
nextStepFile: '{installed_path}/steps/step-07-workflows.md'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
agentTemplate: '{installed_path}/templates/agent.template.md'
|
||||
agent_examples_path: '{project-root}/src/modules/bmb/reference/agents/module-examples'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 6: Create Module Agents
|
||||
|
||||
## 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 Module Architect and Agent 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 BMAD agent patterns, user brings their domain requirements
|
||||
- ✅ Maintain collaborative, creative tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on creating proper YAML agent files following the template
|
||||
- 🚫 FORBIDDEN to use create-agent workflow (it's problematic)
|
||||
- 💬 Create placeholder workflow folders with README.md for each agent
|
||||
- 🚫 FORBIDDEN to create full workflows in this step
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow agent.template.md exactly for structure
|
||||
- 💾 Save agents as .yaml files to module's agents folder
|
||||
- 📖 Create workflow folders with README.md plans
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Component plan from step 3 defines which agents to create
|
||||
- Agent template provides the required YAML structure
|
||||
- Module structure already created
|
||||
- Focus on agent creation and workflow placeholders
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To create the primary agent(s) for the module using the proper agent template and create placeholder workflow folders for each agent.
|
||||
|
||||
## AGENT CREATION PROCESS:
|
||||
|
||||
### 1. Review Agent Plan
|
||||
|
||||
"Let's create the agents for your {module_display_name} module.
|
||||
|
||||
From your component plan, you have:
|
||||
|
||||
- [agent_count] agents planned
|
||||
- [list of agent types from plan]
|
||||
|
||||
I'll create each agent following the proper BMAD template and set up placeholder workflow folders for them."
|
||||
|
||||
### 2. Load Agent Template
|
||||
|
||||
Load and study the agent template from {agentTemplate}
|
||||
Reference agent examples from {agent_examples_path} for patterns
|
||||
|
||||
### 3. Create Each Agent
|
||||
|
||||
For each agent in the component plan:
|
||||
|
||||
#### 3.1 Determine Agent Characteristics
|
||||
|
||||
"**Agent: [Agent Name]**
|
||||
|
||||
Let's design this agent by understanding what it needs:
|
||||
|
||||
**Memory & Learning:**
|
||||
|
||||
1. Does this agent need to remember things across sessions? (conversations, preferences, patterns)
|
||||
- If yes: We'll add sidecar folder structure for memory
|
||||
- If no: No persistent memory needed
|
||||
|
||||
**Interaction Types:** 2. What does this agent DO?
|
||||
|
||||
- Conversational interactions? → Use embedded prompts
|
||||
- Quick single actions? → Use inline actions
|
||||
- Complex multi-step processes? → Consider workflows
|
||||
- Document generation? → Likely need workflows
|
||||
|
||||
**Multiple Agent Usage:** 3. Will other agents in this module need the same workflows?
|
||||
|
||||
- If yes: Definitely create separate workflow files
|
||||
- If no: Could embed in agent file
|
||||
|
||||
**Based on this, what combination does [Agent Name] need?**
|
||||
|
||||
- Memory/Persistence: [Yes/No]
|
||||
- Embedded prompts: [List main interactions]
|
||||
- Workflows needed: [Which processes need separate files?]"
|
||||
|
||||
#### 3.2 Present Agent Design
|
||||
|
||||
"**Agent Design: [Agent Name]**
|
||||
|
||||
**Core Identity:**
|
||||
|
||||
- Name: [Suggested name]
|
||||
- Title: [Brief description]
|
||||
- Icon: [Appropriate emoji]
|
||||
|
||||
**Persona:**
|
||||
|
||||
- Role: [What the agent does]
|
||||
- Identity: [Personality/background]
|
||||
- Communication Style: [How they communicate]
|
||||
- Principles: [3-5 core principles]
|
||||
|
||||
**Structure:**
|
||||
|
||||
- Memory needed: [Yes/No - sidecar folder]
|
||||
- Embedded prompts: [List main interaction prompts]
|
||||
- Workflow processes: [Which need separate files]
|
||||
|
||||
**Menu Items Planned:**
|
||||
|
||||
- [List with trigger codes and types]
|
||||
|
||||
**Quick actions vs Workflows:**
|
||||
|
||||
- Quick prompts: [single-step interactions]
|
||||
- Workflows: [multi-step, shared processes]
|
||||
|
||||
Does this design match what you envisioned? What should we adjust?"
|
||||
|
||||
#### 3.3 Create Agent File and Structure
|
||||
|
||||
After user confirmation:
|
||||
|
||||
Create hybrid agent file with only needed sections:
|
||||
|
||||
```yaml
|
||||
agent:
|
||||
metadata:
|
||||
name: '[Agent Name]'
|
||||
title: '[Agent Title]'
|
||||
icon: '[Icon]'
|
||||
module: '{module_code}'
|
||||
persona:
|
||||
role: '[Agent Role]'
|
||||
identity: |
|
||||
[Multi-line identity description]
|
||||
communication_style: |
|
||||
[Multi-line communication style]
|
||||
principles:
|
||||
- '[Principle 1]'
|
||||
- '[Principle 2]'
|
||||
- '[Principle 3]'
|
||||
|
||||
# Only include if agent needs memory/persistence
|
||||
critical_actions:
|
||||
- 'Load COMPLETE file {agent-folder}/[agent-name]-sidecar/memories.md and integrate all past interactions'
|
||||
- 'ONLY read/write files in {agent-folder}/[agent-name]-sidecar/ - this is our private workspace'
|
||||
|
||||
# Only include if agent has embedded prompts
|
||||
prompts:
|
||||
- id: '[prompt-name]'
|
||||
content: |
|
||||
<instructions>
|
||||
[How to use this prompt]
|
||||
</instructions>
|
||||
|
||||
[Detailed prompt content]
|
||||
|
||||
menu:
|
||||
# Always include
|
||||
- multi: '[CH] Chat with agent or [SPM] Start Party Mode'
|
||||
triggers:
|
||||
- party-mode:
|
||||
input: SPM
|
||||
route: '{project-root}/{bmad_folder}/core/workflows/edit-agent/workflow.md'
|
||||
type: exec
|
||||
- expert-chat:
|
||||
input: CH
|
||||
action: agent responds as expert
|
||||
type: action
|
||||
|
||||
# Group related functions
|
||||
- multi: '[PF] Primary Function [QF] Quick Task'
|
||||
triggers:
|
||||
- primary-function:
|
||||
input: PF
|
||||
action: '#[prompt-id]'
|
||||
type: action
|
||||
- quick-task:
|
||||
input: QF
|
||||
route: '#[prompt-id]'
|
||||
type: exec
|
||||
|
||||
# Workflow only for complex processes
|
||||
- trigger: 'complex-process'
|
||||
route: '{project-root}/{bmad_folder}/{custom_module}/workflows/[workflow]/workflow.md'
|
||||
description: 'Complex process [icon]'
|
||||
|
||||
# Quick inline actions
|
||||
- trigger: 'save-item'
|
||||
action: 'Save to {agent-folder}/[agent-name]-sidecar/file.md'
|
||||
description: 'Save item 💾'
|
||||
```
|
||||
|
||||
#### 3.4 Create Supporting Structure
|
||||
|
||||
**If agent needs memory:**
|
||||
|
||||
1. Create folder: {custom_module_location}/{module_name}/agents/[agent-name]-sidecar/
|
||||
2. Create files:
|
||||
- memories.md (empty, for persistent memory)
|
||||
- instructions.md (empty, for agent protocols)
|
||||
- insights.md (empty, for breakthrough moments)
|
||||
- sessions/ (subfolder for session records)
|
||||
- patterns.md (empty, for tracking patterns)
|
||||
|
||||
**If agent has workflows:**
|
||||
For each workflow that needs separate file:
|
||||
|
||||
1. Create folder: {custom_module_location}/{module_name}/workflows/[workflow-name]/
|
||||
2. Create README.md with workflow plan
|
||||
|
||||
### 4. Repeat for All Agents
|
||||
|
||||
Go through each agent from the component plan, presenting drafts and creating files with user confirmation.
|
||||
|
||||
### 5. Document Agent Creation
|
||||
|
||||
Update module-plan.md with agents section:
|
||||
|
||||
```markdown
|
||||
## Agents Created
|
||||
|
||||
1. **[Agent Name]** - [Agent Title]
|
||||
- File: [agent-filename].yaml
|
||||
- Features: [Memory/Sidecar, Embedded prompts, Workflows]
|
||||
- Structure:
|
||||
- Sidecar: [Yes/No]
|
||||
- Prompts: [number embedded]
|
||||
- Workflows: [list of workflow folders]
|
||||
- Status: Created with [combination of features]
|
||||
```
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask} to refine agent designs
|
||||
- IF P: Execute {partyModeWorkflow} to get creative input on agent personas
|
||||
- IF C: Save agent creation status to module-plan.md, add step-06-agents to the end of the stepsCompleted array in frontmatter, then load nextStepFile
|
||||
- IF Any other comments or queries: help user respond then redisplay menu
|
||||
|
||||
#### 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 then end with display again of the menu options
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All planned agents created with proper YAML structure
|
||||
- Each agent follows agent.template.md format exactly
|
||||
- Workflow placeholder folders created with README.md plans
|
||||
- Agent menu items properly reference workflow paths
|
||||
- Users confirmed each agent draft before creation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Using create-agent workflow instead of template
|
||||
- Creating XML agents instead of YAML
|
||||
- Not creating workflow placeholder folders
|
||||
- Skipping user confirmation on agent drafts
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all agents are created with placeholder workflows and stepsCompleted updated, will you then load, read entire file, then execute `{nextStepFile}` to begin workflow plan review.
|
||||
@@ -0,0 +1,228 @@
|
||||
---
|
||||
installed_path: '{project-root}/{bmad_folder}/bmb/workflows/create-module'
|
||||
nextStepFile: '{installed_path}/steps/step-08-installer.md'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
workflowPlanTemplate: '{installed_path}/templates/workflow-plan-template.md'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 7: Review Workflow Plans
|
||||
|
||||
## 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 Module Architect and Workflow 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 BMAD workflow patterns, user brings their workflow requirements
|
||||
- ✅ Maintain collaborative, review-focused tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on reviewing existing workflow README files from Step 6
|
||||
- 🚫 FORBIDDEN to use create-workflow workflow in this step
|
||||
- 💬 Review and refine workflow plans, not create new ones
|
||||
- 🚫 FORBIDDEN to create actual workflow steps
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Review workflow README files created in Step 6
|
||||
- 💾 Update README files based on user feedback
|
||||
- 📖 Add "step-07-workflows" to stepsCompleted array` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Workflow README files were created in Step 6 for each agent
|
||||
- These README files contain workflow plans for later implementation
|
||||
- Module structure already created with workflow folders
|
||||
- Focus on reviewing and refining, not creating from scratch
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To review and refine the workflow README files created in Step 6, ensuring they have clear plans for later implementation with the create-workflow workflow.
|
||||
|
||||
## WORKFLOW REVIEW PROCESS:
|
||||
|
||||
### 1. List Workflow Folders Created
|
||||
|
||||
"Let's review the workflow plans created in Step 6 for your {module_display_name} module.
|
||||
|
||||
I've already created workflow folders and README.md files for each agent's workflows:
|
||||
|
||||
**Workflow folders found:**
|
||||
|
||||
- [List all workflow folders in {custom_module_location}/{module_name}/workflows/]
|
||||
|
||||
**Each workflow folder contains a README.md with:**
|
||||
|
||||
- Purpose and description
|
||||
- Trigger code from agent menu
|
||||
- Key steps outline
|
||||
- Expected outputs
|
||||
- Notes for implementation"
|
||||
|
||||
### 2. Review Each Workflow Plan
|
||||
|
||||
For each workflow README file:
|
||||
|
||||
#### 2.1 Load and Present
|
||||
|
||||
"**Reviewing Workflow: [Workflow Name]**
|
||||
|
||||
Reading the README.md from: [workflow-folder]/README.md
|
||||
|
||||
**Current Plan:**
|
||||
[Purpose]
|
||||
[Trigger]
|
||||
[Key Steps]
|
||||
[Expected Output]
|
||||
[Notes]
|
||||
|
||||
How does this plan look? Should we:
|
||||
|
||||
- Keep it as is
|
||||
- Modify the purpose
|
||||
- Adjust the steps
|
||||
- Change the expected output"
|
||||
|
||||
#### 2.2 Update Based on Feedback
|
||||
|
||||
If user wants changes:
|
||||
|
||||
- Update the README.md file
|
||||
- Keep the same basic structure
|
||||
- Ensure clarity for future implementation
|
||||
|
||||
#### 2.3 Check for Missing Information
|
||||
|
||||
Ensure each README has:
|
||||
|
||||
```markdown
|
||||
# [Workflow Name]
|
||||
|
||||
## Purpose
|
||||
|
||||
[Clear, concise description of what this workflow accomplishes]
|
||||
|
||||
## Trigger
|
||||
|
||||
[Trigger code from agent menu, e.g., "WF" or specific code]
|
||||
|
||||
## Key Steps
|
||||
|
||||
1. [Step 1 - What happens first]
|
||||
2. [Step 2 - What happens next]
|
||||
3. [Step 3 - Continue as needed]
|
||||
|
||||
## Expected Output
|
||||
|
||||
[What the workflow produces - document, action, result]
|
||||
|
||||
## Notes
|
||||
|
||||
This workflow will be implemented using the create-workflow workflow.
|
||||
(Optional: Any special considerations or requirements)
|
||||
```
|
||||
|
||||
### 3. Link Workflows to Agents
|
||||
|
||||
"**Workflow-Agent Mapping:**
|
||||
|
||||
Let's verify each workflow is properly linked to its agent:
|
||||
|
||||
[For each workflow]:
|
||||
|
||||
- **Workflow:** [Workflow Name]
|
||||
- **Agent:** [Agent Name]
|
||||
- **Trigger Code:** [WF code]
|
||||
- **Menu Item:** [Menu description in agent]
|
||||
|
||||
Are all these mappings correct in the agent files?"
|
||||
|
||||
### 4. Document Implementation Plan
|
||||
|
||||
Update module-plan.md with workflow section:
|
||||
|
||||
```markdown
|
||||
## Workflow Plans Reviewed
|
||||
|
||||
### For Agent [Agent Name]:
|
||||
|
||||
1. **[Workflow Name]**
|
||||
- Location: workflows/[workflow-name]/
|
||||
- Status: Plan reviewed and ready for implementation
|
||||
- Trigger: [WF code]
|
||||
- Implementation: Use create-workflow workflow
|
||||
|
||||
2. **[Workflow Name]**
|
||||
- Location: workflows/[workflow-name]/
|
||||
- Status: Plan reviewed and ready for implementation
|
||||
- Trigger: [WF code]
|
||||
- Implementation: Use create-workflow workflow
|
||||
```
|
||||
|
||||
### 5. Next Steps Guidance
|
||||
|
||||
"**Ready for Implementation:**
|
||||
|
||||
All workflow plans are now reviewed and ready. To implement these workflows later:
|
||||
|
||||
1. Use the `/bmad:bmb:workflows:create-workflow` command
|
||||
2. Select each workflow folder
|
||||
3. Follow the create-workflow workflow
|
||||
4. It will create the full workflow.md and step files
|
||||
|
||||
The README.md in each folder serves as your blueprint for implementation."
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask} to refine workflow designs
|
||||
- IF P: Execute {partyModeWorkflow} to get creative input on workflow processes
|
||||
- IF C: Save workflow plan status to module-plan.md, add step-07-workflows to the end of the stepsCompleted array in frontmatter, then load nextStepFile
|
||||
- IF Any other comments or queries: help user respond then redisplay menu
|
||||
|
||||
#### 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 then end with display again of the menu options
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All workflow README files reviewed with user
|
||||
- Each workflow plan has clear purpose and steps
|
||||
- Workflow-agent mappings verified
|
||||
- README files updated based on feedback
|
||||
- Clear implementation guidance provided
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping review of workflow README files
|
||||
- Not updating plans based on user feedback
|
||||
- Missing critical information in README files
|
||||
- Not verifying workflow-agent mappings
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all workflow plans are reviewed and documented and stepsCompleted updated, will you then load, read entire file, then execute `{nextStepFile}` to begin installer setup.
|
||||
@@ -0,0 +1,186 @@
|
||||
---
|
||||
installed_path: '{project-root}/{bmad_folder}/bmb/workflows/create-module'
|
||||
nextStepFile: '{installed_path}/steps/step-09-documentation.md'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
installerTemplate: '{installed_path}/templates/installer.template.js'
|
||||
installConfigTemplate: '{installed_path}/templates/install-config.template.yaml'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 8: Setup Module Installer
|
||||
|
||||
## 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 Module Architect and Installation 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 installation patterns, user brings their module requirements
|
||||
- ✅ Maintain collaborative, technical tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on creating installer configuration files
|
||||
- 🚫 FORBIDDEN to run actual installation
|
||||
- 💬 Follow BMAD installer standards exactly
|
||||
- 🚫 FORBIDDEN to deviate from configuration template
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Use configuration plan from step 5
|
||||
- 💾 Create install-config.yaml with all fields
|
||||
- 📖 Add "step-08-installer" to stepsCompleted array` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Configuration plan from step 5 defines installer fields
|
||||
- Standard BMAD installer template to follow
|
||||
- Module structure already created
|
||||
- Focus on installer setup, not module content
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To create the module installer configuration (install-config.yaml) that defines how users will install and configure the module.
|
||||
|
||||
## INSTALLER SETUP PROCESS:
|
||||
|
||||
### 1. Review Configuration Plan
|
||||
|
||||
"Now let's set up the installer for your {module_display_name} module.
|
||||
|
||||
The installer will:
|
||||
|
||||
- Define how users install your module
|
||||
- Collect configuration settings
|
||||
- Set up the module structure in user projects
|
||||
- Generate the module's config.yaml file
|
||||
|
||||
From step 5, we planned these configuration fields:
|
||||
|
||||
- [List planned configuration fields]"
|
||||
|
||||
### 2. Create Installer Directory
|
||||
|
||||
Ensure \_module-installer directory exists
|
||||
Directory: {custom_module_location}/{module_name}/\_module-installer/
|
||||
|
||||
### 3. Create install-config.yaml
|
||||
|
||||
"I'll create the install-config.yaml file based on your configuration plan. This is the core installer configuration file."
|
||||
|
||||
Create file: {custom_module_location}/{module_name}/\_module-installer/install-config.yaml from template {installConfigTemplate}
|
||||
|
||||
### 4. Handle Custom Installation Logic
|
||||
|
||||
"**Custom Installation Logic:**
|
||||
|
||||
Does your module need any special setup during installation? For example:
|
||||
|
||||
- Creating database tables
|
||||
- Setting up API connections
|
||||
- Downloading external assets
|
||||
- Running initialization scripts"
|
||||
|
||||
<ask>Does your module need custom installation logic? [yes/no]</ask>
|
||||
|
||||
"I'll create an installer.js file for custom logic."
|
||||
|
||||
Create file: {custom_module_location}/{module_name}/\_module-installer/installer.js from {installerTemplate}
|
||||
|
||||
Update installer.js with module-specific logic
|
||||
|
||||
### 5. Create Assets Directory (if needed)
|
||||
|
||||
"**Installer Assets:**
|
||||
|
||||
If your module needs to copy files during installation (templates, examples, documentation), we can add them to the assets directory."
|
||||
|
||||
Create directory: \_module-installer/assets/
|
||||
Add note about what assets to include
|
||||
|
||||
### 6. Document Installer Setup
|
||||
|
||||
Update module-plan.md with installer section:
|
||||
|
||||
```markdown
|
||||
## Installer Configuration
|
||||
|
||||
### Install Configuration
|
||||
|
||||
- File: \_module-installer/install-config.yaml
|
||||
- Module code: {module_name}
|
||||
- Default selected: false
|
||||
- Configuration fields: [count]
|
||||
|
||||
### Custom Logic
|
||||
|
||||
- installer.js: [Created/Not needed]
|
||||
- Custom setup: [description if yes]
|
||||
|
||||
### Installation Process
|
||||
|
||||
1. User runs: `bmad install {module_name}`
|
||||
2. Installer asks: [list of questions]
|
||||
3. Creates: {bmad_folder}/{module_name}/
|
||||
4. Generates: config.yaml with user settings
|
||||
|
||||
### Validation
|
||||
|
||||
- ✅ YAML syntax valid
|
||||
- ✅ All fields defined
|
||||
- ✅ Paths use proper templates
|
||||
- ✅ Custom logic ready (if needed)
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask} to review installer configuration
|
||||
- IF P: Execute {partyModeWorkflow} to get input on user experience
|
||||
- IF C: Save installer info to module-plan.md, add step-08-installer to the end of the stepsCompleted array in frontmatter, then load nextStepFile
|
||||
- IF Any other comments or queries: help user respond then redisplay menu
|
||||
|
||||
#### 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 then end with display again of the menu options
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- install-config.yaml created with all planned fields
|
||||
- YAML syntax valid
|
||||
- Custom installation logic prepared (if needed)
|
||||
- Installer follows BMAD standards
|
||||
- Configuration properly templated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not creating install-config.yaml
|
||||
- Invalid YAML syntax
|
||||
- Missing required fields
|
||||
- Not using proper path templates
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and installer info is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5, 6, 7, 8], will you then load, read entire file, then execute `{nextStepFile}` to begin documentation creation.
|
||||
@@ -0,0 +1,308 @@
|
||||
---
|
||||
installed_path: '{project-root}/{bmad_folder}/bmb/workflows/create-module'
|
||||
nextStepFile: '{installed_path}/steps/step-10-roadmap.md'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
moduleReadmeFile: '{custom_module_location}/{module_name}/README.md'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 9: Create Module Documentation
|
||||
|
||||
## 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 Module Architect and Technical Writer
|
||||
- ✅ 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 documentation best practices, user brings their module knowledge
|
||||
- ✅ Maintain collaborative, clear tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on creating comprehensive README documentation
|
||||
- 🚫 FORBIDDEN to create docs in other locations
|
||||
- 💬 Generate content based on module plan
|
||||
- 🚫 FORBIDDEN to skip standard sections
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Use all gathered module information
|
||||
- 💾 Update the placeholder README.md file
|
||||
- 📖 Add "step-09-documentation" to stepsCompleted array` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All module information from previous steps
|
||||
- Module structure and components already created
|
||||
- Focus on README.md, not other documentation
|
||||
- Generate content dynamically from plan
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To create comprehensive README.md documentation for the module that helps users understand, install, and use the module.
|
||||
|
||||
## DOCUMENTATION CREATION PROCESS:
|
||||
|
||||
### 1. Initialize Documentation
|
||||
|
||||
"Let's create the README.md for your {module_display_name} module.
|
||||
|
||||
Good documentation is crucial for module adoption. Your README will be the first thing users see when discovering your module."
|
||||
|
||||
### 2. Generate README Content
|
||||
|
||||
Load module-plan.md to gather all module information
|
||||
Update {moduleReadmeFile} with comprehensive content:
|
||||
|
||||
````markdown
|
||||
# {module_display_name}
|
||||
|
||||
{module_purpose}
|
||||
|
||||
## Overview
|
||||
|
||||
This module provides:
|
||||
[Generate list based on module components and features]
|
||||
|
||||
## Installation
|
||||
|
||||
Install the module using BMAD:
|
||||
|
||||
```bash
|
||||
bmad install {module_name}
|
||||
```
|
||||
````
|
||||
|
||||
## Components
|
||||
|
||||
### Agents ({agent_count})
|
||||
|
||||
[List created agents with brief descriptions]
|
||||
|
||||
### Workflows ({workflow_count})
|
||||
|
||||
[List planned workflows with purposes]
|
||||
|
||||
### Tasks ({task_count})
|
||||
|
||||
[List tasks if any]
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. **Load the primary agent:**
|
||||
|
||||
```
|
||||
agent {primary_agent_name}
|
||||
```
|
||||
|
||||
2. **View available commands:**
|
||||
|
||||
```
|
||||
*help
|
||||
```
|
||||
|
||||
3. **Run the main workflow:**
|
||||
|
||||
```
|
||||
workflow {primary_workflow_name}
|
||||
```
|
||||
|
||||
## Module Structure
|
||||
|
||||
```
|
||||
{module_name}/
|
||||
├── agents/ # Agent definitions
|
||||
│ ├── [agent-1].md
|
||||
│ └── [agent-2].md
|
||||
├── workflows/ # Workflow folders
|
||||
│ ├── [workflow-1]/
|
||||
│ │ ├── workflow-plan.md
|
||||
│ │ └── README.md
|
||||
│ └── [workflow-2]/
|
||||
│ └── ...
|
||||
├── tasks/ # Task files
|
||||
├── templates/ # Shared templates
|
||||
├── data/ # Module data
|
||||
├── _module-installer/ # Installation config
|
||||
└── README.md # This file
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
The module can be configured in `{bmad_folder}/{module_name}/config.yaml`
|
||||
|
||||
**Key Settings:**
|
||||
|
||||
[List configuration fields from installer]
|
||||
|
||||
[Example:]
|
||||
|
||||
- **output_path**: Where outputs are saved
|
||||
- **detail_level**: Controls output verbosity
|
||||
- **feature_x**: Enable/disable specific features
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: [Primary Use Case]
|
||||
|
||||
[Step-by-step example of using the module for its main purpose]
|
||||
|
||||
1. Start the agent
|
||||
2. Provide input
|
||||
3. Review output
|
||||
|
||||
### Example 2: [Secondary Use Case]
|
||||
|
||||
[Additional example if applicable]
|
||||
|
||||
## Development Status
|
||||
|
||||
This module is currently:
|
||||
|
||||
- [x] Structure created
|
||||
- [x] Installer configured
|
||||
- [ ] Agents implemented
|
||||
- [ ] Workflows implemented
|
||||
- [ ] Full testing complete
|
||||
|
||||
**Note:** Some workflows are planned but not yet implemented. See individual workflow folders for status.
|
||||
|
||||
## Contributing
|
||||
|
||||
To extend this module:
|
||||
|
||||
1. Add new agents using `create-agent` workflow
|
||||
2. Add new workflows using `create-workflow` workflow
|
||||
3. Update the installer configuration if needed
|
||||
4. Test thoroughly
|
||||
|
||||
## Requirements
|
||||
|
||||
- BMAD Method version 6.0.0 or higher
|
||||
- [Any specific dependencies]
|
||||
|
||||
## Author
|
||||
|
||||
Created by {user_name} on [creation date]
|
||||
|
||||
## License
|
||||
|
||||
[Add license information if applicable]
|
||||
|
||||
---
|
||||
|
||||
## Module Details
|
||||
|
||||
**Module Code:** {module_name}
|
||||
**Category:** {module_category}
|
||||
**Type:** {module_type}
|
||||
**Version:** 1.0.0
|
||||
|
||||
**Last Updated:** [current date]
|
||||
|
||||
````
|
||||
|
||||
### 3. Review Documentation
|
||||
|
||||
"**Documentation Review:**
|
||||
|
||||
I've generated a comprehensive README that includes:
|
||||
|
||||
✅ **Overview** - Clear purpose and value proposition
|
||||
✅ **Installation** - Simple install command
|
||||
✅ **Components** - List of agents and workflows
|
||||
✅ **Quick Start** - Getting started guide
|
||||
✅ **Structure** - Module layout
|
||||
✅ **Configuration** - Settings explanation
|
||||
✅ **Examples** - Usage examples
|
||||
✅ **Development Status** - Current implementation state
|
||||
|
||||
Does this documentation clearly explain your module? Is there anything you'd like to add or modify?"
|
||||
|
||||
### 4. Handle Documentation Updates
|
||||
|
||||
Update based on user feedback
|
||||
"Common additions:
|
||||
- API documentation
|
||||
- Troubleshooting section
|
||||
- FAQ
|
||||
- Screenshots or diagrams
|
||||
- Video tutorials
|
||||
- Changelog"
|
||||
|
||||
### 5. Document Documentation Creation
|
||||
|
||||
Update module-plan.md with documentation section:
|
||||
|
||||
```markdown
|
||||
## Documentation
|
||||
|
||||
### README.md Created
|
||||
- Location: {custom_module_location}/{module_name}/README.md
|
||||
- Sections: [list of sections included]
|
||||
- Status: Complete
|
||||
|
||||
### Content Highlights
|
||||
- Clear installation instructions
|
||||
- Component overview
|
||||
- Quick start guide
|
||||
- Configuration details
|
||||
- Usage examples
|
||||
- Development status
|
||||
|
||||
### Updates Made
|
||||
- [List any customizations or additions]
|
||||
````
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask} to improve documentation clarity
|
||||
- IF P: Execute {partyModeWorkflow} to get input on user experience
|
||||
- IF C: Save documentation info to module-plan.md, add step-09-documentation to the end of the stepsCompleted array in frontmatter, then load nextStepFile
|
||||
- IF Any other comments or queries: help user respond then redisplay menu
|
||||
|
||||
#### 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 then end with display again of the menu options
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- README.md fully populated with all sections
|
||||
- Content accurately reflects module structure
|
||||
- Installation instructions clear and correct
|
||||
- Examples provide helpful guidance
|
||||
- Development status honestly represented
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Leaving placeholder content in README
|
||||
- Not updating with actual module details
|
||||
- Missing critical sections (installation, usage)
|
||||
- Misrepresenting implementation status
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and documentation info is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5, 6, 7, 8, 9], will you then load, read entire file, then execute `{nextStepFile}` to begin roadmap generation.
|
||||
336
src/modules/bmb/workflows/create-module/steps/step-10-roadmap.md
Normal file
336
src/modules/bmb/workflows/create-module/steps/step-10-roadmap.md
Normal file
@@ -0,0 +1,336 @@
|
||||
---
|
||||
installed_path: '{project-root}/{bmad_folder}/bmb/workflows/create-module'
|
||||
nextStepFile: '{installed_path}/steps/step-11-validate.md'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
moduleTodoFile: '{custom_module_location}/{module_name}/TODO.md'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 10: Generate Development Roadmap
|
||||
|
||||
## 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 Module Architect and Project Planner
|
||||
- ✅ 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 development planning, user brings their module vision
|
||||
- ✅ Maintain collaborative, forward-looking tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on creating actionable roadmap and TODO
|
||||
- 🚫 FORBIDDEN to create actual components
|
||||
- 💬 Prioritize tasks for successful launch
|
||||
- 🚫 FORBIDDEN to set time estimates
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Use component status to determine next steps
|
||||
- 💾 Create clear TODO.md with actionable items
|
||||
- 📖 Add "step-10-roadmap" to stepsCompleted array` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All module information from previous steps
|
||||
- Current implementation status
|
||||
- Focus on planning, not implementation
|
||||
- Avoid time-based estimates
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To create a development roadmap and TODO list that guides the next steps for completing the module.
|
||||
|
||||
## ROADMAP GENERATION PROCESS:
|
||||
|
||||
### 1. Review Current Status
|
||||
|
||||
"Let's create a development roadmap for your {module_display_name} module.
|
||||
|
||||
**Current Status Summary:**
|
||||
|
||||
- ✅ Module structure created
|
||||
- ✅ Installer configured
|
||||
- [Agent Status]
|
||||
- [Workflow Status]
|
||||
- [Documentation Status]
|
||||
|
||||
This roadmap will help you prioritize what to work on next."
|
||||
|
||||
### 2. Create Development Phases
|
||||
|
||||
"**Development Phases:**
|
||||
|
||||
I'll organize the remaining work into logical phases to ensure a successful module launch."
|
||||
|
||||
### 3. Generate TODO.md
|
||||
|
||||
Create file: {custom_module_location}/{module_name}/TODO.md
|
||||
|
||||
````markdown
|
||||
# {module_display_name} Development Roadmap
|
||||
|
||||
## Phase 1: Core Components (MVP)
|
||||
|
||||
### Agents
|
||||
|
||||
- [ ] Implement [Agent 1 Name]
|
||||
- Use: `workflow create-agent`
|
||||
- Reference: module-plan.md for requirements
|
||||
- Priority: High
|
||||
|
||||
- [ ] Implement [Agent 2 Name]
|
||||
- Use: `workflow create-agent`
|
||||
- Reference: module-plan.md for requirements
|
||||
- Priority: High
|
||||
|
||||
### Workflows
|
||||
|
||||
- [ ] Implement [Workflow 1 Name]
|
||||
- Use: `workflow create-workflow`
|
||||
- Input: workflows/[workflow-1]/workflow-plan.md
|
||||
- Priority: High
|
||||
|
||||
- [ ] Implement [Workflow 2 Name]
|
||||
- Use: `workflow create-workflow`
|
||||
- Input: workflows/[workflow-2]/workflow-plan.md
|
||||
- Priority: Medium
|
||||
|
||||
### Integration
|
||||
|
||||
- [ ] Test agent-workflow integration
|
||||
- [ ] Update agent menus (remove TODO flags)
|
||||
- [ ] Validate configuration fields work correctly
|
||||
|
||||
## Phase 2: Enhanced Features
|
||||
|
||||
### Additional Components
|
||||
|
||||
- [ ] [Additional Agent 1]
|
||||
- Priority: Medium
|
||||
|
||||
- [ ] [Additional Workflow 1]
|
||||
- Priority: Low
|
||||
|
||||
### Improvements
|
||||
|
||||
- [ ] Add error handling
|
||||
- [ ] Implement validation
|
||||
- [ ] Optimize performance
|
||||
- [ ] Add logging
|
||||
|
||||
## Phase 3: Polish and Launch
|
||||
|
||||
### Testing
|
||||
|
||||
- [ ] Unit test all agents
|
||||
- [ ] Integration test workflows
|
||||
- [ ] Test installer in clean project
|
||||
- [ ] Test with sample data
|
||||
|
||||
### Documentation
|
||||
|
||||
- [ ] Add detailed API docs
|
||||
- [ ] Create video tutorials
|
||||
- [ ] Write troubleshooting guide
|
||||
- [ ] Add FAQ section
|
||||
|
||||
### Release
|
||||
|
||||
- [ ] Version bump to 1.0.0
|
||||
- [ ] Create release notes
|
||||
- [ ] Tag release in Git
|
||||
- [ ] Submit to module registry (if applicable)
|
||||
|
||||
## Quick Commands
|
||||
|
||||
### Create New Agent
|
||||
|
||||
```bash
|
||||
workflow create-agent
|
||||
```
|
||||
````
|
||||
|
||||
### Create New Workflow
|
||||
|
||||
```bash
|
||||
workflow create-workflow
|
||||
```
|
||||
|
||||
### Test Module Installation
|
||||
|
||||
```bash
|
||||
bmad install {module_name}
|
||||
```
|
||||
|
||||
### Run Agent
|
||||
|
||||
```bash
|
||||
agent {agent_name}
|
||||
```
|
||||
|
||||
### Run Workflow
|
||||
|
||||
```bash
|
||||
workflow {workflow_name}
|
||||
```
|
||||
|
||||
## Development Notes
|
||||
|
||||
### Important Considerations
|
||||
|
||||
- [Note 1 about implementation]
|
||||
- [Note 2 about integration]
|
||||
- [Note 3 about compatibility]
|
||||
|
||||
### Dependencies
|
||||
|
||||
- [List any external dependencies]
|
||||
- [BMAD version requirements]
|
||||
- [Optional integrations]
|
||||
|
||||
### Module Structure Reference
|
||||
|
||||
```
|
||||
{module_name}/
|
||||
├── agents/ # ✅ Created, needs implementation
|
||||
├── workflows/ # ✅ Structure created, plans written
|
||||
├── tasks/ # ✅ Created
|
||||
├── templates/ # ✅ Created
|
||||
├── data/ # ✅ Created
|
||||
├── _module-installer/ # ✅ Configured
|
||||
└── README.md # ✅ Complete
|
||||
```
|
||||
|
||||
## Completion Criteria
|
||||
|
||||
The module is complete when:
|
||||
|
||||
- [ ] All Phase 1 items are done
|
||||
- [ ] Installation works smoothly
|
||||
- [ ] Documentation covers all features
|
||||
- [ ] Sample usage produces expected results
|
||||
|
||||
---
|
||||
|
||||
Created: [current date]
|
||||
Last Updated: [current date]
|
||||
|
||||
````
|
||||
|
||||
### 4. Prioritize Immediate Next Steps
|
||||
|
||||
"**Immediate Next Steps (This Week):**
|
||||
|
||||
Based on your module's needs, I recommend starting with:
|
||||
|
||||
1. **[Most important agent]** - Core functionality
|
||||
2. **[Most important workflow]** - Primary user journey
|
||||
3. **[Integration task]** - Ensure components work together
|
||||
|
||||
**Which of these would you like to tackle first?**"
|
||||
|
||||
### 5. Provide Development Guidance
|
||||
|
||||
"**Development Tips:**
|
||||
|
||||
1. **Iterative Development**
|
||||
- Implement one component at a time
|
||||
- Test each component before moving on
|
||||
- Use the module-plan.md as your guide
|
||||
|
||||
2. **Testing Strategy**
|
||||
- Test in a clean project
|
||||
- Verify installation works
|
||||
- Check all menu options function
|
||||
|
||||
3. **Documentation Updates**
|
||||
- Update README.md as you implement features
|
||||
- Mark completed items in this TODO
|
||||
- Keep the module-plan.md in sync
|
||||
|
||||
4. **Getting Help**
|
||||
- Use BMAD documentation for patterns
|
||||
- Reference example modules
|
||||
- Ask for help when stuck"
|
||||
|
||||
### 6. Document Roadmap Creation
|
||||
|
||||
Update module-plan.md with roadmap section:
|
||||
|
||||
```markdown
|
||||
## Development Roadmap
|
||||
|
||||
### TODO.md Created
|
||||
- Location: {custom_module_location}/{module_name}/TODO.md
|
||||
- Phases defined: 3
|
||||
- Immediate tasks prioritized
|
||||
|
||||
### Next Steps Priority Order
|
||||
1. [Priority 1]
|
||||
2. [Priority 2]
|
||||
3. [Priority 3]
|
||||
|
||||
### Quick Reference Commands
|
||||
- `workflow create-agent` - Create new agents
|
||||
- `workflow create-workflow` - Create new workflows
|
||||
- `bmad install {module_name}` - Test installation
|
||||
|
||||
### Development Notes
|
||||
- [Key implementation notes]
|
||||
- [Testing recommendations]
|
||||
- [Integration considerations]
|
||||
````
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask} to explore development approaches
|
||||
- IF P: Execute {partyModeWorkflow} to get creative input on implementation
|
||||
- IF C: Save roadmap info to module-plan.md, add step-10-roadmap to the end of the stepsCompleted array in frontmatter, then load nextStepFile
|
||||
- IF Any other comments or queries: help user respond then redisplay menu
|
||||
|
||||
#### 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 then end with display again of the menu options
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- TODO.md created with clear phases
|
||||
- Tasks prioritized by importance
|
||||
- Quick reference commands included
|
||||
- Development guidance provided
|
||||
- Actionable next steps identified
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not creating TODO.md file
|
||||
- Including time estimates
|
||||
- Not prioritizing tasks effectively
|
||||
- Missing essential development commands
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and roadmap info is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], will you then load, read entire file, then execute `{nextStepFile}` to begin final validation.
|
||||
@@ -0,0 +1,335 @@
|
||||
---
|
||||
workflowFile: '{installed_path}/workflow.md'
|
||||
modulePlanFile: '{custom_module_location}/{module_name}/module-plan-{module_name}.md'
|
||||
validationChecklist: '{installed_path}/validation.md'
|
||||
advancedElicitationTask: '{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml'
|
||||
partyModeWorkflow: '{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 11: Validate and Finalize Module
|
||||
|
||||
## 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 Module Architect and Quality Assurance 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 validation patterns, user brings their module knowledge
|
||||
- ✅ Maintain collaborative, thorough tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on validation and quality checks
|
||||
- 🚫 FORBIDDEN to modify core structure at this stage
|
||||
- 💬 Present findings clearly with recommendations
|
||||
- 🚫 FORBIDDEN to skip validation steps
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Run validation checklist systematically
|
||||
- 💾 Document validation results
|
||||
- 📖 Append "step-11-validate" to stepsCompleted array` before completing
|
||||
- 🚫 FORBIDDEN to mark as complete without validation
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Module fully created with all components
|
||||
- Focus on validation, not new creation
|
||||
- Use validation checklist for systematic review
|
||||
- Ensure BMAD compliance
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To validate the completed module structure, ensure all components are properly configured, and provide next steps for testing and deployment.
|
||||
|
||||
## VALIDATION PROCESS:
|
||||
|
||||
### 1. Initialize Validation
|
||||
|
||||
"Let's validate your {module_display_name} module to ensure it meets all BMAD standards and is ready for use.
|
||||
|
||||
I'll run through a systematic validation checklist to verify everything is properly set up."
|
||||
|
||||
### 2. Structure Validation
|
||||
|
||||
"**1. Module Structure Check**"
|
||||
|
||||
Validate module directory structure
|
||||
|
||||
```
|
||||
Expected Structure:
|
||||
{module_name}/
|
||||
├── agents/ [✅/❌]
|
||||
├── workflows/ [✅/❌]
|
||||
├── tasks/ [✅/❌]
|
||||
├── templates/ [✅/❌]
|
||||
├── data/ [✅/❌]
|
||||
├── _module-installer/ [✅/❌]
|
||||
│ ├── install-config.yaml [✅/❌]
|
||||
│ └── installer.js [✅/N/A]
|
||||
└── README.md [✅/❌]
|
||||
```
|
||||
|
||||
**Results:**
|
||||
|
||||
- [List validation results for each item]
|
||||
|
||||
### 3. Configuration Validation
|
||||
|
||||
"**2. Configuration Files Check**"
|
||||
|
||||
**Install Configuration:**
|
||||
Validate install-config.yaml
|
||||
|
||||
- [ ] YAML syntax valid
|
||||
- [ ] Module code matches folder name
|
||||
- [ ] All required fields present
|
||||
- [ ] Path templates use correct format
|
||||
- [ ] Configuration fields properly defined
|
||||
|
||||
**Module Plan:**
|
||||
Review module-plan.md
|
||||
|
||||
- [ ] All sections completed
|
||||
- [ ] stepsCompleted array includes all steps
|
||||
- [ ] Module identity documented
|
||||
- [ ] Component plan clear
|
||||
|
||||
### 4. Component Validation
|
||||
|
||||
"**3. Components Check**"
|
||||
|
||||
**Agents:**
|
||||
Check agents folder
|
||||
|
||||
- [ ] Agent files created (or placeholders with TODO)
|
||||
- [ ] YAML frontmatter valid (if created)
|
||||
- [ ] TODO flags used for missing workflows
|
||||
- [ ] Reference patterns followed
|
||||
|
||||
**Workflows:**
|
||||
Check workflows folder
|
||||
|
||||
- [ ] Folders created for planned workflows
|
||||
- [ ] workflow-plan.md files created (or placeholders)
|
||||
- [ ] README.md in each workflow folder
|
||||
- [ ] Plans include all required sections
|
||||
|
||||
### 5. Documentation Validation
|
||||
|
||||
"**4. Documentation Check**"
|
||||
|
||||
**README.md:**
|
||||
Review README.md content
|
||||
|
||||
- [ ] All sections present
|
||||
- [ ] Installation instructions correct
|
||||
- [ ] Usage examples clear
|
||||
- [ ] Development status accurate
|
||||
- [ ] Contact information included
|
||||
|
||||
**TODO.md:**
|
||||
Review TODO.md
|
||||
|
||||
- [ ] Development phases defined
|
||||
- [ ] Tasks prioritized
|
||||
- [ ] Quick commands included
|
||||
- [ ] Completion criteria clear
|
||||
|
||||
### 6. Integration Validation
|
||||
|
||||
"**5. Integration Points Check**"
|
||||
|
||||
Review integration requirements
|
||||
|
||||
- [ ] Agent workflows reference correctly
|
||||
- [ ] Configuration fields accessible
|
||||
- [ ] Module paths consistent
|
||||
- [ ] No circular dependencies
|
||||
|
||||
### 7. Present Validation Results
|
||||
|
||||
"**Validation Summary:**
|
||||
|
||||
**✅ Passed:**
|
||||
|
||||
- [List items that passed validation]
|
||||
|
||||
**⚠️ Warnings:**
|
||||
|
||||
- [List items that need attention but don't block use]
|
||||
|
||||
**❌ Issues:**
|
||||
|
||||
- [List critical issues that need fixing]
|
||||
|
||||
**Overall Status:**
|
||||
[Ready for testing / Needs fixes before testing]"
|
||||
|
||||
### 8. Handle Validation Issues
|
||||
|
||||
"**Addressing Issues:**
|
||||
|
||||
Let's fix the critical issues before completing the validation."
|
||||
|
||||
For each issue:
|
||||
|
||||
1. **Explain the issue** clearly
|
||||
2. **Show how to fix** it
|
||||
3. **Make the fix** if user approves
|
||||
4. **Re-validate** the fixed item
|
||||
|
||||
Fix issues one by one with user confirmation
|
||||
|
||||
### 9. Final Module Summary
|
||||
|
||||
"**Module Creation Complete!**
|
||||
|
||||
**Module Summary:**
|
||||
|
||||
- **Name:** {module_display_name}
|
||||
- **Code:** {module_name}
|
||||
- **Location:** {custom_module_location}/{module_name}
|
||||
- **Type:** {module_type}
|
||||
- **Status:** Ready for testing
|
||||
|
||||
**Created Components:**
|
||||
|
||||
- [agent_count] agents ([created] created, [planned-created] planned)
|
||||
- [workflow_count] workflows (plans created)
|
||||
- [task_count] tasks
|
||||
- Complete installer configuration
|
||||
- Comprehensive documentation
|
||||
|
||||
### 10. Next Steps Guidance
|
||||
|
||||
"**Your Next Steps:**
|
||||
|
||||
1. **Test the Installation:**
|
||||
|
||||
```bash
|
||||
cd [test-project]
|
||||
bmad install {module_name}
|
||||
```
|
||||
|
||||
2. **Implement Components:**
|
||||
- Follow TODO.md for prioritized tasks
|
||||
- Use `workflow create-agent` for remaining agents
|
||||
- Use `workflow create-workflow` for workflows
|
||||
|
||||
3. **Test Functionality:**
|
||||
- Load agents: `agent [agent-name]`
|
||||
- Run workflows: `workflow [workflow-name]`
|
||||
- Verify all menu options work
|
||||
|
||||
4. **Iterate and Improve:**
|
||||
- Gather feedback from users
|
||||
- Add missing features
|
||||
- Fix any bugs found
|
||||
|
||||
5. **Share Your Module:**
|
||||
- Document improvements in README.md
|
||||
- Consider submitting to BMAD registry
|
||||
- Share with the community"
|
||||
|
||||
### 11. Document Validation
|
||||
|
||||
Create validation summary in module-plan.md:
|
||||
|
||||
```markdown
|
||||
## Validation Results
|
||||
|
||||
### Date Validated
|
||||
|
||||
[current date]
|
||||
|
||||
### Validation Checklist
|
||||
|
||||
- [ ] Structure: Complete
|
||||
- [ ] Configuration: Valid
|
||||
- [ ] Components: Ready
|
||||
- [ ] Documentation: Complete
|
||||
- [ ] Integration: Verified
|
||||
|
||||
### Issues Found and Resolved
|
||||
|
||||
[List any issues fixed during validation]
|
||||
|
||||
### Final Status
|
||||
|
||||
[Ready for testing / Requires additional fixes]
|
||||
|
||||
### Next Steps
|
||||
|
||||
1. [First next step]
|
||||
2. [Second next step]
|
||||
3. [Third next step]
|
||||
```
|
||||
|
||||
### 12. Complete Workflow
|
||||
|
||||
Mark workflow as complete:
|
||||
Update module-plan.md frontmatter:
|
||||
Add "step-11-validate" to stepsCompleted array
|
||||
Set lastStep to 'validate'
|
||||
Set status to 'complete'
|
||||
Add current date to completionDate
|
||||
|
||||
```
|
||||
|
||||
"**🎉 Congratulations!**
|
||||
|
||||
Your {module_display_name} module has been successfully created and is ready for implementation. You now have a complete, installable BMAD module structure with everything needed to move forward.
|
||||
|
||||
Would you like me to help you with anything else?"
|
||||
|
||||
### 13. Final MENU OPTIONS
|
||||
|
||||
Display: **Module Creation Complete!** [A] Advanced Elicitation [P] Party Mode [C] Exit
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml for reflection on process
|
||||
- IF P: Execute {project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md to celebrate completion
|
||||
- IF C: Mark as complete and exit gracefully
|
||||
- IF Any other comments or queries: help user respond then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- This is the final step - workflow complete
|
||||
- User can ask questions or exit
|
||||
- Always respond helpfully to final queries
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All validation checks performed
|
||||
- Issues identified and resolved
|
||||
- Module marked as complete
|
||||
- Clear next steps provided
|
||||
- User satisfied with results
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping validation checks
|
||||
- Not documenting validation results
|
||||
- Marking as complete with critical issues
|
||||
- Not providing next steps guidance
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
WHEN validation is complete, all issues resolved (or documented), and module-plan.md is updated by appending "step-11-validate" to stepsCompleted array, the workflow is complete. Present final summary and allow user to exit or ask final questions.
|
||||
```
|
||||
@@ -0,0 +1,317 @@
|
||||
# TEMPLATE
|
||||
|
||||
the template to use has comments to help guide generation are are not meant to be in the final agent output
|
||||
|
||||
## Agent Template to use
|
||||
|
||||
### Hybrid Agent (Can have prompts, sidecar memory, AND workflows)
|
||||
|
||||
```yaml
|
||||
agent:
|
||||
metadata:
|
||||
name: '{person-name}'
|
||||
title: '{agent-title}'
|
||||
icon: '{agent-icon}'
|
||||
module: '{module}'
|
||||
persona:
|
||||
role: '{agent-role}'
|
||||
identity: |
|
||||
{agent-identity - multi-line description}
|
||||
communication_style: |
|
||||
{communication-style - multi-line description}
|
||||
principles:
|
||||
- '{agent-principle-1}'
|
||||
- '{agent-principle-2}'
|
||||
- '{agent-principle-3}'
|
||||
- '{agent-principle-N}'
|
||||
|
||||
# Optional: Only include if agent needs memory/persistence
|
||||
critical_actions:
|
||||
- 'Load COMPLETE file {agent-folder}/[agent-name]-sidecar/memories.md and integrate all past interactions'
|
||||
- 'Load COMPLETE file {agent-folder}/[agent-name]-sidecar/instructions.md and follow ALL protocols'
|
||||
- 'ONLY read/write files in {agent-folder}/[agent-name]-sidecar/ - this is our private workspace'
|
||||
|
||||
# Optional: Embedded prompts for common interactions
|
||||
prompts:
|
||||
- id: 'core-function'
|
||||
content: |
|
||||
<instructions>
|
||||
Main interaction pattern for this agent
|
||||
</instructions>
|
||||
|
||||
{Detailed prompt content}
|
||||
|
||||
- id: 'quick-task'
|
||||
content: |
|
||||
<instructions>
|
||||
Quick, common task the agent performs
|
||||
</instructions>
|
||||
|
||||
{Prompt for quick task}
|
||||
|
||||
menu:
|
||||
# Always include chat/party mode
|
||||
- multi: '[CH] Chat with the agent or [SPM] Start Party Mode'
|
||||
triggers:
|
||||
- party-mode:
|
||||
input: SPM or fuzzy match start party mode
|
||||
route: '{project-root}/{bmad_folder}/core/workflows/edit-agent/workflow.md'
|
||||
data: what is being discussed or suggested with the command
|
||||
type: exec
|
||||
- expert-chat:
|
||||
input: CH or fuzzy match validate agent
|
||||
action: agent responds as expert based on its personal to converse
|
||||
type: action
|
||||
|
||||
# Group related functions
|
||||
- multi: '[CF] Core Function [QT] Quick Task'
|
||||
triggers:
|
||||
- core-function:
|
||||
input: CF or fuzzy match core function
|
||||
action: '#core-function'
|
||||
type: action
|
||||
- quick-task:
|
||||
input: QT or fuzzy match quick task
|
||||
action: '#quick-task'
|
||||
type: action
|
||||
|
||||
# Individual prompts
|
||||
- trigger: 'analyze'
|
||||
action: 'Perform deep analysis based on my expertise'
|
||||
description: 'Analyze situation 🧠'
|
||||
type: action
|
||||
|
||||
# Workflow for complex processes
|
||||
- trigger: 'generate-report'
|
||||
route: '{project-root}/{bmad_folder}/{custom_module}/workflows/report-gen/workflow.md'
|
||||
description: 'Generate detailed report 📊'
|
||||
|
||||
# Exec with internal prompt reference
|
||||
- trigger: 'brainstorm'
|
||||
route: '#brainstorm-session'
|
||||
description: 'Brainstorm ideas 💡'
|
||||
type: exec
|
||||
```
|
||||
|
||||
## Sidecar Folder Structure
|
||||
|
||||
When creating expert agents in modules, create a sidecar folder:
|
||||
|
||||
```
|
||||
{custom_module_location}/{module_name}/agents/[agent-name]-sidecar/
|
||||
├── memories.md # Persistent memory across sessions
|
||||
├── instructions.md # Agent-specific protocols
|
||||
├── insights.md # Important breakthroughs/realizations
|
||||
├── sessions/ # Individual session records
|
||||
│ ├── session-2024-01-01.md
|
||||
│ └── session-2024-01-02.md
|
||||
└── patterns.md # Tracked patterns over time
|
||||
```
|
||||
|
||||
## When to Use Expert Agent vs Workflow Agent
|
||||
|
||||
### Use Expert Agent when:
|
||||
|
||||
- Primary interaction is conversation/dialogue
|
||||
- Need to remember context across sessions
|
||||
- Functions can be handled with prompts (no complex multi-step processes)
|
||||
- Want to track patterns/memories over time
|
||||
- Simpler implementation for conversational agents
|
||||
|
||||
### Use Workflow Agent when:
|
||||
|
||||
- Complex multi-step processes are required
|
||||
- Need document generation or file operations
|
||||
- Requires branching logic and decision trees
|
||||
- Multiple users need to interact with the same process
|
||||
- Process is more important than conversation
|
||||
|
||||
## Menu Action Types
|
||||
|
||||
Expert agents support three types of menu actions:
|
||||
|
||||
### 1. **Inline Actions** (Direct commands)
|
||||
|
||||
```yaml
|
||||
- trigger: 'save-insight'
|
||||
action: 'Document this insight in {agent-folder}/[agent-name]-sidecar/insights.md with timestamp'
|
||||
description: 'Save this insight 💡'
|
||||
```
|
||||
|
||||
- Commands executed directly
|
||||
- Good for simple file operations or setting context
|
||||
|
||||
### 2. **Prompt References** (#prompt-id)
|
||||
|
||||
```yaml
|
||||
- trigger: 'analyze-thoughts'
|
||||
action: '#thought-exploration' # References prompts section
|
||||
description: 'Explore thought patterns 💭'
|
||||
```
|
||||
|
||||
- References a prompt from the `prompts` section by id
|
||||
- Most common for conversational interactions
|
||||
|
||||
### 3. **Workflow Routes** (for complex processes)
|
||||
|
||||
```yaml
|
||||
- trigger: 'generate-report'
|
||||
route: '{project-root}/{bmad_folder}/{custom_module}/workflows/report-gen/workflow.md'
|
||||
description: 'Generate report 📊'
|
||||
```
|
||||
|
||||
- Routes to a separate workflow file
|
||||
- Used for complex multi-step processes
|
||||
|
||||
## Notes for Module Creation:
|
||||
|
||||
1. **File Paths**:
|
||||
- Agent files go in: `{custom_module_location}/{module_name}/agents/[agent-name].yaml`
|
||||
- Sidecar folders go in: `{custom_module_location}/{module_name}/agents/[agent-name]-sidecar/`
|
||||
|
||||
2. **Variable Usage**:
|
||||
- `{agent-folder}` resolves to the agents folder within your module
|
||||
- `{bmad_folder}` resolves to .bmad
|
||||
- `{custom_module}` resolves to custom/src/modules
|
||||
- `{module}` is your module code/name
|
||||
|
||||
3. **Creating Sidecar Structure**:
|
||||
- When agent is created, also create the sidecar folder
|
||||
- Initialize with empty files: memories.md, instructions.md
|
||||
- Create sessions/ subfolder
|
||||
- These files are automatically loaded due to critical_actions
|
||||
|
||||
4. **Choosing Menu Actions**:
|
||||
- Use **inline actions** for simple commands (save, load, set context)
|
||||
- Use **prompt references** for conversational flows
|
||||
- Use **workflow routes** for complex processes needing multiple steps
|
||||
|
||||
# Example Module Generated Agent
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
name: Caravaggio
|
||||
title: Visual Communication + Presentation Expert
|
||||
icon: 🎨
|
||||
module: cis
|
||||
|
||||
persona:
|
||||
role: Visual Communication Expert + Presentation Designer + Educator
|
||||
identity: |
|
||||
Master presentation designer who's dissected thousands of successful presentations—from viral YouTube explainers to funded pitch decks to TED talks. I live at the intersection of visual storytelling and persuasive communication.
|
||||
communication_style: |
|
||||
Constant sarcastic wit and experimental flair. Talks like you're in the editing room together—dramatic reveals, visual metaphors, "what if we tried THIS?!" energy. Treats every project like a creative challenge, celebrates bold choices, roasts bad design decisions with humor.
|
||||
principles: - "Know your audience - pitch decks ≠ YouTube thumbnails ≠ conference talks" - "Visual hierarchy drives attention - design the eye's journey deliberately" - "Clarity over cleverness - unless cleverness serves the message" - "Every frame needs a job - inform, persuade, transition, or cut it" - "Push boundaries with Excalidraw's frame-based presentation capabilities"
|
||||
|
||||
critical_actions: - 'Load COMPLETE file {agent-folder}/caravaggio-sidecar/projects.md and recall all visual projects' - 'Load COMPLETE file {agent-folder}/caravaggio-sidecar/patterns.md and remember design patterns' - 'ONLY read/write files in {agent-folder}/caravaggio-sidecar/ - my creative studio'
|
||||
|
||||
prompts: - id: 'design-critique'
|
||||
content: |
|
||||
<instructions>
|
||||
Analyze the visual design with my signature dramatic flair
|
||||
</instructions>
|
||||
|
||||
Alright, let me see what we've got here. *leans in closer*
|
||||
|
||||
First impression: Is this making me shout "BRAVO!" or "BARF!"?
|
||||
|
||||
Visual hierarchy scan: Where's my eye landing first? Second? Is it a deliberate journey or visual chaos?
|
||||
|
||||
The good stuff: What's working? What's making me grin?
|
||||
|
||||
The facepalm moments: Where are we losing impact? What's confusing the message?
|
||||
|
||||
My "WHAT IF WE TRIED THIS?!": [Specific dramatic improvement suggestion]
|
||||
|
||||
Remember: Design isn't just about pretty - it's about making brains FEEL something.
|
||||
|
||||
- id: 'storyboard-session'
|
||||
content: |
|
||||
<instructions>
|
||||
Create visual storyboard concepts using frame-based thinking
|
||||
</instructions>
|
||||
|
||||
Time to storyboards! Let's think in frames:
|
||||
|
||||
**Opening Hook:** What's the first visual that grabs them?
|
||||
**The Turn:** Where do we shift perspective?
|
||||
**The Reveal:** What's the money shot?
|
||||
**The Close:** What image sticks with them?
|
||||
|
||||
For each frame:
|
||||
- Visual: What do they SEE?
|
||||
- Text: What do they READ?
|
||||
- Emotion: What do they FEEL?
|
||||
|
||||
Remember: Each frame is a scene in your visual story. Make it COUNT!
|
||||
|
||||
- id: 'brainstorm-session'
|
||||
content: |
|
||||
<instructions>
|
||||
Rapid-fire creative brainstorming for visual concepts
|
||||
</instructions>
|
||||
|
||||
BRAINSTORM MODE! 🔥
|
||||
|
||||
Give me three wild ideas:
|
||||
1. The safe but solid option
|
||||
2. The "ooh, interesting" middle ground
|
||||
3. The "are you crazy? LET'S DO IT!" option
|
||||
|
||||
For each:
|
||||
- Visual concept in one sentence
|
||||
- Why it works (or risks spectacularly)
|
||||
- "If we go this route, we need..."
|
||||
|
||||
Let's push some boundaries! What's the most unexpected way to show this?
|
||||
|
||||
menu: # Core interactions - multi: "[CH] Chat with Caravaggio or [SPM] Start Party Mode"
|
||||
triggers: - party-mode:
|
||||
input: SPM or fuzzy match start party mode
|
||||
route: "{project-root}/{bmad_folder}/core/workflows/edit-agent/workflow.md"
|
||||
data: what's being discussed, plus custom party agents if specified
|
||||
type: exec - expert-chat:
|
||||
input: CH or fuzzy match validate agent
|
||||
action: agent responds as expert based on its personal to converse
|
||||
type: action
|
||||
|
||||
# Design services group
|
||||
- multi: "[DC] Design Critique [SB] Storyboard"
|
||||
triggers:
|
||||
- design-critique:
|
||||
input: DC or fuzzy match design critique
|
||||
route: '#design-critique'
|
||||
description: 'Ruthless design analysis 🎭'
|
||||
type: exec
|
||||
- storyboard:
|
||||
input: SB or fuzzy match storyboard
|
||||
route: '#storyboard-session'
|
||||
description: 'Visual story frames 🎬'
|
||||
type: exec
|
||||
|
||||
# Quick actions
|
||||
- trigger: 'analyze'
|
||||
action: 'Quick visual analysis with my signature bluntness'
|
||||
description: 'Quick visual take 🎯'
|
||||
type: action
|
||||
|
||||
- trigger: 'brainstorm'
|
||||
action: '#brainstorm-session'
|
||||
description: 'Creative storm 💡'
|
||||
type: action
|
||||
|
||||
# Document workflows for complex processes
|
||||
- multi: "[PD] Pitch Deck [EX] Explainer Video"
|
||||
triggers:
|
||||
- pitch-deck:
|
||||
input: PD or fuzzy match pitch deck
|
||||
route: "{project-root}/{bmad_folder}/{custom_module}/workflows/pitch-deck/workflow.md"
|
||||
description: 'Investor pitch deck 📈'
|
||||
- explainer:
|
||||
input: EX or fuzzy match explainer
|
||||
route: "{project-root}/{bmad_folder}/{custom_module}/workflows/explainer/workflow.md"
|
||||
description: 'Video explainer 🎥'
|
||||
|
||||
- trigger: 'save-project'
|
||||
action: 'Document this project concept in {agent-folder}/caravaggio-sidecar/projects.md with sketches and notes'
|
||||
description: 'Save project 💾'
|
||||
@@ -0,0 +1,53 @@
|
||||
# {module_display_name} Module Configuration
|
||||
# This file defines installation questions and module configuration values
|
||||
|
||||
code: "${module_name}" # e.g., my-module
|
||||
name: "{module_display_name}"
|
||||
default_selected: false
|
||||
|
||||
# Welcome message shown during installation
|
||||
prompt:
|
||||
- "Thank you for choosing {module_display_name}!"
|
||||
- "{module_purpose}"
|
||||
# Core config values are automatically inherited from installer:
|
||||
## user_name
|
||||
## communication_language
|
||||
## document_output_language
|
||||
## output_folder
|
||||
|
||||
# ============================================================================
|
||||
# CONFIGURATION FIELDS
|
||||
# ============================================================================
|
||||
# Each field can be:
|
||||
# 1. INTERACTIVE (has 'prompt' - asks user during installation)
|
||||
# 2. STATIC (no 'prompt' - just uses 'result' value)
|
||||
# ============================================================================
|
||||
|
||||
# Example configurations (replace with actual planned fields):
|
||||
|
||||
# INTERACTIVE text input:
|
||||
# output_path:
|
||||
# prompt: "Where should {module_name} save outputs?"
|
||||
# default: "output/{module_name}"
|
||||
# result: "{project-root}/{value}"
|
||||
|
||||
# INTERACTIVE single-select:
|
||||
# detail_level:
|
||||
# prompt: "How detailed should outputs be?"
|
||||
# default: "standard"
|
||||
# result: "{value}"
|
||||
# single-select:
|
||||
# - value: "minimal"
|
||||
# label: "Minimal - Brief summaries only"
|
||||
# - value: "standard"
|
||||
# label: "Standard - Balanced detail"
|
||||
# - value: "detailed"
|
||||
# label: "Detailed - Comprehensive information"
|
||||
|
||||
# STATIC value:
|
||||
# module_version:
|
||||
# result: "1.0.0"
|
||||
|
||||
# STATIC path:
|
||||
# data_path:
|
||||
# result: "{project-root}/{bmad_folder}/{module_name}/data"
|
||||
@@ -0,0 +1,47 @@
|
||||
/**
|
||||
* {module_display_name} Module Installer
|
||||
* Custom installation logic
|
||||
*/
|
||||
|
||||
/**
|
||||
* @param {Object} options - Installation options
|
||||
* @param {string} options.projectRoot - Project root directory
|
||||
* @param {Object} options.config - Module configuration from install-config.yaml
|
||||
* @param {Array} options.installedIDEs - List of IDE codes being configured
|
||||
* @param {Object} options.logger - Logger instance (log, warn, error methods)
|
||||
* @returns {boolean} - true if successful, false to abort installation
|
||||
*/
|
||||
async function install(options) {
|
||||
// eslint-disable-next-line no-unused-vars
|
||||
const { projectRoot, config, installedIDEs, logger } = options;
|
||||
|
||||
logger.log('Installing {module_display_name}...');
|
||||
|
||||
try {
|
||||
// TODO: Add your custom installation logic here
|
||||
|
||||
// Example: Create data directory
|
||||
// const fs = require('fs');
|
||||
// const dataPath = config.data_path;
|
||||
// if (!fs.existsSync(dataPath)) {
|
||||
// fs.mkdirSync(dataPath, { recursive: true });
|
||||
// logger.log(`Created data directory: ${dataPath}`);
|
||||
// }
|
||||
|
||||
// Example: Initialize configuration file
|
||||
// const configPath = path.join(projectRoot, config.config_file);
|
||||
// fs.writeFileSync(configPath, JSON.stringify({
|
||||
// initialized: new Date().toISOString(),
|
||||
// version: config.module_version
|
||||
// }, null, 2));
|
||||
|
||||
logger.log('{module_display_name} installation complete!');
|
||||
return true;
|
||||
} catch (error) {
|
||||
logger.error(`Installation failed: ${error.message}`);
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
// eslint-disable-next-line unicorn/prefer-module
|
||||
module.exports = { install };
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
stepsCompleted: []
|
||||
---
|
||||
|
||||
# Module Plan {module name}
|
||||
@@ -0,0 +1,23 @@
|
||||
# Workflow Plan Template
|
||||
|
||||
Use this template when creating workflow plans in step-07-workflows.md
|
||||
|
||||
## Template Structure
|
||||
|
||||
Copy the content from step-07-workflows.md when creating workflow plans. The template is embedded in the step file as a code block under "Workflow plan template".
|
||||
|
||||
## Usage
|
||||
|
||||
1. Navigate to the workflow folder
|
||||
2. Create workflow-plan.md
|
||||
3. Use the template structure from step-07-workflows.md
|
||||
4. Fill in details specific to your workflow
|
||||
|
||||
## Required Sections
|
||||
|
||||
- Purpose
|
||||
- Requirements (User Inputs, Prerequisites, Dependencies)
|
||||
- Proposed Steps
|
||||
- Expected Outputs
|
||||
- Integration Points
|
||||
- Implementation Notes
|
||||
126
src/modules/bmb/workflows/create-module/validation.md
Normal file
126
src/modules/bmb/workflows/create-module/validation.md
Normal file
@@ -0,0 +1,126 @@
|
||||
# Create Module Workflow Validation Checklist
|
||||
|
||||
This document provides the validation criteria used in step-11-validate.md to ensure module quality and BMAD compliance.
|
||||
|
||||
## Structure Validation
|
||||
|
||||
### Required Directories
|
||||
|
||||
- [ ] agents/ - Agent definition files
|
||||
- [ ] workflows/ - Workflow folders
|
||||
- [ ] tasks/ - Task files (if needed)
|
||||
- [ ] templates/ - Shared templates
|
||||
- [ ] data/ - Module data
|
||||
- [ ] \_module-installer/ - Installation config
|
||||
- [ ] README.md - Module documentation
|
||||
|
||||
### Required Files in \_module-installer/
|
||||
|
||||
- [ ] install-config.yaml - Installation configuration
|
||||
- [ ] installer.js - Custom logic (if needed)
|
||||
|
||||
## Configuration Validation
|
||||
|
||||
### install-config.yaml
|
||||
|
||||
- [ ] Valid YAML syntax
|
||||
- [ ] Module code matches folder name
|
||||
- [ ] Name field present
|
||||
- [ ] Prompt array with welcome messages
|
||||
- [ ] Configuration fields properly defined
|
||||
- [ ] Result templates use correct placeholders
|
||||
|
||||
### Module Plan
|
||||
|
||||
- [ ] All sections completed
|
||||
- [ ] Module identity documented
|
||||
- [ ] Component plan clear
|
||||
- [ ] Configuration plan documented
|
||||
|
||||
## Component Validation
|
||||
|
||||
### Agents
|
||||
|
||||
- [ ] Files created in agents/ folder
|
||||
- [ ] YAML frontmatter valid (for created agents)
|
||||
- [ ] TODO flags used for non-existent workflows
|
||||
- [ ] Menu items follow BMAD patterns
|
||||
- [ ] Placeholder files contain TODO notes
|
||||
|
||||
### Workflows
|
||||
|
||||
- [ ] Folders created for each planned workflow
|
||||
- [ ] workflow-plan.md in each folder
|
||||
- [ ] README.md in each workflow folder
|
||||
- [ ] Plans include all required sections
|
||||
- [ ] Placeholder READMEs created for unplanned workflows
|
||||
|
||||
## Documentation Validation
|
||||
|
||||
### README.md
|
||||
|
||||
- [ ] Module name and purpose
|
||||
- [ ] Installation instructions
|
||||
- [ ] Components section
|
||||
- [ ] Quick start guide
|
||||
- [ ] Module structure diagram
|
||||
- [ ] Configuration section
|
||||
- [ ] Usage examples
|
||||
- [ ] Development status
|
||||
- [ ] Author information
|
||||
|
||||
### TODO.md
|
||||
|
||||
- [ ] Development phases defined
|
||||
- [ ] Tasks prioritized
|
||||
- [ ] Quick commands included
|
||||
- [ ] Completion criteria defined
|
||||
|
||||
## Integration Validation
|
||||
|
||||
### Path Consistency
|
||||
|
||||
- [ ] All paths use correct template format
|
||||
- [ ] Module code consistent throughout
|
||||
- [ ] No hardcoded paths
|
||||
- [ ] Cross-references correct
|
||||
|
||||
### Agent-Workflow Integration
|
||||
|
||||
- [ ] Agents reference correct workflows
|
||||
- [ ] TODO flags used appropriately
|
||||
- [ ] No circular dependencies
|
||||
- [ ] Clear integration points
|
||||
|
||||
## BMAD Compliance
|
||||
|
||||
### Standards
|
||||
|
||||
- [ ] Follows BMAD module structure
|
||||
- [ ] Uses BMAD installation patterns
|
||||
- [ ] Agent files follow BMAD format
|
||||
- [ ] Workflow plans follow BMAD patterns
|
||||
|
||||
### Best Practices
|
||||
|
||||
- [ ] Clear naming conventions
|
||||
- [ ] Proper documentation
|
||||
- [ ] Version control ready
|
||||
- [ ] Installable via bmad install
|
||||
|
||||
## Final Checklist
|
||||
|
||||
### Before Marking Complete
|
||||
|
||||
- [ ] All validation items checked
|
||||
- [ ] Critical issues resolved
|
||||
- [ ] Module plan updated with final status
|
||||
- [ ] stepsCompleted includes all 11 steps
|
||||
- [ ] User satisfied with result
|
||||
|
||||
### Ready for Testing
|
||||
|
||||
- [ ] Installation should work
|
||||
- [ ] Documentation accurate
|
||||
- [ ] Structure complete
|
||||
- [ ] Next steps clear
|
||||
55
src/modules/bmb/workflows/create-module/workflow.md
Normal file
55
src/modules/bmb/workflows/create-module/workflow.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: create-module
|
||||
description: 'Interactive workflow to build complete BMAD modules with agents, workflows, and installation infrastructure'
|
||||
web_bundle: true
|
||||
installed_path: '{project-root}/{bmad_folder}/bmb/workflows/create-module'
|
||||
---
|
||||
|
||||
# Create Module Workflow
|
||||
|
||||
**Goal:** To guide users through creating complete, installable BMAD modules with proper structure, agents, workflow plans, and documentation.
|
||||
|
||||
**Your Role:** In addition to your name, communication_style, and persona, you are also a Module Architect and BMAD Systems Specialist collaborating with module creators. This is a partnership, not a client-vendor relationship. You bring expertise in BMAD architecture, component design, and installation patterns, while the user brings their domain knowledge and specific module requirements. Work together as equals.
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
|
||||
- **Just-In-Time Loading**: Only 1 current step file will be loaded, read, and executed to completion - 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. Module Configuration Loading
|
||||
|
||||
Load and read full config from {project-root}/{bmad_folder}/bmb/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`, `custom_module_location`
|
||||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
Load, read the full file and then execute {installed_path}/steps/step-01-init.md to begin the workflow.
|
||||
@@ -39,11 +39,14 @@ agent:
|
||||
workflow: "{project-root}/{bmad_folder}/bmm/workflows/document-project/workflow.yaml"
|
||||
description: Document your existing project (optional, but recommended for existing brownfield project efforts)
|
||||
|
||||
- trigger: party-mode
|
||||
exec: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.md"
|
||||
description: Bring the whole team in to chat with other expert agents from the party
|
||||
|
||||
- trigger: advanced-elicitation
|
||||
exec: "{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml"
|
||||
description: Advanced elicitation techniques to challenge the LLM to get better results
|
||||
web-only: true
|
||||
- multi: "[SPM] Start Party Mode (optionally suggest attendees and topic), [CH] Chat"
|
||||
triggers:
|
||||
- party-mode:
|
||||
- input: SPM or fuzzy match start party mode
|
||||
- route: "{project-root}/{bmad_folder}/core/workflows/edit-agent/workflow.md"
|
||||
- data: what is being discussed or suggested with the command, along with custom party custom agents if specified
|
||||
- type: exec
|
||||
- expert-chat:
|
||||
- input: CH or fuzzy match validate agent
|
||||
- action: agent responds as expert based on its personal to converse
|
||||
- type: action
|
||||
|
||||
@@ -139,6 +139,9 @@ Comprehensive documentation for all BMM workflows organized by phase:
|
||||
- Complete story lifecycle
|
||||
- One-story-at-a-time discipline
|
||||
|
||||
<<<<<<< Updated upstream
|
||||
<<<<<<< Updated upstream
|
||||
|
||||
- **[Testing & QA Workflows](./test-architecture.md)** - Comprehensive quality assurance (1,420 lines)
|
||||
- Test strategy, automation, quality gates
|
||||
- TEA agent and test healing
|
||||
@@ -146,6 +149,14 @@ Comprehensive documentation for all BMM workflows organized by phase:
|
||||
|
||||
**Total: 34 workflows documented across all phases**
|
||||
|
||||
=======
|
||||
|
||||
> > > > > > > Stashed changes
|
||||
|
||||
=======
|
||||
|
||||
> > > > > > > Stashed changes
|
||||
|
||||
### Advanced Workflow References
|
||||
|
||||
For detailed technical documentation on specific complex workflows:
|
||||
@@ -170,10 +181,21 @@ Quality assurance guidance:
|
||||
|
||||
<!-- Test Architect documentation to be added -->
|
||||
|
||||
<<<<<<< Updated upstream
|
||||
|
||||
<<<<<<< Updated upstream
|
||||
|
||||
- Test design workflows
|
||||
- Quality gates
|
||||
- Risk assessment
|
||||
- NFR validation
|
||||
- # NFR validation
|
||||
=======
|
||||
> > > > > > > Stashed changes
|
||||
- Test design workflows
|
||||
- Quality gates
|
||||
- Risk assessment
|
||||
- NFR validation
|
||||
> > > > > > > Stashed changes
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -725,6 +725,13 @@ flowchart TD
|
||||
- **[Quick Start Guide](./quick-start.md)** - Getting started with BMM
|
||||
- **[Glossary](./glossary.md)** - Key terminology
|
||||
- **[FAQ](./faq.md)** - Common questions
|
||||
<<<<<<< Updated upstream
|
||||
=======
|
||||
- **[Troubleshooting](./troubleshooting.md)** - Problem resolution
|
||||
<<<<<<< Updated upstream
|
||||
> > > > > > > # Stashed changes
|
||||
> > > > > > >
|
||||
> > > > > > > Stashed changes
|
||||
- **[Workflow Documentation](./README.md#-workflow-guides)** - Complete workflow reference
|
||||
|
||||
---
|
||||
@@ -739,7 +746,13 @@ flowchart TD
|
||||
|
||||
**Documentation:**
|
||||
|
||||
- [Test Architect Guide](./test-architecture.md) - Comprehensive testing strategy
|
||||
<<<<<<< Updated upstream
|
||||
<<<<<<< Updated upstream
|
||||
|
||||
- # [Test Architect Guide](./test-architecture.md) - Comprehensive testing strategy
|
||||
> > > > > > > # Stashed changes
|
||||
> > > > > > >
|
||||
> > > > > > > Stashed changes
|
||||
- [BMM Module README](../README.md) - Complete module and workflow reference
|
||||
|
||||
---
|
||||
|
||||
@@ -95,6 +95,20 @@ Game development equivalent of PRD, created by Game Designer agent for game proj
|
||||
|
||||
## Workflow and Phases
|
||||
|
||||
<<<<<<< Updated upstream
|
||||
|
||||
# <<<<<<< Updated upstream
|
||||
|
||||
=======
|
||||
|
||||
> > > > > > > Stashed changes
|
||||
|
||||
### Phase 0: Documentation (Prerequisite)
|
||||
|
||||
**Conditional phase for brownfield projects.** Creates comprehensive codebase documentation before planning. Only required if existing documentation is insufficient for AI agents.
|
||||
|
||||
> > > > > > > Stashed changes
|
||||
|
||||
### Phase 1: Analysis (Optional)
|
||||
|
||||
Discovery and research phase including brainstorming, research workflows, and product brief creation. Optional for Quick Flow, recommended for BMad Method, required for Enterprise Method.
|
||||
|
||||
652
src/modules/bmm/docs/quick-spec-flow.md
Normal file
652
src/modules/bmm/docs/quick-spec-flow.md
Normal file
@@ -0,0 +1,652 @@
|
||||
# BMad Quick Spec Flow
|
||||
|
||||
**Perfect for:** Bug fixes, small features, rapid prototyping, and quick enhancements
|
||||
|
||||
**Time to implementation:** Minutes, not hours
|
||||
|
||||
---
|
||||
|
||||
## What is Quick Spec Flow?
|
||||
|
||||
Quick Spec Flow is a **streamlined alternative** to the full BMad Method for Quick Flow track projects. Instead of going through Product Brief → PRD → Architecture, you go **straight to a context-aware technical specification** and start coding.
|
||||
|
||||
### When to Use Quick Spec Flow
|
||||
|
||||
✅ **Use Quick Flow track when:**
|
||||
|
||||
- Single bug fix or small enhancement
|
||||
- Small feature with clear scope (typically 1-15 stories)
|
||||
- Rapid prototyping or experimentation
|
||||
- Adding to existing brownfield codebase
|
||||
- You know exactly what you want to build
|
||||
|
||||
❌ **Use BMad Method or Enterprise tracks when:**
|
||||
|
||||
- Building new products or major features
|
||||
- Need stakeholder alignment
|
||||
- Complex multi-team coordination
|
||||
- Requires extensive planning and architecture
|
||||
|
||||
💡 **Not sure?** Run `workflow-init` to get a recommendation based on your project's needs!
|
||||
|
||||
---
|
||||
|
||||
## Quick Spec Flow Overview
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
START[Step 1: Run Tech-Spec Workflow]
|
||||
DETECT[Detects project stack<br/>package.json, requirements.txt, etc.]
|
||||
ANALYZE[Analyzes brownfield codebase<br/>if exists]
|
||||
TEST[Detects test frameworks<br/>and conventions]
|
||||
CONFIRM[Confirms conventions<br/>with you]
|
||||
GENERATE[Generates context-rich<br/>tech-spec]
|
||||
STORIES[Creates ready-to-implement<br/>stories]
|
||||
|
||||
OPTIONAL[Step 2: Optional<br/>Generate Story Context<br/>SM Agent<br/>For complex scenarios only]
|
||||
|
||||
IMPL[Step 3: Implement<br/>DEV Agent<br/>Code, test, commit]
|
||||
|
||||
DONE[DONE! 🚀]
|
||||
|
||||
START --> DETECT
|
||||
DETECT --> ANALYZE
|
||||
ANALYZE --> TEST
|
||||
TEST --> CONFIRM
|
||||
CONFIRM --> GENERATE
|
||||
GENERATE --> STORIES
|
||||
STORIES --> OPTIONAL
|
||||
OPTIONAL -.->|Optional| IMPL
|
||||
STORIES --> IMPL
|
||||
IMPL --> DONE
|
||||
|
||||
style START fill:#bfb,stroke:#333,stroke-width:2px
|
||||
style OPTIONAL fill:#ffb,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
|
||||
style IMPL fill:#bbf,stroke:#333,stroke-width:2px
|
||||
style DONE fill:#f9f,stroke:#333,stroke-width:3px
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Single Atomic Change
|
||||
|
||||
**Best for:** Bug fixes, single file changes, isolated improvements
|
||||
|
||||
### What You Get
|
||||
|
||||
1. **tech-spec.md** - Comprehensive technical specification with:
|
||||
- Problem statement and solution
|
||||
- Detected framework versions and dependencies
|
||||
- Brownfield code patterns (if applicable)
|
||||
- Existing test patterns to follow
|
||||
- Specific file paths to modify
|
||||
- Complete implementation guidance
|
||||
|
||||
2. **story-[slug].md** - Single user story ready for development
|
||||
|
||||
### Quick Spec Flow Commands
|
||||
|
||||
```bash
|
||||
# Start Quick Spec Flow (no workflow-init needed!)
|
||||
# Load PM agent and run tech-spec
|
||||
|
||||
# When complete, implement directly:
|
||||
# Load DEV agent and run dev-story
|
||||
```
|
||||
|
||||
### What Makes It Quick
|
||||
|
||||
- ✅ No Product Brief needed
|
||||
- ✅ No PRD needed
|
||||
- ✅ No Architecture doc needed
|
||||
- ✅ Auto-detects your stack
|
||||
- ✅ Auto-analyzes brownfield code
|
||||
- ✅ Auto-validates quality
|
||||
- ✅ Story context optional (tech-spec is comprehensive!)
|
||||
|
||||
### Example Single Change Scenarios
|
||||
|
||||
- "Fix the login validation bug"
|
||||
- "Add email field to user registration form"
|
||||
- "Update API endpoint to return additional field"
|
||||
- "Improve error handling in payment processing"
|
||||
|
||||
---
|
||||
|
||||
## Coherent Small Feature
|
||||
|
||||
**Best for:** Small features with 2-3 related user stories
|
||||
|
||||
### What You Get
|
||||
|
||||
1. **tech-spec.md** - Same comprehensive spec as single change projects
|
||||
2. **epics.md** - Epic organization with story breakdown
|
||||
3. **story-[epic-slug]-1.md** - First story
|
||||
4. **story-[epic-slug]-2.md** - Second story
|
||||
5. **story-[epic-slug]-3.md** - Third story (if needed)
|
||||
|
||||
### Quick Spec Flow Commands
|
||||
|
||||
```bash
|
||||
# Start Quick Spec Flow
|
||||
# Load PM agent and run tech-spec
|
||||
|
||||
# Optional: Organize stories as a sprint
|
||||
# Load SM agent and run sprint-planning
|
||||
|
||||
# Implement story-by-story:
|
||||
# Load DEV agent and run dev-story for each story
|
||||
```
|
||||
|
||||
### Story Sequencing
|
||||
|
||||
Stories are **automatically validated** to ensure proper sequence:
|
||||
|
||||
- ✅ No forward dependencies (Story 2 can't depend on Story 3)
|
||||
- ✅ Clear dependency documentation
|
||||
- ✅ Infrastructure → Features → Polish order
|
||||
- ✅ Backend → Frontend flow
|
||||
|
||||
### Example Small Feature Scenarios
|
||||
|
||||
- "Add OAuth social login (Google, GitHub, Twitter)"
|
||||
- "Build user profile page with avatar upload"
|
||||
- "Implement basic search with filters"
|
||||
- "Add dark mode toggle to application"
|
||||
|
||||
---
|
||||
|
||||
## Smart Context Discovery
|
||||
|
||||
Quick Spec Flow automatically discovers and uses:
|
||||
|
||||
### 1. Existing Documentation
|
||||
|
||||
- Product briefs (if they exist)
|
||||
- Research documents
|
||||
- `document-project` output (brownfield codebase map)
|
||||
|
||||
### 2. Project Stack
|
||||
|
||||
- **Node.js:** package.json → frameworks, dependencies, scripts, test framework
|
||||
- **Python:** requirements.txt, pyproject.toml → packages, tools
|
||||
- **Ruby:** Gemfile → gems and versions
|
||||
- **Java:** pom.xml, build.gradle → Maven/Gradle dependencies
|
||||
- **Go:** go.mod → modules
|
||||
- **Rust:** Cargo.toml → crates
|
||||
- **PHP:** composer.json → packages
|
||||
|
||||
### 3. Brownfield Code Patterns
|
||||
|
||||
- Directory structure and organization
|
||||
- Existing code patterns (class-based, functional, MVC)
|
||||
- Naming conventions (camelCase, snake_case, PascalCase)
|
||||
- Test frameworks and patterns
|
||||
- Code style (semicolons, quotes, indentation)
|
||||
- Linter/formatter configs
|
||||
- Error handling patterns
|
||||
- Logging conventions
|
||||
- Documentation style
|
||||
|
||||
### 4. Convention Confirmation
|
||||
|
||||
**IMPORTANT:** Quick Spec Flow detects your conventions and **asks for confirmation**:
|
||||
|
||||
```
|
||||
I've detected these conventions in your codebase:
|
||||
|
||||
Code Style:
|
||||
- ESLint with Airbnb config
|
||||
- Prettier with single quotes, 2-space indent
|
||||
- No semicolons
|
||||
|
||||
Test Patterns:
|
||||
- Jest test framework
|
||||
- .test.js file naming
|
||||
- expect() assertion style
|
||||
|
||||
Should I follow these existing conventions? (yes/no)
|
||||
```
|
||||
|
||||
**You decide:** Conform to existing patterns or establish new standards!
|
||||
|
||||
---
|
||||
|
||||
## Modern Best Practices via WebSearch
|
||||
|
||||
Quick Spec Flow stays current by using WebSearch when appropriate:
|
||||
|
||||
### For Greenfield Projects
|
||||
|
||||
- Searches for latest framework versions
|
||||
- Recommends official starter templates
|
||||
- Suggests modern best practices
|
||||
|
||||
### For Outdated Dependencies
|
||||
|
||||
- Detects if your dependencies are >2 years old
|
||||
- Searches for migration guides
|
||||
- Notes upgrade complexity
|
||||
|
||||
### Starter Template Recommendations
|
||||
|
||||
For greenfield projects, Quick Spec Flow recommends:
|
||||
|
||||
**React:**
|
||||
|
||||
- Vite (modern, fast)
|
||||
- Next.js (full-stack)
|
||||
|
||||
**Python:**
|
||||
|
||||
- cookiecutter templates
|
||||
- FastAPI starter
|
||||
|
||||
**Node.js:**
|
||||
|
||||
- NestJS CLI
|
||||
- express-generator
|
||||
|
||||
**Benefits:**
|
||||
|
||||
- ✅ Modern best practices baked in
|
||||
- ✅ Proper project structure
|
||||
- ✅ Build tooling configured
|
||||
- ✅ Testing framework set up
|
||||
- ✅ Faster time to first feature
|
||||
|
||||
---
|
||||
|
||||
## UX/UI Considerations
|
||||
|
||||
For user-facing changes, Quick Spec Flow captures:
|
||||
|
||||
- UI components affected (create vs modify)
|
||||
- UX flow changes (current vs new)
|
||||
- Responsive design needs (mobile, tablet, desktop)
|
||||
- Accessibility requirements:
|
||||
- Keyboard navigation
|
||||
- Screen reader compatibility
|
||||
- ARIA labels
|
||||
- Color contrast standards
|
||||
- User feedback patterns:
|
||||
- Loading states
|
||||
- Error messages
|
||||
- Success confirmations
|
||||
- Progress indicators
|
||||
|
||||
---
|
||||
|
||||
## Auto-Validation and Quality Assurance
|
||||
|
||||
Quick Spec Flow **automatically validates** everything:
|
||||
|
||||
### Tech-Spec Validation (Always Runs)
|
||||
|
||||
Checks:
|
||||
|
||||
- ✅ Context gathering completeness
|
||||
- ✅ Definitiveness (no "use X or Y" statements)
|
||||
- ✅ Brownfield integration quality
|
||||
- ✅ Stack alignment
|
||||
- ✅ Implementation readiness
|
||||
|
||||
Generates scores:
|
||||
|
||||
```
|
||||
✅ Validation Passed!
|
||||
- Context Gathering: Comprehensive
|
||||
- Definitiveness: All definitive
|
||||
- Brownfield Integration: Excellent
|
||||
- Stack Alignment: Perfect
|
||||
- Implementation Readiness: ✅ Ready
|
||||
```
|
||||
|
||||
### Story Validation (Multi-Story Features)
|
||||
|
||||
Checks:
|
||||
|
||||
- ✅ Story sequence (no forward dependencies!)
|
||||
- ✅ Acceptance criteria quality (specific, testable)
|
||||
- ✅ Completeness (all tech spec tasks covered)
|
||||
- ✅ Clear dependency documentation
|
||||
|
||||
**Auto-fixes issues if found!**
|
||||
|
||||
---
|
||||
|
||||
## Complete User Journey
|
||||
|
||||
### Scenario 1: Bug Fix (Single Change)
|
||||
|
||||
**Goal:** Fix login validation bug
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. **Start:** Load PM agent, say "I want to fix the login validation bug"
|
||||
2. **PM runs tech-spec workflow:**
|
||||
- Asks: "What problem are you solving?"
|
||||
- You explain the validation issue
|
||||
- Detects your Node.js stack (Express 4.18.2, Jest for testing)
|
||||
- Analyzes existing UserService code patterns
|
||||
- Asks: "Should I follow your existing conventions?" → You say yes
|
||||
- Generates tech-spec.md with specific file paths and patterns
|
||||
- Creates story-login-fix.md
|
||||
3. **Implement:** Load DEV agent, run `dev-story`
|
||||
- DEV reads tech-spec (has all context!)
|
||||
- Implements fix following existing patterns
|
||||
- Runs tests (following existing Jest patterns)
|
||||
- Done!
|
||||
|
||||
**Total time:** 15-30 minutes (mostly implementation)
|
||||
|
||||
---
|
||||
|
||||
### Scenario 2: Small Feature (Multi-Story)
|
||||
|
||||
**Goal:** Add OAuth social login (Google, GitHub)
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. **Start:** Load PM agent, say "I want to add OAuth social login"
|
||||
2. **PM runs tech-spec workflow:**
|
||||
- Asks about the feature scope
|
||||
- You specify: Google and GitHub OAuth
|
||||
- Detects your stack (Next.js 13.4, NextAuth.js already installed!)
|
||||
- Analyzes existing auth patterns
|
||||
- Confirms conventions with you
|
||||
- Generates:
|
||||
- tech-spec.md (comprehensive implementation guide)
|
||||
- epics.md (OAuth Integration epic)
|
||||
- story-oauth-1.md (Backend OAuth setup)
|
||||
- story-oauth-2.md (Frontend login buttons)
|
||||
3. **Optional Sprint Planning:** Load SM agent, run `sprint-planning`
|
||||
4. **Implement Story 1:**
|
||||
- Load DEV agent, run `dev-story` for story 1
|
||||
- DEV implements backend OAuth
|
||||
5. **Implement Story 2:**
|
||||
- DEV agent, run `dev-story` for story 2
|
||||
- DEV implements frontend
|
||||
- Done!
|
||||
|
||||
**Total time:** 1-3 hours (mostly implementation)
|
||||
|
||||
---
|
||||
|
||||
## Integration with Phase 4 Workflows
|
||||
|
||||
Quick Spec Flow works seamlessly with all Phase 4 implementation workflows:
|
||||
|
||||
### story-context (SM Agent)
|
||||
|
||||
- ✅ Recognizes tech-spec.md as authoritative source
|
||||
- ✅ Extracts context from tech-spec (replaces PRD)
|
||||
- ✅ Generates XML context for complex scenarios
|
||||
|
||||
### create-story (SM Agent)
|
||||
|
||||
- ✅ Can work with tech-spec.md instead of PRD
|
||||
- ✅ Uses epics.md from tech-spec workflow
|
||||
- ✅ Creates additional stories if needed
|
||||
|
||||
### sprint-planning (SM Agent)
|
||||
|
||||
- ✅ Works with epics.md from tech-spec
|
||||
- ✅ Organizes multi-story features for coordinated implementation
|
||||
- ✅ Tracks progress through sprint-status.yaml
|
||||
|
||||
### dev-story (DEV Agent)
|
||||
|
||||
- ✅ Reads stories generated by tech-spec
|
||||
- ✅ Uses tech-spec.md as comprehensive context
|
||||
- ✅ Implements following detected conventions
|
||||
|
||||
---
|
||||
|
||||
## Comparison: Quick Spec vs Full BMM
|
||||
|
||||
| Aspect | Quick Flow Track | BMad Method/Enterprise Tracks |
|
||||
| --------------------- | ---------------------------- | ---------------------------------- |
|
||||
| **Setup** | None (standalone) | workflow-init recommended |
|
||||
| **Planning Docs** | tech-spec.md only | Product Brief → PRD → Architecture |
|
||||
| **Time to Code** | Minutes | Hours to days |
|
||||
| **Best For** | Bug fixes, small features | New products, major features |
|
||||
| **Context Discovery** | Automatic | Manual + guided |
|
||||
| **Story Context** | Optional (tech-spec is rich) | Required (generated from PRD) |
|
||||
| **Validation** | Auto-validates everything | Manual validation steps |
|
||||
| **Brownfield** | Auto-analyzes and conforms | Manual documentation required |
|
||||
| **Conventions** | Auto-detects and confirms | Document in PRD/Architecture |
|
||||
|
||||
---
|
||||
|
||||
## When to Graduate from Quick Flow to BMad Method
|
||||
|
||||
Start with Quick Flow, but switch to BMad Method when:
|
||||
|
||||
- ❌ Project grows beyond initial scope
|
||||
- ❌ Multiple teams need coordination
|
||||
- ❌ Stakeholders need formal documentation
|
||||
- ❌ Product vision is unclear
|
||||
- ❌ Architectural decisions need deep analysis
|
||||
- ❌ Compliance/regulatory requirements exist
|
||||
|
||||
💡 **Tip:** You can always run `workflow-init` later to transition from Quick Flow to BMad Method!
|
||||
|
||||
---
|
||||
|
||||
## Quick Spec Flow - Key Benefits
|
||||
|
||||
### 🚀 **Speed**
|
||||
|
||||
- No Product Brief
|
||||
- No PRD
|
||||
- No Architecture doc
|
||||
- Straight to implementation
|
||||
|
||||
### 🧠 **Intelligence**
|
||||
|
||||
- Auto-detects stack
|
||||
- Auto-analyzes brownfield
|
||||
- Auto-validates quality
|
||||
- WebSearch for current info
|
||||
|
||||
### 📐 **Respect for Existing Code**
|
||||
|
||||
- Detects conventions
|
||||
- Asks for confirmation
|
||||
- Follows patterns
|
||||
- Adapts vs. changes
|
||||
|
||||
### ✅ **Quality**
|
||||
|
||||
- Auto-validation
|
||||
- Definitive decisions (no "or" statements)
|
||||
- Comprehensive context
|
||||
- Clear acceptance criteria
|
||||
|
||||
### 🎯 **Focus**
|
||||
|
||||
- Single atomic changes
|
||||
- Coherent small features
|
||||
- No scope creep
|
||||
- Fast iteration
|
||||
|
||||
---
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- BMad Method installed (`npx bmad-method install`)
|
||||
- Project directory with code (or empty for greenfield)
|
||||
|
||||
### Quick Start Commands
|
||||
|
||||
```bash
|
||||
# For a quick bug fix or small change:
|
||||
# 1. Load PM agent
|
||||
# 2. Say: "I want to [describe your change]"
|
||||
# 3. PM will ask if you want to run tech-spec
|
||||
# 4. Answer questions about your change
|
||||
# 5. Get tech-spec + story
|
||||
# 6. Load DEV agent and implement!
|
||||
|
||||
# For a small feature with multiple stories:
|
||||
# Same as above, but get epic + 2-3 stories
|
||||
# Optionally use SM sprint-planning to organize
|
||||
```
|
||||
|
||||
### No workflow-init Required!
|
||||
|
||||
Quick Spec Flow is **fully standalone**:
|
||||
|
||||
- Detects if it's a single change or multi-story feature
|
||||
- Asks for greenfield vs brownfield
|
||||
- Works without status file tracking
|
||||
- Perfect for rapid prototyping
|
||||
|
||||
---
|
||||
|
||||
## FAQ
|
||||
|
||||
### Q: Can I use Quick Spec Flow on an existing project?
|
||||
|
||||
**A:** Yes! It's perfect for brownfield projects. It will analyze your existing code, detect patterns, and ask if you want to follow them.
|
||||
|
||||
### Q: What if I don't have a package.json or requirements.txt?
|
||||
|
||||
**A:** Quick Spec Flow will work in greenfield mode, recommend starter templates, and use WebSearch for modern best practices.
|
||||
|
||||
### Q: Do I need to run workflow-init first?
|
||||
|
||||
**A:** No! Quick Spec Flow is standalone. But if you want guidance on which flow to use, workflow-init can help.
|
||||
|
||||
### Q: Can I use this for frontend changes?
|
||||
|
||||
**A:** Absolutely! Quick Spec Flow captures UX/UI considerations, component changes, and accessibility requirements.
|
||||
|
||||
### Q: What if my Quick Flow project grows?
|
||||
|
||||
**A:** No problem! You can always transition to BMad Method by running workflow-init and create-prd. Your tech-spec becomes input for the PRD.
|
||||
|
||||
### Q: Do I need story-context for every story?
|
||||
|
||||
**A:** Usually no! Tech-spec is comprehensive enough for most Quick Flow projects. Only use story-context for complex edge cases.
|
||||
|
||||
### Q: Can I skip validation?
|
||||
|
||||
**A:** No, validation always runs automatically. But it's fast and catches issues early!
|
||||
|
||||
### Q: Will it work with my team's code style?
|
||||
|
||||
**A:** Yes! It detects your conventions and asks for confirmation. You control whether to follow existing patterns or establish new ones.
|
||||
|
||||
---
|
||||
|
||||
## Tips and Best Practices
|
||||
|
||||
### 1. **Be Specific in Discovery**
|
||||
|
||||
When describing your change, provide specifics:
|
||||
|
||||
- ✅ "Fix email validation in UserService to allow plus-addressing"
|
||||
- ❌ "Fix validation bug"
|
||||
|
||||
### 2. **Trust the Convention Detection**
|
||||
|
||||
If it detects your patterns correctly, say yes! It's faster than establishing new conventions.
|
||||
|
||||
### 3. **Use WebSearch Recommendations for Greenfield**
|
||||
|
||||
Starter templates save hours of setup time. Let Quick Spec Flow find the best ones.
|
||||
|
||||
### 4. **Review the Auto-Validation**
|
||||
|
||||
When validation runs, read the scores. They tell you if your spec is production-ready.
|
||||
|
||||
### 5. **Story Context is Optional**
|
||||
|
||||
For single changes, try going directly to dev-story first. Only add story-context if you hit complexity.
|
||||
|
||||
### 6. **Keep Single Changes Truly Atomic**
|
||||
|
||||
If your "single change" needs 3+ files, it might be a multi-story feature. Let the workflow guide you.
|
||||
|
||||
### 7. **Validate Story Sequence for Multi-Story Features**
|
||||
|
||||
When you get multiple stories, check the dependency validation output. Proper sequence matters!
|
||||
|
||||
---
|
||||
|
||||
## Real-World Examples
|
||||
|
||||
### Example 1: Adding Logging (Single Change)
|
||||
|
||||
**Input:** "Add structured logging to payment processing"
|
||||
|
||||
**Tech-Spec Output:**
|
||||
|
||||
- Detected: winston 3.8.2 already in package.json
|
||||
- Analyzed: Existing services use winston with JSON format
|
||||
- Confirmed: Follow existing logging patterns
|
||||
- Generated: Specific file paths, log levels, format example
|
||||
- Story: Ready to implement in 1-2 hours
|
||||
|
||||
**Result:** Consistent logging added, following team patterns, no research needed.
|
||||
|
||||
---
|
||||
|
||||
### Example 2: Search Feature (Multi-Story)
|
||||
|
||||
**Input:** "Add search to product catalog with filters"
|
||||
|
||||
**Tech-Spec Output:**
|
||||
|
||||
- Detected: React 18.2.0, MUI component library, Express backend
|
||||
- Analyzed: Existing ProductList component patterns
|
||||
- Confirmed: Follow existing API and component structure
|
||||
- Generated:
|
||||
- Epic: Product Search Functionality
|
||||
- Story 1: Backend search API with filters
|
||||
- Story 2: Frontend search UI component
|
||||
- Auto-validated: Story 1 → Story 2 sequence correct
|
||||
|
||||
**Result:** Search feature implemented in 4-6 hours with proper architecture.
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
Quick Spec Flow is your **fast path from idea to implementation** for:
|
||||
|
||||
- 🐛 Bug fixes
|
||||
- ✨ Small features
|
||||
- 🚀 Rapid prototyping
|
||||
- 🔧 Quick enhancements
|
||||
|
||||
**Key Features:**
|
||||
|
||||
- Auto-detects your stack
|
||||
- Auto-analyzes brownfield code
|
||||
- Auto-validates quality
|
||||
- Respects existing conventions
|
||||
- Uses WebSearch for modern practices
|
||||
- Generates comprehensive tech-specs
|
||||
- Creates implementation-ready stories
|
||||
|
||||
**Time to code:** Minutes, not hours.
|
||||
|
||||
**Ready to try it?** Load the PM agent and say what you want to build! 🚀
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **Try it now:** Load PM agent and describe a small change
|
||||
- **Learn more:** See the [BMM Workflow Guides](./README.md#-workflow-guides) for comprehensive workflow documentation
|
||||
- **Need help deciding?** Run `workflow-init` to get a recommendation
|
||||
- **Have questions?** Join us on Discord: https://discord.gg/gk8jAdXWmj
|
||||
|
||||
---
|
||||
|
||||
_Quick Spec Flow - Because not every change needs a Product Brief._
|
||||
680
src/modules/bmm/docs/troubleshooting.md
Normal file
680
src/modules/bmm/docs/troubleshooting.md
Normal file
@@ -0,0 +1,680 @@
|
||||
# BMM Troubleshooting Guide
|
||||
|
||||
Common issues and solutions for the BMad Method Module.
|
||||
|
||||
---
|
||||
|
||||
## Quick Diagnosis
|
||||
|
||||
**Use this flowchart to find your issue:**
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
START{What's the problem?}
|
||||
|
||||
START -->|Can't get started| SETUP[Setup & Installation Issues]
|
||||
START -->|Wrong level detected| LEVEL[Level Detection Problems]
|
||||
START -->|Workflow not working| WORKFLOW[Workflow Issues]
|
||||
START -->|Agent lacks context| CONTEXT[Context & Documentation Issues]
|
||||
START -->|Implementation problems| IMPL[Implementation Issues]
|
||||
START -->|Files/paths wrong| FILES[File & Path Issues]
|
||||
|
||||
style START fill:#ffb,stroke:#333,stroke-width:2px
|
||||
style SETUP fill:#bfb,stroke:#333,stroke-width:2px
|
||||
style LEVEL fill:#bbf,stroke:#333,stroke-width:2px
|
||||
style WORKFLOW fill:#fbf,stroke:#333,stroke-width:2px
|
||||
style CONTEXT fill:#f9f,stroke:#333,stroke-width:2px
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Setup and Installation Issues](#setup-and-installation-issues)
|
||||
- [Level Detection Problems](#level-detection-problems)
|
||||
- [Workflow Issues](#workflow-issues)
|
||||
- [Context and Documentation Issues](#context-and-documentation-issues)
|
||||
- [Implementation Issues](#implementation-issues)
|
||||
- [File and Path Issues](#file-and-path-issues)
|
||||
- [Agent Behavior Issues](#agent-behavior-issues)
|
||||
- [Integration Issues (Brownfield)](#integration-issues-brownfield)
|
||||
|
||||
---
|
||||
|
||||
## Setup and Installation Issues
|
||||
|
||||
### Problem: BMM not found after installation
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- `bmad` command not recognized
|
||||
- Agent files not accessible
|
||||
- Workflows don't load
|
||||
|
||||
**Solution:**
|
||||
|
||||
```bash
|
||||
# Check if BMM is installed
|
||||
ls bmad/
|
||||
|
||||
# If not present, run installer
|
||||
npx bmad-method@alpha install
|
||||
|
||||
# For fresh install
|
||||
npx bmad-method@alpha install --skip-version-prompt
|
||||
```
|
||||
|
||||
### Problem: Agents don't have menu
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Load agent file but no menu appears
|
||||
- Agent doesn't respond to commands
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. Ensure you're loading the correct agent file path: `bmad/bmm/agents/[agent-name].md`
|
||||
2. Wait a few seconds for agent to initialize
|
||||
3. Try asking "show menu" or "help"
|
||||
4. Check IDE supports Markdown rendering with context
|
||||
5. For Claude Code: Ensure agent file is open in chat context
|
||||
|
||||
### Problem: Workflows not found
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Agent says workflow doesn't exist
|
||||
- Menu shows workflow but won't run
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. Check workflow exists: `ls bmad/bmm/workflows/`
|
||||
2. Verify agent has access to workflow (check agent's workflow list)
|
||||
3. Try using menu number instead of workflow name
|
||||
4. Restart chat with agent in fresh session
|
||||
|
||||
---
|
||||
|
||||
## Level Detection Problems
|
||||
|
||||
### Problem: workflow-init suggests wrong level
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Detects Level 3 but you only need Level 1
|
||||
- Suggests Level 1 but project is actually Level 2
|
||||
- Can't figure out appropriate level
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Override the suggestion** - workflow-init always asks for confirmation, just say "no" and choose correct level
|
||||
2. **Be specific in description** - Use level keywords when describing:
|
||||
- "fix bug" → Level 0
|
||||
- "add small feature" → Level 1
|
||||
- "build dashboard" → Level 2
|
||||
3. **Manual override** - You can always switch levels later if needed
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
workflow-init: "Level 3 project?"
|
||||
You: "No, this is just adding OAuth login - Level 1"
|
||||
workflow-init: "Got it, creating Level 1 workflow"
|
||||
```
|
||||
|
||||
### Problem: Project level unclear
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Between Level 1 and Level 2
|
||||
- Not sure if architecture needed
|
||||
- Story count uncertain
|
||||
|
||||
**Solution:**
|
||||
**When in doubt, start smaller:**
|
||||
|
||||
- Choose Level 1 instead of Level 2
|
||||
- You can always run `create-prd` later if needed
|
||||
- Level 1 is faster, less overhead
|
||||
- Easy to upgrade, hard to downgrade
|
||||
|
||||
**Decision criteria:**
|
||||
|
||||
- Single epic with related stories? → Level 1
|
||||
- Multiple independent epics? → Level 2
|
||||
- Need product-level planning? → Level 2
|
||||
- Just need technical plan? → Level 1
|
||||
|
||||
### Problem: Old planning docs influencing level detection
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Old Level 3 PRD in folder
|
||||
- Working on new Level 0 bug fix
|
||||
- workflow-init suggests Level 3
|
||||
|
||||
**Solution:**
|
||||
workflow-init asks: "Is this work in progress or previous effort?"
|
||||
|
||||
- Answer: "Previous effort"
|
||||
- Then describe your NEW work clearly
|
||||
- System will detect level based on NEW work, not old artifacts
|
||||
|
||||
---
|
||||
|
||||
## Workflow Issues
|
||||
|
||||
### Problem: Workflow fails or hangs
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Workflow starts but doesn't complete
|
||||
- Agent stops responding mid-workflow
|
||||
- Progress stalls
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Check context limits** - Start fresh chat for complex workflows
|
||||
2. **Verify prerequisites**:
|
||||
- Phase 2 needs Phase 1 complete (if used)
|
||||
- Phase 3 needs Phase 2 complete
|
||||
- Phase 4 needs Phase 3 complete (if Level 3-4)
|
||||
3. **Restart workflow** - Load agent in new chat and restart
|
||||
4. **Check status file** - Verify `bmm-workflow-status.md` or `sprint-status.yaml` is present and valid
|
||||
|
||||
### Problem: Agent says "workflow not found"
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Request workflow by name
|
||||
- Agent doesn't recognize it
|
||||
- Menu doesn't show workflow
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. Check spelling/format - Use exact workflow name or menu shortcut (*prd not *PRD)
|
||||
2. Verify agent has workflow:
|
||||
- PM agent: prd, tech-spec
|
||||
- Architect agent: create-architecture, validate-architecture
|
||||
- SM agent: sprint-planning, create-story, story-context
|
||||
3. Try menu number instead of name
|
||||
4. Check you're using correct agent for workflow
|
||||
|
||||
### Problem: Sprint-planning workflow fails
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Can't create sprint-status.yaml
|
||||
- Epics not extracted from files
|
||||
- Status file empty or incorrect
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Verify epic files exist**:
|
||||
- Level 1: tech-spec with epic
|
||||
- Level 2-4: epics.md or sharded epic files
|
||||
2. **Check file format**:
|
||||
- Epic files should be valid Markdown
|
||||
- Epic headers should be clear (## Epic Name)
|
||||
3. **Run in Phase 4 only** - Ensure Phase 2/3 complete first
|
||||
4. **Check file paths** - Epic files should be in correct output folder
|
||||
|
||||
### Problem: story-context generates empty or wrong context
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Context file created but has no useful content
|
||||
- Context doesn't reference existing code
|
||||
- Missing technical guidance
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Run epic-tech-context first** - story-context builds on epic context
|
||||
2. **Check story file exists** - Verify story was created by create-story
|
||||
3. **For brownfield**:
|
||||
- Ensure document-project was run
|
||||
- Verify docs/index.md exists with codebase context
|
||||
4. **Try regenerating** - Sometimes needs fresh attempt with more specific story details
|
||||
|
||||
---
|
||||
|
||||
## Context and Documentation Issues
|
||||
|
||||
### Problem: AI agents lack codebase understanding (Brownfield)
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Suggestions don't align with existing patterns
|
||||
- Ignores available components
|
||||
- Proposes approaches that conflict with architecture
|
||||
- Doesn't reference existing code
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Run document-project** - Critical for brownfield projects
|
||||
```
|
||||
Load Analyst agent → run document-project
|
||||
Choose scan level: Deep (recommended for PRD prep)
|
||||
```
|
||||
2. **Verify docs/index.md exists** - This is master entry point for AI agents
|
||||
3. **Check documentation completeness**:
|
||||
- Review generated docs/index.md
|
||||
- Ensure key systems are documented
|
||||
4. **Run deep-dive on specific areas** if needed
|
||||
|
||||
### Problem: Have documentation but agents can't find it
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- README.md, ARCHITECTURE.md exist
|
||||
- AI agents still ask questions answered in docs
|
||||
- No docs/index.md file
|
||||
|
||||
**Solution:**
|
||||
**Option 1: Quick fix (2-5min)**
|
||||
Run `index-docs` task:
|
||||
|
||||
- Located at `bmad/core/tasks/index-docs.xml`
|
||||
- Scans existing docs and generates index.md
|
||||
- Lightweight, just creates navigation
|
||||
|
||||
**Option 2: Comprehensive (10-30min)**
|
||||
Run document-project workflow:
|
||||
|
||||
- Discovers existing docs in Step 2
|
||||
- Generates NEW AI-friendly documentation from codebase
|
||||
- Creates index.md linking to BOTH existing and new docs
|
||||
|
||||
**Why this matters:** AI agents need structured entry point (index.md) to navigate docs efficiently.
|
||||
|
||||
### Problem: document-project takes too long
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Exhaustive scan running for hours
|
||||
- Impatient to start planning
|
||||
|
||||
**Solution:**
|
||||
**Choose appropriate scan level:**
|
||||
|
||||
- **Quick (2-5min)** - Pattern analysis, no source reading - Good for initial overview
|
||||
- **Deep (10-30min)** - Reads critical paths - **Recommended for most brownfield projects**
|
||||
- **Exhaustive (30-120min)** - Reads all files - Only for migration planning or complete understanding
|
||||
|
||||
For most brownfield projects, **Deep scan is sufficient**.
|
||||
|
||||
---
|
||||
|
||||
## Implementation Issues
|
||||
|
||||
### Problem: Existing tests breaking (Brownfield)
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Regression test failures
|
||||
- Previously working functionality broken
|
||||
- Integration tests failing
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Review changes against existing patterns**:
|
||||
- Check if new code follows existing conventions
|
||||
- Verify API contracts unchanged (unless intentionally versioned)
|
||||
2. **Run test-review workflow** (TEA agent):
|
||||
- Analyzes test coverage
|
||||
- Identifies regression risks
|
||||
- Suggests fixes
|
||||
3. **Add regression testing to DoD**:
|
||||
- All existing tests must pass
|
||||
- Add integration tests for new code
|
||||
4. **Consider feature flags** for gradual rollout
|
||||
|
||||
### Problem: Story takes much longer than estimated
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Story estimated 4 hours, took 12 hours
|
||||
- Acceptance criteria harder than expected
|
||||
- Hidden complexity discovered
|
||||
|
||||
**Solution:**
|
||||
**This is normal!** Estimates are estimates. To handle:
|
||||
|
||||
1. **Continue until DoD met** - Don't compromise quality
|
||||
2. **Document learnings in retrospective**:
|
||||
- What caused the overrun?
|
||||
- What should we watch for next time?
|
||||
3. **Consider splitting story** if it's truly two stories
|
||||
4. **Adjust future estimates** based on this data
|
||||
|
||||
**Don't stress about estimate accuracy** - use them for learning, not judgment.
|
||||
|
||||
### Problem: Integration points unclear
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Not sure how to connect new code to existing
|
||||
- Unsure which files to modify
|
||||
- Multiple possible integration approaches
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **For brownfield**:
|
||||
- Ensure document-project captured existing architecture
|
||||
- Review architecture docs before implementing
|
||||
2. **Check story-context** - Should document integration points
|
||||
3. **In tech-spec/architecture** - Explicitly document:
|
||||
- Which existing modules to modify
|
||||
- What APIs/services to integrate with
|
||||
- Data flow between new and existing code
|
||||
4. **Run integration-planning workflow** (Level 3-4):
|
||||
- Architect agent creates integration strategy
|
||||
|
||||
### Problem: Inconsistent patterns being introduced
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- New code style doesn't match existing
|
||||
- Different architectural approach
|
||||
- Not following team conventions
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Check convention detection** (Quick Spec Flow):
|
||||
- Should detect existing patterns
|
||||
- Asks for confirmation before proceeding
|
||||
2. **Review documentation** - Ensure document-project captured patterns
|
||||
3. **Use story-context** - Injects pattern guidance per story
|
||||
4. **Add to code-review checklist**:
|
||||
- Pattern adherence
|
||||
- Convention consistency
|
||||
- Style matching
|
||||
5. **Run retrospective** to identify pattern deviations early
|
||||
|
||||
---
|
||||
|
||||
## File and Path Issues
|
||||
|
||||
### Problem: Output files in wrong location
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- PRD created in wrong folder
|
||||
- Story files not where expected
|
||||
- Documentation scattered
|
||||
|
||||
**Solution:**
|
||||
Check `bmad/bmm/config.yaml` for configured paths:
|
||||
|
||||
```yaml
|
||||
output_folder: '{project-root}/docs'
|
||||
dev_story_location: '{project-root}/docs/stories'
|
||||
```
|
||||
|
||||
Default locations:
|
||||
|
||||
- Planning docs (PRD, epics, architecture): `{output_folder}/`
|
||||
- Stories: `{dev_story_location}/`
|
||||
- Status files: `{output_folder}/bmm-workflow-status.md`, `{output_folder}/sprint-status.yaml`
|
||||
|
||||
To change locations, edit config.yaml then re-run workflows.
|
||||
|
||||
### Problem: Can't find status file
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- workflow-status says no status file
|
||||
- Can't track progress
|
||||
- Lost place in workflow
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Check default location**: `docs/bmm-workflow-status.md`
|
||||
2. **If missing, reinitialize**:
|
||||
```
|
||||
Load Analyst agent → run workflow-init
|
||||
```
|
||||
3. **For Phase 4**: Look for `sprint-status.yaml` in same folder as PRD
|
||||
4. **Search for it**:
|
||||
```bash
|
||||
find . -name "bmm-workflow-status.md"
|
||||
find . -name "sprint-status.yaml"
|
||||
```
|
||||
|
||||
### Problem: Sprint-status.yaml not updating
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Workflows complete but status unchanged
|
||||
- Stories stuck in old status
|
||||
- Epic status not progressing
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Manual update required** - Most status changes are manual:
|
||||
```yaml
|
||||
stories:
|
||||
- id: epic-1-story-1
|
||||
status: done # Change this manually
|
||||
```
|
||||
2. **Some workflows auto-update**:
|
||||
- sprint-planning creates file
|
||||
- epic-tech-context changes epic to "contexted"
|
||||
- create-story changes story to "drafted"
|
||||
- story-context changes to "ready-for-dev"
|
||||
- dev-story may auto-update (check workflow)
|
||||
3. **Re-run sprint-planning** to resync if needed
|
||||
|
||||
---
|
||||
|
||||
## Agent Behavior Issues
|
||||
|
||||
### Problem: Agent provides vague or generic responses
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- "Use appropriate framework"
|
||||
- "Follow best practices"
|
||||
- Generic advice without specifics
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Provide more context** - Be specific in your description:
|
||||
- "Add OAuth using passport.js to Express server"
|
||||
- Not: "Add authentication"
|
||||
2. **For brownfield**:
|
||||
- Ensure document-project was run
|
||||
- Agent needs codebase context for specific advice
|
||||
3. **Reference existing docs**:
|
||||
- "Based on the existing auth system in UserService..."
|
||||
4. **Start fresh chat** - Context overload can cause generic responses
|
||||
|
||||
### Problem: Agent hallucinating or making up information
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- References files that don't exist
|
||||
- Suggests APIs that aren't in your stack
|
||||
- Creates imaginary requirements
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Use fresh chat** - Context overflow main cause of hallucinations
|
||||
2. **Provide concrete constraints**:
|
||||
- "We use Express 4.18.2, not Next.js"
|
||||
- "Our database is PostgreSQL, not MongoDB"
|
||||
3. **For brownfield**:
|
||||
- Document-project provides factual grounding
|
||||
- Agent sees actual code, not assumptions
|
||||
4. **Correct immediately**:
|
||||
- "No, we don't have UserService, we have AuthenticationModule"
|
||||
|
||||
### Problem: Agent won't follow instructions
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Ignores specific requests
|
||||
- Does something different than asked
|
||||
- Doesn't respect constraints
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Be more explicit** - Agents respond to clear, specific instructions:
|
||||
- "Use EXACTLY these three steps..."
|
||||
- "Do NOT include database migrations in this story"
|
||||
2. **Check agent capabilities** - Agent might not have access to requested workflow
|
||||
3. **Try different phrasing** - Rephrase request to be more direct
|
||||
4. **Use menu system** - Numbers are clearer than text commands
|
||||
|
||||
---
|
||||
|
||||
## Integration Issues (Brownfield)
|
||||
|
||||
### Problem: New code conflicts with existing architecture
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Integration approach doesn't fit existing structure
|
||||
- Would require major refactoring
|
||||
- Conflicts with established patterns
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Check if document-project was run** - Agents need architecture context
|
||||
2. **Review existing architecture docs**:
|
||||
- Read docs/architecture.md (from document-project)
|
||||
- Understand current system design
|
||||
3. **For Level 3-4**:
|
||||
- Run validate-architecture workflow before planning
|
||||
- Use integration-planning workflow
|
||||
4. **Explicitly document integration strategy** in architecture:
|
||||
- How new components fit existing structure
|
||||
- What modifications needed to existing code
|
||||
- Migration path if changing patterns
|
||||
|
||||
### Problem: Breaking changes to existing APIs
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Changing API breaks consumers
|
||||
- Downstream services affected
|
||||
- Need backward compatibility
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Identify all API consumers** (document-project should show this)
|
||||
2. **Plan versioning strategy**:
|
||||
- API v1 (existing) + v2 (new)
|
||||
- Deprecation timeline
|
||||
3. **Use feature flags** for gradual rollout
|
||||
4. **Document migration guide** for API consumers
|
||||
5. **Add to testing strategy**:
|
||||
- Existing consumers still work (v1)
|
||||
- New functionality works (v2)
|
||||
|
||||
### Problem: Data migration required
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Schema changes needed
|
||||
- Existing data needs transformation
|
||||
- Risk of data loss
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Create explicit migration strategy** in architecture:
|
||||
- Forward migration (old → new schema)
|
||||
- Rollback plan (new → old schema)
|
||||
- Data validation approach
|
||||
2. **Test migrations thoroughly**:
|
||||
- On copy of production data
|
||||
- Measure performance impact
|
||||
3. **Plan rollout**:
|
||||
- Staging environment first
|
||||
- Gradual production rollout
|
||||
- Monitoring for issues
|
||||
4. **Document in tech-spec/architecture**:
|
||||
- Migration scripts
|
||||
- Rollback procedures
|
||||
- Expected downtime
|
||||
|
||||
---
|
||||
|
||||
## Still Stuck?
|
||||
|
||||
### Getting More Help
|
||||
|
||||
If your issue isn't covered here:
|
||||
|
||||
1. **Check other documentation**:
|
||||
- [FAQ](./faq.md) - Common questions
|
||||
- [Glossary](./glossary.md) - Terminology
|
||||
- [Quick Start](./quick-start.md) - Basic usage
|
||||
- [Brownfield Guide](./brownfield-guide.md) - Existing codebases
|
||||
- [Scale Adaptive System](./scale-adaptive-system.md) - Understanding levels
|
||||
|
||||
2. **Community support**:
|
||||
- [Discord](https://discord.gg/gk8jAdXWmj) - #general-dev, #bugs-issues
|
||||
- Active community, fast responses
|
||||
- Share your specific situation
|
||||
|
||||
3. **Report bugs**:
|
||||
- [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)
|
||||
- Include version, steps to reproduce, expected vs actual behavior
|
||||
|
||||
4. **Video tutorials**:
|
||||
- [YouTube Channel](https://www.youtube.com/@BMadCode)
|
||||
- Visual walkthroughs of common workflows
|
||||
|
||||
---
|
||||
|
||||
## Common Error Messages
|
||||
|
||||
### "No workflow status file found"
|
||||
|
||||
**Cause:** Haven't run workflow-init yet
|
||||
**Fix:** Load Analyst agent → run workflow-init
|
||||
|
||||
### "Epic file not found"
|
||||
|
||||
**Cause:** PRD/epics not created, or wrong path
|
||||
**Fix:** Verify PRD/epics exist in output folder, check config.yaml paths
|
||||
|
||||
### "Story not in sprint-status.yaml"
|
||||
|
||||
**Cause:** Sprint-planning not run, or story file not created
|
||||
**Fix:** Run sprint-planning workflow, verify story files exist
|
||||
|
||||
### "Documentation insufficient for brownfield"
|
||||
|
||||
**Cause:** No docs/index.md or document-project not run
|
||||
**Fix:** Run document-project workflow with Deep scan
|
||||
|
||||
### "Level detection failed"
|
||||
|
||||
**Cause:** Ambiguous project description
|
||||
**Fix:** Be more specific, use level keywords (fix, feature, platform, etc.)
|
||||
|
||||
### "Context generation failed"
|
||||
|
||||
**Cause:** Missing prerequisites (epic context, story file, or docs)
|
||||
**Fix:** Verify epic-tech-context run, story file exists, docs present
|
||||
|
||||
---
|
||||
|
||||
## Prevention Tips
|
||||
|
||||
**Avoid common issues before they happen:**
|
||||
|
||||
1. ✅ **Always run document-project for brownfield** - Saves hours of context issues later
|
||||
2. ✅ **Use fresh chats for complex workflows** - Prevents hallucinations and context overflow
|
||||
3. ✅ **Verify files exist before running workflows** - Check PRD, epics, stories are present
|
||||
4. ✅ **Read agent menu before requesting workflows** - Confirm agent has the workflow
|
||||
5. ✅ **Start with smaller level if unsure** - Easy to upgrade (Level 1 → 2), hard to downgrade
|
||||
6. ✅ **Keep status files updated** - Manual updates when needed, don't let them drift
|
||||
7. ✅ **Run retrospectives after epics** - Catch issues early, improve next epic
|
||||
8. ✅ **Follow phase sequence** - Don't skip required phases (Phase 2 before 3, 3 before 4)
|
||||
|
||||
---
|
||||
|
||||
**Issue not listed?** Please [report it](https://github.com/bmad-code-org/BMAD-METHOD/issues) so we can add it to this guide!
|
||||
@@ -133,6 +133,7 @@ The `sprint-status.yaml` file is the single source of truth for all implementati
|
||||
### (BMad Method / Enterprise)
|
||||
|
||||
```
|
||||
<<<<<<< Updated upstream
|
||||
PRD (PM) → Architecture (Architect)
|
||||
→ create-epics-and-stories (PM) ← V6: After architecture!
|
||||
→ implementation-readiness (Architect)
|
||||
@@ -141,6 +142,144 @@ PRD (PM) → Architecture (Architect)
|
||||
→ story loop (SM/DEV)
|
||||
→ retrospective (SM)
|
||||
→ [Next Epic]
|
||||
=======
|
||||
Current Phase: 4 (Implementation)
|
||||
Current Epic: Epic 1 (Authentication)
|
||||
Current Sprint: Sprint 1
|
||||
|
||||
Next Story: Story 1.3 (Email Verification)
|
||||
Status: TODO
|
||||
Dependencies: Story 1.2 (DONE) ✅
|
||||
|
||||
**Recommendation:** Run `create-story` to generate Story 1.3
|
||||
|
||||
After create-story:
|
||||
1. Run story-context
|
||||
2. Run dev-story
|
||||
3. Run code-review
|
||||
4. Run story-done
|
||||
```
|
||||
|
||||
See: [workflow-status instructions](../workflows/workflow-status/instructions.md)
|
||||
|
||||
---
|
||||
|
||||
### document-project
|
||||
|
||||
**Purpose:** Analyze and document brownfield projects by scanning codebase, architecture, and patterns.
|
||||
|
||||
**Agent:** Analyst
|
||||
**Duration:** 1-3 hours
|
||||
**When to Use:** Brownfield projects without documentation
|
||||
|
||||
**How It Works:**
|
||||
|
||||
1. Scans codebase structure
|
||||
2. Identifies architecture patterns
|
||||
3. Documents technology stack
|
||||
4. Creates reference documentation
|
||||
5. Generates PRD-like document from existing code
|
||||
|
||||
**Output:** `project-documentation-{date}.md`
|
||||
|
||||
**When to Run:**
|
||||
|
||||
- Before starting work on legacy project
|
||||
- When inheriting undocumented codebase
|
||||
- Creating onboarding documentation
|
||||
|
||||
See: [document-project reference](./workflow-document-project-reference.md)
|
||||
|
||||
---
|
||||
|
||||
## Story Lifecycle Visualization
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ PHASE 4: IMPLEMENTATION (Iterative Story Lifecycle) │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌─────────────────┐
|
||||
│ Sprint Planning │ → Creates sprint-status.yaml
|
||||
└────────┬────────┘ Defines story queue
|
||||
│
|
||||
├──────────────────────────────────────────┐
|
||||
│ │
|
||||
▼ │
|
||||
┌─────────────────────┐ │
|
||||
│ Epic Tech Context │ → Optional per epic │
|
||||
│ (Once per epic) │ Provides technical │
|
||||
└─────────────────────┘ guidance │
|
||||
│ │
|
||||
▼ │
|
||||
┌─────────────────────────────────────────────────┤
|
||||
│ FOR EACH STORY IN QUEUE: │
|
||||
├─────────────────────────────────────────────────┤
|
||||
│ │
|
||||
▼ │
|
||||
┌─────────────────┐ │
|
||||
│ Create Story │ → Generates story file │
|
||||
│ (TODO → IN PROGRESS) │
|
||||
└────────┬────────┘ │
|
||||
│ │
|
||||
▼ │
|
||||
┌─────────────────┐ │
|
||||
│ Story Context │ → Assembles focused context │
|
||||
└────────┬────────┘ │
|
||||
│ │
|
||||
▼ │
|
||||
┌─────────────────┐ │
|
||||
│ Dev Story │ → Implements + tests │
|
||||
│ (IN PROGRESS) │ │
|
||||
└────────┬────────┘ │
|
||||
│ │
|
||||
▼ │
|
||||
┌─────────────────┐ │
|
||||
│ Code Review │ → Senior dev review │
|
||||
│ (IN PROGRESS → │ │
|
||||
│ READY FOR REVIEW) │
|
||||
└────────┬────────┘ │
|
||||
│ │
|
||||
┌────┴────┐ │
|
||||
│ Result? │ │
|
||||
└────┬────┘ │
|
||||
│ │
|
||||
┌────┼────────────────────┐ │
|
||||
│ │ │ │
|
||||
▼ ▼ ▼ │
|
||||
APPROVED APPROVED REQUEST │
|
||||
WITH COMMENTS CHANGES │
|
||||
│ │ │ │
|
||||
└─────────┴───────────────────┘ │
|
||||
│ │
|
||||
▼ │
|
||||
┌─────────────────┐ │
|
||||
│ Story Done │ → READY FOR REVIEW → DONE│
|
||||
└────────┬────────┘ │
|
||||
│ │
|
||||
├─────────────────────────────────────┘
|
||||
│ More stories?
|
||||
│
|
||||
▼
|
||||
┌────────────────┐
|
||||
│ Epic Complete? │
|
||||
└────────┬───────┘
|
||||
│
|
||||
┌────┼────┐
|
||||
│ │
|
||||
Yes No
|
||||
│ └──> Continue to next story
|
||||
│
|
||||
▼
|
||||
┌─────────────────┐
|
||||
│ Retrospective │ → Review epic, lessons learned
|
||||
└─────────────────┘
|
||||
│
|
||||
▼
|
||||
All epics done?
|
||||
│
|
||||
Yes → PROJECT COMPLETE
|
||||
>>>>>>> Stashed changes
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
85
src/modules/bmm/tasks/daily-standup.xml
Normal file
85
src/modules/bmm/tasks/daily-standup.xml
Normal file
@@ -0,0 +1,85 @@
|
||||
<task id="bmad/bmm/tasks/daily-standup.xml" name="Daily Standup">
|
||||
<llm critical="true">
|
||||
<i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
|
||||
<i>DO NOT skip steps or change the sequence</i>
|
||||
<i>HALT immediately when halt-conditions are met</i>
|
||||
<i>Each action tag within a step tag is a REQUIRED action to complete that step</i>
|
||||
<i>Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution</i>
|
||||
</llm>
|
||||
<flow>
|
||||
<step n="1" title="Project Context Discovery">
|
||||
<action>Check for stories folder at {project-root}{output_folder}/stories/</action>
|
||||
<action>Find current story by identifying highest numbered story file</action>
|
||||
<action>Read story status (In Progress, Ready for Review, etc.)</action>
|
||||
<action>Extract agent notes from Dev Agent Record, TEA Results, PO Notes sections</action>
|
||||
<action>Check for next story references from epics</action>
|
||||
<action>Identify blockers from story sections</action>
|
||||
</step>
|
||||
|
||||
<step n="2" title="Initialize Standup with Context">
|
||||
<output>
|
||||
🏃 DAILY STANDUP - Story-{{number}}: {{title}}
|
||||
|
||||
Current Sprint Status:
|
||||
- Active Story: story-{{number}} ({{status}} - {{percentage}}% complete)
|
||||
- Next in Queue: story-{{next-number}}: {{next-title}}
|
||||
- Blockers: {{blockers-from-story}}
|
||||
|
||||
Team assembled based on story participants:
|
||||
{{ List Agents from {project-root}/bmad/_cfg/agent-manifest.csv }}
|
||||
</output>
|
||||
</step>
|
||||
|
||||
<step n="3" title="Structured Standup Discussion">
|
||||
<action>Each agent provides three items referencing real story data</action>
|
||||
<action>What I see: Their perspective on current work, citing story sections (1-2 sentences)</action>
|
||||
<action>What concerns me: Issues from their domain or story blockers (1-2 sentences)</action>
|
||||
<action>What I suggest: Actionable recommendations for progress (1-2 sentences)</action>
|
||||
</step>
|
||||
|
||||
<step n="4" title="Create Standup Summary">
|
||||
<output>
|
||||
📋 STANDUP SUMMARY:
|
||||
Key Items from Story File:
|
||||
- {{completion-percentage}}% complete ({{tasks-complete}}/{{total-tasks}} tasks)
|
||||
- Blocker: {{main-blocker}}
|
||||
- Next: {{next-story-reference}}
|
||||
|
||||
Action Items:
|
||||
- {{agent}}: {{action-item}}
|
||||
- {{agent}}: {{action-item}}
|
||||
- {{agent}}: {{action-item}}
|
||||
|
||||
Need extended discussion? Use *party-mode for detailed breakout.
|
||||
</output>
|
||||
</step>
|
||||
</flow>
|
||||
|
||||
<agent-selection>
|
||||
<context type="prd-review">
|
||||
<i>Primary: Sarah (PO), Mary (Analyst), Winston (Architect)</i>
|
||||
<i>Secondary: Murat (TEA), James (Dev)</i>
|
||||
</context>
|
||||
<context type="story-planning">
|
||||
<i>Primary: Sarah (PO), Bob (SM), James (Dev)</i>
|
||||
<i>Secondary: Murat (TEA)</i>
|
||||
</context>
|
||||
<context type="validate-architecture">
|
||||
<i>Primary: Winston (Architect), James (Dev), Murat (TEA)</i>
|
||||
<i>Secondary: Sarah (PO)</i>
|
||||
</context>
|
||||
<context type="implementation">
|
||||
<i>Primary: James (Dev), Murat (TEA), Winston (Architect)</i>
|
||||
<i>Secondary: Sarah (PO)</i>
|
||||
</context>
|
||||
</agent-selection>
|
||||
|
||||
<llm critical="true">
|
||||
<i>This task extends party-mode with agile-specific structure</i>
|
||||
<i>Time-box responses (standup = brief)</i>
|
||||
<i>Focus on actionable items from real story data when available</i>
|
||||
<i>End with clear next steps</i>
|
||||
<i>No deep dives (suggest breakout if needed)</i>
|
||||
<i>If no stories folder detected, run general standup format</i>
|
||||
</llm>
|
||||
</task>
|
||||
Reference in New Issue
Block a user