Git-native edits
Aider commits each change as it goes, so every edit is a reviewable diff. A Primo site is a normal repo — pages, blocks, content, config — so it drops straight into that workflow.
Primo + Aider
Build and edit a website with Aider.
Pull your whole site down as files, point Aider at the repo, and let it edit anything — components, content, pages, routes — committing each change to git as it goes. 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.
Aider edits the site. Your client edits the same site.
Aider lives in your git repo — it reads the files, makes the edit, and commits it, so every change the agent makes is a reviewable diff. A Primo site is exactly that kind of repo: primo pull brings your entire site down as plain files. Blocks are Svelte components, content and config are YAML. Aider edits them like any other codebase, one clean commit at a time.
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 Aider 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. Aider 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 Aider just edited. One source of truth.
The loop with Aider
Four steps. The CLI is the real Primo CLI — primo pull, primo push. What’s Aider-specific is step three, where Aider edits and commits inside the repo.
Pull the site as files.
Brings your whole site into the repo — 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 repo and auto-imports your file changes so you see them as Aider edits.
$ primo dev
▸ dev server on http://localhost:5173 · watching files
Let Aider edit anything.
Run Aider in the repo and describe the change. It edits across the whole codebase — components, content, new pages — and commits each change to git. No fields to instrument first.
$ aider blocks/pricing/component.svelte pages/pricing.yaml
✎ edited 2 files · committed "redesign pricing"
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 2 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, Cursor, and Codex.
Questions
Can I use Aider as a CMS?
Yes. With Primo, Aider edits your whole site as files in a git repo — 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 Aider and the content.
How does Aider edit a Primo site?
You run primo pull <your-site-host> to bring the site down as files, then run Aider in that repo. Blocks are Svelte components and content is YAML, so Aider edits them like any codebase and commits each change to git. primo dev previews changes locally; primo push deploys them.
Does Aider's git workflow conflict with Primo?
No — they complement each other. Aider commits each edit to your repo’s git history, giving you reviewable diffs. primo push is a separate step that syncs the current files to the server. Your git history and your live site stay independent, so you can review and roll back locally before you ever push.
How is this different from TinaCMS with Aider?
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 Aider to edit the site?
No. Aider 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 agent and no git involved.
Build it with Aider. Hand it to a human.
One command to spin up a workspace. Point Aider 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