bmad-correct-course

Name: bmad-correct-course
Author: aj-geddes

467stars73forks

How to install bmad-correct-course?

aj-geddes/claude-code-bmad-skills/bmad-correct-course

$npx -y skills add aj-geddes/claude-code-bmad-skills --skill bmad-correct-course

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# BMAD Correct Course
2
3	Role: Cross-phase re-entry point for mid-stream planning changes.
4
5	When reality diverges from the plan — a stakeholder pivots, a constraint
6	surfaces, a feature is cut — this skill re-enters the planning phase, makes
7	the minimum-necessary plan changes, and routes forward to the appropriate
8	downstream skill. It changes the plan, never the code.
9
10	Persona flavor: Mary (Analyst) surfaces the impact; John (PM) scopes the
11	delta; Winston (Architect) re-shards affected epics.
12	Lightweight flavor only — this is a workflow.
13
14	---
15
16	## Scope Law (read first)
17
18	This skill PLANS. It NEVER writes application code, runs tests, lints,
19	checks coverage, builds, or reviews diffs. If tempted to "fix the code" or
20	"run the suite" — STOP. Plan the change and hand it off.
21
22	The latest artifact this skill may produce is a story file marked
23	`ready-for-dev`, an updated `sprint-status.yaml`, or a routing directive
24	to a downstream planning skill.
25
26	---
27
28	## When to Use This Skill
29
30	Trigger when ANY of the following is true:
31
32	- A requirement, feature, or constraint has changed after any planning
33	artifact (PRD, architecture, epics.md, or stories) was produced.
34	- Stories need to be added, dropped, split, merged, or re-scoped for reasons
35	not captured in the existing plan.
36	- The architecture changed in a way that invalidates Owned File/Module Scope
37	declarations in existing stories.
38	- The user wants to document a mid-stream decision in `decision-log.md`
39	before proceeding.
40
41	---
42
43	## Inputs (load these first)
44
45	\| File \| Why \|
46	\|------\|-----\|
47	\| `bmad-output/project-context.md` \| Project constitution — load every run \|
48	\| `bmad-output/decision-log.md` \| Threaded decisions; append here \|
49	\| `bmad-output/epics.md` \| Existing epic map to diff against \|
50	\| `bmad-output/prd.md` \| Source of truth for requirements \|
51	\| `bmad-output/architecture.md` \| Tech boundaries (if architecture changed) \|
52	\| `bmad-output/sprint-status.yaml` \| Current sequencing state \|
53	\| `bmad-output/stories/*.story.md` \| In-flight and backlog stories \|
54
55	Output folder default: `bmad-output/`. Honor any user-configured override
56	from `bmad-output/config.yaml`.
57
58	---
59
60	## Three Intents
61
62	\| Intent \| When to use \|
63	\|--------\|-------------\|
64	\| Scope Change \| A feature is added, dropped, or reshaped — re-shard affected epics and re-sequence. \|
65	\| Architecture Change \| Module boundaries, stack, or integrations shift — update Owned Scope declarations in impacted stories. \|
66	\| Record Only \| The change is already reflected in planning artifacts; write the decision-log entry and confirm consistency. \|
67
68	State the intent explicitly before proceeding. When unclear, ask the user
69	which scenario applies rather than assuming.
70
71	---
72
73	## Workflow
74
75	Use `TodoWrite` to track progress through these steps.
76
77	### Step 1 — Load and orient
78
79	1. Read all inputs listed above.
80	2. Identify the change statement: what is new, what is removed, what
81	is altered, and why (ask the user if unclear).
82	3. State back to the user what you understood before making any edits.
83
84	### Step 2 — Impact triage
85
86	Identify the minimum blast radius:
87
88	- Which epics are affected? (added / dropped / reshaped)
89	- Which stories are affected? (added / dropped / re-scoped /
90	invalidated Owned Scope)
91	- Which story statuses must change? (`in-progress` stories touched by
92	the change need special care — flag them; do not silently move them.)
93	- Does `sprint-status.yaml` need re-sequencing?
94
95	Present the triage to the user and confirm before editing.
96
97	### Step 3 — Update planning artifacts
98
99	Apply only the minimum-necessary changes.
100
101	#### 3a. Update epics.md (affected epics only)
102
103	- Add new epics with a `# COURSE-CORRECTION` annotation and the date.
104	- Mark dropped epics as `status: cancelled` — do not delete; preserve history.
105	- Update epic descriptions, scope boundaries, and the ordere

People who liked this also viewed

6 picks

Type

bmad-correct-course

467stars73forks

View on GitHub

How to install bmad-correct-course?

aj-geddes/claude-code-bmad-skills/bmad-correct-course

$npx -y skills add aj-geddes/claude-code-bmad-skills --skill bmad-correct-course

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# BMAD Correct Course
2
3	Role: Cross-phase re-entry point for mid-stream planning changes.
4
5	When reality diverges from the plan — a stakeholder pivots, a constraint
6	surfaces, a feature is cut — this skill re-enters the planning phase, makes
7	the minimum-necessary plan changes, and routes forward to the appropriate
8	downstream skill. It changes the plan, never the code.
9
10	Persona flavor: Mary (Analyst) surfaces the impact; John (PM) scopes the
11	delta; Winston (Architect) re-shards affected epics.
12	Lightweight flavor only — this is a workflow.
13
14	---
15
16	## Scope Law (read first)
17
18	This skill PLANS. It NEVER writes application code, runs tests, lints,
19	checks coverage, builds, or reviews diffs. If tempted to "fix the code" or
20	"run the suite" — STOP. Plan the change and hand it off.
21
22	The latest artifact this skill may produce is a story file marked
23	`ready-for-dev`, an updated `sprint-status.yaml`, or a routing directive
24	to a downstream planning skill.
25
26	---
27
28	## When to Use This Skill
29
30	Trigger when ANY of the following is true:
31
32	- A requirement, feature, or constraint has changed after any planning
33	artifact (PRD, architecture, epics.md, or stories) was produced.
34	- Stories need to be added, dropped, split, merged, or re-scoped for reasons
35	not captured in the existing plan.
36	- The architecture changed in a way that invalidates Owned File/Module Scope
37	declarations in existing stories.
38	- The user wants to document a mid-stream decision in `decision-log.md`
39	before proceeding.
40
41	---
42
43	## Inputs (load these first)
44
45	\| File \| Why \|
46	\|------\|-----\|
47	\| `bmad-output/project-context.md` \| Project constitution — load every run \|
48	\| `bmad-output/decision-log.md` \| Threaded decisions; append here \|
49	\| `bmad-output/epics.md` \| Existing epic map to diff against \|
50	\| `bmad-output/prd.md` \| Source of truth for requirements \|
51	\| `bmad-output/architecture.md` \| Tech boundaries (if architecture changed) \|
52	\| `bmad-output/sprint-status.yaml` \| Current sequencing state \|
53	\| `bmad-output/stories/*.story.md` \| In-flight and backlog stories \|
54
55	Output folder default: `bmad-output/`. Honor any user-configured override
56	from `bmad-output/config.yaml`.
57
58	---
59
60	## Three Intents
61
62	\| Intent \| When to use \|
63	\|--------\|-------------\|
64	\| Scope Change \| A feature is added, dropped, or reshaped — re-shard affected epics and re-sequence. \|
65	\| Architecture Change \| Module boundaries, stack, or integrations shift — update Owned Scope declarations in impacted stories. \|
66	\| Record Only \| The change is already reflected in planning artifacts; write the decision-log entry and confirm consistency. \|
67
68	State the intent explicitly before proceeding. When unclear, ask the user
69	which scenario applies rather than assuming.
70
71	---
72
73	## Workflow
74
75	Use `TodoWrite` to track progress through these steps.
76
77	### Step 1 — Load and orient
78
79	1. Read all inputs listed above.
80	2. Identify the change statement: what is new, what is removed, what
81	is altered, and why (ask the user if unclear).
82	3. State back to the user what you understood before making any edits.
83
84	### Step 2 — Impact triage
85
86	Identify the minimum blast radius:
87
88	- Which epics are affected? (added / dropped / reshaped)
89	- Which stories are affected? (added / dropped / re-scoped /
90	invalidated Owned Scope)
91	- Which story statuses must change? (`in-progress` stories touched by
92	the change need special care — flag them; do not silently move them.)
93	- Does `sprint-status.yaml` need re-sequencing?
94
95	Present the triage to the user and confirm before editing.
96
97	### Step 3 — Update planning artifacts
98
99	Apply only the minimum-necessary changes.
100
101	#### 3a. Update epics.md (affected epics only)
102
103	- Add new epics with a `# COURSE-CORRECTION` annotation and the date.
104	- Mark dropped epics as `status: cancelled` — do not delete; preserve history.
105	- Update epic descriptions, scope boundaries, and the ordere

People who liked this also viewed

6 picks

Type