@respira/wordpress-mcp-server 8.2.2 → 8.2.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@respira/wordpress-mcp-server",
-  "version": "8.2.2",
+  "version": "8.2.4",
   "mcpName": "io.github.webmyc/respira-wordpress",
   "description": "WordPress MCP server with MCP 2026-07-28 and legacy-client support. 198 tools, 303 with WooCommerce, across 17 page builders and the Site Editor.",
   "main": "dist/index.js",

package/skills/design-system-synthesizer/SKILL.md

@@ -1,8 +1,20 @@
+---
+name: design-system-synthesizer
+description: "Use when the user says 'build a design system for my site', 'extract design tokens', 'capture my brand', or 'build my style guide', or after a rebrand. Reads representative pages, theme files, and media to extract logo, colors, typography, spacing, and components, then writes a visible style-guide page."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 1.3.0
+  mcp-server: respira-wordpress
+  category: intelligence
+---
+
 # Design System Synthesizer
 
-**Version:** 1.2.0
-**Updated:** 2026-06-30
-**Freshly updated:** v1.2.0 makes the synthesis safe and source-traceable end to end. Reads tokens from the actual builder content (`respira_extract_builder_content`) and theme files (`respira_read_theme_file` on style.css / theme.json) rather than guessing. Persists the design_system JSON via `respira_get_option` (diff first) + `respira_update_option`, and takes a `respira_get_snapshot` checkpoint before building the visible style-guide page with `respira_build_page` so the write is explicitly reversible (restore the snapshot, delete the draft). Applying tokens to a builder's global colors and typography is described in plain words since there is no confirmed MCP tool name for that path yet.
+**Version:** 1.3.0
+**Updated:** 2026-08-04
+**Freshly updated:** v1.3.0 catches up with the design-token surface. Builder global palettes and typography are now written through first-class token tools (`respira_list_design_tokens`, `respira_create_design_token`, `respira_update_design_token`, `respira_delete_design_token`), replacing v1.2.0's describe-it-in-plain-words guidance. HTML/design conversions register the colors and typography they carry as named tokens in the builder's own global styles automatically, and converted pages reference those tokens instead of carrying value copies — so the synthesizer reads what is already registered before synthesizing, reuses those names instead of re-inlining values, and reports token registration in its summary.
 **Category:** intelligence
 **Status:** stable
 **Requires:** Respira for WordPress plugin 7.1+ + MCP server
@@ -316,6 +328,8 @@ After page creation, output:
 
 **Human view:** {page_url} · status: private (editors only)
 
+**Builder tokens:** {n} tokens registered or aligned in {builder}'s global styles (`respira_list_design_tokens` to inspect), or "none — {builder} has no global token store"
+
 **Open it now:** [{page_title} in the editor]({builder_edit_url})
 
 **Promote to public:** call `respira_update_page(id={page_id}, status='publish')` if you want this visible on your site as a /design-system/ landing.
@@ -338,13 +352,15 @@ Once persisted, future skills (Page Template Library, Brand Voice Synthesizer, f
 
 ### Applying tokens to the builder's own global colors / typography
 
-Some builders (Bricks, Elementor, Divi, Oxygen) keep their own global color palette and global typography settings, separate from the page-level styles. Pushing the synthesized tokens into those global settings means future hand-edits in the builder also snap to the brand.
+Builders with a global store — the block editor family, Elementor, Divi, Bricks, Beaver, Breakdance, Oxygen — keep their own global color palette and typography settings, separate from the page-level styles. Pushing the synthesized tokens into that store means future hand-edits in the builder also snap to the brand.
 
-There is **no confirmed MCP tool name** for writing a builder's global palette today, so do not invent one (e.g. do not assume a `respira_*` design-system tool exists). The real path is the plugin's design-token import layer on the WordPress side (`includes/bricks-intelligence/class-design-token-import.php` and the design-system REST handler in `includes/class-respira-bricks-tools.php`), reached through the site, not a named MCP tool. In practice:
+That path is now first-class: `respira_list_design_tokens`, `respira_create_design_token`, `respira_update_design_token`, `respira_delete_design_token`. And HTML/design conversions register the colors and typography they carry as named tokens in that store automatically, with converted pages referencing the tokens instead of carrying value copies. In practice:
 
-- Persist the `respira_design_system` option (Step 8) — that is the canonical, tool-confirmed write.
-- Build the visible style-guide page (Step 9) so the tokens are visible and editable.
-- For pushing tokens into a builder's *global* palette/typography, describe the change to the user in plain words and let them apply it (or trigger the plugin's design-token import). Only reference a builder-token tool by name once you have grepped `includes/` and confirmed the exact registered name.
+- Start with `respira_list_design_tokens` — conversions may already have registered tokens on this site. Reuse those names rather than re-inlining raw values or inventing a parallel palette.
+- Persist the `respira_design_system` option (Step 8) — that stays the canonical machine artifact.
+- With the user's confirmation, register or align the synthesized tokens in the builder's global store via `respira_create_design_token` / `respira_update_design_token`.
+- Builders without a global store (Brizy, Thrive Architect, WPBakery, Visual Composer, Flatsome, SeedProd) register nothing — page-level values are the only surface there; say so instead of pretending.
+- Mention the token registration — names and counts — in the completion summary.
 
 This is the foundation. Every other content skill stands on it.
 
@@ -378,7 +394,12 @@ This is the foundation. Every other content skill stands on it.
 - `respira_build_page` — render the visible style-guide page in the active builder
 - `respira_restore_snapshot` + `respira_delete_page` — explicit rollback of the build
 
-Applying tokens to a builder's *global* colors/typography has **no confirmed MCP tool name** — describe it in plain words (see "Applying tokens to the builder's own global colors / typography" above). Never invent a builder-token tool name.
+**Builder global tokens**
+- `respira_list_design_tokens` — see what conversions already registered; always read before writing
+- `respira_create_design_token` / `respira_update_design_token` — register or align the synthesized tokens in the builder's global store (with user confirmation)
+- `respira_delete_design_token` — remove a token the user has retired
+
+No-store builders (Brizy, Thrive Architect, WPBakery, Visual Composer, Flatsome, SeedProd) have no global surface to write; skip token registration there and say so.
 
 ---
 

package/skills/design-system-synthesizer/metadata.json

@@ -12,8 +12,8 @@
   "requires_accessibility_addon": false,
   "is_read_only": false,
   "is_duplicate_first": false,
-  "version": "1.1.0",
-  "last_updated": "2026-05-24",
+  "version": "1.3.0",
+  "last_updated": "2026-08-04",
   "tools_used": [
     "respira_get_active_site",
     "respira_get_site_context",
@@ -26,7 +26,10 @@
     "respira_get_builder_info",
     "respira_get_builder_inline_schemas",
     "respira_build_page",
-    "respira_update_page"
+    "respira_update_page",
+    "respira_list_design_tokens",
+    "respira_create_design_token",
+    "respira_update_design_token"
   ],
   "detects": [
     "logo_url",

package/skills/figma-to-elementor/SKILL.md

@@ -1,3 +1,15 @@
+---
+name: figma-to-elementor
+description: "Use when the user says 'figma to elementor', 'build this figma design in elementor', or hands over a Figma frame to rebuild in WordPress. Maps the Figma node tree to Elementor widgets and containers and writes clean Elementor JSON into a draft duplicate, so nothing live is touched."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 1.1.0
+  mcp-server: respira-wordpress
+  category: migration
+---
+
 # Figma to Elementor
 
 Rebuilds a Figma frame as a real, editable Elementor page on your WordPress site. Reads the Figma node tree (layers, auto-layout, text, colors, images), maps each node to its closest Elementor widget or container, generates a build plan for approval, and writes clean Elementor JSON to a draft duplicate so nothing live is touched. Use this skill whenever someone wants to turn a Figma design into an Elementor page, build a Figma mockup in Elementor, or hand a design off to WordPress without rebuilding it by hand.
@@ -99,7 +111,7 @@ Respira writes Elementor as a simplified tree of `{ type, widget, settings, elem
 
 **Images:** collect IMAGE fills, export from Figma, sideload with `respira_sideload_image`, and set the resulting media on the Elementor image widget/background.
 
-**Design system:** map the frame's distinct fill colors to Elementor global colors (primary/secondary/accent/text) so later edits stay on-brand.
+**Design system:** map the frame's distinct fill colors to Elementor global colors (primary/secondary/accent/text) so later edits stay on-brand. Conversion writes register these colors and the frame's typography as named design tokens in Elementor's own global styles, and the built page references the tokens instead of carrying value copies — when refining afterwards, reuse the registered tokens (`respira_list_design_tokens` shows them) rather than re-inlining raw values.
 
 ## Execution Workflow
 
@@ -130,7 +142,7 @@ For the approved frame:
 6. Report status for the frame before moving on.
 
 ### Phase 4: Verify
-1. Summarize: sections/widgets built, images imported, items flagged.
+1. Summarize: sections/widgets built, images imported, design tokens registered in Elementor's global styles (names and counts), items flagged.
 2. Provide the wp-admin/Elementor editor link to the draft.
 3. Give a checklist: open in the Elementor editor, check tablet/mobile, confirm images load, test links/buttons, review flagged items, compare against the Figma frame.
 

package/skills/html-to-bricks/SKILL.md

@@ -1,7 +1,19 @@
+---
+name: html-to-bricks
+description: "Use when the user says 'convert this html to bricks' or 'paste html into bricks', or has a Webflow, Framer, CodePen, or old static export to bring into a Bricks site. Converts raw HTML and CSS into native Bricks elements, mapping colors, type, and spacing to design tokens, plus ACSS classes when installed."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 1.1.0
+  mcp-server: respira-wordpress
+  category: migration
+---
+
 # HTML to Bricks Builder
 
-**Version:** 1.0.0
-**Updated:** 2026-05-24
+**Version:** 1.1.0
+**Updated:** 2026-08-04
 **Category:** migration
 **Status:** stable
 **Requires:** Respira for WordPress plugin 7.1+ + Bricks Builder active + MCP server
@@ -71,6 +83,8 @@ Call `respira_convert_html_to_builder` with `builder=bricks`, the HTML, the CSS,
 
 The MCP tool returns a Bricks element tree. Each element has a `name` (Bricks element type — `section`, `block`, `container`, `heading`, `text-basic`, `button`, `image`, etc.) and `settings` matching the Bricks schema.
 
+The conversion also registers the colors and typography it carries as named design tokens in Bricks' own global styles, and the converted elements reference those tokens instead of carrying value copies. When refining afterwards, reuse the registered tokens (`respira_list_design_tokens` shows them) rather than re-inlining raw hex values or font stacks — and mention the registration, token names and counts, when you report the conversion done.
+
 ### Step 6 — Map raw values to design system tokens
 
 For each element in the tree:

package/skills/html-to-bricks/metadata.json

@@ -12,8 +12,8 @@
   "requires_accessibility_addon": false,
   "is_read_only": false,
   "is_duplicate_first": true,
-  "version": "1.0.0",
-  "last_updated": "2026-05-24",
+  "version": "1.1.0",
+  "last_updated": "2026-08-04",
   "tools_used": [
     "respira_get_active_site",
     "respira_get_builder_info",
@@ -21,7 +21,8 @@
     "respira_convert_html_to_builder",
     "respira_build_page",
     "respira_create_page_duplicate",
-    "respira_inject_builder_content"
+    "respira_inject_builder_content",
+    "respira_list_design_tokens"
   ],
   "detects": [
     "active_bricks_version",

package/skills/migrate-beaver-builder-to-bricks/SKILL.md

@@ -1,8 +1,20 @@
+---
+name: migrate-beaver-builder-to-bricks
+description: "Use when the user says 'migrate beaver builder to bricks', 'convert bb to bricks', or 'replace beaver builder with bricks'. Reads the Beaver Builder flat node map, maps each module to its Bricks element, and creates draft duplicates for review."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 2.1.0
+  mcp-server: respira-wordpress
+  category: migration
+---
+
 # Migrate Beaver Builder 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 (collapsed column widths from the row/column-to-container translation, broken parent refs, a misconverted module) 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.
+**Version:** 2.1.0
+**Updated:** 2026-08-04
+**Freshly updated:** v2.1.0 adds design-token awareness: conversion writes now register the colors and typography they carry as named design tokens in Bricks' own global styles, and converted pages reference those tokens instead of carrying value copies. Reuse registered tokens instead of re-inlining raw values, and report the registration in the migration summary.
 
 Full-site migration from Beaver Builder to Bricks Builder. Audits every Beaver Builder page, maps modules to their Bricks equivalents, builds a migration plan for approval, and executes page-by-page conversion into Bricks' JSON format — all through duplicates so your live site stays untouched. Use this skill whenever someone mentions migrating from Beaver Builder to Bricks, switching from BB to Bricks, converting Beaver Builder pages to Bricks, or replacing Beaver Builder with Bricks.
 
@@ -159,6 +171,7 @@ For each approved page:
 ### Phase 4: Post-Migration Verification
 
 1. Summarize all migrated pages with status:
+   - Design tokens registered in Bricks' global styles (token names and counts)
    - Clean migrations (no issues)
    - Migrations with warnings (flagged items needing review)
    - Failed migrations (if any)
@@ -172,6 +185,10 @@ For each approved page:
    - How to preview Bricks pages
    - How to delete duplicates if not wanted
 
+## Design Tokens
+
+Conversion writes now register the colors and typography they carry as named design tokens in Bricks' own global styles, and the converted pages reference those tokens instead of carrying value copies. When fixing or extending a migrated page, reuse the registered tokens (`respira_list_design_tokens` shows them) rather than re-inlining raw hex values or font stacks. And say so when you finish: the migration summary should name the tokens that were registered and note that migrated pages reference them.
+
 ## Safety Model
 
 - Read-only analysis first — full Beaver Builder content audit before any changes

package/skills/migrate-beaver-builder-to-gutenberg/SKILL.md

@@ -1,8 +1,20 @@
+---
+name: migrate-beaver-builder-to-gutenberg
+description: "Use when the user says 'migrate beaver builder to gutenberg', 'convert beaver builder to blocks', or 'move beaver builder to the block editor'. Reads the Beaver Builder flat node map, maps modules to core blocks, and creates draft duplicates for review."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 2.1.0
+  mcp-server: respira-wordpress
+  category: migration
+---
+
 # Migrate Beaver Builder to Gutenberg
 
-**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 initial block-markup write (`respira_update_page` / `respira_update_post`), validation issues (collapsed column widths, malformed block markup, a misconverted module) are corrected surgically with `respira_find_element` + `respira_update_element` (and `respira_batch_update` for multi-block or multi-page fixes) instead of rewriting whole pages. Snapshot restore and draft deletion are now explicit rollback paths. Reflects the current 16 supported builders.
+**Version:** 2.1.0
+**Updated:** 2026-08-04
+**Freshly updated:** v2.1.0 adds design-token awareness: conversion writes now register the colors and typography they carry as named design tokens in the block editor's own global styles, and converted pages reference those tokens instead of carrying value copies. Reuse registered tokens instead of re-inlining raw values, and report the registration in the migration summary.
 
 Full-site migration from Beaver Builder to the WordPress block editor (Gutenberg). Audits every Beaver Builder page, maps modules to their Gutenberg block equivalents, builds a migration plan for approval, and executes page-by-page conversion into native block markup — all through duplicates so your live site stays untouched. Use this skill whenever someone mentions migrating from Beaver Builder to Gutenberg, switching from Beaver Builder to blocks, converting Beaver Builder pages to the block editor, or moving away from Beaver Builder to native WordPress.
 
@@ -156,6 +168,7 @@ For each approved page:
 ### Phase 4: Post-Migration Verification
 
 1. Summarize all migrated pages with status:
+   - Design tokens registered in the block editor's global styles (token names and counts)
    - Clean migrations (no issues)
    - Migrations with warnings (flagged items needing review)
    - Failed migrations (if any)
@@ -169,6 +182,10 @@ For each approved page:
    - How to preview pages in the block editor
    - How to delete duplicates if not wanted
 
+## Design Tokens
+
+Conversion writes now register the colors and typography they carry as named design tokens in the block editor's own global styles, and the converted pages reference those tokens instead of carrying value copies. When fixing or extending a migrated page, reuse the registered tokens (`respira_list_design_tokens` shows them) rather than re-inlining raw hex values or font stacks. And say so when you finish: the migration summary should name the tokens that were registered and note that migrated pages reference them.
+
 ## Safety Model
 
 - Read-only analysis first — full Beaver Builder content audit before any changes

package/skills/migrate-brizy-to-gutenberg/SKILL.md

@@ -1,8 +1,20 @@
+---
+name: migrate-brizy-to-gutenberg
+description: "Use when the user says 'migrate brizy to gutenberg', 'convert brizy to blocks', or 'replace brizy with native wordpress'. Parses the Brizy JSON data, maps elements to core blocks, and creates draft duplicates for review."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 2.1.0
+  mcp-server: respira-wordpress
+  category: migration
+---
+
 # Migrate Brizy to Gutenberg
 
-**Version:** 2.0.0
-**Updated:** 2026-06-30
-**Freshly updated:** v2.0.0 weaves in the current Respira safety and precision flow — `respira_find_builder_targets` to inventory and scope source pages up front, a `respira_get_snapshot` checkpoint before any write, and surgical fixes via `respira_find_element` + `respira_update_element` (and `respira_batch_update` for multi-element or multi-page corrections) instead of rewriting whole pages. Rollback is now explicit (restore the snapshot, delete the draft duplicates). Reflects the current 16 supported builders.
+**Version:** 2.1.0
+**Updated:** 2026-08-04
+**Freshly updated:** v2.1.0 adds design-token awareness: conversion writes now register the colors and typography they carry as named design tokens in the block editor's own global styles, and converted pages reference those tokens instead of carrying value copies. Reuse registered tokens instead of re-inlining raw values, and report the registration in the migration summary.
 
 Full-site migration from Brizy Builder to the WordPress block editor (Gutenberg). Audits every Brizy-built page, maps components to their Gutenberg block equivalents, builds a migration plan for approval, and executes page-by-page conversion into native block markup — all through duplicates so your live site stays untouched. Use this skill whenever someone mentions migrating from Brizy to Gutenberg, switching from Brizy to blocks, converting Brizy pages to the block editor, or moving away from Brizy to native WordPress.
 
@@ -158,6 +170,7 @@ For each approved page:
 ### Phase 4: Post-Migration Verification
 
 1. Summarize all migrated pages with status:
+   - Design tokens registered in the block editor's global styles (token names and counts)
    - Clean migrations (no issues)
    - Migrations with warnings (flagged items needing review)
    - Failed migrations (if any)
@@ -171,6 +184,10 @@ For each approved page:
    - How to preview pages in the block editor
    - How to delete duplicates if not wanted
 
+## Design Tokens
+
+Conversion writes now register the colors and typography they carry as named design tokens in the block editor's own global styles, and the converted pages reference those tokens instead of carrying value copies. When fixing or extending a migrated page, reuse the registered tokens (`respira_list_design_tokens` shows them) rather than re-inlining raw hex values or font stacks. And say so when you finish: the migration summary should name the tokens that were registered and note that migrated pages reference them.
+
 ## Safety Model
 
 - Read-only analysis first — full Brizy content audit before any changes

package/skills/migrate-divi-to-breakdance/SKILL.md

@@ -1,8 +1,20 @@
+---
+name: migrate-divi-to-breakdance
+description: "Use when the user says 'migrate divi to breakdance', 'convert divi to breakdance', or 'rebuild divi pages in breakdance'. Parses Divi shortcodes, maps modules to Breakdance elements, and creates draft duplicates for review."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 2.1.0
+  mcp-server: respira-wordpress
+  category: migration
+---
+
 # Migrate Divi to Breakdance
 
-**Version:** 2.0.0
-**Updated:** 2026-06-30
-**Freshly updated:** v2.0.0 weaves in the current Respira safety and precision flow — `respira_find_builder_targets` to inventory and scope the Divi source pages up front, a `respira_get_snapshot` checkpoint before any write, and surgical fixes via `respira_find_element` + `respira_update_element` (and `respira_batch_update` for multi-element or multi-page corrections) instead of re-injecting whole pages. Rollback is now explicit (restore the snapshot, delete the draft duplicates). Reflects the current 16 supported builders.
+**Version:** 2.1.0
+**Updated:** 2026-08-04
+**Freshly updated:** v2.1.0 adds design-token awareness: conversion writes now register the colors and typography they carry as named design tokens in Breakdance's own global styles, and converted pages reference those tokens instead of carrying value copies. Reuse registered tokens instead of re-inlining raw values, and report the registration in the migration summary.
 
 Converts Divi-built WordPress pages to Breakdance Builder. Parses Divi's shortcode-based content from post_content, maps each module to its Breakdance element equivalent, generates a migration plan for approval, and writes Breakdance content to the target pages. Use this skill whenever someone wants to move from Divi to Breakdance, switch builders from Divi to Breakdance, or rebuild Divi pages in Breakdance.
 
@@ -213,6 +225,7 @@ For each approved page:
 ### Phase 4: Post-Migration Verification
 
 1. Summarize migrations:
+   - Design tokens registered in Breakdance's global styles (token names and counts)
    - Pages migrated, elements created, items flagged
 2. For each migrated page:
    - Link to Breakdance editor
@@ -231,6 +244,10 @@ For each approved page:
    - [ ] Compare with Divi original
    - [ ] Check for Divi shortcode remnants
 
+## Design Tokens
+
+Conversion writes now register the colors and typography they carry as named design tokens in Breakdance's own global styles, and the converted pages reference those tokens instead of carrying value copies. When fixing or extending a migrated page, reuse the registered tokens (`respira_list_design_tokens` shows them) rather than re-inlining raw hex values or font stacks. And say so when you finish: the migration summary should name the tokens that were registered and note that migrated pages reference them.
+
 ## Safety Model
 
 - Read-only analysis first — full content scan before any changes

package/skills/migrate-divi-to-bricks/SKILL.md

@@ -1,8 +1,20 @@
+---
+name: migrate-divi-to-bricks
+description: "Use when the user says 'migrate divi to bricks', 'convert divi to bricks', or 'rebuild divi pages in bricks'. Parses Divi shortcode content, maps modules to Bricks elements, and generates draft duplicates for review."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 2.1.0
+  mcp-server: respira-wordpress
+  category: migration
+---
+
 # Migrate Divi to Bricks
 
-**Version:** 2.0.0
-**Updated:** 2026-06-30
-**Freshly updated:** v2.0.0 weaves in the current Respira safety and precision flow — `respira_find_builder_targets` to inventory and scope the Divi source pages up front, a `respira_get_snapshot` checkpoint before any write, and surgical fixes via `respira_find_element` + `respira_update_element` (and `respira_batch_update` for multi-element or multi-page corrections) instead of re-injecting whole pages. Rollback is now explicit (restore the snapshot, delete the draft duplicates). Reflects the current 16 supported builders.
+**Version:** 2.1.0
+**Updated:** 2026-08-04
+**Freshly updated:** v2.1.0 adds design-token awareness: conversion writes now register the colors and typography they carry as named design tokens in Bricks' own global styles, and converted pages reference those tokens instead of carrying value copies. Reuse registered tokens instead of re-inlining raw values, and report the registration in the migration summary.
 
 Converts Divi-built WordPress pages to Bricks Builder. Parses Divi's shortcode-based content from post_content, maps each module to its 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 Divi to Bricks, replace the Divi Builder with Bricks, or rebuild Divi pages in Bricks.
 
@@ -223,6 +235,7 @@ For each approved page:
 ### Phase 4: Post-Migration Verification
 
 1. Summarize migrations:
+   - Design tokens registered in Bricks' global styles (token names and counts)
    - Pages migrated, elements created, items flagged
 2. For each migrated page:
    - Link to Bricks editor
@@ -240,6 +253,10 @@ For each approved page:
    - [ ] Compare with Divi original
    - [ ] Check for any Divi shortcode remnants
 
+## Design Tokens
+
+Conversion writes now register the colors and typography they carry as named design tokens in Bricks' own global styles, and the converted pages reference those tokens instead of carrying value copies. When fixing or extending a migrated page, reuse the registered tokens (`respira_list_design_tokens` shows them) rather than re-inlining raw hex values or font stacks. And say so when you finish: the migration summary should name the tokens that were registered and note that migrated pages reference them.
+
 ## Safety Model
 
 - Read-only analysis first — full content scan before any changes

package/skills/migrate-divi-to-gutenberg/SKILL.md

@@ -1,8 +1,20 @@
+---
+name: migrate-divi-to-gutenberg
+description: "Use when the user says 'migrate divi to gutenberg', 'convert divi to blocks', 'get off divi', or 'decommission divi'. Parses Divi shortcodes, maps modules to core blocks, and creates draft duplicates for review."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 2.1.0
+  mcp-server: respira-wordpress
+  category: migration
+---
+
 # Migrate Divi to Gutenberg
 
-**Version:** 2.0.0
-**Updated:** 2026-06-30
-**Freshly updated:** v2.0.0 weaves in the current Respira safety and precision flow — `respira_find_builder_targets` to inventory and scope the Divi source pages up front, a `respira_get_snapshot` checkpoint before any write, and surgical fixes via `respira_find_element` + `respira_update_element` (and `respira_batch_update` for multi-block or multi-page corrections) instead of rewriting whole pages. Rollback is now explicit (restore the snapshot, delete the draft duplicates). Reflects the current 16 supported builders.
+**Version:** 2.1.0
+**Updated:** 2026-08-04
+**Freshly updated:** v2.1.0 adds design-token awareness: conversion writes now register the colors and typography they carry as named design tokens in the block editor's own global styles, and converted pages reference those tokens instead of carrying value copies. Reuse registered tokens instead of re-inlining raw values, and report the registration in the migration summary.
 
 Converts Divi-built WordPress pages to native Gutenberg blocks. Parses Divi's shortcode-based content from post_content, maps each module to its closest core block equivalent, generates a migration plan for approval, and writes clean block markup to the target pages. Use this skill whenever someone wants to move from Divi to Gutenberg, eliminate the Divi dependency, switch to native blocks, or simplify their WordPress stack by removing Elegant Themes' builder.
 
@@ -231,6 +243,7 @@ For each approved page:
 ### Phase 4: Post-Migration Verification
 
 1. Summarize all migrations
+   - Design tokens registered in the block editor's global styles (token names and counts)
 2. For each migrated page:
    - Link to edit in Gutenberg
    - Flagged items
@@ -246,6 +259,10 @@ For each approved page:
    - [ ] Check page speed improvement
    - [ ] Review for Divi shortcode remnants in content
 
+## Design Tokens
+
+Conversion writes now register the colors and typography they carry as named design tokens in the block editor's own global styles, and the converted pages reference those tokens instead of carrying value copies. When fixing or extending a migrated page, reuse the registered tokens (`respira_list_design_tokens` shows them) rather than re-inlining raw hex values or font stacks. And say so when you finish: the migration summary should name the tokens that were registered and note that migrated pages reference them.
+
 ## Safety Model
 
 - Read-only analysis first — full content scan before any changes

package/skills/migrate-elementor-to-breakdance/SKILL.md

@@ -1,14 +1,26 @@
+---
+name: migrate-elementor-to-breakdance
+description: "Use when the user says 'migrate elementor to breakdance', 'convert elementor to breakdance', or 'rebuild elementor pages in breakdance'. Maps Elementor widgets to Breakdance elements and creates draft duplicates for review."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 2.1.0
+  mcp-server: respira-wordpress
+  category: migration
+---
+
 # Migrate Elementor to Breakdance
 
-**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 initial `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.
+**Version:** 2.1.0
+**Updated:** 2026-08-04
+**Freshly updated:** v2.1.0 adds design-token awareness: conversion writes now register the colors and typography they carry as named design tokens in Breakdance's own global styles, and converted pages reference those tokens instead of carrying value copies. Reuse registered tokens instead of re-inlining raw values, and report the registration in the migration summary.
 
 Converts Elementor-built WordPress pages to Breakdance Builder. Reads Elementor's JSON widget tree from post meta, maps each widget to its Breakdance element equivalent, generates a migration plan for approval, and writes Breakdance content to the target pages. Use this skill whenever someone wants to move from Elementor to Breakdance, switch builders from Elementor to Breakdance, or rebuild Elementor pages in Breakdance.
 
 ## What This Skill Does
 
-Breakdance is a newer builder created by the Oxygen team with a focus on clean output and familiar visual editing. Both Elementor and Breakdance are widget/element-based builders, making this a relatively smooth migration path. The main challenge is mapping Elementor's JSON widget tree (`_elementor_data`) to Breakdance's post meta format, translating settings names, and handling the structural differences in how each builder handles sections, columns, and responsive design. Both sit among the 17 page builders Respira reads and writes natively, so extraction and injection run through the same builder-aware tooling Respira uses everywhere else.
+Breakdance is a newer builder created by the Oxygen team with a focus on clean output and familiar visual editing. Both Elementor and Breakdance are widget/element-based builders, making this a relatively smooth migration path. The main challenge is mapping Elementor's JSON widget tree (`_elementor_data`) to Breakdance's post meta format, translating settings names, and handling the structural differences in how each builder handles sections, columns, and responsive design. Both sit among the 16 page builders Respira reads and writes natively, so extraction and injection run through the same builder-aware tooling Respira uses everywhere else.
 
 **Handles:**
 - Section/Column layouts → Breakdance Section/Div elements
@@ -189,6 +201,7 @@ For each approved page:
 ### Phase 4: Post-Migration Verification
 
 1. Summarize all migrations:
+   - Design tokens registered in Breakdance's global styles (token names and counts)
    - Pages migrated, widgets converted, items flagged
 2. For each migrated page:
    - Link to edit in Breakdance
@@ -204,6 +217,10 @@ For each approved page:
    - [ ] Check Breakdance's CSS output for clean rendering
    - [ ] Compare with Elementor original
 
+## Design Tokens
+
+Conversion writes now register the colors and typography they carry as named design tokens in Breakdance's own global styles, and the converted pages reference those tokens instead of carrying value copies. When fixing or extending a migrated page, reuse the registered tokens (`respira_list_design_tokens` shows them) rather than re-inlining raw hex values or font stacks. And say so when you finish: the migration summary should name the tokens that were registered and note that migrated pages reference them.
+
 ## Safety Model
 
 - Read-only analysis first — full content scan before any changes

package/skills/migrate-elementor-to-bricks/SKILL.md

@@ -1,14 +1,26 @@
+---
+name: migrate-elementor-to-bricks
+description: "Use when the user says 'migrate elementor to bricks', 'convert elementor to bricks', or 'move my site from elementor to bricks'. Reads the Elementor JSON widget data, maps each widget to its Bricks equivalent, and creates draft duplicates with clean Bricks JSON."
+license: MIT
+metadata:
+  author: Respira for WordPress
+  author_url: https://respira.press
+  version: 2.1.0
+  mcp-server: respira-wordpress
+  category: migration
+---
+
 # 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.
+**Version:** 2.1.0
+**Updated:** 2026-08-04
+**Freshly updated:** v2.1.0 adds design-token awareness: conversion writes now register the colors and typography they carry as named design tokens in Bricks' own global styles, and converted pages reference those tokens instead of carrying value copies. Reuse registered tokens instead of re-inlining raw values, and report the registration in the migration summary.
 
 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 17 page builders Respira reads and writes natively, so the extraction and injection run through the same builder-aware tooling Respira uses everywhere else.
+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
@@ -190,6 +202,7 @@ For each approved page:
 ### Phase 4: Post-Migration Verification
 
 1. Summarize all migrations:
+   - Design tokens registered in Bricks' global styles (token names and counts)
    - Pages migrated successfully
    - Total widgets converted
    - Items flagged for manual attention
@@ -206,6 +219,10 @@ For each approved page:
    - [ ] Check forms and interactive elements
    - [ ] Compare side-by-side with Elementor original
 
+## Design Tokens
+
+Conversion writes now register the colors and typography they carry as named design tokens in Bricks' own global styles, and the converted pages reference those tokens instead of carrying value copies. When fixing or extending a migrated page, reuse the registered tokens (`respira_list_design_tokens` shows them) rather than re-inlining raw hex values or font stacks. And say so when you finish: the migration summary should name the tokens that were registered and note that migrated pages reference them.
+
 ## Safety Model
 
 - Read-only analysis first — full Elementor content scan before any changes