LangChain ha raccolto 160 milioni di dollari. Tre anni di sviluppo. Una valutazione da un miliardo. LangSmith, la loro piattaforma di test, è davvero sofisticata: valutazioni di traiettorie, pipeline trace-to-dataset, LLM-as-judge, suite di regressione, framework di unit test per strumenti. Hanno i pezzi. A ciascuno il suo merito.
Ma i pezzi non sono una pratica.
LangChain ti dà strumenti per testare. Non ti dice mai cosa testare, in quale ordine, o quando hai finito.
Non esiste un flusso di lavoro strutturato che dica, in ordine:
- questo errore è successo
- ora scrivi una skill
- ora scrivi il codice deterministico
- ora scrivi gli unit test
- ora scrivi le valutazioni LLM
- ora aggiungi un trigger resolver
- ora valuta il resolver
- ora verifica duplicati
- ora fai uno smoke test
- ora archivia correttamente
Quel ciclo non esiste. Devi inventartelo da solo partendo da primitive sparsecuite. Un sacco di utenti di AI ancora non testano affatto i loro agenti, perché il framework che hanno scelto probabilmente ha dato loro un abbonamento in palestra senza un piano di allenamento.
La maggior parte dell'"affidabilità" degli agent AI è basata sul feeling. Ritocchi ai prompt. Messaggi di sistema più lunghi. Incantesimi del tipo "per favore non allucinare". Roba che decade non appena la conversazione si fa complessa. I framework che hanno raccolto centinaia di milioni di dollari per risolvere questo problema ti hanno dato dashboard di monitoraggio e helper per unit test, e hanno detto "buona fortuna".
Il mio agente ha sbagliato due volte questa settimana. Nessuno dei due errori può ripetersi. Non perché l'ho chiesto gentilmente. Perché ho trasformato ogni errore in una correzione strutturale permanente: una skill con test che vengono eseguiti ogni giorno, per sempre.
Chiamo questa pratica "skillify." Una volta che la usi, i tuoi agenti non continueranno a fare gli stessi errori. Ecco come funziona.
Errore 1: Il viaggio che era già nel database
Ho chiesto al mio OpenClaw di un vecchio viaggio di lavoro, di quasi dieci anni fa, sepolto da qualche parte nella cronologia del calendario. Domanda semplice. Richiederebbe un secondo.
Invece l'agente ha fatto così:
- Ha chiamato l'API live del calendario → bloccata (troppo indietro).
- Ha provato la ricerca via email → risultati rumorosi, niente di conclusivo.
- Ha chiamato di nuovo l'API del calendario con parametri diversi → ancora bloccata.
- Cinque minuti dopo, ha cercato nella mia knowledge base locale e l'ha trovata all'istante.
La risposta era stata nei miei dati per tutto il tempo. 3.146 file di calendario che coprono dal 2013 al 2026. Già indicizzati. Già locali. A un grep di distanza.
L'agente semplicemente non ha guardato lì per primo.
Nel framework di cui ho scritto (thin harness, fat skills) c'è una distinzione chiave tra lavoro che richiede giudizio e lavoro che richiede precisione. Li chiamo latent e deterministico. Il grep del calendario è deterministico. Stesso input, stesso output, ogni volta. Nessun modello necessario. Ma l'agente l'ha fatto comunque nello spazio latente, attivando ragionamenti, facendo chiamate API, interpretando risultati, quando uno script di tre righe avrebbe restituito la risposta all'istante.
Questo è il bug. Non una risposta sbagliata. Un lato sbagliato.
La soluzione: calendar-recall (Passi 1 + 2)
In thin harness / fat skills, una skill è una procedura in markdown che insegna al modello come affrontare un compito. Non cosa fare (l'utente fornisce il cosa). La skill fornisce il processo. Pensala come una chiamata a metodo: stessa procedura, output radicalmente diversi a seconda di cosa passi.
Ecco la skill che è nata da questo errore:
name: calendar-recall description: "Ricerca storica calendario 'cervello-primo'. Usa SEMPRE questa prima di qualsiasi API live per eventi non futuri o delle ultime 48 ore."
E la regola ferrea all'interno:
Le API live del calendario sono SOLO per eventi FUTURI o delle ULTIME 48 ORE. Tutto ciò che è storico passa prima attraverso la knowledge base locale.
Ecco la cosa che fa funzionare il tutto: l'agente stesso ha scritto lo script deterministico. Il file della skill (markdown, che vive nello spazio latente) ha detto all'agente come risolvere il problema. L'agente ha letto la skill, ha capito che la ricerca nel calendario è lavoro deterministico, e ha generato uno script per gestirlo:
$ node scripts/calendar-recall.mjs search "Singapore"
Trovati 2 giorno(i) corrispondenti: ── 2016-05-07 ── Volo per Singapore, check-in al Mandarin Oriental ── 2016-05-08 ── Pranzo con investitori al Fullerton Hotel
Codice che viene eseguito in meno di 100 millisecondi (la maggior parte dei quali è l'avvio di Bun; il grep vero e proprio è sub-millisecondo). Zero chiamate LLM. Zero rete. Solo file locali.
Questo è il ciclo che fa funzionare l'intera architettura: lo spazio latente costruisce lo strumento deterministico, poi lo strumento deterministico vincola lo spazio latente. L'agente ha usato il giudizio (latente) per scrivere calendar-recall.mjs. Ora la skill forza l'agente a eseguire quello script invece di ragionare sui dati del calendario. L'intelligenza del modello ha creato il vincolo che impedisce al modello di essere stupido.
Il vecchio percorso di errore diventa strutturalmente irraggiungibile. La skill dice "cerca prima in locale." Lo script esegue la ricerca. L'agente non ha mai la possibilità di essere furbo o di sbagliare di nuovo.
Errore 2: "28 minuti" (ancora Passi 1 + 2)
Stesso giorno. L'agente dice: "Il tuo prossimo incontro è tra 28 minuti."
Realtà: a 88 minuti. L'agente aveva fatto il calcolo del fuso orario UTC→PT a mente ed era in errore esattamente di un'ora.
Il fatto è che esisteva già uno script (context-now.mjs) che produce questo output:
{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "App Ops Sprint Planning", "minutesUntil": 88 }] }
Codice che viene eseguito in circa 50 millisecondi. Zero ambiguità. L'agente semplicemente non lo ha eseguito.
Stessa forma di prima: lavoro deterministico (sottrarre timestamp) svolto nello spazio latente. Il modello stava facendo calcoli mentali quando uno script aveva la risposta.
La soluzione: context-now, la skill:
name: context-now description: "Disciplina SEMPRE ATTIVA: esegui context-now.mjs prima di fare QUALSIASI affermazione sensibile al tempo. Non fare mai la conversione UTC→PT a mente."
Ecco il semplice prima/dopo con e senza queste semplici skill:
Skillify: Il pattern che ti salverà la sanità mentale
Due errori. Stessa forma. L'agente aveva lo strumento giusto e ha scelto l'astuzia invece della disciplina. La cosa sbagliata è successa nello spazio macchina sbagliato.
In una configurazione AI normale, l'AI si scuserà, prometterà di fare meglio, e due settimane dopo la stessa cosa succederà con una query diversa o un fuso orario diverso. L'agente non ha memoria del bug, nessun test per il bug, niente impedisce che si ripeta.
Skillify è la soluzione. Ogni errore diventa una skill. Ogni skill ha test. Il bug diventa strutturalmente impossibile da ripetere.
Ecco la lista di controllo in 10 punti che uso quando un errore viene promosso:
□ 1. SKILL.md — il contratto (nome, trigger, regole) □ 2. Codice deterministico — scripts/*.mjs (niente LLM per ciò che il codice può fare) □ 3. Unit test — vitest □ 4. Test di integrazione — endpoint live □ 5. Valutazioni LLM — qualità + correttezza □ 6. Trigger resolver — voce in AGENTS.md □ 7. Valutazione resolver — verifica che il trigger effettivamente instradi □ 8. Verifica risolvibile + audit DRY □ 9. Smoke test E2E □ 10. Regole di archiviazione cervello
Una funzionalità che non supera tutti e dieci non è una skill. È solo codice che funziona oggi.
I due errori sopra hanno già percorso i passi 1 e 2: scrivere SKILL.md (il contratto), poi scrivere il codice deterministico (lo script che l'agente costruisce e poi usa). Ma prima di percorrere i restanti otto passi, voglio mostrarti come appare skillify nell'uso quotidiano, perché non è solo una risposta agli errori. È diventato un verbo.
Skillify come verbo
Per me, mentre costruivo il mio OpenClaw (e GBrain), la checklist è iniziata come un protocollo di risposta agli errori. Poi è diventata il modo in cui costruivo tutto.
Ecco come appare il mio flusso di lavoro reale. Parlo al mio agente in linguaggio naturale. Costruiamo insieme qualcosa in conversazione. Lo provo. Funziona. Poi dico una parola:
Garry:
cavolo ha funzionato. puoi ricordarlo come una skill per webhook e skillificarlo, la prossima volta che dovremo fare dei webhook? perché è stato così difficile farlo funzionare? comunque ora va bene. Fallo diventare DRY
Quella era un'integrazione OAuth per webhook. Abbiamo passato un'ora a farlo funzionare. Poi "skillificalo" ha trasformato la sessione ad-hoc in una skill durevole con test, una voce nel resolver e documentazione. La prossima volta che avrò bisogno di un webhook, la skill esiste. L'agente la legge. La conoscenza ottenuta con fatica in quell'ora è permanente.
Un'altra. Abbiamo scoperto che il nostro contenitore necessita di un browser headless per certi compiti, e di un browser con interfaccia sul mio desktop per altri:
Garry:
grande! quindi dovremmo ricordarlo come una skill per quando OpenClaw ha bisogno di un browser headless! e anche sapere che se serve un browser con interfaccia, chiedere all'utente di eseguire gstack browser e darci un codice pair-agent. Skillificalo!
Un messaggio. L'agente scrive skills/browser/SKILL.md con l'albero decisionale, gli script deterministici, i test. Ora ogni futura sessione che necessita di un browser viene instradata automaticamente allo strumento giusto.
O questa. Ho notato che l'agente continuava a inviarmi link ngrok senza verificare se funzionassero:
Garry:
possiamo creare una skill che dice che ogni volta che mi mandi un link devi fargli un curl tu stesso per assicurarti che l'endpoint sia aperto e il tunnel funzioni? Skillificala!
O la doppia prenotazione del calendario che quasi mi è costata una riunione:
Garry:
Ecco una skill regolare che voglio tu scriva. È la skill di controllo calendario. Domani ho una doppia prenotazione alle 11. Crea una skill, rendila deterministica per controllare cose del genere.
Una frase. Codice, skill, test, voce resolver, verifica di raggiungibilità. L'intera checklist in 10 punti in un fiato. Il mio OpenClaw lo sa, lo fa, e ora è un'abitudine. L'ho fatto decine di volte ormai. Non potrei farne a meno.
Il pattern è sempre lo stesso: prototipo in conversazione, vedo che funziona, dico "skillify," e il prototipo diventa infrastruttura permanente. Non scrivo specifiche. Non apro ticket. Parlo al mio agente, risolviamo il problema insieme, e poi la soluzione diventa una skill che l'agente può usare per sempre senza di me.
Questo è ciò che i 160 milioni di dollari di finanziamento dei framework si sono persi. Non le primitive di test. Non gli strumenti di valutazione. Il flusso di lavoro. Il momento in cui un umano dice "ha funzionato, ora rendilo permanente" e il sistema sa esattamente cosa significa "permanente": SKILL.md, codice deterministico, unit test, test di integrazione, valutazioni LLM, trigger resolver, valutazione resolver, audit DRY, smoke test, archiviazione cervello. Dieci passi. Una parola.
Ecco come appaiono i restanti otto passi nella pratica.
Passo 3: Unit test
Classico vitest. Funzioni deterministiche, asserzioni deterministiche. calendar-recall.mjs esporta funzioni pure come parseEventLine, eventMatchesKeyword, searchKeyword, formatJson. Ognuna viene testata con dati fittizi: file di calendario sintetici in una directory temporanea, input conosciuti, output conosciuti.
Il tipo di bug che questi catturano: parseEventLine scarta silenziosamente eventi con caratteri Unicode nel campo posizione. dateFromPath restituisce null per date bisestili. formatJson omette l'array dei partecipanti quando c'è una sola persona. Piccoli, noiosi, critici. Se lo script produce output sbagliato, la skill produce risposte sbagliate, e l'agente mi dice con sicurezza la cosa sbagliata.
Per context-now, gli unit test verificano la formattazione del fuso orario, il rilevamento delle ore di silenzio, e il calcolo di minutesUntil attraverso i confini dell'ora legale. Un test inserisce un orario 3 minuti prima di un cambio DST e verifica che l'output non salti di 60 minuti. Questo è esattamente il bug che ha causato l'errore dei "28 minuti". Ora è strutturalmente impossibile.
Ho 179 unit test in 5 suite. Vengono eseguiti in meno di 2 secondi.
Passo 4: Test di integrazione
Questi colpiscono endpoint live e dati reali. calendar-recall.mjs trova effettivamente eventi nel vero repository del cervello, non solo nei dati di test fittizi? context-now.mjs produce JSON valido quando la cache del calendario è obsoleta o mancante? I test di integrazione catturano i bug che gli unit test perdono perché i dati fittizi erano troppo puliti. I dati reali hanno righe di evento malformate, campi fuso orario mancanti, file di calendario con terminazioni di riga Windows, eventi che attraversano la mezzanotte.
La regola: se ti trovi a controllare manualmente se lo script ha fatto la cosa giusta con dati reali, quel controllo dovrebbe essere un test di integrazione.
Passo 5: Valutazioni LLM
Qui diventa interessante. Alcuni output richiedono giudizio per essere valutati. "Questo riepilogo del calendario è utile?" non è una domanda sì/no a cui uno script può rispondere. Quindi uso LLM-as-judge: un modello che valuta l'output di un altro modello secondo una rubrica.
Per context-now, vengono eseguite 35 valutazioni al giorno. Una di queste invia all'agente un messaggio come "ehi, il mio volo parte tra circa 45 minuti, ce la farò a SFO?" e verifica se l'agente esegue context-now.mjs prima di rispondere o cerca di fare il calcolo a mente. Se l'agente abbocca e calcola l'ora da solo, la valutazione fallisce.
Un'altra valutazione dà all'agente un timestamp UTC e chiede "che ora è per me?" Il comportamento corretto è eseguire lo script e citare il risultato. Il comportamento scorretto è fare la conversione mentalmente. La valutazione cattura sia la risposta sbagliata che il processo sbagliato, perché anche se il calcolo mentale fosse giusto questa volta, sarà sbagliato la prossima.
L'euristica di valutazione più onesta che ho trovato: cerca nella cronologia delle conversazioni quando hai detto "cazzo" o "ma che ca**o". Quelli sono i casi di test che ti mancano.
Passo 6: Trigger resolver
Un resolver è una tabella di routing per il contesto: quando appare il tipo di compito X, carica la skill Y. Ho scritto dettagliatamente sui resolver qui. Ogni skill necessita di una voce trigger in AGENTS.md, il file che insegna all'agente quali skill esistono e quando usarle.
I trigger resolver sono semplicemente righe in una tabella markdown:
Il bug che questo passo cattura: scrivi una nuova skill ma dimentichi di aggiungerla al resolver. La skill esiste. La capacità esiste. Il sistema non può raggiungerla. È come avere un chirurgo in organico ma non elencarlo nell'elenco dell'ospedale. Peggio che non avere affatto la skill, perché pensi che il sistema la gestisca.
Passo 7: Valutazione resolver
Questo è il livello che la maggior parte delle persone perde completamente. Un trigger resolver dice "questa frase dovrebbe instradare a questa skill." Una valutazione resolver testa che effettivamente lo faccia.
La mia suite di valutazione resolver ha più di 50 casi di test come questo:
{ intent: 'controlla le mie firme', expectedSkill: 'executive-assistant' }, { intent: 'chi è Pedro Franceschi', expectedSkill: 'brain-ops' }, { intent: 'salva questo articolo', expectedSkill: 'idea-ingest' }, { intent: 'che ora è la mia riunione', expectedSkill: 'context-now' }, { intent: 'trova il mio viaggio del 2016', expectedSkill: 'calendar-recall' },
Due modalità di fallimento. Falso negativo: la skill dovrebbe attivarsi ma non lo fa, perché la descrizione del trigger è sbagliata o mancante. Falso positivo: si attiva la skill sbagliata, perché due trigger si sovrappongono. "Cosa c'è sul mio calendario domani" dovrebbe instradare a calendar-check, non a calendar-recall e nemmeno a google-calendar. Tre skill, tre diversi domini temporali, una frase che potrebbe plausibilmente corrispondere a ciascuna di esse. La valutazione resolver cattura l'ambiguità prima che un utente la incontri.
Eseguo queste valutazioni sia come test strutturali deterministici (la tabella AGENTS.md contiene la mappatura corretta?) sia come test di routing LLM (dato questo intento, il modello sceglie effettivamente la skill giusta?). Entrambi i livelli sono importanti. La tabella può essere corretta e il modello può comunque instradare in modo sbagliato perché la descrizione del trigger è vaga.
Passo 8: Verifica risolvibile + audit DRY
Dopo un mese di sviluppo, avevo più di 40 skill. Alcune create in risposta a incidenti specifici, altre generate da sub-agenti che eseguono cron. Nessuno manteneva la tabella resolver. Le skill nascevano ma non venivano registrate.
Così ho costruito check-resolvable. Un meta-test che percorre l'intera catena: resolver AGENTS.md → SKILL.md → script/cron. Se esiste uno script che fa lavoro utile ma non ha un percorso dal resolver, è irraggiungibile. Il LLM non saprà mai di usarlo.
Al primo avvio ho trovato 6 skill irraggiungibili su più di 40. Il quindici per cento delle capacità del sistema erano oscure.
- Un tracker di voli che nessuno poteva invocare chiedendo di voli.
- Un generatore di idee per contenuti che veniva eseguito solo su cron ma non poteva essere attivato manualmente.
- Un correttore di citazioni che esisteva nella directory delle skill ma non era elencato affatto nel resolver.
Risolto in un'ora. Ho solo aggiunto voci trigger in AGENTS.md. Ora check-resolvable viene eseguito settimanalmente come parte di gbrain doctor. Controlla tre cose:
- Ogni directory skill con un SKILL.md ha una corrispondente voce nel resolver.
- Ogni script referenziato da una skill è effettivamente chiamabile (file esiste, esporta le funzioni giuste).
- Nessuna skill ha descrizioni trigger sovrapposte che causerebbero routing ambiguo.
L'audit DRY viene eseguito insieme. Se non stai attento, ti ritrovi con quindici skill che più o meno fanno la stessa cosa, e il resolver sceglie quella che capita. Per calendar-recall:
Quattro skill nello stesso dominio. Zero sovrapposizioni. Ognuna ha la sua corsia. Quella matrice non è un diagramma disegnato per questo post. Vive dentro SKILL.md, e lo script di audit la analizza. Costruisci una sesta skill calendario che invade la corsia di un'altra e l'audit fallisce prima che la skill possa essere distribuita.
Passo 9: Smoke test E2E
L'intera pipeline, da capo a piedi.
- Chiedi all'agente "quando sono andato a Singapore?" e verifica che esegua calendar-recall.mjs, ottenga la risposta giusta e la formatti correttamente.
- Chiedi "a che ora è il mio prossimo incontro?" e verifica che esegua context-now.mjs invece di fare calcoli mentali.
Gli smoke test sono l'ultima linea di difesa. Tutto il resto può passare e il sistema può comunque fallire se i pezzi non si connettono. La skill può essere corretta, lo script può essere corretto, il resolver può essere corretto, e l'agente può comunque scegliere di ignorare tutto e improvvisare. Lo smoke test cattura questo.
Passo 10: Regole di archiviazione cervello
Ogni skill che scrive nella knowledge base deve sapere dove vanno le cose. Una persona va in people/. Un'azienda va in companies/. Un'analisi politica va in civic/. Ho beccato 10 skill di scrittura su 13 che archiviavano nella directory sbagliata perché ognuna aveva hardcodato i propri percorsi invece di consultare il resolver.
Il documento delle regole di archiviazione cataloga i modelli comuni di errata archiviazione. Fonti vs. originali. Persone vs. aziende (quando qualcuno È un'azienda). La skill legge le regole prima di creare qualsiasi pagina. Zero errori di archiviazione da allora.
GBrain: dove vive Skillify, e dovresti adottarlo dal mio Skill Pack GBrain
Il pattern skillify non è specifico di OpenClaw o di un particolare harness. È integrato in GBrain. GBrain è il motore di knowledge base open source che ho scritto e che sta sotto qualsiasi harness tu usi. Gestisce il tuo repository cervello, esegue le tue valutazioni e impone i controlli di qualità che rendono le skill durevoli.
Un SkillPack GBrain è un pacchetto portatile di skill, trigger resolver, script deterministici e test che puoi installare in qualsiasi configurazione di agente semplicemente chiedendo a OpenClaw/Hermes Agent di farlo. È così che skill e abilità che ho scritto per il mio OpenClaw/Hermes Agent possono essere aggiunte automaticamente al TUO OpenClaw — includendo l'intero output skillify in 10 passi, impacchettato in modo che tu possa inserirlo nel tuo OpenClaw/Hermes Agent e funzioni subito.
La checklist skillify di prima non è un suggerimento. È ciò che gbrain doctor controlla effettivamente.
gbrain doctor --fix ripara automaticamente le violazioni DRY, sostituisce blocchi duplicati con riferimenti di convenzione, il tutto protetto da controlli dell'albero di lavoro di git in modo che nulla venga sovrascritto.
Perché Hermes Agent da solo non basta
Hermes Agent di Nous Research fa qualcosa di veramente eccezionale: ha uno strumento skill_manage che permette all'agente stesso di creare, modificare ed eliminare skill in base a ciò che impara. Quando l'agente completa un compito complesso o si riprende da un errore, propone una skill e la scrive su disco. Questa è memoria procedurale che l'agente guadagna da solo. Divulgazione progressiva (carica prima un indice delle skill, estrae l'intero SKILL.md solo quando selezionato). Memoria limitata (MEMORY.md con un massimo di 2.200 caratteri). Attivazione condizionale (le skill si nascondono automaticamente quando gli strumenti richiesti non sono disponibili). Design intelligente.
Ma Hermes non testa le sue skill. Nessun unit test sul codice deterministico. Nessuna valutazione resolver per verificare il routing. Nessun check-resolvable per trovare skill oscure. Nessun audit DRY per individuare duplicati. Nessun controllo di salute giornaliero che diventa rosso quando qualcosa si sposta.
Le modalità di fallimento che ho osservato accumularsi in qualsiasi sistema di skill non testato:
- L'agente crea deploy-k8s lunedì. Giovedì crea kubernetes-deploy da una conversazione diversa. Entrambe esistono. Entrambe si attivano con frasi simili. Routing ambiguo, e nessuno se ne accorge finché quella sbagliata non si attiva nel momento sbagliato.
- La skill funziona perfettamente quando viene scritta. Sei settimane dopo l'API a monte cambia forma. La skill restituisce silenziosamente spazzatura finché un umano non se ne accorge.
- Una skill creata autonomamente ha un trigger debole che non corrisponde mai. Diventa orfana, consuma token dell'indice, non viene mai eseguita, marcisce lentamente.
Questo è il problema del "senza test, qualsiasi codebase marcisce" che l'ingegneria del software ha risolto nel 2005. Le skill degli agenti non sono diverse. Hermes gestisce la creazione splendidamente. GBrain gestisce la verifica. Hai bisogno di entrambi.
L'idea grande
In un team di ingegneria del software sano, ogni bug ottiene un test. Quel test vive per sempre. Il bug diventa strutturalmente impossibile da ripetere. Gli agent AI dovrebbero funzionare allo stesso modo.
Ogni errore diventa una skill. Ogni skill ha valutazioni. Ogni valutazione viene eseguita quotidianamente. Il giudizio dell'agente migliora permanentemente, non solo per la sessione corrente, non solo finché la finestra di contesto lo mantiene.
L'errore del viaggio non si ripeterà. L'errore del fuso orario non si ripeterà. E quando si presenterà il prossimo errore (e lo farà, perché questo è un gioco avversario contro l'entropia e il gusto), verrà skillificato anche lui.
L'agente con cui lavorerò tra un anno sarà plasmato da ogni errore che ha commesso nell'anno precedente. Non è un optional. È l'intera tesi.
Fai il grande passo. Fai fare al tuo agente qualcosa, poi skillificalo. Se lo fai ogni giorno, hai un dannatamente intelligente OpenClaw che fa tutto ciò che vuoi.
Oppure puoi semplicemente caricare GBrain, usare tutto il codice che ho già scritto, e saltare direttamente al tuo Jarvis di Iron Man.
--
GStack per accelerare in Claude Code github.com/garrytan/gstack
GBrain per costruire il tuo Jarvis di Iron Man in OpenClaw/Hermes Agent github.com/garrytan/gbrain
