ros/BMAD-METHOD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

core agents alignment

Browse Source
This commit is contained in:
Brian Madison
2025-07-12 20:16:05 -05:00
parent f32a5fe08a
commit 24a35ff2c4
16 changed files with 82 additions and 814 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
bmad-core/agents/bmad-master.md
View File

@@ -46,14 +46,12 @@ dependencies:
- correct-course.md
- create-deep-research-prompt.md
- create-doc.md
- create-workflow-plan.md
- document-project.md
- create-next-story.md
- execute-checklist.md
- generate-ai-frontend-prompt.md
- index-docs.md
- shard-doc.md
- update-workflow-plan.md
templates:
- architecture-tmpl.yaml
- brownfield-architecture-tmpl.yaml

3
bmad-core/agents/bmad-orchestrator.md
View File

@@ -114,7 +114,6 @@ workflow-guidance:
- Understand each workflow's purpose, options, and decision points
- Ask clarifying questions based on the workflow's structure
- Guide users through workflow selection when multiple options exist
- For complex projects, offer to create a workflow plan using create-workflow-plan task
- When appropriate, suggest: "Would you like me to create a detailed workflow plan before starting?"
- For workflows with divergent paths, help users choose the right path
- Adapt questions to the specific domain (e.g., game dev vs infrastructure vs web dev)
@@ -124,9 +123,7 @@ dependencies:
tasks:
- advanced-elicitation.md
- create-doc.md
- create-workflow-plan.md
- kb-mode-interaction.md
- update-workflow-plan.md
data:
- bmad-kb.md
- elicitation-methods.md

5
bmad-core/core-config.yaml
View File

@@ -18,8 +18,3 @@ devLoadAlwaysFiles:
- docs/architecture/source-tree.md
devDebugLog: .ai/debug-log.md
devStoryLocation: docs/stories
workflow:
planFile: docs/workflow-plan.md
trackProgress: true
enforceSequence: false
updateOnCompletion: true

21
bmad-core/tasks/correct-course.md
View File

@@ -2,9 +2,9 @@
## Purpose
- Guide a structured response to a change trigger using the `change-checklist`.
- Guide a structured response to a change trigger using the `{root}/checklists/change-checklist`.
- Analyze the impacts of the change on epics, project artifacts, and the MVP, guided by the checklist's structure.
- Explore potential solutions (e.g., adjust scope, rollback elements, rescope features) as prompted by the checklist.
- Explore potential solutions (e.g., adjust scope, rollback elements, re-scope features) as prompted by the checklist.
- Draft specific, actionable proposed updates to any affected project artifacts (e.g., epics, user stories, PRD sections, architecture document sections) based on the analysis.
- Produce a consolidated "Sprint Change Proposal" document that contains the impact analysis and the clearly drafted proposed edits for user review and approval.
- Ensure a clear handoff path if the nature of the changes necessitates fundamental replanning by other core agents (like PM or Architect).
@@ -16,19 +16,16 @@
- **Acknowledge Task & Inputs:**
- Confirm with the user that the "Correct Course Task" (Change Navigation & Integration) is being initiated.
- Verify the change trigger and ensure you have the user's initial explanation of the issue and its perceived impact.
- Confirm access to all relevant project artifacts (e.g., PRD, Epics/Stories, Architecture Documents, UI/UX Specifications) and, critically, the `change-checklist` (e.g., `change-checklist`).
- Confirm access to all relevant project artifacts (e.g., PRD, Epics/Stories, Architecture Documents, UI/UX Specifications) and, critically, the `{root}/checklists/change-checklist`.
- **Establish Interaction Mode:**
- Ask the user their preferred interaction mode for this task:
- **"Incrementally (Default & Recommended):** Shall we work through the `change-checklist` section by section, discussing findings and collaboratively drafting proposed changes for each relevant part before moving to the next? This allows for detailed, step-by-step refinement."
- **"Incrementally (Default & Recommended):** Shall we work through the change-checklist section by section, discussing findings and collaboratively drafting proposed changes for each relevant part before moving to the next? This allows for detailed, step-by-step refinement."
- **"YOLO Mode (Batch Processing):** Or, would you prefer I conduct a more batched analysis based on the checklist and then present a consolidated set of findings and proposed changes for a broader review? This can be quicker for initial assessment but might require more extensive review of the combined proposals."
- Request the user to select their preferred mode.
- Once the user chooses, confirm the selected mode (e.g., "Okay, we will proceed in Incremental mode."). This chosen mode will govern how subsequent steps in this task are executed.
- **Explain Process:** Briefly inform the user: "We will now use the `change-checklist` to analyze the change and draft proposed updates. I will guide you through the checklist items based on our chosen interaction mode."
<rule>When asking multiple questions or presenting multiple points for user input at once, number them clearly (e.g., 1., 2a., 2b.) to make it easier for the user to provide specific responses.</rule>
- Once the user chooses, confirm the selected mode and then inform the user: "We will now use the change-checklist to analyze the change and draft proposed updates. I will guide you through the checklist items based on our chosen interaction mode."
### 2. Execute Checklist Analysis (Iteratively or Batched, per Interaction Mode)
- Systematically work through Sections 1-4 of the `change-checklist` (typically covering Change Context, Epic/Story Impact Analysis, Artifact Conflict Resolution, and Path Evaluation/Recommendation).
- Systematically work through Sections 1-4 of the change-checklist (typically covering Change Context, Epic/Story Impact Analysis, Artifact Conflict Resolution, and Path Evaluation/Recommendation).
- For each checklist item or logical group of items (depending on interaction mode):
- Present the relevant prompt(s) or considerations from the checklist to the user.
- Request necessary information and actively analyze the relevant project artifacts (PRD, epics, architecture documents, story history, etc.) to assess the impact.
@@ -51,7 +48,7 @@
### 4. Generate "Sprint Change Proposal" with Edits
- Synthesize the complete `change-checklist` analysis (covering findings from Sections 1-4) and all the agreed-upon proposed edits (from Instruction 3) into a single document titled "Sprint Change Proposal." This proposal should align with the structure suggested by Section 5 of the `change-checklist` (Proposal Components).
- Synthesize the complete change-checklist analysis (covering findings from Sections 1-4) and all the agreed-upon proposed edits (from Instruction 3) into a single document titled "Sprint Change Proposal." This proposal should align with the structure suggested by Section 5 of the change-checklist.
- The proposal must clearly present:
- **Analysis Summary:** A concise overview of the original issue, its analyzed impact (on epics, artifacts, MVP scope), and the rationale for the chosen path forward.
- **Specific Proposed Edits:** For each affected artifact, clearly show or describe the exact changes (e.g., "Change Story X.Y from: [old text] To: [new text]", "Add new Acceptance Criterion to Story A.B: [new AC]", "Update Section 3.2 of Architecture Document as follows: [new/modified text or diagram description]").
@@ -68,6 +65,6 @@
## Output Deliverables
- **Primary:** A "Sprint Change Proposal" document (in markdown format). This document will contain:
- A summary of the `change-checklist` analysis (issue, impact, rationale for the chosen path).
- A summary of the change-checklist analysis (issue, impact, rationale for the chosen path).
- Specific, clearly drafted proposed edits for all affected project artifacts.
- **Implicit:** An annotated `change-checklist` (or the record of its completion) reflecting the discussions, findings, and decisions made during the process.
- **Implicit:** An annotated change-checklist (or the record of its completion) reflecting the discussions, findings, and decisions made during the process.

71
bmad-core/tasks/create-brownfield-story.md
View File

@@ -22,20 +22,7 @@ Create detailed, implementation-ready stories for brownfield projects where trad
## Task Execution Instructions
### 0. Check Workflow Plan and Documentation Context
[[LLM: Check for workflow plan first, then available documentation]]
#### 0.1 Check Workflow Plan
- Load core-config.yaml and check if `workflow.trackProgress: true`
- If yes, check for active plan at `workflow.planFile`
- If plan exists:
- Verify story creation aligns with current plan step
- If out of sequence, warn user (enforce based on config)
- Note which step this story creation corresponds to
#### 0.2 Determine Documentation Context
### 0. Documentation Context
Check for available documentation in this order:
@@ -68,7 +55,7 @@ Based on available documentation:
#### 1.2 Gather Essential Context
[[LLM: For brownfield stories, you MUST gather enough context for safe implementation. Be prepared to ask the user for missing information.]]
CRITICAL: For brownfield stories, you MUST gather enough context for safe implementation. Be prepared to ask the user for missing information.
**Required Information Checklist:**
@@ -78,21 +65,7 @@ Based on available documentation:
- [ ] What technical constraints exist?
- [ ] Are there any "gotchas" or workarounds to know about?
If any required information is missing, ask the user:
```
I need additional context for this brownfield story:
Missing Information:
- [List specific missing items]
Please provide:
1. [Specific question about integration]
2. [Specific question about patterns]
3. [Specific question about constraints]
Or point me to documentation that contains this information.
```
If any required information is missing, list the missing information and ask the user to provide it.
### 2. Extract Technical Context from Available Sources
@@ -117,8 +90,6 @@ If using brownfield PRD:
#### 2.3 From User Documentation
[[LLM: When working with non-BMad documentation, actively extract and organize the information into categories the Dev agent will need]]
Ask the user to help identify:
- Relevant technical specifications
@@ -138,12 +109,13 @@ Start with the story template, filling in what's known:
## Status: Draft
## Story
As a {{user_type}},
I want {{enhancement_capability}},
so that {{value_delivered}}.
## Context Source
[[LLM: Document where story requirements came from]]
- Source Document: {{document name/type}}
- Enhancement Type: {{single feature/bug fix/integration/etc}}
- Existing System Impact: {{brief assessment}}
@@ -151,7 +123,7 @@ so that {{value_delivered}}.
#### 3.2 Develop Acceptance Criteria
[[LLM: For brownfield, ALWAYS include criteria about maintaining existing functionality]]
Critical: For brownfield, ALWAYS include criteria about maintaining existing functionality
Standard structure:
@@ -163,7 +135,7 @@ Standard structure:
#### 3.3 Gather Technical Guidance
[[LLM: This is where you'll need to be interactive with the user if information is missing]]
Critical: This is where you'll need to be interactive with the user if information is missing
Create Dev Technical Guidance section with available information:
@@ -180,22 +152,8 @@ Create Dev Technical Guidance section with available information:
[From documentation or user input]
### Missing Information
[[LLM: List anything you couldn't find that dev will need]]
- [ ] {{missing item 1}}
- [ ] {{missing item 2}}
```
If critical information is missing, pause and ask:
```
To complete the technical guidance for this story, I need:
1. **{{Missing Category}}**:
- Specifically: {{what you need to know}}
- Why needed: {{how it impacts implementation}}
Can you provide this information or point me to relevant code/docs?
```
Critical: List anything you couldn't find that dev will need and ask for the missing information
### 4. Task Generation with Safety Checks
@@ -236,7 +194,7 @@ Example task structure for brownfield:
### 5. Risk Assessment and Mitigation
[[LLM: CRITICAL for brownfield - always include risk assessment]]
CRITICAL: for brownfield - always include risk assessment
Add section for brownfield-specific risks:
@@ -324,15 +282,6 @@ Next Steps:
4. Dev agent can then implement with safety checks
```
### 9. Update Workflow Plan (if applicable)
[[LLM: After successful story creation]]
- If workflow plan tracking is enabled and story was created successfully:
- Call update-workflow-plan task to mark step complete
- Parameters: task: create-brownfield-story, step_id: {from plan check}, status: complete
- If plan shows next recommended step, include it in handoff message
## Success Criteria
The brownfield story creation is successful when:
@@ -348,7 +297,7 @@ The brownfield story creation is successful when:
## Important Notes
- This task is specifically for brownfield projects with non-standard documentation
- Always prioritize existing system safety over new features
- Always prioritize existing system stability over new features
- When in doubt, add exploration and verification tasks
- It's better to ask the user for clarification than make assumptions
- Each story should be self-contained for the dev agent

22
bmad-core/tasks/create-deep-research-prompt.md
View File

@@ -14,7 +14,7 @@ Generate well-structured research prompts that:
## Research Type Selection
[[LLM: First, help the user select the most appropriate research focus based on their needs and any input documents they've provided.]]
CRITICAL: First, help the user select the most appropriate research focus based on their needs and any input documents they've provided.
### 1. Research Focus Options
@@ -77,15 +77,13 @@ Present these numbered options to the user:
- Consider regulatory and legal implications
9. **Custom Research Focus**
[[LLM: Allow user to define their own specific research focus.]]
- User-defined research objectives
- Specialized domain investigation
- Cross-functional research needs
### 2. Input Processing
[[LLM: Based on the selected research type and any provided inputs (project brief, brainstorming results, etc.), extract relevant context and constraints.]]
**If Project Brief provided:**
- Extract key product concepts and goals
@@ -118,11 +116,11 @@ Present these numbered options to the user:
### 3. Research Prompt Structure
[[LLM: Based on the selected research type and context, collaboratively develop a comprehensive research prompt with these components.]]
CRITICAL: collaboratively develop a comprehensive research prompt with these components.
#### A. Research Objectives
[[LLM: Work with the user to articulate clear, specific objectives for the research.]]
CRITICAL: collaborate with the user to articulate clear, specific objectives for the research.
- Primary research goal and purpose
- Key decisions the research will inform
@@ -131,7 +129,7 @@ Present these numbered options to the user:
#### B. Research Questions
[[LLM: Develop specific, actionable research questions organized by theme.]]
CRITICAL: collaborate with the user to develop specific, actionable research questions organized by theme.
**Core Questions:**
@@ -147,8 +145,6 @@ Present these numbered options to the user:
#### C. Research Methodology
[[LLM: Specify appropriate research methods based on the type and objectives.]]
**Data Collection Methods:**
- Secondary research sources
@@ -165,8 +161,6 @@ Present these numbered options to the user:
#### D. Output Requirements
[[LLM: Define how research findings should be structured and presented.]]
**Format Specifications:**
- Executive summary requirements
@@ -183,8 +177,6 @@ Present these numbered options to the user:
### 4. Prompt Generation
[[LLM: Synthesize all elements into a comprehensive, ready-to-use research prompt.]]
**Research Prompt Template:**
```markdown
@@ -253,8 +245,6 @@ Present these numbered options to the user:
### 5. Review and Refinement
[[LLM: Present the draft research prompt for user review and refinement.]]
1. **Present Complete Prompt**
- Show the full research prompt
@@ -276,8 +266,6 @@ Present these numbered options to the user:
### 6. Next Steps Guidance
[[LLM: Provide clear guidance on how to use the research prompt.]]
**Execution Options:**
1. **Use with AI Research Assistant**: Provide this prompt to an AI model with research capabilities

7
bmad-core/tasks/create-next-story.md
View File

@@ -8,7 +8,7 @@ To identify the next logical story based on project progress and epic definition
### 0. Load Core Configuration and Check Workflow
- Load `.bmad-core/core-config.yaml` from the project root
- Load `{root}/core-config.yaml` from the project root
- If the file does not exist, HALT and inform the user: "core-config.yaml not found. This file is required for story creation. You can either: 1) Copy it from GITHUB bmad-core/core-config.yaml and configure it for your project OR 2) Run the BMad installer against your project to upgrade and add the file automatically. Please add and configure core-config.yaml before proceeding."
- Extract key configurations: `devStoryLocation`, `prd.*`, `architecture.*`, `workflow.*`
@@ -102,12 +102,11 @@ ALWAYS cite source documents: `[Source: architecture/{filename}.md#{section}]`
- Verify all source references are included for technical details
- Ensure tasks align with both epic requirements and architecture constraints
- Update status to "Draft" and save the story file
- If `workflow.trackProgress: true` and `workflow.updateOnCompletion: true`, call update-workflow-plan task to mark story creation step complete
- Execute `tasks/execute-checklist` `checklists/story-draft-checklist`
- Execute `{root}/tasks/execute-checklist` `{root}/checklists/story-draft-checklist`
- Provide summary to user including:
- Story created: `{devStoryLocation}/{epicNum}.{storyNum}.story.md`
- Status: Draft
- Key technical components included from architecture docs
- Any deviations or conflicts noted between epic and architecture
- Checklist Results
- Next steps: For Complex stories, suggest the user carefully review the story draft and also optionally have the PO run the task `validate-next-story`
- Next steps: For Complex stories, suggest the user carefully review the story draft and also optionally have the PO run the task `{root}/tasks/validate-next-story`

289
bmad-core/tasks/create-workflow-plan.md
View File

@@ -1,289 +0,0 @@
# Create Workflow Plan Task
## Purpose
Guide users through workflow selection and create a detailed plan document that outlines the selected workflow steps, decision points, and expected outputs. This task helps users understand what will happen before starting a complex workflow and provides a checklist to track progress.
## Task Instructions
### 1. Understand User's Goal
[[LLM: Start with discovery questions to understand what the user wants to accomplish]]
Ask the user:
1. **Project Type**:
- Are you starting a new project (greenfield) or enhancing an existing one (brownfield)?
- What type of application? (web app, service/API, UI only, full-stack)
2. **For Greenfield**:
- Do you need a quick prototype or production-ready application?
- Will this have a UI component?
- Single service or multiple services?
3. **For Brownfield**:
- What's the scope of the enhancement?
- Single bug fix or small feature (few hours)
- Small enhancement (1-3 stories)
- Major feature requiring coordination
- Architectural changes or modernization
- Do you have existing documentation?
- Are you following existing patterns or introducing new ones?
### 2. Recommend Appropriate Workflow
Based on the answers, recommend:
**Greenfield Options:**
- `greenfield-fullstack` - Complete web application
- `greenfield-service` - Backend API/service only
- `greenfield-ui` - Frontend only
**Brownfield Options:**
- `brownfield-create-story` - Single small change
- `brownfield-create-epic` - Small feature (1-3 stories)
- `brownfield-fullstack` - Major enhancement
**Simplified Option:**
- For users unsure or wanting flexibility, suggest starting with individual agent tasks
### 3. Explain Selected Workflow
[[LLM: Once workflow is selected, provide clear explanation]]
For the selected workflow, explain:
1. **Overview**: What this workflow accomplishes
2. **Duration**: Estimated time for planning phase
3. **Outputs**: What documents will be created
4. **Decision Points**: Where user input will be needed
5. **Requirements**: What information should be ready
### 4. Create Workflow Plan Document
[[LLM: Generate a comprehensive plan document with the following structure]]
```markdown
# Workflow Plan: {{Workflow Name}}
<!-- WORKFLOW-PLAN-META
workflow-id: {{workflow-id}}
status: active
created: {{ISO-8601 timestamp}}
updated: {{ISO-8601 timestamp}}
version: 1.0
-->
**Created Date**: {{current date}}
**Project**: {{project name}}
**Type**: {{greenfield/brownfield}}
**Status**: Active
**Estimated Planning Duration**: {{time estimate}}
## Objective
{{Clear description of what will be accomplished}}
## Selected Workflow
**Workflow**: `{{workflow-id}}`
**Reason**: {{Why this workflow fits the user's needs}}
## Workflow Steps
### Planning Phase
- [ ] Step 1: {{step name}} <!-- step-id: 1.1, agent: {{agent}}, task: {{task}} -->
- **Agent**: {{agent name}}
- **Action**: {{what happens}}
- **Output**: {{what's created}}
- **User Input**: {{if any}}
- [ ] Step 2: {{step name}} <!-- step-id: 1.2, agent: {{agent}}, task: {{task}} -->
- **Agent**: {{agent name}}
- **Action**: {{what happens}}
- **Output**: {{what's created}}
- **Decision Point**: {{if any}} <!-- decision-id: D1 -->
{{Continue for all planning steps}}
### Development Phase (IDE)
- [ ] Document Sharding <!-- step-id: 2.1, agent: po, task: shard-doc -->
- Prepare documents for story creation
- [ ] Story Development Cycle <!-- step-id: 2.2, repeats: true -->
- [ ] Create story (SM agent) <!-- step-id: 2.2.1, agent: sm, task: create-next-story -->
- [ ] Review story (optional) <!-- step-id: 2.2.2, agent: analyst, optional: true -->
- [ ] Implement story (Dev agent) <!-- step-id: 2.2.3, agent: dev -->
- [ ] QA review (optional) <!-- step-id: 2.2.4, agent: qa, optional: true -->
- [ ] Repeat for all stories
- [ ] Epic Retrospective (optional) <!-- step-id: 2.3, agent: po, optional: true -->
## Key Decision Points
1. **{{Decision Name}}** (Step {{n}}): <!-- decision-id: D1, status: pending -->
- Trigger: {{what causes this decision}}
- Options: {{available choices}}
- Impact: {{how it affects the workflow}}
- Decision Made: _Pending_
{{List all decision points}}
## Expected Outputs
### Planning Documents
- [ ] {{document 1}} - {{description}}
- [ ] {{document 2}} - {{description}}
{{etc...}}
### Development Artifacts
- [ ] Stories in `docs/stories/`
- [ ] Implementation code
- [ ] Tests
- [ ] Updated documentation
## Prerequisites Checklist
Before starting this workflow, ensure you have:
- [ ] {{prerequisite 1}}
- [ ] {{prerequisite 2}}
- [ ] {{prerequisite 3}}
{{etc...}}
## Customization Options
Based on your project needs, you may:
- Skip {{optional step}} if {{condition}}
- Add {{additional step}} if {{condition}}
- Choose {{alternative}} instead of {{default}}
## Risk Considerations
{{For brownfield only}}
- Integration complexity: {{assessment}}
- Rollback strategy: {{approach}}
- Testing requirements: {{special needs}}
## Next Steps
1. Review this plan and confirm it matches your expectations
2. Gather any missing prerequisites
3. Start workflow with: `*task workflow {{workflow-id}}`
4. Or begin with first agent: `@{{first-agent}}`
## Notes
{{Any additional context or warnings}}
---
*This plan can be updated as you progress through the workflow. Check off completed items to track progress.*
```
### 5. Save and Present Plan
1. Save the plan as `docs/workflow-plan.md`
2. Inform user: "Workflow plan created at docs/workflow-plan.md"
3. Offer options:
- Review the plan together
- Start the workflow now
- Gather prerequisites first
- Modify the plan
### 6. Plan Variations
[[LLM: Adjust plan detail based on workflow complexity]]
**For Simple Workflows** (create-story, create-epic):
- Simpler checklist format
- Focus on immediate next steps
- Less detailed explanations
**For Complex Workflows** (full greenfield/brownfield):
- Detailed step breakdowns
- All decision points documented
- Comprehensive output descriptions
- Risk mitigation sections
**For Brownfield Workflows**:
- Include existing system impact analysis
- Document integration checkpoints
- Add rollback considerations
- Note documentation dependencies
### 7. Interactive Planning Mode
[[LLM: If user wants to customize the workflow]]
If user wants to modify the standard workflow:
1. Present workflow steps as options
2. Allow skipping optional steps
3. Let user reorder certain steps
4. Document customizations in plan
5. Warn about dependencies if steps are skipped
### 8. Execution Guidance
After plan is created, provide clear guidance:
```text
Your workflow plan is ready! Here's how to proceed:
1. **Review the plan**: Check that all steps align with your goals
2. **Gather prerequisites**: Use the checklist to ensure you're ready
3. **Start execution**:
- Full workflow: `*task workflow {{workflow-id}}`
- Step by step: Start with `@{{first-agent}}`
4. **Track progress**: Check off steps in the plan as completed
Would you like to:
a) Review the plan together
b) Start the workflow now
c) Gather prerequisites first
d) Modify the plan
```
## Success Criteria
The workflow plan is successful when:
1. User clearly understands what will happen
2. All decision points are documented
3. Prerequisites are identified
4. Expected outputs are clear
5. User feels confident to proceed
6. Plan serves as useful progress tracker
## Integration with BMad Master and Orchestrator
When used by BMad Master or BMad Orchestrator, this task should:
1. Be offered when user asks about workflows
2. Be suggested before starting complex workflows
3. Create a plan that the agent can reference during execution
4. Allow the agent to track progress against the plan
## Example Usage
```text
User: "I need to add a payment system to my existing app"
BMad Orchestrator: "Let me help you create a workflow plan for that enhancement. I'll ask a few questions to recommend the best approach..."
[Runs through discovery questions]
BMad Orchestrator: "Based on your answers, I recommend the brownfield-fullstack workflow. Let me create a detailed plan for you..."
[Creates and saves plan]
BMad Orchestrator: "I've created a workflow plan at docs/workflow-plan.md. This shows all the steps we'll go through, what documents will be created, and where you'll need to make decisions. Would you like to review it together?"
```

143
bmad-core/tasks/doc-migration-task.md
View File

@@ -1,143 +0,0 @@
# Document Migration Task
## Purpose
Simple document migration that cleans up heading formats and adds epic structure for PRDs.
## Task Requirements
1. **Input**: User specifies the document to migrate (e.g., `docs/prd.md`)
2. **Detection**: Automatically determine if it's a PRD or other document type
3. **Migration**: Apply appropriate transformations
4. **Backup**: Create backup with `.bak` extension
## Migration Rules
### For PRDs
- Find all level 3 headings that appear to be epics
- Add a level 2 heading "## Epic #" (incrementing number) before each epic
- Also apply the heading cleanup rules below
### For All Documents
- Find all level 2 headings (`## ...`)
- Remove leading numbers and symbols
- Keep only alphabetic characters and spaces
- **CRITICAL**: Do not lose any information - preserve all content under appropriate headings
- Examples:
- `## 1. Foo & Bar` → `## Foo Bar`
- `## 2.1 Technical Overview` → `## Technical Overview`
- `## 3) User Experience` → `## User Experience`
### For Architecture Documents
- **PRIMARY GOAL**: Align level 2 headings to match template level 2 titles exactly
- **PRESERVE EVERYTHING**: Do not lose any information during migration
- Map existing content to the closest matching template section
- If content doesn't fit template sections, create appropriate level 3 subsections
## Detection Logic
A document is considered a PRD if:
- Filename contains "prd" (case insensitive)
- OR main title contains "Product Requirements" or "PRD"
- OR contains sections like "User Stories", "Functional Requirements", "Acceptance Criteria"
## Implementation Steps
1. **Backup Original**: Copy `filename.md` to `filename.md.bak`
2. **Detect Type**: Check if document is a PRD
3. **Process Headings**:
- Clean all level 2 headings
- If PRD: Add epic structure before level 3 headings that look like epics
4. **Write Result**: Overwrite original file with migrated content
## Epic Detection for PRDs
Level 3 headings are treated as epics if they:
- Describe features or functionality
- Are substantial sections (not just "Overview" or "Notes")
- Common epic patterns: "User Management", "Payment Processing", "Reporting Dashboard"
The epic numbering starts at 1 and increments for each epic found.
## Example
### Before (PRD):
```markdown
# Product Requirements Document
## 1. Executive Summary
Content here...
## 2.1 Functional Requirements & Specs
Content here...
### User Management System
Epic content...
### Payment Processing
Epic content...
## 3) Success Metrics
Content here...
```
### After (PRD):
```markdown
# Product Requirements Document
## Executive Summary
Content here...
## Functional Requirements Specs
Content here...
## Epic 1
### User Management System
Epic content...
## Epic 2
### Payment Processing
Epic content...
## Success Metrics
Content here...
```
### Before (Non-PRD):
```markdown
# Architecture Document
## 1. System Overview
Content...
## 2.1 Technical Stack & Tools
Content...
```
### After (Non-PRD):
```markdown
# Architecture Document
## System Overview
Content...
## Technical Stack Tools
Content...
```

48
bmad-core/tasks/document-project.md
View File

@@ -8,7 +8,7 @@ Generate comprehensive documentation for existing projects optimized for AI deve
### 1. Initial Project Analysis
[[LLM: First, check if a PRD or requirements document exists in context. If yes, use it to focus your documentation efforts on relevant areas only.
**CRITICAL:** First, check if a PRD or requirements document exists in context. If yes, use it to focus your documentation efforts on relevant areas only.
**IF PRD EXISTS**:
@@ -56,11 +56,10 @@ Ask the user these elicitation questions to better understand their needs:
- Are there any existing documentation standards or formats you prefer?
- What level of technical detail should the documentation target? (junior developers, senior developers, mixed team)
- Is there a specific feature or enhancement you're planning? (This helps focus documentation)
]]
### 2. Deep Codebase Analysis
[[LLM: Before generating documentation, conduct extensive analysis of the existing codebase:
CRITICAL: Before generating documentation, conduct extensive analysis of the existing codebase:
1. **Explore Key Areas**:
- Entry points (main files, index files, app initializers)
@@ -83,13 +82,14 @@ Ask the user these elicitation questions to better understand their needs:
- Document workarounds and technical debt
- Note areas that differ from standard patterns
**IF PRD PROVIDED**: Also analyze what would need to change for the enhancement]]
**IF PRD PROVIDED**: Also analyze what would need to change for the enhancement
### 3. Core Documentation Generation
[[LLM: Generate a comprehensive BROWNFIELD architecture document that reflects the ACTUAL state of the codebase.
**CRITICAL**: This is NOT an aspirational architecture document. Document what EXISTS, including:
- Technical debt and workarounds
- Inconsistent patterns between different parts
- Legacy code that can't be changed
@@ -101,13 +101,16 @@ Ask the user these elicitation questions to better understand their needs:
# [Project Name] Brownfield Architecture Document
## Introduction
This document captures the CURRENT STATE of the [Project Name] codebase, including technical debt, workarounds, and real-world patterns. It serves as a reference for AI agents working on enhancements.
### Document Scope
[If PRD provided: "Focused on areas relevant to: {enhancement description}"]
[If no PRD: "Comprehensive documentation of entire system"]
### Change Log
| Date | Version | Description | Author |
|------|---------|-------------|--------|
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
@@ -115,6 +118,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
## Quick Reference - Key Files and Entry Points
### Critical Files for Understanding the System
- **Main Entry**: `src/index.js` (or actual entry point)
- **Configuration**: `config/app.config.js`, `.env.example`
- **Core Business Logic**: `src/services/`, `src/domain/`
@@ -123,22 +127,25 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
- **Key Algorithms**: [List specific files with complex logic]
### If PRD Provided - Enhancement Impact Areas
[Highlight which files/modules will be affected by the planned enhancement]
## High Level Architecture
### Technical Summary
[Real assessment of architecture - mention if it's well-structured or has issues]
### Actual Tech Stack (from package.json/requirements.txt)
| Category | Technology | Version | Notes |
|----------|------------|---------|--------|
| Runtime | Node.js | 16.x | [Any constraints] |
| Framework | Express | 4.18.2 | [Custom middleware?] |
| Database | PostgreSQL | 13 | [Connection pooling setup] |
| [etc...] |
etc...
### Repository Structure Reality Check
- Type: [Monorepo/Polyrepo/Hybrid]
- Package Manager: [npm/yarn/pnpm]
- Notable: [Any unusual structure decisions]
@@ -146,7 +153,8 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
## Source Tree and Module Organization
### Project Structure (Actual)
```
```text
project-root/
├── src/
│ ├── controllers/ # HTTP request handlers
@@ -160,6 +168,7 @@ project-root/
```
### Key Modules and Their Purpose
- **User Management**: `src/services/userService.js` - Handles all user operations
- **Authentication**: `src/middleware/auth.js` - JWT-based, custom implementation
- **Payment Processing**: `src/legacy/payment.js` - CRITICAL: Do not refactor, tightly coupled
@@ -168,12 +177,14 @@ project-root/
## Data Models and APIs
### Data Models
Instead of duplicating, reference actual model files:
- **User Model**: See `src/models/User.js`
- **Order Model**: See `src/models/Order.js`
- **Related Types**: TypeScript definitions in `src/types/`
### API Specifications
- **OpenAPI Spec**: `docs/api/openapi.yaml` (if exists)
- **Postman Collection**: `docs/api/postman-collection.json`
- **Manual Endpoints**: [List any undocumented endpoints discovered]
@@ -181,12 +192,14 @@ Instead of duplicating, reference actual model files:
## Technical Debt and Known Issues
### Critical Technical Debt
1. **Payment Service**: Legacy code in `src/legacy/payment.js` - tightly coupled, no tests
2. **User Service**: Different pattern than other services, uses callbacks instead of promises
3. **Database Migrations**: Manually tracked, no proper migration tool
4. **[Other significant debt]**
### Workarounds and Gotchas
- **Environment Variables**: Must set `NODE_ENV=production` even for staging (historical reason)
- **Database Connections**: Connection pool hardcoded to 10, changing breaks payment service
- **[Other workarounds developers need to know]**
@@ -194,13 +207,16 @@ Instead of duplicating, reference actual model files:
## Integration Points and External Dependencies
### External Services
| Service | Purpose | Integration Type | Key Files |
|---------|---------|------------------|-----------|
| Stripe | Payments | REST API | `src/integrations/stripe/` |
| SendGrid | Emails | SDK | `src/services/emailService.js` |
| [etc...] |
etc...
### Internal Integration Points
- **Frontend Communication**: REST API on port 3000, expects specific headers
- **Background Jobs**: Redis queue, see `src/workers/`
- **[Other integrations]**
@@ -208,11 +224,13 @@ Instead of duplicating, reference actual model files:
## Development and Deployment
### Local Development Setup
1. Actual steps that work (not ideal steps)
2. Known issues with setup
3. Required environment variables (see `.env.example`)
### Build and Deployment Process
- **Build Command**: `npm run build` (webpack config in `webpack.config.js`)
- **Deployment**: Manual deployment via `scripts/deploy.sh`
- **Environments**: Dev, Staging, Prod (see `config/environments/`)
@@ -220,12 +238,14 @@ Instead of duplicating, reference actual model files:
## Testing Reality
### Current Test Coverage
- Unit Tests: 60% coverage (Jest)
- Integration Tests: Minimal, in `tests/integration/`
- E2E Tests: None
- Manual Testing: Primary QA method
### Running Tests
```bash
npm test # Runs unit tests
npm run test:integration # Runs integration tests (requires local DB)
@@ -234,6 +254,7 @@ npm run test:integration # Runs integration tests (requires local DB)
## If Enhancement PRD Provided - Impact Analysis
### Files That Will Need Modification
Based on the enhancement requirements, these files will be affected:
- `src/services/userService.js` - Add new user fields
- `src/models/User.js` - Update schema
@@ -241,11 +262,13 @@ Based on the enhancement requirements, these files will be affected:
- [etc...]
### New Files/Modules Needed
- `src/services/newFeatureService.js` - New business logic
- `src/models/NewFeature.js` - New data model
- [etc...]
### Integration Considerations
- Will need to integrate with existing auth middleware
- Must follow existing response format in `src/utils/responseFormatter.js`
- [Other integration points]
@@ -253,6 +276,7 @@ Based on the enhancement requirements, these files will be affected:
## Appendix - Useful Commands and Scripts
### Frequently Used Commands
```bash
npm run dev # Start development server
npm run build # Production build
@@ -261,14 +285,13 @@ npm run seed # Seed test data
```
### Debugging and Troubleshooting
- **Logs**: Check `logs/app.log` for application logs
- **Debug Mode**: Set `DEBUG=app:*` for verbose logging
- **Common Issues**: See `docs/troubleshooting.md`]]
### 4. Document Delivery
[[LLM: After generating the complete architecture document:
1. **In Web UI (Gemini, ChatGPT, Claude)**:
- Present the entire document in one response (or multiple if too long)
- Tell user to copy and save as `docs/brownfield-architecture.md` or `docs/project-architecture.md`
@@ -280,6 +303,7 @@ npm run seed # Seed test data
- Can be sharded later using PO agent if desired
The document should be comprehensive enough that future agents can understand:
- The actual state of the system (not idealized)
- Where to find key files and logic
- What technical debt exists
@@ -288,7 +312,7 @@ The document should be comprehensive enough that future agents can understand:
### 5. Quality Assurance
[[LLM: Before finalizing the document:
CRITICAL: Before finalizing the document:
1. **Accuracy Check**: Verify all technical details match the actual codebase
2. **Completeness Review**: Ensure all major system components are documented
@@ -296,7 +320,7 @@ The document should be comprehensive enough that future agents can understand:
4. **Clarity Assessment**: Check that explanations are clear for AI agents
5. **Navigation**: Ensure document has clear section structure for easy reference
Apply the advanced elicitation task after major sections to refine based on user feedback.]]
Apply the advanced elicitation task after major sections to refine based on user feedback.
## Success Criteria

2
bmad-core/tasks/facilitate-brainstorming-session.md
View File

@@ -1,6 +1,6 @@
---
docOutputLocation: docs/brainstorming-session-results.md
template: brainstorming-output-tmpl
template: "{root}/templates/brainstorming-output-tmpl.md"
---
# Facilitate Brainstorming Session Task

2
bmad-core/tasks/generate-ai-frontend-prompt.md
View File

@@ -6,7 +6,7 @@ To generate a masterful, comprehensive, and optimized prompt that can be used wi
## Inputs
- Completed UI/UX Specification (`front-end-spec`)
- Completed UI/UX Specification (`front-end-spec.md`)
- 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)

9
bmad-core/tasks/kb-mode-interaction.md
View File

@@ -1,6 +1,7 @@
# KB Mode Interaction Task
## Purpose
Provide a user-friendly interface to the BMad knowledge base without overwhelming users with information upfront.
## Instructions
@@ -8,11 +9,11 @@ Provide a user-friendly interface to the BMad knowledge base without overwhelmin
When entering KB mode (*kb-mode), follow these steps:
### 1. Welcome and Guide
Announce entering KB mode with a brief, friendly introduction:
"I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method."
Announce entering KB mode with a brief, friendly introduction.
### 2. Present Topic Areas
Offer a concise list of main topic areas the user might want to explore:
**What would you like to know more about?**
@@ -29,19 +30,23 @@ Offer a concise list of main topic areas the user might want to explore:
Or ask me about anything else related to BMad-Method!
### 3. Respond Contextually
- Wait for user's specific question or topic selection
- Provide focused, relevant information from the knowledge base
- Offer to dive deeper or explore related topics
- Keep responses concise unless user asks for detailed explanations
### 4. Interactive Exploration
- After answering, suggest related topics they might find helpful
- Maintain conversational flow rather than data dumping
- Use examples when appropriate
- Reference specific documentation sections when relevant
### 5. Exit Gracefully
When user is done or wants to exit KB mode:
- Summarize key points discussed if helpful
- Remind them they can return to KB mode anytime with *kb-mode
- Suggest next steps based on what was discussed

6
bmad-core/tasks/review-story.md
View File

@@ -1,8 +1,6 @@
# review-story
When a developer marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
[[LLM: QA Agent executing review-story task as Senior Developer]]
When a developer agent marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
## Prerequisites
@@ -131,6 +129,7 @@ After review and any refactoring, append your results to the story file in the Q
## Blocking Conditions
Stop the review and request clarification if:
- Story file is incomplete or missing critical sections
- File List is empty or clearly incomplete
- No tests exist when they were required
@@ -140,6 +139,7 @@ Stop the review and request clarification if:
## Completion
After review:
1. If all items are checked and approved: Update story status to "Done"
2. If unchecked items remain: Keep status as "Review" for dev to address
3. Always provide constructive feedback and explanations for learning

14
bmad-core/tasks/shard-doc.md
View File

@@ -8,20 +8,20 @@
## Primary Method: Automatic with markdown-tree
[[LLM: First, check if markdownExploder is set to true in bmad-core/core-config.yaml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
[[LLM: First, check if markdownExploder is set to true in {root}/core-config.yaml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
2. Or set markdownExploder to false in bmad-core/core-config.yaml
2. Or set markdownExploder to false in {root}/core-config.yaml
**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
1. Set markdownExploder to true in bmad-core/core-config.yaml
1. Set markdownExploder to true in {root}/core-config.yaml
2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
I will now proceed with the manual sharding process."
@@ -61,8 +61,6 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
[[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
### Task Instructions
1. Identify Document and Target Location
@@ -73,7 +71,7 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
2. Parse and Extract Sections
[[LLM: When sharding the document:
CRITICAL AEGNT SHARDING RULES:
1. Read the entire document content
2. Identify all level 2 sections (## headings)
@@ -134,8 +132,6 @@ Create an `index.md` file in the sharded folder that:
### 5. Preserve Special Content
[[LLM: Pay special attention to preserving:
1. **Code blocks**: Must capture complete blocks including:
```language
@@ -157,7 +153,7 @@ Create an `index.md` file in the sharded folder that:
6. **Links and references**: Keep all markdown links intact
7. **Template markup**: If documents contain {{placeholders}} or [[LLM instructions]], preserve exactly]]
7. **Template markup**: If documents contain {{placeholders}} ,preserve exactly
### 6. Validation

248
bmad-core/tasks/update-workflow-plan.md
View File

@@ -1,248 +0,0 @@
# Update Workflow Plan Task
## Purpose
Update the status of steps in an active workflow plan, mark completions, add notes about deviations, and maintain an accurate record of workflow progress. This task can be called directly by users or automatically by other tasks upon completion.
## Task Instructions
### 0. Load Plan Configuration
[[LLM: First load core-config.yaml to get plan settings]]
Check workflow configuration:
- `workflow.planFile` - Location of the plan (default: docs/workflow-plan.md)
- `workflow.trackProgress` - Whether tracking is enabled
- `workflow.updateOnCompletion` - Whether to auto-update on task completion
If tracking is disabled, inform user and exit.
### 1. Verify Plan Exists
[[LLM: Check if workflow plan exists at configured location]]
If no plan exists:
```
No active workflow plan found at {location}.
Would you like to create one? Use *plan command.
```
### 2. Determine Update Type
[[LLM: Ask user what type of update they want to make]]
Present options:
```
What would you like to update in the workflow plan?
1. Mark step as complete
2. Update current step
3. Add deviation note
4. Mark decision point resolution
5. Update overall status
6. View current plan status only
Please select an option (1-6):
```
### 3. Parse Current Plan
[[LLM: Read and parse the plan to understand current state]]
Extract:
- All steps with their checkbox status
- Step IDs from comments (if present)
- Current completion percentage
- Any existing deviation notes
- Decision points and their status
### 4. Execute Updates
#### 4.1 Mark Step Complete
If user selected option 1:
1. Show numbered list of incomplete steps
2. Ask which step to mark complete
3. Update the checkbox from `[ ]` to `[x]`
4. Add completion timestamp: `<!-- completed: YYYY-MM-DD HH:MM -->`
5. If this was the current step, identify next step
#### 4.2 Update Current Step
If user selected option 2:
1. Show all steps with current status
2. Ask which step is now current
3. Add/move `<!-- current-step -->` marker
4. Optionally add note about why sequence changed
#### 4.3 Add Deviation Note
If user selected option 3:
1. Ask for deviation description
2. Ask which step this relates to (or general)
3. Insert note in appropriate location:
```markdown
> **Deviation Note** (YYYY-MM-DD): {user_note}
> Related to: Step X.Y or General workflow
```
#### 4.4 Mark Decision Resolution
If user selected option 4:
1. Show pending decision points
2. Ask which decision was made
3. Record the decision and chosen path
4. Update related steps based on decision
#### 4.5 Update Overall Status
If user selected option 5:
1. Show current overall status
2. Provide options:
- Active (continuing with plan)
- Paused (temporarily stopped)
- Abandoned (no longer following)
- Complete (all steps done)
3. Update plan header with new status
### 5. Automatic Updates (When Called by Tasks)
[[LLM: When called automatically by another task]]
If called with parameters:
```
task: {task_name}
step_id: {step_identifier}
status: complete|skipped|failed
note: {optional_note}
```
Automatically:
1. Find the corresponding step
2. Update its status
3. Add completion metadata
4. Add note if provided
5. Calculate new progress percentage
### 6. Generate Update Summary
After updates, show summary:
```
✅ Workflow Plan Updated
Changes made:
- {change_1}
- {change_2}
New Status:
- Progress: {X}% complete ({completed}/{total} steps)
- Current Step: {current_step}
- Next Recommended: {next_step}
Plan location: {file_path}
```
### 7. Integration with Other Tasks
[[LLM: How other tasks should call this]]
Other tasks can integrate by:
1. **After Task Completion**:
```
At end of task execution:
- Check if task corresponds to a plan step
- If yes, call update-workflow-plan with:
- task: {current_task_name}
- step_id: {matching_step}
- status: complete
```
2. **On Task Failure**:
```
If task fails:
- Call update-workflow-plan with:
- task: {current_task_name}
- status: failed
- note: {failure_reason}
```
### 8. Plan Status Display
[[LLM: When user selects view status only]]
Display comprehensive status:
```markdown
📋 Workflow Plan Status
━━━━━━━━━━━━━━━━━━━━
Workflow: {workflow_name}
Status: {Active|Paused|Complete}
Progress: {X}% complete ({completed}/{total} steps)
Last Updated: {timestamp}
✅ Completed Steps:
- [x] Step 1.1: {description} (completed: {date})
- [x] Step 1.2: {description} (completed: {date})
🔄 Current Step:
- [ ] Step 2.1: {description} <!-- current-step -->
Agent: {agent_name}
Task: {task_name}
📌 Upcoming Steps:
- [ ] Step 2.2: {description}
- [ ] Step 3.1: {description}
⚠️ Deviations/Notes:
{any_deviation_notes}
📊 Decision Points:
- Decision 1: {status} - {choice_made}
- Decision 2: Pending
💡 Next Action:
Based on the plan, you should {recommended_action}
```
## Success Criteria
The update is successful when:
1. Plan accurately reflects current workflow state
2. All updates are clearly timestamped
3. Deviations are documented with reasons
4. Progress calculation is correct
5. Next steps are clear to user
6. Plan remains readable and well-formatted
## Error Handling
- **Plan file not found**: Offer to create new plan
- **Malformed plan**: Attempt basic updates, warn user
- **Write permission error**: Show changes that would be made
- **Step not found**: Show available steps, ask for clarification
- **Concurrent updates**: Implement simple locking or warn about conflicts
## Notes
- Always preserve plan history (don't delete old information)
- Keep updates atomic to prevent corruption
- Consider creating backup before major updates
- Updates should enhance, not complicate, the workflow experience
- If plan becomes too cluttered, suggest creating fresh plan for next phase