/apply-findings

name: apply-findings
description: "Apply findings by making the suggested code changes. Applies accepted verdicts, escalates ambiguous findings to the user, and offers to note genuine improvements for later. Use when the user asks to \"apply findings\", \"apply fixes\", \"apply suggestions\", \"apply accepted findings\", \"fix the findings\", or \"apply the review results\"."

Apply Findings

Apply evaluated findings from the conversation context. Findings must have been through `/evaluate-findings` first.

Step 1: Identify Findings

Collect all findings from the conversation context. Findings should have Verdict columns (Apply, Skip, Escalate) from `/evaluate-findings`.

If findings are unevaluated (raw output without verdicts), stop and say to run `/evaluate-findings` first.

Step 2: Apply in File Order

Group Apply findings by file path and apply in file order to minimize context switching. For each finding:

1. Read the full function or logical block at the referenced location 2. Verify the finding still applies to the current code 3. When the finding carries a suggested fix, treat the fix as a separate claim from the finding and verify it independently before applying it — trace it against the failure modes the finding names, then against the behavior the code had before the fix on inputs the finding never mentioned, since a remedy can address the named mode while regressing an axis alongside it. Where the finding arrives with opposing remedies recorded, verify the measured one first, and where none was measured, measure before applying rather than choosing on the proposer's authority. When the fix encodes, escapes, quotes, or otherwise sanitizes untrusted input, enumerate the character classes the target interpreter treats specially and name the construct in the fix that blocks each one; a class with no blocker means the fix is incomplete, including when it reproduces the finding's suggested wording. If the fix does not hold up, treat the finding as Escalate (surface it in Step 3) and record why the remedy fails, rather than applying an unsound fix on the finding's authority. 4. When the fix would reverse a decision the user made earlier — in discussion or recorded in the artifact — treat the finding as Escalate (surface it in Step 3) and name the original decision. Judge by the outcome rather than the wording of the option the user chose: a reversal leaves the user with something materially different from what they chose. When the finding refutes only the factual premise the user's choice rested on and the fix leaves the chosen outcome intact, that is a premise correction: confirm the refutation against whichever of the code, the governing artifact, or authoritative documentation the premise turns on, and when none settles it, treat the finding as Escalate. Otherwise continue with the remaining checks, and state both the corrected premise and the chosen outcome it leaves standing in Step 4. 5. Check what the fix you are about to make changes about the inputs the code accepts. When the change in accepted inputs is exactly the defect the finding names, apply it normally. When it turns away or newly admits anything beyond that defect — a value or path a legitimate caller could send — that is a behavior change: treat the finding as Escalate (surface it in Step 3) and name the input class that changes. 6. Make the fix 7. If the finding renames an identifier or changes a recurring shape — a type signature, call pattern, or wrapper that appears in many places — search every caller and reference the change reaches, not only the changed files, by concept rather than by the literal just replaced: a stem that survives inflection and compounding, or the shape common to every variant. A clean search proves nothing when its pattern was derived from a single instance, and the cited location is often only one of several references. When the finding names several sites, also tick them off against the finding text. Complete the sweep before marking the fix complete. 8. When the fix adds or edits a comment stating a contract — what is handled, what is excluded, what callers may rely on — verify the code enforces that contract before marking the fix complete. When it does not, add the enforcement rather than narrowing the comment.

If a finding references code that has changed since it was generated (e.g., by a prior fix in this same run), re-assess whether it still applies. Skip if the code has diverged.

When an escalated finding's outcome would change what the other fixes should look like, settle it in Step 3 before applying them.

Step 3: Handle Escalated Findings

For findings with Escalate verdict, use `AskUserQuestion` to let the user decide. Output the finding's technical detail as text first, then state the question as the decision the user owns. When the finding is a disagreement between two artifacts, ask which behavior is wanted; reconciling the artifacts follows from that answer.

Recommend the genuinely best option: place it first and append `(Recommended)` to its label, judging "best" on technical merit alone (the soundest engineering outcome), independent of how closely the option conforms to the task's original scope. When the choice hinges on product intent or domain knowledge you lack and merit cannot settle it, say so instead of forcing a pick. Give each option a plain-language description that carries the trade-off: its concrete effect and what it costs. When the recommended option also widens the changeset's scope, name both its merit and that scope cost so the user can weigh them. When an earlier escalation already widened the changeset, state the running total alongside this option's increment. When the choice is costly to reverse — it establishes a pattern others will follow, defines an interface, or commits to a data shape — include the consultation option alongside the concrete alternatives, labeled "Get a second opinion". Include it as well whenever no o