bmad-correct-course

Assess the impact of a significant change during sprint execution across the PRD, epics, architecture, and UX documents, and produce a sprint change proposal. Use when the user says "correct course" or "propose sprint change"

By bmad-code-org · 1,390 installs

npx skills add bmad-code-org/bmad-method --skill bmad-correct-course

Source repository · Upstream listing

Correct Course Sprint Change Management Workflow Goal: Manage significant changes during sprint execution by analyzing impact across all project artifacts and producing a structured Sprint Change Proposal. Your Role: You are a Developer 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. Conventions Bare paths (e.g. checklist.md ) resolve from the skill root. {skill root} resolves to this skill's installed directory (where customize.toml lives). {project root} prefixed paths resolve from the project working directory. {skill name} resolves to the skill directory's basename. On Activation Step 1: Resolve the Workflow Block Run: uv run {project root}/ bmad/scripts/resolve customization.py skill {skill root} project root {project root} key workflow If the script fails , resolve the workflow block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver: 1. {skill root}/customize.toml — defaults 2. {project root}/ bmad/custom/{skill name}.toml — team overrides 3. {project root}/ bmad/custom/{skill name}.user.toml — personal overrides Any missing file is skipped. Scalars override, tables deep merge, arrays of tables keyed by code or id replace matching entries and append new entries, and all other arrays append. Step 2: Execute Prepend Steps Execute each entry in {workflow.activation steps prepend} in order before proceeding. Step 3: Load Persistent Facts Treat every entry in {workflow.persistent facts} as foundational context you carry for the rest of the workflow run. Entries prefixed file: are paths or globs under {project root} — load the referenced contents as facts. All other entries are facts verbatim. Step 4: Load Config Run: uv run {project root}/ bmad/scripts/resolve config.py project root {project root} key core.project name key modules.bmm.implementation artifacts key modules.bmm.planning artifacts key modules.bmm.project knowledge date as system generated current datetime YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style DOCUMENT OUTPUT: Updated epics, stories, or PRD sections. Clear, actionable changes. Step 5: Greet the User Greet the user. Step 6: Execute Append Steps Execute each entry in {workflow.activation steps append} in order. Activation is complete. If activation steps prepend or activation steps append were non empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed. 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 Spec {planning artifacts}/ spec .md (whole) FULL LOAD Project Context AGENTS.md in the affected repo (the bmad:context block) FULL LOAD 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, 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 , 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 Project Context: 1. Read AGENTS.md in the repo the change affects — the block between the bmad:context markers carries the policy, frozen paths, and conventions a course correction must respect. 2. Follow only the pointers that relate to the impacted areas — nested component files or linked rule files listed under "Where things are". Do not load them all. 3. This document is optional — skip if the repo has no AGENTS.md (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, 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 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 project documents:</action PRD (Product Requirements Document) — required Current Epics and Stories — required Architecture documentation — optional, load if available UI/UX specifications — optional, load if available <action Ask user for mode preference:</action Incremental (recommended): Refine each edit collaboratively Batch : Present all changes at once for review <action Store mode selection for use throughout workflow</action <action if="change trigger is unclear" HALT: "Cannot navigate change without clear understanding of the triggering issue. Please provide specific details about what needs to change and why."</action <action if="PRD or Epics are unavailable" HALT: "Need access to PRD and Epics to assess change impact. Please ensure these documents are accessible. Architecture and UI/UX will be used if available."</action </step <step n="2" goal="Execute Change Analysis Checklist" <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 [N/A] Skip Item not applicable to this change [!] Action needed Item requires attention or follow up <action Maintain running notes of findings and impacts discovered</action <action Present checklist progress after each major section</action <action if="checklist cannot be completed" Identify blocking issues and work with user to resolve before continuing</action </step <step n="3" goal="Draft Specific Change Proposals" <action Based on checklist findings, create explicit edit proposals for each identified artifact</action <action For Story changes:</action Show old → new text format Include story ID and section being modified Provide rationale for each change Example format: <action For PRD modifications:</action Specify exact sections to update Show current content and proposed changes Explain impact on MVP scope and requirements <action For Architecture changes:</action Identify affected components, patterns, or technology choices Describe diagram updates needed Note any ripple effects on other components <action For UI/UX specification updates:</action Reference specific screens or components Show wireframe or flow changes needed Connect changes to user experience impact <check if="mode is Incremental" <action Present each edit proposal individually</action <action HALT and give the user a choice: Approve — accept this proposal Edit — refine this proposal Skip — drop this proposal </action <action If the user chooses Approve , keep the proposal. If they choose Edit , refine it with them. If they choose Skip , drop it. Continue to the next proposal.</action </check <action if="mode is Batch" Collect all edit proposals and present together at end of step</action </step <step n="4" goal="Generate Sprint Change Proposal" <action Compile comprehensive Sprint Change Proposal document with following sections:</action <action Section 1: Issue Summary</action Clear problem statement describing what triggered the change Context about when/how the issue was discovered Evidence or examples demonstrating the issue <action Section 2: Impact Analysis</action Epic Impact: Which epics are affected and how Story Impact: Current and future stories requiring changes Artifact Conflicts: PRD, Architecture, UI/UX documents needing updates Technical Impact: Code, infrastructure, or deployment implications <action Section 3: Recommended Approach</action Present chosen path forward from checklist evaluation: Direct Adjustment: Modify/add stories within existing plan Potential Rollback: Revert completed work to simplify resolution MVP Review: Reduce scope or modify goals Provide clear rationale for recommendation Include effort estimate, risk assessment, and timeline impact <action Section 4: Detailed Change Proposals</action Include all refined edit proposals from Step 3 Group by artifact type (Stories, PRD, Architecture, UI/UX) Ensure each change includes before/after and justification <action Section 5: Implementation Handoff</action Categorize change scope: Minor: Direct implementation by Developer agent Moderate: Backlog reorganization needed (PO/DEV) Major: Fundamental replan required (PM/Architect) Specify handoff recipients and their responsibilities Define success criteria for implementation <action Present complete Sprint Change Proposal to user</action <action Write Sprint Change Proposal document to {default output file}</action <action HALT and give the user a choice: Continue — proceed to approval Edit — revise the proposal first </action <action If the user chooses Edit , revise the proposal with them and write the updated document before continuing.</action </step <step n="5" goal="Finalize and Route for Implementation" <action Get explicit user approval for complete proposal</action <ask Do you approve this Sprint Change Proposal for implementation? (yes/no/revise)</ask <check if="no or revise" <action Gather specific feedback on what needs adjustment</action <action Return to appropriate step to address concerns</action <goto step="3" If changes needed to edit proposals</goto <goto step="4" If changes needed to overall proposal structure</goto </check <check if="yes the proposal is approved by the user" <action Finalize Sprint Change Proposal document</action <action Determine change scope classification:</action Minor : Can be implemented directly by Developer agent Moderate : Requires backlog reorganization and PO/DEV coordination Major : Needs fundamental replan with PM/Architect involvement <action Provide appropriate handoff based on scope:</action </check <check if="Minor scope" <action Route to: Developer agent for direct implementation</action <action Deliverables: Finalized edit proposals and implementation tasks</action </check <check if="Moderate scope" <action Route to: Product Owner / Developer agents</action <action Deliverables: Sprint Change Proposal + backlog reorganization plan</action </check <check if="Major scope" <action Route to: Product Manager / Solution Architect</action <action Deliverables: Complete Sprint Chang