pr-review

Reviews GitHub pull requests against Notion tickets and posts one grouped review with labeled findings.

Updated Feb 24, 2025
One-click install
npx skills add https://github.com/maarten00/dotfiles --skill pr-review-maarten00
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pr-review
Source: https://github.com/maarten00/dotfiles/tree/main/skills/pr-review
Command: npx skills add https://github.com/maarten00/dotfiles --skill pr-review-maarten00

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing a pull request often means scattered one-off comments, re-running tests CI already ran, and losing track of what the original ticket actually asked for. This Skill enforces a disciplined end-to-end review process so every finding lands in a single grouped GitHub review with consistent severity labels. ## Core Features & Use Cases - Ticket-aware review: Fetches the linked Notion ticket (including its comments) before reading the diff, and flags coverage gaps where the PR misses requirements or builds unrequested behavior. - Delegated code analysis: Hands the code-level review to Claude Code's built-in code-review skill, then merges those findings with ticket-coverage gaps instead of duplicating work. - Grouped review posting: Posts all inline comments plus a summary in one GitHub review API call, with Dutch-language comments, severity/confidence labels (Blocker, Belangrijk, Suggestie, Nit), collapsed technical details, and a mandatory AI footnote. - Use Case: You are asked to review PR #1234. The Skill fetches the linked EXO-1234 ticket from Notion, checks CI status instead of running tests, collects findings, and posts one structured review with labeled inline comments. ## Quick Start Ask the assistant to review pull request 1234 and post the findings as a single grouped GitHub review.

Frequently Asked Questions about pr-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a GitHub pull request with grouped inline comments?▼

Post all findings through GitHub's review API in a single call to repos/OWNER/REPO/pulls/NUMBER/reviews, attaching every inline comment to one review event. This avoids firing separate events per comment and gives watchers one complete set of findings.

How do I check a pull request against a Notion ticket?▼

Fetch the Notion page linked in the PR body or referenced by an EXO-XXXX tag, and also read the ticket's comments since requirements may be revised there. Then compare the diff against the ticket and flag missing coverage or unrequested behavior as findings.

Should I run tests locally when reviewing a pull request?▼

No, CI already runs the test suite on every pull request, so read the result with gh pr checks instead. Only run something locally when the review hinges on behavior CI does not cover and reading the code cannot settle it.

What severity labels should code review comments use?▼

Use four levels: Blocker for must-fix bugs, Belangrijk for should-fix issues, Suggestie for optional improvements, and Nit for cosmetic remarks. Pair each with a confidence label (zeker, vrij zeker, twijfel) and never mark something Blocker below vrij zeker confidence.

When should I use REQUEST_CHANGES instead of COMMENT on a GitHub review?▼

Default to the COMMENT event for review submissions. Only use REQUEST_CHANGES or APPROVE when explicitly asked, and note that GitHub refuses to let you approve your own pull request.