Decide before you type, build in pieces, use real content, and put every request in front of the right agent. These habits turn one-line ideas into finished results.

Start in project chat. Open the chat for the project you want to change, then choose or address the agent whose role matches the work. If you are unsure which agent fits, ask the team to clarify before building.

This guide collects the techniques that consistently get better results from your agent team. None of them require special ability. They are about what you say, not how you format it. Whether you are writing your very first request or refining a mature project, the same principles apply: clear thinking in, clear results out.

Let the team ask before it builds

One of the most effective ways to get a better result: when a request is big or fuzzy, invite questions instead of hoping the team guesses right. State what you want, then add one line at the end:

Ask me anything you need to fully understand what I want before you start.

You will often get questions you would not have thought to answer on your own, whether it is about edge cases, audiences, or trade-offs. Settling them up front costs a minute; discovering them after a build costs a rework. The result lands far closer to your intent on the first pass.

Step 1: Decide before you type

Know what you are building

A few minutes of thinking upfront can save a lot of re-prompting later. Before you start, make sure you can answer four simple questions: what are you building, who is it for, why would they use it, and what is the main action you want them to take.

That main action is often called the CTA, short for call to action. It is the button, link, or next step you most want users to choose, such as Sign Up, Book a Demo, Start Free, or Buy Now.

You do not need to write a full specification. The goal is simply to give the project a clear direction. The more specific your starting point is, the easier it is to generate a result that matches what you have in mind.

Build a one-page site for a budgeting app aimed at freelancers. The main CTA is “Start Saving Smarter.” Use a bold, expressive look with large types and punchy colors.

Sketch the journey, not just the screens

Good design lives between screens as much as on them. Walk the path your user takes: what do they see first, what builds trust, what gives them confidence to act, and where does that action lead? Even a three-beat sketch, hero, proof, call to action, makes your requests dramatically more effective, because every section now has a reason to exist and a reason to lead to the next.

Set the visual direction early

Style is far easier to establish than to retrofit. Pick a direction: calm and elegant, bold and disruptive, premium and sleek, and state it in your first request using tone words the team can act on: minimal, playful, cinematic, developer focused. These words are more than decoration: they shape typography, spacing, color, shadow, and corner radius from the very first component. Reuse the same style line in later requests to keep everything cohesive.

Use a calm, wellness-inspired design: soft gradients, muted earth tones, rounded corners, generous padding. Overall tone gentle and reassuring.

Step 2: Write requests that land

Describe outcomes, not implementations

Describe the result you want, not the steps for building it. For example, “Add a pricing section with three options and make the middle one stand out” is more useful than explaining exactly how the page should be constructed. Focus on what should appear and why it matters; the team can decide how to build it.

Work in pieces, not pages

Requests scoped to one component — a hero, a feature grid, a testimonial row, a pricing table — give you clarity and control. If a piece misses the mark, you adjust that piece instead of regenerating everything around it. Build a block, review it, refine it, then move to the next. A full-page request produces noise; a component request produces signal.

Create a feature section: centered headline, then three cards side by side, each with an icon, a title, and one line of description. Soft shadows, slight lift on hover.

Use real words

Placeholder text hides problems; real copy reveals them. A real headline might need two lines; a real CTA might work better as a verb. Write what a user would actually read, even if it is a draft, layouts, spacing, and design decisions all improve when the content is real.

Hero headline: “Design Calmly.” Subtext: “Turn stress into structure.” CTA: “Start Building Free.” Copy-centered layout with generous vertical spacing.

Name real elements

Use clear, specific words to describe what you want on the page. You do not need to know design terminology—just name the things users should see or interact with, such as a profile card, a button, or a form.

Specific requests are easier to build than broad ones. Start with the basic element you need, then add details one at a time.

Create a profile card with a photo, name, and follow button. Add a small “Verified” label next to the name, and show a short explanation when someone hovers over it.

Step 3: Change with precision

Scope every change: what moves, what stays

When adjusting existing work, be explicit on both sides, what should change and what must not. Use direction words like “replace,” “update,” and “adjust” rather than “make this better,” and fence off the parts you like. Precision here is what keeps iteration from becoming regression.

Change the CTA text to “Get Started” and increase its horizontal padding. Keep the current colors, font, and everything else in this section unchanged.

One meaningful change at a time

Update the copy, then the layout, then the interactions and check each result before the next request. Small, deliberate steps compound into a polished product; ten changes in one message compound into ambiguity, and when something goes wrong you will not know which change caused it.

Mid-task corrections happen in chat. When Prompt Queue is available in your chat and Agent work is active, follow-up messages are queued behind the running work. Confirm that your message appears in the queue before sending another copy. If queue controls are not visible, do not resend: wait for the current work to finish, or use an interrupt control if your chat provides one, then confirm the task status before sending a follow-up. See Project chat for details.

Think one step ahead of the UI

If your project needs to do more than look polished, define behavior alongside appearance. Specify what users see when signed in or signed out, where dynamic content comes from, and how the interface handles empty, loading, and error states. You do not need a working backend to design around these scenarios—planning for them early helps prevent major UI rework later.

If the user is logged in, show their avatar and name in the top right. If not, show a “Log In” button that routes to the auth screen.

FAQ