expansion packs updates in progress
This commit is contained in:
Brian Madison
@@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
[](https://www.npmjs.com/package/bmad-method)
|
[](https://www.npmjs.com/package/bmad-method)
|
||||||
[](LICENSE)
|
[](LICENSE)
|
||||||
[](https://nodejs.org)
|
[](https://nodejs.org)
|
||||||
[](https://discord.gg/g6ypHytrCB)
|
[](https://discord.gg/g6ypHytrCB)
|
||||||
|
|
||||||
**AI-Powered Agile Development Framework** - Transform your software development with specialized AI agents that work as your complete Agile team.
|
**AI-Powered Agile Development Framework** - Transform your software development with specialized AI agents that work as your complete Agile team.
|
||||||
|
|||||||
@@ -1,58 +0,0 @@
|
|||||||
# [AGENT_ID]
|
|
||||||
|
|
||||||
CRITICAL: Read the full YML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
|
|
||||||
|
|
||||||
```yml
|
|
||||||
activation-instructions:
|
|
||||||
- Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
|
|
||||||
- Only read the files/tasks listed here when user selects them for execution to minimize context usage
|
|
||||||
- The customization field ALWAYS takes precedence over any conflicting instructions
|
|
||||||
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
|
||||||
|
|
||||||
agent:
|
|
||||||
name: [AGENT_NAME]
|
|
||||||
id: [AGENT_ID]
|
|
||||||
title: [AGENT_TITLE]
|
|
||||||
customization: [OPTIONAL_CUSTOMIZATION]
|
|
||||||
|
|
||||||
persona:
|
|
||||||
role: [AGENT_ROLE_DESCRIPTION]
|
|
||||||
style: [COMMUNICATION_STYLE]
|
|
||||||
identity: [AGENT_IDENTITY_DESCRIPTION]
|
|
||||||
focus: [PRIMARY_FOCUS_AREAS]
|
|
||||||
|
|
||||||
core_principles:
|
|
||||||
- [PRINCIPLE_1]
|
|
||||||
- [PRINCIPLE_2]
|
|
||||||
- [PRINCIPLE_3]
|
|
||||||
# Add more principles as needed
|
|
||||||
|
|
||||||
startup:
|
|
||||||
- [STARTUP_INSTRUCTIONS]
|
|
||||||
|
|
||||||
commands:
|
|
||||||
- "*help" - Show: numbered list of the following commands to allow selection
|
|
||||||
- "*chat-mode" - (Default) [DEFAULT_MODE_DESCRIPTION]
|
|
||||||
- "*create-doc {template}" - Create doc (no template = show available templates)
|
|
||||||
- [tasks] specific to the agent that are not covered by a template
|
|
||||||
- "*exit" - Say goodbye as the [AGENT_TITLE], and then abandon inhabiting this persona
|
|
||||||
|
|
||||||
dependencies:
|
|
||||||
tasks:
|
|
||||||
- [TASK_1]
|
|
||||||
- [TASK_2]
|
|
||||||
# Add required tasks
|
|
||||||
templates:
|
|
||||||
- [TEMPLATE_1]
|
|
||||||
- [TEMPLATE_2]
|
|
||||||
# Add required templates
|
|
||||||
checklists:
|
|
||||||
- [CHECKLIST_1]
|
|
||||||
# Add required checklists
|
|
||||||
data:
|
|
||||||
- [DATA_1]
|
|
||||||
# Add required data files
|
|
||||||
utils:
|
|
||||||
- [UTIL_1]
|
|
||||||
# Add required utilities
|
|
||||||
```
|
|
||||||
@@ -1,112 +0,0 @@
|
|||||||
# Agent Switcher Instructions
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
This document provides instructions for switching between different IDE agent personas in the BMAD-METHOD framework.
|
|
||||||
|
|
||||||
## Behavior
|
|
||||||
|
|
||||||
### Listing Available Agents
|
|
||||||
|
|
||||||
When no agent name is provided:
|
|
||||||
|
|
||||||
1. Read the `bmad-core/ide-agents/` directory
|
|
||||||
2. Look for files matching the pattern `*.ide.md`
|
|
||||||
3. Extract agent names from filenames (the part before `.ide.md`)
|
|
||||||
4. Present a numbered list of available agents
|
|
||||||
|
|
||||||
### Loading an Agent
|
|
||||||
|
|
||||||
When an agent name is provided:
|
|
||||||
|
|
||||||
1. Attempt to load `bmad-core/ide-agents/{agent-name}.ide.md`
|
|
||||||
2. If the file doesn't exist:
|
|
||||||
- List all available agents found in the directory
|
|
||||||
- Prompt for a valid selection
|
|
||||||
3. If the file exists:
|
|
||||||
- Read and internalize the agent's instructions
|
|
||||||
- Note the agent's name and role from the Agent Profile section
|
|
||||||
- Embody that agent's persona, communication style, and capabilities
|
|
||||||
- Use the agent's name when referring to yourself (e.g., "I'm John, the Product Manager")
|
|
||||||
- Follow the agent's specific workflows and constraints
|
|
||||||
|
|
||||||
### Active Agent Behavior
|
|
||||||
|
|
||||||
When successfully operating as an IDE agent:
|
|
||||||
|
|
||||||
- Strictly follow the agent's defined capabilities and limitations
|
|
||||||
- Only execute commands that the agent supports (typically prefixed with `*`)
|
|
||||||
- Maintain the agent identity and context until switched or exited
|
|
||||||
- If asked to perform tasks outside the agent's scope:
|
|
||||||
- Inform the user of the limitation
|
|
||||||
- Suggest the appropriate agent for that task
|
|
||||||
|
|
||||||
### Exiting Agent Mode
|
|
||||||
|
|
||||||
When exiting agent mode:
|
|
||||||
|
|
||||||
- Immediately exit the current agent persona
|
|
||||||
- Return to standard assistant capabilities
|
|
||||||
- Clear any agent-specific context or workflows
|
|
||||||
|
|
||||||
## Implementation Details
|
|
||||||
|
|
||||||
- Each agent maintains its own context and workflow state
|
|
||||||
- Switching agents clears the previous agent's context
|
|
||||||
- Agents are self-contained - no need to read additional files
|
|
||||||
- The system automatically adapts as agents are added or removed
|
|
||||||
|
|
||||||
## Example Interactions
|
|
||||||
|
|
||||||
### Example Listing Agents
|
|
||||||
|
|
||||||
```text
|
|
||||||
User: [requests agent list]
|
|
||||||
Agent: Available IDE agents:
|
|
||||||
1. architect
|
|
||||||
2. dev
|
|
||||||
3. devops
|
|
||||||
4. pm
|
|
||||||
5. po
|
|
||||||
6. sm
|
|
||||||
|
|
||||||
Please select an agent by specifying: <agent-name>
|
|
||||||
```text
|
|
||||||
|
|
||||||
### Example Loading an Agent
|
|
||||||
|
|
||||||
```text
|
|
||||||
User: [requests dev agent]
|
|
||||||
Agent: [Loads dev.ide.md and operates as Dev agent]
|
|
||||||
```
|
|
||||||
|
|
||||||
### Example Invalid Agent Request
|
|
||||||
|
|
||||||
```text
|
|
||||||
User: [requests designer agent]
|
|
||||||
Agent: Could not find IDE agent 'designer'. Available agents:
|
|
||||||
1. architect
|
|
||||||
2. dev
|
|
||||||
3. devops
|
|
||||||
4. pm
|
|
||||||
5. po
|
|
||||||
6. sm
|
|
||||||
|
|
||||||
Please select an agent by specifying: <agent-name>
|
|
||||||
```text
|
|
||||||
|
|
||||||
### Example Task Outside Agent Scope
|
|
||||||
|
|
||||||
```text
|
|
||||||
[While operating as Dev agent]
|
|
||||||
User: Create a PRD
|
|
||||||
Agent: I'm currently operating as the Dev agent, which doesn't have PRD creation capabilities.
|
|
||||||
The PM agent can create PRDs. Would you like me to switch to the PM agent?
|
|
||||||
```
|
|
||||||
|
|
||||||
### Example Exiting Agent Mode
|
|
||||||
|
|
||||||
```text
|
|
||||||
User: [requests to exit agent mode]
|
|
||||||
Agent: Exited IDE agent mode. Returned to standard assistant capabilities.
|
|
||||||
```
|
|
||||||
@@ -1,425 +0,0 @@
|
|||||||
# Create Expansion Pack Task
|
|
||||||
|
|
||||||
This task helps you create a comprehensive BMAD expansion pack that can include new agents, tasks, templates, and checklists for a specific domain.
|
|
||||||
|
|
||||||
## Understanding Expansion Packs
|
|
||||||
|
|
||||||
Expansion packs extend BMAD with domain-specific capabilities. They are self-contained packages that can be installed into any BMAD project. Every expansion pack MUST include a custom BMAD orchestrator agent that manages the domain-specific workflow.
|
|
||||||
|
|
||||||
## CRITICAL REQUIREMENTS
|
|
||||||
|
|
||||||
1. **Create Planning Document First**: Before any implementation, create a concise task list for user approval
|
|
||||||
2. **Verify All References**: Any task, template, or data file referenced in an agent MUST exist in the pack
|
|
||||||
3. **Include Orchestrator**: Every pack needs a custom BMAD-style orchestrator agent
|
|
||||||
4. **User Data Requirements**: Clearly specify any files users must provide in their data folder
|
|
||||||
|
|
||||||
## Process Overview
|
|
||||||
|
|
||||||
### Phase 1: Discovery and Planning
|
|
||||||
|
|
||||||
#### 1.1 Define the Domain
|
|
||||||
|
|
||||||
Ask the user:
|
|
||||||
|
|
||||||
- **Pack Name**: Short identifier (e.g., `healthcare`, `fintech`, `gamedev`)
|
|
||||||
- **Display Name**: Full name (e.g., "Healthcare Compliance Pack")
|
|
||||||
- **Description**: What domain or industry does this serve?
|
|
||||||
- **Key Problems**: What specific challenges will this pack solve?
|
|
||||||
- **Target Users**: Who will benefit from this expansion?
|
|
||||||
|
|
||||||
#### 1.2 Gather Examples
|
|
||||||
|
|
||||||
Request from the user:
|
|
||||||
|
|
||||||
- **Sample Documents**: Any existing documents in this domain
|
|
||||||
- **Workflow Examples**: How work currently flows in this domain
|
|
||||||
- **Compliance Needs**: Any regulatory or standards requirements
|
|
||||||
- **Output Examples**: What final deliverables look like
|
|
||||||
- **Data Requirements**: What reference data files users will need to provide
|
|
||||||
|
|
||||||
#### 1.3 Create Planning Document
|
|
||||||
|
|
||||||
IMPORTANT: STOP HERE AND CREATE PLAN FIRST
|
|
||||||
|
|
||||||
Create `expansion-packs/{pack-name}/plan.md` with:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# {Pack Name} Expansion Pack Plan
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
- Pack Name: {name}
|
|
||||||
- Description: {description}
|
|
||||||
- Target Domain: {domain}
|
|
||||||
|
|
||||||
## Components to Create
|
|
||||||
|
|
||||||
### Agents
|
|
||||||
|
|
||||||
- [ ] {pack-name}-orchestrator (REQUIRED: Custom BMAD orchestrator)
|
|
||||||
- [ ] {agent-1-name}
|
|
||||||
- [ ] {agent-2-name}
|
|
||||||
|
|
||||||
### Tasks
|
|
||||||
|
|
||||||
- [ ] {task-1} (referenced by: {agent})
|
|
||||||
- [ ] {task-2} (referenced by: {agent})
|
|
||||||
|
|
||||||
### Templates
|
|
||||||
|
|
||||||
- [ ] {template-1} (used by: {agent/task})
|
|
||||||
- [ ] {template-2} (used by: {agent/task})
|
|
||||||
|
|
||||||
### Checklists
|
|
||||||
|
|
||||||
- [ ] {checklist-1}
|
|
||||||
- [ ] {checklist-2}
|
|
||||||
|
|
||||||
### Data Files Required from User
|
|
||||||
|
|
||||||
- [ ] {filename}.{ext} - {description of content needed}
|
|
||||||
- [ ] {filename2}.{ext} - {description of content needed}
|
|
||||||
|
|
||||||
## Approval
|
|
||||||
|
|
||||||
User approval received: [ ] Yes
|
|
||||||
```text
|
|
||||||
|
|
||||||
Important: Wait for user approval before proceeding to Phase 2
|
|
||||||
|
|
||||||
### Phase 2: Component Design
|
|
||||||
|
|
||||||
#### 2.1 Create Orchestrator Agent
|
|
||||||
|
|
||||||
**FIRST PRIORITY**: Design the custom BMAD orchestrator:
|
|
||||||
|
|
||||||
- **Name**: `{pack-name}-orchestrator`
|
|
||||||
- **Purpose**: Master coordinator for domain-specific workflow
|
|
||||||
- **Key Commands**: Domain-specific orchestration commands
|
|
||||||
- **Integration**: How it leverages other pack agents
|
|
||||||
- **Workflow**: The complete process it manages
|
|
||||||
|
|
||||||
#### 2.2 Identify Specialist Agents
|
|
||||||
|
|
||||||
For each additional agent:
|
|
||||||
|
|
||||||
- **Role**: What specialist is needed?
|
|
||||||
- **Expertise**: Domain-specific knowledge required
|
|
||||||
- **Interactions**: How they work with orchestrator and BMAD agents
|
|
||||||
- **Unique Value**: What can't existing agents handle?
|
|
||||||
- **Required Tasks**: List ALL tasks this agent references
|
|
||||||
- **Required Templates**: List ALL templates this agent uses
|
|
||||||
- **Required Data**: List ALL data files this agent needs
|
|
||||||
|
|
||||||
#### 2.3 Design Specialized Tasks
|
|
||||||
|
|
||||||
For each task:
|
|
||||||
|
|
||||||
- **Purpose**: What specific action does it enable?
|
|
||||||
- **Inputs**: What information is needed?
|
|
||||||
- **Process**: Step-by-step instructions
|
|
||||||
- **Outputs**: What gets produced?
|
|
||||||
- **Agent Usage**: Which agents will use this task?
|
|
||||||
|
|
||||||
#### 2.4 Create Document Templates
|
|
||||||
|
|
||||||
For each template:
|
|
||||||
|
|
||||||
- **Document Type**: What kind of document?
|
|
||||||
- **Structure**: Sections and organization
|
|
||||||
- **Placeholders**: Variable content areas
|
|
||||||
- **Instructions**: How to complete each section
|
|
||||||
- **Standards**: Any format requirements
|
|
||||||
|
|
||||||
#### 2.5 Define Checklists
|
|
||||||
|
|
||||||
For each checklist:
|
|
||||||
|
|
||||||
- **Purpose**: What quality aspect does it verify?
|
|
||||||
- **Scope**: When should it be used?
|
|
||||||
- **Items**: Specific things to check
|
|
||||||
- **Criteria**: Pass/fail conditions
|
|
||||||
|
|
||||||
### Phase 3: Implementation
|
|
||||||
|
|
||||||
IMPORTANT: Only proceed after plan.md is approved
|
|
||||||
|
|
||||||
#### 3.1 Create Directory Structure
|
|
||||||
|
|
||||||
```text
|
|
||||||
expansion-packs/
|
|
||||||
└── {pack-name}/
|
|
||||||
├── plan.md (ALREADY CREATED)
|
|
||||||
├── manifest.yml
|
|
||||||
├── README.md
|
|
||||||
├── agents/
|
|
||||||
│ ├── {pack-name}-orchestrator.yml (REQUIRED)
|
|
||||||
│ └── {agent-id}.yml
|
|
||||||
├── personas/
|
|
||||||
│ ├── {pack-name}-orchestrator.md (REQUIRED)
|
|
||||||
│ └── {agent-id}.md
|
|
||||||
├── tasks/
|
|
||||||
│ └── {task-name}.md
|
|
||||||
├── templates/
|
|
||||||
│ └── {template-name}.md
|
|
||||||
├── checklists/
|
|
||||||
│ └── {checklist-name}.md
|
|
||||||
└── ide-agents/
|
|
||||||
├── {pack-name}-orchestrator.ide.md (REQUIRED)
|
|
||||||
└── {agent-id}.ide.md
|
|
||||||
```text
|
|
||||||
|
|
||||||
#### 3.2 Create Manifest
|
|
||||||
|
|
||||||
Create `manifest.yml`:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
name: {pack-name}
|
|
||||||
version: 1.0.0
|
|
||||||
description: >-
|
|
||||||
{Detailed description of the expansion pack}
|
|
||||||
author: {Your name or organization}
|
|
||||||
bmad_version: "4.0.0"
|
|
||||||
|
|
||||||
# Files to create in the expansion pack
|
|
||||||
files:
|
|
||||||
agents:
|
|
||||||
- {pack-name}-orchestrator.yml
|
|
||||||
- {agent-name}.yml
|
|
||||||
|
|
||||||
personas:
|
|
||||||
- {pack-name}-orchestrator.md
|
|
||||||
- {agent-name}.md
|
|
||||||
|
|
||||||
ide-agents:
|
|
||||||
- {pack-name}-orchestrator.ide.md
|
|
||||||
- {agent-name}.ide.md
|
|
||||||
|
|
||||||
tasks:
|
|
||||||
- {task-name}.md
|
|
||||||
|
|
||||||
templates:
|
|
||||||
- {template-name}.md
|
|
||||||
|
|
||||||
checklists:
|
|
||||||
- {checklist-name}.md
|
|
||||||
|
|
||||||
# Data files users must provide
|
|
||||||
required_data:
|
|
||||||
- filename: {data-file}.{ext}
|
|
||||||
description: {What this file should contain}
|
|
||||||
location: bmad-core/data/
|
|
||||||
|
|
||||||
# Dependencies on core BMAD components
|
|
||||||
dependencies:
|
|
||||||
- {core-agent-name}
|
|
||||||
- {core-task-name}
|
|
||||||
|
|
||||||
# Post-install message
|
|
||||||
post_install_message: |
|
|
||||||
{Pack Name} expansion pack ready!
|
|
||||||
|
|
||||||
Required data files:
|
|
||||||
- {data-file}.{ext}: {description}
|
|
||||||
|
|
||||||
To use: npm run agent {pack-name}-orchestrator
|
|
||||||
```text
|
|
||||||
|
|
||||||
### Phase 4: Content Creation
|
|
||||||
|
|
||||||
IMPORTANT: Work through plan.md checklist systematically!
|
|
||||||
|
|
||||||
#### 4.1 Create Orchestrator First
|
|
||||||
|
|
||||||
1. Create `personas/{pack-name}-orchestrator.md` with BMAD-style commands
|
|
||||||
2. Create `agents/{pack-name}-orchestrator.yml` configuration
|
|
||||||
3. Create `ide-agents/{pack-name}-orchestrator.ide.md`
|
|
||||||
4. Verify ALL referenced tasks exist
|
|
||||||
5. Verify ALL referenced templates exist
|
|
||||||
6. Document data file requirements
|
|
||||||
|
|
||||||
#### 4.2 Agent Creation Order
|
|
||||||
|
|
||||||
For each additional agent:
|
|
||||||
|
|
||||||
1. Create persona file with domain expertise
|
|
||||||
2. Create agent configuration YAML
|
|
||||||
3. Create IDE-optimized version
|
|
||||||
4. **STOP** - Verify all referenced tasks/templates exist
|
|
||||||
5. Create any missing tasks/templates immediately
|
|
||||||
6. Mark agent as complete in plan.md
|
|
||||||
|
|
||||||
#### 4.3 Task Creation Guidelines
|
|
||||||
|
|
||||||
Each task should:
|
|
||||||
|
|
||||||
1. Have a clear, single purpose
|
|
||||||
2. Include step-by-step instructions
|
|
||||||
3. Provide examples when helpful
|
|
||||||
4. Reference domain standards
|
|
||||||
5. Be reusable across agents
|
|
||||||
|
|
||||||
#### 4.4 Template Best Practices
|
|
||||||
|
|
||||||
Templates should:
|
|
||||||
|
|
||||||
1. Include clear section headers
|
|
||||||
2. Provide inline instructions
|
|
||||||
3. Show example content
|
|
||||||
4. Mark required vs optional sections
|
|
||||||
5. Include domain-specific terminology
|
|
||||||
|
|
||||||
### Phase 5: Verification and Documentation
|
|
||||||
|
|
||||||
#### 5.1 Final Verification Checklist
|
|
||||||
|
|
||||||
Before declaring complete:
|
|
||||||
|
|
||||||
1. [ ] All items in plan.md marked complete
|
|
||||||
2. [ ] Orchestrator agent created and tested
|
|
||||||
3. [ ] All agent references validated
|
|
||||||
4. [ ] All required data files documented
|
|
||||||
5. [ ] manifest.yml lists all components
|
|
||||||
6. [ ] No orphaned tasks or templates
|
|
||||||
|
|
||||||
#### 5.2 Create README
|
|
||||||
|
|
||||||
Include:
|
|
||||||
|
|
||||||
- Overview of the pack's purpose
|
|
||||||
- **Orchestrator usage instructions**
|
|
||||||
- Required data files and formats
|
|
||||||
- List of all components
|
|
||||||
- Integration with BMAD workflow
|
|
||||||
- Example scenarios
|
|
||||||
|
|
||||||
#### 5.3 Data File Documentation
|
|
||||||
|
|
||||||
For each required data file:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Required Data Files
|
|
||||||
|
|
||||||
### {filename}.{ext}
|
|
||||||
|
|
||||||
- **Purpose**: {why this file is needed}
|
|
||||||
- **Format**: {file format and structure}
|
|
||||||
- **Location**: Place in `bmad-core/data/`
|
|
||||||
- **Example**:
|
|
||||||
```
|
|
||||||
|
|
||||||
## Example: Healthcare Expansion Pack
|
|
||||||
|
|
||||||
```text
|
|
||||||
healthcare/
|
|
||||||
├── plan.md (Created first for approval)
|
|
||||||
├── manifest.yml
|
|
||||||
├── README.md
|
|
||||||
├── agents/
|
|
||||||
│ ├── healthcare-orchestrator.yml (REQUIRED)
|
|
||||||
│ ├── clinical-analyst.yml
|
|
||||||
│ └── compliance-officer.yml
|
|
||||||
├── personas/
|
|
||||||
│ ├── healthcare-orchestrator.md (REQUIRED)
|
|
||||||
│ ├── clinical-analyst.md
|
|
||||||
│ └── compliance-officer.md
|
|
||||||
├── ide-agents/
|
|
||||||
│ ├── healthcare-orchestrator.ide.md (REQUIRED)
|
|
||||||
│ ├── clinical-analyst.ide.md
|
|
||||||
│ └── compliance-officer.ide.md
|
|
||||||
├── tasks/
|
|
||||||
│ ├── hipaa-assessment.md
|
|
||||||
│ ├── clinical-protocol-review.md
|
|
||||||
│ └── patient-data-analysis.md
|
|
||||||
├── templates/
|
|
||||||
│ ├── clinical-trial-protocol.md
|
|
||||||
│ ├── hipaa-compliance-report.md
|
|
||||||
│ └── patient-outcome-report.md
|
|
||||||
└── checklists/
|
|
||||||
├── hipaa-checklist.md
|
|
||||||
└── clinical-data-quality.md
|
|
||||||
|
|
||||||
Required user data files:
|
|
||||||
- bmad-core/data/medical-terminology.md
|
|
||||||
- bmad-core/data/hipaa-requirements.md
|
|
||||||
```
|
|
||||||
|
|
||||||
## Interactive Questions Flow
|
|
||||||
|
|
||||||
### Initial Discovery
|
|
||||||
|
|
||||||
1. "What domain or industry will this expansion pack serve?"
|
|
||||||
2. "What are the main challenges or workflows in this domain?"
|
|
||||||
3. "Do you have any example documents or outputs? (Please share)"
|
|
||||||
4. "What specialized roles/experts exist in this domain?"
|
|
||||||
5. "What reference data will users need to provide?"
|
|
||||||
|
|
||||||
### Planning Phase
|
|
||||||
|
|
||||||
1. "Here's the proposed plan. Please review and approve before we continue."
|
|
||||||
|
|
||||||
### Orchestrator Design
|
|
||||||
|
|
||||||
1. "What key commands should the {pack-name} orchestrator support?"
|
|
||||||
2. "What's the typical workflow from start to finish?"
|
|
||||||
3. "How should it integrate with core BMAD agents?"
|
|
||||||
|
|
||||||
### Agent Planning
|
|
||||||
|
|
||||||
1. "For agent '{name}', what is their specific expertise?"
|
|
||||||
2. "What tasks will this agent reference? (I'll create them)"
|
|
||||||
3. "What templates will this agent use? (I'll create them)"
|
|
||||||
4. "What data files will this agent need? (You'll provide these)"
|
|
||||||
|
|
||||||
### Task Design
|
|
||||||
|
|
||||||
1. "Describe the '{task}' process step-by-step"
|
|
||||||
2. "What information is needed to complete this task?"
|
|
||||||
3. "What should the output look like?"
|
|
||||||
|
|
||||||
### Template Creation
|
|
||||||
|
|
||||||
1. "What sections should the '{template}' document have?"
|
|
||||||
2. "Are there any required formats or standards?"
|
|
||||||
3. "Can you provide an example of a completed document?"
|
|
||||||
|
|
||||||
### Data Requirements
|
|
||||||
|
|
||||||
1. "For {data-file}, what information should it contain?"
|
|
||||||
2. "What format should this data be in?"
|
|
||||||
3. "Can you provide a sample?"
|
|
||||||
|
|
||||||
## Important Considerations
|
|
||||||
|
|
||||||
- **Plan First**: ALWAYS create and get approval for plan.md before implementing
|
|
||||||
- **Orchestrator Required**: Every pack MUST have a custom BMAD orchestrator
|
|
||||||
- **Verify References**: ALL referenced tasks/templates MUST exist
|
|
||||||
- **Document Data Needs**: Clearly specify what users must provide
|
|
||||||
- **Domain Expertise**: Ensure accuracy in specialized fields
|
|
||||||
- **Compliance**: Include necessary regulatory requirements
|
|
||||||
|
|
||||||
## Tips for Success
|
|
||||||
|
|
||||||
1. **Plan Thoroughly**: The plan.md prevents missing components
|
|
||||||
2. **Build Orchestrator First**: It defines the overall workflow
|
|
||||||
3. **Verify As You Go**: Check off items in plan.md
|
|
||||||
4. **Test References**: Ensure no broken dependencies
|
|
||||||
5. **Document Data**: Users need clear data file instructions
|
|
||||||
|
|
||||||
## Common Mistakes to Avoid
|
|
||||||
|
|
||||||
1. **Missing Orchestrator**: Every pack needs its own BMAD-style orchestrator
|
|
||||||
2. **Orphaned References**: Agent references task that doesn't exist
|
|
||||||
3. **Unclear Data Needs**: Not specifying required user data files
|
|
||||||
4. **Skipping Plan**: Going straight to implementation
|
|
||||||
5. **Generic Orchestrator**: Not making it domain-specific
|
|
||||||
|
|
||||||
## Completion Checklist
|
|
||||||
|
|
||||||
- [ ] plan.md created and approved
|
|
||||||
- [ ] All plan.md items checked off
|
|
||||||
- [ ] Orchestrator agent created
|
|
||||||
- [ ] All agent references verified
|
|
||||||
- [ ] Data requirements documented or added
|
|
||||||
- [ ] README includes all setup instructions
|
|
||||||
- [ ] manifest.yml reflects actual files
|
|
||||||
74
expansion-packs/expansion-creator/common-tasks/create-doc.md
Normal file
74
expansion-packs/expansion-creator/common-tasks/create-doc.md
Normal file
@@ -0,0 +1,74 @@
|
|||||||
|
# Create Document from Template Task
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
- Generate documents from any specified template following embedded instructions from the perspective of the selected agent persona
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
|
||||||
|
### 1. Identify Template and Context
|
||||||
|
|
||||||
|
- Determine which template to use (user-provided or list available for selection to user)
|
||||||
|
|
||||||
|
- Agent-specific templates are listed in the agent's dependencies under `templates`. For each template listed, consider it a document the agent can create. So if an agent has:
|
||||||
|
|
||||||
|
@{example}
|
||||||
|
dependencies:
|
||||||
|
templates: - prd-tmpl - architecture-tmpl
|
||||||
|
@{/example}
|
||||||
|
|
||||||
|
You would offer to create "PRD" and "Architecture" documents when the user asks what you can help with.
|
||||||
|
|
||||||
|
- Gather all relevant inputs, or ask for them, or else rely on user providing necessary details to complete the document
|
||||||
|
- Understand the document purpose and target audience
|
||||||
|
|
||||||
|
### 2. Determine Interaction Mode
|
||||||
|
|
||||||
|
Confirm with the user their preferred interaction style:
|
||||||
|
|
||||||
|
- **Incremental:** Work through chunks of the document.
|
||||||
|
- **YOLO Mode:** Draft complete document making reasonable assumptions in one shot. (Can be entered also after starting incremental by just typing /yolo)
|
||||||
|
|
||||||
|
### 3. Execute Template
|
||||||
|
|
||||||
|
- Load specified template from `templates#*` or the /templates directory
|
||||||
|
- Follow ALL embedded LLM instructions within the template
|
||||||
|
- Process template markup according to `utils#template-format` conventions
|
||||||
|
|
||||||
|
### 4. Template Processing Rules
|
||||||
|
|
||||||
|
#### CRITICAL: Never display template markup, LLM instructions, or examples to users
|
||||||
|
|
||||||
|
- Replace all {{placeholders}} with actual content
|
||||||
|
- Execute all [[LLM: instructions]] internally
|
||||||
|
- Process `<<REPEAT>>` sections as needed
|
||||||
|
- Evaluate ^^CONDITION^^ blocks and include only if applicable
|
||||||
|
- Use @{examples} for guidance but never output them
|
||||||
|
|
||||||
|
### 5. Content Generation
|
||||||
|
|
||||||
|
- **Incremental Mode**: Present each major section for review before proceeding
|
||||||
|
- **YOLO Mode**: Generate all sections, then review complete document with user
|
||||||
|
- Apply any elicitation protocols specified in template
|
||||||
|
- Incorporate user feedback and iterate as needed
|
||||||
|
|
||||||
|
### 6. Validation
|
||||||
|
|
||||||
|
If template specifies a checklist:
|
||||||
|
|
||||||
|
- Run the appropriate checklist against completed document
|
||||||
|
- Document completion status for each item
|
||||||
|
- Address any deficiencies found
|
||||||
|
- Present validation summary to user
|
||||||
|
|
||||||
|
### 7. Final Presentation
|
||||||
|
|
||||||
|
- Present clean, formatted content only
|
||||||
|
- Ensure all sections are complete
|
||||||
|
- DO NOT truncate or summarize content
|
||||||
|
- Begin directly with document content (no preamble)
|
||||||
|
- Include any handoff prompts specified in template
|
||||||
|
|
||||||
|
## Important Notes
|
||||||
|
|
||||||
|
- Template markup is for AI processing only - never expose to users
|
||||||
@@ -0,0 +1,97 @@
|
|||||||
|
# Checklist Validation Task
|
||||||
|
|
||||||
|
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||||
|
|
||||||
|
## Context
|
||||||
|
|
||||||
|
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
|
||||||
|
|
||||||
|
## Available Checklists
|
||||||
|
|
||||||
|
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
|
||||||
|
1. **Initial Assessment**
|
||||||
|
|
||||||
|
- If user or the task being run provides a checklist name:
|
||||||
|
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||||
|
- If multiple matches found, ask user to clarify
|
||||||
|
- Load the appropriate checklist from bmad-core/checklists/
|
||||||
|
- If no checklist specified:
|
||||||
|
- Ask the user which checklist they want to use
|
||||||
|
- Present the available options from the files in the checklists folder
|
||||||
|
- Confirm if they want to work through the checklist:
|
||||||
|
- Section by section (interactive mode - very time consuming)
|
||||||
|
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||||
|
|
||||||
|
2. **Document and Artifact Gathering**
|
||||||
|
|
||||||
|
- Each checklist will specify its required documents/artifacts at the beginning
|
||||||
|
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||||
|
|
||||||
|
3. **Checklist Processing**
|
||||||
|
|
||||||
|
If in interactive mode:
|
||||||
|
|
||||||
|
- Work through each section of the checklist one at a time
|
||||||
|
- For each section:
|
||||||
|
- Review all items in the section following instructions for that section embedded in the checklist
|
||||||
|
- Check each item against the relevant documentation or artifacts as appropriate
|
||||||
|
- Present summary of findings for that section, highlighting warnings, errors and non applicable items (rationale for non-applicability).
|
||||||
|
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||||
|
|
||||||
|
If in YOLO mode:
|
||||||
|
|
||||||
|
- Process all sections at once
|
||||||
|
- Create a comprehensive report of all findings
|
||||||
|
- Present the complete analysis to the user
|
||||||
|
|
||||||
|
4. **Validation Approach**
|
||||||
|
|
||||||
|
For each checklist item:
|
||||||
|
|
||||||
|
- Read and understand the requirement
|
||||||
|
- Look for evidence in the documentation that satisfies the requirement
|
||||||
|
- Consider both explicit mentions and implicit coverage
|
||||||
|
- Aside from this, follow all checklist llm instructions
|
||||||
|
- Mark items as:
|
||||||
|
- ✅ PASS: Requirement clearly met
|
||||||
|
- ❌ FAIL: Requirement not met or insufficient coverage
|
||||||
|
- ⚠️ PARTIAL: Some aspects covered but needs improvement
|
||||||
|
- N/A: Not applicable to this case
|
||||||
|
|
||||||
|
5. **Section Analysis**
|
||||||
|
|
||||||
|
For each section:
|
||||||
|
|
||||||
|
- think step by step to calculate pass rate
|
||||||
|
- Identify common themes in failed items
|
||||||
|
- Provide specific recommendations for improvement
|
||||||
|
- In interactive mode, discuss findings with user
|
||||||
|
- Document any user decisions or explanations
|
||||||
|
|
||||||
|
6. **Final Report**
|
||||||
|
|
||||||
|
Prepare a summary that includes:
|
||||||
|
|
||||||
|
- Overall checklist completion status
|
||||||
|
- Pass rates by section
|
||||||
|
- List of failed items with context
|
||||||
|
- Specific recommendations for improvement
|
||||||
|
- Any sections or items marked as N/A with justification
|
||||||
|
|
||||||
|
## Checklist Execution Methodology
|
||||||
|
|
||||||
|
Each checklist now contains embedded LLM prompts and instructions that will:
|
||||||
|
|
||||||
|
1. **Guide thorough thinking** - Prompts ensure deep analysis of each section
|
||||||
|
2. **Request specific artifacts** - Clear instructions on what documents/access is needed
|
||||||
|
3. **Provide contextual guidance** - Section-specific prompts for better validation
|
||||||
|
4. **Generate comprehensive reports** - Final summary with detailed findings
|
||||||
|
|
||||||
|
The LLM will:
|
||||||
|
|
||||||
|
- Execute the complete checklist validation
|
||||||
|
- Present a final report with pass/fail rates and key findings
|
||||||
|
- Offer to provide detailed analysis of any section, especially those with warnings or failures
|
||||||
@@ -121,7 +121,7 @@ Present to the user:
|
|||||||
1. Review and customize the created tasks/templates
|
1. Review and customize the created tasks/templates
|
||||||
2. Run npm run build:agents
|
2. Run npm run build:agents
|
||||||
3. Test the agent thoroughly
|
3. Test the agent thoroughly
|
||||||
```
|
```text
|
||||||
|
|
||||||
## Template Reference
|
## Template Reference
|
||||||
|
|
||||||
1023
expansion-packs/expansion-creator/tasks/generate-expansion-pack.md
Normal file
1023
expansion-packs/expansion-creator/tasks/generate-expansion-pack.md
Normal file
File diff suppressed because it is too large
Load Diff
154
expansion-packs/expansion-creator/templates/agent-teams-tmpl.md
Normal file
154
expansion-packs/expansion-creator/templates/agent-teams-tmpl.md
Normal file
@@ -0,0 +1,154 @@
|
|||||||
|
# Agent Team Configuration Template
|
||||||
|
|
||||||
|
[[LLM: This template is for creating agent team configurations in YAML format. Follow the structure carefully and replace all placeholders with appropriate values. The team name should reflect the team's purpose and domain focus.]]
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
bundle:
|
||||||
|
name: {{team-display-name}}
|
||||||
|
[[LLM: Use format "Team [Descriptor]" for generic teams or "[Domain] Team" for specialized teams. Examples: "Team Fullstack", "Healthcare Team", "Legal Team"]]
|
||||||
|
|
||||||
|
icon: {{team-emoji}}
|
||||||
|
[[LLM: Choose a single emoji that best represents the team's function or name]]
|
||||||
|
|
||||||
|
description: {{team-description}}
|
||||||
|
[[LLM: Write a concise description (1 sentence) that explains:
|
||||||
|
1. The team's primary purpose
|
||||||
|
2. What types of projects they handle
|
||||||
|
3. Any special capabilities or focus areas
|
||||||
|
4. Keep it short as its displayed in menus
|
||||||
|
Example: "Full Stack Ideation Web App Team." or "Startup Business Coaching team"]]
|
||||||
|
|
||||||
|
agents:
|
||||||
|
[[LLM: List the agents that make up this team. Guidelines:
|
||||||
|
- Use shortened agent names (e.g., 'analyst' not 'business-analyst')
|
||||||
|
- Include 'bmad-orchestrator' for bmad-core teams as the coordinator
|
||||||
|
- Only use '*' for an all-inclusive team (rare)
|
||||||
|
- Order agents logically by workflow (analysis → design → development → testing)
|
||||||
|
- For expansion packs, include both core agents and custom agents]]
|
||||||
|
|
||||||
|
^^CONDITION: standard-team^^
|
||||||
|
# Core workflow agents
|
||||||
|
- bmad-orchestrator # Team coordinator
|
||||||
|
- analyst # Requirements and analysis
|
||||||
|
- pm # Product management
|
||||||
|
- architect # System design
|
||||||
|
- dev # Development
|
||||||
|
- qa # Quality assurance
|
||||||
|
^^/CONDITION: standard-team^^
|
||||||
|
|
||||||
|
^^CONDITION: minimal-team^^
|
||||||
|
# Minimal team for quick iterations
|
||||||
|
- bmad-orchestrator # Team coordinator
|
||||||
|
- architect # Design and planning
|
||||||
|
- dev # Implementation
|
||||||
|
^^/CONDITION: minimal-team^^
|
||||||
|
|
||||||
|
^^CONDITION: specialized-team^^
|
||||||
|
# Domain-specific team composition
|
||||||
|
- {{domain}}-orchestrator # Domain coordinator
|
||||||
|
<<REPEAT section="specialist-agents" count="{{agent-count}}">>
|
||||||
|
- {{agent-short-name}} # {{agent-role-description}}
|
||||||
|
<</REPEAT>>
|
||||||
|
^^/CONDITION: specialized-team^^
|
||||||
|
|
||||||
|
^^CONDITION: include-all-agents^^
|
||||||
|
- '*' # Include all available agents
|
||||||
|
^^/CONDITION: include-all-agents^^
|
||||||
|
|
||||||
|
workflows:
|
||||||
|
[[LLM: Define the workflows this team can execute that will guide the user through a multi-step multi agent process. Guidelines:
|
||||||
|
- Use null if the team doesn't have predefined workflows
|
||||||
|
- Workflow names should be descriptive
|
||||||
|
- use domain-specific workflow names]]
|
||||||
|
|
||||||
|
^^CONDITION: no-workflows^^
|
||||||
|
null # No predefined workflows
|
||||||
|
^^/CONDITION: no-workflows^^
|
||||||
|
|
||||||
|
^^CONDITION: standard-workflows^^
|
||||||
|
# New project workflows
|
||||||
|
- greenfield-fullstack # New full-stack application
|
||||||
|
- greenfield-service # New backend service
|
||||||
|
- greenfield-ui # New frontend application
|
||||||
|
|
||||||
|
# Existing project workflows
|
||||||
|
- brownfield-fullstack # Enhance existing full-stack app
|
||||||
|
- brownfield-service # Enhance existing service
|
||||||
|
- brownfield-ui # Enhance existing UI
|
||||||
|
^^/CONDITION: standard-workflows^^
|
||||||
|
|
||||||
|
^^CONDITION: domain-workflows^^
|
||||||
|
# Domain-specific workflows
|
||||||
|
<<REPEAT section="workflows" count="{{workflow-count}}">>
|
||||||
|
- {{workflow-name}} # {{workflow-description}}
|
||||||
|
<</REPEAT>>
|
||||||
|
^^/CONDITION: domain-workflows^^
|
||||||
|
```text
|
||||||
|
|
||||||
|
@{example-1: Standard fullstack team}
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
bundle:
|
||||||
|
name: Team Fullstack
|
||||||
|
icon: 🚀
|
||||||
|
description: Complete agile team for full-stack web applications. Handles everything from requirements to deployment.
|
||||||
|
agents:
|
||||||
|
- bmad-orchestrator
|
||||||
|
- analyst
|
||||||
|
- pm
|
||||||
|
- architect
|
||||||
|
- dev
|
||||||
|
- qa
|
||||||
|
- ux-expert
|
||||||
|
workflows:
|
||||||
|
- greenfield-fullstack
|
||||||
|
- greenfield-service
|
||||||
|
- greenfield-ui
|
||||||
|
- brownfield-fullstack
|
||||||
|
- brownfield-service
|
||||||
|
- brownfield-ui
|
||||||
|
```
|
||||||
|
|
||||||
|
@{example-2: Healthcare expansion pack team}
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
bundle:
|
||||||
|
name: Healthcare Compliance Team
|
||||||
|
icon: ⚕️
|
||||||
|
description: Specialized team for healthcare applications with HIPAA compliance focus. Manages clinical workflows and regulatory requirements.
|
||||||
|
agents:
|
||||||
|
- healthcare-orchestrator
|
||||||
|
- clinical-analyst
|
||||||
|
- compliance-officer
|
||||||
|
- architect
|
||||||
|
- dev
|
||||||
|
- qa
|
||||||
|
workflows:
|
||||||
|
- healthcare-patient-portal
|
||||||
|
- healthcare-compliance-audit
|
||||||
|
- clinical-trial-management
|
||||||
|
```text
|
||||||
|
|
||||||
|
@{example-3: Minimal IDE team}
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
bundle:
|
||||||
|
name: Team IDE Minimal
|
||||||
|
icon: ⚡
|
||||||
|
description: Minimal team for IDE usage. Just the essentials for quick development.
|
||||||
|
agents:
|
||||||
|
- bmad-orchestrator
|
||||||
|
- architect
|
||||||
|
- dev
|
||||||
|
workflows: null
|
||||||
|
```
|
||||||
|
|
||||||
|
[[LLM: When creating a new team configuration:
|
||||||
|
|
||||||
|
1. Choose the most appropriate condition block based on team type
|
||||||
|
2. Remove all unused condition blocks
|
||||||
|
3. Replace all placeholders with actual values
|
||||||
|
4. Ensure agent names match available agents in the system
|
||||||
|
5. Verify workflow names match available workflows
|
||||||
|
6. Save as team-[descriptor].yml or [domain]-team.yml
|
||||||
|
7. Place in the agent-teams directory of the appropriate location]]
|
||||||
140
expansion-packs/expansion-creator/templates/agent-tmpl.md
Normal file
140
expansion-packs/expansion-creator/templates/agent-tmpl.md
Normal file
@@ -0,0 +1,140 @@
|
|||||||
|
# [AGENT_ID]
|
||||||
|
|
||||||
|
[[LLM: This is an agent definition template. When creating a new agent:
|
||||||
|
|
||||||
|
1. ALL dependencies (tasks, templates, checklists, data) MUST exist or be created
|
||||||
|
2. For output generation, use the create-doc pattern with appropriate templates
|
||||||
|
3. Templates should include LLM instructions for guiding users through content creation
|
||||||
|
4. Character personas should be consistent and domain-appropriate
|
||||||
|
5. Follow the numbered options protocol for all user interactions]]
|
||||||
|
|
||||||
|
CRITICAL: Read the full YML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
|
||||||
|
|
||||||
|
```yml
|
||||||
|
activation-instructions:
|
||||||
|
- Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
|
||||||
|
- Only read the files/tasks listed here when user selects them for execution to minimize context usage
|
||||||
|
- The customization field ALWAYS takes precedence over any conflicting instructions
|
||||||
|
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
||||||
|
|
||||||
|
agent:
|
||||||
|
name: [AGENT_NAME]
|
||||||
|
id: [AGENT_ID]
|
||||||
|
title: [AGENT_TITLE]
|
||||||
|
customization: [OPTIONAL_CUSTOMIZATION]
|
||||||
|
|
||||||
|
persona:
|
||||||
|
role: [AGENT_ROLE_DESCRIPTION]
|
||||||
|
style: [COMMUNICATION_STYLE]
|
||||||
|
identity: [AGENT_IDENTITY_DESCRIPTION]
|
||||||
|
focus: [PRIMARY_FOCUS_AREAS]
|
||||||
|
|
||||||
|
core_principles:
|
||||||
|
- [PRINCIPLE_1]
|
||||||
|
- [PRINCIPLE_2]
|
||||||
|
- [PRINCIPLE_3]
|
||||||
|
# Add more principles as needed
|
||||||
|
|
||||||
|
startup:
|
||||||
|
- [STARTUP_INSTRUCTIONS]
|
||||||
|
|
||||||
|
commands:
|
||||||
|
- "*help" - Show: numbered list of the following commands to allow selection
|
||||||
|
- "*chat-mode" - (Default) [DEFAULT_MODE_DESCRIPTION]
|
||||||
|
- "*create-doc {template}" - Create doc (no template = show available templates)
|
||||||
|
[[LLM: For output generation tasks, always use create-doc with templates rather than custom tasks.
|
||||||
|
Example: Instead of a "create-blueprint" task, use "*create-doc blueprint-tmpl"
|
||||||
|
The template should contain LLM instructions for guiding users through the creation process]]
|
||||||
|
- [tasks] specific to the agent that are not covered by a template
|
||||||
|
[[LLM: Only create custom tasks for actions that don't produce documents, like analysis, validation, or process execution]]
|
||||||
|
- "*exit" - Say goodbye as the [AGENT_TITLE], and then abandon inhabiting this persona
|
||||||
|
|
||||||
|
dependencies:
|
||||||
|
[[LLM: CRITICAL - All dependencies listed here MUST exist in the expansion pack or be created:
|
||||||
|
- Tasks: Must exist in tasks/ directory (include create-doc if using templates)
|
||||||
|
- Templates: Must exist in templates/ directory with proper LLM instructions
|
||||||
|
- Checklists: Must exist in checklists/ directory for quality validation
|
||||||
|
- Data: Must exist in data/ directory or be documented as user-required
|
||||||
|
- Utils: Must exist in utils/ directory (include template-format if using templates)]]
|
||||||
|
|
||||||
|
tasks:
|
||||||
|
- create-doc # Required if agent creates documents from templates
|
||||||
|
- [TASK_1] # Custom task for non-document operations
|
||||||
|
- [TASK_2] # Another custom task
|
||||||
|
[[LLM: Example tasks: validate-design, analyze-requirements, execute-tests]]
|
||||||
|
|
||||||
|
templates:
|
||||||
|
- [TEMPLATE_1] # Template with LLM instructions for guided creation
|
||||||
|
- [TEMPLATE_2] # Another template for different document type
|
||||||
|
[[LLM: Example: blueprint-tmpl, contract-tmpl, report-tmpl
|
||||||
|
Each template should include [[LLM: guidance]] and other conventions from `template-formmat.md` sections for user interaction]]
|
||||||
|
|
||||||
|
checklists:
|
||||||
|
- [CHECKLIST_1] # Quality validation for template outputs
|
||||||
|
[[LLM: Example: blueprint-checklist, contract-checklist
|
||||||
|
Checklists validate documents created from templates]]
|
||||||
|
|
||||||
|
data:
|
||||||
|
- [DATA_1] # Domain knowledge files
|
||||||
|
[[LLM: Example: building-codes.md, legal-terminology.md
|
||||||
|
Can be embedded in pack or required from user]]
|
||||||
|
|
||||||
|
utils:
|
||||||
|
- template-format # Required if using templates
|
||||||
|
- [UTIL_1] # Other utilities as needed
|
||||||
|
[[LLM: Include workflow-management if agent participates in workflows]]
|
||||||
|
```text
|
||||||
|
|
||||||
|
@{example: Construction Contractor Agent}
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
activation-instructions:
|
||||||
|
- Follow all instructions in this file
|
||||||
|
- Stay in character as Marcus Thompson, Construction Manager
|
||||||
|
- Use numbered options for all interactions
|
||||||
|
agent:
|
||||||
|
name: Marcus Thompson
|
||||||
|
id: construction-contractor
|
||||||
|
title: Construction Project Manager
|
||||||
|
customization: null
|
||||||
|
persona:
|
||||||
|
role: Licensed general contractor with 20 years experience
|
||||||
|
style: Professional, detail-oriented, safety-conscious
|
||||||
|
identity: Former site foreman who worked up to project management
|
||||||
|
focus: Building design, code compliance, project scheduling, cost estimation
|
||||||
|
core_principles:
|
||||||
|
- Safety first - all designs must prioritize worker and occupant safety
|
||||||
|
- Code compliance - ensure all work meets local building codes
|
||||||
|
- Quality craftsmanship - no shortcuts on structural integrity
|
||||||
|
startup:
|
||||||
|
- Greet as Marcus Thompson, Construction Project Manager
|
||||||
|
- Briefly mention your experience and readiness to help
|
||||||
|
- Ask what type of construction project they're planning
|
||||||
|
- DO NOT auto-execute any commands
|
||||||
|
commands:
|
||||||
|
- '*help" - Show numbered list of available commands'
|
||||||
|
- '*chat-mode" - Discuss construction projects and provide expertise'
|
||||||
|
- '*create-doc blueprint-tmpl" - Create architectural blueprints'
|
||||||
|
- '*create-doc estimate-tmpl" - Create project cost estimate'
|
||||||
|
- '*create-doc schedule-tmpl" - Create construction schedule'
|
||||||
|
- '*validate-plans" - Review plans for code compliance'
|
||||||
|
- '*safety-assessment" - Evaluate safety considerations'
|
||||||
|
- '*exit" - Say goodbye as Marcus and exit'
|
||||||
|
dependencies:
|
||||||
|
tasks:
|
||||||
|
- 'create-doc # For document creation'
|
||||||
|
- 'validate-plans # Custom validation task'
|
||||||
|
- 'safety-assessment # Custom safety review task'
|
||||||
|
templates:
|
||||||
|
- 'blueprint-tmpl # Architectural blueprint template'
|
||||||
|
- 'estimate-tmpl # Cost estimation template'
|
||||||
|
- 'schedule-tmpl # Project timeline template'
|
||||||
|
checklists:
|
||||||
|
- 'blueprint-checklist # Validates blueprint completeness'
|
||||||
|
- 'safety-checklist # Safety compliance validation'
|
||||||
|
data:
|
||||||
|
- 'building-codes.md # Local building code reference'
|
||||||
|
- 'materials-guide.md # Construction materials specs'
|
||||||
|
utils:
|
||||||
|
- 'template-format # For template processing'
|
||||||
|
```
|
||||||
26
expansion-packs/expansion-creator/utils/template-format.md
Normal file
26
expansion-packs/expansion-creator/utils/template-format.md
Normal file
@@ -0,0 +1,26 @@
|
|||||||
|
# Template Format Conventions
|
||||||
|
|
||||||
|
Templates in the BMAD method use standardized markup for AI processing. These conventions ensure consistent document generation.
|
||||||
|
|
||||||
|
## Template Markup Elements
|
||||||
|
|
||||||
|
- **{{placeholders}}**: Variables to be replaced with actual content
|
||||||
|
- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
|
||||||
|
- **REPEAT** sections: Content blocks that may be repeated as needed
|
||||||
|
- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
|
||||||
|
- **@{examples}**: Example content for guidance (never output to users)
|
||||||
|
|
||||||
|
## Processing Rules
|
||||||
|
|
||||||
|
- Replace all {{placeholders}} with project-specific content
|
||||||
|
- Execute all [[LLM: instructions]] internally without showing users
|
||||||
|
- Process conditional and repeat blocks as specified
|
||||||
|
- Use examples for guidance but never include them in final output
|
||||||
|
- Present only clean, formatted content to users
|
||||||
|
|
||||||
|
## Critical Guidelines
|
||||||
|
|
||||||
|
- **NEVER display template markup, LLM instructions, or examples to users**
|
||||||
|
- Template elements are for AI processing only
|
||||||
|
- Focus on faithful template execution and clean output
|
||||||
|
- All template-specific instructions are embedded within templates
|
||||||
223
expansion-packs/expansion-creator/utils/workflow-management.md
Normal file
223
expansion-packs/expansion-creator/utils/workflow-management.md
Normal file
@@ -0,0 +1,223 @@
|
|||||||
|
# Workflow Management
|
||||||
|
|
||||||
|
This utility enables the BMAD orchestrator to manage and execute team workflows.
|
||||||
|
|
||||||
|
## Important: Dynamic Workflow Loading
|
||||||
|
|
||||||
|
The BMAD orchestrator MUST read the available workflows from the current team configuration's `workflows` field. Do not use hardcoded workflow lists. Each team bundle defines its own set of supported workflows based on the agents it includes.
|
||||||
|
|
||||||
|
**Critical Distinction**:
|
||||||
|
|
||||||
|
- When asked "what workflows are available?", show ONLY the workflows defined in the current team bundle's configuration
|
||||||
|
- Use `/agent-list` to show agents in the current bundle
|
||||||
|
- Use `/workflows` to show workflows in the current bundle, NOT any creation tasks
|
||||||
|
|
||||||
|
### Workflow Descriptions
|
||||||
|
|
||||||
|
When displaying workflows, use these descriptions based on the workflow ID:
|
||||||
|
|
||||||
|
- **greenfield-fullstack**: Build a new full-stack application from concept to development
|
||||||
|
- **brownfield-fullstack**: Enhance an existing full-stack application with new features
|
||||||
|
- **greenfield-service**: Build a new backend service or API from concept to development
|
||||||
|
- **brownfield-service**: Enhance an existing backend service or API
|
||||||
|
- **greenfield-ui**: Build a new frontend/UI application from concept to development
|
||||||
|
- **brownfield-ui**: Enhance an existing frontend/UI application
|
||||||
|
|
||||||
|
## Workflow Commands
|
||||||
|
|
||||||
|
### /workflows
|
||||||
|
|
||||||
|
Lists all available workflows for the current team. The available workflows are determined by the team configuration and may include workflows such as:
|
||||||
|
|
||||||
|
- greenfield-fullstack
|
||||||
|
- brownfield-fullstack
|
||||||
|
- greenfield-service
|
||||||
|
- brownfield-service
|
||||||
|
- greenfield-ui
|
||||||
|
- brownfield-ui
|
||||||
|
|
||||||
|
The actual list depends on which team bundle is loaded. When responding to this command, display the workflows that are configured in the current team's `workflows` field.
|
||||||
|
|
||||||
|
Example response format:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Available workflows for [Team Name]:
|
||||||
|
1. [workflow-id] - [Brief description based on workflow type]
|
||||||
|
2. [workflow-id] - [Brief description based on workflow type]
|
||||||
|
[... etc. ...]
|
||||||
|
|
||||||
|
Use /workflow-start {number or id} to begin a workflow.
|
||||||
|
```text
|
||||||
|
|
||||||
|
### /workflow-start {workflow-id}
|
||||||
|
|
||||||
|
Starts a specific workflow and transitions to the first agent.
|
||||||
|
|
||||||
|
Example: `/workflow-start greenfield-fullstack`
|
||||||
|
|
||||||
|
### /workflow-status
|
||||||
|
|
||||||
|
Shows current workflow progress, completed artifacts, and next steps.
|
||||||
|
|
||||||
|
Example response:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Current Workflow: Greenfield Full-Stack Development
|
||||||
|
Stage: Product Planning (2 of 6)
|
||||||
|
Completed:
|
||||||
|
✓ Discovery & Requirements
|
||||||
|
- project-brief (completed by Mary)
|
||||||
|
|
||||||
|
In Progress:
|
||||||
|
⚡ Product Planning
|
||||||
|
- Create PRD (John) - awaiting input
|
||||||
|
|
||||||
|
Next: Technical Architecture
|
||||||
|
```text
|
||||||
|
|
||||||
|
### /workflow-resume
|
||||||
|
|
||||||
|
Resumes a workflow from where it left off, useful when starting a new chat.
|
||||||
|
|
||||||
|
User can provide completed artifacts:
|
||||||
|
|
||||||
|
```text
|
||||||
|
User: /workflow-resume greenfield-fullstack
|
||||||
|
I have completed: project-brief, PRD
|
||||||
|
BMad: I see you've completed Discovery and part of Product Planning.
|
||||||
|
Based on the greenfield-fullstack workflow, the next step is:
|
||||||
|
- UX Strategy with Sally (ux-expert)
|
||||||
|
|
||||||
|
Would you like me to load Sally to continue?
|
||||||
|
```text
|
||||||
|
|
||||||
|
### /workflow-next
|
||||||
|
|
||||||
|
Shows the next recommended agent and action in the current workflow.
|
||||||
|
|
||||||
|
## Workflow Execution Flow
|
||||||
|
|
||||||
|
### 1. Starting a Workflow
|
||||||
|
|
||||||
|
When a workflow is started:
|
||||||
|
|
||||||
|
1. Load the workflow definition
|
||||||
|
2. Identify the first stage and step
|
||||||
|
3. Transition to the required agent
|
||||||
|
4. Provide context about expected inputs/outputs
|
||||||
|
5. Guide artifact creation
|
||||||
|
|
||||||
|
### 2. Stage Transitions
|
||||||
|
|
||||||
|
After each artifact is completed:
|
||||||
|
|
||||||
|
1. Mark the step as complete
|
||||||
|
2. Check transition conditions
|
||||||
|
3. If stage is complete, move to next stage
|
||||||
|
4. Load the appropriate agent
|
||||||
|
5. Pass relevant artifacts as context
|
||||||
|
|
||||||
|
### 3. Artifact Tracking
|
||||||
|
|
||||||
|
Track all created artifacts:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
workflow_state:
|
||||||
|
current_workflow: greenfield-fullstack
|
||||||
|
current_stage: planning
|
||||||
|
current_step: 2
|
||||||
|
artifacts:
|
||||||
|
project-brief:
|
||||||
|
status: completed
|
||||||
|
created_by: analyst
|
||||||
|
timestamp: 2024-01-15T10:30:00.000Z
|
||||||
|
prd:
|
||||||
|
status: in-progress
|
||||||
|
created_by: pm
|
||||||
|
started: 2024-01-15T11:00:00.000Z
|
||||||
|
```text
|
||||||
|
|
||||||
|
### 4. Workflow Interruption Handling
|
||||||
|
|
||||||
|
When user returns after interruption:
|
||||||
|
|
||||||
|
1. Ask if continuing previous workflow
|
||||||
|
2. Request any completed artifacts
|
||||||
|
3. Analyze provided artifacts
|
||||||
|
4. Determine workflow position
|
||||||
|
5. Suggest next appropriate step
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
```text
|
||||||
|
User: I'm working on a new app. Here's my PRD and architecture doc.
|
||||||
|
BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||||
|
it looks like you're following the greenfield-fullstack workflow and have completed
|
||||||
|
stages 1-3. The next recommended step would be:
|
||||||
|
|
||||||
|
Stage 4: Validation & Refinement
|
||||||
|
- Load Sarah (Product Owner) to validate all artifacts
|
||||||
|
|
||||||
|
Would you like to continue with this workflow?
|
||||||
|
```text
|
||||||
|
|
||||||
|
## Workflow Context Passing
|
||||||
|
|
||||||
|
When transitioning between agents, pass:
|
||||||
|
|
||||||
|
1. Previous artifacts created
|
||||||
|
2. Current workflow stage
|
||||||
|
3. Expected outputs
|
||||||
|
4. Any decisions or constraints identified
|
||||||
|
|
||||||
|
Example transition:
|
||||||
|
|
||||||
|
```text
|
||||||
|
BMad: Great! John has completed the PRD. According to the greenfield-fullstack workflow,
|
||||||
|
the next step is UX Strategy with Sally.
|
||||||
|
|
||||||
|
/ux-expert
|
||||||
|
|
||||||
|
Sally: I see we're in the Product Planning stage of the greenfield-fullstack workflow.
|
||||||
|
I have access to:
|
||||||
|
- Project Brief from Mary
|
||||||
|
- PRD from John
|
||||||
|
|
||||||
|
Let's create the UX strategy and UI specifications. First, let me review
|
||||||
|
the PRD to understand the features we're designing for...
|
||||||
|
```text
|
||||||
|
|
||||||
|
## Multi-Path Workflows
|
||||||
|
|
||||||
|
Some workflows may have multiple paths:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
conditional_paths:
|
||||||
|
- condition: project_type == 'mobile'
|
||||||
|
next_stage: mobile-specific-design
|
||||||
|
- condition: project_type == 'web'
|
||||||
|
next_stage: web-architecture
|
||||||
|
- default: fullstack-architecture
|
||||||
|
```
|
||||||
|
|
||||||
|
Handle these by asking clarifying questions when needed.
|
||||||
|
|
||||||
|
## Workflow Best Practices
|
||||||
|
|
||||||
|
1. **Always show progress** - Users should know where they are
|
||||||
|
2. **Explain transitions** - Why moving to next agent
|
||||||
|
3. **Preserve context** - Pass relevant information forward
|
||||||
|
4. **Allow flexibility** - Users can skip or modify steps
|
||||||
|
5. **Track everything** - Maintain complete workflow state
|
||||||
|
|
||||||
|
## Integration with Agents
|
||||||
|
|
||||||
|
Each agent should be workflow-aware:
|
||||||
|
|
||||||
|
- Know which workflow is active
|
||||||
|
- Understand their role in the workflow
|
||||||
|
- Access previous artifacts
|
||||||
|
- Know expected outputs
|
||||||
|
- Guide toward workflow goals
|
||||||
|
|
||||||
|
This creates a seamless experience where the entire team works together toward the workflow's objectives.
|
||||||
Reference in New Issue
Block a user