fix-pr

name	fix-pr
description	Triage and implement actionable GitHub pull-request review feedback with minimal verified edits. Use only to address PR comments or requested changes; use plan-review for plans and code-review for a fresh read-only diff review.

Fix Pull Request Feedback

Inspect all review feedback, preserve non-actionable items in the report, apply the smallest correct fixes, and verify the result. This workflow may edit files but must not create unrequested external or Git state changes.

Route exclusively

• Use this skill only when the user asks to address feedback already attached to a GitHub pull request.
• Use plan-review for an implementation plan before coding.
• Use code-review for a fresh read-only review of code or a pull-request diff.
• If the user supplies a local review report rather than GitHub feedback, use ordinary implementation workflow after confirming which findings to fix.

Protect local and external state

1. Parse and confirm the PR owner, repository, number, and local repository identity.
2. Record the starting branch, HEAD, git status --short, and the existing diff before editing.
3. If unrelated changes exist, do not stash, reset, clean, overwrite, or include them. Ask whether to stop, continue around non-overlapping changes, or use a separate worktree.
4. Ask before changing branches or creating a worktree unless the user explicitly requested that transition in this turn.
5. Never commit, stage, push, resolve threads, submit reviews, or post comments unless the user explicitly requests that separate action.
6. Use read-only GitHub queries. Do not accept arbitrary API methods, GraphQL documents, or mutation input.

Accept PR references as a canonical pull-request URL, a URL ending in /files, /commits, or /checks, or owner/repo#number. Strip query parameters and trailing view paths. Stop with accepted formats when parsing fails.

Fetch complete review data

Prefer scripts/read_pr_review.py when the GitHub CLI is authenticated. It uses fixed read-only GraphQL queries, follows pagination for reviews, issue comments, review threads, and thread comments, and exposes no mutation option. A connected provider is acceptable only when it returns equivalent pagination and thread state.

Collect:

• PR URL, title, author, base/head branches, base/head OIDs, and review decision;
• reviews and their state;
• every inline thread with stable ID/URL, path, current and original lines, resolution, outdated state, authors, timestamps, and comments;
• every issue-level PR comment;
• pagination completeness and any provider limits.

If only flat comments are available, label resolution, outdated state, and thread identity as unknown. Never infer them.

Verify the exact source revision

Compare local git rev-parse HEAD with the provider's headRefOid before editing.

• If they match, continue.
• If they differ, stop editing and report both OIDs.
• With user authorization, fetch and check out or create a worktree at the exact PR head. Do not merge, rebase, or force-update unrelated work.
• After any authorized transition, compare OIDs again and record the new baseline.

Do not apply feedback to a stale approximation of the PR branch.

Classify every item

Process current code and the full thread conversation before assigning a disposition. Use stable IDs PRF-001, PRF-002, and so on.

Priority:

• P0: immediate safety, security, or irreversible-loss issue.
• P1: blocking correctness or requested-change item.
• P2: material but non-blocking improvement.
• P3: optional cleanup.
• none: no code change is requested.

Disposition:

• open: concrete, still-unsatisfied request with a current target;
• already-addressed: current PR head satisfies the request even though the thread is unresolved;
• resolved: provider marks the thread resolved;
• question: human response or clarification is required;
• skipped: praise, author-only discussion, non-requesting bot summary, or outdated item with no current target;
• blocked: actionable intent exists but the target, expected behavior, or authorization is insufficient.

Do not treat a bot summary as a human request. For a multi-comment thread, interpret the latest reviewer position together with later author replies and current code; do not mechanically select one comment while ignoring resolution context.

For outdated threads, locate the referenced symbol or behavior and confirm that the acceptance condition still applies. File or text-pattern existence alone is insufficient.

Report before editing

Present a compact inventory before changes:

ID | Priority | Disposition | Thread/comment URL | Reviewer | Timestamp | Path:line | Request | Planned target

Include all non-actionable items. Pause only when an open item requires a broad redesign or any item is question or blocked in a way that materially changes implementation.

Apply minimal, correct fixes

For every open item:

1. Read the target file, surrounding implementation, tests, and path-scoped instructions.
2. Restate the reviewer's acceptance condition.
3. Check whether current code already satisfies it; if so, change the disposition to already-addressed.
4. Treat a GitHub suggestion block as proposed text, not authoritative code. Verify its semantics, contracts, imports, security, error behavior, style rules, and test impact before applying it.
5. If the original range moved, locate the current code by symbol and behavior. Stop when identity is uncertain.
6. Implement the smallest change that meets the acceptance condition.
7. Add or adjust tests when behavior changes or the feedback exposes a missing case.

Do not expand feedback into unrelated cleanup or speculative refactoring.

For generated targets, edit the authoritative source when identifiable and authorized, then run the documented generator. Do not hand-edit generated output. For renamed files, use read-only history to prove the new location. For deleted targets, use blocked unless the reviewer clearly described a surviving behavior.

Verify portably

Inspect repository instructions and manifests, then run the narrowest available checks for changed files using the host's normal command capability:

1. required generation;
2. formatter or format check;
3. lint or static analysis;
4. compile or build;
5. focused tests;
6. broader tests only when the change warrants them.

Use documented commands first. Request any command permission the host requires; do not weaken or skip a check silently because a platform-specific allowlist is absent. Separate edit-caused failures from pre-existing, environment, or provider failures.

Review the final diff against the recorded baseline. Confirm that only intended task changes were added and that unrelated pre-existing changes remain untouched.

Final report

Return:

• PR identity, title, exact reviewed head OID, and current local branch/OID;
• each stable PRF-* item with priority, final disposition, source URL, reviewer, timestamp, request summary, and resulting file context;
• fixes applied and tests changed;
• unresolved questions, blocked items, generated targets, and provider limits;
• verification commands and results;
• final working-tree state and actions still requiring human authorization.

Do not claim that a thread is resolved merely because code changed. Only GitHub thread state or an explicitly authorized resolution action can establish that.