Writing good requests

Terra works on its own inside a turn. It plans, does the work, checks its result, and saves, all without stopping to ask permission for routine decisions. That is what makes it fast, and it is also why the wording of your request matters more here than in a chatbot: a vague request does not produce a vague reply, it produces real changes to your site based on Terra's best guess at what you meant.

A good request answers four questions.

1. Which page? Or: is the right page open in the preview?
2. What outcome do you want? Say what "better" means here.
3. What is the constraint? Length, tone, structure, what must survive.
4. What must not change? Prices, claims, the section you like.

You do not need all four every time. A one-line copy tweak needs almost none. A page rebuild needs all of them.

Name the page, or open it

Terra resolves "this page", "the hero", "make it shorter" against the route currently open in the preview. The header of the chat tells you which one that is (viewing /pricing). If you are talking about a different page, name its route.

Before and after

Improving a page

Improve my pricing page

Terra has to invent a definition of "improve", and it will act on it.

On /pricing, each of the three plan cards leads with the price.
Lead with the outcome instead and move the price under it.
Keep each heading to six words or fewer, and don't change any prices.

Names the page, states the outcome, gives a length constraint, and fences off the numbers.

Rewriting copy

Make the hero better

The home page hero reads like generic SaaS copy. Rewrite it around
what actually makes us different: we ship the finished site, not a plan
for one. One headline line, subhead under 20 words, keep the button label.

"Better" is now a direction, and the button is protected.

Adding content

Add some testimonials

Terra will not invent quotes, so this turns into a question and a wasted round trip.

Add a testimonials section under the features on /about, using the three
quotes from our G2 page at <url>. Use those exact quotes and attributions,
don't write new ones.

Points at where the real facts live. Terra fetches them, uses them verbatim, and records the source.

Copying an existing page

Make my site look like example.com

Recreate https://example.com/pricing. Put it at /pricing-v2, not over
our current /pricing.

Recreating a page lands it at the same route as the source by default, so saying where you want it up front avoids the "this route already exists, what should I do?" stop.

Matching a brand

Match our brand

The header on /features doesn't match our live site. Match example.com:
same nav links, same order, same colours, same button treatment.

Terra measures the real values from the live site rather than eyeballing a screenshot, but it needs to know which site and which part.

Images

Generate a screenshot of our dashboard for the hero

Terra will refuse this one. Generated interface imagery invents UI text and lies about the product.

Use the dashboard screenshot from our asset library in the hero.
If there isn't one, tell me and I'll upload it.

Or, for imagery that is not product UI:

Generate an image for the hero: a wide workshop bench in warm morning
light, no people, no text, muted palette to match the site.

Translation

Translate my site

That starts a background job across every page, when often you want one page first.

/translate Spanish, just /pricing for now

One page, done in under a minute, and you can look at the result before committing to the whole site.

Analytics-driven changes

Why isn't my pricing page converting?

/pricing has been live three weeks. Look at the section signals and tell me
where people drop off. Don't change anything yet.

"Don't change anything yet" is worth adding whenever you want a diagnosis before a fix. Terra will also tell you when the sample is too small to mean anything.

Ground your claims

The one thing Terra will never do is invent a specific: a number, a customer name, a testimonial, a capability. If your request implies a fact it cannot find on your site or in your brand knowledge, it stops and asks.

You can prevent the round trip by supplying the fact, or by pointing at where it lives:

Update the stat in the hero from "200 teams" to "500 teams".

Rewrite the integrations section from what's on
https://example.com/integrations, don't add any we don't actually have.

If you want a durable fact remembered for later work, use /remember:

/remember we never describe ourselves as an "AI platform", we're a
site agent

Keep one goal per request

Terra scopes its work to what you asked in that turn, on purpose. A request bundling four unrelated goals gets a long turn with a plan you cannot steer mid-flight, and one bad guess contaminates the rest.

Better: ask for the biggest thing, look at the result, then ask for the next. If you are unsure how big the work is, ask for the shape first:

I want /pricing rebuilt around three tiers instead of two. Before you
build anything, tell me what sections you'd change and what you'd reuse.

Use the commands when they fit

The slash commands carry extra context Terra would otherwise have to reconstruct. /refresh with a real page opportunity picked from the list brings the keyword and the brief along. /seo-check runs a structured audit and ranks findings by impact instead of applying scattershot fixes. /undo shows you what would be reverted before anything happens.

Typing a command and then picking a concrete row from the list that appears is more precise than describing the same thing in prose.

Answer the question cards

When Terra posts a question with options, pick one. It is waiting, and it will not proceed until you answer. Every card also takes free text, so if none of the options is right, say what you want instead rather than repeating the original request.

Correcting mid-turn

If you see Terra heading the wrong way, you have two options.

• Send a message. It does not interrupt. Terra folds the correction into the work in progress and confirms the new direction in one line.
• Press Stop. This ends the turn. Anything already saved stays saved. Then start again with a sharper request.

Stop is the right call when the direction is wrong from the start. A mid-turn message is right when the direction is close and you want a course correction.

Requests that will not go the way you expect