← Indice documentazione Architettura › skill & backend

Metnos

skill ↔ backend — due assi ortogonali

Architettura del confine fra skill e backend
Pubblico: chi vuole capire dove finisce un provider e dove comincia una skill.

Lettura: 12 minuti.

Indice

Due assi ortogonali
I tre tier di skill
Da un provider a molti
Lo spegni-accendi sta sul backend
Promozione: il meccanismo
Come fanno gli altri (Hermes, MCP)
Per andare più a fondo
E per te, in pratica?

1. Due assi ortogonali

In Metnos «skill» e «backend» rispondono a due domande diverse. Il backend dice COME si esegue un verbo_oggetto contro un servizio. La skill dice SE e QUALI capacità sono sbloccate, fidate e spedite. Confonderli porta a sdoppiare gli executor; tenerli separati è quel che permette di aggiungere un provider senza toccare il pianificatore.

	Backend / provider	Skill
Risponde a	COME eseguo `verbo_oggetto` contro un servizio	SE / QUALI capacità sono sbloccate, fidate, spedite
Asse	oggetto × provider	dipendenza esterna (credenziale / backend / hardware)
Visibilità	invisibile all'LLM, risolto da configurazione dal resolver dei backend	visibile all'utente (abilita / disabilita, dormienza, recinto, impacchettamento)

I due assi si toccano solo quando una skill ha un solo provider: in quel caso github, geo, mail sono di fatto il nome user-facing del backend di quel provider. Divergono appena la skill ha più backend (il calendario si serve su ICS locale, Google o CalDAV) o non ha alcun provider esterno (le foto, il nucleo). La mappa è molti-a-molti: un solo provider (Google Workspace) serve più skill — posta, calendario, drive, fogli, documenti.

Regola anti-duplicazione. La dipendenza esterna (credenziale, indirizzo di servizio, hardware) si dichiara una volta sola, al backend. La skill la aggrega — somma dei requisiti dei suoi backend — e non la ridichiara. La dormienza della skill è derivata dai suoi backend, non scritta a mano.

Figura 1 — I due assi. A sinistra l'esecuzione (planner → executor canonico → resolver → backend): invisibile all'LLM, risolta da configurazione. A destra le skill: accendono e spengono i backend, ma non cambiano il pool del pianificatore, che vede sempre find_issues.

2. I tre tier di skill

«Skill» ha finito per indicare tre cose diverse: una classificazione di executor già nel repository, dei pacchetti veri in repository, e codice di terzi importato. Il campo tier le unifica sotto un modello solo. Vive in skills_catalog.py (funzione skill_tier()) e nell'intestazione di SKILL.md.

Tier	Cos'è	Fiducia	Dove vive	Attivazione
1 — core	planner ed engine, file locali, cartelle, processi, tempo, scheduler locale, persone, credenziali, firme, proposte, gli helper dello scratchpad (filtra / ordina / raggruppa / calcola / descrivi / estrai)	massima	repository, firmato, multilingua	sempre attiva
2 — first_party	capacità spedite con Metnos allo stesso standard del nucleo, ma dormienti finché manca la dipendenza: github, foto, posta, web, geo, calendario, frontier, Google Workspace	massima	repository (pacchetto versionato + executor firmati)	automatica, dormiente se non configurata
3 — imported	codice di terzi non auditato né vendorizzato (da agentskills.io e simili)	bassa	dati utente, con provenienza tracciata	opt-in, recinto + rete a 7 strati

Cosa si spedisce al pubblico. Il rilascio porta con sé solo tier 1 e 2, dentro il repository firmato. Il tier 3 no: lo installa l'utente, e proprio a esso si applica la tesi-sicurezza del README («non fidarti del pacchetto»). La promozione tier 3→tier 2 richiede quattro sì congiunti: utile in generale, licenza compatibile, disponibilità a mantenerla (undo, i18n, ri-firma), e sostegno a una capacità già in catalogo.

3. Da un provider a molti

Domani potrebbe arrivare GitLab accanto a GitHub. La domanda è: come si aggiunge un secondo provider per le stesse issue? Due strade.

Opzione (a): sdoppiare l'executor — SCARTATA

Generare find_issues_github e find_issues_gitlab e lasciare che il pianificatore scelga. Funziona dove al centro c'è un modello frontier che disambigua leggendo la prosa. In Metnos il pianificatore è un modello locale, che davanti a due nomi quasi identici sviluppa un pregiudizio sul provider: sceglie sempre lo stesso, o sbaglia. Lo sdoppiamento rompe il routing.

Opzione (b): astrarre — SCELTA

Un executor canonico agnostico rispetto al provider: find_issues, read_issues, find_pulls. L'oggetto (issues, pulls) è l'astrazione stabile.
Un albero di backend per provider: runtime/backends/{issues,pulls}/{github,gitlab}.py.
Il resolver dei backend sceglie il provider dalla configurazione (mappa repository→provider, o per account), non dall'intento dell'utente.
Una skill per provider: skill github (PAT) e skill gitlab (token), con dormienza indipendente — perché la credenziale è il confine dove serve granularità («abilita gitlab» senza toccare github).
Il qualifier _github / _gitlab resta per il pin esplicito dell'utente («apri la issue su gitlab»); il default è agnostico.

Costo di un provider nuovo: +1 file backend, +1 skill (se introduce una credenziale nuova), 0 nuovi executor. È il percorso che calendario e file hanno già preso.

Figura 2 — Mono→multi provider. A sinistra lo stato «cotto» (find_issues_github + find_issues_gitlab confondono il planner locale). A destra lo stato astratto: un solo find_issues, il resolver, due backend. La freccia è la promozione: refactoring con frontier una-tantum, poi vaglio umano.

Debito noto. Oggi GitHub è «cotto»: i tredici executor *_github portano il provider nel nome. Funziona finché il provider resta unico; appena ne arriva un secondo va astratto. Regola generale: un provider che plausibilmente avrà fratelli (github→gitlab/gitea, posta IMAP, calendario) va astratto da subito; uno che resterà unico può restare cotto.

4. Lo spegni-accendi sta sul backend

Nel modello a più provider la skill non accende e spegne l'executor: accende e spegne il backend. Questo cambia chi vede cosa.

L'executor find_issues è disponibile se almeno uno dei suoi backend è abilitato e configurato; diventa dormiente solo se sono spenti tutti (un AND su tutti i backend).
La skill è un backend (il confine è la credenziale): skill accesa → quel backend entra nel pool del resolver.
Il resolver sceglie fra i backend accesi e configurati; è onesto (§2.8) se chiedi un provider la cui skill è spenta.

Effetto desiderato: accendere o spegnere un provider non cambia il pool di strumenti del pianificatore — vede sempre find_issues — cambia solo il routing. Disabilitare uno dei due: l'altro continua a servire. Disabilitarli entrambi: l'executor diventa dormiente.

Oggi il gating è per pattern sul nome dell'executor (skills_catalog): funziona solo finché il provider è unico. Il pezzo nuovo da costruire è una mappa skill→backend più la regola «executor dormiente = AND su tutti i suoi backend spenti». È il primo mattone: serve appena esiste il primo executor a più backend.

5. Promozione: il meccanismo

Fondere una skill mono-provider cotta (*_github) in find_issues + backend è un'operazione straordinaria. È ammesso un LLM frontier una-tantum SOLO per il refactoring; rilevamento e applicazione restano deterministici e con vaglio umano — firmare in automatico del codice generato da un frontier romperebbe la fiducia.

Fase	Chi	Cosa
QUANDO (trigger)	deterministico	all'arrivo del 2° provider — tipicamente l'import di una skill che mappa su un oggetto già coperto solo da executor provider-suffissati (`*_github`, riconosciuti dall'autorità di naming). Sovrapposizione di oggetto + provider diverso → «candidato a promozione». Nessun LLM per accorgersene.
DOVE (seam)	infrastruttura riusata	rilevamento nel layer di ammissione dell'importer; refactoring tramite l'escalation a un modello frontier in modo agentico; atterraggio nella pagina admin delle modifiche come modifica di tipo `promote_provider`, niente auto-apply; applicazione che scrive i file, ri-firma (§7.10), registra skill↔backend e gating per-backend (§4).
COME (pipeline)	frontier solo in mezzo	rileva (det.) → il frontier genera {executor canonico + `backends/<obj>/{p1,p2}.py` + mappa skill→backend} → la modifica viene proposta → vaglio umano → applica + firma + verifica con i 7 strati di ammissione + smoke.

Bordi deterministici, centro creativo. Il frontier sta solo nel mezzo: produce la bozza del refactoring. I bordi — accorgersi che serve, e applicare firmando — sono codice deterministico e mani umane. Tre pezzi nuovi, indipendenti e incrementali: (1) un rilevatore di candidati alla promozione; (2) il prompt di promozione per l'escalation al modello frontier; (3) il gating per-backend del §4 — che serve comunque, ed è il candidato da fare per primo.

6. Come fanno gli altri (Hermes, MCP)

Per capire perché Metnos separa skill e backend mentre gli altri li fondono, conviene guardare chi sta al centro a scegliere il provider.

	Hermes / skill drop-in	Claude-Code + famiglia MCP	Metnos
chi sceglie il provider	frontier (legge SKILL.md, disambigua)	frontier (legge le descrizioni dei tool)	modello locale medio (Gemma): ha un pregiudizio sul provider
skill vs backend	fusi (skill = cartella di script = provider)	fusi (tool / server MCP = provider)	separati (backend = esecuzione, skill = attivazione)
multi-provider	skill parallele per provider, l'agente sceglie	tool / server paralleli, il modello sceglie	un executor canonico + un backend per provider (resolver)
credenziale / dormienza	`required_credential_files` + setup	implicita (server connesso o no)	dormienza formalizzata
fiducia	esegue il codice della skill coi propri privilegi	esegue tool / server	vocabolario chiuso + recinto a 7 strati

Conseguenza obbligata, non un ritardo. Hermes e i cloni MCP mettono un frontier al centro: possono permettersi skill o tool paralleli per provider (opzione (a)), perché il modello disambigua dalla prosa. Metnos gira su modello locale, dove (a) genera pregiudizio sul provider → deve astrarre (opzione (b)). La separazione skill↔backend non è un ritardo dell'architettura: è la conseguenza inevitabile del pianificatore locale e del modello di sicurezza per costruzione.

7. Per andare più a fondo

Per capire…	Leggi
come si importa una skill di terzi e la si trasforma in executor firmati	skill importer
il recinto a strati in cui gli executor importati eseguono	sandbox
i controlli prima di ogni azione rischiosa	vaglio
cos'è un executor e com'è fatto	executor

8. E per te, in pratica?

E per te, in pratica? Dal tuo punto di vista, tutto questo cosa comporta? Non molto. Questa complessità vive sotto il cofano. La incontrerai soltanto quando userai funzioni che fanno la stessa cosa ma fornite da provider diversi — anzi, solo nel momento in cui aggiungerai il secondo provider per una stessa capacità: a quel punto basterà chiedere di «fondere» le due skill e Metnos creerà un nuovo backend. Sinceramente: quante volte ti capiterà, nell'uso quotidiano di uno strumento come Metnos? Quante volte userai contemporaneamente GitLab e GitHub?

Il lato positivo. Metnos nasce per restare il più possibile locale, senza costi aggiuntivi: il cervello che usi ogni giorno gira sulla tua macchina. Quella complessità di astrazione — fondere due skill in un backend — è l'unico momento in cui, e solo se serve, Metnos ricorre una tantum a un modello frontier (presumibilmente a pagamento) per generare il codice del nuovo backend. Un costo occasionale, esplicito e raro — non una dipendenza continua dal cloud. Per il resto, sei e resti locale.

Metnos — skill ↔ backend, due assi ortogonali