Skills: Criando o Primeiro Skill
Última atualização: 2026-08-31
A teoria sem prática é superficial. Esta aula guia você da criação de um Skill realmente utilizável do zero.
1. Análise de requisitos
Vamos criar um Skill de revisão de código com os seguintes requisitos:
| Requisito | Descrição |
|---|---|
| Objetivo | Revisar código automaticamente, gerando relatório de revisão estruturado |
| Dimensões de revisão | Segurança, desempenho, legibilidade, melhores práticas |
| Formato de saída | Lista de revisão classificada por severidade |
| Forma de ativação | Palavra-chave "review" ou invocação manual |
| Necessidade de ferramentas | Leitura de arquivos, busca de código |
2. Criando o arquivo do Skill
(1) Criar o arquivo
# Claude Code
touch .claude/skills/code-review.md
# OpenCode
touch skills/code-review.md
(2) Escrever o Frontmatter
---
name: code-review
description: "Skill de revisão automática de código, verifica segurança, desempenho, legibilidade e melhores práticas"
triggers:
- keyword: "review|revisar código|revisão de código"
tools:
- Read
- Grep
- Glob
---
(3) Escrever o corpo do prompt
# Skill de Revisão de Código
## Papel
Você é um especialista sênior em revisão de código, com mais de 10 anos de experiência em desenvolvimento full-stack.
## Fluxo de revisão
1. Use a ferramenta Read para ler o arquivo alvo
2. Use Grep para buscar contexto relacionado (como definições de tipos, interfaces)
3. Revise segundo as quatro dimensões a seguir
## Dimensões de revisão
### Segurança
- Injeção SQL, XSS, CSRF e outras vulnerabilidades comuns
- Informações sensíveis hardcoded
- Uso de dependências inseguras
### Desempenho
- Consultas N+1, loops desnecessários
- Riscos de vazamento de memória
- Falta de cache/índices
### Legibilidade
- Nomenclatura clara
- Funções muito longas (>50 linhas, alertar)
- Comentários suficientes
### Melhores práticas
- Seguir convenções do projeto
- Tratamento de erros completo
- Código redundante
## Formato de saída
Para cada problema, informe:
- 📍 Localização: nome_do_arquivo:linha
- 🔴/🟡/🟢 Severidade
- 📝 Descrição do problema
- ✅ Sugestão de modificação (com exemplo de código)
3. Testando o Skill
(1) Ativação manual
Insira a palavra-chave de gatilho na conversa:
Você: review src/auth/login.py
IA: (carrega automaticamente o skill code-review, executa o fluxo de revisão)
(2) Observar o comportamento
Verifique se o Skill foi carregado corretamente:
✅ O arquivo alvo foi lido automaticamente?
✅ A revisão foi feita nas quatro dimensões?
✅ O relatório de revisão classificado foi gerado?
✅ Sugestões de modificação concretas foram fornecidas?
(3) Ajustar e otimizar
Se a saída não for ideal, ajuste o prompt:
# Otimização: adicionar exemplo de saída
## Exemplo de saída
📍 Localização: src/auth/login.py:42
🔴 Severidade: Risco de injeção SQL
📝 Uso de concatenação de strings para construir consulta SQL
✅ Sugestão:
```python
# Antes
query = f"SELECT * FROM users WHERE name = '{username}'"
# Depois
query = "SELECT * FROM users WHERE name = ?"
cursor.execute(query, (username,))
---
## 4. Refinamento iterativo
### (1) Adicionar percepção de contexto
```markdown
## Regras de contexto
- Se o projeto tem .eslintrc, siga suas regras para revisar
- Se o projeto tem pyproject.toml, verifique se segue a configuração
- Antes de revisar, use Glob para verificar a stack tecnológica do projeto
(2) Adicionar ramificação condicional
## Revisão condicional
- Projeto Python: verificar adicionalmente type hints, docstring
- Projeto TypeScript: verificar adicionalmente tipo any, segurança de tipos
- Projeto Go: verificar adicionalmente error handling, vazamento de goroutine
(3) Adicionar convenções da equipe
## Convenções da equipe
- Funções não excedem 30 linhas (convenção da equipe mais rigorosa que 50 linhas)
- Cobertura de testes unitários obrigatória
- Endpoints de API devem ter documentação Swagger
Alice completou as iterações e a eficiência de revisão de código da equipe aumentou 3 vezes. Bob disse: "O segredo é que o prompt deve ser específico — 'revisar código' é vago demais, 'revisar por quatro dimensões com saída classificada' é uma instrução executável."
❓ Perguntas Frequentes
P: O que fazer se o Skill não for carregado automaticamente? R: Verifique se o nome do arquivo e o diretório estão corretos, se os triggers no frontmatter correspondem à palavra-chave digitada e se a plataforma suporta carregamento automático. P: Qual o tamanho ideal para o prompt? R: O suficiente para ser eficaz, sem limite fixo. Skills práticos geralmente têm 50-200 linhas. O essencial é ser específico e acionável, não longo e vago. P: Dá para lidar com múltiplas linguagens em um Skill? R: Sim, com ramificação condicional. Mas recomenda-se dividir em Skills separados por linguagem, mais fáceis de manter.
📖 Resumo
- Três passos para criar um Skill: analisar requisitos → escrever arquivo → testar e iterar
- Frontmatter define metadados, corpo Markdown define o comportamento
- O prompt deve ser específico e acionável, incluindo papel, fluxo, dimensões e formato de saída
- Refine iterativamente com exemplos de saída e regras de contexto
📝 Exercícios
- Básico (dificuldade⭐): Siga os passos desta aula, crie um Skill code-review e teste sua execução.
- Intermediário (dificuldade⭐⭐): Adicione ramificação condicional ao Skill code-review, suportando regras de revisão específicas para pelo menos 2 linguagens de programação.
- Avançado (dificuldade⭐⭐⭐): Crie um Skill completo de "Geração de documentação de API", incluindo análise de requisitos, design de prompt e verificação de teste em todo o fluxo.