agentsclimarketplace

Nvidia nemo rl review pr

Skill autohandai/community-skills/nvidia-nemo-rl-review-pr

Interactive code review for NVIDIA-NeMo/RL pull requests. Checks out PR locally, reads existing comments, applies coding guidelines from skills, previews findings, and posts review comments. Also supports reviewing the current branch locally.From its SKILL.md

Install
npx -y skills add autohandai/community-skills --skill nvidia-nemo-rl-review-pr

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0 AND CC-BY-4.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

9.8 KB, ~2.3k tokens by cl100k_base, as published. Nobody here has run it

Interactive PR Review — NVIDIA-NeMo/RL

Review a pull request or local branch interactively, applying the project's coding guidelines.

Parse Arguments

  • If $ARGUMENTS contains a number → PR mode with that PR number
  • If $ARGUMENTS is empty or has no number → LOCAL mode (review current branch vs main)
  • If $ARGUMENTS contains updateUPDATE mode (PR mode only)
  • If $ARGUMENTS contains --deep → use parallel subagents for deeper review

Repo: NVIDIA-NeMo/RL

Examples:

  • /review-pr 123 — review PR #123, single agent
  • /review-pr 123 --deep — review PR #123 with parallel subagents
  • /review-pr 123 update — follow up on existing threads for PR #123
  • /review-pr — review current branch vs main, terminal output only

Phase 1: Setup

PR mode

git fetch origin pull/$PRNUM/head:pr-$PRNUM-review
git checkout pr-$PRNUM-review

LOCAL mode

Already on the correct branch. Determine the merge base:

git merge-base main HEAD

Phase 2: Gather Context

PR mode — parallel MCP fetches

All with owner=NVIDIA-NeMo, repo=RL, pullNumber=$PRNUM:

  1. mcp__github__pull_request_read method=get → PR title, description, author, base branch, labels, head SHA
  2. mcp__github__pull_request_read method=get_diff → full diff
  3. mcp__github__pull_request_read method=get_files → list of changed files
  4. mcp__github__pull_request_read method=get_review_comments → existing review threads
  5. mcp__github__pull_request_read method=get_reviews → existing reviews
  6. mcp__github__pull_request_read method=get_comments → general PR comments

LOCAL mode — git diff

git diff $(git merge-base main HEAD)..HEAD
git diff $(git merge-base main HEAD)..HEAD --name-only

No MCP calls needed.

Both modes — local reads

  1. Read @CLAUDE.md from repo root for review philosophy
  2. Read all .claude/skills/*/SKILL.md files (except review-pr) for guideline rules
  3. Glob .claude/review-memory/*.md — if any exist, read them for learned patterns

Phase 3: Analyze

Single-agent mode (default)

Analyze all changes yourself. Return a list of candidate issues — each with file, line, category, and description. Do NOT score them yet; scoring happens in the validation step (Phase 3b).

Deep mode (--deep) — parallel subagents

Launch 3 opus subagents in parallel using the Agent tool. Provide each with the diff, PR description (if PR mode), and the guideline skills content. Each returns a list of candidate issues (file, line, category, description). Do NOT ask them to score — scoring happens in Phase 3b.

Subagent 1 — Guideline compliance: Review the diff against all guideline skills (code-style, config-conventions, error-handling, testing, copyright, docs). For each violation, return the file, line, description, and which skill it violates.

Subagent 2 — Bug scan (diff only): Scan for obvious bugs in the diff without reading surrounding context. Flag syntax errors, type errors, clear logic errors, missing imports, unresolved references.

Subagent 3 — Contextual bug scan: Read surrounding code and git history for each changed file. Look for bugs that only become apparent with context: incorrect API usage (especially megatron-bridge, megatron-lm, automodel, gym), race conditions, broken assumptions.

After all subagents return: merge results and deduplicate (same file+line+issue = one finding). Then proceed to Phase 3b.

Analysis rules (all modes)

NEW mode

  • Analyze the diff against all guideline skills
  • For each changed file, read surrounding context locally using Read and Grep to understand the change in context
  • Cross-reference existing review comments (PR mode only, from step 4) to avoid duplicating points already raised by other reviewers
  • Also apply any patterns from review memory files
  • Categorize findings:
    • [BUG] — Logic errors, null refs, race conditions, syntax errors
    • [TEST] — Missing or insufficient test coverage
    • [GUIDELINE] — Violations of coding guidelines from skills
    • [DOC] — Outdated or missing documentation

UPDATE mode (PR mode only)

  • Review all unresolved review threads on the PR
  • For each thread, determine if action is needed:
    1. We disagree with the response → draft a comment like "We can resolve this thread because XYZ"
    2. The author asked a question or made a comment that needs a response → draft an answer
  • CAN also create new comments if you notice something warranted while reviewing threads
  • Skip threads that are resolved or where no response is needed

Phase 3b: Validate & Score

For each candidate issue from Phase 3, launch a separate opus validation subagent using the Agent tool. Launch these in parallel (batch all at once).

Each validation subagent receives:

  • The candidate issue (file, line, category, description)
  • The relevant code context (the diff hunk + surrounding lines)
  • The PR title and description (if PR mode)
  • The specific guideline skill content (if it's a guideline violation)

The validation subagent's job:

  1. Independently verify the issue is real by examining the actual code — e.g., if the issue says "variable is not defined", check that it's actually undefined; if it says a CLAUDE.md/skill rule is violated, confirm the rule applies to this file
  2. Assign a confidence score (0-100):
ScoreMeaning
0Not confident, likely false positive
25Somewhat confident, might be real
50Moderately confident, real but minor
75Highly confident, real and important
100Absolutely certain, definitely real
  1. Return: validated (yes/no), confidence score, and optionally a refined description

Filter: discard any issue scoring below 80. These are the false positives we want to avoid.


Phase 4: Preview & Confirm

Display findings to the user with confidence scores:

PR mode

PR #<number>: <title> (by <author>)
Files changed: <count>

--- Findings (scored ≥80) ---
[BUG 95] path/to/file.py:42 — <brief description>
  Suggested: "<the comment text>"

[GUIDELINE 85] path/to/other.py:15 — <brief description>
  Suggested: "<the comment text>"

--- Filtered (scored <80) ---
N low-confidence issues omitted

--- Skipped (already covered by other reviewers) ---
- <brief list>

--- Thread Responses (<count>) --- (UPDATE mode only)
Thread on file.py:10 (by <author>) — <planned action>
  Suggested reply: "<the reply text>"

Then use AskUserQuestion:

  • Options: (1) Post all — post everything as shown, (2) Discuss individually — go through each item one by one, (3) Cancel — do nothing
  • If user picks "Discuss individually": iterate through items. For each, ask if they want to approve, edit the text, or skip.

LOCAL mode

Branch: <branch-name> (vs main)
Files changed: <count>

--- Findings (scored ≥80) ---
[BUG 95] path/to/file.py:42 — <brief description>
[GUIDELINE 85] path/to/other.py:15 — <brief description>

--- Filtered (scored <80) ---
N low-confidence issues omitted

No posting step — terminal output only. Ask if the user wants to discuss any findings.


Phase 5: Post Review (PR mode only)

New comments (NEW and UPDATE mode)

  1. Create a pending review: mcp__github__pull_request_review_write with method=create, commitID=<head_sha> (no event — creates pending review)
  2. For each approved comment: mcp__github__add_comment_to_pending_review with:
    • path: relative file path
    • line: line number on the RIGHT side of the diff
    • side: RIGHT
    • subjectType: LINE (or FILE if the comment is file-level)
    • body: the comment text
  3. Submit the review: mcp__github__pull_request_review_write with method=submit_pending, event=COMMENT, body=<one-line summary of findings>

If a line number cannot be mapped from the diff, fall back to subjectType: FILE.

Thread replies (UPDATE mode)

For each thread response: mcp__github__add_reply_to_pull_request_comment with:

  • commentId: the ID of the comment being replied to
  • body: the reply text

Phase 6: Update Review Memory

After the review (both PR and LOCAL mode), for each comment/finding the user approved or discussed:

  1. Glob .claude/review-memory/*.md for existing patterns
  2. Check if a file already covers this pattern (by reading titles)
  3. If a matching memory file exists:
    • Add the new occurrence to the ## Occurrences section
    • Ask user: "Pattern '<name>' has come up before. Promote to the <skill-name> skill? (yes/no)"
    • If yes → add as a new subsection in the appropriate skill's SKILL.md, then delete the memory file
    • If no → keep in memory
  4. If no matching memory file exists:
    • Create a new flat file in .claude/review-memory/ with this format:
# <Pattern Name>

**Do:** <what to do instead>
**Don't:** <the anti-pattern>

## Occurrences
- PR #<number>: <file>:<line> (<date>)

Create the .claude/review-memory/ directory if it does not exist (mkdir -p).

What ships with it: 2 files

14.7 KB alongside SKILL.md

Keep looking

Skills are one crate of 326,679. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.