TL;DR: /wayfinder è una skill di pianificazione per agenti IA che risolve il problema della «nebbia della guerra»: progetti il cui stato finale non è completamente definito all'inizio. Invece di jonglare manualmente tra sessioni e finestre di contesto, interviene un livello di orchestrazione: scompone la pianificazione in sotto-sessioni con una mappa comune e tipi di ticket precisi, e ricompone il tutto in uno spec dettagliato.
Il problema: la pianificazione come collo di bottiglia degli agenti AFK
Matt Pocock, fondatore di aihero.dev e gestore di un repo GitHub di skill con oltre 220.000 stelle, descrive in un'intervista con Latent Space il tipico collo di bottiglia del suo lavoro: l'esecuzione vera e propria gira quasi da sola con gli agenti AFK (Away From Keyboard) — la pianificazione che la precede no.
- La sessione di pianificazione deve tenere d'occhio costantemente la finestra di contesto: quanti token consumati, quanto in profondità è già arrivata la sessione?
- Gli handoff tra fili di pianificazione, prototipi e ricerca avvengono manualmente e sono soggetti a errori.
- Alla fine c'è uno spec troppo grossolano perché un agente «semplicemente continui».
L'approccio di /wayfinder: un livello di orchestrazione sopra la pianificazione che si fa carico di questa contabilità.
Come funziona /wayfinder
La meccanica si riduce a tre concetti nominati con precisione — Pocock li chiama «leading words», perché un vocabolario univoco stabilizza il comportamento dell'agente:
- Mappa — un documento centrale con la panoramica generale e tutte le decisioni prese fin qui.
- Ticket — il compito concreto di una singola sotto-sessione.
- Sessione — il contesto di lavoro che riceve mappa e ticket e da lì lavora fino a una chiusura.
Ogni sotto-sessione ha bisogno esattamente di due cose: la comprensione dell'insieme tramite la mappa e il suo compito specifico come ticket. Una sessione grilling può così gestire ulteriori sessioni grilling e fondere alla fine i risultati in un livello di dettaglio che un singolo contesto non produrrebbe.
I quattro tipi di ticket
| Tipo | Scopo |
|---|---|
| Grilling | Un dialogo di pianificazione che estrae decisioni |
| Prototype | Prototipo rapido per verificare una via |
| Research | Ricerca mirata su un sotto-aspetto |
| Task | Tutto ciò che l'umano deve fare e l'agente non può |
Questa tassonomia è deliberatamente piccola. Pocock usa quindi /wayfinder non solo per il software: si possono pianificare anche corsi — ogni struttura di obiettivo vago più decisioni parziali è compatibile.
Il concetto centrale: Fog of War
Per Pocock «nebbia della guerra» significa due cose: lo stato di un progetto il cui stato finale non si può definire del tutto all'inizio — e il limite dei singoli contesti degli agenti. /wayfinder riduce entrambi passo dopo passo: ogni sessione solleva un pezzo di nebbia, la mappa registra la chiarezza, e la generazione successiva di ticket vi si appoggia.
Il guadagno pratico è un workflow copiabile:
1. avviare /wayfinder, nominare l'obiettivo vago del progetto
2. la mappa emerge: cornice + domande aperte
3. esternalizzare le domande aperte come ticket grilling/research/prototype
4. reinserire i risultati nella mappa
5. trasferire lo spec finito in ticket task per agenti AFK
Perché il modello regge
La skill è un esempio da manuale dell'idea «skill = SOP per agenti»: una procedura documentata e riutilizzabile che sostituisce la gestione manuale del contesto. Chi lavora con Claude Code o harness simili può applicare i tre mattoni (mappa, ticket, sessione) direttamente ai propri progetti — la tassonomia è harness-neutral.
L'insegnamento più importante dell'intervista: nomi precisi prima della logica arguta. Chi distingue con coerenza mappa, ticket e sessione ottiene meno drift nei lunghi fili di pianificazione — indipendentemente dal modello che gira sotto.
FAQ
A cosa mi serve /wayfinder se ho già un workflow spec-first? Il workflow spec-first presuppone che lo stato finale sia già noto. /wayfinder è esattamente per i casi precedenti: un obiettivo vago, più rami aperti, priorità poco chiare. Le sotto-sessioni chiariscono i rami, e alla fine c'è lo spec dettagliato con cui il workflow normale prosegue.
Qual è la differenza tra mappa e ticket? La mappa è il documento trasversale: panoramica, contesto, tutte le decisioni prese fin qui. Il ticket è il compito singolo e chiudibile di una sessione. Questa separazione evita che ogni sotto-sessione debba ri-«indovinare» tutta la storia.
Perché tipi di ticket propri come Grilling e Prototype sono sensati? Perché ogni tipo ha una fine diversa: Grilling termina con una decisione, Prototype con una via verificata, Research con una risposta, Task con una spunta. L'agente riconosce dal tipo quale forma di output è richiesta — questo riduce richieste di seguito e output sbagliati.
Si può ricostruire il principio senza il repo di Pocock? Sì, la meccanica è deliberatamente semplice: un documento mappa, ticket numerati, denominazione chiara per livello. Il repo di Pocock su github.com/mattpocock/skills fornisce il modello pronto, ma il modello che ci sta dietro (parole guida più flusso di informazioni) si trasferisce in ogni harness con file di testo.
Per quali dimensioni di progetto la skill conviene di più? Di più per intraprese medio-grandi con più decisioni parziali — progetti greenfield, formati di corso, refactor pesanti di migrazione. Per spec di una frase senza rami aperti l'overhead è inutile; basta la via diretta da spec a task.