raise-blockerlisted

# Raise a blocker Guessing is the most expensive thing a worker can do: it spends effort on an answer nobody asked for, and the rework returns as a review finding. A blocker is progress when it becomes a question someone can answer in one step. This is the worker's channel to the primary. The primary owns the conversation with the developer (see `escalate-decision`); your job is to make the decision cheap to make. ## When to use - The brief is ambiguous, contradicts itself, or an acceptance criterion cannot be interpreted as written. - The work needs a decision only the primary or developer can make — scope, priority, an interface, a tradeoff. - Continuing would require a risky, out-of-scope, or hard-to-reverse action. - A required check cannot run, or evidence is missing, and the task cannot proceed without it. ## When not to use - You can settle it inside scope with the project's own context — read the code, docs, tests, and conventions first. This skill is for what you cannot settle alone. - You have a preference but a reasonable default exists — take the default, say you did, and record the assumption. Do not block on taste. ## Inputs - The blocker, in one sentence. - What you tried and what you observed: the smallest evidence. - The decision required, and the options you can see. ## Procedure 1. **State the blocker precisely.** One sentence naming what is stopping you and the artifact it concerns — a file, a criterion, a command. 2. **Give the sm