Formato de Skills do Thoth
Estrutura de Pastas
(seção não gerada — tente novamente)
Como Nomear uma Skill (Slug)
O slug é o identificador único da skill no repositório. Ele aparece no caminho da pasta (skills/<slug>/) e é usado internamente pelo Thoth para indexação e roteamento.
Regras obrigatórias
-
Formato kebab-case
Use apenas letras minúsculas, números e hífens (-). Nunca use:- Espaços →
marketing helper❌ - Underscores →
marketing_helper❌ - CamelCase →
MarketingHelper❌ - Caracteres especiais →
marketing@helper❌
- Espaços →
-
Descritivo e específico
O slug deve comunicar claramente o propósito da skill. Prefira verbos de ação + contexto:- ✅
briefing-extractor(extrai briefings de conversas) - ✅
horus-content-creator(cria conteúdo seguindo brand kit Horus) - ✅
calendar-scheduler(agenda eventos em calendário) - ❌
skill1,helper,marketing(genéricos demais)
- ✅
-
Único no repositório
Antes de criar, verifique se o slug já existe emskills/. Colisões causam falha no build.
Convenções recomendadas
| Padrão | Quando usar | Exemplo |
|---|---|---|
<ação>-<domínio> | Skill faz uma ação específica em um domínio | analyze-contract, draft-petition |
<produto>-<função> | Skill é parte de um produto/ecossistema | horus-onboarding, thoth-validator |
<output>-<formato> | Skill gera um tipo específico de saída | landing-page-builder, email-composer |
Exemplos práticos
Bom:
legal-brief-analyzer— analisa petições jurídicasseo-article-writer— escreve artigos otimizados para SEOclient-intake-form— processa formulários de captação
Ruim:
the-best-skill-ever— não descreve funçãoSkill_Marketing— usa underscore e maiúsculahelper— genérico demaisskill-2024-01-15— não deve incluir timestamps
Checklist rápido
- Usa apenas
a-z,0-9e-? - Tem entre 2 e 5 palavras?
- Comunica claramente o propósito?
- Não colide com slugs existentes em
skills/? - Evita termos genéricos ("helper", "tool", "skill")?
💡 Dica: Se você precisar de mais de 5 palavras, a skill provavelmente está fazendo coisas demais. Considere dividir em duas skills menores e mais focadas.
Anatomia do SKILL.md
(seção não gerada — tente novamente)
Frontmatter: Campos Obrigatórios e Opcionais
(seção não gerada — tente novamente)
Por Que a Description É Crítica?
(seção não gerada — tente novamente)
Corpo do SKILL.md: Seções Recomendadas
(seção não gerada — tente novamente)
Pasta references/: Quando e Como Usar
(seção não gerada — tente novamente)
Pasta templates/: Esqueletos de Saída
(seção não gerada — tente novamente)
Pasta scripts/: Helpers Executáveis
(seção não gerada — tente novamente)
Guardrails: Regras Não-Negociáveis
(seção não gerada — tente novamente)
Versionamento Semântico
(seção não gerada — tente novamente)
Pipeline de Build e Formatos Derivados
(seção não gerada — tente novamente)
Por Que Usar Apenas Caminhos Relativos?
(seção não gerada — tente novamente)
Checklist: Antes de Submeter uma Skill
(seção não gerada — tente novamente)
Perguntas frequentes
Qual é a estrutura mínima obrigatória de uma skill?
Uma pasta com nome kebab-case contendo obrigatoriamente o arquivo SKILL.md com frontmatter (name + description). Subpastas references/, templates/ e scripts/ são opcionais.
Como o modelo decide qual skill invocar?
O modelo lê apenas o campo 'description' do frontmatter. Por isso, a descrição deve ser específica, mencionando casos de uso concretos e tipo de saída esperada.
Posso editar os arquivos gerados automaticamente pelo build?
Não. Edite apenas o SKILL.md canônico e execute 'npm run build'. O pipeline gera automaticamente os formatos derivados (Copilot, Cursor, system prompts).
O que são guardrails e por que são obrigatórios?
Guardrails são regras explícitas sobre quando recusar requests, o que nunca inventar e como lidar com inputs incompletos. Skills sem guardrails não são aceitas no merge.
