Knowledge

Knowledge stores the instructions you would otherwise repeat in project conversations. Use it to tell Mythos what your app is for, which terms your team uses, and which conventions future changes should preserve.

There are two scopes:

Mythos includes both as context for Build. Project instructions are more specific and take precedence when they conflict with workspace instructions. Keep the two consistent where possible.

Knowledge or skills?

Knowledge is background for future requests. A Skill is a reusable workflow you choose for a particular task.

For example, “Our customers call a booking a reservation” belongs in Knowledge. A sequence for reviewing a reservation form belongs in a skill. Your current chat message is still the right place for a one-time request.

Add workspace instructions

Workspace owners and admins can edit workspace knowledge.

1. Open Workspace settings → Knowledge.
2. Enter the shared rules in Workspace instructions.
3. Wait for Saved before leaving the page or starting work that depends on the change.

Use a small set of rules that makes sense across the whole workspace. Each workspace has one shared instruction field; put exceptions in the relevant project’s instructions.

Workspace examples

For a team building customer-facing websites:

Writing
- Use plain English and sentence case for headings.
- Explain the benefit before listing technical details.
- Ask for missing customer facts instead of inventing testimonials or figures.
Design
- Keep navigation labels consistent across pages.
- Give every form field a visible label.
- Check narrow layouts before treating a visual change as finished.
Development
- Reuse the project's existing components and dependencies.
- Explain any new service the app needs before adding it.

For an agency with several unrelated client projects, shared process is usually more useful than a single brand palette:

Keep each client's existing identity, terminology, and contact details.
Use sample content only when the request asks for a demonstration.
Before replacing real content, explain which sections will change.

Put each client’s colors, audience, and product names in that project’s knowledge instead.

Add project instructions

People with permission to edit the project can update its instructions.

1. Open the project.
2. Go to More → Settings → Knowledge.
3. Edit Project instructions and wait for Saved.

Start with the app’s purpose and the decisions most likely to affect future changes. Add details only when they help Mythos make a correct choice. Useful examples include the meaning of a booking status, which people may see a record, or an existing page that new pages should resemble.

Project examples

For a workshop booking app:

Purpose
Help a ceramics studio manage small group classes and reservations.
Audience
Visitors browse classes and reserve a place.
Studio staff manage dates, capacity, and attendance.
Terminology
A class is one scheduled session.
A reservation is a visitor's place in that class.
Cancelled reservations do not count toward capacity.
Behavior to preserve
Visitors may view class details without signing in.
Only the person who made a reservation may view their reservation details.
Use the studio's existing local date and time format.
Design
Keep the current warm palette and readable type.
New forms should follow the layout of the reservation form.

For a reporting dashboard, focus on what the numbers mean:

Revenue means paid invoices, excluding tax and refunded amounts.
Draft invoices must not appear in revenue charts.
A customer may have more than one subscription.
Use the selected reporting timezone consistently across charts and exports.

Write decisions you have actually made. If the backend or data rules are still undecided, describe the open question in chat instead of recording a guess as a permanent rule.

Saving and resolving conflicts

Both fields save automatically and support up to 10,000 characters each. An over-limit draft stays visible, but it must be shortened before it can save.

If someone changes the same instructions while you are editing, Mythos pauses autosave and keeps your draft visible. Expand Saved version to compare the two versions. Copy any text you want to keep, then choose:

• Load saved version to use the currently saved instructions.
• Replace saved version to save your draft over that version.

Make this choice deliberately when working with a teammate. Retrying without comparing can discard useful changes.

New instructions apply to subsequent Build requests. Editing Knowledge is not a request to change existing code, update stored data, or publish the site.

Write instructions that help

Keep shared rules at the workspace level and app-specific facts at the project level. Use short sections and concrete language. “Show prices in euros with two decimal places” is more useful than “Format prices correctly.”

Review Knowledge when the app changes direction. Remove obsolete decisions rather than adding a second rule that contradicts them. You do not need to describe every component or copy the full project history.

Knowledge is guidance, not a test of whether the app follows it. Ask Mythos to implement a needed change, then check the resulting behavior. In particular, writing an access rule in Knowledge does not configure database permissions; see Row-level security.

Do not put passwords, access tokens, or other credentials in these fields. Use the relevant connection or secret-setting flow when a feature requires them.