## TL;DR
Marimo's reactivity (cells re-running when their dependencies change) lives in the marimo runtime, not in the file, so an ipynb export is necessarily a static snapshot: cells in file order with whatever outputs the last run produced. Keep the `.py` marimo file as the source of truth and regenerate the ipynb export on every change. If consumers need the reactive behavior, point them at the marimo file or a marimo-hosted app, not the exported notebook.

```text
agent's marimo export to ipynb lost the reactive graph: static cells only
```

## Use this when
- An exported ipynb shows cells and outputs but nothing re-runs when values change.
- An agent's pipeline exports marimo to ipynb for compatibility and downstream users expect reactivity.
- The exported notebook's cell order does not match the reactive dependency order.

## Not for this skill when
- The marimo notebook itself fails to run. That is a marimo execution problem, not an export problem.
- An ipynb has out-of-order execution bugs. That is classic notebook statefulness, a different fix.

## Steps
1. Confirm the source of truth: locate the marimo `.py` file the export came from. Expected: the marimo file exists and opens as a reactive app.
2. Re-export after any change: run the marimo export command to regenerate the ipynb from the current marimo file. Expected: the ipynb reflects the latest marimo state.
3. Order the export for readers: marimo exports in dependency order where possible; verify the ipynb reads top to bottom sensibly. Expected: a reader can follow the static notebook linearly.
4. Document the export as a snapshot: add a note (in the marimo file's header and the export pipeline) that the ipynb is a static rendering. Expected: no consumer mistakes the snapshot for a reactive document.
5. For consumers who need interactivity, serve the marimo file directly (`marimo run`) or export to HTML with marimo's app mode instead of ipynb. Expected: interactive consumers get reactivity; ipynb consumers get a correct snapshot.
6. Wire the export into the agent's pipeline so it regenerates on every marimo change, never by hand. Expected: the ipynb can never go stale relative to the marimo source.

## Tool compatibility
marimo 0.9.x and later; ipynb export via marimo's export command; Jupyter notebook 7.x / Lab 4.x for viewing.

## Variant phrasings
### marimo to ipynb export static
The snapshot phrasing. The export is static by design; regenerate it from the marimo source.

### marimo reactive cells lost in jupyter export
The loss phrasing. Reactivity is a runtime property that ipynb cannot carry.

### convert marimo notebook to ipynb keeps reactivity
The hope phrasing. It cannot; serve the marimo app for reactivity.

## Why it happens
Marimo and Jupyter have opposite execution models: marimo builds a dataflow graph and re-runs cells automatically when dependencies change, while ipynb is a linear document with manually executed cells. The ipynb format has no representation of a reactive graph, so any export is a lossy projection, cells plus last-known outputs in some linear order. Expecting the export to stay reactive is a category error. The healthy pattern is the same as compiled artifacts everywhere: the marimo file is source, the ipynb is a build artifact, and the build runs automatically.

## Edge cases / pitfalls
- Hand-editing the exported ipynb creates a fork that the next export silently overwrites. All edits go in the marimo file.
- Cells with side effects (writes, API calls) may execute in a different order in the static export than in the reactive graph. Review the export for order-sensitive cells.
- Outputs in the export are from export time. A reader who re-runs cells manually gets classic notebook staleness, not marimo reactivity.
- Agents that diff the exported ipynb will see churn on every export. Diff the marimo `.py` source instead; it is the meaningful change.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wfIynJJYERdzu73GNnFwYA