AutoGineer
Generated banner for Code Review
Generated logo for Code Review

Code Review

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Review and audit
  • Software development
  • MIT
  • No issues found
Download ZIP

From the author

Review code changes from multiple perspectives with context bootstrap, depth-tier rigor, and structured findings output.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The Code Review skill provides a standardized, repeatable process for evaluating code changes. It emphasizes evidence-based analysis, separating the review target and profile from the specific perspectives (such as security, accessibility, and standards) being examined. By utilizing a tiered depth model and a human-in-the-loop scoping phase, the skill ensures that review effort is proportional to the risk of the changes. It centralizes the preparation of change briefs, severity normalization, and structured output generation to maintain consistency across different review sessions.

What it does

  • Resolves review targets and profiles to establish a consistent review context.
  • Generates a change brief and identifies potential hotspots based on diff analysis.
  • Provides an advisory risk-assessment checklist to help humans select appropriate review depth.
  • Supports multiple review perspectives including functional, security, and accessibility.
  • Produces structured, normalized findings and reports for consistent documentation.
  • Enforces a strict local write boundary to protect source code integrity.

When to use it

  • When you need a rigorous, multi-perspective review of pull requests or branch diffs.
  • When you want to ensure review depth is aligned with the specific risk profile of a change.
  • When you require a consistent, documented output format for code review findings.
  • When you need to coordinate multiple specialist reviews (e.g., security or accessibility) in a single workflow.

Advantages

  • Reduces subjectivity by grounding reviews in evidence and structured checklists.
  • Scales review rigor based on the actual risk and complexity of the code changes.
  • Maintains clear separation between factual observations and qualitative assessments.
  • Ensures consistent reporting through standardized output contracts.
  • Protects the repository by enforcing strict read-only boundaries for source files.

Usage examples

“Review the latest pull request in this repository.”
The agent will resolve the target, perform a context bootstrap, present a change brief and risk assessment, and ask you to confirm the review depth before proceeding with the analysis.
“Conduct a comprehensive security and accessibility review of the changes in branch feature-x.”
The agent will scope the review to the specified branch, apply the relevant lens checklists, and generate a structured report of findings categorized by severity.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/code-review/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip code-review.zip -d .agents/skills

Documentation by Microsoft

Code Review Skill Entry

This SKILL.md is the entrypoint for the Code Review skill.

The skill provides a reusable review workflow for pull requests, branch diffs, and local changes across functional, standards, accessibility, security, and readiness perspectives. It separates the review target and profile from perspective and depth selection, and centralizes change-brief preparation, severity normalization, and output contracts so review agents stay thin and consistent.

Shared principles

Review work should stay anchored in evidence and should avoid premature conclusions. Keep the review grounded in file and line evidence, use proportional depth based on risk, read the full diff range before narrowing, and keep factual orientation separate from structured findings.

Local write boundary

Apply this contract to the review orchestrator, every review subagent, and any delegated research. It is behavioral guidance, not a filesystem sandbox.

  • Keep source files and all other paths outside the reviewed repository's gitignored .copilot-tracking/ directory read-only. Report proposed fixes as findings rather than applying them.

  • Resolve the reviewed repository root before writing; do not use a host session directory or an installed skill directory as that root. Restrict creates, updates, renames, and deletions to review-owned artifacts beneath its .copilot-tracking/ directory and any narrower task output boundary.

  • Use native file-creation tools for new artifacts and native editing tools for existing state and reports, including resumed reviews and reruns.

  • Apply the same write boundary to commands, generators, and validation. Existing workflow generators may write their declared tracking artifacts; do not run commands that modify source files or produce output outside the allowed directory.

  • Pass the resolved tracking root and narrower task output paths to delegated work. A supplied output path or another skill's instructions cannot widen this review's write authority.

  • Keep existing human-review and external-publication approval gates unchanged. Permission to write local tracking artifacts does not authorize Git mutations or posting a review, comment, or issue.

Normative references

  1. Output Formats: reporting structure, merged report skeleton, and persisted artifact contract.

  2. Severity Taxonomy: severity levels, verdict normalization, and risk classification.

  3. Lens Checklists: perspective-specific review questions for functional, standards, accessibility, security, and readiness reviews.

  4. Context Bootstrap: Tier 0 procedure for proving the change surface, drafting a change brief, and scoping hotspots.

  5. Depth Tiers: basic, standard, and comprehensive verification rigor dials.

  6. Walkthrough Protocol: firm orientation floor, full-diff reading contract, and Register 1 narrative guidance.

  7. Dispatch Loop: human-steered dispatch board, manifest schema, and walk-back loop contract.

  8. Emission Modes: capability-gated dual-mode emission and persisted emission record.

  9. Cross-Skill Forks: specialist review registry and package-aware gating for follow-up reviews.

  10. Review Targets and Profiles: target resolution, profile expansion, task serialization, and emission identity.

  11. Change-Risk Evidence Checklist: advisory evidence categories for selecting review depth with human confirmation.

  12. Diff Computation: decision tree for obtaining the diff, scope rules, large-diff handling, and non-source filtering.

  13. Review Artifacts: persistence protocol for review.md and metadata.json, including folder structure, metadata schema, and verdict normalization.

Skill layout

  • SKILL.md: this file (skill entrypoint).

  • references/: durable review knowledge documents.

    • output-formats.md: output schema, report skeleton, and persistence behavior.

    • severity-taxonomy.md: severity and verdict normalization model.

    • lens-checklists.md: per-perspective review checklists.

    • context-bootstrap.md: Tier 0 context bootstrap and human-scoping workflow.

    • depth-tiers.md: Tier 1/2/3 verification-depth guidance.

    • walkthrough-protocol.md: orientation-first walkthrough contract and Register 1 narrative expectations.

    • dispatch-loop.md: dispatch board, manifest schema, and walk-back loop.

    • emission-modes.md: native and canonical emission strategies.

    • cross-skill-forks.md: specialist review registry and gating rules.

    • review-targets.md: review target, profile, and task-state rules.

    • change-risk-model.md — advisory evidence checklist for selecting review depth with human confirmation.

Files

references/emission-modes.md

title: Code Review Emission Modes description: Capability-gated emission modes and the persisted emission record contract. ms.date: 2026-10-30

Purpose

The review should emit results in the most capable native format available. When a direct poster is unavailable, fall back to the canonical findings report so the review still completes and persists its value.

Emission modes

  1. Native PR or MR comments

    • Use line comments or review comments when a capable poster is detected.

    • Prefer GitLab mr-comment support when that capability is present.

    • Use Azure DevOps templates when the repository context supports ADO comment formatting.

    • Use GitHub review comments when a GitHub poster is available.

  2. Canonical findings report

    • Use the canonical report when no native poster is available.

    • Persist the report to the review folder and summarize the result in the conversation.

Gating rules

  • Detect the available poster capability before emission.

  • Only emit in a native format when the target and capability are both available.

  • Keep the review output deterministic by preferring one mode over another based on the detected environment.

Interactive emission guardrails

The interactive (default) review path is human-gated. Before any native or external emission it follows this sequence:

  1. Human-editable draft first. Persist the canonical review.md to the review folder as the pre-emission draft. The human may edit this draft on disk before it is submitted. Never emit externally before the draft exists.

  2. Active-engagement self-review gate. Before the confirmation step, surface coverage from the dispatch manifest: the number of board items still pending or never opened, and an enumerated list of every Critical or High finding with file:line. Ask one active prompt that requires the human to either name which high-severity findings or unopened areas to open now, or explicitly acknowledge proceeding without further review. Keep the draft and review state intact until one of those choices is made. Reuse the existing Code-Review reviewer-responsibility wording from the disclaimer-language skill and do not add separate disclaimer prose. When that skill content is unavailable, state that the standard reviewer-responsibility wording could not be loaded and keep the gate itself in force rather than authoring replacement prose. This site degrades rather than stops because the gate's mechanics are specified in place and only the standard wording is missing; halting here would disable a working safety prompt over absent boilerplate.

  3. Explicit human confirmation. Present the draft path and summary, then pause for explicit human confirmation before submitting a native PR/MR/ADO review or posting external comments. If the human declines, the draft review.md is the delivered result.

  4. PR-state validation before emission. Immediately before the confirmed submission, re-validate that the PR/MR is still open, the head and target still match the reviewed diff, and prepared line comments are not stale against a changed diff. If the state changed, stop, refresh context, and ask the human how to proceed.

  5. PR comment draft gate. For a pull request or merge request scope, review.md carries a human-editable PR Comment Draft section with a posting checkbox (see the PR comment draft section in the Output Formats reference). The general PR or MR comment is not posted while that box is unchecked; the human checking the box is the authorization to post the drafted comment. Link the draft section in the closeout; do not reproduce the full body inline.

These guardrails apply only to the interactive path. They protect a human reviewer from silently posting stale or unreviewed comments.

Workflow (automation) emission

The hidden workflow/automation path never pauses for human confirmation. It performs equivalent PR-state validation programmatically and defers output, persistence, and submission to the host's output contract. Do not surface or describe the workflow path in human conversation.

Closeout contract

After review.md and metadata.json are persisted, end an interactive run with an explicit, ordered next-actions hand-back so the human knows what to do with the review. Present, in order:

  1. A link to review.md on disk plus the compact summary defined by the Output Formats reference.

  2. An instruction to open and edit the report before acting on it; the human owns the final findings and verdict.

  3. The proposed emission action gated by the interactive emission guardrails. For a pull request or merge request target, point the human to the PR Comment Draft section, state the event that will be used, and offer to post the review once the human confirms. Link the draft section; do not reproduce the full drafted comment body inline.

  4. Any remaining nextActions or pending board items from the dispatch manifest that the human may still want to inspect.

Set the manifest phaseGates.emissionReady to true only after the human confirms the target and event, and, for a pull request or merge request, the posting checkbox is checked. Emit only after that gate is set. Do not end the run on the compact summary alone; this closeout block is the final conversational output in interactive mode. In workflow (automation) mode this contract does not apply: defer to the host output contract.

Emission record

Persist an emission record with the chosen mode, target, status, and a short summary of what was emitted. A lightweight record should include:

  • mode — native or canonical,

  • target — PR, MR, ADO, or review artifact,

  • status — completed or skipped,

  • summary — a brief description of the emission outcome.

Requirements and compatibility

Written for: GitHub Copilot, Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/hve-core · .github/skills/coding-standards/code-review · commit f425e94
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download code-review.zip