Audit Code Complexity

Find code that is harder to understand, change, or verify than the problem requires, and propose simpler shapes that keep its behavior. Simpler means easier to understand and change while keeping every real requirement; fewer files, functions, or lines do not by themselves make code simpler. This is an audit: do not edit code unless the user asks.

1. Set the scope

• Current state: audit the named code as it exists, whenever its complexity was introduced.
• Change: audit only complexity that the named commits, branch, or pull request introduced or made worse. Read surrounding code for context.
• Proposal: audit a design or code the user proposes before it is built, against the requirements it states. A request to revise the proposal changes the proposal, not the code it describes.

Use the change scope only when the user names a change; uncommitted work in the repository is not a reason to switch. If the user asks for both, report them separately.

For a large target, split it by module across parallel read-only subagents where available, and verify their findings yourself before reporting.

2. Look for complexity

Read the target, the repository instructions, the callers, the tests, and the configuration, plus only the docs needed to understand required behavior. Use git log to see which files change most often; complexity there costs the most. Separate the behavior and contracts callers rely on from assumptions and nice-to-haves nobody asked for; dropping behavior that callers or users could notice is the user's decision, so recommend it rather than assume it.

Look for: