Build

Plan mode

Resolve important decisions in a read-only conversation, edit the resulting plan, and approve the exact scope you want Mythos to build.

Plan mode helps when the desired outcome is clear but the path to it is not. Mythos asks focused questions, prepares an editable plan, and waits for approval before it changes the project.

You can use Plan for a new project or for a substantial change to an existing one. Until you approve the draft, planning does not write project code or replace the current Preview.

When Plan is useful

Choose Plan when the request includes decisions that would materially change the result, such as:

  • Which pages or user flow belong in the first release.
  • What data must persist and which service will hold it.
  • Which roles or permissions the app needs.
  • Which interactions are essential and which can wait.
  • Which constraints or reference files the Build must respect.

Choose Build instead when you can already describe one testable outcome without further discovery.

Create and approve a plan

Choose Plan in the composer

Select Plan, then describe the project or change in the same plain language you would use for a Build.

Answer focused questions

Mythos asks only for missing decisions. Reply with the information you know; if a detail is not important, say that Mythos can choose it.

Review the draft

When the scope is ready, Mythos saves a concrete plan in the workspace. Check the goals, user flow, data needs, and acceptance points rather than treating the draft as background prose.

Edit what needs to change

Change the draft directly when a sentence, order, or boundary is wrong. Saving your own edits does not ask the AI to rewrite the plan.

Approve the exact version

Approve only when the draft describes the result you want. Approval hands that exact plan to the normal Build; it does not silently add later conversation or an older draft.

Example

Start with a useful brief rather than a blank request:

Plan a booking experience for a small pilates studio called Still Point.
It needs class discovery, a clear schedule, pricing, and a way to request a place.
Keep the first release focused and call out anything that requires connected data.

The questions should resolve only the choices that block a buildable result. If the plan grows into a future roadmap, trim it back to the first outcome you can test.

Change or leave a plan

  • Continue the planning conversation when a product decision is still unresolved.
  • Edit the draft directly when you already know the correction.
  • Cancel when you no longer want to build that plan; cancellation does not change project code.
  • Start a fresh Plan if the existing project changes enough that the saved draft no longer describes its current source.

Plan turns and the Build started after approval are separate usage actions. Direct draft edits, approval, and cancellation do not start another Plan turn. See Credits and usage.

Next step

After approval, follow Building and editing to review the delivered result. If the initial brief itself is still vague, use Writing good prompts before starting the session.