> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.mythos.new/prompting/writing-good-prompts/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mythos.new/_mcp/server.

# Writing good prompts

> Describe the outcome, content, behavior, and constraints that matter so Mythos can build the right first version.

A useful prompt gives Mythos a clear destination without prescribing every implementation detail.
Describe what you want people to see and do, then name the few choices that must not be guessed.

## Start with the outcome

#### Name what you are building

Say whether you need a landing page, dashboard, portfolio, store, or another
product. Add the audience or industry when it should shape the language and
design.

#### Describe the important content

List the sections, screens, or information the result must include. Put them
in the order that matters to you.

#### Explain what should work

Name real interactions such as filtering, sign-in, saving a form, or moving
between pages. Say what should happen after each action.

#### Add firm constraints

Include required wording, brand colors, accessibility needs, device
priorities, or content that must stay unchanged. Leave the rest open for
Mythos to decide.

> **Tip**
>
> Lead with the product goal. “Help customers compare plans and request a demo”
> gives better direction than a long list of visual effects.

## Make the request specific

A vague request makes Mythos choose the product structure as well as the design:

```text
Make a website for my moving company.
```

A focused request gives it a useful frame:

```text
Build a landing page for Iron Anchor, a local moving company.
Include a hero, services, customer reviews, a quote form, and a compact footer.
Use confident, practical copy and a dark blue-and-cream palette.
The primary action should take visitors to the quote form.
```

You do not need to specify every color, spacing value, or component. Add a detail when the result
would be wrong without it.

## Ask for real behavior

Say when an interaction must keep data or affect another part of the product. For example:

```text
Add a waitlist form for name and email. Save each submission and show a clear success state.
```

For forms, accounts, uploads, or other saved data, use a [managed Supabase backend](/integrations/supabase).
Describe who can read and change each record, not only what the form looks like. Include the empty,
loading, success, and error states that matter.

For example, a reservation flow needs more than a confirmation message:

```text
Let signed-in customers reserve an available session and see their own
reservations after reloading. Prevent a second booking when the session is full.
Show a useful message if saving fails.
```

Connect the required service when Mythos asks for it, and test that the result is saved and accessible
only to the intended people.

## Plan before you build

Use [Plan mode](/features/plan-mode) when the audience, workflow, or scope is still uncertain. Mythos
asks for missing decisions and gives you an editable plan to review before the build starts. Use
Build mode when the outcome and constraints are already clear.

## Use references and real content

Attach a screenshot, brief, or CSV when it supplies details that are difficult to describe. Explain
which part to follow. A reference image can guide spacing while your own copy and branding stay
unchanged. Use real headings, labels, and examples where possible; they make the layout easier to
judge than placeholder text.

See [Chat attachments](/features/chat-attachments) for supported files and limits.

## Keep recurring context

Save stable product facts, naming, and design rules in [Knowledge](/features/knowledge) so that you
do not need to restate them in each Build request. Use a [skill](/features/skills) for a repeatable
procedure that you want to invoke by name, such as a release review.

## Correct one thing at a time

After the first result, do not repeat the original brief. Point to the exact section, describe what
you see now, and say what should change. A focused follow-up is easier to review and easier to undo.

## Related

* [Fixing a build that isn't right](/prompting/debugging)
* [Build with Mythos](/features/building-and-editing)
* [Plan mode](/features/plan-mode)

> Learn how to turn an idea into a working app, improve it in Mythos, and publish it when it is ready.