Objetivo: ao final, o consultor decide entre skill pessoal e de projeto, e sabe como contribuir para a biblioteca da consultoria.
| Pessoal | De projeto | |
|---|---|---|
| Caminho | ~/.claude/skills/<nome>/SKILL.md |
.claude/skills/<nome>/SKILL.md na raiz do projeto |
| Windows | C:\Users\<usuario>\.claude\skills\ |
idem, relativo à pasta do projeto |
| Quem usa | Só você, em todos os projetos | Todo mundo que tem a pasta do projeto |
| Versionada | Não | Sim, junto com o material do projeto |
| Serve para | Seu jeito de trabalhar | Padrão do time e do cliente |
| Skill | Onde | Por quê |
|---|---|---|
| Como você gosta que e-mails sejam redigidos | Pessoal | Preferência sua |
| Seu checklist de revisão de spec | Pessoal, depois de projeto | Começa como seu; quando o time adota, migra |
| Convenção de nomenclatura de objetos do cliente | De projeto | Vale para todos naquele cliente |
| Procedimento de cutover daquele projeto | De projeto | Todos precisam seguir igual |
| Template de spec da Wayon | Biblioteca da casa | Vale em todos os clientes |
| Padrão de análise de dump | Pessoal, candidata à biblioteca | Se funcionar em dois clientes, propõe |
1. Você repete um procedimento duas vezes
↓
2. Escreve como skill PESSOAL
↓
3. Usa em um projeto, ajusta o que não funcionou
↓
4. Um colega precisa do mesmo → vira skill DE PROJETO
↓
5. Funcionou em dois clientes → propõe para a BIBLIOTECA
Não pule etapas. Skill que vai direto para a biblioteca sem ter sido usada tende a estar errada de um jeito que só o uso revela.
A biblioteca da Wayon fica em repositório GitHub privado. No Nível 3 ela vira o marketplace interno de plugins (módulo 3.3), então o que você publica agora não precisa ser refeito depois.
Critério de entrada - Usada em pelo menos dois clientes diferentes - Sem nada específico de cliente no conteúdo (nome, sigla, particularidade de customizing) - Descrição testada com o teste de 3 + 3 (aula 1.5.3) - Formato de saída explícito no corpo
Fluxo 1. Você limpa a skill do que era específico de cliente 2. Publica no repositório GitHub da biblioteca 3. Geovani revisa: a descrição dispara bem? O procedimento é verificável? É genérica de verdade? 4. Publicada, com dono e data de revisão
Manutenção - Toda skill na biblioteca tem um dono - Revisão a cada seis meses, ou quando o produto muda
Regra Wayon A biblioteca fica em repositório GitHub privado. Propõem: os consultores que fizeram este curso. Revisa e aprova a publicação: Geovani (geovani@nkodeai.com), engenheiro de AI da NkodeAI. Critério de entrada: usada em dois clientes, sem nada específico de cliente, descrição testada com o teste de 3 + 3. Toda skill publicada tem dono e data de revisão — sem dono, ela envelhece e ninguém percebe. Skill da biblioteca que não serve para um cliente: copie para o seu lado e ajuste. Não altere a da biblioteca para resolver um caso — isso quebra para todos os outros.
Por que existe revisor, e por que isso importa mais adiante: no módulo 3.3 esta biblioteca vira plugin, e plugin carrega hook, subagente e uma pasta
bin/que entra no PATH. A partir dali, publicar deixa de ser compartilhar texto e passa a ser distribuir código que roda na máquina dos colegas — e é por isso que a revisão do Geovani é o portão, não uma formalidade. A aula 3.3.3 mostra o que ele confere.
Este módulo cobriu a skill de um arquivo. No módulo 2.4 você aprende a skill multi-arquivo — com reference.md para material extenso e scripts que a skill executa —, a skill de verificação (a que vale construir primeiro) e o troubleshooting de skill que não dispara.
Correto. Quem tem a pasta do projeto herda a convenção automaticamente.
Só você seguiria a convenção. Os outros continuariam nomeando cada um do seu jeito.
É específica de um cliente. Biblioteca é para o que vale em qualquer cliente.
Você imporia o seu estilo de e-mail a todo mundo do projeto.
Funcionaria dentro daquele Project, e você teria que repetir em cada um. Skill pessoal resolve de uma vez.
Correto. É preferência sua e viaja com você em todos os projetos.
Correto. O critério é ter funcionado em dois clientes diferentes.
Um uso é uma hipótese. Skill que vai para a biblioteca sem rodagem tende a estar errada de um jeito que só o uso revela.
Análise de dump não é específica do Meridiano. Como pessoal, ela já serve você em todos os clientes.
Exemplos ajudam muito. Remova os que citam cliente, mas mantenha exemplos genéricos.
Correto. Skill de biblioteca precisa ser genérica de verdade, ou vai dar respostas erradas no cliente seguinte.
A descrição é o gatilho. Sem ela a skill não dispara para ninguém.