$ ~/registry/skill/microsoft-review-areas-skills-review-areas

SKILL

review-areas

Name: review-areas
Author: microsoft

Review code deeply across correctness, tests, security, performance, and product quality.

Stars

★ 24

Source

GitHub

Updated

2026-07-08

// securityCaution

Prompt only, no code
Open source

Summary

The material indicates this is an open-source, prompt-only code review skill with no required secrets and no declared remote endpoints, so overall risk is low. Some caution is warranted because the instructions mention reading code context, running tests, and saving session memory, but based on the material these appear to be workflow guidance rather than built-in executable capability.

CredentialsLow risk

The material explicitly states that no keys or environment variables are required, and it does not ask the user for tokens, API keys, or other sensitive credentials, so credential exposure and abuse risk appears low.

Network egressLow risk

No remote endpoints are declared, and the system flags it as prompt-only; the material does not describe sending code or user data to external services.

Code executionCaution

The README says subagents can 'read files and inspect changes' and, for test-related reviews, 'run tests,' and also mentions saving to session memory; this suggests it expects the host agent toolchain to perform local inspection, but the skill itself does not appear to package executable code.

Data accessCaution

Its purpose is to review PRs, git diffs, branches, and file sets, and save synthesized findings to `/memories/session/review.md`; this means it may access project code and session-level review results, but there is no sign of permissions beyond its stated purpose.

Supply chainLow risk

The source is a Microsoft GitHub repository and the system marks it as open-source, making the code auditable—this is a strong risk-reducing factor. Although it has 0 stars, no declared license, and unknown maintenance status, the current material shows no specific supply-chain red flags such as closed-source data exfiltration or suspicious install scripts.

Recommendations

Verify the repository contents and commit history before use to confirm the skill is only prompt/configuration based and does not include scripts.
If used with sensitive codebases, limit access to only the necessary PRs, diffs, or file sets.
If the host environment allows test execution or memory writes, ensure those capabilities align with your local security policy first.
Prefer importing from an official source or a pinned commit to reduce supply-chain uncertainty from future changes.

Audited by: gpt-5.4 · 2026-06-17

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "review-areas" skill from askskill:
1. Download https://raw.githubusercontent.com/microsoft/vscode-team-kit/main/review-areas/skills/review-areas/SKILL.md
2. Save it as ~/.claude/skills/review-areas/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Full review before submitting a PR

Prompt

Review this code change from five angles: correctness, test coverage, security risks, performance impact, and product behavior. List issues, risk levels, reasons, and provide actionable fixes plus suggested additional tests.

Expected

A structured review report with issue lists, priorities, fix recommendations, and extra test suggestions.

Hunt for hidden defects

Prompt

This refactor seems to work on the surface, but I worry about hidden bugs. Review the code like a senior reviewer, focusing on edge cases, error handling, concurrency issues, regression risks, and missing tests.

Expected

A list of potential defects and regression risks, with reproduction ideas and fix directions.

Check release readiness quality gates

Prompt

Assess whether this set of changes is release-ready: check for high-risk logic errors, insufficient tests, security concerns, performance regressions, or behavior that conflicts with product expectations, and conclude whether you recommend merging.

Expected

A pre-release review conclusion including merge recommendation, blocking issues, and suggested resolution order.

// docs

Skill: Review Areas

Fan out parallel read-only subagents, each assigned a different review area, then synthesize the highest-signal findings. This surfaces issues that a single-pass review misses because each subagent goes deep on its area instead of skimming everything.

Review Areas

Pick 2–4 areas based on the nature of the change. Not every review needs all areas — match the areas to the risk profile.

Area	When to include	Focus
Correctness	Always	Logic errors, type safety, race conditions, null/undefined paths, unsafe casts, wrong behavior
Tests	When tests exist or should exist	Run tests, check failing/missing coverage, validate assertions match intent
Security	Auth, input handling, data flow changes	Input validation, auth checks, injection, data exposure
Performance	Hot paths, data structures, async changes	Algorithm complexity, unnecessary allocations, blocking async patterns
Product	UI, UX, or user-facing behavior changes	UX implications, feature completeness, accessibility gaps

Workflow

1 — Scope

Prefer the active pull request, current git diff, or an explicit file list from the user.
If there is nothing to review, ask the user to point at a branch, PR, diff, or file set.

2 — Build a Change Summary

Before fanning out, build a concise change summary. Do not paste raw diffs into the subagent prompts — each subagent has tools to read files and inspect changes itself.

The summary should include:

Intent — what the change is trying to accomplish (from PR description, commit messages, or conversation context).
Changed files — list each file path with a one-line description of what changed (e.g., "added input validation", "refactored into helper").
Risk areas — anything risky: new dependencies, auth changes, hot-path modifications, API surface changes.
How to inspect — branch/PR/commit info so subagents can use their tools.

Keep the summary under ~50 lines. Subagents get better results reading code in context than scanning a wall of diff.

3 — Fan Out

Launch 2–4 parallel subagents using the area prompts below. Each subagent works in isolation — do not share one area's findings with another before synthesis.

Use unnamed subagents (no custom agent needed). Each gets a self-contained prompt with its area, the change summary, and the return format.

4 — Synthesize

When all subagents return:

Deduplicate findings that overlap across areas (e.g., a correctness bug that also shows up as a missing test).
Order by severity: breaking > wrong behavior > security > missing coverage > performance > product.
Apply the signal filter — drop anything that wouldn't block a PR.
If no blocking issues survive, say so and mention any meaningful testing gaps.

5 — Save Findings

Always save the synthesized findings to session memory at /memories/session/review.md. This makes them available for follow-up turns, fix planning, and cross-referencing with future reviews.

6 — Fix or Report

Review-only: if the user said "only review", "just review", or "read-only", stop after reporting.
Default (review-and-fix):
1. For each fixable finding, launch one or more parallel Explore subagents to investigate the fix — this is faster and deeper than reading files inline. Give each Explore agent the finding, the relevant file paths, and ask it to return the specific change needed (what to replace, where).
2. Apply fixes in severity order based on the Explore agents' recommendations.
3. After applying, re-check the changed lines and diagnostics to validate.
4. Report what was fixed and any remaining items that need the user's input.

Signal Filter

Keep only findings a senior engineer would block a PR for:

Will fail to compile, type-check, or produce wrong results
Clear, citable violation of workspace coding standards

…

View full docs ↗

Review implementation plans for gaps, assumptions, and sequencing before coding starts

microsoftGet→

$ loading_