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.

소스 정보

저장소
bmad-code-org/bmad-auto
최근 소스 활동
2026년 6월 24일 08:43
감지된 SKILL.md 언어
영어
스타
6
포크
2

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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.
GitHub에서 보기