awesome-code-review-jury
Code Review Jury
Several reviewers read the same change on their own, none of them sees the others, and a judge who never touches the code turns their reports into one verdict, asking them follow-up questions wherever they disagree. Everything runs on the subagents the host agent can already spawn; nothing gets installed.
Why this matters: the agent that wrote a change is the worst-placed party to review it. Four ways to check agent-written code, each catching more than the last:
- Same session, same model. The agent rereads its own code. It has already decided the code is correct, and a second reading does not change that decision.
- New session, same model. Clean context, same training and habits. It accepts the mistakes it would have made itself.
- One different model. It finds real bugs, but now there are two opinions, and when they disagree the user has to decide.
- A jury. Several isolated reviewers on different models get the same task; a judge reads all the reports, cross-examines the disputed points and writes one answer. Agreement means independent checks converged; a split is settled by the judge, not handed to the user.
The published evidence behind each choice (self-correction without outside feedback, sycophancy, correlated errors between similar models, aggregation, cross-examination) is summarised in references/evidence.md. Load it when someone asks why the procedure is shaped this way, or before changing a rule below.
The design follows Rejudge, which runs the same panel-and-judge process as a standalone engine. This skill keeps its rules and replaces the engine with the host's own subagents.