Workspace-native
Cursor’s agent edits across the whole workspace. A Primo site is the workspace — pages, blocks, content, config — so there’s nothing it can’t reach.
Primo + Cursor
Build and edit a website with Cursor.
Pull your whole site into your Cursor workspace, point the agent at it, and let it edit anything — components, content, pages, routes — the way it would any repo. Push it back, and your client edits the same files live in the browser. No data layer to instrument, no API between the code and the content.
Cursor edits the site. Your client edits the same site.
Cursor works on a workspace — a folder of files it can read, search, and edit across with its agent. A Primo site is that folder: primo pull brings your entire site down as plain files. Blocks are Svelte components, content and config are YAML. Cursor's agent edits them like any other project — Composer, the agent, inline edits, all of it.
When you primo push, those files sync to a relational database on the server, and your client edits the same site visually — on the rendered page, in the fields each block declared. The editor generates itself from each block's fields.yaml; there's no glue code to write to make a field editable.
That's the difference from a git-backed headless CMS. With Tina, your files get indexed into a GraphQL data layer and you instrument each field with useTina before it's editable. Primo has neither the data layer nor the per-field wiring — the editor and the renderer read the same files and rows directly.
Why Cursor fits Primo
Just files, no API
No GraphQL layer, no useTina wiring, no SDK to call. Components are .svelte, schema is fields.yaml, content is YAML. Cursor edits files.
Client edits the same source
After push, your client edits on the rendered page in the fields your blocks declared — the same source Cursor just edited. One source of truth.
The loop with Cursor
Four steps. The CLI is the real Primo CLI — primo pull, primo push. What’s Cursor-specific is step three, where you drive the change from Cursor’s agent.
Pull the site into your workspace.
Brings your whole site in as files — Svelte blocks, YAML content and config, pages, routes. Auth is a PRIMO_TOKEN you generate per site in the admin.
$ primo pull <your-site-host>
✓ pulled 14 blocks · 6 pages · content + config
Run the local preview.
Starts the local dev server. It watches the workspace and auto-imports your file changes so you see them as Cursor edits.
$ primo dev
▸ dev server on http://localhost:5173 · watching files
Let Cursor edit anything.
Open the folder in Cursor and describe the change in the agent or Composer. It edits across the whole workspace — components, content, new pages — no fields to instrument first.
$ ⌘K "redesign the pricing page and add a /vs/sanity comparison"
✎ editing blocks/pricing · creating pages/vs/sanity.yaml
Push it back, hand off the browser.
Only changed files upload. They sync to the database on the server, and your client edits the same site live — on the page, in the fields your blocks declared.
$ primo push
✓ pushed 3 changed files · live
MIT · open source. The CLI is the same one your editors authenticate with — no separate API surface to learn. The same loop works from Claude Code and Codex.
Questions
Can I use Cursor as a CMS?
Yes. With Primo, Cursor’s agent edits your whole site as files in a workspace — components, content, schema, and routes — then primo push syncs it to a server where non-technical clients edit the same source visually. There’s no separate admin or API between Cursor and the content.
How does Cursor edit a Primo site?
You run primo pull <your-site-host> to bring the site down as files, then open that folder in Cursor. Blocks are Svelte components and content is YAML, so Cursor’s agent edits them like any codebase. primo dev previews changes locally; primo push deploys them.
How is this different from TinaCMS with Cursor?
Tina indexes your files into a GraphQL data layer and you instrument each field with useTina before it’s editable. Primo has neither — the editor generates itself from each block’s fields.yaml, and the editor and renderer read the same files and database rows directly. Less for the agent to wire up, and nothing between the code and the content. See the full Primo vs Tina breakdown.
Do my clients need Cursor to edit the site?
No. Cursor is how you build and change the site as code. After you push, your client edits on the rendered page in the browser — click and type — with no editor and no agent involved.
How does Cursor authenticate to push?
The CLI reads a PRIMO_TOKEN from your environment, which you generate per site in the admin. primo pull <host> clones the project and primo push uploads only changed files. It’s the same auth an editor uses — no separate API.
Build it with Cursor. Hand it to a human.
One command to spin up a workspace. Point Cursor at the repo, then hand your client the browser.
$ npx primo-cli init my-workspace
✓ workspace ready · server.yaml written
MIT · open source · free forever