🧭 Regra é comportamento recorrente
Até aqui você coletou o acervo (trilha 2) e compilou a wiki (trilha 3). Agora vem a fase 3 do método: tirar dessa wiki as regras de conduta do especialista. A definição que o kit usa está na própria skill de regras: "Regra = o que a pessoa FAZ de forma recorrente ao ensinar/construir, não uma frase de efeito."
🆕 Novo aqui?
- Raw é a pasta
raw/com o acervo cru (legendas, transcrições, guias), que nunca é editado. - Wiki é a pasta
wiki/com o acervo compilado em páginas curtas e ligadas entre si: fontes, temas, princípios e métodos. - Regra é um bloco no arquivo
regras.md: um título, uma frase de ação (o enunciado), trechos copiados do raw que provam a regra (as citações) e onde ela aparece na resposta do mentor. - Frase de efeito é o que soa bem num slide mas não diz o que fazer na próxima tarefa ("qualidade em primeiro lugar").
Como ler: à esquerda, a frase não tem quando, nem o quê, nem prova — o mentor não teria como segui-la. À direita, a R1 do piloto tem as três peças em ciano: um momento que dispara a regra, uma ação que dá para ver e trechos do acervo que mostram a pessoa fazendo isso. Se faltar uma das três, ainda não é regra.
✗ Não é regra
- ✗Opinião sobre o mercado ("IA vai mudar tudo")
- ✗Gosto pessoal que não muda a forma de trabalhar
- ✗Algo dito uma vez, numa live, sem repetir em lugar nenhum
- ✗Bordão de abertura ou de encerramento
✓ É regra
- ✓Um gesto de trabalho que se repete em fontes diferentes
- ✓Começa com verbo: conferir, medir, definir, cortar, recusar
- ✓Muda o que o mentor escreve na resposta
- ✓Tem trecho literal no raw para provar
🔎 Onde procurar: princípios e métodos da wiki
Você não procura regra no raw inteiro: 189 mil palavras é muito para ler de novo. Procura na wiki, que já fez esse
trabalho. A skill manda ler duas pastas: wiki/principios/ (o que a pessoa acredita e repete) e
wiki/metodos/ (como ela executa, passo a passo). Regra boa costuma ser o ponto onde um
princípio vira gesto dentro de vários métodos.
Como ler: o funil estreita da esquerda para a direita. O raw tem tudo; a wiki em ciano já separou princípios e métodos; as regras são o que sobra depois de fundir e cortar. Na fase 3 do piloto saíram 8 regras; quando um guia novo foi ingerido, viraram 10 (a R9 e a R10 nasceram aí — você vê isso na trilha 6).
Leia os princípios procurando verbos
No piloto, wiki/principios/ tem 12 páginas hoje (verificar antes de afirmar, critério de pronto explícito, medir antes de acreditar, menor custo que resolve, falhar cedo…). Cada página tem um enunciado e uma lista de trechos com a fonte de cada um.
Cruze com os métodos
wiki/metodos/ tem 21 páginas (loop com critério de sucesso e aborto, revisão cruzada entre agentes, auditoria de ablação, trocar LLM por script…). Um princípio que aparece como passo dentro de vários métodos é candidato forte.
Conte as fontes, não as menções
Dez trechos da mesma live valem menos que dois trechos de fontes diferentes. É essa contagem que vai decidir o status da regra no módulo 4.2.
Trecho real: wiki/principios/verificar-antes-de-afirmar.md
## Enunciado O OK da ferramenta ou do agente não prova nada. Nada é dado como feito sem conferir o resultado real (ls, refresh, teste final, exit code, outra IA, caso nunca visto) [...] ## Trechos - "Arquivo existir não é prova. O agente ter lido e usado é." — [[guia-agente-claude-codex-...]] - "Nada sai sem passar pelo qa_short.py" — [[guia-makeshorts-...]] - "ele passou dizendo que tinha OK, mas não" (@02:38:55) — [[video-inema-vibecode-do-zero-dia-3-...]] - "Confira você mesmo (rode o teste final, veja o hash dos testes)" — [[guia-execucao-longa-...]]
O que reparar: a página já traz trechos de guias e de lives diferentes, com o arquivo de origem. Quatro desses trechos foram parar, palavra por palavra, nas citações da R1. A wiki fez a garimpagem; a fase 3 só escolhe e prova de novo contra o raw.
✂️ Fundir e cortar: poucas e fortes
A skill dá a meta: "Mire em 5–9 regras. Menos regras e mais fortes é melhor que muitas e fracas." O mentor lê
o regras.md inteiro antes de toda resposta; cada regra a mais dilui as outras e alonga a resposta.
Por isso a fase 3 tem duas operações, nesta ordem: fundir o que é a mesma conduta com
nomes diferentes e cortar o que não muda a resposta.
Como ler: três jeitos de dizer a mesma coisa (em ciano) entram como citações de uma regra só, e cada um reforça a prova. A caixa vermelha é o que não sobrevive: se tirar a frase não muda nada no que o mentor escreve, ela não vira regra. Fundir aumenta a prova; cortar diminui o ruído.
| Situação na wiki | O que fazer | Exemplo do piloto |
|---|---|---|
| Mesma conduta com nomes diferentes | Fundir numa regra; as frases viram citações | R1 junta "verificar", "não confiar no OK" e "arquivo existir não é prova" |
| Duas condutas que sempre andam juntas | Uma regra com enunciado composto | R2: critério de pronto e de aborto |
| Conduta forte, mas só em uma fonte | Fica, com status banco, à espera da 2ª fonte | Nenhuma ficou em banco no piloto: as 10 estão ativas |
| Opinião, tema ou assunto | Fica na wiki, não vira regra | Os temas de wiki/temas/ não entram no regras.md |
| Trecho que contradiz a wiki | Descartar e explicar no relatório | O diário registra que a sessão descartou um trecho assim |
💡 Teste do corte
Para cada regra candidata, pergunte: "Se eu apagar esta regra, a próxima resposta do mentor muda em quê?" Se você não consegue apontar a seção que muda, corte. É a própria R7 do Nei aplicada às regras: "remover instrução, skill ou camada que não melhora o resultado medido".
📜 As 10 regras do Nei
Este é o regras.md real do mentor do Nei, resumido. Cada cartão traz o título da regra e uma das citações
copiadas do raw — fala de live (com a marca de tempo) ou frase de guia. Repare que todas começam com verbo e que
dá para imaginar o mentor fazendo cada uma.
Como ler: a seta é uma tarefa do começo ao fim. As regras em âmbar no início decidem se e como começar; as em ciano guiam o trabalho; as em âmbar com brilho seguram a entrega. Um mentor que segue só o meio parece prestativo, mas entrega sem prova — é por isso que as pontas pesam tanto.
R1 — Conferir o resultado real antes de dizer "pronto"
"ele passou dizendo que tinha OK, mas não" · live, 02:38:55
R2 — Definir o critério de pronto (e de aborto) antes de começar
"dou essa missão 3. Se tu não resolver," · live, 00:15:19
R3 — Medir com e sem antes de acreditar
"comparei, testei com e sem e descobri" · live, 00:05:23
R4 — Usar o menor custo que resolve
"O menor modelo que resolve bem esse passo é o escolhido" · guia
R5 — Ensinar o fundamento que não muda, não a casca
"dar camada, eu quero dar fundamento." · live, 01:55:39
R6 — Construir junto, e construir o seu
"usar sistema dos outros. Vocês têm que" · live, 01:38:35
R7 — Começar mínimo e cortar o que não paga o custo
"né? Com menos prompt, mais inteligência." · live, 01:01:56
R8 — Falhar cedo, na entrada
"ter essa visão. Nós temos que errar cedo" · live, 01:38:48
R9 — Revisar com outro agente, entregando o artefato real
"Os dois concordarem não é prova: eles podem dividir a mesma suposição errada." · guia
R10 — Ação irreversível só com pedido atual do humano
"Handoff não é permissão." · guia
🔍 Por que as citações de live parecem cortadas?
"dou essa missão 3. Se tu não resolver," não é erro de cópia: é o trecho literal da legenda, que quebra a fala em pedaços. A skill pede trechos curtos (5 a 25 palavras) e copiados, não parafraseados. Quem lê a citação inteira entende a regra pelo enunciado; a citação só prova que a fala existe. No módulo 4.2 você vê como o validador lida com essas quebras.
🧩 A linha "no mentor:" e as seções do especialista
Uma regra sem lugar na resposta fica só no papel. Por isso cada bloco termina com - no mentor:, dizendo
em qual seção da resposta a regra aparece. No piloto, a R6 diz: "seção Sua vez — a resposta
termina com um exercício que o aluno executa no próprio projeto, não com a solução pronta." A R4 pede uma seção
Custo; a R8 e a R10, uma seção Risco.
Como ler: a linha no mentor: sai do regras.md, vira item da lista de seções
exigidas, o agente escreve a seção e o validador (em ciano, de fora) confere. Se qualquer elo faltar, a regra existe no
arquivo mas não aparece na resposta — foi exatamente o furo que o piloto encontrou.
⚠️ O furo que o piloto achou (kit 1.1)
O diário da fase 3 registra: "As regras do Nei pedem seções próprias (Custo, Sua vez, Por baixo, Risco), mas o agente do template tem loop fixo (Pronto, Menor versão…) e validar_resposta exige as seções fixas." Gravidade média. A correção entrou no kit 1.2: o agente inclui as seções pedidas pelas regras e a skill de regras ganhou um passo 5 que junta esses nomes em secoes_resposta — com limite de 1 a 3 seções novas, para a resposta não virar formulário.
Na prática: o relatório do teste 1 do piloto
A resposta real do mentor ao pedido "hook Stop que bloqueia com TODO.md aberto" terminou com uma tabela em que cada passo diz qual regra o guiou (trecho):
| Passo | O que saiu | Regra |
|---|---|---|
| Definir pronto e aborto | 3 critérios, teto de 3 bloqueios | R2 |
| Menor versão (v0) | hook mínimo, zero tokens por checagem | R7, R4 |
| Versão quebrada | 6 blocks, loop sem fim | R2 |
| Prova real | 3 itens [x] numa sessão de verdade | R1 |
| Exercício | no projeto do aluno | R6 |
O que reparar: a coluna "Regra" só faz sentido porque as regras têm ID estável (R1, R2…). O validar_resposta.py confere que todo ID citado existe no regras.md — inventar uma "R11" reprova.
⌨️ Na prática: rodar /<slug>-regras
O gerador do kit criou, no seu mentor, uma skill chamada <slug>-regras (no piloto, slug é
nei, então a skill é /nei-regras). Ela lê princípios e métodos, escreve o regras.md no
formato exato e roda o validador. No piloto, a fase 3 levou 1,1 minuto, saiu com
8 regras ativas e 31 citações e o validador passou de primeira.
🆕 Novo aqui?
Skill é uma pasta .claude/skills/<nome>/ com um SKILL.md de instruções; no Claude Code você a chama digitando /<nome>. Slug é o apelido curto do mentor, sem espaço nem acento, escolhido ao gerar o projeto. Exit code é o número que um comando devolve ao terminar: 0 é sucesso, qualquer outro é falha.
🧪 Exercício copiável 1 — gerar as regras
Objetivo: extrair as regras do seu especialista a partir da wiki que você compilou na trilha 3. Abra o Claude Code dentro da pasta do seu mentor e cole:
/<slug>-regras Mire em 5 a 9 regras. Antes de escrever cada uma, me diga de quais páginas de wiki/principios/ e wiki/metodos/ ela saiu e quantas fontes DIFERENTES a sustentam. Copie os trechos do raw, não parafraseie. No fim, rode python3 tools/validar_citacoes.py e mostre a saída inteira.
Como verificar: a última linha da saída tem que ser OK, logo depois de algo como 8 regras (8 ativas), 31 citações encontradas, 0 faltando (esses são os números da fase 3 do piloto; os seus serão outros). Se aparecer REPROVADO:, a correção é copiar o trecho do raw de novo — nunca afrouxar o validador.
🔬 Exercício copiável 2 — auditar se é conduta
Objetivo: pegar regra que é frase de efeito disfarçada, antes que ela entre no mentor.
Leia regras.md. Não altere nada. Para cada regra, responda numa tabela: regra | gatilho (quando ela vale) | ação observável | seção da resposta que muda (linha "no mentor:") | nº de arquivos diferentes nas citações. Marque como SUSPEITA toda regra sem gatilho claro, sem ação que dê para ver ou que não mude nenhuma seção. Sugira fundir regras que descrevem a mesma conduta.
Como verificar: nenhuma linha deve ficar com gatilho ou ação vazios. Cada SUSPEITA vira uma decisão sua: reescrever o enunciado com verbo, fundir com outra ou apagar. Depois de mexer, rode o validador de novo.
Checagem rápida: qual candidata é uma regra de conduta, no sentido do kit?
📌 Resumo do Módulo
Próximo Módulo:
4.2 - Citação, status e validador: o formato exato, ativa/banco/inferência, a normalização e o dia em que um git checkout apagou as regras.