Reference

How assistants receive skills and instructions

What memex tells an assistant when it connects, the ways skills are served, how a change reaches a connection, and the notices on live-state and profile notes.

At connect time

When an assistant connects, memex hands it a short instruction text before anything else: that it writes descriptions and tags itself; that list_skills returns instruction sets you have approved and get_skill loads one; that a note’s Sources section is what to reread before acting on the note, and where to record what it consulted; that its writes are reviewed; and what curation it may and may not do in its role. The wording differs for agents and curators.

How skills are served

Skills are served as tools (list_skills and get_skill), resources (memex://skill/<slug>) and prompts, which some clients display as commands. The Skills page has one enable switch and opens all these access paths when a skill is turned on. The underlying API retains separate surface flags for compatibility.

Six skills ship with memex and are listed first: memex-recall, the conventions for reading and writing this knowledge base; memex-curation, the curation procedure; memex-profile, how to find, read and maintain your profile note; memex-docs, this documentation; memex-skills, how to write, review and improve a skill; and memex-writing, how to write a note, while you keep it switched on. Your own served skill notes follow, newest first. The shipped skills appear on the Skills page as compact system cards; they have no note to edit. Only memex-writing changes with your settings, and only through its presets.

Who is served what

A skill’s enable switch is one setting for the whole knowledge base: turning it off or on changes access for every connection, not just one. Narrowing a skill to a set of connections is the part that varies per connection: only the connections you choose are served it, and every other connection is served nothing for that skill.

How a change reaches an assistant

memex’s transport is one request and one reply, never a stream, so it cannot push a change to an assistant mid conversation; the list reaches an assistant three ways instead.

1. At connect time, the initialize instructions name exactly what that connection is served.
2. The list_skills tool description carries the same list, so a client that keeps tool descriptions in context for the session already has it without calling anything.
3. Every tool result, including a failed load, carries a short skills_version; when it differs from the one that connection last saw, including a change to a description, the same result also carries skills_changed, the served list in one line. So the next call after you change something is where the assistant learns of it, never sooner.

memex-writing

memex-writing reaches assistants the same way. While it is on, the initialize text carries a short paragraph, Writing notes, telling the assistant to load it before it writes or edits a note and that what you ask comes first; memex-recall says the same in one line, and the description of propose ends with it. The first tool result after you change a preset or the switch carries personalization_changed once: load the skill again, or, when you switched it off, that it no longer applies. Off, none of these pointers is sent.

live-state

live-state works only through get: the reply for a note carrying that tag includes a standing instruction to correct the note if the assistant’s own work changed the system it describes, by proposing a patch to the sentences that are now wrong or, failing that, a comment saying what changed.

user-profile

user-profile works at connect time and through get. The instruction text every connection receives names your profile note (or says there is none, and how to look again), and the reply for the note itself carries a reading instruction: it outranks what the assistant remembers about you, an unwritten section is unknown, the boundaries in it apply to every note written here, and a change is proposed as a small patch only when the conversation shows a line has stopped being true.

A profile that is still pending gets a different instruction: it is not in force, and only there so no second profile is proposed. A note carrying both tags receives the profile instruction alone.