Read Your Own Diff
Makes the agent review the change as a stranger would, before it tells you the work is done.
When to reach for it
The moment before 'done' — after the code works, before you are asked to look at it or before it becomes a commit.
What changes
- The agent reads the complete diff line by line and reports what it found, rather than declaring success from memory of what it intended.
- Debug leftovers, commented-out code, stray print statements and unrelated formatting get removed before they reach you.
- Anything in the diff the request did not call for is named out loud, so scope creep is visible instead of bundled in.
- Problems get reported honestly, including the ones the agent introduced itself, instead of being quietly patched over.
- You get a short summary written from the diff rather than from the plan — including which part of the change is weakest.
Pairs with
- Accessibility PassCatches the accessibility failures generated interfaces produce almost every time.
- Spot the SlopNames the specific tells of generic machine-made code and design, so you can delete them.
- Taste CheckReviews generated interface against design criteria you can count, instead of "looks fine".
Read Your Own Diff
Before saying this is done, read the whole change as though someone else wrote it and you have to approve it.
1. Get the actual diff
Read every changed line, including the files you touched early and forgot about. Read the diff, not your memory of what you meant to do. Include new files in full, and the deleted lines, not only the additions.
2. Find what should not be there
Go through hunting specifically for:
- Debug output, temporary logging, a hard-coded value left from testing.
- Commented-out code, and TODOs with no owner and no condition.
- A changed file that has nothing to do with the task.
- Formatting or import reordering that is not part of the change.
- A dependency added and then not used.
- Secrets, tokens, machine-specific paths, real personal data in a fixture.
Take each one out.
3. Read it as a stranger
For each block of change, ask what a reviewer would ask:
- What does this do on empty, on null, on something enormous?
- Is anything renamed here and not renamed somewhere else?
- Does this new branch have a way to be reached, and a way back out?
- Did I change something shared, and did I look at its other callers?
- Would this be obvious in six months, or does it need one line of explanation?
4. Check it against what was asked
Read the original request again. Anything in the diff it does not call for gets named, and stays only if the user agrees — not because it seemed like an improvement while you were in there.
5. Report honestly
Three or four sentences: what changed, what you actually verified, and what you are unsure about. Name the weakest part of the change yourself.
Rules
- Do not skip this because the change is small. Small changes are where a stray edit hides best.
- Do not summarize the plan instead of the diff. Only the diff ships.
- Do not hide a flaw because reporting it makes the work look unfinished. It is unfinished either way; only one version wastes the user's afternoon.
- Do not fix new things you spot while reading. Note them, land this change, raise them separately.