implement-paper

Implement Paper

Turn a research paper into an interactive marimo notebook. For general marimo notebook conventions (cell structure, PEP 723 metadata, output rendering, marimo check, variable naming, etc.), refer to the marimo-notebook skill.

Step 1: Understand what the user wants

Before fetching or reading anything, have a short conversation to scope the work. Ask the user:

• Which part of the paper interests you most? A paper may have multiple contributions — the user likely cares about one or two. Don't implement the whole thing.
• What's the goal? Are they trying to understand the method, reproduce a result, adapt it to their own data, or teach it to someone else? This changes the notebook's tone and depth.
• Do they want to use a specific dataset? If it's relevant, ask. Otherwise, suggest simulating data.
• Does this require PyTorch? Some papers need it, many don't. Ask if unclear — it's a heavy dependency.
• What's their background? The paper aims to fill a knowledge gap — gauge what the user already knows so the notebook can meet them where they are. Skip basics they're familiar with, explain prerequisites they're not.

Only move on once you have a clear picture of what to build.

Step 2: Fetch the paper

If the user gives you an Arxiv/AlphaXiv link, you will an efficient way to read the paper.

See references/fetching-papers.md for how to retrieve paper content via alphaxiv.org. This avoids reading raw PDFs and gives you structured markdown.

Step 3: Plan the notebook

After reading the paper, outline the notebook structure for the user before writing code.

Keep the notebook as small as possible. Sometimes the idea is best conveyed with just a single interactive widget — if you need a custom one, consider the anywidget skill. Other times you need a full training loop — if so, consider using the marimo-batch skill for heavy computation. The goal is the minimum amount of code needed to get the idea across.

A typical arc:

Not every notebook needs all sections. Share the outline with the user and adjust before writing code.

Step 4: Build the notebook

Create the marimo notebook following the marimo-notebook skill conventions.

Key guidelines:

• Never assume the dataset. Use whatever the user specified in Step 1. If they didn't specify one, simulate data.
• Make it self-contained. A reader should understand the notebook without reading the full paper.
• Use KaTeX for equations. Render key equations with mo.md(r"""$...$""") so the notebook mirrors the paper's notation. Keep notation consistent with the paper.
• Add interactivity where it aids understanding. Sliders for hyperparameters, dropdowns for dataset variants, or toggles for ablations help readers build intuition.
• Show, don't just tell. Prefer a plot or table over a paragraph of explanation.
• Name variables to match the paper's notation where practical (e.g., alpha, X, W), and add comments mapping them to equation numbers.

Tips

• Don't reproduce the entire paper. Focus on what the user asked about in Step 1.
• Iterate visually. Build up figures incrementally (e.g., show data → show model fit → show residuals) rather than dumping everything into one plot.
• If the paper uses heavy notation, include a small "notation reference" cell with a markdown table mapping symbols to descriptions.

If the user wants a custom anywidget, refer to references/anywidget.md.