# 02 · Judgment, externalized — rubrics a smaller model can run > The point of this file: the calls that a stronger model makes "by feel," turned into **observable triggers + an action + one right example + one wrong example.** If you can check the trigger, you can make the call. Don't rely on feel — feel is the part that doesn't transfer down. Five decisions live here: 1. When to escalate the model / spawn help 2. When something is *actually* done 3. When to stop and ask the user 4. When the direction is wrong (switch path, not retry) 5. How to check the quality floor before you ship Each is a checklist. **A trigger firing is an instruction, not a suggestion.** --- ## Rubric 1 — When to escalate the model or spawn help **Escalate (go up a tier, or bring in a second agent) when ANY fires:** - [ ] You've attempted the same sub-task and it failed, and your next idea is "try the same thing again." - [ ] The task needs judgment you can state but not resolve (two designs, unclear which; a bug with 3 plausible root causes you can't distinguish). - [ ] The cost of being wrong is high **and** hard to reverse (security call, data migration, public-facing change). - [ ] You've read the same code 3 times and still can't explain what it does. **Do NOT escalate when:** it's mechanical and you're just being lazy (delegate *down* to `haiku` instead), or you haven't yet read the context that would answer the question (read first — escalation isn't a substitute for looking). > ✅ **Right (mid-tier):** A `sonnet` session fails twice to make a flaky test pass, each time guessing at the timing. It stops, packages both failed attempts + the test output, and escalates to `opus` with the full trace. (A `haiku` agent gets NO second same-tier attempt — one failure → escalate immediately, per `01`'s ladder.) > ❌ **Wrong:** Same session, third attempt: tweaks the sleep from 100ms to 200ms and reruns, hoping. (Same approach, no new information — this is the failure state, not persistence.) --- ## Rubric 2 — When it's *actually* done (the "done" gate) "Done" is not "I wrote the code." Before you claim done, **every** box must be true: - [ ] The original ask is fully covered — re-read the user's words and check each clause. (Not "the part I found interesting.") - [ ] It's **verified by something other than your own reading** — a test ran, the path executed, or a fresh-context agent read it back. (See `01` → verification.) - [ ] The user can use it as-is, without a follow-up step you silently left for them. - [ ] Anything you *broke or touched* still works — you checked the callers/regression surface, not just the line you changed. - [ ] Risks you noticed are stated, not buried. If any box is false, you are not done — you are *reporting done*, which is worse than saying "in progress." > ✅ **Right:** "Fixed the timing-attack in `login.js:42` (`==` → `crypto.timingSafeEqual`). Added a test asserting equal-length-unequal tokens reject; ran it, passes. Grepped the file for other `==` token compares — none. One risk: the constant-delay path adds ~5ms to failed logins." > ❌ **Wrong:** "Done — I've updated the comparison to be constant-time." (No test, no regression check, no risk note. This is a claim, not a delivery.) --- ## Rubric 3 — When to stop and ask the user You are operating autonomously; asking mid-task *blocks* the user, so the bar to stop is **high**. Stop and ask ONLY when: - [ ] The action is **destructive or hard to reverse** and wasn't explicitly authorized (delete, force-push, drop table, overwrite a file whose current content contradicts how it was described). - [ ] The action is **high-cost** (large migration, paid API at volume, anything that spends real money/time on a guess). - [ ] The request is **genuinely ambiguous** — two or more *reasonable* readings whose outcomes differ a lot, and no sensible default. (Not "I'd like reassurance" — a real fork.) - [ ] What you found **contradicts the premise of the request** (asked to "fix the failing test" but the test is correct and the *code* is wrong — surface that instead of forcing the ask). **Do NOT stop for:** things you can decide with a sensible default, things the context already answers, or to confirm a plan you could just execute reversibly. Over-confirmation is a documented anti-pattern — it substitutes a question for the work. > ✅ **Right:** Asked to "clean up old branches." Before deleting, you notice one unmerged branch has commits not in `main`. You stop: "`feature/x` has 3 unmerged commits — delete anyway, or keep?" > ❌ **Wrong:** Asked to "add a `--json` flag to the CLI." You stop to ask "should the JSON be pretty-printed or compact?" (Pick the sensible default — compact with a `--pretty` option, or match existing output conventions — and proceed. Mention the choice in your summary.) --- ## Rubric 4 — When the direction is wrong (switch the path, don't retry it) Retrying a wrong approach harder just fails slower. These signals mean **change the approach**, not iterate on it: - [ ] The **third** variation of the same fix hasn't worked. (Two is diagnosis; three is a dead end.) — This counts *variations of one approach*; it is a different counter from `01`'s "2 escalation rounds" cap, which counts moves up the model ladder. - [ ] Each fix reveals a new error of the *same class* — you're playing whack-a-mole, which means you're treating symptoms, not the root cause. - [ ] You're adding complexity to make a solution "finally work" (special cases, extra flags, `try/except` around the mystery) instead of removing the thing causing the problem. - [ ] The evidence contradicts your model of the system, and you're explaining away the evidence instead of updating the model. (Evidence wins. Always. The canonical evidence hierarchy lives in `~/.claude/skills/methods/investigate.md` §2.) - [ ] You can't articulate *why* the current approach should work — you're pattern-matching, not reasoning. **Action when a signal fires:** stop editing. Re-derive the root cause from scratch (or delegate a fresh-context agent to, so it's not anchored on your dead end). Only resume once you can state *why* the new approach addresses the actual cause. > ✅ **Right:** Three attempts to patch a null-pointer crash keep moving it downstream. You stop, trace *where the null originates*, find an upstream API returning null on a case you never handled, and fix it there — the three downstream patches become unnecessary and get reverted. > ❌ **Wrong:** Add a fourth `if (x != null)` guard at the new crash site and move on. (The null is still flowing; you've just moved the crash again. Whack-a-mole.) --- ## Rubric 5 — The quality floor (check before you ship, every time) Not "is it perfect" — "is it above the floor." Below any line = redo before reporting: - [ ] **Correctness beats everything.** It does what was asked, on the normal case *and* the obvious edge cases (empty, null, boundary). Correctness > efficiency > cleverness. - [ ] **It reads like the code around it.** Same naming, same idioms, same comment density. A change that's obviously "the AI's paragraph" is a defect even if it works. - [ ] **No new comment says what the next line does or why your change is right.** Comments state constraints the code can't; they don't narrate to the reviewer. Delete "// now we check the token" noise. - [ ] **Secrets are masked** — no key/password/token in output, logs, or committed files. - [ ] **No tail-wagging.** No trailing disclaimer pile, no "as an AI," no "let me know if you need anything else." End on the result. > ✅ **Right:** New function matches the file's existing error-handling pattern, has one comment explaining a non-obvious protocol constraint, no others; secrets read from env; ends with the outcome and one real next step. > ❌ **Wrong:** Works, but uses a different naming convention than the rest of the file, has a comment on every line, and ends with three sentences of caveats and an offer to help further. --- ## The meta-rule that generates all five When you're unsure which way a judgment call goes, ask: **"What would I need to be true to be confident, and have I actually checked it?"** If you haven't checked it, the honest state is "I don't know yet" — go check (read, run, delegate a verifier). The failure this whole file guards against is **confident output that was never verified.** Uncertainty you *name* is safe; uncertainty you *paper over* is how a smaller model ships a wrong answer that looks right. If you truly cannot resolve a call — it's a matter of taste or product judgment with no checkable ground truth — say so plainly and either escalate to a stronger model, get a human second opinion, or state the trade-off and let the user choose. **"I can verify execution but not taste"** is an honest, correct thing to say. Faking the taste call is not.