fix-all

"fix all" is a common opening phrase and the most common failure is the half sweep: the agent fixes the first page or the first few findings and stops, and the user comes back with "scan each and every page, not just 1 and 2" or "I still see a lot of findings in the PR, old and new, fix each and every one". This skill owns the loop.

Read first

• Your user-level honesty rules: for sweep/audit tasks, enumerate the full match set first, then report progress against that count
• Stale snapshot lists: re-derive the worklist from live data before each chunk; a script's own "0 remaining" is not proof
• Don't-remove-unasked: existing UI, content and features stay
• Repo CLAUDE.md for the test, lint and build commands that count as checks here

Step 1: enumerate, print, do not touch

Collect every source that applies to the repo or PR and print one table before any edit. A source with zero findings is still a row.

| source | count | scope |
| CI checks | 2 failing | build, python |
| SonarCloud | 47 (44 new, 3 inherited) | S3776 x12, S1854 x9, ... |
| review comments | 6 unresolved | Copilot 4, human 2 |
| Dependabot | 0 | |
| CodeQL | 1 | js/incomplete-sanitization |
| lint + type | 13 | eslint 9, tsc 4 |
| tests | 0 failing | 59 pass |
TOTAL 69

Step 2: fix in dependency order

Build-breaking first, then tests, then lint and type, then security alerts, then quality findings, then review comments. After each group re-run only the check that group affects and record the new count. Rules while fixing:

• Behavior-preserving. A finding is fixed by correcting the code, never by deleting the feature, hiding the UI, downgrading the rule, adding eslint-disable, # noqa, NOSONAR, or marking won't-fix in a dashboard.
• Prod-aware. When the user says it is a production environment and to be careful, no data migrations and no schema changes inside the sweep; list them separately.
• Same branch, same PR. One work stream per PR; do not open a second PR to hold the fixes.
• Two failed attempts at one finding: stop iterating on it, list the finding with what was tried, move on. Report it in the leftover list.
• Re-derive before each group: the initial counts are a baseline, not the worklist. Query the source again so findings that appeared since are caught.

Step 3: report against the baseline

| source | before | after | fixed | left |
| CI checks | 2 | 0 | 2/2 | - |
| SonarCloud | 47 | 3 | 44/47 | S3776 in legacy/parser.ts x3 (complexity split would change behavior; listed for review) |
| review comments | 6 | 0 | 6/6 | - |
| CodeQL | 1 | 0 | 1/1 | - |
| lint + type | 13 | 0 | 13/13 | - |
TOTAL 69 -> 3, fixed 66/69

verified by: <the exact commands re-run and their final output line>
not done on purpose: <features not asked for, tests not asked for>

Then, only if the message asked for it, hand to ship ("fix all and merge", "push and create PR"). Otherwise stop with the branch pushed and the receipt.

Must not

• Never stop before the enumeration table is complete, and never fix before printing it.
• Never remove existing UI, content, footers, credits or features to make a finding disappear.
• Never report a fix without the before and after counts from a re-run check.
• Never add tests, docs, refactors or "while I was here" changes that were not asked for; list them as suggestions at the end if worth it.
• Never silence a rule to reach zero.
• Never run when the user said to skip the quality gates and focus on the feature (for example "not sonar, just focus on the UI"); that message suspends the gates for the session.

Non-goals

Deep whole-repo analysis with a report and no edits is repo-audit. A Sonar only sweep with rule-by-rule reporting is sonar-sweep, which this skill calls for the SonarCloud row. Merging is ship. Prod verification is prod-check.