pr-review

Name: pr-review
Author: faizkhairi

61stars19forks

How to install pr-review?

faizkhairi/claude-code-blueprint/pr-review

$npx -y skills add faizkhairi/claude-code-blueprint --skill pr-review

Installs into the current project.

Summary

Review and post feedback on a GitHub or Gitea pull request end-to-end: fetch the PR diff, run a multi-agent code review, and auto-post the verdict as a real PR review (approve/request-changes/comment) via the platform's API. Triggers on: 'review this PR', 'review PR #N', 'check t

Files · 1

View on GitHub

SKILL.md

1	This posts a REAL review to GitHub or Gitea (comments, and an approve/request-changes/comment verdict). It fetches a pull request's diff, runs the same multi-agent analysis as `review-full`, applies any project-specific review rules, then submits the review via the platform's API. For reviewing local diffs that aren't an open PR, use `review-full` or `review-diff` instead.
2
3	## Step 0: Resolve the PR and detect the platform
4
5	- Determine the target PR from `$ARGUMENTS` (a number or URL). If empty, detect the PR for the current branch.
6	- Detect the git host from `git remote get-url origin`:
7	- `github.com` -> GitHub. Use the `gh` CLI (assume it is already authenticated).
8	- Anything else (self-hosted Gitea/Forgejo/Gogs, e.g. a company git server) -> Gitea-style REST API via `curl`.
9	- For Gitea, locate this project's own credentials rather than asking every time:
10	- Check whether the project's `CLAUDE.md` `@import`s a credentials file (commonly `rules/credentials.md`; this mirrors a common per-project credentials-import convention).
11	- If none is found, ask the user for the base URL and a `username:token`, and offer to save them into a new, gitignored file (e.g. `rules/credentials.md`). Never write real secrets into a tracked file, an `.example` template, or any file already committed to git.
12
13	## Step 1: Load PR context
14
15	- Fetch PR metadata (title, author, base/head branch, mergeable state, description) and the unified diff:
16	- GitHub: `gh pr view <N> --json title,author,baseRefName,headRefName,mergeable,body`, `gh pr diff <N>`
17	- Gitea: `GET /repos/{owner}/{repo}/pulls/{n}` and `GET /repos/{owner}/{repo}/pulls/{n}.diff`
18	- Count `diff --git` headers in the diff and record the file count (checked again in Step 5).
19	- Determine reviewer identity. Compare the authenticated account against the PR author:
20	- GitHub: `gh api user --jq .login`
21	- Gitea: the username from the credentials file
22	- Record whether this is a self-review (author == reviewer). Both platforms reject `APPROVE`/`REQUEST_CHANGES` on your own PR, so a self-review always posts as `COMMENT`.
23	- Check for a prior review from this reviewer account (`gh api repos/{o}/{r}/pulls/{n}/reviews`, or the Gitea equivalent):
24	- No prior review -> first-pass review.
25	- Prior review exists -> list commits and check for any commit after that review's `submitted_at`.
26	- New commits -> re-review mode: only findings still present in the new diff are valid; call out previously-flagged items now fixed.
27	- No new commits -> stop and report "No new commits since my last review: nothing to re-review." Do not re-run the full checklist.
28
29	## Step 2: Load project-specific review rules (if any)
30
31	- Read the target project's `CLAUDE.md`. If it `@import`s rule files (naming conventions, architecture patterns, framework-specific rules, etc.), read those too and apply them in Step 4 alongside the generic checks.
32	- If the project defines a cross-module impact table (e.g. "field X renamed -> grep the other repo for consumers"), run it: for each matching pattern in the diff, grep the referenced codebase paths, read every hit, and record any broken consumer as a finding.
33	- If the project has no documented review rules, proceed with the generic checks only. Do not invent stack-specific rules that aren't written down anywhere.
34
35	## Step 3: Determine PR scope
36
37	Look at the diff's file paths to scope which rules apply (e.g. frontend-only, backend-only, or mixed changes) and skip rules tagged for the side the PR doesn't touch.
38
39	## Step 4: Multi-agent analysis
40
41	Follow the `review-full` skill's Steps 1-6 (spawn `code-reviewer`, `security-reviewer`, `db-analyst`, and `architecture-reviewer` as applicable) using the fetched PR diff as the change set, plus any project-specific rules loaded in Step 2. Produce the standard findings table:
42
43	```
44	\| # \| Severity \| File:Line \| Finding \| Recommendation \|
45	```
46
47	## Step 5: Mandatory self-verification (do not skip; runs before posting)
48
49	1. Grep verification. For every project-specific "must fix"-style rule with a greppable pattern, re-run the grep against the diff and confirm every match is either included as a finding or explicitly justified as not a violation.
50	2. Rule/agent coverage line. State which agents ran and which project rules were checked, e.g. "checked code-reviewer, security-reviewer, rules A1-A2, G1-G8: N rules/checks in scope, M fin

People who liked this also viewed

6 picks

Type

pr-review

61stars19forks

View on GitHub

How to install pr-review?

faizkhairi/claude-code-blueprint/pr-review

$npx -y skills add faizkhairi/claude-code-blueprint --skill pr-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	This posts a REAL review to GitHub or Gitea (comments, and an approve/request-changes/comment verdict). It fetches a pull request's diff, runs the same multi-agent analysis as `review-full`, applies any project-specific review rules, then submits the review via the platform's API. For reviewing local diffs that aren't an open PR, use `review-full` or `review-diff` instead.
2
3	## Step 0: Resolve the PR and detect the platform
4
5	- Determine the target PR from `$ARGUMENTS` (a number or URL). If empty, detect the PR for the current branch.
6	- Detect the git host from `git remote get-url origin`:
7	- `github.com` -> GitHub. Use the `gh` CLI (assume it is already authenticated).
8	- Anything else (self-hosted Gitea/Forgejo/Gogs, e.g. a company git server) -> Gitea-style REST API via `curl`.
9	- For Gitea, locate this project's own credentials rather than asking every time:
10	- Check whether the project's `CLAUDE.md` `@import`s a credentials file (commonly `rules/credentials.md`; this mirrors a common per-project credentials-import convention).
11	- If none is found, ask the user for the base URL and a `username:token`, and offer to save them into a new, gitignored file (e.g. `rules/credentials.md`). Never write real secrets into a tracked file, an `.example` template, or any file already committed to git.
12
13	## Step 1: Load PR context
14
15	- Fetch PR metadata (title, author, base/head branch, mergeable state, description) and the unified diff:
16	- GitHub: `gh pr view <N> --json title,author,baseRefName,headRefName,mergeable,body`, `gh pr diff <N>`
17	- Gitea: `GET /repos/{owner}/{repo}/pulls/{n}` and `GET /repos/{owner}/{repo}/pulls/{n}.diff`
18	- Count `diff --git` headers in the diff and record the file count (checked again in Step 5).
19	- Determine reviewer identity. Compare the authenticated account against the PR author:
20	- GitHub: `gh api user --jq .login`
21	- Gitea: the username from the credentials file
22	- Record whether this is a self-review (author == reviewer). Both platforms reject `APPROVE`/`REQUEST_CHANGES` on your own PR, so a self-review always posts as `COMMENT`.
23	- Check for a prior review from this reviewer account (`gh api repos/{o}/{r}/pulls/{n}/reviews`, or the Gitea equivalent):
24	- No prior review -> first-pass review.
25	- Prior review exists -> list commits and check for any commit after that review's `submitted_at`.
26	- New commits -> re-review mode: only findings still present in the new diff are valid; call out previously-flagged items now fixed.
27	- No new commits -> stop and report "No new commits since my last review: nothing to re-review." Do not re-run the full checklist.
28
29	## Step 2: Load project-specific review rules (if any)
30
31	- Read the target project's `CLAUDE.md`. If it `@import`s rule files (naming conventions, architecture patterns, framework-specific rules, etc.), read those too and apply them in Step 4 alongside the generic checks.
32	- If the project defines a cross-module impact table (e.g. "field X renamed -> grep the other repo for consumers"), run it: for each matching pattern in the diff, grep the referenced codebase paths, read every hit, and record any broken consumer as a finding.
33	- If the project has no documented review rules, proceed with the generic checks only. Do not invent stack-specific rules that aren't written down anywhere.
34
35	## Step 3: Determine PR scope
36
37	Look at the diff's file paths to scope which rules apply (e.g. frontend-only, backend-only, or mixed changes) and skip rules tagged for the side the PR doesn't touch.
38
39	## Step 4: Multi-agent analysis
40
41	Follow the `review-full` skill's Steps 1-6 (spawn `code-reviewer`, `security-reviewer`, `db-analyst`, and `architecture-reviewer` as applicable) using the fetched PR diff as the change set, plus any project-specific rules loaded in Step 2. Produce the standard findings table:
42
43	```
44	\| # \| Severity \| File:Line \| Finding \| Recommendation \|
45	```
46
47	## Step 5: Mandatory self-verification (do not skip; runs before posting)
48
49	1. Grep verification. For every project-specific "must fix"-style rule with a greppable pattern, re-run the grep against the diff and confirm every match is either included as a finding or explicitly justified as not a violation.
50	2. Rule/agent coverage line. State which agents ran and which project rules were checked, e.g. "checked code-reviewer, security-reviewer, rules A1-A2, G1-G8: N rules/checks in scope, M fin

People who liked this also viewed

6 picks

Type