Defaults and sources
Rewriting one cautious sentence changed more than a pile of exceptions. A few standing defaults about how to act matter most.
This is the update edition. If you’ve read Mastering Claude Code and you’re back to catch up, this is the diff: just what changed this week, so you don’t have to go through the whole guide again. There are two changes worth your attention.
The default got rewritten
Start with the one that matters most, because it’s the follow-through on the previous update.
Last time, the lesson was a failure mode called the defensive-rule pileup. Every time the assistant does something you don’t like, the natural move is to write a feedback rule saying “don’t do that.” Each rule is reasonable on its own. But they accumulate, and they all point the same way, toward caution, until the assistant opens every task already half-paralysed, asking permission to breathe. The tell is the carve-out: when a new rule has to say “for this kind of work, go ahead without asking,” it’s quietly admitting the default has grown too cautious.
Naming that was the previous update. This update is what happened next: the default was actually rewritten. It went from “read and report; ask before acting” to “act when the work is authorised; ask only when a step is hard to reverse, undecided, or touches shared infrastructure.” Two clauses. The interesting part is the size of the effect against the size of the change. An assistant that had been pausing at every step to confirm started driving work to completion, and the shift took inside a single session. The lesson is easy to misread as “audit your feedback files.” The real lever is narrower: rewrite the one sentence all those files are carving exceptions from.
The behavioural defaults worth setting
That rewrite pointed at something bigger. The standing instructions that earn their keep aren’t facts about your project at all. They’re a handful of instructions about how you want the assistant to behave. And because they shape every task instead of one, they matter more than any single project detail. Chapter one now names five of them.
Act when the work is authorised, and ask first only when a step is hard to reverse, genuinely undecided, or touches shared infrastructure. Stay in lane: do the thing you asked, and treat a side-comment as a side-comment, not a licence to start a new project. Search before asking: look in memory and in the files for a missing detail before asking you to supply what’s already on disk. Calibrate confidence: label what hasn’t been verified, flag risks up front, and don’t fold the moment you push back if the assistant is actually right. And evidence before “done”: don’t report a thing fixed until the symptom has actually been checked.
The discipline note matters as much as the list. Keep it short, and phrase each one as what to do. A pile of “never do that” instructions produces exactly the assistant that asks permission to breathe, which is the pileup all over again.
Memory needs a source
The second change is a new failure mode in the memory chapter, and it’s a quiet one: memory without provenance. Every fact in the store should trace back to where it came from: something you said, a document on disk, or a decision the two of you made together. The hazard is the unsourced guess. The assistant meets a gap, fills it with something plausible, writes it down, and from then on every piece of work that draws on memory treats the guess as established fact. A fabricated detail doesn’t sit still. It propagates through everything derived from it. So cite the source on each entry, and mark anything inferred as inferred. This bites hardest with anything written in your own voice: a single invented biographical detail, once in memory, will resurface in letters and documents you never thought to check.
That’s the week. As always, the full written guide, with tables, diagrams, and the copy-paste prompt for spinning up a fresh assistant that already knows all of this, lives at claude-guide.sauer.com.au. Share it with anyone who’d find it useful.
The cards
