Reviews and fixing what they find

Ask "review my changes", "review my last 3 commits", "review this branch" or "review PR #42" and zerd runs a full pipeline modeled on how a careful human team reviews.

• Scope is stated. The answer says what was reviewed, how many commits, and every fallback taken. A PR is diffed against the branch it merges into (from gh, not assumed to be main), after fetching that base so a stale local copy doesn't drag in other people's commits.
• Lenses. Behaviour, approach, failures, project rules, history, security and a dedicated producer/consumer contracts reviewer. By default one reviewer works through every angle with a bigger budget; set review_lenses = N for N separate specialists.
• Review memory. A claim the verifier refuted, or you called wrong, is remembered per repo for two weeks and shown to the next reviewers as "already ruled out". Code that changed since then reopens it.
• Alternate reviewer. A review can run as a headless claude -p session on your own Claude login, with read-only tools.

FixingCopy Anchor Link

Say "fix them", "fix 2 and 3" or "review and fix", and the fix run starts from the facts the review already proved (not a vague "fix the issues"):

The verifier never saw the author's reasoning, so it can't inherit its blind spots. It diffs the change against what the author claimed, triggers each finding, checks that the added test fails without the fix, and runs checks and edge cases. A FAIL goes back to the author.