> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Criando Skills
> Referência completa do formato SKILL.md e das opções de frontmatter
As skills são definidas em arquivos `SKILL.md` dentro de um diretório nomeado. Esta página explica tudo o que você precisa saber para escrever skills eficazes.
***
## Estrutura de Arquivos
Coloque as skills no diretório apropriado, de acordo com o escopo:
```
# Específico do projeto (com commit no git)
.devin/skills/
└── my-skill/
└── SKILL.md
# Global — disponível em todos os projetos (sem commit)
# Linux/macOS:
~/.config/devin/skills/
└── my-skill/
└── SKILL.md
# Windows:
%APPDATA%\devin\skills\
└── my-skill\
└── SKILL.md
```
O nome do diretório é o identificador da skill (usado na chamada `/my-skill`). O arquivo `SKILL.md` contém frontmatter YAML opcional e o conteúdo do prompt da skill.
No Windows, `%APPDATA%` normalmente corresponde a `C:\Users\\AppData\Roaming`.
***
## Referência do frontmatter
```yaml theme={null}
---
name: my-skill
description: What this skill does (shown in completions)
argument-hint: "[file] [options]"
model: sonnet
subagent: true
allowed-tools:
- read
- grep
- glob
- exec
permissions:
allow:
- Read(src/**)
deny:
- exec
ask:
- Write(**)
triggers:
- user
- model
---
Your prompt content goes here...
```
### Todos os campos do frontmatter
| Campo | Tipo | Padrão | Descrição |
| --------------- | ------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| `name` | string | nome do diretório | Nome de exibição da skill |
| `description` | string | nenhum | Exibido nas sugestões de autocompletar do comando de barra |
| `argument-hint` | string | nenhum | Dica exibida após o nome do comando (ex.: `[filename]`) |
| `model` | string | modelo atual | Substitui o modelo usado ao executar esta skill |
| `subagent` | boolean | `false` | Executa a skill como um [subagente](/pt-BR/cli/subagents) em vez de inline |
| `agent` | string | nenhum | Executa a skill como um subagente usando um perfil específico de [subagente personalizado](/pt-BR/cli/subagents#custom-subagents) |
| `allowed-tools` | list | todas as ferramentas | Restringe quais ferramentas a skill pode usar |
| `permissions` | object | herdar | Substituições de permissão para esta skill |
| `triggers` | list | `[user, model]` | Como a skill pode ser acionada |
***
## Override de modelo
Use o campo `model` para executar uma skill usando um modelo diferente do que está ativo na sessão atual. Isso é útil para usar um modelo mais rápido em tarefas simples ou um modelo mais avançado em tarefas complexas:
```yaml theme={null}
---
name: quick-fix
description: Fast lint fix using a lightweight model
model: swe
---
Fix the lint errors in the current file.
```
O nome do modelo usa os mesmos valores da flag `--model` da CLI (por exemplo, `opus`, `sonnet`, `swe`, `codex`). Consulte [Models](/pt-BR/cli/models) para ver a lista completa. Após a conclusão da skill, a sessão retorna ao modelo que estava ativo anteriormente.
***
## Executando Skills como Subagentes
Executar skills como subagentes é **experimental**. Os campos `subagent` e `agent` do frontmatter podem mudar em versões futuras.
Por padrão, o prompt de uma skill é injetado na conversa atual — o agente o processa inline. Como alternativa, você pode executar uma skill como um **subagente**, o que inicia um worker independente com sua própria janela de contexto. Isso é útil para skills que executam tarefas focadas e autocontidas, em que você não quer que a saída sobrecarregue a conversa principal.
Há duas maneiras de executar uma skill como subagente:
### `subagent: true`
Defina `subagent: true` para executar a skill como subagente usando o perfil padrão `subagent_general`:
```yaml theme={null}
---
name: deep-research
description: Thorough codebase research on a topic
subagent: true
model: sonnet
allowed-tools:
- read
- grep
- glob
---
Research the topic the user asked about thoroughly.
Search broadly, follow references, and trace call chains.
Report all findings with specific file paths and line numbers.
```
Ao ser invocada, esta skill inicia um subagente em primeiro plano que executa o prompt da skill como tarefa. O agente principal aguarda a conclusão do subagente e, em seguida, lê e resume os resultados.
Use o campo `agent` para executar a skill como um subagente com um [perfil personalizado de subagente](/pt-BR/cli/subagents#custom-subagents) específico:
```yaml theme={null}
---
name: review-pr
description: Review the current PR using the reviewer subagent
agent: reviewer
---
Review the staged changes for correctness, security, and style issues.
```
O valor `agent` deve corresponder ao nome de um perfil de subagente registrado (seja um perfil integrado, como `subagent_explore` / `subagent_general`, ou um perfil personalizado que você definiu). O subagente herda o prompt de sistema, as restrições de ferramentas e o modelo do perfil — enquanto o conteúdo da skill se torna a task.
Se `agent` e `subagent` estiverem definidos, `agent` terá precedência. O campo `model` na skill faz override do modelo do perfil do subagente quando ambos estiverem especificados.
Skills executadas como subagentes não criam subagentes aninhados — se a skill já estiver sendo executada dentro de um subagente, ela será executada inline para evitar recursão infinita.
### Orquestrando subagentes com skills
Como as skills podem ser executadas como subagentes, você pode usá-las para orquestrar trabalhos em várias etapas. Defina um conjunto de skills de subagente, cada uma responsável por uma tarefa específica, e depois escreva uma skill comum que as invoque. A skill externa se torna a orquestradora — ela chama cada subagente, coleta os resultados e decide o que fazer em seguida.
Por exemplo, aqui estão duas skills de subagente e uma orquestradora que as coordena:
```markdown theme={null}
---
name: research-changes
description: Research recent code changes and their impact
subagent: true
allowed-tools:
- read
- grep
- glob
- exec
---
Analyze the recent changes in this repository:
1. Run `git log --oneline -20` to see recent commits
2. For each significant commit, examine what changed and why
3. Identify any patterns, risks, or areas that need attention
Report your findings with specific file paths and commit references.
```
```markdown theme={null}
---
name: validate-tests
description: Run tests and validate coverage for recent changes
subagent: true
allowed-tools:
- read
- grep
- glob
- exec
---
Validate the test suite for the project:
1. Identify the test framework and run command
2. Run the full test suite
3. Check for any failing tests
4. Review test coverage for recently changed files
Report which tests pass, which fail, and any coverage gaps.
```
```markdown theme={null}
---
name: health-check
description: Full project health check — research changes then validate tests
---
Perform a full health check on this project:
1. First, use the /research-changes skill to understand recent changes
2. Then, use the /validate-tests skill to verify the test suite
3. Finally, synthesize the findings from both into a summary:
- What changed recently and why
- Whether tests are passing
- Any risks or recommended actions
```
Invocar `/health-check` executa o orquestrador no agente principal. Ele chama `/research-changes`, que cria um subagente para explorar o repo. Quando isso termina, ele chama `/validate-tests`, que cria outro subagente para executar os testes. Em seguida, o orquestrador combina os dois resultados em um resumo final.
Uma skill de subagente **nunca** usará um subagente ao chamar outras skills, mesmo que essas skills tenham `subagent: true` — elas são executadas inline. Isso significa que você não precisa se preocupar com aninhamento sem limites. O padrão de orquestração tem sempre apenas um nível de profundidade: o orquestrador cria subagentes, e esses subagentes executam todo o restante inline.
***
## Conteúdo do prompt
O conteúdo do arquivo SKILL.md (após o frontmatter) é o prompt injetado quando a skill é invocada.
***
## Permissões
As skills podem definir seu próprio escopo de permissões usando a mesma sintaxe da configuração principal de permissões:
```yaml theme={null}
permissions:
allow:
- Read(src/**)
- Exec(npm run test)
deny:
- Write(/etc/**)
- exec
ask:
- Write(src/**)
```
**Como as permissões de skill funcionam:**
* `allow` — Esses escopos são aprovados automaticamente durante a execução da skill
* `deny` — Esses escopos são bloqueados durante a execução da skill
* `ask` — Esses escopos sempre pedem confirmação ao usuário
As permissões de skill são adicionadas às permissões base da sessão (não as substituem). Uma skill não pode conceder permissões negadas em um nível mais alto (configuração do projeto ou da organização).
***
## Ferramentas permitidas
Restrinja as ferramentas que a skill pode usar:
```yaml theme={null}
allowed-tools:
- read
- grep
- glob
```
Nomes de ferramentas disponíveis: `read`, `edit`, `grep`, `glob`, `exec`
Você também pode permitir ferramentas do MCP:
```yaml theme={null}
allowed-tools:
- read
- mcp__github__list_issues
- mcp__github__create_issue
```
Se `allowed-tools` não for especificado, a skill terá acesso a todas as ferramentas. Para skills críticas de segurança, sempre restrinja ao mínimo necessário.
***
## Exemplos
### Skill de revisão de código
```markdown theme={null}
---
name: review
description: Review staged changes for issues
allowed-tools:
- read
- grep
- glob
- exec
permissions:
allow:
- Exec(git diff)
- Exec(git log)
---
Run `git diff --staged` and review the changes for quality issues.
Evaluate:
1. **Correctness** — Any logic errors or edge cases?
2. **Security** — Any vulnerabilities introduced?
3. **Performance** — Any obvious inefficiencies?
4. **Style** — Consistent with the codebase?
Provide a summary with specific line references.
```
### Gerador de Componentes
```markdown theme={null}
---
name: component
description: Generate a React component from a description
argument-hint: ""
allowed-tools:
- read
- edit
- grep
- glob
model: sonnet
permissions:
allow:
- Write(src/components/**)
---
Crie um novo componente React usando o nome fornecido pelo usuário:
1. Verifique os componentes existentes em src/components/ para convenções de estilo
2. Crie o arquivo do componente em src/components//.tsx
3. Crie uma exportação barrel em src/components//index.ts
4. Adicione testes básicos em src/components//.test.tsx
5. Siga os padrões encontrados nos componentes existentes
```
### Checklist de implantação
```markdown theme={null}
---
name: deploy
description: Run through the deployment checklist
triggers:
- user
allowed-tools:
- read
- exec
- grep
permissions:
allow:
- Exec(npm run)
- Exec(git)
---
Run through the deployment checklist:
1. Run the test suite: `npm run test`
2. Run the linter: `npm run lint`
3. Check for uncommitted changes: `git status`
4. Verify the build: `npm run build`
5. Show the current branch and last commit
Report the status of each step. If anything fails, stop and explain the issue.
```
### Especialista em buscas
```markdown theme={null}
---
name: find
description: Find relevant code across the project
argument-hint: ""
allowed-tools:
- read
- grep
- glob
triggers:
- user
- model
---
Pesquise o código-fonte minuciosamente para o que o usuário perguntou.
Use grep para busca de conteúdo e glob para descoberta de arquivos.
Forneça caminhos de arquivos relevantes e trechos de código.
Explique como as partes se conectam.
```
***
## Dicas
Uma skill deve fazer bem uma única coisa. Crie várias skills em vez de uma mega-skill.
Mostre ao agente, no prompt, como é uma boa saída.
Restringir as ferramentas torna as skills mais seguras e previsíveis.
Invoque sua skill e refine o prompt até que a saída seja o que você quer.