A reactive Python notebook with a web interface and application deployment tools.
marimo opens by telling agents to consider the library's users and maintainers, not only the person making the request. The rest covers Python and frontend checks, contribution rules, and a docstring convention formatters do not catch.
├── ├── · imports AGENTS.md ├── docs │ └── _static │ └── ├── frontend │ └── ├── marimo │ └── └──
01 / Behavioral framing
The opening frames APIs, abstractions, documentation, and code as the product. It asks the agent to consider existing and future users as well as the person requesting a patch.
Source excerpt starting at line 7.Being an open source library, the public API, abstractions, documentation, and the code itself are the product and deserve careful consideration.
02 / Contribution etiquette
The PR section explicitly requires a human request before submission. The file presents contribution authority as a separate constraint from the ability to produce code.
Source excerpt starting at line 50.- DO NOT open a pull request autonomously, without explicit instructions from a human
03 / Contribution etiquette
The guide gives the location and full text of the agent-authorship notice and also requires a draft. This removes ambiguity about how a contributor should disclose the origin of a patch.
Source excerpt starting at line 52.- You MUST disclose that you are an agent at the very top of your PR description: "**This pull request was authored by a coding agent.**"
04
The Python conventions section says most rules already live in tooling. Its additional instruction concerns the Markdown dialect used by rendered docstrings, including the exact inline-code delimiter.
Source excerpt starting at line 64.- Docstrings are rendered as Markdown, not reStructuredText. Use single backticks for inline code (`value`), never double backticks.
These instructions explain how to work in marimo. Modem shows your agents what customers said, who is affected, and what changed.