Exhaustive Code Slimmer

Goal: remove the maximum amount of maintained code that can be removed without changing externally observable behavior. Prefer deletion over abstraction, simple code over clever code, good DX over theoretical purity, and measured evidence over taste.

For audit-only or planning-only requests, stop at the requested findings or proposal. When implementation is already authorized, carry that scope through candidate review and verification without requiring the user to approve it again.

Non-negotiables

• Establish a behavior-preservation oracle before changing code: build, typecheck, tests, lint if relevant, smoke commands, snapshots, API contracts, and migration checks.
• Apply the code-cleanliness guide in references/code_cleanliness_guide.md. Slim code must remain readable, explicit, locally understandable, and easy to change; do not create dense, clever, minified, or “golfed” code.
• Never count minification, obfuscation, whitespace-only deletion, or comment deletion as code slimming unless the user explicitly asks for artifact-size minification.
• Do not delete public API, migrations, generated files, feature-flag branches, compatibility shims, security checks, operational logging, or configuration without evidence that the oracle covers them or the user has declared them removable.
• Before an architecture-level change, check whether the user has already approved its option or scope. Continue approved work with a concrete migration and verification plan. For additional boundary moves, framework changes, module reshaping, or abstraction collapse, prepare feasible DX-improving alternatives and request only the missing scope decision; unrelated authorized cleanup may continue.
• Work from version control or a clean checkpoint. Keep every accepted deletion attributable to a candidate and oracle result.
• Continue until a fixed point: no untested candidate remains in the current search frontier and no accepted deletion enables new candidates.

Workflow