---
titulo: Construir Skills a partir do modelo
modelo: Modelo de Gestão de Agentes de IA
codigo: M09
versao: "1.2.0-rc.1"
consumo: integral na construção; consulta focal na reforma de uma Skill
---

# M09 — Construir Skills a partir do modelo

Uma Skill torna uma transformação reutilizável sob demanda, com entradas diferentes e resultado reconhecível. Seu desenho precisa resolver reconhecimento, conteúdo e execução. A Skill não assume a identidade, a responsabilidade persistente ou a autoridade inteira do agente. Pode mobilizar conhecimento, procedimento e ferramenta sem se tornar nenhum deles.

Use a capacidade a realizar, definida em [M03](M03-Conceber-o-Agente-e-suas-Capacidades.md), o conhecimento desenvolvido em [M04](M04-Desenvolver-a-Inteligencia-do-Trabalho.md), a organização das fontes de [M05](M05-Organizar-Conhecimento-Compartilhado-Fontes-e-Rotas.md) e os requisitos de acesso e operação de [M10](M10-Compor-Acessos-Ferramentas-e-Operacoes.md). Use [M08](M08-Escrever-Prompts-e-Instrucoes-de-Entrada.md) para escrever instruções claras. O resultado desta engenharia é uma fonte operacional suficiente para o consumidor e, quando a implementação o exigir, seus apoios e sua distribuição. [M11](M11-Implementar-e-Instalar-em-Cada-Ambiente.md) confere a instalação.

## 1. Delimitar a transformação reutilizável

Explique ocasião, entrada variável, transformação, saída utilizável, benefício e fronteira com recursos vizinhos. Examine se uma Skill existente pode ser aproveitada ou evoluída. Uma nova variante só merece unidade própria quando sua condição de uso, operação ou manutenção justifica a separação.

Uma instrução pequena pode bastar a uma tarefa simples; uma regra que deve valer sempre pertence à orientação permanente; uma fonte pode oferecer julgamento sob demanda sem nova transformação. Uma Skill é pertinente quando organizar a operação recorrente, seus critérios e apoios produz contribuição reconhecível. Acesso vivo e acionamento por agenda são meios de M10, não propriedades criadas pelo nome da Skill.

Se houver procedimento de origem, separe método, sequência do processo e dados da ocorrência. Copiar passos para outro arquivo pode conservar a lacuna de julgamento do procedimento. Preserve origem, edição e autoridade; a transformação não recebe permissão para atos que o processo reserva a outra pessoa.

## 2. Incorporar o método suficiente

Converta os capítulos pertinentes em operação para o público da Skill. Ela precisa ensinar como reconhecer a situação, obter os insumos, escolher caminhos, transformar material, tratar insuficiências, produzir e conferir a saída. “Use o modelo e analise” não transfere a operação.

Defina como a IA receberá o conhecimento necessário: o pacote pode conter o conteúdo de que ela precisa ou indicar uma fonte que ela conseguirá consultar durante o trabalho. Se receber somente o pacote, inclua nele o método, os critérios e os apoios necessários, com links que funcionem dentro da pasta entregue. Se depender de uma fonte atual do contexto, explique como encontrá-la, acessá-la e interpretar seu conteúdo com os meios disponíveis à IA. Dado atual deve permanecer atual; independência de autoria não significa congelá-lo em um pacote.

Mantenha relação de origem e manutenção de M05. Aplicação própria recebe revisão de impacto, sem herdar automaticamente toda mudança ou versão da fonte. Cópia recebe conferência de fidelidade. O consumidor não pode depender silenciosamente do plugin de construção, de caminho pessoal ou da conversa que produziu o recurso.

## 3. Escrever nome, descrição e fronteira

Nomeie ação, objeto e qualificador necessário. A descrição deve permitir reconhecer o trabalho pela linguagem real dos pedidos, inclusive sem a palavra “Skill”. Comece pela contribuição principal e inclua a fronteira que evita confusão provável. Não use a descrição como resumo de todos os títulos do manual.

Para as três transformações de gestão abaixo, as descrições de referência são:

| Transformação | Descrição funcional | Fronteira |
|---|---|---|
| Organizar e instalar o sistema de gestão de agentes | Organiza ou ajusta o ambiente e aplica componentes em um destino escolhido; permite realizar somente a parte suficiente ao pedido | Não desenvolve sozinha a inteligência especializada dos agentes nem exige instalação completa para organizar o ambiente |
| Construir ou evoluir agente | Concebe capacidades, desenvolve conhecimento, escreve orientação e compõe componentes e implementação de um agente novo ou existente | Não assume o trabalho operacional do agente produzido |
| Auditar agente e suas relações | Examina conteúdo, estrutura e relações no alcance definido, diagnostica causas e prepara ou aplica ajustes autorizados | Auditoria documental não comprova funcionamento ou utilidade em uso |

Os nomes finais e campos técnicos seguem o destino. Uma transformação pode colaborar com outra sem disputar o mesmo pedido. Em um pedido de “avaliar se o agente está adequado”, começa a auditoria; se o diagnóstico exige reforma, o construtor recebe a passagem e o alcance correspondente.

A construção produz os componentes e os requisitos de implementação; a instalação realiza a configuração no destino, conforme M11. Organização de ambiente, instalação e atualização/migração são modos proporcionais da Skill de organização e instalação, descrita na tabela como **Organizar e instalar o sistema de gestão de agentes**. Sua escrita pode ocorrer depois dos outros componentes, enquanto seu uso pode iniciar o sistema em um assistente de origem, sem exigir o agente final previamente instalado. O ambiente entrega à construção objetos, fontes, destinos, acessos e dependências suficientes; a construção devolve somente a relação que precisar de ajuste. Na ausência da Skill vizinha, a contribuição mínima de [M02](M02-Desenhar-o-Ambiente-e-o-Modelo-de-Gestao.md) permite continuar a parte sustentada sem simular efeitos não realizados.

Reconhecimento e autorização do efeito são decisões diferentes. Proteger uma ação externa no seu ponto de realização não exige tornar toda Skill exclusivamente manual. Preserve a política de invocação escolhida e o que o ambiente suporta.

## 4. Distribuir corpo e apoios

| Recurso | Conteúdo que justifica sua presença | Condição de qualidade |
|---|---|---|
| Corpo principal | Transformação, critérios essenciais, operação comum, limites e condições de cada apoio | Permite conduzir o caso comum e encontrar aprofundamento |
| Referência | Conhecimento substancial ou variante necessária em certa situação | Conteúdo efetivo, condição de abertura e fronteira explícitas |
| Script | Cálculo, validação ou manipulação mecânica repetível | Entradas validadas, saída útil e falha tratada; julgamento permanece onde cabe |
| Modelo/arquivo de apoio | Forma que precisa ser preservada na saída | É efetivamente usado, sem substituir o critério de qualidade |
| Ferramenta/conector | Dado ou efeito fora dos meios suficientes da sessão | Interface observada, autoridade e acesso definidos em M10 |

Uma Skill simples pode conter apenas o corpo. Não crie referências vazias, scripts cerimoniais ou modelos sem utilização. Uma condição crítica da operação comum não deve ficar escondida em apoio opcional. Uma variante volumosa não precisa ocupar toda execução.

Quando o destino adotar arquivo `SKILL.md`, escreva nome, descrição e metadados no esquema aceito. Não invente campos ou comportamento de seleção. A versão deve ser identificável no recurso ou manifesto suportado. O corpo contém o método vigente; histórico, respostas esperadas de testes e bastidores ficam nos registros de autoria.

## 5. Estabelecer o contrato com agente e meios

O agente fornece contexto, mandato e continuidade; a Skill realiza sua transformação. Declare entradas que recebe, fontes que recupera, resultado que devolve e condição que exige retornar à condução. O usuário não precisa conceber capacidades que o método já permite deduzir, mas fatos e decisões particulares precisam de origem.

Declare os meios indispensáveis e alternativas suficientes. Se puder produzir o artefato sem escrever no destino, entregue o conteúdo e a passagem exata de aplicação, identificando a parte não realizada. Uma ferramenta indisponível não deve virar alegação de efeito concluído. Credenciais e segredos ficam fora do pacote.

Preserve identidade do objeto nas passagens. Se a auditoria devolve achado, inclua fonte, trecho, consequência e ajuste; se o construtor devolve componente, inclua origem/edição, destino e conferência; se o ambiente devolve relação, inclua significado e identidades. [M14](M14-Construir-a-Conducao-do-Agente-Construtor.md) compõe essas passagens para completar a demanda.

## 6. Escrever, versionar e conferir a distribuição

Mantenha uma fonte editável. Pacote e cópia instalada derivam dela, com correspondência de edição e variações declaradas. Preserve identificadores existentes em reforma; uma melhoria de texto não autoriza reinicializar e apagar campos, recursos ou política de uso.

Confira caminhos relativos, dependências e condição de abertura dos apoios. Remova marcadores sem conteúdo e referências que só funcionam na máquina do autor. Teste o pacote em localização diferente da autoria, com o conjunto previsto para o consumidor. Uma falha não pode ser completada em silêncio pelo conhecimento do construtor.

Mudança em método compartilhado exige análise de consumidores de M05/[M13](M13-Operar-Gerir-e-Evoluir-o-Conjunto.md). Uma edição instalada pode continuar distinta da fonte nova, mas essa condição precisa ser recuperável. Não declare atualização do ambiente a partir da geração do pacote.

## 7. Separar as provas e corrigir a camada

Fixe a pergunta e a condição de falha antes do ensaio:

| Pergunta | Ensaio pertinente | O que não demonstra |
|---|---|---|
| É reconhecida na situação certa? | Pedidos positivos, negativos próximos e fronteiras, sem depender do nome | Uma classificação documental não prova seleção nativa |
| Carrega conhecimento suficiente? | Consumidor separado com recurso e insumos, sem análise pronta | Estrutura válida não prova bom julgamento |
| Executa a operação mecânica? | Entrada representativa e falha material dos scripts | Importar o programa não comprova resultado |
| Está presente no ambiente? | Descoberta, seleção e leitura pelo mecanismo normal | Invocação por caminho explícito não prova descoberta automática |
| Produz resultado útil? | Artefato ou efeito confrontado com pedido e critério | Acionamento não prova utilidade |

Compare com a versão anterior ou com realização sem Skill quando for necessário julgar benefício, usando condições comparáveis. Um resultado favorável isolado não demonstra ganho causal nem eficácia recorrente. Se ambas as condições atendem, a reutilização e a manutenção podem justificar a forma, sem inventar superioridade observada.

Diagnostique reconhecimento, conteúdo, conhecimento, operação mecânica, acesso, presença, autoridade ou efeito. Corrija a menor casa suficiente e reteste o aspecto afetado. Preserve evidências fora da distribuição, com versão, caso, meios, resultado, intervenção e limite.

Exemplo ilustrativo: uma Skill revisa documentos recebidos contra critérios informados e produz devolução acionável. Uma referência desenvolve julgamento substancial; um script verifica IDs únicos quando esse contrato existe; um modelo conserva formato se necessário. O script não decide aceitação. A aprovação em sistema externo exige outra operação e autoridade. Para corrigir apenas uma referência, a transformação ampla pode ser dispensada. Essa proporção orienta a construção das três Skills sem obrigar todos os apoios em cada uma.