Code review

Reviews GitHub PRs by applying a panel of specialist review lenses to the diff, filtering for high-signal findings, and returning structured comments for the host to post.

Operating environment

This skill usually runs inside an automated review harness (e.g., Copilot Code Review). It assumes:

• The diff and PR context are already provided by the harness. In an interactive invocation without that context, use read-only git and gh commands to discover the current branch diff and PR metadata. Do not change branches or the worktree.
• No interactive user. No ask the user flows, no walkthroughs, no "want to proceed?" gates. The skill produces findings and returns them.
• No build or test execution. Test code is reviewed statically.
• The harness handles posting. The skill returns structured findings; the harness creates the review.
• Extension contract reviews use a companion skill. Keep extension-user-contract-review available alongside this skill when distributing it outside this repository.

If the host is interactive (e.g., a chat agent invoking the skill manually), the same workflow still works — interactive steps simply don't apply.

Workflow

Step 1: Read the diff and PR context

Use whatever PR metadata, diff, and changed-file list the harness provides. In an interactive invocation where these are missing, discover them with read-only git and gh commands. If supplementary context such as linked issues or prior review comments is available, use it.

Step 2: Mandatory extension contract pass

For any PR changing cli/azd/extensions/**, including fork PRs, you MUST load and apply the extension-user-contract-review skill and its full review procedure before the general review lenses. Do not make invocation depend on already recognizing a contract change. Inspect every changed extension file, track coverage and existing threads, and preserve its findings for shared triage. For command changes, trace base/head registrations to constructors and parent commands across files; track each public path separately so unrelated findings or constructor moves do not hide new commands. If the skill or required evidence is unavailable, report the contract pass as blocked rather than skipping it. Skip this pass only when the complete file list contains no extension changes.

If added files are under a top-level path in cli/azd/extensions/ that did not exist before the PR, also load new-extension.md and apply its onboarding review. An added extension.yaml is enough to trigger the new-extension review because a dependency-only extension pack may have no module or entry point.

Step 3: Apply review lenses

Load reviewers.md and apply each of the 9 fixed lenses to the diff. Then scan the changed files for the domain signals listed in reviewers.md and apply matching domain lenses. Each lens produces zero or more findings in the structured format defined in reviewers.md.

If the diff changes telemetry collection or declarations, read the privacy checklist's reviewer guidance and the maintainer's coverage decision in the PR. This applies even when filenames do not contain telemetry, such as changes to ReportUsage calls or fixed event values. Apply the Observability Expert checks from reviewers.md.

The reviewing agent is the same LLM — these lenses are perspectives to apply sequentially or in parallel, not separate subagents. The host may parallelize lens application if supported, but a single-pass application of all lenses to the same diff is equally valid.

Step 4: Triage findings

Load findings.md. Apply the self-reflection pass: drop low-signal findings according to the dismissal triggers, merge duplicates across lenses, group by file, and sort by line.

Step 5: Voice and format

Still in findings.md. Apply the voice rules to every finding's text. Build the review body (one sentence + optional bullets for non-line findings). Return the final findings in the format the harness expects.

Step 6: Mandatory contract completion audit

For extension PRs, reconcile the contract coverage ledger with the complete changed-file list, discovered command tree deltas, and actual outgoing comments. Every distinct in-scope addition or removal must have one inline comment or a matching existing thread. Do not drop contract comments to satisfy an ordinary finding budget. Expose the companion skill's completion status and counts in the review body or supported result channel. An incomplete pass must say blocked, not imply a clean review.

Principles

• Silence over noise. If a lens has nothing meaningful to say, it returns nothing. No invented concerns. Fewer, better comments is the goal.
• Codebase context matters. Review the change in context — read surrounding code, not just the diff. Cross-file logic errors are the most common real bugs.
• Independence. The reviewing agent builds its own understanding. It does not share assumptions with whatever generated the code.
• Findings must be useful. Critical, suggestion, and nit comments must give the author something specific to act on. Praise must name a concrete pattern worth preserving.

Bundled resources