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

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/review-artifacts.md


description: "Code review artifact persistence: folder structure, metadata schema, verdict normalization, and writing rules"

<!-- markdownlint-disable-file -->

Review Artifacts Persistence Protocol

Any code review agent that produces a structured verdict follows this protocol to enable CI integration and cross-agent artifact compatibility.

Folder Structure

.copilot-tracking/
  reviews/
    code-reviews/
      <sanitized-branch>/
        review.md              # full markdown review output
        metadata.json          # machine-readable summary (see schema below)
        diff-state.json         # shared subagent input (branch, base, files, depth)
        dispatch-manifest.json  # canonical loop state (phase gates, next actions, board items)
        dispatch-board.md       # human-readable enumerated dispatch board
        walkthrough.md          # factual Register 1 orientation narrative
        emission-record.json    # selected emission mode, target, status, outcome
        explanations/
          <board-item>-<symbol>.md   # per-item Register 1 explanation artifacts
        walkback/
          <board-item>-research.md   # per-item Register 2 investigation artifacts

Sanitize the branch name by replacing every / with - (e.g. feat/my-feature → feat-my-feature).

The review.md, metadata.json, diff-state.json, and dispatch-manifest.json artifacts are always produced. The orientation-first artifacts (dispatch-board.md, walkthrough.md, explanations/, walkback/, and emission-record.json) are produced only when the review runs in interactive orientation-first mode; omit them in non-interactive workflow runs.

metadata.json Schema

{
  "schema_version": "1",
  "branch": "<original branch name, e.g. feat/my-feature>",
  "head_commit": "<full SHA of HEAD at time of review>",
  "reviewed_at": "<ISO 8601 UTC timestamp, e.g. 2026-02-27T10:00:00Z>",
  "verdict": "<normalized verdict - see table below>",
  "files_changed": ["<workspace-relative paths of source files in the diff>"],
  "findings_count": {
    "critical": 0,
    "high": 0,
    "medium": 0,
    "low": 0
  },
  "reviewer": "<agent or prompt name, e.g. code-review>",
  "artifacts": {
    "dispatch_manifest": "dispatch-manifest.json",
    "dispatch_board": "dispatch-board.md",
    "walkthrough": "walkthrough.md",
    "emission_record": "emission-record.json",
    "explanations": ["explanations/<board-item>-<symbol>.md"],
    "walkbacks": ["walkback/<board-item>-research.md"]
  }
}

The artifacts object records the orientation-first artifacts produced during the review. Omit any key whose artifact was not produced (for example, omit artifacts entirely for a non-interactive workflow run, or omit explanations when no per-item explanation was requested). The explanations and walkbacks values are arrays of review-folder-relative paths, one entry per board item that was explained or investigated.

Verdict Normalization

Agent Output Verdictverdict value
✅ Approveapprove
💬 Approve with commentsapprove_with_comments
❌ Request changesrequest_changes

Orientation-First Artifacts

Interactive orientation-first reviews persist the following artifacts alongside review.md and metadata.json. Each is referenced from review.md so the markdown report links to the supporting evidence.

  • dispatch-manifest.json — the canonical loop state: phaseGates, currentPhase, nextActions, and boardItems. This is the machine-readable source of truth for the human-steered walk-back loop.

  • dispatch-board.md — the human-readable enumerated board rendered from the manifest boardItems: id, area, status, register, summary, openable links, and selectable symbols.

  • walkthrough.md — the factual Register 1 orientation narrative (diff summary, runway summary, and appendices) presented before any findings register. It contains no severity grades or verdicts.

  • explanations/<board-item>-<symbol>.md — per-item Register 1 explanation artifacts written by the explainer when a human asks a shallow factual question about a symbol. Each includes the answer, source file reference, relevant code excerpt, and follow-on symbols.

  • walkback/<board-item>-research.md — per-item Register 2 investigation artifacts written by the walk-back researcher when a human asks a deep investigative question. Each is anchored to its board item.

  • emission-record.json — the selected emission mode (native or canonical), target (PR, MR, ADO, or review artifact), status (completed or skipped), and a short outcome summary.

Change-Risk Decision State

diff-state.json is the canonical owner of the evidence and depth decision used by every review lane:

  • reviewStateProvenance records human-confirmed or automation-derived origins for scope, changeRiskEvidence, recommendedDepth, depthTier, and depthRationale. It describes origin, not confidence.

  • changeRiskEvidence contains exactly one entry for each of change-scope, path-criticality, history, test-presence, coverage, and rollback.

  • Each entry contains signal, availability, and evidence. The availability field records the evidence state, not confidence in a claim. Its value is observed, unavailable, or qualitative; unavailable inputs remain explicit and are never fabricated.

  • recommendedDepth records the advisory basic, standard, or comprehensive recommendation. Use standard when evidence is incomplete or inconclusive unless observed evidence supports comprehensive review.

  • In interactive mode, existing depthTier remains the human-selected verification depth, and depthRationale explains that selection and any difference from recommendedDepth. Mark scope, evidence, depth, and rationale as human-confirmed; keep the advisory recommendation automation-derived.

  • In workflow mode, mark all five provenance values automation-derived. Host-supplied or default values are not represented as human-confirmed.

In interactive mode, write these values after human scope and depth confirmation. In workflow mode, write them after automated context preparation. Complete either write before perspective dispatch. Subagents consume the values and provenance as shared context but do not recalculate or overwrite them.

Writing Rules

  • Always overwrite any existing review.md and metadata.json for the branch: only the latest review per branch is retained.

  • Obtain the HEAD commit SHA with git rev-parse HEAD immediately before writing artifacts.

  • Obtain the current UTC timestamp immediately before writing artifacts:

    • In POSIX-compatible shells, use date -u +%Y-%m-%dT%H:%M:%SZ.

    • In PowerShell, use Get-Date -AsUtc -Format "yyyy-MM-ddTHH:mm:ssZ".

  • files_changed must list only source files present in the diff (additions, modifications, or deletions). Filter by relevance - e.g. .py, .sh, .ts, .tf - excluding lock files, binaries, and build output.

  • Do not write artifacts if the diff was empty and the review was aborted.

  • The reviewer field must use the kebab-case form of the agent's or prompt's name from its frontmatter (e.g. Code Review → code-review).

  • Write orientation-first artifacts only when the review runs in interactive orientation-first mode; record each produced artifact under the artifacts key in metadata.json and link it from review.md.

  • Keep walkthrough.md and explanations/ artifacts factual (Register 1): no severity grades or verdicts. Keep walkback/ artifacts in the structured investigation register (Register 2).

  • Create the explanations/ and walkback/ subfolders only when at least one explanation or investigation artifact is written.

  • Every review.md ends with a Disclaimer and Human Review section: the verbatim ## Code-Review CAUTION disclaimer from the disclaimer-language skill followed by an unchecked - [ ] Reviewed and validated by a qualified human reviewer checkbox. This section is always present, is always the final section, and the agent never checks the checkbox; only a human may convert [ ] to [x].

  • When the review scope targets a pull request or merge request, review.md includes a mandatory human-editable PR Comment Draft section with an unchecked posting checkbox. This section is the only place the general PR or MR comment is authored; the agent never reproduces the full drafted comment body in the conversational summary. The agent never checks the posting box; only the human may convert [ ] to [x], and that check is the gate that authorizes posting the general PR or MR comment.

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