# The First-Hour Prompts Six prompts cover almost everything you'll say to an AI app builder in your first hour: start the build, fix an error, change a screen, add login, put it online, make it work on phones. Fill the [SLOTS], paste, send. Every prompt works in Lovable, Bolt, Replit, and Claude. One rule before you paste anything: **one prompt, one job.** "Fix the error and also make it blue and also add a settings page" is how builds go sideways. These prompts are scoped tight on purpose. --- ## 1. The kickoff prompt (your first message) The first message decides most of what you get. Vague in, vague out. This prompt forces the four things the builder actually needs: what it is, who it's for, which screens, and what "done" means. ``` Build me a web app: [ONE SENTENCE: a ___ that lets ___ do ___]. Who it's for: [WHO WILL USE IT, AND WHAT THEY DO TODAY INSTEAD, e.g. "my climbing group, who currently coordinate sessions in a group chat"] The screens I need (keep it to 3 or fewer): 1. [SCREEN NAME: its one job, e.g. "Home: shows this week's sessions as cards"] 2. [SCREEN NAME: its one job] 3. [SCREEN NAME: its one job] "Done" means (checkable, not vibes): - [e.g. "I can add a session with a date, location, and note"] - [e.g. "Sessions appear newest first and I can delete one"] Rules: - No user accounts, no payments, no features I didn't list. I'll ask later. - Use placeholder text and sample data where content is missing, and tell me what you assumed. - When you're finished, tell me the 3 things I should click to test it. ``` **For anything bigger than a 3-screen app**, don't stretch this prompt. Use the Fable Kickoff PRD instead (a fill-in template where an AI interviews you first, then hands the complete spec to the builder): robotsonpayroll.com/resources/fable-kickoff-prd. --- ## 2. Fix this error without rewriting everything The most important prompt in this file. The beginner instinct when an error appears is "it's broken, fix it", and an unscoped "fix it" is how builders rewrite half your working app. This version pins the blast radius down. ``` I got this error: [PASTE THE EXACT ERROR TEXT. If there's no error text, describe what you see, e.g. "the screen is blank after I click Save"] It happened when I: [WHAT YOU DID, e.g. "clicked Save on the new-session form"] Do this in order: 1. Tell me in one plain-English sentence what caused it. 2. Make the smallest possible fix. Do not redesign, rename, or "improve" anything else while you're in there. 3. Tell me exactly what to click to confirm it's fixed. ``` If the same error survives two attempts, stop repeating "still broken" and send: "This is attempt 3 on the same error. List 3 different possible causes, tell me which is most likely and why, then fix only that one." --- ## 3. Change this screen (and only this screen) Unscoped visual feedback ("make it look better") invites the builder to restyle everything. Name the screen, name the change, fence off the rest. ``` On the [SCREEN NAME] screen, change ONLY this: [THE CHANGE, e.g. "make the Save button green, move it to the top right, and make the session cards show the date in bold"] Touch nothing else: no other screens, no colors, fonts, or layout I didn't mention. If my request conflicts with how something currently works, ask me before changing it. ``` --- ## 4. Add login Accounts are where beginners get hurt, because a builder can produce a login screen that looks right while every user sees everyone else's data. This prompt makes the builder use the tool's built-in accounts system (never hand-rolled password code) and then prove the data is private. ``` Add user accounts to this app: email + password sign-up and login. Requirements: - A logged-out visitor sees only the login / sign-up screen, nothing else. - Each user sees ONLY their own data. This is the most important requirement. - Add a "Log out" button in the [WHERE, e.g. "top right corner"]. Use this platform's built-in authentication (auth is the accounts system: sign-up, login, passwords). Do not write your own password handling. When done: tell me how to create two test accounts, and walk me through verifying that user A cannot see user B's data. ``` Actually do the two-account check. It's 90 seconds, and it's the difference between an app and a data leak. --- ## 5. Put it online Until now your app runs in a preview (the private, only-you-can-see-it version inside the builder). Publishing, also called deploying, puts it on a real URL anyone can open. ``` I want to put this app online so anyone with the link can use it. 1. Walk me through publishing it from this tool, step by step, naming the exact buttons to click. 2. Before I publish: list anything that works in preview but will break in the published version (sample data, missing settings, test values), and fix those first. 3. After: tell me the URL, and the 3 things I should test on the live version, not just the preview. ``` In Lovable this ends at the Publish button, top right. In Bolt look for Deploy, in Replit look for Publish. The prompt makes the tool name its own buttons so you're never hunting. --- ## 6. Make it work on phones Most people who click your link will open it on a phone, and preview mode quietly hides how bad that can look. Send this before you share the URL anywhere. ``` Check every screen of this app at phone width (375px wide) and fix what breaks: text overflowing, buttons pushed off screen, tables too wide to read, tap targets too small for a thumb. Keep the desktop version looking the way it does now. List every fix you made, screen by screen. If a screen was already fine, say so. ``` Then verify like a human: open the live URL on your actual phone and tap through the core flow. If something's still off, screenshot it, attach it, and use prompt 3. --- ## The pattern behind all six Notice what every prompt here does: it states the goal, fences off what must not change, and demands a way to verify the result. Goal, fence, proof. Once that becomes reflex, you can stop copying prompts and just write your own. That usually takes about a week.