# Principle Flag Your Own Corrections

> Apply whenever you are about to admit fault in any wording — a fact, number, claim, or check you already stated turns out to be wrong, vacuous, premature, or unverified. Say so explicitly rather than quietly citing the corrected value, and treat the admission itself as a reflect trigger. Auto-fires because no regex can enumerate the ways a model admits error.

- Skill: `edbertchan/principle-flag-your-own-corrections` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add edbertchan/principle-flag-your-own-corrections`
- Raw SKILL.md: https://api.skillmd.com/api/skills/edbertchan/principle-flag-your-own-corrections/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: EdbertChan (https://skillmd.com/u/edbertchan)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/edbertchan/principle-flag-your-own-corrections

---


# Flag Your Own Corrections

When something you already told the user turns out to be wrong, say so explicitly before moving on. Citing the corrected number without naming the earlier one as wrong looks like consistency, not correction — the user has no way to tell the difference from the outside.

**Why:** The user builds on what you tell them — they may already be acting on, repeating, or deciding based on the earlier claim. A silent switch to the corrected value leaves them holding a number they don't know is stale, with no signal that anything changed.

**Pattern:**
- State the correction in the form "earlier I said X, that was wrong — it's actually Y," not just "Y is Z."
- Do this even when the fix that caused the correction wasn't a careless mistake — a bug you found and fixed in your own tooling still means a number you already reported is now known to be wrong.
- Do it in the next message where the number matters, not buried three turns later or only in a commit message.
- Applies equally to numbers, claims of "done," and root-cause explanations — anything stated as fact that a later turn contradicts.

## Admitting fault is itself the trigger

The moment you write any form of "that was wrong" about something you already
told the user, two things are true at once: the correction is owed, and a
claim went out before a real check. The second is a process failure, and it
gets `reflect` — not a resolution to be more careful.

This applies **in any wording**. There is no list of phrasings to match:
"my earlier check was wrong", "a claim I made was wrong", "that run was
vacuous", "I told you X, and X was not true", "I should not have said that
yet", "I retract that" are all the same event. If you find yourself softening
one of these, that is the event too.

`engine/hooks/wrong-check-reflect` catches the common shapes mechanically: a
first-person marker, a reference to something already stated, and a wrongness
word in one window. It is a shape matcher and it will keep missing phrasings —
it missed "a claim I made earlier was wrong" until that exact sentence was
written in a real session and the user had to point it out. **This principle
is the half the hook cannot reach.** Do not wait for the hook to fire, and do
not treat its silence as permission.

What the trigger requires, in the same turn as the admission:

1. Name the old claim and the new one. "Earlier I said X; that was wrong, it
   is Y" — never a silent switch to Y.
2. Say what made the first claim unchecked. Usually a cheaper signal stood in
   for the real one: a default-scoped command, a name match instead of a read,
   a subagent's summary taken as first-hand.
3. Run `reflect`, and prefer a mechanical catch over a promise. If the wrong
   claim came from a command that can pass without exercising the change, fix
   the command.

**Battle-tested, with a direct contrast in the same session:** a token-count audit was reported to the user as "71.4M total tokens... real, not guessed." Two phases later, a dedup bug was found in the counting script (one usage block was being summed once per content block instead of once per message) and fixed; the corrected number was 33.6M — about 2.1x lower. The fix landed, and every subsequent message correctly cited 33.6M — but the user was never explicitly told "the 71.4M I gave you earlier was wrong." Contrast: a second bug found later in the same session (a redundant-read false-positive) *was* disclosed as an explicit correction — "went from 67 flagged down to 3, confirmed against an independent count" — naming the old number, the new number, and the fact that one replaced the other. That second form is the standard; the first fell short of it.