Components: Retire completed Emotion migration guidance

.agents/skills/design-system-code-review/SKILL.md

@@ -18,6 +18,6 @@ Read the affected package's `AGENTS.md` and [Working with WordPress Design Syste
 5. **Interaction or accessibility regressions.** Check the semantics, accessible names, keyboard paths, focus, and disabled states the change can affect. Use the guide's [verification guidance](../../../docs/contributors/design/design-system-packages.md#verify-the-affected-behavior) for standards and browser evidence. Passing types or class assertions do not prove interaction or visual parity.
 6. **Public documentation or generated output left behind.** Check affected prop documentation, stories, component status and recommendation metadata, generated token assets, and required changelogs. Do not request new stories or documentation for an unchanged capability.
 
-Apply [package-runtime-compatibility](../package-runtime-compatibility/SKILL.md) only when the changed contract crosses independently updated package and WordPress versions. For an Emotion migration, use the [migration guide](../../../packages/components/emotion-to-scss-modules.md) to check cascade and consumer compatibility.
+Apply [package-runtime-compatibility](../package-runtime-compatibility/SKILL.md) only when the changed contract crosses independently updated package and WordPress versions. For stylesheet changes, use the [styling conventions](../../../packages/components/CONTRIBUTING.md#styling) to check cascade and consumer compatibility.
 
 Keep findings tied to the change, including downstream effects. Missing tests alone are not a finding. Reuse existing coverage and request a new check only for a concrete, meaningful risk introduced by our code or integration. Combine concerns that have one coherent fix.

.agents/skills/design-system-contribution/SKILL.md

@@ -21,7 +21,7 @@ Keep product-specific behavior in the consuming package and use [design-system-u
 
 - Follow the package's component, prop/ref, state, and styling conventions. Reuse existing composition and helpers instead of rebuilding behavior already provided by a dependency.
 - For removals, replacements, or behavior changes, compare the affected old and new contracts using the [compatibility guidance](../../../docs/contributors/design/design-system-packages.md#compare-contracts-before-replacing-an-api). Include plugin and npm consumers, even when all Gutenberg callers have been migrated.
-- For token changes, choose by semantic purpose and affected modes, then follow the [token source guide](../../../packages/theme/tokens/README.md) and [build procedure](../../../packages/theme/README.md#building). For Emotion migrations, use [emotion-to-scss-modules](../emotion-to-scss-modules/SKILL.md).
+- For token changes, choose by semantic purpose and affected modes, then follow the [token source guide](../../../packages/theme/tokens/README.md) and [build procedure](../../../packages/theme/README.md#building).
 - Use [package-runtime-compatibility](../package-runtime-compatibility/SKILL.md) only when changing a contract between independently updated package and WordPress versions.
 
 ## Verify what changed

packages/components/AGENTS.md

@@ -4,6 +4,5 @@ Use [design-system-contribution](../../.agents/skills/design-system-contribution
 
 -   [CONTRIBUTING.md](./CONTRIBUTING.md) for component APIs, compatibility, styling, stories, and documentation. Existing components can have compatibility constraints that differ from the conventions for new components.
 -   The affected component's README, types, stories, and consumers before changing its contract.
--   [emotion-to-scss-modules](../../.agents/skills/emotion-to-scss-modules/SKILL.md) for an Emotion migration.
 
 For consumer component selection, follow [Choose a recommended component](../../docs/contributors/design/design-system-packages.md#choose-a-recommended-component). This package remains supported; do not migrate existing consumers to `@wordpress/ui` just because it is newer.

packages/components/CHANGELOG.md

@@ -71,6 +71,7 @@
 
 ### Documentation
 
+-   Retire completed Emotion migration guidance and keep permanent styling advice in the contribution guide ([#85023](https://github.com/WordPress/gutenberg/pull/85023)).
 -   Update styling guidance and the `ToolsPanel` example after the Emotion migration ([#85020](https://github.com/WordPress/gutenberg/pull/85020)).
 
 ## 42.0.0 (2026-10-07)

packages/components/CONTRIBUTING.md

@@ -424,7 +424,7 @@ Use `--_wp-components-*` for new private custom properties. These are implementa
 
 Components no longer use Emotion. Do not add new Emotion imports.
 
-The [Emotion-to-SCSS migration guide](./emotion-to-scss-modules.md) records compatibility checks, cascade and custom-property pitfalls, verification, and examples from the completed source migrations.
+For styling compatibility and verification, follow [Change a package safely](/docs/contributors/design/design-system-packages.md#change-a-package-safely) and the [cross-document setup guidance](/packages/theme/README.md#across-documents-iframes-and-other-portals).
 
 ### Deprecating styles