| name | review-verify |
| description | Verify whether PR review comments are addressed by mapping concerns to code, targeted tests, and browser checks when needed. Use when checking review-fix claims for current-user pending reviews or teammate-visible review threads before replying, resolving, clearing, or submitting. |
Review Verify Skill
Verify whether PR review comments have been addressed. Treat CI and deployment as supporting signals, not proof. Map each concern to changed code, tests, and browser behavior when needed.
Suggested slash command: /review-verify <pr-number-or-url>
When to Use
- The user asks whether review comments have been addressed
- The user asks to verify fixes before resolving, replying, clearing, or submitting
- CI has passed but review concerns need independent confirmation
- A staging browser check is useful for behavior that tests do not fully cover
- Review comments may be current-user pending, teammate-visible, squashed, outdated, or only visible through review summaries
Default Behavior
- Do not assume review comments are addressed; verify them against review text, commits, code, tests, browser behavior, and logs
- Do not run E2E tests by default; use targeted non-E2E tests and manual browser checks when needed
- Do not submit, delete, resolve, publish, or publicly reply to review content unless explicitly asked
- Do not use a pending review as a workaround for publishing replies
- Prefer the smallest targeted test set that maps directly to the review concerns
- Treat example URLs as entry points, not exhaustive scope
Source-Specific Outcomes
Current-user pending review concerns
- If pending inline comments are not visible through REST, use the pending review body and referenced commits as the source of truth
- Report whether each concern is addressed, still open, uncertain, or no longer applicable
- If the user asks to clear pending review artifacts after verification, hand off to
review-clear
- If the user asks to reply, keep replies pending unless they explicitly ask to submit or publish
Teammate-visible review concerns
- Report which threads are ready to resolve, still open, or uncertain
- If the user explicitly asked to verify and resolve, hand off only fully verified threads to
team-review-resolve
- If the user only asked to verify, stop before mutating GitHub state
- Public replies are allowed only when explicitly requested and must include concrete evidence
Workflow
- Read PR metadata, reviews, review comments, commits, CI status, and current-user pending reviews.
- Inspect referenced commits, including commits that may have been squashed away.
- Map each concern to changed files, tests, and browser scenarios.
- Classify each concern as
addressed, still-open, uncertain, or not-applicable.
- Run targeted non-E2E tests that map directly to the concerns.
- Use browser verification when behavior is not fully covered by tests.
- Report evidence, ready-to-resolve threads, still-open concerns, and coverage gaps.
- Mutate GitHub state only through explicit follow-up skills or explicit user instruction.
Reply and Mutation Rules
- Reply to review or PR comments only when the user explicitly asks
- Never submit an existing pending review to make replies visible unless the user explicitly says to submit that pending review
- Do not use
gh pr review, the create-review REST endpoint, or any review submission event to satisfy a reply request unless explicitly asked
- Do not delete pending review artifacts; use
review-clear only when explicitly asked
- Do not resolve teammate-visible threads; use
team-review-resolve only when explicitly asked and only for fully verified threads
Reference
See REFERENCE.md for GitHub API commands, commit inspection commands, test command examples, browser verification steps, and the final response template.
