fix-findings

Apply the findings from the most recent review, audit, verification, lint run, test run, or other check reported earlier in this session, whatever produced it. Arguments that name findings (codes or numbers) narrow which ones; arguments that carry a finding's own text are the report, even when it came from another session. No arguments means every finding, at every severity. A finding the report left as a choice for the user: apply the option the arguments name, else the one the report recommended in so many words ("I recommend X"), worded exactly as it was offered. An option listed first or labelled "proposed" is not a recommendation. With none named, apply no option: ask the caller which one to take, and report the finding as <code>: pending, <the choice it waits on> until the caller answers. The out-of-scope deferral in step 4 is the one open choice with its own form, <code>: deferred, follow-up pending.

1. No such report in this session and no finding text in the arguments: say so and stop. Do not go looking for problems to invent.
2. Before the first edit in each affected repository, discover and read its applicable AGENTS.md, CLAUDE.md, and CONTRIBUTING.md, including any instructions they point to. Repeat this before touching another repository. Record absent instruction files separately from a repository whose available instructions document no checks.
3. Fix root causes, not the symptom each finding names. Grep every caller before editing a shared function: one guard where the callers converge beats a guard in each of them.
4. Do not expand scope. A finding is a fix, not an invitation to refactor around it. If its fix needs a schema or data migration, a new ADR, or a redesign beyond the branch's change (a new subsystem, scheduler, or cross-module restructuring), check whether the defect already exists at the merge base with the default branch. If it does, the fix is out of scope for this branch: do not apply it. Offer filing a follow-up issue and say "I recommend a follow-up issue". Until the caller chooses, report the finding as <code>: deferred, follow-up pending (this form, not pending, even when the report also left the finding as a choice), and name no issue. When the follow-up is chosen, create it with the Create an issue operation in docs/agents/issue-tracker.md, or gh issue create when that file is missing, including the defect, its evidence, and the proposed fix, then report the finding as <code>: deferred to <issue>. When it is declined, report <code>: deferred, follow-up declined. A defect introduced by this branch is still fixed on the branch, whatever the size, following the rules below. For in-scope findings, when the finding proposes a fix, apply that fix, together with any change it cannot work without, and name that change on the finding's report line. If it cannot work even so, skip the finding and say why instead of choosing another. If it works at only some of the places the finding names, apply it there and report the finding as partly fixed.
5. For every edited repository, run its required checks and make its other required edits (a version bump, a changelog entry). Done when each edited repository has its checks run, or the report distinguishes unavailable instructions from available instructions that document no checks.
6. Report one line per finding: <code>: fixed, <code>: partly fixed, <what is left and why>, <code>: pending, <the choice it waits on>, <code>: deferred, follow-up pending, <code>: deferred to <issue>, <code>: deferred, follow-up declined, or <code>: skipped, <why>. Then one line per edited repository with the checks run. Say plainly when a finding was wrong.

Do not commit. The user commits with /commit or /ship-pr in Claude linked installs or Cursor, /supermatt:commit or /supermatt:ship-pr from the Claude plugin, $commit or $ship-pr in Codex, or /skill:commit or /skill:ship-pr in OMP.