Skip to main content
The better you describe what you want, the closer Rocket gets on the first try. This guide covers how to write Build prompts for new apps, features, iterations, and redesigns - with concrete examples of what works and what doesn’t.

Principles of effective Build prompts

Be specific about what, not how

Tell Rocket what you want the app to do and look like. Don’t tell it which CSS properties to use or how to structure the component tree - that’s Rocket’s job.
Why it works: Describes the user experience clearly - layout, interaction, and visual style - without dictating implementation details.

Include the full picture in your first prompt

The more context you give upfront, the better the initial generation. Include:
  • App type - web app, mobile app, landing page, dashboard
  • Key features - the 3-5 most important things the app does
  • User flow - what happens when someone uses the app (first, second, third)
  • Design direction - color scheme, mood, reference sites, specific aesthetic
  • Data model - what data exists and how it relates (users, projects, tasks)
The comprehensive prompt generates a near-complete app in one shot. The sparse prompt generates something generic that needs many iterations to become useful.

Describe the experience from the user’s perspective

Frame your prompt as if you’re describing the app to a new user - what they see, what they do, what happens.

Prompts for new apps

Simple app

Complex app

Mobile app

Prompts for features and iterations

When iterating on an existing app, be specific about what to change and what to keep.

Adding a feature

Changing design

Fixing a specific issue

Prompts for Redesign

Redesign prompts work differently from new builds. You’re transforming something that exists, so describe what to keep and what to change.

Full visual refresh

Conversion-focused redesign

Brand-aligned redesign

Iteration strategies

Small, focused prompts work best

Instead of one massive prompt with 10 changes, make 2-3 changes at a time. This lets you see the impact of each change and catch issues early.

Use visual edit for fine-tuning

For pixel-level adjustments - spacing, font sizes, specific colors - visual edit is faster than writing a prompt. Click the element, make the change, done.

Reference what Rocket already built

When iterating, reference existing elements: “Make the sidebar navigation look like the header - same font weight and hover style” or “Apply the same card style from the dashboard to the settings page.”

Common mistakes

“Use a useState hook with useEffect to fetch data on mount” - Rocket handles the implementation. Describe what you want the user to experience instead.
“Make it look good” gives Rocket no direction. Instead: “Clean and minimal, similar to Linear’s aesthetic - monochrome with one accent color, lots of whitespace, sharp typography.”
Apps have loading states, empty states, error states, and success states. Mention them: “Show a skeleton loader while data loads, a friendly empty state with an illustration when there are no items, and a toast notification on successful save.”
“Redesign the whole app, add 5 new features, and change the color scheme” in one prompt makes it hard to evaluate the result. Break it into focused iterations.
For iteration patterns, complexity management, and testing strategies for Build tasks, see Build best practices.

Quick reference: prompt template

Use this template as a starting point for any Build prompt:

What’s next?

Prompting for Solve

Frame strategic research questions effectively.

Configure Intelligence

Describe monitoring needs for Intelligence.

Build overview

Explore everything Build can create.

Prompt starters

Copy-paste prompts organized by role.