Prompting best practices
Roc builds whatever you describe, so the quality of what you get tracks the quality of what you ask for. This page explains how Roc approaches a request and gives you the habits that consistently produce better apps: what to put in a first prompt, how to phrase edits, and which tools to reach for instead of a prompt.
How Roc works, briefly
It helps to know what happens on the other side of the chat. On a new build, Roc asks you 2 to 4 quick questions (your app's name, the visual style you want, any decisive unknowns), plans the whole app internally, and then builds it: multiple pages, mobile-first, with a real backend when your idea needs one. On changes to an existing app, Roc reads the relevant code first and makes minimal, surgical edits. It will not restyle or refactor things you did not ask about. Once a change is done the app rebuilds and the preview refreshes, usually within a few seconds.
That shapes the advice below: give Roc outcomes and context up front, then make small, focused requests as you refine.
Describe outcomes, not implementations
Say what the app should do for its users, not how to code it. "Customers can book a 30-minute consultation and get a confirmation" beats "add a calendar component with a POST endpoint". Roc picks solid technical defaults on its own, and outcome language leaves it room to do that.
Give your app a name
Name your app in the prompt (or in the name question) and Roc uses it as the brand everywhere: the page title, the navbar, the footer. "Build Harborline, a booking site for my kayak tours" produces a branded app instead of a generic one.
Answer the style question
When Roc asks about visual style, answer it, or volunteer a mood in your prompt: elegant and minimal, bold and playful, dark and modern, warm and friendly. Roc commits to a palette and font pairing per app, so a clear direction up front saves restyling later. If you change your mind, theme changes are cheap; "make it warmer" or "go darker" is a quick request because the theme lives in one place.
Ground Roc in reality
Two habits kill placeholder text:
- Mention real business details. Services, prices, opening hours, your city. "We charge 950 kr for a full detail, we are in Malmö, open Tuesday to Saturday" gets you real copy instead of lorem-ipsum filler.
- Paste a URL. Mention a link in your message and Roc reads that page to ground the build in real content, whether it is your current site, a menu, or a competitor you admire.
You can also attach screenshots and files through the "+" menu in the chat input, which works well for logos, brand references, or a layout you want to echo.
One focused change per message
When editing, ask for one thing at a time. "Make the pricing section three columns" is easy to verify and easy to revert. A message that bundles five unrelated changes is harder to check, and if one part goes wrong you revert all five. Small steps compound faster than big leaps.
Use Plan mode for big features
For anything substantial (a member area, a checkout flow, a whole new section), turn on the Plan toggle. Roc writes a step-by-step plan first and writes no code on that turn, you adjust the plan in plain language, and then it builds. Complex first prompts get the same offer automatically ("Create an implementation plan first?"). Plans catch misunderstandings before any code exists.
Use the right tool for small tweaks
Not everything deserves a prompt. For small text, color, or spacing changes, switch on Visual edits and click the element in the preview; you get a property panel and can save directly. It is faster than describing a button's shade in words. When something misbehaves and you are not sure why, type /troubleshoot and Roc explores your app to find and fix issues. See Troubleshooting for the full recovery toolkit.
Trust defaults, then iterate
Do not try to specify everything up front. Let Roc make the first pass with sensible defaults, look at the preview, and then refine what matters to you. Downvote responses that miss and revert freely from the version history; both signals feed the project's memory, and Roc adapts to your preferences over time. Style, audience, and color preferences persist per project, so the tenth request needs less explanation than the first.
Stuck on phrasing? Just talk. In plain discussion Roc describes what it would change and asks "Want me to build this?" before spending anything, which is a good way to scope an idea.
For complete worked prompts you can adapt, continue to Examples.