agentleFS
jugoljugol/workcell/.agents/skills/prcheckloop/SKILL.md

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

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
  1. Very specific:

    If the user also wants review-comment cleanup, pair this with check-pr.

    line 21
  2. Very specific:

    Max iterations: default 5.

    line 26
  3. Distinctive:

    If no PR number is provided, detect it from the current branch:

    line 32
  4. Distinctive:

    If needed, switch to the PR branch before making changes.

    line 38
  5. Distinctive:

    Always work against the current PR head SHA:

    line 48
  6. Distinctive:

    After a new push, checks can take a moment to appear.

    line 93
  7. Distinctive:

    no checks appear after a reasonable wait, usually 2 minutes

    line 98
  8. Distinctive:

    Treat these as terminal success states:

    line 100
  9. Very specific:

    check runs: SUCCESS, NEUTRAL, SKIPPED

    line 102
  10. Distinctive:

    Treat these as pending:

    line 105
  11. Very specific:

    check runs: QUEUED, PENDING, WAITING, REQUESTED, IN_PROGRESS

    line 107
  12. Distinctive:

    Treat these as failures:

    line 110
  13. Very specific:

    check runs: FAILURE, TIMED_OUT, CANCELLED, ACTION_REQUIRED, STARTUP_FAILURE, STALE

    line 112
  14. Very specific:

    If no checks appear for the latest SHA, inspect .github/workflows/, workflow path filters, and branch protection expectations.

    line 115
  15. Distinctive:

    Only rerun a failed job once without code changes.

    line 139
  16. Distinctive:

    If the failure is actionable from the checked-out code:

    line 143
  17. Distinctive:

    Read the workflow or failing command to identify the real gate.

    line 145
  18. Distinctive:

    Run focused verification first, then broader verification if needed.

    line 148
  19. Distinctive:

    Commit in a logical commit.

    line 149
  20. Distinctive:

    Do not stop at a local fix.

    line 152
  21. Distinctive:

    all checks for the latest head SHA are green, or

    line 168
  22. Distinctive:

    If you cannot get the PR green, report:

    line 174
  23. Distinctive:

    When the skill completes, report:

    line 195

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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,isDraft

If needed, switch to the PR branch before making changes.

Stop early if:

  • gh is 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-failed

For each failing check, classify it:

Failure typeAction
Code/test regressionReproduce locally, fix, and verify
Lint/type/build mismatchRun the matching local command from the workflow and fix it
Flake or transient infra issueRerun once if evidence supports flakiness
External service/status app failureEscalate with the details URL and owner guess
Missing secret/permission/branch protection issueEscalate 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:

  1. Read the workflow or failing command to identify the real gate.
  2. Reproduce locally where reasonable.
  3. Make the smallest correct fix.
  4. Run focused verification first, then broader verification if needed.
  5. Commit in a logical commit.
  6. 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 5

Then 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.