Mythos home page
Start building

Build

Building and editing

Turn a clear request into a verified project version, then improve it with focused edits you can review in Preview.

A Build creates the first working version of a project. An edit starts from the current version and changes it. Both use the same basic loop: describe an outcome, follow progress, inspect the delivered result, and decide what to do next.

Build the first version

Start with the purpose, audience, page structure, and visual direction. You do not need to prescribe every implementation detail.

Build a one-page website for North Slope, a neighborhood coffee roaster.
Include a hero, featured beans, wholesale information, opening hours,
and contact details. Use a warm, minimal visual style.

A useful first prompt tells Mythos what must be true in the result. Anything you leave open becomes a design decision Mythos can make for you.

Follow the delivery loop

Send one coherent request

Ask for a result you can review together. A focused page or feature is easier to verify than a long list of unrelated changes.

Watch progress in the conversation

The progress card shows that the run is active. Keep the workspace open and avoid sending the same request again while it is still working.

Wait for verification

Mythos checks the candidate app before delivery. The current working Preview stays available until the new result is ready.

Inspect the delivered result

Open Preview and test the visible behavior, links, forms, and responsive layout that matter to your request. A result card marks the new current project version.

Continue with a focused edit

Name the exact area and the outcome you want. The edit starts from the current project, so you do not need to restate everything that already works.

Write edits that are easy to verify

Prefer a bounded change:

In the featured beans section, add three roast cards with a tasting note
and price for each. Keep the existing palette and spacing.

Avoid requests such as “make everything better.” If several areas need work, group changes only when they serve one outcome, then inspect that outcome before moving on.

Describe what you see when something is broken: name the page, viewport, action, and visible failure. “The pricing cards overlap the footer on mobile” is more useful than “the layout is wrong.”

Delivered and failed results

  • Delivered: the result card appears, the new version becomes current, and Preview can load it.
  • Failed before delivery: the current project remains unchanged. A platform failure normally returns the reserved credits.
  • Stopped after AI work begins: the current project remains unchanged, but the fixed charge is kept. If delivery may already have started, billing can remain pending while Mythos reconciles the outcome.

If a request fails once, read the message, check the credit balance, and remove ambiguity or split an oversized task before trying again. Repeated failures belong in Troubleshooting, not an unchanged retry loop.

If a delivered edit is simply the wrong direction, open Version history, preview the earlier result, and revert to it before continuing.

When to use Plan instead

Choose Plan mode when the request has unresolved product decisions, multiple possible flows, or important data requirements. Plan keeps the conversation read-only until you approve an editable draft. Choose Build when the outcome is already clear.

Continue from here