Overview
Two binaries — one runs the workspace, one connects it to the cloud.
There are two command-line surfaces, and which one you want depends on whether you are working on a deck or moving it somewhere.
beem-slide comes from the framework package and operates on the workspace
in front of you: run it, compile-check it, build it, refresh its skills. It is
on your PATH inside a scaffolded project because @beem-slide/core provides
the binary.
beem comes from @beem-slide/cli and does the two things that reach
outside the directory: scaffolding a new workspace, and talking to the cloud —
sign in, push, pull, publish, and register the MCP toolset with an agent
client. See Connect.
The runtime commands
| Command | Does |
|---|---|
beem-slide dev | Dev server with hot reload, inspector, assets panel and present mode. |
beem-slide check | Type-checks every deck without building a site. |
beem-slide build | Static site into dist/. |
beem-slide preview | Serves dist/ so you can rehearse against the real build. |
beem-slide sync:skills | Re-copies the built-in agent skills after an upgrade. |
What the scaffold wires up
beem init writes two scripts, not five:
{
"scripts": {
"dev": "beem-slide dev",
"check": "beem-slide check"
}
}Those are the two you run constantly, so they get the shorthand. The rest you
call directly — npx beem-slide build, npx beem-slide preview — or add to
scripts yourself if a deck is something you build often.
This catches people out, so it is worth saying plainly: in a fresh workspace
npm run build fails, because there is no build script to run. The command
is npx beem-slide build.