agentleFS
markphelpsmarkphelps/agent-plugins/skills/github-pr-fixup/SKILL.md

github-pr-fixup

Skill5 starsChanged 45 days agoMITView on GitHub

Fix review feedback and CI failures on an existing GitHub pull request. Work on the PR's source branch. Do not open a new PR. Verify both tools exist before doing anything else: If either command is missing, stop and tell the user to run: Extract the PR number from the URL: Stop if PR_NUMBER is empty. Use GraphQL so you can ignore resolved threads and outdated comments. Focus only on threads where: Read each active thread carefully. Fix the requested…

  • Installs packages

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 15 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈15

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Verify both tools exist before doing anything else:

    line 16
  2. Distinctive:

    If either command is missing, stop and tell the user to run:

    line 23
  3. Very specific:

    Stop if PR_NUMBER is empty.

    line 39
  4. Distinctive:

    Check out the existing PR branch.

    line 43
  5. Distinctive:

    Read PR metadata you will need later.

    line 49
  6. Distinctive:

    Use GraphQL so you can ignore resolved threads and outdated comments.

    line 57
  7. Distinctive:

    Read each active thread carefully.

    line 90
  8. Distinctive:

    Check CI status for the PR head commit.

    line 94
  9. Distinctive:

    Run the smallest relevant validation that covers the fixes you made.

    line 121
  10. Distinctive:

    Commit and push fixes to the existing source branch.

    line 126
  11. Distinctive:

    Do not create a new branch and do not create a new PR.

    line 128
  12. Distinctive:

    Never open a new PR.

    line 132
  13. Distinctive:

    Never resolve review threads unless the user explicitly asks.

    line 133
  14. Distinctive:

    Prefer the PR head repository and branch already associated with the PR.

    line 135
  15. Distinctive:

    Keep fixes scoped to active review feedback and failing CI unless you find a directly related root cause.

    line 136
  16. Distinctive:

    If a CI failure depends on unavailable secrets, external services, or flaky infrastructure, state that clearly and avoid speculative code …

    line 138

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

GitHub PR Fixup

Fix review feedback and CI failures on an existing GitHub pull request. Work on the PR's source branch. Do not open a new PR.

Required tools

Verify both tools exist before doing anything else:

gh --version
jq --version

If either command is missing, stop and tell the user to run:

brew install gh jq

Inputs

  • GitHub URL: $ARGUMENTS

Extract the PR number from the URL:

PR_NUMBER="$(echo "$ARGUMENTS" | grep -oE '[0-9]+$')"

Stop if PR_NUMBER is empty.

Workflow

  1. Check out the existing PR branch.
gh pr checkout "$PR_NUMBER"
  1. Read PR metadata you will need later.
gh pr view "$PR_NUMBER" --json number,title,headRefName,headRepositoryOwner,headRepository,headRefOid,baseRefName,url
  1. Gather unresolved review feedback.

Use GraphQL so you can ignore resolved threads and outdated comments.

gh api graphql -f query='
query($owner: String!, $repo: String!, $number: Int!) {
  repository(owner: $owner, name: $repo) {
    pullRequest(number: $number) {
      reviewThreads(first: 100) {
        nodes {
          isResolved
          isOutdated
          path
          line
          comments(first: 20) {
            nodes {
              author { login }
              body
              createdAt
              url
            }
          }
        }
      }
    }
  }
}' -F owner="$(gh pr view "$PR_NUMBER" --json headRepositoryOwner -q '.headRepositoryOwner.login')" -F repo="$(gh pr view "$PR_NUMBER" --json headRepository -q '.headRepository.name')" -F number="$PR_NUMBER"

Focus only on threads where:

  • isResolved == false
  • isOutdated == false

Read each active thread carefully. Fix the requested changes in code, tests, docs, or config as needed. If comments conflict, prefer the most recent reviewer guidance and note the conflict in your final summary.

  1. Check CI status for the PR head commit.
HEAD_SHA="$(gh pr view "$PR_NUMBER" --json headRefOid -q '.headRefOid')"
gh pr checks "$PR_NUMBER"
gh run list --commit "$HEAD_SHA" --json databaseId,status,conclusion,name,event,workflowName,headSha,url
  1. Investigate failed runs only.

Filter for failing runs:

gh run list --commit "$HEAD_SHA" --json databaseId,status,conclusion,name,event,workflowName,url | jq '.[] | select(.conclusion == "failure")'

For each failed run:

gh run view <run-id> --log-failed

Diagnose the underlying failure from the failed job log. Do not patch symptoms blindly. Fix the actual issue in code or configuration.

  1. Verify locally.

Run the smallest relevant validation that covers the fixes you made. Prefer repo-native lint, unit, or integration commands over broad full-suite runs when scope is small. If full local verification is not possible, explain why and state what you did run.

  1. Commit and push fixes to the existing source branch.

Do not create a new branch and do not create a new PR.

Guardrails

  • Never open a new PR.
  • Never resolve review threads unless the user explicitly asks.
  • Ignore resolved and outdated review threads.
  • Prefer the PR head repository and branch already associated with the PR.
  • Keep fixes scoped to active review feedback and failing CI unless you find a directly related root cause.
  • If a CI failure depends on unavailable secrets, external services, or flaky infrastructure, state that clearly and avoid speculative code changes.

Final response

Report:

  • what unresolved review comments you addressed
  • which CI failures you fixed
  • what validation you ran
  • any remaining blockers you could not complete

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.