codebase-audit
Codebase Audit
A systematic audit that builds deep understanding of the project before identifying problems. The understanding phase isn't just a formality -- it's what lets you distinguish "this constant is fine" from "this constant will break in production."
Phase 1: Understand the Project
Before looking for problems, you need to know what the project is and how it's built. Without this context, you'll flag things that are intentional and miss things that are actually broken.
-
Read the docs thoroughly. Start with AGENTS.md and README.md (or whatever top-level docs exist). Read them completely -- don't skim. These tell you what the project does, how it's structured, and what conventions it follows. If there's a CLAUDE.md, CONTRIBUTING.md, or architecture doc, read those too.
-
Investigate the code structure. Use code navigation to understand the technical architecture: what the main modules are, how they connect, what the entry points are, what external services it talks to. Build a mental model of the system before you start auditing it.
The goal is to understand the project well enough that you could explain its architecture to someone in 2-3 paragraphs. If you can't do that yet, keep reading.
-
Summarize your understanding. Before moving to Phase 2, briefly state what the project does and how it's structured. This forces you to crystallize your understanding and gives the user a chance to correct any misunderstandings before you start the audit.
Phase 2: Find Hardcoded Constants
Search the entire project for values that are hardcoded but should be dynamic -- meaning they'll be wrong in some environments, over time, or under different conditions.