Escalation Governance
Decide when to move an agent task from a fast cheap model to a deeper reasoning tier without wasting latency and budget.
Overview
Escalation Governance is a journey-wide agent skill that defines when model escalation (e.g. faster to deeper tiers) is justified after systematic investigation—not as a default fix for uncertainty.
Install
npx skills add https://github.com/athola/claude-night-market --skill escalation-governanceWhat is this skill?
- Iron Law: no escalation without justified trade-off versus speed and cost
- Four-step decision framework: understand problem, investigate systematically, confirm escalation fits, justify trade-off
- Explicit When to Escalate vs When NOT to Escalate lists for haiku→sonnet→opus style ladders
- Red-flag STOP list and orchestrator authority for multi-agent setups
- Documents common rationalizations that push unjustified model upgrades
- 4-step decision framework before escalation
- ~800 estimated tokens in skill metadata
- Model ladder referenced as haiku→sonnet→opus
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You keep bumping agents to smarter models hoping luck changes, and latency plus cost climb without proof the task needs deeper reasoning.
Who is it for?
Indie builders running tiered model stacks (haiku/sonnet/opus or equivalents) with an orchestrator or supervisor agent.
Skip if: Single-model chats with no routing, or tasks you have not investigated with the current tier’s tooling and evidence.
When should I use this skill?
Assess whether to escalate models when evaluating reasoning depth in agent or orchestrator workflows.
What do I get? / Deliverables
You apply a documented escalation protocol with justified trade-offs, red-flag checks, and orchestrator-aligned authority before changing model tiers.
- Escalation decision record with trade-off justification
- Updated orchestrator or agent schema escalation rules
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Encode escalation gates in your router YAML so cheap models finish tool loops before sonnet is allowed.
Decide whether a fuzzy product tradeoff needs a deeper model or clearer written constraints on haiku.
Reject a reviewer agent’s opus request until systematic diff analysis on the standard tier is logged.
Post-incident, audit whether escalations during the outage matched the four-step justification framework.
How it compares
Governance for model routing decisions—not a substitute for debugging skills or better prompts on the base tier.
Common Questions / FAQ
Who is escalation-governance for?
Builders wiring agent workflows who need consistent rules for when deeper reasoning models earn their cost.
When should I use escalation-governance?
Before escalating during Build agent-tooling design; when Validate prototypes stall on architecture judgment; when Ship review or Operate incidents tempt a blind model upgrade; whenever you evaluate reasoning depth per the skill trigger.
Is escalation-governance safe to install?
It is policy guidance only—review the Security Audits panel on this Prism page; it does not execute shell or network actions by itself.
SKILL.md
READMESKILL.md - Escalation Governance
## Table of Contents - [Overview](#overview) - [The Iron Law](#the-iron-law) - [When to Escalate](#when-to-escalate) - [When NOT to Escalate](#when-not-to-escalate) - [Decision Framework](#decision-framework) - [1. Have I understood the problem?](#1-have-i-understood-the-problem) - [2. Have I investigated systematically?](#2-have-i-investigated-systematically) - [3. Is escalation the right solution?](#3-is-escalation-the-right-solution) - [4. Can I justify the trade-off?](#4-can-i-justify-the-trade-off) - [Escalation Protocol](#escalation-protocol) - [Common Rationalizations](#common-rationalizations) - [Agent Schema](#agent-schema) - [Orchestrator Authority](#orchestrator-authority) - [Red Flags - STOP and Investigate](#red-flags-stop-and-investigate) - [Integration with Agent Workflow](#integration-with-agent-workflow) - [Quick Reference](#quick-reference) # Escalation Governance ## Overview Model escalation (haiku→sonnet→opus) trades speed/cost for reasoning capability. This trade-off must be justified. **Core principle:** Escalation is for tasks that genuinely require deeper reasoning, not for "maybe a smarter model will figure it out." ## The Iron Law ``` NO ESCALATION WITHOUT INVESTIGATION FIRST ``` **Verification:** Run the command with `--help` flag to verify availability. Escalation is never a shortcut. If you haven't understood why the current model is insufficient, escalation is premature. ## When to Escalate **Legitimate escalation triggers:** | Trigger | Description | Example | |---------|-------------|---------| | Genuine complexity | Task inherently requires nuanced judgment | Security policy trade-offs | | Reasoning depth | Multiple inference steps with uncertainty | Architecture decisions | | Novel patterns | No existing patterns apply | First-of-kind implementation | | High stakes | Error cost justifies capability investment | Production deployment | | Ambiguity resolution | Multiple valid interpretations need weighing | Spec clarification | ## When NOT to Escalate **Illegitimate escalation triggers:** | Anti-Pattern | Why It's Wrong | What to Do Instead | |--------------|----------------|---------------------| | "Maybe smarter model will figure it out" | This is thrashing | Investigate root cause | | Multiple failed attempts | Suggests wrong approach, not insufficient capability | Question your assumptions | | Time pressure | Urgency doesn't change task complexity | Systematic investigation is faster | | Uncertainty without investigation | You haven't tried to understand yet | Gather evidence first | | "Just to be safe" | False safety - wastes resources | Assess actual complexity | ## Decision Framework Before escalating, answer these questions: ### 1. Have I understood the problem? - [ ] Can I articulate why the current model is insufficient? - [ ] Have I identified what specific reasoning capability is missing? - [ ] Is this a capability gap or a knowledge gap? **If knowledge gap:** Gather more information, don't escalate. ### 2. Have I investigated systematically? - [ ] Did I read error messages/outputs carefully? - [ ] Did I check for similar solved problems? - [ ] Did I form and test a hypothesis? **If not investigated:** Complete investigation first. ### 3. Is escalation the right solution? - [ ] Would a different approach work at current model level? - [ ] Is the task inherently complex, or am I making it complex? - [ ] Would breaking the task into smaller pieces help? **If decomposable:** Break down, don't escalate. ### 4. Can I justify the trade-off? - [ ] What's the cost (latency, tokens, money) of escalation? - [ ] What's the benefit (accuracy, safety, completeness)? - [ ]