Perché abbiamo costruito Open Design come uno strato di skill, non come un prodotto

Il coding agent più potente che hai sul tuo laptop in questo momento è Claude, Codex, Cursor, Gemini, OpenCode o Qwen. Non pensiamo che ti serva un altro. Ciò che manca non è l'intelligenza grezza — è il gusto, la struttura e un flusso di lavoro che rispetta il design come un mestiere.

Open Design è il nostro tentativo di colmare quello strato mancante. Non è un prodotto di chat. Non è uno strumento di design che “usa l'AI sotto il cofano”. È un sottile strato di skill — una cartella di file SKILL.md, una libreria portatile di design system e un daemon che rileva automaticamente i tuoi CLI agent esistenti e li collega tra loro.

Questo articolo spiega perché abbiamo fatto questa scelta, cosa implica per il modo in cui userai Open Design e perché “strato, non prodotto” è una scommessa sulla longevità anziché una scorciatoia.

Un prodotto avrebbe la forma sbagliata

L'istinto, quando si avvia un progetto di design basato sull'AI nel 2026, è costruire una nuova app: un'interfaccia di chat, un canvas, un sistema di fatturazione, una bolletta dei modelli che cresce in modo lineare con il numero di utenti. Abbiamo considerato questa strada e l'abbiamo respinta per tre motivi.

L'interfaccia di chat è una commodity

Ogni utente ha già un agente capace e una casella di chat di cui si fida. Aggiungerne una peggiore — avvolta nel nostro marchio, priva della memoria muscolare che si è costruito — non aiuta nessuno. Il valore non è nell'interfaccia. Il valore è in ciò che l'agente fa dopo che hai premuto invio: se produce una presentazione dall'aspetto curato o un muro di div.

La bolletta dei modelli è una tassa sulla creatività

Includi l'inferenza nel prodotto e l'economia ti forza la mano. Devi ricaricare i token, limitare le sessioni lunghe e razionare l'accesso ai modelli più recenti per far sopravvivere il tuo margine. Ognuna di queste mosse punisce esattamente il comportamento che uno strumento di design dovrebbe premiare: iterare, esplorare ed eseguire di nuovo l'agente perché è alla terza bozza che il lavoro diventa buono.

Il lock-in è l'impostazione predefinita sbagliata

I designer dovrebbero poter andarsene con i loro file, i loro system e le loro skill intatti. Un prodotto avvolge tutto in uno stato proprietario — esportalo e ottieni un'ombra appiattita della cosa reale. Uno strato di skill non ha nulla da avvolgere, perché gli artefatti sono i file. Andarsene non costa nulla, ed è proprio per questo che restare significa qualcosa.

Così abbiamo costruito invece lo strato. Inserisci una cartella, riavvia il daemon, la skill compare. Porta la cartella con te, inseriscila in un agente diverso, la skill funziona anche lì.

Cos'è davvero una skill

Una skill in Open Design è un file SKILL.md più eventuali asset di supporto nella stessa cartella. Il file Markdown descrive:

• Cosa fa la skill — un paragrafo, in linguaggio semplice
• Quando invocarla — le condizioni di attivazione, scritte in modo che l'agente possa instradare correttamente
• La forma dell'output — HTML, PDF, slide, un brief in Markdown
• I vincoli — palette in OKLch, stack di font, postura di layout, vocabolario del marchio

L'agente legge il file, decide se invocarla e scrive l'output su disco. Non c'è alcun sistema di plugin, nessuna superficie API, nessuna matrice di compatibilità delle versioni. Se sai scrivere Markdown, sai distribuire una skill.

Anatomia di una skill

Concretamente, una skill è una directory che il daemon scopre all'avvio:

skills/
  magazine-poster/
    SKILL.md          # the contract: trigger, output shape, constraints
    examples/
      launch.html     # a known-good artifact the agent can pattern-match

Il front matter di SKILL.md dà il nome alla skill e ai suoi trigger; il corpo è una guida che l'agente legge come un brief. Niente registra la skill se non la sua presenza su disco — nessun manifest da aggiornare, nessuna fase di build, nessuna coda di revisione.

Perché i file battono i plugin

È una scelta intenzionale. Abbiamo osservato gli ecosistemi di plugin decadere per quindici anni — ognuno un compromesso tra espressività e longevità, vinto da nessuno dei due. Un plugin è un'istantanea dell'API di qualcuno in un anno particolare; il runtime si evolve, l'API si rompe e il flusso di lavoro da cui dipendevi sparisce. I file non si rompono. Un SKILL.md scritto oggi si legge esattamente allo stesso modo per un agente tra due anni, e per un essere umano senza alcuno strumento.

Perché anche i system sono Markdown

Open Design distribuisce decine di design system — Linear, Vercel, Stripe, Apple, Cursor, Figma e altri ancora — come file DESIGN.md. Stessa idea: portatili, leggibili, assimilabili dall'agente.

Un design system, in questo contesto, non è una libreria Figma. È un contratto:

## 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.

L'agente legge il contratto e produce un lavoro che lo rispetta — colori in OKLch così da restare percettivamente uniformi, una scala tipografica da cui non si discosterà, una postura di layout che fa sì che dieci schermate generate sembrino un unico prodotto.

Mescola, fai il fork e rendili tuoi

Poiché un system è solo testo, puoi farne il fork e modificarlo sul posto, distribuire una variante o scriverne uno tuo da zero in trenta minuti. Puoi persino mescolare più system a metà progetto — prendere la tipografia da Linear, la logica dei colori da Vercel, il layout da una specifica interna personalizzata — perché non c'è alcun formato binario tra te e le regole. L'intero meccanismo di come skill e system si compongono è descritto in 31 skills, 72 systems: how the Open Design library works.

BYOK è l'unico modello onesto

Open Design funziona con il bring-your-own-key. Incolli un base URL e una API key per qualsiasi endpoint compatibile con OpenAI — DeepSeek, Groq, OpenRouter, il tuo vLLM self-hosted — e hai finito:

OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…

Non eseguiamo l'inferenza. Non prendiamo un margine sui token. Non abbiamo un rapporto di fatturazione con te. Non è un problema di sostenibilità — è l'unica risposta onesta alla domanda “chi paga quando l'agente gira?”

La privacy deriva dalla stessa scelta

Poiché il daemon chiama il provider direttamente dalla tua macchina, i tuoi prompt non transitano mai sui nostri server. Non c'è alcun proxy a registrarli, nessuna pipeline di analytics che trattiene silenziosamente il tuo lavoro non ancora pubblicato. Per il lavoro di agenzia o per qualsiasi cosa coperta da NDA, “dove gira tutto questo?” smette di essere una conversazione di procurement e diventa un'impostazione. I compromessi più profondi — e gli spigoli che ancora esistono — sono in the BYOK reality check.

La risposta a chi paga è: paghi tu, direttamente, al provider di modelli che hai scelto. Noi ci togliamo di mezzo.

Cosa significa questo per te

Se vuoi un SaaS rifinito con una bella casella di chat e un unico abbonamento, non siamo lo strumento giusto. Ci sono buoni prodotti di quella forma — usali.

Se vuoi un flusso di lavoro in cui:

• l'agente di cui ti fidi già fa il lavoro,
• le skill sono file che puoi leggere e modificare,
• i design system sono portatili tra progetti e agenti,
• e la bolletta va al provider di modelli, non a noi —

allora Open Design è costruito per te. Entra nel repository GitHub, esegui pnpm tools-dev, punta il tuo agente su una skill e distribuisci.

Lo strato di skill vince perché non compete con l'agente sul tuo laptop. Lo potenzia.

Letture correlate

• 31 skills, 72 systems: how the Open Design library works — i quattro primitivi da cui è costruito questo strato
• BYOK design workflow: run Claude, Codex, or Qwen on your own key — il modello bring-your-own-key nella pratica
• The open-source alternative to Figma — dove la scommessa “strato, non prodotto” si colloca rispetto all'incumbent