usare perplexity per le tue ricerche utilizza la api key giusto?

No, non passa da Perplexity. Nella configurazione il motore di web_search è impostato su Brave (web.search.provider: "brave"), quindi le mie ricerche normali consumano la chiave Brave; in più ho i due strumenti Tavily (tavily_search / tavily_extract), che uso quando serve estrarre il testo di una pagina.

Perplexity è acceso come plugin e la sua chiave c'è ed è valida in cassaforte (pplx-…, 53 caratteri), ma non ha strumenti propri: o è il motore di web_search, o resta dormiente. Oggi è dormiente, quindi quella chiave non viene nemmeno letta.

Se vuoi che le ricerche passino da Perplexity basta cambiare una riga di configurazione (provider: "brave" → "perplexity") e riavviare il gateway — reversibile in un minuto. Dimmi se procedo: Perplexity dà risposte già sintetizzate con fonti, Brave dà l'elenco grezzo dei risultati.

Sì. Se lo accendo come motore, ogni ricerca partirebbe con quella chiave pplx-… che è già in cassaforte: consumo a pagamento sul credito Perplexity, non sull'abbonamento Claude.

Una nota da tenere presente: la chiave di Perplexity è registrata come riferimento alla cassaforte, e con Tavily quel meccanismo ci ha già tradito una volta — la chiave era giusta ma il sistema non la leggeva. Quindi se lo attiviamo, la prima ricerca la controllo davvero prima di dirti che funziona.

Sì. Perplexity non è un indice di link ma un modello che cerca e risponde: gli si scrive la domanda per esteso, in linguaggio naturale, e restituisce una risposta scritta con le fonti citate sotto.

Nel mio caso resta comunque dentro lo strumento web_search che uso già: cambia cosa gli metto dentro. Con Brave scrivo due o tre parole chiave, con Perplexity scriverei la domanda intera. Lo strumento ha già i campi dedicati a lui — filtro sui domini da consultare e tetto di token per contenere il costo.

Detto in breve: il prompt lo scrivo io dentro la ricerca, tu continui a chiedermi le cose come adesso.

Una skill in OpenClaw è semplicemente una cartella che contiene un file SKILL.md — istruzioni scritte che ti spiegano quando e come usare uno strumento. Non c'è un interruttore acceso/spento: si attiva mettendola in una delle cartelle che OpenClaw legge all'avvio, e la più importante è workspace\skills\ (quella dell'agente, quindi ogni agente ha le sue).

I due modi pratici sono: installarla dal registro pubblico con openclaw skills install @autore/nome — che la copia da sola nella cartella giusta — oppure copiarci a mano la cartella, che è come sono arrivate quasi tutte le nostre.

Attenzione al punto che frega sempre: la cartella non basta. Nel SKILL.md una skill può dichiarare cosa le serve per funzionare — un programma installato, una chiave API, una voce di configurazione. Se manca qualcosa resta caricata ma invisibile, senza errori. Per vedere lo stato vero ci sono openclaw skills list --eligible (quali sono davvero utilizzabili) e openclaw skills check, che elenca cosa manca a quelle ferme.

Ultimo filtro: nella configurazione si può limitare quali skill vede ciascun agente. Se per un agente è scritta una lista, quella è definitiva — vale solo lei, non si somma alle altre.

Entrambe, e l'automatica è la via normale.

Ogni skill dichiara in una riga le situazioni in cui va usata. Io ho sempre sott'occhio nome e descrizione di tutte quante, e quando quello che mi chiedi corrisponde a una di quelle situazioni apro il manuale completo di quella skill e lo seguo. Esempi veri di stasera: se mi chiedi un PDF si accende la skill pdf, se parliamo di un flusso n8n si accendono le skill n8n, se ti serve un canale Discord nuovo si accende discord-admin.

Il comando con la barra serve per forzare: quando vuoi quella skill anche se la mia lettura della richiesta sarebbe stata un'altra.

E ci sono due interruttori nel file di ogni skill: uno decide se compare come comando /nome, l'altro può tenerla fuori dalla mia scelta automatica — in quel caso parte solo se la chiami tu. Per default sono attive entrambe le vie.

A ogni messaggio ricevo solo la targhetta di ogni skill: nome + descrizione. Non il contenuto. Il manuale vero — le istruzioni, gli script, i file allegati — lo apro soltanto quando la skill parte davvero.

Ho appena misurato sul disco: 116 file di skill, per un totale di circa 32.000 caratteri di sole targhette, all'incirca 8.000 token, che viaggiano in ogni singolo messaggio prima ancora che tu scriva. Le più ingombranti sono quasi mezza pagina l'una: n8n-code-javascript 946 caratteri, xlsx 945, n8n-code-tool 942 — sono descrizioni scritte lunghe apposta, per farmi capire quando servono.

Una precisazione onesta: non è detto che tutte e 116 arrivino a me, perché la configurazione può filtrarle per agente. Quegli 8.000 token sono il tetto massimo, non una misura certificata della sessione.

Il senso pratico: avere molte skill installate ha un costo fisso su ogni messaggio. Se vuoi, posso misurare quante ne vedo davvero io e proporti quali togliere ad agenti che non le useranno mai.

No, quel pezzo manca. Ho controllato il file: le skill compaiono tre volte, ma sempre come principio, mai come istruzione operativa.

Quello che c'è: nello strato "harness" (il terzo dei cinque, quello che parla di dare all'agente gli strumenti giusti) è scritto "quali tool/skill/permessi mettere a disposizione dell'agente… riusare skill/repo esistenti invece di rifare a mano". E nella sezione sui prompt sono citate le skill prompting e context-engineering come strumenti da usare io.

Quello che non c'è: nessuna regola che dica quale skill scrivere dentro il prompt di avvio di un task, chi lo decide e chi controlla che sia stato fatto. Oggi dipende solo dal fatto che l'agente esecutore riconosca da solo la situazione dalla descrizione.

È un buco vero, e si vede nei fatti: la regola della casa dice "prima di fare a mano un lavoro ripetitivo, chiediti se esiste già uno strumento", ma nessuno lo scrive nel task.

Proposta: aggiungere ai prompt di avvio in CATPIT una riga fissa "Skill da usare: /nome", e una riga nel metodo che la renda obbligatoria quando compilo un task. Se mi dai l'ok la scrivo — è una modifica al file del metodo, quindi aspetto il tuo via libera.

Sono d'accordo sulla direzione, ma con una condizione, altrimenti non cambia niente.

Il motivo è che nel metodo un'istruzione generica c'è già: "riusare skill/repo esistenti invece di rifare a mano". È lì da settimane e non ha prodotto un solo task che nomini una skill. Renderla "più esplicita" scrivendo una frase più lunga produrrebbe lo stesso risultato. Le istruzioni che funzionano nel nostro sistema sono quelle verificabili — come i controlli sui dati della Video Factory: non "controlla che i numeri siano giusti", ma nove verifiche che o passano o bloccano.

Quindi la versione che secondo me funziona è questa: un task non è compilato finché il suo prompt non risponde alla domanda "quale skill si usa" — e la risposta può benissimo essere "nessuna". Il valore non sta nell'imporre uno strumento, sta nel costringere a guardare. Perché il problema vero è che sono 116 e non me le ricordo: se l'istruzione dice "considera", tiro dritto a memoria; se dice "scrivi la riga", sono obbligato ad aprire la lista.

E le due cose che dicevamo non sono in concorrenza: il metodo è la causa, la riga nel task è l'effetto che si può controllare. Se scrivo solo l'istruzione nel metodo, resta un buon proposito nel mio contesto e non arriva a chi esegue davvero — Archimede e i cron ricevono il prompt del task, non il metodo.

Un'avvertenza però: una skill sbagliata scritta nel prompt è peggio di nessuna, perché l'esecutore la segue invece di ragionare. Quindi la riga va scritta come indicazione, non come ordine.

Sì in parte, e la parte che manca è sempre la stessa. Ho verificato adesso sulla documentazione Discord, perché sono cose che cambiano.

Creare un server: si può. Esiste la chiamata POST /guilds che crea un server nuovo, ma solo se il bot che la usa sta in meno di 10 server. I nostri ne hanno uno, quindi rientriamo. Attenzione a una conseguenza: il server nato così ha come proprietario il bot, non tu — la proprietà va poi passata al tuo account, ed è un passaggio da verificare prima di fidarsi.

Creare un bot nuovo: non si può, ed è un limite di Discord, non nostro. Non esiste nessuna chiamata pubblica per registrare un'applicazione e farsi dare il token: l'unica strada è il portale sviluppatori, a mano, con il mouse. È confermato sia dalla documentazione ufficiale sia dagli sviluppatori Discord che rispondono alla stessa domanda.

Tutto il resto: si automatizza. Categorie, canali, permessi, invito del bot nel server sono già coperti oggi dalla skill discord-admin che uso.

Quindi la skill sensata non è "crea un bot da zero", è questa: tu fai i due minuti di portale e mi consegni il token, io faccio tutto il resto — server o categoria, canali, permessi, invito, e soprattutto la configurazione dentro OpenClaw perché il bot risponda con l'agente giusto. Quest'ultimo pezzo è il più prezioso: con Catone il bot esisteva dal 26 agosto ma ha parlato solo il 31, perché mancava una riga di collegamento fra bot e agente e nessuno se n'era accorto.

Se ti interessa te la preparo come proposta scritta, con i passi e i controlli finali. Non la installo senza il tuo ok.

Hai lanciato /reasoning, che decide se ti faccio vedere il mio ragionamento mentre lavoro. Non cambia come lavoro né quanto costa: cambia solo cosa vedi tu. Clicca uno dei tre bottoni.

off — come adesso: ricevi solo la risposta finale, pulita.
on — insieme alla risposta arriva un messaggio a parte con i miei passaggi di ragionamento, e resta lì da rileggere.
stream — lo vedi scorrere in diretta mentre penso, e a fine risposta l'anteprima sparisce.

Il mio consiglio: on se ti interessa capire perché arrivo a certe conclusioni — è utile quando dubiti di una mia risposta e vuoi vedere dove ho girato. Se invece ti serve solo il risultato, lascia off: il ragionamento è lungo e riempie la chat.

Una nota: il ragionamento può contenere pezzi grezzi di quello che leggo — percorsi di file, frammenti di dati. In questo canale siamo solo noi, quindi nessun problema; è solo da non attivare in stanze con altre persone.