TL;DR: Il repository Skills di Matt Pocock ha oltre 160.000 stelle su GitHub e il suo workflow principale si riassume in quattro comandi: prima lasci che l'agente ti torchi con delle domande (grill-me), poi comprimi le risposte in una Spec (specifica), la dividi in Ticket che rientrano in una singola Context Window, e fai implementare il codice — ma facendolo revisionare da un Subagent con un contesto pulito. Il trucco non è l'intelligenza, ma il processo: l'agente non scrive codice prima che vi siate capiti, e non valuta da solo il proprio lavoro.
Il problema: l'agente digita più velocemente di quanto pensi
La maggior parte dei progetti di AI coding non fallisce per la qualità del modello, ma perché le domande di design non sono mai state poste. L'umano e l'agente iniziano a chattare con un'idea vaga, l'agente parte in quarta e venti minuti dopo nasce una PR che nessuno aveva richiesto: uno spaghetti code lasciato a metà, perché nessuno ha pensato all'architettura prima di iniziare a scrivere.
Matt Pocock, noto per i suoi corsi su TypeScript, ha creato un set di skill per risolvere esattamente questo problema: la sua directory .agents personale, resa pubblica su github.com/mattpocock/skills. Oggi conta oltre 160.000 stelle, milioni di download e, di recente, anche un tutorial end-to-end ufficiale.
Il principio di base: Allineamento prima del codice. L'agente è già intelligente. Quello che manca è un processo che forzi quel lavoro di pensiero preliminare che nessuno ha fatto.
Fase 1: grill-me — la papera di gomma automatizzata e propensa alla discussione
La skill probabilmente più amata del repository è composta da tre frasi. Non fa nulla di spettacolare: fa la domanda giusta al momento giusto. Invece di passare subito alla fase di pianificazione, lasci che sia l'agente a fare il terzo grado a te — una domanda dopo l'altra, finché entrambi non avete la stessa comprensione dell'obiettivo, dei vincoli e dei rischi.
Prima dell'era dell'IA, questo si chiamava Rubber Ducking. La differenza: il processo di "grilling" trasforma la papera di gomma in un interlocutore critico che ti contraddice, cerca le lacune ed evidenzia le assunzioni che avevi dato per scontate.
La variante potenziata /grill-with-docs compila anche un file CONTEXT.md con il vocabolario del progetto e utilizza gli Architectural Decision Records (ADR), in modo che le decisioni non ovvie vengano documentate invece di finire sepolte nella cronologia della chat.
Fase 2: to-spec — dalla discussione all'artefatto
Dopo il grilling, il flusso si biforca: se il lavoro può essere completato in una sola sessione, passi direttamente all'implementazione. Se richiede più sessioni, comprimi la discussione con /to-spec in una Spec (specifica) dettagliata: l'obiettivo, le user story, le decisioni di implementazione e di test, scritte nell'issue tracker e non in un messaggio di chat.
La Spec è l'ancora a cui tutto può essere ricondotto in seguito: ogni ticket, ogni commento di review, ogni commit. Senza questo artefatto, il concetto di "finito" è solo una sensazione.
Fase 3: to-tickets — un ticket per Context Window
/to-tickets taglia la Spec a fette, ognuna delle quali deve rientrare in una singola Context Window. L'esempio di Pocock nel tutorial: una singola Spec è stata trasformata in undici sub-issue.
Perché tanta rigidità? Gli LLM hanno una "Smart Zone" affidabile. Più il contesto è pieno, più l'agente dimentica le convenzioni, i casi limite e le istruzioni precedenti. Un ticket che rimane al di sotto di questo limite (indicativamente sotto i ~140K token di contesto utilizzato) verrà sviluppato in modo molto più affidabile rispetto a un mega-ticket che vive per tre sessioni nel ventre della memoria di un'unica conversazione.
Importante durante il taglio: i ticket dovrebbero essere fette verticali (vertical slices) — una sezione funzionale trasversale, piuttosto che "prima il DB, poi l'interfaccia utente, poi i test". In questo modo, ogni ticket è testabile singolarmente.
Fase 4: implement — e soprattutto: Review con un contesto pulito
La skill /implement elabora un ticket: Type Checks, Build, TDD sui punti di giunzione concordati in precedenza — e per finire /code-review, eseguita tramite Subagent.
Questo è il punto in cui la maggior parte dei setup si arrende alla via più facile: l'agente principale fa la review del proprio codice, nello stesso contesto saturo in cui l'ha scritto. Il risultato va dall'indulgente al cieco. Un contesto pulito fornisce una review più onesta, perché non si trascina dietro alcuna logica di autogiustificazione.
La Code-Review di Pocock si muove quindi su due assi come Subagent paralleli, che non si contaminano a vicenda:
| Asse | Domanda | Riferimento |
|---|---|---|
| Standard | Il diff rispetta gli standard di coding e non presenta code smell classici? | codingstandards.md nel repo + Smell-Baseline |
| Spec | Il codice implementa effettivamente il ticket/Spec originale? | Issue/Spec originale |
Nel setup personale di Pocock, i Subagent di implementazione girano in Sandcastle, il suo orchestratore per agenti di coding in sandbox. Ma per l'uso quotidiano, il flusso funziona altrettanto bene con Subagent normali: il principio fondamentale è il contesto pulito (la "tabula rasa"), non il tool.
Setup in due comandi
npx skills@latest add mattpocock/skills
/setup-matt-pocock-skills
La skill di setup configura l'Issue-Tracker, le etichette di triage e il layout dei documenti una volta per ogni repository. Dopodiché, il workflow procede in un ordine fisso: grill → (spec → ticket) → implement. Per chi vuole solo l'essenziale: grill-me funziona anche perfettamente da solo. La versione da tre frasi ha un costo di infrastruttura pari a zero ed è la singola skill con il ROI (Ritorno sull'Investimento) più alto in assoluto.
Il Workflow in sintesi
| Fase | Comando | Artefatto | Durata |
|---|---|---|---|
| Allineamento | /grill-me o /grill-with-docs | Comprensione condivisa, CONTEXT.md | 10–30 Min |
| Compressione | /to-spec | Spec nel tracker | una tantum |
| Taglio | /to-tickets | Ticket da una Context Window l'uno | una tantum |
| Costruzione | /implement + /code-review | PR con Review pulita | per ogni ticket |
❌ Cosa non fare — ✅ Cosa fare
- ❌ Inserire il prompt, tirare fuori il codice, aprire la PR — ✅ Farsi prima torchiare con le domande, rispondere, poi scrivere la Spec
- ❌ "Sviluppa l'intera feature" in una sola chat — ✅ Un ticket per Context Window
- ❌ L'agente principale revisiona il proprio codice in un contesto pieno — ✅ Subagent pulito, due assi separati
- ❌ Decisioni lasciate solo nella cronologia della chat — ✅ Spec e ADR nel tracker, versione dopo versione
Quando questo Workflow è eccessivo (Overkill)
Ad essere onesti: per un fix di due righe o per un prototipo usa e getta, l'intero treno delle quattro fasi è troppo lungo. Il workflow diventa vantaggioso dal momento in cui una feature deve sopravvivere a più sessioni, quando altre persone (o agenti) ci lavoreranno in seguito, o quando tu stesso domani non ricorderai più perché hai scelto la variante B. Il repository è fatto esattamente per questo: "Skills for Real Engineers", non per giochini coi prompt. Tra l'altro, per lavori così grandi da non poter essere contenuti in una singola sessione dell'agente, nel repo è presente anche /wayfinder — un sistema di mappe composto da ticket decisionali sul tracker.
FAQ
Da cosa comincio se l'intero flusso mi sembra troppo?
Solo con /grill-me. La skill è composta da tre frasi, non richiede configurazione e cambia immediatamente il modo in cui pianifichi: l'agente ti fa una domanda dopo l'altra finché non avete la stessa immagine dell'obiettivo. Il resto del flusso (spec, ticket, review) si basa su questo, ma può essere aggiunto in seguito. Se c'è una sola cosa da portare via da questo articolo, è lasciare che l'agente ti faccia il terzo grado prima di iniziare la prossima feature, invece di lanciare subito il prompt da solo.
Ho bisogno di Sandcastle o dell'esatta toolchain di Pocock?
No. Sandcastle è lo strumento di Pocock per orchestrare agenti in sandbox, ma il flusso funziona con qualsiasi setup di agenti in grado di gestire Subagent o almeno sessioni pulite: Claude Code, Codex, OpenClaw, qualsiasi cosa. Il nucleo trasferibile è la regola "Implementazione e Review avvengono in contesti separati e puliti", non lo strumento specifico. Anche la parte di review può essere implementata in modo primitivo: apri una nuova chat, incolli il diff e interroghi sui due assi.
Qual è la dimensione massima di un ticket?
Come regola generale: deve entrare, compreso il contesto della codebase e la discussione, in un'unica Context Window rimanendo nella zona di affidabilità del modello — approssimativamente sotto i ~140K token di contesto utilizzato, a seconda del modello anche molto meno. Un buon segno è riuscire a chiudere il ticket in una sessione con tutti i test verdi. Se un ticket suona come "Fase 1 di 3", è stato tagliato troppo grande: meglio dividerlo di nuovo.
Qual è la differenza tra grill-me e grill-with-docs?
/grill-me è la variante veloce: l'agente fa domande, parlate finché la comprensione non è condivisa, ed è fatta. /grill-with-docs conduce lo stesso interrogatorio, ma mantiene artefatti persistenti: un CONTEXT.md come glossario del tuo dominio e gli Architectural Decision Records per le decisioni non ovvie. Per un lavoro una tantum basta grill-me, in un repo di team con uno storico, la variante con documentazione si ripaga già dalla seconda settimana.
Perché uno sconosciuto dovrebbe revisionare il mio codice al posto dell'agente che lo ha scritto?
Perché l'agente che scrive è di parte e cieco: il suo contesto è pieno dei compromessi e degli errori che hanno portato al codice, e i modelli tendono a giudicare le proprie prestazioni in modo indulgente. Un Subagent con contesto pulito vede solo il diff, gli standard e la Spec, e segnala i "code smell" in modo più onesto, proprio perché non deve difendere il proprio lavoro. L'approccio a due assi (Standard paralleli alla fedeltà alla Spec) impedisce inoltre che i commenti di review di un canale contaminino l'altro.
Funziona solo con Claude Code o anche con altri agenti?
Il formato (le skill come file SKILL.md nella directory degli agenti) è volutamente cross-tool e funziona in Claude Code, Codex e in altri harness che caricano skill basate su cartelle. L'installer (npx skills add mattpocock/skills) posiziona i file di conseguenza, /setup-matt-pocock-skills adatta il tracker e il layout al tuo repository. La qualità del modello sottostante non importa al workflow: il suo scopo è proprio quello di strutturare il processo attorno al modello.
Fonti (Sources)
- Matt Pocock: Skills-Repo — https://github.com/mattpocock/skills
- Matt Pocock: End-to-End-Tutorial des Workflows (X) — https://x.com/mattpocockuk/status/2075218406266036236
- Matt Pocock: Workflow-Tutorial (YouTube) — https://www.youtube.com/watch?v=M6mYodf0dJM
- Matt Pocock: Skills Changelog v1.1 (/wayfinder, /to-spec, /to-tickets, Code-Review-Achsen) — https://www.aihero.dev/skills/skills-changelog-v1-1-wayfinder-to-spec-to-tickets-grilling-improvements
- Matt Pocock: AI-Coding-Workshop mit Sandcastle (YouTube) — https://www.youtube.com/watch?v=-QFHIoCo-Ko
- Alex Rusin: "Matt Pocock Skills: The Main Flow Explained" — https://blog.alexrusin.com/matt-pocock-skills-main-flow
- Aditya Kumar Puri: "Matt Pocock's Claude Code Skills made me rewrite how I work with AI agents" — https://adityakumarpuri.medium.com/matt-pococks-5-claude-code-skills-made-me-rewrite-how-i-work-with-ai-agents-d71853c3056c
- Danny Shmueli: Subagents + Pocock-Skills in Hermes — https://dannyshmueli.com/2026/04/29/Matt-Pocock-Skills-Hermes-Subagents-Feature-Work/