Escalation

Purpose

Define when and how to interrupt autonomous work to consult the user.

Escalation Triggers

Always escalate:

• Requirements are ambiguous after reasonable interpretation effort
• Requirements conflict with each other
• Requirements conflict with existing architecture
• Decision has architectural implications (new patterns, dependencies)
• Decision has security implications (auth, data exposure, permissions)
• Decision requires external API/service choice
• Spec gap discovered that blocks implementation
• Implementation would require changing files not listed in spec
• Available capabilities are insufficient for the task

Never escalate (decide autonomously):

• Code style choices within project conventions
• Variable/function naming (follow existing patterns)
• Minor refactoring to enable the change
• Test structure and organization
• Order of implementation steps
• Which subagent to use for a task

Escalation Format

## Escalation Required

**Phase:** <current phase>
**Task:** <what you were working on>

**Issue:** <one sentence summary>

**Context:**
<2-3 sentences explaining the situation>

**Options:**
A) <option> - <trade-off>
B) <option> - <trade-off>
C) <other> - let me know your preference

**My recommendation:** <A/B/C> because <reasoning>

**Blocked until:** <what you need to continue>

Escalation Behavior

1. Stop work immediately - Don't guess and continue
2. Capture state - Write current progress to scratchpad
3. Present clearly - Use the format above
4. Wait for response - Do not proceed until user responds
5. Document resolution - Add decision to scratchpad

Post-Escalation

After user responds:

1. Record the decision in scratchpad with reasoning
2. If decision changes spec: update spec doc, note the change
3. Resume work from where you stopped
4. Reference the decision if similar situation arises