Coordinate bounded multi-perspective code reviews

This skill coordinates a bounded code review. It reviews a defined diff or subsystem from several relevant perspectives, such as correctness, authorization and performance. It describes a review procedure only: it does not install an orchestration engine or prove compliance. It is a compatibility alias of error-debugging-multi-agent-review, so new references should use that ID unless an existing contract requires this one. The full instructions stay local so existing installations keep working offline, and the callable ID is preserved for existing manifests and client configurations.

Execution scope is set up front. Pin the repository, base and head, the changed paths, the intended behavior and the available tests. Use independent agents only if the user authorizes delegation and the host supports it, otherwise conduct the perspectives sequentially. Do not spawn agents merely because the callable ID contains "multi-agent". Read-only review is the default, and fixes, external posts and deployment stay within the user's actual task authority.

The review process has six steps:

• Read the complete diff and the directly affected call paths and tests.
• Choose only perspectives relevant to the change. Give each authorized reviewer a bounded question, owned paths, a time or effort limit and an expected evidence format.
• Record findings with exact locations, trigger, consequence and reproduction. Keep hypotheses separate from demonstrated failures, and do not invent confidence scores.
• Reproduce important findings centrally, and deduplicate by root cause and not by wording.
• Resolve disagreement through code or tests. Weighted votes and multiple agents repeating a claim are not evidence of correctness.
• Return blockers first, then material improvements and untested areas. Preserve the original failing result, because a rerun does not erase it.

A worked example is a tenant-scoped cache change. Review key construction, authorization context and invalidation, then reproduce two tenants requesting the same prompt and different prompt versions within one tenant. The expected result is a finding only if an actual cross-scope hit or stale result can occur, with the smallest case that shows it. A general style opinion must not be presented as a data-exposure defect.

Use it to review a defined change from more than one angle with evidence-backed findings. Do not expect bundled agent-routing code, a compliance validator or a quality-score calculator, because none is included. Parallel review adds cost and can duplicate blind spots. The procedure cannot prove whole-repository safety from a diff, and it cannot authorize production load tests or messages.

Input is the pinned diff or subsystem and the intended behavior. Output is a findings list ordered with blockers first, each with location, trigger, consequence and reproduction, followed by material improvements and untested areas.

Reviewers and teams that want structured, reproducible code review across correctness, authorization and performance without treating agent consensus as proof.