How do I install the Lovable Cleanup skill?

Run npx skillmds add whoisabhishekadhikari/lovable-cleanup in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Lovable Cleanup skill do?

Audits and strips Lovable scaffolding from Vite + React projects — removes lovable-tagger, swaps placeholder assets, prunes unused Radix deps, cleans generated docs, and neutralizes stale favicon/CDN caching so the codebase ships as yours. It is listed under Web & Frontend on SkillMD.

Is Lovable Cleanup safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: executes scripts, makes network calls. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Lovable Cleanup?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Lovable Cleanup free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Lovable Cleanup?

whoisabhishekadhikari (@whoisabhishekadhikari) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Lovable Cleanup by whoisabhishekadhikari

Name: Lovable Cleanup
Rating: 4.666666666666667 (3 reviews)
Author: whoisabhishekadhikari

lovable-cleanup

Remove every trace of Lovable scaffolding and ship the project as your own. Made with agentic-awesome-skills · author: whoisabhishekadhikari

Overview

Lovable (lovable.dev) bootstraps Vite + React + shadcn/ui projects with its own tagger dependency, branding, placeholder assets, and generated markdown docs baked in. Most developers export from Lovable and want a clean, ownable codebase before shipping or open-sourcing. This skill covers all 15 areas where Lovable leaves fingerprints.

When to Use This Skill

User says "clean up my Lovable project" or "remove Lovable branding"
User says "de-Lovable", "I exported from Lovable", or "audit for Lovable leftovers"
Project contains lovable-tagger in package.json
Project contains CLEANUP_SUMMARY.md, DEPLOYMENT_GUIDE.md, or DEVELOPMENT_SUMMARY.md
index.html still has a generic <title> or Lovable favicon
User wants to audit a Vite/React project for scaffolding leftovers before shipping

Core Concepts

What Lovable injects

Lovable adds three categories of scaffolding that must be removed:

Dependency — lovable-tagger dev dep + componentTagger() call in vite.config.ts. This is the only runtime hook; removing it is always safe.
Branding artifacts — favicon.ico/png, og-image.png, logo.png, generic <title>, and a Lovable project URL in README.md.
Generated docs — CLEANUP_SUMMARY.md, DEPLOYMENT_GUIDE.md, DEVELOPMENT_SUMMARY.md, LOGO_UPDATE.md in the project root.

Why the execution order matters

Removing deps before editing source files avoids lockfile conflicts. Cleaning docs last means the README reflects the already-cleaned project.

Unused dep footprint

Lovable pre-installs the full shadcn/ui component set (~~29 components) and all Radix UI primitives (~~30 packages). Most projects use 5–10. The unused ones are safe to remove but @radix-ui/react-slot must be kept — it is an indirect dep used internally by many shadcn components via the asChild prop.

Recommended Execution Order

Dependencies (Areas 2 & 7) — clear the package graph first
Build config (Area 3) — remove the tagger from Vite
Entry points (Areas 4 & 6) — clear runtime references
Assets (Area 5) — swap brand files (defer if assets not ready yet)
Docs & README (Areas 1 & 10) — clean last so README reflects the cleaned project
Environment & Git (Areas 9 & 12) — security sweep
SEO / deploy (Area 11) — usually a no-op; confirm and move on
Unused deps (Area 13) — safe to defer until after ship if on a deadline
Favicon / CDN cache (Area 15) — do ASAP after assets are swapped; browser or CDN caching can keep the old icon visible, so verify the live response

Step-by-Step Guide

Area 1 · README.md

Line 1: Replace # Welcome to your Lovable project with the real project title
Line 5: Remove https://lovable.dev/projects/REPLACE_WITH_PROJECT_ID
Lines 11–19: Delete the "Use Lovable" instructions block
Lines 65–73: Delete the "Deploy via Lovable / custom domain docs" block

✅ After stripping, read the README end-to-end. Offer to write a replacement intro paragraph if large sections were removed.

Area 2 · package.json

Remove "lovable-tagger" from devDependencies
Rename "name" from "vite_react_shadcn_ts" to the real project name (kebab-case)
Scan the scripts block for "lovable" or "lovable:*" entries and remove them

grep -n "lovable" package.json

Area 3 · vite.config.ts

Remove import { componentTagger } from "lovable-tagger"
Remove mode === 'development' && componentTagger() from the plugins array
Remove .filter(Boolean) if it was only present to handle the conditional tagger

grep -n "lovable\|componentTagger\|filter(Boolean)" vite.config.ts

Area 4 · index.html

Replace the generic <title> with the real product name
Remove any  comments or Lovable meta tags
Replace the Lovable favicon reference if present

grep -in "lovable\|generator" index.html

Area 5 · public/ assets

Replace these files (keep filenames, swap content):

File	Action
`favicon.ico`	Overwrite with real icon — do NOT just delete, see Area 15
`favicon.png`	Replace with real icon
`og-image.png` / `logo.png`	Replace with real brand assets
`placeholder.svg`	Usually unused — safe to delete

✅ Flag which files are actually referenced in <head> vs dead weight so the user knows what to prioritise.

Area 6 · Source files

src/main.tsx — scan for Lovable HOCs, wrappers, or comments
src/App.tsx — same
Auto-generated components — look for // generated by Lovable headers

grep -rn "lovable\|Lovable" src/ --include="*.tsx" --include="*.ts"

Area 7 · Lockfile

npm uninstall lovable-tagger
grep "lovable-tagger" package-lock.json

Use yarn remove or pnpm remove if the project uses those instead.

Area 8 · package.json scripts (follow-up)

Double-check after Area 2 — scripts are sometimes injected separately from deps:

grep -n '"lovable' package.json

Area 9 · Environment files

grep -rin "lovable" .env .env.local .env.example 2>/dev/null \
  | sed -E 's/([A-Za-z_][A-Za-z0-9_]*LOVABLE[A-Za-z0-9_]*=).*/\1[REDACTED]/I'

Remove any Lovable API keys or project IDs. If a variable is Lovable-only, delete the entire line — don't leave an empty key.

Area 10 · Root markdown docs

Delete or repurpose these common Lovable-generated files:

CLEANUP_SUMMARY.md
DEPLOYMENT_GUIDE.md
DEVELOPMENT_SUMMARY.md
LOGO_UPDATE.md

grep -rln "lovable\|Lovable" *.md 2>/dev/null

✅ Skim each file before deleting — Lovable docs sometimes contain useful architecture notes worth preserving in a rewritten CONTRIBUTING.md or ARCHITECTURE.md.

Area 11 · SEO & deploy config

Usually clean — confirm and move on:

grep -in "lovable" \
  public/robots.txt public/sitemap.xml public/_redirects \
  vercel.json netlify.toml 2>/dev/null

After replacing og-image.png, update OG meta in index.html:

<meta property="og:image" content="/og-image.png" />
<meta property="og:url" content="https://your-domain.com" />
<meta property="og:title" content="Your Real Title" />

Area 12 · Git config

grep -in "lovable" .gitignore
ls .git/hooks/

Remove any Lovable-specific .gitignore entries or commit hooks.

Area 13 · Unused dependencies

Step 1 — Map what's actually imported

tmpdir="$(mktemp -d "${TMPDIR:-/tmp}/lovable-cleanup.XXXXXX")" || exit 1
grep -rh "from [\"']@radix-ui/" src/ --include="*.tsx" --include="*.ts" \
  | grep -oP "from [\"']\K@radix-ui/[^\"']+" | sort -u > "$tmpdir/radix-used.txt"

grep -rh "from [\"']@/components/ui/" src/ --include="*.tsx" \
  | grep -oP "from [\"']\K@/components/ui/[^\"']+" | sort -u > "$tmpdir/shadcn-used.txt"

Step 2 — Diff against installed

grep -oP '"@radix-ui/[^"]+' package.json | tr -d '"' | sort > "$tmpdir/radix-installed.txt"
diff "$tmpdir/radix-installed.txt" "$tmpdir/radix-used.txt"

Step 3 — Bulk remove & verify

npm uninstall @radix-ui/react-accordion @radix-ui/react-alert-dialog  # etc.
npm run build

Area 14 · Generic Lovable artifacts

components.json — verify style, baseColor, and aliases match the real project
eslint.config.js — usually standard; quick scan only

grep -in "lovable" components.json eslint.config.js

Area 15 · Favicon removal & stale CDN caches (Vercel)

Lovable ships a default favicon.ico that browsers auto-request from site root and that can remain visible after cleanup through browser or CDN caching. Handle the four steps — replace the path, link all icon flavours, keep unversioned icon URLs revalidatable, and verify after deploy — then purge the confirmed Vercel project cache only if the live response stays stale. Full commands/JSON live in references/favicon-vercel-cleanup.md.

Master Scan Command

grep -rn "lovable\|Lovable\|LOVABLE\|lovable-tagger\|lovable\.dev" \
  --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" \
  --include="*.json" --include="*.md" --include="*.html" --include="*.toml" \
  --include="*.yaml" --include="*.yml" --include="*.txt" \
  . 2>/dev/null \
  | grep -v "node_modules\|\.git\|dist\|build" \
  | sed -E 's/([A-Za-z_][A-Za-z0-9_]*LOVABLE[A-Za-z0-9_]*=).*/\1[REDACTED]/I'

Examples

Example 1: Full audit from scratch

User: I just exported my project from Lovable. Clean it up.

Agent:
1. Runs master scan — finds 23 matches across 8 files
2. Uninstalls lovable-tagger, renames package.json "name"
3. Strips vite.config.ts of componentTagger
4. Updates index.html title, removes generator comment
5. Flags 4 markdown docs for deletion, skims each first
6. Produces cleanup report

Example 2: Targeted dep pruning only

User: Just prune the unused Radix packages from my Lovable project.

Agent:
1. Runs grep diff (Area 13 only)
2. Identifies 18 unused @radix-ui packages
3. Removes them in bulk, keeps @radix-ui/react-slot
4. Runs npm run build to verify — passes clean

Best Practices

✅ Do: Run dep removal (Areas 2 & 7) before touching source files
✅ Do: Skim Lovable-generated docs before deleting — may contain useful arch notes
✅ Do: Verify npm run build passes after every batch of changes
✅ Do: Replace favicons at the existing paths (Area 15), then verify the live response and purge only the confirmed project if it remains stale
✅ Do: Deploy replacement favicon content and cache headers in the same commit
✅ Do: Replace OG image before launch — it directly affects social sharing previews
❌ Don't: Remove @radix-ui/react-slot — it's an indirect dep of most shadcn components
❌ Don't: Leave empty env vars like LOVABLE_PROJECT_ID= — delete the whole line

Limitations

This skill does not create or source real brand assets (favicons, OG images). Area 15 generates a transparent placeholder ICO only — the user must supply genuine artwork.
Dep pruning (Area 13) is safe but not foolproof — some Radix packages are indirect deps not caught by a direct grep. Always verify with npm run build.
The skill does not modify components.json aliases automatically — it only scans and flags mismatches for the user to fix manually.
Does not cover Lovable-specific backend integrations (Supabase row-level security, edge functions) — those require separate review.

Troubleshooting

Problem: Build fails after removing Radix packages

Symptoms: Module not found error for a @radix-ui/* package
Solution: Re-add the missing package. Open src/components/ui/*.tsx and search for the from '@radix-ui/...' import to find which component depends on it.

Problem: lovable-tagger still in lockfile after uninstall

Symptoms: grep "lovable-tagger" package-lock.json returns results
Solution: Delete node_modules/ and package-lock.json, then run npm install fresh.

Problem: Generic title still showing in browser after updating index.html

Symptoms: Browser tab shows "Lovable" or "Vite App" despite edits
Solution: Check for a <Helmet> or <Head> component in src/App.tsx or a layout wrapper — React-level title tags override index.html at runtime.

Problem: Old favicon still serving after deletion (Vercel)

Symptoms: curl -sI https://<domain>/favicon.ico returns the old ETag with x-vercel-cache: HIT after the replacement deployment. Solution: Overwrite public/favicon.ico with replacement content (a transparent 1×1 ICO if no real asset yet), verify the custom domain, then use the explicit Vercel CDN purge only if the response remains stale — see Area 15.

Related Skills

@vite-config — Vite configuration best practices
@shadcn-setup — shadcn/ui installation and customization
@react-cleanup — general React project hygiene

Additional Resources

Output Format

After completing the audit, produce a cleanup report:

## ✅ Cleaned
<list of changes made>

## ⚠️ Needs your input
<items needing a decision — brand assets, project name, domain>

## 🗑️ Deferred (safe to do later)
<e.g. unused dep pruning, OG image swap>

Made with agentic-awesome-skills · author: whoisabhishekadhikari