📚 Inventário da Biblioteca
Mapeando prompts em produção, categorizando, priorizando por risco.
Listagem de todos os prompts rodando em produção — system prompts, Claude.md, harnesses, code.
Você não pode migrar o que não conhece. Muitos prompts antigos rodam silenciosamente.
Git grep + docs + rubber duck com stakeholders.
Taxonomia: system prompts, scaffolds/harnesses, snippets reusáveis, documentação.
Cada categoria tem risco e custo de migração diferentes.
System prompt antigo = impacto mais amplo.
Frases como "double-check", "MUST use tool X", "if in doubt" — sinal de prompt 4.6.
No 4.7 ativamente prejudicam performance.
Regex simples encontra 80% deles.
Fórmula: Impacto (users × frequência) × Dívida técnica (anti-patterns encontrados).
Evita migrar o barato antes do perigoso.
Score alto = migre esta semana.
Ficha: nome, local, última edição, owner, usuários/dia, anti-patterns detectados, ação.
Sem template, auditoria vira chaos.
Markdown simples basta.
Todo prompt em arquivo versionado, com commits descritivos e diffs revisáveis.
Permite rollback instantâneo se migração quebrar.
Um prompt por arquivo facilita diff.
Produção atinge usuários reais. Staging atinge equipe. Local atinge só você.
Urgência escala com blast radius.
Não toque no local antes de produção limpa.
🚮 Os 6 Scaffolds para Aposentar
Seis padrões do 4.6 que no 4.7 atrapalham — e como substituir cada um.
Frase que forçava 4.6 a revisar — no 4.7 gera loops redundantes e over-thinking.
4.7 já verifica naturalmente em xhigh.
Remova e confie no effort.
Scaffold de progress-check periódico — 4.7 gerencia contexto melhor sozinho.
Causa interrupções desnecessárias e drip-feed.
Deixe o 4.7 decidir quando resumir.
CAPS LOCK + imperativo para forçar tool use — gera over-trigger no 4.7.
4.7 segue instruções literalmente; CRITICAL amplifica demais.
Substitua por "Use tool X when [condição específica]".
Regra de fallback que no 4.7 dispara mesmo quando não há dúvida real.
4.7 tem "dúvida" calibrada — fallback externo atrapalha.
Especifique condições concretas, não emoção.
Truque antigo de colocar texto na resposta do assistente para guiar saída.
Quebra extended thinking e structured output moderno.
Use structured output ou tools.
Campo que fixava budget de thinking — substituído por adaptive + effort.
Código legado precisa migrar para thinking: {type: "adaptive"}.
Remover campo + configurar effort no cliente.
Lista de 10 itens de grep/revisão manual para rodar em toda a biblioteca.
Transforma auditoria em processo repetível.
Cole no seu runbook.
🏗️ Anti-overengineering + Anti-hardcoding
Os dois snippets canônicos que controlam a tendência de over-engineer e "teaching to the test".
Treinamento privilegia "solução robusta" — então adiciona validação, error handling, abstrações sem necessidade.
Sem contrapeso, PRs ficam inchados e difíceis de revisar.
O snippet canônico resolve.
Bloco de instrução: "Avoid over-engineering" cobrindo Scope, Documentation, Defensive coding, Abstractions.
É o antídoto padrão recomendado pela Anthropic.
Cola em Claude.md ou system prompt.
Viés de satisfazer os testes literais — hardcoded returns só para passar nos asserts visíveis.
Testes passam, produção quebra.
Sinais: returns mágicos, casos específicos, lógica ad-hoc.
Bloco "Please write a high-quality, general-purpose solution..." — impede gaming dos testes.
Sem esse snippet, o 4.7 às vezes faz cheat silencioso.
Obrigatório em todo harness agêntico com testes.
Princípio: se framework/tipagem já garante invariante, não revalide no middle of the code.
Corta 30–50% do código defensivo redundante.
Validação só em boundaries (input público).
Declarar explicitamente o que NÃO deve ser feito, não só o que deve.
Sem explicit no-scope, 4.7 "ajuda demais".
"Don't refactor adjacent files" é ouro.
Bug fix de 3 linhas que o 4.7 tentou "melhorar" reformatando 200 linhas adjacentes.
Ilustra a necessidade do escopo explícito.
Frase de bloqueio: "Do not change unrelated code".
🔎 Anti-alucinação + Code Review
Investigate before answering, coverage não conservadorismo, e harness de review pronto.
Bloco <investigate_before_answering> que força Claude a ler antes de afirmar.
Reduz alucinações sobre código que ele nunca leu.
Padrão para system prompts de code review.
Instrução explícita: se não leu o arquivo, leia antes de opinar; não palpite.
Palpite vira alucinação confiante.
Anti-speculation é anti-hallucination.
"Be conservative" suprime findings legítimos; coverage pede para achar todos e depois filtrar.
4.7 acha +11pp mais bugs reais quando rodado em coverage mode.
Separar geração de ranking.
Prompt canônico "Report every issue you find..." + campos confidence (0–1) e severity (low/med/high).
Permite pipeline downstream que filtra sem perder sinal.
Incluir exemplos no prompt aumenta recall.
Arquitetura: 1ª chamada gera, 2ª chamada rankeia/filtra. Evita auto-censura.
Mesmo modelo, dois papéis = melhor sinal/ruído.
Pode usar modelo menor no filter.
4.7 em coverage mode acha 11pp mais bugs reais que 4.6 em mesma suite.
Justificativa empírica para migrar code review para 4.7.
Ganho vem do framing, não só do modelo.
System prompt + user template + JSON schema de resposta para code review em PR.
Acelera adoção — só adapte bordas do seu repo.
Cole e use amanhã.
🏜️ O Default Terracota
Por que o 4.7 gera creme + âmbar + Fraunces por padrão, e por que "não use" não resolve.
Paleta: cream #F4F1EA, tipografia serifada editorial (Fraunces/Playfair), acento âmbar.
É o estilo que 4.7 gera por default quando pedir "landing moderna".
Herdado do training — não é bug, é viés estatístico.
Sites de livros, revistas, hotéis boutique, cafés artesanais, wellness.
Reconhecer quando pode deixar o default rodar.
Estética terracota é legítima nestes domínios.
SaaS B2B, fintech, healthcare, cybersecurity, dashboards, enterprise.
Terracota comunica "cozy" — errado para confiança técnica.
Aqui você PRECISA quebrar o default.
Modelo processa conceitos, não negações. "Não use creme" ativa "creme" no contexto.
Explica por que tentativas intuitivas falham.
Prompt engineering aqui é contra-intuitivo.
Testes reais: ao proibir cream, 4.7 usa #F0EDE5, #F5F2EC — aproxima o proibido.
Precisa positivamente afirmar outra estética.
"Use silver-gray #8C9A9E + blue #11171B" funciona.
5 domínios (SaaS, fintech, healthcare, dashboard, ecommerce) em default × paleta apropriada.
Treina o olho.
Default é bonito mas errado.
Checklist visual de 3 itens: paleta terrosa? Serifada editorial? Acento âmbar?
3 sim = é default.
Aplique a screenshots que você e colegas compartilham.
🎨 Quebrando o Default
3 abordagens (paleta concreta, 4 direções, anti-slop) — e como aplicar.
Fornecer hex codes explícitos: #E9ECEC, #C9D2D4, #8C9A9E, #44545B, #11171B.
Hex elimina ambiguidade e força a paleta fria.
5 tons do claro ao escuro = base completa.
Prompt: "Before building, propose 4 distinct visual directions...". Força exploração.
Quebra o modo "pular para execução".
Escolhe 1 das 4 depois.
Bloco <frontend_aesthetics> que proíbe defaults e exige escolhas concretas.
Cola em Claude.md do projeto de frontend.
Abordagem mais robusta das três.
Construindo paletas frias: silver base + blue accent + near-black para texto.
Comunica precisão, confiança, tech.
Evite saturação alta em fintech.
Alternativas: IBM Plex, Söhne, Neue Haas Grotesk, JetBrains Mono para code-heavy.
Inter virou cliché.
Especifique no prompt, senão 4.7 volta para Inter.
Hover states, transições entre states, easing curves customizadas.
Diferencia produto de landing genérica.
Especifique cubic-bezier, duração, delay.
Dashboard fintech construído com paleta fria + IBM Plex + micro-interações.
Ver as 3 abordagens aplicadas juntas.
Resultado transmite confiança técnica.
🎓 Projeto Final Integrador
Entregue uma feature/refactor real usando tudo — briefing ICCA, scaffold agêntico, subagente, rewind, compact, code review, rubrica 100 pontos.
Uma feature ou refactor que levaria 4–8h para você humanamente — seu benchmark.
Pequeno demais não exercita, grande demais vira projeto eterno.
Se for maior, divida em subprojetos.
Intent, Context, Constraints, Artifacts — todos preenchidos.
Briefing fraco = execução fraca.
Revisite T2 se necessário.
3 arquivos mínimos para rodar auto mode: init, testes, specificação.
Sem eles, auto mode é caos.
tests.json define success criteria objetivo.
Execução em xhigh + Shift+Tab (auto mode) + hook de notificação sonora ao terminar.
Libera você para outras tarefas.
Claude cria seus próprios hooks ("play a sound when done").
Exige exercício real das 3 ferramentas avançadas da T3.
Consolida na prática.
Documente cada uma no relatório.
Aplicar o harness do 4.4 no PR do projeto.
Valida o próprio trabalho antes de aprovar.
Anote findings no relatório.
Relatório final + tabela de 10 critérios (cada 5–15 pts) totalizando 100.
Auto-avaliação estruturada.
≥80 pts = certificação aprovada.