Overview

The bet the framework makes is narrow: a slide is code, models are good at code, and the part nobody wants to write is the runtime around it. So the runtime is the product, and the pages are written by whatever agent you already use.

That only works if the agent knows two different kinds of thing, and they arrive by two different routes.

The rules ship with the workspace

beem init writes AGENTS.md at the root — the file contract and the guardrails, short enough that an agent reads all of it:

• A deck lives in slides/<kebab-case-id>/, entry slides/<id>/index.tsx.
• That file default-exports a non-empty array of zero-prop components.
• Assets go in slides/<id>/assets/, imported as ES modules.
• Do not touch package.json, beem-slide.config.ts, or another deck.
• Do not add dependencies. React and the web platform are what there is.

CLAUDE.md links to the same file, so Claude Code and the tools that look for AGENTS.md end up reading one source rather than two that drift.

The last two rules are the ones that earn their place. Without them an agent solving a layout problem will reach for a chart library, or "tidy" a config it does not understand, and you find out later.

The guides are served, not shipped

Knowing the file contract is not the same as knowing how to make a deck look good. The canvas arithmetic, the type scale, how to plan a running order, how to lift a theme out of an existing deck — that material is the authoring guides, and it is deliberately in no npm package and no scaffold.

It comes from the MCP server's authoring_guide tool, served to a signed-in account:

npx --package=@beem-slide/cli beem mcp install
npx --package=@beem-slide/cli beem login

Two consequences worth knowing. The guides are current — an agent gets today's version rather than whatever was vendored into your repo when you scaffolded. And a workspace with no MCP registration still works: your agent can author decks from AGENTS.md alone, it just does not have the material that makes pages come out consistent.