Prompting tips
How to describe what you want so your AI assistant builds the right thing on the first attempt.
You build by talking to your own AI assistant — Claude, ChatGPT, Cursor, or another client with the Floot connector attached. Your prompt is what it works from, and these habits make the biggest difference to what comes back.
Start with what the app does
For a first prompt, describe the core features and what the app should do for the person using it. Keep it short — you will add detail as you go, and a fuzzy idea is better talked through than written up.
There is no stack to choose. Every Floot project is React and TypeScript on the front end, with serverless endpoints and — when the app needs one — a Floot-provisioned Postgres database behind it. Naming a framework only narrows the result: ask for Tailwind, for example, and it will not be installed, because Floot does not support it.
Naming a package is still fine
Ask for a specific npm package when you genuinely need one. A few cannot be installed — anything ffmpeg- or ffprobe-based, wasm modules, and most packages that need node-gyp (sharp is the supported exception for backend image work). Floot refuses those and explains why to your assistant, so it can offer another route.
Include enough context
Be specific and descriptive about what you want changed. When something is broken, do not just say “it doesn't work” — describe what you did, what you expected to happen, and what actually happened.
When I click the Submit button, a dialog should open, but nothing happens.That works far better than “that button doesn't work”.
An attached image is not a file in your project
Attaching a mockup or a logo in a chat client lets the model see it, but the file itself never reaches Floot. If you want that image in the app, your assistant shows you an upload card so you can hand over the actual file in one click.
Point at the exact element
The preview link your assistant gives you opens your project view at /mcp-preview/<id>. Use Select or Annotate above the preview there: Select picks one element, Annotate takes a screenshot you can draw on. Neither one sends a message for you.
What you picked is copied to your clipboard, so you can paste it into the chat and add what you want changed. It is also stashed for your assistant, so “check my Floot context” works just as well — it then reads the selected element, your drawing, and the page you were on before it changes anything.
Keep it focused
Ask for one thing per prompt. Bundling several changes together means you cannot verify any of them cleanly, and if something goes wrong you have to untangle which change caused it.
One feature, one fix, one prompt
Build it, check it in the preview, then move on to the next thing.
Describe outcomes, not implementations
Say what the app should do for the person using it, not how to build it. “Someone should be able to save a recipe and find it again next time they sign in” gives your assistant far more to work with than a list of tables and routes.
Let it read the project first
With the connector attached, your assistant can list and read your files, search your code, read your logs, and read Floot's own build guides before it writes a line. On an existing project, ask it to look before it changes anything — “read the pages this touches first” costs one turn and saves several.
For a big change, ask it to talk the change through before it touches the code. If you want the plan to stay in the project, ask it to write the plan into a file under static/__dev/plans/: that opens in your project view as a plan with a Build Plan button, and clicking that sends your go-ahead back to your assistant the next time it checks your Floot context.
Check each change before the next one
After each change, click through the flow in the preview yourself. One bug described on its own is far easier to fix than five found at the end, and leaving visual polish until the features work saves redoing it.
Ask for the preview link first
Ask for the preview link at the start of the session and keep it open. It live-updates as the app changes, opens with no Floot login, and works on your phone.
When something breaks, ask for the logs
Your assistant can read the project's runtime logs: the last hour of backend requests, and the browser console and network activity from your open project view. Ask for them by name — “read the logs before you try another fix” — rather than letting it guess from the error text alone.
Browser logs are only captured while your project view is open in a browser, so keep that tab open while you are debugging.
When the same error survives three attempts
Stop and change the approach rather than trying a fourth time. Asking for the logs to be read before another fix is attempted clears most loops. Full steps: Troubleshooting and support.
Save a restore point before something risky
Ask for a named checkpoint before a big refactor — “checkpoint this first” is enough. Assistants are also told to create one each time they finish a coherent piece of work. Named checkpoints show up in the Checkpoint panel in your project view, and you can restore any of them from there.
Restoring rolls back code and project settings only. Database rows, uploaded files, and anything already published are not rolled back.