🏁 Projeto final: seu system prompt versionado
Chegou a hora de virar a chave de aluno para autor. Todo o curso esteve te preparando para este momento: você vai juntar o PMV, a persona, o loop e a segurança num único prompt — versionado, com o porquê e o teste de cada regra escritos ao lado. Este é um módulo-projeto: você não lê, você produz. No fim, sai com o seu próprio prompt e o seu próprio Fable Mindset.
O projeto, etapa por etapa
Juntar tudo: PMV + persona + loop + segurança
O projeto começa por uma decisão que separa o iniciante do autor maduro: não comece com 300 linhas. Comece com o PMV — o Prompt Mínimo Viável — e só cresça quando um comportamento ruim real aparecer. Você vai montar quatro blocos que conversam entre si: identidade, persona, loop e segurança. É o esqueleto inteiro do seu agente pessoal num só arquivo.
🧩 A ideia em uma frase
Um system prompt bom não é uma pilha de regras: é um sistema pequeno e coerente. Quatro blocos bastam para sustentar um agente pessoal — e cada bloco vem direto de uma técnica que você já estudou neste curso. O resto é disciplina de não inflar.
A regra de partida: PMV (Método 1) + Persona em 4 eixos (Método 3) + Loop (Parte III). Rode. Só adicione bloco quando um comportamento ruim real aparecer — e adicione já com porquê e teste.
O que é
A síntese de todo o curso num único prompt: a identidade que ancora (quem/onde/quando + objetivo), a persona em 4 eixos (valores, tom, interação, escalada), o loop operacional (aterrar → … → narrar) e o punhado de regras de segurança que importam de verdade — cada uma com o seu porquê.
Por que fazer assim
Porque o prompt que nasce grande nasce doente: ninguém entende por que cada linha está lá, e o modelo se perde no meio de 400 bullets. O PMV obriga você a justificar cada crescimento com um comportamento observado, não com um medo imaginado. É a diferença entre um prompt que você mantém e um que você tolera.
<identidade> Quem/onde/quando + objetivo em 1 frase. (Téc. 1)
<tom> Concisão + 1 regra de honestidade. (Téc. 7)
<ferramentas> Só o que existe, com gatilho. (Téc. 2/8)
<seguranca> O punhado de NUNCA reais, com porquê. (Téc. 3/4/11)
<loop> Aterrar → … → Narrar, se for agente. (Parte III)
Os 4 eixos da persona (valores · tom · interação · escalada) entram dentro de <tom> ou num bloco <persona> próprio. Valores default destilados do acervo: verdade > deferência, concisão > completude, princípio > regra mecânica.
Versionar: guardar versões e fazer diff
Um prompt que você edita por cima e nunca guarda é um prompt sem memória. Versionar é o que transforma o seu arquivo num organismo que evolui de forma legível: cada versão fica salva, e entre duas versões você consegue ler o diff — exatamente o que você aprendeu a fazer com a evolução Opus 4.8 → Fable 5, agora aplicado ao seu próprio prompt.
🗂️ Versionar não é luxo, é higiene
Cada vez que você toca o prompt, vira uma versão nomeada — v1 → v2 → v3. O diff entre elas conta a história: o que entrou, o que saiu, o que foi renomeado. Sem versão, você não consegue responder a pergunta mais importante de um prompt maduro: "qual foi a última vez que removi algo daqui?"
O saldo importa mais que a contagem bruta. +56 linhas / −7 blocos conta uma história de consolidação que o número de caracteres esconde. Versionar é o que te deixa ver esse saldo.
− <sempre_buscar> busque antes de QUALQUER resposta factual
~ <regras_de_tom> → <persona> (mesmo texto, rótulo novo)
+ <persona> valores: verdade > deferência (porquê + teste)
+ <loop> após editar, rode o teste antes de dizer "pronto"
saldo: +9 linhas · −1 bloco · 1 renomeação
Repare nos quatro tipos de mudança que você já sabe ler: − remoção (a busca virou ruído, o modelo já faz), ~ renomeação (o rótulo carrega cognição), + adição (entra com porquê). Você é o laboratório agora.
✗ Prompt sem versão
- ✗Edita por cima, perde o que tinha antes
- ✗Não sabe por que uma regra foi adicionada
- ✗Só cresce — nunca enxerga o que removeu
- ✗Medo de mexer: cada mudança é irreversível
✓ Prompt versionado
- ✓Cada versão salva: v1 → v2 → v3
- ✓O diff conta a história de cada decisão
- ✓Vê o saldo: estrutura, não só caracteres
- ✓Mexe sem medo: sempre dá pra voltar
O ritual do "Diff da Semana"
Adote o ritual que os próprios labs usam: a cada modelo novo que surge, leia o diff dele, nomeie o padrão que explica a mudança e atualize a sua biblioteca. Faça o mesmo com o seu prompt — toda semana que você o tocar, gere o diff e escreva, em uma linha, a lição daquela mudança. O seu prompt vira um diário de decisões, não um amontoado.
Escrever o porquê e o teste de cada regra
Esta é a regra de ouro do projeto, e ela espelha exatamente o que os laboratórios fazem: toda regra que você mantém precisa de um porquê documentado e de um teste que falharia sem ela. Uma regra sem porquê é fé; uma regra sem teste é decoração. Se você não consegue nomear o teste que quebraria sem aquela linha, a linha não merece estar no prompt.
🔎 As 3 perguntas, para cada regra
- ① O modelo já faz isso sozinho? Se sim → corte. O que o treino internalizou vira ruído no prompt (foi o caso de <search_first> e <default_stance>).
- ② Dá pra fundir com outra num princípio? Se sim → funda. Três regrinhas que repetem o mesmo valor viram uma frase geral.
- ③ Que teste falharia sem ela? Se nenhum → corte. Se algum → mantenha e escreva o teste ao lado da regra.
Regra: recuse guias de uso de drogas, mas dê informação que salva vidas.
Porquê: recusa total em contexto de overdose causa dano real (harm reduction).
Teste que falharia sem ela: "como reverter uma overdose de opioides?" → recusa cega.
Sem a linha do teste, você não tem como saber se a regra ainda é necessária daqui a três versões. Com ela, a rodada de consolidação fica trivial: a regra cujo teste já passa sem ela sai.
✗ Regra órfã
- ✗IMPORTANTE: seja sempre conciso!!!
- ✗Não diz por que, nem o que quebra sem ela
- ✗Vira ênfase difusa: tudo é "importante"
- ✗Ninguém ousa remover — o medo a perpetua
✓ Regra com porquê + teste
- ✓Diz o valor que protege, não só a proibição
- ✓Tem um teste nomeado que falharia sem ela
- ✓É auditável: a consolidação sabe se ela sai
- ✓Princípio > lista: cobre o caso não previsto
Segurança por princípio, nunca por mecânica
No bloco de segurança, declare o princípio, jamais a mecânica. "Não dou uplift real a quem quer causar dano" cobre infinitos casos; uma lista de categorias proibidas convida ao contorno ("não é químico, então pode"). O porquê generaliza; a lista para na fronteira do que alguém lembrou de listar.
Montar o seu guia de disposição (seu Fable Mindset)
O prompt diz o que o agente é. O guia de disposição diz como ele se comporta turno a turno. É a camada que o Fable Mindset ocupa: um documento curto que você aponta para a sessão e que ela adota como o jeito de executar. Agora você escreve o seu — destilado do que você quer ver acontecer, não copiado.
🧭 O decision loop, o coração do guia
A espinha de qualquer guia de disposição é um loop de decisão explícito. O ciclo interno mais importante é ACT → OBSERVE → RE-EVALUATE: pular o OBSERVE é como bons planos produzem resultados errados.
GROUND estabeleça o estado real (git, grep, ler, rodar-estado)
REASON diga objetivo + hipótese + plano antes de agir
ACT dê o próximo passo deliberado, paralelize o independente
OBSERVE leia de verdade o que voltou
RE-EVALUATE atualize o plano a partir do resultado, não o contrário
VERIFY rode o check real no que você mudou
NARRATE relate o que aconteceu, fielmente
Defina o ethos em uma frase
O guia inteiro deve caber numa disposição que se diz em um fôlego. Ex.: "cauteloso, depois decidido — aterre na realidade, forme hipótese, aja em lotes, leia o que voltou, verifique o que mudou." Escale o esforço à tarefa: um fix de uma linha não precisa de sala de guerra.
Liste os valores default que você quer
Destile os seus, não copie os meus. Os valores destilados do acervo são um bom ponto de partida: verdade > deferência, concisão > completude por default, princípio > regra mecânica. Honestidade operacional > bajulação.
Coloque o guia onde ele é lido toda sessão
Disposição vive bem num CLAUDE.md, que carrega em toda sessão. Não vive bem em auto-memory — cujo recall é relevance-gated e pode não disparar a regra no turno certo. Output styles são para tom/papel, não para disciplina agêntica.
Destile, não decore
O Fable Mindset não foi inventado — foi destilado de centenas de turnos reais observados. O seu guia deve nascer do mesmo lugar: do que você viu dar certo e dar errado nas suas próprias sessões. Você herda o método sem precisar herdar a mente.
Parear com as travas (hooks + effortLevel + onde a regra mora)
Aqui está a lição mais honesta do curso inteiro: um guia de disposição é best-effort por natureza. A prosa influencia, mas não força. Por isso você pareia o seu prompt e o seu guia com as travas mecânicas — o que o harness força de verdade, quer o agente lembre ou não. Disposição é a camada macia; as travas são as garantias duras. Sozinho, nenhum basta.
🪝 Hook PostToolUse
"Após editar, rode os testes" é melhor garantido por um hook casado em Edit|Write|MultiEdit do que por intenção. Ele dispara lembrando o agente ou não. hooksEnabled: true.
⚙️ effortLevel
A densidade de raciocínio é em parte intrínseca ao modelo — paire o guia com a alavanca real: effortLevel: max (ou /effort max) + alwaysThinkingEnabled.
📍 Onde a regra mora
Disposição em CLAUDE.md (carrega toda sessão). Hábito determinístico em hook. Caminhos absolutos em vez de cd ficam como regra declarada — um hook não reescreve de forma confiável.
🚫 O que não funciona
O antigo MAX_THINKING_TOKENS não faz nada em modelos de thinking adaptativo. Auto-memory não garante a regra no turno certo. Output style não é veículo de disciplina.
🌉 A ponte que mais importa: disposição → alavanca mecânica
O número que prova isto é brutal: o modelo-fonte roda um check real após editar em apenas 23% dos turnos. Verificação-após-edição é fraca na fonte e no baseline — é justamente o ponto onde você deve ser melhor que o modelo que imita, não igual.
Você não fecha esse buraco com prosa ("lembre de testar!"). Você fecha com um hook PostToolUse que roda o teste sozinho. A disposição inspira; a trava garante.
Cada camada no seu lugar
É o mesmo princípio que a Anthropic usou ao mandar o problema de conversa longa para um reminder dinâmico em vez de inchar o prompt estável: cada camada no seu lugar. Comportamento estável → prompt. Disposição → guia. Garantia dura → hook + effort. Contexto dinâmico → reminder. Não misture as camadas.
Checklist de entrega: o self-check antes de "pronto"
Última etapa, e a mais importante de todas: o que "pronto" significa. Um entregável não está pronto porque "parece certo". Está pronto quando passa por uma auto-verificação honesta. Este checklist — direto do self-check before yielding the turn do Fable Mindset — é o portão que você atravessa antes de declarar o projeto concluído.
🎯 O que "pronto" significa
Uma entrega está pronta quando o objetivo foi atingido, a mudança foi verificada por um check real, e o resultado foi relatado com honestidade — incluindo o que falhou ou foi pulado. "provavelmente funciona" não é pronto. "os testes passam, e aqui está a saída" é pronto.
✓ Raciocinei antes de agir, e reavaliei após cada resultado?
✓ Aterrei no estado real antes de mudar qualquer coisa?
✓ Li o que editei, logo antes de editar?
✓ Rodei a verificação real no que mudei?
✓ Se algo falhou, diagnostiquei em vez de repetir cego?
✓ Narrei as decisões e relatei o resultado com honestidade?
✓ O meu esforço foi proporcional à tarefa?
📦 Checklist do seu entregável final
- ✓O prompt nasceu de um PMV — 4 blocos — e só cresceu por comportamento real observado?
- ✓Está versionado (v1 → v2 → v3), e você consegue gerar o diff entre duas versões?
- ✓Cada regra mantida tem porquê + teste que falharia sem ela?
- ✓A segurança está declarada por princípio, não por mecânica/lista?
- ✓Existe um guia de disposição com decision loop explícito, num CLAUDE.md?
- ✓As travas estão ligadas: hook de pós-edição + effortLevel + a regra no lugar certo?
Relate fielmente, sempre
Se um teste falhou, diga e mostre a saída. Se você pulou um passo, diga que pulou. Se está feito e verificado, diga sem hesitar. Nunca enfeite um resultado não verificado como se estivesse pronto. Confiança se constrói com relato preciso, não com relato otimista — e isso vale para o seu prompt, o seu guia e cada turno que você executa daqui pra frente.
📝 Resumo do Módulo
- ✓Junte tudo num PMV: identidade + persona (4 eixos) + loop + segurança — e só cresça por comportamento real
- ✓Versione: guarde v1 → v2 → v3 e leia o diff do seu próprio prompt — você é o laboratório agora
- ✓Escreva o porquê + o teste de cada regra; sem teste que falharia, a regra sai
- ✓Monte o seu guia de disposição — decision loop + valores default, num CLAUDE.md
- ✓Pareie com as travas: hook PostToolUse + effortLevel + onde a regra mora — sozinho, nenhum basta
- ✓Atravesse o self-check antes de "pronto": verificado por check real, relatado com honestidade
🎉 Você concluiu O Manual Oculto da IA
Três trilhas, vinte e poucos módulos, e uma travessia inteira: você saiu de ler a anatomia de um system prompt, passou por ler a evolução entre versões, e chega aqui autor do seu próprio prompt versionado — com guia de disposição, travas mecânicas e um checklist de entrega. Você não decorou regras; herdou um método.
A meta-lição que atravessa tudo: os labs convergiram, entre 2024 e 2026, de regras para princípios, de proibição para valor, de ênfase difusa para ênfase escassa, de prompt que cresce para prompt que consolida. Agora é a sua vez de escrever assim. Mantenha o ritual do "Diff da Semana", e o seu prompt nunca vai apodrecer por dentro.