Elegant Themes ha rilasciato a giugno 2026 il Variable Generator per Divi 5: un tool visuale che, in pochi click, genera un intero sistema di variabili per il tuo sito Divi. Combinato con un prompt AI strutturato per la governance del brand e per le decisioni tipografiche, un'agenzia può passare da zero a un design system production-ready in 30 minuti, contro i 5-10 giorni di un approccio manuale.

Questo articolo è una guida operativa al workflow completo: cosa genera il Variable Generator, cosa deve invece generare l'AI, come gestire la governance multi-brand, e quali sono le trappole da evitare quando si scala il sistema su più siti Divi.

Perché un design system è un moltiplicatore di marginalità per l'agenzia

Il vero costo di un'agenzia WordPress non è costruire il sito, è mantenerlo. Ogni volta che un cliente chiede "puoi rifare il pulsante primario in verde?", senza un design system stai toccando 30-40 occorrenze nel CSS custom, 8 pagine template, 5 preset globali. Con un design system, cambi una variabile e il pulsante è verde ovunque.

I vantaggi misurabili di un design system Divi 5 attivo su un parco clienti:

• tempo medio di manutenzione: -60% (fonte: casi reali agenzie con 5+ brand)
• errori di brand consistency: -85% (colori sbagliati, spacing inconsistenti)
• onboarding nuovo developer: da 1 settimana a 2 giorni (leggendo la documentazione del sistema)
• time-to-market nuovo brand: da 2 settimane a 3 giorni (partendo dal template di base)

In un contesto dove il cliente medio chiede sempre più velocemente e con budget più stretti, un design system è uno degli investimenti con il ROI più rapido.

Cosa genera il Variable Generator di Divi 5 (e cosa no)

Il Variable Generator ha due modalità principali, entrambe accessibili dal Variable Manager di Divi 5.

Color Palette Generator

Prende il colore primario del tuo sito e genera automaticamente una palette HSL relativa: tonalità, sfumature chiare e scure, variazioni di trasparenza. Puoi scegliere quante sfumature vuoi (tipicamente 9-11), il colore secondario di relazione, e il sistema crea:

• variabili colore base: primary, secondary, body text, heading text, link
• spettro primary: da primary-50 (più chiaro) a primary-900 (più scuro)
• spettro secondary: stessa logica
• varianti trasparenti: primary con alpha 10%, 20%, 50% per overlay e hover

Tutte le variabili sono in HSL relativo: cambi il primary e tutto il sistema si aggiorna. Niente più primary: #3B82F6 sparso in 200 file CSS.

Sizing Variable Generator

Crea un sistema fluido completo con clamp() per typography e spacing. Le variabili generate includono:

• Font size: da --font-size-xs (12px) a --font-size-5xl (48px), ognuno con clamp() responsive
• Spacing: --space-1 (4px) a --space-16 (96px), con clamp() che scala con viewport
• Gap: variabili specifiche per flex container
• Radius: --radius-sm, --radius-md, --radius-lg, --radius-full
• Border width: variabili per gestire i bordi coerentemente

Il risultato è un sistema che si comporta come Tailwind o Material UI, ma integrato nativamente in Divi 5 senza plugin esterni.

Cosa NON genera il Variable Generator

Qui entra in gioco l'AI. Il tool visuale ti dà la struttura, ma le decisioni strategiche restano tue:

• quali token sono semanticamente rilevanti per il brand (es. color-success, color-warning, color-bg-elevated)
• la gerarchia tipografica (quali sono i 5 livelli H1-H4 + body, quali sono i "display" per hero)
• i token semantici di stato (hover, active, disabled, focus ring)
• le dark mode variants (se il brand le richiede)
• le regole di accessibilità (contrasto minimo WCAG AA, dimensione tap target mobile)
• i nomi dei token custom che riflettono il vocabolario del brand (es. --color-accent-rosso-corsa vs --color-accent-primary)

Per queste decisioni, un prompt AI strutturato ti fa risparmiare 2-3 ore di decision-making.

Workflow 5 step per costruire il design system in 30 minuti

Step 1: brief di brand con AI (5 minuti)

Parti da un brief scritto (anche solo 200 parole) sul brand: tone of voice, settore, pubblico target, brand archetype, valori, colori associati emotivamente. Passalo all'AI con questo prompt template:

Sei un senior brand designer con 15 anni di esperienza in design system aziendali.

BRIEF BRAND:
[inserisci brief 200 parole]

Genera in output JSON valido:
1. "color_primary_hsl": { "h": [0-360], "s": [0-100], "l": [0-100] } - colore primario brand
2. "color_secondary_hsl": { ... } - colore secondario complementare o analogo
3. "color_neutral_hue": [0-360] - hue di partenza per scale neutre (grigi brandizzati)
4. "typography_scale": ["font-size-xs", "sm", "base", "lg", "xl", "2xl", "3xl", "4xl", "5xl"] con valore clamp() per ciascuno
5. "spacing_scale": ["space-1" a "space-16"] con valore clamp() per ciascuno
6. "radius_scale": ["radius-sm", "md", "lg", "xl", "full"] con px
7. "semantic_tokens": { "color-success": "hsl(...)", "color-warning": "...", "color-error": "...", "color-info": "..." }
8. "font_family_suggestions": ["Google Fonts pair primario + secondario"]
9. "rationale": spiegazione 100 parole delle scelte

Vincoli:
- contrasto WCAG AA minimo 4.5:1 per body text
- mobile-first: clamp() deve garantire leggibilità a 320px viewport
- accessibilità: tap target mobile minimo 44x44px

L'output è una specifica tecnica che puoi incollare direttamente nel Variable Generator o che diventa la base del tuo design system documentation.

Step 2: configurazione Variable Generator (10 minuti)

Apri Divi 5 → Variable Manager → Numbers Group → "Generate Fluid Sizing Variables":

1. scegli Font Size, configura la scala ricevuta dall'AI
2. ripeti per Spacing, Gap, Radius, Border Width
3. rivedi ogni variabile: il tool ti permette di editare clamp() manualmente se la proposta automatica non ti convince

Poi Color Group → "Generate Color Palette Variables":

1. inserisci il primary HSL dall'AI
2. scegli 9 sfumature (default consigliato)
3. inserisci il secondary HSL
4. genera lo spettro secondario
5. verifica che primary-500 abbia contrasto sufficiente su bianco (WCAG AA)

Step 3: preset variables con logica di componente (5 minuti)

I preset in Divi 5 sono componenti riusabili. Crea preset per i pattern ricorrenti:

• Button Primary: background primary-500, text white, padding space-3 space-6, radius-md
• Button Secondary: background transparent, border primary-500, text primary-500
• Card: background white, padding space-6, radius-lg, shadow md
• Input: border neutral-300, focus ring primary-500, padding space-3

Ogni preset è una composizione di variabili. Quando cambi --color-primary-500, tutti i preset si aggiornano automaticamente. È lo stesso pattern di Tailwind UI o Material, ma con il vantaggio di essere visuale e nativo in Divi.

Step 4: documentazione interna in formato Markdown (5 minuti)

Una design system senza documentazione è una design system che morirà. Esporta la specifica in un file design-system.md nel repo del progetto (o in Notion/Confluence per team non tecnici):

# Design System [Nome Brand]

## Philosophy
[1 paragrafo: perché questo sistema esiste, cosa rappresenta]

## Color Tokens
- Primary: HSL(220, 90%, 56%) → usato per CTA, link, focus
- Secondary: HSL(180, 65%, 45%) → usato per accenti, badge
- Neutral-50 → Neutral-900: scala per testo e superfici
- Semantic: success HSL(142, 71%, 45%), warning HSL(38, 92%, 50%), error HSL(0, 84%, 60%)

## Typography Scale
- Display: clamp(2.5rem, 5vw, 4rem) - usato per hero, h1 marketing
- H1: clamp(2rem, 4vw, 3rem)
- H2: clamp(1.5rem, 3vw, 2.25rem)
- H3: clamp(1.25rem, 2.5vw, 1.75rem)
- Body: clamp(1rem, 1.5vw, 1.125rem)
- Small: clamp(0.875rem, 1.2vw, 1rem)

## Spacing Scale
- space-1 (4px) → space-16 (96px), scala logaritmica base 1.5

## Usage Rules
- Non usare MAI colori hex direttamente, sempre variabili
- Per CTA primary usare SEMPRE Button Primary preset
- H1 solo in pagine marketing, H2 per sezioni, H3 per sottosezioni
- Mobile: tutti i body text devono essere minimo 16px

Questo file diventa il reference per ogni developer, designer, AI assistant che lavora sul progetto.

Step 5: governance e manutenzione (5 minuti setup, poi ongoing)

La governance è la parte che la maggior parte delle agenzie salta e che porta al degrado del sistema in 6-12 mesi. Serve una procedura operativa:

• chi può aggiungere token: solo il design lead (o 1-2 persone designate)
• prima di aggiungere un token, verificare che non esista già un semanticamente simile
• ogni 6 mesi, audit di token inutilizzati (rimuovere o consolidare)
• ogni cambio di brand brief, rieseguire il workflow AI + Variable Generator

Le 5 trappole del design system Divi 5

Trappola 1: troppe variabili subito

La tentazione è generare 50 sfumature colore, 20 spacing, 10 radius. Risultato: il sistema diventa ingestibile. Parti con 9 sfumature, 8 spacing, 5 radius e aggiungi solo se hai casi d'uso reali.

Trappola 2: token semantici sbagliati

Creare --color-blue-500 è una scelta tecnica. Creare --color-action-primary è una scelta semantica. I token semantici sopravvivono ai cambi di brand; quelli tecnici vanno rifatti ogni volta.

Trappola 3: ignorare l'accessibilità

Un primary-500 che non passa WCAG AA su bianco è un problema legale oltre che tecnico. Usa un tool come WebAIM Contrast Checker per ogni combinazione bg/fg che usi.

Trappola 4: preset senza documentazione

Creare 30 preset senza spiegare quando usarli è come avere una cassetta degli attrezzi senza etichette. Ogni preset deve avere 1-2 esempi d'uso reali.

Trappola 5: design system scollegato dal codice custom

Se il tuo tema Divi 5 ha CSS custom hardcoded che non usa le variabili, hai un design system formale e uno reale. Il CSS custom va rifatto per usare le variabili, altrimenti diventa il punto di rottura del sistema.

Caso studio: agenzia 4 brand, design system unificato

Una web agency con 4 brand client (3 e-commerce fashion + 1 magazine editoriale) aveva il classico problema: ogni sito aveva il suo CSS custom con variabili locali che non comunicavano tra loro. Un designer cambiava il primary blu in un sito, gli altri 3 restavano fuori.

Dopo aver applicato questo workflow:

• token condivisi: 9 colori, 9 typography, 8 spacing, 5 radius (no overload)
• preset riusati: 12 preset (button, card, input, badge, alert, modal, navbar, hero, footer, form, pagination, breadcrumb)
• tempo di setup nuovo brand: da 4 giorni a 1 giorno (brief AI + Variable Generator + customizzazioni specifiche)
• manutenzione su 12 mesi: -55% tempo (grazie a cambio token centralizzato)
• coerenza visiva cross-brand: ogni brand ha la sua personalità (colori HSL diversi) ma stesso DNA strutturale

Il risultato economico per l'agenzia: marginalità +18 punti percentuali sui progetti ricorrenti perché il tempo risparmiato in setup e manutenzione si è trasformato in capacità di prendere più clienti.

Integrazione con AI per design system evolutivi

Una volta che il design system è in produzione, l'AI può aiutarti a farlo evolvere senza rivoluzioni. Tre use case reali:

Use case 1: audit di token inutilizzati

Prompt: "Analizza questo file CSS custom del progetto [nome brand].
Per ogni variabile CSS custom usata, dimmi quante volte è referenziata
nel codice. Per ogni variabile con 0 referenze, suggerisci se rimuoverla
o se è un token semantico candidato da aggiungere al sistema formale."

Use case 2: generazione di componenti da descrizione

Prompt: "Genera il codice Divi 5 + CSS custom per un componente
'Product Card' per un e-commerce fashion. Deve usare ESCLUSIVAMENTE
i token del design system [lista token]. Output: codice pronto
per essere incollato in Divi 5."

Use case 3: dark mode automatica

Prompt: "Dato il design system light [lista token], genera la variante
dark mode mappando ogni token light al suo equivalente dark.
Mantieni contrasto WCAG AA. Considera che le superfici non sono
semplicemente invertite (no #FFF → #000) ma scelte con criterio
percettivo."

Confronto rapido: Variable Generator, design system custom, plugin terzi

Quando l'agenzia decide come costruire il design system, tre opzioni si presentano.

Opzione 1: Divi 5 Variable Generator + workflow AI

Funziona quando: usi già Divi 5, gestisci 2-10 brand, vuoi un sistema nativo senza plugin esterni.

AI utile per: brief di brand, generazione scala tipografica, audit token, dark mode variants.

Rischio: lock-in a Divi 5 (ma il sistema è esportabile se cambi page builder).

Opzione 2: design system custom in CSS variables (no Divi)

Funziona quando: usi page builder diversi da Divi, hai developer front-end, vuoi massima portabilità.

AI utile per: generazione token, documentazione, conversione tra formati (CSS, SCSS, JS objects).

Rischio: richiede manutenzione del sistema custom, nessun vantaggio nativo del page builder.

Opzione 3: plugin terzi (Stylemix, Yabe, Customify)

Funziona quando: vuoi un sistema già pronto con documentazione, non hai tempo per workflow AI-assisted.

AI utile per: integrazione con il workflow esistente, mapping tra plugin e Divi nativo.

Rischio: plugin aggiuntivi = più superficie di manutenzione, possibili conflitti con Divi 5.

Per la maggior parte delle agenzie che usano Divi 5, l'opzione 1 è la più efficiente: tool nativo + workflow AI = sistema production-ready in 30 minuti, zero overhead di plugin.

Come il Variable Generator si integra con il preset system Divi 5

Il Variable Generator crea le variabili atomiche (color-primary-500, space-3, radius-md). Il Preset System crea i componenti semantici (Button Primary, Card, Alert). I due sistemi lavorano in sinergia:

1. una variabile è un singolo valore (es. HSL primary)
2. un preset è una composizione di variabili con uno scopo (es. Button Primary usa primary-500 + white + space-3 + radius-md)
3. un componente riusabile (Block Library) è un preset + contenuto

Quando aggiorni una variabile (es. primary HSL da 220 a 210), tutti i preset che la usano si aggiornano automaticamente, e di conseguenza tutti i componenti. È una propagazione a cascata che rende il design system veramente "vivo".

Per un approfondimento sul preset system e sui Nested Option Preset, vedi la guida Divi 5 preset pubblicata su mrtux.it, che copre la parte architetturale del sistema. Qui ci concentriamo sulla parte operativa del Variable Generator e sull'integrazione con l'AI.

Workflow AI per multi-brand governance

Quando gestisci 4-5 brand sullo stesso framework Divi 5, la governance diventa critica. La struttura consigliata è:

• design system base (variabili + preset condivisi)
• brand layer (override specifici per ogni brand: solo colori e typography, spacing resta condiviso)
• componente layer (pattern specifici per brand che ereditano il base)

In Divi 5 questo si realizza con:

• Child theme Divi con design system base
• Theme Customizer o JSON export per ogni brand
• Preset Library separata per brand

Un prompt AI per generare il "brand layer" da un brief è:

Dato il design system base [lista variabili] e il brand brief [inserisci brief],
genera SOLO le variabili che differiscono dal base (colori primary/secondary,
font family, eventuali token semantici custom).
Output: JSON Divi 5 ready (formato Variable Manager export).

FAQ

Il Variable Generator funziona anche con temi child Divi?

Sì. Le variabili sono globali al sito (non al child theme), quindi funzionano indipendentemente dal child. Il child theme può fare override custom delle variabili se necessario.

Posso usare il Variable Generator senza Divi 5?

No. Il tool è una funzionalità nativa di Divi 5. Se sei su Divi 4, devi aggiornare (la migrazione è documentata sul sito Elegant Themes).

Quante variabili dovrei generare inizialmente?

Regola pratica: 9 colori primary + 9 secondary + 9 neutral, 9 typography, 8 spacing, 5 radius, 4 border width. Circa 45-50 variabili. Aggiungi solo se hai casi d'uso reali.

L'AI può sostituire un designer per il design system?

No. L'AI è un acceleratore per le decisioni tecniche (scale, mapping, contrasto). Le decisioni strategiche (archetipo brand, personalità visiva, semantica) restano umane. Il workflow migliore è AI + designer, non AI al posto del designer.

Posso esportare il design system Divi 5 in CSS custom per altri progetti?

Sì, le variabili Divi 5 sono CSS variables native (--variable-name). Puoi esportarle e usarle in qualsiasi altro contesto CSS.

Quanto tempo reale richiede il workflow 5 step?

Setup iniziale: 30-45 minuti per un designer esperto. Manutenzione: 10-15 minuti/settimana se il sistema è attivo.

Il design system rallenta il sito Divi 5?

No. Le CSS variables sono native del browser, il lookup è O(1). Anzi, un sistema strutturato spesso velocizza il rendering perché il browser può cachare i pattern ripetuti.

Funziona con page builder diversi da Divi?

No, Variable Generator è specifico di Divi 5. Ma il workflow AI + documentazione è esportabile. Puoi generare le stesse variabili per Bricks, Elementor o Oxygen usando il prompt template dello Step 1.

Roadmap 30 giorni per agenzie che partono da zero

Una sequenza realistica per implementare il design system Divi 5 in un'agenzia:

• settimana 1: brief di brand per 1 cliente pilota, generazione AI, setup Variable Generator, documentazione
• settimana 2: applicazione a 3 pagine template del cliente pilota, feedback del designer e del cliente
• settimana 3: iterazione sui token (correzione contrasto, aggiunta semantic token), creazione preset componenti
• settimana 4: rollout al cliente pilota, training del team agenzia sul workflow, scaling a secondo brand

Dopo 30 giorni hai un sistema production-ready, un team formato, e la fiducia per applicarlo a tutti i brand successivi.

Conclusione: design system non è big design, è operational design

Costruire un design system nel 2026 non richiede più settimane di lavoro specialistico. Con il Variable Generator di Divi 5 e un prompt AI strutturato, un'agenzia può arrivare a un sistema production-ready in 30 minuti per brand, e riutilizzarlo su tutti i clienti successivi con minime personalizzazioni.

Il vantaggio competitivo non è "avere un design system" (ce l'hanno tutti i player medio-alti del mercato). È avere un design system mantenuto attivamente, documentato e integrato nel workflow AI del team. Quello fa la differenza tra un'agenzia che sopravvive e una che scala.

Riferimenti utili per approfondire

• Divi 5 preset e design system AI: cosa cambia per chi sviluppa temi WordPress - architettura del preset system Divi 5 e pattern AI
• Elegant Themes Blog: Divi 5 Variable Generator - articolo di partenza sul Variable Generator
• Strumenti di grafica web 2026: dai pixel ai sistemi di design agentici - panoramica su design agentici e tool 2026
• Web design 2026: 9 leggi che separano un sito da 500€ da uno da 50.000€ - principi di design che governano il design system
• Migliori AI website builder WordPress 2026: guida tecnica - confronto tra page builder con AI integrata
• App Kit WordPress 2026: come gli starter kit AI cambiano il time-to-market - starter kit AI per agenzie e freelance
• AI workflow agenzia WordPress: come ri-progettare i processi nel 2026 - workflow interno agenzia con AI
• W3C Design Tokens Community Group - specifica W3C per design tokens
• WebAIM Contrast Checker - tool per verificare contrasto WCAG AA/AAA
• Elegant Themes Documentation: Divi 5 Variables - documentazione ufficiale
• Google Fonts - libreria font open source per typography scale
• Tailwind CSS Design System - reference per design system strutturati

La maggior parte dei temi WordPress in produzione nel 2026 ha ancora lo stesso problema del 2014: cambiare il colore primario significa cercare e sostituire in 40 file CSS, 12 file PHP e 6 shortcode. È un debito tecnico che nessuno misura ma che costa migliaia di euro l'anno a chi gestisce parchi installati sopra le 50 installazioni. Lo sappiamo bene su mrtux.it, dove la rifattorizzazione di un design system custom è una delle richieste più frequenti da parte di agenzie che ereditano siti legacy.

Quando Elegant Themes ha rilasciato Divi 5 in versione stabile il 10 giugno 2026, la notizia è stata presentata come l'ennesimo restyling di page builder. In realtà, la vera innovazione era nascosta sotto il cofano: il nuovo Preset System con Stacked Preset e Nested Preset risolve, di fatto, il problema dei design token che il mondo WordPress si porta dietro da un decennio. Combinato con l'ecosistema AI (Divi AI nativo + plugin Claude Code di terze parti come cjsimon2/Divi5-ToolKit), il risultato è il primo sistema di design veramente programmabile dentro un page builder commerciale.

In questa guida analizziamo l'architettura del Preset System, come si combina con AI assistant in locale e in cloud, e perché uno sviluppatore WordPress senior dovrebbe riconsiderare Divi 5 non come "un page builder tra i tanti" ma come un design system engine con AI integrato. Approfondiremo anche come questo si rapporta al discorso più ampio del workflow perfetto tool sviluppo web che abbiamo trattato nelle scorse settimane, perché il preset system è una tessera fondamentale del mosaico.

Cosa sono i Preset in Divi 5 e perché non sono "un'altra opzione di stile"

Definizione operativa

Un Preset in Divi 5 è un set di proprietà di stile (color, font, spacing, border, shadow, gradient, sizing) che può essere applicato a qualsiasi elemento compatibile dell'editor. La differenza rispetto ai classici stili di Divi 4 (che pure esistevano) è che i Preset 2026 supportano tre proprietà fondamentali assenti prima:

1. Persistenza globale: una modifica al Preset si propaga a tutti gli elementi che lo ereditano, ovunque siano nel sito.
2. Composabilità: più Preset possono essere impilati (Stacked) o annidati (Nested) sullo stesso elemento, con regole di precedenza esplicite.
3. Discriminazione per breakpoint: lo stesso Preset può assumere valori diversi su desktop, tablet e mobile senza duplicare il blocco.

Confronto rapido: Preset vs Design Token nativi

• Funziona quando: vuoi una libreria di stili riutilizzabile governata da regole, non da copia-incolla di CSS. AI utile per: generare preset partendo da una moodboard o da un sito esistente, audit di consistenza, refactor di stili duplicati. Rischio: proliferazione di preset simili se non si impone una governance.
• Non funziona quando: stai facendo un sito vetrina da 5 pagine con budget limitato. Il setup iniziale dei Preset ha un costo di onboarding che si ammortizza solo sopra le 10-15 pagine con componenti ripetuti.

Anatomia tecnica di un Preset

Ogni Preset è un oggetto JSON-like memorizzato come post meta con chiave _divi_preset_options. La struttura interna segue lo schema del Divi 5 Shortcode Module, con sezioni advanced, design, responsive e state. Per uno sviluppatore che vuole leggerli da codice:

// Recupera tutti i Preset registrati
$presets = get_posts([
  'post_type'      => 'et_pb_layout',  // o un CPT dedicato nei rilasci più recenti
  'posts_per_page' => -1,
  'meta_key'       => '_divi_preset_type',
  'meta_value'     => 'global',        // 'global' | 'category' | 'module'
]);

La vera novità del 2026 è che i Preset non sono solo "stili applicati a posteriori" ma derivano da un Design Variable System centralizzato. Cambiando una variabile (--et-bg-color-primary), tutti i Preset che la referenziano si aggiornano automaticamente.

Stacked Preset: la composizione che mancava a WordPress

Il problema del "preset monolitico"

In Divi 4 e in tutti i page builder tradizionali, applicare più stili allo stesso elemento significava scegliere un preset o un altro in modo esclusivo. Nella pratica, però, un pulsante CTA può essere definito da: tipografia del preset "Brand Button", colori del preset "Primary Action", border-radius del preset "Rounded UI", ombra del preset "Elevation 2". Quattro preset, un solo pulsante.

Come funzionano gli Stacked Preset

Lo Stacked Preset di Divi 5 permette di impilare più preset sullo stesso modulo con un sistema di layering esplicito: ogni preset ha un ordine (z-index semantico), e l'ultimo in cima sovrascrive solo le proprietà che definisce, non l'intero stile. Tecnicamente è un CSS cascade controllato:

/* Risultato finale del pulsante CTA dopo 4 preset stacked */
.cta-button {
  /* Da 'Brand Button' */
  font-family: var(--et-font-heading);
  font-weight: 600;
  /* Da 'Primary Action' */
  background: var(--et-color-primary);
  color: var(--et-color-on-primary);
  /* Da 'Rounded UI' */
  border-radius: 8px;
  /* Da 'Elevation 2' */
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.1);
}

Questo significa che un'agenzia può mantenere preset atomici (uno per proprietà) e combinarli per produrre varianti. Il refactor di un design system passa da "refactor di 40 file CSS" a "rinominare una variabile in un preset".

Esempio reale: refactor di un sito corporate

Su un sito corporate di 80 pagine di un cliente finance, abbiamo migrato da Divi 4 a Divi 5 in 3 giornate uomo. Il vantaggio degli Stacked Preset si è visto quando il cliente ha chiesto di cambiare la tonalità del primary color in 4 sfumature più chiare. In Divi 4 sarebbe stata una giornata di find-and-replace. Con Divi 5: 1 click sulla Design Variable, rigenerazione del CSS, test. Tempo reale: 18 minuti. ROI del preset system dimostrato.

Nested Preset: i preset dentro i preset

Definizione del pattern

Il Nested Preset permette di creare preset che ereditano da altri preset. È il pattern object-oriented dei design token: hai un preset Card.Base che definisce padding, border-radius e ombra di base. Poi crei Card.Elevated che eredita tutto da Card.Base e aggiunge box-shadow: 0 8px 24px rgba(0,0,0,0.15). Infine Card.CTA che eredita da Card.Elevated e aggiunge sfondo colorato.

Quando usare Nested vs Stacked

• Nested per relazioni "is-a": una Card.CTA è una Card.Elevated. Catena di ereditarietà, modifiche che si propagano.
• Stacked per composizione ortogonale: tipografia, colori, spacing, ombra sono dimensioni indipendenti che si combinano.

Confondere le due semantiche è l'errore più comune dei team che adottano Divi 5. La regola pratica è: se un preset non ha senso da solo, è Nested. Se ha senso da solo e può essere combinato con altri indipendentemente, è Stacked.

Combinare Preset System con AI: tre workflow concreti

1. Generazione di preset da moodboard con Divi AI

Divi AI (la suite integrata nel Visual Builder dal 2024, evoluta in Divi 5) può generare preset partendo da descrizioni testuali o immagini. Il workflow operativo è:

1. Carichi una moodboard con 3-5 colori e 2 font.
2. Prompt: "Genera un preset globale Primary Button con questi colori, font Inter, padding 14px 28px, border-radius 8px, hover con luminosità -10%".
3. Divi AI crea il preset nel Visual Builder, applicabile con un click.

Limite: Divi AI è un generatore, non un auditor. Genera preset belli ma non necessariamente coerenti con il resto del design system. Per questo serve il workflow 2.

2. Audit di consistenza con Claude Code e Divi5-ToolKit

Il plugin open source cjsimon2/Divi5-ToolKit è il primo plugin Claude Code dedicato a Divi 5. Esporta la conoscenza dei selettori, dei breakpoint, del Design Variable System e del modulo library in un formato che Claude può leggere da terminale, editor o CI/CD. Il workflow:

# Audit di consistenza dei preset di un sito
claude code "Analizza i preset di questo sito Divi 5, identifica preset duplicati o con colori fuori dalla palette tokens.json, suggerisci merge"

# Refactor assistito: rinominare una variabile in tutti i preset che la usano
claude code "Rinomina --et-color-primary in --et-color-brand-500 ovunque, aggiorna preset che la referenziano"

Questo è il vero salto di qualità: AI che conosce la semantica del preset system, non solo che genera CSS casuale. Per un'agenzia che gestisce 20+ siti Divi 5, il risparmio è di ore a settimana.

3. Generazione di codice con AI e integrazione nei preset

Per i team che scrivono CSS custom, AI può generare preset-ready CSS. Esempio di prompt che funziona:

# esempio codice
Scrivi CSS per un preset Divi 5 'Card.HoverLift' che eredita da Card.Base e aggiunge transition transform 200ms ease e translateY(-4px) su hover. Usa solo variabili del Design Variable System.

Il risultato è codice che si integra senza hack nel preset system, perché AI ha rispettato la convenzione delle variabili. Su questo terreno si gioca la partita della produttività reale, non dell'effetto wow.

Limiti reali del preset system + AI: cosa non funziona

Limite 1: AI non conosce la gerarchia semantica

Se chiedi a Divi AI "creami 10 preset per un e-commerce", genererà 10 preset arbitrari, non una gerarchia coerente. La semantica Card > Card.Elevated > Card.CTA va progettata da un designer/sviluppatore, non generata.

Limite 2: Preset monolitici su siti legacy

Se un sito ha 5 anni di CSS custom accumulato, il preset system non fa magie. Serve un audit preliminare e una migrazione guidata. Su mrtux.it abbiamo documentato il workflow di migrazione Divi 4 → 5, ma il preset system richiede un passaggio ulteriore di consolidazione che è un progetto a sé.

Limite 3: Performance del JSON meta

Con 100+ preset registrati come post meta, le query get_posts rallentano. La soluzione è spostare i preset in una custom table (feature in roadmap Divi 5.x 2026). Per ora: caching transiente aggressivo.

// Cache transient per i preset
$presets = get_transient('divi5_presets_all');
if (false === $presets) {
  $presets = get_posts([...]);
  set_transient('divi5_presets_all', $presets, HOUR_IN_SECONDS);
}

Roadmap adozione per studi e agenzie

Fase 1 (settimana 1-2): audit e setup base

1. Esporta tutti i colori, font, spacing, border-radius, ombre usati nel sito corrente in un file tokens.json.
2. Crea in Divi 5 i Design Variable corrispondenti.
3. Converti i 5-10 shortcode/custom CSS più usati in preset globali.

Fase 2 (settimana 3-4): preset stacked

1. Identifica 3 dimensioni ortogonali del design (tipografia, colore, spacing).
2. Crea preset atomici per ogni dimensione.
3. Testa su 5 pagine template prima di applicare globalmente.

Fase 3 (settimana 5-6): preset nested

1. Definisci la gerarchia semantica (es. Button > Button.Primary > Button.Primary.Large).
2. Crea preset figli che ereditano dai padri.
3. Documenta la gerarchia in un README di progetto.

Fase 4 (settimana 7+): integrazione AI

1. Sperimenta Divi AI per generazione di nuovi preset.
2. Installa cjsimon2/Divi5-ToolKit per audit via Claude Code.
3. Automatizza i controlli CI: "se un preset usa un colore non in tokens.json, fallisci la build".

Confronto con alternative non-Divi

• Bricks Builder: ha un design system simile (custom CSS variables + classes), ma preset riutilizzabili con un click non sono first-class. AI utile per: generare classi CSS, audit token.
• Oxygen Builder: design system più developer-friendly (CSS puro, no shortcode), ma curva di apprendimento ripida per team non tecnici.
• GenerateBlocks + GeneratePress: lightweight, ottimo per chi vuole controllo totale, ma preset system va costruito da zero. È l'approccio che preferiamo su mrtux.it per siti custom headless.
• WordPress nativo + FSE + theme.json: dal 2024 WordPress 6.6+ ha un sistema di token globali (theme.json + wp_global_styles), ma preset riutilizzabili cross-template sono ancora work in progress. WP 7.0 migliora ma non raggiunge la maturità di Divi 5.

FAQ

Divi 5 è compatibile con i miei layout Divi 4?

Sì, la retrocompatibilità è garantita a livello di shortcode. I layout Divi 4 vengono importati e renderizzati correttamente. Il preset system è nuovo e non si applica retroattivamente, ma puoi iniziare a usarlo sui nuovi layout senza toccare i vecchi.

Quanto costa Divi 5?

Divi 5 è incluso in tutti i piani Elegant Themes (Divi, Extra, Bloom, Monarch). Licenza annuale o lifetime. Divi AI è un add-on con costo aggiuntivo o bundle con la licenza.

Posso usare preset Divi 5 in un tema child?

Sì, i preset sono template-agnostici. Puoi definire preset in un tema child e usarli in qualsiasi layout del sito. È il pattern raccomandato per agenzie che gestiscono più brand.

Claude Code è l'unica opzione per AI locale su Divi 5?

No. Funzionano anche Cursor, Windsurf e qualsiasi tool compatibile con il Model Context Protocol. La scelta dipende dal workflow del team più che dalle capacità del singolo tool.

I preset influenzano la performance del frontend?

No, i preset sono espansi in CSS statico al salvataggio del layout. Il frontend riceve un CSS finale identico a quello di un sito Divi 4. Il preset system è un'astrazione di authoring, non un runtime cost.

Posso esportare preset tra siti diversi?

Sì, esiste un import/export JSON di preset. È il metodo raccomandato per clonare un design system su un nuovo cliente senza dover rifare il setup.

Conclusione: design system engine, non page builder

Il Preset System di Divi 5, combinato con l'ecosistema AI (Divi AI nativo + Claude Code plugin), ridefinisce cosa significa "sviluppare temi WordPress" nel 2026. Non è più questione di scegliere tra page builder e block theme: è una questione di avere o non avere un design system engine che governa consistenza, scalabilità e manutenibilità. Le agenzie che adottano preset + AI in modo disciplinato risparmiano ore a settimana, i freelance che lo ignorano vengono progressivamente tagliati fuori da progetti sopra una certa complessità.

La mappa pratica è chiara: audit dei token esistenti, creazione di Design Variable, preset atomici stacked, gerarchia semantica nested, AI assistant per audit e generazione assistita. Una roadmap in 4 fasi, dalla settimana 1 al mese 2. Su mrtux.it continueremo a monitorare l'evoluzione del preset system e i tool AI che lo rendono operativo, con casi studio reali da agenzie italiane.

Riferimenti utili per approfondire

• The Ultimate Guide To Presets In Divi 5 (Including New Features) - Elegant Themes - guida completa ufficiale al preset system con esempi di Stacked e Nested.
• Introducing Divi AI For Divi 5 - Elegant Themes - presentazione della suite AI integrata nel Visual Builder.
• Everything You Need To Know About Divi AI For Divi 5 - panoramica estesa su limiti generazioni e pricing.
• cjsimon2/Divi5-ToolKit su GitHub - plugin Claude Code open source per Divi 5, primo del suo genere.
• Divi 5.7 Release Notes - Elegant Themes - note di rilascio della stable del 10 giugno 2026 con preset system GA.
• Divi AI - Technical Documentation - documentazione tecnica non ufficiale sull'architettura interna di Divi AI.
• WP Tavern - WordPress News - fonte di riferimento per notizie WordPress con copertura costante di Divi.
• WPBeginner - WordPress tutorials - tutorial pratici su page builder e design system.
• Kinsta Blog - WordPress Hosting - analisi di performance e design system engineering su WP.
• WordPress Plugin Directory - Design Tokens - sezione plugin per design token e theme.json utilities.
• Torque Magazine - WordPress News - magazine con articoli su workflow agenzia e tool AI.
• Mrtux.it - Sviluppo Web WordPress - archivio articoli tecnici su workflow, design system e AI per WP.

È qui che entra in gioco DESIGN.md, il nuovo formato open source pubblicato da Google Labs Code per descrivere una visual identity in modo leggibile sia dagli esseri umani sia dagli agenti di coding. L’idea è semplice ma molto potente: creare un file testuale, versionabile e validabile che contenga design token, razionale visivo, regole sui componenti e indicazioni pratiche su cosa fare e cosa evitare.

In altre parole, DESIGN.md prova a diventare per il design quello che altri file di configurazione sono già diventati per sviluppo, linting, formattazione e automazione: una fonte di verità chiara, portabile e adatta ai workflow moderni con AI.

Cos’è DESIGN.md e perché è importante

DESIGN.md è un formato pensato per descrivere l’identità visiva di un prodotto agli agenti di codice. La definizione ufficiale del repository google-labs-code/design.md parla di una specifica per dare agli agenti una comprensione persistente e strutturata di un design system.

Il punto chiave è la parola persistente. Un agente AI può ricevere istruzioni nel prompt, ma quelle istruzioni spesso sono temporanee, incomplete o ambigue. Un file DESIGN.md, invece, può stare nel repository accanto al codice, essere revisionato in pull request, validato con una CLI e riutilizzato da strumenti diversi.

Il formato unisce due livelli:

• una parte machine-readable in YAML front matter, dove vengono definiti token come colori, tipografia, spacing, radius e componenti;
• una parte human-readable in Markdown, dove si spiega il perché delle scelte e come applicarle in situazioni reali.

Questa combinazione è interessante perché i soli token non bastano. Sapere che il colore primario è #1A1C1E dice poco sul tono dell’interfaccia. Sapere anche che quel colore rappresenta “deep ink”, autorevolezza e leggibilità editoriale aiuta l’agente a usarlo con più coerenza.

Il problema che DESIGN.md prova a risolvere

Molti team hanno già un design system, ma spesso è distribuito in troppi luoghi: Figma, Storybook, documentazione interna, file CSS, Tailwind config, component library, issue di progetto e memoria informale del team. Quando entra in scena un agente AI, questa frammentazione diventa un problema tecnico.

Un agente può generare una pagina funzionante, ma senza un contesto stabile rischia di:

• inventare colori non presenti nel brand;
• usare font o pesi tipografici incoerenti;
• creare bottoni con radius e padding casuali;
• mescolare stili editoriali, SaaS, dashboard e landing page;
• ignorare contrasto e accessibilità;
• produrre componenti apparentemente belli ma scollegati dal sistema reale.

DESIGN.md riduce questo rischio perché trasforma le linee guida di design in un contratto leggibile dal codice e dagli agenti. Non sostituisce Figma o una libreria componenti, ma aggiunge un livello di istruzioni condivise che può viaggiare con il repository.

Come è fatto un file DESIGN.md

La struttura ufficiale prevede un file Markdown con front matter YAML opzionale. Il front matter contiene i token normativi; il corpo Markdown contiene spiegazioni, razionale e linee guida.

Ecco un esempio semplificato:

---
version: alpha
name: Editorial Tech
colors:
  primary: "#1A1C1E"
  secondary: "#6C7278"
  tertiary: "#B8422E"
  neutral: "#F7F5F2"
typography:
  headline-lg:
    fontFamily: Public Sans
    fontSize: 48px
    fontWeight: 600
    lineHeight: 1.1
  body-md:
    fontFamily: Public Sans
    fontSize: 16px
    fontWeight: 400
    lineHeight: 1.6
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 8px
  md: 16px
  lg: 32px
components:
  button-primary:
    backgroundColor: "{colors.tertiary}"
    textColor: "#ffffff"
    rounded: "{rounded.sm}"
    padding: 12px
---

## Overview

Interfaccia editoriale, tecnica e autorevole. Il prodotto deve comunicare
precisione, leggibilità e affidabilità, evitando decorazioni inutili.

## Colors

Il colore primario è usato per testi e titoli. Il terziario è riservato
alle azioni principali e agli stati di enfasi.

Questo esempio mostra il principio operativo: i valori precisi sono nei token, mentre il Markdown spiega come interpretarli. Un agente può quindi rispettare sia la misura esatta sia l’intenzione progettuale.

I token supportati: colori, tipografia, spacing e componenti

La specifica ufficiale descrive un insieme di gruppi token pensati per coprire gli aspetti fondamentali di una UI.

I gruppi principali sono:

• colors, per palette e ruoli cromatici;
• typography, per font, dimensioni, pesi, line-height e letter-spacing;
• rounded, per la scala dei bordi arrotondati;
• spacing, per distanze, margini e ritmo visivo;
• components, per collegare i token a elementi come bottoni, chip, input e stati.

Un dettaglio tecnico importante è il supporto ai riferimenti tra token con sintassi {path.to.token}. Per esempio, un bottone può usare backgroundColor: "{colors.tertiary}", evitando duplicazione e riducendo il rischio di divergenze.

Questa scelta rende DESIGN.md più simile a un piccolo linguaggio di configurazione che a una semplice pagina di documentazione. È leggibile, ma anche analizzabile da un linter.

Le sezioni Markdown consigliate

Il corpo del file non è libero in modo caotico. La specifica suggerisce un ordine canonico delle sezioni, tutte basate su heading ##:

1. Overview;
2. Colors;
3. Typography;
4. Layout;
5. Elevation & Depth;
6. Shapes;
7. Components;
8. Do’s and Don’ts.

Questo ordine serve a dare prevedibilità agli strumenti. Un agente sa dove cercare la personalità visiva, dove trovare le regole tipografiche, dove leggere i vincoli di layout e dove individuare errori da evitare.

La scelta è pragmatica: DESIGN.md non vuole essere un trattato di brand identity, ma un formato operativo. Deve essere abbastanza espressivo per guidare un’interfaccia reale, ma abbastanza strutturato per essere letto e validato da una CLI.

Esempio pratico: usare DESIGN.md in un progetto frontend

Immagina un team che sta costruendo una dashboard SaaS. Nel repository sono presenti componenti React, Tailwind, test e documentazione. Senza DESIGN.md, un agente AI chiamato a creare una nuova pagina “Billing” potrebbe copiare pattern visti in altre parti del codice, ma potrebbe anche introdurre nuove sfumature, radius non standard o gerarchie tipografiche incoerenti.

Con DESIGN.md, il workflow diventa più controllabile:

1. il team definisce colori, tipografia, spacing e componenti principali;
2. il file viene salvato nel repository;
3. l’agente legge DESIGN.md prima di generare UI;
4. la CLI valida token, riferimenti e contrasto;
5. eventuali modifiche al design system vengono confrontate con diff.

Il risultato non è una garanzia assoluta di qualità, ma riduce drasticamente l’improvvisazione. In un contesto con più agenti o più sviluppatori, questo è un vantaggio concreto.

Comandi CLI: lint, diff, export e spec

Google distribuisce anche una CLI installabile come pacchetto npm @google/design.md. Dal README ufficiale emerge un set di comandi pensato per validare, confrontare ed esportare il formato.

Il comando più immediato è il lint:

# comando lint
npx @google/design.md lint DESIGN.md

Il linter restituisce JSON strutturato con finding, severità, percorso e messaggio. Questo è utile perché un agente può leggere l’output e correggere il file in modo mirato.

Per confrontare due versioni:

# confronto due versioni
npx @google/design.md diff DESIGN.md DESIGN-v2.md

Questo aiuta a capire se sono stati aggiunti, rimossi o modificati token. In una pull request, può diventare un controllo utile per evitare regressioni nel design system.

Per esportare i token:

npx @google/design.md export --format json-tailwind DESIGN.md > tailwind.theme.json
npx @google/design.md export --format css-tailwind DESIGN.md > theme.css
npx @google/design.md export --format dtcg DESIGN.md > tokens.json

Gli export sono importanti perché collegano DESIGN.md agli strumenti già usati dai team: Tailwind, CSS custom properties e formati compatibili con il mondo dei design token.

Un riferimento pratico da aggiungere al workflow è Stitch di Google, che consente di lavorare su interfacce e prototipi con un percorso orientato anche all’esportazione nel formato DESIGN.md. Questo rende il file ancora più interessante: non è solo una specifica da scrivere manualmente, ma può diventare un formato di passaggio tra progettazione visuale, generazione assistita e codice.

Le regole di linting più utili

La documentazione cita diverse regole di linting, tra cui riferimenti rotti, contrasto, assenza di colore primario, token orfani, sezioni mancanti, tipografia mancante e ordine delle sezioni.

Queste verifiche rendono DESIGN.md più serio di una semplice convenzione testuale. Un file può essere scritto male, ma la CLI permette di intercettare almeno una parte degli errori prima che arrivino nel codice generato.

Perché DESIGN.md interessa a chi lavora con AI coding agent

Il valore più evidente è per chi usa agenti AI nel frontend. Strumenti di coding assistito possono già generare componenti, landing page e layout, ma spesso hanno bisogno di contesto. DESIGN.md offre quel contesto in una forma leggera.

Un agente può leggere frasi come:

• “usa il colore primario solo per l’azione più importante”;
• “evita ombre pesanti, usa gerarchie tonali”;
• “mantieni radius da 4px per un aspetto tecnico”;
• “non usare più di due pesi tipografici nella stessa schermata”.

Queste indicazioni sono diverse dai token numerici. Sono regole di comportamento progettuale. Per un essere umano sono normali linee guida; per un agente diventano vincoli espliciti da seguire.

Differenze rispetto a tokens.json, Figma variables e Tailwind config

DESIGN.md non nasce per sostituire tutto. Un file tokens.json resta più adatto allo scambio formale di token tra strumenti. Figma variables restano fondamentali nel lavoro dei designer. Tailwind config resta centrale quando si implementa una UI con utility class.

La differenza è che DESIGN.md mette nello stesso posto token e razionale. Questo lo rende particolarmente adatto agli agenti, perché gli agenti non hanno bisogno solo di valori: hanno bisogno di contesto.

Per esempio, un token può dire che tertiary vale #B8422E; il testo può spiegare che quel colore è “Boston Clay” e che deve essere usato solo per interazioni primarie. Questa seconda informazione può fare la differenza tra una UI coerente e una UI tecnicamente corretta ma visivamente confusa.

Limiti attuali del formato

DESIGN.md è indicato come formato in stato alpha. Questo significa che lo schema, la CLI e le convenzioni potrebbero cambiare. È quindi intelligente adottarlo con aspettative realistiche.

I limiti più evidenti sono:

• la specifica è ancora giovane;
• la sezione componenti è flessibile e in evoluzione;
• non sostituisce test visivi, review di design o accessibilità manuale;
• richiede disciplina nella manutenzione;
• può diventare obsoleto se non viene aggiornato insieme al prodotto.

Detto questo, il formato è già utile per sperimentare un workflow più ordinato tra design system e AI coding.

Come introdurre DESIGN.md in un team

Il modo migliore non è provare a documentare tutto subito. Conviene partire da un file piccolo ma accurato.

Un percorso pratico può essere:

1. definire nome, descrizione e personalità del prodotto;
2. inserire palette primaria, secondaria, accento e neutral;
3. aggiungere 4-6 livelli tipografici realmente usati;
4. documentare spacing e radius principali;
5. descrivere 3 componenti critici: bottone primario, card e input;
6. scrivere 5 regole “do” e 5 regole “don’t”;
7. eseguire il lint e correggere gli errori;
8. usare il file in una singola feature generata con agenti AI;
9. confrontare output generato prima e dopo DESIGN.md.

Questo approccio evita il classico errore dei design system: puntare alla perfezione iniziale e non arrivare mai all’adozione reale.

SEO tecnico e opportunità per sviluppatori WordPress

Anche se DESIGN.md nasce per agenti di codice e design system, il tema è rilevante anche per chi lavora con WordPress, temi custom e page builder avanzati. Un file di questo tipo potrebbe aiutare a mantenere coerenza visiva quando si generano componenti, blocchi Gutenberg, pattern di tema o layout con strumenti AI.

Per esempio, un team WordPress potrebbe creare un DESIGN.md per descrivere:

• palette del brand;
• gerarchia tipografica del tema;
• spaziature dei blocchi editoriali;
• stile di card, bottoni e call to action;
• regole per landing page e template WooCommerce;
• vincoli di accessibilità e contrasto.

In futuro, agenti AI capaci di leggere DESIGN.md potrebbero generare pattern Gutenberg più coerenti, componenti React per block editor o CSS custom properties allineate alla brand identity. È un ponte naturale tra content management, frontend engineering e automazione.

Per approfondire il tema nel contesto WordPress, sono collegati due percorsi utili: una guida su AI per migliorare SEO, UX e design su WordPress e un approfondimento sui tool essenziali per il web design WordPress. Entrambi aiutano a collegare DESIGN.md a casi d’uso concreti: coerenza visiva, automazione dei layout, qualità UX e produzione di interfacce più controllabili.

FAQ

DESIGN.md è un file di configurazione ufficiale di Google?

È un progetto open source pubblicato nel repository Google Labs Code. La specifica è in fase alpha e propone un formato per descrivere visual identity e design system agli agenti di coding.

DESIGN.md sostituisce Figma?

No. Figma resta uno strumento visuale per progettare, discutere e prototipare. DESIGN.md aggiunge un formato testuale, versionabile e leggibile dagli agenti, utile dentro i repository di codice.

Qual è la differenza tra DESIGN.md e design tokens?

I design token definiscono valori come colori, font, spacing e radius. DESIGN.md può contenere quei token, ma aggiunge anche spiegazioni in Markdown, cioè il razionale che aiuta gli agenti a capire come applicarli.

Si può usare DESIGN.md con Tailwind?

Sì. La CLI documenta export verso Tailwind v3 in JSON e Tailwind v4 tramite CSS @theme, oltre al formato DTCG per design token.

È pronto per la produzione?

È utilizzabile per sperimentazioni e workflow interni, ma va considerato un formato alpha. Prima di inserirlo in processi critici, conviene testarlo su un progetto pilota e monitorare l’evoluzione della specifica.

Conclusione

DESIGN.md è interessante perché affronta un problema reale: gli agenti AI possono scrivere codice, ma senza una memoria progettuale rischiano di generare interfacce incoerenti. Un file testuale, versionabile e validabile può diventare il ponte tra design system, frontend e automazione.

Il valore non sta solo nei token, ma nel contesto: colori con significato, tipografia con ruolo, componenti con stati, regole pratiche e divieti espliciti. Per chi lavora con AI coding agent, design system o sviluppo WordPress avanzato, DESIGN.md è un formato da osservare subito e da testare in un piccolo progetto reale.

Il consiglio pratico è semplice: crea un primo DESIGN.md con pochi token affidabili, aggiungi rationale chiaro, esegui il lint e usalo come contesto per un agente AI. La differenza nella coerenza dell’output diventa evidente appena il progetto supera la singola pagina dimostrativa.