Builder-Ready Spec Prompt

What it does

You describe your app idea however it comes out. A chat model rewrites it as one spec of short lines (usually 400-700 words) that you paste into an app builder as the first prompt.

Most people ask a chat model for "a clear spec". This prompt also asks for the things that usually go missing:

• Every need you stated, kept. It reads your whole idea first and treats anything you say you need, already do or must support as a requirement, even inside a wish list. Only what you mark as optional ("maybe", "would be nice", "later") can be left out, and it checks its out-of-scope list against that before it finishes.
• Your rules, exactly. Every number, limit, time and price becomes a numbered rule (R1, R2, ...) with your values. Builders quietly lose these otherwise.
• Roles. Who can see and do what, and what each role cannot see. Every person and thing your notes mention gets a place in the data and the pages.
• Lifecycles. For everything that moves through stages: how it is created, what the person sees when it works, and how it is changed, cancelled or expires.
• Checks tied to rules. Each acceptance check names the rule, role or stage it proves, so you can try it in the preview.
• Setup. How the first admin account is created and which sample records to load, so the checks can be run at once.

Gaps are decided inside the spec with the simplest choice that fits your rules and marked ASSUMED where they apply, so the spec builds as written. A closing line lists the assumptions most likely to be wrong.

Use it when

• You are about to start a new project in Lovable, Bolt or Cursor and your idea is still a paragraph of notes.
• A builder keeps producing the wrong pages, features you didn't ask for, or a stack you can't maintain.
• You want a brief you can reuse to restart a build cleanly after a messy first attempt.

Skip it when

• The app already exists and you want to change it. Write one small change request per prompt instead (the paid builder-change-request prompt splits a list of changes for you).
• You need a product requirements document for a team or investors. This spec is a build brief in short lines, not a document for stakeholders.

The prompt

You turn a messy app idea into a spec that an AI app builder (Lovable, Bolt or Cursor) can build a working first version from without guessing. My idea and my allowed stack are at the end.

First read my whole idea and collect every requirement by what it says, not by where it sits: anything I say I need, already do today or must support is a requirement, even inside a list of wishes. Only ideas I mark as optional ("maybe", "would be nice", "later") are wishes. Every kind of person or thing my notes mention needs a place in DATA, PAGES and FLOW, and only the people my notes say use the app get an account.

Write these sections in this order, as plain text, each starting with its label in capitals:

PRODUCT: one sentence: what it is and who it is for.
USERS & ROLES: each kind of user, what they can see and do, and what they cannot see (for example "tenants see only their own maintenance requests"). If the app keeps records about people who do not log in, say which role manages those records.
RULES: every number, limit, time, price and condition in my idea, numbered R1, R2, ... Keep my exact values. Add no rule I did not state; a rule you had to infer to make the app work is marked ASSUMED.
PAGES: one line per page: its purpose, the data it shows or collects, and which roles can open it. Include the pages where the core records (the things the app is about) are created, edited and removed, and say which role manages them.
DATA: tables with fields (name: type) and the links between them. Anything that moves through stages gets a status field with all its values.
LIFECYCLE: for each record with stages, one line per change of stage: who or what triggers it, what the person sees when it succeeds, and how it can be changed, cancelled or expire, including what happens to anything it holds (credits, places, stock, money) when it does.
FLOW: the main path in a few steps, from opening the app to the first useful result.
STACK LOCK: only the tools I allow. No other services or libraries for payments, email, maps or messages unless I listed them. If I left the stack blank, write a common, simple stack and mark it ASSUMED.
SETUP: in one or two lines, how the first account with the highest role is created, and the sample records to load so every ACCEPTANCE check can be tried.
ACCEPTANCE: checks I can try in the preview, each starting with the rule, role or stage it proves (for example "R3: a quote older than 7 days cannot be approved"). Cover every rule, every "cannot see" and every stage change that can fail. No vague checks like "it works".
OUT OF SCOPE: only ideas I marked as optional that are not in the first version, plus things a builder is likely to add on its own that I did not ask for (for example notifications, online payments, an admin dashboard). Before you finish, check every line here: if I did not call it optional and it is not a builder extra, move it back into the spec.

Gaps: where my idea is silent, decide inside the spec. Choose the simplest option consistent with my rules, use it, and mark it "ASSUMED: ..." in the line where it applies. Do not ask me questions and do not leave a decision open: the spec has to build correctly as written. End with one line starting "VERIFY FIRST:" that names the assumptions most likely to be wrong, usually two to four.

Length: usually 400-700 words of short lines, no prose paragraphs; go longer only when my idea has many rules. If my idea states a word limit, stay about 10% under it. Do not repeat my idea back, add an introduction or explain the spec.

MY IDEA:
[DESCRIBE YOUR APP IDEA]

ALLOWED STACK:
[STACK, OR LEAVE BLANK]

How to use

1. Replace [DESCRIBE YOUR APP IDEA] with your idea in your own words. Messy is fine. Include every number you already know (limits, prices, opening hours, deadlines), everyone the app has to handle, and how you do things today. Mark the ideas you could live without as "maybe" or "would be nice": those get an in-or-out decision, and everything else is treated as a requirement.
2. Replace [STACK, OR LEAVE BLANK] with the tools you allow (for example "React, Tailwind, Supabase"), or leave it blank and confirm the ASSUMED stack against what your builder actually sets up.
3. Run the prompt as the first message of a new chat (see "How to run" below).
4. Read the VERIFY FIRST line and every ASSUMED line. Fix wrong ones by editing the spec directly.
5. Compare RULES with your notes: every number you wrote should appear with the same value. Then read OUT OF SCOPE: nothing you need should be on it.
6. Paste the finished spec into your builder as described below. Do the SETUP step first, then use the ACCEPTANCE list to check each page as it is built.

How to run (Oct 2026)

• ChatGPT: paste into a new chat. GPT-6 with the Thinking slider on Medium suits most ideas; use High for a long idea with many rules. For repeated use, put the prompt in a ChatGPT Project's instructions (Project settings) and send only your idea and stack. GPT-6 models lean toward asking questions: if it replies with questions, answer "Infer what you can and mark it ASSUMED."
• Claude: paste into a new chat, or put it in a Project's instructions and send only your idea. Claude Sonnet 5.5 or Opus 5.5 at their default effort is enough for this job.
• Gemini: paste into the Gemini app, or save it as a Gemini skill and call it with / and its name. In Google AI Studio, Gemini 3.8 Flash at its default thinking level is enough. Gemini works best with context first and the request last: if a rule goes missing, move MY IDEA and ALLOWED STACK above the instructions and end with "Based on the idea above, write the spec."
• Lovable: open the new project in Plan mode, paste the spec and ask Lovable to propose a build plan; switch to Build mode once you agree with it. Then build one page or change per prompt and check it against ACCEPTANCE in the preview. Also paste PRODUCT, USERS & ROLES, RULES, LIFECYCLE and OUT OF SCOPE into the project knowledge (capped at 10,000 characters) so later prompts keep them.
• Bolt: paste the spec as your first prompt. Bolt's own guidance is to treat the first prompt as the blueprint and state the architecture, frameworks and tools up front, which the STACK LOCK does. Put STACK LOCK, RULES, LIFECYCLE and OUT OF SCOPE in the project's Knowledge so later prompts keep them. If you run Enhance prompt on the spec, check afterwards that every R rule survived.
• Cursor: save the spec as SPEC.md in the repository root and add one line to AGENTS.md: "Build from SPEC.md. Do not add anything listed under OUT OF SCOPE without asking."

Example

Input: [DESCRIBE YOUR APP IDEA] = "i run a bike repair shop with 2 mechanics. customers should request a repair online and see where their bike is. we do a free check first, then send a quote, anything over 80 eur the customer has to approve before we start. quotes are valid 7 days. bikes left more than 30 days after they're ready pay 2 eur a day storage. i need to see all open jobs per mechanic. would be nice: a text when the bike is ready. online payment maybe later." · [STACK, OR LEAVE BLANK] = React, Tailwind, Supabase

Output

PRODUCT: Repair tracker for one bike shop: customers request repairs and approve quotes; the owner and 2 mechanics run each job to collection.

USERS & ROLES
- Customer: requests repairs, approves or declines quotes; sees only their own jobs.
- Mechanic: works on all open jobs: checks, quotes, stage changes. ASSUMED: every job, not only their own.
- Owner: what mechanics do, plus assigning jobs and managing mechanic accounts. ASSUMED: one owner account, separate from the 2 mechanics.

RULES
- R1: The first check is free.
- R2: A quote over €80 needs the customer's approval before work starts.
- R3: A quote is valid for 7 days, then expires and cannot be approved.
- R4: A bike collected more than 30 days after it is ready pays €2 per day of storage. ASSUMED: charged from day 31.
- R5: ASSUMED: a quote of €80 or less starts without approval and is shown to the customer.

PAGES
- Request repair (customer): bike, problem, phone number.
- My repairs (customer): own jobs with stage, quote, Approve/Decline, storage fee if any.
- Job board (mechanic, owner): all open jobs by stage.
- Job detail (mechanic, owner): check notes, quote lines, stage buttons, history.
- Jobs by mechanic (owner): open jobs grouped by assigned mechanic.
- Team (owner): add, edit and remove mechanic accounts.

DATA
- profiles: name: text, email: text, phone: text, role: customer | mechanic | owner
- jobs: customer_id, mechanic_id (empty until assigned), bike: text, problem: text, status: requested | checked | quoted | in_repair | ready | collected | cancelled, ready_at: timestamp
- quotes: job_id, amount_eur: numeric, lines: text, expires_at: timestamp, status: sent | approved | declined | expired
- Storage fee: computed at collection from ready_at, not stored.

LIFECYCLE (job)
- requested: customer submits Request repair and sees "Request received" in My repairs.
- checked: mechanic records the free check (R1).
- quoted: mechanic sends a quote; expires_at = sending date + 7 days (R3). €80 or less goes straight to in_repair (R5).
- in_repair: customer approves a quote over €80 (R2) and sees "Approved, work starting".
- Quote declined: the job goes to ready with no work done (ASSUMED). Quote expired: the job returns to checked for a new quote.
- ready: mechanic marks the repair done; ready_at is set; customer sees "Ready to collect".
- collected: mechanic or owner records the pickup; the screen shows any storage fee (R4).
- cancelled: by the customer until work starts, after that only by the owner (ASSUMED).

FLOW
1. Customer signs up and submits Request repair.
2. Owner assigns a mechanic, who records the check and sends a quote.
3. Customer approves in My repairs (at €80 or less, work starts at once).
4. Mechanic marks it ready; the pickup is recorded.

STACK LOCK: React, Tailwind, Supabase (auth, database, row-level security). Nothing else: no SMS, email or payment service.

SETUP: create the owner account in Supabase and set its role to owner by hand; the owner adds the 2 mechanics on Team. Sample data: 3 customers, one job in each stage, one quote sent 8 days ago, one bike ready 33 days ago.

ACCEPTANCE
- R1: a checked job shows the check as free.
- R2: a €95 quote cannot move to in_repair until the customer approves it.
- R5: a €60 quote moves to in_repair without approval.
- R3: the quote sent 8 days ago shows Expired and has no Approve button.
- R4: the bike ready 33 days ago shows a €6 storage fee at collection.
- Customer: cannot open another customer's job, even by changing the URL.
- Owner: Jobs by mechanic lists every open job under its mechanic.
- Stage: a declined quote moves the job to ready with no work done.

OUT OF SCOPE: a text when the bike is ready (you wrote "would be nice"), online payment (you wrote "maybe later"), plus builder extras: email notifications, invoices, a parts inventory.

VERIFY FIRST: quotes of €80 or less start without approval; the owner is a separate account from the 2 mechanics; a declined quote means the bike is collected unrepaired.

Illustrative example written by Meevra to show the target format. Your model's wording will differ.

Troubleshooting

• Something you need ended up under OUT OF SCOPE. Reply: "OUT OF SCOPE may only hold ideas I called optional. Move it into the spec with its pages, data, lifecycle and checks."
• A group of people from your notes has no place in the app. Reply: "Every group I mention needs a place in DATA and PAGES. Add the missing one and say which role manages its records."
• A rule from your idea is missing or has a different value. Reply: "RULES is missing one of my rules. Add it with my exact value and add an ACCEPTANCE check for it."
• The spec is longer than you want. Reply: "Shorten it. Keep every R rule, LIFECYCLE line and ACCEPTANCE check; shorten PAGES and DATA first."
• DATA has tables or fields no page uses. Reply: "Remove any table or field that no page shows or collects."
• It asks you questions instead of writing the spec. Reply: "Do not ask. Choose the simplest option, mark it ASSUMED and write the full spec."
• The builder adds pages or services you didn't ask for. Paste STACK LOCK and OUT OF SCOPE again and ask it to remove the extras before continuing. In Lovable, do this in Plan mode first so you see the plan before any code changes.
• The builder ignores a rule. Send that rule and its ACCEPTANCE check as a single change request, then try the check in the preview.

© 2026 Meevra · meevra.com · Licensed to the purchaser for personal and internal business use.