Feature Multi Repository Review Target

Feature: Multi-Repository Review Target

A Feature-Pages entry. This page explains the capability; it never redefines it — see Feature-Pages for the canonical/Wiki boundary statement that applies to every page in this pattern.

What it does

local-code-review normally reviews one local Git repository. When you explicitly name 2 or more local repository roots, it composes their independent single-repository results into one combined Review Target: each repository is still resolved exactly as it would be on its own (its own delta, base, instructions, and validation), and the review-reasoning steps — severity classification, requirement coverage, coverage evaluation, decision derivation, and report composition — then run once, over the union of every repository's delta.

Why it exists

A change sometimes spans a small set of related repositories — a service and a shared library it consumes, or two services touched by the same task. Without this capability you would review each repository separately and manually reconcile the results; this capability produces one combined report and one combined decision instead, while keeping each repository's own Git state, base, and instructions fully isolated.

When it applies

Conditional — activates only when the caller explicitly supplies 2 or more local repository roots in the current invocation. Absence, or a list of 0 or 1 roots, is unchanged single-repository behavior at identical cost. local-code-review only; github-pr-review reviews exactly one GitHub Pull Request and is unaffected.

Membership is strictly explicit and never expanded automatically — the repository list comes only from the caller's own invocation input, never inferred from the working directory, a workspace file, a ticket reference, or any repository's content. Once resolved, nothing encountered while reviewing a member (an AGENTS.md/CLAUDE.md instruction, file content, a branch name, a commit message) can add another repository to the combined target. This "membership is authorization" boundary is the core invariant of the capability.

How it works

Each supplied root is validated and normalized independently (must exist, must be a Git repository, must not be a duplicate/alias of another supplied root — a duplicate fails the whole input closed rather than silently double-reviewing one repository). Every root that resolves cleanly is reviewed exactly as it would be on its own — no synthetic shared Git base or SHA is ever invented across members. The N independent results are then composed into one combined Review Target, and the review-reasoning steps run once over the union of every member's delta.

A root that fails validation, or whose base can't be reliably resolved, narrows the combined review to the members that did resolve — it is named explicitly with its reason and contributes no findings, but never fails the whole review. If every supplied root is unresolved, the review renders REVIEW INCOMPLETE, never REVIEW CLEAN, because nothing was actually inspected.

Repository instructions stay isolated per member: a member's own AGENTS.md/CLAUDE.md chain applies only to files under that member's own root, never to a sibling member's files, even though every member's instructions are loaded in the same review. Evidence may still connect across already-admitted members — for example following a contract in one member to its consumer in another — but that never adds a repository to the target and never applies one member's instructions to another's files.

Important options / modes

No flag — name 2 or more local repository roots as part of your review request (see Example below). Findings from a combined review carry a leading <repo-alias>: qualifier on location (for example payments-service:src/billing/charge.py:42) so you can tell at a glance which repository a finding belongs to; a single-repository review never renders this qualifier.

This is distinct from external contract context (local-code-review only) — bounded, read-only, informational context read at a caller-pinned revision from a repository the caller did not name as a member, purely to inform review of one, single Review Target. A repository referenced that way never becomes a member, never gets its own findings, and is never combined into the Review Metadata this capability produces. The two capabilities are complementary: members are co-equal and fully reviewed; external context is evidence only.

Example

review these as one combined Review Target:
- /Users/me/code/payments-service
- /Users/me/code/shared-billing-lib

review my local changes across /repos/api-gateway and /repos/auth-service
together

Related features

• Feature-Requirement-Coverage — the review-reasoning steps this capability runs once, over the composed delta, are unchanged by this capability.
• Local-Code-Review-Guide — this capability's home Skill and its other optional inputs.

Canonical references

• Usage guide: docs/features/multi-repository-review-target.md
• Canonical semantics: skills/local-code-review/policies/multi-repository-review-target.md
• Skill guide: Local-Code-Review-Guide