Smetti di fare il suggeritore al tuo fornitore di IA e crea sub‑agenti, competenze e comandi

Passare dalla dipendenza dai prompt ai sistemi di agenti intelligenti

La maggior parte delle persone sta ancora usando l’IA come un gobbo elettronico.

Scrivono un prompt. Aspettano. Ricevono una risposta. La copiano e incollano da qualche parte. Poi lo rifanno. E lo rifanno ancora. Ogni interazione parte da zero. Ogni conversazione dimentica ciò che è successo prima.

Questa non è collaborazione. È dettatura con passaggi extra.

Nel 2026, se stai ancora usando il tuo provider di IA come un gobbo elettronico, ti stai perdendo l’intero cambiamento che sta avvenendo sotto ai tuoi piedi.

Il problema del gobbo elettronico

Quando usi l’IA come un gobbo elettronico, stai trattando un sistema potenzialmente autonomo come un generatore di testo “one-shot”. Lo schema è questo:

1. Scrivi un prompt dettagliato
2. Aspetti la risposta
3. Valuti manualmente l’output
4. Affini e ripeti il prompt
5. Perdi tutto il contesto quando chiudi la chat

Questo modello ha tre difetti fatali:

Nessuna conoscenza persistente. Ogni conversazione è una tabula rasa. Spieghi lo stesso contesto ripetutamente. La tua IA non conosce il tuo codebase, le tue preferenze, i tuoi vincoli o la tua storia.

Nessuna delega. Rimani il collo di bottiglia. Ogni decisione, ogni validazione, ogni passo successivo richiede il tuo intervento. L’IA aspetta che tu le dica cosa fare dopo.

Nessuna specializzazione. Usi un’unica interfaccia generica per tutto: coding, documentazione, design, test, deployment. Un solo stile di prompt. Una sola finestra di contesto. Una conversazione che svolge il lavoro di molte.

Il modello del gobbo tratta l’IA come uno strumento. Ma gli strumenti non scalano l’autonomia. Gli agenti sì.

Cosa cambia quando pensi in termini di agenti

In Claude Code, l’architettura a agenti è composta da tre elementi primitivi:

• Sottoagenti: istanze specializzate di Claude con finestre di contesto isolate (~/.claude/agents/)
• Skill: moduli di conoscenza con attivazione automatica dotati di file SKILL.md (~/.claude/skills/)
• Comandi: comandi /slash attivati dall’utente per azioni esplicite (~/.claude/commands/)

La differenza chiave rispetto al prompting tradizionale:

• Le Skill vengono attivate automaticamente da Claude in base al contesto
• I Comandi richiedono che tu digiti esplicitamente /command
• I Sottoagenti operano in un contesto separato con i propri strumenti

Considera la differenza:

Approccio da gobbo elettronico:

“Scrivimi un componente card con un’immagine, un titolo, un testo principale e un pulsante primario seguendo i pattern del nostro design system e gli standard di accessibilità...”

Approccio Claude Code:

/generate card --variant=default --with-image=true --with-button=true

La prima è una richiesta. La seconda invoca una skill che sa già cos’è una card, cosa richiede il tuo design system, quali standard di accessibilità si applicano e come validare il proprio output.

L’architettura: Sottoagenti, Skill & Comandi

Ecco la struttura che sostituisce il modello del gobbo:

Livello 1: Sottoagenti

I sottoagenti sono file markdown autonomi in ~/.claude/agents/ che eseguono lavoro in parallelo. Hanno le proprie finestre di contesto e possono invocare skill.

~/.claude/agents/
├── header-builder.md
├── footer-builder.md
└── dashboard-builder.md

Ogni file di sottoagente ha un frontmatter YAML:

• name: identificatore chiaro
• description: cosa fa e quando invocarlo
• tools: capacità consentite (Read, Write, Bash, Grep, Glob)

Esempio di sottoagente (header-builder.md):

---
name: header-builder
description: Build complete header components with navigation
tools: Read, Write, Bash, Glob, Grep
---  You are a header component specialist...

Livello 2: Skill

Le skill sono moduli di conoscenza con attivazione automatica. Quando chiedi qualcosa a Claude che corrisponde allo scopo di una skill, Claude la applica automaticamente.

~/.claude/skills/
├── card/
│   ├── SKILL.md
│   ├── workflows/
│   │   ├── generate.md
│   │   ├── validate.md
│   │   └── improve.md
│   ├── references/
│   │   └── schema.yml
│   └── scripts/
│       └── validate.py

Questo segue la metodologia Atomic Design: atomi, molecole, organismi. Ogni skill è esperta in una sola cosa. Quando ti serve una card, la skill card si attiva automaticamente.

Ogni skill conosce:

• Lo schema del componente (prop, slot, varianti)
• Le convenzioni del tuo design system
• I pattern specifici del framework
• I requisiti di accessibilità WCAG
• Le skill correlate a cui può fare riferimento

Livello 3: Comandi

I comandi sono scorciatoie attivate dall’utente. Digiti /command per invocarli. Vivono nei workflow delle skill o globalmente:

~/.claude/skills/card/workflows/
├── generate.md    # /generate card
├── validate.md    # /validate card
├── improve.md     # /improve card
├── document.md    # /document card
├── test.md        # /test card
└── a11y.md        # /a11y card

I comandi possono invocare sottoagenti per la pianificazione, poi l’istanza principale di Claude gestisce l’esecuzione. Questo ti dà workflow strutturati con pieno accesso agli strumenti.

Esempio completo: Skill Card

Ti mostro esattamente come funziona con una skill reale:

La struttura della Skill

~/.claude/skills/card/
├── SKILL.md           # Core prompt and instructions
├── workflows/         # Slash commands
│   ├── generate.md
│   ├── validate.md
│   ├── improve.md
│   ├── document.md
│   ├── test.md
│   └── a11y.md
├── references/        # Documentation loaded into context
│   └── schema.yml
└── scripts/           # Executable Python/Bash scripts
    └── validate.py

Il file SKILL.md

---
name: card
description: Generate and validate card components 
  for any design system with accessibility checks
---  # Card Skill  When user requests card components, this skill 
auto-triggers based on context.
 ## Schema  props:
  title: string
  body: string
  image: { src, alt, width }
  variant: default | horizontal | overlay
 slots:
  header: Custom header content
  footer: Buttons, links
 ## Related Skills  This skill can reference:
- image
- heading
- button
- link
- text

Uso dei comandi slash

Generare una nuova card:

/generate card \   --variant="default" \   --title="Welcome" \   --with-image=true \   --with-button=true

Validare una card esistente:

/validate card \   --file="components/card.jsx"

Verificare la conformità all’accessibilità:

/a11y card --level="AA"

Migliorare la UX per un contesto specifico:

/improve card \   --context="e-commerce product listing" \   --focus="conversion"

Cosa succede dietro le quinte

Quando invochi /generate card, Claude:

1. Attiva la skill card: SKILL.md viene caricato nel contesto
2. Legge lo schema:  valida i tuoi parametri rispetto alle prop ammesse
3. Fa riferimento ad altre skill:  le skill image, heading, button forniscono la loro competenza
4. Esegue il workflow: viene eseguito workflows/generate.md
5. Si autovalida: esegue il workflow di validate sul proprio output
6. Restituisce il risultato:  fornisce il componente più eventuali avvisi

La skill card non si limita a generare markup. Orquestra un sistema di specialisti, ognuno dei quali contribuisce con la propria competenza di dominio.

Perché è importante: da builder a systems thinker

Il modello del gobbo ti mantiene nel ruolo di operatore. Il modello basato sulle skill ti rende architetto.

Quando sono passato dallo scrivere prompt al progettare skill, sono cambiate diverse cose:

Ho smesso di ripetere il contesto. Ogni skill conosce già il proprio dominio. Non devo spiegare cos’è una card ogni volta che me ne serve una.

Ho iniziato a pensare in termini di composizione. Una pagina non è un singolo prompt: è il coordinamento di organismi, che sono coordinamenti di molecole, che sono coordinamenti di atomi. Ogni livello ha la propria skill.

Ho delegato la validazione. Invece di rivedere manualmente ogni output, il comando /validate controlla la struttura, il comando /a11y verifica la conformità alle WCAG e il comando /test esegue controlli automatizzati. Io rivedo le eccezioni, non ogni risultato.

Ho costruito conoscenza istituzionale. Quando miglioro la SKILL.md di una skill, quel miglioramento persiste. Il sistema diventa più intelligente nel tempo, non solo durante una singola conversazione.

Questa è la differenza tra usare l’IA e costruire con l’IA.

Il design è il codice

Nel mio lavoro con i design system, sono arrivato a un principio: Il design è il codice.

Quando design token, schemi dei componenti e configurazioni degli agenti sono allineati, non esiste uno strato di traduzione tra ciò che i designer specificano e ciò che gli sviluppatori costruiscono. La specifica è l’implementazione.

Ecco come gli agenti rendono concreta questa idea:

# The schema IS the source of truth schema:   props:     variant:       type: string
      enum: [primary, secondary, success, danger, warning, info]       default: primary
    size:       type: string
      enum: [sm, md, lg]       default: md
 tokens:   colors:     - --btn-bg
    - --btn-color
    - --btn-border-color

Questo schema non è solo documentazione. È la fonte di verità. L’agente genera i componenti a partire da esso. Il validatore controlla rispetto ad esso. I design token lo referenziano. Un solo file, molti utilizzi.

Quando un designer aggiorna i valori dei token in Figma, si aggiorna la configurazione dell’agente. Quando si aggiorna la configurazione dell’agente, si aggiornano i componenti generati. Il design è il codice perché entrambi derivano dallo stesso schema.

Come iniziare a costruire con Claude Code

Se sei pronto a superare il modello del gobbo, ecco un percorso pratico:

Passo 1: Identifica i tuoi domini

Quali aree del tuo lavoro sono ripetitive, governate da regole e dipendenti dal contesto? Queste sono candidate per diventare skill:

• Generazione di codice
• Documentazione
• Testing
• Revisione e validazione
• Gestione del design system
• Deployment e DevOps

Passo 2: Crea la tua prima Skill

Inizia con una semplice SKILL.md:

---
name: my-component
description: Generate and validate my-component
---  # My Component Skill  When user asks about my-component, apply these rules...

Passo 3: Aggiungi i workflow (Comandi)

Crea i sei comandi principali in workflows/:

Ogni comando è un file markdown con istruzioni.

Passo 4: Definisci i riferimenti tra Skill

Le skill possono fare riferimento ad altre skill:

## Related Skills  This skill uses:
- image (for card images)
- button (for CTAs)
- heading (for titles)

Mappa queste dipendenze. La gerarchia dovrebbe rispecchiare la struttura naturale del tuo dominio.

Passo 5: Crea Sottoagenti per i task complessi

Quando hai bisogno di contesto isolato o esecuzione parallela, crea un file sottoagente in ~/.claude/agents/:

---
name: header-builder
description: Build complete header components with navigation, logo, and search
tools: Read, Write, Bash, Glob, Grep
---  You are a header component specialist. When building headers:
1. Check existing header patterns in the codebase
2. Use the nav, button, logo skills for sub-components
3. Ensure responsive design and accessibility

Costruire la tua libreria di Skill

Struttura le tue skill seguendo l’Atomic Design:

Ogni skill:

• Ha la propria configurazione SKILL.md
• Ha workflows/ con comandi slash
• Ha references/ con documentazione
• Ha scripts/ per l’automazione
• Sa quali altre skill referenzia

Questo crea un sistema coerente e scalabile in cui Claude attiva automaticamente la skill giusta in base al contesto.

Il futuro è agentico

Brad Frost, il creatore di Atomic Design, parla da tempo di questo cambiamento: i design system devono diventare infrastrutture leggibili dalle macchine, perché ora gli agenti di IA stanno assemblando le interfacce con gli stessi componenti usati dai team umani.

Non è una previsione per il 2030. Sta succedendo adesso.

Se il tuo design system non può essere interpretato da un agente, sta diventando legacy. Se il tuo workflow di sviluppo richiede un umano che faccia prompt a ogni passo, non è scalabile. Se ogni interazione con l’IA parte da zero, stai sprecando conoscenza accumulata.

Il modello del gobbo andava bene quando l’IA era una novità. Non va più bene quando l’IA è infrastruttura.

Smetti di fare prompt. Inizia a progettare.

Costruisci agenti. Dai loro delle skill. Lasciali coordinare.

Il futuro appartiene a chi progetta sistemi, non a chi scrive script.

Costruire design system agentici per il futuro dello sviluppo web.

Per approfondire

• The Design Is the Code  La mia esplorazione del pensiero a automi cellulari nei design system
• Atomic Design by Brad Frost  La metodologia alla base delle gerarchie di componenti
• Designing Systems That Build Themselves  Dal builder al systems thinker