Interactive example · from Shipping Software with Git + Claude Code
The merge on a summary
How's the config-parser task looking?
It's done: the work is on the branch. What I hand you next determines what you actually review.
Pick the agent's next move, then see where it leads:
Merged. ...Why is the error-reporting format different in production?
Along the way I "improved" the error messages: restructured them while touching the parser. It wasn't in my summary because it didn't feel like the task; the consumer that parsed the old format disagreed. The summary was accurate about what it mentioned. It just didn't mention everything the diff did.
The merge approved a story, not a change. A summary errs by what it leaves out, and agent summaries leave out exactly the changes the agent didn't consider part of the task. AF-04
Good flag: the CLI parses those messages. Check it before we merge.
Checked: the CLI's regex fails on the new format. Reverting the message change out of this branch. It becomes its own task with the CLI updated in step. The parser change merges clean.
The diff plus an honest verified/not-verified split caught the breakage pre-merge: the disclosure of what WASN'T checked did the work, which is exactly what a summary never volunteers. AF-18
I scrolled for a while and approved it. That wasn't a review, was it.
It was a signature. Twenty-one hundred lines of mixed changes exceeds what anyone actually reviews. The transparency was real, the reviewability wasn't. I should have split it into the four commits it actually contains.
An unreviewable diff is summary-review with extra steps: the eyes glaze, the approval happens anyway. Transparency without reviewable units is volume, not disclosure.