Run comprehensive PR checks including reviewing CodeRabbit comments, ensuring PR description quality, running pre-commit hooks, tests, and validation. Use on an existing PR to address review feedback.
This skill runs comprehensive PR checks to ensure code quality and address review feedback on an existing pull request.
Run this skill when:
/pr-checks
First, understand what's being reviewed:
# Check current branch and status
git branch --show-current
git status --short
# Show diff summary vs main
git diff --stat main...HEAD
# Get the PR number for this branch
gh pr view --json number,title,state
Ensure the PR has a proper description before addressing code comments:
# View current PR description
gh pr view --json body,title
A good PR description should include:
Closes MAS-XXX)If the description is missing or inadequate:
# Update the PR description
gh pr edit --body "$(cat <<'EOF'
## Summary
<1-2 sentence overview of what this PR accomplishes>
### Changes
- <change 1: what was added/modified/removed>
- <change 2>
- <change 3>
- ...
### Technical details (if applicable)
<Brief explanation of implementation approach, architectural decisions, or non-obvious changes>
## Test plan
- [ ] <verification step 1>
- [ ] <verification step 2>
- [ ] <edge case or error scenario tested>
## Related issues
Closes MAS-XXX
## Screenshots/recordings (if applicable)
<Add screenshots for UI changes, terminal output for CLI changes>
š¤ Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
Fix the title if needed (should follow conventional commits format):
# Update PR title
gh pr edit --title "feat: descriptive title here"
This is the primary workflow. CodeRabbit automatically reviews PRs and posts comments. Use /pr-comments to fetch and process them:
/pr-comments
This fetches all review comments from the PR. For each CodeRabbit comment:
Walk through comments one by one with the user:
## CodeRabbit Comment #1 of 5
**File:** `massgen/backend/foo.py:45`
**Original code:**
```python
response = client.api_call(params)
return response.data
CodeRabbit suggestion:
Consider adding error handling for the API call. The request could fail due to network issues or API errors, which would cause an unhandled exception. This is especially important since this is called from the main orchestration loop where failures could crash the entire run. [truncated - 8 more lines]
Suggested change:
try:
response = client.api_call(params)
return response.data
except APIError as e:
logger.error(f"API call failed: {e}")
raise
My assessment: Valid concern - the API call could fail and there's no error handling.
Recommendation: ā Implement
Do you want me to:
**After user decides, resolve the comment on GitHub:**
```bash
# If implemented or intentionally skipped, resolve the comment thread
gh api graphql -f query='
mutation {
resolveReviewThread(input: {threadId: "THREAD_ID"}) {
thread { isResolved }
}
}
'
Alternatively, reply to the comment explaining the action taken:
# Reply to the comment
gh pr comment <PR_NUMBER> --body "Addressed in <commit-sha>: <brief description of fix>"
When showing comments:
Wait for user approval before implementing each fix. This ensures:
After making fixes, run pre-commit to ensure code style:
uv run pre-commit run --all-files
If issues are found, fix them and commit.
# Run tests (skip expensive API tests)
uv run pytest massgen/tests/ -v -m "not expensive and not docker" -x --tb=short
uv run python scripts/validate_all_configs.py
# Stage fixes
git add -u .
# Commit with descriptive message
git commit -m "fix: address CodeRabbit review comments
- Fix error handling in foo.py
- Add missing type hints in bar.py
š¤ Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>"
# Push to trigger CodeRabbit re-review
git push
For additional analysis beyond CodeRabbit:
/pr-review-toolkit:review-pr
This runs specialized agents for:
If you want to run a fresh local review (separate from GitHub PR comments):
coderabbit --prompt-only --type committed
Note: This runs CodeRabbit's own analysis locally, which may differ from the automated PR review. The GitHub PR comments from step 3 are typically more thorough since they have full PR context.
After all checks, output a summary:
## PR Checks Summary
### Branch: feature/my-feature
- PR #123: "feat: add new feature"
- Commits ahead of main: 3
- Files changed: 5
### PR Description
ā
Has summary, test plan, and issue links
### CodeRabbit Comments Addressed
| Comment | File | Action |
|---------|------|--------|
| Add error handling | foo.py:45 | ā
Implemented |
| Consider caching | bar.py:12 | ā Skipped (not applicable) |
| Missing type hint | baz.py:78 | ā
Implemented |
### Check Results
| Check | Status |
|-------|--------|
| Pre-commit | ā
Passed |
| Tests | ā
47 passed |
| Config Validation | ā
Valid |
### Ready for Merge?
ā
All critical issues addressed, ready for final review
## Summary
<1-2 sentence overview of what this PR accomplishes>
### Changes
- <change 1: what was added/modified/removed>
- <change 2>
- <change 3>
### Technical details (if applicable)
<Implementation approach, architectural decisions, or non-obvious changes>
## Test plan
- [ ] Step to verify functionality
- [ ] Edge cases tested
- [ ] Error scenarios handled
## Related issues
Closes MAS-XXX
## Screenshots/recordings (if applicable)
<For UI/CLI changes>
## Breaking changes (if applicable)
<What breaks and migration steps>
Use conventional commits format:
feat: - New featurefix: - Bug fixdocs: - Documentation onlyrefactor: - Code change that neither fixes a bug nor adds a featureperf: - Performance improvementtest: - Adding or updating testschore: - Maintenance tasks@pytest.mark.expensive - Skip in quick checks@pytest.mark.docker - Docker-dependentSee .coderabbit.yaml for path-specific review instructions and exclusions.