🔍 Como diagnosticar

Toda instrução da sua config cai em uma de dez caixas: CONTEXTO, GUARDRAIL, CRITÉRIO DE QUALIDADE, VERIFICAÇÃO, INTEGRAÇÃO/FERRAMENTA, PROCEDIMENTO REPETÍVEL, MICROGERENCIAMENTO, REDUNDÂNCIA, LEGADO/OBSOLETA e AMBÍGUA/NÃO COMPROVADA. "O deploy é via git" é CONTEXTO; "nunca force push na main" é GUARDRAIL; "pense passo a passo" é MICROGERENCIAMENTO.

Sem nome, toda linha parece igualmente importante — e você acaba defendendo tudo. A categoria é o que separa o que o modelo não tem como saber (contexto, integrações) do que ele já faz melhor sozinho (microgerenciamento). É o passo que torna a auditoria discutível com outra pessoa.

Categoria descreve o que a linha é, não o que fazer com ela. As quatro últimas (microgerenciamento, redundância, legado, ambígua) são as suspeitas naturais; as seis primeiras carregam o valor. Uma linha pode ter duas categorias — isso já é sinal de que ela precisa ser quebrada em duas.

Depois da categoria vem a decisão. KEEP = fica como está. SIMPLIFY = fica, mas em metade das palavras. MOVE = está no lugar errado (regra de um projeto na config global, ou vice-versa). MERGE = duas linhas dizem a mesma coisa. TEST = você não sabe, então prove por ablação. REMOVE = você sabe que é peso morto.

A auditoria falha quando só existem dois botões, "fica" e "sai" — aí tudo vira "fica". Seis saídas permitem o movimento honesto: a maioria das linhas não precisa sumir, precisa encolher, mudar de arquivo ou fundir com a vizinha.

Na dúvida, TEST — nunca KEEP. Uma auditoria sem nenhuma linha em TEST quase sempre significa que o autor está protegendo a própria config. TEST não apaga nada: só agenda a prova.

O que essa linha evita ou garante? O modelo atual ainda precisa dela? Ela diz o que deve acontecer ou dirige como o modelo pensa? Está duplicada em outro lugar? Limita a autonomia sem motivo? Existe forma mais curta? O que quebra se ela sumir?

Elas transformam uma opinião ("acho que isso ajuda") em um registro auditável. A mais discriminante é a terceira: instrução que diz o quê costuma sobreviver; instrução que dirige como pensar é a que envelheceu junto com o modelo antigo.

Anote sempre a pergunta que decidiu e a resposta de "o que quebra se sumir?". Se a resposta for "não sei", a decisão já está tomada: TEST. Esse par — pergunta + consequência — é o que a Trilha 4 vai usar como hipótese do teste A/B/C.

Identidade do projeto, caminhos e fontes de verdade, branding, segurança, compliance, contratos de interface, integrações e convenções internas. Nada disso está nos pesos do modelo: ele não tem como adivinhar que seu deploy é por git, que a key mora em tal `.env` ou que a conta de destino do commit muda por repositório.

Ablação vira estrago quando alguém corta por entusiasmo. Esta lista é o freio: são as linhas cuja ausência não degrada a qualidade aos poucos — quebra de uma vez, e às vezes em produção.

Teste rápido: se a informação é específica do seu mundo e não deduzível do repositório, ela é KEEP (no máximo SIMPLIFY). "Não cortar" não significa "não encurtar" — contexto verdadeiro também cabe em uma linha.

A função-objetivo da auditoria é maximizar qualidade + autonomia + verificabilidade ÷ complexidade. Contagem de linhas aparece só no denominador — e nunca sozinha.

Quem persegue só o denominador produz uma config linda e pior: corta a verificação (que era barata e valiosa) junto com o microgerenciamento. Uma auditoria pode legitimamente terminar com a config maior, se o que entrou foi um critério de saída verificável.

Adicionar verificação sobe o numerador. Tirar passo a passo desce o denominador e sobe a autonomia. São os dois movimentos de maior retorno — e é por isso que o módulo 2.2 existe.

Padrões que aparecem em quase toda config madura: regra duplicada entre `CLAUDE.md` e skills, skill grande demais, excesso de exemplos, formatação rígida sem motivo, exceções acumuladas ("exceto quando…", três vezes), contradições entre arquivos, contexto global que só serve a duas tarefas — e, o mais caro de todos, verificações ausentes.

São atalhos de leitura: em vez de reler tudo com a mesma atenção, você varre a config atrás desses cinco ou seis cheiros e chega rápido nos candidatos. Duplicação e contradição são as que mais sabotam na surdina — o modelo escolhe uma das duas versões e você nunca sabe qual.

O sinal mais caro é o que não está lá. Exceções acumuladas são fóssil de um modelo antigo; contradição é bug silencioso; verificação ausente é a instrução que faltava para todo o resto funcionar sem babá.

Dizer ao modelo cada passo do caminho em vez de dizer aonde chegar. "Abra o arquivo, procure a função, edite a linha 12, rode o build, depois…" — um roteiro que só descreve um caminho, o que você teria seguido.

É o modo de falha número um — e, curiosamente, mais frequente em quem tem anos de engenharia, porque especificar bem sempre foi virtude. Com modelos antigos o roteiro salvava; com os atuais ele bloqueia a rota melhor que o modelo acharia sozinho.

O nível certo de instrução é o que você daria a um colega competente que acabou de entrar: contexto e critério, não passo a passo. Se a sua instrução não sobreviveria a um "por quê?", ela é roteiro.

Trocar "faça A, depois B, depois C" por "Produza X. Respeite Y. O resultado deve atingir Z. Verifique usando W. Escolha a estratégia." Mesma intenção, outra forma: o que era sequência vira alvo mais restrição mais prova.

É a reescrita que costuma encolher a instrução e melhorar o resultado ao mesmo tempo — porque devolve ao modelo a escolha do caminho, mas não a escolha do padrão. Você continua no controle do que importa: o Y e o Z.

Se, ao converter, você não consegue escrever o Z ("o resultado deve atingir…"), o problema nunca foi o prompt: você ainda não definiu o que quer. E sem o W, a instrução volta a depender de você olhando cada saída.

Objetivo (o que produzir) · Contexto (o que o modelo não infere) · Guardrails (o que nunca fazer) · Critérios de qualidade (quando está bom) · Verificação (como conferir) · Autonomia (o que pode decidir sozinho e quando parar para perguntar).

Preencher os seis campos expõe o buraco na hora. Quase toda instrução ruim que você tem hoje é forte em Objetivo, obesa em passo a passo e vazia em Verificação e Autonomia — os dois campos que decidem se você vai precisar ficar por perto.

Cada campo mapeia direto na taxonomia do módulo 2.1: Contexto = CONTEXTO, Guardrails = GUARDRAIL, Critérios = CRITÉRIO DE QUALIDADE, Verificação = VERIFICAÇÃO. O que não cabe em nenhum dos seis campos é, com alta probabilidade, microgerenciamento.

Dar ao modelo um jeito real de conferir o próprio trabalho. O exemplo de Cherny: reescrever um app Electron em Swift rodando o original numa VM, tirando screenshot dos dois e comparando pixel a pixel, sem parar enquanto não batesse. Produzir → observar → comparar → parar.

Um prompt curto com verificação vence um prompt gigante sem verificação, e não é perto. Sem o passo de comparação, o modelo não tem como saber que errou — e você vira o verificador, manualmente, para sempre.

Verificação boa é executável por um terceiro: um comando, um teste, uma comparação, uma checagem de arquivo. "Revise com cuidado" não é verificação — é torcida. E toda verificação precisa de uma condição de parada explícita.

Dar ao modelo uma tarefa um pouco mais difícil do que parece confortável — e guardar uma lista dos pedidos que falharam, para rodá-la de novo a cada modelo novo.

A maior parte das instruções defensivas da sua config existe por causa de um fracasso que hoje não acontece mais. Sem reteste, você nunca descobre — e continua pagando complexidade por um problema resolvido há dois modelos.

Isto é ciência empírica, não teórica: não existe truque secreto, existe tarefa difícil → meio de verificar → observar onde trava → corrigir aquilo → repetir. A lista de fracassos antigos é o seu benchmark pessoal, e é ela que alimenta o ciclo da Trilha 4.

Escolha a instrução mais "receita de bolo" da sua config ou de uma skill sua e escreva duas versões ao lado da original: (a) 50% menor, mantendo a intenção; (b) mínima, no template de 6 campos, com um passo de verificação objetivo.

Ler sobre conversão não muda nada; fazer uma vez muda. As duas versões lado a lado revelam quanto do texto original era caminho e quanto era critério — e normalmente a resposta surpreende.

Critério de saída do exercício: a versão mínima tem uma verificação que um terceiro conseguiria executar sem te perguntar nada. Se precisa de você para explicar, ainda não é verificação. Guarde as três versões — elas viram os braços A/B/C do teste de ablação.