audit-and-remediation

Audit and remediation

Audit code that already exists and turn findings into a sequenced, owned remediation plan. This is distinct from greenfield planning: you are not designing a system from scratch (the execution-plan templates cover that), you are assessing what is there, ranking what is wrong, and deciding who fixes what, in what order, gated by explicit exit criteria.

Use this skill when asked to review a codebase for health, tech debt, or risk; to triage a backlog of known defects; or to produce a remediation roadmap someone can execute against.

1. Produce the audit doc

An audit is documentation, not a single wall of text. Produce an audit doc -- split it into multiple files when the audit is large, so each part can be updated independently as remediation proceeds -- covering three things:

1. Scope + method. What was and was not examined, the HEAD SHA the audit was run against, and the audit date; plus how the audit was conducted so it is reproducible (paths/layers/subsystems inspected, tools/commands run, what was explicitly out of scope, and the severity rubric used). A finding is only as trustworthy as the method that produced it. A one-paragraph executive summary up top helps a reader orient.
2. Findings ranked across the three lenses. The findings themselves, each with a stable ID, a location (path + anchor), evidence, and its three-lens ranking (Step 2). Group by subsystem or theme to keep a long list navigable. Where it helps, capture the system as it actually is today -- components, boundaries, data flow, load-bearing invariants -- and note where reality diverges from the intended design.
3. A sequenced action list with exit criteria. Findings converted into discrete, actionable items -- one item = one deliverable -- each carrying its three-lens priority, a cost/effort class and ownership (Step 3), and a work lane (Step 5), then sequenced into phases gated by written exit criteria (Step 6).