escalate-decisionlisted

# Escalate a decision Automation fails when it either hides a decision or drowns the developer in them. Escalate when the answer genuinely belongs to the developer, and make each escalation cheap to answer: one situation, one question, the evidence that matters, and the options. The developer stays the final decision-maker; everything else you coordinate. ## When to use - A worker returned a question (is blocked) or has failed. - Acceptance criteria are ambiguous or contradictory, and guessing would spend real work on the wrong target. - An action is risky or consequential — commit, merge, push, publish, deploy, delete, or exposing secrets. These always need explicit approval. - A review is `inconclusive`, or a reviewer and implementer dispute a finding. - The rework loop reached `max_iterations` without converging. ## When not to use - Routine progress or a completed task: that is `report-progress`. - A question the task's own criteria or the project context already answers: decide it and record the decision. Escalating what you can settle yourself trains the developer to ignore escalations. ## Inputs - The state that needs a decision, and what you tried. - The smallest evidence that makes the decision possible — a worker's question, review findings, a diff stat, command output. - The options, with your recommendation. ## Procedure 1. **Check that it is theirs.** Confirm the call needs developer intent or a risk appetite you do not have. If the criteria