Strip Lovable scaffolding and ship a clean codebase

Lovable Cleanup audits fifteen areas where an exported Lovable project can retain unwanted scaffolding. It covers the lovable-tagger dependency, Vite configuration, entry points, branding files, generated documentation, package scripts, environment references, Git configuration, deployment metadata, and unused component packages. Required copyright, license, and contributor attribution remain intact when product branding changes.

The workflow starts by inspecting source and configuration references before removing dependencies. It clears the tagger import and componentTagger call from Vite, updates the manifest and lockfile with the existing package manager, and checks entry points for wrappers or generated references. Documentation comes later so the README reflects the cleaned project. Useful architecture notes are preserved or rewritten rather than deleted solely because a filename appears in a checklist.

Branding cleanup reviews the page title, generator metadata, favicon references, social images, and placeholder assets. Existing icon paths receive replacement content because deleting a favicon can leave browsers or a CDN serving an older copy. The skill checks icon links, revalidation behavior, and the actual live response after deployment, then purges only the confirmed Vercel project if the content remains stale. Replacement assets are backed up first.

Use it when cleaning an exported Lovable project, auditing leftover branding, or preparing a Vite/React codebase for shipping or open sourcing. It can also focus on unused Radix dependencies rather than perform the entire cleanup. Dependency pruning remains a candidate audit: direct import matches alone do not establish safety.

The skill does not supply genuine brand artwork, automatically repair components.json aliases, or review Lovable-specific backend integrations such as Supabase row-level security and edge functions. Those need separate inputs or review. A transparent placeholder icon is available when genuine artwork is absent, but it is not a replacement for a real brand asset.

Inputs are the exported project, its actual package-manager setup, and any replacement name, domain, or artwork. For an initial dependency-reference scan, use:

grep -n "lovable" package.json

Search results are hints to inspect, not automatic deletion instructions. The audit includes dynamic imports, CSS and asset references, workspaces, tests, and package metadata. Radix pruning preserves react-slot because shadcn components can use it indirectly through asChild. Package removal follows the project's dependency policy because lifecycle scripts and network access can be involved.

Environment scanning reports filenames without exposing matching credential values. Lockfile leftovers prompt investigation of direct and transitive references rather than an immediate destructive reinstall. Runtime title overrides are checked when an edited HTML title does not appear in the browser. GNU-specific search examples require an appropriate available tool.

The final cleanup report lists changes, decisions requiring input, and deferred items. Build checks accompany dependency changes, while runtime behavior, license clearance, and deployed asset bytes need their own inspection.

The workflow targets Vite, React, shadcn/ui, and Radix UI projects, using npm, yarn, or pnpm as appropriate. It also scans common Vercel and Netlify configuration and includes targeted Vercel favicon-cache troubleshooting.