Audit template
lean
Find the bloat, dead codeCode that can never execute or is never referenced, so removing it changes nothing., and unused dependencies — without deleting anything load-bearing.
Maps to: Google Eng · OWASPOpen Worldwide Application Security Project — the reference catalog of web-application security risks. · YAGNIYou Aren't Gonna Need It — a principle against building functionality before it is actually required.
specialists, in parallel
Each finding is evidence-bound and survives ≥2-of-3 adversarial skeptics.
How this audit works
A read-only leanness audit across five dimensions: dependency transparency and supply chain, dead codeCode that can never execute or is never referenced, so removing it changes nothing. and orphan filesFiles that no other part of the codebase imports or references, so nothing reaches them., duplication, AI slopLow-value, redundant code or text that AI agents generate in bulk without adding real substance. and defensive boilerplate, and over-engineering. It builds an SBOMSoftware Bill of Materials — a complete inventory of the components and dependencies a piece of software ships. and a reachability mapA graph of which code is actually reachable from real entry points, used to prove what is unused. first, then gates every removal behind Chesterton's FenceThe principle that you should not remove something until you understand why it was put there. and a Resurrector skeptic — so each cut is sorted into remove-now, investigate, deprecate, or protected, never a blind delete.
Use it when
Inheriting an AI-generated codebase
After months of agent-written code, you suspect duplicated utilities, restating-the-code comments, and over-defensive boilerplate but cannot prove it. The audit reports duplication density with both clone locations, flags log-and-continue catch blocks, and names which simplifications are behaviour-equivalent.
Trimming the dependency surface before a release
You want to shrink install and supply-chain risk but fear breaking a fresh install. It separates declared-but-unused dependencies from phantomA package the code actually uses but never declares in the manifest, so it works only by accident. used-but-undeclared ones, explains why every transitiveA dependency you don't depend on directly — it is pulled in by one of your direct dependencies. package is present, and checks the lockfile and licenses against policy.
Deciding whether dead code is really dead
A static tool flagged unused exports and orphan filesFiles that no other part of the codebase imports or references, so nothing reaches them., but reflection, dynamic imports, and out-of-repo consumers make you hesitant to delete. The audit traces the reachability mapA graph of which code is actually reachable from real entry points, used to prove what is unused., states which dynamic channels were ruled out, and labels each candidate proven-dead or only suspected-dead.
What you get
A leanness scorecard plus prioritized GitHub issues, each with a removal class, the reachability proof, and a before/after fix with a revert note.