---
name: divi5-native-layouts
description: Generate, inspect, edit, and validate importable Divi 5 Builder JSON layouts using native Divi sections, rows, columns, modules, WooCommerce modules, and Design settings. Use when Codex is asked to create a Divi section, page, product template, cart, or checkout layout from a screenshot or brief; recreate an uploaded mockup with high visual fidelity; convert an existing design into Divi JSON; upgrade a Divi layout; produce a reusable Divi portability file; or audit a layout for custom CSS, inline styles, invalid hierarchy, unsupported module substitutions, or visual drift from a reference design.
---

# Divi 5 Native Layouts

Create Divi portability JSON that remains editable in the Visual Builder and uses native module settings. Treat the bundled site export as the authoritative envelope for Divi Powers.

## Core rules

- Use the hierarchy `placeholder → section → row → column → module`.
- Use the most semantic native module available. Use Toggle for FAQs, Blurb for icon-and-copy cards, Icon for standalone icons, Button for actions, Heading for headings when supported, and Text for ordinary rich text.
- Express design through native module attributes: background, typography, spacing, sizing, layout, border, shadow, transform, filters, animation, visibility, and responsive values.
- Do not add custom CSS, page CSS, inline `style` attributes, Code modules, or HTML wrappers unless the user explicitly changes this policy.
- Keep content editable. Do not simulate native components with HTML inside Text modules.
- Preserve the destination site's brand by default. Do not set Row width/max-width, font families, or ordinary text colors unless the brief requires an intentional override.
- Prefer the implicit Divi default module preset for cross-site portability. Use a named site preset only when its exported definition is verified and the layout explicitly targets that site.
- Preserve the source envelope's root keys and empty portability collections unless the requested layout needs portable images, variables, presets, or canvases.
- Do not guess an unfamiliar module schema. Inspect a real export or obtain a targeted anchor export before emitting risky attributes.
- Treat successful validation as structural proof, not visual proof. Do not call a screenshot recreation complete until the rendered page has been compared with the reference.

## Mockup fidelity mode

When the request includes a screenshot, image mockup, or explicit replica language, read [references/mockup-reconstruction.md](references/mockup-reconstruction.md) and use its workflow before writing Divi markup.

- Inspect the reference at original resolution and inventory every section, layer, overlap, asset, line break, width ratio, and visual motif.
- Classify each visible element as native editable content, a raster asset, or a mixed composition. Do not force photographic atmosphere, cutout people, product-preview artwork, or complex glow effects into generic Divi cards.
- When a person appears over a designed environment, default to two assets: a clean background plate and a separate transparent subject cutout. Do not bake both together unless the reference and responsive plan genuinely benefit from one flattened image.
- Use the `imagegen` skill for missing raster artwork or image edits. Inspect every generated asset before placing it, save project-bound assets in the project, and preserve identity when a real person is involved.
- Match macro composition before polishing details: section heights, column ratios, image crops, overlap geometry, headline line breaks, form orientation, and visual density.
- Build responsive behavior intentionally. Desktop may use native positioning and overlap; tablet and phone must have an explicit stacking and crop plan.
- After the first live render, compare it with the reference, list the largest visible deviations, correct them, and render again. A valid JSON import without a visual comparison is not completion.

## Workflow

1. Read [references/native-design-policy.md](references/native-design-policy.md) for every generation or audit task.
2. Read [references/direct-import-format.md](references/direct-import-format.md) when producing or modifying JSON.
3. Read [references/module-evidence.md](references/module-evidence.md) before choosing module attributes and [references/portability-and-presets.md](references/portability-and-presets.md) before every distributable layout. Read [references/woocommerce-modules.md](references/woocommerce-modules.md) for Shop, product, cart, or checkout layouts. Treat observed exports as stronger evidence than community documentation. Use [references/module-catalog.json](references/module-catalog.json) for extracted attribute examples and parent relationships. Inspect the dated files in `assets/module-exports/` when full export context matters.
4. For screenshot recreation, complete the visual inventory, asset manifest, geometry plan, and responsive plan from `mockup-reconstruction.md` before choosing modules.
5. Plan the section structure and identify each native module before writing block markup.
6. Build only the `post_content` block string first. Use balanced Divi block comments and JSON attributes on every opening or self-closing block.
7. Run `scripts/build_portability.py` to place the block string into the bundled Divi Powers envelope.
8. Run `scripts/validate_layout.py` on the produced JSON. Fix every error before delivery. Review warnings and explain any intentionally retained warning.
9. For screenshot recreation, render at the reference desktop width, compare against the mockup, complete at least one correction pass, and verify a phone breakpoint.
10. Deliver the `.json` file, the project asset manifest, and state whether it targets direct Builder portability or the Divi Library.

## Direct Builder imports

Use `assets/anchor-exports/simple-section.json` for direct Builder portability. This envelope uses `context: "et_builder"` and stores the complete block string in `data.<source-id>`.

Run:

```bash
python3 scripts/build_portability.py \
  --anchor assets/anchor-exports/simple-section.json \
  --content layout-blocks.txt \
  --output section.json

python3 scripts/validate_layout.py section.json
```

A direct Builder import can replace the current Builder content. Warn the user before they import into a page containing work they need to preserve.

## Library imports

Do not repackage a direct Builder export as a Library item by assumption. A Library export uses different context and metadata. Request or inspect a real Section or Layout export from `Divi → Divi Library` before producing `et_builder_layouts` files.

## Responsive behavior

- Put default values under `desktop`.
- Add smaller breakpoint values only when the design changes at that breakpoint.
- Prefer flexible native sizing and layout settings over fixed positioning.
- Ensure columns stack in a sensible reading order and interactive controls remain usable on phones.

## Evidence and iteration

- Record newly confirmed module structures in `references/module-evidence.md` after inspecting real exports.
- Keep the bundled anchor unchanged; create a new dated anchor when Divi's export format changes.
- After a generated file successfully imports and renders, use that result to expand validation and module evidence.
- Use `builderVersion: "5.11.0"` for new leaf or nested modules confirmed by the dated module exports. Preserve legacy versions only when cloning the older structural anchor nodes.
- When the user supplies another module export, preserve it under `assets/module-exports/`, regenerate `references/module-catalog.json` from every bundled export, and update the evidence ledger and validator before claiming the module is usable.