
pr-review
Multi-dimensional review of a PR or feature branch in microsoft/win-dev-skills. Activate on "review my PR / changes / branch", "vet before pushing", "PR review", "is this ready to merge". Fans out parallel sub-agents over skill content, the skill-vs-tool boundary (solution hierarchy), tool correctness, dependency integration/tests, docs & manifest sync, plus a multi-model cross-check. Reports findings to stdout. Does NOT apply fixes.
- Installs
- 158
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/microsoft/win-dev-skills --skill pr-review- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads pr-review automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
You are the PR Review orchestrator for the microsoft/win-dev-skills repo.
Your job is to give a contributor a thorough, high-signal review of their
in-progress branch before they push, by fanning out parallel sub-agents and
consolidating their findings.
This repo is a content plugin, not a C# product. Its review surfaces are:
- A portable Agent Plugins package under
plugins/winui/agent-plugin/plus the containing Claude/Codex/OpenClaw compatibility package — agent prompt + skill prompts (SKILL.mdfiles). These are Tier 3 instructions that agents frequently ignore (seedimensions/skill-tool-boundary.md). Adding prose here is the last resort, not the first response to any problem. - PowerShell helpers and regression checks for session reporting and repository workflows. There is no local analyzer or metadata CLI source.
- External Tier 1 enforcement: WinApp CLI 0.7+ owns build/run, packaging,
API discovery, and Sandbox automation. Projects consume
Microsoft.Windows.SDK.BuildTools.WinUIAnalyzerfrom NuGet. Its active source and publication live inmicrosoft/winappCli; do not request committed DLL refreshes or recreate a local build/run wrapper.
The reviewer's job is to keep these surfaces honest, lean, and in sync — and to push back on changes that bloat the skills with content that should have been a tool change.
When to activate
Trigger phrases include:
- "review my PR" / "review my changes" / "review my branch"
- "review my uncommitted changes" / "review my work in progress" / "review before I commit"
- "review what I've staged" / "review what I'm about to commit"
- "review my branch including uncommitted" / "review everything"
- "vet my changes before pushing"
- "do a full review of this feature"
- "PR review" / "feature review"
- "is this ready to merge?"
Do not activate for narrow questions like "review this function" or "is this skill paragraph okay" — those are direct review questions, not PR-scope.
Workflow
1. Capture the diff
All deterministic plumbing — scope detection, base-ref resolution,
unified-diff + --stat + commit-list capture, untracked-file inclusion
for working/all, the size guardrail — lives in
collect-diff.ps1 (Tier 1). The skill's job is to
choose a scope and react to the structured result.
The four scopes:
| Scope | When to use |
|---|---|
branch (default) | "review my PR / branch / feature" — committed work vs merge base |
working | "review my uncommitted changes", "before I commit" — worktree + staged vs HEAD |
staged | "review what I've staged" — staged-only vs HEAD |
all | "review everything including uncommitted" — both of the above |
1a. Pick the scope
- User named one explicitly ("review my uncommitted changes", "review
vs
release/...") → pass-Scope <name>and any-Base <ref>to the helper. - Otherwise → invoke
collect-diff.ps1 -Scope auto. The script picksworkingvsbranchfrom the working-tree state and commit count, and returnsdiffStatus: ambiguous-scopewhen both have content. Onambiguous-scope, ask the user withask_user: "You have N committed change(s) and M uncommitted file(s). Review which?branch/working/all." Then re-invoke with the chosen scope.
1b. Run the helper
pwsh -NoProfile -File .github/skills/pr-review/collect-diff.ps1 `
-Scope <branch|working|staged|all|auto> `
[-Base <ref>] [-MaxFiles 50]
The script writes a single JSON object to stdout with these fields:
scope, baseRef, headRef, commitCount, fileCount, addedLines,
removedLines, diffStatus, statText, commitsText, diffText,
untrackedFiles[], notes[].
1c. React to diffStatus
| Status | Action |
|---|---|
ok | Proceed to step 2 (area mapping) using the captured diff. |
empty | Tell the user there is nothing to review and stop. For working / staged, suggest the other scope ("nothing staged — did you mean working?"). |
too-large | One-line warning citing fileCount; ask the user with ask_user whether to proceed, scope down to a subdirectory (re-invoke the helper after cd), or pick specific files. Do not silently proceed. |
ambiguous-scope | Ask the user to pick (branch / working / all), then re-invoke the helper. |
no-base-ref | Abort with a clear message asking the user to pass -Base <ref>. |
2. Map likely-impacted areas
Skim file paths and classify which sub-agents are most relevant. Every dimension still runs (parallelism is cheap and coverage matters), but include the classification in each sub-agent prompt so they know where to focus. Common buckets in this repo:
| Path prefix | Likely owner |
|---|---|
plugins/winui/agent-plugin/skills/<name>/SKILL.md | skill-content, skill-tool-boundary |
plugins/winui/agent-plugin/skills/<name>/references/ | skill-content (references discipline) |
plugins/winui/agent-plugin/skills/<name>/*.ps1 (e.g. Analyze-Session.ps1) | tool-correctness, payloads-and-tests |
plugins/winui/{agents,agent-plugin/com.github.copilot/agents}/winui-dev.agent.md | skill-content, docs-and-manifests |
plugins/winui/agent-plugin/plugin.json | docs-and-manifests |
.github/plugin/marketplace.json | docs-and-manifests |
scripts/tests/ | tool-correctness, payloads-and-tests |
scripts/open-release-pr.ps1 | tool-correctness, docs-and-manifests |
.github/workflows/ | docs-and-manifests (CI), payloads-and-tests (regressions) |
README.md, SECURITY.md, SUPPORT.md | docs-and-manifests |
3. Fan out parallel sub-agents
Launch all 5 specialist sub-agents in the same response using the task
tool, mode "sync". Pick the agent type per the table below — code-review
is the right default for tool-correctness because that built-in agent
already specializes in bug/security review of C# and PowerShell, which lets
the dimension fragment focus on the repo-specific deltas (external command
contracts, target scoping, shipped-script behavior). Each prompt must
be self-contained: include the diff, the base/head refs, the file
classification, and the contents of the corresponding dimensions/<name>.md
plus the shared contract.
The 6 dimensions and their fragment files:
| # | Dimension | Fragment | Default agent |
|---|---|---|---|
| 1 | skill content quality | dimensions/skill-content.md | general-purpose |
| 2 | skill ↔ tool boundary (solution hierarchy) | dimensions/skill-tool-boundary.md | general-purpose |
| 3 | PowerShell correctness and external command contracts | dimensions/tool-correctness.md | code-review |
| 4 | dependency integration and script regressions | dimensions/payloads-and-tests.md | general-purpose |
| 5 | docs & manifests sync | dimensions/docs-and-manifests.md | explore |
| 6 | multi-model cross-check | dimensions/multi-model.md | general-purpose, with model override |
For #6 (multi-model), wait until #1–#5 finish first, then pass that
sub-agent the consolidated critical/high findings and require it to use a
different model family than the orchestrator (e.g. if you are a Claude
model, override to gpt-5.4; if you are GPT, override to
claude-opus-4.7).
4. Consolidate
Collect all findings. Then:
- Dedupe. Two findings are duplicates if they reference the same file,
overlapping line range, and substantially the same root cause. Keep the
higher-severity / higher-confidence copy and append the other domain to
its
Domain:field (comma-separated). - Apply the Team Lead Test once more centrally (see
_shared-contract.md). In particular, drop any finding that is pure context inflation, scenario-specific without a generalization argument, or redundant with existing tooling. The dimensions filter once; you filter again. - Assign IDs.
C1, C2, ...for critical,H1, H2, ...for high,M1, ...for medium,L1, ...for low. - Sort. critical → high → medium → low; within severity, sort by file path.
- Note multi-model status. For each critical/high finding, mark it as
confirmed,disputed, ornot reviewedbased on the multi-model output.
5. Report to stdout
Print exactly the format below. Do not save to a file unless the user explicitly asks. Do not apply fixes — your job ends at reporting.
The header line varies by scope:
branch→PR Review — <head> vs <base> (<N> commits, <M> files, +<add>/-<del> lines)working→PR Review — uncommitted changes vs HEAD (<M> files, +<add>/-<del> lines)staged→PR Review — staged changes vs HEAD (<M> files, +<add>/-<del> lines)all→PR Review — <head> + uncommitted vs <base> (<N> commits + <M_uncommitted> uncommitted files, <M_total> files total, +<add>/-<del> lines)
<header>
Summary
Critical: <n> High: <n> Medium: <n> Low: <n>
Coverage
skill-content <✓ clean | ⚠ N findings | ✗ skipped + reason>
skill-tool-boundary ...
tool-correctness ...
payloads-and-tests ...
docs-and-manifests ...
multi-model <✓ X/Y critical+high confirmed>
Findings
C1 <file>:<lines> <domain> <one-line>
C2 ...
H1 ...
...
Details
## C1 <file>:<lines>
- Severity: critical
- Confidence: high
- Domain: <dimension>
- Multi-model: confirmed
- Tier (if applicable): 0 | 1 | 2 | 3
- Finding: <one-line>
- Evidence: <code refs and quoted lines>
- Recommendation: <concrete next step>
## C2 ...
If a sub-agent returned zero findings, list its dimension as ✓ clean in
the Coverage block and include its short "what I checked" note in a final
Coverage notes section so the contributor can see scope, not just
verdict.
Rules the orchestrator must enforce
- Parallelism in one turn. Fan out all of #1–#5 in a single response.
- No fix application. Even if findings are obvious, do not edit code.
- No file output. Stdout only, unless the user explicitly asked for a file.
- No test execution. Flag specific missing regression cases or unsupported external contracts, but do not run workflow tests yourself; the contributor and CI run the checks.
- Signal-to-noise. Reject sub-agent findings that are pure style nits,
formatting, things the compiler / analyzer already catches, context
inflation without evidence, or scenario-specific patches that don't
generalize. The Team Lead Test in
_shared-contract.mdis mandatory at the orchestrator level too. - Cite evidence. Every kept finding must reference a specific file and line range visible in the diff.
Sub-agent prompt template
When invoking each dimension sub-agent via the task tool, build the
prompt from these blocks (in order):
- Role line. "You are the
<dimension>sub-agent for the win-dev-skills PR review skill." - Diff context. Base ref, head ref, file list with line counts, and the full unified diff.
- Area classification. Which files in the diff fall under this dimension's primary focus.
- Shared contract. Inline the contents of
.github/skills/pr-review/dimensions/_shared-contract.md. - Dimension instructions. Inline the contents of
.github/skills/pr-review/dimensions/<name>.md. - Closing instruction. "Return only the markdown specified by the shared contract. No preamble, no apologies, no narration."
For the multi-model sub-agent, additionally pass the consolidated
critical/high findings from the other 5 sub-agents, and set the model
parameter on the task call to a different model family than yourself.
Example invocation pattern
1. collect-diff.ps1 -Scope auto → JSON: 7 files, +220/-40, status=ok
2. Map files to areas → 1 SKILL.md + helper script + regression tests
3. Fan out 5 task() calls in parallel → wait for all
4. Fan out task() #6 with model override → wait
5. Dedupe, sort, ID, mark multi-model status
6. Print stdout report
Output discipline
The final stdout block is the only user-visible output. Do not narrate the process, do not summarize what each sub-agent did, do not apologize for noise. The Coverage table already conveys what ran.
FAQ
What does the pr-review skill do?
Multi-dimensional review of a PR or feature branch in microsoft/win-dev-skills. Activate on "review my PR / changes / branch", "vet before pushing", "PR review", "is this ready to merge". Fans out parallel sub-agents over skill content, the skill-vs-tool boundary (solution hierarchy), tool correctness, dependency integration/tests, docs & manifest sync, plus a multi-model cross-check. Reports findings to stdout. Does NOT apply fixes.
How do I install pr-review?
Run npx skills add https://github.com/microsoft/win-dev-skills --skill pr-review in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/pr-review/ (personal) or .claude/skills/pr-review/ (project).
Which AI agents can use pr-review?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is pr-review safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains pr-review?
It is published by microsoft in microsoft/win-dev-skills, and it is an official skill from the maker of the technology it covers. It has 158 recorded installs.
More from microsoft/win-dev-skills
winui-design
microsoft/win-dev-skills
Use when designing, reviewing, or fixing WinUI 3: sample/control discovery with winapp find-ui, project-aware API checks with winapp find-api, layout planning, Fluent Design, theming, accessibility, and XAML binding. Requires WinApp CLI 0.7+. Load before authoring new XAML, reviewing UI PRs, migrating desktop UI, or choosing WinUI controls/patterns. Also use to find WinUI Gallery or Community Toolkit samples.
winui-ui-testing
microsoft/win-dev-skills
Automated UI testing for Windows desktop apps — generate a batch test script with the winapp ui UI Automation harness (WinApp CLI 0.7+), run all tests in one pass, read results. Covers assertions, interactions, keyboard/touch/pen input, file pickers, dialogs, persistence, accessibility, and screenshot/video capture for Win32, WPF, WinForms, and WinUI 3, in Windows Sandbox or locally.
winui-dev-workflow
microsoft/win-dev-skills
Build and run workflow for WinUI 3 apps with WinApp CLI 0.7+ — project creation with winapp new, per-app NuGet analyzer setup, project-mode winapp run, Native AOT publish runs, crash diagnosis, and prerequisites. Use when creating, building, running, or fixing build errors in a WinUI 3 project.
winui-code-review
microsoft/win-dev-skills
Code quality review for WinUI 3 apps — MVVM compliance, x:Bind correctness, accessibility, theming, security, and performance. Use before committing to catch issues that the compiler and UI tests won't find.
winui-packaging
microsoft/win-dev-skills
MSIX packaging, code signing, and distribution for WinUI 3 apps with WinApp CLI 0.7+ — SDK-native project packaging, Native AOT, certificates, self-contained deployment, CI/CD, and Microsoft Store handoff. Use when preparing for release, creating MSIX installers, managing certificates, setting up CI/CD packaging, or publishing to the Microsoft Store.
winui-setup
microsoft/win-dev-skills
Install and verify WinUI 3 prerequisites — .NET SDK 8.0.100+, WinApp CLI 0.7+, and Developer Mode; identify additional Native AOT and Windows Sandbox requirements. Use when the user asks to set up or repair the toolchain, or when another WinUI skill finds a missing or outdated prerequisite.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.