31 skill, 72 sistemi: come funziona la libreria di Open Design

Open Design è, meccanicamente, quattro primitive impilate una sull'altra:

1. Skill: cosa dovrebbe fare l'agente
2. Sistemi: come dovrebbe apparire l'output
3. Adattatori: quale agente svolge il lavoro
4. Il daemon: il ciclo che li collega tra loro

Ogni primitiva è una cartella di file. Nessuna di esse richiede un database, un runtime di plugin o un servizio ospitato. Questa è l'intera libreria: non c'è un quinto concetto nascosto dietro un muro di login. Questo articolo passa in rassegna ognuna a turno e mostra cosa succede quando punti il tuo agente a un brief reale. Se vuoi l'argomentazione sul perché l'abbiamo plasmato così prima del come, inizia da perché abbiamo costruito Open Design come un livello di skill, non come un prodotto.

Skill: l'unità di capacità

Una skill è una cartella che contiene un SKILL.md e zero o più file di supporto. Il file Markdown è il contratto dell'agente: tutto il resto nella cartella serve ad aiutare l'agente a rispettarlo.

Anatomia di una cartella di skill

Una skill tipica si presenta così:

skills/
  guizang-ppt/
    SKILL.md
    templates/
      magazine.html
    examples/
      product-launch.html
      pitch-deck.html

SKILL.md dichiara il nome della skill, le condizioni di attivazione, la forma dell'input, la forma dell'output e qualsiasi indicazione inline per l'agente. Le cartelle templates/ ed examples/ sono opzionali ma pesano molto: gli esempi sono artefatti noti come validi su cui l'agente può fare pattern-matching, ed è la differenza tra "fammi un deck" che produce qualcosa di coerente rispetto a qualcosa di improvvisato.

Il front matter è la parte che il daemon legge per registrare la skill; il corpo è la parte che l'agente legge per eseguirla:

---
name: guizang-ppt
trigger: a deck, slide presentation, or pitch
output: HTML (exportable to PDF, PPTX)
---

Build a horizontal slide deck. One idea per slide.
Lead with a cover, close with a call to action.
Respect the locked-in design system for color, type, and spacing.
Pattern-match against examples/ for layout density and rhythm.

Perché il file è il registro

Quando il daemon si avvia, scansiona skills/ e registra ogni cartella che contiene un SKILL.md. Non c'è alcun manifest di plugin. Non c'è alcun campo di versione. Non c'è alcun passo di upload, nessuna coda di revisione, nessuna build. C'è il file, e il file è la fonte di verità. Lascia cadere una nuova cartella, riavvia il daemon, e la skill appare nel selettore. Eliminala, ed è sparita: nessuna voce orfana nel registro che punta a codice che non esiste più.

Al momento rilasciamo 31 skill. Alcune sono generatori di deck, alcune producono mockup mobile, alcune costruiscono pagine editoriali, alcune scrivono documenti d'ufficio (Word, Excel, PowerPoint). Ognuna è una cartella che puoi forkare, modificare o sostituire. Poiché il contratto è testo semplice, "scrivere una skill" e "leggere una skill per capire cosa fa" sono la stessa attività: la verifichi aprendola.

Sistemi: l'unità di gusto

Se una skill descrive cosa creare, un sistema descrive come dovrebbe apparire. Un sistema è un file DESIGN.md più asset di riferimento opzionali. Descrive un'identità visiva in forma leggibile dalla macchina:

• Colore: valori OKLch per primo piano, sfondo, accento, errore e così via
• Tipografia: stack di font, pesi, la scala tipografica, convenzioni di interlinea
• Spazio: unità di base, scala di spaziatura, larghezze dei contenitori, regole di gutter
• Postura del layout: scelte di griglia, regole di asimmetria, preferenze di densità
• Voce: tipografia delle parole: tono, vocabolario, ritmo delle frasi

Un DESIGN.md è un contratto, non una libreria di componenti

In pratica un DESIGN.md si legge come un brief di brand breve e deciso che un agente non può fraintendere:

## Color
--bg: oklch(98% 0.01 95);
--ink: oklch(20% 0.02 260);
--accent: oklch(72% 0.19 35);

## Type
Display — Albert Sans, 600, -0.02em
Body — Albert Sans, 400, 1.7 line-height

## Posture
Generous whitespace. One accent, used sparingly. No drop shadows.

I colori sono in OKLch così restano percettivamente uniformi su superfici chiare e scure; la scala tipografica è una scala da cui l'agente non si allontana; le regole di postura sono la differenza tra dieci schermate generate che sembrano un unico prodotto e dieci che sembrano dieci stagisti diversi. L'agente legge questo una volta e lo rispetta per l'intero lavoro.

Un sistema non è una libreria Figma. Non ci sono componenti, né varianti, né istanze annidate, né formato binario che si frappone tra te e le regole. È un contratto che qualsiasi agente può leggere e qualsiasi umano può verificare. Rilasciamo 72 sistemi pronti all'uso, incluse versioni portabili di Linear, Vercel, Stripe, Apple, Cursor, Figma e una lunga coda di sistemi editoriali e di brand.

Mescola, forka, possiedi

Poiché un sistema è solo testo, puoi forkarne uno e modificarlo sul posto, rilasciare una variante o scriverne uno tuo da zero in circa 30 minuti di lavoro concentrato. Puoi persino mescolare sistemi a metà progetto — la tipografia da Linear, la logica del colore da Vercel, il layout da una specifica interna — perché nulla è bloccato in un binario proprietario. La separazione tra le cartelle skills/ e design-systems/ è deliberata: capacità e gusto sono ortogonali, quindi qualsiasi skill può girare sotto qualsiasi sistema, e qualsiasi sistema può pilotare qualsiasi skill.

Adattatori: l'unità di agente

Skill e sistemi sono testo inerte. Gli adattatori sono la piccola quantità di codice che li collega all'agente che fa effettivamente il lavoro. Un adattatore è un breve file TypeScript in adapters/ che sa come:

• rilevare se l'agente è installato nel $PATH dell'utente
• avviare una sessione con quell'agente
• inviare un'invocazione di skill
• raccogliere indietro l'output

Oggi rilasciamo adattatori per 12 agenti: Claude, Codex, Gemini, Cursor, Copilot, OpenCode, Devin, Hermes, Pi, Kimi, Kiro, Qwen. Il daemon rileva automaticamente quali sono presenti e li offre come menu a tendina al primo avvio: non configuri nulla, vedi semplicemente gli agenti che hai già.

Primitiva	Risiede in	File	Fonte di verità
Skill	skills/	SKILL.md	il file su disco
Sistema	design-systems/	DESIGN.md	il file su disco
Adattatore	adapters/	un file .ts	una chiamata register()

Se vuoi aggiungere un nuovo adattatore, il file è all'incirca 80 righe di TypeScript e una singola chiamata register(). Nessun SDK da imparare, nessun permesso da richiedere, nessun registro centrale su cui pubblicare. Lo stesso agente di cui ti fidi già sul tuo laptop diventa il motore: Open Design non lo sostituisce mai. (Il pezzo complementare flusso di lavoro di design BYOK illustra come puntare un adattatore alla tua chiave.)

Il daemon: il ciclo che lega tutto insieme

Il daemon è l'unico processo in esecuzione nel sistema. È un piccolo processo Node che avvii con pnpm tools-dev, e fa quattro cose in sequenza:

1. Rileva: scansiona il $PATH per gli agenti installati e skills/ per le skill installate, all'avvio
2. Scopri: apre un modulo di domande interattivo per definire superficie, pubblico, tono, scala e contesto di brand per il brief corrente
3. Indirizza: presenta 5 direzioni visive deterministiche (palette in OKLch, stack di font, indicazioni sulla postura del layout) e chiede all'utente di sceglierne una
4. Consegna: invoca la skill selezionata con il sistema bloccato, lascia che l'agente scriva su disco, e mostra l'anteprima dell'output in un iframe in sandbox

L'intero ciclo sta in all'incirca 1500 righe di codice. È volutamente piccolo. L'ingegnosità è nelle skill, non nel runtime: il compito del daemon è scansionare cartelle, instradare un brief attraverso i quattro passi e togliersi di mezzo. Quella piccolezza è il punto: c'è ben poco qui che può marcire, e quasi nulla che può tenere in ostaggio il tuo lavoro.

Come ci si sente in pratica

Supponi di volere un deck di lancio per una nuova funzionalità di prodotto. Ecco il flusso:

1. Esegui pnpm tools-dev in un terminale. Il daemon si avvia su localhost:7780.
2. Apri l'URL. Il daemon ti mostra quali agenti ha trovato (es. Claude, Cursor, Codex).
3. Scegli guizang-ppt dalla lista delle skill.
4. Appare un modulo di domande di 30 secondi: chi è il pubblico, qual è il tono, qual è il contesto di brand.
5. Ti vengono mostrate 5 direzioni visive — palette diverse, abbinamenti tipografici, posture di layout. Ne scegli una.
6. L'agente scrive su disco. Un iframe in sandbox mostra il risultato. Puoi esportare in HTML, PDF, PPTX, ZIP o Markdown.

Ripercorrilo attraverso le primitive e l'intera cosa è leggibile: il passo 3 ha scelto una skill, il passo 5 ha bloccato un sistema, l'agente dietro è arrivato tramite un adattatore, e il daemon ha eseguito il ciclo a quattro passi. L'output è reale. I file sono tuoi. Puoi modificarli in qualsiasi editor, consegnarli a un designer o reimmetterli in un'altra skill.

Perché file, non un database

Ogni primitiva — skill, sistemi, adattatori — è una cartella di file di testo. Non c'è alcun database centrale. Non c'è alcun "account Open Design". Non c'è alcun servizio ospitato che debba continuare a funzionare perché il tuo lavoro continui a funzionare.

Questo è un compromesso deliberato. Rinunciamo alla capacità di fare analitiche cross-utente sofisticate, memoria cross-progetto o collaborazione ospitata. In cambio otteniamo: portabilità, longevità, verificabilità e la possibilità per chiunque di forkare l'intera libreria e rilasciare la propria variante. Un SKILL.md scritto oggi si legge in modo identico per un agente tra due anni e per un umano senza alcuno strumento: lo stesso non si può dire di un plugin ancorato all'API dell'anno scorso.

Se hai visto una generazione di strumenti di design morire portandosi via i tuoi file, capirai perché questo compromesso ne vale la pena.

Letture correlate

• Perché abbiamo costruito Open Design come un livello di skill, non come un prodotto: la scommessa dietro le quattro primitive
• Flusso di lavoro di design BYOK: usa Claude, Codex o Qwen con la tua chiave: come gli adattatori si collegano all'agente che già paghi
• Il livello di layout che il canvas nascondeva: perché le regole di postura in un DESIGN.md battono il trascinare riquadri su un canvas