The @devdojo/sites CLI

Everything the browser builder does, from your terminal. Your site is a plain folder of Blade files; the CLI keeps that folder and DevDojo in step, renders it locally with the same engine production uses, and lets your own tools — VS Code, Cursor, Claude Code, git — work on it.

npm i -g @devdojo/sites        # or run anything with: npx @devdojo/sites <command>

site login                     # device-code login in the browser
site new my-site               # a minimal starter (or --template=lumen, see `site templates`)
cd my-site && site dev         # local preview with live reload
site connect --create          # create the site on DevDojo from this folder
site deploy                    # push + publish → live at your-slug.devdojo.site

devdojo is an alias for site — handy in scripts, or if site clashes with something on your PATH. The npm package is not the Composer package devdojo/devdojo, which pulls a site into a Laravel app; both are clients of the same API.

#Your folder is the source of truth

my-site/
├── resources/
│   ├── views/pages/**.blade.php        # pages (dynamic ones: [collection.field].blade.php)
│   ├── views/components/**.blade.php   # sections, layouts (+ optional .yml schemas)
│   ├── data/site.json                  # → $site
│   ├── data/collections/*.json         # → $name
│   ├── css/site.css                    # Tailwind v4
│   └── design.md                       # the site's design brief
├── public/**                           # assets, served verbatim
└── .devdojo/
    ├── link.json                       # which site this folder is linked to (gitignored)
    ├── rules.md                        # rules every agent editing this site must follow
    └── skills/<name>/SKILL.md          # site-specific skills for agents

Only resources/, public/ and .devdojo/ sync. The Blade dialect is the pocketknife subset: @props, components and slots, @foreach / @if / @class, collections — no @php, no raw <?php. Anything executable is refused on push, because connected Laravel apps render these files as native Blade.

#Syncing, without surprises

Nothing is silently overwritten. Every file has a hash; when the same file changed both here and on DevDojo, push answers 409 and pull stops, naming the paths. You decide: site pull --force keeps the server copy, site push --force keeps yours. Files only one side changed merge automatically. If the Assistant is mid-turn, push waits with a 423 — retry in a moment.

site deploy sends source, never built HTML. DevDojo's exporter is the only production build, so the browser builder, Visual mode, the Content panel and the AI all keep working on the same files. site build is for local inspection only.

#Agents

• site ai "add a pricing page" runs an Assistant turn on your site's chat from the terminal: local changes are pushed first, the reply streams, and the result is pulled back. --engine=<key> picks the model (site ai --engines lists them), --new starts a fresh thread, --create builds from scratch.
• site mcp exposes the folder to Claude Code, Cursor or any MCP client over stdio: list_files, read_file, apply_changes (same guards as above), compile, list_sections / add_section, pull, push, publish, plus the dialect skill and your .devdojo/rules.md as resources. site mcp --setup prints the config snippet. For agents with no local checkout there is a remote endpoint, POST /api/sites/{slug}/mcp, with the same tools.
• .devdojo/rules.md and .devdojo/skills/*/SKILL.md are injected into every Assistant turn as Site rules / Site skills — below the platform's own rules, so a site rule can steer taste but never break the dialect.
• site log, site diff --turn=<id>, site rollback <id> — every Assistant turn is addressable: see what it changed, line by line, and restore the site to just before it (the rollback is itself recorded as a turn).
• site keys set anthropic stores your own provider key (encrypted, write-only). Turns on that provider run on your key and are not metered against your credits. Manage keys and CLI tokens at Account → CLI & API tokens.

#Building blocks

• site add --list, site add heros/hero-01 — copy a library section into resources/views/components/sections/ and paste the tag it prints. The file is yours from then on.
• site check — the pre-deploy report: the compile lint for every page (static and dynamic), broken internal links, CSS size. Exit code 1 on errors, so it slots into CI.
• site templates — the catalog; site new <folder> --template=<slug> starts from one.

#Tokens and security

site login opens /cli/activate in your browser and shows an 8-character code; approving it mints a token scoped to your account (abilities sites:read, sites:write, sites:publish, sites:ai). A verified email is required. The token lives in ~/.config/devdojo/credentials (mode 0600), one per control-plane host; DEVDOJO_TOKEN overrides it for CI. Revoke tokens any time from Account → CLI & API tokens. Pointing the CLI at another instance: DEVDOJO_URL=https://devdojo.test site ….