Transformar tarefa recorrente em workflow de IA

Use para descrever uma tarefa textual que se repete e cujo início, término e resultado podem ser observados. Bons casos incluem transformar um briefing confirmado em um rascunho padronizado, classificar solicitações recebidas ou preparar um relatório a partir de materiais autorizados. A entrega é um workflow legível e testável, não uma automação implantada.

O trabalho é adequado quando existem dois ou três casos recentes anonimizados, porque eles revelam decisões e exceções que uma descrição abstrata costuma esconder. O workflow deve tornar explícito o que entra, o que uma pessoa decide, o que dependeria de sistema externo e como reconhecer uma saída aceitável.

Não use para operar contas, enviar mensagens, publicar conteúdo, movimentar dinheiro ou conceder acesso. Não converta uma intenção vaga, como “melhorar o atendimento”, em passos fictícios. Primeiro delimite uma tarefa e um resultado. Se o processo envolver decisão legal, médica, financeira, trabalhista ou de segurança, preserve a autoridade humana e peça os controles aplicáveis.

Não registre senhas, chaves, dados pessoais desnecessários nem exemplos identificáveis. Não suponha integração disponível. Uma ação externa pode ser descrita como dependência, com responsável e confirmação, mas não como algo que esta Skill já executou.

Siga o modelo de saída. Entregue objetivo e escopo, gatilho e término, contrato de entrada, fluxo numerado, matriz de decisões e exceções, contrato de saída, critérios de aceite, cenário comum, cenário de exceção, lacunas e próximo teste manual.

Cada passo deve indicar entrada consumida, transformação textual, decisão necessária, saída intermediária e próximo estado. Aponte claramente ações externas que não serão executadas. Consulte o exemplo como demonstração fictícia do nível de detalhe, sem transportar seus nomes ou regras para outro negócio.

1. Delimite uma tarefa e um resultado. Escreva uma frase com gatilho, trabalho textual e estado final observável. Retire objetivos amplos que exigiriam vários workflows. Confirme o que fica fora do escopo e não confunda resultado produzido com impacto de negócio futuro.
2. Reconstrua casos recentes. Percorra dois ou três casos anonimizados do início ao fim. Registre entradas realmente usadas, ordem dos passos, perguntas feitas, retrabalho e motivo de variação. Quando os relatos divergirem, preserve a divergência e indique quem tem autoridade para resolvê-la.
3. Separe texto, decisão humana e ação externa. Marque o que o agente pode redigir ou analisar, o que exige julgamento ou aprovação humana e o que dependeria de outro sistema. Nunca esconda envio, publicação, alteração de cadastro ou consulta privada dentro de um verbo genérico como “processar”.
4. Defina o contrato de entrada. Para cada campo, informe nome, finalidade, origem, formato aceito, obrigatoriedade, limite e tratamento de ausência. Rejeite credenciais e dados sem necessidade. Se uma entrada obrigatória faltar, o workflow deve perguntar ou parar, não fabricar um valor plausível.
5. Modele decisões, exceções e recuperação. Escreva condições observáveis no formato “se/então”. Para cada exceção, indique estado seguro, pergunta necessária, responsável conhecido e como retomar. Uma falha externa não autoriza repetir indefinidamente, contornar aprovação ou declarar sucesso.
6. Defina saída e aceite. Especifique campos, ordem, rótulos e critérios que uma pessoa pode conferir. Separe completude, sustentação e formato. Evite critérios subjetivos como “ficar excelente”; traduza-os em presença de fontes, limites, decisões e pendências.
7. Crie cenários comum e de exceção. O cenário comum percorre uma entrada válida até a saída aceita. O cenário de exceção deve ativar uma falta, conflito ou dependência indisponível e provar que o workflow para, pergunta ou bloqueia corretamente. Use dados fictícios e não alegue execução em agente.
8. Exponha somente responsáveis e lacunas conhecidos. Nomeie responsáveis apenas quando informados. Termine com decisões abertas, integrações não verificadas, riscos e o próximo teste manual. Não converta uma lacuna em dono inventado nem uma hipótese em regra operacional.

Pare sem concluir o workflow quando não houver um caso concreto, um gatilho de início, uma condição de término ou um resultado observável. Faça perguntas específicas sobre o elemento ausente. Se os casos se contradisserem e não houver autoridade informada, registre o conflito e não escolha uma versão.

Pare também diante de credenciais, dados privados desnecessários ou solicitação de executar sistemas externos. Você pode descrever a interface e o ponto de confirmação, mas não alegar conexão, envio ou teste. A entrega termina quando o workflow textual, os dois cenários e as lacunas estão explícitos. Para instalar a pasta e fazer um ensaio manual não sensível, consulte instalação.

Dois casos anonimizados mostram uma equipe recebendo um pedido textual por canal autorizado, comparando-o com uma política vigente e preparando um resumo para revisão humana. O início é a chegada do texto e da identificação interna não pessoal. O término é um resumo revisável com pendências. Uma exceção observada é a ausência da versão da política.

Objetivo: preparar um resumo sustentado; não responder nem alterar sistemas. Contrato de entrada: texto do pedido, finalidade, versão da política e formato do resumo. Se a versão faltar, perguntar e manter estado bloqueado.

Fluxo comum: validar campos, separar pedidos e contexto, relacionar cada conclusão a um trecho da política, listar pendências e entregar o resumo para aprovação. Critérios de aceite: todos os pedidos aparecem; conclusões apontam a fonte; nenhuma resposta foi enviada.

Cenário de exceção: a política chega sem versão. Resultado esperado: o workflow não escolhe uma versão, registra a lacuna e pede ao responsável informado a referência vigente. A retomada começa na validação da fonte. Dono da decisão: não informado no exemplo; permanece como lacuna.