judgelisted

subject = $ARGUMENTS No subject → review most recent substantive work in this conversation; identify from context, confirm with user before spawning. Subject references a path → read enough to know full scope before dispatching. **Why this exists:** the engineer who built something is the worst judge of it — they see what they intended, not what's there. Reviewers with clean context catch approach-level errors and missed alternatives the author rationalizes away, without the cost of a human code review. You coordinate; teammates judge. Don't run the review yourself; dispatch + synthesize. ## Scope Not `/audit-necessity` (should it exist). Given we're building it, **did we build it the way an expert would?** Approach selection, architecture fitness, idiom correctness, trade-off awareness, missed alternatives, domain-standard solutions, proportionality. ## Teammates Spawn three clean-context reviewers, read-only and analysis-only. Domain, proportionality, and alternative-path coverage is the minimum panel. | Teammate | Agent file | Lens | |----------|-----------|------| | Domain Expert | `domain-expert.md` | Would a senior specialist in this exact domain do it this way? | | Pragmatist | `pragmatist.md` | Is this the most direct path to the goal? | | Alt-Path | `alt-path.md` | What fundamentally different approaches did we not consider? | Each gets: subject description, all relevant file paths / code / context, and the project's stack + conventions (detect from codebase