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, o conhecimento desenvolvido em M04, a organização das fontes de M05 e os requisitos de acesso e operação de M10. Use M08 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 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 — Compor acessos, ferramentas e operações, 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 — Organizar conhecimento compartilhado, fontes e rotas. 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:

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 — Implementar e instalar em cada ambiente. 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 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

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 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 — Organizar conhecimento compartilhado, fontes e rotas/M13. 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:

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.