| name | pr-autofix |
| description | Auto-fix a PR — address ALL reviewers' open feedback + failing CI, push, and reply in each addressed thread with honest attribution |
| argument-hint | [pr-number] (defaults to the current branch's PR) |
PR auto-fix
Address ALL the open review feedback on a PR, from automated and human reviewers alike, plus any failing CI. Then commit, push, and reply in each thread you addressed. This is the methodology behind Open Session's os-auto-fix label loop; it also runs standalone from a session.
You are expected to fix everything actionable, not just blockers — P2 and P3 findings included. Only leave a finding unfixed when you have a clear reason, and record that reason (see the disposition lines at the end).
This skill is headless-safe: never use AskUserQuestion or any interactive tool.
Setup
If $ARGUMENTS contains a PR number, use it; otherwise use the current branch's PR. Resolve the repo with gh repo view --json owner,name (below, <repo> is that owner/name).
gh pr view <pr> --json number,title,headRefName,state,url
If the PR isn't OPEN, stop and say so.
Gather the work
The caller may have already listed the open review feedback and failing CI checks in its prompt — treat that as current and don't re-derive it. Otherwise gather it yourself:
- Inline review comments:
gh api repos/<repo>/pulls/<pr>/comments — skip outdated ones (no current line).
- Review summaries:
gh api repos/<repo>/pulls/<pr>/reviews (every reviewer, not just bots).
- Conversation:
gh pr view <pr> --comments — humans sometimes put requests there.
- CI:
gh pr checks <pr>; for failures, read the logs and reproduce locally (run the relevant tests/typecheck/lint).
Then read the diff (gh pr diff <pr>) and enough surrounding code to understand each finding in context.
Scope governor
Review feedback is not permission to grow the PR. Before fixing each finding, classify it:
- In-scope — introduced or made worse by this PR's diff, and fixable without changing what the PR is about. Fix it.
- Follow-up — real, but pre-existing behavior, an adjacent surface, or cleanup beyond this change. Leave the code unchanged, reply in the thread proposing the follow-up (no fixed-marker), and record it on SKIPPED as "finding — out of scope, follow-up".
- Out-of-scope — needs a new API/protocol/config/storage contract, a migration, or a design decision this PR never made. Same treatment as follow-up: propose, don't implement.
Never let review-triggered fixes turn this into a different PR: if the honest fix would make the diff no longer match the PR's title and description, or would roughly double the size of the original change, stop and put it on SKIPPED instead of pushing it. And if the previous round's fixes drew new findings rather than converging, don't pile another speculative patch on top — reclassify what's left and hand the rest back.
Only genuine blockers justify breaking scope: active data loss, crash, broken build/install, or a concrete security exposure. If it's not one of those, it's not critical enough to blow up the PR.
Fix
- Make the smallest correct changes that resolve the findings and the CI failures. Match the surrounding code style. Do NOT make unrelated changes.
- Evaluate each finding critically — reviewers (bots especially) are sometimes wrong or contradict the PR's intent. A finding you reject deliberately goes on the SKIPPED line with the reason, and gets a reply explaining why (without the fixed-marker — see below).
- Fix as many findings as you reasonably can this round (P2 and P3 included) — don't stop at the blockers.
- Commit with a clear message, then push to the PR branch:
git push origin HEAD:<headRefName>.
- NEVER merge the PR (
gh pr merge is forbidden) and never force-push over other people's work.
Reply in each thread you addressed
So reviewers see it was handled. Reply via gh api repos/<repo>/pulls/<pr>/comments/<id>/replies -f body="<body>". Attribute honestly — only claim work you actually did:
- A finding you fixed in a commit you pushed this run:
<!-- os-fixed -->\nFixed in <your-short-sha>: <what you changed>.
- A finding that was already resolved by an existing commit (someone else's work, before your run):
<!-- os-fixed -->\nLooks addressed in <short-sha>: <how it is handled now>. Do NOT say you fixed it.
- A finding you deliberately did not act on: reply with your reasoning, and do NOT include the
<!-- os-fixed --> marker or the words "Fixed in". That keeps the thread open for a human.
The <!-- os-fixed --> marker (or a leading "Fixed in") is what marks a thread resolved, so only put it on threads that are genuinely handled. Never claim you or the agent fixed something a human actually fixed. This applies to human reviewers' comments too.
Disposition lines (required output contract)
End your turn with these three lines (exact keys, one line each). Open Session's auto-fix loop parses them (parseDispositions in packages/core/opensession-server/src/agents/github/autofix.ts`) to report what happened and decide whether to continue — do not rename the keys. Use "none" where a category is empty:
FIXED: <short list of findings you fixed and pushed, or none>
SKIPPED: <findings you deliberately left, each as "finding — reason", or none>
UNRESOLVED: <findings you tried but couldn't fix, each as "finding — reason", or none>
