A cena a seguir é típica e serve como exemplo, não é o relato de uma pessoa identificada. Alguém que revisa pull request todo dia foi ajustando, ao longo de semanas, um prompt de revisão de código até chegar num comentário que realmente ajuda o time. Um colega pede o texto, copia, cola no chat dele e recebe de volta algo morno: o código está legível, considere extrair funções em trechos longos. Mesmo prompt, resultado pior, e nenhum dos dois consegue dizer o que mudou.
Na maioria das vezes o problema não está no modelo. Está no que o prompt não diz. O texto não informava qual linguagem, qual padrão de projeto o time segue, o que deve ser apontado primeiro (falha de segurança, depois contrato de API, depois estilo) nem em que formato o retorno é útil. Nada disso precisava estar escrito enquanto o prompt vivia no chat de quem o criou, porque aquela conversa já tinha o repositório colado no início, as preferências corrigidas na segunda tentativa e os exemplos de comentário que deram certo três dias antes.
Esta é a nossa leitura do fenômeno: um prompt usado no próprio histórico se apoia em contexto que o autor já forneceu e deixou de enxergar. Ele lê o texto e vê um comando completo. O colega lê o mesmo texto e vê um pedido vago. O que sumiu na cópia foi justamente a parte que ninguém digitou de novo.
O formulário de envio faz as perguntas que o chat não faz
A Prompteira é um catálogo de prompts, não um modelo de IA nem um chat próprio. Quem compra ou baixa executa o texto na ferramenta que já usa. Isso muda o que precisa estar dentro do prompt: ele viaja sozinho, sem a conversa que o produziu. Por isso publicar tem quatro passos e leva cerca de 15 minutos, e cada passo cobra uma informação que costuma ficar subentendida.
O primeiro passo é escrever o template, com as entradas do usuário marcadas por chaves duplas. É aqui que a pessoa da nossa cena descobre quanta coisa no prompt dela era fixa por acidente. Linguagem, trecho de código e critério de revisão não eram decisões do prompt, eram informações que ela repetia na conversa. No template, viram campos: {{linguagem}}, {{trecho_de_codigo}}, {{criterios_de_revisao}}. A separação é simples de explicar e difícil de fazer na primeira tentativa: o que fica em texto fixo é a instrução, o que entra em chaves duplas é o que muda a cada uso. Quando essa divisão está clara, o colega sabe onde encaixar o caso dele, em vez de adivinhar qual parte deve reescrever.
O segundo passo é declarar os modelos em que o prompt foi de fato rodado. A declaração é obrigatória: prompt sem modelo informado não entra no catálogo. São 18 opções disponíveis, entre elas Claude Opus 5, Claude Sonnet 5, Claude Haiku 4.5, GPT-5, Gemini Pro, Midjourney v7 e FLUX. Repare no verbo: rodado, não imaginado. Se o prompt de revisão foi testado em um modelo e nunca em outro, é esse que vai na ficha. O mesmo texto pode se comportar de forma diferente em modelos diferentes, principalmente em tarefas que dependem de seguir uma ordem de prioridade ou devolver um formato estável. Declarar o modelo é dizer ao leitor onde existe evidência de uso, em vez de prometer que funciona em qualquer IA.
O terceiro passo é fornecer um exemplo de saída sem edição. Sem edição quer dizer o que o modelo devolveu, não a versão que você arrumou depois para ficar apresentável. Esse é o passo mais desconfortável e o mais útil, porque é nele que a lacuna aparece. Se a saída colada é um comentário genérico sobre legibilidade, o problema não estava no colega: estava no prompt. Quem publica costuma voltar ao template nesse momento e acrescentar o que faltava, por exemplo a ordem em que os achados devem vir e o tamanho esperado de cada observação.
O quarto passo é escolher entre gratuito ou premium, a decisão de publicação que fecha o envio. Nos três primeiros já está resolvido o que interessa a quem vai usar o prompt: o que é entrada, onde ele foi testado e como é o resultado cru.
Por que a ficha do prompt tem essas informações
No catálogo, cada prompt aparece com o modelo de IA usado, o nome do autor, a contagem de downloads e o tier. Não é enfeite de página. Quem chega a um prompt de Código e Dev precisa saber em qual modelo aquela pessoa rodou antes de decidir se o comportamento descrito tem chance de se repetir no ambiente dele. É a diferença entre receber um texto e receber um texto com a procedência informada.
A mesma revisão serve para quem não vai publicar nada
Os quatro passos funcionam como lista de verificação mesmo quando o destino do prompt é o canal interno do time. Antes de mandar, leia o seu texto fingindo que nunca conversou com aquele modelo sobre aquele assunto. Toda informação que você teria que explicar em voz alta para o colega entender o pedido está faltando ali dentro.
Na prática, são três perguntas. O que muda a cada uso e, portanto, deveria estar marcado como campo? Em qual modelo isso foi realmente testado, e o que você sabe sobre o resultado fora dele? Qual foi a última saída que esse prompt produziu, sem nenhum ajuste seu depois? Se a terceira resposta não existir, você ainda não tem um prompt pronto para compartilhar, tem um atalho pessoal que funciona por causa de tudo que ficou para trás na conversa.
Publicar apenas antecipa esse trabalho. O formulário não melhora o prompt sozinho: ele obriga o autor a escrever o que já sabia e nunca tinha precisado dizer.
