Writing a brief your AI builder can follow

The quality of what Lovable builds depends on the brief you give it. A good brief is specific, small and testable.

The six parts

1. Goal. One sentence on what this feature does and for whom.
2. Context. What already exists that it connects to: tables, pages, roles.
3. Data. The table and fields, with types, and who can read or change each row.
4. Screens. What the user sees and does, step by step.
5. Rules. Validation, limits, and what happens on errors.
6. Done when. Three to five checks that prove it works.

Example

Goal: Let signed-in users save favorite recipes.
Context: Users sign in with Supabase auth. Recipes are in the recipes table.
Data: New table favorites with user_id and recipe_id, unique together. Row-level security: users can only read, add and delete their own rows.
Screens: A heart button on each recipe card. Filled when saved. A Favorites page listing saved recipes, newest first.
Rules: Signed-out users who click the heart go to sign in, then back.
Done when: Saving and unsaving works; another user cannot see my favorites; the Favorites page loads with no saved recipes and shows a friendly empty state.

Tips

• One feature per prompt. Big prompts produce big messes.
• Ask Claude to turn your rough idea into this format, then edit it yourself.
• Save briefs that worked in your Build Journal. They become your next recipe.