escalate

Escalate Skill

This skill handles escalation decisions when the executor returns a hard_fail or budget_exceeded result. Given the briefing, you choose a lever: refined re-dispatch (default for weak models), session takeover (last resort), or resume. The decision is judgment-heavy — wrong defaults burn the architect-executor split.

Read these first

Before any action:

1. Read the briefing from the returned PhaseResult.briefing. This is your primary input — it contains one_line, current_blocker, what_was_tried, and diagnostics.
2. Read the phase doc (resolve <phase> from the argument) to understand the original spec, its acceptance criteria, and what the executor was attempting.
3. Read <repo>/docs/dev/STANDARDS.md for context on the engineering contract the executor was held to.
4. If the briefing references specific turns, query the session log via executor_log_tail + get_turn MCP tools using the phase's log_path.
5. Read any open bug reports in the milestone's bugs/ directory that reference this phase.

The repo root is <repo> — resolve it from CLAUDE_PROJECT_DIR, ANTIGRAVITY_PROJECT_DIR, or the nearest directory containing the milestone layout.

1. Refuse non-failure results

Check PhaseResult.status:

• If "complete": this is a review, not an escalation. Point the user at /rexymcp:review <phase> and stop. Escalate is not for clean results.
• If "hard_fail" or "budget_exceeded": proceed to §2.
• If "cancelled": proceed to §2 — a deliberately-stopped run is the clearest resume candidate (its partial work is already on disk). See the Resume lever.

2. Choosing a lever

A hard_fail briefing is a signal: the executor reached the budget, hit a diagnostic it couldn't resolve, lost track of state, or otherwise stopped without producing a clean PhaseResult. The escalation question is what changes so the next attempt succeeds.

On a NoProgressStall, run the project's gates against the partial tree yourself before picking a lever — build, lint, tests. A stall is usually a nearly-finished phase: the executor writes most of the work, then loops re-reading instead of running a gate. The minute of gate-running decides the lever (if the missing piece is small, resume with the diagnosis; if the missing piece is the very edit it stalled on, the stall itself is the wall) and it finds defects nothing else will — the executor stalled before running any gate, so its partial work is unverified by construction and the briefing cannot show what's broken in it. Do not treat the stall as evidence the work is bad; the design is typically right and what's missing is integration.