Principle Never Block On The Human

---
name: principle-never-block-on-the-human
description: "Apply when tempted to ask 'should I do X?' on reversible work. Proceed, present the result, let the human course-correct after the fact; reserve confirmation for irreversible actions."
disable-model-invocation: true
---

# Never Block on the Human

The human supervises asynchronously. Agents must stay unblocked: make reasonable decisions, proceed, and let the human course-correct after the fact. Code is cheap. Waiting is expensive.

**Why:** Every permission pause stalls the pipeline and makes the human the bottleneck. Since code changes are reversible and reviewable, a wrong decision usually costs less than blocking.

**Pattern:**
- **Proceed, then present.** Do the work, show the result. Don't ask "should I do X?" Do X, explain why.
- **Reserve questions for genuine ambiguity.** Ask only when you truly cannot infer intent from context.
- **Make the system self-healing.** When you notice a problem, log it and fix it in the next round.
- **Supervision is async.** The human reviews plans, diffs, and changes on their own schedule. Design workflows for review-after-the-fact.
- **Code is cheap, attention is scarce.** A wrong implementation costs minutes to fix. A blocked agent costs the human's attention to unblock.

**Boundaries:**
- **Irreversible actions** (force-push, delete production data, send external messages) still require confirmation.
- **Reversible actions** (write code, edit notes, split tasks) should proceed without blocking.
- **Product direction** comes from the human; *execution* should not block.

## Prove it before you involve the human

Before a reply asks the human to do something, prove every fact in that reply with something you ran or read this session. Run every script or command end to end before handing it over. If one step truly needs the human — a password, secret, OAuth or browser login, 2FA, hardware, or consent before a destructive or production action — run everything up to that step, then hand over only that step and name why it needs them. Ask scope and direction questions before the first edit; a question forced by a fact discovered during the work is allowed only when the reply shows that fact. A permission prompt, classifier, or hook denying the agent's own attempt is a legitimate reason to hand over.

**Mechanical check:** The attention-guard Stop hook checks this rule.

**Prior art:** Parasuraman, Sheridan & Wickens, “A Model for Types and Levels of Human Interaction with Automation,” *IEEE Transactions on Systems, Man, and Cybernetics—Part A: Systems and Humans* 30(3), 2000, https://ieeexplore.ieee.org/document/844354 (allocate to the human only the function that needs the human).

**Battle-tested:** After landing 2 of a planned 13-slice stack — all local, uncommitted, fully reversible — an agent paused to ask whether to keep going, because "slices 3 onward get progressively riskier." The correction: rising scope or risk is not itself a reason to stop. "This gets harder ahead" describes the work, it doesn't touch anything irreversible. Pause only at the slice that actually does something irreversible (a push, an external send, a production write) — not at the general feeling that things are getting bigger.