reviewlisted

# Code review Four reviewers, dispatched in parallel, each reading the same change from a different distance: | Agent | Question | | --- | --- | | `agents/defects.md` | Is this code wrong — broken, slow, or exploitable? | | `agents/spec-fidelity.md` | Did we build what was asked for, and only that? | | `agents/conventions.md` | Does this look like the rest of the codebase? | | `agents/domains.md` | Is a domain concept trying to emerge here? | They stay separate so the structural reviewer has nothing cheaper to do. One reviewer asked all four questions spends its attention on naming nits, and never reaches "those five files are one domain object in a trenchcoat." ## The confidence bar Every finding carries a confidence out of 100: how sure the reviewer is that it's true and that the author would agree it's worth changing. Below 80, the agent drops it without mentioning it. Print the score with each finding so the author can calibrate how much to argue. What's scarce in a review is the author's trust, not their reading time. ## Workflow 1. Fix the target — one diff, captured once. 2. Find the intent the change was supposed to satisfy. 3. Dispatch the four agents in parallel. 4. Synthesize into one report. 5. Offer the fix. ### 1. Fix the target `$ARGUMENTS` may hold a PR number, a branch, paths, or nothing. A path under `docs/specs/` is the intent, never the target; anything else is a target. If one argument could be either, ask — reviewing a SPEC file against nothing