base tune, finds the corrections nobody filed and the rules that need merging, splitting or retiring.
How base notices a correction
Four checks, and no one of them decides.- Your wording. Each prompt after a session’s first is checked for a phrase from
[corrections] phrases, as whole words with case ignored: “no,”, “wrong”, “that’s not”, “not what i asked”, “i told you”, “again”, “stop doing”, “why did you”, swearing, and the rest of the list. - What you did. You stopped a turn with Esc, refused a tool call, changed a file the AI had just written, or sent nearly the same request twice in a row.
- The AI’s own marker at the start of a line of its reply:
CORRECTED:,UPDATED:,MISREAD:orDEFERRED:([corrections] markers). A marker in backticks, in a code block or in the middle of a line is a quote and does not count. - The question. When your wording suggests a correction, that prompt carries one line; when what you did does, your next prompt carries it:
DEFERRED: marker means the AI held its position. It is logged and never proposed, because a disagreement is not a rule.
The CORRECTED line
base install and base scaffold offer once to add one line to ~/.claude/CLAUDE.md, just above the BASE CLI section:
base install --corrections-line adds it and base install --no-corrections-line does not. If you said no, or were never asked, session start carries the same line once per session instead, unless a CLAUDE.md the session loads already asks for one of the markers. base uninstall removes it with the BASE CLI section.
Turning a correction into a proposal
--from-turn reads the session’s own transcript: the last prompt you typed, the AI’s marker line and the signals of that turn. It compares the correction with every rule and decision base holds and sorts it three ways:
The prompt you typed becomes the proposal’s first test prompt, so the change has to serve it.
--rule, --decision or --new overrides the sort, and running it again for the same turn replaces that turn’s proposal. Nothing changes until the proposal is approved.
Reviewing proposals
Session start shows the count when any are waiting:base rule review walks the pending proposals with one key each: a approve, e edit, r reject, s skip, q stop. Each shows the prompts behind it and its replay. A rejected proposal is never made again.
Check before you approve. base rule replay runs a change over your recent prompts in the match log (the last 500 by default) and shows which prompts would start or stop serving the rule, and its share of all of them:
[tune] broad_share) is flagged TOO BROAD, and approving it needs --broad-ok.
The rule pass: base tune
base tune reads what your sessions did since the last pass and writes proposals for base rule review. It applies nothing. For each session it reads the transcript past the turns the last pass judged and makes one call to headless Claude on Haiku, which says which prompts corrected the AI, the one-sentence rule that would have prevented each, and which domain a prompt that matched nothing belongs to. Answers are cached, so a rerun on the same turns makes no call, and --max-calls (10 by default) caps a pass. --dry-run shows what it would read and how many calls it would make, and calls nothing.
Once a day, or with --store, one more call reads the match log for rules to merge, rules to split and keywords to drop. A rule nothing served in 30 days, that the pass has known for 30 days, is proposed for retirement with no call.
You do not have to remember it. No hook ever runs it, because it spends model calls and can take minutes. After [tune] corrections (3) flagged corrections, or after [tune] turns (15) prompts without a pass when one was corrected or matched nothing, the next prompt carries a line saying a pass is due. Session start says when earlier sessions ended with corrections not yet passed.
What each kind of proposal changes
base rule unretire <domain>.<id> serves a retired rule again. A rule written in domains.toml moves to the graph first when a proposal changes it, and the output says so.
Trying a matcher in the shadows
base shadow report shows where the two differ, and whether the corrections that followed favour the candidate.
A candidate promotes itself at session start once it has run on at least 200 prompts and its wins are at least three times its losses. After a promotion base watches the next 100 prompts and rolls back if corrections rise clearly. Both are announced once, with the command that undoes them. [shadow] auto_promote = false leaves promotion to base shadow promote. base rule update <rule> --protected marks a rule so that a candidate which loses it is never promoted automatically. Nothing runs until you start a shadow.
Seeing what it read
base log corrections prints this session’s, --session another’s, and --transcript runs the same checks over a whole transcript, turn by turn. [corrections] enabled = false turns all of it off.
Next
Rules and domains
Writing a rule that reaches Claude, and its test prompts.
Context reference
Every rule, log, tune and shadow command, with its flags.