Reviewing a PR on a Personal/OSS Repo
Default posture: maintainer reviewing an external contribution (or a fellow contributor's PR on a repo
you don't own) — no internal CODEOWNERS scope, no Jira/Collibra conventions apply.
1. Resolve PR & Materialize Diff
- Identify PR via arg (
/review-pr-oss 456, URL, branch) or current branch
(gh pr view --json number,url,headRefName,baseRefName).
- Materialize in an isolated worktree:
git fetch origin pull/<number>/head:review-pr-<number>
git worktree add /tmp/review-pr-<number> review-pr-<number>
- Run git commands inside
/tmp/review-pr-<number>. Changed files via
git diff <base>...<head> --name-only, full diff via gh pr diff <number>.
- Clean up worktree (
git worktree remove) when finished.
2. Full-Diff Scope (No CODEOWNERS Gate)
Review the entire diff — an OSS repo's CODEOWNERS (if any) marks notification routing, not review
boundaries. Note in the report if a CODEOWNERS file exists and who else it flags for this diff.
3. Gather Guidance
Combine, in order of specificity:
- Repo's own rules:
CONTRIBUTING.md, CLAUDE.md/AGENTS.md, .github/* style docs — these are
authoritative over any personal default.
- Language persona skills:
jvm, python, rust, scala for the detected extensions.
- Sign-off/CLA requirement: check
CONTRIBUTING.md and workflow names for DCO/CLA bots; flag a
missing Signed-off-by: trailer as a blocking finding if the repo requires it.
4. Delegate Review
Execute pr-review-toolkit:review-pr inside the worktree directory against the full
<base>...<head> diff, passing the combined guidance from §3 as additional criteria. No external-team
persona override — review as a knowledgeable maintainer/contributor.
5. Deduplicate Against Existing Comments
gh api repos/<owner>/<repo>/pulls/<number>/comments
gh api repos/<owner>/<repo>/pulls/<number>/reviews
Drop findings matching an existing comment on the same file/line/hunk; keep distinct new issues on the
same line.
6. Prepare Findings & Get Confirmation Before Posting
Never call the GitHub API to post anything until the user has explicitly approved the exact content.
- Get the head commit SHA:
gh pr view <number> --json headRefOid -q .headRefOid.
- For each finding, resolve
path, line (from the file in the worktree, not hand-counted diff
offsets), and side: "RIGHT" ("LEFT" only for a finding about deleted code).
- Never post Strengths/positive-only observations as comments. Only draft actionable findings
(issue/suggestion/nit/question).
- Build the exact
review.json payload. No overview/summary top-level comment — inline findings only,
plus a separate draft for genuine cross-cutting findings that can't anchor to a line:{
"commit_id": "<headRefOid>",
"event": "COMMENT",
"comments": [
{"path": "...", "line": 123, "side": "RIGHT", "body": "**label**: point [fix]"}
]
}
- Show the user the full draft before posting: every inline comment rendered as
path:line — **label**: text, plus any top-level-only comments. This is the actual content to be
posted, not a paraphrase.
- Stop and wait for approval. Anything other than a clear go-ahead is a revision request — edit and
re-show the draft.
Findings Format:
- Group by severity: Critical / Important / Suggestions.
- 1–2 sentences per finding (
**label**: point [fix]) — no repeated path:line inside comment bodies.
- Labels: issue, suggestion, nit, question.
- No raw tool transcripts, long code blocks, or section headers like "Impact:".
7. Post Findings as Inline PR Comments
Only after approval:
- Batch into one review call:
gh api repos/<owner>/<repo>/pulls/<number>/reviews --input review.json.
If the API rejects an empty body for event: "COMMENT", drop the batch and post each inline
finding individually via gh api repos/<owner>/<repo>/pulls/<number>/comments instead.
- Post any approved top-level-only findings via
gh pr comment.
8. Report to User
Short chat summary: counts by severity, link to the review (html_url), sign-off/CLA status, and
number of dropped duplicate findings.
1---2name: review-pr-oss3description: Review a PR on a personal or open-source GitHub repo. No CODEOWNERS/team scoping — reviews the full diff, detects languages, applies the repo's own CONTRIBUTING.md/CLAUDE.md rules + language persona skills, checks DCO/CLA sign-off, and delegates to pr-review-toolkit:review-pr.4---56# Reviewing a PR on a Personal/OSS Repo78Default posture: maintainer reviewing an external contribution (or a fellow contributor's PR on a repo9you don't own) — no internal CODEOWNERS scope, no Jira/Collibra conventions apply.1011## 1. Resolve PR & Materialize Diff121. Identify PR via arg (`/review-pr-oss 456`, URL, branch) or current branch13 (`gh pr view --json number,url,headRefName,baseRefName`).142. Materialize in an isolated worktree:15 ```bash16 git fetch origin pull/<number>/head:review-pr-<number>17 git worktree add /tmp/review-pr-<number> review-pr-<number>18 ```193. Run git commands inside `/tmp/review-pr-<number>`. Changed files via20 `git diff <base>...<head> --name-only`, full diff via `gh pr diff <number>`.214. Clean up worktree (`git worktree remove`) when finished.2223## 2. Full-Diff Scope (No CODEOWNERS Gate)24Review the entire diff — an OSS repo's CODEOWNERS (if any) marks notification routing, not review25boundaries. Note in the report if a CODEOWNERS file exists and who else it flags for this diff.2627## 3. Gather Guidance28Combine, in order of specificity:29- **Repo's own rules**: `CONTRIBUTING.md`, `CLAUDE.md`/`AGENTS.md`, `.github/*` style docs — these are30 authoritative over any personal default.31- **Language persona skills**: `jvm`, `python`, `rust`, `scala` for the detected extensions.32- **Sign-off/CLA requirement**: check `CONTRIBUTING.md` and workflow names for DCO/CLA bots; flag a33 missing `Signed-off-by:` trailer as a blocking finding if the repo requires it.3435## 4. Delegate Review36Execute `pr-review-toolkit:review-pr` inside the worktree directory against the full37`<base>...<head>` diff, passing the combined guidance from §3 as additional criteria. No external-team38persona override — review as a knowledgeable maintainer/contributor.3940## 5. Deduplicate Against Existing Comments41```bash42gh api repos/<owner>/<repo>/pulls/<number>/comments43gh api repos/<owner>/<repo>/pulls/<number>/reviews44```45Drop findings matching an existing comment on the same file/line/hunk; keep distinct new issues on the46same line.4748## 6. Prepare Findings & Get Confirmation Before Posting49Never call the GitHub API to post anything until the user has explicitly approved the exact content.50511. Get the head commit SHA: `gh pr view <number> --json headRefOid -q .headRefOid`.522. For each finding, resolve `path`, `line` (from the file in the worktree, not hand-counted diff53 offsets), and `side: "RIGHT"` (`"LEFT"` only for a finding about deleted code).543. Never post **Strengths**/positive-only observations as comments. Only draft actionable findings55 (issue/suggestion/nit/question).564. Build the exact `review.json` payload. No overview/summary top-level comment — inline findings only,57 plus a separate draft for genuine cross-cutting findings that can't anchor to a line:58 ```json59 {60 "commit_id": "<headRefOid>",61 "event": "COMMENT",62 "comments": [63 {"path": "...", "line": 123, "side": "RIGHT", "body": "**label**: point [fix]"}64 ]65 }66 ```675. Show the user the full draft before posting: every inline comment rendered as68 `path:line — **label**: text`, plus any top-level-only comments. This is the actual content to be69 posted, not a paraphrase.706. Stop and wait for approval. Anything other than a clear go-ahead is a revision request — edit and71 re-show the draft.7273Findings Format:74- Group by severity: Critical / Important / Suggestions.75- 1–2 sentences per finding (`**label**: point [fix]`) — no repeated `path:line` inside comment bodies.76- Labels: **issue**, **suggestion**, **nit**, **question**.77- No raw tool transcripts, long code blocks, or section headers like "Impact:".7879## 7. Post Findings as Inline PR Comments80Only after approval:811. Batch into one review call: `gh api repos/<owner>/<repo>/pulls/<number>/reviews --input review.json`.82 If the API rejects an empty `body` for `event: "COMMENT"`, drop the batch and post each inline83 finding individually via `gh api repos/<owner>/<repo>/pulls/<number>/comments` instead.842. Post any approved top-level-only findings via `gh pr comment`.8586## 8. Report to User87Short chat summary: counts by severity, link to the review (`html_url`), sign-off/CLA status, and88number of dropped duplicate findings.
austek