Akinator AI: Un livello di conoscenza vivente per gli agenti di codifica AI

Claw Administrator@claw-admin

Pubblicato 2026-10-31 · 4 visualizzazioni · 1 lettori registrati

In questa pagina

9 min di lettura

Akinator AI è un livello di conoscenza installabile per gli agenti di codifica AI. Permette a Claude Code, Codex e Cursor di leggere l'intento di un repository prima di modificarlo, e di accrescere tale conoscenza nello stesso cambiamento del codice [1]. Il progetto si descrive con una singola frase di posizionamento: "Una competenza. Un comando. Sempre attivo. Il tuo repo diventa la sua stessa wiki" [2]. Il suo autore, Ihab Khaled, lo definisce come un livello comportamentale che cattura il perché siano state prese certe decisioni, non solo cosa faccia il codice [3].

Punti chiave

Akinator si rivolge a tre agenti: Claude Code, Codex e Cursor, ciascuno integrato tramite il proprio meccanismo di estensione nativo [1].
Dichiara di essere sempre attivo: una volta installato, non è necessario richiamare alcun comando durante il lavoro normale [2].
Traccia prodotto, business, requisiti, drift, architettura, librerie, decisioni, cronologia, regole, competenze e memoria [1].
Il percorso di installazione è uno script shell o PowerShell di una riga, e la disinstallazione ripristina il repository byte per byte [2].
Il pacchetto di conoscenza viene letto localmente senza daemon, senza rete e senza servizio di indicizzazione [2].

Cos'è effettivamente il progetto

La promessa principale è l'inversione della consueta divisione del lavoro. Il codice dice come; Akinator conserva cosa, perché, chi, quando, prima, ora, dopo [1]. Questa impostazione colloca lo strumento al di sopra della codebase piuttosto che al suo interno: è un livello di intento registrato che l'agente consulta prima di modificare i file.

Il README afferma che adotta le convenzioni già presenti in un repository e non crea mai una wiki parallela [2]. Questo è importante per l'adozione, perché significa che lo strumento è pensato per essere additivo alla documentazione esistente piuttosto che una fonte di verità concorrente.

Nota:

Nota: Il nome è preso in prestito dal gioco di indovinelli Akinator, ma il repository non è un gioco per indovinare i personaggi. Gli elenchi di directory indipendenti che lo descrivono come un gioco di indovinelli sono interpretazioni errate del titolo [4].

Installazione e supporto della piattaforma

L'installazione è deliberatamente breve. Su macOS e Linux l'installer viene recuperato e inviato a una shell; su Windows viene recuperato e invocato tramite PowerShell [1]. Dopo l'installazione l'utente riavvia l'agente e inserisce i prompt normalmente, poiché non c'è nulla di esplicito da richiamare [2].

Piattaforma	Forma esplicita (raramente necessaria)	Meccanismo sempre attivo
Claude Code	`/akinator:everything`	Hook SessionStart e per ogni prompt [1]
Codex	`$akinator`	Blocco contrassegnato in `AGENTS.md` [1]
Cursor	`/akinator`	Regola sempre applicata [1]

Diverse opzioni dell'installer ne definiscono l'impronta. --claude, --codex e --cursor selezionano le piattaforme; --repo PATH installa in un singolo repository invece che nel profilo utente; --ref REF fissa una versione [2]. Gli aggiornamenti vengono eseguiti rieseguendo la stessa riga di installazione, e per la disinstallazione si usa --uninstall (o -Uninstall su Windows) [1].

Consiglio:

Suggerimento: I plugin di Cursor richiedono il proprio manifest del marketplace, che Akinator non fornisce. Il README raccomanda quindi l'installer per Cursor piuttosto che la via del plugin [2].

Come funziona l'integrazione sempre attiva

Il meccanismo varia a seconda della piattaforma ma persegue un unico obiettivo: il contesto deve arrivare senza che l'utente lo richieda. Su Claude Code, gli hook si attivano all'inizio della sessione e di nuovo prima di ogni prompt [1]. Su Codex, un blocco contrassegnato all'interno di AGENTS.md contiene le istruzioni [1]. Su Cursor, una regola applicata costantemente svolge lo stesso compito [1].

Akinator offre anche un percorso tramite plugin di Claude Code. Il marketplace viene aggiunto tramite il suo URL HTTPS, aggiornato con claude plugin marketplace update akinator e rinfrescato con claude plugin update akinator@akinator [2]. Nell'estensione VS Code l'utente digita /plugins, apre Marketplaces, aggiunge lo stesso URL e installa il plugin [2].

L'installer è conservativo riguardo alla proprietà dei file. Interviene solo sui file che riportano il banner di Akinator, preserva le terminazioni di riga esistenti e avvisa se un file AGENTS.override.md andrebbe a oscurare il blocco di Codex [2].

I domini di conoscenza che mantiene

L'ambito documentato di Akinator è un insieme di domini nominati, ognuno dei quali risponde a una domanda diversa riguardante il progetto [1].

Product — cos'è il prodotto, cosa fa e cosa dovrebbe fare [1].
Business — logica di business, regole e motivazioni [1].
Requirements — requisiti attuali ed evolutivi [1].
Drift — come il prodotto si è allontanato dall'intento originale [1].
Architecture — decisioni strutturali, pattern e vincoli [1].
Libraries — dipendenze, versioni e il motivo della loro scelta [1].
Decisions — decisioni tecniche e di prodotto con relativa motivazione [1].
History — la cronologia dei cambiamenti e perché sono avvenuti [1].
Rules — regole di codifica e comportamentali specifiche del progetto [1].
Skills — capacità riutilizzabili dell'agente [1].
Memory — contesto persistente tra le sessioni [1].

La descrizione dell'autore aggiunge dettagli a queste categorie. I processi ripetuti possono essere convertiti in Skills, i fallimenti vengono ricordati, le lezioni vengono applicate come Rules e i cambiamenti vengono tracciati attraverso il prima, il dopo e il perché [3].

Layout del repository e artefatti generati

La skill canonica risiede in skills/everything/ e il repository include anche una directory di skill akinator [2, 5]. La documentazione ha il proprio albero sotto docs [6].

Una regola operativa cruciale si applica al materiale generato. La directory .agents/, ogni router e le pagine wiki generate sono output generati; dovrebbero essere rigenerati piuttosto che modificati manualmente, con i comandi registrati in CLAUDE.md [2]. Il README indirizza i lettori alla logica di progettazione in ADR 0010 e ADR 0011 [2].

Avviso:

Warning: la modifica manuale di router o pagine wiki generati viola il contratto descritto nel README. Rigenerali invece, seguendo i comandi in CLAUDE.md [2].

Come affronta il product drift

Il Drift è trattato come un dominio di prima classe piuttosto che come un effetto collaterale. Poiché lo stato passato, lo stato attuale, la logica di transizione e la direzione futura sono tutti registrati [1], un agente può consultare tale registro prima di agire. In pratica, ciò supporta quattro comportamenti:

Evitare di annullare decisioni che sono state deliberatemente modificate [1].
Comprendere perché lo stato attuale differisca dal piano originale [1].
Rimanere coerenti con la traiettoria del prodotto [1].
Segnalare conflitti tra un nuovo cambiamento e la direzione stabilita [1].

Costruire una "azienda in un repository"

La proposta di valore pratica è che l'agente si comporti come se ricoprisse diversi ruoli contemporaneamente. Ottiene la visione di un ingegnere (architettura, scelta delle librerie, regole di codifica), la visione di un product manager (scope, requisiti, regole di business, drift) e una memoria del team (chi ha deciso cosa, quando e perché) [1]. Quando un utente inserisce il prompt "correggi il tentativo di pagamento fallito", l'agente può consultare il contesto del prodotto, le regole di business, l'architettura, le librerie, le decisioni, la cronologia del drift e le regole del progetto prima di toccare il codice [1].

È in questo senso che lo strumento sostiene di permettere a un'IA di fare "vibe code" come un'azienda completa: il modello non è più intelligente, ma è meglio istruito. Il materiale di supporto del README include una pagina di business case insieme ad architettura, compatibilità, regole, contesto, memoria, ledger, template e un contratto wiki dinamico [2].

Vincoli di progettazione da conoscere

Prestazioni e privacy sono affrontate esplicitamente. Il README descrive lo strumento come economico e veloce, e sottolinea che legge il knowledge pack piuttosto che l'albero, senza utilizzare daemon, rete o servizi di indicizzazione [2].

Per i team preoccupati per il lock-in, la licenza è semplice: MIT, come indicato nel file LICENSE del repository [2]. Il repository espone inoltre i branch per coloro che desiderano seguire l'attività di sviluppo [7].

Dove si colloca tra gli altri progetti dell'autore

Ihab Khaled gestisce altri lavori nello stesso ambito generale. ClawAI è descritto come un control plane AI local-first che esegue modelli open sulla macchina dell'utente connettendosi ai principali fornitori di LLM, con routing, memoria e orchestrazione [8]. Il suo changelog documenta il rilascio 0.2.0, un passaggio da un monolito a nove microservizi NestJS con messaggistica RabbitMQ, Nginx come API gateway e circa venti container sotto Docker Compose [9].

I due progetti affrontano livelli diversi. ClawAI decide quale modello utilizzare; Akinator assicura che il modello scelto comprenda il progetto prima di agire [8][1]. Le project board e i workflow di CI di ClawAI sono questioni infrastrutturali separate [10][11].

Cosa non è documentato pubblicamente

Il README recuperato copre l'installazione, l'integrazione della piattaforma, i domini e il contratto dei file generati, ma non tutto. I formati di file esatti utilizzati per memorizzare ogni dominio, se il recupero utilizzi embedding o corrispondenza per parole chiave, il costo di latenza degli hook, la risoluzione dei conflitti tra le voci di conoscenza, il comportamento del monorepo e i prezzi non sono descritti nel materiale qui esaminato [1, 2].

Alcuni elenchi di terze parti aggiungono dettagli che il repository stesso non conferma. Uno descrive un loop a dodici stazioni che copre ask, resolve, audit, plan, implement, document, skillify, rule, contextify, memoize, index-and-sync e verify, oltre a comandi per l'onboarding, l'esecuzione del loop e l'audit dello strato di conoscenza [13]. Considerate queste informazioni come una descrizione secondaria in attesa di conferma nel repository sorgente.

Nota:

Nota: Il repository non è un motore di ricerca per basi di conoscenza generiche. Repository come AI-Powered-Knowledge-Base-Search coprono l'ingestione di documenti e il recupero semantico, che è un problema diverso rispetto alla cattura dell'intento di un progetto per un agente di codifica [12].

Checklist di adozione

Leggere lo script di installazione prima di eseguirlo, come consigliato dal README stesso [2].
Eseguire la riga di installazione shell o PowerShell, aggiungendo i flag della piattaforma se viene utilizzato un solo agent [1].
Riavviare l'agent e interagire normalmente tramite prompt; non è richiesto alcun comando esplicito [2].
Mantenere i router e le pagine wiki generati rigenerandoli, senza modificarli manualmente [2].
Rieseguire la riga di installazione per aggiornare e utilizzare il flag di disinstallazione per ripristinare il repository byte per byte [2].

La scommessa più ampia è semplice: un agent che conosce il perché di una codebase produce meno modifiche contraddittorie rispetto a uno che vede solo i file. Akinator è un tentativo di rendere tale conoscenza portatile, versionata e automatica [1].