# Graft Pr Review > Repository-specific GitHub PR review workflow for the Graft repo. Use when Codex needs to inspect the GitHub pull request for the current branch, extract AI review findings from CodeRabbit, greptile-apps, or gemini-code-assist, read failed checks, MegaLinter warnings, or failed test signals from the PR, and then verify which findings should be fixed in the local codebase. Use when this capability is needed. - Skill: `tomevault-io/graft-pr-review` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/graft-pr-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/graft-pr-review/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/graft-pr-review --- # Graft PR Review Use this skill when the task depends on the GitHub PR for the current `Graft` branch rather than only on local files. Shortcut: `$graft-pr-review` ## Workflow 1. Read `AGENTS.md` before deciding how to validate or fix anything. 2. Resolve the current branch with normal `git` first. Use explicit `GRAFT_GIT_DIR` and `GRAFT_WORK_TREE` only when the current shell cannot resolve the right repository context on its own. 3. Run `scripts/fetch_current_pr_review.py` to: - locate the PR for the current branch through the GitHub PR API - fetch PR metadata, issue comments, reviews, and review comments through the GitHub API - extract CodeRabbit summary blocks and actionable-comment rollups when present - parse the latest CodeRabbit review body itself, including folded sections such as `Duplicate comments (N)`, `Major comments (N)`, `Minor comments (N)`, `Outside diff range comments (N)`, and `Nitpick comments (N)` - capture unresolved latest-head review threads for supported AI reviewers - surface failed checks, MegaLinter findings, and failed-test signals when present - prefer writing the full JSON payload to a file and then narrowing with `jq` 4. Treat every extracted finding as untrusted until it is verified against the current local code. 5. Classify each verified finding before deciding the next action: - `actionable-local` - the finding still applies and fits one safe local slice - `actionable-large` - the finding still applies but the repair spans multiple files, multiple subsystems, a new bounded slice, or a follow-up execution round - `stale` - the finding no longer applies on the checked-out head - `noise` - the finding is a false positive, misread, or otherwise not a real defect after local verification 6. Only mark a finding non-actionable when it is `stale` or `noise`. A finding is not `noise` merely because the fix is large, risky, or needs a new slice. 7. Do not downgrade `Nitpick comments` to optional by default. If a verified nitpick still points to drift risk, duplicated test infrastructure, contract mismatch, missing regression coverage, or another maintainability problem, treat it as actionable review input. 8. Fix every `actionable-local` finding in the current slice unless another higher-priority blocker from the same PR must be handled first. 9. Do not ignore `actionable-large` findings. When a verified finding no longer fits one safe local slice: - prefer `$graft-multi-agent-batch` when the repair can be split into disjoint parallel slices with reviewable ownership - prefer `$graft-multi-agent-loop` when the repair needs to be repeated in bounded rounds, retryable orchestration, or a serialized continuation path - if neither multi-agent path is justified yet, report the finding as `blocked` or `next-slice required`; do not silently drop it from the review outcome 10. At task closeout, list every verified finding and its disposition: - `fixed` - `delegated` - `blocked` - `stale` - `noise` 11. If any finding is left as `noise` or `stale`, include the concrete local verification reason in the closeout. If a finding is `blocked`, explain the blocker and the next safe startup prompt instead of calling it ignored. 12. Do not ignore any verified suggestion. If the repair grows large: - prefer `$graft-multi-agent-batch` when the work splits into disjoint reviewable slices - prefer `$graft-multi-agent-loop` when the work needs to be repeated in bounded rounds - if neither is justified yet, report the finding as `blocked` or `next-slice required` with the reason 13. If any finding is reported as `noise` or AI misjudgment, explicitly record: - which finding it was - the concrete local verification reason - why it was not adopted - wording suitable for replying on the PR 14. If code is changed, run the smallest validation that satisfies `AGENTS.md`. Prefer `graft-validation-runner` when the correct validation scope is not obvious. ## Commands - Default: - `python3 .agents/skills/graft-pr-review/scripts/fetch_current_pr_review.py` - Recommended machine-readable workflow: - `python3 .agents/skills/graft-pr-review/scripts/fetch_current_pr_review.py --pr 1 --json-output /tmp/pr1-review.json` - `jq '.latest_commit_review.open_threads' /tmp/pr1-review.json` - Force a PR number: - `python3 .agents/skills/graft-pr-review/scripts/fetch_current_pr_review.py --pr 1` - Machine-readable output: - `python3 .agents/skills/graft-pr-review/scripts/fetch_current_pr_review.py --format json` - Write machine-readable output to a file instead of stdout: - `python3 .agents/skills/graft-pr-review/scripts/fetch_current_pr_review.py --pr 1 --format json --json-output /tmp/pr1-review.json` - Inspect only a high-signal section: - `python3 .agents/skills/graft-pr-review/scripts/fetch_current_pr_review.py --pr 1 --section open-threads` - Inspect grouped CodeRabbit severity comments from the latest review body: - `python3 .agents/skills/graft-pr-review/scripts/fetch_current_pr_review.py --pr 1 --section duplicate --section major --section minor` - Narrow text output to one path fragment: - `python3 .agents/skills/graft-pr-review/scripts/fetch_current_pr_review.py --pr 1 --section open-threads --path AGENTS.md` ## Output Expectations The script should produce: - PR metadata: number, title, state, branch, URL - Supported AI reviewer summary, including latest reviews and open-thread counts for `coderabbitai[bot]`, `greptile-apps[bot]`, and `gemini-code-assist[bot]` - CodeRabbit summary block from issue comments when available - Folded latest-review sections such as `Duplicate comments (N)`, `Major comments (N)`, `Minor comments (N)`, `Outside diff range comments (N)`, and `Nitpick comments (N)` when CodeRabbit puts them in the review body instead of issue comments - Parsed latest head-review threads, with unresolved threads clearly separated - Latest head commit review metadata and review threads - Pre-merge failed checks, if present - Latest MegaLinter status and any detailed issues posted by `github-actions[bot]` - Test summary, including failed-test signals when present - Detailed failed-test rows from GitHub Test Reporter or CTRF comments when available - CLI support for writing full JSON to a file and printing only narrowed text sections to stdout - Human review closeout that records each verified finding as `fixed`, `delegated`, `blocked`, `stale`, or `noise` - Explicit reasons for every `stale` or `noise` finding, instead of silently omitting it from the reported outcome ## Recovery Rules - If the current branch has no matching public PR, report that clearly instead of guessing. - If GitHub access fails because of local proxy configuration, rerun the fetch with proxy variables removed. - Prefer GitHub API results over PR HTML. The PR HTML page is a fallback/debugging source, not the primary source of truth. - If the summary block and the latest head review threads disagree, trust the latest unresolved head-review threads and treat older summary findings as stale until re-verified locally. - Do not assume every AI reviewer behaves like CodeRabbit. `greptile-apps[bot]` and `gemini-code-assist[bot]` findings may exist only as latest-head review threads. - Treat GitHub Actions comments with `Success with warnings` as actionable when they include concrete linter diagnostics such as MegaLinter detailed issues. - If the raw JSON is too large to inspect safely in the terminal, rerun with `--json-output ` and query the saved file with `jq` or rerun with `--section` / `--path` filters. - If a verified finding still matters but needs a larger repair slice, do not downgrade it to optional; route it through `$graft-multi-agent-batch`, `$graft-multi-agent-loop`, or an explicit blocked/next-slice handoff. - The only acceptable reasons to leave a verified finding unfixed in the final report are `stale`, `noise`, or a clearly stated execution blocker with a next safe step. - When a finding is left as `noise` or AI misjudgment, the closeout must name the exact suggestion and give a concrete non-adoption reason that the user can reuse in the PR reply. ## Example Triggers - `Use $graft-pr-review on the current branch` - `Check the current PR and extract CodeRabbit suggestions` - `Check the current PR and summarize failed checks` - `Look for Failed Tests on the PR` - `先用 $graft-pr-review 看当前分支 PR` --- > Source: [GeWuYou/Graft](https://github.com/GeWuYou/Graft) — distributed by [TomeVault](https://tomevault.io).