nous-hermeshub lovable-cleanup
Remove every trace of Lovable scaffolding and ship the project as your own. Made with antigravity-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 14 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-taggerinpackage.json - Project contains
CLEANUP_SUMMARY.md,DEPLOYMENT_GUIDE.md, orDEVELOPMENT_SUMMARY.md index.htmlstill 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-taggerdev dep +componentTagger()call invite.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 inREADME.md. - Generated docs —
CLEANUP_SUMMARY.md,DEPLOYMENT_GUIDE.md,DEVELOPMENT_SUMMARY.md,LOGO_UPDATE.mdin 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
Step-by-Step Guide
Area 1 · README.md
- Line 1: Replace
# Welcome to your Lovable projectwith 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"fromdevDependencies - Rename
"name"from"vite_react_shadcn_ts"to the real project name (kebab-case) - Scan the
scriptsblock 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
<!-- Generated by Lovable -->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 |
Replace with real icon |
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 commentssrc/App.tsx— same- Auto-generated components — look for
// generated by Lovableheaders
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
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.mdDEPLOYMENT_GUIDE.mdDEVELOPMENT_SUMMARY.mdLOGO_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
grep -rh "from [\"']@radix-ui/" src/ --include="*.tsx" --include="*.ts" \
| grep -oP "from [\"']\K@radix-ui/[^\"']+" | sort -u > /tmp/radix-used.txt
grep -rh "from [\"']@/components/ui/" src/ --include="*.tsx" \
| grep -oP "from [\"']\K@/components/ui/[^\"']+" | sort -u > /tmp/shadcn-used.txt
Step 2 — Diff against installed
grep -oP '"@radix-ui/[^"]+' package.json | tr -d '"' | sort > /tmp/radix-installed.txt
diff /tmp/radix-installed.txt /tmp/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— verifystyle,baseColor, andaliasesmatch the real projecteslint.config.js— usually standard; quick scan only
grep -in "lovable" components.json eslint.config.js
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"
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 buildpasses after every batch of changes - ✅ 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 brand assets (favicons, OG images) — it only flags what needs replacing. The user must supply real assets.
- Dep pruning (Area 13) is safe but not foolproof — some Radix packages are indirect deps
not caught by a direct
grep. Always verify withnpm run build. - The skill does not modify
components.jsonaliases 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.
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 antigravity-awesome-skills · author: whoisabhishekadhikari