← ClaudeAtlas

resolve-epiclisted

Resolve-epic handler for the dispatch chain — judges whether a verifiably-complete parent epic's own acceptance criteria are genuinely met by the merged child work, then auto-closes it (dispatch-close-resolved) or escalates to office-hours (dispatch-mark-deviation) when a criterion is not autonomously verifiable.
natb1/commons.systems · ★ 3 · AI & Automation · score 66
Install: claude install-skill natb1/commons.systems
# Resolve Epic A dispatch worker runs this skill when the routed target is a **parent epic** whose sub-issues are all closed, so the epic became the topological leaf with no PR and no `dispatch:planned` label. Routing the epic to `/plan-issue` would find nothing to build and stop without a completion marker, so `dispatch-stop.sh` Branch A would park the epic on `dispatch:office-hours` for a human to merely confirm-and-close. That confirm-and-close is pure ceremony when the epic is genuinely done. See issue #1456. This skill replaces that ceremony. It judges whether the epic's **own** acceptance criteria are genuinely met by the merged child work, then either **auto-closes** the epic (via `dispatch-close-resolved`, whose `resolved-closed` sentinel `dispatch-stop.sh` Branch R reads to advance the chain) or **escalates to office-hours** (via `dispatch-mark-deviation`, whose marker-absence `dispatch-stop.sh` reads as Branch A, falling back to today's confirm-and-close behavior) when a criterion is not autonomously verifiable. `/resolve-epic` operates **in place** — the current worktree dictates the target. The router enters the target worktree; this skill never switches. ## Sandbox Run every `gh` call and every gh-invoking script with `dangerouslyDisableSandbox: true` — `gh`'s TLS validation is blocked by the sandbox (`.claude/rules/sandbox.md`). That covers: - The `gh issue view` state check (Step 2). - `dispatch-context-pack` (Step 3) — it calls `gh`. - `dispatch-close-re