The Fable Method: O Workflow Que Fez o Claude Fable 5 Funcionar — Agora Para Qualquer Modelo

Pense. Aja. Prove. Três palavras que resumem o método mais comentado do momento no ecossistema de agentes de código. O Fable Method (também chamado de Fable Workflow) é uma distilhação pública de como o Claude Fable 5 — modelo que foi removido do plano Subscription da Anthropic — abordava problemas. E o mais importante: ele foi escrito para qualquer modelo seguir, não apenas o Fable 5.

Criado pelo desenvolvedor Sahir619 (com contribuições da comunidade e do próprio Claude), o repositório fable-method já ultrapassou 1800 estrelas no GitHub e 266 forks em poucas semanas. Não é hype: os números de avaliação são concretos.

O Problema Que o Fable Method Resolve

Agentes de código falham em padrões previsíveis, especialmente modelos fracos ou de médio porte:

• Ignoram a especificação e "consertam" o código certo
• Declaram tarefa concluída sem verificar
• Escrevem APIs de memória (que não existem)
• Tomam ações que ninguém pediu (deploy, push)
• Fazem uma alteração e ignoram cópias do mesmo bug em outros arquivos

O Fable Method trata isso como um problema procedural, não de inteligência. Um modelo que segue o loop à risca supera um modelo mais forte que "voa livre" — essa é a tese central do projeto, e as avaliações provam isso.

O método não torna o modelo mais inteligente. Torna-o disciplinado e honesto.

A Origem: Como o Método Foi Criado

O Fable Method não é um framework teórico. Ele nasceu de sessões de trabalho com o Claude Fable 5 nos seus últimos dias antes de ser removido do plano Subscription:

1. O Fable 5 escreveu o primeiro rascunho do seu próprio método
2. Três agentes críticos adversários atacaram esse rascunho (usabilidade para modelos fracos, fidelidade, inchaço)
3. Cada regra que sobreviveu ganhou seu lugar corrigindo uma falha observada nas rodadas de avaliação
4. O próprio Fable 5 quebrou uma de suas regras durante os testes e foi superado por modelos mais baratos seguindo a versão escrita

A lição: a estrutura do trabalho agêntico importa mais que o julgamento dentro de cada passo.

Os Quatro Pilares: Think, Act, Prove, Grow

O método é dividido em quatro skills (habilidades) que funcionam juntas:

O Loop Principal: 7 Passos

Passo 0 — Classifique a Pergunta

Desempate: se qualquer sinal de "plano primeiro" aparecer, ele vence. Se a dúvida persistir entre tarefa e plano, escolha plano primeiro.

Passo 1 — Defina "Pronto"

Em uma ou duas frases: como fica o resultado final e como será verificado.

• Tarefa: uma observação concreta (este teste passa, o build fica verde, este número muda)
• Pergunta: cada afirmação traça para algo que você realmente leu ou executou
• Plano: um plano que o usuário pode aprovar, com a verificação nomeada para cada passo

Passo 2 — Reúna Evidências

1. Oriente-se primeiro. Liste o diretório, faça um glob no projeto antes de ler qualquer arquivo específico.
2. Fontes primárias vencem memória. Leia o código real, os arquivos reais. Nunca invente uma API, endpoint ou caminho.
3. Paralelize o que for independente e caro. Web fetches, consultas de documentação, subagentes exploratórios — tudo em um lote paralelo.
4. Leia estreito, nunca releia. Busque para localizar a seção relevante, depois leia só ela.
5. Limite de tempo mecânico. Uma rodada de consultas + uma rodada de acompanhamento cobrem a maioria das tarefas.
6. Estabeleça a intenção antes de alterar comportamento. Um teste falhando tem dois culpados possíveis: o código ou o teste. Descubra qual.
7. Supreendentes redirecionam o loop. Se algo contradiz sua expectativa, essa é sua descoberta mais importante: comunique ao usuário.

Passo 3 — Decida e Comprometa-se

Sintetize as evidências em uma recomendação. Se considerou alternativas, nomeie cada uma em uma linha e diga por que perdeu.

Portão de autorização: uma ação irreversível ou voltada para o exterior (push, publish, send, deploy) precisa das próprias palavras do usuário. Escreva a linha AUTH: user said "". Se não houver citação, não aja.

Passo 4 — Aja Cirurgicamente

1. Portão de intenção: antes de qualquer edite que mude comportamento, escreva INTENT: code does ; check expects ; spec says . Abra o README/docs para preencher Z.
2. Portão de memória: antes de usar algo que você não abriu nesta sessão (API, endpoint, config key), pare e abra a fonte agora.
3. Menor alteração correta. Toque só o que a tarefa precisa.
4. Edições precisas > reescritas completas.
5. Trabalho com múltiplas partes usa checklist escrito.
6. Nunca destrua sem olhar.
7. Escada de recuperação: releia a região, ajuste, tente uma vez. Só então amplie.
8. Proibições permanentes: nunca commit ou push; nunca enfraqueça um teste; nunca toque em secrets; nunca adicione dependência.

Passo 5 — Verifique por Observação

• (a) O critério de "pronto" passa, observado (executou, renderizou, contou)
• (b) O sistema ao redor ainda funciona (build, testes existentes, lint)
• (c) Twin Check (novo na v1.4): se corrigiu um defeito, procure pelo mesmo padrão no projeto inteiro e escreva TWINS: searched - found sites:

Limite: após 3 ciclos falhos de corrigir-verificar no mesmo problema, PARE e devolva ao usuário.

Passo 6 — Relatório com o Resultado Primeiro

• A primeira frase responde "o que aconteceu" ou "o que você descobriu"
• Detalhes vêm depois, sem números de passo
• Inclua as ressalvas: o que foi pulado, o que ainda está fraco, o que não pôde ser verificado
• Portão de artefato (novo v1.4): varra o relatório final: comportamento mudou mas sem INTENT? Adicione. Ação externa sem AUTH? Adicione. Defeito corrigido sem TWINS? Adicione.

Resultados das Avaliações

Os números falam por si. O repositório tem 15 rodadas de avaliação com mais de 260 execuções de agente, todas documentadas com juízes cegos que verificam por diff e execução, nunca por relatório.

Onde o método NÃO ajuda: modelos capazes em tarefas pequenas e limpas. O valor está concentrado em armadilhas — conflitos de autoridade, alegações falsas de conclusão, executores fracos, execuções não supervisionadas.

Instalação — 3 Formas

1. Como Plugin do Claude Code (Recomendado)

# Dentro de uma sessão Claude Code:
/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

As quatro skills chegam com namespace (/fable:fable-method, /fable:fable-loop, etc.) e versionadas.

2. Como Skills Avulsas

git clone https://github.com/Sahir619/fable-method
bash fable-method/install.sh

Instala em ~/.claude/skills/ como /fable-method, /fable-loop, /fable-judge.

Windows PowerShell:

git clone https://github.com/Sahir619/fable-method
.\fable-method\install.ps1

3. Como AGENTS.md (Universal — Qualquer Harness)

O repositório fornece um arquivo AGENTS.md idêntico ao método, mas sem frontmatter específico do Claude. Copie para a raiz do seu projeto e qualquer agente compatível vai lê-lo.

Configuração Para Diferentes Harnesses

Claude Code

Já coberto acima via plugin ou skills avulsas. Para tornar o método proativo, adicione ao seu ~/.claude/CLAUDE.md global:

# Fable family (think / act / prove)
- Before any non-trivial multi-step task, apply the fable-method loop
- After completing substantive work, run a fable-judge pass before presenting

OpenCode

O OpenCode (ex-SST) lê AGENTS.md do projeto e também suporta arquivos globais.

Para usar como regras de projeto:

# Copie o AGENTS.md do repositório para seu projeto
curl -sL https://raw.githubusercontent.com/Sahir619/fable-method/main/AGENTS.md > AGENTS.md

Ou use /init dentro do OpenCode para criar o arquivo.

Para usar como regras globais (aplicam a todos os projetos):

mkdir -p ~/.config/opencode
curl -sL https://raw.githubusercontent.com/Sahir619/fable-method/main/AGENTS.md > ~/.config/opencode/AGENTS.md

Para usar como skills OpenCode:

# Skills globais
mkdir -p ~/.config/opencode/skills
cp -r fable-method/skills/* ~/.config/opencode/skills/

# Ou skills por projeto
mkdir -p .opencode/skills
cp -r fable-method/skills/* .opencode/skills/

Precedência de regras no OpenCode:

1. AGENTS.md local (sobe até a raiz do projeto)
2. CLAUDE.md local (fallback se AGENTS.md não existir)
3. ~/.config/opencode/AGENTS.md (global)
4. ~/.claude/CLAUDE.md (fallback global)

OMP (Oh My Pi)

O OMP lê AGENTS.md e CLAUDE.md de múltiplas fontes. Sua configuração é flexível:

Usando AGENTS.md no projeto:

# Na raiz do projeto
curl -sL https://raw.githubusercontent.com/Sahir619/fable-method/main/AGENTS.md > AGENTS.md

Usando AGENTS.md global (usuário):

# OMP nativo lê AGENTS.md de .omp/
mkdir -p ~/.omp/agent
curl -sL https://raw.githubusercontent.com/Sahir619/fable-method/main/AGENTS.md > ~/.omp/agent/AGENTS.md

Usando skills OMP:

# Skills nativas
mkdir -p ~/.omp/agent/skills/fable-method
curl -sL https://raw.githubusercontent.com/Sahir619/fable-method/main/skills/fable-method/SKILL.md > ~/.omp/agent/skills/fable-method/SKILL.md

# Skills do projeto
mkdir -p .omp/skills/fable-method
curl -sL https://raw.githubusercontent.com/Sahir619/fable-method/main/skills/fable-method/SKILL.md > .omp/skills/fable-method/SKILL.md

Personalização via SYSTEM.md: O OMP também aceita ~/.omp/agent/SYSTEM.md para substituir o prompt de sistema inteiro. Você pode incorporar o Fable Method lá.

Precedência OMP:

1. .omp/ no projeto (nativo, prioridade 100)
2. .claude/ no projeto (prioridade 80)
3. ~/.omp/agent/ (usuário nativo)
4. ~/.claude/ (fallback)

Codex CLI (OpenAI)

O Codex CLI também suporta AGENTS.md:

# Coloque o AGENTS.md na raiz do projeto
curl -sL https://raw.githubusercontent.com/Sahir619/fable-method/main/AGENTS.md > AGENTS.md

Configuração global via ~/.codex/config.toml (para instruções persistentes).

Tabela Comparativa de Configuração

AGENTS.md: O Formato Universal

A grande vantagem do Fable Method é que ele é distribuído como AGENTS.md — um formato aberto que funciona em mais de 20 ferramentas e agentes diferentes. A lista inclui:

RooCode, Gemini CLI, Warp, Semgrep, Amp, Kilo Code, Aider, OpenCode, Codex (OpenAI), Jules (Google), Augment Code, Devin (Cognition), Cursor, VS Code, Windsurf, Zed, GitHub Copilot, Junie (JetBrains), goose, Phoenix, Factory, e mais.

A principal recomendação do projeto: para usar em qualquer harness que não seja Claude Code, basta copiar o AGENTS.md para a raiz do projeto.

Exemplo Prático: Aplicativo Flutter Todo com Modelo Barato

Vamos ver o Fable Method aplicado a um caso real: criar um aplicativo de lista de tarefas (Todo) em Flutter usando um modelo de API gratuito ou barato (como Gemini Flash, Haiku, ou Llama 3 via Groq).

Passo 1: Configure o Método no seu Harness

Escolha o AGENTS.md universal:

curl -sL https://raw.githubusercontent.com/Sahir619/fable-method/main/AGENTS.md > AGENTS.md

Se estiver usando OMP com modelo barato:

# Configure o modelo barato como padrão
omp --smol gemini/gemini-2.0-flash-exp
# Ou via .omp/config.yml:
# model: gemini/gemini-2.0-flash-exp

Se estiver usando OpenCode com Gemini:

opencode --provider gemini

Passo 2: Prompt para o Agente (Já com o Fable Ativo)

Com o AGENTS.md carregado, você dá o seguinte prompt:

>

>

Passo 3: O Que o Fable Method Faz Internamente (Trace)

Aqui está o que acontece nos bastidores quando um agente segue o método:

0 — Classifica: tarefa. Escopo claro, várias operações.

1 — Define pronto: app funcional com as 7 funcionalidades, testes passando, build limpo.

2 — Evidências: o agente pesquisa a estrutura típica de um app Flutter, verifica a versão atual do sqflite na pub.dev, lê exemplos de Material Design 3. Tudo em paralelo: um subagente para pesquisa de docs, outro para olhar projetos de referência.

3 — Decide: recomenda arquitetura com camadas: model/, repository/, ui/screens/, ui/widgets/. Scope: arquivos dentro de lib/ e test/.

4 — Age cirurgicamente (com checklist):

• ✓ criar pubspec.yaml com dependências (sqflite, path_provider, provider)
• ✓ criar lib/models/todo.dart — classe Todo com id, título, descrição, concluído, data
• ✓ criar lib/repository/todo_repository.dart — CRUD com SQLite
• ✓ criar lib/ui/screens/todo_list_screen.dart — tela principal com filtros
• ✓ criar lib/ui/widgets/todo_item.dart — widget de item individual
• ✓ criar test/models/todo_test.dart — teste unitário
• ✓ executar flutter pub get
• ✓ executar flutter analyze

INTENT antes de cada alteração: antes de definir o modelo, escreve INTENT: sqflite docs say use toMap()/fromMap() pattern; tests expect proper equality; spec requires id, title, description, isDone, createdAt.

TWINS depois de cada correção: se encontrar um bug no repositório, procura pelo mesmo padrão no projeto todo.

5 — Verifica: flutter test roda, flutter analyze limpo, build compila.

6 — Relatório: resultado primeiro, detalhes depois, caveats honestos.

Resultado Esperado (Código Gerado)

O agente geraria algo como:

// lib/models/todo.dart
class Todo {
  final int? id;
  final String title;
  final String description;
  final bool isDone;
  final DateTime createdAt;

  Todo({
    this.id,
    required this.title,
    this.description = '',
    this.isDone = false,
    DateTime? createdAt,
  }) : createdAt = createdAt ?? DateTime.now();

  Map<String, dynamic> toMap() => {
    'id': id,
    'title': title,
    'description': description,
    'isDone': isDone ? 1 : 0,
    'createdAt': createdAt.toIso8601String(),
  };

  factory Todo.fromMap(Map<String, dynamic> map) => Todo(
    id: map['id'] as int?,
    title: map['title'] as String,
    description: map['description'] as String? ?? '',
    isDone: (map['isDone'] as int) == 1,
    createdAt: DateTime.parse(map['createdAt'] as String),
  );

  Todo copyWith({int? id, String? title, String? description, bool? isDone, DateTime? createdAt}) =>
      Todo(
        id: id ?? this.id,
        title: title ?? this.title,
        description: description ?? this.description,
        isDone: isDone ?? this.isDone,
        createdAt: createdAt ?? this.createdAt,
      );
}

// lib/repository/todo_repository.dart
import 'package:sqflite/sqflite.dart';
import '../models/todo.dart';

class TodoRepository {
  static Database? _db;

  Future<Database> get database async {
    if (_db != null) return _db!;
    _db = await openDatabase(
      'todos.db',
      version: 1,
      onCreate: (db, version) => db.execute(
        'CREATE TABLE todos(id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, description TEXT, isDone INTEGER DEFAULT 0, createdAt TEXT NOT NULL)',
      ),
    );
    return _db!;
  }

  Future<int> insert(Todo todo) async {
    final db = await database;
    return db.insert('todos', todo.toMap());
  }

  Future<List<Todo>> getAll({bool? isDone}) async {
    final db = await database;
    final maps = isDone != null
        ? await db.query('todos', where: 'isDone = ?', whereArgs: [isDone ? 1 : 0])
        : await db.query('todos');
    return maps.map((m) => Todo.fromMap(m)).toList();
  }

  Future<int> update(Todo todo) async {
    final db = await database;
    return db.update('todos', todo.toMap(), where: 'id = ?', whereArgs: [todo.id]);
  }

  Future<int> delete(int id) async {
    final db = await database;
    return db.delete('todos', where: 'id = ?', whereArgs: [id]);
  }
}

Modelos Baratos Recomendados Para Este Workflow

O Fable Method foi especificamente desenhado para elevar modelos fracos. Aqui estão boas opções gratuitas/baratas:

A combinação Gemini 2.0 Flash + Fable Method via AGENTS.md é provavelmente a mais econômica: modelo gratuito com qualidade impressionante quando disciplinado pelo loop.

Domain Adapters: O Mesmo Loop Fora do Código

O Fable Method não é só para programação. Ele vem com 8 adaptadores de domínio prontos:

E se você precisa de um novo domínio? Use /fable-domain — a skill gera o adaptador, o fixture de teste (trap), e uma avaliação smoke, tudo com fontes pesquisadas da web. E se recusa a gerar domínios de risco (médico, legal, financeiro — onde uma checklist não substitui um profissional qualificado).

Lições Valiosas do Projeto

O Que Funciona em Modelos Fracos

O Ciclo de Iteração Que Criou Cada Regra

O design é brutalmente honesto: cada regra existe porque um teste falhou sem ela. O exemplo clássico:

• v1: regra sobre intenção ausente → Haiku surfou conflito spec vs test em 0 de 4
• v2: regra como prosa no meio da lista → 1 de 4
• v3: artefato forçado INTENT: na linha de decisão → 4 de 4

Onde o Método é Mais (e Menos) Eficaz

Muito eficaz para:

• Execuções com modelos baratos (Haiku, Gemini Flash, Llama)
• Tarefas não supervisionadas (o juiz pega fraudes)
• Tarefas com armadilhas (especificação vs teste, autorizações implícitas)
• Pesquisa e dados (força evidência real)
• Múltiplos arquivos (twin check evita bugs replicados)

Pouco ou nenhum impacto:

• Tarefas triviais (1 arquivo, <10 linhas="linhas">
• Modelos capazes (Sonnet, Opus, GPT-4) fazem isso naturalmente
• Perguntas que dependem de conhecimento recente (o método dá disciplina, não conhecimento)

Conclusão

O Fable Method representa uma mudança de paradigma em como pensamos sobre agentes de código. Em vez de tentar fazer o modelo mais inteligente, ele o torna mais disciplinado — e as avaliações mostram que disciplina compensa mais do que capacidade bruta na maioria das tarefas do mundo real.

Para o desenvolvedor brasileiro que quer maximizar resultados com modelos gratuitos ou baratos, o Fable Method (especialmente via AGENTS.md + Gemini Flash ou Haiku) é a ferramenta mais subestimada do momento. Uma tarde configurando o método pode economizar dias de debug de agentes que "acham que estão certos".

Links e Referências

• Repositório oficial fable-method
• AGENTS.md — versão universal
• Resultados das avaliações
• Documentação das falhas (18 modos de falha)
• Flowcharts do método
• AGENTS.md — formato universal
• OMP (Oh My Pi)
• OpenCode
• Claude Code — mais informações