Menu
Review automated PR feedback, discuss with the user, fix what they approve, respond to comments, and push
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Run the same comprehensive review your CI runs on PRs, but locally against your full local-vs-remote diff and printed as text in the session, with an optional fix loop. Use when the user wants to mirror or preview the CI code review before pushing, get their branch CI-clean, or run an iterative review-then-fix loop. Triggers on "run the CI review locally", "preview the CI review", "mirror CI", "ci review", "will CI pass", "review-and-fix before pushing". For a plain read-only local review with no CI-parity framing or fix loop, prefer /review-local instead.
For coding/implementation tasks, use your own judgement to delegate the actual code-writing to a subagent running an appropriately lower-power model, to conserve top-tier tokens. Triggers whenever a task is primarily writing or editing code (features, fixes, refactors, mechanical edits). Skip for judgement-heavy work (design, debugging, auditing, synthesis).
Merge the current PR with branch deletion, but only after CI passes. Use when the user clearly means "merge the open PR" (e.g. plain "merge", "merge it", "ship it"). Do NOT use for git branch merges ("merge main into X") or code merges.
Inspect Claude Code session logs (transcripts) for the current or another project. Use when the user explicitly asks to "look at the claude logs", "parse my session", "what did I ask claude", "show the transcript", "list claude sessions", or similar phrasings referencing Claude's own JSONL logs.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Docs-aware grilling. Explores the repo's existing docs first, then interviews the user relentlessly about a plan or design while cross-referencing those docs and the code. Use when user wants to stress-test a plan against the project's existing documentation, says "grill me with docs", "grill against the docs", or similar.
| name | address-pr-feedback |
| description | Review automated PR feedback, discuss with the user, fix what they approve, respond to comments, and push |
| disable-model-invocation | false |
| argument-hint | [pr-number] |
Address automated review feedback on PR #$ARGUMENTS.
Fetch review comments using /pr-comments first, then supplement with both GitHub API endpoints to ensure full coverage:
gh api repos/{owner}/{repo}/pulls/{pr}/comments โ inline review comments on specific linesgh api repos/{owner}/{repo}/issues/{pr}/comments โ general conversation comments (where automated review bots like the CI code review post)Combine results from all sources, deduplicating and ignoring bot comments that aren't code review feedback (e.g., Vercel deployment status, coverage reports).
Summarize each suggestion with your assessment of whether it's worth fixing. Present as a numbered table with columns: suggestion, your take (fix/skip + rationale). Be opinionated.
Discuss with the user. Wait for them to tell you which suggestions to act on and which to skip. They may have additional context or disagree with your assessment.
Implement the agreed fixes. Make the code changes, run type-check and tests to verify.
Respond to the review comments on the PR via gh api repos/{owner}/{repo}/issues/{pr}/comments. Mention that you're Claude speaking on @thavelick's behalf. Address each numbered suggestion: what was done and why, or why it was skipped.
Commit and push the changes.