Skip to main content

/pr-fixer — Address PR feedback locally

Read every comment thread on the current branch’s GitHub PR, implement reasonable fixes locally (respecting repo rules), and summarize what was done or intentionally skipped—without committing or pushing. Use when the user runs /pr-fixer or asks to address PR review feedback locally.

Source: .agents/skills/pr-fixer/SKILL.md

Metadata​

  • name: pr-fixer

Content​

/pr-fixer — Address PR feedback locally

When this skill runs, the agent loads all review and discussion comments for the open pull request matching the current Git branch, triages them, implements reasonable code changes in the working tree only, and delivers a clear report. Do not git push. Do not commit unless the user explicitly asks — keep changes uncommitted so the developer can review diff and commit themselves.

Prerequisites​

  • Repo git root; gh authenticated (gh auth status).
  • Current branch has an open PR, or the user provides a PR number (see below).

1. Resolve the PR​

git branch --show-current
gh pr view --json number,url,baseRefName,headRefName 2>/dev/null \
  || gh pr list --head "$(git branch --show-current)" --json number,url --jq '.[0]'

If multiple PRs exist for the head branch, use the open one or ask the user once to pick a number.

Optional user override: /pr-fixer 8893 → use that PR after confirming it matches expectations.

2. Fetch all comments (nothing skipped)​

Use the PR number (N) and owner/repo from gh repo view --json nameWithOwner -q .nameWithOwner (or infer from remote get-url origin).

Gather all of the following and merge into one triage list:

SourcePurpose
Review threads (inline)gh api repos/<owner>/<repo>/pulls/N/comments — path, line, body, user, in_reply_to_id, id
Conversation on PRgh api repos/<owner>/<repo>/issues/N/comments — general issue comments
Reviews (summary / approve / request changes)gh api repos/<owner>/<repo>/pulls/N/reviews — body, state, user

If the API returns pagination, follow Link headers or use --paginate with gh api so every comment and review is loaded.

Deduplicate by subject: same file + same line + similar text can be treated as one actionable item with multiple quotes.

3. Triage each thread​

For each comment (or grouped thread):

  • Actionable — clear code/test/docs change, aligns with repo behavior and .agents/rules/*.mdc.
  • Needs clarification — ambiguous; do not guess a large refactor — reply only in your summary and ask one focused question if needed.
  • Won’t fix (not reasonable) — wrong, outdated (superseded by later commits), product/policy decision, intentional design, or riskier than scope — reply in your summary with brief justification (no snark); no code change.
  • Bot / noise — e.g. stale linters, formatting-only nits already fixed — note “skipped as obsolete” if verifiable from current HEAD.

Apply code-review mindset when fixing: follow .agents/skills/code-review/SKILL.md and project rules (services &#123; data, error &#125;, no gratuitous useCallback, etc.). If a comment touches a documented product domain, load .agents/skills/feature-context/SKILL.md and the relevant .agents/references/features/*.md file before editing.

4. Implement fixes (local only)​

  • Edit files in the workspace; prefer minimal, targeted diffs scoped to the feedback.
  • If a fix changes durable domain behavior, update the matching .agents/references/features/*.md file.
  • Run linters/typecheck only on touched areas if fast and useful: e.g.
    npx eslint <paths> / npx tsc --noEmit — fix new issues you introduce.
  • Do not:
    • git push (forbidden)
    • git commit unless the user explicitly requests a commit in the same turn
  • git add: avoid unless the user asked to stage; default is uncommitted working tree.

If a fix spans many files purely from one comment, split into atomic edits per file still without committing.

5. Reply vs fix (documentation)​

End with a structured report:

## PR
- Branch: …
- Link: …

## Fixed locally (working tree, not pushed)
- [file] — reviewer point — what changed

## Replied only / not fixing
- Quote or summary — why (no code change)

## Needs input from developer
- …

Reply in this chat — do not post rebuttal comments on GitHub unless the user asks you to engage on the PR.

6. Verification​

Before finishing:

  • git status — list modified files for the developer.
  • Confirm no push occurred and no commit unless requested.

Optional: unresolved threads​

Leaving GitHub threads unresolved after local fixes is preferred so the reviewer can verify. Do not resolve threads programmatically unless the user asks.