Verification Is a Design Choice, Not a Promise

A workflow can have clear stages and still produce a wrong conclusion. This chapter examines how the official plugins try to reduce that risk through independent roles, confidence thresholds, adversarial challenges, coverage checks, and bounded patch review. The practical goal is to judge a verification claim by its mechanism: who checks the result, what evidence they see, what rule filters the output, and what the process admits it cannot establish.

The central distinction is between more model activity and more evidence. Launching several agents does not automatically make a finding true. Independent perspectives help only when they have distinct responsibilities, can challenge the same candidate, and feed into a decision rule that controls what reaches the user. The repository’s review and security plugins make this pattern visible, while their own limitations prevent it from being mistaken for a guarantee.

Independent perspectives reduce shared blind spots

The code-review and feature-dev plugins use specialized reviewers rather than asking one general agent to inspect everything at once. In code-review, different passes examine repository guidance, obvious bugs in the changed lines, historical context, previous pull-request discussions, and code comments. Feature-dev’s reviewers emphasize project conventions, functional correctness, and simplicity. Each role approaches the change with a different question and a different source of evidence.

That separation can reveal issues that a single perspective would miss. A reviewer focused on the diff may see a missing error path. A reviewer reading history may discover that an unusual condition is deliberate or that a previous fix established an important invariant. A reviewer checking CLAUDE.md can distinguish a project rule from a generic style preference. A reviewer focused on simplicity may identify a new abstraction that makes the change harder to maintain even when it works.

Independence is not the same as statistical independence. Agents can share the same model tendencies, incomplete context, or misleading repository assumptions. If every reviewer receives the same flawed summary, they may repeat the same omission. The mechanism is therefore best described as diversified scrutiny, not mathematical proof. The repository’s evidence supports the existence of distinct roles and review steps; it does not establish that their errors are uncorrelated or that more reviewers always improve precision.

A useful verification process also gives reviewers the right scope. Code-review instructs agents to focus on issues introduced by the pull request rather than reporting every pre-existing weakness. It asks reviewers to avoid nitpicks and issues that a compiler or linter will catch. This scope rule matters because a review can become less useful when it produces a long list of technically possible concerns that do not affect the change under discussion.