**Version:** 2.0.0 **Updated:** 2026-06-30 **Freshly updated:** v2.0.0 wires in current Respira safety and precision. Pre-migration now inventories source pages with `respira_find_builder_targets`. Every write is preceded by a `respira_get_snapshot`, and the existing
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/migrate-elementor-to-bricks
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
**Version:** 2.0.0 **Updated:** 2026-06-30 **Freshly updated:** v2.0.0 wires in current Respira safety and precision. Pre-migration now inventories source pages with `respira_find_builder_targets`. Every write is preceded by a `respira_get_snapshot`, and the existing
# Migrate Elementor to Bricks
**Version:** 2.0.0
**Updated:** 2026-06-30
**Freshly updated:** v2.0.0 wires in current Respira safety and precision. Pre-migration now inventories source pages with `respira_find_builder_targets`. Every write is preceded by a `respira_get_snapshot`, and the existing draft-duplicate path is kept. After the first `respira_inject_builder_content`, validation issues (column widths, broken refs) are corrected surgically with `respira_find_element` + `respira_update_element` (and `respira_batch_update` for multi-element or multi-page fixes) instead of re-injecting whole pages. Snapshot restore and draft deletion are now explicit rollback paths. Reflects the current 16 supported builders.
Converts Elementor-built WordPress pages to Bricks Builder. Reads Elementor's JSON widget tree from post meta, maps each widget to its closest Bricks element equivalent, generates a migration plan for approval, and writes clean Bricks JSON to the target pages. Use this skill whenever someone wants to move from Elementor to Bricks, rebuild Elementor pages in Bricks, or switch page builders from Elementor to Bricks.
## What This Skill Does
Elementor and Bricks are both visual page builders, but they store content in fundamentally different formats — Elementor uses a nested JSON widget tree in `_elementor_data`, while Bricks uses a flat-ish JSON array in `_bricks_page_content_2`. This skill bridges that gap by reading every Elementor widget, understanding its purpose, and recreating it as the appropriate Bricks element. Both Elementor and Bricks are among the 16 page builders Respira reads and writes natively, so the extraction and injection run through the same builder-aware tooling Respira uses everywhere else.
**Handles:**
- Section/Column layouts → Bricks Section/Container elements
- Text Editor, Heading, Image, Video, Button widgets → native Bricks equivalents
- **Third-party Elementor addons** — Widgets from Essential Addons, JetElements, Crocoblock, PowerPack, etc. are flagged for manual migration. The skill cannot map proprietary addon widgets to Bricks equivalents automatically.
- **Elementor Pro dynamic tags** — Dynamic content (ACF fields, custom field displays, loop templates) require Bricks' own dynamic data system, which has different capabilities. These are flagged, not auto-converted.
- **Theme Builder templates** — Elementor's header/footer/archive/single templates use a different storage mechanism. This skill migrates page content, not theme builder templates.
- **Popup/modal content** — Elementor popups are stored separately and are not included in page migration.
- **WooCommerce widgets** — Elementor Pro's product grid, cart, checkout widgets need Bricks' WooCommerce elements configured separately.
- **Pixel-perfect recreation** — Bricks uses a different rendering engine. Spacing and alignment will be close but may need manual fine-tuning.
## Requirements
- Respira for WordPress plugin installed and connected
- MCP connection active (desktop or WebMCP)
- Elementor plugin active (to read source content)
- Bricks theme installed and active (to write target content)
- Read access to scan Elementor content
- Write access to create duplicates with Bricks content
## Trigger Phrase
- "migrate elementor to bricks"
## Alternative Triggers
- "convert elementor to bricks"
- "switch from elementor to bricks"
- "rebuild elementor pages in bricks"
- "move my site from elementor to bricks"
- "elementor to bricks migration"
## Source Builder: Elementor
Elementor stores page content in the `_elementor_data` post meta field as a JSON string. The structure is a nested tree:
- Elements use `name` (not widgetType): `section`, `container`, `heading`, `text-basic`, `image`, `button`, `video`, `icon`
- Parent-child relationships use `parent` field referencing parent `id`
- IDs are short alphanumeric strings (6 chars typical)
- Settings keys differ from Elementor (e.g., `tag` not `header_size`, `text` not `title`)
- Responsive settings use `_breakpoints` key within settings
Write Bricks content via `respira_inject_builder_content` with `builder=bricks`.
## Execution Workflow
### Phase 1: Pre-Migration Audit
1. Verify Respira + MCP connection via `respira_get_site_context`. If unavailable, stop and show setup guidance.
2. Confirm Elementor is active via `respira_list_plugins`.
3. Confirm Bricks theme is installed via `respira_get_site_context`.
4. Inventory and scope the source pages with `respira_find_builder_targets` (builder=elementor) — this gives a fast, ranked list of every Elementor-built page/post before you touch anything. Fall back to `respira_list_pages` / `respira_list_posts` + `respira_get_builder_info` to confirm builder per item where needed.
5. For each Elementor page, extract content via `respira_extract_builder_content` with `builder=elementor`
6. Build an inventory:
- Total pages/posts using Elementor
- Widget types used across the site (frequency count)
- Third-party addon widgets detected (flagged for manual handling)
- Global widgets referenced
- Dynamic tags usage
- Estimated migration complexity per page (simple/moderate/complex)
### Phase 2: Migration Plan
Present a clear migration plan:
```
## Elementor → Bricks Migration Plan
### Site Inventory
- Total Elementor pages: X
- Total widgets to convert: X
- Auto-convertible widgets: X (Y%)
- Manual attention needed: X (Y%)
### Widget Mapping Summary
| Elementor Widget | Bricks Element | Status |
|-----------------|----------------|--------|
| heading | heading | Auto |
| text-editor | text-basic | Auto |
| image | image | Auto |
| [addon widget] | — | Manual |
### Page-by-Page Plan
1. **[Page Title]** — X widgets, [simple/moderate/complex]
- Auto-convertible: X widgets
- Needs attention: [list any flagged widgets]
2. ...
### Flagged Items (Require Manual Work)
- [List of third-party widgets, dynamic tags, etc.]
```
Ask for confirmation:
> Ready to proceed? I'll create Bricks duplicates of each page — your original Elementor pages stay untouched.
> 1. Migrate all pages
> 2. Migrate specific pages (pick from list)
> 3. Start with a test page first
> 4. Just keep this plan as reference
### Phase 3: Page-by-Page Migration
For each approved page:
1. Read full Elementor content via `respira_extract_builder_content` with `builder=elementor`
2. Walk the Elementor JSON tree and map each widget:
4. Create a duplicate page via `respira_create_page_duplicate` or `respira_create_post_duplicate`
5. Before writing, take a snapshot with `respira_get_snapshot` so the duplicate's pre-write state can be restored if anything goes wrong
6. Write Bricks content to the duplicate via `respira_inject_builder_content` with `builder=bricks`
7. Surgical fix pass — if the injected page has validation issues (collapsed column widths, broken parent refs, a misconverted element), do not re-inject the whole page. Locate the specific element with `respira_find_element` and correct it with `respira_update_element`. For repeated fixes across many elements or several pages, batch them with `respira_batch_update`
8. Report status for this page before moving to next
### Phase 4: Post-Migration Verification
1. Summarize all migrations:
- Pages migrated successfully
- Total widgets converted
- Items flagged for manual attention
2. For each migrated page, provide:
- Link to the Bricks duplicate in wp-admin
- List of any flagged widgets or settings that need manual review
- Comparison notes (what was preserved vs. what needs adjustment)
3. Provide a post-migration checklist:
- [ ] Open each duplicate in Bricks editor and review layout
- [ ] Check responsive views (tablet, mobile)
- [ ] Verify all images and media load correctly
- [ ] Test all links and buttons
- [ ] Review flagged items and recreate manually
- [ ] Check forms and interactive elements
- [ ] Compare side-by-side with Elementor original
## Safety Model
- Read-only analysis first — full Elementor content scan before any changes
- Explicit user confirmation required before creating any duplicates
- Original Elementor pages are never modified or deleted
- All migrated content goes to draft duplicates only
- Never auto-publishes migrated pages
- Takes a `respira_get_snapshot` of each duplicate before any write, so its pre-write state can be restored
- Two explicit rollback paths: restore the snapshot with `respira_restore_snapshot`, or delete the draft duplicates entirely with `respira_delete_page` / `respira_delete_post`
- Surgical fixes (`respira_find_element` + `respira_update_element`, or `respira_batch_update`) replace whole-page re-injection, so corrections stay scoped and reversible
## Honest Disclaimer
This skill converts Elementor page content to Bricks Builder format and creates draft duplicates for review.
