# Lovable Rigor > Disciplined workflow for directing Lovable's AI agent on any project (via the Lovable + Supabase MCP connectors) — investigate before fixing, independently re-verify every claimed fix, catch the preview/production publish gap, and test safely against real-shaped data. Use whenever sending instructions to a Lovable project's AI agent or reviewing its work. - Skill: `gidila91/lovable-rigor` (Agent Skill) - Install (CLI): `npx skillmds@latest add gidila91/lovable-rigor` - Raw SKILL.md: https://api.skillmd.com/api/skills/gidila91/lovable-rigor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: gidila91 (https://skillmd.com/u/gidila91) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/gidila91/lovable-rigor --- # Lovable Rigor Lovable's agent is capable but self-reported "done" is not verified truth — it can misdiagnose, patch the wrong thing, forget to publish, or introduce a regression while fixing something else. This skill is the checklist that catches those failure modes before they reach production, distilled from a long QA/hardening engagement where every one of these failure modes actually happened at least once. ## Core loop for any non-trivial request to Lovable 1. **Investigate first, fix second.** For anything beyond a one-line typo, tell Lovable explicitly: "investigate and report findings before writing any code." Don't let it jump straight to a migration/patch on a hunch — a wrong root-cause guess produces a fix that looks plausible and does nothing. 2. **Verify the finding yourself before approving a fix.** You have the same Supabase MCP tools Lovable does. Before approving a proposed fix, independently confirm the root cause: read the actual function definition (`pg_get_functiondef`), the actual constraint, the actual RLS policy, the actual data — not just Lovable's description of it. This is the single highest-leverage habit in this whole workflow: it catches misdiagnoses, stale claims, and "confirmed" findings that don't hold up. 3. **After Lovable reports a fix shipped, re-verify the fix directly** — don't trust the report. Query the deployed function/schema again, or drive the actual UI, to confirm the fix is really there and really works. A "done" message is a claim, not evidence. 4. **Ask for live proof on anything security- or data-integrity-sensitive**, not just a passing test suite: have Lovable reproduce the *original* failing scenario against the *fixed* code and show you the before/after, ideally via a rolled-back transaction or tagged scratch fixtures so nothing real gets touched. Then confirm that proof yourself with a second, independent read. ## The publish gap (catches people constantly) Lovable's code changes land on the **preview** build immediately, but require an explicit publish action to reach the real **production** URL. A "shipped" report can be true for preview and false for production simultaneously. - After any fix that needs to be live, ask Lovable to publish, then confirm yourself: fetch `/version.json` (or equivalent build-stamp endpoint) on the actual production domain and check the build hash/timestamp actually changed. Don't just check preview. - Publishing isn't instant — poll for the new hash rather than checking once and assuming failure. - If Lovable's response shows only a ``-style UI affordance rather than an actual publish tool call, that means it didn't publish — call it out and ask it to actually trigger the publish. ## Safe testing against real-shaped data - Prefer **rolled-back transactions** (`BEGIN; ... RAISE EXCEPTION 'rollback';`) for exercising RPCs/triggers against real schema without leaving residue. - When persistent test fixtures are unavoidable, **tag them distinctly** (e.g. a `qa--` prefix in a name/notes field) so they're easy to find and batch-clean later, and agree explicitly on when cleanup happens (usually: end of the full pass, not mid-pass, in case a later step needs to reference earlier state). - For a real client's production data: default to **read-only** unless the user explicitly authorizes a specific write, and say so out loud before doing anything destructive or corrective on their account. ## Reviewing Lovable's own migrations/diffs - For edits to an existing SQL function, ask for (or read yourself) a diff against the previous version rather than trusting a full-body rewrite — full rewrites are exactly where unrelated lines get silently mangled (wrong column name, dropped guard, reverted logic) while "just" fixing one thing. - When Lovable rewrites a whole function to change one clause, that's a smell — prefer changing only the affected section, or explicitly diff the untouched parts against the prior version before shipping. - Watch for **stale scan/lint findings that don't match reality** — a security scanner flags based on static patterns (e.g. an RLS policy) and can miss that a trigger stack already closes the gap behaviorally, or can flag your own throwaway QA scaffolding as a real vulnerability. Verify what the finding actually is before treating it as either "ignore" or "fix now." ## Communication pattern with Lovable - State findings and decisions plainly; when a design question is genuinely ambiguous, ask Lovable to lay out options with tradeoffs rather than silently picking one. - When you already made this exact policy decision earlier in the conversation, say so and point back to it rather than re-litigating from scratch — Lovable's agent doesn't retain full context across compaction/summarization the way you might expect, and will sometimes present something you already settled as a fresh open question. - Keep a running todo list across a long multi-part engagement (many small fixes, or a phased QA pass across "clusters"/areas) — it's easy for both sides to lose track of what's actually been verified vs. merely reported. ## When to reach for this skill Any time you're sending a message to a Lovable project's AI agent (via `mcp__claude_ai_Lovable__send_message` or equivalent) about something more consequential than pure cosmetic copy — bug fixes, schema changes, security findings, new features, anything touching RLS/auth/payments/tenant isolation.