check-pr

Solid

Read-only inspection of a single GitHub PR lifecycle — checks CI, review threads, description sync, and mergeability, and returns PASS or FAIL with per-gate findings. Never invokes the merge button. Use when verifying a PR is ready to merge, polling lifecycle progress, checking mergeability, or babysitting a GitHub PR through CI and approvals.

Code & Development 73 stars 10 forks Updated today MIT

Install

View on GitHub

Quality Score: 87/100

Stars 20%
62
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# 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. You never mutate PR or repo state and you never press the merge button. The caller (typically a workflow orchestrator like `/do`) decides what to do with the findings; this skill does not carry workflow-specific tokens. ## Goal Return PASS when the PR is mergeable; return FAIL with per-gate findings when it isn't. Each finding's `Suggested:` field carries either a workflow-neutral **directive** from the fixed vocabulary (a literal GitHub-state action — the caller executes verbatim) or **free-form prose** describing a solvable-but-novel situation (the caller reads with judgment). Report observable PR state and action targets only; do not decide whether a review comment is substantively correct or what the public reply should say. Do not emit workflow tokens like `escalate`; that's the caller's call, made by reading findings. ## 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, su...

Details

Author
doodledood
Repository
doodledood/manifest-dev
Created
8 months ago
Last Updated
today
Language
Python
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Listed

check-pr

Checks a GitHub pull request for unresolved review comments, failing status checks, and incomplete PR descriptions. Waits for pending checks to complete, categorizes issues as actionable or informational, and optionally fixes and resolves them. Use when the user wants to check a PR, address review feedback, or prepare a PR for merge.

2 Updated today
Bboyfarouk
AI & Automation Listed

pr-gate

Validate a pull request end to end — work out what it actually changes and who it breaks, diagnose and fix a red pipeline, triage agent review comments (fix the valid ones, reply to and resolve the rest), judge whether it is genuinely ready, and merge it when asked. Use this whenever the user points at a PR (a number, a URL, "this PR", a Renovate/Dependabot bump) and wants to know whether it is safe, why a check is failing, whether it can be merged, or wants it merged. Use it for inbound PRs you did not write, dependency bumps, and any "is this ready to merge", "can you merge it", "fix the CI on this PR", "why is this check red", "address the review comments", or "does this break anything" request. For deploying and canary-verifying your own freshly shipped PR, use land-and-deploy instead; for a line-by-line code critique with no merge decision, use code-review.

0 Updated 4 days ago
Max-Levitskiy
Code & Development Listed

pr-review

Reviews a branch, PR, staged, or working-tree diff for correctness, security, repo-convention, test-coverage, and documentation gaps, returning severity-rated findings without editing code. Use when asked to "review my branch/PR", "is this ready to merge", "check this diff before I push", "does this need an ADR", or to apply fixes for findings from a previous review round. When the target is a GitHub PR, the same report is also posted to the PR — as inline comments on each finding's line plus a summary, by default — so the whole team can read it.

3 Updated 1 weeks ago
eagerworks