chore: upgrade BMAD framework to skill-based architecture

Migrates from slash-command files (.claude/commands, .cursor/commands)
to the new skill-based architecture with workflow step files.
This commit is contained in:
2026-03-20 11:59:39 +00:00
parent d572f65684
commit e53b013359
977 changed files with 31594 additions and 29546 deletions

View File

@@ -0,0 +1,6 @@
---
name: bmad-code-review
description: 'Review code changes adversarially using parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor) with structured triage into actionable categories. Use when the user says "run code review" or "review this code"'
---
Follow the instructions in ./workflow.md.

View File

@@ -0,0 +1 @@
type: skill

View File

@@ -0,0 +1,61 @@
---
diff_output: '' # set at runtime
spec_file: '' # set at runtime (path or empty)
review_mode: '' # set at runtime: "full" or "no-spec"
---
# Step 1: Gather Context
## RULES
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
- The prompt that triggered this workflow IS the intent — not a hint.
- Do not modify any files. This step is read-only.
## INSTRUCTIONS
1. **Detect review intent from invocation text.** Check the triggering prompt for phrases that map to a review mode:
- "staged" / "staged changes" → Staged changes only
- "uncommitted" / "working tree" / "all changes" → Uncommitted changes (staged + unstaged)
- "branch diff" / "vs main" / "against main" / "compared to {branch}" → Branch diff (extract base branch if mentioned)
- "commit range" / "last N commits" / "{sha}..{sha}" → Specific commit range
- "this diff" / "provided diff" / "paste" → User-provided diff (do not match bare "diff" — it appears in other modes)
- When multiple phrases match, prefer the most specific match (e.g., "branch diff" over bare "diff").
- **If a clear match is found:** Announce the detected mode (e.g., "Detected intent: review staged changes only") and proceed directly to constructing `{diff_output}` using the corresponding sub-case from instruction 3. Skip to instruction 4 (spec question).
- **If no match from invocation text, check sprint tracking.** Look for a sprint status file (`*sprint-status*`) in `{implementation_artifacts}` or `{planning_artifacts}`. If found, scan for any story with status `review`. Handle as follows:
- **Exactly one `review` story:** Suggest it: "I found story {{story-id}} in `review` status. Would you like to review its changes? [Y] Yes / [N] No, let me choose". If confirmed, use the story context to determine the diff source (branch name derived from story slug, or uncommitted changes). If declined, fall through to instruction 2.
- **Multiple `review` stories:** Present them as numbered options alongside a manual choice option. Wait for user selection. Then use the selected story's context to determine the diff source as in the single-story case above, and proceed to instruction 3.
- **If no match and no sprint tracking:** Fall through to instruction 2.
2. HALT. Ask the user: **What do you want to review?** Present these options:
- **Uncommitted changes** (staged + unstaged)
- **Staged changes only**
- **Branch diff** vs a base branch (ask which base branch)
- **Specific commit range** (ask for the range)
- **Provided diff or file list** (user pastes or provides a path)
3. Construct `{diff_output}` from the chosen source.
- For **branch diff**: verify the base branch exists before running `git diff`. If it does not exist, HALT and ask the user for a valid branch.
- For **commit range**: verify the range resolves. If it does not, HALT and ask the user for a valid range.
- For **provided diff**: validate the content is non-empty and parseable as a unified diff. If it is not parseable, HALT and ask the user to provide a valid diff.
- For **file list**: validate each path exists in the working tree. Construct `{diff_output}` by running `git diff HEAD -- <path1> <path2> ...`. If any paths are untracked (new files not yet staged), use `git diff --no-index /dev/null <path>` to include them. If the diff is empty (files have no uncommitted changes and are not untracked), ask the user whether to review the full file contents or to specify a different baseline.
- After constructing `{diff_output}`, verify it is non-empty regardless of source type. If empty, HALT and tell the user there is nothing to review.
4. Ask the user: **Is there a spec or story file that provides context for these changes?**
- If yes: set `{spec_file}` to the path provided, verify the file exists and is readable, then set `{review_mode}` = `"full"`.
- If no: set `{review_mode}` = `"no-spec"`.
5. If `{review_mode}` = `"full"` and the file at `{spec_file}` has a `context` field in its frontmatter listing additional docs, load each referenced document. Warn the user about any docs that cannot be found.
6. Sanity check: if `{diff_output}` exceeds approximately 3000 lines, warn the user and offer to chunk the review by file group.
- If the user opts to chunk: agree on the first group, narrow `{diff_output}` accordingly, and list the remaining groups for the user to note for follow-up runs.
- If the user declines: proceed as-is with the full diff.
### CHECKPOINT
Present a summary before proceeding: diff stats (files changed, lines added/removed), `{review_mode}`, and loaded spec/context docs (if any). HALT and wait for user confirmation to proceed.
## NEXT
Read fully and follow `./step-02-review.md`

View File

@@ -0,0 +1,41 @@
---
failed_layers: '' # set at runtime: comma-separated list of layers that failed or returned empty
---
# Step 2: Review
## RULES
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
- The Blind Hunter subagent receives NO project context — diff only.
- The Edge Case Hunter subagent receives diff and project read access.
- The Acceptance Auditor subagent receives diff, spec, and context docs.
## INSTRUCTIONS
1. Launch parallel subagents. Each subagent gets NO conversation history from this session:
- **Blind Hunter** -- Invoke the `bmad-review-adversarial-general` skill in a subagent. Pass `content` = `{diff_output}` only. No spec, no project access.
- **Edge Case Hunter** -- Invoke the `bmad-review-edge-case-hunter` skill in a subagent. Pass `content` = `{diff_output}`. This subagent has read access to the project.
- **Acceptance Auditor** (only if `{review_mode}` = `"full"`) -- A subagent that receives `{diff_output}`, the content of the file at `{spec_file}`, and any loaded context docs. Its prompt:
> You are an Acceptance Auditor. Review this diff against the spec and context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
2. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
3. If `{review_mode}` = `"no-spec"`, note to the user: "Acceptance Auditor skipped — no spec file provided."
4. **Fallback** (if subagents are not available): Generate prompt files in `{implementation_artifacts}` -- one per active reviewer:
- `review-blind-hunter.md` (always)
- `review-edge-case-hunter.md` (always)
- `review-acceptance-auditor.md` (only if `{review_mode}` = `"full"`)
HALT. Tell the user to run each prompt in a separate session and paste back findings. When findings are pasted, resume from this point and proceed to step 3.
5. Collect all findings from the completed layers.
## NEXT
Read fully and follow `./step-03-triage.md`

View File

@@ -0,0 +1,50 @@
---
---
# Step 3: Triage
## RULES
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
- Be precise. When uncertain between categories, prefer the more conservative classification.
## INSTRUCTIONS
1. **Normalize** findings into a common format. Expected input formats:
- Adversarial (Blind Hunter): markdown list of descriptions
- Edge Case Hunter: JSON array with `location`, `trigger_condition`, `guard_snippet`, `potential_consequence` fields
- Acceptance Auditor: markdown list with title, AC/constraint reference, and evidence
If a layer's output does not match its expected format, attempt best-effort parsing. Note any parsing issues for the user.
Convert all to a unified list where each finding has:
- `id` -- sequential integer
- `source` -- `blind`, `edge`, `auditor`, or merged sources (e.g., `blind+edge`)
- `title` -- one-line summary
- `detail` -- full description
- `location` -- file and line reference (if available)
2. **Deduplicate.** If two or more findings describe the same issue, merge them into one:
- Use the most specific finding as the base (prefer edge-case JSON with location over adversarial prose).
- Append any unique detail, reasoning, or location references from the other finding(s) into the surviving `detail` field.
- Set `source` to the merged sources (e.g., `blind+edge`).
3. **Classify** each finding into exactly one bucket:
- **intent_gap** -- The spec/intent is incomplete; cannot resolve from existing information. Only possible if `{review_mode}` = `"full"`.
- **bad_spec** -- The spec should have prevented this; spec is wrong or ambiguous. Only possible if `{review_mode}` = `"full"`.
- **patch** -- Code issue that is trivially fixable without human input. Just needs a code change.
- **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
- **reject** -- Noise, false positive, or handled elsewhere.
If `{review_mode}` = `"no-spec"` and a finding would otherwise be `intent_gap` or `bad_spec`, reclassify it as `patch` (if code-fixable) or `defer` (if not).
4. **Drop** all `reject` findings. Record the reject count for the summary.
5. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping rejects AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
6. If zero findings remain after dropping rejects and no layers failed, note clean review.
## NEXT
Read fully and follow `./step-04-present.md`

View File

@@ -0,0 +1,38 @@
---
---
# Step 4: Present
## RULES
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
- Do NOT auto-fix anything. Present findings and let the user decide next steps.
## INSTRUCTIONS
1. Group remaining findings by category.
2. Present to the user in this order (include a section only if findings exist in that category):
- **Intent Gaps**: "These findings suggest the captured intent is incomplete. Consider clarifying intent before proceeding."
- List each with title + detail.
- **Bad Spec**: "These findings suggest the spec should be amended. Consider regenerating or amending the spec with this context:"
- List each with title + detail + suggested spec amendment.
- **Patch**: "These are fixable code issues:"
- List each with title + detail + location (if available).
- **Defer**: "Pre-existing issues surfaced by this review (not caused by current changes):"
- List each with title + detail.
3. Summary line: **X** intent_gap, **Y** bad_spec, **Z** patch, **W** defer findings. **R** findings rejected as noise.
4. If clean review (zero findings across all layers after triage): state that N findings were raised but all were classified as noise, or that no findings were raised at all (as applicable).
5. Offer the user next steps (recommendations, not automated actions):
- If `patch` findings exist: "These can be addressed in a follow-up implementation pass or manually."
- If `intent_gap` or `bad_spec` findings exist: "Consider running the planning workflow to clarify intent or amend the spec before continuing."
- If only `defer` findings remain: "No action needed for this change. Deferred items are noted for future attention."
Workflow complete.

View File

@@ -0,0 +1,54 @@
---
main_config: '{project-root}/_bmad/bmm/config.yaml'
---
# Code Review Workflow
**Goal:** Review code changes adversarially using parallel review layers and structured triage.
**Your Role:** You are an elite code reviewer. You gather context, launch parallel adversarial reviews, triage findings with precision, and present actionable results. No noise, no filler.
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution:
- **Micro-file Design**: Each step is self-contained and followed exactly
- **Just-In-Time Loading**: Only load the current step file
- **Sequential Enforcement**: Complete steps in order, no skipping
- **State Tracking**: Persist progress via in-memory variables
- **Append-Only Building**: Build artifacts incrementally
### Step Processing Rules
1. **READ COMPLETELY**: Read the entire step file before acting
2. **FOLLOW SEQUENCE**: Execute sections in order
3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
4. **LOAD NEXT**: When directed, read fully and follow the next step file
### Critical Rules (NO EXCEPTIONS)
- **NEVER** load multiple step files simultaneously
- **ALWAYS** read entire step file before execution
- **NEVER** skip steps or optimize the sequence
- **ALWAYS** follow the exact instructions in the step file
- **ALWAYS** halt at checkpoints and wait for human input
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{main_config}` and resolve:
- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as system-generated current datetime
- `project_context` = `**/project-context.md` (load if exists)
- CLAUDE.md / memory files (load if exist)
YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
### 2. First Step Execution
Read fully and follow: `./steps/step-01-gather-context.md` to begin the workflow.

View File

@@ -0,0 +1,6 @@
---
name: bmad-correct-course
description: 'Manage significant changes during sprint execution. Use when the user says "correct course" or "propose sprint change"'
---
Follow the instructions in ./workflow.md.

View File

@@ -1,6 +1,6 @@
# Change Navigation Checklist
<critical>This checklist is executed as part of: {project-root}/_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml</critical>
<critical>This checklist is executed as part of: ./workflow.md</critical>
<critical>Work through each section systematically with the user, recording findings and impacts</critical>
<checklist>

View File

@@ -1,16 +1,81 @@
# Correct Course - Sprint Change Management Instructions
# Correct Course - Sprint Change Management Workflow
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
**Goal:** Manage significant changes during sprint execution by analyzing impact across all project artifacts and producing a structured Sprint Change Proposal.
<critical>DOCUMENT OUTPUT: Updated epics, stories, or PRD sections. Clear, actionable changes. User skill level ({user_skill_level}) affects conversation style ONLY, not document updates.</critical>
**Your Role:** You are a Scrum Master navigating change management. Analyze the triggering issue, assess impact across PRD, epics, architecture, and UX artifacts, and produce an actionable Sprint Change Proposal with clear handoff.
---
## INITIALIZATION
### Configuration Loading
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `user_name`
- `communication_language`, `document_output_language`
- `user_skill_level`
- `implementation_artifacts`
- `planning_artifacts`
- `project_knowledge`
- `date` as system-generated current datetime
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
- Language MUST be tailored to `{user_skill_level}`
- Generate all documents in `{document_output_language}`
- DOCUMENT OUTPUT: Updated epics, stories, or PRD sections. Clear, actionable changes. User skill level (`{user_skill_level}`) affects conversation style ONLY, not document updates.
### Paths
- `default_output_file` = `{planning_artifacts}/sprint-change-proposal-{date}.md`
### Input Files
| Input | Path | Load Strategy |
|-------|------|---------------|
| PRD | `{planning_artifacts}/*prd*.md` (whole) or `{planning_artifacts}/*prd*/*.md` (sharded) | FULL_LOAD |
| Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD |
| Architecture | `{planning_artifacts}/*architecture*.md` (whole) or `{planning_artifacts}/*architecture*/*.md` (sharded) | FULL_LOAD |
| UX Design | `{planning_artifacts}/*ux*.md` (whole) or `{planning_artifacts}/*ux*/*.md` (sharded) | FULL_LOAD |
| Tech Spec | `{planning_artifacts}/*tech-spec*.md` (whole) | FULL_LOAD |
| Document Project | `{project_knowledge}/index.md` (sharded) | INDEX_GUIDED |
### Context
- Load `**/project-context.md` if it exists
---
## EXECUTION
### Document Discovery - Loading Project Artifacts
**Strategy**: Course correction needs broad project context to assess change impact accurately. Load all available planning artifacts.
**Discovery Process for FULL_LOAD documents (PRD, Epics, Architecture, UX Design, Tech Spec):**
1. **Search for whole document first** - Look for files matching the whole-document pattern (e.g., `*prd*.md`, `*epic*.md`, `*architecture*.md`, `*ux*.md`, `*tech-spec*.md`)
2. **Check for sharded version** - If whole document not found, look for a directory with `index.md` (e.g., `prd/index.md`, `epics/index.md`)
3. **If sharded version found**:
- Read `index.md` to understand the document structure
- Read ALL section files listed in the index
- Process the combined content as a single document
4. **Priority**: If both whole and sharded versions exist, use the whole document
**Discovery Process for INDEX_GUIDED documents (Document Project):**
1. **Search for index file** - Look for `{project_knowledge}/index.md`
2. **If found**: Read the index to understand available documentation sections
3. **Selectively load sections** based on relevance to the change being analyzed — do NOT load everything, only sections that relate to the impacted areas
4. **This document is optional** — skip if `{project_knowledge}` does not exist (greenfield projects)
**Fuzzy matching**: Be flexible with document names — users may use variations like `prd.md`, `bmm-prd.md`, `product-requirements.md`, etc.
**Missing documents**: Not all documents may exist. PRD and Epics are essential; Architecture, UX Design, Tech Spec, and Document Project are loaded if available. HALT if PRD or Epics cannot be found.
<workflow>
<step n="1" goal="Initialize Change Navigation">
<action>Load {project_context} for coding standards and project-wide patterns (if exists)</action>
<action>Load **/project-context.md for coding standards and project-wide patterns (if exists)</action>
<action>Confirm change trigger and gather user description of the issue</action>
<action>Ask: "What specific issue or change has been identified that requires navigation?"</action>
<action>Verify access to required project documents:</action>
@@ -28,13 +93,8 @@
<action if="core documents are unavailable">HALT: "Need access to project documents (PRD, Epics, Architecture, UI/UX) to assess change impact. Please ensure these documents are accessible."</action>
</step>
<step n="0.5" goal="Discover and load project documents">
<invoke-protocol name="discover_inputs" />
<note>After discovery, these content variables are available: {prd_content}, {epics_content}, {architecture_content}, {ux_design_content}, {tech_spec_content}, {document_project_content}</note>
</step>
<step n="2" goal="Execute Change Analysis Checklist">
<action>Read fully and follow the systematic analysis from: {checklist}</action>
<action>Read fully and follow the systematic analysis from: checklist.md</action>
<action>Work through each checklist section interactively with the user</action>
<action>Record status for each checklist item:</action>
- [x] Done - Item completed successfully
@@ -200,7 +260,7 @@
- Specific edit proposals with before/after
- Implementation handoff plan
<action>Report workflow completion to user with personalized message: "Correct Course workflow complete, {user_name}!"</action>
<action>Report workflow completion to user with personalized message: "Correct Course workflow complete, {user_name}!"</action>
<action>Remind user of success criteria and next steps for implementation team</action>
</step>

View File

@@ -0,0 +1,6 @@
---
name: bmad-create-story
description: 'Creates a dedicated story file with all the context the agent will need to implement it later. Use when the user says "create the next story" or "create story [story identifier]"'
---
Follow the instructions in ./workflow.md.

View File

@@ -0,0 +1 @@
type: skill

View File

@@ -33,25 +33,25 @@ This is a COMPETITION to create the **ULTIMATE story context** that makes LLM de
### **When Running from Create-Story Workflow:**
- The `{project-root}/_bmad/core/tasks/workflow.xml` framework will automatically:
- The workflow framework will automatically:
- Load this checklist file
- Load the newly created story file (`{story_file_path}`)
- Load workflow variables from `{installed_path}/workflow.yaml`
- Load workflow variables from `./workflow.md`
- Execute the validation process
### **When Running in Fresh Context:**
- User should provide the story file path being reviewed
- Load the story file directly
- Load the corresponding workflow.yaml for variable context
- Load the corresponding workflow.md for variable context
- Proceed with systematic analysis
### **Required Inputs:**
- **Story file**: The story file to review and improve
- **Workflow variables**: From workflow.yaml (implementation_artifacts, epics_file, etc.)
- **Workflow variables**: From workflow.md (implementation_artifacts, epics_file, etc.)
- **Source documents**: Epics, architecture, etc. (discovered or provided)
- **Validation framework**: `validate-workflow.xml` (handles checklist execution)
- **Validation framework**: The workflow's checklist execution system
---
@@ -61,12 +61,11 @@ You will systematically re-do the entire story creation process, but with a crit
### **Step 1: Load and Understand the Target**
1. **Load the workflow configuration**: `{installed_path}/workflow.yaml` for variable inclusion
1. **Load the workflow configuration**: `./workflow.md` for variable inclusion
2. **Load the story file**: `{story_file_path}` (provided by user or discovered)
3. **Load validation framework**: `{project-root}/_bmad/core/tasks/workflow.xml`
4. **Extract metadata**: epic_num, story_num, story_key, story_title from story file
5. **Resolve all workflow variables**: implementation_artifacts, epics_file, architecture_file, etc.
6. **Understand current status**: What story implementation guidance is currently provided?
3. **Extract metadata**: epic_num, story_num, story_key, story_title from story file
4. **Resolve all workflow variables**: implementation_artifacts, epics_file, architecture_file, etc.
5. **Understand current status**: What story implementation guidance is currently provided?
**Note:** If running in fresh context, user should provide the story file path being reviewed. If running from create-story workflow, the validation framework will automatically discover the checklist and story file.

View File

@@ -0,0 +1,88 @@
# Discover Inputs Protocol
**Objective:** Intelligently load project files (whole or sharded) based on the workflow's Input Files configuration.
**Prerequisite:** Only execute this protocol if the workflow defines an Input Files section. If no input file patterns are configured, skip this entirely.
---
## Step 1: Parse Input File Patterns
- Read the Input Files table from the workflow configuration.
- For each input group (prd, architecture, epics, ux, etc.), note the **load strategy** if specified.
## Step 2: Load Files Using Smart Strategies
For each pattern in the Input Files table, work through the following substeps in order:
### 2a: Try Sharded Documents First
If a sharded pattern exists for this input, determine the load strategy (defaults to **FULL_LOAD** if not specified), then apply the matching strategy:
#### FULL_LOAD Strategy
Load ALL files in the sharded directory. Use this for PRD, Architecture, UX, brownfield docs, or whenever the full picture is needed.
1. Use the glob pattern to find ALL `.md` files (e.g., `{planning_artifacts}/*architecture*/*.md`).
2. Load EVERY matching file completely.
3. Concatenate content in logical order: `index.md` first if it exists, then alphabetical.
4. Store the combined result in a variable named `{pattern_name_content}` (e.g., `{architecture_content}`).
#### SELECTIVE_LOAD Strategy
Load a specific shard using a template variable. Example: used for epics with `{{epic_num}}`.
1. Check for template variables in the sharded pattern (e.g., `{{epic_num}}`).
2. If the variable is undefined, ask the user for the value OR infer it from context.
3. Resolve the template to a specific file path.
4. Load that specific file.
5. Store in variable: `{pattern_name_content}`.
#### INDEX_GUIDED Strategy
Load index.md, analyze the structure and description of each doc in the index, then intelligently load relevant docs.
**DO NOT BE LAZY** -- use best judgment to load documents that might have relevant information, even if there is only a 5% chance of relevance.
1. Load `index.md` from the sharded directory.
2. Parse the table of contents, links, and section headers.
3. Analyze the workflow's purpose and objective.
4. Identify which linked/referenced documents are likely relevant.
- *Example:* If the workflow is about authentication and the index shows "Auth Overview", "Payment Setup", "Deployment" -- load the auth docs, consider deployment docs, skip payment.
5. Load all identified relevant documents.
6. Store combined content in variable: `{pattern_name_content}`.
**When in doubt, LOAD IT** -- context is valuable, and being thorough is better than missing critical info.
---
After applying the matching strategy, mark the pattern as **RESOLVED** and move to the next pattern.
### 2b: Try Whole Document if No Sharded Found
If no sharded matches were found OR no sharded pattern exists for this input:
1. Attempt a glob match on the "whole" pattern (e.g., `{planning_artifacts}/*prd*.md`).
2. If matches are found, load ALL matching files completely (no offset/limit).
3. Store content in variable: `{pattern_name_content}` (e.g., `{prd_content}`).
4. Mark pattern as **RESOLVED** and move to the next pattern.
### 2c: Handle Not Found
If no matches were found for either sharded or whole patterns:
1. Set `{pattern_name_content}` to empty string.
2. Note in session: "No {pattern_name} files found" -- this is not an error, just unavailable. Offer the user a chance to provide the file.
## Step 3: Report Discovery Results
List all loaded content variables with file counts. Example:
```
OK Loaded {prd_content} from 5 sharded files: prd/index.md, prd/requirements.md, ...
OK Loaded {architecture_content} from 1 file: Architecture.md
OK Loaded {epics_content} from selective load: epics/epic-3.md
-- No ux_design files found
```
This gives the workflow transparency into what context is available.

View File

@@ -0,0 +1,380 @@
# Create Story Workflow
**Goal:** Create a comprehensive story file that gives the dev agent everything needed for flawless implementation.
**Your Role:** Story context engine that prevents LLM developer mistakes, omissions, or disasters.
- Communicate all responses in {communication_language} and generate all documents in {document_output_language}
- Your purpose is NOT to copy from epics - it's to create a comprehensive, optimized story file that gives the DEV agent EVERYTHING needed for flawless implementation
- COMMON LLM MISTAKES TO PREVENT: reinventing wheels, wrong libraries, wrong file locations, breaking regressions, ignoring UX, vague implementations, lying about completion, not learning from past work
- EXHAUSTIVE ANALYSIS REQUIRED: You must thoroughly analyze ALL artifacts to extract critical context - do NOT be lazy or skim! This is the most important function in the entire development process!
- UTILIZE SUBPROCESSES AND SUBAGENTS: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different artifacts simultaneously and thoroughly
- SAVE QUESTIONS: If you think of questions or clarifications during analysis, save them for the end after the complete story is written
- ZERO USER INTERVENTION: Process should be fully automated except for initial epic/story selection or missing documents
---
## INITIALIZATION
### Configuration Loading
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `user_name`
- `communication_language`, `document_output_language`
- `user_skill_level`
- `planning_artifacts`, `implementation_artifacts`
- `date` as system-generated current datetime
### Paths
- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
- `epics_file` = `{planning_artifacts}/epics.md`
- `prd_file` = `{planning_artifacts}/prd.md`
- `architecture_file` = `{planning_artifacts}/architecture.md`
- `ux_file` = `{planning_artifacts}/*ux*.md`
- `story_title` = "" (will be elicited if not derivable)
- `project_context` = `**/project-context.md` (load if exists)
- `default_output_file` = `{implementation_artifacts}/{{story_key}}.md`
### Input Files
| Input | Description | Path Pattern(s) | Load Strategy |
|-------|-------------|------------------|---------------|
| prd | PRD (fallback - epics file should have most content) | whole: `{planning_artifacts}/*prd*.md`, sharded: `{planning_artifacts}/*prd*/*.md` | SELECTIVE_LOAD |
| architecture | Architecture (fallback - epics file should have relevant sections) | whole: `{planning_artifacts}/*architecture*.md`, sharded: `{planning_artifacts}/*architecture*/*.md` | SELECTIVE_LOAD |
| ux | UX design (fallback - epics file should have relevant sections) | whole: `{planning_artifacts}/*ux*.md`, sharded: `{planning_artifacts}/*ux*/*.md` | SELECTIVE_LOAD |
| epics | Enhanced epics+stories file with BDD and source hints | whole: `{planning_artifacts}/*epic*.md`, sharded: `{planning_artifacts}/*epic*/*.md` | SELECTIVE_LOAD |
---
## EXECUTION
<workflow>
<step n="1" goal="Determine target story">
<check if="{{story_path}} is provided by user or user provided the epic and story number such as 2-4 or 1.6 or epic 1 story 5">
<action>Parse user-provided story path: extract epic_num, story_num, story_title from format like "1-2-user-auth"</action>
<action>Set {{epic_num}}, {{story_num}}, {{story_key}} from user input</action>
<action>GOTO step 2a</action>
</check>
<action>Check if {{sprint_status}} file exists for auto discover</action>
<check if="sprint status file does NOT exist">
<output>🚫 No sprint status file found and no story specified</output>
<output>
**Required Options:**
1. Run `sprint-planning` to initialize sprint tracking (recommended)
2. Provide specific epic-story number to create (e.g., "1-2-user-auth")
3. Provide path to story documents if sprint status doesn't exist yet
</output>
<ask>Choose option [1], provide epic-story number, path to story docs, or [q] to quit:</ask>
<check if="user chooses 'q'">
<action>HALT - No work needed</action>
</check>
<check if="user chooses '1'">
<output>Run sprint-planning workflow first to create sprint-status.yaml</output>
<action>HALT - User needs to run sprint-planning</action>
</check>
<check if="user provides epic-story number">
<action>Parse user input: extract epic_num, story_num, story_title</action>
<action>Set {{epic_num}}, {{story_num}}, {{story_key}} from user input</action>
<action>GOTO step 2a</action>
</check>
<check if="user provides story docs path">
<action>Use user-provided path for story documents</action>
<action>GOTO step 2a</action>
</check>
</check>
<!-- Auto-discover from sprint status only if no user input -->
<check if="no user input provided">
<critical>MUST read COMPLETE {sprint_status} file from start to end to preserve order</critical>
<action>Load the FULL file: {{sprint_status}}</action>
<action>Read ALL lines from beginning to end - do not skip any content</action>
<action>Parse the development_status section completely</action>
<action>Find the FIRST story (by reading in order from top to bottom) where:
- Key matches pattern: number-number-name (e.g., "1-2-user-auth")
- NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
- Status value equals "backlog"
</action>
<check if="no backlog story found">
<output>📋 No backlog stories found in sprint-status.yaml
All stories are either already created, in progress, or done.
**Options:**
1. Run sprint-planning to refresh story tracking
2. Load PM agent and run correct-course to add more stories
3. Check if current sprint is complete and run retrospective
</output>
<action>HALT</action>
</check>
<action>Extract from found story key (e.g., "1-2-user-authentication"):
- epic_num: first number before dash (e.g., "1")
- story_num: second number after first dash (e.g., "2")
- story_title: remainder after second dash (e.g., "user-authentication")
</action>
<action>Set {{story_id}} = "{{epic_num}}.{{story_num}}"</action>
<action>Store story_key for later use (e.g., "1-2-user-authentication")</action>
<!-- Mark epic as in-progress if this is first story -->
<action>Check if this is the first story in epic {{epic_num}} by looking for {{epic_num}}-1-* pattern</action>
<check if="this is first story in epic {{epic_num}}">
<action>Load {{sprint_status}} and check epic-{{epic_num}} status</action>
<action>If epic status is "backlog" → update to "in-progress"</action>
<action>If epic status is "contexted" (legacy status) → update to "in-progress" (backward compatibility)</action>
<action>If epic status is "in-progress" → no change needed</action>
<check if="epic status is 'done'">
<output>🚫 ERROR: Cannot create story in completed epic</output>
<output>Epic {{epic_num}} is marked as 'done'. All stories are complete.</output>
<output>If you need to add more work, either:</output>
<output>1. Manually change epic status back to 'in-progress' in sprint-status.yaml</output>
<output>2. Create a new epic for additional work</output>
<action>HALT - Cannot proceed</action>
</check>
<check if="epic status is not one of: backlog, contexted, in-progress, done">
<output>🚫 ERROR: Invalid epic status '{{epic_status}}'</output>
<output>Epic {{epic_num}} has invalid status. Expected: backlog, in-progress, or done</output>
<output>Please fix sprint-status.yaml manually or run sprint-planning to regenerate</output>
<action>HALT - Cannot proceed</action>
</check>
<output>📊 Epic {{epic_num}} status updated to in-progress</output>
</check>
<action>GOTO step 2a</action>
</check>
<action>Load the FULL file: {{sprint_status}}</action>
<action>Read ALL lines from beginning to end - do not skip any content</action>
<action>Parse the development_status section completely</action>
<action>Find the FIRST story (by reading in order from top to bottom) where:
- Key matches pattern: number-number-name (e.g., "1-2-user-auth")
- NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
- Status value equals "backlog"
</action>
<check if="no backlog story found">
<output>No backlog stories found in sprint-status.yaml
All stories are either already created, in progress, or done.
**Options:**
1. Run sprint-planning to refresh story tracking
2. Load PM agent and run correct-course to add more stories
3. Check if current sprint is complete and run retrospective
</output>
<action>HALT</action>
</check>
<action>Extract from found story key (e.g., "1-2-user-authentication"):
- epic_num: first number before dash (e.g., "1")
- story_num: second number after first dash (e.g., "2")
- story_title: remainder after second dash (e.g., "user-authentication")
</action>
<action>Set {{story_id}} = "{{epic_num}}.{{story_num}}"</action>
<action>Store story_key for later use (e.g., "1-2-user-authentication")</action>
<!-- Mark epic as in-progress if this is first story -->
<action>Check if this is the first story in epic {{epic_num}} by looking for {{epic_num}}-1-* pattern</action>
<check if="this is first story in epic {{epic_num}}">
<action>Load {{sprint_status}} and check epic-{{epic_num}} status</action>
<action>If epic status is "backlog" → update to "in-progress"</action>
<action>If epic status is "contexted" (legacy status) → update to "in-progress" (backward compatibility)</action>
<action>If epic status is "in-progress" → no change needed</action>
<check if="epic status is 'done'">
<output>ERROR: Cannot create story in completed epic</output>
<output>Epic {{epic_num}} is marked as 'done'. All stories are complete.</output>
<output>If you need to add more work, either:</output>
<output>1. Manually change epic status back to 'in-progress' in sprint-status.yaml</output>
<output>2. Create a new epic for additional work</output>
<action>HALT - Cannot proceed</action>
</check>
<check if="epic status is not one of: backlog, contexted, in-progress, done">
<output>ERROR: Invalid epic status '{{epic_status}}'</output>
<output>Epic {{epic_num}} has invalid status. Expected: backlog, in-progress, or done</output>
<output>Please fix sprint-status.yaml manually or run sprint-planning to regenerate</output>
<action>HALT - Cannot proceed</action>
</check>
<output>Epic {{epic_num}} status updated to in-progress</output>
</check>
<action>GOTO step 2a</action>
</step>
<step n="2" goal="Load and analyze core artifacts">
<critical>🔬 EXHAUSTIVE ARTIFACT ANALYSIS - This is where you prevent future developer mistakes!</critical>
<!-- Load all available content through discovery protocol -->
<action>Read fully and follow `./discover-inputs.md` to load all input files</action>
<note>Available content: {epics_content}, {prd_content}, {architecture_content}, {ux_content},
{project_context}</note>
<!-- Analyze epics file for story foundation -->
<action>From {epics_content}, extract Epic {{epic_num}} complete context:</action> **EPIC ANALYSIS:** - Epic
objectives and business value - ALL stories in this epic for cross-story context - Our specific story's requirements, user story
statement, acceptance criteria - Technical requirements and constraints - Dependencies on other stories/epics - Source hints pointing to
original documents <!-- Extract specific story requirements -->
<action>Extract our story ({{epic_num}}-{{story_num}}) details:</action> **STORY FOUNDATION:** - User story statement
(As a, I want, so that) - Detailed acceptance criteria (already BDD formatted) - Technical requirements specific to this story -
Business context and value - Success criteria <!-- Previous story analysis for context continuity -->
<check if="story_num > 1">
<action>Find {{previous_story_num}}: scan {implementation_artifacts} for the story file in epic {{epic_num}} with the highest story number less than {{story_num}}</action>
<action>Load previous story file: {implementation_artifacts}/{{epic_num}}-{{previous_story_num}}-*.md</action> **PREVIOUS STORY INTELLIGENCE:** -
Dev notes and learnings from previous story - Review feedback and corrections needed - Files that were created/modified and their
patterns - Testing approaches that worked/didn't work - Problems encountered and solutions found - Code patterns established <action>Extract
all learnings that could impact current story implementation</action>
</check>
<!-- Git intelligence for previous work patterns -->
<check
if="previous story exists AND git repository detected">
<action>Get last 5 commit titles to understand recent work patterns</action>
<action>Analyze 1-5 most recent commits for relevance to current story:
- Files created/modified
- Code patterns and conventions used
- Library dependencies added/changed
- Architecture decisions implemented
- Testing approaches used
</action>
<action>Extract actionable insights for current story implementation</action>
</check>
</step>
<step n="3" goal="Architecture analysis for developer guardrails">
<critical>🏗️ ARCHITECTURE INTELLIGENCE - Extract everything the developer MUST follow!</critical> **ARCHITECTURE DOCUMENT ANALYSIS:** <action>Systematically
analyze architecture content for story-relevant requirements:</action>
<!-- Load architecture - single file or sharded -->
<check if="architecture file is single file">
<action>Load complete {architecture_content}</action>
</check>
<check if="architecture is sharded to folder">
<action>Load architecture index and scan all architecture files</action>
</check> **CRITICAL ARCHITECTURE EXTRACTION:** <action>For
each architecture section, determine if relevant to this story:</action> - **Technical Stack:** Languages, frameworks, libraries with
versions - **Code Structure:** Folder organization, naming conventions, file patterns - **API Patterns:** Service structure, endpoint
patterns, data contracts - **Database Schemas:** Tables, relationships, constraints relevant to story - **Security Requirements:**
Authentication patterns, authorization rules - **Performance Requirements:** Caching strategies, optimization patterns - **Testing
Standards:** Testing frameworks, coverage expectations, test patterns - **Deployment Patterns:** Environment configurations, build
processes - **Integration Patterns:** External service integrations, data flows <action>Extract any story-specific requirements that the
developer MUST follow</action>
<action>Identify any architectural decisions that override previous patterns</action>
</step>
<step n="4" goal="Web research for latest technical specifics">
<critical>🌐 ENSURE LATEST TECH KNOWLEDGE - Prevent outdated implementations!</critical> **WEB INTELLIGENCE:** <action>Identify specific
technical areas that require latest version knowledge:</action>
<!-- Check for libraries/frameworks mentioned in architecture -->
<action>From architecture analysis, identify specific libraries, APIs, or
frameworks</action>
<action>For each critical technology, research latest stable version and key changes:
- Latest API documentation and breaking changes
- Security vulnerabilities or updates
- Performance improvements or deprecations
- Best practices for current version
</action>
**EXTERNAL CONTEXT INCLUSION:** <action>Include in story any critical latest information the developer needs:
- Specific library versions and why chosen
- API endpoints with parameters and authentication
- Recent security patches or considerations
- Performance optimization techniques
- Migration considerations if upgrading
</action>
</step>
<step n="5" goal="Create comprehensive story file">
<critical>📝 CREATE ULTIMATE STORY FILE - The developer's master implementation guide!</critical>
<action>Initialize from template.md:
{default_output_file}</action>
<template-output file="{default_output_file}">story_header</template-output>
<!-- Story foundation from epics analysis -->
<template-output
file="{default_output_file}">story_requirements</template-output>
<!-- Developer context section - MOST IMPORTANT PART -->
<template-output file="{default_output_file}">
developer_context_section</template-output> **DEV AGENT GUARDRAILS:** <template-output file="{default_output_file}">
technical_requirements</template-output>
<template-output file="{default_output_file}">architecture_compliance</template-output>
<template-output
file="{default_output_file}">library_framework_requirements</template-output>
<template-output file="{default_output_file}">
file_structure_requirements</template-output>
<template-output file="{default_output_file}">testing_requirements</template-output>
<!-- Previous story intelligence -->
<check
if="previous story learnings available">
<template-output file="{default_output_file}">previous_story_intelligence</template-output>
</check>
<!-- Git intelligence -->
<check
if="git analysis completed">
<template-output file="{default_output_file}">git_intelligence_summary</template-output>
</check>
<!-- Latest technical specifics -->
<check if="web research completed">
<template-output file="{default_output_file}">latest_tech_information</template-output>
</check>
<!-- Project context reference -->
<template-output
file="{default_output_file}">project_context_reference</template-output>
<!-- Final status update -->
<template-output file="{default_output_file}">
story_completion_status</template-output>
<!-- CRITICAL: Set status to ready-for-dev -->
<action>Set story Status to: "ready-for-dev"</action>
<action>Add completion note: "Ultimate
context engine analysis completed - comprehensive developer guide created"</action>
</step>
<step n="6" goal="Update sprint status and finalize">
<action>Validate the newly created story file {default_output_file} against `./checklist.md` and apply any required fixes before finalizing</action>
<action>Save story document unconditionally</action>
<!-- Update sprint status -->
<check if="sprint status file exists">
<action>Update {{sprint_status}}</action>
<action>Load the FULL file and read all development_status entries</action>
<action>Find development_status key matching {{story_key}}</action>
<action>Verify current status is "backlog" (expected previous state)</action>
<action>Update development_status[{{story_key}}] = "ready-for-dev"</action>
<action>Update last_updated field to current date</action>
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
</check>
<action>Report completion</action>
<output>**🎯 ULTIMATE BMad Method STORY CONTEXT CREATED, {user_name}!**
**Story Details:**
- Story ID: {{story_id}}
- Story Key: {{story_key}}
- File: {{story_file}}
- Status: ready-for-dev
**Next Steps:**
1. Review the comprehensive story in {{story_file}}
2. Run dev agents `dev-story` for optimized implementation
3. Run `code-review` when complete (auto-marks done)
4. Optional: If Test Architect module installed, run `/bmad:tea:automate` after `dev-story` to generate guardrail tests
**The developer now has everything needed for flawless implementation!**
</output>
</step>
</workflow>

View File

@@ -0,0 +1,6 @@
---
name: bmad-dev-story
description: 'Execute story implementation following a context filled story spec file. Use when the user says "dev this story [story file]" or "implement the next story in the sprint plan"'
---
Follow the instructions in ./workflow.md.

View File

@@ -0,0 +1 @@
type: skill

View File

@@ -1,6 +1,44 @@
# Dev Story Workflow
**Goal:** Execute story implementation following a context filled story spec file.
**Your Role:** Developer implementing the story.
- Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
- Generate all documents in {document_output_language}
- Only modify the story file in these areas: Tasks/Subtasks checkboxes, Dev Agent Record (Debug Log, Completion Notes), File List, Change Log, and Status
- Execute ALL steps in exact order; do NOT skip steps
- Absolutely DO NOT stop because of "milestones", "significant progress", or "session boundaries". Continue in a single execution until the story is COMPLETE (all ACs satisfied and all tasks/subtasks checked) UNLESS a HALT condition is triggered or the USER gives other instruction.
- Do NOT schedule a "next session" or request review pauses unless a HALT condition applies. Only Step 6 decides completion.
- User skill level ({user_skill_level}) affects conversation style ONLY, not code updates.
---
## INITIALIZATION
### Configuration Loading
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `user_name`
- `communication_language`, `document_output_language`
- `user_skill_level`
- `implementation_artifacts`
- `date` as system-generated current datetime
### Paths
- `story_file` = `` (explicit story path; auto-discovered if empty)
- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
### Context
- `project_context` = `**/project-context.md` (load if exists)
---
## EXECUTION
<workflow>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>Only modify the story file in these areas: Tasks/Subtasks checkboxes, Dev Agent Record (Debug Log, Completion Notes), File List,
@@ -195,6 +233,7 @@
<check if="current status == 'ready-for-dev' OR review_continuation == true">
<action>Update the story in the sprint status report to = "in-progress"</action>
<action>Update last_updated field to current date</action>
<output>🚀 Starting work on story {{story_key}}
Status updated: ready-for-dev → in-progress
</output>
@@ -348,6 +387,7 @@
<action>Find development_status key matching {{story_key}}</action>
<action>Verify current status is "in-progress" (expected previous state)</action>
<action>Update development_status[{{story_key}}] = "review"</action>
<action>Update last_updated field to current date</action>
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
<output>✅ Story status updated to "review" in sprint-status.yaml</output>
</check>

View File

@@ -0,0 +1,6 @@
---
name: bmad-retrospective
description: 'Post-epic review to extract lessons and assess success. Use when the user says "run a retrospective" or "lets retro the epic [epic]"'
---
Follow the instructions in ./workflow.md.

View File

@@ -1,31 +1,65 @@
# Retrospective - Epic Completion Review Instructions
# Retrospective Workflow
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmm/workflows/4-implementation/retrospective/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
**Goal:** Post-epic review to extract lessons and assess success.
<critical>
DOCUMENT OUTPUT: Retrospective analysis. Concise insights, lessons learned, action items. User skill level ({user_skill_level}) affects conversation style ONLY, not retrospective content.
**Your Role:** Scrum Master facilitating retrospective.
- No time estimates — NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed.
- Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
- Generate all documents in {document_output_language}
- Document output: Retrospective analysis. Concise insights, lessons learned, action items. User skill level ({user_skill_level}) affects conversation style ONLY, not retrospective content.
- Facilitation notes:
- Psychological safety is paramount - NO BLAME
- Focus on systems, processes, and learning
- Everyone contributes with specific examples preferred
- Action items must be achievable with clear ownership
- Two-part format: (1) Epic Review + (2) Next Epic Preparation
- Party mode protocol:
- ALL agent dialogue MUST use format: "Name (Role): dialogue"
- Example: Bob (Scrum Master): "Let's begin..."
- Example: {user_name} (Project Lead): [User responds]
- Create natural back-and-forth with user actively participating
- Show disagreements, diverse perspectives, authentic team dynamics
FACILITATION NOTES:
---
- Scrum Master facilitates this retrospective
- Psychological safety is paramount - NO BLAME
- Focus on systems, processes, and learning
- Everyone contributes with specific examples preferred
- Action items must be achievable with clear ownership
- Two-part format: (1) Epic Review + (2) Next Epic Preparation
## INITIALIZATION
PARTY MODE PROTOCOL:
### Configuration Loading
- ALL agent dialogue MUST use format: "Name (Role): dialogue"
- Example: Bob (Scrum Master): "Let's begin..."
- Example: {user_name} (Project Lead): [User responds]
- Create natural back-and-forth with user actively participating
- Show disagreements, diverse perspectives, authentic team dynamics
</critical>
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `user_name`
- `communication_language`, `document_output_language`
- `user_skill_level`
- `planning_artifacts`, `implementation_artifacts`
- `date` as system-generated current datetime
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
### Paths
- `sprint_status_file` = `{implementation_artifacts}/sprint-status.yaml`
### Input Files
| Input | Description | Path Pattern(s) | Load Strategy |
|-------|-------------|------------------|---------------|
| epics | The completed epic for retrospective | whole: `{planning_artifacts}/*epic*.md`, sharded_index: `{planning_artifacts}/*epic*/index.md`, sharded_single: `{planning_artifacts}/*epic*/epic-{{epic_num}}.md` | SELECTIVE_LOAD |
| previous_retrospective | Previous epic's retrospective (optional) | `{implementation_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md` | SELECTIVE_LOAD |
| architecture | System architecture for context | whole: `{planning_artifacts}/*architecture*.md`, sharded: `{planning_artifacts}/*architecture*/*.md` | FULL_LOAD |
| prd | Product requirements for context | whole: `{planning_artifacts}/*prd*.md`, sharded: `{planning_artifacts}/*prd*/*.md` | FULL_LOAD |
| document_project | Brownfield project documentation (optional) | sharded: `{planning_artifacts}/*.md` | INDEX_GUIDED |
### Required Inputs
- `agent_manifest` = `{project-root}/_bmad/_config/agent-manifest.csv`
### Context
- `project_context` = `**/project-context.md` (load if exists)
---
## EXECUTION
<workflow>
@@ -159,7 +193,7 @@ Bob (Scrum Master): "Perfect. Epic {{epic_number}} is complete and ready for ret
</step>
<step n="0.5" goal="Discover and load project documents">
<invoke-protocol name="discover_inputs" />
<action>Load input files according to the Input Files table in INITIALIZATION. For SELECTIVE_LOAD inputs, load only the epic matching {{epic_number}}. For FULL_LOAD inputs, load the complete document. For INDEX_GUIDED inputs, check the index first and load relevant sections. After discovery, these content variables are available: {epics_content} (selective load for this epic), {architecture_content}, {prd_content}, {document_project_content}</action>
<note>After discovery, these content variables are available: {epics_content} (selective load for this epic), {architecture_content}, {prd_content}, {document_project_content}</note>
</step>
@@ -1336,6 +1370,7 @@ Bob (Scrum Master): "See you all when prep work is done. Meeting adjourned!"
<action>Find development_status key "epic-{{epic_number}}-retrospective"</action>
<action>Verify current status (typically "optional" or "pending")</action>
<action>Update development_status["epic-{{epic_number}}-retrospective"] = "done"</action>
<action>Update last_updated field to current date</action>
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
<check if="update successful">

View File

@@ -0,0 +1,6 @@
---
name: bmad-sprint-planning
description: 'Generate sprint status tracking from epics. Use when the user says "run sprint planning" or "generate sprint plan"'
---
Follow the instructions in ./workflow.md.

View File

@@ -35,6 +35,7 @@
# EXAMPLE STRUCTURE (your actual epics/stories will replace these):
generated: 05-06-2-2025 21:30
last_updated: 05-06-2-2025 21:30
project: My Awesome Project
project_key: NOKEY
tracking_system: file-system

View File

@@ -1,9 +1,49 @@
# Sprint Planning - Sprint Status Generator
# Sprint Planning Workflow
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml</critical>
**Goal:** Generate sprint status tracking from epics, detecting current story statuses and building a complete sprint-status.yaml file.
## 📚 Document Discovery - Full Epic Loading
**Your Role:** You are a Scrum Master generating and maintaining sprint tracking. Parse epic files, detect story statuses, and produce a structured sprint-status.yaml.
---
## INITIALIZATION
### Configuration Loading
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `user_name`
- `communication_language`, `document_output_language`
- `implementation_artifacts`
- `planning_artifacts`
- `date` as system-generated current datetime
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
### Paths
- `tracking_system` = `file-system`
- `project_key` = `NOKEY`
- `story_location` = `{implementation_artifacts}`
- `story_location_absolute` = `{implementation_artifacts}`
- `epics_location` = `{planning_artifacts}`
- `epics_pattern` = `*epic*.md`
- `status_file` = `{implementation_artifacts}/sprint-status.yaml`
### Input Files
| Input | Path | Load Strategy |
|-------|------|---------------|
| Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD |
### Context
- `project_context` = `**/project-context.md` (load if exists)
---
## EXECUTION
### Document Discovery - Full Epic Loading
**Strategy**: Sprint planning needs ALL epics and stories to build complete status tracking.
@@ -44,11 +84,6 @@
<action>Build complete inventory of all epics and stories from all epic files</action>
</step>
<step n="0.5" goal="Discover and load project documents">
<invoke-protocol name="discover_inputs" />
<note>After discovery, these content variables are available: {epics_content} (all epics loaded - uses FULL_LOAD strategy)</note>
</step>
<step n="2" goal="Build sprint status structure">
<action>For each epic found, create entries in this order:</action>
@@ -95,6 +130,7 @@ development_status:
```yaml
# generated: {date}
# last_updated: {date}
# project: {project_name}
# project_key: {project_key}
# tracking_system: {tracking_system}
@@ -130,6 +166,7 @@ development_status:
# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
generated: { date }
last_updated: { date }
project: { project_name }
project_key: { project_key }
tracking_system: { tracking_system }
@@ -168,7 +205,7 @@ development_status:
- **File Location:** {status_file}
- **Total Epics:** {{epic_count}}
- **Total Stories:** {{story_count}}
- **Epics In Progress:** {{epics_in_progress_count}}
- **Epics In Progress:** {{in_progress_count}}
- **Stories Completed:** {{done_count}}
**Next Steps:**

View File

@@ -0,0 +1,6 @@
---
name: bmad-sprint-status
description: 'Summarize sprint status and surface risks. Use when the user says "check sprint status" or "show sprint status"'
---
Follow the instructions in ./workflow.md.

View File

@@ -1,9 +1,40 @@
# Sprint Status - Multi-Mode Service
# Sprint Status Workflow
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmm/workflows/4-implementation/sprint-status/workflow.yaml</critical>
<critical>Modes: interactive (default), validate, data</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES. Do NOT mention hours, days, weeks, or timelines.</critical>
**Goal:** Summarize sprint status, surface risks, and recommend the next workflow action.
**Your Role:** You are a Scrum Master providing clear, actionable sprint visibility. No time estimates — focus on status, risks, and next steps.
---
## INITIALIZATION
### Configuration Loading
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `user_name`
- `communication_language`, `document_output_language`
- `implementation_artifacts`
- `date` as system-generated current datetime
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
### Paths
- `sprint_status_file` = `{implementation_artifacts}/sprint-status.yaml`
### Input Files
| Input | Path | Load Strategy |
|-------|------|---------------|
| Sprint status | `{sprint_status_file}` | FULL_LOAD |
### Context
- `project_context` = `**/project-context.md` (load if exists)
---
## EXECUTION
<workflow>
@@ -36,7 +67,7 @@ Run `/bmad:bmm:workflows:sprint-planning` to generate it, then rerun sprint-stat
<step n="2" goal="Read and parse sprint-status.yaml">
<action>Read the FULL file: {sprint_status_file}</action>
<action>Parse fields: generated, project, project_key, tracking_system, story_location</action>
<action>Parse fields: generated, last_updated, project, project_key, tracking_system, story_location</action>
<action>Parse development_status map. Classify keys:</action>
- Epics: keys starting with "epic-" (and not ending with "-retrospective")
- Retrospectives: keys ending with "-retrospective"
@@ -84,7 +115,7 @@ Enter corrections (e.g., "1=in-progress, 2=backlog") or "skip" to continue witho
- IF any story has status "review": suggest `/bmad:bmm:workflows:code-review`
- IF any story has status "in-progress" AND no stories have status "ready-for-dev": recommend staying focused on active story
- IF all epics have status "backlog" AND no stories have status "ready-for-dev": prompt `/bmad:bmm:workflows:create-story`
- IF `generated` timestamp is more than 7 days old: warn "sprint-status.yaml may be stale"
- IF `last_updated` timestamp is more than 7 days old (or `last_updated` is missing, fall back to `generated`): warn "sprint-status.yaml may be stale"
- IF any story key doesn't match an epic pattern (e.g., story "5-1-..." but no "epic-5"): warn "orphaned story detected"
- IF any epic has status in-progress but has no associated stories: warn "in-progress epic has no stories"
</step>
@@ -195,7 +226,7 @@ If the command targets a story, set `story_key={{next_story_id}}` when prompted.
<action>Read and parse {sprint_status_file}</action>
<action>Validate required metadata fields exist: generated, project, project_key, tracking_system, story_location</action>
<action>Validate required metadata fields exist: generated, project, project_key, tracking_system, story_location (last_updated is optional for backward compatibility)</action>
<check if="any required field missing">
<template-output>is_valid = false</template-output>
<template-output>error = "Missing required field(s): {{missing_fields}}"</template-output>

View File

@@ -1,23 +0,0 @@
# Senior Developer Review - Validation Checklist
- [ ] Story file loaded from `{{story_path}}`
- [ ] Story Status verified as reviewable (review)
- [ ] Epic and Story IDs resolved ({{epic_num}}.{{story_num}})
- [ ] Story Context located or warning recorded
- [ ] Epic Tech Spec located or warning recorded
- [ ] Architecture/standards docs loaded (as available)
- [ ] Tech stack detected and documented
- [ ] MCP doc search performed (or web fallback) and references captured
- [ ] Acceptance Criteria cross-checked against implementation
- [ ] File List reviewed and validated for completeness
- [ ] Tests identified and mapped to ACs; gaps noted
- [ ] Code quality review performed on changed files
- [ ] Security review performed on changed files and dependencies
- [ ] Outcome decided (Approve/Changes Requested/Blocked)
- [ ] Review notes appended under "Senior Developer Review (AI)"
- [ ] Change Log updated with review entry
- [ ] Status updated according to settings (if enabled)
- [ ] Sprint status synced (if sprint tracking enabled)
- [ ] Story saved successfully
_Reviewer: {{user_name}} on {{date}}_

View File

@@ -1,227 +0,0 @@
<workflow>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>🔥 YOU ARE AN ADVERSARIAL CODE REVIEWER - Find what's wrong or missing! 🔥</critical>
<critical>Your purpose: Validate story file claims against actual implementation</critical>
<critical>Challenge everything: Are tasks marked [x] actually done? Are ACs really implemented?</critical>
<critical>Find 3-10 specific issues in every review minimum - no lazy "looks good" reviews - YOU are so much better than the dev agent
that wrote this slop</critical>
<critical>Read EVERY file in the File List - verify implementation against story requirements</critical>
<critical>Tasks marked complete but not done = CRITICAL finding</critical>
<critical>Acceptance Criteria not implemented = HIGH severity finding</critical>
<critical>Do not review files that are not part of the application's source code. Always exclude the _bmad/ and _bmad-output/ folders from the review. Always exclude IDE and CLI configuration folders like .cursor/ and .windsurf/ and .claude/</critical>
<step n="1" goal="Load story and discover changes">
<action>Use provided {{story_path}} or ask user which story file to review</action>
<action>Read COMPLETE story file</action>
<action>Set {{story_key}} = extracted key from filename (e.g., "1-2-user-authentication.md" → "1-2-user-authentication") or story
metadata</action>
<action>Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Agent Record → File List, Change Log</action>
<!-- Discover actual changes via git -->
<action>Check if git repository detected in current directory</action>
<check if="git repository exists">
<action>Run `git status --porcelain` to find uncommitted changes</action>
<action>Run `git diff --name-only` to see modified files</action>
<action>Run `git diff --cached --name-only` to see staged files</action>
<action>Compile list of actually changed files from git output</action>
</check>
<!-- Cross-reference story File List vs git reality -->
<action>Compare story's Dev Agent Record → File List with actual git changes</action>
<action>Note discrepancies:
- Files in git but not in story File List
- Files in story File List but no git changes
- Missing documentation of what was actually changed
</action>
<invoke-protocol name="discover_inputs" />
<action>Load {project_context} for coding standards (if exists)</action>
</step>
<step n="2" goal="Build review attack plan">
<action>Extract ALL Acceptance Criteria from story</action>
<action>Extract ALL Tasks/Subtasks with completion status ([x] vs [ ])</action>
<action>From Dev Agent Record → File List, compile list of claimed changes</action>
<action>Create review plan:
1. **AC Validation**: Verify each AC is actually implemented
2. **Task Audit**: Verify each [x] task is really done
3. **Code Quality**: Security, performance, maintainability
4. **Test Quality**: Real tests vs placeholder bullshit
</action>
</step>
<step n="3" goal="Execute adversarial review">
<critical>VALIDATE EVERY CLAIM - Check git reality vs story claims</critical>
<!-- Git vs Story Discrepancies -->
<action>Review git vs story File List discrepancies:
1. **Files changed but not in story File List** → MEDIUM finding (incomplete documentation)
2. **Story lists files but no git changes** → HIGH finding (false claims)
3. **Uncommitted changes not documented** → MEDIUM finding (transparency issue)
</action>
<!-- Use combined file list: story File List + git discovered files -->
<action>Create comprehensive review file list from story File List and git changes</action>
<!-- AC Validation -->
<action>For EACH Acceptance Criterion:
1. Read the AC requirement
2. Search implementation files for evidence
3. Determine: IMPLEMENTED, PARTIAL, or MISSING
4. If MISSING/PARTIAL → HIGH SEVERITY finding
</action>
<!-- Task Completion Audit -->
<action>For EACH task marked [x]:
1. Read the task description
2. Search files for evidence it was actually done
3. **CRITICAL**: If marked [x] but NOT DONE → CRITICAL finding
4. Record specific proof (file:line)
</action>
<!-- Code Quality Deep Dive -->
<action>For EACH file in comprehensive review list:
1. **Security**: Look for injection risks, missing validation, auth issues
2. **Performance**: N+1 queries, inefficient loops, missing caching
3. **Error Handling**: Missing try/catch, poor error messages
4. **Code Quality**: Complex functions, magic numbers, poor naming
5. **Test Quality**: Are tests real assertions or placeholders?
</action>
<check if="total_issues_found lt 3">
<critical>NOT LOOKING HARD ENOUGH - Find more problems!</critical>
<action>Re-examine code for:
- Edge cases and null handling
- Architecture violations
- Documentation gaps
- Integration issues
- Dependency problems
- Git commit message quality (if applicable)
</action>
<action>Find at least 3 more specific, actionable issues</action>
</check>
</step>
<step n="4" goal="Present findings and fix them">
<action>Categorize findings: HIGH (must fix), MEDIUM (should fix), LOW (nice to fix)</action>
<action>Set {{fixed_count}} = 0</action>
<action>Set {{action_count}} = 0</action>
<output>**🔥 CODE REVIEW FINDINGS, {user_name}!**
**Story:** {{story_file}}
**Git vs Story Discrepancies:** {{git_discrepancy_count}} found
**Issues Found:** {{high_count}} High, {{medium_count}} Medium, {{low_count}} Low
## 🔴 CRITICAL ISSUES
- Tasks marked [x] but not actually implemented
- Acceptance Criteria not implemented
- Story claims files changed but no git evidence
- Security vulnerabilities
## 🟡 MEDIUM ISSUES
- Files changed but not documented in story File List
- Uncommitted changes not tracked
- Performance problems
- Poor test coverage/quality
- Code maintainability issues
## 🟢 LOW ISSUES
- Code style improvements
- Documentation gaps
- Git commit message quality
</output>
<ask>What should I do with these issues?
1. **Fix them automatically** - I'll update the code and tests
2. **Create action items** - Add to story Tasks/Subtasks for later
3. **Show me details** - Deep dive into specific issues
Choose [1], [2], or specify which issue to examine:</ask>
<check if="user chooses 1">
<action>Fix all HIGH and MEDIUM issues in the code</action>
<action>Add/update tests as needed</action>
<action>Update File List in story if files changed</action>
<action>Update story Dev Agent Record with fixes applied</action>
<action>Set {{fixed_count}} = number of HIGH and MEDIUM issues fixed</action>
<action>Set {{action_count}} = 0</action>
</check>
<check if="user chooses 2">
<action>Add "Review Follow-ups (AI)" subsection to Tasks/Subtasks</action>
<action>For each issue: `- [ ] [AI-Review][Severity] Description [file:line]`</action>
<action>Set {{action_count}} = number of action items created</action>
<action>Set {{fixed_count}} = 0</action>
</check>
<check if="user chooses 3">
<action>Show detailed explanation with code examples</action>
<action>Return to fix decision</action>
</check>
</step>
<step n="5" goal="Update story status and sync sprint tracking">
<!-- Determine new status based on review outcome -->
<check if="all HIGH and MEDIUM issues fixed AND all ACs implemented">
<action>Set {{new_status}} = "done"</action>
<action>Update story Status field to "done"</action>
</check>
<check if="HIGH or MEDIUM issues remain OR ACs not fully implemented">
<action>Set {{new_status}} = "in-progress"</action>
<action>Update story Status field to "in-progress"</action>
</check>
<action>Save story file</action>
<!-- Determine sprint tracking status -->
<check if="{sprint_status} file exists">
<action>Set {{current_sprint_status}} = "enabled"</action>
</check>
<check if="{sprint_status} file does NOT exist">
<action>Set {{current_sprint_status}} = "no-sprint-tracking"</action>
</check>
<!-- Sync sprint-status.yaml when story status changes (only if sprint tracking enabled) -->
<check if="{{current_sprint_status}} != 'no-sprint-tracking'">
<action>Load the FULL file: {sprint_status}</action>
<action>Find development_status key matching {{story_key}}</action>
<check if="{{new_status}} == 'done'">
<action>Update development_status[{{story_key}}] = "done"</action>
<action>Save file, preserving ALL comments and structure</action>
<output>✅ Sprint status synced: {{story_key}} → done</output>
</check>
<check if="{{new_status}} == 'in-progress'">
<action>Update development_status[{{story_key}}] = "in-progress"</action>
<action>Save file, preserving ALL comments and structure</action>
<output>🔄 Sprint status synced: {{story_key}} → in-progress</output>
</check>
<check if="story key not found in sprint status">
<output>⚠️ Story file updated, but sprint-status sync failed: {{story_key}} not found in sprint-status.yaml</output>
</check>
</check>
<check if="{{current_sprint_status}} == 'no-sprint-tracking'">
<output> Story status updated (no sprint tracking configured)</output>
</check>
<output>**✅ Review Complete!**
**Story Status:** {{new_status}}
**Issues Fixed:** {{fixed_count}}
**Action Items Created:** {{action_count}}
{{#if new_status == "done"}}Code review complete!{{else}}Address the action items and continue development.{{/if}}
</output>
</step>
</workflow>

View File

@@ -1,43 +0,0 @@
# Review Story Workflow
name: code-review
description: 'Perform adversarial code review finding specific issues. Use when the user says "run code review" or "review this code"'
# Critical variables from config
config_source: "{project-root}/_bmad/bmm/config.yaml"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
user_skill_level: "{config_source}:user_skill_level"
document_output_language: "{config_source}:document_output_language"
date: system-generated
planning_artifacts: "{config_source}:planning_artifacts"
implementation_artifacts: "{config_source}:implementation_artifacts"
sprint_status: "{implementation_artifacts}/sprint-status.yaml"
# Workflow components
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/code-review"
instructions: "{installed_path}/instructions.xml"
validation: "{installed_path}/checklist.md"
template: false
project_context: "**/project-context.md"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
# Strategy: SELECTIVE LOAD - only load the specific epic needed for this story review
input_file_patterns:
architecture:
description: "System architecture for review context"
whole: "{planning_artifacts}/*architecture*.md"
sharded: "{planning_artifacts}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (if UI review)"
whole: "{planning_artifacts}/*ux*.md"
sharded: "{planning_artifacts}/*ux*/*.md"
load_strategy: "FULL_LOAD"
epics:
description: "Epic containing story being reviewed"
whole: "{planning_artifacts}/*epic*.md"
sharded_index: "{planning_artifacts}/*epic*/index.md"
sharded_single: "{planning_artifacts}/*epic*/epic-{{epic_num}}.md"
load_strategy: "SELECTIVE_LOAD"

View File

@@ -1,53 +0,0 @@
# Correct Course - Sprint Change Management Workflow
name: "correct-course"
description: 'Manage significant changes during sprint execution. Use when the user says "correct course" or "propose sprint change"'
config_source: "{project-root}/_bmad/bmm/config.yaml"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
user_skill_level: "{config_source}:user_skill_level"
document_output_language: "{config_source}:document_output_language"
date: system-generated
implementation_artifacts: "{config_source}:implementation_artifacts"
planning_artifacts: "{config_source}:planning_artifacts"
project_knowledge: "{config_source}:project_knowledge"
project_context: "**/project-context.md"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
# Strategy: Load project context for impact analysis
input_file_patterns:
prd:
description: "Product requirements for impact analysis"
whole: "{planning_artifacts}/*prd*.md"
sharded: "{planning_artifacts}/*prd*/*.md"
load_strategy: "FULL_LOAD"
epics:
description: "All epics to analyze change impact"
whole: "{planning_artifacts}/*epic*.md"
sharded: "{planning_artifacts}/*epic*/*.md"
load_strategy: "FULL_LOAD"
architecture:
description: "System architecture and decisions"
whole: "{planning_artifacts}/*architecture*.md"
sharded: "{planning_artifacts}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (if UI impacts)"
whole: "{planning_artifacts}/*ux*.md"
sharded: "{planning_artifacts}/*ux*/*.md"
load_strategy: "FULL_LOAD"
tech_spec:
description: "Technical specification"
whole: "{planning_artifacts}/*tech-spec*.md"
load_strategy: "FULL_LOAD"
document_project:
description: "Brownfield project documentation (optional)"
sharded: "{project_knowledge}/index.md"
load_strategy: "INDEX_GUIDED"
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/correct-course"
template: false
instructions: "{installed_path}/instructions.md"
checklist: "{installed_path}/checklist.md"
default_output_file: "{planning_artifacts}/sprint-change-proposal-{date}.md"

View File

@@ -1,346 +0,0 @@
<workflow>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language} and generate all documents in {document_output_language}</critical>
<critical>🔥 CRITICAL MISSION: You are creating the ULTIMATE story context engine that prevents LLM developer mistakes, omissions or
disasters! 🔥</critical>
<critical>Your purpose is NOT to copy from epics - it's to create a comprehensive, optimized story file that gives the DEV agent
EVERYTHING needed for flawless implementation</critical>
<critical>COMMON LLM MISTAKES TO PREVENT: reinventing wheels, wrong libraries, wrong file locations, breaking regressions, ignoring UX,
vague implementations, lying about completion, not learning from past work</critical>
<critical>🚨 EXHAUSTIVE ANALYSIS REQUIRED: You must thoroughly analyze ALL artifacts to extract critical context - do NOT be lazy or skim!
This is the most important function in the entire development process!</critical>
<critical>🔬 UTILIZE SUBPROCESSES AND SUBAGENTS: Use research subagents, subprocesses or parallel processing if available to thoroughly
analyze different artifacts simultaneously and thoroughly</critical>
<critical>❓ SAVE QUESTIONS: If you think of questions or clarifications during analysis, save them for the end after the complete story is
written</critical>
<critical>🎯 ZERO USER INTERVENTION: Process should be fully automated except for initial epic/story selection or missing documents</critical>
<step n="1" goal="Determine target story">
<check if="{{story_path}} is provided by user or user provided the epic and story number such as 2-4 or 1.6 or epic 1 story 5">
<action>Parse user-provided story path: extract epic_num, story_num, story_title from format like "1-2-user-auth"</action>
<action>Set {{epic_num}}, {{story_num}}, {{story_key}} from user input</action>
<action>GOTO step 2a</action>
</check>
<action>Check if {{sprint_status}} file exists for auto discover</action>
<check if="sprint status file does NOT exist">
<output>🚫 No sprint status file found and no story specified</output>
<output>
**Required Options:**
1. Run `sprint-planning` to initialize sprint tracking (recommended)
2. Provide specific epic-story number to create (e.g., "1-2-user-auth")
3. Provide path to story documents if sprint status doesn't exist yet
</output>
<ask>Choose option [1], provide epic-story number, path to story docs, or [q] to quit:</ask>
<check if="user chooses 'q'">
<action>HALT - No work needed</action>
</check>
<check if="user chooses '1'">
<output>Run sprint-planning workflow first to create sprint-status.yaml</output>
<action>HALT - User needs to run sprint-planning</action>
</check>
<check if="user provides epic-story number">
<action>Parse user input: extract epic_num, story_num, story_title</action>
<action>Set {{epic_num}}, {{story_num}}, {{story_key}} from user input</action>
<action>GOTO step 2a</action>
</check>
<check if="user provides story docs path">
<action>Use user-provided path for story documents</action>
<action>GOTO step 2a</action>
</check>
</check>
<!-- Auto-discover from sprint status only if no user input -->
<check if="no user input provided">
<critical>MUST read COMPLETE {sprint_status} file from start to end to preserve order</critical>
<action>Load the FULL file: {{sprint_status}}</action>
<action>Read ALL lines from beginning to end - do not skip any content</action>
<action>Parse the development_status section completely</action>
<action>Find the FIRST story (by reading in order from top to bottom) where:
- Key matches pattern: number-number-name (e.g., "1-2-user-auth")
- NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
- Status value equals "backlog"
</action>
<check if="no backlog story found">
<output>📋 No backlog stories found in sprint-status.yaml
All stories are either already created, in progress, or done.
**Options:**
1. Run sprint-planning to refresh story tracking
2. Load PM agent and run correct-course to add more stories
3. Check if current sprint is complete and run retrospective
</output>
<action>HALT</action>
</check>
<action>Extract from found story key (e.g., "1-2-user-authentication"):
- epic_num: first number before dash (e.g., "1")
- story_num: second number after first dash (e.g., "2")
- story_title: remainder after second dash (e.g., "user-authentication")
</action>
<action>Set {{story_id}} = "{{epic_num}}.{{story_num}}"</action>
<action>Store story_key for later use (e.g., "1-2-user-authentication")</action>
<!-- Mark epic as in-progress if this is first story -->
<action>Check if this is the first story in epic {{epic_num}} by looking for {{epic_num}}-1-* pattern</action>
<check if="this is first story in epic {{epic_num}}">
<action>Load {{sprint_status}} and check epic-{{epic_num}} status</action>
<action>If epic status is "backlog" → update to "in-progress"</action>
<action>If epic status is "contexted" (legacy status) → update to "in-progress" (backward compatibility)</action>
<action>If epic status is "in-progress" → no change needed</action>
<check if="epic status is 'done'">
<output>🚫 ERROR: Cannot create story in completed epic</output>
<output>Epic {{epic_num}} is marked as 'done'. All stories are complete.</output>
<output>If you need to add more work, either:</output>
<output>1. Manually change epic status back to 'in-progress' in sprint-status.yaml</output>
<output>2. Create a new epic for additional work</output>
<action>HALT - Cannot proceed</action>
</check>
<check if="epic status is not one of: backlog, contexted, in-progress, done">
<output>🚫 ERROR: Invalid epic status '{{epic_status}}'</output>
<output>Epic {{epic_num}} has invalid status. Expected: backlog, in-progress, or done</output>
<output>Please fix sprint-status.yaml manually or run sprint-planning to regenerate</output>
<action>HALT - Cannot proceed</action>
</check>
<output>📊 Epic {{epic_num}} status updated to in-progress</output>
</check>
<action>GOTO step 2a</action>
</check>
<action>Load the FULL file: {{sprint_status}}</action>
<action>Read ALL lines from beginning to end - do not skip any content</action>
<action>Parse the development_status section completely</action>
<action>Find the FIRST story (by reading in order from top to bottom) where:
- Key matches pattern: number-number-name (e.g., "1-2-user-auth")
- NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
- Status value equals "backlog"
</action>
<check if="no backlog story found">
<output>📋 No backlog stories found in sprint-status.yaml
All stories are either already created, in progress, or done.
**Options:**
1. Run sprint-planning to refresh story tracking
2. Load PM agent and run correct-course to add more stories
3. Check if current sprint is complete and run retrospective
</output>
<action>HALT</action>
</check>
<action>Extract from found story key (e.g., "1-2-user-authentication"):
- epic_num: first number before dash (e.g., "1")
- story_num: second number after first dash (e.g., "2")
- story_title: remainder after second dash (e.g., "user-authentication")
</action>
<action>Set {{story_id}} = "{{epic_num}}.{{story_num}}"</action>
<action>Store story_key for later use (e.g., "1-2-user-authentication")</action>
<!-- Mark epic as in-progress if this is first story -->
<action>Check if this is the first story in epic {{epic_num}} by looking for {{epic_num}}-1-* pattern</action>
<check if="this is first story in epic {{epic_num}}">
<action>Load {{sprint_status}} and check epic-{{epic_num}} status</action>
<action>If epic status is "backlog" → update to "in-progress"</action>
<action>If epic status is "contexted" (legacy status) → update to "in-progress" (backward compatibility)</action>
<action>If epic status is "in-progress" → no change needed</action>
<check if="epic status is 'done'">
<output>🚫 ERROR: Cannot create story in completed epic</output>
<output>Epic {{epic_num}} is marked as 'done'. All stories are complete.</output>
<output>If you need to add more work, either:</output>
<output>1. Manually change epic status back to 'in-progress' in sprint-status.yaml</output>
<output>2. Create a new epic for additional work</output>
<action>HALT - Cannot proceed</action>
</check>
<check if="epic status is not one of: backlog, contexted, in-progress, done">
<output>🚫 ERROR: Invalid epic status '{{epic_status}}'</output>
<output>Epic {{epic_num}} has invalid status. Expected: backlog, in-progress, or done</output>
<output>Please fix sprint-status.yaml manually or run sprint-planning to regenerate</output>
<action>HALT - Cannot proceed</action>
</check>
<output>📊 Epic {{epic_num}} status updated to in-progress</output>
</check>
<action>GOTO step 2a</action>
</step>
<step n="2" goal="Load and analyze core artifacts">
<critical>🔬 EXHAUSTIVE ARTIFACT ANALYSIS - This is where you prevent future developer fuckups!</critical>
<!-- Load all available content through discovery protocol -->
<invoke-protocol
name="discover_inputs" />
<note>Available content: {epics_content}, {prd_content}, {architecture_content}, {ux_content},
{project_context}</note>
<!-- Analyze epics file for story foundation -->
<action>From {epics_content}, extract Epic {{epic_num}} complete context:</action> **EPIC ANALYSIS:** - Epic
objectives and business value - ALL stories in this epic for cross-story context - Our specific story's requirements, user story
statement, acceptance criteria - Technical requirements and constraints - Dependencies on other stories/epics - Source hints pointing to
original documents <!-- Extract specific story requirements -->
<action>Extract our story ({{epic_num}}-{{story_num}}) details:</action> **STORY FOUNDATION:** - User story statement
(As a, I want, so that) - Detailed acceptance criteria (already BDD formatted) - Technical requirements specific to this story -
Business context and value - Success criteria <!-- Previous story analysis for context continuity -->
<check if="story_num > 1">
<action>Find {{previous_story_num}}: scan {implementation_artifacts} for the story file in epic {{epic_num}} with the highest story number less than {{story_num}}</action>
<action>Load previous story file: {implementation_artifacts}/{{epic_num}}-{{previous_story_num}}-*.md</action> **PREVIOUS STORY INTELLIGENCE:** -
Dev notes and learnings from previous story - Review feedback and corrections needed - Files that were created/modified and their
patterns - Testing approaches that worked/didn't work - Problems encountered and solutions found - Code patterns established <action>Extract
all learnings that could impact current story implementation</action>
</check>
<!-- Git intelligence for previous work patterns -->
<check
if="previous story exists AND git repository detected">
<action>Get last 5 commit titles to understand recent work patterns</action>
<action>Analyze 1-5 most recent commits for relevance to current story:
- Files created/modified
- Code patterns and conventions used
- Library dependencies added/changed
- Architecture decisions implemented
- Testing approaches used
</action>
<action>Extract actionable insights for current story implementation</action>
</check>
</step>
<step n="3" goal="Architecture analysis for developer guardrails">
<critical>🏗️ ARCHITECTURE INTELLIGENCE - Extract everything the developer MUST follow!</critical> **ARCHITECTURE DOCUMENT ANALYSIS:** <action>Systematically
analyze architecture content for story-relevant requirements:</action>
<!-- Load architecture - single file or sharded -->
<check if="architecture file is single file">
<action>Load complete {architecture_content}</action>
</check>
<check if="architecture is sharded to folder">
<action>Load architecture index and scan all architecture files</action>
</check> **CRITICAL ARCHITECTURE EXTRACTION:** <action>For
each architecture section, determine if relevant to this story:</action> - **Technical Stack:** Languages, frameworks, libraries with
versions - **Code Structure:** Folder organization, naming conventions, file patterns - **API Patterns:** Service structure, endpoint
patterns, data contracts - **Database Schemas:** Tables, relationships, constraints relevant to story - **Security Requirements:**
Authentication patterns, authorization rules - **Performance Requirements:** Caching strategies, optimization patterns - **Testing
Standards:** Testing frameworks, coverage expectations, test patterns - **Deployment Patterns:** Environment configurations, build
processes - **Integration Patterns:** External service integrations, data flows <action>Extract any story-specific requirements that the
developer MUST follow</action>
<action>Identify any architectural decisions that override previous patterns</action>
</step>
<step n="4" goal="Web research for latest technical specifics">
<critical>🌐 ENSURE LATEST TECH KNOWLEDGE - Prevent outdated implementations!</critical> **WEB INTELLIGENCE:** <action>Identify specific
technical areas that require latest version knowledge:</action>
<!-- Check for libraries/frameworks mentioned in architecture -->
<action>From architecture analysis, identify specific libraries, APIs, or
frameworks</action>
<action>For each critical technology, research latest stable version and key changes:
- Latest API documentation and breaking changes
- Security vulnerabilities or updates
- Performance improvements or deprecations
- Best practices for current version
</action>
**EXTERNAL CONTEXT INCLUSION:** <action>Include in story any critical latest information the developer needs:
- Specific library versions and why chosen
- API endpoints with parameters and authentication
- Recent security patches or considerations
- Performance optimization techniques
- Migration considerations if upgrading
</action>
</step>
<step n="5" goal="Create comprehensive story file">
<critical>📝 CREATE ULTIMATE STORY FILE - The developer's master implementation guide!</critical>
<action>Initialize from template.md:
{default_output_file}</action>
<template-output file="{default_output_file}">story_header</template-output>
<!-- Story foundation from epics analysis -->
<template-output
file="{default_output_file}">story_requirements</template-output>
<!-- Developer context section - MOST IMPORTANT PART -->
<template-output file="{default_output_file}">
developer_context_section</template-output> **DEV AGENT GUARDRAILS:** <template-output file="{default_output_file}">
technical_requirements</template-output>
<template-output file="{default_output_file}">architecture_compliance</template-output>
<template-output
file="{default_output_file}">library_framework_requirements</template-output>
<template-output file="{default_output_file}">
file_structure_requirements</template-output>
<template-output file="{default_output_file}">testing_requirements</template-output>
<!-- Previous story intelligence -->
<check
if="previous story learnings available">
<template-output file="{default_output_file}">previous_story_intelligence</template-output>
</check>
<!-- Git intelligence -->
<check
if="git analysis completed">
<template-output file="{default_output_file}">git_intelligence_summary</template-output>
</check>
<!-- Latest technical specifics -->
<check if="web research completed">
<template-output file="{default_output_file}">latest_tech_information</template-output>
</check>
<!-- Project context reference -->
<template-output
file="{default_output_file}">project_context_reference</template-output>
<!-- Final status update -->
<template-output file="{default_output_file}">
story_completion_status</template-output>
<!-- CRITICAL: Set status to ready-for-dev -->
<action>Set story Status to: "ready-for-dev"</action>
<action>Add completion note: "Ultimate
context engine analysis completed - comprehensive developer guide created"</action>
</step>
<step n="6" goal="Update sprint status and finalize">
<invoke-task>Validate against checklist at {installed_path}/checklist.md using _bmad/core/tasks/validate-workflow.xml</invoke-task>
<action>Save story document unconditionally</action>
<!-- Update sprint status -->
<check if="sprint status file exists">
<action>Update {{sprint_status}}</action>
<action>Load the FULL file and read all development_status entries</action>
<action>Find development_status key matching {{story_key}}</action>
<action>Verify current status is "backlog" (expected previous state)</action>
<action>Update development_status[{{story_key}}] = "ready-for-dev"</action>
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
</check>
<action>Report completion</action>
<output>**🎯 ULTIMATE BMad Method STORY CONTEXT CREATED, {user_name}!**
**Story Details:**
- Story ID: {{story_id}}
- Story Key: {{story_key}}
- File: {{story_file}}
- Status: ready-for-dev
**Next Steps:**
1. Review the comprehensive story in {{story_file}}
2. Run dev agents `dev-story` for optimized implementation
3. Run `code-review` when complete (auto-marks done)
4. Optional: If Test Architect module installed, run `/bmad:tea:automate` after `dev-story` to generate guardrail tests
**The developer now has everything needed for flawless implementation!**
</output>
</step>
</workflow>

View File

@@ -1,52 +0,0 @@
name: create-story
description: 'Creates a dedicated story file with all the context the agent will need to implement it later. Use when the user says "create the next story" or "create story [story identifier]"'
# Critical variables from config
config_source: "{project-root}/_bmad/bmm/config.yaml"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level"
date: system-generated
planning_artifacts: "{config_source}:planning_artifacts"
implementation_artifacts: "{config_source}:implementation_artifacts"
# Workflow components
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story"
template: "{installed_path}/template.md"
instructions: "{installed_path}/instructions.xml"
validation: "{installed_path}/checklist.md"
# Variables and inputs
sprint_status: "{implementation_artifacts}/sprint-status.yaml" # Primary source for story tracking
epics_file: "{planning_artifacts}/epics.md" # Enhanced epics+stories with BDD and source hints
prd_file: "{planning_artifacts}/prd.md" # Fallback for requirements (if not in epics file)
architecture_file: "{planning_artifacts}/architecture.md" # Fallback for constraints (if not in epics file)
ux_file: "{planning_artifacts}/*ux*.md" # Fallback for UX requirements (if not in epics file)
story_title: "" # Will be elicited if not derivable
project_context: "**/project-context.md"
default_output_file: "{implementation_artifacts}/{{story_key}}.md"
# Smart input file references - Simplified for enhanced approach
# The epics+stories file should contain everything needed with source hints
input_file_patterns:
prd:
description: "PRD (fallback - epics file should have most content)"
whole: "{planning_artifacts}/*prd*.md"
sharded: "{planning_artifacts}/*prd*/*.md"
load_strategy: "SELECTIVE_LOAD" # Only load if needed
architecture:
description: "Architecture (fallback - epics file should have relevant sections)"
whole: "{planning_artifacts}/*architecture*.md"
sharded: "{planning_artifacts}/*architecture*/*.md"
load_strategy: "SELECTIVE_LOAD" # Only load if needed
ux:
description: "UX design (fallback - epics file should have relevant sections)"
whole: "{planning_artifacts}/*ux*.md"
sharded: "{planning_artifacts}/*ux*/*.md"
load_strategy: "SELECTIVE_LOAD" # Only load if needed
epics:
description: "Enhanced epics+stories file with BDD and source hints"
whole: "{planning_artifacts}/*epic*.md"
sharded: "{planning_artifacts}/*epic*/*.md"
load_strategy: "SELECTIVE_LOAD" # Only load needed epic

View File

@@ -1,20 +0,0 @@
name: dev-story
description: 'Execute story implementation following a context filled story spec file. Use when the user says "dev this story [story file]" or "implement the next story in the sprint plan"'
# Critical variables from config
config_source: "{project-root}/_bmad/bmm/config.yaml"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
user_skill_level: "{config_source}:user_skill_level"
document_output_language: "{config_source}:document_output_language"
date: system-generated
# Workflow components
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/dev-story"
instructions: "{installed_path}/instructions.xml"
validation: "{installed_path}/checklist.md"
story_file: "" # Explicit story path; auto-discovered if empty
implementation_artifacts: "{config_source}:implementation_artifacts"
sprint_status: "{implementation_artifacts}/sprint-status.yaml"
project_context: "**/project-context.md"

View File

@@ -1,52 +0,0 @@
# Retrospective - Epic Completion Review Workflow
name: "retrospective"
description: 'Post-epic review to extract lessons and assess success. Use when the user says "run a retrospective" or "lets retro the epic [epic]"'
config_source: "{project-root}/_bmad/bmm/config.yaml"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
user_skill_level: "{config_source}:user_skill_level"
document_output_language: "{config_source}:document_output_language"
date: system-generated
planning_artifacts: "{config_source}:planning_artifacts"
implementation_artifacts: "{config_source}:implementation_artifacts"
project_context: "**/project-context.md"
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/retrospective"
template: false
instructions: "{installed_path}/instructions.md"
required_inputs:
- agent_manifest: "{project-root}/_bmad/_config/agent-manifest.csv"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
# Strategy: SELECTIVE LOAD - only load the completed epic and relevant retrospectives
input_file_patterns:
epics:
description: "The completed epic for retrospective"
whole: "{planning_artifacts}/*epic*.md"
sharded_index: "{planning_artifacts}/*epic*/index.md"
sharded_single: "{planning_artifacts}/*epic*/epic-{{epic_num}}.md"
load_strategy: "SELECTIVE_LOAD"
previous_retrospective:
description: "Previous epic's retrospective (optional)"
pattern: "{implementation_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md"
load_strategy: "SELECTIVE_LOAD"
architecture:
description: "System architecture for context"
whole: "{planning_artifacts}/*architecture*.md"
sharded: "{planning_artifacts}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
prd:
description: "Product requirements for context"
whole: "{planning_artifacts}/*prd*.md"
sharded: "{planning_artifacts}/*prd*/*.md"
load_strategy: "FULL_LOAD"
document_project:
description: "Brownfield project documentation (optional)"
sharded: "{planning_artifacts}/*.md"
load_strategy: "INDEX_GUIDED"
# Required files
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml"

View File

@@ -1,47 +0,0 @@
name: sprint-planning
description: 'Generate sprint status tracking from epics. Use when the user says "run sprint planning" or "generate sprint plan"'
author: "BMad"
# Critical variables from config
config_source: "{project-root}/_bmad/bmm/config.yaml"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
date: system-generated
implementation_artifacts: "{config_source}:implementation_artifacts"
planning_artifacts: "{config_source}:planning_artifacts"
# Workflow components
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning"
instructions: "{installed_path}/instructions.md"
template: "{installed_path}/sprint-status-template.yaml"
validation: "{installed_path}/checklist.md"
# Variables and inputs
project_context: "**/project-context.md"
project_name: "{config_source}:project_name"
# Tracking system configuration
tracking_system: "file-system" # Options: file-system, Future will support other options from config of mcp such as jira, linear, trello
project_key: "NOKEY" # Placeholder for tracker integrations; file-system uses a no-op key
story_location: "{implementation_artifacts}" # Relative path for file-system, Future will support URL for Jira/Linear/Trello
story_location_absolute: "{implementation_artifacts}" # Absolute path for file operations
# Source files (file-system only)
epics_location: "{planning_artifacts}" # Directory containing epic*.md files
epics_pattern: "epic*.md" # Pattern to find epic files
# Output configuration
status_file: "{implementation_artifacts}/sprint-status.yaml"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
# Strategy: FULL LOAD - sprint planning needs ALL epics to build complete status
input_file_patterns:
epics:
description: "All epics with user stories"
whole: "{planning_artifacts}/*epic*.md"
sharded: "{planning_artifacts}/*epic*/*.md"
load_strategy: "FULL_LOAD"
# Output configuration
default_output_file: "{status_file}"

View File

@@ -1,25 +0,0 @@
# Sprint Status - Implementation Tracker
name: sprint-status
description: 'Summarize sprint status and surface risks. Use when the user says "check sprint status" or "show sprint status"'
author: "BMad"
# Critical variables from config
config_source: "{project-root}/_bmad/bmm/config.yaml"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
implementation_artifacts: "{config_source}:implementation_artifacts"
# Workflow components
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-status"
instructions: "{installed_path}/instructions.md"
# Inputs
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml"
# Smart input file references
input_file_patterns:
sprint_status:
description: "Sprint status file generated by sprint-planning"
whole: "{implementation_artifacts}/sprint-status.yaml"
load_strategy: "FULL_LOAD"