Skills

• Ometti agents.defaults.skills per lasciare tutte le skill senza limitazioni per impostazione predefinita.
• Ometti agents.list[].skills per ereditare agents.defaults.skills.
• Imposta agents.list[].skills: [] per non esporre alcuna skill a tale agente.
• Un elenco agents.list[].skills non vuoto costituisce l'insieme finale e non viene unito ai valori predefiniti.
• L'elenco di autorizzazione effettivo si applica alla creazione dei prompt, al rilevamento dei comandi slash, alla sincronizzazione della sandbox e alle istantanee delle skill.
• Questo non costituisce un confine di autorizzazione della shell host. Se lo stesso agente può usare exec, limita separatamente tale shell mediante sandboxing, isolamento dell'utente del sistema operativo, elenchi di autorizzazione/blocco per l'esecuzione e credenziali specifiche per risorsa.

Per impostazione predefinita, openclaw skills install installa nella directory skills/ dell'area di lavoro attiva. Aggiungi --global per installare nella directory condivisa ~/.openclaw/skills, visibile a tutti gli agenti locali salvo restrizioni imposte dagli elenchi di autorizzazione degli agenti.

Le installazioni da Git e da fonti locali richiedono SKILL.md nella directory radice della fonte. Lo slug deriva dal campo name del frontmatter di SKILL.md, se valido, e in caso contrario dal nome della directory o del repository. Usa --as <slug> per sostituirlo. openclaw skills update tiene traccia solo delle installazioni da ClawHub: reinstalla le fonti Git o locali per aggiornarle.

openclaw skills verify @owner/<slug> richiede a ClawHub il perimetro di attendibilità clawhub.skill.verify.v1 della skill. Le skill ClawHub installate vengono verificate rispetto alla versione e al registro riportati in .clawhub/origin.json. Gli slug senza proprietario restano accettati per le skill esistenti installate o non ambigue, ma i riferimenti qualificati con il proprietario evitano ambiguità sull'editore.

Le pagine delle skill di ClawHub mostrano lo stato dell'ultima scansione di sicurezza prima dell'installazione, con pagine dettagliate per VirusTotal, ClawScan e l'analisi statica. Il comando termina con un codice diverso da zero quando ClawHub contrassegna la verifica come non riuscita. Gli editori possono risolvere i falsi positivi tramite la dashboard di ClawHub o clawhub skill rescan @owner/<slug>.

I client Gateway che richiedono una distribuzione esterna a ClawHub possono preparare un archivio ZIP della skill con skills.upload.begin, skills.upload.chunk e skills.upload.commit, quindi installarlo con skills.install({ source: "upload", ... }). Questo percorso è disattivato per impostazione predefinita e richiede skills.install.allowUploadedArchives: true in openclaw.json. Le normali installazioni da ClawHub non richiedono mai tale impostazione.

Il rilevamento delle skill dell'area di lavoro, dell'agente del progetto e delle directory aggiuntive accetta solo directory radice delle skill il cui percorso reale risolto rimane all'interno della directory radice configurata, a meno che skills.load.allowSymlinkTargets non consideri esplicitamente attendibile una directory radice di destinazione. Il Laboratorio delle skill scrive attraverso tali destinazioni attendibili solo quando skills.workshop.allowSymlinkTargetWrites è abilitato. Le directory gestite ~/.openclaw/skills e personali ~/.agents/skills possono contenere cartelle di skill collegate simbolicamente, ma il percorso reale di ogni SKILL.md deve comunque rimanere all'interno della relativa directory della skill risolta.

Configura security.installPolicy per eseguire un comando locale attendibile relativo ai criteri prima di proseguire con l'installazione delle skill. Il criterio riceve i metadati e il percorso della fonte preparata, si applica ai percorsi ClawHub, caricamento, Git, locale, aggiornamento e installazione delle dipendenze e blocca l'operazione quando il comando non può restituire una decisione valida.

skills.entries.*.env e skills.entries.*.apiKey inseriscono i segreti nel processo host solo per quel turno dell'agente, non nella sandbox. Non includere i segreti nei prompt e nei registri.

• Quando sono elencati più strumenti di installazione, il Gateway sceglie un'opzione preferita (brew, se disponibile; altrimenti node).
• Se tutti gli strumenti di installazione sono download, OpenClaw elenca ogni voce in modo che sia possibile vedere tutti gli artefatti disponibili.
• Le specifiche possono includere os: ["darwin"|"linux"|"win32"] per applicare un filtro in base alla piattaforma.
• Le installazioni Node rispettano skills.install.nodeManager in openclaw.json (predefinito: npm; opzioni: npm / pnpm / yarn / bun). Ciò influisce solo sulle installazioni delle skill; il runtime del Gateway deve continuare a essere Node.
• Ordine di preferenza degli strumenti di installazione del Gateway: Homebrew → uv → gestore Node configurato → go → download.

• Homebrew: OpenClaw non installa automaticamente Homebrew né converte le formule brew in comandi del gestore di pacchetti di sistema. Nei container Linux senza brew, gli strumenti di installazione basati solo su brew sono nascosti; usa un'immagine personalizzata o installa manualmente la dipendenza.
• Go: OpenClaw richiede Go 1.21 o versioni successive per le installazioni automatiche delle skill. Se go non è presente e Homebrew è disponibile, OpenClaw installa prima Go tramite Homebrew; su Linux senza Homebrew può invece usare apt-get come root o tramite sudo senza password, quando il candidato golang-go aggiornato soddisfa la versione minima. Il comando go install effettivo per la dipendenza usa sempre una directory dedicata per i binari gestita da OpenClaw (bin di Homebrew per una nuova installazione, altrimenti ~/.local/bin), anziché il valore GOBIN configurato: le tue variabili d'ambiente GOBIN, GOPATH e GOTOOLCHAIN vengono lette ma mai sovrascritte.
• Download: url (obbligatorio), archive (tar.gz | tar.bz2 | zip), extract (predefinito: automatico quando viene rilevato un archivio), stripComponents, targetDir (predefinito: ~/.openclaw/tools/<skillKey>).

requires.bins viene verificato sull'host al momento del caricamento della skill. Se un agente viene eseguito in un ambiente isolato, il binario deve esistere anche all'interno del container. Installalo tramite agents.defaults.sandbox.docker.setupCommand o un'immagine personalizzata. setupCommand viene eseguito una volta dopo la creazione del container e richiede accesso in uscita alla rete, un file system radice scrivibile e un utente root nell'ambiente isolato.

Per impostazione predefinita, OpenClaw monitora le cartelle delle skill e aggiorna l'istantanea quando cambiano i file SKILL.md. Configura il comportamento in skills.load:

{  skills: {    load: {      extraDirs: ["~/Projects/agent-scripts/skills"],      allowSymlinkTargets: ["~/Projects/manager/skills"],      watch: true, // default      watchDebounceMs: 250, // default    },  },}

Usa allowSymlinkTargets per strutture intenzionali con collegamenti simbolici, nelle quali un collegamento simbolico alla radice di una skill punta all'esterno della radice configurata, ad esempio <workspace>/skills/manager -> ~/Projects/manager/skills. Abilita skills.workshop.allowSymlinkTargetWrites solo quando Skill Workshop deve anche applicare le proposte tramite tali percorsi con collegamenti simbolici considerati attendibili.

Se il Gateway viene eseguito su Linux, ma è connesso un Node macOS con system.run consentito, OpenClaw può considerare idonee le skill disponibili solo su macOS quando i binari richiesti sono presenti su tale Node. L'agente deve eseguire tali skill tramite lo strumento exec con host=node.

I Node non in linea non rendono visibili le skill disponibili solo in remoto. Se un Node smette di rispondere ai controlli dei binari, OpenClaw cancella dalla cache le corrispondenze dei binari per tale Node.