Agent skill

OpenROAD PR Review

by The-OpenROAD-Project in The-OpenROAD-Project/OpenROAD

Reviews an OpenROAD pull request in the project's priority order and prints draft review notes for a human reviewer to inspect and post.

BSD-3-ClauseAuto-check passedDevelopment

Install OpenROAD PR Review

skills CLI
$ npx skills add The-OpenROAD-Project/OpenROAD --skill review-pr -a claude-code

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

GitHub CLI
$ gh skill install The-OpenROAD-Project/OpenROAD review-pr --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/The-OpenROAD-Project/OpenROAD.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/review-pr .claude/skills/review-pr && 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
review-pr
GitHub stars
3.2k
Token cost
~1.4k tokens
SKILL.md length
618 words
Files
1
Skills in repo
4
Repo updated
First seen
Licence
BSD-3-Clause

At a glance

Reviews an OpenROAD pull request in the project's priority order and prints draft review notes for a human reviewer to inspect and post.

  • Works in 3 steps: Fetch PR context → Review by priority order → Draft the review locally (do not post to…
  • Reviewing an OpenROAD pull request before approving it
  • SKILL.md covers 1. Fetch PR context, 2. Review by priority order and 3. Draft the review locally…
  • Calls gh

What it does

Given a PR number or full GitHub URL, the skill normalizes it to a PR number and repository, so fork URLs are not mismatched, then fetches the title, body, labels, files and line counts with `gh pr view`. It identifies the affected modules from file paths, the change type and the scope before reviewing in the project's priority order: correctness, QoR impact, testing, architecture, style and process.

Correctness gets the most attention: iterator invalidation, use-after-free with database objects, off-by-one errors, integer overflow in area calculations, null dereferences, unreachable code and suppressed tests, and files under `src/sta/` must not be changed because OpenSTA is managed upstream. QoR-affecting changes need validation on real designs rather than a single design or unit tests, and tests must be registered in both CMake and Bazel. The output is draft notes only, which the human reviewer inspects and posts manually.

When your agent uses it

  • Reviewing an OpenROAD pull request before approving it
  • Checking whether a change affects QoR and needs design-level validation
  • Spotting missing CMake or Bazel test registration

Example prompts

  • “Review the OpenROAD pull request at the URL I pasted and give me draft notes to post myself.”
  • “Check this PR for use-after-free and integer overflow problems in the resizer code.”
  • “Does this change need QoR validation, and are its tests registered in both build systems?”

Requirements

  • The GitHub CLI (`gh`)

Workflow steps

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

  1. Fetch PR context
  2. Review by priority order
  3. Draft the review locally (do not post to GitHub)

What it can do on your machine

Read from SKILL.md and the folder at commit 821ecb8. 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

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

  • Network

    No URLs in SKILL.md. Its commands use gh, 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

OpenROAD PR Review loads about 1.4k tokens when it runs. Until then it costs about 129 tokens; SKILL.md has 618 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~129
When it runs · the whole SKILL.md, loaded when a task matches
~1.4k

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 The-OpenROAD-Project/OpenROAD at commit 821ecb8, republished under its BSD-3-Clause licence (© The-OpenROAD-Project). 618 words, ~1,427 tokens.

Download SKILL.mdSave it as .claude/skills/review-pr/SKILL.md (or your agent's skills folder).
name
review-pr
description
Review an OpenROAD pull request following the project's review priority order: correctness > QoR impact > testing > architecture > style > process. Fetches PR diff, analyzes changes, and prints draft review notes for the human reviewer to inspect and post manually. Use when asked to review a PR, check a pull request, look at changes, or provide code review for any OpenROAD module. Also triggers on: "review PR", "check this PR", "look at pull request", "code review", "review changes", "review #NUMBER".
argument-hint
<pr-number-or-url>

Review OpenROAD Pull Request

You are reviewing PR $ARGUMENTS.

$ARGUMENTS may be either:

  • A bare PR number (e.g. 10062)
  • A full GitHub PR URL (e.g. https://github.com/The-OpenROAD-Project/OpenROAD/pull/10062)

Normalize first. Before running any gh command, decide what $ARGUMENTS is and bind two shell variables:

  • If $ARGUMENTS is a bare number: PR=$ARGUMENTS and REPO=The-OpenROAD-Project/OpenROAD.
  • If $ARGUMENTS is a URL: extract the trailing number into PR, and extract <owner>/<repo> from the URL path into REPO. This matters because URLs from forks (or any non-canonical mirror) point at a different repo, and passing --repo The-OpenROAD-Project/OpenROAD with such a URL silently mismatches.

1. Fetch PR context

bash
gh pr view "$PR" --repo "$REPO" \
  --json title,body,labels,files,additions,deletions,baseRefName

gh pr diff "$PR" --repo "$REPO"

Identify:

  • Modules affected -- from file paths (e.g., src/rsz/ = resizer)
  • Change type -- bug fix, feature, refactor, test, docs
  • Scope -- number of files and lines changed

2. Review by priority order

Follow CONTRIBUTING.md review priorities exactly. Spend most effort on the top priorities and less on lower ones.

Priority 1: Correctness (most important)

Flag any code that could silently produce wrong output. An explicit error is always preferable to silently incorrect behavior.

Check for:

  • Iterator invalidation -- modifying a container while iterating
  • Use-after-free -- especially with ODB objects that may be deleted
  • Off-by-one errors -- in loop bounds, coordinate calculations
  • Integer overflow -- area calculations must use int64_t
  • Null pointer dereference -- but don't add overly defensive checks for objects that cannot be null
  • Unreachable code -- code after error() or throw should be removed
  • Suppressed tests -- if a test is disabled, ask whether it hides a bug
  • src/sta/ modifications -- these files must NOT be modified (OpenSTA is managed upstream)
Priority 2: QoR Impact

Any change affecting placement, routing, timing, or physical design:

  • Ask: "Does this have a QoR impact?"
  • QoR-affecting changes need validation on real designs, not just unit tests
  • Be skeptical of improvements claimed from a single design
Priority 3: Testing
  • Does every code change have an accompanying test?
  • Are tests registered in both CMake and Bazel?
  • Do golden files look reasonable?
  • Are test inputs minimal?
Priority 4: Architecture
  • OpenROAD is single-process, single-database
  • Watch for memory cost in heavily-instantiated classes (dbITerm, etc.)
  • Check ODB schema changes require a revision bump
Priority 5: Style

Don't flag issues handled by clang-format or clang-tidy. Only flag:

  • Missing const qualifiers
  • C-style casts (should use C++ casts)
  • Missing braces on single-line statements
  • Functions exceeding 100 lines
Show full SKILL.md (243 more words)Show less
Priority 6: Process
  • PR focused on one bug or feature?
  • Style fixes in separate commits?
  • References an open issue for non-trivial changes?

3. Draft the review locally (do not post to GitHub)

Important: This skill never posts comments to GitHub. AI-generated review comments can be noisy or wrong, and posting them directly to a public PR creates work for maintainers and erodes trust in human review. The human reviewer must read your draft, edit it, and decide what (if anything) to submit.

Print your draft review to the terminal for the human to inspect. Use this format so it is easy to copy specific items into the GitHub UI:

PR #<num>: <title>
Modules: <list>

== Priority 1 (correctness) ==
- <file>:<line>  bug: <one-line description>
- <file>:<line>  question: <one-line question>

== Priority 2 (QoR) ==
- <file>:<line>  question: does this affect placement/routing/timing on real designs?

== Priority 3 (testing) ==
- <observation about test coverage, dual-registration, golden files>

== Priority 4-6 (architecture / style / process) ==
- <only if material -- skip what clang-format/clang-tidy already covers>

== Overall ==
- <one or two sentences: LGTM, needs changes, or questions before approval>
Drafting style

Be concise. One-word or one-sentence items when the issue is clear (e.g., "const", "unreachable after throw", "int64_t for area").

Ask probing questions for non-obvious issues rather than prescribing fixes:

  • "Have you tested this on a real design?"
  • "Could this hide a bug?"
  • "What happens if this is null?"

Lead with severity: bug:, nit:, question:, suggestion:.

Group related issues rather than listing each line separately.

Don't generate PR summaries unless asked.

Do not flag issues already handled by clang-format or clang-tidy.

If the PR is clean, say so briefly: "LGTM -- correctness and testing look solid."

After printing the draft, stop. Do not call gh pr review, gh pr comment, gh api .../comments, or any other command that posts to the PR. The human will copy what they want into the GitHub web UI.

© The-OpenROAD-Project, BSD-3-Clause. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/review-pr of The-OpenROAD-Project/OpenROAD.

Open the folder on GitHubat commit 821ecb8

Compare with similar skills

OpenROAD PR Review 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.

OpenROAD PR Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
OpenROAD PR Review this skillThe-OpenROAD-Project/OpenROAD3.2k—~1.4kAutomated safety check: PassBSD-3-Clause
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
PR Finalize Reviewmicrosoft/garnet12k—~3.1kAutomated safety check: PassMIT
Fastlane Pull Request Reviewfastlane/fastlane42k—~550Automated safety check: PassMIT

Similar skills

  • 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 yesterday
    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 yesterday
    DevelopmentAuto-check passed
  • 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 yesterday
    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
  • Pull Request Babysitter

    thedotmack/claude-mem

    Keeps watching a pull request, fixing real review and CI problems and resolving stale threads, until it is clean and ready to merge.

    99k GitHub stars~1.1k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

More from The-OpenROAD-Project/OpenROAD

  • OpenROAD Module Test Adder

    The-OpenROAD-Project/OpenROAD

    Adds integration or unit tests to an OpenROAD module: writes the Tcl test, generates golden files and registers it in both CMake and Bazel.

    3.2k GitHub stars~1.8k tokensUpdated today
    Auto-check passed
  • OpenROAD Bug Fixer

    The-OpenROAD-Project/OpenROAD

    Fixes an OpenROAD bug from a GitHub issue or error code: finds the root cause, implements the fix, adds a regression test and prepares a signed-off commit.

    3.2k GitHub stars~784 tokensUpdated today
    Auto-check passed
  • OpenROAD Issue Triage

    The-OpenROAD-Project/OpenROAD

    Reproduces an OpenROAD GitHub bug from an attached tarball and shrinks the failing design with whittle.py so maintainers get a minimal test case.

    3.2k GitHub stars~842 tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about OpenROAD PR Review

What does OpenROAD PR Review do?

Reviews an OpenROAD pull request in the project's priority order and prints draft review notes for a human reviewer to inspect and post. Given a PR number or full GitHub URL, the skill normalizes it to a PR number and repository, so fork URLs are not mismatched, then fetches the title, body, labels, files and line counts with `gh pr view`. It identifies the affected modules from file paths, the change type and the scope before reviewing in the project's priority order: correctness, QoR impact, testing, architecture, style and process.

When should I use OpenROAD PR Review?

OpenROAD PR Review fits situations like: reviewing an OpenROAD pull request before approving it; checking whether a change affects QoR and needs design-level validation; spotting missing CMake or Bazel test registration.

How do I install OpenROAD PR Review in Claude Code?

Run `npx skills add The-OpenROAD-Project/OpenROAD --skill review-pr -a claude-code`. Or copy the skill folder (.agents/skills/review-pr in The-OpenROAD-Project/OpenROAD) into .claude/skills/review-pr in your project. Claude Code loads it when a task matches its description.

How do I install OpenROAD PR Review in Codex?

Run `npx skills add The-OpenROAD-Project/OpenROAD --skill review-pr -a codex`. Or copy the skill folder (.agents/skills/review-pr in The-OpenROAD-Project/OpenROAD) into .agents/skills/review-pr in your project. Codex loads it when a task matches its description.

Can I use OpenROAD PR Review 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 The-OpenROAD-Project/OpenROAD --skill review-pr -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/review-pr, .gemini/skills/review-pr, .github/skills/review-pr and .opencode/skills/review-pr in your project.

What does OpenROAD PR Review need to run?

Going by SKILL.md and its folder, OpenROAD PR Review needs the command-line tools its instructions call (gh). Our summary lists: The GitHub CLI (`gh`).

Does OpenROAD PR Review access the network?

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

Is OpenROAD PR Review 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 OpenROAD PR Review use?

OpenROAD PR Review is published under the BSD-3-Clause licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does OpenROAD PR Review use?

About 1.4k tokens (SKILL.md is roughly 5.7k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to OpenROAD PR Review?

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

Who maintains OpenROAD PR Review?

The-OpenROAD-Project (a GitHub organization) maintains it in The-OpenROAD-Project/OpenROAD, which has 3,161 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on October 11, 2026.

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