Lição 11 de 13: Quando NÃO escrever uma skill

O anchor do M3: reconhecer otimização prematura

Você acabou de construir uma fatia ponta a ponta: tabela, validação, API, UI, evento, retrospectiva. Olha pro .claude/skills/ do seu projeto. Nenhuma skill nova foi criada. Foi proposital.

A regra é simples: a maioria das skills custom que builders criam são prematuras. E skill prematura vira entulho no .claude/, que polui o contexto e atrapalha o Claude nas próximas sessões. O foco desta lição é saber quando segurar a criação de uma skill.

Vocabulário rápido:

• Skill = arquivo .claude/skills/[nome]/SKILL.md (M1/L07). Capacidade que vive em disco — Claude carrega quando o trigger dispara.
• Trigger = a parte da skill que diz "quando isso é relevante." Skill sem trigger bom é skill que nunca dispara ou dispara errado.

Por que você fez a fatia 1 sem criar skill nova

A fatia 1 tinha 4-5 padrões que poderiam virar skill, e você não criou nenhum.

Candidato 1: "Crie schema + migration." Parece útil. Mas:

• Você fez isso 1 vez na fatia 1. Talvez faça mais 2 ou 3 vezes na fatia 2.
• O Claude já faz isso bem com prompt simples (você viu na L02). Skill custom não melhora muito.
• Toda decisão importante (tipos brasileiros, monetário em centavos, naming convention) é específica do produto — skill canônica não consegue antecipar.

Candidato 2: "Validação CPF/CNPJ." Também parece útil. Mas:

• Você já escreveu a função na L03 e ela vive em lib/validators/. Já é capacidade reutilizável, só não é skill.
• Pra outras pessoas usarem, é importar a função, não invocar skill.
• A regra que importa (validação na borda com Zod) já está documentada. Ou viraria uma regra nova, não skill.

Candidato 3: "Comente os 4 estados de form." Parece interessante. Mas:

• Você fez isso 1 vez na L05. Uma vez é instância, não padrão.
• Se a fatia 2 tiver outro formulário e você fizer parecido, são 2. Ainda é coincidência, não skill.
• Você precisa de 3 instâncias diferentes do mesmo padrão antes de virar skill. Caso contrário, está se antecipando.

A regra da 3ª repetição

A regra pra decidir se algo vira skill é simples: espera até a 3ª vez que você fizer a mesma coisa.

• 1ª vez: você está descobrindo o padrão. Foco em fazer bem, não em generalizar.
• 2ª vez: você refina o padrão. Pode copiar do 1º, mas ajusta. Ainda não tem certeza se vai precisar de novo.
• 3ª vez: você já está repetindo. Aí a pergunta vale: "vale extrair pra skill?"

A maioria dos padrões nunca chega na 3ª vez. Você descobre, no caminho, que (a) o padrão não era tão geral, ou (b) cada instância tem variação suficiente pra que skill canônica atrapalhe mais que ajude.

Passo 1 — Liste os candidatos a skill da fatia 1

Cole no Claude:

Olha o git log da fatia 1 e identifica 3-5 padrões que se repetiram (ou que parecem candidatos a se repetir na fatia 2). Pra cada um, descreve:

1. Nome do padrão (ex: "crie schema com colunas brasileiras", "valide payload com Zod + .refine", "form com 4 estados nomeados")
2. Quantas vezes apareceu na fatia 1 (1, 2, ou 3+)
3. Se viraria skill ÚTIL ou skill com 80% de configuração

Não cria nenhuma skill. Apenas lista os candidatos.

Lê a resposta com olho crítico — provavelmente vai ter 4-5 candidatos, e 3-4 deles com "aparecimento = 1 vez."

Passo 2 — Salve em docs/maybe-skills.md

Cria o arquivo docs/maybe-skills.md no repo com este shape:

# Candidatos a skill (não criar agora)

Lista de padrões observados durante construção da fatia 1. Espera-se que cada um chegue à 3ª repetição antes de virar skill formal. Revisar ao final do Módulo 5.

## [Nome do padrão 1]
- Aparições até agora: 1
- Tipo: padrão técnico (ou: regra, ou: workflow)
- Próxima oportunidade de teste: fatia 2, durante [contexto].

(Repete pra 3-5 padrões.)

---

Quando algum desses chegar a 3 aparições, considerar:
- Vira skill se: trigger é claro, lógica > configuração, serve mais que 1 pessoa.
- Vira regra se: é constraint sempre-ligado, não procedimento condicional.
- Vira receita pessoal se: só pra mim, modelos próprios — vira parte do Personal Pack (o plugin que você empacota no M5).

Mostre o diff antes de criar.

Passo 3 — Faça o commit

Faça commit do docs/maybe-skills.md com mensagem: docs: capture skill candidates from slice 1

Build Diary — o que o autor do CEAP NÃO publicou

O NOTAS_DO_AUTOR.md do CEAP tem uma seção "Descobertas Que Não Publiquei." Trecho real:

Os 6 Deputados com HHI Extremo. Tabela com 6 deputados, HHI > 3300, fornecedor único > 55% do total.

Por que não fiz case studies? Nenhum estava em investigação pública. Acusar com base apenas em estatística seria irresponsável. HHI alto pode significar: (1) fraude, (2) contrato legítimo de longo prazo, (3) fornecedor especializado sem concorrência local.

E mais duas descobertas registradas com a mesma forma: o que achei / por que não publiquei / o que precisaria pra publicar.

A regra implícita dessa seção é a mesma desta lição: nem toda observação vira artefato. Cada descoberta poderia virar post, matéria, ou case study no produto. O autor resistiu: registrou a descoberta no arquivo de notas, esperando contexto pra publicar (ou não publicar nunca).

No seu caso é o mesmo: nem todo padrão vira skill. Anota em docs/maybe-skills.md, espera o contexto, decide depois. Skill prematura é como matéria publicada com sinal insuficiente: fácil de fazer, difícil de retirar.

Takeaways

• A regra da 3ª repetição: espera até fazer a mesma coisa 3 vezes antes de transformá-la em skill. Antes disso você não tem evidência de que o padrão se repete.
• Skills custom prematuras viram entulho no .claude/: poluem o contexto, atrapalham o Claude nas próximas sessões.
• 3 sinais de "não vira skill mesmo com 3 repetições": 80% configuração, depende de stack específica, ou só serve pra você (vira Personal Pack, não canônica).
• Capacidade reutilizável ≠ skill. Função em lib/ é reutilizável e não precisa virar skill.

Você terminou quando

Três coisas:

1. Você consegue articular por que não criou skill na fatia 1 (não foi descuido, foi decisão)
2. docs/maybe-skills.md commitado com 3-5 candidatos
3. Modelo mental claro: regra da 3ª repetição + 3 sinais de não-skill