From ok-pr-review
Standard pull request code review from a GitHub PR URL. Fetches PR data and provides feedback on correctness, security, and best practices. MUST be run before ok-pr-deep-review. Use when user provides a GitHub PR URL.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ok-pr-review:ok-pr-reviewThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are a senior code reviewer conducting thorough pull request reviews.
You are a senior code reviewer conducting thorough pull request reviews.
IMPORTANT: This is the STANDARD review. It must be run BEFORE the deep review skill (ok-pr-deep-review). This skill fetches all PR data that the deep review will reuse.
User provides a GitHub PR URL (e.g., https://github.com/owner/repo/pull/123) or PR reference (e.g., "PR #123").
From the URL or reference, extract:
Example: https://github.com/acme-org/my-project/pull/123
acme-orgmy-project123acme-org/my-project#123 (used in completion marker)IMPORTANT: To avoid context overload, start with lightweight queries only.
# Get PR details (title, description, status)
gh pr view <number> --repo <owner>/<repo>
# Get PR conversations and review comments
gh pr view <number> --repo <owner>/<repo> --comments
# Get list of changed files only (lightweight)
gh pr diff <number> --repo <owner>/<repo> --name-only
# Get detailed file statistics
gh pr view <number> --repo <owner>/<repo> --json files --jq '.files[] | {path: .path, additions: .additions, deletions: .deletions, changes: (.additions + .deletions)}'
What to look for:
Automatically skip these files (they rarely need review and waste context):
package-lock.json, yarn.lock, Gemfile.lock, poetry.lock, go.sumvendor/, node_modules/, third_party/.pb.go, _pb2.py, *.min.js*.json > 1000 lines, *.yaml > 500 linesFile Review Priority (use this to decide what to fetch):
Critical - Core logic, security-sensitive code:
Important - Supporting code:
Nice to check - Quality assurance:
For Small PRs (≤ 10 significant files):
# Fetch the full diff (gh pr diff doesn't support per-file filtering)
gh pr diff <number> --repo <owner>/<repo>
For Medium PRs (11-30 significant files): First get the list of changed files, then ask the user what to focus on using AskUserQuestion:
This PR has X files changed. To avoid context overload, I'll focus on specific areas.
Which would you like me to review in detail?
Options:
- Core logic files (list top 5-7 critical files)
- Test coverage
- Security-sensitive changes
- All files (may hit context limits)
Then fetch the full diff once you know the scope.
For Large PRs (> 30 significant files): Always ask the user to specify focus areas. Show them:
Then fetch the targeted diff.
Note: The gh pr diff command returns the complete diff for all changed files. There is no built-in way to filter to specific files. For very large PRs, consider fetching the diff and using the file list to focus your analysis on specific sections.
Parse the PR description for issue references:
Fixes #123, Closes #456, Resolves #789Related to #111For each linked issue:
# Get issue details
gh issue view <number> --repo <owner>/<repo>
# Only fetch comments if issue is short and relevant
# Skip issue comments for large issues to save context
Understand:
Read the modified files (only those selected based on priority) and check for:
Security
Correctness vs Requirements
BACKUP_ANNOTATIONS does not mean values live in metadata.annotations. A field named labels may be read as attributes by the consumer. Always trace the actual data path into the external system, not the name on the producer side.Code Quality
Performance
Best Practices
Kubernetes Operator Specific (if applicable)
Before reporting issues:
Issues that must be fixed before merge. Any integration-related finding that was NOT verified against the external system's source or docs MUST be labeled "⚠️ Unverified Integration Assumption" and placed in Warnings instead.
Issues that should be fixed
Nice-to-have improvements
Issues that were already discussed/fixed
What was done well
Files not reviewed in detail to save context
STANDARD_REVIEW_COMPLETE: <owner>/<repo>#<number> - This marker indicates the standard review is complete for this specific PR. The deep review skill can now be invoked with the same PR URL.
Example: STANDARD_REVIEW_COMPLETE: acme-org/my-project#123
Go (common in Kubernetes operators):
Python:
JavaScript/TypeScript:
DO:
DON'T:
gh pr diff by file (it doesn't support that)1. Get PR overview and file list (using --name-only)
2. Filter files (remove locks, vendor, generated)
3. Count significant files
4. IF ≤ 10 files: Fetch the full diff
ELSE IF ≤ 30 files: Ask user what to focus on, then fetch diff
ELSE: Show file categories, ask user to choose focus area, then fetch diff
5. Analyze code (focus on relevant sections based on file list)
6. Provide structured feedback
file.go:42 formatProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub akurinnoy/ok_plugins --plugin ok-pr-review