Publicávamos artigo por artigo repetindo os mesmos passos na mão: escolher tema, checar fato, gerar capa, traduzir em 3 línguas, publicar. Depois de errar a mesma coisa duas vezes, viramos os passos em regra escrita. Depois de errar de um jeito novo, viramos a regra em gate: um passo que a Verboo Code não pode pular. Isso é uma skill.
Como transformar um processo manual em skill de agente?
Separe o padrão do fluxo. O padrão é o documento que diz o que é um bom resultado: como escrever um título, o que compõe um CTA, que dado precisa de fonte. O fluxo é a skill que a Verboo Code executa: em que ordem fazer, qual tool chamar, qual gate checar antes de seguir. Um arquivo `.md` de skill começa assim:
---
name: minha-skill
description: O que ela faz, e quando usar (a Verboo Code lê essa linha pra decidir se aciona)
---
# Minha Skill
## Passo 1 - ...
## Passo 2 - ...Manter os dois documentos separados evita um problema concreto: se a regra de estilo muda toda semana e mora dentro da skill, a skill inteira precisa ser reescrita toda semana. Separado, só o padrão muda.
Como saber se a skill está pronta pra rodar sozinha?
Não está, só porque compilou. Testamos publicando artigo de verdade em produção, um por tipo de fluxo que a skill cobre, antes de deixar ela escolher e publicar sem ninguém olhando por cima. Só depois disso rodamos ela uma vez do início ao fim sem guiar nenhum passo, pra ver se as instruções escritas bastavam sem a gente completando lacuna na hora.
Na prática: a primeira vez que a skill rodou sozinha, ela escolheu um tema pela fila, verificou o fato numa fonte que a instrução nem citava (o repositório de um concorrente), e corrigiu isso por conta própria. Sinal de que a regra geral ("nunca invente comando, leia o código-fonte") tinha ficado específica demais no texto original.
O que quebrou no caminho, e como virou regra?
Cada linha da tabela abaixo é um erro real que aconteceu numa rodada e virou gate na versão seguinte da skill.
| Antes | Depois | Por quê |
|---|---|---|
| Taxonomia de tema fixa no texto da skill | Taxonomia mora só na fila editorial, a skill lê de lá | A taxonomia mudou e a skill continuou lendo a antiga, dessincronizada |
| Dado de produto (versão, preço) escrito à mão na skill | Script roda e busca o dado na hora antes de escrever | Número escrito à mão em documento que ninguém revisita fica velho e ninguém percebe |
| Gerar capa e subir direto | Abrir o arquivo gerado e conferir a cor da mascote antes de subir | O gerador de imagem ignorou a cor pedida no prompt em 2 de 3 tentativas |
| Assumir revisão de tradução isolada por idioma | Reler a revisão de cada idioma imediatamente antes de publicar | Publicar uma tradução muda a revisão das outras do mesmo post, mesmo sem tocar nelas |
Esse padrão serve pra qualquer skill que você for construir?
Sim, os 3 princípios não são específicos de blog. Documento de padrão fora da skill, pra mudar um sem reescrever o outro. Gate explícito pra cada erro real encontrado, nunca uma regra genérica tipo "capriche" que ninguém consegue checar. E rodar cada ramo raro pelo menos uma vez em produção antes de confiar nele sem supervisão, porque o ramo raro é justamente o que a primeira leitura da instrução não cobre bem.
Testar uma skill assim custa sessão longa, com muita chamada de ferramenta e tradução repetida em 3 línguas até acertar. Na Verboo Code isso não vira decisão de custo: os planos não têm teto de token, então a sessão de teste não compete com a de produção. Conheça em verboo.ai.
