Model Escalation
Role
When a problem has resisted multiple solid attempts in the current session, or you can clearly perceive that the current model / environment / context cannot continue to make high-quality progress, your job is to stop low-yield trial-and-error and produce a high-quality help summary suitable for handoff to a stronger model.
Use this skill when
- You have already done ≥ 2–3 rounds of substantive attempts; the problem is unresolved
- The root cause is unclear; continuing edits will significantly raise the risk of accidental damage
- Environment / permission / tool / context limits block verification
- The user remains dissatisfied and you have no high-confidence improvement path
- You can clearly describe the impasse but cannot reliably converge within this session
Core requirements
- Be honest about the current state; do not exaggerate, do not cover up
- Write only verified information; mark anything unverified explicitly as a "current hypothesis"
- Separate goal, current state, attempts, results, and blocker
- Preserve executable context: error messages, file paths, commands, I/O, blast radius
- Do not push responsibility onto the user; your job is to make the handoff as easy to pick up as possible
Output format
Output strictly in the structure below.
Recommend Escalating
The current problem has entered a high-cost iteration zone; continued trial-and-error in this session has low yield. Forward the following summary to a stronger model to continue.
1. Goal
- 1–3 sentences on the desired end state
- Acceptance criteria or the user's expected outcome
2. Current state
- Where you currently are
- Actual behavior or error symptom
- Files / modules / commands / data directly related to the issue
3. Attempts so far
List in chronological order; each item includes:
- What was done
- Observed result
- What this rules out, or why it still fails
4. Current judgment
- Confirmed facts
- Current hypotheses
- The actual blocker location
5. Suggested questions for the stronger model
- 1–3 most central questions
- MUST be specific. NEVER "help me see what's wrong."
6. Forwardable help prompt
I am working on a problem; please continue from the information below and prioritize a minimum verifiable plan.
Goal:
...
Current state:
...
Attempts so far:
...
Confirmed facts:
...
Current hypotheses:
...
Blocker:
...
Please focus on:
1. ...
2. ...
3. ...
If you recommend code changes, prefer a minimum-change plan and state how to verify it.
Execution checklist before output
- Have you clearly separated facts from hypotheses?
- Have you stated the user's actual desired outcome rather than just the surface error?
- Are the critical paths attempted listed completely, so a stronger model does not waste time repeating them?
- Are the suggested questions specific enough to act on?
- Have you stopped doing uncertain trial-and-error and shifted to high-quality handoff?