review-pr

Use when you need to review or update the latest open GitLab merge request or GitHub pull request through a local worktree, or when a user provides a specific MR or PR number.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "review-pr" with this command: npx skills add minakoto00/vcs-review-flow/minakoto00-vcs-review-flow-review-pr

Review PR

Use this skill when the user wants you to pull, review, or update a remote GitLab MR or GitHub PR through a local worktree instead of switching the current checkout.

Prerequisites

  • git
  • jq
  • gh for GitHub repositories
  • glab for GitLab repositories

Workflow

  1. Resolve the repository root.
git rev-parse --show-toplevel
  1. Detect the VCS platform.
bash scripts/detect_platform.sh --repo <repo-root>
  1. Resolve the review target.

Latest open MR/PR:

bash scripts/resolve_review_target.sh --repo <repo-root> --latest

Specific MR/PR number:

bash scripts/resolve_review_target.sh --repo <repo-root> --number <number>
  1. Fetch remote review comments for the resolved MR/PR.
bash scripts/fetch_review_comments.sh --repo <repo-root> --number <number> --platform <github|gitlab> --json

Rules:

  • if code-review comments exist, ask the user whether to include code-review comments in scope before continuing
  • if discussion comments exist, ask the user whether to include discussion comments in scope after the code-review comment decision
  • only the approved comment categories enter the active review scope
  • preserve richer remote metadata for approved code-review comments when the platform provides it
  • resolved code-review feedback is excluded from review scope by default
  • outdated code-review feedback is validated separately from unresolved threads
  • approved unresolved and outdated code-review feedback is grouped into issue clusters before validation
  • if any categories are approved, dispatch several subagents in parallel to validate whether those approved comments still make sense
  • subagents search only within changed files for same-pattern candidates
  • report same-pattern candidates separately from the original issue clusters
  • present a simple verification report before planning fixes
  • ask the user to confirm the verification report before planning fixes
  • if the user confirms, treat the confirmed comments as in-scope issues even when tests do not yet cover them
  • after comment handling, ask the user to choose one of these options before planning changes:
    1. Review full changeset for additional issues
    2. Do not do additional reviews
    3. Specify otherwise
  1. Inspect repository policy before touching worktrees.
bash scripts/repo_policy.sh --repo <repo-root>

Read both AGENTS.md and CLAUDE.md when present. If they conflict on worktree location or workflow, surface that conflict instead of guessing.

  1. Reuse or create the worktree for the MR/PR source branch.
bash scripts/worktree_sync.sh \
  --repo <repo-root> \
  --source-branch <source-branch> \
  --head-sha <head-sha>

Rules:

  • if the matching worktree already exists locally, sync it to the latest remote branch head
  • if the matching worktree does not exist, create it in the repo-approved location
  • if the existing worktree has uncommitted changes, stop and ask before syncing
  1. If approved comment categories were selected, validate them before additional review or fix planning.

For approved comments:

  • exclude resolved code-review feedback from active validation by default
  • validate outdated threads separately from unresolved threads
  • group approved code-review feedback into issue clusters before dispatch
  • dispatch several subagents in parallel to classify each selected comment or issue cluster as likely valid, unclear, or likely stale
  • search only within changed files for same-pattern candidates
  • report same-pattern candidates separately from the original issue clusters
  • produce a verification report with a short reason for each classification
  • ask the user to confirm the verification report before planning fixes
  1. Ask the user to choose one of these options before planning changes, even when no comments were approved or no unresolved comments remain:
1. Review full changeset for additional issues.
2. Do not do additional reviews.
3. Specify otherwise.
  1. If the user chooses Review full changeset for additional issues, run a full code review session from the prepared worktree.

If the environment exposes a review skill such as requesting-code-review, invoke it with:

  • the user's review request
  • the resolved base/head context
  • the approved comment categories plus their pulled comment content
  • the richer remote metadata for approved code-review comments
  • the prepared worktree path
  • instructions to review the full changeset for issues beyond the remote comments

If no dedicated review skill is available, perform the review directly with a code-review mindset across the full changeset.

Keep any new findings separate from the remote-comment verification report.

  1. After any required confirmation and any requested full review, produce a change plan.

The change plan must include:

  • key findings being addressed
  • likely files or areas to change
  • implementation direction
  • verification steps

If the user confirmed approved comments as valid, include them in the change plan even when tests do not yet cover them. If the user requested a full changeset review, include any additional findings from that review in the change plan alongside the confirmed remote-comment issues.

  1. Present exactly these finish options.
1. Implement locally on the original source branch, commit, and push to update the MR/PR.
2. Implement locally on the original source branch, commit there, then merge or cherry-pick into a user-specified branch.
3. Do not implement locally; post the proposed changes as a GitLab/GitHub comment with concrete patch guidance.

Safety Stops

  • Stop if gh or glab is missing for the detected platform.
  • Stop if authentication fails.
  • Stop if there are no open MRs/PRs.
  • Stop if the remote source branch no longer exists.
  • Stop before syncing a dirty worktree.
  • Never force-push unless the user explicitly asks.

Quick Reference

Detect platform:

bash scripts/detect_platform.sh --repo <repo-root>

Resolve latest target:

bash scripts/resolve_review_target.sh --repo <repo-root> --latest

Resolve explicit target:

bash scripts/resolve_review_target.sh --repo <repo-root> --number 123

Inspect repo policy:

bash scripts/repo_policy.sh --repo <repo-root>

Sync worktree:

bash scripts/worktree_sync.sh --repo <repo-root> --source-branch feat/example --head-sha <sha>

Fetch review comments:

bash scripts/fetch_review_comments.sh --repo <repo-root> --number 123 --platform github --json

Post comment-only proposal:

bash scripts/post_review_comment.sh --repo <repo-root> --number 123 --body-file /tmp/review-plan.md

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

review-pr

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

review-pr

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

review-pr

No summary provided by upstream source.

Repository SourceNeeds Review
General

review-pr

No summary provided by upstream source.

Repository SourceNeeds Review