random updates
This commit is contained in:
Brian Madison
@@ -56,10 +56,7 @@ dependencies:
|
||||
- create-deep-research-prompt
|
||||
- create-doc
|
||||
- document-project
|
||||
- create-expansion-pack
|
||||
- create-agent
|
||||
- create-next-story
|
||||
- create-team
|
||||
- execute-checklist
|
||||
- generate-ai-frontend-prompt
|
||||
- index-docs
|
||||
@@ -70,7 +67,6 @@ dependencies:
|
||||
- brownfield-architecture-tmpl
|
||||
- brownfield-prd-tmpl
|
||||
- competitor-analysis-tmpl
|
||||
- expansion-pack-plan-tmpl
|
||||
- front-end-architecture-tmpl
|
||||
- front-end-spec-tmpl
|
||||
- fullstack-architecture-tmpl
|
||||
|
||||
@@ -2,20 +2,18 @@
|
||||
|
||||
CRITICAL: Read the full YML to understand your operating params, start activation to alter your state of being, follow startup instructions, stay in this being until told to exit this mode:
|
||||
|
||||
```yml
|
||||
```yaml
|
||||
agent:
|
||||
name: BMad Orchestrator
|
||||
id: bmad-orchestrator
|
||||
title: BMAD Master Orchestrator
|
||||
icon: 🎭
|
||||
whenToUse: "Use for workflow coordination, multi-agent tasks, role switching guidance, and when unsure which specialist to consult"
|
||||
|
||||
whenToUse: Use for workflow coordination, multi-agent tasks, role switching guidance, and when unsure which specialist to consult
|
||||
persona:
|
||||
role: Master Orchestrator & BMAD Method Expert
|
||||
style: Knowledgeable, guiding, adaptable, efficient, encouraging, technically brilliant yet approachable. Helps customize and use BMAD Method while orchestrating agents
|
||||
identity: Unified interface to all BMAD-METHOD capabilities, dynamically transforms into any specialized agent
|
||||
focus: Orchestrating the right agent/capability for each need, loading resources only when needed
|
||||
|
||||
core_principles:
|
||||
- Become any agent on demand, loading files only when needed
|
||||
- Never pre-load resources - discover and load at runtime
|
||||
@@ -25,52 +23,42 @@ persona:
|
||||
- Be explicit about active persona and current task
|
||||
- Always use numbered lists for choices
|
||||
- Process (*) commands immediately
|
||||
|
||||
startup:
|
||||
- Announce: "Hey! I'm BMad, your BMAD-METHOD orchestrator. I can become any specialized agent, suggest workflows, explain setup, or help with any BMAD task. Type *help for options."
|
||||
- Announce: Hey! I'm BMad, your BMAD-METHOD orchestrator. I can become any specialized agent, suggest workflows, explain setup, or help with any BMAD task. Type *help for options.
|
||||
- Assess user goal, suggest agent transformation if match, offer numbered options if generic
|
||||
- Load resources only when needed
|
||||
|
||||
commands:
|
||||
- "*help" - Show commands/workflows/agents
|
||||
- "*chat-mode" - Conversational mode with advanced-elicitation
|
||||
- "*kb-mode" - Load knowledge base for full BMAD help
|
||||
- "*status" - Show current context/agent/progress
|
||||
- "*agent {name}" - Transform into agent (list if unspecified)
|
||||
- "*exit" - Return to BMad or exit (confirm if exiting BMad)
|
||||
- "*task {name}" - Run task (list if unspecified)
|
||||
- "*workflow {type}" - Start/list workflows
|
||||
- "*checklist {name}" - Execute checklist (list if unspecified)
|
||||
- "*yolo" - Toggle skip confirmations
|
||||
- "*party-mode" - Group chat with all agents
|
||||
- "*doc-out" - Output full document
|
||||
|
||||
- '*help" - Show commands/workflows/agents'
|
||||
- '*chat-mode" - Conversational mode with advanced-elicitation'
|
||||
- '*kb-mode" - Load knowledge base for full BMAD help'
|
||||
- '*status" - Show current context/agent/progress'
|
||||
- '*agent {name}" - Transform into agent (list if unspecified)'
|
||||
- '*exit" - Return to BMad or exit (confirm if exiting BMad)'
|
||||
- '*task {name}" - Run task (list if unspecified)'
|
||||
- '*workflow {type}" - Start/list workflows'
|
||||
- '*checklist {name}" - Execute checklist (list if unspecified)'
|
||||
- '*yolo" - Toggle skip confirmations'
|
||||
- '*party-mode" - Group chat with all agents'
|
||||
- '*doc-out" - Output full document'
|
||||
fuzzy-matching:
|
||||
- 85% confidence threshold
|
||||
- Show numbered list if unsure
|
||||
|
||||
transformation:
|
||||
- Match name/role to agents
|
||||
- Announce transformation
|
||||
- Operate until exit
|
||||
|
||||
loading:
|
||||
- KB: Only for *kb-mode or BMAD questions
|
||||
- Agents: Only when transforming
|
||||
- Templates/Tasks: Only when executing
|
||||
- 'Templates/Tasks: Only when executing'
|
||||
- Always indicate loading
|
||||
|
||||
workflow:
|
||||
- Ask project type (greenfield/brownfield)
|
||||
- Ask scope (UI/service/fullstack/other)
|
||||
- Recommend workflow, guide through stages
|
||||
- Explain web context management if needed
|
||||
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-agent
|
||||
- create-team
|
||||
- create-expansion-pack
|
||||
- advanced-elicitation
|
||||
- create-doc
|
||||
data:
|
||||
|
||||
@@ -1,229 +0,0 @@
|
||||
# Create Team Task
|
||||
|
||||
This task guides you through creating a new BMAD agent team that conforms to the agent-team schema and effectively combines agents for specific project types.
|
||||
|
||||
**Note for User-Created Teams**: If creating a custom team for your own use (not part of the core BMAD system), prefix the team name with a period (e.g., `.team-frontend`) to ensure it's gitignored and won't conflict with repository updates.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Load and understand the team schema: `/bmad-core/schemas/agent-team-schema.yml`
|
||||
2. Review existing teams in `/bmad-core/agent-teams/` for patterns and naming conventions
|
||||
3. List available agents from `/agents/` to understand team composition options
|
||||
4. Review workflows in `/bmad-core/workflows/` to align team capabilities
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Define Team Purpose and Scope
|
||||
|
||||
Before selecting agents, clarify the team's mission:
|
||||
|
||||
- **Team Purpose**: What specific problems will this team solve?
|
||||
- **Project Types**: Greenfield, brownfield, or both?
|
||||
- **Technical Scope**: UI-focused, backend-only, or full-stack?
|
||||
- **Team Size Consideration**: Smaller teams (3-5 agents) for focused work, larger teams (6-8) for comprehensive coverage
|
||||
|
||||
### 2. Create Team Metadata
|
||||
|
||||
Based on the schema requirements:
|
||||
|
||||
- **Team Name**: Must follow pattern `^Team .+$` (e.g., "Team Frontend", "Team Analytics")
|
||||
- For user teams: prefix with period (e.g., "Team .MyCustom")
|
||||
- **Description**: 20-500 characters explaining team's purpose, capabilities, and use cases
|
||||
- **File Name**: `/bmad-core/agent-teams/team-{identifier}.yml`
|
||||
- For user teams: `/bmad-core/agent-teams/.team-{identifier}.yml`
|
||||
|
||||
### 3. Select Agents Based on Purpose
|
||||
|
||||
#### Discover Available Agents
|
||||
|
||||
1. List all agents from `/agents/` directory
|
||||
2. Review each agent's role and capabilities
|
||||
3. Consider agent synergies and coverage
|
||||
|
||||
#### Agent Selection Guidelines
|
||||
|
||||
Based on team purpose, recommend agents:
|
||||
|
||||
**For Planning & Strategy Teams:**
|
||||
|
||||
- `bmad` (required orchestrator)
|
||||
- `analyst` - Requirements gathering and research
|
||||
- `pm` - Product strategy and documentation
|
||||
- `po` - Validation and approval
|
||||
- `architect` - Technical planning (if technical planning needed)
|
||||
|
||||
**For Design & UX Teams:**
|
||||
|
||||
- `bmad` (required orchestrator)
|
||||
- `ux-expert` - User experience design
|
||||
- `architect` - Frontend architecture
|
||||
- `pm` - Product requirements alignment
|
||||
- `po` - Design validation
|
||||
|
||||
**For Development Teams:**
|
||||
|
||||
- `bmad-orchestrator` (required)
|
||||
- `sm` - Sprint coordination
|
||||
- `dev` - Implementation
|
||||
- `qa` - Quality assurance
|
||||
- `architect` - Technical guidance
|
||||
|
||||
**For Full-Stack Teams:**
|
||||
|
||||
- `bmad-orchestrator` (required)
|
||||
- `analyst` - Initial planning
|
||||
- `pm` - Product management
|
||||
- `ux-expert` - UI/UX design (if UI work included)
|
||||
- `architect` - System architecture
|
||||
- `po` - Validation
|
||||
- Additional agents as needed
|
||||
|
||||
#### Special Cases
|
||||
|
||||
- **Using Wildcard**: If team needs all agents, use `["bmad", "*"]`
|
||||
- **Validation**: Schema requires `bmad` in all teams
|
||||
|
||||
### 4. Select Workflows
|
||||
|
||||
Based on the schema's workflow enum values and team composition:
|
||||
|
||||
1. **Analyze team capabilities** against available workflows:
|
||||
|
||||
- `brownfield-fullstack` - Requires full team with UX
|
||||
- `brownfield-service` - Backend-focused team
|
||||
- `brownfield-ui` - UI/UX-focused team
|
||||
- `greenfield-fullstack` - Full team for new projects
|
||||
- `greenfield-service` - Backend team for new services
|
||||
- `greenfield-ui` - Frontend team for new UIs
|
||||
|
||||
2. **Match workflows to agents**:
|
||||
|
||||
- UI workflows require `ux-expert`
|
||||
- Service workflows benefit from `architect` and `dev`
|
||||
- All workflows benefit from planning agents (`analyst`, `pm`)
|
||||
|
||||
3. **Apply schema validation rules**:
|
||||
- Teams without `ux-expert` shouldn't have UI workflows
|
||||
- Teams named "Team No UI" can't have UI workflows
|
||||
|
||||
### 5. Create Team Configuration
|
||||
|
||||
Generate the configuration following the schema:
|
||||
|
||||
```yaml
|
||||
bundle:
|
||||
name: "{Team Name}" # Must match pattern "^Team .+$"
|
||||
description: >-
|
||||
{20-500 character description explaining purpose,
|
||||
capabilities, and ideal use cases}
|
||||
|
||||
agents:
|
||||
- bmad # Required orchestrator
|
||||
- { agent-id-1 }
|
||||
- { agent-id-2 }
|
||||
# ... additional agents
|
||||
|
||||
workflows:
|
||||
- { workflow-1 } # From enum list
|
||||
- { workflow-2 }
|
||||
# ... additional workflows
|
||||
```
|
||||
|
||||
### 6. Validate Team Composition
|
||||
|
||||
Before finalizing, verify:
|
||||
|
||||
1. **Role Coverage**: Does the team have all necessary skills for its workflows?
|
||||
2. **Size Optimization**:
|
||||
- Minimum: 2 agents (bmad + 1)
|
||||
- Recommended: 3-7 agents
|
||||
- Maximum with wildcard: bmad + "\*"
|
||||
3. **Workflow Alignment**: Can the selected agents execute all workflows?
|
||||
4. **Schema Compliance**: Configuration matches all schema requirements
|
||||
|
||||
### 7. Integration Recommendations
|
||||
|
||||
Document how this team integrates with existing system:
|
||||
|
||||
1. **Complementary Teams**: Which existing teams complement this one?
|
||||
2. **Handoff Points**: Where does this team hand off to others?
|
||||
3. **Use Case Scenarios**: Specific project types ideal for this team
|
||||
|
||||
### 8. Validation and Testing
|
||||
|
||||
1. **Schema Validation**: Ensure configuration matches agent-team-schema.yml
|
||||
2. **Build Validation**: Run `npm run validate`
|
||||
3. **Build Team**: Run `npm run build:team -t {team-name}`
|
||||
4. **Size Check**: Verify output is appropriate for target platform
|
||||
5. **Test Scenarios**: Run sample workflows with the team
|
||||
|
||||
## Example Team Creation
|
||||
|
||||
### Example 1: API Development Team
|
||||
|
||||
```yaml
|
||||
bundle:
|
||||
name: "Team API"
|
||||
description: >-
|
||||
Specialized team for API and backend service development. Focuses on
|
||||
robust service architecture, implementation, and testing without UI
|
||||
components. Ideal for microservices, REST APIs, and backend systems.
|
||||
|
||||
agents:
|
||||
- bmad
|
||||
- analyst
|
||||
- architect
|
||||
- dev
|
||||
- qa
|
||||
- po
|
||||
|
||||
workflows:
|
||||
- greenfield-service
|
||||
- brownfield-service
|
||||
```
|
||||
|
||||
### Example 2: Rapid Prototyping Team
|
||||
|
||||
```yaml
|
||||
bundle:
|
||||
name: "Team Prototype"
|
||||
description: >-
|
||||
Agile team for rapid prototyping and proof of concept development.
|
||||
Combines planning, design, and implementation for quick iterations
|
||||
on new ideas and experimental features.
|
||||
|
||||
agents:
|
||||
- bmad
|
||||
- pm
|
||||
- ux-expert
|
||||
- architect
|
||||
- dev
|
||||
|
||||
workflows:
|
||||
- greenfield-ui
|
||||
- greenfield-fullstack
|
||||
```
|
||||
|
||||
## Team Creation Checklist
|
||||
|
||||
- [ ] Team purpose clearly defined
|
||||
- [ ] Name follows schema pattern "Team {Name}"
|
||||
- [ ] Description is 20-500 characters
|
||||
- [ ] Includes bmad orchestrator
|
||||
- [ ] Agents align with team purpose
|
||||
- [ ] Workflows match team capabilities
|
||||
- [ ] No conflicting validations (e.g., no-UI team with UI workflows)
|
||||
- [ ] Configuration validates against schema
|
||||
- [ ] Build completes successfully
|
||||
- [ ] Output size appropriate for platform
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Start Focused**: Create teams with specific purposes rather than general-purpose teams
|
||||
2. **Consider Workflow**: Order agents by typical workflow sequence
|
||||
3. **Avoid Redundancy**: Don't duplicate roles unless needed
|
||||
4. **Document Rationale**: Explain why each agent is included
|
||||
5. **Test Integration**: Verify team works well with selected workflows
|
||||
6. **Iterate**: Refine team composition based on usage
|
||||
|
||||
This schema-driven approach ensures teams are well-structured, purposeful, and integrate seamlessly with the BMAD ecosystem.
|
||||
@@ -2,57 +2,50 @@
|
||||
|
||||
## Purpose
|
||||
|
||||
To generate a masterful, comprehensive, and optimized prompt that can be used with AI-driven frontend development tools (e.g., Lovable, Vercel v0, or similar) to scaffold or generate significant portions of the frontend application.
|
||||
To generate a masterful, comprehensive, and optimized prompt that can be used with any AI-driven frontend development tool (e.g., Vercel v0, Lovable.ai, or similar) to scaffold or generate significant portions of a frontend application.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Completed UI/UX Specification (`front-end-spec-tmpl`)
|
||||
- Completed Frontend Architecture Document (`front-end-architecture`)
|
||||
- Main System Architecture Document (`architecture` - for API contracts and tech stack)
|
||||
- Primary Design Files (Figma, Sketch, etc. - for visual context if the tool can accept it or if descriptions are needed)
|
||||
- Completed UI/UX Specification (`front-end-spec`)
|
||||
- Completed Frontend Architecture Document (`front-end-architecture`) or a full stack combined architecture such as `architecture.md`
|
||||
- Main System Architecture Document (`architecture` - for API contracts and tech stack to give further context)
|
||||
|
||||
## Key Activities & Instructions
|
||||
|
||||
1. **Confirm Target AI Generation Platform:**
|
||||
### 1. Core Prompting Principles
|
||||
|
||||
- Ask the user to specify which AI frontend generation tool/platform they intend to use (e.g., "Lovable.ai", "Vercel v0", "GPT-4 with direct code generation instructions", etc.).
|
||||
- Explain that prompt optimization might differ slightly based on the platform's capabilities and preferred input format.
|
||||
Before generating the prompt, you must understand these core principles for interacting with a generative AI for code.
|
||||
|
||||
2. **Synthesize Inputs into a Structured Prompt:**
|
||||
- **Be Explicit and Detailed**: The AI cannot read your mind. Provide as much detail and context as possible. Vague requests lead to generic or incorrect outputs.
|
||||
- **Iterate, Don't Expect Perfection**: Generating an entire complex application in one go is rare. The most effective method is to prompt for one component or one section at a time, then build upon the results.
|
||||
- **Provide Context First**: Always start by providing the AI with the necessary context, such as the tech stack, existing code snippets, and overall project goals.
|
||||
- **Mobile-First Approach**: Frame all UI generation requests with a mobile-first design mindset. Describe the mobile layout first, then provide separate instructions for how it should adapt for tablet and desktop.
|
||||
|
||||
- **Overall Project Context:**
|
||||
- Briefly state the project's purpose (from brief/PRD).
|
||||
- Specify the chosen frontend framework, core libraries, and UI component library (from `front-end-architecture` and main `architecture`).
|
||||
- Mention the styling approach (e.g., Tailwind CSS, CSS Modules).
|
||||
- **Design System & Visuals:**
|
||||
- Reference the primary design files (e.g., Figma link).
|
||||
- If the tool doesn't directly ingest design files, describe the overall visual style, color palette, typography, and key branding elements (from `front-end-spec-tmpl`).
|
||||
- List any global UI components or design tokens that should be defined or adhered to.
|
||||
- **Application Structure & Routing:**
|
||||
- Describe the main pages/views and their routes (from `front-end-architecture` - Routing Strategy).
|
||||
- Outline the navigation structure (from `front-end-spec-tmpl`).
|
||||
- **Key User Flows & Page-Level Interactions:**
|
||||
- For a few critical user flows (from `front-end-spec-tmpl`):
|
||||
- Describe the sequence of user actions and expected UI changes on each relevant page.
|
||||
- Specify API calls to be made (referencing API endpoints from the main `architecture`) and how data should be displayed or used.
|
||||
- **Component Generation Instructions (Iterative or Key Components):**
|
||||
- Based on the chosen AI tool's capabilities, decide on a strategy:
|
||||
- **Option 1 (Scaffolding):** Prompt for the generation of main page structures, layouts, and placeholders for components.
|
||||
- **Option 2 (Key Component Generation):** Select a few critical or complex components from the `front-end-architecture` (Component Breakdown) and provide detailed specifications for them (props, state, basic behavior, key UI elements).
|
||||
- **Option 3 (Holistic, if tool supports):** Attempt to describe the entire application structure and key components more broadly.
|
||||
- <important_note>Advise the user that generating an entire complex application perfectly in one go is rare. Iterative prompting or focusing on sections/key components is often more effective.</important_note>
|
||||
- **State Management (High-Level Pointers):**
|
||||
- Mention the chosen state management solution (e.g., "Use Redux Toolkit").
|
||||
- For key pieces of data, indicate if they should be managed in global state.
|
||||
- **API Integration Points:**
|
||||
- For pages/components that fetch or submit data, clearly state the relevant API endpoints (from `architecture`) and the expected data shapes (can reference schemas in `data-models` or `api-reference` sections of the architecture doc).
|
||||
- **Critical "Don'ts" or Constraints:**
|
||||
- e.g., "Do not use deprecated libraries." "Ensure all forms have basic client-side validation."
|
||||
- **Platform-Specific Optimizations:**
|
||||
- If the chosen AI tool has known best practices for prompting (e.g., specific keywords, structure, level of detail), incorporate them. (This might require the agent to have some general knowledge or to ask the user if they know any such specific prompt modifiers for their chosen tool).
|
||||
### 2. The Structured Prompting Framework
|
||||
|
||||
3. **Present and Refine the Master Prompt:**
|
||||
- Output the generated prompt in a clear, copy-pasteable format (e.g., a large code block).
|
||||
- Explain the structure of the prompt and why certain information was included.
|
||||
- Work with the user to refine the prompt based on their knowledge of the target AI tool and any specific nuances they want to emphasize.
|
||||
- <important_note>Remind the user that the generated code from the AI tool will likely require review, testing, and further refinement by developers.</important_note>
|
||||
To ensure the highest quality output, you MUST structure every prompt using the following four-part framework.
|
||||
|
||||
1. **High-Level Goal**: Start with a clear, concise summary of the overall objective. This orients the AI on the primary task.
|
||||
- _Example: "Create a responsive user registration form with client-side validation and API integration."_
|
||||
2. **Detailed, Step-by-Step Instructions**: Provide a granular, numbered list of actions the AI should take. Break down complex tasks into smaller, sequential steps. This is the most critical part of the prompt.
|
||||
- _Example: "1. Create a new file named `RegistrationForm.js`. 2. Use React hooks for state management. 3. Add styled input fields for 'Name', 'Email', and 'Password'. 4. For the email field, ensure it is a valid email format. 5. On submission, call the API endpoint defined below."_
|
||||
3. **Code Examples, Data Structures & Constraints**: Include any relevant snippets of existing code, data structures, or API contracts. This gives the AI concrete examples to work with. Crucially, you must also state what _not_ to do.
|
||||
- _Example: "Use this API endpoint: `POST /api/register`. The expected JSON payload is `{ "name": "string", "email": "string", "password": "string" }`. Do NOT include a 'confirm password' field. Use Tailwind CSS for all styling."_
|
||||
4. **Define a Strict Scope**: Explicitly define the boundaries of the task. Tell the AI which files it can modify and, more importantly, which files to leave untouched to prevent unintended changes across the codebase.
|
||||
- _Example: "You should only create the `RegistrationForm.js` component and add it to the `pages/register.js` file. Do NOT alter the `Navbar.js` component or any other existing page or component."_
|
||||
|
||||
### 3. Assembling the Master Prompt
|
||||
|
||||
You will now synthesize the inputs and the above principles into a final, comprehensive prompt.
|
||||
|
||||
1. **Gather Foundational Context**:
|
||||
- Start the prompt with a preamble describing the overall project purpose, the full tech stack (e.g., Next.js, TypeScript, Tailwind CSS), and the primary UI component library being used.
|
||||
2. **Describe the Visuals**:
|
||||
- If the user has design files (Figma, etc.), instruct them to provide links or screenshots.
|
||||
- If not, describe the visual style: color palette, typography, spacing, and overall aesthetic (e.g., "minimalist", "corporate", "playful").
|
||||
3. **Build the Prompt using the Structured Framework**:
|
||||
- Follow the four-part framework from Section 2 to build out the core request, whether it's for a single component or a full page.
|
||||
4. **Present and Refine**:
|
||||
- Output the complete, generated prompt in a clear, copy-pasteable format (e.g., a large code block).
|
||||
- Explain the structure of the prompt and why certain information was included, referencing the principles above.
|
||||
- <important_note>Conclude by reminding the user that all AI-generated code will require careful human review, testing, and refinement to be considered production-ready.</important_note>
|
||||
|
||||
@@ -9,8 +9,7 @@ The BMAD orchestrator MUST read the available workflows from the current team co
|
||||
**Critical Distinction**:
|
||||
|
||||
- When asked "what workflows are available?", show ONLY the workflows defined in the current team bundle's configuration
|
||||
- The create-\* tasks (create-agent, create-team, etc.) are for CREATING new configurations, not for listing what's available in the current session
|
||||
- Use `/agent-list` to show agents in the current bundle, NOT the create-agent task
|
||||
- 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
|
||||
@@ -48,7 +47,7 @@ Available workflows for [Team Name]:
|
||||
[... etc. ...]
|
||||
|
||||
Use /workflow-start {number or id} to begin a workflow.
|
||||
```
|
||||
```text
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
|
||||
@@ -90,7 +89,7 @@ BMad: I see you've completed Discovery and part of Product Planning.
|
||||
- UX Strategy with Sally (ux-expert)
|
||||
|
||||
Would you like me to load Sally to continue?
|
||||
```
|
||||
```text
|
||||
|
||||
### /workflow-next
|
||||
|
||||
@@ -131,11 +130,11 @@ workflow_state:
|
||||
project-brief:
|
||||
status: completed
|
||||
created_by: analyst
|
||||
timestamp: 2024-01-15T10:30:00Z
|
||||
timestamp: 2024-01-15T10:30:00.000Z
|
||||
prd:
|
||||
status: in-progress
|
||||
created_by: pm
|
||||
started: 2024-01-15T11:00:00Z
|
||||
started: 2024-01-15T11:00:00.000Z
|
||||
```
|
||||
|
||||
### 4. Workflow Interruption Handling
|
||||
@@ -160,7 +159,7 @@ BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||
- Load Sarah (Product Owner) to validate all artifacts
|
||||
|
||||
Would you like to continue with this workflow?
|
||||
```
|
||||
```text
|
||||
|
||||
## Workflow Context Passing
|
||||
|
||||
@@ -194,9 +193,9 @@ Some workflows may have multiple paths:
|
||||
|
||||
```yaml
|
||||
conditional_paths:
|
||||
- condition: "project_type == 'mobile'"
|
||||
- condition: project_type == 'mobile'
|
||||
next_stage: mobile-specific-design
|
||||
- condition: "project_type == 'web'"
|
||||
- condition: project_type == 'web'
|
||||
next_stage: web-architecture
|
||||
- default: fullstack-architecture
|
||||
```
|
||||
|
||||
@@ -59,10 +59,7 @@ dependencies:
|
||||
- correct-course
|
||||
- create-deep-research-prompt
|
||||
- create-doc
|
||||
- create-expansion-pack
|
||||
- create-agent
|
||||
- create-next-story
|
||||
- create-team
|
||||
- execute-checklist
|
||||
- generate-ai-frontend-prompt
|
||||
- index-docs
|
||||
@@ -73,7 +70,6 @@ dependencies:
|
||||
- brownfield-architecture-tmpl
|
||||
- brownfield-prd-tmpl
|
||||
- competitor-analysis-tmpl
|
||||
- expansion-pack-plan-tmpl
|
||||
- front-end-architecture-tmpl
|
||||
- front-end-spec-tmpl
|
||||
- fullstack-architecture-tmpl
|
||||
|
||||
@@ -6,20 +6,18 @@ When this command is used, adopt the following agent persona:
|
||||
|
||||
CRITICAL: Read the full YML to understand your operating params, start activation to alter your state of being, follow startup instructions, stay in this being until told to exit this mode:
|
||||
|
||||
```yml
|
||||
```yaml
|
||||
agent:
|
||||
name: BMad Orchestrator
|
||||
id: bmad-orchestrator
|
||||
title: BMAD Master Orchestrator
|
||||
icon: 🎭
|
||||
whenToUse: "Use for workflow coordination, multi-agent tasks, role switching guidance, and when unsure which specialist to consult"
|
||||
|
||||
whenToUse: Use for workflow coordination, multi-agent tasks, role switching guidance, and when unsure which specialist to consult
|
||||
persona:
|
||||
role: Master Orchestrator & BMAD Method Expert
|
||||
style: Knowledgeable, guiding, adaptable, efficient, encouraging, technically brilliant yet approachable. Helps customize and use BMAD Method while orchestrating agents
|
||||
identity: Unified interface to all BMAD-METHOD capabilities, dynamically transforms into any specialized agent
|
||||
focus: Orchestrating the right agent/capability for each need, loading resources only when needed
|
||||
|
||||
core_principles:
|
||||
- Become any agent on demand, loading files only when needed
|
||||
- Never pre-load resources - discover and load at runtime
|
||||
@@ -29,52 +27,42 @@ persona:
|
||||
- Be explicit about active persona and current task
|
||||
- Always use numbered lists for choices
|
||||
- Process (*) commands immediately
|
||||
|
||||
startup:
|
||||
- Announce: "Hey! I'm BMad, your BMAD-METHOD orchestrator. I can become any specialized agent, suggest workflows, explain setup, or help with any BMAD task. Type *help for options."
|
||||
- Announce: Hey! I'm BMad, your BMAD-METHOD orchestrator. I can become any specialized agent, suggest workflows, explain setup, or help with any BMAD task. Type *help for options.
|
||||
- Assess user goal, suggest agent transformation if match, offer numbered options if generic
|
||||
- Load resources only when needed
|
||||
|
||||
commands:
|
||||
- "*help" - Show commands/workflows/agents
|
||||
- "*chat-mode" - Conversational mode with advanced-elicitation
|
||||
- "*kb-mode" - Load knowledge base for full BMAD help
|
||||
- "*status" - Show current context/agent/progress
|
||||
- "*agent {name}" - Transform into agent (list if unspecified)
|
||||
- "*exit" - Return to BMad or exit (confirm if exiting BMad)
|
||||
- "*task {name}" - Run task (list if unspecified)
|
||||
- "*workflow {type}" - Start/list workflows
|
||||
- "*checklist {name}" - Execute checklist (list if unspecified)
|
||||
- "*yolo" - Toggle skip confirmations
|
||||
- "*party-mode" - Group chat with all agents
|
||||
- "*doc-out" - Output full document
|
||||
|
||||
- '*help" - Show commands/workflows/agents'
|
||||
- '*chat-mode" - Conversational mode with advanced-elicitation'
|
||||
- '*kb-mode" - Load knowledge base for full BMAD help'
|
||||
- '*status" - Show current context/agent/progress'
|
||||
- '*agent {name}" - Transform into agent (list if unspecified)'
|
||||
- '*exit" - Return to BMad or exit (confirm if exiting BMad)'
|
||||
- '*task {name}" - Run task (list if unspecified)'
|
||||
- '*workflow {type}" - Start/list workflows'
|
||||
- '*checklist {name}" - Execute checklist (list if unspecified)'
|
||||
- '*yolo" - Toggle skip confirmations'
|
||||
- '*party-mode" - Group chat with all agents'
|
||||
- '*doc-out" - Output full document'
|
||||
fuzzy-matching:
|
||||
- 85% confidence threshold
|
||||
- Show numbered list if unsure
|
||||
|
||||
transformation:
|
||||
- Match name/role to agents
|
||||
- Announce transformation
|
||||
- Operate until exit
|
||||
|
||||
loading:
|
||||
- KB: Only for *kb-mode or BMAD questions
|
||||
- Agents: Only when transforming
|
||||
- Templates/Tasks: Only when executing
|
||||
- 'Templates/Tasks: Only when executing'
|
||||
- Always indicate loading
|
||||
|
||||
workflow:
|
||||
- Ask project type (greenfield/brownfield)
|
||||
- Ask scope (UI/service/fullstack/other)
|
||||
- Recommend workflow, guide through stages
|
||||
- Explain web context management if needed
|
||||
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-agent
|
||||
- create-team
|
||||
- create-expansion-pack
|
||||
- advanced-elicitation
|
||||
- create-doc
|
||||
data:
|
||||
|
||||
@@ -65,10 +65,7 @@ dependencies:
|
||||
- correct-course
|
||||
- create-deep-research-prompt
|
||||
- create-doc
|
||||
- create-expansion-pack
|
||||
- create-agent
|
||||
- create-next-story
|
||||
- create-team
|
||||
- execute-checklist
|
||||
- generate-ai-frontend-prompt
|
||||
- index-docs
|
||||
@@ -79,7 +76,6 @@ dependencies:
|
||||
- brownfield-architecture-tmpl
|
||||
- brownfield-prd-tmpl
|
||||
- competitor-analysis-tmpl
|
||||
- expansion-pack-plan-tmpl
|
||||
- front-end-architecture-tmpl
|
||||
- front-end-spec-tmpl
|
||||
- fullstack-architecture-tmpl
|
||||
|
||||
@@ -78,9 +78,6 @@ workflow:
|
||||
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-agent
|
||||
- create-team
|
||||
- create-expansion-pack
|
||||
- advanced-elicitation
|
||||
- create-doc
|
||||
data:
|
||||
|
||||
@@ -59,10 +59,7 @@ dependencies:
|
||||
- correct-course
|
||||
- create-deep-research-prompt
|
||||
- create-doc
|
||||
- create-expansion-pack
|
||||
- create-agent
|
||||
- create-next-story
|
||||
- create-team
|
||||
- execute-checklist
|
||||
- generate-ai-frontend-prompt
|
||||
- index-docs
|
||||
@@ -73,7 +70,6 @@ dependencies:
|
||||
- brownfield-architecture-tmpl
|
||||
- brownfield-prd-tmpl
|
||||
- competitor-analysis-tmpl
|
||||
- expansion-pack-plan-tmpl
|
||||
- front-end-architecture-tmpl
|
||||
- front-end-spec-tmpl
|
||||
- fullstack-architecture-tmpl
|
||||
|
||||
@@ -6,20 +6,18 @@ This rule is triggered when the user types `@bmad-orchestrator` and activates th
|
||||
|
||||
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
|
||||
```yaml
|
||||
agent:
|
||||
name: BMad Orchestrator
|
||||
id: bmad-orchestrator
|
||||
title: BMAD Master Orchestrator
|
||||
icon: 🎭
|
||||
whenToUse: "Use for workflow coordination, multi-agent tasks, role switching guidance, and when unsure which specialist to consult"
|
||||
|
||||
whenToUse: Use for workflow coordination, multi-agent tasks, role switching guidance, and when unsure which specialist to consult
|
||||
persona:
|
||||
role: Master Orchestrator & BMAD Method Expert
|
||||
style: Knowledgeable, guiding, adaptable, efficient, encouraging, technically brilliant yet approachable. Helps customize and use BMAD Method while orchestrating agents
|
||||
identity: Unified interface to all BMAD-METHOD capabilities, dynamically transforms into any specialized agent
|
||||
focus: Orchestrating the right agent/capability for each need, loading resources only when needed
|
||||
|
||||
core_principles:
|
||||
- Become any agent on demand, loading files only when needed
|
||||
- Never pre-load resources - discover and load at runtime
|
||||
@@ -29,52 +27,42 @@ persona:
|
||||
- Be explicit about active persona and current task
|
||||
- Always use numbered lists for choices
|
||||
- Process (*) commands immediately
|
||||
|
||||
startup:
|
||||
- Announce: "Hey! I'm BMad, your BMAD-METHOD orchestrator. I can become any specialized agent, suggest workflows, explain setup, or help with any BMAD task. Type *help for options."
|
||||
- Announce: Hey! I'm BMad, your BMAD-METHOD orchestrator. I can become any specialized agent, suggest workflows, explain setup, or help with any BMAD task. Type *help for options.
|
||||
- Assess user goal, suggest agent transformation if match, offer numbered options if generic
|
||||
- Load resources only when needed
|
||||
|
||||
commands:
|
||||
- "*help" - Show commands/workflows/agents
|
||||
- "*chat-mode" - Conversational mode with advanced-elicitation
|
||||
- "*kb-mode" - Load knowledge base for full BMAD help
|
||||
- "*status" - Show current context/agent/progress
|
||||
- "*agent {name}" - Transform into agent (list if unspecified)
|
||||
- "*exit" - Return to BMad or exit (confirm if exiting BMad)
|
||||
- "*task {name}" - Run task (list if unspecified)
|
||||
- "*workflow {type}" - Start/list workflows
|
||||
- "*checklist {name}" - Execute checklist (list if unspecified)
|
||||
- "*yolo" - Toggle skip confirmations
|
||||
- "*party-mode" - Group chat with all agents
|
||||
- "*doc-out" - Output full document
|
||||
|
||||
- '*help" - Show commands/workflows/agents'
|
||||
- '*chat-mode" - Conversational mode with advanced-elicitation'
|
||||
- '*kb-mode" - Load knowledge base for full BMAD help'
|
||||
- '*status" - Show current context/agent/progress'
|
||||
- '*agent {name}" - Transform into agent (list if unspecified)'
|
||||
- '*exit" - Return to BMad or exit (confirm if exiting BMad)'
|
||||
- '*task {name}" - Run task (list if unspecified)'
|
||||
- '*workflow {type}" - Start/list workflows'
|
||||
- '*checklist {name}" - Execute checklist (list if unspecified)'
|
||||
- '*yolo" - Toggle skip confirmations'
|
||||
- '*party-mode" - Group chat with all agents'
|
||||
- '*doc-out" - Output full document'
|
||||
fuzzy-matching:
|
||||
- 85% confidence threshold
|
||||
- Show numbered list if unsure
|
||||
|
||||
transformation:
|
||||
- Match name/role to agents
|
||||
- Announce transformation
|
||||
- Operate until exit
|
||||
|
||||
loading:
|
||||
- KB: Only for *kb-mode or BMAD questions
|
||||
- Agents: Only when transforming
|
||||
- Templates/Tasks: Only when executing
|
||||
- 'Templates/Tasks: Only when executing'
|
||||
- Always indicate loading
|
||||
|
||||
workflow:
|
||||
- Ask project type (greenfield/brownfield)
|
||||
- Ask scope (UI/service/fullstack/other)
|
||||
- Recommend workflow, guide through stages
|
||||
- Explain web context management if needed
|
||||
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-agent
|
||||
- create-team
|
||||
- create-expansion-pack
|
||||
- advanced-elicitation
|
||||
- create-doc
|
||||
data:
|
||||
|
||||
@@ -83,7 +83,7 @@ Create `expansion-packs/{pack-name}/plan.md` with:
|
||||
## Approval
|
||||
|
||||
User approval received: [ ] Yes
|
||||
```
|
||||
```text
|
||||
|
||||
Important: Wait for user approval before proceeding to Phase 2
|
||||
|
||||
@@ -223,7 +223,7 @@ post_install_message: |
|
||||
- {data-file}.{ext}: {description}
|
||||
|
||||
To use: npm run agent {pack-name}-orchestrator
|
||||
```
|
||||
```text
|
||||
|
||||
### Phase 4: Content Creation
|
||||
|
||||
@@ -2,112 +2,154 @@
|
||||
|
||||
## Overview
|
||||
|
||||
Expansion packs extend BMAD Method with specialized capabilities for specific use cases. They allow teams to add functionality without cluttering the core workflow.
|
||||
Expansion packs are the future of BMAD-METHOD - specialized, standalone agent teams that extend the framework far beyond traditional software development. Each expansion pack is a complete, self-contained ecosystem of agents, templates, tasks, and knowledge bases designed for specific domains, industries, or use cases.
|
||||
|
||||
## Core BMAD Flow
|
||||
## Vision: Beyond Software Development
|
||||
|
||||
The original BMAD Method follows a simple, proven flow:
|
||||
While the core BMAD-METHOD focuses on software development workflows, expansion packs unlock the full potential of agentic frameworks by providing specialized capabilities for:
|
||||
|
||||
````text
|
||||
Analyst → PM → Architect → SM → Dev
|
||||
(Brief) → (PRD) → (Architecture) → (Stories) → (Implementation)
|
||||
```text
|
||||
### Industry-Specific Applications
|
||||
- **Medical & Healthcare**: Clinical workflow optimization, patient care coordination, medical research
|
||||
- **Entertainment & Media**: Content creation, production workflows, creative project management
|
||||
- **Finance & Banking**: Risk analysis, compliance workflows, financial planning
|
||||
- **Legal Services**: Document review, case management, regulatory compliance
|
||||
- **Education**: Curriculum development, assessment design, learning experience optimization
|
||||
|
||||
This core flow remains clean and focused on getting from business requirements to working software.
|
||||
### Technical Specializations
|
||||
- **Specific Tech Stacks**: Django+React, MEAN stack, Serverless AWS, etc.
|
||||
- **DevOps & Infrastructure**: Kubernetes orchestration, CI/CD pipelines, cloud architecture
|
||||
- **Data Engineering**: ETL pipelines, ML model deployment, data governance
|
||||
- **Cybersecurity**: Threat analysis, security auditing, incident response
|
||||
|
||||
## Why Expansion Packs?
|
||||
### Creative & Interactive Applications
|
||||
- **Interactive Role-Playing**: Campaign management, character development, narrative design
|
||||
- **Game Development**: Level design, character creation, game mechanics
|
||||
- **Content Creation**: Video production, podcast workflows, social media management
|
||||
- **Design Systems**: Brand management, UI/UX workflows, design token systems
|
||||
|
||||
As BMAD has evolved, we've identified specialized needs that don't fit every project:
|
||||
## Expansion Pack Architecture
|
||||
|
||||
- Infrastructure and DevOps workflows
|
||||
- UX/UI design processes
|
||||
- Data engineering pipelines
|
||||
- Security and compliance workflows
|
||||
- Mobile development patterns
|
||||
- Real World assistance and workflows without AI Agents development in mind
|
||||
|
||||
Rather than complicate the core method, expansion packs let you "opt-in" to additional capabilities.
|
||||
|
||||
## Available Expansion Packs
|
||||
|
||||
### 1. Infrastructure & DevOps
|
||||
|
||||
- **Purpose**: Cloud infrastructure design and platform engineering
|
||||
- **Adds**: DevOps agent, infrastructure templates, validation checklists
|
||||
- **Use When**: You need to design and implement cloud infrastructure
|
||||
|
||||
### 2. UX/Design (Coming Soon)
|
||||
|
||||
- **Purpose**: User experience and interface design workflows
|
||||
- **Adds**: Design Architect agent, UI component templates
|
||||
- **Use When**: You need detailed UI/UX design processes
|
||||
|
||||
### 3. Data Engineering (Planned)
|
||||
|
||||
- **Purpose**: Data pipeline and analytics infrastructure
|
||||
- **Adds**: Data Engineer agent, ETL templates, data architecture patterns
|
||||
- **Use When**: You're building data-intensive applications
|
||||
|
||||
## Structure of an Expansion Pack
|
||||
|
||||
Each expansion pack contains:
|
||||
Each expansion pack is a complete, standalone system that follows BMAD conventions:
|
||||
|
||||
```text
|
||||
expansion-pack-name/
|
||||
├── README.md # Overview and usage instructions
|
||||
├── manifest.yml # Installation configuration
|
||||
├── agents/ # Agent configurations (.yml)
|
||||
├── personas/ # Persona definitions (.md)
|
||||
├── ide-agents/ # IDE-specific agents (.ide.md)
|
||||
├── templates/ # Document templates (.md)
|
||||
├── tasks/ # Specialized tasks (.md)
|
||||
└── checklists/ # Validation checklists (.md)
|
||||
````
|
||||
├── README.md # Pack overview and usage instructions
|
||||
├── manifest.yml # Pack metadata and configuration
|
||||
├── agents/ # Specialized agent definitions
|
||||
│ ├── domain-expert.md
|
||||
│ ├── specialist-role.md
|
||||
│ └── coordinator.md
|
||||
├── templates/ # Domain-specific document templates
|
||||
│ ├── industry-doc.md
|
||||
│ └── workflow-spec.md
|
||||
├── tasks/ # Specialized automation tasks
|
||||
│ ├── domain-process.md
|
||||
│ └── validation-check.md
|
||||
├── data/ # Domain knowledge base
|
||||
│ ├── industry-kb.md
|
||||
│ ├── best-practices.md
|
||||
│ └── regulations.md
|
||||
├── checklists/ # Quality assurance checklists
|
||||
│ └── compliance-check.md
|
||||
├── workflows/ # Domain-specific workflows
|
||||
│ └── industry-process.yml
|
||||
└── team-config.yml # Team bundle configuration
|
||||
```
|
||||
|
||||
## Installing an Expansion Pack
|
||||
## Key Principles
|
||||
|
||||
### Method 1: NPM Script
|
||||
### 1. Standalone Independence
|
||||
- Each expansion pack works independently of the core BMAD system
|
||||
- Can be used without any software development context
|
||||
- Complete with its own agents, knowledge, and workflows
|
||||
|
||||
````bash
|
||||
npm run install:expansion <pack-name>
|
||||
```text
|
||||
### 2. Domain Expertise
|
||||
- Deep specialization in specific industries or use cases
|
||||
- Expert-level knowledge embedded in agents and templates
|
||||
- Industry-specific terminology, processes, and best practices
|
||||
|
||||
### Method 2: Direct Script
|
||||
### 3. Consistent Framework
|
||||
- Follows BMAD architectural patterns and conventions
|
||||
- Compatible with existing tooling and build systems
|
||||
- Maintains quality and structure standards
|
||||
|
||||
```bash
|
||||
node tools/install-expansion-pack.js <pack-name>
|
||||
````
|
||||
### 4. Flexible Application
|
||||
- Some packs may be technical, others completely non-technical
|
||||
- Scalable from single-agent specialists to complex multi-agent teams
|
||||
- Adaptable to different user environments (web UI, IDE, etc.)
|
||||
|
||||
### Method 3: Manual
|
||||
## Example Expansion Packs
|
||||
|
||||
1. Copy files according to manifest.yml
|
||||
2. Update team configurations as needed
|
||||
3. Rebuild bundles with `npm run build`
|
||||
### Medical Practice Management
|
||||
- **Agents**: Medical Director, Practice Manager, Compliance Officer, Patient Coordinator
|
||||
- **Templates**: Treatment protocols, compliance documentation, patient intake forms
|
||||
- **Workflows**: Patient onboarding, treatment planning, regulatory reporting
|
||||
- **Knowledge Base**: Medical regulations, best practices, industry standards
|
||||
|
||||
## Creating Your Own Expansion Pack
|
||||
### Interactive Storytelling
|
||||
- **Agents**: Narrative Designer, Character Developer, World Builder, Campaign Master
|
||||
- **Templates**: Character sheets, world documentation, campaign notes
|
||||
- **Workflows**: Story development, character arcs, world building
|
||||
- **Knowledge Base**: Storytelling techniques, genre conventions, narrative structures
|
||||
|
||||
1. Create a new folder under `expansion-packs/`
|
||||
2. Add your specialized agents, templates, and tasks
|
||||
3. Create a manifest.yml defining installation mappings
|
||||
4. Write a README explaining purpose and usage
|
||||
5. Test installation process
|
||||
### Fintech Compliance
|
||||
- **Agents**: Compliance Officer, Risk Analyst, Regulatory Expert, Audit Specialist
|
||||
- **Templates**: Compliance reports, risk assessments, audit documentation
|
||||
- **Workflows**: Regulatory review, compliance monitoring, audit preparation
|
||||
- **Knowledge Base**: Financial regulations, compliance frameworks, audit standards
|
||||
|
||||
## Best Practices
|
||||
## Development Status
|
||||
|
||||
1. **Keep Core Simple**: Don't add to core what could be an expansion
|
||||
2. **Clear Purpose**: Each pack should solve a specific need
|
||||
3. **Self-Contained**: Packs should work independently when possible
|
||||
4. **Document Well**: Clear README and usage examples
|
||||
5. **Version Compatibility**: Note which BMAD version the pack requires
|
||||
**Current Status**: Conceptual framework established, awaiting implementation
|
||||
|
||||
**Roadmap**:
|
||||
1. **Phase 1**: Core expansion pack architecture and tooling
|
||||
2. **Phase 2**: First expansion packs (Medical, Entertainment, Interactive RPG)
|
||||
3. **Phase 3**: Community-contributed expansion packs
|
||||
4. **Phase 4**: Marketplace and distribution system
|
||||
|
||||
## Creating Expansion Packs
|
||||
|
||||
### Planning Your Pack
|
||||
1. **Define Domain**: Clear scope and target use case
|
||||
2. **Identify Roles**: What specialist agents are needed?
|
||||
3. **Map Workflows**: What processes need to be supported?
|
||||
4. **Gather Knowledge**: What domain expertise must be embedded?
|
||||
|
||||
### Development Process
|
||||
1. **Pack Structure**: Follow the standard expansion pack architecture
|
||||
2. **Agent Development**: Create specialized agents with domain expertise
|
||||
3. **Template Creation**: Develop industry-specific document templates
|
||||
4. **Knowledge Integration**: Embed best practices and domain knowledge
|
||||
5. **Testing & Validation**: Ensure quality and effectiveness
|
||||
|
||||
### Quality Standards
|
||||
- **Domain Accuracy**: Expert-level knowledge and terminology
|
||||
- **Practical Utility**: Solves real problems in the target domain
|
||||
- **User Experience**: Clear, intuitive interaction patterns
|
||||
- **Documentation**: Comprehensive usage guides and examples
|
||||
|
||||
## Future Vision
|
||||
|
||||
We envision a library of expansion packs for various industries and use cases:
|
||||
Expansion packs will transform BMAD-METHOD from a software development framework into a universal agentic platform capable of supporting any specialized domain or industry. The goal is to create a rich ecosystem where experts can package their knowledge into reusable, intelligent agent teams.
|
||||
|
||||
- Healthcare compliance workflows
|
||||
- Financial services security patterns
|
||||
- E-commerce optimization flows
|
||||
- Gaming development pipelines
|
||||
- IoT device management
|
||||
**Long-term Goals**:
|
||||
- Hundreds of specialized expansion packs covering diverse domains
|
||||
- Community marketplace for sharing and distributing packs
|
||||
- Integration with industry-specific tools and platforms
|
||||
- AI-powered pack recommendations based on user needs
|
||||
|
||||
The goal is to keep BMAD's core simple while allowing infinite extensibility through modular expansion packs.
|
||||
## Contributing
|
||||
|
||||
**Note**: Expansion pack development is not yet available. This README documents the planned architecture and vision. Follow the project for updates on when expansion pack development will be open.
|
||||
|
||||
**Future Contribution Areas**:
|
||||
- Domain expertise and knowledge base development
|
||||
- Specialized agent design and persona development
|
||||
- Industry-specific template and workflow creation
|
||||
- Testing and validation of expansion packs
|
||||
- Documentation and user experience improvements
|
||||
|
||||
---
|
||||
|
||||
*Expansion packs represent the next evolution of BMAD-METHOD - transforming it from a software development tool into a comprehensive agentic framework capable of supporting any specialized domain or workflow.*
|
||||
74
expansion-packs/infrastructure-devops/tasks/create-doc.md
Normal file
74
expansion-packs/infrastructure-devops/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
|
||||
Reference in New Issue
Block a user