Agent skill
pr-review
Review GitHub pull requests with structured analysis and gh CLI integration. Use when asked to "review a PR", "check my PRs", "review pull request", or help with code review workflows.
Install this agent skill to your Project
npx add-skill https://github.com/edmundmiller/dotfiles/tree/main/config/agents/skills/pr-review
Metadata
Additional technical details for this skill
- author
- Rafael Garcia <https://github.com/rgarcia>
- version
- 1.0.0
SKILL.md
PR Review Skill
Structured workflow for reviewing GitHub pull requests with gh CLI.
Workflow
Step 1: Find Relevant PRs
Find open PRs where I am assigned, requested as a reviewer, or have already submitted a review:
gh pr list \
--search "is:open (review-requested:@me OR reviewed-by:@me OR assignee:@me)" \
--limit 10 \
--json number,title,author,reviewRequests,assignees,createdAt \
--jq '.[] | {number, title, author: .author.login, reviewers: [.reviewRequests[]?.login], assignees: [.assignees[]?.login], created: .createdAt}'
If there are multiple PRs, ask which one I want to review. Present the results to me as a numbered list for me to choose from. If there's only one, confirm before proceeding.
Step 2: Check Out and Examine the PR
Once I confirm the PR:
- Check out the PR locally:
gh pr checkout <PR_NUMBER> - Get PR details:
gh pr view <PR_NUMBER> - Get the full diff against the base branch:
gh pr diff <PR_NUMBER> - Check for existing review comments:
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments
Step 3: Analyze the Changes
Examine the diff and provide:
High-Level Summary
- What is the overall purpose of this PR?
- New APIs introduced (endpoints, functions, methods)
- New or modified data structures (types, interfaces, schemas)
- New dependencies or libraries added
- Architectural or design pattern changes
- Configuration changes
- Database migrations or schema changes
- Any breaking changes
Dependency Check
- For any new dependencies: check if they are actively maintained
- Flag archived, deprecated, or unmaintained libraries
- Look for existing libraries in the codebase that could be used instead (check imports across the codebase)
Impact Assessment
- How does this affect existing code?
- What areas of the codebase will need to be aware of these changes?
- Are there documentation implications?
Step 4: Review Focus Areas
Provide a numbered list of files or directories to review, in logical order (foundational changes first, then core logic, then usages, then tests). For each item, briefly note what to focus on:
- API or DB schema design considerations, if any
- Complex logic that needs careful examination
- Potential edge cases or error handling gaps
- Performance considerations
- Security implications
- Test coverage gaps
- Code style or consistency issues
Step 5: Suggested Comments
Prepare a list of suggested review comments, ordered by line number ascending (group by file, then sort by line within each file). For each comment:
- Use casual, lowercase messaging (e.g., "consider..." not "Consider...")
- Keep it short and to the point
- Use a friendly, suggestion-based tone (e.g., "consider...", "might be worth...", "nit: ...")
- Only be strongly opinionated if there's an obvious bug or issue
- Include the file path and line number as a clickable link to get me directly to the file and line within my editor
- Verify line numbers by reading the actual file content before suggesting
Format each suggestion as plain text (not in code blocks, since code blocks don't wrap and are hard to read):
File: <path>
Line: <number>
Comment:
Step 6: Prepare gh CLI Commands
Generate ready-to-run commands. Important: Create a pending review first, add each line comment individually, then submit.
-
Get the commit SHA for comments:
bashCOMMIT_SHA=$(gh pr view <PR_NUMBER> --json headRefOid -q .headRefOid) -
Check for an existing pending review before creating a new one:
bashgh api repos/{owner}/{repo}/pulls/{pr_number}/reviews \ --jq '.[] | select(.state == "PENDING") | {id, user: .user.login, state}'If a pending review exists, skip creating a new one and add comments to it instead.
-
Create an empty pending review (only if no pending review exists):
bashgh api repos/{owner}/{repo}/pulls/{pr_number}/reviews \ -f commit_id="$COMMIT_SHA" -
Add each line comment to the pending review (one call per comment):
bashgh api repos/{owner}/{repo}/pulls/{pr_number}/comments \ -f body="<comment>" \ -f path="<file_path>" \ -f commit_id="$COMMIT_SHA" \ -F line=<line_number> \ -f side="RIGHT" -
Reply to existing comments (if needed):
bashgh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies \ -f body="<reply>" -
After all comments are added, submit the review as an approval:
bashgh pr review <PR_NUMBER> --approve --body "Short summary here."Keep the final review body short (1-2 sentences). The detailed feedback is in the line comments.
Output Format
Present findings in sections, then wait for user feedback. The user will:
- Ask to modify suggestions
- Tell which comments to keep/remove
- Request changes to the review approach
Do NOT submit any reviews or comments until the user explicitly approves the plan.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
zbench
Benchmark interactive zsh performance with zsh-bench and track regressions. Use when benchmarking shell startup, comparing zsh latency after config changes, investigating slow shell, or running git bisect on performance. Trigger phrases: "benchmark zsh", "shell is slow", "zbench", "zsh-bench", "shell startup time", "profile zsh", "zsh performance".
nix-rebuild
Rebuild nix-darwin/NixOS system after dotfiles changes. Use when config files managed by Nix (lazygit, ghostty, etc.) need to be regenerated, or after editing any .nix file in the dotfiles repo.
hass-config-flow
Interact with Home Assistant via the REST API on a NixOS host. Use when adding integrations, querying entities, managing config flows, creating API tokens, or automating HA setup programmatically. Also covers identifying device protocols (Matter, Zigbee, Thread, HomeKit) from the device registry. Trigger phrases: "add HA integration", "configure home assistant", "query HA entities", "create HA token", "HA REST API", "pair homekit", "set up matter in HA", "add spotify to HA", "is this device zigbee or thread", "what protocol is this device", "move devices to ZHA", "identify matter devices".
hass-declarative
Manage Home Assistant automations, scenes, and scripts declaratively via NixOS modules. Covers adding/editing/removing entities in the domain-based Nix structure, the ensureEnabled wrapper (initial_state enforcement), the sweep service that cleans orphaned entities, entity identity (IDs, slugs, unique_ids), the eval test assertions, and the build-time manifest. Trigger phrases: "add HA automation", "new scene", "new script", "remove automation", "declarative HA", "sweep unmanaged", "entity drift", "ghost entity", "orphaned automation", "HA domain file", "eval-automations test", "hass assertion", "ensureEnabled", "initial_state".
agenix-secrets
Create, edit, and wire up agenix-encrypted secrets in this dotfiles repo. Use when adding API keys, tokens, credentials, passwords, or any sensitive values to NixOS host configs. Trigger phrases: "add a secret", "encrypt with agenix", "new age secret", "hide this value", "agenix secret".
linear
Read-only Linear issue access via the Linear GraphQL API.
Didn't find tool you were looking for?