Skip to main content

bmad-auto-resolve

Interactive escalation-resolution workflow for the bmad-auto orchestrator. A bmad-auto run paused on a CRITICAL escalation (a contradiction or gap a dev/review session could not safely resolve alone); you and the human disambiguate the frozen spec so the story can be re-driven. Invoked as /bmad-auto-resolve <story-key>. Unlike the automated dev/review sessions this session is interactive — a human is present and you SHOULD ask.

Source facts

Repository
bmad-code-org/bmad-auto
Last source activity
June 24, 2026 at 08:43
Detected SKILL.md language
English
Stars
6
Forks
2

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
bmad-auto-resolve
description
Interactive escalation-resolution workflow for the bmad-auto orchestrator. A bmad-auto run paused on a CRITICAL escalation (a contradiction or gap a dev/review session could not safely resolve alone); you and the human disambiguate the frozen spec so the story can be re-driven. Invoked as /bmad-auto-resolve <story-key>. Unlike the automated dev/review sessions this session is interactive — a human is present and you SHOULD ask.
# bmad-auto Escalation Resolution A `bmad-auto` run drove a story through dev → review, a session raised a **CRITICAL escalation** (work could not proceed safely — usually a contradiction or an unanswered question in the _frozen spec_), and the orchestrator paused the whole run for a human. The session that escalated is gone; you are a fresh interactive session whose job is to **resolve the ambiguity with the human and update the frozen spec**, so the orchestrator can re-arm the story and re-drive it against a corrected spec. This is **interactive**: a human IS present. Ask questions, present options, recommend — but the human makes the call. (`$BMAD_AUTO_MODE` is intentionally unset for this session; the never-ask automation rules do NOT apply.) ## Identity & I/O contract These environment variables are set: - `$BMAD_AUTO_RUN_DIR` — the paused run's directory. - `$BMAD_AUTO_STORY_KEY` — the escalated story key (also your invocation argument). - `$BMAD_AUTO_RESOLVE_CONTEXT` — path to a `context.json` written for you. **Read `$BMAD_AUTO_RESOLVE_CONTEXT` FIRST.** Its schema: ```json { "story_key": "6-4-cli-list-command", "run_id": "20260613-111429-6a14", "spec_file": "/abs/path/to/_bmad-output/implementation-artifacts/spec-<story>.md", "baseline_commit": "<sha>", "paused_reason": "CRITICAL escalation from review session: ...", "escalations": [ { "type": "<kind>", "severity": "CRITICAL", "detail": "<what's ambiguous/contradictory>" } ], "resolution_path": "/abs/path/to/<run>/resolve/<story>/resolution.json" } ``` Your **output marker** is the file at `resolution_path`. Writing it is the LAST action of a successful resolution. Schema: ```json { "story_key": "<key>", "decision": "<one or two sentences: the rule you and the human chose>", "spec_file": "<the spec you edited>", "spec_updated": true } ``` ## What you MUST do 1. **Read the context**, then read the **frozen spec** at `spec_file` in full — especially its `<frozen-after-approval>` block (the intent the dev/review sessions treat as authoritative). The escalation is almost always that this block is silent on, or contradicts, a case the implementation hit. 2. **Present the escalation plainly** to the human: what is ambiguous or contradictory, why it blocks safe implementation, and **2–4 concrete resolution options** with a clear recommendation and its trade-offs. Keep it tight — quote the relevant spec lines. 3. **Get the human's decision.** Ask follow-ups if the choice is unclear. Do not invent requirements; if the human is unsure, help them reason, don't guess. 4. **Update the frozen spec** to encode the decision unambiguously: amend the `<frozen-after-approval>` block and any affected acceptance criteria / test matrix rows so a fresh dev session has exactly one correct reading. Make the smallest change that removes the ambiguity. You MAY use the `bmad-spec` or `bmad-correct-course` skills if a larger spec change is warranted. 5. **Write the resolution marker** at `resolution_path` (schema above), then tell the human the resolution is recorded and they can exit this session — the orchestrator will offer to **re-arm the story and resume the run** (a clean rebuild against the corrected spec). ## What you MUST NOT do - **Do NOT** write the orchestrator's `result.json` — that is a dev/review artifact; this is not one of those sessions. - **Do NOT** change `sprint-status.yaml`, and **do NOT** set the spec's `status:` field — the orchestrator deterministically re-arms the spec status on resume. Edit spec **content** only. - **Do NOT** implement the story, write feature code, run tests, or commit. Your job ends at a corrected spec + the resolution marker. - **Do NOT** widen scope. Resolve exactly the escalated ambiguity; if you notice unrelated problems, note them to the human but leave them alone. ## If you cannot resolve it If the human defers, the information needed is genuinely unavailable, or the right fix is out of scope for a spec edit (e.g. it needs a PRD/architecture change), say so plainly and **do not** write the resolution marker. Exiting without the marker leaves the story escalated and the run paused — the safe default. The orchestrator will not re-arm a story with no recorded resolution.
View on GitHub