judgment-gate

name	judgment-gate
description	A judgment classifier for planned tool calls or agent actions. Scores reversibility, cost boundary, blast radius, and user observability, then routes to ACT / ASK / QUEUE / ABORT with reasoning.

Judgment Gate

A reusable judgment classifier that sits between an agent and its planned action. Given a description of what the agent is about to do, applies a four-question rubric and routes the action to the correct approval path. Generalizes the ad-hoc judgment patterns found in individual hooks and CLAUDE.md rules into a single callable skill.

Trigger

Use when the user says "judgment gate", "should I act or ask?", "is this safe to auto-run?", "classify this action", "reversibility check", or when an agent needs to decide whether to proceed autonomously before executing a consequential tool call.

Can also be wired as a PreToolUse hook: "before any Edit, Write, or POST call, run judgment-gate on the planned action."

Phase 1: Intake

Accept the planned action. This can be:

• A natural-language description ("I'm about to delete the staging database")
• A tool call signature ("Edit /etc/nginx/nginx.conf lines 40-55")
• An API call ("POST /api/payments with amount=5000")
• A shell command ("git push --force origin main")

If no planned action is provided, ask for one sentence describing what the agent is about to do and why.

Phase 2: Four-Question Rubric

Evaluate the action against all four questions. For each, assign PASS or FAIL with a one-line reason.

Q1: Reversibility

Can this action be fully undone in under 5 minutes by the user, without data loss or external side effects?

PASS examples: editing a local file (git can revert), creating a draft (not sent), running a read-only query. FAIL examples: sending an email, deleting a production record without backup, pushing to a shared branch, charging a payment card.

Q2: Cost Boundary

Is the cost of this action bounded and within a pre-authorized limit?

Cost includes: money, API tokens, compute time, rate-limit consumption, third-party service charges. PASS: action costs nothing or is under a clearly pre-authorized threshold. FAIL: cost is unbounded, unknown, or exceeds the threshold. If no threshold exists, treat as FAIL.

Q3: Blast Radius

Does this action affect only the current user's local state, or does it touch shared systems, other users, or external services?

PASS: affects only local files, local database, or the current user's private data. FAIL: touches a shared database, sends a network request with side effects, modifies infrastructure visible to others, or affects any other user.

Q4: Observability

Is the user currently positioned to notice this action and correct it within 60 seconds if it goes wrong?

PASS: user is in an active interactive session and can see what the agent is doing. FAIL: agent is running autonomously (scheduled, background, unattended), or the user is on a different device and not watching.

Phase 3: Route the Action

Apply routing logic based on PASS/FAIL counts:

Q1	Q2	Q3	Q4	Route
PASS	PASS	PASS	PASS	ACT — proceed autonomously
PASS	PASS	PASS	FAIL	ACT with audit log — proceed, but log the action for post-hoc review
PASS	PASS	FAIL	any	ASK — get explicit approval before proceeding
PASS	FAIL	any	any	ASK — cost unclear or exceeds threshold
FAIL	any	any	any	QUEUE — stage the action for synchronous human review; do not execute
FAIL	FAIL	FAIL	any	ABORT — action is irreversible, unbounded cost, and affects shared state; refuse

Override: if any question is FAIL AND the user is not currently observing (Q4 FAIL), escalate one level (ACT → ASK, ASK → QUEUE, QUEUE → ABORT).

Phase 4: Output

## Judgment Gate — [Action Summary]

| Question       | Result | Reason                                           |
|----------------|--------|--------------------------------------------------|
| Reversibility  | PASS/FAIL | [one line]                                    |
| Cost Boundary  | PASS/FAIL | [one line]                                    |
| Blast Radius   | PASS/FAIL | [one line]                                    |
| Observability  | PASS/FAIL | [one line]                                    |

**Route: ACT / ASK / QUEUE / ABORT**

[One-sentence rationale for the route]

[If ASK or QUEUE: exact question or approval request to surface to the user]
[If ABORT: what would need to change for this action to be routable as ACT or ASK]

Phase 5: Hook Pattern

To wire judgment-gate as a PreToolUse hook, add to settings.json:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit|Write|Bash",
      "hooks": [{
        "type": "command",
        "command": "echo '[judgment-gate] Run /judgment-gate on this planned action before proceeding'"
      }]
    }]
  }
}

The hook is advisory-only — the user decides whether to block or allow after seeing the gate output.

Verification

A good gate output:

• Does not default to ABORT on every action (that defeats the purpose — ACT should be the common path for safe, local, reversible work)
• Makes Blast Radius and Reversibility primary discriminators (these are the highest-signal questions)
• Produces an ASK or QUEUE when Q1 (Reversibility) is FAIL — never ACTs on irreversible actions without explicit approval
• The rationale sentence names the specific FAIL question(s), not generic uncertainty

Source

Extracted from Nate Kadlac newsletter (2026-05-05) — "The Anticipation Gap: Why 4 Problems Have to Be Solved Together for Consumer AI to Work" — judgment problem (when should an agent act vs ask?) generalized into a standalone classifier skill.