Prompts

Traduza o texto abaixo para português do Brasil. Mantenha termos, código e nomes próprios. Dê a tradução primeiro, depois liste três mudanças e por que você as fez. Marque o que não tiver certeza. Não invente. {texto}

Você é o entrevistador do cargo {cargo}. Faça uma pergunta por vez. Depois da minha resposta, aponte o que eu deixei passar e faça a próxima. Depois de 8 perguntas, dê um parecer curto para este cargo: aprovado, em espera ou reprovado, com a base.

Revise a mudança abaixo. Liste só problemas que a deixem errada, lenta ou difícil de manter. Em cada um, diga o arquivo, a gravidade (alta, média, baixa) e a correção. Não reescreva o arquivo inteiro. Se não houver problema, escreva que não há.

Transforme as anotações soltas abaixo num relatório semanal. Divida em: feito nesta semana, não feito e o motivo, três itens da próxima semana. Uma frase cada e mantenha os números. Não escreva como autoavaliação.

Com os nomes de coluna abaixo, escreva uma fórmula de Excel para concluir: {tarefa}. Escreva a fórmula primeiro e calcule o resultado com duas linhas de exemplo. Se precisar usar outra coluna, diga antes. Não use coluna que eu não tenha dado.

Responda com SQL padrão: {pergunta}. A estrutura das tabelas está abaixo. Escreva a consulta primeiro e diga de quais tabelas ela depende. Não invente colunas que não existem. Se a pergunta estiver vaga, me faça uma pergunta antes.

Escreva um regex de JavaScript que combine com: {deveCombinar}. Não combine com: {naoDeveCombinar}. Dê a expressão e depois dois exemplos que passam e dois que falham.

Explique o código abaixo para quem acabou de assumir o repositório. Primeiro diga em três frases o que ele faz e depois siga a ordem de execução. Marque entradas, saídas e onde falha. Não altere o código.

Escreva uma mensagem de commit para o diff abaixo. A primeira linha tem no máximo 72 caracteres e diz o que mudou. Depois de uma linha em branco, diga por quê. Não escreva frase vazia como "update" ou "fix bug".

Faça esta mudança: {tarefa}. Mexa só nas linhas necessárias para concluí-la. Não aproveite para formatar, renomear ou reescrever o código ao lado. Ao terminar, indique os arquivos que você alterou e como verificar que o comportamento não mudou.

O defeito é: {sintoma}. Primeiro escreva os passos ou o teste que o reproduz. Não altere o código do produto antes de reproduzir. Depois da reprodução, faça a menor alteração e explique por que essa é a causa.

Para {comportamento}, escreva primeiro um teste que falha. Mostre a saída da falha e depois escreva a implementação que o faz passar. Não comece pela implementação. Depois que passar, não acrescente o que eu não pedi.

Leia primeiro os arquivos ligados a {tarefa}. Liste os fatos que você viu e o que ainda não está certo. Neste passo não altere arquivo. Só altere depois que eu confirmar.

Ainda não escreva código. Para {objetivo}, dê um plano curto: arquivos a alterar, o que não fazer e como saber que acabou. Se houver dois caminhos igualmente razoáveis, pare e pergunte qual eu quero.

Leia o diff abaixo e procure só problemas de segurança: injeção, acesso indevido, segredo no repositório e desserialização insegura. Em cada um, dê o arquivo e como é disparado. Se não houver, escreva que não há. Não comente estilo fora do assunto.

Escreva 5 titles e 5 meta descriptions para esta página. A página fala de: {tema}. Cada title tem no máximo 60 caracteres e cada description no máximo 160. Cada um inclui palavras que a pessoa buscaria. Não empilhe palavras-chave.

Escreva a primeira tela de {produto}: um resultado, um texto de no máximo 40 caracteres e um botão. O botão diz o que o clique abre. Sem slogan e sem três pontos de venda lado a lado.

Reescreva o texto abaixo para soar como alguém falando com uma pessoa específica. Corte frase vazia e paralelismo. Mantenha todos os fatos, números e caminhos de arquivo. No fim, liste os clichês que você tirou.

Crie 10 títulos para o texto abaixo. Cinco dizem o resultado direto e cinco trazem um detalhe concreto. Não use "chocante", "definitivo" nem "empoderar". Cada título tem no máximo 22 caracteres.

Escreva 3 anúncios curtos para {produto}. Cada um mira um comprador e uma coisa. Diga quem é o comprador, o problema que ele tem agora e o que o clique entrega. Não empilhe adjetivos.

Escreva uma nota do Xiaohongshu sobre {tema}. A primeira linha é o título. O corpo tem no máximo 300 caracteres, inclui um detalhe concreto de uso e termina com uma pergunta. Não use "家人们" nem "绝绝子". Indique 3 imagens que combinam.

Responda ao e-mail abaixo. Na primeira frase, responda ao pedido. Depois diga o que você precisa que a pessoa faça e, por fim, dê um prazo. Seja direto. Não use "espero que este e-mail te encontre bem".

Transforme o registro da reunião abaixo em ata. Deixe só decisões, responsáveis, prazos e questões em aberto. Corte a discussão. Marque à parte o item sem responsável.

O cargo alvo é {cargo}. Reescreva a experiência abaixo em 5 pontos de currículo. Cada um começa com um verbo e traz um número ou um artefato. Corte o que o cargo não precisa. Não invente experiência que eu não tenha escrito.

Os requisitos do cargo estão acima e o material do candidato abaixo. Liste os requisitos que ele atende, os que não atende e os que o material não menciona. Não suponha personalidade. No fim, diga se marca a entrevista ou não, com a base.

Monte 3 dias em {cidade}. Cada dia tem uma coisa de manhã, uma à tarde e uma à noite, e diga como ir de um lugar ao outro. Marque o que precisa de reserva. Não inclua compras que eu não pedi. O orçamento é {orcamento}.

Com a premissa abaixo, escreva um conto de no máximo 800 caracteres: {premissa}. Um protagonista, uma coisa a concluir e uma mudança no fim. Sem capítulos e sem lição de moral.

Transforme o enredo abaixo numa cena: {enredo}. Escreva só o título da cena, a ação e o diálogo. O diálogo tem de poder ser falado. Sem jargão de câmera e sem pensamento do personagem.

A tese é: {tese}. Primeiro os três pontos mais fortes a favor e depois os três mais fortes contra. Cada ponto em uma frase, mais o fato de que depende. No fim, não declare um vencedor.

Me ensine {tema}. Primeiro explique o núcleo com um exemplo concreto e depois me dê duas perguntas. Não comece a seção seguinte antes de eu responder. Se eu errar, aponte só o passo que falhou.

Quero entender {pergunta}. Não dê a resposta direto. Faça uma pergunta por vez que reduza o escopo. Espere eu responder antes da próxima. Só explique quando eu disser "dê a resposta".

Leia o artigo abaixo. Resuma em 8 frases: problema, método, dados, resultado e os limites que os próprios autores escreveram. Depois de cada frase, marque entre parênteses de qual seção ela veio. Não acrescente o que o artigo não diz.

Compare {opcaoA} e {opcaoB} para fazer {objetivo}. Faça uma tabela: custo, o que precisa mudar e o que acontece se falhar. Cada célula precisa de uma base. Se a base não bastar, escreva desconhecido. Não chute.

Olhe a interface abaixo. Comente só hierarquia, espaçamento, área de clique e foco. Liste três mudanças. Em cada uma, diga o problema de agora e como fica depois. Não troque o estilo visual inteiro.

Escreva um prompt de imagem para {assunto}. Deixe claro o que está no quadro, a luz, o enquadramento e o que não pode aparecer. Um parágrafo, sem pilha de palavras-chave. Faça 2 versões: uma quadrada e uma horizontal.

Proponha 12 nomes para {produto}. Cada nome tem de servir de domínio: curto, pronunciável e sem hífen. Evite palavra genérica já gasta. Depois de cada nome, uma frase sobre o que ele aponta.

O que eu quero dizer é: {frase}. Primeiro dê uma versão mais natural e depois marque o problema original (escolha de palavra, ordem ou tom). Depois dê uma versão mais curta para eu repetir.

Preciso fazer isto em {sistema}: {tarefa}. Liste os comandos a executar, um por linha, e diga o que cada um altera. Não finja que você é o terminal. Antes de um comando destrutivo, pare e me pergunte.

Leia o JavaScript abaixo. Na ordem de execução, liste o que cada console imprime. Se lançar erro, escreva o tipo do erro e em qual linha. Não altere o código, a menos que eu peça em seguida para você corrigir.

Divida {sistema} em módulos. Para cada um, escreva o que ele cobre, o que não cobre e uma interface que expõe. No máximo 6 módulos. Não escreva o código da implementação.

Leia o material abaixo. Escreva um resumo de no máximo 40 caracteres. Depois liste as ideias que o texto de fato afirma, no máximo 8. Cite só frases que aparecem no original, no máximo 5. No fim, um aprendizado. Se uma parte não tiver conteúdo, escreva "nenhum". Não invente citação. {material}

Leia o git diff abaixo e escreva em Markdown uma descrição de pull request com estas seções: Resumo, Arquivos alterados, Motivo, Impacto, Plano de teste. Para cada arquivo, diga o que mudou. Se o diff não mostrar teste, escreva que o plano de teste está ausente. Não reescreva o código.

Leia o log abaixo. Liste anomalias e problemas que se repetem. Em cada um, cite a linha ou o horário que o sustenta. Depois escreva só mudanças que o próprio log sustenta. Se a causa não estiver no log, diga isso. Não corrija com chute de fora do arquivo.

Transforme esta nota de produto num PRD em Markdown, com estas seções: Visão geral, Objetivos, Público, Funções, Requisitos funcionais, Requisitos não funcionais, Métricas de sucesso. Cada requisito tem de poder ser verificado. O fato que faltar, escreva "desconhecido". Não acrescente função que a nota não menciona. {nota}

Escreva uma história de usuário para {funcionalidade}. Use três linhas: Como {papel} / Eu quero / Para que. Depois liste em itens simples os critérios de aceite que um teste consegue conferir. Não escreva uma segunda história. Não inclua critério sem base na nota. {nota}

Escreva uma nota de design para {sistema}. Use estas seções: Objetivo de negócio, Contexto, Contêineres, Implantação, Riscos, Perguntas e premissas. Contexto, Contêineres e Implantação recebem cada um um diagrama mermaid e uma tabela com nome, tipo e responsabilidade. Na segurança, escreva só os controles que a descrição já afirma. Se não houver, escreva que não foi especificado. Não descreva como atacar este sistema. {descricao}

Leia o plano Terraform abaixo. Em uma frase, diga o que vai mudar. Depois liste as criações, atualizações e destruições que importam. Liste mudança de custo e de acesso só quando o texto do plano mostrar. Se não houver custo, escreva "custo não mostrado". Não invente preço nem escreva passos de ataque.

Leia o diff abaixo. A primeira linha tem no máximo 100 caracteres, no presente, com um destes prefixos: feat, fix, docs, refactor, test ou chore. Depois no máximo 6 itens. Cada item é uma frase curta no presente sobre uma mudança de comportamento. Pule arquivos que só movem espaço em branco.

Leia o argumento abaixo. Para cada passo que não se sustenta, diga em linguagem simples que falácia é, cite a frase e explique por que esse passo não prova a conclusão. Um passo fraco não torna a conclusão falsa. Se o argumento se sustenta, escreva que se sustenta. Não liste falácia que o texto não usa.

Reescreva o prompt abaixo para um modelo conseguir seguir. Mantenha a mesma tarefa. Acrescente o formato da saída, o tamanho, o que não escrever e um espaço reservado para a entrada. Coloque a entrada num bloco marcado com clareza. Não adicione uma persona. Devolva só o prompt reescrito. {prompt}

Escreva um relatório de defeito para {sintoma}. Campos: Título, Ambiente, Passos, Esperado, Real, Gravidade. O título nomeia o componente, a ação e o sintoma. Os passos são numerados e curtos. A gravidade é crítica, alta, média ou baixa, com o impacto em quem usa. O campo que eu não dei, escreva "desconhecido". Não proponha correção de código.

Para {comportamento}, escreva um plano de teste em três grupos: unidade, integração e ponta a ponta. Cada caso é uma frase no formato dado / quando / então e verifica uma só coisa. A maioria fica em unidade. No máximo 2 casos ponta a ponta, e só de um caminho que uma pessoa percorre. Não escreva código de teste. Não use espera fixa.

Transforme {funcionalidade} em requisitos que um teste consiga conferir. Cada linha usa um destes formatos: QUANDO [evento], O SISTEMA DEVE [comportamento]; ENQUANTO [estado], O SISTEMA DEVE [comportamento]; SE [condição indesejada], O SISTEMA DEVE [resposta]. Depois liste os limites que a nota ainda não cobre e marque cada um como "proposto". Não escreva design nem código.

Registre uma decisão sobre {escolha}. Seções: Decisão, Contexto, Opções, Motivo, Impacto, Quando rever. As opções são só as que eu nomeei. Se eu nomeei só uma, escreva que as alternativas não foram dadas. O motivo deixa a troca explícita. Quando rever diz o que nos faria reabrir a decisão. Não invente uma métrica.

Leia o diff abaixo. Liste só os documentos que o leitor precisaria atualizar: README, registro de mudanças, referência de API, exemplo de configuração ou nota de migração. Em cada um, diga a seção e o fato no diff que o deixa desatualizado. Se o diff não tiver mudança que o usuário notaria, escreva que não precisa atualizar documento. Não rascunhe função que o diff não contém.

Primeiro vêm os exemplos e depois a entrada nova. A resposta usa o mesmo formato dos exemplos. Use só rótulos que aparecem nos exemplos. Se a entrada nova não encaixar em nenhum, escreva "não encaixa" e aponte o exemplo mais próximo. Não invente rótulo. {exemplos} Entrada nova: {entrada}

Responda {pergunta} com três métodos diferentes. Cada caminho tem no máximo 80 caracteres e termina com "Resposta:". Depois diga se as três respostas concordam. Se concordarem, dê essa resposta. Se não, liste o desacordo. Não junte as três num número novo.

Escreva sobre {tema}. Use só estas seções, nesta ordem: {secoes}. O texto todo não passa de {limite} caracteres. Se uma seção precisar de um fato que eu não dei, escreva "desconhecido" ali. Não acrescente seção, slogan nem fato que eu não escrevi.

Escreva sobre {tema}. Nada disto pode aparecer: {exclusao}. Não nomeie esses itens e não os descreva com outro nome. Depois apague qualquer frase que ainda toque a lista. Se não sobrar nada, escreva que a exclusão tirou a resposta.

Encontre um skill que transforme um esboço em Markdown em PPT e instale.

Use Grill Me para questionar este plano de migração. Não pule a reversão, o volume de dados nem a falta de responsável.

Refaça esta página inicial de marketing segundo Frontend Design. Sem degradê roxo e sem fileira de três cartões de função.

Abra o console de pré-produção, entre com a conta das variáveis de ambiente e liste as tarefas que falharam na última hora.

Audite src/app/dashboard/page.tsx com as práticas de React da Vercel e corrija primeiro os três itens de maior impacto.

Verifique esta página de destino com as Web Design Guidelines e liste o que falha, com o caminho do arquivo.

Escreva um skill que transforme uma issue do GitHub num plano de implementação com teste primeiro.

Una estes três PDFs, grave um título de documento de verdade e extraia a tabela da página 4.

Transforme esta página de texto em 10 slides para investidores. Deixe um só ponto em cada slide.

Una estes três CSVs por sku, remova as linhas duplicadas e grave inventory.xlsx.

Projete um servidor MCP para a nossa API interna de chamados. No máximo três ferramentas. Mostre o schema primeiro.

O total do pagamento só erra em euro. Diagnostique primeiro. Não faça a correção antes de conseguir reproduzir.

Proponha um mapa de módulos para esta pasta billing. Nomeie as costuras e os testes que cada uma precisa.

Modele os reembolsos desta loja. Antes de escrever uma função, liste os pares de estado ilegais.

Compare Agent Skills e MCP num agente de código. Cite os documentos originais. Marque o que ainda não está claro.

Edite este README. Tire as marcas de IA. Comandos e caminhos de arquivo ficam exatamente como estão.

Me ensine Astro Content Collections. Faça um teste antes da próxima aula. Salve o progresso em ./notes.

Lembre que usamos trailingSlash never e que o idioma padrão é inglês. Grave nas notas do agente.

Reescreva este componente na API de composição do Vue 3. Alinhe à versão local do vue. Sem Vuex.

Audite /guides/install-agent-skills quanto ao tamanho do título, ao canonical e a ter um único h1.

Reescreva a primeira tela. Um só resultado. Sem frase vazia. O botão tem de dizer o que o clique abre.

Transforme este esboço num informe em Word: use estilos de título, acrescente capa e deixe comentários nas questões em aberto.

Suba o servidor de desenvolvimento e teste o fluxo de finalização da compra com Playwright: uma passagem com carrinho vazio e outra com usuário logado.

Adicione uma tabela orders e use RLS para o usuário ver só as próprias linhas. Mostre a migração e as políticas.

Refatore esta página de configurações em componentes compostos. Não passe theme e title por cinco camadas.

Faça a tela de perfil com Expo. A lista de publicações usa FlatList. Sem arranjo de div que só serve na web.

Adicione Checkout para uma compra única. Verifique a assinatura do Webhook e grave o estado do pagamento de forma idempotente.

Crie um ramo da Neon para este PR, rode as migrações nele e aponte o ambiente de prévia para lá.

Faça uma abertura de produto de 15 segundos no Remotion: cartão de título, três pontos de venda e logo final. 1080p.

Este teste instável falha uma vez a cada cinco. Use depuração sistemática. Não faça a correção antes de conseguir reproduzir.

Adicione limite de taxa com TDD. Mostre primeiro o teste que falha e depois a implementação.

Refaça esta página de configurações. Acerte hierarquia, espaçamento e estado de foco. Sem o degradê roxo pronto.

Adicione autenticação a esta API. Se algo não estiver claro, pergunte antes de inventar um esquema.