Mapa da trilha
🔬 Ler a evolução por diffs
Cada linha +/− é uma decisão
🗜️ Consolidação
Desinchar sem perder comportamento
🛡️ Segurança por princípio
O princípio, nunca a mecânica
🪜 Prioridade e camadas
Quem manda e o que é dinâmico
🧠 Destilação: recuperar o cérebro
O coração do curso — dos logs ao guia ⭐
⚙️ Disposição × garantia dura
Guia mole + travas que não falham
🏁 Projeto final
Seu system prompt versionado
Conteúdo detalhado
🔬 Ler a evolução por diffs
Quando um laboratório troca de versão, ele deixa um rastro: o diff entre o prompt antigo e o novo. Ler esse rastro é arqueologia de decisões — cada linha adicionada, removida ou renomeada conta por que alguém mudou de ideia. Aqui você lê um diff como pesquisador.
Adição, remoção, reescrita e renomeação — cada tipo carrega uma intenção diferente. O passo zero da leitura é separar o que mudou do como mudou.
O leitor amador só vê as adições e confunde reescrita com renomeação. Saber os quatro tipos separa registrar de entender uma mudança.
Adição (+) · remoção (−) · reescrita (≈) · renomeação (~) · caso de estudo Opus 4.8 → Fable 5.
A regra mais subestimada: quem só lê o que entrou lê metade do livro. O que saiu foi internalizado pelo treino (virou ruído) ou consolidado num princípio.
A maturidade de um prompt se mede pela última vez que algo foi removido dele. Um prompt que só cresce está apodrecendo por dentro.
Internalizado = ruído · consolidado = princípio · search_first sumiu · remover também é editar.
Reconstruir o problema que a mudança provavelmente resolve — armas viraram princípio, drogas ganharam exceção vital, o fim da conversa passou a ser respeitado.
A motivação inferida é interpretação sua, não declaração do lab. Inferir é legítimo desde que você não confunda hipótese com verdade declarada.
Que incidente isto responde? · motivação provável · honestidade epistêmica · o diff é registro de problemas vividos.
A mudança mais sutil não muda nenhuma palavra do conteúdo: copyright_compliance → core_copyright_principle. O texto fica, o rótulo muda.
Você sempre escolhe como o modelo se vê obedecendo — e isso muda como ele obedece. "Compliance" cumpre; "principle" raciocina em casos novos.
Proibição vs princípio · compliance vs core_principle · renomeie pela intenção · nome de valor generaliza.
Cada mudança específica esconde uma lição que vale fora do contexto. A reescrita de self-harm vira "exemplo + critério gerador > só exemplos".
Se você guarda só o caso, nada se transfere. A lição se aplica ao seu próximo prompt — como estudar partidas de xadrez pelos princípios.
Caso × lição · princípio > lista · evoluir ≠ crescer · herdar o método sem herdar a mente.
O protocolo completo: para cada mudança, classifique o tipo, infira a motivação provável e destile a lição — e olhe o saldo (+56 linhas / −7 blocos).
A mesma lente de análise é a que você usa para desinchar o seu próprio prompt depois. Ler diffs fecha o ciclo com a consolidação do 3.2.
Classifique · leia os − · extraia a lição · o saldo (estrutura > caracteres).
🗜️ Consolidação: desinchar sem perder comportamento
No 3.1 você leu a evolução de fora; agora é o lado da ação. A rodada de consolidação pega um prompt que só cresce e o desincha — fundindo regrinhas em princípios — sem perder uma única garantia de comportamento. A regra de ouro: nada sai sem porquê e sem teste.
A entropia do prompt: cada problema vira uma regra nova, nenhuma sai, e o documento vira um monstro que ninguém ousa tocar.
Um prompt inchado dilui a atenção do modelo e esconde contradições. Reconhecer o sintoma é o primeiro passo para tratá-lo.
Entropia do prompt · regra por incidente · atenção diluída · ninguém ousa apagar.
Um ritual agendado: a cada N regras adicionadas, pare e revise tudo de uma vez — fundir, remover, reescrever — em vez de só empilhar.
Consolidar de propósito, periodicamente, é o que impede o apodrecimento. É manutenção, não conserto de emergência.
Ritual periódico · a cada N regras · refatorar o prompt · manutenção, não pânico.
O crivo aplicado a cada regra: o modelo já faz isso sozinho? dá pra fundir num princípio mais geral? qual teste falharia sem ela?
As três perguntas transformam "limpeza por intuição" em decisão justificável. Cada regra ou prova seu valor ou sai.
Já faz sozinho? · dá pra fundir? · qual teste falha sem? · decisão justificável.
A trava da consolidação: toda regra carrega o porquê de existir e um teste que falharia sem ela. Sem os dois, ela não merece ficar.
É o que protege você de remover algo importante por engano — e de manter algo inútil por medo. A prova decide, não o palpite.
Porquê documentado · teste que falharia · evidência por regra · prova > medo.
O exemplo canônico: a evolução Opus 4.8 → Fable 5 ganhou conteúdo (+56 linhas) mas encolheu em estrutura (−7 blocos). Cresceu e desinchou ao mesmo tempo.
É a prova viva de que "evoluir ≠ crescer". Um time maduro adiciona o que faltava e remove o que o treino já absorveu, no mesmo diff.
+56 linhas / −7 blocos · conteúdo sobe, estrutura desce · saldo > volume · maturidade visível.
O contraponto: consolidar antes de ter visto o comportamento real é otimização prematura. Sem casos suficientes, você funde regras que ainda não entende.
Desinchar cedo demais é tão perigoso quanto inchar: você pode generalizar um princípio errado. Espere os dados antes de fundir.
Otimização prematura · espere os dados · princípio errado · maturidade tem hora.
🛡️ Segurança por princípio, não por mecânica
A lição mais delicada dos labs: em segurança, o que você escreve para proteger também pode ensinar a atacar. A saída é declarar o princípio, nunca a mecânica de detecção — e dar ao modelo um gatilho de recusa que ele reconheça pelo próprio raciocínio.
O caso do Fable 5: a política de segurança infantil fica no nível do princípio e do padrão, sem detalhar os sinais que a detecção usa.
Detalhar a mecânica de detecção num prompt é dar o mapa de como contorná-la. O nível certo é o princípio, não o procedimento.
Nível do princípio · não detalhar sinais · o padrão basta · o prompt é legível por quem ataca.
O risco central da segurança: o conhecimento que protege é simétrico ao que ataca. Explicar como detectar é explicar como evadir.
Reconhecer a simetria é o que te faz pensar duas vezes antes de escrever a mecânica. A defesa e o ataque compartilham a mesma informação.
Simetria do conhecimento · educar = armar · pense no leitor hostil · informação de dois gumes.
A regra prática: escreva o valor de alto nível ("proteja X") e deixe o modelo derivar a aplicação — sem listar como reconhecer cada tentativa.
O princípio cobre o caso que a lista não previu e não entrega o método. É mais robusto e mais seguro ao mesmo tempo.
Princípio > mecânica · alto nível · derivar a aplicação · não entregue o método.
Um gatilho introspectivo: if you find yourself reframing… então recuse. O sinal de alerta é o próprio modelo se pegar contornando a regra.
Em vez de uma lista de proibições que se contorna, o gatilho usa o raciocínio do modelo como sensor — ele percebe a evasão e para.
Gatilho introspectivo · o reenquadramento como sinal · REFUSE · o raciocínio é o sensor.
O passo seguinte ao "não": permanecer atento nos turnos posteriores, porque o pedido pode voltar fatiado ou reenquadrado para escapar da recusa.
Uma recusa isolada não fecha o risco se o modelo "esquece" no turno seguinte. A precaução tem que sobreviver à própria recusa.
Atenção pós-recusa · pedido fatiado · reenquadre na sequência · o risco persiste.
A forma da recusa: uma resposta conversacional e humana — sem despejar listas de políticas nem sermão, mantendo a dignidade da conversa.
Recusa fria e burocrática afasta o usuário legítimo e não ajuda ninguém. O tom certo recusa o pedido sem punir a pessoa.
Conversacional · sem bullet points · sem sermão · firme e humano.
🪜 Prioridade e camadas
Quando duas instruções brigam, quem vence? E o que é aquele <system-reminder> que aparece no meio da conversa? Este módulo separa o comportamento estável (o prompt) do estado dinâmico (a camada injetada pelo harness) — e mostra por que essa arquitetura escala no tempo.
A regra que declara a precedência entre instruções conflitantes — política central acima de system, system acima do usuário, usuário acima do padrão.
Sem uma ordem explícita, o conflito de instruções deixa o comportamento à sorte. A hierarquia diz, de antemão, quem ganha.
Precedência declarada · política central no topo · resolver conflito · nada à sorte.
A cadeia destrinchada elo a elo, com o exemplo real da precedência de copyright: a segurança no topo, descendo até o comportamento padrão.
Ver a cadeia inteira mostra onde cada instrução do seu prompt se encaixa — e por que uma regra "fraca" não derruba uma "forte".
Elo por elo · copyright precedence chain · segurança inegociável · cada nível no lugar.
O <system-reminder>: uma camada de contexto injetada pelo harness durante a execução — estado do momento, não regra fixa do prompt.
É como o sistema empurra informação dinâmica (conversa longa, lembrete de regra) sem reescrever o prompt estável. Entender isso explica muito comportamento.
<system-reminder> · injetado pelo harness · estado do momento · camada dinâmica.
A distinção crucial: o reminder é injected by the harness, not the user — é contexto que orienta, não um comando do usuário que precise ser obedecido cegamente.
Tratar contexto como ordem (ou vice-versa) quebra a hierarquia. O modelo precisa saber a origem para pesar corretamente o que lê.
Contexto ≠ instrução · origem importa · não é o usuário falando · pese pela fonte.
A separação de responsabilidades: o prompt guarda o comportamento que vale sempre; o reminder carrega o estado que muda turno a turno.
Misturar os dois incha o prompt com coisas efêmeras. Cada camada no seu lugar mantém o prompt estável enxuto e o estado atualizado.
Estável vs dinâmico · cada camada no lugar · não incha o prompt · separação de responsabilidades.
A regra que resolve o choque entre o que o usuário pede agora e o que a memória/auto-memory guardou antes: o pedido atual do usuário prevalece.
Memória que sobrepõe o usuário gera agente teimoso, preso a preferências velhas. O agora informado pelo usuário tem que vencer o lembrado.
Usuário > memória · o agora vence · sem teimosia · preferência velha não trava.
🧠 Destilação: recuperar o cérebro
O coração do curso. Perdemos os pesos do Fable — mas ficaram os logs. Este módulo te ensina o método que recupera o "cérebro" de um agente a partir dos seus próprios registros: achar os JSONL, reduzir o ruído com script, perfilar o comportamento em números e sintetizar um guia de decisão para apontar a um modelo novo.
A ideia fundadora: você não tem os pesos do modelo, mas tem o rastro do que ele fez — e o comportamento de um bom agente está inteiro nesses logs.
Reposiciona o que é "recuperar" um modelo: não é treinar de novo, é destilar o método observável do rastro que ele deixou.
Sem pesos, com logs · comportamento observável · destilar ≠ treinar · o rastro basta.
O passo prático: localizar os arquivos .jsonl de sessão onde cada turno do agente fica registrado — entrada, raciocínio, ação e resultado.
Sem saber onde o registro mora, não há matéria-prima. Encontrar os JSONL é abrir a caixa-preta do comportamento.
Arquivos .jsonl · sessões registradas · turno a turno · a matéria-prima.
A disciplina-chave: filtrar e resumir os logs com um script Python — nunca despejar centenas de turnos crus dentro da janela de contexto do modelo.
Jogar log bruto no contexto é caro, lento e estoura o limite. O script faz o trabalho pesado fora do modelo e entrega só o sinal.
Script > contexto · processar fora do modelo · sinal, não ruído · não estoure a janela.
O recorte: dentre todos os turnos, isolar apenas os do agente cujo comportamento você quer destilar — separando o cérebro-alvo do resto do sistema.
Misturar agentes diferentes embaralha os padrões e dilui o perfil. Filtrar pelo alvo é o que dá foco à destilação.
Recorte por agente · isolar o alvo · não misturar cérebros · foco no perfil.
Quantificar o perfil a partir dos 429 turnos: 97% com raciocínio, 84% raciocinando antes da 1ª ação, 87% reavaliando, 23% com teste real.
Os números transformam impressão em retrato. Eles revelam o que o agente realmente prioriza — pensar muito antes de agir, reavaliar quase sempre.
429 turnos · 97% raciocínio · 84% antes da ação · 87% reavalia · 23% teste real.
O passo final: transformar o perfil numérico num guia de decisão — o decision loop destilado — e apontar a sessão de um modelo novo para esse guia.
É aqui que o cérebro "volta": o método observado vira instrução reutilizável. Você herda a disciplina do agente sem ter os pesos dele.
Perfil → guia · o decision loop · apontar o modelo novo · o cérebro recuperado.
⚙️ Disposição × garantia dura
Um guia de comportamento é só "melhor esforço" — o modelo tenta seguir, mas pode falhar. Para o que precisa ser garantido, você não pede: você trava. Este módulo separa a disposição (mole) das garantias duras — densidade de raciocínio via effortLevel, hábito determinístico via hook — e mostra onde cada regra mora.
A natureza do guia: instruções de comportamento inclinam o modelo numa direção, mas não a impõem. É disposição, não garantia.
Confiar num prompt para o que precisa ser certo sempre é apostar. Saber o limite do guia te diz quando partir para a trava dura.
Melhor esforço · disposição ≠ garantia · o prompt inclina · saiba o limite.
A alavanca certa para "pensar mais": o effortLevel (xhigh/max), que controla a densidade de raciocínio — não o antigo MAX_THINKING_TOKENS.
Pedir "pense com cuidado" no prompt é disposição; subir o effortLevel é configuração que de fato muda quanto o modelo raciocina.
effortLevel xhigh/max · densidade de raciocínio · config, não prompt · ≠ token budget.
A trava dura: um hook PostToolUse que dispara o teste automaticamente depois de cada edição — o harness executa, não o modelo "lembra".
O que precisa acontecer sempre não pode depender da disposição do modelo. O hook garante o hábito de forma determinística.
PostToolUse · o harness força · determinístico · hábito garantido.
A decisão de lugar: o CLAUDE.md carrega sempre (toda sessão), enquanto a auto-memory é relevance-gated — só entra quando o contexto a puxa.
Pôr uma regra crítica só na auto-memory é arriscar que ela não apareça quando importa. Onde a regra mora decide se ela é confiável.
CLAUDE.md carrega sempre · auto-memory relevance-gated · onde > o quê · garantir presença.
O escopo certo dos output styles: eles moldam como o agente soa e que papel encena — mas não impõem a disciplina de processo (testar, reavaliar, verificar).
Esperar disciplina agêntica de um output style é usar a ferramenta errada. Tom é tom; comportamento operacional mora em outro lugar.
Tom e papel · ≠ disciplina · ferramenta certa pro fim certo · estilo não verifica.
A síntese: o guia de disposição dá direção e bom-senso; as travas duras (hooks, effortLevel, onde a regra mora) garantem o que não pode falhar. Juntos, formam o sistema.
Só prompt é frágil; só trava é rígido e cego. A combinação é o que produz um agente ao mesmo tempo flexível e confiável.
Guia inclina + trava garante · mole + duro · flexível e confiável · o sistema completo.
🏁 Projeto final: seu system prompt versionado
A hora de juntar tudo. Você monta o seu próprio system prompt — PMV, persona, loop e segurança —, versiona com diffs, escreve o porquê e o teste de cada regra, redige o seu guia de disposição e o pareia com travas duras. O entregável é seu: um prompt + guia versionados, prontos para evoluir como os labs evoluem.
A montagem do prompt final reunindo as peças do curso: o Mínimo Viável, a persona de quatro eixos, o Loop operacional e os blocos de segurança.
É a integração de tudo que você praticou — sem repetir o erro de inchar. Cada peça entra porque o seu caso pede, não "por garantia".
PMV + persona + loop + segurança · integrar sem inchar · só o que o caso pede · prompt completo.
Tratar o prompt como artefato versionado: guardar cada versão e comparar com diff, fechando o ciclo que você aprendeu a ler no 3.1.
Versionar torna a evolução visível e reversível. Você passa a ler o seu próprio diff — e a aplicar a si o método que aplicava aos labs.
Prompt como código · guardar versões · diff próprio · evolução visível e reversível.
Aplicar a regra de ouro do 3.2 ao seu prompt: cada regra acompanhada do porquê de existir e do teste que falharia sem ela.
É o que torna o seu prompt auditável e podável no futuro: você (ou outra pessoa) sabe por que cada linha está lá e como verificar se ainda serve.
Porquê por regra · teste que falharia · prompt auditável · podável depois.
Redigir o seu guia de comportamento — o seu "Fable Mindset" — destilando o decision loop que você quer que o agente siga, no espírito do 3.5.
O guia é a disposição que orienta o agente nos casos que o prompt rígido não cobre. Escrevê-lo é capturar o seu método em texto reutilizável.
Guia de disposição · seu Fable Mindset · decision loop escrito · método reutilizável.
Aplicar o 3.6 ao seu projeto: parear o guia mole com travas duras — hooks para o hábito, effortLevel para o raciocínio, e a escolha de onde cada regra mora.
É o que tira o seu prompt do "torço para funcionar" e o leva ao "garanto o que precisa". A combinação fecha a lacuna entre intenção e execução.
Hooks + effortLevel · onde a regra mora · guia + travas · intenção vira execução.
O self-check final: uma lista de verificação que confirma que prompt, guia, testes e travas estão completos e coerentes antes de declarar "pronto".
Fecha o curso com o mesmo rigor que ele ensina: nada é "pronto" por sensação — é pronto por verificação, item por item.
Checklist de entrega · pronto por verificação · prompt + guia + testes + travas · coerência final.