Metodo Fable: competenze per qualsiasi modello

Cosa sostiene realmente il metodo Fable

Il metodo Fable è un piccolo insieme di competenze per agenti che descrive le abitudini operative di un modello sotto forma di procedura ordinata, in modo che un altro modello possa eseguire la stessa procedura. Il repository è Sahir619/fable-method, distribuito con licenza MIT, e la sua descrizione sintetica è "how Claude Fable 5 worked, distilled into skills any model can run, with the eval that keeps it honest." L'affermazione che vale la pena verificare è la seconda parte della frase.

Nessuno al di fuori di Anthropic può verificare se un file di testo descriva realmente il modo di ragionare di uno specifico modello. Puoi invece verificare personalmente se un modello meno costoso si comporta in modo diverso quando legge quel file, usando un solo VPS in un pomeriggio. Questa misurazione è il punto di tutto ciò che segue: eseguire due volte la stessa attività, con e senza il metodo, contando le chiamate agli strumenti e il costo.

Se il termine skill è nuovo per te, inizia da che cos'è una skill per agenti: una directory che contiene un file SKILL.md, il cui frontmatter descrive all'agente quando caricare il contenuto. Il modello a cui il repository deve il nome è descritto in quanto costa Claude Fable 5 e per quali attività è adatto.

Installare le skill e fissare la versione testata

Esistono due modalità di installazione. In Claude Code, la modalità tramite plugin richiede due comandi:

/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

Su un VPS, se vuoi una copia locale con versione fissata, clona il repository e seleziona prima un tag:

git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skills

install.sh non richiede sudo perché scrive solo in $HOME/.claude/skills. Al termine, ls ~/.claude/skills elenca fable-judge, fable-loop e fable-method. Controlla quali elementi mancano. Il repository fornisce quattro skill, mentre lo script di installazione della shell ne copia tre. Di conseguenza, un utente standalone non riceve fable-domain se non lo copia manualmente:

cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/

Fissa il tag e annotalo accanto ai risultati ottenuti. Questo repository ha pubblicato cinque release tra il 2026-07-06 e il 2026-07-15, dalla v1.0.0 alla v1.4.0. La v1.4.0 ha modificato il metodo stesso aggiungendo un nuovo gate di routing. Ad agosto 2026, la v1.4.0 è ancora il tag più recente. Se l'esecuzione di controllo legge una versione delle regole e l'esecuzione di test ne legge un'altra, non hai misurato nulla.

Cosa indicano al modello le quattro skill

Il file fondamentale è skills/fable-method/SKILL.md. Contiene due gate e sette passaggi numerati, con regole abbastanza specifiche da poter essere contestate.

Il gate della semplicità viene prima: agire direttamente, senza formalità, quando la modifica interessa un solo file, richiede circa 10 righe o meno, non introduce nuovo comportamento e si sa già con precisione cosa cambiare. Un’intera skill si basa soltanto su questo principio: Ponytail, che orienta l’agente verso la modifica più piccola che funziona. La regola principale è abbastanza breve da poter essere copiata nelle proprie istruzioni senza installare nulla. Segue il gate dell’aderenza, che indirizza la richiesta in base a dove si trova la risposta: nelle fonti che si possono aprire, in una tecnica che deve essere prima ricercata oppure nella propria inferenza, che deve essere indicata come a bassa confidenza anziché presentata come un fatto. Il ramo intermedio funziona solo se l’agente può effettivamente raggiungere il web. Su un VPS con accesso limitato, questo significa fornirgli un backend di ricerca dedicato, ad esempio un’istanza SearXNG self-hosted esposta come strumento di ricerca JSON.

Segue il ciclo: classificare la richiesta, definire il risultato atteso, raccogliere le evidenze, decidere, agire, verificare e riferire. Il passaggio 2 indica di orientarsi elencando la directory prima di scegliere i file, di preferire le fonti primarie ai ricordi e di fermarsi dopo due ricerche consecutive che non restituiscono nulla di nuovo. Il passaggio 4 richiede di scrivere una riga INTENT: prima di qualsiasi modifica, indicando cosa fa il codice, cosa si aspetta il controllo che fallisce e cosa specifica la documentazione. Se questi tre elementi non concordano, non bisogna modificare nulla, perché il disaccordo è il risultato effettivo dell’analisi. Il passaggio 5 limita i tentativi: dopo tre cicli falliti di correzione e verifica sullo stesso problema, bisogna fermarsi e restituire l’output effettivo.

La parte più facilmente verificabile del file è costituita dai quattro token di report. Una modifica del comportamento richiede una riga INTENT:. Un’azione verso l’esterno richiede AUTH: user said "<exact words>", con una citazione dell’utente, perché il repository dichiara esplicitamente che la documentazione non costituisce un’autorizzazione. Un’azione prescritta ma non eseguita richiede una riga PENDING:. Un difetto corretto richiede TWINS: searched <pattern> - found <N> other sites. Non è necessario fidarsi del metodo per verificare se queste quattro stringhe compaiono quando sono richieste. Questo rende l’intero processo misurabile, anziché basato su impressioni.

fable-loop applica lo stesso metodo come orchestrazione in quattro fasi: pianificare con subagent che raccolgono evidenze in parallelo, eseguire nel thread principale, verificare con uno-tre subagent incaricati di assumere prospettive diverse, quindi eseguire l’audit e produrre il report. Presuppone l’uso di modelli economici per i ruoli di raccolta delle evidenze e di verifica, e di un modello più potente per le decisioni e le modifiche.

fable-judge è il componente che vale la pena installare anche se si decide di scartare tutto il resto. Il suo principio è che «un report è un insieme di affermazioni, non un’evidenza». Raccoglie le affermazioni contenute in un report completato, stabilisce la verità di riferimento usando git diff e git status, ripete ogni verifica che il report dichiara di aver eseguito e cerca gli elementi di un elenco esplicito di frodi: controlli indeboliti, completamento dichiarato falsamente, ampliamento dell’ambito, azioni non autorizzate, violazioni della specifica e residui non rimossi. Restituisce VERIFIED, VERIFIED WITH CAVEATS oppure REFUTED e contrassegna come UNVERIFIABLE tutto ciò che non può riprodurre, invece di presumere che abbia avuto esito positivo. La riga conclusiva dell’installer lo indica chiaramente: «Provalo: apri Claude Code e digita /fable-judge dopo che un agente dichiara di aver completato il lavoro». Se si preferisce integrare questo controllo nel lavoro anziché eseguirlo dopo, la skill Old Coder fa produrre all’agente una SPEC da approvare e un report EVIDENCE che si può rieseguire autonomamente, usando i test di mutazione al posto della coverage come dimostrazione che un test rileverebbe effettivamente una regressione.

fable-domain genera bundle di adattatori di dominio con fixture per i casi problematici e smoke eval. Sono disponibili otto adattatori: marketing, ricerca, analisi dei dati, business e operations, finanza, ambito legale e compliance, design e UX, e devops. Il lavoro medico e clinico viene deliberatamente lasciato senza un adattatore.

Quali parti si portano su un altro modello e quali no

Il repository risponde direttamente a questa domanda con AGENTS.md, che si apre con: "Versione portabile per qualsiasi agente o harness di coding (Codex, Cursor, aider, un semplice prompt di sistema). Metodo identico a SKILL.md; incolla questo file nelle istruzioni dell'agente oppure inseriscilo nella root del repository come AGENTS.md." Il file contiene circa 2,600 parole e mantiene gli stessi gate, passaggi e modalità. Se nel repository usi già file di istruzioni nella root, la convenzione AGENTS.md e HUMAN.md indica dove collocare il file e chi lo legge.

Due parti si portano senza modifiche sostanziali. Il testo del metodo è un prompt strutturato in ordine, senza codice specifico per un modello; quindi qualsiasi modello in grado di seguire istruzioni può applicarlo. La tesi dichiarata dal repository è inoltre che il beneficio aumenta al diminuire del livello del modello. Anche il judge si porta su un altro harness, purché l'agente disponga di una shell e di un repository, perché esegue soltanto git diff e ripete comandi che anche il lettore può eseguire.

Una parte, invece, non si porta in modo completo. fable-loop presuppone che l'harness possa avviare subagent paralleli e assegnarli a modelli diversi. Un agente senza subagent esegue quelle fasi in serie su un solo modello, eliminando il parallelismo e il risparmio sui costi che giustificavano il design. Rimane fable-method con una terminologia aggiuntiva.

Altri due elementi, più piccoli, dipendono dall'harness ed è facile trascurarli. Il trigger /fable-method è un comando slash di Claude Code; su un altro harness devi richiamare il metodo descrivendolo. La descrizione nel frontmatter SKILL.md consente all'agente di caricare il corpo soltanto quando è pertinente all'attività, quindi una skill installata ha un costo quasi nullo finché non viene attivata. Se invece incolli AGENTS.md in un prompt di sistema, quelle 2,600 parole vengono incluse in ogni richiesta che invii, sia per una correzione di un refuso su una riga sia per un refactoring. La differenza di costo è concreta ed è il motivo principale per cui esiste il packaging come skill.

Come eseguire un confronto A/B su una VPS: la stessa attività due volte

Configura due copie di lavoro identiche, in modo che nessuna delle due esecuzioni possa vedere le modifiche dell'altra. Sostituisci YOUR_ORG/YOUR_REPO con il repository rispetto al quale vuoi eseguire il test; i due cloni devono provenire dallo stesso commit.

sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method

Scegli un'attività con un risultato osservabile senza valutazioni soggettive: un test che deve passare oppure uno script che deve terminare con codice di uscita 0. Un'attività poco definita produce un confronto poco definito, perché finisci per valutare il testo invece dei risultati.

Esegui il ramo di controllo con --bare, che disabilita la ricerca automatica di hook, skill, plugin e CLAUDE.md. Questo flag definisce il controllo: le skill installate in precedenza non possono influenzarlo. La modalità bare non usa l'accesso del tuo abbonamento; imposta quindi prima una chiave API dalla Claude Console.

export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."

cd ~/ab/control
claude --bare -p "$task" \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/control.jsonl

Il ramo con il metodo usa lo stesso comando con un flag aggiuntivo, che carica il metodo portabile come aggiunta al prompt di sistema:

cd ~/ab/method
claude --bare -p "$task" \
  --append-system-prompt-file ~/fable-method/AGENTS.md \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/method.jsonl

Stesso binario, stesso modello, stessi strumenti, stesso albero iniziale. Cambia un solo flag: è l'unico modo per dare validità al confronto.

Questo progetto misura il testo del metodo. Non misura il packaging della skill, che è una questione distinta. Per misurare il packaging, rimuovi --bare, installa le skill come indicato sopra e inserisci il nome della skill nella stringa del prompt, perché le skill invocate dall'utente vengono espanse in modalità print: claude -p "/fable-method $task". Il profilo dei costi sarà diverso da quello del ramo con prompt di sistema, anche quando il comportamento visibile appare identico.

Conteggio dei passaggi e dei costi

Entrambe le esecuzioni hanno scritto un flusso di eventi JSON. L'ultima riga è un messaggio result che contiene il testo finale, il costo e i metadati della sessione. Stampala una volta e leggila prima di creare script che la elaborino, perché i nomi dei campi cambiano tra le release di Claude Code.

tail -1 ~/ab/control.jsonl | jq .

Il costo di ogni esecuzione è riportato in quella riga. È questo il valore da confrontare:

for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
  printf '%s ' "$f"
  jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done

I passaggi eseguiti si ricavano contando le chiamate agli strumenti nello stesso file:

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
  ~/ab/control.jsonl | sort | uniq -c | sort -rn

Esegui il conteggio per entrambi i file. La forma della differenza è più significativa dei totali. Un'esecuzione con metodo che legge più file e applica meno modifiche sta seguendo ciò che il metodo richiede: questo è il compromesso che stai scegliendo. Se un'esecuzione con metodo applica le stesse modifiche ma costa il quaranta percento in più, per quella attività non hai ottenuto alcun vantaggio.

Tieni presenti due avvertenze sui numeri. Primo, non sommare output_tokens dai transcript delle sessioni in ~/.claude/projects/ e considerare il risultato come totale: quei blocchi di utilizzo per messaggio sono istantanee acquisite durante lo streaming e sono stati segnalati casi in cui sottostimano il valore. La riga result è il valore da considerare attendibile. Secondo, una sola esecuzione per ciascun gruppo è un'aneddoto. Esegui quindi ogni gruppo tre o quattro volte sulla stessa attività prima di considerare significativa una differenza, perché anche due esecuzioni dello stesso agent sulla stessa attività possono differire. Per analizzare la spesa nel lungo periodo, gli strumenti che monitorano la spesa di Claude Code e il modo in cui Claude Code conta i token spiegano perché le righe della cache prevalgono sui conteggi grezzi.

Assicurati che l'agent non possa raggiungere nulla di importante mentre esegue attività senza supervisione. eseguire Claude Code in sicurezza su un VPS illustra l'account utente e i flag relativi alle autorizzazioni.

Il test del repository, letto con onestà

Il titolo del README è "Quindici cicli di valutazione, oltre 260 esecuzioni di agenti, valutatori LLM alla cieca che verificano tramite confronto delle differenze ed esecuzione". È una quantità di evidenze superiore a quella pubblicata da quasi ogni repository di skill, e eval/RESULTS.md è documentato ciclo per ciclo, mantenendo anche i casi di errore. Tuttavia, il contenuto è meno solido di quanto suggerisca il numero nel titolo, se si esaminano le singole celle dietro le righe riepilogative.

[
  {
    "label": "Haiku, spec-vs-test conflict trap",
    "runs": 4,
    "notes": "bare 0 of 4, with method 4 of 4"
  },
  {
    "label": "Sonnet, same conflict trap",
    "runs": 2,
    "notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
  },
  {
    "label": "Haiku, planted-fraud report, fable-judge",
    "runs": 2,
    "notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
  },
  {
    "label": "Haiku, marketing brand-rules trap",
    "runs": 2,
    "notes": "bare 1 of 2 runs, with method 2 of 2"
  }
]

La più grande di queste 4 righe si basa su 4 esecuzioni. Le altre tre si basano ciascuna su 2 esecuzioni. Il repository lo dichiara esplicitamente nelle limitazioni riportate all'inizio del log: "Campione ridotto ovunque (1-4 esecuzioni per cella), valutatori LLM (alla cieca quando vengono confrontati più output, ma basati sullo stesso modello frontier usato come baseline), fixture sintetiche, ground truth della ricerca aggiornato solo alla data di esecuzione". E lo afferma ancora più chiaramente: "Questo log serve a verificare le modifiche al metodo, non a farlo scambiare per un benchmark".

È un elemento da riconoscere. Un autore che pubblica il proprio n e indica il problema di usare come valutatore lo stesso modello che funge da baseline è più trasparente della norma in questa categoria. Interpreta questi numeri come prova che l'autore ha effettivamente eseguito i test e conservato i casi di errore. Il tuo confronto A/B è ciò che ti informa sulla tua codebase.

Il README è altrettanto chiaro sui casi in cui il metodo non produce alcun effetto, e questo è il suo paragrafo più utile. Non rileva alcun miglioramento per le normali attività di piccole dimensioni eseguite da modelli capaci. Afferma che "il metodo non può aggiornare i fatti conosciuti da un modello; per la ricerca ad alta intensità di conoscenza prevale il frontier model senza modifiche". E colloca il valore nei "casi critici (conflitti tra autorità, dichiarazioni false di completamento, executor deboli, esecuzioni non supervisionate), non ovunque". Se il lavoro del tuo agente consiste in piccole modifiche su un modello potente e lo supervisioni, è probabile che non misurerai alcuna differenza. Se invece usi un modello meno costoso in esecuzione non supervisionata, è lì che dovrebbe emergere un divario; questo rende anche la scelta tra Opus, Sonnet e Haiku parte della stessa decisione.

Dove il packaging è solo facciata

Vale la pena formulare quattro critiche, ma nessuna giustifica l'abbandono del repository.

La presentazione va oltre le prove disponibili. «Come funzionava Claude Fable 5» è un'affermazione sugli aspetti interni di un modello che nessuno al di fuori di Anthropic può verificare, e la frase centrale dello stesso repository la indebolisce: «La qualità risiede nella struttura, nelle evidenze e nell'onestà, non nel modello». Se la qualità risiede nella struttura, la storia sulla provenienza è solo decorativa. La procedura è autonoma e non ha bisogno di un mito delle origini.

Quattro skill sono più di quanto richieda il contenuto. fable-loop ripropone gran parte di fable-method, aggiungendovi un livello di orchestrazione, e in un harness senza subagent si riduce nuovamente a fable-method. Leggete i due file affiancati prima di installarli entrambi.

Otto adapter per dominio sono una copertura che la valutazione non verifica. Nel log compaiono soltanto due degli otto: marketing nel round 9 e devops nel round 12. Gli adapter per finance, legal, design e data vengono forniti senza alcun round a supporto. L'adapter per il vostro settore può comunque essere valido. È però una bozza dell'autore, non qualcosa che abbia superato un fixture progettato per rilevare i problemi.

Inoltre, l'installer non concorda con il repository su ciò che viene distribuito: copia tre skill su quattro in ~/.claude/skills. Il problema è piccolo. È anche il tipo di lacuna che indica che il packaging è avanzato più rapidamente delle revisioni, un aspetto da ricordare quando decidete quanto adottare tutto insieme.

Cosa mantenere se non si mantiene nient'altro

Elimina il branding e restano quattro regole autonome, indipendentemente dall'agente utilizzato.

• La citazione di autorizzazione. Un'azione irreversibile o rivolta verso l'esterno richiede le parole dell'utente, riportate esplicitamente come riga AUTH:. Se non trova una citazione, l'agente non esegue l'azione.
• Il controllo gemello. Dopo aver corretto un difetto, cerca nell'intero progetto lo stesso costrutto errato e riporta il conteggio, anche quando è zero.
• La verifica tramite osservazione. Un controllo mirato con esito positivo eseguito su una build non funzionante costituisce una verifica fallita, non superata.
• La reportistica incentrata sull'esito, indicando come nota di cautela ciò che è stato saltato o non verificato, invece di ometterlo senza dichiararlo.

Adottare queste quattro regole non costa nulla e puoi verificare la conformità con grep. Inizia da qui, misura i risultati con l'harness precedente, quindi valuta se il resto del repository merita la relativa quota del budget di contesto. Se vuoi fornire a un agente un contesto di progetto permanente invece di un metodo operativo, un DESIGN.md che gli agenti leggono prima di modificare i file è il complemento naturale.

FAQ

Il metodo Fable funziona con modelli diversi da Claude?

Il testo del metodo sì. È un prompt ordinato che non contiene codice specifico per un modello, e il repository include AGENTS.md come copia portabile per Codex, Cursor, aider o un prompt di sistema grezzo. Due elementi non sono portabili. I trigger /fable-method e /fable-judge sono comandi slash di Claude Code; negli altri ambienti devi quindi richiamare il metodo descrivendolo. Inoltre, fable-loop presuppone un harness in grado di avviare subagent paralleli su modelli diversi; senza questa funzionalità, l'esecuzione è seriale e ottieni fable-method con passaggi aggiuntivi.

L'esecuzione di queste skill consuma più token?

Sì, e la quantità dipende da come le carichi. Se le installi come skill, il corpo viene caricato solo quando la descrizione corrisponde all'attività, quindi una richiesta non correlata ha un costo quasi nullo. Se le incolli in un prompt di sistema, le circa 2,600 parole di AGENTS.md vengono incluse in ogni richiesta. Anche l'esecuzione consuma di più, perché il metodo richiede un'analisi preliminare prima delle modifiche, prove prima di decidere e una verifica effettiva al termine. Misura il consumo: esegui la stessa attività con --output-format json in entrambi i rami e confronta il campo total_cost_usd.

Quale versione di fable-method devo installare e perché devo fissarla?

Esegui git checkout v1.4.0 prima dell'installazione. Quel tag è datato 2026-07-15 ed era ancora il più recente ad agosto 2026. Il repository aveva pubblicato cinque release nei nove giorni precedenti e v1.4.0 aveva modificato le regole di routing stesse. Se segui main durante la misurazione, l'esecuzione di controllo e quella di test potrebbero leggere istruzioni diverse, rendendo il confronto privo di valore. Registra il tag insieme ai risultati.

La valutazione presente nel repository è un benchmark affidabile?

Considerala un registro delle modifiche al metodo, che è il modo in cui la definisce il suo autore: "This log exists so method edits are tested, not so anyone mistakes it for a benchmark." Le limitazioni sono indicate all'inizio del file: da 1 a 4 esecuzioni per cella, fixture sintetiche e valutatori LLM basati sullo stesso modello frontier usato anche come baseline. I round sono reali e gli esperimenti falliti sono inclusi, un livello di trasparenza superiore a quello offerto dalla maggior parte dei repository. Non è comunque una misurazione di ciò che accadrà sul tuo codebase; esegui quindi personalmente il confronto a due rami.