skill-factory

O que skill-factory faz?

Constrói uma skill da mesma forma que um mantenedor cuidadoso faria, e então segura o lançamento até que o usuário o aprove. Funciona em qualquer agente; cada etapa nomeia a melhor ferramenta e um fallback que sempre funciona.

Entrada: uma ideia de skill, ou um drop entregue pelo loot com suas evidências (consulta, resultados de busca, prova, borda). Pasta de destino: onde o usuário disser, senão ../<slug> fora do histórico do repositório atual.

1. Especificação

Escreva SPEC.md: objetivo, entradas e saídas, e uma checklist de aceitação onde cada linha pode ser testada. Menos de uma página. Se o loot entregou o item, reutilize suas evidências em vez de pesquisar novamente. Pergunte ao usuário apenas quando duas interpretações da ideia produziriam skills diferentes.

2. Construção, testes primeiro

• Se o agente tiver um auxiliar de criação de skills (no Claude Code: anthropic-skills:skill-creator), use-o para a skill e suas avaliações.
• Caso contrário, escreva SKILL.md você mesmo: frontmatter com name (kebab-case) e uma description que diga o que faz e quando acionar, depois os passos.
• Scripts recebem testes antes do código (node:test ou pytest). Implemente até que passem. Escreva arquivos com sua ferramenta de edição de arquivos, não com heredocs do shell.
• Execute todos os testes e avaliações. Mantenha o comando exato e sua saída para a etapa 4.

3. Revisão independente

O construtor não avalia o próprio trabalho.

• Melhor: inicie um subagente que não tenha visto esta conversa. Dê a ele apenas a pasta de destino e references/release-checklist.md com esta instrução: "Revise a skill em contra a checklist. Responda PASS ou FAIL por item com evidência arquivo:linha. Quando estiver em dúvida, FAIL. Sinalize qualquer alegação que os testes ou avaliações não comprovem."
• Fallback: sem subagentes: para cada item da checklist, escreva o argumento mais forte de que ele FALHA antes de decidir.

Corrija cada FAIL, execute os testes novamente, revise novamente. Pare quando todos os itens passarem, ou quando um item estiver bloqueado no usuário (diga qual e por quê).

4. Portão de lançamento

Varra por segredos: node <pasta da skill loot>/scripts/scan.mjs <pasta>, mais gitleaks dir <pasta> se estiver instalado. Em seguida, mostre ao usuário um manifesto e pare para um "sim" claro:

• nome do repositório, público ou privado
• versão e linha do changelog
• os arquivos a publicar
• resultados de testes e avaliações (comando + contagem de aprovações), o veredito da revisão
• qualquer coisa pulada

Um "sim" cobre exatamente aquele manifesto. Então publique a partir de um git init novo: commit release vX.Y.Z, tag, gh repo create e push, e instale a skill onde o agente do usuário carrega skills. Sem gh ou não logado: imprima os comandos. Nunca peça, digite ou armazene credenciais.

5. Relatório

Uma mensagem curta em linguagem simples: links, resultados de testes, resultado da revisão e o que resta para o usuário.