Escrevendo uma task

O trabalho principal de uma task é tirar ambiguidade. Um agente leva uma task até o fim quando o que significa "pronto" é inequívoco. Quando não é, o agente chuta, e você gasta a revisão descobrindo que ele chutou errado.

Esta página é sobre escrever a task de um jeito que isso não aconteça.

O que uma boa task carrega

O resultado, não a implementação. "As imagens de produto na PLP carregam devagar no mobile" é melhor que "adicione loading=lazy no grid da PLP". Você conhece o sintoma; o agente está em melhor posição para escolher a correção, e vai explicar o que escolheu.

Onde olhar. A página, a URL, o componente, a rota. Um agente que precisa primeiro achar o arquivo certo gasta o orçamento na busca em vez da correção.

Como você vai saber que funcionou. Os critérios de aceite. "LCP abaixo de 2,5s na PLP, medido no mobile" é verificável. "Deixar mais rápido" não é.

No que ele não pode mexer. Restrição é barata de escrever e cara de descobrir na revisão. Checkout, um script de terceiro, uma página no meio de campanha.

O que você não precisa escrever

Você não precisa escolher um agente, escolher um modelo nem descrever como o trabalho deve ser feito. Você declara o resultado e o sistema escolhe as habilidades e ferramentas.

Corrigindo no meio do caminho

Comente na task. O comentário é a superfície de controle: corrige o agente, acrescenta o contexto que faltava e dispara outra rodada. Você não precisa fechar a task e abrir outra porque a primeira tentativa errou.

Como a conversa fica na task, a próxima pessoa que abrir entende por que o trabalho ficou daquele jeito — inclusive a correção que você fez.

Quando voltar

Olhe primeiro o preview, não o diff. O preview é a mudança rodando; o diff é como ela foi obtida. Se o preview está certo e o diff está estranho, diga isso num comentário — é exatamente o tipo de correção que melhora a próxima rodada.