Reviewing with Peer Agents

Scope

Use this skill only after an explicit request for another model or agent's review. Treat named reviewers as requested identities, not interchangeable labels. If a requested reviewer is unavailable, disclose that limitation instead of silently substituting another model or presenting your own review as theirs.

Choose the available review mechanism at runtime from the current environment and project instructions. This skill defines no tool, command, API, transport, authentication flow, or output plumbing for requesting a review. If no suitable mechanism is available, stop and report that the requested independent review is unavailable in the current session.

Reviewers are read-only. They must not edit files or mutate external state while gathering independent findings. Resolution happens only after the primary agent verifies and normalizes their responses.

Establish the Review Contract

Establish the review boundary from the user's request and repository evidence rather than assuming a base branch or scope. Give each reviewer the target, work intent, constraints, requested focus, and a concise decision record. The decision record contains decisions made, supporting constraints or evidence, alternatives explicitly considered or rejected, and unresolved questions.

Use only observable rationale that can be shared as review context. Do not request or transmit private chain-of-thought, invent rationale that was not recorded, or expose unrelated sensitive context. Give reviewers access to the primary artifacts they need:

• In a shared workspace, identify the target and let the reviewer inspect the diff, files, tests, and project instructions directly.
• Without shared workspace access, provide the smallest sufficient source artifacts and state any missing context.
• Do not bias reviewers with another reviewer's conclusions, expected findings, or a proposed answer.