The loop you already trust
Grok Build lives in your terminal. You point it at a directory, hand it a prompt, and it plans the change, edits the files, and works against the output until the task is done. You read the plan, you read the diff, nothing lands until you approve it. That is how you already work on code.
Your content deserves the same loop. But your product copy lives in Shopify, your posts in WordPress, your docs in Notion. Grok Build can't reach any of it, and there's no diff to read before a change goes live.
What Scratch does
Scratch pulls your CMS into a folder on your machine. One JSON file per record. Prose fields (bodies, descriptions, alt text) sit alongside structured fields (IDs, tags, slugs, dates) in the same file. Shopify, WordPress, HubSpot, Notion, the rest.
Now your content is the thing Grok Build is built for: files in a directory. cd into the Scratch project folder, run grok, and it reads, edits, and writes the changes back to the files. Scratch shows you every change as a per-record diff, the way you'd review a pull request, and publishes only what you approve back to the CMS. The agent edits. You keep the merge button.
Plan first, then edit at scale
Grok Build's defaults map cleanly onto a Scratch folder.
Plan mode. For anything past a one-record tweak, launch in plan mode. Grok Build writes out a structured plan, file by file, before it touches anything. You read the plan against your catalog, approve it, and only then does it start editing. That plan, review, approve step sits in front of the Scratch review queue, so a bad instruction gets caught before it ever becomes a diff.
Parallel subagents. Grok Build can split a job across subagents that run at the same time, each in its own Git worktree. A tone pass on descriptions, an alt-text fix, a tag cleanup, all moving over the same folder at once. Scratch still surfaces every change as one reviewable queue.
Room for the whole catalog. A 2 million token context window means Grok Build can hold a large slice of records, plus your rules and conventions, in a single pass. Drop an AGENTS.md in the Scratch folder and it picks up your tone, your tags, and your length caps automatically.
For scripted runs, grok -p "..." works headless and returns structured output, so a nightly refresh over a Scratch folder is one line in a cron job.
What stays safe
Files are local. Grok Build reads and writes files in your Scratch project folder; it never touches your CMS. Nothing leaves your machine until you click publish in Scratch, per record.
Validators (optional) are AI-authored Python rules that fail length-cap and formatting regressions before a diff ever reaches your eyes. Per-row approve. Per-row rollback. The original version sits next to the dirty one until you decide.
Bring your own xAI account. Scratch holds no Grok credentials and runs no model. You sign into Grok Build the way you already do.
What this is not
Not an xAI integration. Not a "Grok for CMS" wrapper that pushes through an API on Grok's behalf. Scratch is the file substrate; Grok Build is the agent you brought. The shape (pull, edit, diff, ship) survives whichever Grok model and version you run this quarter.
Browse the skills below for prompts that work end-to-end with Grok Build.