lovable-codebase-audit-cleanup

Lovable Codebase Audit & Cleanup

This skill governs two distinct, sequential phases of codebase rationalization. They must never be merged into a single pass. Determine which phase applies before doing anything else.

Phase routing

1. No prior audit exists, or the user asks to inspect/find/review issues → run Phase 1: Audit.
2. An audit report already exists and the user references an approved batch or finding IDs to implement → run Phase 2: Cleanup.
3. The user asks to "clean up" without a prior audit → do not skip to editing. Run Phase 1 first, present the findings and the batch roadmap, and wait for explicit batch approval before touching any code.

Never combine phases in one response. Never modify code while still in Phase 1.

---

Phase 1: Audit (read-only)

Use Plan mode (or the project's equivalent read-only/chat mode). Perform a comprehensive, read-only audit of the entire existing codebase to identify dead code, unused code, obsolete dependencies, duplicated implementations, and maintainability risks.

Do not modify, delete, rename, move, or refactor any file during this phase.

Objective

Rationalize the codebase to make it as professional, maintainable, predictable, and technically robust as possible. Identify code that:

• Is no longer referenced or executed, or is unreachable.
• Is obsolete or superseded by a newer implementation.
• Duplicates existing functionality.
• Adds unnecessary complexity or creates maintenance risk.
• Could produce technical issues in future releases.
• Increases bundle size, build time, runtime overhead, or cognitive load without providing value.
• Is inconsistent with the architecture and conventions currently used by the project.

Audit scope

Inspect the complete repository, including:

• Application routes and route registrations.
• Pages, layouts, components, hooks, utilities, services, providers, contexts, stores, reducers, actions, schemas, types, interfaces, constants, configuration files, tests, scripts, styles, assets, and public files.
• Frontend and backend code, if both are present.
• Supabase or Lovable Cloud integrations: migrations, Edge Functions, database clients, queries, RPC calls, storage usage, authentication logic, generated types.
• Package dependencies and dev dependencies.
• Build configuration, TypeScript configuration, linting configuration, environment-variable usage, import aliases, deployment configuration.
• Feature flags, role-based flows, experimental features, legacy implementations, commented-out code, temporary workarounds, stale TODOs.
• CSS classes, design tokens, stylesheets, images, icons, fonts, and other assets that may no longer be used.
• Tests, mocks, fixtures, and test utilities that no longer correspond to active functionality.