📜 O que é um playbook
Um playbook é um único arquivo .md acionável. Ele captura o delta que você
mediu não como uma narrativa ("o Fable parecia mais cuidadoso") nem como impressão de vídeo, mas como REGRAS: instruções
imperativas que o modelo-alvo pode seguir — "pense antes de agir", "leia antes de editar". Regra é injetável; impressão não.
🎯 O que faz um playbook honesto
- •1 arquivo: cabe no contexto sem inchar a sessão.
- •Imperativo: cada linha é uma ordem, não uma descrição.
- •Números reais embutidos: o +45 pts vem do SEU corpus.
- •Honesto: diz o que NÃO transfere e o que NÃO copiar.
✓ É um playbook
- ✓"Em tarefa não-trivial, planeje em 2–5 linhas antes da 1ª ferramenta."
- ✓"Nunca edite um arquivo que você não leu neste contexto."
- ✓Cada regra checável e seguível.
✗ NÃO é um playbook
- ✗"O Fable é um modelo muito reflexivo." (impressão)
- ✗Um ensaio sobre como o modelo "pensa".
- ✗Copiar o Fable cegamente, defeitos inclusos.
⚙️ make_playbook.py — gera do compare.json
O gerador é o make_playbook.py. Ele tem dois modos: ou você passa o compare.json
já medido na Trilha 2 (via --from-json, mais rápido), ou ele mede o histórico na hora. Em ambos, o ponto-chave é o
mesmo: os NÚMEROS reais entram no texto das regras — não impressões genéricas.
# reusa o compare já medido (rápido): python make_playbook.py --from-json compare.json \ --out ../playbook/fable-mindset-playbook.md # ou mede o histórico na hora: python make_playbook.py --target claude-opus-4-8 \ --model-fable claude-fable-5
--from-json compare.json
Reaproveita a medição já feita pelo compare_models.py. Mesmo número, sem re-varrer milhares de sessões.
Números injetados no texto
O build_playbook() escreve "99% contra 54% (+45 pontos)" lendo os valores do dict de métricas — não constantes chumbadas no código.
💡 Dica prática
Gere o compare.json uma vez (Trilha 2) e versione-o junto do playbook. Assim qualquer pessoa pode regenerar o .md com --from-json em segundos, sem acesso ao seu histórico bruto.
📶 Ordenar por FORÇA do sinal
A ordem das regras não segue a ordem do vídeo nem a do código — segue a força do sinal medido. O delta robusto é o pensar-antes-de-agir (+45 pts): vem em primeiro. O read-before-edit e o teste-depois entram depois, como boa prática a importar, com a ressalva honesta de amostra pequena — não como delta estatisticamente firme.
Pense antes de agir delta firme · +45 pts
Fable raciocinou em 99% dos turnos vs 54% do Opus. A maior alavanca, a que mais transfere — topo da lista.
⚠ Atualização: medido depois em amostra grande (4.892 passos), o número honesto é ~85% (não 99%) e o gap cai pra +31 pts — e aparece um gap escondido em teste-após-editar (41% vs 2%). Veja a Trilha 4 · A Prova Real.
Ferramenta com propósito densidade
6,57 vs 7,86 ferr./turno: o Fable foi mais econômico. Densidade, não thrashing.
Ler antes de editar boa prática
~34% / ~38% nos dois: modesto em ambos. Disciplina a SUBIR para 100%, não a copiar.
Fechar o loop: teste/build boa prática
Amostra ruidosa (0% / 3%). Entra como hábito a adotar, com a ressalva.
⚠️ Amostra pequena de Fable (7 sessões)
Trate read-antes-de-edit e teste-depois-de-edit como BOA PRÁTICA a importar, não como delta firme. O make_playbook.py até avisa quando há menos de 30 sessões. O sinal robusto aqui é só o raciocínio-antes-de-agir.
🔄 Corrigir, não copiar
Aqui está a parte que distingue um playbook honesto de uma cópia ingênua: ele inverte os hábitos fracos do Fable em vez de replicá-los. Raciocinar em 99% dos turnos é ótimo no difícil — e desperdício num rename de uma linha. Um playbook que copia tudo importaria também os defeitos.
✗ Hábito fraco do Fable
- ✗Over-thinking no trivial — raciocínio até num rename.
- ✗Verbosidade — narra demais o que vai fazer.
- ✗Plano que vira ensaio — planejar longo demais.
✓ Correção no playbook
- ✓Raciocínio proporcional à dificuldade — mecânico vai direto.
- ✓Aja; o resumo vem curto DEPOIS, com caminhos e o que foi verificado.
- ✓O plano cabe em poucas linhas; a profundidade vai para a execução.
🔎 Por que isso importa
O objetivo não é virar o Fable — é melhorar a execução do modelo-alvo. Importar um defeito junto com a virtude anula o ganho. Corrigir mantém só o que ajuda: o ritmo bom, sem o atrito.
🧭 As regras transferíveis
Estas são as regras que o modelo-alvo de fato adota — o coração do playbook. Todas convergem para uma sequência canônica de trabalho.
🧩 As seis regras que transferem
- 1.Pense antes no não-trivial (2–5 linhas de plano antes da 1ª ferramenta).
- 2.Ferramenta com propósito: densidade, não agitação; chamadas independentes no mesmo turno.
- 3.Ler antes de editar → 100%: nunca editar um arquivo não lido neste contexto.
- 4.Fechar o loop com teste/build e relatar o resultado REAL.
- 5.Sequência canônica: entender → plano → ler → editar → testar → relatar.
- 6.Pare quando tiver o suficiente para agir — não re-derive fatos já estabelecidos.
✅ O checklist de uma linha
Todo o playbook destila numa única linha que você cola no topo de tarefas de código. É o lembrete mínimo, de custo de contexto desprezível, que carrega a sequência canônica e as correções. Este é o checklist final, exatamente como sai do gerador:
entender → plano curto → ler → editar → testar → relatar (com output) ·
pense-antes-no-não-trivial · ferramenta-com-propósito · read-before-edit→100% ·
teste-depois-de-edit · sem-verbosidade · sem-over-think-no-trivial
topo da tarefa de código
desprezível (1 linha)
sequência + correções
injetar automático (3.2)
💡 Dica prática
Esse checklist é o resumo; o playbook completo (com a tabela do delta e a seção "NÃO copie isto") é o que você injeta. No Módulo 3.2 vemos como fazer esse arquivo entrar no contexto sozinho a cada sessão.
📜 Resumo do Módulo
make_playbook.py injeta os números reais — do compare.json ou medindo na hora.Próximo Módulo:
3.2 — Injetando no Modelo (e Sem Dados Próprios)