O método,
não a ferramenta.

Objetivo: resumir um atendimento para o sistema da empresa.

Contexto: conversa por chat com cliente fictícia "Mariana", 12 minutos: pedido #4821 de dois ventiladores chegou com um quebrado. Orientei tirar foto e enviar; foto recebida; abri troca; prazo informado de 5 dias úteis. Cliente perguntou se pode retirar na loja — respondi que sim, na unidade Centro.

Formato: 4 linhas no máximo, com campos Motivo, Ação, Próximo passo, Prazo.

Critério de pronto: quem pegar o chamado amanhã entende o que já foi feito sem ler a conversa inteira.

Antes de usar, confira: o prazo conta a partir de quando (abertura da troca?) e se a unidade tem o item em estoque antes de confirmar retirada.

Testado em 26/10: saiu o resumo em 4 campos e a IA avisou duas suposições que fez (início do prazo, checagem de estoque) — sinal de que pediu para eu conferir.

Objetivo: responder uma cliente irritada por atraso na entrega.

Contexto: cliente "Sônia" comprou uma cadeira na segunda, prazo de 3 dias úteis, hoje é o 5º dia útil sem atualização no rastreio. Política da empresa: atraso acima de 2 dias úteis dá frete grátis no próximo pedido. Não tenho como acelerar a transportadora.

Formato: mensagem de WhatsApp, no máximo 6 linhas, direta, sem juridiquês.

Critério de pronto: reconhece o problema sem culpar a transportadora abertamente, diz o que farei agora e quando volto a falar com ela, oferece o que a política permite.

Antes de usar, confira: o horário que você promete retornar (tem que ser um que você cumpre) e se você realmente consegue acionar a logística — senão troque o verbo.

Testado em 26/10: resposta pronta + lembretes: não prometer data de entrega nem reembolso (não dependem de mim), e o frete grátis só vale depois de 2 dias úteis de atraso.

Objetivo: classificar chamados da semana por motivo.

Contexto: lista fictícia de 10 chamados de uma loja de móveis: 4 sobre prazo de entrega, 3 sobre troca/devolução, 2 sobre montagem agendada, 1 sobre nota fiscal. Quero ver se há um motivo dominante.

Formato: tabela Motivo | Quantidade, ordenada do maior para o menor, e 1 linha apontando o motivo dominante.

Critério de pronto: a soma das quantidades é 10 e cada chamado entra em um único motivo.

Antes de usar, confira: a soma bate com o total e nenhum chamado entrou em dois motivos (o critério de pronto pede isso).

Testado em 26/10: tabela correta somando 10, e a IA lembrou que "4 de 10 é pluralidade, não maioria" — cuidado com conclusão apressada.

Objetivo: montar um roteiro para ligar e confirmar uma entrega atrasada.

Contexto: ligação para cliente fictícia "Helena", pedido #5017, sofá, 4 dias de atraso. Ela já abriu um chamado reclamando. Tenho 3 minutos de ligação.

Formato: roteiro com abertura, 2 perguntas essenciais e fechamento com próximo passo e prazo, em tópicos.

Critério de pronto: nenhum tópico depende de promessa que eu não possa cumprir; o cliente termina sabendo o que acontece depois.

Antes de usar, confira: o status real do pedido e o que você pode prometer (data confirmada? só retorno?) antes de discar — o roteiro da IA vai depender disso.

Testado em 26/10: roteiro com "antes de discar" (conferir status, definir o que pode prometer), abertura de 30 s e 2 perguntas que evitam nova falha de entrega.

Objetivo: escrever um artigo curto para a base de conhecimento da equipe.

Contexto: política fictícia de troca da loja: 7 dias corridos para troca com nota fiscal; sem nota, vale crédito na loja pelo menor preço dos últimos 30 dias; eletrônicos lacrados só trocam se estiverem com defeito; troca por defeito em até 90 dias é obrigação legal.

Formato: artigo de no máximo 15 linhas, com seção "como atender" passo a passo.

Critério de pronto: um atendente novo consegue seguir sem perguntar para o supervisor; nenhuma regra inventada além das que passei.

Antes de usar, confira: as lacunas que a IA vai apontar — início da contagem dos 7 dias, o que fazer com nota fiscal fora do prazo, prazo do crédito sem nota. Responda e peça para incluir.

Testado em 26/10: artigo de 14 linhas só com as regras passadas, e a IA listou as 3 lacunas da política em vez de inventar resposta — exatamente o que o critério de pronto pedia.

Objetivo: escrever a resposta padrão para a pergunta mais frequente do chat.

Contexto: pergunta "quanto tempo demora a entrega?" aparece 40% das conversas. Prazos fictícios: capitais 3 dias úteis, interior 5 a 8, com código de rastreio no e-mail em até 24h após o envio.

Formato: resposta de 4 linhas com as duas faixas de prazo e onde ver o rastreio.

Critério de pronto: funciona para as duas faixas de prazo sem eu editar; não promete data exata de chegada.

Antes de usar, confira: de onde contam os dias úteis (compra, pagamento ou envio?) e se o e-mail traz o link ou só o código.

Testado em 26/10: 4 linhas prontas para as duas faixas, e a IA perguntou justamente as duas confirmações acima antes de dar o texto como final.

Objetivo: revisar minha resposta antes de enviar para um cliente.

Contexto: cliente pediu cancelamento de um pedido que já foi separado no estoque. Minha resposta: "Infelizmente não dá mais, o sistema não permite cancelamento depois da separação. O senhor pode recusar a entrega quando chegar." A regra real da empresa: cancelamento é possível até a separação; depois, recusar a entrega gera estorno em até 7 dias úteis.

Formato: lista do que está bom e do que mudar, com a versão corrigida.

Critério de pronto: a versão corrigida explica o caminho do estorno e o prazo, sem "infelizmente" e sem culpar o sistema.

Antes de usar, confira: se o estorno inclui o frete e se há algum passo além de recusar ao entregador (protocolo, aviso) — a IA vai perguntar.

Testado em 26/10: 6 ajustes de tom e clareza, versão corrigida pronta, e a pergunta do frete apareceu como "ponto a confirmar antes de enviar".

Objetivo: traduzir uma mensagem de erro do sistema para a linguagem do cliente.

Contexto: cliente viu na tela: "Erro 402-PG: timeout na autorização de pagamento — gateway indisponível. Tente novamente." Ele perguntou se foi cobrado duas vezes.

Formato: explicação em 3 linhas, linguagem simples, sem termo técnico.

Critério de pronto: o cliente entende que provavelmente não foi cobrado e o que fazer; sem prometer reembolso imediato.

Antes de usar, confira: o fluxo de estorno para cobrança indevida na sua empresa (a IA não deve prometer "some sozinho" sem isso definido).

Testado em 26/10: explicação em 3 linhas sem juridiquês; falou em "reserva temporária" em vez de garantir, e condicionou o estorno ao comprovante.

Objetivo: preparar uma pauta de 1:1 com um colaborador.

Contexto: Paulo, analista de suporte, 14 meses na equipe. Mês: 96% dos chamados no prazo, 1 reclamação de cliente sobre o tom, e ele pediu para falar sobre virar pleno. Última conversa foi há 1 mês, sobre autonomia.

Formato: pauta em tópicos: 1 ponto de reconhecimento com dado, 1 ponto de atenção com exemplo, 3 perguntas sobre o pedido de promoção.

Critério de pronto: toda afirmação vem de fato observável, não de impressão; a pauta cabe em 1 página.

Antes de usar, confira: a meta da equipe e a média dele nos meses anteriores — sem essa referência, o "96%" não diz se foi bom. Leve o trecho exato do chamado reclamado.

Testado em 26/10: pauta de 45 min com tempo por bloco; a IA recusou afirmar padrão de tom com 1 caso só e pediu o texto do chamado antes de opinar.

Objetivo: escrever um feedback estruturado para um colaborador.

Contexto: Marina, analista, entregou o relatório de fechamento com 2 dias de atraso e sem a aba de devoluções. É a segunda vez no trimestre. Ela é boa na análise, mas o atraso fez o time trabalhar no fim de semana.

Formato: feedback em 3 blocos: Situação, Comportamento, Impacto, e uma pergunta para ela responder.

Critério de pronto: descreve o que aconteceu sem julgar a pessoa; separa o padrão (2 vezes) do incidente; termina com diálogo, não com sermão.

Antes de usar, confira: as datas reais e se ela avisou do atraso — o feedback muda se ela avisou. Preencha os colchetes que a IA vai deixar.

Testado em 26/10: blocos Situação/Comportamento/Impacto com "incidente × padrão" separados, e terminou com pergunta aberta ("o que teria facilitado me avisar?").

Objetivo: transformar os números da semana em um relatório semanal.

Contexto: semana fictícia da operação de atendimento: 312 chamados, 91% resolvidos no primeiro contato, tempo médio 5min48, 12 reclamações (8 sobre prazo de entrega), satisfação 4,4/5. Semana anterior: 298 chamados, 89%, 6min10, 9 reclamações, 4,5/5.

Formato: máximo 12 linhas, com seções Destaques e Pontos de atenção, cada ponto com o número que sustenta.

Critério de pronto: nenhum número sem comparação ou contexto; os pontos de atenção apontam causa provável, não culpa.

Antes de usar, confira: cada número na planilha fonte antes de apresentar — a "causa provável" das reclamações é hipótese, não fato.

Testado em 26/10: relatório com todo número comparado à semana anterior; a IA marcou explicitamente o que era causa provável não confirmada.

Objetivo: priorizar a lista de tarefas da semana.

Contexto: 8 tarefas fictícias: (1) responder e-mail de fornecedor, 10 min, baixo impacto; (2) corrigir erro no relatório que a diretoria vê amanhã, 40 min, alto impacto; (3) reorganizar pastas do drive, 60 min, baixo; (4) treinar estagiário no sistema, 90 min, médio impacto e prazo sexta; (5) aprovar 3 orçamentos, 20 min, alto impacto e prazo hoje; (6) reunião de alinhamento, 60 min, médio; (7) atualizar planilha de metas, 30 min, médio; (8) responder cliente importante, 15 min, alto.

Formato: tabela Prioridade | Tarefa | Por quê, e a ordem sugerida de execução.

Critério de pronto: prioriza por impacto e prazo, não por tamanho; nada é descartado, só ordenado.

Antes de usar, confira: os prazos e horários fixos reais (a IA não conhece sua agenda — reuniões fixas mandam no calendário).

Testado em 26/10: priorizou por impacto/prazo (orçamentos > relatório da diretoria > cliente) e deixou "reorganizar pastas" para o fim — não por tamanho, por impacto.

Objetivo: analisar uma planilha de vendas e achar padrões.

Contexto: tabela fictícia de vendas da semana por dia (segunda a domingo): seg 42, ter 45, qua 39, qui 41, sex 78, sáb 96, dom 84. A meta diária era 50.

Formato: 5 linhas: o padrão principal, o que chama atenção, 2 hipóteses possíveis, 1 pergunta para investigar.

Critério de pronto: separa fato de hipótese; não inventa causa sem dado.

Antes de usar, confira: se o padrão se repete nas semanas anteriores antes de agir — uma semana não prova padrão.

Testado em 26/10: achou a divisão seg–qui × sex–dom (venda ~2x no fim de semana) e separou claramente fato de hipótese, pedindo as semanas anteriores para confirmar.

Objetivo: escrever um comunicado de mudança de processo para a equipe.

Contexto: a partir de segunda, todo reembolso acima de R$ 200 passa a precisar de aprovação da supervisão, antes de ser lançado. Motivo: erro de digitação gerou 3 reembolsos errados no mês. A equipe tem 9 pessoas.

Formato: comunicado de no máximo 8 linhas: o que muda, a partir de quando, por quê, e onde tirar dúvida.

Critério de pronto: quem ler entende o que muda na prática sem reler; o tom é direto, sem culpar ninguém.

Antes de usar, confira: a data de início (a IA vai supor) e o canal de dúvidas antes de enviar.

Testado em 26/10: comunicado de 5 linhas sem citar quem errou; a IA deixou marcados exatamente os dois pontos para eu confirmar (data, canal).

Objetivo: montar um plano de ação para uma queda de resultado.

Contexto: as vendas da loja caíram 18% no mês. Fatos conhecidos: uma obra na rua reduziu o movimento; dois vendedores saíram e não foram repostos; o concorrente abriu promoção. Não há dado sobre satisfação no período.

Formato: tabela com Hipótese | Como verificar | Primeira ação, e 1 linha de decisão final.

Critério de pronto: toda hipótese tem um jeito de verificar; nenhuma ação é tomada antes de verificar.

Antes de usar, confira: o dado de verificação existe na sua operação (fluxo de entrada, conversão, ticket) — se não, a hipótese fica sem teste.

Testado em 26/10: cada hipótese veio com verificação e com a ação condicionada à confirmação — a IA se recusou a agir antes de verificar.

Objetivo: resumir uma atualização longa para meu superior em 5 linhas.

Contexto: texto fictício de 20 linhas sobre a semana da operação: atraso do fornecedor de embalagens, três pedidos grandes em negociação, dois funcionários de férias na próxima semana, meta do mês em 71%, sistema de ponto com falha na quarta, reunião com o comercial marcada para sexta.

Formato: 5 linhas no máximo, começando pela conclusão, depois o que precisa de decisão do superior.

Critério de pronto: o superior sabe o que decidir sem ler o texto original; nada de detalhe que não mude decisão.

Antes de usar, confira: as alçadas da sua empresa (quem decide o quê) — a IA vai propor decisões e você ajusta ao seu contexto.

Testado em 26/10: 5 linhas com conclusão primeiro, 3 decisões propostas e o detalhe sem decisão (falha do ponto) corretamente deixado de fora.

Objetivo: implementar uma mudança pequena e delimitada em uma função de desconto.

Contexto: função atual (fictícia): desconto de 5% para pedidos acima de R$ 200. Nova regra: pedidos acima de R$ 500 ganham 10%, e os demais continuam com 5%. A regra vale para pedidos aprovados, não para orçamentos.

Formato: código da função nova, uma lista de casos de teste com entrada e resultado esperado, e o que pode quebrar.

Critério de pronto: a função velha continua coberta pelos mesmos testes; a mudança não altera o comportamento de pedidos abaixo de R$ 500.

Antes de usar, confira: as suposições que a IA declarar (o que acontece abaixo de R$ 200? e com orçamentos?) — ela avisa, mas a resposta é sua.

Testado em 26/10: código com os tiers corretos e casos de teste novos só para a faixa nova; a IA listou 2 suposições antes de entregar.

Objetivo: revisar um diff antes de aprovar o merge.

Contexto: diff fictício em uma função de cálculo de frete. Mudança: adicionou taxa de R$ 12 para pedidos abaixo de R$ 100 e mudou a variável de peso de gramas para quilos, dividindo o valor por 1000. Suspeito que há um erro de unidade.

Formato: lista de problemas, cada um com a linha e o porquê, separando bloqueador de sugestão.

Critério de pronto: cada problema é reproduzível a partir do diff; nenhum estilo sem impacto listado como bloqueador.

Antes de usar, confira: o diff tem que ir colado no prompt. Sem ele, a revisão não é revisão — é hipótese. A IA vai dizer isso, e está certa.

Testado em 26/10: sem o diff, a IA se recusou a apontar linhas e devolveu 3 hipóteses reproduzíveis (divisão no lugar errado, divisão inteira, faixas em gramas). Com o diff colado, vira lista com linha.

Objetivo: gerar os casos de teste de uma regra de negócio.

Contexto: regra fictícia de prazo de entrega: capitais até 3 dias úteis; interior 5 a 8; pedidos com montagem ganham 2 dias a mais; feriados não contam; prazo começa no dia útil seguinte à aprovação do pagamento.

Formato: tabela de casos de teste: Situação | Entrada | Resultado esperado, cobrindo cada regra e as bordas.

Critério de pronto: um caso para cada regra, um caso de fronteira (ex.: pedido com e sem montagem no mesmo CEP) e um caso inválido.

Antes de usar, confira: as premissas que a IA declarar (dia útil = seg–sex?, "interior 5 a 8" vem de onde?) com quem definiu a regra.

Testado em 26/10: tabela completa com regras base, fronteiras e casos inválidos; a IA declarou 3 premissas que a regra não fechava antes de gerar os casos.

Objetivo: explicar um trecho de código legado que ninguém documentou.

Contexto: função fictícia em Python que calcula o prazo de entrega: consulta a tabela de CEPs, aplica regras de capital/interior, soma dias de montagem, e no final subtrai 1 se o dia da aprovação for sexta. O time não sabe por que o "-1 se sexta".

Formato: explicação em linguagem simples, linha a linha, e uma hipótese sobre o "-1", marcada como hipótese.

Critério de pronto: alguém que não programa entende o que a função faz; a hipótese não vira fato no texto.

Antes de usar, confira: a hipótese do "-1" no histórico do git (blame/log) antes de mexer ou documentar como fato.

Testado em 26/10: explicação linha a linha em linguagem simples e a hipótese do "-1" claramente marcada como não confirmada.

Objetivo: investigar um erro em produção antes de mexer no código.

Contexto: erro fictício no log: "TimeoutError: falha ao conectar no serviço de pagamento após 10s" às 18h42 de sexta, em 34 pedidos seguidos; o serviço de pagamento respondeu normal às 18h45. Primeira vez que aparece.

Formato: 3 hipóteses ordenadas da mais provável para a menos, com o comando ou a consulta que confirma ou descarta cada uma.

Critério de pronto: nenhuma correção de código é proposta antes da hipótese ser confirmada.

Antes de usar, confira: adapte os comandos ao seu ambiente (a IA supõe stack; o critério de pronto segura a correção prematura).

Testado em 26/10: 3 hipóteses ordenadas com comando de verificação para cada uma; a IA se recusou a propor correção antes de confirmar.

Objetivo: escrever título e descrição de um pull request.

Contexto: mudança fictícia: a tela de pedidos ganhou filtro por status e a consulta ao banco passou a usar paginação, reduzindo o tempo de resposta de 4s para 0,8s nos testes.

Formato: título de no máximo 70 caracteres, descrição em 4 linhas: o que mudou, por quê, como testar, o que não mudou.

Critério de pronto: alguém que não viu o código decide se quer revisar; o número de desempenho aparece como medida de teste, não como promessa.

Antes de usar, confira: o número de desempenho é do seu ambiente de teste — escreva "medido em [ambiente]" para não virar promessa de produção.

Testado em 26/10: título e descrição prontos, com o 4s→0,8s apresentado como medição local, não garantia.

Objetivo: refatorar uma função sem mudar o comportamento.

Contexto: função fictícia de cálculo de frete com 90 linhas, vários condicionais aninhados e nomes de variáveis como a, b, tmp. Ela tem testes passando e eu não quero quebrar nada.

Formato: versão refatorada, lista do que mudou e por quê, e a lista de testes que devem continuar passando.

Critério de pronto: o comportamento é o mesmo para as mesmas entradas; a versão nova não adiciona regra nova.

Antes de usar, confira: rode os testes atuais antes de começar (baseline) — e cole a função e os testes no prompt, senão a IA vai recusar refatorar código que não viu.

Testado em 26/10: a IA se recusou a refatorar sem o código colado e descreveu o processo certo: baseline → testes de caracterização → passos pequenos com teste a cada passo.

Objetivo: quebrar um requisito em tarefas pequenas.

Contexto: requisito fictício: "o cliente quer acompanhar o pedido pelo site: ver status, ver código de rastreio e cancelar antes da separação." O time é pequeno e cada tarefa não pode passar de 1 dia.

Formato: lista de tarefas de no máximo 1 dia cada, ordenada, com o critério de pronto de cada uma.

Critério de pronto: nenhuma tarefa depende de uma decisão de negócio não tomada sem avisar; a primeira tarefa já entrega valor visível.

Antes de usar, confira: as decisões de negócio que a IA separar (quais status o cliente vê? cancelamento por item entra?) — decidir antes de codar evita retrabalho.

Testado em 26/10: separou 5 decisões de negócio das tarefas, marcou 2 como bloqueantes e colocou como primeira tarefa a página só-leitura que já entrega valor.