Official agent skill

PR Finalize

by dotnet in dotnet/maui

Checks that a pull request's title and description match its implementation and reviews the code for best practices before merge, without posting anything.

OfficialMITAuto-check passedDevelopment

Install PR Finalize

skills CLI
$ npx skills add dotnet/maui --skill pr-finalize -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install dotnet/maui pr-finalize --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/dotnet/maui.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/pr-finalize .claude/skills/pr-finalize && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
pr-finalize
GitHub stars
23k
Token cost
~3.1k tokens
SKILL.md length
1,068 words
Files
2 (incl. references)
Skills in repo
27
Repo updated
First seen
Licence
MIT

At a glance

Checks that a pull request's title and description match its implementation and reviews the code for best practices before merge, without posting anything.

  • Works in 5 steps: NEVER Approve or Request Changes → NEVER Post Comments Directly → Review Existing Description Quality → …
  • Asked to finalize a PR before merging
  • SKILL.md covers Two-Phase Workflow, 🚨 CRITICAL RULES, Phase 1: Title & Description and Usage, plus 8 more sections
  • Calls gh and git

What it does

The skill works in two phases: first it verifies that the PR title and description match what the code does, then it reviews the code for best practices and potential issues. It stands alone and can be used on any PR. It is analysis only. The agent must never approve or request changes with the GitHub CLI, and never post comments itself; findings go to pr-finalize-summary.md, and the summary is only posted or used when a user explicitly asks for PR finalization.

For the description, the core principle is to preserve quality. The agent evaluates the existing text first, keeps a thorough description rather than swapping in a generic template, adds only missing required elements such as a NOTE block or issue links, and rewrites only when the text is stale, inaccurate or missing key information. Current state comes from gh pr view with JSON fields, so no local checkout is needed. Lessons extraction, test writing and build failure investigation are left to other skills. The excerpt is cut off in the evaluation workflow.

When your agent uses it

  • Asked to finalize a PR before merging
  • Checking that a PR title and description match the code
  • Reviewing a commit message for best practices
  • Re-checking a PR after its implementation changed during review

Example prompts

  • “Finalize this PR: check that the description matches the diff and review the code.”
  • “Does the title and description of this PR still match what the code does after the review changes?”
  • “Review the commit message for best practices before I merge.”

Requirements

  • The GitHub CLI (`gh`) with access to the repository

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. NEVER Approve or Request Changes
  2. NEVER Post Comments Directly
  3. Review Existing Description Quality
  4. Compare to Template
  5. Produce Output

What it can do on your machine

Read from SKILL.md and the folder at commit b926f05. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh and git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

PR Finalize loads about 3.1k tokens when it runs, and up to ~3.8k if it reads all its reference files. Until then it costs about 116 tokens; SKILL.md has 1,068 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~116
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~3.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from dotnet/maui at commit b926f05, republished under its MIT licence (© dotnet). 1,068 words, ~3,124 tokens.

Download SKILL.mdSave it as .claude/skills/pr-finalize/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
pr-finalize
description
Finalizes any PR for merge by verifying title/description match implementation AND performing code review for best practices. Use when asked to "finalize PR", "check PR description", "review commit message", before merging any PR, or when PR implementation changed during review. Do NOT use for extracting lessons (use learn-from-pr), writing tests (use write-tests-agent), or investigating build failures (use azdo-build-investigator and ci-analysis).

PR Finalize

Ensures PR title and description accurately reflect the implementation, and performs a code review for best practices before merge.

Standalone skill - Can be used on any PR, not just PRs reviewed by the pr-review skill.

Two-Phase Workflow

  1. Title & Description Review - Verify PR metadata matches implementation
  2. Code Review - Review code for best practices and potential issues

🚨 CRITICAL RULES

1. NEVER Approve or Request Changes

AI agents must NEVER use --approve or --request-changes flags.

ActionAllowed?Why
gh pr review --approve❌ NEVERApproval is a human decision
gh pr review --request-changes❌ NEVERBlocking PRs is a human decision
2. NEVER Post Comments Directly

This skill is ANALYSIS ONLY. Never post comments using gh commands.

ActionAllowed?Why
gh pr review --comment❌ NEVERReview-PR.ps1 handles posting via scripts
gh pr comment❌ NEVERReview-PR.ps1 handles posting via scripts
Analyze and report findings✅ YESThis is the skill's purpose

Correct workflow:

  1. This skill: Analyze PR, produce findings and write to pr-finalize-summary.md
  2. Human-controlled follow-up: PR finalization is not part of the automated Review-PR.ps1 flow. Only post or use the summary when a user explicitly asks for PR finalization.

Only humans control when comments are posted. Your job is to analyze and present findings.


Phase 1: Title & Description

Core Principle: Preserve Quality

Review existing description BEFORE suggesting changes. Many PR authors write excellent, detailed descriptions. Your job is to:

  1. Evaluate first - Is the existing description good? Better than a template?
  2. Preserve quality - Don't replace a thorough description with a generic template
  3. Enhance, don't replace - Add missing required elements (NOTE block, issue links) without rewriting good content
  4. Only rewrite if needed - When description is stale, inaccurate, or missing key information

Usage

bash
# Get current state (no local checkout required)
gh pr view XXXXX --json title,body
gh pr view XXXXX --json files --jq '.files[].path'

# Review commit messages (helpful for squash/merge commit quality)
gh pr view XXXXX --json commits --jq '.commits[].messageHeadline'

# Review actual code changes
gh pr diff XXXXX

# Optional: if the PR branch is checked out locally
git diff origin/main...HEAD

Evaluation Workflow

Step 1: Review Existing Description Quality

Before suggesting changes, evaluate the current description:

Quality IndicatorLook For
StructureClear sections, headers, organized flow
Technical depthFile-by-file changes, specific code references
ScanabilityEasy to find what changed and where
AccuracyMatches actual diff - not stale or incorrect
CompletenessPlatforms, breaking changes, testing info
Step 2: Compare to Template

Ask: "Is the existing description better than what my template would produce?"

  • If YES: Keep existing, only add missing required elements
  • If NO: Suggest improvements or replacement
Step 3: Produce Output
  • Recommended PR title (if change needed)
  • Assessment of existing description
  • Specific additions needed (e.g., "Add NOTE block at top")
  • Only full replacement if description is inadequate

Title Requirements

The title becomes the commit message headline. Make it searchable and informative.

RequirementGoodBad
Platform prefix (if specific)[iOS] Fix Shell back buttonFix Shell back button
Describes behavior, not issue[iOS] SafeArea: Return Empty for non-ISafeAreaView viewsFix #23892
Captures the "what"Return Empty for non-ISafeAreaViewFix SafeArea bug
Notes model change if applicable(opt-in model)(omitted)
No noise prefixes[iOS] Fix...[PR agent] Fix...
Title Formula
[Platform] Component: What changed (model change if any)

Examples:

  • [iOS] SafeArea: Return Empty for non-ISafeAreaView views (opt-in model)
  • [Android] CollectionView: Fix scroll position reset on item update
  • [Windows] Shell: Use NavigationView instead of custom flyout

Description Requirements

PR description should:

  1. Include the base sections from .github/PULL_REQUEST_TEMPLATE.md ("Description of Change" and "Issues Fixed"). The skill adds additional structured fields (Root cause, Fix, Key insight, etc.) as recommended enhancements for better agent context.
  2. Match the actual implementation
markdown
### Description of Change
[Must match actual implementation]

### Issues Fixed
Fixes #XXXXX

Content for Future Agents

The title and description become the commit message. Future agents searching git history will use this to understand:

  • What changed and why
  • What patterns to follow or avoid
  • How this change affects related code
Required Elements for Agent Success
ElementPurposeExample
Root causeWhy the bug occurred"Non-ISafeAreaView views falling through to return baseSafeArea"
Fix approachWhat the code now does"Return SafeAreaPadding.Empty for views without interface"
Philosophy/model changeIf behavior model changed"Before: opt-out. After: opt-in via interface"
Key interfaces/typesTypes agents need to know"ISafeAreaView, ISafeAreaView2 = opt-in contract"
What NOT to doFailed approaches to avoid"Don't use Element type in Platform layer"
Architectural constraintsLayer boundaries, type availability"Platform layer cannot reference Controls types"
Edge casesKnown limitations or risks"Legacy layouts are [Obsolete], custom views need interface"
Show full SKILL.md (393 more words)Show less
"What NOT to Do" Section (Critical)

When try-fix or debugging revealed failed approaches, document them:

markdown
### What NOT to Do (for future agents)

- ❌ **Don't use [Type] in [Layer]** - [Why it fails]
- ❌ **Don't use [Pattern]** - [Why it's brittle/wrong]
- ❌ **Don't [Approach]** - [Why it doesn't work]

This prevents future agents from repeating failed experiments.

Philosophy/Model Changes

When a fix changes the behavioral model (not just fixing a bug), call it out explicitly:

markdown
**This is a philosophy change:**
- **Before:** [Old behavior model]
- **After:** [New behavior model]

Example: "Before: Safe area applied by default (opt-out). After: Only views implementing ISafeAreaView get safe area (opt-in)."

Common Issues

ProblemCauseSolution
Description doesn't match codeImplementation changed during reviewUpdate description to match actual diff
Missing root causeAuthor focused on "what" not "why"Add root cause from issue/analysis
References wrong approachStarted with A, switched to BUpdate to describe final approach
Missing NOTE blockAuthor didn't use templatePrepend NOTE block, keep rest
Good description replacedAgent used template blindlyEvaluate existing quality first

Output Format

When Existing Description is Good
markdown
## PR #XXXXX Finalization Review

### ✅ Title: [Good / Needs Update]
**Current:** "Existing title"
**Recommended:** "[Platform] Improved title" (if needed)

### ✅ Description: Excellent - Keep As-Is

**Quality assessment:**
- Structure: ✅ Clear sections with headers
- Technical depth: ✅ File-by-file breakdown
- Accuracy: ✅ Matches implementation
- Completeness: ✅ Platforms, breaking changes noted

**Only addition needed:**
- ❌ Missing NOTE block - prepend to top

**Action:** Add NOTE block, preserve everything else.
When Description Needs Rewrite

Use structured template only when existing description is inadequate:

markdown
### Root Cause

[Why the bug occurred - be specific about the code path]

### Description of Change

[What the code now does]

**This is a philosophy change:** (if applicable)
- **Before:** [Old model]
- **After:** [New model]

[Cross-platform alignment notes if relevant]

### Key Technical Details

**[Relevant interfaces/types]:**
- `InterfaceA` - [What it does]
- `InterfaceB` - [What it does]

**[Category] that [work/don't work]:**
- List of types/views affected

### What NOT to Do (for future agents)

- ❌ **Don't [approach 1]** - [Why it fails]
- ❌ **Don't [approach 2]** - [Why it's wrong]
- ❌ **Don't [approach 3]** - [Constraint that prevents it]

### Edge Cases

| Scenario | Risk | Mitigation |
|----------|------|------------|
| [Case 1] | Low/Medium/High | [How to handle] |
| [Case 2] | Low/Medium/High | [How to handle] |

### Issues Fixed

Fixes #XXXXX

### Platforms Tested

- [x] iOS
- [x] Android
- [ ] Windows
- [ ] Mac

Quality Comparison Examples

Good Existing Description (KEEP)
markdown
## Changes Made

### 1. **PickerHandler.iOS.cs** - MacCatalyst-specific improvements

#### Added UIAlertController instance field
- Declared `UIAlertController? pickerController` as instance field...

#### Improved picker dismiss logic
- Moved picker dismiss logic from event handler to "Done" button action
- Removed `EditingDidEnd` event handler causing duplicate dismiss calls

## Platforms Affected
- **MacCatalyst** (primary)
- iOS (no behavior changes, shared code)

## Breaking Changes
None

Verdict: Excellent - file-by-file breakdown, specific changes, platforms, breaking changes. Keep it.

Poor Existing Description (REWRITE)
markdown
Fixed the issue mentioned in #30897

Verdict: Inadequate - no detail on what changed. Use template.


Phase 2: Code Review

After verifying title/description, perform a code review to catch best practice violations and potential issues before merge.

Review Focus Areas

When reviewing code changes, focus on:

  1. Code quality and maintainability - Clean code, good naming, appropriate abstractions
  2. Error handling and edge cases - Null checks, exception handling, boundary conditions
  3. Performance implications - Unnecessary allocations, N+1 queries, blocking calls
  4. Platform-specific concerns - iOS/Android/Windows differences, platform APIs
  5. Breaking changes - API changes, behavior changes that affect existing code
How to Review
bash
# Get the PR diff
gh pr diff XXXXX

# Review specific files
gh pr diff XXXXX -- path/to/file.cs
Output Format
markdown
## Code Review Findings

### 🔴 Critical Issues

**[Issue Title]**
- **File:** [path/to/file.cs]
- **Problem:** [Description]
- **Recommendation:** [Code fix or approach]

### 🟡 Suggestions

- [Suggestion 1]
- [Suggestion 2]

### ✅ Looks Good

- [Positive observation 1]
- [Positive observation 2]
🚨 CRITICAL: Do NOT Post Comments Directly

The pr-finalize skill is ANALYSIS ONLY. Never post comments using gh pr review or gh pr comment.

ActionAllowed?Why
gh pr review --comment❌ NEVERReview-PR.ps1 handles posting via scripts
gh pr comment❌ NEVERReview-PR.ps1 handles posting via scripts
Analyze and report findings✅ YESThis is the skill's purpose

Workflow:

  1. This skill: Analyze PR, produce findings and write to pr-finalize-summary.md
  2. Human-controlled follow-up: PR finalization is not part of the automated Review-PR.ps1 flow. Only post or use the summary when a user explicitly asks for PR finalization.

The user controls when comments are posted. Your job is to analyze and present findings.


Complete Example

See references/complete-example.md for a full agent-optimized PR description showing all elements above applied to a real SafeArea fix.

© dotnet, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in .github/skills/pr-finalize of dotnet/maui.

  • SKILL.md
  • references/complete-example.md

Open the folder on GitHubat commit b926f05

Compare with similar skills

PR Finalize next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

PR Finalize compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
PR Finalize this skilldotnet/maui23k—~3.1kAutomated safety check: PassMIT
PR Finalize Reviewmicrosoft/garnet12k—~3.1kAutomated safety check: PassMIT
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
GitHub Review Iterationprisma/orm48k—~2.2kAutomated safety check: PassApache-2.0
PR Review State Fetchprisma/orm48k—~767Automated safety check: PassApache-2.0
Fastlane Pull Request Reviewfastlane/fastlane42k—~550Automated safety check: PassMIT

Similar skills

  • PR Finalize Review

    microsoft/garnet

    Official

    Checks that a pull request's title and description match its implementation and reviews the code for Garnet best practices, reporting findings without posting them.

    12k GitHub stars~3.1k tokensUpdated today
    DevelopmentAuto-check passed
  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed
  • Official

    Runs a loop on a GitHub pull request: fetch review state, triage comments into actions, implement them and resolve threads, repeating until nothing actionable is left.

    48k GitHub stars~2.2k tokensUpdated today
    DevelopmentAuto-check passed
  • Official

    Fetches a pull request's canonical review state as JSON, validates it, and renders markdown, a text summary and triage target files from it using bundled scripts.

    48k GitHub stars~767 tokensUpdated today
    DevelopmentAuto-check passed
  • Reviews a fastlane pull request against its linked issue and the project guides, separating blocking from non-blocking findings and handling vulnerabilities privately.

    42k GitHub stars~550 tokensUpdated today
    DevelopmentAuto-check passed
  • React Router Pull Request Creator

    remix-run/react-router

    Packages finished React Router work into a draft pull request: branch, commit, push, a written PR body and the right GitHub labels.

    57k GitHub stars~2.5k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from dotnet/maui

All 27 skills in this repo
  • Mines local Copilot CLI session logs for dotnet/maui to rank costly or failing runs, tag recurring failure modes, propose repo edits and emit guard evals.

    23k GitHub stars~3.4k tokensUpdated today
    Auto-check passed
  • Official

    Reviews the tests added in a pull request for fix coverage, quality, edge cases and test type, and recommends lighter test types where they would do.

    23k GitHub stars~2.9k tokensUpdated today
    Auto-check passed
  • Official

    Produces evidence-backed ship-readiness verdicts for .NET MAUI Servicing Releases and Previews, and drafts public-safe release handoff pages from the result.

    23k GitHub stars~15k tokensUpdated today
    Auto-check passed
  • Official

    Interprets pinned managed benchmark evidence for a dotnet/maui pull request and writes a narrative for the performance review workflow, without running or publishing anything.

    23k GitHub stars~2.4k tokensUpdated today
    Auto-check passed
  • Official

    Adds MAUI-specific guardrails on top of the maestro-cli skill and Maestro MCP tools for darc, BAR, and channel or feed lookups in dotnet/maui.

    23k GitHub stars~10k tokensUpdated today
    Auto-check passed
  • Official

    Adds dotnet/maui-specific context for investigating failing PR checks and broken nightly builds: pipelines, Helix logs, binlogs and merge-readiness verdicts.

    23k GitHub stars~2k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about PR Finalize

What does PR Finalize do?

Checks that a pull request's title and description match its implementation and reviews the code for best practices before merge, without posting anything. The skill works in two phases: first it verifies that the PR title and description match what the code does, then it reviews the code for best practices and potential issues. It stands alone and can be used on any PR.

When should I use PR Finalize?

PR Finalize fits situations like: asked to finalize a PR before merging; checking that a PR title and description match the code; reviewing a commit message for best practices; re-checking a PR after its implementation changed during review.

How do I install PR Finalize in Claude Code?

Run `npx skills add dotnet/maui --skill pr-finalize -a claude-code`. Or copy the skill folder (.github/skills/pr-finalize in dotnet/maui) into .claude/skills/pr-finalize in your project. Claude Code loads it when a task matches its description.

How do I install PR Finalize in Codex?

Run `npx skills add dotnet/maui --skill pr-finalize -a codex`. Or copy the skill folder (.github/skills/pr-finalize in dotnet/maui) into .agents/skills/pr-finalize in your project. Codex loads it when a task matches its description.

Can I use PR Finalize in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add dotnet/maui --skill pr-finalize -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/pr-finalize, .gemini/skills/pr-finalize, .github/skills/pr-finalize and .opencode/skills/pr-finalize in your project.

What does PR Finalize need to run?

Going by SKILL.md and its folder, PR Finalize needs the command-line tools its instructions call (gh and git). Our summary lists: The GitHub CLI (`gh`) with access to the repository.

Does PR Finalize access the network?

SKILL.md contains no URLs. Its commands use gh and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is PR Finalize safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does PR Finalize use?

PR Finalize is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does PR Finalize use?

About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 701 tokens, read only when the agent opens those files.

What are the alternatives to PR Finalize?

Skills that share tags, products or a category with PR Finalize: PR Finalize Review (microsoft/garnet, 12k stars), PR Babysitter (openinterpreter/openinterpreter, 69k stars), GitHub Review Iteration (prisma/orm, 48k stars) and PR Review State Fetch (prisma/orm, 48k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains PR Finalize?

dotnet (a GitHub organization, an official publisher) maintains it in dotnet/maui, which has 23,321 GitHub stars. The repository holds 27 skills in this directory. The repository was last updated on October 8, 2026.

Source: dotnet/maui on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.