On a CMS with no undo, what you want from an agent is not confidence. It is intentions you can read before anything moves. That is the specific thing Grok Build does differently: launch it in plan mode and it writes out the whole pass, file by file, before it edits a thing. Which items, which fields, what kind of change. You read the plan the way you would read a contractor's quote, and nothing starts until you approve it.
Scratch supplies the other half: somewhere safe for the approved plan to run. Your Webflow collections come down as a folder on your laptop, one file per item, and Grok Build does 99% of the work there, in the copy. The last 1% stays with you. Every edit comes back as a word-level diff, you approve what ships, and Scratch publishes only those items through the Webflow CMS API. Two reads, one before the edits and one after, and the Designer never moves.
How it works
- Scratch pulls your collections into files. Every CMS item, page, and asset lands in a folder on your laptop, one file each, with an
AGENTS.mddescribing the layout, which Grok Build picks up automatically. Designer layout, components, and bindings never come down at all. - Grok Build plans, then edits.
cdinto the folder, rungrokin plan mode, and describe the job. Rewrite every excerpt to one sentence, fix the title case, backfill the missing meta descriptions. Read the plan, approve it, and Grok Build works the files, never the live CMS. - You review every diff and publish. Scratch shows each change beside the original, word by word. Approve what ships, and Scratch sends only those items back through the Webflow CMS API. What you do not approve stays local.
What people use it for
The jobs that pile up because the Webflow editor opens one item at a time:
- Rewrite every blog excerpt to a single tight sentence across the whole collection.
- Backfill SEO titles and meta descriptions on the case studies that shipped without them.
- Carry a rebrand through body copy, headings, and SEO fields in one planned pass.
- Split a big cleanup across parallel subagents, each in its own worktree, and review one queue in Scratch.
- Localize a collection into a second language, where Webflow exposes locales.
Plan a pass over ten items first. When the plan reads right, run the collection.
Why not an MCP server?
A Webflow MCP server wires the agent straight to your live CMS, publish step included. One confident pass ships across the collection, and Webflow gives you nothing to roll it back with. A plan you read in the terminal does not help if the writes still go straight to production.
Scratch moves the writes. Grok Build gets full read and write against a local copy, and what reaches Webflow is a separate, per-item decision that belongs to you. The plan gates the edits. The diff gates the publish. Both gates are yours.
What Grok Build edits in Webflow
- CMS collection items: rich-text, plain-text, slug, and custom fields
- Page metadata: title, slug, SEO and Open Graph
- Asset alt text
- Multi-locale content, where Webflow exposes it
Designer layout, components, bindings, and reference targets are never pulled into the folder. Ecommerce collections are out of scope. Validators flag length overruns, slug problems, and any field you tell them to watch, right next to the diff. The full field list is on Scratch for Webflow.
Questions people ask
Is this an MCP server or a native integration?
Neither. An MCP server bundles the publish step into the agent's connection. With Scratch, Grok Build edits a local copy, and publishing is a separate step you approve, one item at a time.
Will Grok Build touch my Designer layout?
No. It only ever sees content fields. Layout, components, bindings, and reference targets are never pulled into the folder, so there is nothing there for it to break.
Webflow has no undo. Am I stuck if a rewrite is wrong?
No. Scratch keeps the original beside every rewrite, and any published item can be rolled back per row, even though Webflow itself cannot do that. You decide which version stays.
What does plan mode actually gate?
The edits. Grok Build writes out the pass, file by file, before touching anything, so a misread instruction dies as a paragraph in a plan instead of as five hundred rewrites. The Scratch diff then gates the publish. A bad pass has to get through both of you.
Can it handle a big collection in one pass?
Yes. A 2 million token context lets Grok Build hold a large slice of the collection, plus your rules, while it works, which is what keeps item 400 consistent with item 4.
Do I need to be a developer?
You need to be comfortable in a terminal. If you would rather run the same loop in a desktop app, the Claude desktop app works identically against the same Scratch folder.
See it on your own collection
The fastest way to trust it is to watch it run on your content. Book a 30-minute demo on your Webflow CMS →, or try Scratch free and run the first pass yourself.