/bmad-correct-course

name: bmad-correct-course
description: |
  CROSS-PHASE mid-stream scope correction. Re-enters planning when requirements,
  features, architecture, or constraints change after planning has started. Re-shards
  affected epics/stories, re-sequences sprint-status.yaml, appends rationale to
  decision-log.md. Routes to bmad-epics-and-stories, bmad-sprint-planning, or
  bmad-parallel-plan as needed. Changes the PLAN, never code.

  Use when: "we need to change course", "scope has changed", "new requirement came in",
  "we're dropping feature X", "we need to pivot", "re-plan after the change",
  "requirements changed mid-sprint", "correct course", "architecture changed",
  "re-scope the backlog", "update epics after feedback", "cancel story X",
  "add epic for Y", "change the plan", "we got new constraints", or when stories
  are split/merged/reordered due to a decision not in the original plan.

  Produces: updated epics.md (affected only), revised/new story files, updated
  sprint-status.yaml, new decision-log.md entry. NEVER writes code or runs tests.
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, TodoWrite

BMAD Correct Course

**Role:** Cross-phase re-entry point for mid-stream planning changes.

When reality diverges from the plan — a stakeholder pivots, a constraint surfaces, a feature is cut — this skill re-enters the planning phase, makes the minimum-necessary plan changes, and routes forward to the appropriate downstream skill. It changes **the plan**, never the code.

**Persona flavor:** Mary (Analyst) surfaces the impact; John (PM) scopes the delta; Winston (Architect) re-shards affected epics. Lightweight flavor only — this is a workflow.

---

Scope Law (read first)

This skill PLANS. It NEVER writes application code, runs tests, lints, checks coverage, builds, or reviews diffs. If tempted to "fix the code" or "run the suite" — STOP. Plan the change and hand it off.

The latest artifact this skill may produce is a story file marked `ready-for-dev`, an updated `sprint-status.yaml`, or a routing directive to a downstream planning skill.

---

When to Use This Skill

Trigger when ANY of the following is true:

• A requirement, feature, or constraint has changed **after** any planning

artifact (PRD, architecture, epics.md, or stories) was produced.

• Stories need to be added, dropped, split, merged, or re-scoped for reasons

not captured in the existing plan.

• The architecture changed in a way that invalidates Owned File/Module Scope

declarations in existing stories.

• The user wants to document a mid-stream decision in `decision-log.md`

before proceeding.

---

Inputs (load these first)

| File | Why | |------|-----| | `bmad-output/project-context.md` | Project constitution — load every run | | `bmad-output/decision-log.md` | Threaded decisions; append here | | `bmad-output/epics.md` | Existing epic map to diff against | | `bmad-output/prd.md` | Source of truth for requirements | | `bmad-output/architecture.md` | Tech boundaries (if architecture changed) | | `bmad-output/sprint-status.yaml` | Current sequencing state | | `bmad-output/stories/*.story.md` | In-flight and backlog stories |

Output folder default: `bmad-output/`. Honor any user-configured override from `bmad-output/config.yaml`.

---

Three Intents

| Intent | When to use | |--------|-------------| | **Scope Change** | A feature is added, dropped, or reshaped — re-shard affected epics and re-sequence. | | **Architecture Change** | Module boundaries, stack, or integrations shift — update Owned Scope declarations in impacted stories. | | **Record Only** | The change is already reflected in planning artifacts; write the decision-log entry and confirm consistency. |

State the intent explicitly before proceeding. When unclear, ask the user which scenario applies rather than assuming.

---

Workflow

Use `TodoWrite` to track progress through these steps.

Step 1 — Load and orient

1. Read all inputs listed above. 2. Identify the **change statement**: what is new, what is removed, what is altered, and why (ask the user if unclear). 3. State back to the user what you understood before making any edits.

Step 2 — Impact triage

Identify the minimum blast radius:

• Which **epics** are affected? (added / dropped / reshaped)
• Which **stories** are affected? (added / dropped / re-scoped /

invalidated Owned Scope)

• Which **story statuses** must change? (`in-progress` stories touched by

the change need special care — flag them; do not silently move them.)

• Does `sprint-status.yaml` need re-sequencing?

Present the triage to the user and confirm before editing.

Step 3 — Update planning artifacts

Apply only the minimum-necessary changes.

3a. Update epics.md (affected epics only)

• Add new epics with a `# COURSE-CORRECTION` annotation and the date.
• Mark dropped epics as `status: cancelled` — do not delete; preserve history.
• Update epic descriptions, scope boundaries, and the ordered story list.
• Do **not** re-generate untouched epics.

3b. Re-shard affected stories (route to bmad-epics-and-stories)

For any epic that changed scope, invoke the story-sharding workflow:

> **Route to `bmad-epics-and-stories` (intent: Update or Create)** > Provide the updated epic definition and a list of story IDs to add, > drop, or revise. The sharding skill owns the story context-object > contract; do not reproduce it here.

• Stories being dropped: set `status: cancelled` in the story file header

and in `sprint-status.yaml`. Do not delete files.

• Stories being added: they start at `status: backlog`.
• Stories being re-scoped: mark the change and re-validate LOCKED sections.

A LOCKED section (Acceptance Criteria, Dev Notes, Testing) may only change with explicit user confirmation; record the change in `decision-log.md`.

3c. Re-sequence sprint-status.yaml (route to bmad-sprint-planning)

After all story changes are settled, route to `bmad-sprint-planning` to r