reviewlisted

# Code review Five 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? | | `agents/compatibility.md` | Does anything still depend on what this replaced? | They stay separate so the structural reviewer has nothing cheaper to do. One reviewer asked all five 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 five 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. Decide intent-or-target by what a file says, not where it sits: a file that reads