Pr Review

Name: Pr Review
Author: NVIDIA

ASecurity

Review rubric for the `/review` pull-request command. The formal reviewer reads it as a file and it is not an interactive skill — do not load it to answer questions or to review code outside that command.

18,041 stars

0 votes

0 copies

4 views

Added 9/20/2026

code-qualitypythongonodetestinggit

Works with

claude code

Security Analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned 10/1/2026

$npx -y skills add NVIDIA/Megatron-LM --skill pr-review --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Pr Review?

Add the live security badge to your README — it updates automatically with every re-scan.

[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/nvidia-pr-review/badge)](https://www.skillsdirectory.com/skills/nvidia-pr-review)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro

Files

SKILL.md

---
name: pr-review
description: Review rubric for the `/review` pull-request command. The formal reviewer reads it as a file and it is not an interactive skill — do not load it to answer questions or to review code outside that command.
license: Apache-2.0
disable-model-invocation: true
user_invocable: false
---

# PR Review

This is the review rubric behind the `/review` pull-request command. The
reviewer receives the requested `REVIEW DEPTH` (`mode=light|strict`), then reads
this file.

It lives in `skills/` so the rubric can be diffed, reviewed and evolved like
code instead of being buried in YAML, but it is deliberately inert: the
frontmatter carries `disable-model-invocation: true`, so Claude Code drops it
from the advertised skill list and refuses to auto-invoke it. Reading it by
path, which is exactly what the reviewer does, still works. Do not add a
`when_to_use:` field — that is the trigger text that would make it activate on
its own.

## Pick the depth

Read only the reference for the depth the caller passed. Each one is a complete
rubric, so loading the other adds nothing but noise:

| `REVIEW DEPTH` | Comment trigger | Read |
| -------------- | --------------- | ---- |
| `light` | `/review` | `skills/pr-review/references/light.md` |
| `strict` | `/review mode=strict` | `skills/pr-review/references/strict.md` |

## Mandatory workflow — never skip or reorder

1. Read the PR diff first: `gh pr diff $PR_NUMBER --repo $REPO`.
2. From the changed files and areas, identify the relevant domain skills. Use
   Glob on `skills/*/SKILL.md` to see what exists rather than assuming names —
   the set changes over time, and Megatron-LM domain guides carry an `mcore-`
   prefix (`mcore-testing`, `mcore-cicd`, `mcore-build-and-dependency`,
   `mcore-linting-and-formatting`, `mcore-run-on-slurm`, `mcore-split-pr`,
   `mcore-onboard-gb200-1node-tests`, …).
3. Read those `SKILL.md` files with the Read tool.
4. Read the depth reference from the table above.
5. For Python changes, read the local [style-guide.md](../../style-guide.md)
   with the Read tool. Do not load the entire Google Python Style Guide by
   default. Consult relevant sections as needed; read it in full when performing
   a comprehensive style audit.
6. Only then review.

The order is what makes the review worth reading. A reviewer who forms an
opinion before loading `mcore-testing` will invent a test convention that this
repo does not use, and a confidently wrong review comment costs the author more
time than no review at all.

## Posting findings

Use inline ` ```suggestion ` blocks only for simple, self-contained line
replacements — typos, renames, single-line fixes. For structural changes that
add, remove or reorganize blocks of code (a new function, an inserted YAML
step, reordered logic), post a top-level PR comment with a fenced code block
showing the proposed change instead. GitHub's suggestion blocks can only
replace the exact lines they are anchored to, so an insertion or a multi-block
restructuring applied via `suggestion` silently corrupts the author's file.

Findings that deeper analysis invalidates should be dropped entirely rather
than hedged. A hedged comment transfers the work of disproving it to the author.

Completion — what to post at the end, and when to approve — is depth-specific
and covered in the reference file.

Attribution

NVIDIA

View source See grades on GitHub More from NVIDIA →

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

--- name: pr-review description: Review rubric for the `/review` pull-request command. The formal reviewer reads it as a file and it is not an interactive skill — do not load it to answer questions or to review code outside that command. license: Apache-2.0 disable-model-invocation: true user_invocable: false --- # PR Review This is the review rubric behind the `/review` pull-request command. The reviewer receives the requested `REVIEW DEPTH` (`mode=light|strict`), then reads this file. It lives in `skills/` so the rubric can be diffed, reviewed and evolved like code instead of being buried in YAML, but it is deliberately inert: the frontmatter carries `disable-model-invocation: true`, so Claude Code drops it from the advertised skill list and refuses to auto-invoke it. Reading it by path, which is exactly what the reviewer does, still works. Do not add a `when_to_use:` field — that is the trigger text that would make it activate on its own. ## Pick the depth Read only the reference for the depth the caller passed. Each one is a complete rubric, so loading the other adds nothing but noise: | `REVIEW DEPTH` | Comment trigger | Read | | -------------- | --------------- | ---- | | `light` | `/review` | `skills/pr-review/references/light.md` | | `strict` | `/review mode=strict` | `skills/pr-review/references/strict.md` | ## Mandatory workflow — never skip or reorder 1. Read the PR diff first: `gh pr diff $PR_NUMBER --repo $REPO`. 2. From the changed files and areas, identify the relevant domain skills. Use Glob on `skills/*/SKILL.md` to see what exists rather than assuming names — the set changes over time, and Megatron-LM domain guides carry an `mcore-` prefix (`mcore-testing`, `mcore-cicd`, `mcore-build-and-dependency`, `mcore-linting-and-formatting`, `mcore-run-on-slurm`, `mcore-split-pr`, `mcore-onboard-gb200-1node-tests`, …). 3. Read those `SKILL.md` files with the Read tool. 4. Read the depth reference from the table above. 5. For Python changes, read the local [style-guide.md](../../style-guide.md) with the Read tool. Do not load the entire Google Python Style Guide by default. Consult relevant sections as needed; read it in full when performing a comprehensive style audit. 6. Only then review. The order is what makes the review worth reading. A reviewer who forms an opinion before loading `mcore-testing` will invent a test convention that this repo does not use, and a confidently wrong review comment costs the author more time than no review at all. ## Posting findings Use inline ` ```suggestion ` blocks only for simple, self-contained line replacements — typos, renames, single-line fixes. For structural changes that add, remove or reorganize blocks of code (a new function, an inserted YAML step, reordered logic), post a top-level PR comment with a fenced code block showing the proposed change instead. GitHub's suggestion blocks can only replace the exact lines they are anchored to, so an insertion or a multi-block restructuring applied via `suggestion` silently corrupts the author's file. Findings that deeper analysis invalidates should be dropped entirely rather than hedged. A hedged comment transfers the work of disproving it to the author. Completion — what to post at the end, and when to approve — is depth-specific and covered in the reference file.