reviewing-pull-requests
Reviewing Pull Requests
Review pull requests against issue requirements and good coding practices.
Workflow
- Auto-detect tracking system -- GitHub PR (gh CLI) or Linear-linked PR (linear-cli)
- Read the pull request -- changes, scope, implementation approach
- Find related issue/ticket for acceptance criteria and original requirements
- Ensure latest code context -- pull changes and verify working directory state
- Review project documentation -- check
docs/,spec.md,requirements.md,CLAUDE.md - Analyze implementation quality -- code structure, patterns, maintainability
- Verify test coverage -- ensure complete testing of new functionality
- Check style compliance -- validate against project guidelines
- Assess scope adherence -- confirm changes are minimal and focused
- Determine review action -- self-authored (comment) vs external (formal review)
- Submit structured feedback
Review Framework
Requirements Alignment
- All acceptance criteria met
- No scope creep beyond original ticket
- Edge cases and error handling covered
Code Quality
- Follows established patterns from codebase
- Single Responsibility, DRY compliance
- Adequate comments for complex logic
- No obvious performance bottlenecks
Test Coverage
- All new functionality has corresponding tests
- Error scenarios and edge cases tested
- Integration with existing system validated
Implementation Standards
- Clean commit history
- Smallest necessary changes
- No breaking changes without justification
- Input validation, no credentials exposure
Review Output
Requirements Coverage
- What criteria are met, partially met, or missing
Code Quality
- Architecture adherence, pattern consistency, docs, performance
Test Assessment
- Coverage verification, edge case testing, integration validation
Final Recommendation
- Approve: Ready for merge
- Request Changes: Specific issues listed
- Comment: Self-authored PR feedback
Command Reference
# View PR with full details
gh pr view <number> --json title,body,author,commits,files,comments,reviews
# Get diff
gh pr diff <number>
# View related issue
gh issue view <number> --json title,body,labels,assignees
# Submit review
gh pr review <number> --approve|--request-changes|--comment
# Linear integration
linear-cli issues
linear-cli issue <team-id>
More from trevors/dot-claude
jj-workflow
Jujutsu (jj) version control, load skill when hook output shows vcs=jj-colocated or vcs=jj in the system-reminder.
93notion-formatter
Format markdown content for Notion import with proper syntax for toggles, code blocks, and tables. Use when formatting responses for Notion, creating Notion-compatible documentation, or preparing markdown for Notion paste/import.
47using-jj
Advanced jj/jujutsu workflows — revsets, absorb, evolog, op restore/undo, immutable_heads bypass, divergent-change resolution, jj split, parallel jj new, conflict-after-rebase, force-push recovery. Contains non-obvious rules (e.g., always `-m` to avoid editor) that prevent broken workflows. Skip for simple commit/push/rebase.
44book-reader
Read and search digital books (PDF, EPUB, MOBI, TXT). Use when answering questions about a book, finding quotes or passages, navigating to specific pages or chapters, or extracting information from documents.
44svelte5
Svelte 5 syntax reference. Use when writing ANY Svelte component. Svelte 5 uses runes ($state, $derived, $effect, $props) instead of Svelte 4 patterns. Training data is heavily Svelte 4—this skill prevents outdated syntax.
39maintaining-claude-code
Create, validate, and improve Claude Code configuration — SKILL.md files, CLAUDE.md, rules, hooks, and settings.json. Use when creating a new skill, writing a SKILL.md, adding a hook, editing rules, auditing skill descriptions, checking config quality, debugging hook behavior, or deciding between skills vs rules vs CLAUDE.md. Also auto-loads when working in ~/.claude/ on skills, rules, hooks, or settings.
32