/marimo-pair

name: marimo-pair
description: >-
  Drive a live marimo notebook as a workspace: run Python in the same kernel
  the user does, inspect live notebook state, and commit durable notebook
  changes. Use when the user wants to start a marimo notebook or pair on an
  active marimo session.
allowed-tools: Bash(bash **/scripts/discover-servers.sh *), Bash(bash **/scripts/execute-code.sh *), Read

marimo is a reactive Python runtime for building reproducible Python programs (marimo notebooks). Cells are connected by the variables they define and reference. Running a cell re-executes dependents in dataflow order. The active runtime holds the kernel namespace, cell state, and dataflow graph. The notebook (`.py` file) is the artifact the kernel writes from that state while a session is running.

A user interacts with the same runtime via a notebook UI with cells, outputs, and widgets.

**WARNING. The active runtime is the source of truth.** During a session, you SHOULD NOT modify the associated `.py` file directly. File edits WILL NOT reach the active kernel or user, and the kernel may overwrite them on save. Use `marimo._code_mode` (`cm`) for notebook changes. Reading disk is fine, but prefer `ctx.cells[...].code` for current cell code.

The harness reports the absolute path to this `SKILL.md`. Resolve bundled `scripts/...` and `reference/...` paths from its parent directory, even when the current working directory is a notebook workspace. In command examples, replace `/absolute/path/to/marimo-pair` with that directory.

Required first kernel command

Start every code-mode session with this dedicated command:

bash /absolute/path/to/marimo-pair/scripts/execute-code.sh \
  --url http://localhost:2718 \
  -c "import marimo._code_mode as cm; help(cm)"

Follow this order for each kernel, including read-only tasks:

1. Run the inspection command once. 2. Wait for successful `help(cm)` output. 3. Then use `cm.get_context()` or another `cm` API in a later call.

Do not run task-specific `cm` code before the inspection command succeeds.

Connect to a Notebook

Use the bundled `execute-code.sh` from the reported skill directory or MCP (`execute_code(...)`) to run Python in a live marimo kernel.

`execute-code.sh` always takes `--url`. If the user provides a notebook URL, run the required inspection against it directly:

bash /absolute/path/to/marimo-pair/scripts/execute-code.sh \
  --url http://localhost:2718 \
  -c "import marimo._code_mode as cm; help(cm)"

After that command succeeds, pass task code with `-c CODE`, `-` for stdin, or a file path:

bash /absolute/path/to/marimo-pair/scripts/execute-code.sh \
  --url http://localhost:2718 - <<'PY'
import marimo._code_mode as cm

async with cm.get_context() as ctx:
    cid = ctx.create_cell("x = df.head()")
    ctx.run_cell(cid)
PY

If the user gives no URL, find or start a notebook. Look for a running server with `bash /absolute/path/to/marimo-pair/scripts/discover-servers.sh`, MCP `list_sessions()`, or local process context, and pass the `url` it reports to `--url`. With one notebook open, the script targets it automatically; with several, pass `--file` with the notebook's file key.

If no server is running and the user wants a notebook, start marimo with `--no-token` (and without `--headless`) so it auto-registers for discovery. The notebook UI must be open for `execute-code` to target it. The right invocation depends on context (project tooling, global install, sandbox mode). If the notebook file contains a PEP 723 `# /// script` header, it MUST be opened with `--sandbox` — otherwise marimo ignores the inline dependencies. See [finding-marimo.md](reference/finding-marimo.md) for the full decision tree and [execution-context.md](reference/execution-context.md) for selector resolution, scripts, MCP, and shell quoting.

Scratchpad Scope

`execute-code` evaluates Python in marimo's scratchpad: a temporary namespace with a shallow copy of the kernel globals. Notebook variables are available by name, but new top-level bindings and rebindings are discarded after each call. In-place mutations to notebook-owned objects can persist because those names still reference live objects.

Each call reports stdout and stderr from the scratchpad, plus console output from notebook cells it causes to run, including reactive descendants.

Ordinary Python

Use ordinary Python in the scratchpad to inspect variables, sample data, test transformations, probe APIs, check imports, and read widget state.

print(df.head())

x = 10
print(x)

Here `df` comes from notebook globals, while `x` is a scratchpad-local binding. `x` exists for this call only and WILL NOT be added to notebook globals.

Persist with `cm`

Top-level scratchpad assignments and rebindings are temporary. To persist work, including new variables, you MUST submit changes through `marimo._code_mode` (`cm`).

`marimo._code_mode` is a PRIVATE, UNSTABLE agent API (note the leading underscore). It exists for tools like this skill to drive a live kernel from the scratchpad. DO NOT import it from notebook cells, library code, or anything a user would run — methods can change or disappear across marimo versions and kernels. Treat every `import marimo._code_mode as cm` as scratchpad-only.

Open a code-mode context to queue notebook changes.

import marimo._code_mode as cm

async with cm.get_context() as ctx:
    cid = ctx.create_cell("x = df.head()")
    ctx.run_cell(cid)

The scratchpad supports top-level async code. Use `async with` directly; wrapping it in `asyncio.run(...)` is unnecessary and can conflict with the kernel's event loop.

After this block exits and the new cell runs, `x` is notebook state. Later scratchpad calls can read `x` by name. Code later in the same scratchpad call should read `ctx.globals["x"]`, because the scratchpad namespace was copied before the cell ran.

Inside the context, queued mutation methods are synch