Transforme o SOP da equipe em um Skill — e teste quando ele não deve rodar

Toda semana, um agente resume chamados. Toda semana, alguém repete datas, campos e formato. Um Skill pode reunir essas instruções. Mas se “explique este modelo” inicia a consolidação, ou a falta de dados leva ao arquivo da semana anterior, o erro também vira reutilizável.

A primeira aceitação é começar e parar nas situações certas. Escolha um trabalho já repetido e defina os limites antes da automação.

Defina o contrato de entrada de um relatório

Use um exemplo fictício: relatório de suporte com problemas recorrentes, escalonamentos, lacunas e próximos responsáveis. Ele prepara um rascunho; não envia, altera chamados nem emite reembolsos.

Especifique período, fila, arquivo atual, modelo permitido e saída. Datas são variáveis de cada execução, não uma instrução permanente de “esta semana”. Identifique produto ou fila, sem autorizar implicitamente a leitura de todas as pastas.

Se faltar arquivo, houver datas incompatíveis ou campos necessários ausentes, peça a entrada. Não estime fatos atuais a partir da semana anterior nem transforme vazio em normal. Quantidade de chamados não determina tempo de resolução.

Trabalho: resumir uma fila nomeada entre início e fim explícitos.
Entradas: período, arquivo atual de chamados e modelo.
Saídas: relatório preliminar e lista de lacunas na pasta desta execução.
Parar: período indefinido, arquivo ausente ou janela incompatível.
Não fazer: enviar, alterar status, reembolsar ou responder ao cliente.

Peça ao Skill Creator para empacotar o método

Em uma sessão do Buda, diga “Transforme isso em um Skill”. O Skill Creator pergunta sobre trabalho, gatilhos, saída e testes antes de criar SKILL.md.

Entregue contrato de entrada, modelo e exemplos. name identifica o Skill; description explica quando usar; o corpo contém as etapas. Não copie dados de clientes, credenciais ou o arquivo de uma semana para um Skill compartilhado. O método deve referenciar as entradas de cada execução.

Primeiro pesquise e instale um Skill adequado no Marketplace do Buda AI, leia o método e só então decida se precisa personalizar. A diferença útil pode estar no período, formato e condição de parada, não no nome sofisticado.

Separe três pedidos parecidos

“Resuma os chamados desta semana no nosso modelo” deve acionar o método. “Explique as colunas do modelo” não deve iniciar a consolidação. “Não temos arquivo novo; vamos discutir estratégia” não autoriza fabricar relatório.

Uma descrição pode explicitar os limites:

Usar quando o usuário solicitar explicitamente um relatório de chamados
para um período nomeado no modelo da equipe.
Não usar para ler o modelo, explicar campos ou discutir estratégia.
Se faltarem entradas obrigatórias, listar lacunas antes de gerar o relatório.

Isso é uma descrição para testar, não um classificador garantido. Use a linguagem real dos colegas. Declarações de ferramentas não são um sistema de aprovação; escrever “somente leitura” não substitui verificar o comportamento.

Escreva cinco etapas com resultados verificáveis

Ler: confirmar janela e arquivo atual, sem vasculhar dados de clientes fora do escopo.

Validar: verificar datas, IDs e campos obrigatórios; separar divergências de lacunas.

Organizar: seguir o modelo, manter referências aos chamados e marcar causas não registradas como pendentes.

Conferir: reconciliar contagens com as entradas, explicar duplicatas e identificar responsáveis por escalonamentos.

Entregar: salvar rascunho e lacunas, informar caminhos ao revisor e parar antes do envio.

Entradas e resultados por etapa são mais testáveis que “analise com atenção”. Separe fatos registrados de inferências; a causa ausente deve permanecer ausente.

Experimente três positivos, três negativos e dois incompletos

É um conjunto sugerido de aceitação, não desempenho medido:

Registre pedido, acionamento real, artefato, erro e revisão. Separe gatilhos perdidos de falsos gatilhos. Um relatório bem formatado com fonte errada falha. Oito exemplos aprovados não estabelecem confiabilidade em todo cenário comercial.

Confira a versão antes de compartilhar

Apps & Skills mostra o manifesto completo. Depois de editar um Skill Local, clique Refresh, confira as novas etapas e repita o caso que motivou a mudança. Refresh não certifica testes nem publica no Marketplace.

Teste primeiro no escopo de um agente. Considere o escopo do Space após a equipe aceitar saídas e condições de parada. Skills do Space ficam visíveis aos agentes desse espaço; mantenha informações sensíveis e contexto de clientes fora do método compartilhado.

Registre versão, mudança de comportamento e casos afetados. Alterar description muda o acionamento; alterar campos pode afetar etapas posteriores. Repita positivos, negativos e entradas incompletas. O agendamento vem depois, com datas e fontes por execução. Uma agenda fixa não valida o método.

Qual a diferença entre Skill e agente?

O agente mantém sessões, arquivos e tarefas; o Skill oferece um método que ele carrega. Isso reduz explicações repetidas, mas cada relatório ainda exige período e arquivo atual.

Por que usar Refresh após editar?

Apps & Skills precisa verificar novamente o workspace para incorporar mudanças. Edite o SKILL.md Local, use Refresh, abra o manifesto e confira versão e etapas antes de repetir os testes afetados.

Qual caso negativo vale guardar?

Um pedido próximo ao trabalho real que não deveria executar, como “apenas explique este modelo”. Ele expõe uma descrição ampla demais. Guarde também um caso de datas conflitantes para detectar entradas antigas.

Escolha um SOP repetido, escreva condições de parada e entregue os oito exemplos ao Skill Creator. Um método reutilizável deve facilitar o começo e deixar claro quando parar.