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

# Knowledge

> Keep shared conventions and project context available for future Build requests.

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:

| Scope                      | Applies to                     | Useful for                                                               |
| -------------------------- | ------------------------------ | ------------------------------------------------------------------------ |
| **Workspace instructions** | Projects in the same workspace | Shared style, terminology, libraries, and team preferences               |
| **Project instructions**   | One project                    | The audience, app behavior, data model, and project-specific constraints |

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](/features/skills) 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:

```text
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:

```text
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:

```text
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:

```text
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](/integrations/supabase#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.