prcheckloop
Skill1 starsChanged 4 months agoMITView on GitHub
Iteratively gets a GitHub pull request's checks green. Detects the PR for the current branch or uses a provided PR number, waits for every check on the latest head SHA to appear and finish, investigates failing checks, fixes actionable code or test issues, pushes, and repeats. Escalates with a precise blocker when failures are external, flaky, or not safely fixable. Use when a PR still has unsuccessful checks after review fixes, including after greploop.
- Commits and pushes
3 other projects use a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- paperclipai/paperclipedited, first seen Oct 8, 2026
- microsoft/amplifier-app-paperclipword for word, first seen Jun 5, 2026
- jpoindexter/theft-kitword for word, first seen May 20, 2026
Other versions3 projects use a version of this.
Word for word · 2
- jpoindexter/theft-kit★ 1100% same
- microsoft/amplifier-app-paperclip★ 1100% same
Edited · 1
- paperclipai/paperclip★ 112k97% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository12 other files it gives its agents.
- AGENTS.mdAGENTS.md
- company-creatorSkill
- create-agent-adapterSkill
- deal-with-security-advisorySkill
- doc-maintenanceSkill
- pr-reportSkill
- release-changelog-discord-messageSkill
- release-changelogSkill
- releaseSkill
- design-guideSkill
- frontend-designSkill
- web-design-guidelinesSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. About 0 are common, 17 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈17
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 21
If the user also wants review-comment cleanup, pair this with check-pr.
- Very specific: line 26
Max iterations: default 5.
- Distinctive: line 32
If no PR number is provided, detect it from the current branch:
- Distinctive: line 38
If needed, switch to the PR branch before making changes.
- Distinctive: line 48
Always work against the current PR head SHA:
- Distinctive: line 93
After a new push, checks can take a moment to appear.
- Distinctive: line 98
no checks appear after a reasonable wait, usually 2 minutes
- Distinctive: line 100
Treat these as terminal success states:
- Very specific: line 102
check runs: SUCCESS, NEUTRAL, SKIPPED
- Distinctive: line 105
Treat these as pending:
- Very specific: line 107
check runs: QUEUED, PENDING, WAITING, REQUESTED, IN_PROGRESS
- Distinctive: line 110
Treat these as failures:
- Very specific: line 112
check runs: FAILURE, TIMED_OUT, CANCELLED, ACTION_REQUIRED, STARTUP_FAILURE, STALE
- Very specific: line 115
If no checks appear for the latest SHA, inspect .github/workflows/, workflow path filters, and branch protection expectations.
- Distinctive: line 139
Only rerun a failed job once without code changes.
- Distinctive: line 143
If the failure is actionable from the checked-out code:
- Distinctive: line 145
Read the workflow or failing command to identify the real gate.
- Distinctive: line 148
Run focused verification first, then broader verification if needed.
- Distinctive: line 149
Commit in a logical commit.
- Distinctive: line 152
Do not stop at a local fix.
- Distinctive: line 168
all checks for the latest head SHA are green, or
- Distinctive: line 174
If you cannot get the PR green, report:
- Distinctive: line 195
When the skill completes, report:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
PRCheckloop
Get a GitHub PR to a fully green check state, or exit with a concrete blocker.
Scope
- GitHub PRs only. If the repo is GitLab, stop and use
check-pr. - Focus on checks for the latest PR head SHA, not old commits.
- Focus on CI/status checks, not review comments or PR template cleanup.
- If the user also wants review-comment cleanup, pair this with
check-pr.
Inputs
- PR number (optional): If not provided, detect the PR for the current branch.
- Max iterations: default
5.
Workflow
1. Identify the PR
If no PR number is provided, detect it from the current branch:
gh pr view --json number,headRefName,headRefOid,url,isDraftIf needed, switch to the PR branch before making changes.
Stop early if:
ghis not authenticated- there is no PR for the branch
- the repo is not hosted on GitHub
2. Track the latest head SHA
Always work against the current PR head SHA:
PR_JSON=$(gh pr view "$PR_NUMBER" --json number,headRefName,headRefOid,url)
HEAD_SHA=$(echo "$PR_JSON" | jq -r .headRefOid)
PR_URL=$(echo "$PR_JSON" | jq -r .url)Ignore failing checks from older SHAs. After every push, refresh HEAD_SHA and
restart the inspection loop.
3. Inventory checks for that SHA
Fetch both GitHub check runs and legacy commit status contexts:
gh api "repos/{owner}/{repo}/commits/$HEAD_SHA/check-runs?per_page=100"
gh api "repos/{owner}/{repo}/commits/$HEAD_SHA/status"For a compact PR-level view, this GraphQL payload is useful:
gh api graphql -f query='
query($owner:String!, $repo:String!, $pr:Int!) {
repository(owner:$owner, name:$repo) {
pullRequest(number:$pr) {
headRefOid
url
statusCheckRollup {
contexts(first:100) {
nodes {
__typename
... on CheckRun { name status conclusion detailsUrl workflowName }
... on StatusContext { context state targetUrl description }
}
}
}
}
}
}' -F owner=OWNER -F repo=REPO -F pr="$PR_NUMBER"4. Wait for checks to actually run
After a new push, checks can take a moment to appear. Poll every 15-30 seconds until one of these is true:
- checks have appeared and every item is in a terminal state
- checks have appeared and at least one failed
- no checks appear after a reasonable wait, usually 2 minutes
Treat these as terminal success states:
- check runs:
SUCCESS,NEUTRAL,SKIPPED - status contexts:
SUCCESS
Treat these as pending:
- check runs:
QUEUED,PENDING,WAITING,REQUESTED,IN_PROGRESS - status contexts:
PENDING
Treat these as failures:
- check runs:
FAILURE,TIMED_OUT,CANCELLED,ACTION_REQUIRED,STARTUP_FAILURE,STALE - status contexts:
FAILURE,ERROR
If no checks appear for the latest SHA, inspect .github/workflows/, workflow
path filters, and branch protection expectations. If the missing check cannot be
caused or fixed from the repo, escalate.
5. Investigate failing checks
For GitHub Actions failures, inspect runs and failed logs for the current SHA:
gh run list --commit "$HEAD_SHA" --json databaseId,workflowName,status,conclusion,url,headSha
gh run view <RUN_ID> --json databaseId,name,workflowName,status,conclusion,jobs,url,headSha
gh run view <RUN_ID> --log-failedFor each failing check, classify it:
| Failure type | Action |
| Code/test regression | Reproduce locally, fix, and verify |
| Lint/type/build mismatch | Run the matching local command from the workflow and fix it |
| Flake or transient infra issue | Rerun once if evidence supports flakiness |
| External service/status app failure | Escalate with the details URL and owner guess |
| Missing secret/permission/branch protection issue | Escalate immediately |
Only rerun a failed job once without code changes. Do not loop on reruns.
6. Fix actionable failures
If the failure is actionable from the checked-out code:
- Read the workflow or failing command to identify the real gate.
- Reproduce locally where reasonable.
- Make the smallest correct fix.
- Run focused verification first, then broader verification if needed.
- Commit in a logical commit.
- Push before re-checking the PR.
Do not stop at a local fix. The loop is only complete when the remote PR checks for the new head SHA are green.
7. Push and repeat
After each fix:
git push
sleep 5Then refresh the PR metadata, get the new HEAD_SHA, and restart from Step 3.
Exit the loop only when:
- all checks for the latest head SHA are green, or
- a blocker remains after reasonable repair effort, or
- the max iteration count is reached
8. Escalate blockers precisely
If you cannot get the PR green, report:
- PR URL
- latest head SHA
- exact failing or missing check names
- details URLs
- what you already tried
- why it is blocked
- who should likely unblock it
- the next concrete action
Good blocker examples:
- external status app outage
- missing GitHub secret or permission
- required check name mismatch in branch protection
- persistent flake after one rerun
- failure needs credentials or infrastructure access you do not have
Output
When the skill completes, report:
- PR URL and branch
- final head SHA
- green/pending/failing check summary
- fixes made and verification run
- whether changes were pushed
- blocker summary if not fully green
Notes
- This skill is intentionally narrower than
check-pr: it is a repair loop for PR checks. - This skill complements
greploop: Greptile can be perfect while CI is still red.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

