---
name: escalate
description: Use when a task's routed tier isn't good enough — a prompt keeps failing its evals at the tier the routing table assigns. The evidence-gated promotion procedure - demands the failing eval, writes the escalation changelog entry, records the new tier. Triggers on /escalate, "this needs a stronger model", "bump this to frontier", "the cheap model can't do this".
---

# Escalate — evidence-gated tier promotion

Promotion is earned by a failing eval, never by intuition. This skill is the only legitimate path to running a task above its routed tier — and it is deliberately fast: one eval run of evidence, one entry, done. No approvals theater.

## Procedure

1. **Demand the evidence.** A completed `prompt-eval` run at the currently routed tier, failing the family threshold. No run ⇒ run it now (that is the whole gate). An old run doesn't count — the evidence is for the current prompt version.
2. **Write the escalation entry** — this skill owns the format; `cost-report` parses these entries, so the shape is a contract:
   - File: `docs/history/changelog/YYYY-MM-DD-{three-words}.md`, standard changelog-entry template, plus its `docs/history/CHANGELOG.md` row.
   - **`Class: escalation`** — the fixed rendezvous keyword. Exactly this word; `cost-report` and `retro` match on it.
   - `Change:` names the task type, the family, the failing score vs. threshold, and the tier movement (`standard → frontier`).
   - `Discovered:` what the failure teaches about the tier's capability ceiling — this is the routing table's tuning signal.
3. **Record the promotion scope**: one-off (this task runs high once) or standing (the routing row itself is wrong). A standing promotion also appends an out-of-scope discovery proposing the routing-table row change — the table is policy and moves by its own edit, not silently.
4. **Dispatch at the new tier** and finish the work.

## Rules

- **The entry precedes the dispatch.** An escalation with no entry is an unevidenced promotion — the routing guardrails prohibit it.
- **Escalation is symmetric.** When `regression-runner`'s demotion experiment passes a tier down, that result is recorded the same way (`Class: escalation`, direction down) — the table tunes on both signals.
- **Frequency is signal, not failure.** Many escalations from one row mean the row is wrong; that is `retro`'s finding to make, from these entries. Never suppress one to keep the table looking right.