1
🔀 Fork ou herança?
90% dos casos: fork (copiar e adaptar). Herança (referenciar a skill original e sobrescrever) é possível mas complica.
✓ Fork
- Copiar
fs-seis-chapeus/→fs-code-review/ - Adaptar SKILL.md e references/
- Independente, fácil de manter
- Sem risco de quebra cruzada
✗ Herança
- Referencia skill mãe no description
- Requer orquestração explícita
- Mudança na mãe pode quebrar filha
- Use só se tem 10+ variantes
2
✏️ Ajustando o description
O description da variante tem que ser único — senão as duas skills ativam juntas. Gatilhos específicos do seu domínio.
Exemplo: description para "fs-code-review"
---
name: fs-code-review
description: Code review estruturado pelos Seis Chapéus adaptado
para análise de pull requests. Use SEMPRE que o usuário pedir
'code review', 'revisa esse PR', 'análise de código',
ou quando enviar um diff, PR, ou arquivo .py/.js/.ts/.go/.rs
pedindo avaliação...
---3
🔧 Adaptando regras ao domínio — code review
Cada chapéu vira mais específico. Exemplos concretos do domínio.
⚪ Branco (adaptado): Linhas alteradas, testes adicionados/removidos, coverage, dependências novas. Sem opinião.
🟡 Amarelo (adaptado): Código que resolve bem o problema, testes bons, refactor útil. Com "por que é bom".
⚫ Preto (adaptado): Bugs, problemas de segurança, performance, edge cases. Enunciados concretos.
🟢 Verde (adaptado): Refactorings alternativos, padrões, extract method/class, simplificações.
🔴 Vermelho (adaptado): "Cheira a mal-design", "esse teste me preocupa". Reações viscerais sem justificativa.
4
🧬 Criando novos marcos divergentes
Seu domínio pode ter marcos próprios que valem mais que os genéricos.
Marcos novos para code review
K — Padrões de design: "Isso é um Strategy? Factory? Observer?"
L — Complexidade ciclomática: "Quantos if/for aninhados? Vale decompor?"
M — Acoplamento: "Quem essa classe conhece? É excessivo?"
N — Testabilidade: "Como se testa isso? Tem dependências hard?"
5
🧪 Validação com casos reais
Rode sua variante em 10 casos reais do seu trabalho. Anote o que funciona, o que quebra, o que falta. Itere.
💡 Loop de validação
- 1. Rodar skill em 10 casos reais.
- 2. Anotar: gatilhou quando devia? Formato correto? Saída útil?
- 3. Revisar SKILL.md baseado nas falhas.
- 4. Rodar 10 casos novos. Comparar.
- 5. Parar quando 9/10 são úteis.
6
✅ Checklist final antes de publicar
Os 10 items
Name em kebab-case, com prefixo.
Description testado com 10 mensagens (5 ativam, 5 não).
Exclusões explícitas listadas.
Regras imperativas (PROIBIDO, SEMPRE, sem exceção).
Formato de saída com template visual.
Checklist final com "reescrever se falha".
references/ organizada (variants, frameworks, anti-patterns, examples).
Testes de contaminação executados.
Validação em 10 casos reais com 9+ sucessos.
Versionamento — commit com mensagem descritiva.
🎓 Parabéns — curso concluído!
Você agora entende o método, sabe usar a skill, e sabe construir sua própria variante. As 3 trilhas cobertas.
✓
Trilha 1 - Método + Anti-Âncora + Regras + Síntese.
✓
Trilha 2 - Invocação, variantes, marcos, anti-padrões, casos.
✓
Trilha 3 - Anatomia, description, regras, modularização, isolamento, workshop.
Próximo passo sugerido:
Criar sua primeira variante da fs-seis-chapeus. "fs-seis-chapeus-pessoal", "fs-code-review-hats", "fs-hiring-decision" — escolha algo que você usa toda semana.