azd-code-reviewer

name	azd-code-reviewer
description	Reviews GitHub pull requests by applying multiple specialist lenses (security, Go expert, architect, testing, UX, docs, PM, Azure, novice customer), triaging findings for signal-to-noise, and returning structured inline comments. Use for: review PR, look at this PR, give feedback on PR, check this PR, code review, PR feedback.
license	MIT
metadata	{"version":"1.1"}

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.

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: Detect review cases

If added files are under a top-level path in cli/azd/extensions/ that did not exist before the PR, 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.

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.

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

File	Contents
reviewers.md	9 fixed lens definitions, dynamic domain detection rules, shared ground rules, findings format
findings.md	Self-reflection triage, dismissal triggers, merge/dedup, voice rules, review body guidance
new-extension.md	New first-party extension scaffolding, repository wiring, release, and handoff checks