Mythos Docs

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.

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:

Make a website for my moving company.

A focused request gives it a useful frame:

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:

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. 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:

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 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 for supported files and limits.

Keep recurring context

Save stable product facts, naming, and design rules in Knowledge so that you do not need to restate them in each Build request. Use a skill 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.