fix-audit

Skill: fix-audit

Implement findings from the latest audit report for a package, one item at a time.

Arguments: <package-name> [developer notes] — package name plus optional free-text notes (e.g. "only fix #1", "skip #2, needs discussion", "fix all but use X pattern for #1 instead").

---

Phase 0 — Load

Find the most recent audit/*-{package-name}*.md (sort by filename date descending). Record this exact filename — it is the audit file for all later steps. Extract unresolved Critical items — an item is resolved if it contains **Resolved or has strikethrough text.

If no unresolved Criticals exist, check developer notes — if they say "important", work the Important tier instead.

Print the final work list before starting any changes.

---

For each item (work sequentially — fully complete one before starting the next)

Step 1 — Read before touching

Re-read the relevant source files in packages/{package-name}/src/. Verify the bug still exists at the exact file:line the audit references. Apply developer notes if they override the implementation approach.

Step 2 — Implement

Minimal change that fixes exactly what the audit item describes. Rules:

• Never use TypeScript escape hatches (as any, @ts-ignore, @ts-expect-error without justification)
• Never add eslint-disable comments to hide a warning caused by the fix
• Never skip writing tests

Step 3 — Self-review

Before running tests, ask:

• Does the fix make sense in the full application context?
• Are callers in other packages affected? Check usages with grep across packages/ and examples/.
• Does it change a public contract — exported type, hook return shape, event payload?
• Is there anything the audit item missed that makes the fix incomplete?

Step 3.5 — Write tests first

Write a test that would have failed before the fix and passes now. Assert the exact corrected behaviour. Place the test in the package's existing test file or create a new *.test.ts alongside the changed file.