bmad-method 1.0.1

package/.bmad-core/tasks/create-team.md

@@ -0,0 +1,229 @@
+# 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.

package/.bmad-core/tasks/doc-migration-task.md

@@ -0,0 +1,198 @@
+# Document Migration Task
+
+## Purpose
+
+Migrate BMAD-METHOD documents to match V4 template structure exactly, preserving all content while enforcing strict template compliance.
+
+## Task Requirements
+
+1. **Input**: User MUST specify the document to migrate (e.g., `docs/prd.md`)
+2. **Template**: User MUST specify the V4 template to use (e.g., `.bmad-core/templates/prd-tmpl.md`)
+3. **Validation**: Verify document and template are compatible types
+4. **Output**: Creates migrated document with original name, backs up original with `.bak` extension
+
+[[LLM: VALIDATION REQUIREMENTS:
+
+- Both input document and template paths MUST be provided by the user
+- Do NOT assume or select templates automatically
+- Validate that document type matches template type (e.g., PRD → PRD template)
+- Reject incompatible migrations (e.g., PRD → architecture template)
+
+]]
+
+## Migration Rules
+
+### Strict Template Compliance
+
+[[LLM: CRITICAL RULES:
+
+1. The ONLY Level 2 headings (##) allowed are EXACTLY those in the V4 template
+2. No additions, no removals, no modifications to Level 2 headings
+3. All user content must be preserved and placed under appropriate template sections
+4. Remove any existing table of contents
+5. Never delete user content - find the most appropriate section
+6. DO NOT add any LLM prompts, placeholders, or "TBD" content
+7. Leave empty sections empty - no instructions or guidance text
+
+]]
+
+### Content Migration Process
+
+1. **Read Template Structure**
+
+   - Extract all Level 2 headings from the V4 template
+   - These are the ONLY Level 2 headings allowed in the final document
+
+2. **Analyze Original Document**
+
+   - Identify all content blocks
+   - Note original section organization
+   - Flag any custom sections
+
+3. **Create Backup First**
+
+   - Rename original file: `mv filename.md filename.md.bak`
+   - This preserves the original completely
+
+4. **Create New File**
+
+   - Create new `filename.md` from scratch
+   - Start with template structure (all Level 2 headings)
+   - For each content block from original:
+     - Find the most appropriate V4 template section
+     - If original had Level 2 heading not in template, demote to Level 3
+     - Preserve all text, lists, code blocks, diagrams, tables
+     - Remove only table of contents sections
+   - **IMPORTANT**: Do NOT add any LLM prompts, placeholders, or instructions
+   - If a template section has no matching content, leave it empty
+
+5. **Validate Content Preservation**
+   - For each major content block from original (excluding headings):
+     - Use grep or search to verify it exists in new file
+     - Report any content that couldn't be verified
+   - This ensures no accidental content loss
+
+## Example Migration
+
+```markdown
+Original (prd.md):
+
+## Executive Summary
+
+[content...]
+
+## Custom Feature Section
+
+[content...]
+
+## Table of Contents
+
+[toc...]
+
+Template (prd-tmpl.md):
+
+## Goals and Background Context
+
+## Functional Requirements
+
+## Success Metrics and KPIs
+
+Result (prd.md):
+
+## Goals and Background Context
+
+[executive summary content moved here]
+
+### Custom Feature Section
+
+[content preserved but demoted to Level 3]
+
+## Functional Requirements
+
+## Success Metrics and KPIs
+```
+
+## Execution Instructions
+
+[[LLM: When executing this task:
+
+1. Ask user for BOTH: input file path AND template path (do not assume)
+2. Validate compatibility:
+   - Check document title/type (PRD, Architecture, etc.)
+   - Ensure template matches document type
+   - REJECT if types don't match (e.g., "Cannot migrate PRD to architecture template")
+3. Read both files completely
+4. Rename original to .bak: `mv original.md original.md.bak`
+5. Extract Level 2 headings from template - these are MANDATORY
+6. Create NEW file with original name
+7. Build new content:
+   - Start with all template Level 2 sections
+   - Map original content to appropriate sections
+   - Demote any non-template Level 2 headings to Level 3
+   - Leave empty sections empty (no placeholders or instructions)
+8. Validate content preservation:
+   - Extract key content snippets from .bak file
+   - Use grep to verify each exists in new file
+   - Report any missing content
+9. Report migration summary:
+   - Sections moved/demoted
+   - Content validation results
+   - Any manual review needed
+
+]]
+
+### Document Type Detection
+
+[[LLM: Detect document type by examining:
+
+- File name (prd.md, architecture.md, etc.)
+- Main title (# Product Requirements Document, # Architecture, etc.)
+- Content patterns (user stories → PRD, technology stack → Architecture)
+
+Template compatibility:
+
+- prd-tmpl.md → Only for PRD documents
+- architecture-tmpl.md → Only for backend/single architecture
+- full-stack-architecture-tmpl.md → Only for architecture documents (can merge multiple)
+
+]]
+
+## Common Migrations
+
+Valid migrations:
+
+- `prd.md` → `.bmad-core/templates/prd-tmpl.md`
+- `architecture.md` → `.bmad-core/templates/architecture-tmpl.md`
+- `architecture.md` + `front-end-architecture.md` → `.bmad-core/templates/full-stack-architecture-tmpl.md`
+
+Invalid migrations (MUST REJECT):
+
+- `prd.md` → `.bmad-core/templates/architecture-tmpl.md`
+- `architecture.md` → `.bmad-core/templates/prd-tmpl.md`
+- `ux-ui-spec.md` → `.bmad-core/templates/prd-tmpl.md`
+
+## Validation
+
+After migration verify:
+
+- [ ] All Level 2 headings match template exactly
+- [ ] All original content is preserved (use grep validation)
+- [ ] No table of contents remains
+- [ ] Backup file exists with .bak extension
+- [ ] Custom sections demoted to Level 3 or lower
+
+### Content Validation Example
+
+[[LLM: Example validation approach:
+
+1. Extract significant text blocks from .bak file (>20 words)
+2. For each block, grep in new file:
+   ```bash
+   grep -F "first 10-15 words of content block" newfile.md
+   ```
+3. Track validation results:
+   - ✓ Found: content successfully migrated
+   - ✗ Missing: needs investigation
+4. Report any content that couldn't be found
+
+]]

package/.bmad-core/tasks/execute-checklist.md

@@ -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

package/.bmad-core/tasks/generate-ai-frontend-prompt.md

@@ -0,0 +1,58 @@
+# Create AI Frontend Prompt Task
+
+## 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.
+
+## 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)
+
+## Key Activities & Instructions
+
+1. **Confirm Target AI Generation Platform:**
+
+   - 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.
+
+2. **Synthesize Inputs into a Structured Prompt:**
+
+   - **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).
+
+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>