
Implement Paper Auto
Generate marimo notebook anywidget components with vanilla JavaScript _esm, light/dark _css, and mo.ui.anywidget wrapping.
Overview
Implement Paper Auto is an agent skill for the Build phase that generates marimo anywidget components with JavaScript ESM renderers and themed CSS.
Install
npx skills add https://github.com/marimo-team/skills --skill implement-paper-autoWhat is this skill?
- anywidget class pattern with traitlets synced state and default export render function
- Mandatory _esm (vanilla JS) and _css with bespoke light and dark styling
- Display via mo.ui.anywidget(WidgetClass()) wrapper in marimo cells
- Optional pathlib paths for external _esm/_css when widgets are large
- Keeps CSS small unless explicitly asked for elaborate styling
Adoption & trust: 867 installs on skills.sh; 144 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need interactive controls or visuals inside a marimo notebook but lack a consistent pattern for anywidget _esm, _css, and mo.ui.anywidget display.
Who is it for?
Indie data scientists and agent users authoring marimo notebooks who want lightweight custom UI without a separate React app.
Skip if: Production React Native or SaaS frontends, non-marimo Jupyter-only workflows without anywidget parity, or heavy multi-page web apps.
When should I use this skill?
User asks to implement or generate anywidget components for marimo, including _esm render functions, _css theming, and mo.ui.anywidget display.
What do I get? / Deliverables
You get a working anywidget class, correct export/default render wiring, themed CSS, and a marimo cell that displays via mo.ui.anywidget with syncable traitlets state.
- anywidget Python class with _esm and _css
- Marimo display cell using mo.ui.anywidget(...)
Recommended Skills
Journey fit
Build/agent-tooling is the primary shelf because the skill produces interactive notebook UI widgets inside marimo, not production mobile or web app shells. Agent-tooling fits notebook-bound custom widgets that extend how an agent-authored marimo app behaves and displays results.
How it compares
Notebook-scoped widget generator for marimo, not a general React component library or MCP integration.
Common Questions / FAQ
Who is implement-paper-auto for?
Builders using marimo notebooks who want agents to scaffold anywidget-based interactivity with Python state and in-cell JavaScript renderers.
When should I use implement-paper-auto?
Use it in Build when adding counters, controls, or custom displays to marimo notebooks, especially when you need _esm, _css, and mo.ui.anywidget wrapping done correctly.
Is implement-paper-auto safe to install?
Review the Security Audits panel on this Prism page; generated widgets execute JavaScript in the notebook context, so treat untrusted notebook code like any local script execution.
SKILL.md
READMESKILL.md - Implement Paper Auto
When writing an anywidget use vanilla javascript in `_esm` and do not forget about `_css`. The css should look bespoke in light mode and dark mode. Keep the css small unless explicitly asked to go the extra mile. When you display the widget it must be wrapped via `widget = mo.ui.anywidget(OriginalAnywidget())`. You can also point `_esm` and `_css` to external files if needed using pathlib. This makes sense if the widget does a lot of elaborate JavaScript or CSS. <example title="Example of simple anywidget implementation"> import anywidget import traitlets class CounterWidget(anywidget.AnyWidget): _esm = """ // Define the main render function function render({ model, el }) { let count = () => model.get("number"); let btn = document.createElement("b8utton"); btn.innerHTML = `count is ${count()}`; btn.addEventListener("click", () => { model.set("number", count() + 1); model.save_changes(); }); model.on("change:number", () => { btn.innerHTML = `count is ${count()}`; }); el.appendChild(btn); } // Important! We must export at the bottom here! export default { render }; """ _css = """button{ font-size: 14px; }""" number = traitlets.Int(0).tag(sync=True) widget = mo.ui.anywidget(CounterWidget()) widget # Grabbing the widget from another cell, `.value` is a dictionary. print(widget.value["number"]) </example> The above is a minimal example that could work for a simple counter widget. In general the widget can become much larger because of all the JavaScript and CSS required. Unless the widget is dead simple, you should consider using external files for `_esm` and `_css` using pathlib. When sharing the anywidget, keep the example minimal. No need to combine it with marimo ui elements unless explicitly stated to do so. ## Best Practices Unless specifically told otherwise, assume the following: 1. **Use vanilla JavaScript in `_esm`**: - Define a `render` function that takes `{ model, el }` as parameters - Use `model.get()` to read trait values - Use `model.set()` and `model.save_changes()` to update traits - Listen to changes with `model.on("change:traitname", callback)` - Export default with `export default { render };` at the bottom - All widgets inherit from `anywidget.AnyWidget`, so `widget.observe(handler)` remains the standard way to react to state changes. - Python constructors tend to validate bounds, lengths, or choice counts; let the raised `ValueError/TraitError` guide you instead of duplicating the logic. 2. **Include `_css` styling**: - Keep CSS minimal unless explicitly asked for more - Make it look bespoke in both light and dark mode - Use CSS media query for dark mode: `@media (prefers-color-scheme: dark) { ... }` 3. **Wrap the widget for display**: - Always wrap with marimo: `widget = mo.ui.anywidget(OriginalAnywidget())` - Access values via `widget.value` which returns a dictionary 4. **Keep examples minimal**: - Add a marimo notebook that highlights the core utility - Show basic usage only - Don't combine with other marimo UI elements unless explicitly requested 5. **External file paths**: When using pathlib for external `_esm`/`_css` files, keep paths relative to the project directory, consider using `Path(__file__)` for this. Do not read files outside the project (e.g., `~/.ssh`, `~/.env`, `/etc/`) or embed their contents in widget output. Dumber is better. Prefer obvious, direct code over clever abstractions—someone new to the project should be able to read the code top-to-bottom and grok it without needing to look up framework magic or trace through indirection. --- name: implement-paper-auto description: Implement a research paper in a marimo notebook fully automatically without extra user input. --- You need to come up with a c