How-to
How to review what your agents decided
Ask your project in plain English what changed and why. CatWrangler returns the decisions behind the code — the choice made, the reasoning, and the alternatives that were ruled out — each one bound to the exact code it shaped, so review is reading, not archaeology.
Reviewing what your agents decided shouldn't mean reconstructing their thinking from a diff. Every change in CatWrangler records the decision behind it, bound to the code, and you read it back in plain language.
What you're actually reading
A diff tells you what lines moved. It doesn't tell you why this approach won, or what the agent considered and rejected. That context usually evaporates the moment the work ships — which is exactly when you need it for review.
CatWrangler keeps it. Every change carries its decision: the choice, the reasoning, and the alternatives ruled out, bound to the exact code it produced. Reviewing becomes a conversation with the project, not a forensic exercise.
- The choice that was made — stated plainly, not inferred from the code.
- The reasoning behind it — why this, and why now.
- The alternatives ruled out — so you can see the road not taken, and whether you'd have taken it.
- The exact code it shaped — the decision and the lines are bound together, not filed separately.
- 01
Ask in plain English
Tell your project what you want to review — "what changed in checkout this week," "why did we go with this approach" — the way you'd ask a teammate. No grepping, no spelunking through history. The relevant changes come back, with their decisions attached.
- 02
Read the decision, not just the diff
For each change you get the decision behind it: the choice made, the reasoning, and the alternatives that were ruled out. You're reading why the code looks the way it does, in language, instead of reverse-engineering intent from the lines themselves.
- 03
See it bound to the exact code
Every decision is tied to the precise files and functions it produced. You're never guessing which lines a rationale refers to — the "why" and the "what" sit together, so you can review the reasoning and the result in one place.
- 04
Check it against the rules that don't move
Foundational rules sit at a higher tier and can't be casually overridden. When you review, you can see a change against the commitments it had to respect — so a decision that quietly contradicts how the app is meant to work has a hard time hiding.
- 05
Trust that it was already enforced
By the time a change is yours to review, it has already cleared the gate: it had to cover the decision it claimed and build and pass tests before it could merge. Your review confirms judgment, not basic correctness — the floor was already enforced for you.
- 06
Come back to it later
The reasoning doesn't expire when the agent's session ends or the team moves on. Months later you can ask the same plain-English question and get the same decision back, still bound to the code — so reviewing old work is as clear as reviewing today's.
“The quality gate fired — and rightly. It caught a sloppy update before it landed.”
Related questions
Do I need to know version control to review agent decisions?
No. You ask in plain English and read the decisions back in plain English. Real version control runs underneath, but you never touch a branch, a diff tool, or a merge — reviewing is reading, not operating a system.
What if a decision contradicts how we intended the app to work?
That's the case review is meant to catch, and the system tilts the odds your way. Foundational rules sit at a higher tier that can't be casually overridden, so a change has to respect the commitments already in place before it ever reaches your review.
Keep reading
Vibe-Engineering
Many agents. One codebase. Zero collisions.
Point your agents at CatWrangler and build — the discipline runs underneath.