npx claudepluginhub jsamuelsen11/claude-config --plugin ccfg-core<pr-number-or-url># PR Review Conduct a structured, comprehensive pull request review using a 5-part rubric that evaluates correctness, security, performance, maintainability, and conventions. Produces actionable feedback with severity ratings. ## Usage Examples: - `/pr-review 42` - Review PR #42 in current repository - `/pr-review https://github.com/owner/repo/pull/123` - Review by URL ## Review Process ### Step 1: Fetch PR Details Retrieve PR metadata and changed files: **Information to Extract:** - PR title and description - Author and reviewers - List of changed files - Number of additions/d...
/devkit.github.review-prReviews GitHub PR by number for code quality, security, architecture, performance, best practices. Optional focus (full/security/etc.) and format (summary/detailed/etc.).
/review-prReviews GitHub pull request via CLI, checking correctness, security, performance, maintainability, testing; outputs verdict, severity-rated findings table, summary, and post option.
/review-prReviews GitHub Pull Request by number: fetches diff, audits changed files for style, logic, security, performance, architecture; posts comments, summary, and verdict.
/pr-reviewReviews pull request diffs, code listings, or outputs for code quality, security, performance, and architecture, delivering prioritized feedback with classifications and improvement suggestions.
/review-prReviews GitHub PR via <PR_URL>: fetches details/diff/checks, evaluates code quality/design/testing/other criteria, presents findings table, posts approved verdict.
/prp-reviewPerforms thorough PR code review: fetches metadata/diff, checks patterns, runs lint/tests/build, posts comments on PR, saves local report. Accepts PR number/URL and --approve/--request-changes flags.
Share bugs, ideas, or general feedback.
Conduct a structured, comprehensive pull request review using a 5-part rubric that evaluates correctness, security, performance, maintainability, and conventions. Produces actionable feedback with severity ratings.
/pr-review <pr-number-or-url>
Examples:
/pr-review 42 - Review PR #42 in current repository/pr-review https://github.com/owner/repo/pull/123 - Review by URLRetrieve PR metadata and changed files:
# Get PR information
gh pr view <pr-number> --json title,body,author,commits,files
# Get detailed diff
gh pr diff <pr-number>
Information to Extract:
Fetch the PR branch locally for deeper inspection:
# Check out the PR branch
gh pr checkout <pr-number>
# Verify branch is up to date
git fetch origin
git log --oneline main..HEAD
Systematically read all modified files to understand the changes:
File Analysis Strategy:
Use Glob and Read tools to efficiently navigate changed files.
Evaluate the PR against 5 quality dimensions:
Does the code do what it claims? Are edge cases handled? Any logic errors?
Evaluate:
Common Issues:
Are there injection vectors, auth issues, secret exposure, or OWASP top 10 vulnerabilities?
Evaluate:
Common Issues:
Are there N+1 queries, unnecessary allocations, missing indexes, or O(n²) algorithms?
Evaluate:
Common Issues:
Is the code clear, well-abstracted, tested, and DRY?
Evaluate:
Common Issues:
Does it follow project rules? Lint clean? Commit style?
Evaluate:
Common Issues:
Produce a structured markdown report with findings organized by severity:
# PR Review: <PR Title>
**PR:** #<number> **Author:** @<username> **Files Changed:** <count>
**Lines:** +<additions> -<deletions>
## Summary
<1-2 sentence overall assessment>
## Findings
### BLOCKER Issues (Must fix before merge)
#### [BLOCKER] <Category>: <Brief Title>
**File:** `path/to/file.ts:42`
**Issue:** <Clear description of the problem>
**Impact:** <What could go wrong if not fixed>
**Remediation:** <Specific steps to fix>
---
### WARNING Issues (Should fix, creates risk)
#### [WARNING] <Category>: <Brief Title>
**File:** `path/to/file.ts:78`
**Issue:** <Description>
**Impact:** <Potential consequences>
**Remediation:** <How to address>
---
### NIT Issues (Suggestions, non-blocking)
#### [NIT] <Category>: <Brief Title>
**File:** `path/to/file.ts:120`
**Suggestion:** <Improvement recommendation>
---
## Positive Observations
- <Well-done aspect 1>
- <Well-done aspect 2>
- <Well-done aspect 3>
## Recommendation
- [ ] **APPROVE** - Ready to merge
- [ ] **APPROVE with NITS** - Can merge, address suggestions in follow-up
- [ ] **REQUEST CHANGES** - Must address warnings/blockers before merge
- [ ] **NEEDS DISCUSSION** - Architectural concerns require team input
## Additional Notes
<Any context, questions, or discussion points>
BLOCKER:
WARNING:
NIT:
Before completing review, verify automated checks:
# Check CI status
gh pr checks <pr-number>
# View test results
gh pr view <pr-number> --json statusCheckRollup
If CI is failing, include status in review report.