Getting Started

MEM installs as one Markdown file, MEM.md, placed in a folder of your repository. Your agent reads it, creates a small knowledge base beside it, and asks which optional extensions you want. Everything after that happens through ordinary prompts.

Install

Let the agent do it

Paste this into your coding agent at the root of the repository:

Download the latest MEM.md file from https://raw.githubusercontent.com/Ryadel/MEM/main/src/MEM.md
and place it under /MEM/MEM.md in this repository.

Then read and apply /MEM/MEM.md as the persistent operating memory for this project.
Initialize the MEM knowledge base if required,
then inspect the project before making implementation claims.

The agent creates the folder, saves the file, and starts using it as the project's operating memory.

Do it by hand

1. Download src/MEM.md.
2. Save it in a root-level folder of your project, for example /MEM/MEM.md.
3. Ask your agent:

Read and apply /MEM/MEM.md as the persistent operating memory for this project.
Initialize the MEM knowledge base if required,
then inspect the project before making implementation claims.

Where the knowledge base lives

/MEM/ is a convention, not a requirement. The folder that holds MEM.md is the knowledge base root, called KB_ROOT throughout the documentation, wherever it is. It can be a differently named folder, a subfolder, or a separate repository next to your code. That last layout keeps the knowledge base out of a public repository, and the mem-workspace extension describes it.

What the first session does

On an empty knowledge base, the agent creates a lightweight starting set:

MEM.index.md                      the table of contents of the knowledge base
MEM.project.md                    what the project is: purpose, stack, structure, constraints
architecture/system-overview.md
conventions/coding-style.md
conventions/naming.md
conventions/comments.md
tasks/index.md
tasks/current/backlog.md
logs/YYYY-MM-DD.md                today's log

It fills in what it can verify from the code and marks the rest as placeholders (> TODO: Fill this section after inspecting the codebase.). It must not invent project details. The knowledge base then grows a little with each session; see Knowledge Base for what goes where.

If you want to change a default, create MEM.config.md beside MEM.md, for example to set the language of the knowledge base or your build and test commands. A missing file, or a missing option, means the default applies. See Configuration.

Choosing extensions

Once the knowledge base exists, the agent asks one multiple-choice question:

Which extensions do you want to install? (Some extensions may install additional software.)

Each option names the extension, says what it does, and whether it reaches outside the repository or ships code. Then:

• Choosing is not yet approval. Before writing anything, the agent shows one confirmation listing every file it will write and the URL it comes from, with code files named as code.
• Extensions that ship code are listed even when code is disabled in your configuration (extensions_allow_executable_content: false, the default). If you choose one, the agent explains that the setting covers every code-shipping extension and asks whether to enable it.
• The extensions you do not choose are recorded as declined and are not offered again. You can install one later just by asking, or by using one of its commands.
• If you dismiss the question, nothing is recorded and it is asked again next time.

Not sure what an extension does? Type its name, for example mem-stats ? or explain mem-optimize, and the agent explains it without changing anything. Extensions explains the model; each extension has its own page.

Day-to-day use

You mostly just work. The agent reads the parts of the knowledge base the request needs, inspects the code before making claims about it, and records durable findings: a decision, a diagnosed bug, a convention, a finished task, and a short daily log entry.

A few prompts are worth knowing:

Prompt	What it does
MEM HELP	Lists the commands available in this installation
MEM STATUS	MEM version, KB_ROOT, configuration in effect, extensions with installed and available versions
MEM LINT	Reviews the knowledge base for stale claims, contradictions, orphan pages, open items that are done
MEM FORCE	Re-anchors a drifting session: the agent re-reads MEM and reports which files it read and wrote

All commands are on the Commands page.

Updating

MEM UPDATE, or simply asking the agent to update MEM, replaces MEM.md with the latest published version from mem_update_url. Your MEM.config.md is never overwritten. After the update the agent:

1. reads MEM.upgrade.md, the agent-oriented counterpart of the changelog, and applies the upgrade steps in order from your previous version;
2. compares each installed extension's version with the catalogue and reports the ones that are behind, without updating them on its own;
3. offers any extension the catalogue gained since you were last asked.

With mem_auto_update: true (the default) the same update is attempted automatically once a day, when the agent creates the day's log. The log then opens with a status line such as:

> MEM auto-update: up-to-date from `mem_update_url` (previous: 1.2.0, current: 1.2.0).

The status is succeeded, up-to-date or failed; a failed update leaves your MEM.md untouched.

Updating MEM.md updates the core only. Extensions are updated from the catalogue, separately and only with your approval, because an extension's update can replace instructions or code in your repository.