Skip to content
MemMini

Add a new tool

You wrote your rules once. This is how you make them run inside a new tool, a different chat app, coding CLI, or agent, so the same who.md / how.md behave correctly there instead of breaking.

In MemMini a tool you plug in is called a surface (or consumer). Each surface can do different things: some run code, some can’t; some can schedule a task for later, some only respond when you type. Adding a surface means writing down what yours can do, so your portable intentions land on its real buttons. Adding a surface gives your existing agents a new place to work: it adds a tool, not a new worker. The framework calls this the agent-bootloader.

Easy button: just say it once. You don’t have to do the five steps by hand. Tell your agent “onboard Cursor as a surface” (or any tool, Aider, a new chat app, another agent) and it runs the agent-bootloader: it explores the six intents on the tool, wires the four files that connect it to your mind, registers it, and tests it in a live session. The steps below are exactly what it does. Read them to follow along, review each file before it lands, or do it by hand. Easy button and glass box: the same procedure at two fidelities.

Before you start

Section titled “Before you start”
  • You’ve installed MemMini into your own mind repo, or mounted it as a submodule. See Quickstart.
  • You can edit files in your repo. That’s the only requirement.

How it works, in one breath

Section titled “How it works, in one breath”

Your rules speak in six intents: acquire, retain, compute, effect, coordinate, defer (what an agent is trying to do). A surface offers capabilities (a web tool, a shell, a scheduler). Onboarding writes the mapping between them for your tool, plus a degrade rule for anything your tool can’t do, so nothing silently breaks. The full why: the six intents.

Steps

Section titled “Steps”

1. Copy the worked example

Section titled “1. Copy the worked example”

Copy wiki/platforms/example-cli/ to wiki/platforms/<your-tool>/ (use a lowercase-hyphenated name). You now have four filled files to rewrite for your tool. The worked example doubles as the template.

2. Probe your tool: walk the six intents

Section titled “2. Probe your tool: walk the six intents”

Open your tool and ask, for each intent, what actually does this here? This is the only thinking step; the files just record your answers.

Intent (what you want)Ask: on my tool, what does this?
Acquire infoweb search? file read? or just ask me?
Retain a learninga memory? a file it writes?
Compute (run / test)a shell or sandbox?
Effect (publish / deploy)can it push, send, deploy?
Coordinatespawn a helper? hand off through the shared repo?
Defer to latera scheduler? a hook? neither?

Anything it can’t do gets a degrade rule in the next step. That’s the whole point of the exercise.

3. Fill the four files

Section titled “3. Fill the four files”

In your copied contracts/ folder:

  • injection.md: the file your tool auto-reads (so your context reaches it).
  • captures.md: how it writes a learning back to .learnings/raw.md.
  • hooks.md: what it can enforce automatically, or “nothing. Relies on the every-turn rules.”
  • capabilities.md: the two tables from your probe: what it can do, and how each intent is served (or degraded).

Don’t invent the shape. Your copy from step 1 already carries it: wiki/platforms/example-cli/ is filled in completely, degrade rules and all. Keep its structure; replace every example-cli answer with your own probe results.

4. Register it

Section titled “4. Register it”

If your setup keeps a consumer table, add one row to it (e.g. wiki/contracts/<your>-injection-targets.md, or whichever parent your setup uses) linking the four files. Mark them status: undertesting.

5. Test on a live session

Section titled “5. Test on a live session”

Open a fresh session of the tool and ask it something only your rules would know, e.g. “where does the wiki-layout rule live?” It should answer from your injected context. Then check one capability end-to-end: confirm a publish or deploy actually pauses for your approval. If it doesn’t, the contract is wrong. Fix it and re-probe.

What “done” looks like

Section titled “What “done” looks like”

wiki/platforms/<your-tool>/contracts/ holds four filled files; capabilities.md lists all eleven capabilities and all six intents, each with a serving capability or a degrade rule, and carries a freshness sentinel; and your tool answers from your rules in a fresh session.

Going deeper

Section titled “Going deeper”