Una skill è un pacchetto che descrive come usare un servizio o una famiglia
di funzioni. Il suo punto d'ingresso è SKILL.md; il pacchetto può
includere anche script e riferimenti necessari all'esecuzione. Metnos non lo
esegue direttamente: lo traduce in executor con nomi, argomenti, capacità e
provenienza espliciti.
Il file contiene un'intestazione con i metadati e un corpo leggibile, nel quale trovano posto funzioni, prerequisiti, comandi ed esempi. Il parser ne ricava una struttura controllabile; non considera la prosa un'autorizzazione ad ampliare il vocabolario o le capacità del sistema.
Metnos può importare il sorgente di una skill: legge il file, ne ricava una serie di executor nel proprio formato e sottopone ciascuno ai controlli di ammissione. Quelli ammessi entrano nello stesso catalogo degli altri executor e possono essere richiamati in linguaggio naturale; il manifest continua però a registrarne l'origine esterna.
Un file SKILL.md non porta con sé la firma e il contratto di un
executor Metnos. L'importazione genera un wrapper, dichiara capacità e
argomenti nel manifest, applica i controlli di ammissione e firma il risultato.
Questo riduce e rende osservabile l'autorità concessa, ma non certifica come
innocuo il codice di terzi: provenienza e sorgente restano da valutare.
Il comando di importazione avvia una sequenza di passaggi distinti. Questa separazione è importante: una traduzione riuscita non equivale ancora all'ammissione nel catalogo.
SKILL.md.azione_oggetto_qualificatore. Il nome del
fornitore qualifica gli executor importati e le collisioni interne alla skill
vengono rifiutate.La traduzione di nomi e argomenti è procedurale rispetto alla sorgente e al vocabolario correnti. L'intera importazione, invece, non promette un output identico byte per byte: la provenienza contiene l'istante di importazione, le descrizioni possono essere generate da un modello e l'ammissione dipende dal catalogo già installato e dal verificatore semantico disponibile.
Metnos accetta soltanto azioni e oggetti definiti nel vocabolario del
runtime. Una skill che parla di append rows to spreadsheet non può
inventare append_rows: deve essere ricondotta a un nome canonico
compatibile. Se non esiste una corrispondenza semanticamente corretta, il
sotto-comando viene rifiutato. In questo modo sinonimi e formule proprie della
skill non introducono nuovi verbi in modo implicito.
La skill può arrivare da tre posti:
SKILL.md o una cartella che lo
contiene. Gli eventuali scripts/ e references/ adiacenti
vengono conservati insieme alla sorgente.agentskills.io/<autore>/<skill>; l'importatore
lo risolve nel file SKILL.md pubblicato nella radice del
repository atteso.Se una skill invoca script propri, occorre quindi importare una cartella locale completa o il repository, non il solo file raw. Le sorgenti remote sono conservate nella cache locale per un massimo predefinito di sette giorni; l'operatore può forzare un nuovo recupero.
La sorgente viene conservata separatamente dagli executor generati. Con i percorsi predefiniti, entrambi gli alberi appartengono all'utente che esegue l'importazione:
~/.local/share/metnos/skills/google-workspace/ SKILL.md scripts/ references/ ~/.local/share/metnos/executors/skills/google-workspace/ read_events_google_workspace/ read_events_google_workspace.py manifest.toml manifest.lang_state.json manifest.toml.sig send_messages_google_workspace/ …
Prima della firma, ogni cartella contiene tre file generati: wrapper,
manifest e stato linguistico. La firma aggiunge
manifest.toml.sig. Script e riferimenti restano nel pacchetto
sorgente e vengono richiamati dal wrapper. I vincoli della sandbox sono
applicati dal runtime a partire dal contratto e dalle capacità dichiarate,
senza un altro file per executor.
Il manifest conserva il legame con la sorgente:
[provenance] synthesized = true imported_from = "<origine della skill>" source_version = "1.1.0" source_section = "<sezione>" source_subcommand = "calendar list" imported_at = "<istante UTC>" source_sha256 = "<impronta del file SKILL.md>" importer_version = "<versione>"
Posizione, provenienza, sorgente conservata e audit distinguono un executor importato da uno curato direttamente nel prodotto. Firma, contratto e policy di esecuzione sono invece requisiti comuni: la provenienza non sostituisce nessuno di questi controlli.
La pipeline separa i rifiuti di traduzione da quelli di ammissione. Il registro finale riporta entrambe le categorie.
| Passaggio | Cosa verifica | Esito negativo |
|---|---|---|
| Confine del verbo | L'azione della sorgente ha una corrispondenza semanticamente valida nel vocabolario chiuso. | Il sotto-comando non produce alcun piano. |
| Nome e collisioni | Il nome composto è canonico, qualificato dal fornitore e distinto dagli altri nomi della stessa skill. | Il traduttore registra il motivo del rifiuto. |
| Unicità del binding | Il binding della skill non appartiene già a un'altra importazione. | L'intera skill viene rifiutata. |
| L1 — vocabolario | Azione, oggetto e qualificatori del piano appartengono al vocabolario corrente. | Il singolo piano viene rifiutato. |
| L2 — affinità | L'affinità canonica non si sovrappone oltre la soglia agli executor già installati; il binding esplicito consente una soglia distinta. | Il singolo piano viene rifiutato come possibile doppione. |
| L5 — instradamento | Quando esistono una domanda prototipica e un runner disponibile, l'asserzione deve scegliere l'executor atteso. | Un'asserzione eseguita e fallita rifiuta il piano; un caso non mappato o non eseguibile viene saltato. |
| L6 — coerenza semantica | Il verificatore confronta manifest e codice generato. | Una divergenza, un errore o l'indisponibilità del verificatore rifiutano il piano nel flusso ordinario. |
I piani indipendenti possono avere esiti diversi: quelli rifiutati vengono rimossi e gli altri proseguono. La collisione globale del binding costituisce l'eccezione e interrompe l'intera importazione. Le opzioni che saltano L2, L5 o L6 servono a sviluppo e CI; usarle riduce le garanzie e non equivale a una certificazione per l'esercizio.
Il report dell'importazione è l'autorità per quella specifica esecuzione: elenca piani tradotti, nomi accettati e rifiuti con le rispettive motivazioni. Un nome accettato non dimostra, da solo, che ogni possibile asserzione L5 sia stata eseguita, perché alcuni pattern ammettono esplicitamente lo skip.
L'importazione non raccoglie credenziali. Se, durante l'uso, un fornitore
segnala che manca l'autenticazione, il wrapper generato restituisce
decision = "needs_inputs" e conserva gli argomenti necessari a
riprendere l'operazione.
~/.config/metnos/credentials/.0600.I collegamenti e i valori delle credenziali sono isolati per utente. Il
manifest dichiara soltanto il nome del binding e lo schema del dialogo: i
segreti non entrano nel manifest, nel codice generato o nel testo inviato al
pianificatore. Gli executor find_credentials,
set_credentials e
delete_credentials espongono rispettivamente metadati, scrittura
protetta e cancellazione; le loro risposte al pianificatore non contengono i
valori in chiaro.
Chiedi a Metnos con una richiesta come quella di questo esempio: «Che appuntamenti ho domani nel calendario di lavoro?» Se la capacità Google Workspace è ammessa, abilitata e collegata all'account dell'utente, il catalogo rende disponibile l'executor specifico per gli eventi. Altri esempi sono «Trova le email non lette di Anna», «Leggi il contenuto di questo file su Drive» e «Aggiungi queste righe al foglio Spese».
L'importazione è un'operazione amministrativa distinta. Il pacchetto Google Workspace incluso con Metnos contiene anche gli script necessari, per cui il comando usa la cartella completa:
metnos-skills import <install-root>/executors/skills/google-workspace
La sorgente dichiara 24 sotto-comandi. La verifica procedurale corrente dimostra 24 piani canonici distinti e nessun rifiuto di traduzione. Alcune distinzioni semantiche decisive sono:
| Sotto-comando | Executor canonico | Distinzione |
|---|---|---|
gmail send | send_messages_google_workspace | nuovo messaggio |
gmail reply | send_messages_thread_google_workspace | risposta entro una conversazione |
gmail labels | list_messages_labels_google_workspace | elenco delle etichette, non modifica dei messaggi |
drive get | get_files_google_workspace | metadati del file |
drive download | read_files_google_workspace | contenuto del file |
sheets update | set_files_xlsx_google_workspace | aggiornamento di celle esistenti |
sheets append | write_files_xlsx_google_workspace | scrittura di nuove righe |
Il dato 24/24 riguarda traduzione, unicità dei nomi e generazione dei manifest. Non autorizza a dichiarare in anticipo «24 ammessi»: L2 confronta il catalogo dell'utente, L5 dipende dalle prove eseguibili e L6 dal verificatore semantico. Il report prodotto da quella importazione indica quanti executor sono stati accettati; soltanto quelli firmati e validi possono entrare nel catalogo. L'autorizzazione OAuth avviene poi per il singolo utente e non fa parte del conteggio di importazione.
Importare una skill non significa attestare che il suo codice sia innocuo. L'importatore controlla il wrapper e il contratto che genera, ma non esegue un'analisi statica completa di ogni script ricevuto. Prima dell'importazione l'operatore deve verificare origine e impronta, leggere gli script e concedere soltanto capacità e credenziali necessarie.
| Controllo | Momento | Garanzia effettiva |
|---|---|---|
| Provenienza e impronta | acquisizione | collegano l'artefatto alla sorgente esaminata; non ne provano la sicurezza |
| Contratto generato | generazione | rende espliciti argomenti, output, capacità, credenziali e provenienza |
| L1, L2, L5, L6 | ammissione | limitano nomi estranei, sovrapposizioni, errori di instradamento e divergenze semantiche |
| Digest e firma Ed25519 | caricamento del catalogo | impediscono di caricare artefatti mancanti, alterati o non firmati validamente |
| Sandbox, capacità, policy e vaglio | invocazione | limitano l'autorità concreta e applicano le decisioni richieste dal rischio dell'azione |
| Archivio delle credenziali per utente | autenticazione e uso | separa i collegamenti e non espone i segreti al pianificatore |
| Audit e statistiche di efficacia | dopo l'invocazione | registrano uso ed esito e alimentano i controlli del ciclo di vita |
Gli executor curati direttamente da Metnos seguono revisione, prove, firma e policy del rilascio; quelli importati aggiungono provenienza, ammissione e audit specifici. Nessuna delle due origini è «fidata per definizione». Nel flusso ordinario, inoltre, L6 non approva quando il verificatore è indisponibile: il piano viene rifiutato con un motivo esplicito.
| Per capire… | Leggi |
|---|---|
| cos'è un executor e come è fatto | Executor |
| come servizi, skill e backend determinano la disponibilità | Skill, servizi e backend |
| come Synt genera un nuovo executor | Synt |
| il recinto nel quale viene eseguito il codice | Sandbox |
| i controlli prima delle azioni rischiose | Vaglio |
Metnos — importazione delle skill