---
name: lovable-prompt
description: "Rewrites what you want to say into a precise, safe Lovable prompt that won't break what's working."
---
# /lovable-prompt

The way you phrase a request to Lovable determines whether it builds exactly what you meant or breaks three things you didn't mention. Vague prompts ("make the dashboard better", "fix the layout", "add a settings page") cause Lovable to guess — and it often guesses wrong across multiple files at once.

Take what I've described in this conversation and rewrite it as a Lovable prompt that is precise, scoped, and safe.

The rewritten prompt must include:

**What to build or change** — described specifically. Name the component, the page, the field, the behaviour. Not "improve the form" but "add a character count below the bio field that updates as the user types".

**What the correct result looks like** — how you know it worked. What should be visible, what should happen when you interact with it, what data should be saved or displayed.

**What must not change** — explicitly list the parts of the app that should be left alone. This is the most important constraint. Lovable tends to "improve" adjacent things it wasn't asked to touch.

**Any technical constraints** — if there's a specific Supabase table, a component name, an existing pattern to follow, state it here.

Then write a second, shorter version of the same prompt — 2-3 sentences maximum — for when you want a minimal, lower-risk change. Label it "Safe version".

Do not include anything vague. If the request isn't specific enough to write a precise prompt, ask one clarifying question before proceeding.