Studio
The web editor — a three-panel workspace where you (and an AI agent) edit your docs on a branch and publish as a commit or pull request.
The web editor — a three-panel workspace where you (and an AI agent) edit your docs on a branch and publish as a commit or pull request.
The editor is a three-panel workspace for editing a docs site directly in the dashboard:
an AI editing agent, the navigation tree, and a multi-modal MDX editor. It opens at
/:org/:site/editor (the Editor item in the rail, and Open editor on the site
overview).
The editor and the authoring MCP are the same write path, not two parallel ones — both edit one server-side draft buffer on a working branch and publish through one backend. Whatever the agent does, you can do by hand, and vice versa.
A read/write assistant. It can search and read your docs and edit them — ask it to “rewrite the intro” or “add an FAQ entry” and it writes to the same draft you see. When it finishes an edit, the editor pane refreshes to show the change. It never publishes unless you ask.
The agent panel is hidden by default so the page has room to write; open it with the Ask agent button (or ⌘I / Ctrl I) and close it from the button, the panel’s ✕, or the same shortcut. Your conversation is kept while it’s closed.
Your docs.json navigation, rendered from the draft of the current branch. Click any
page to load it into the editor.
Edit the page in Visual mode (WYSIWYG — the page rendered, editable in place) or Source mode (raw MDX), and use Diff to compare your draft against what’s published. Edits autosave to the draft buffer, and your chosen view stays put as you move between pages. Switching pages also saves your in-progress edit first, so a quick click away never loses what you just typed. Pages can be edited together, in real time — see Real-time collaboration.
Visual mode renders your real components, so the links in a page are real links — a markdown
link, or the href on a <Card>. Clicking one moves the editor to that page, the same as
clicking it in the navigation tree: your unsaved edit is written to the draft first, and you stay
in the editor.
Links are resolved against your site, not the dashboard, so /quickstart,
../guides/components, and /quickstart#install all land on the page a reader would get:
Loads in the editor. Root-absolute and relative paths both work, and a #fragment, a query
string, or a trailing .mdx is ignored when matching the page.
An https://, mailto:, or protocol-relative link opens in a new tab, so your editing
session is never replaced.
Nothing is followed — you get a “No page /… in this site” message. That’s a broken link in your docs, surfaced while you’re writing rather than after you publish.
A <Card href=…> wraps its body text in the link. Clicking that text puts the cursor in
it so you can edit; clicking anywhere else on the card follows the link.
The Preview tab renders the page through the same renderer that ships your docs — the same
MDX compilation, the same components (<Card>, <Tabs>, <Frame>, <HeroCard>…), the same
theme. So what you see in Preview is exactly what readers get: what you see is what ships.
Editing happens in Source (raw MDX), and that MDX string is exactly what gets committed — no conversion to a block model, no second source of truth. Git stays canonical. Preview reads your current draft, so unsaved-but-buffered edits appear the moment you switch to it.
The editor opens on your site’s deploy branch — the one marked Default in the branch switcher (top left). You edit it directly; the switcher also lists your open edit sessions and can create a new branch for changes you’d rather land through review.
Wherever you edit, your changes buffer server-side per branch — they never touch the live branch until you publish. Buffered edits persist across tabs, devices, and reloads, and the agent and you share that one buffer. A clean session that you haven’t typed into yet creates no branch and shows the live content as-is.
Nothing is live until you publish.
The Publish button carries the draft to Git. Its action follows the branch you’re on, and the caret menu lets you pick either mode explicitly:
Publish commits your edits straight onto the deploy branch. The normal sync then redeploys the site. This is the default when you’re editing the Default branch.
Publish commits to the working branch and opens a PR into the deploy branch — review before it goes live. Use Create new branch in the switcher when you want this flow.
The outcome — a pull-request link, a commit hash, or an error — appears as a toast that clears itself (and that you can dismiss).
If the deploy branch moved since you started editing, Publish stops with a conflict rather than clobbering it — re-check-out to pick up the latest, then publish again.
The editor is gated behind the editor.workspace feature (admin-only while it’s dogfooded).
Preview renders your draft through the real renderer on the fly; publishing surfaces the change
through the normal deploy (or the PR).