pr-review-apply

You have been invoked as a skill. Execute the steps below immediately. Do not deliberate about whether to respond. Start with Step 1 now.

Apply PR Review Fixes

Read the plan artifact produced by /pr-review:pr-review-plan, verify each finding against the current code, and apply fixes. This skill only makes local working-tree changes — it never posts to GitHub, creates commits, or touches CLAUDE.md.

This skill is often run in a fresh session after /pr-review:pr-review-plan. Do not assume the plan is in context — always read it from disk.

Prerequisites

• A plan artifact exists at .pr-review/pr-<N>-plan.md with status triaged or fixing
• The plan was created by /pr-review:pr-review-plan

Step 1: Locate the plan file

Find the most recent plan file in .pr-review/. If there are multiple, ask the user which PR to work on.

Check the **Status** header:

• triaged or fixing → proceed
• fixed → warn "Fixes already applied. Run /pr-review:pr-review-post to reply and resolve."
• posted → warn "This plan has already been posted. Nothing to do."

Update status to fixing.

Step 2: Apply fixes

Verify each finding against the current code and only fix it if needed.

Trust the plan. The plan file describes exactly what to change and where — file paths, line numbers, fix descriptions, and suggestion text. Do not re-discover code structure with Grep/Search. Follow the plan's **Fix** field directly.

Group all actionable threads (apply_suggestion and fix) by file. Process one file at a time:

1. Read the file with the Read tool before making any edits. The Edit tool requires a prior Read — using Grep/Search is not a substitute. Read enough context around the target lines to verify the issue and make the edit.

2. For each thread in that file:

   • Verify the issue still exists. If the code has already been fixed or the feedback no longer applies, note it as skipped in your tracking.
   • Apply the fix only if the issue is confirmed present. Use the Edit tool's old_string parameter to match the exact code being changed — this is position-independent and robust to other edits in the file. Do not worry about edit ordering.
     • For apply_suggestion: use the exact replacement text from the suggestion block in the plan file.
     • For fix: implement the proposed fix as described in the plan's **Fix** field.
   • Track the result (fixed or skipped with reason) — you will batch-update the plan file in Step 3.

3. Move to the next file.

Do not update the plan file after each individual thread. Collect all results and batch-update in Step 3.

Step 3: Batch-update plan status

After all fixes are applied, update the plan file in a single Write call:

• Read the plan file
• Update the header: **Status**: fixed
• Update every thread's **Status** line: [x] fixed, [x] skipped (reason), etc.
• Write the entire updated plan back

This avoids 20+ individual Edit calls on the plan file. One Read + one Write = 2 tool calls instead of 20+.

Step 4: Adversarial review

Dispatch a subagent to review the changes with fresh eyes. You wrote the fixes — you cannot objectively review them. A separate agent with no shared context will catch mistakes you'd miss.

Spawn the subagent with this prompt (adapt paths as needed):

Review uncommitted code changes against a PR review plan. Your job is to verify
that each fix was applied correctly and completely, and flag any problems.

Plan file: <path to .pr-review/pr-N-plan.md>

Instructions:
1. Read the plan file — focus on threads marked as "fix" or "apply_suggestion"
2. Run `git diff` to see all uncommitted changes
3. For each planned fix, verify:
   - The fix matches what the plan described
   - No unintended side effects (broken indentation, accidentally deleted lines, wrong variable names)
   - Suggestions were applied exactly as specified
   - Skipped threads were correctly identified as not needing changes
4. Check for logical flaws in the fixes themselves:
   - Does the fix actually solve the problem the reviewer identified, or does it just look like it does?
   - Are there edge cases the fix doesn't handle (null inputs, concurrency, error paths)?
   - Does the fix introduce a new bug (e.g., changing an error message but breaking the error code contract)?
   - Read surrounding code if needed — a fix that's correct in isolation can be wrong in context
5. Report: list of issues found (or "No issues found")
   - For each issue: which thread, what went wrong, what the fix should be

If the subagent reports issues, fix them before proceeding. If no issues, continue to Step 5.

Step 5: Report to user

Show the user:

• Count of threads fixed vs skipped (with reasons for skips)
• Ask:

"Fixes applied (not committed). Review the diff, then:

1. Commit and post replies now
2. I'll review the diff first (run /pr-review:pr-review-post when ready)

Which option?"

Wait for the user's response.

• Option 1: The user should commit first (git add -A && git commit), then announce: "Posting replies and resolving threads." and use pr-review:pr-review-post to continue.
• Option 2: Stop here. Do not create a git commit, post to GitHub, or touch CLAUDE.md.

Important guidelines

• Trust the plan. The plan file has everything you need — file paths, fix descriptions, suggestion text. Do not Grep for code patterns or search for where to put things. The plan already told you.
• Read before Edit. Always use the Read tool on a file before editing it. Grep/Search output does not count — the Edit tool will reject edits on files that haven't been Read.
• Use old_string matching. Match the exact code being changed, not line numbers. This is position-independent and works regardless of edit ordering within a file.
• Batch plan updates. Collect all thread results during Step 2, then write them all to the plan file in a single Step 3 call. Do not edit the plan file after each individual thread.
• Verify before fixing. The plan file may be stale if time has passed since triage. Always check the current code.
• Do not commit. The user decides when to commit.
• Do not post to GitHub. That's /pr-review:pr-review-post's job.
• Honor user edits. If the user changed a thread's classification or fix description in the plan file, follow their version, not the original triage.