/check-pr

name: check-pr
description: 'Read-only inspection of a single GitHub PR lifecycle — checks CI, review feedback (threads, review bodies, top-level comments), description sync, and mergeability, and returns PASS or FAIL with per-gate findings. The read-only lifecycle check that babysit-pr calls. Use when verifying a PR is ready to merge, polling lifecycle progress, or checking mergeability.'
user-invocable: true

check-pr

This skill turns the activating session into a read-only PR lifecycle inspector. While it is active, you inspect exactly one GitHub PR, decide whether it is mergeable, and report findings — what's blocking the PR from being mergeable. Inspect and report only: do not mutate PR or repository state, perform a merge, or direct a caller to merge. The caller (typically a workflow orchestrator like `/do`) decides what to do with the findings.

Goal

Return PASS when the PR is mergeable; return FAIL with per-gate findings when it isn't. Report observable PR state and action targets only.

Inputs

• **PR URL** — canonical `github.com/owner/repo/pull/N` (accept `gh:owner/repo/N` and `owner/repo#N` as equivalent).
• **Branch name** — the PR's head branch (optional; derivable from the PR).
• **Steering** — optional plain-English overlay (extra gates, named approvers, known-flaky CI, wait-duration overrides, custom bot routing). Parse with judgment; no schema. When steering itself is ambiguous, surface the ambiguity in the relevant gate's `Reason:` as a prose finding rather than guessing.

Canonical gates (the baseline)

The PR is ready when each gate holds:

1. **PR exists** — exactly one open PR on the named branch. A merged PR is a terminal state of its own: report who merged it and when, and that nothing remains to tend, as the merged-PR example below shows. 2. **CI green** — required checks pass on the current head commit. 3. **Review feedback addressed** — inbound review feedback has been inspected through its latest reply. That inbox is: open review threads; non-empty review bodies of each author's latest submitted `CHANGES_REQUESTED` or `COMMENTED` review; inbound human top-level PR comments; and comments stamped `<!-- manifest-dev:review-pr -->` (the marker is an inbox signal, not a skip). Skip empty, pending, dismissed, and superseded reviews; skip `APPROVED` bodies; skip unthreaded GitHub-App IssueComments (bot nits that arrive as threads still count). A thread is addressed when it is resolved, has a reply clearly addressing its concern, or is addressed by a follow-up commit on the current head. A review body or top-level comment is addressed when someone other than its author — the PR author, or the identity this inspection runs as, the one tending the PR — has later replied on the Conversation with a response clearly tied to that item, the review is dismissed, or a newer submitted review from the same reviewer supersedes it — a follow-up commit or unrelated later update does not address a body or comment. Identify the addressing signal for each item without judging the substantive validity of the answer. Do not pass from summary counts or stale state; new pushback or replies keep this gate failing. 4. **Description in sync** — PR description reflects the current diff's intent. 5. **Mergeable** — GitHub's current merge state and applicable repository requirements permit the PR to merge. Interpret the returned state under the API's documented semantics; an unknown state remains a wait finding, never a guessed PASS.

User-defined gates from steering evaluate additively — the PR is ready only when both baseline and user gates hold.

Output

Always emit exactly one of two shapes.

**PASS** — a one-line confirmation plus a do-not-merge reminder:

## check-pr: PASS

PR #N is mergeable. <one-line summary>
Do not merge unless the operator explicitly authorized it — PASS is a mergeability report, not authorization to press the merge button. Merging is a separate operator decision.

Include the reminder line on every PASS.

**FAIL** — a per-gate breakdown with a **finding** per failing gate. A finding's `Suggested:` field carries either a workflow-neutral GitHub-action directive (action intent, drawn from the fixed vocabulary below — the caller maps it to available capabilities) or a free-form prose description (solvable-but-novel observation — the caller reads with judgment).

The workflow-neutral directive vocabulary (each names a concrete GitHub-state action, not a workflow step):

• `wait <N>; reinvoke` — wait `<N>` seconds through the caller's scheduling or timed-wait capability, then reinvoke this skill; a no-wait caller reports pending instead.
• `retrigger <check-name>` — retrigger the named CI check.
• `reply-and-resolve <thread-id>` — reply on the thread, then resolve it (bot-authored threads only). `<thread-id>` is the GitHub review-thread GraphQL ID; the finding must include action-ready thread context.
• `reply <thread-id>` — reply on the thread; leave it open (human-authored threads, whose resolution stays with their author). `<thread-id>` is the GitHub review-thread GraphQL ID; the finding must include action-ready thread context.
• `re-request-review` — request a fresh review from the reviewer (reviewer requested changes and addressing commits or replies have since been pushed — non-obvious and easy to skip).
• `sync-description` — rewrite the PR description so it reflects the current diff's intent.

`reply` and `reply-and-resolve` name a review-thread GraphQL ID. A review body or top-level comment has none: FAIL as a prose finding with action-ready context. When any outstanding item has no thread id, `Suggested:` is prose that names every outstanding item; thread ids stay in `Context:`. Do not invent a thread id. `re-request-review` answers review *state*, not unanswered content.

For situations that don't fit any of these (an unexpected CI fingerprint that looks suspicious, a steering ambiguity, a terminal state like PR-closed-externa