What to put in Mythos Knowledge

Imagine you are building a site for a bicycle rental business. You have already explained that a rental day ends at 6 pm, that customers collect bikes from the shop, and that repair appointments are a separate service. The next request is about the homepage, but those decisions still matter.

Knowledge gives that continuing context a place in Mythos. It helps you carry business facts, terminology and design decisions into subsequent work. A useful starting point is the last correction you had to make twice. If the answer will still matter next week, consider saving it.

The aim is a short reference someone joining the project could understand. You do not need to document every screen before you start building.

Some instructions belong across a team; others only make sense for one project. Keep that distinction clear when you add Knowledge.

Workspace owners and admins can edit Workspace settings → Knowledge. People who can edit a project can change its Knowledge under More → Settings. Wait for Saved before starting work that depends on the new instructions.

Mythos uses workspace and project instructions as Build context. A project-specific instruction takes precedence where the two conflict, but keeping them consistent makes your intent easier to follow. See the Knowledge documentation for the settings and save behavior.

For the rental example, a useful note would explain the audience, how the service works, and the wording the business has approved. Visitors choose a bike and request a collection date. Staff confirm availability. A request is not a confirmed reservation. Repair enquiries use a different form.

These facts affect several pages. They help distinguish a button that sends a request from one that promises a booking. They also give you something concrete to check when Mythos changes a form or writes a confirmation message.

Add the design decisions that matter across pages: the existing service page is the reference for heading sizes; photographs should show the actual rental bikes; opening hours must match the contact page. A reference to a real page is easier to use than an instruction to make everything look premium.

Only save facts you have agreed on. If the shop has not decided whether it will offer delivery, leave that as a question in the current conversation. Otherwise an unresolved idea can quietly become a premise for later work.

After saving the rental rules, ask for the next change: make the request form explain that staff will confirm availability. Check the form, the submitted state and any message the visitor receives. All three should describe the same process.

Saving instructions does not update existing pages or change stored records. It also does not configure access permissions. If a customer should only see their own requests, that behavior still needs implementation and a test with separate accounts.

Keep a repeatable review procedure in a Skill, and keep the immediate task in chat. Knowledge can supply the business context while the skill supplies a chosen method. You can then review one change at a time against a clear result.

Review the relevant notes when the service changes direction. If the shop starts offering delivery, replace the old collection-only rule and explain which bookings qualify. Adding a second sentence that contradicts the first makes the next request harder to interpret.

Keep passwords and API keys in the appropriate connection or secret-setting flow. Customer records and changing stock levels belong in the systems that manage them, rather than a paragraph of background instructions.

A good Knowledge entry earns its place by helping with the next decision. Start with the few facts you repeatedly explain, try a small change, and revise the notes when the result shows what was unclear.