Migrate a Bricks site to Etch — page by page, by prompt

The job

Switching builders used to mean rebuilding every page by hand — weeks of unbillable work, and the reason most agencies never leave a builder they've outgrown. With NibWP the agent reads each Bricks page as structure (real elements, global classes, query loops), then rebuilds it as native Etch components mapped to the same ACSS tokens.

You migrate one page at a time, approve each result, and keep both builders running side by side until the last page is moved. Nothing is flattened to HTML; the output opens and edits in Etch like it was built there.

The prompts, exactly as you'd type them

Plain English is the interface. These are real prompts for this job — copy them, swap in your own names, and adjust in conversation.

Scope the migration

List every page and template built with Bricks on this site, with element counts.
Group them: simple pages, pages with query loops, templates (header/footer).

Migrate one page

Convert the /about/ page from Bricks to Etch.
Keep the structure and the ACSS tokens. Reuse existing Etch components where they match.
Create it as a draft — don't touch the live page.

Migrate the chrome, then batch

Rebuild the Bricks header and footer as Etch components and assign them.
Then convert the remaining simple pages one by one, showing me a plan per page.

The process — what actually happens

Every write follows the same shape: the agent reads before it writes, shows you a plan, and nothing lands without your approval. The audit log records every call.

1. The agent reads the Bricks element tree and global classes through the Bricks integration — structure, not screenshots.
2. The EtchWP Pro Skill converts each page into validated Etch components: BEM checked, tokens mapped, element whitelist enforced on the server.
3. You get a plan per page — what becomes a component, which tokens are used — and approve before anything is written.
4. New pages land as drafts; the live Bricks pages stay untouched until you swap.
5. Every write is in the audit log; a bad page is one revert away.

The tools this uses

This showcase runs on the Bricks integration (reading), the Etch integration (writing) and the EtchWP Pro Skill (validated conversion):

• nibwp/bricks-* — read pages, elements, global classes and query loops
• nibwp/etchwp-pro-html-to-component — validated Etch output on your tokens
• nibwp/etch-create / nibwp/etch-update — components, styles, page assembly
• Automatic.css read — so both builders speak the same tokens during the transition

The outcome

A 20-page Bricks site moves in days, not weeks — most of it review time. The deliverable is a native Etch site your team edits in the builder, with the design system intact.

Related solutions

See also Elementor → Bricks and fixing 404s after a migration.