gh-pr-audit
Github Pull Request Audit and Review
Overview
Use this skill to review repository pull requests. If multiple PRs are requested, process them one by one and link all of them in your final output.
The skill fetches each PR locally, analyzes the full diff, runs deterministic checks that already exist in the repository, evaluates GitHub PR checks, and posts a single review verdict with one of three result labels.
Core rule: do not assume tooling
- Never assume Python, pytest, Node, Go, Rust, Docker, or any specific stack.
- Always discover how the repo expects validation to run before executing checks.
- Treat repository guidance as source of truth, especially
AGENTS.md.
Python launcher portability guard
If you need to run this skill's helper script or any Python command, resolve and reuse
PYTHON_BIN first:
PYTHON_BIN="$(command -v python3 || command -v python || true)"
[ -n "$PYTHON_BIN" ] || { echo "No Python interpreter found" >&2; exit 1; }
Never run raw python ... in shell commands.
Quick start
"$PYTHON_BIN" "scripts/review_pr.py" --repo "." --pr "<number-or-url>" --post
Use --json for machine-friendly output.
Use --project-filter projects/<slug> to scope to one subproject.
Use --run-tests only when the impacted project explicitly uses Python + pytest.
The script provides a baseline audit. For full review quality, always run the repository-native checks you discover from project instructions.
Workflow
- Confirm
ghauthentication (gh auth status). - Resolve the PR number from
--pror current branch PR. - Discover repository instructions before running tests/checks:
- Read
AGENTS.mdat repo root and in impacted project paths. - Read local docs that define validation commands (
README*,PROJECT.md,Makefile,justfile, CI workflows, task runner configs).
- Read
- Fetch PR head, fetch base branch, create a detached local worktree at the PR head.
- Gather changed files from
base..head, map file paths to impacted projects. - Build a deterministic check plan from discovered commands, prioritizing:
- commands explicitly required by
AGENTS.mdor project docs - commands used by CI for the same paths
- language/framework-native commands already present in the repo
- commands explicitly required by
- Run checks from that plan and collect concrete evidence (pass/fail, logs, skipped reasons).
- Evaluate GitHub check status (
gh pr checks) and combine with local evidence. - Audit the PR and determine whether the issue was actually resolved with sufficient confidence.
- If
--postis set, apply one label and write one PR comment:
pr-review/approvedpr-review/needs-changespr-review/uncertain
- Return only after a final status and evidence block is produced.
Check discovery guidance
- Prefer explicit repo commands over guessed commands.
- If instructions conflict, prefer the most specific scope (changed project > repo root defaults).
- If a required tool is unavailable locally, report it as a confidence gap and keep the verdict conservative.
- Use fallback generic checks only when the repo provides no usable guidance.
Optional browser fallback with agent-browser-relay
Use local environment or project-defined containers to test implementation. If frontend/browser validation is needed, use agent-browser-relay.
Required relay step pattern:
npm run relay:startnode scripts/read-active-tab.js --check --wait-for-attach ...- proceed only after human confirms Chrome tab attachment.
Outputs
verdict: one ofapproved,needs-changes,uncertainconfidence_percent: numeric confidence scorefindings: file-level and project-level findings with evidencepost_actions: comment and label actions when--postis used
More from mindgames/skills
github-sync
Sync a local Git repository with its remote safely. Use when Codex needs to update a repo before starting work, fast-forward a local branch from `origin`, confirm that local `main` or another branch matches the remote, or prepare an up-to-date base branch before creating a new branch.
3github-pull-request
Use when the user asks to create a pull request. Build a complete PR using best-practice structure with rich details on changes, verification, QA evidence, risks, and rollout notes. Include issue linkage and clear testing commands/results in the PR body.
2branch
Use when a user asks to create a new local git branch and start issue work (for example, "create branch" or "start working on issue XYZ"). Use this for issue-based branch naming in the `type/scope-short-description` pattern and for always syncing local `main` from `origin/main` before creating the new branch, creating the local tracking `main` branch first when needed.
1gh-fix-ci
Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.
1github-issue
Create complete, implementation-ready GitHub issues from user input and publish them with `gh issue create`. Use when asked to create/file/open a new issue in any repository, including cases where requirements must be structured into clear scope, acceptance criteria, constraints, and done-when outcomes.
1gh-address-comments
Help address review/issue comments on the open GitHub PR for the current branch using gh CLI; verify gh auth first and prompt the user to authenticate if not logged in.
1