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
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- development/AGENTS.mdAGENTS.md
- cli-designSkill
- codebase-landing-copySkill
- context-file-tuneupSkill
- course-notesSkill
- decision-recordsSkill
- feature-mapSkill
- github-self-hosted-runnerSkill
- oss-marketingSkill
- oss-repo-readinessSkill
- session-log-auditSkill
- technical-manualSkill
- verify-bugSkill
- whiteboardSkill
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
- Distinctive: line 16
Verify both tools exist before doing anything else:
- Distinctive: line 23
If either command is missing, stop and tell the user to run:
- Very specific: line 39
Stop if PR_NUMBER is empty.
- Distinctive: line 43
Check out the existing PR branch.
- Distinctive: line 49
Read PR metadata you will need later.
- Distinctive: line 57
Use GraphQL so you can ignore resolved threads and outdated comments.
- Distinctive: line 90
Read each active thread carefully.
- Distinctive: line 94
Check CI status for the PR head commit.
- Distinctive: line 121
Run the smallest relevant validation that covers the fixes you made.
- Distinctive: line 126
Commit and push fixes to the existing source branch.
- Distinctive: line 128
Do not create a new branch and do not create a new PR.
- Distinctive: line 132
Never open a new PR.
- Distinctive: line 133
Never resolve review threads unless the user explicitly asks.
- Distinctive: line 135
Prefer the PR head repository and branch already associated with the PR.
- Distinctive: line 136
Keep fixes scoped to active review feedback and failing CI unless you find a directly related root cause.
- Distinctive: line 138
If a CI failure depends on unavailable secrets, external services, or flaky infrastructure, state that clearly and avoid speculative code …
≈ “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
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 --versionIf either command is missing, stop and tell the user to run:
brew install gh jqInputs
- 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
- Check out the existing PR branch.
gh pr checkout "$PR_NUMBER"- Read PR metadata you will need later.
gh pr view "$PR_NUMBER" --json number,title,headRefName,headRepositoryOwner,headRepository,headRefOid,baseRefName,url- 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 == falseisOutdated == 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.
- 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- 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-failedDiagnose the underlying failure from the failed job log. Do not patch symptoms blindly. Fix the actual issue in code or configuration.
- 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.
- 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
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.

