Review, repair, or merge pull requests with ak:review-pr

Use ak:review-pr to evaluate one or more GitHub pull requests against their stated scope, the surrounding code, repository rules, tests, security boundaries, and merge readiness. The default mode is read-only. Optional flags deliberately expand each pull request's workflow to repair its branch, post a formal review, or merge and watch post-merge CI.

Choose ak:review-pr for existing GitHub pull requests

Use ak:review-pr when

• You need a verdict backed by the complete diff and relevant full files.
• You want correctness, security, breaking-change, testing, and code-quality findings in one review.
• You want a bounded fix and re-review loop on the pull request branch.
• You explicitly want the final review posted or a ready pull request merged.

Choose another workflow when

• You only need to review local, unsubmitted changes. Use ak:code-review.
• You already know the defect and need a root-cause repair outside a pull request workflow. Use ak:fix.
• You need to prepare commits and open or update a pull request. Use ak:ship.
• The repository is not hosted on GitHub or the session cannot use GitHub CLI.

Prepare GitHub and the repository

Before you start:

• Complete Onboarding, and confirm the installed Kit is available in the current runtime.
• Run from the pull request's repository. Provide one or more refs as a bare number (123), hash-prefixed number (#123), or full PR URL; separate refs with whitespace or commas.
• Install and authenticate gh with permission to read the repository and its pull requests.
• For --fix, start with a clean, correct pull request head branch and preserve unrelated user changes.
• Grant write, review, merge, and Actions permissions only for the modes you intend to use.

Select the authority deliberately

Flags can appear in any order and compose. With no flag, the Skill prints each review locally.

--fix --reply posts only the final re-review for each PR. Adding --merge runs the merge stage last for that PR, after repair and reply behavior completes.

Refs may be separated by whitespace or commas: 482 517 --reply and 482,517 --reply select the same two PRs. The Skill processes refs in input order and completes the full review, fix, reply, merge, and advice flow selected for one PR before starting the next. A fatal PR-specific failure is recorded and the run continues with remaining refs; only an unrecoverable environment-wide failure stops the whole run. Passing one ref keeps the same modes, gates, and effects as the single-PR workflow.

/ak:review-pr 482 --fix --reply

/ak:review-pr 482 --fix --reply

$ak:review-pr 482 --fix --reply

For a read-only review, omit every flag. To authorize the full path, use a request such as 482 --fix --reply --merge; the flags authorize their named stages but do not waive readiness, verification, or repository protection.

Understand the review workflow

For each PR in input order:

1. The Skill resolves context. It reads pull request metadata, description, changed-file counts, the full diff, and current checks.
2. It validates the stated work. The title, body, linked issues, claimed scope, and completion evidence are compared with the actual change.
3. It inspects implementation context. Every changed file and the relevant surrounding source are checked against current project instructions and established patterns.
4. It classifies findings. Correctness, security, breaking changes, tests, and maintainability findings become Critical, Important, or Suggestion items with concrete evidence.
5. It returns a verdict. Approve means no Critical or Important finding; Request changes means blockers remain; Comment means only minor suggestions.
6. Optional stages run in order. The fix loop repairs and re-reviews, reply posts the final review, and merge runs only after every readiness condition passes.

That selected sequence completes end-to-end for the current PR before the next ref starts. Human-facing review prose follows the configured writing language when it can be resolved. Commands, paths, identifiers, GitHub keywords, and quoted evidence stay unchanged.

Understand the adaptive GitHub API path

The installed compatibility helper probes GraphQL availability with gh api graphql. When GraphQL is blocked, supported reads for PR metadata, diffs, changed files, checks, and body content use REST instead. Formal reviews and PR comments also have REST fallbacks: REST-only sessions skip the native attempt, while GraphQL-capable sessions prefer the native gh pr operation and retry through REST if it fails.

This is an adaptive fallback, not a claim that every GitHub operation is GraphQL-free. Native gh pr commands may still use GraphQL, and GitHub exposes auto-merge enablement only through GraphQL. The merge stage therefore uses the qualified native or REST behavior described below.

Keep write and merge authority explicit

Important boundaries:

• A failed gh installation or authentication check in reply mode falls back to local output; it does not silently claim that a review was posted.
• GitHub does not allow you to approve your own pull request. The Skill retries an otherwise approving self-review as a neutral comment and reports that downgrade.
• The merge gate requires an Approve verdict, no fix-loop blocker, an open and mergeable pull request, no outstanding changes request, and passing or only pending checks. With pending checks, the native path may enable --auto; the REST fallback cannot enable auto-merge and instead waits for terminal-green checks before its REST merge. Neither path forces red checks, conflicts, or branch protection.
• --fix must not commit or push when verification fails, secrets are found, or unrelated user changes would be included.
• Re-running --reply posts another review; the current workflow does not deduplicate prior replies.
• gh uses the session's existing credentials and network access. Repository policy, hosted CI minutes, and third-party checks can add external effects or cost; the Skill defines no separate provider charge.

Verify the evidence

A complete result should include, for each PR:

• Summary, risk level, findings by severity, and final verdict.
• File and line or function evidence for every actionable finding.
• Fix-loop iteration count, commits pushed, and remaining blockers when --fix runs.
• Whether --reply posted, downgraded a self-approval, or fell back to local output.
• For --merge, the merge result, merge commit, watched CI conclusions, and any follow-up fixes.
• Explicit unresolved questions instead of unsupported completion claims.

After all refs finish, the result also aggregates the number processed, verdict totals, AK_GH_REST=<0|1> environment mode and actual REST-path use, plus remaining blockers by PR. A one-ref invocation retains its full per-PR result.

Release evidence covers portable Skill projection together with the multi-PR and adaptive API contracts described here. It does not guarantee live GitHub permissions, repository-specific merge rules, CI duration, or identical approval prompts across runtimes.

Troubleshoot safely

Continue with ak:code-review for local review, ak:ship for pull request preparation, or ak:git for a more focused Git workflow.