Lifecycle delle Skill di Osmani

Architettura e principi del pack open source di skill per coding agent (100.000 stelle su GitHub, installabile in circa 70 agenti) creato da Addy Osmani, che traduce la cultura ingegneristica di Google e l'intero ciclo di vita tradizionale dello sviluppo software (SDLC) in istruzioni markdown per agenti. ¹

Il ciclo di vita in 6 fasi e l'autonomia con verifica

A differenza dei pack che introducono un vocabolario metaforico proprio (come grilling, wayfinder e fog of war in Matt Pocock, o potato mode e arene in Pstack di Lauren Tan; vedi Pack di Skill a Confronto), l'approccio di Osmani ricalca senza metafore il classico SDLC in 6 fasi — define, plan, build, verify, review, ship — associando uno slash command a ciascuna fase. ¹ L'impostazione risulta familiare a chiunque abbia praticato spec-driven development con strumenti come BMAD o Superpowers e si innesta con naturalezza nei team di sviluppo esistenti e nelle enterprise, essendo l'unico dei tre pack a spingersi fino a CI/CD, osservabilità, deprecazione e shipping: ¹

• /spec (Define): redige un vero e proprio PRD che definisce obiettivi, struttura, code style, testing e confini (boundaries) prima che venga scritta una sola riga di codice. ¹
• /plan (Plan): scompone la specifica in piccoli task atomici completi di criteri di accettazione (acceptance criteria). ¹
• /build (Build & Verify): implementa una thin vertical slice alla volta; per ciascuna slice l'agente implementa, testa, verifica e crea un commit atomico, prima di passare a test, /review e /ship. ¹
• /build auto (il modo corretto di fare autonomia): permette di approvare il piano una sola volta e lasciare che l'agente esegua tutti i task in autonomia senza intervento umano tra un passo e l'altro, ma senza rimuovere la verifica. Ogni singolo task resta vincolato al test-driven development, viene committato autonomamente e il loop si arresta immediatamente se qualcosa fallisce. ¹

Skill trasversali, le 25 skill e le 4 personas di review

Accanto ai comandi del ciclo principale, il repository include skill specializzate per la qualità e la manutenzione del codice: ¹

• /constraints: conduce un'intervista mirata a far emergere l'asticella di qualità (quality bar) attesa dal progetto e la codifica in un file constraints.md. ¹
• /web-perf: esegue un audit approfondito di web performance, riflettendo l'esperienza diretta di Osmani alla guida dei team Chrome DevEx, Lighthouse e Core Web Vitals. ¹
• /code-simplify: pensata per il codice che funziona ma che nessuno vuole toccare, con l'obiettivo di semplificarlo e scomporlo in parti comprensibili. ¹

Nel complesso il pack conta 25 skill affiancate da 4 personas di review: staff engineer, test engineer, security auditor e web performance auditor. ¹

Tabelle anti-razionalizzazione (Anti-Rationalization Tables)

Il vero valore del repository non risiede negli slash command ma nel contenuto interno dei file markdown delle skill: ogni skill contiene una tabella anti-razionalizzazione (anti-rationalization table). ¹

Si tratta dell'elenco esplicito delle scuse che un agente (o uno sviluppatore junior) utilizza tipicamente per saltare un passaggio, con la relativa replica (rebuttal) posizionata esattamente accanto per disinnescare la scorciatoia nelle tracce di ragionamento (reasoning traces) del modello. ¹ Esempi classici intercettati dalla tabella sono: ¹

• "È troppo semplice per testarlo" ("this is too simple to test"). ¹
• "L'ho testato a mano" ("I tested it manually"). ¹

Mettere per iscritto in anticipo le razionalizzazioni dell'agente impedisce al modello di auto-giustificare l'omissione dei test o delle verifiche. ¹

Doubt-Driven Development

Per qualsiasi decisione importante o non banale presa durante lo sviluppo, il sistema introduce il doubt-driven development: viene avviata una review a contesto fresco (fresh context review) il cui unico incarico è dubitare dell'affermazione appena fatta. ¹

Il processo segue una sequenza rigorosa in cinque passi: ¹

1. Claim (enunciazione della scelta o ipotesi)
2. Extract (estrazione delle assunzioni sottostanti)
3. Doubt (messa in discussione avversariale in contesto pulito)
4. Reconcile (riconciliazione delle obiezioni emerse)
5. Stop (chiusura e consolidamento della decisione)

In questo modo la revisione avversariale avviene durante la build, nel momento stesso in cui si prendono le decisioni, e non soltanto a codice ultimato. ¹

I paradigmi classici codificati nelle skill

Leggere i file delle skill di Osmani — anche senza mai installarle — viene descritto da Rob Shocks come un corso di software engineering migliore della maggior parte di quelli in commercio, perché condensa nel prompt i grandi paradigmi della cultura ingegneristica di Google: ¹

• Legge di Hyrum (Hyrum's Law) nella skill di API design: con un numero sufficiente di utenti di un'API, ogni comportamento osservabile del sistema finirà prima o poi per essere una dipendenza critica per qualcuno. ¹
• Regola di Beyoncé (Beyoncé rule) nella skill di testing: "se ti piace, dovresti metterci sopra un test" ("if you like that you should put a test on it") — ciò che non è coperto da un test automatico non è garantito che continui a funzionare. ¹
• Steccato di Chesterton (Chesterton's fence) nella skill di semplificazione del codice: non rimuovere mai uno steccato (o un blocco di codice esistente) finché non hai capito esattamente perché è stato messo lì. ¹
• Pratiche fondamentali di flusso: trunk-based development, commit atomici piccoli e la consapevolezza che il codice è una passività (code as a liability). ¹

Vedi anche: Addy Osmani, Pack di Skill a Confronto, Spec-Driven Development e Dark Factory Agentica, Cerimonia Proporzionata al Rischio, Leading Words e Fondamentali del Software

Fonti e Riferimenti