mini-me v1.0.5

mm dockerinit and mm sbxinit write the files to run mini-me in a container or a Docker Sandbox, mm init gives the agent its name, two vibe-coding demos (Go and Swift), and a macOS binary signed and notarized by Apple.

New

`mm dockerinit`: run mini-me in a container (#189)

mm dockerinit writes two files in the current directory:

a Dockerfile that installs the latest release of mm, for amd64 and arm64. It finds the release through the SHA256SUMS of releases/latest, so a new release invalidates Docker's cache. The agent never runs as root: the image has a mm user.
a compose.yaml that mounts your project and runs the container with your user and group ids (MM_UID and MM_GID override them).

The output and the how-to show both ways of using it: a long-lived container (docker compose up -d --wait, then docker compose exec … mm tui <agent>) and a one-off run (docker compose run --rm …). For both architectures at once, build with docker buildx: putting platforms in compose.yaml fails without QEMU. An editor can talk to mm in the container over ACP through docker exec -i.

If Dockerfile or compose.yaml already exists, mm asks before overwriting it (default: no). With --yes, or when the input ends, it writes nothing.

Tried on linux/arm64 with Docker 29.8.1. Not tried: the amd64 build, reaching the model directly through host.docker.internal, macOS and Windows hosts.

See Run mini-me in a container.

`mm sbxinit`: a `sbxenv.yaml` for Docker Sandboxes (#191)

mm sbxinit writes sbxenv.yaml in the current directory, for the mini-me kit:

the kit at its latest release, read from the kit's releases page when the file is generated (latest with a warning when the page cannot be reached);
--workspace ./workspace becomes an absolute path;
sandboxOptions.pullPolicy: always.

The agent file is looked for in the current directory, then in the workspace. When it is outside the workspace, mm sbxinit only warns: the how-to explains the two ways out (move the file, or mount its folder read-only and point AGENT_CONFIG at it). Existing files are handled like mm dockerinit's.

Not tried: sbx env create with the generated file.

See Generate a sbxenv.yaml with mm sbxinit.

`mm init` gives the agent its name (#182)

The system prompt of a file written by mm init now starts with Your name is <name>., where the name is the one typed at Agent name?. Without a name, the agent takes the name of its usage (Your name is docs.). Asked its name on Mellum (Docker Model Runner), the agent answered with it 3 times out of 3.

For the editors, acp.name is the name in lower case (bob) and acp.title the name followed by the usage (Bob (developer)).

When the agent file already exists, mm init asks Overwrite agent.yaml? (default: no, and it asks for another file name). The new file is checked by loading it before it replaces the old one.

`mm init` links to the online documentation (#179)

The comments of a file written by mm init point to the documentation as https:// links, instead of paths that only made sense in a copy of the source code. The Next: hints are on four lines.

Point the agent at a list of pages (#181)

No new setting: the list of URLs the agent should read goes in the system prompt. The new section of the how-to has an example. On Mellum with three URLs, the agent fetched the right page 4 times out of 4. The list guides the model but does not restrict it: asked for example.com, it fetched it 2 times out of 2 despite "Do not use any other URL". Blocking URLs would need a hook.

See Point the agent at a list of pages.

Distribution

The macOS binary is signed with a Developer ID and notarized by Apple. Downloaded with a browser, it runs without a quarantine step (macOS checks the notarization online the first time). Downloaded with curl, as in the install guide, nothing changes.
Releases are now built on the maintainer's machine and published as prereleases. The assets and the SHA256SUMS file keep the same names.

Demos

demos/gemma-coder/: a Go specialist for vibe coding on Gemma 4 26B-A4B (thinking on, gopls for lsp, yolo: true). It writes the code and its tests, runs go build and go test, and fixes what fails. Measured on nine cases, two runs each: 16/18.
demos/muse-coder/: the Swift counterpart on Muse-Glimmer 30B (reasoning_strength: high, sourcekit-lsp, SwiftPM). Measured on nine cases, two runs each: 17/18 before the last prompt change, which fixed lsp rename (2/2 afterwards). The other cases were not measured again with the final prompt.
Moved under demos/: dev.team/ → demos/dev.team/, learning-rust/ → demos/learning-rust/, sbx/ → demos/use-with-sbx/.

Documentation

New: Run mini-me in a container.
Getting started with MCP is rewritten (#180): the English page was a copy of the general getting-started tutorial. It now uses demos/dmr/agent.dmr.mcp.yaml, shows the 🔐 confirmations of permissions: ask, and works without any API key through Wikipedia. The Context7 and GitHub steps were not run with real keys.
The vulcan-salute skill is loaded only once per conversation (#190): later requests reuse what the history holds, so the recap shows 📖 0 skill(s) while the command still runs. Expected behaviour, not a bug.

Upgrading

Agent files do not change. Replace the binary: see the install guides for macOS, Linux and Windows.
Two new commands, mm dockerinit and mm sbxinit.
Files written by mm init from now on start their system prompt with Your name is …. Files written before are left alone.
If you used the demos from their old folders, they are now under demos/ (see above).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78


# mini-me v1.0.5

*[Version française](v1.0.5.fr.md)*

`mm dockerinit` and `mm sbxinit` write the files to run mini-me in a container or a Docker Sandbox, `mm init` gives the agent its name, two vibe-coding demos (Go and Swift), and a macOS binary signed and notarized by Apple.

## New

### `mm dockerinit`: run mini-me in a container (#189)

`mm dockerinit` writes two files in the current directory:

- a `Dockerfile` that installs the **latest release** of mm, for `amd64` and `arm64`. It finds the release through the `SHA256SUMS` of `releases/latest`, so a new release invalidates Docker's cache. The agent **never runs as root**: the image has a `mm` user.
- a `compose.yaml` that mounts your project and runs the container with your user and group ids (`MM_UID` and `MM_GID` override them).

The output and the how-to show both ways of using it: a long-lived container (`docker compose up -d --wait`, then `docker compose exec … mm tui <agent>`) and a one-off run (`docker compose run --rm …`). For both architectures at once, build with `docker buildx`: putting `platforms` in `compose.yaml` fails without QEMU. An editor can talk to mm in the container over ACP through `docker exec -i`.

If `Dockerfile` or `compose.yaml` already exists, mm asks before overwriting it (default: no). With `--yes`, or when the input ends, it writes nothing.

Tried on linux/arm64 with Docker 29.8.1. **Not tried**: the amd64 build, reaching the model directly through `host.docker.internal`, macOS and Windows hosts.

See [Run mini-me in a container](../docs/en/how-to/run-in-a-container.md).

### `mm sbxinit`: a `sbxenv.yaml` for Docker Sandboxes (#191)

`mm sbxinit` writes `sbxenv.yaml` in the current directory, for the [mini-me kit](https://rickub.com/bots-garden/mini-me-kit):

- the kit at its **latest release**, read from the kit's releases page when the file is generated (`latest` with a warning when the page cannot be reached);
- `--workspace ./workspace` becomes an absolute path;
- `sandboxOptions.pullPolicy: always`.

The agent file is looked for in the current directory, then in the workspace. When it is outside the workspace, `mm sbxinit` only warns: the how-to explains the two ways out (move the file, or mount its folder read-only and point `AGENT_CONFIG` at it). Existing files are handled like `mm dockerinit`'s.

**Not tried**: `sbx env create` with the generated file.

See [Generate a sbxenv.yaml with `mm sbxinit`](../docs/en/how-to/run-in-a-docker-sandbox.md#generate-a-sbxenvyaml-with-mm-sbxinit).

### `mm init` gives the agent its name (#182)

The system prompt of a file written by `mm init` now starts with `Your name is <name>.`, where the name is the one typed at `Agent name?`. Without a name, the agent takes the name of its usage (`Your name is docs.`). Asked its name on Mellum (Docker Model Runner), the agent answered with it 3 times out of 3.

For the editors, `acp.name` is the name in lower case (`bob`) and `acp.title` the name followed by the usage (`Bob (developer)`).

When the agent file already exists, `mm init` asks `Overwrite agent.yaml?` (default: no, and it asks for another file name). The new file is checked by loading it before it replaces the old one.

### `mm init` links to the online documentation (#179)

The comments of a file written by `mm init` point to the documentation as `https://` links, instead of paths that only made sense in a copy of the source code. The `Next:` hints are on four lines.

### Point the agent at a list of pages (#181)

No new setting: the list of URLs the agent should read goes in the system prompt. The new section of the how-to has an example. On Mellum with three URLs, the agent fetched the right page 4 times out of 4. The list **guides** the model but does not **restrict** it: asked for example.com, it fetched it 2 times out of 2 despite "Do not use any other URL". Blocking URLs would need a hook.

See [Point the agent at a list of pages](../docs/en/how-to/fetch-a-web-page.md#point-the-agent-at-a-list-of-pages).

## Distribution

- **The macOS binary is signed with a Developer ID and notarized by Apple.** Downloaded with a browser, it runs without a quarantine step (macOS checks the notarization online the first time). Downloaded with `curl`, as in the install guide, nothing changes.
- **Releases are now built on the maintainer's machine** and published as **prereleases**. The assets and the `SHA256SUMS` file keep the same names.

## Demos

- [`demos/gemma-coder/`](../demos/gemma-coder/README.en.md): a Go specialist for vibe coding on Gemma 4 26B-A4B (thinking on, gopls for `lsp`, `yolo: true`). It writes the code and its tests, runs `go build` and `go test`, and fixes what fails. Measured on nine cases, two runs each: 16/18.
- [`demos/muse-coder/`](../demos/muse-coder/README.en.md): the Swift counterpart on Muse-Glimmer 30B (`reasoning_strength: high`, sourcekit-lsp, SwiftPM). Measured on nine cases, two runs each: 17/18 before the last prompt change, which fixed `lsp rename` (2/2 afterwards). The other cases were not measured again with the final prompt.
- Moved under `demos/`: `dev.team/` → `demos/dev.team/`, `learning-rust/` → `demos/learning-rust/`, `sbx/` → `demos/use-with-sbx/`.

## Documentation

- New: [Run mini-me in a container](../docs/en/how-to/run-in-a-container.md).
- [Getting started with MCP](../docs/en/tutorials/mcp-getting-started.md) is rewritten (#180): the English page was a copy of the general getting-started tutorial. It now uses `demos/dmr/agent.dmr.mcp.yaml`, shows the `🔐` confirmations of `permissions: ask`, and works without any API key through Wikipedia. The Context7 and GitHub steps were not run with real keys.
- The `vulcan-salute` skill is loaded only once per conversation (#190): later requests reuse what the history holds, so the recap shows `📖 0 skill(s)` while the command still runs. Expected behaviour, not a bug.

## Upgrading

- **Agent files do not change.** Replace the binary: see the install guides for [macOS](../INSTALL.MACOS.md), [Linux](../INSTALL.LINUX.md) and [Windows](../INSTALL.WINDOWS.md).
- Two new commands, `mm dockerinit` and `mm sbxinit`.
- Files written by `mm init` from now on start their system prompt with `Your name is …`. Files written before are left alone.
- If you used the demos from their old folders, they are now under `demos/` (see above).