Un repository può vietare all’agente di distribuire in produzione lasciandogli disponibili comando e credenziali di produzione. La frase comunica un’intenzione, ma non sottrae una capacità. Il modello in quattro parti di Tessl è utile perché separa questa funzione consultiva da procedure e controlli con comportamenti diversi di caricamento e applicazione.
Organizza i file della squadra in contesto persistente, regole per percorso, skill riutilizzabili e hook del ciclo di vita. Gli esempi concreti usano Claude Code, non un formato universale. La domanda architetturale è quale conoscenza debba essere sempre presente, quale procedura caricarsi solo al bisogno e quale operazione pericolosa vada bloccata fuori dal giudizio del modello.
Quattro livelli sono contratti diversi, non copie della stessa policy
CLAUDE.md fornisce contesto trasversale: comandi di build, convenzioni delle directory, confini architetturali e aspettative sui test. Può contenere il gestore di pacchetti di un servizio o la regola di aggiungere soltanto nuove migrazioni. Il file principale funziona meglio come panoramica o indice che come manuale di ogni eccezione.
Regole mirate in .claude/rules/ possono caricare istruzioni tramite pattern dei percorsi. Una regola di validazione API non deve competere per l’attenzione durante una modifica documentale. Una regola trasversale può coprire handler o migrazioni in più pacchetti senza riprodurre lo stesso paragrafo in ogni cartella.
Le capacità riutilizzabili raccolgono una procedura più lunga in una cartella con SKILL.md, metadati, istruzioni e script o riferimenti di supporto. La panoramica rimanda al rilascio, mentre la relativa skill possiede i controlli ordinati. Claude Code inizialmente carica nome e descrizione; le istruzioni complete entrano nel contesto quando pertinenti o esplicitamente richiamate.
Gli hook collegano comportamenti a eventi del ciclo di vita tramite impostazioni o configurazioni correlate. Un controllo precedente allo strumento esamina l’operazione proposta; uno dopo l’edit formatta o valida; uno di completamento può richiedere prove prima di fermarsi. Sono funzioni diverse dall’aggiungere un’altra istruzione da ricordare.
L’argomento di proprietà di Tessl è trasformare la conoscenza in un asset versionato del repository. Gli ingegneri possono esaminare differenze, assegnare responsabili, rivedere modifiche, annullare regole sbagliate e fornire lo stesso contesto a nuove sessioni. Modello ospitato e runtime restano del fornitore. Possedere i file non significa possedere tutti i meccanismi di applicazione.
Il contesto costa quando diventa un database di policy
Si parte spesso da un file perché migliora subito scelta dei comandi e nomi. Poi sicurezza, rilascio, convenzioni frontend ed eccezioni personali si accumulano fino a caricarsi in ogni sessione. Il materiale permanente compete con dettagli del compito, codice, risultati degli strumenti e cronologia. Più prosa non assicura maggiore adesione.
Le indicazioni Anthropic citate consigliano CLAUDE.md sotto 200 righe, un responsabile e revisione come codice. Contano attenzione e manutenzione, non una garanzia legata al numero di righe. Una frase breve può essere fraintesa; una restrizione importante non diventa vincolante solo spostandola in alto.
File annidati possono caricarsi quando l’agente accede alla parte pertinente dell’albero. Le regole per percorso affrontano un altro caso: un’esigenza attraversa più directory. Entrambi riducono contesto irrilevante, ma occorre conoscere caricamento, corrispondenza e precedenza del runtime effettivo.
La classificazione è funzionale. Fatti e convenzioni che richiedono giudizio vanno nel contesto, un’operazione ripetibile multistep in una skill, un’azione proibita in permessi, controlli bloccanti o isolamento più forte. Sessioni lunghe, conflitti e testo ostile influenzano l’adesione. Una frase nel repository prova l’esistenza della policy, non il tasso di applicazione.
Un hook può attivarsi sempre senza decidere deterministicamente
Il modello interpreta istruzioni persistenti, regole e procedure. Un hook differisce perché il runtime lo avvia all’evento configurato, senza aspettare che il modello ricordi una lista. PreToolUse può controllare la chiamata proposta prima dell’esecuzione e restituire un blocco per il comando contrario alla policy.
Il metodo decisionale dipende però dall’handler. Quelli di comando eseguono script; quelli di prompt e agente possono usare giudizio del modello. Un avvio affidabile può comunque produrre una conclusione probabilistica. Condizioni valutabili direttamente dal software si prestano meglio a controlli di comando che all’opinione di un altro modello.
Per file generati, la guida spiega perché evitarne la modifica e un controllo preventivo consapevole del bersaglio respinge la scrittura vietata. Nel deployment, la skill descrive il percorso approvato mentre permessi o hook impediscono la scorciatoia diretta. Spiegazione e barriera si rafforzano perché risolvono problemi diversi.
I permessi stabiliscono autorizzazioni e negazioni per strumenti e comandi; nei controlli Claude Code citati, le negazioni corrispondenti prevalgono sulle autorizzazioni. Gli hook ispezionano condizioni più ricche, ma strumento consentito o controllo superato non equivalgono ad accesso illimitato al sistema operativo. Credenziali ristrette, container, branch protetti e mount di sola lettura restano rilevanti quando le conseguenze sono gravi.
Anche l’automazione post-edit richiede proporzione. Un formatter o validatore mirato può essere economico a ogni edit; l’intera suite può intralciare. Controlli maggiori possono stare al commit o alla conclusione. Un hook di arresto non deve chiedere ripetutamente di continuare senza una strada utile: la barriera diventerebbe un ciclo costoso.
Il piano di controllo è codice che può causare danni
Gli hook sono infrastruttura eseguibile. Uno script difettoso può divulgare dati, bloccare lavoro legittimo o rallentare ogni evento. La proprietà del repository assegna responsabilità di manutenzione, non rende affidabile la configurazione sconosciuta. Fiducia nel workspace, review ed esecuzione isolata restano necessarie.
La modificabilità crea un ulteriore confine. Se l’agente può editare i file che lo limitano, una modifica ordinaria può indebolire una regola vicina o disabilitare un controllo. Le impostazioni critiche richiedono responsabilità e revisioni più forti, branch protetti o esecuzione in sola lettura, non la disponibilità dell’agente a preservare i propri vincoli.
Una negazione basata sul pattern del comando può perdere un task di pacchetto equivalente, uno script indiretto o un altro strumento con lo stesso effetto. I test devono tentare azioni vietate tramite percorsi alternativi, non ripetere solo l’esempio previsto. Serve anche provare lavoro legittimo: divieti troppo ampi incentivano eccezioni, aggiramenti e disattivazione totale.
Issue, documentazione, dipendenze e artefatti generati non fidati possono contenere prompt injection. Il modello potrebbe interpretarli insieme alle istruzioni del repository. Permessi deterministici e isolamento limitano le capacità risultanti; la sola prosa non crea quel confine di sicurezza.
Le skill conservano procedure solo se mantenute e attivate
Le skill rendono conoscenze su release, migrazioni, dipendenze e incidenti ispezionabili oltre la chat di un ingegnere. Un validatore del repository gestisce una parte deterministica mentre l’agente giudica. Una base tecnica ricercabile conserva decisioni e documenti di supporto; la skill definisce come trasformare conoscenza selezionata in procedura.
Presenza non è attivazione. Le descrizioni devono spiegare quando applicare la skill e le valutazioni verificare il caricamento della procedura corretta. Il richiamo esplicito riduce ambiguità nei compiti sensibili. Comandi e architettura cambiano: responsabili, esempi e cicli di revisione sono manutenzione necessaria, non rifinitura.
Duplicare una regola nella radice, in più file mirati e in molte skill crea versioni concorrenti dell’autorità. Una sede principale per ogni fatto, con link o brevi indici altrove, facilita le revisioni. Configurazioni personali e organizzative gestite possono comunque confliggere con il repository. Occorre vedere quali file sono stati caricati e quali regole o permessi hanno influenzato l’azione.
Portabilità e governance si dimostrano con il comportamento
Altri agenti offrono concetti simili di istruzione, workflow ed eventi, ma directory e semantica differiscono. L’interesse commerciale di Tessl nel contesto riutilizzabile non trasforma i percorsi Claude Code in standard portatile. Anche un Markdown comune deve preservare attivazione, ambito, precedenza e blocco per garantire portabilità significativa.
Valutazioni ripetibili partono da ambienti puliti, presentano gli stessi compiti in più prove e registrano configurazioni caricate, decisioni degli strumenti e risultati. Controllano adesione, attivazione corretta, operazioni bloccate e lavoro ordinario riuscito. La ripetizione indipendente vale più di una dimostrazione convincente.
Tre sviluppi rafforzerebbero il modello: valutazioni pratiche delle istruzioni, formati di capacità con semantica precisa tra runtime e interfacce che distinguano consiglio, attivazione garantita e negazione effettiva. I log devono rendere comprensibile il motivo di autorizzazione o rifiuto. Numero di file e volume documentale non sostituiscono gli esiti.
Il prodotto utile è una mappa di controllo spiegabile. Un altro ingegnere deve identificare il contesto che guida la decisione, la procedura che compare al bisogno e il confine esterno che ferma un errore importante. I file della squadra rendono la mappa rivedibile e recuperabile. L’autonomia sicura dipende ancora da applicazione verificata e infrastruttura circostante.
Fonti e letture correlate
Le quattro parti di Tessl · Indicazioni Anthropic · Memoria e caricamento del progetto · Handler degli hook · Permessi degli strumenti · Pacchetti e richiamo delle skill · Lettura correlata: basi tecniche ricercabili