Code review, debugging contextual, documentação automática, testes, refatoração e comunicação com stakeholders. Cada prompt com campos para preencher com o seu código e contexto.
Resposta direta
Os melhores prompts de IA para desenvolvedores são os que fornecem contexto suficiente para a IA se comportar como um par de programação sênior, não como um autocomplete genérico. Em vez de 'revise este código', você fornece: linguagem, framework, critérios de qualidade, contexto do sistema e o que você já tentou.
Neste guia, você encontra 12 prompts prontos para as tarefas que consomem mais tempo no dia a dia do desenvolvedor: code review, debugging, documentação, testes, refatoração de código legado, comunicação com stakeholders e onboarding de novos membros. Cada prompt tem campos entre [colchetes] para você preencher com o seu contexto antes de colar no ChatGPT ou Claude.
Os prompts
Quando usar: Quando você precisa revisar um PR e quer feedback estruturado por categoria: segurança, legibilidade, performance e cobertura de testes.
O que preencher: Preencha: [LINGUAGEM_E_FRAMEWORK] (ex: TypeScript/Next.js), [CONTEXTO_DO_SISTEMA] (o que esse módulo faz no produto), [CRITERIOS_PRIORITARIOS] (ex: segurança acima de performance) e cole o [CODIGO_A_REVISAR].
Você é um desenvolvedor sênior experiente em [LINGUAGEM_E_FRAMEWORK]. Faça o code review do trecho abaixo considerando o contexto do sistema: [CONTEXTO_DO_SISTEMA]. Critérios prioritários desta revisão: [CRITERIOS_PRIORITARIOS]. Código: ``` [CODIGO_A_REVISAR] ``` Estruture o feedback em quatro seções: 1. Problemas críticos (bloqueiam o merge): liste com número da linha e o que exatamente precisa mudar 2. Melhorias recomendadas (não bloqueiam, mas vale resolver): legibilidade, nomeação, duplicação, tratamento de erro 3. Pontos de atenção de performance: apenas se houver algo mensurável 4. O que está bem: liste os pontos positivos do código para que o autor saiba o que manter Para cada problema crítico, mostre a versão corrigida ao lado da versão original.
Quando usar: Quando você precisa documentar uma função, método ou módulo para o repositório, a wiki do time ou o README.
O que preencher: Preencha: [LINGUAGEM] (ex: Python), [TIPO_DOC] (JSDoc, docstring, Markdown), [PUBLICO] (outros devs do time, contribuidores externos), e cole o [CODIGO_A_DOCUMENTAR].
Você é um technical writer especializado em documentação de código. Documente o trecho abaixo em [LINGUAGEM], no formato [TIPO_DOC], para o público: [PUBLICO]. Código: ``` [CODIGO_A_DOCUMENTAR] ``` A documentação deve conter: - Descrição em uma frase (o que faz, não como faz) - Parâmetros: nome, tipo, descrição e se é obrigatório ou opcional - Retorno: tipo e o que representa - Exceções/erros que pode lançar e em que condição - Exemplo de uso com entrada e saída esperadas - Notas de edge cases que não são óbvios pela assinatura Escreva em português claro. Sem jargão desnecessário. Se o código fizer algo contraintuitivo, explique o porquê na seção de notas.
Quando usar: Quando você tem um bug que não consegue resolver e quer um par de programação para levantar hipóteses ordenadas por probabilidade.
O que preencher: Preencha: [COMPORTAMENTO_ESPERADO], [COMPORTAMENTO_OBSERVADO], [AMBIENTE] (OS, versão da linguagem, framework), [O_QUE_JA_TENTEI] e cole o [CODIGO_OU_STACKTRACE].
Você é um desenvolvedor sênior especialista em debugging. Ajude a identificar a causa raiz do problema abaixo. Comportamento esperado: [COMPORTAMENTO_ESPERADO] Comportamento observado: [COMPORTAMENTO_OBSERVADO] Ambiente: [AMBIENTE] O que já tentei: [O_QUE_JA_TENTEI] Código / stack trace: ``` [CODIGO_OU_STACKTRACE] ``` Responda com: 1. As três hipóteses mais prováveis para a causa raiz, ordenadas da mais para a menos provável 2. Para cada hipótese: como confirmar ou descartar em menos de 5 minutos (qual print, log ou teste rápido) 3. Assim que a hipótese for confirmada: qual a correção recomendada com código de exemplo 4. Como evitar que esse bug apareça novamente (teste ou validação preventiva) Se precisar de mais contexto antes de levantar hipóteses, diga exatamente o que precisa ver.
Quando usar: Quando você precisa explicar uma decisão técnica, um problema de performance ou uma estimativa para gestores ou clientes sem background técnico.
O que preencher: Preencha: [TEMA_TECNICO] (ex: migração de banco de dados), [CONTEXTO_DO_NEGOCIO] (por que isso importa para a empresa), [PUBLICO] (ex: diretor de produto), [IMPACTO_ESPERADO] e [PRAZO_OU_CUSTO_ENVOLVIDO].
Você é um desenvolvedor sênior que sabe comunicar assuntos técnicos para quem não é da área. Escreva uma explicação sobre [TEMA_TECNICO] para [PUBLICO]. Contexto do negócio: [CONTEXTO_DO_NEGOCIO] Impacto esperado: [IMPACTO_ESPERADO] Prazo ou custo envolvido: [PRAZO_OU_CUSTO_ENVOLVIDO] A explicação deve: - Começar pelo impacto no negócio, não pelo problema técnico - Usar uma analogia do dia a dia para o conceito mais complexo (máximo uma analogia) - Mostrar os riscos de não agir agora (em termos de impacto, não de tecnologia) - Terminar com o que você precisa do stakeholder: aprovação, prazo, orçamento ou apenas ciência Evite siglas sem explicação. Evite jargão técnico não essencial. Máximo de 200 palavras.
Quando usar: Quando você precisa de uma suíte de testes para uma função específica e quer cobertura de casos limítrofes além do happy path.
O que preencher: Preencha: [LINGUAGEM_E_FRAMEWORK_DE_TEST] (ex: TypeScript/Jest, Python/pytest), [COMPORTAMENTO_QUE_IMPORTA] (o que a função garante), e cole a [FUNCAO_A_TESTAR].
Você é um engenheiro de qualidade experiente em [LINGUAGEM_E_FRAMEWORK_DE_TEST]. Escreva testes unitários para a função abaixo. O que esta função deve garantir: [COMPORTAMENTO_QUE_IMPORTA] Função: ``` [FUNCAO_A_TESTAR] ``` Crie testes para: 1. Happy path: entrada válida com o resultado esperado mais comum 2. Limites de entrada: valores mínimos, máximos, zero, string vazia, null/undefined quando aplicável 3. Entradas inválidas: o que a função deve rejeitar ou como deve se comportar com dados ruins 4. Edge cases específicos da lógica: casos que só aparecem lendo o código com atenção Para cada teste, use um nome descritivo que deixa claro o cenário sem precisar ler o corpo do teste. Siga o padrão Arrange/Act/Assert com comentários se o setup for complexo.
Quando usar: Quando você precisa melhorar a legibilidade e manutenibilidade de código antigo sem alterar o comportamento externo.
O que preencher: Preencha: [LINGUAGEM] (ex: JavaScript), [PROBLEMAS_PRINCIPAIS] (ex: funções de 200 linhas, variáveis sem nome semântico, lógica duplicada), [RESTRICOES] (ex: não pode mudar a assinatura da função pois outros módulos dependem dela) e cole o [CODIGO_LEGADO].
Você é um desenvolvedor experiente em refatoração de código em [LINGUAGEM]. Refatore o trecho abaixo mantendo o comportamento externo idêntico. Problemas identificados que precisam ser resolvidos: [PROBLEMAS_PRINCIPAIS] Restrições da refatoração: [RESTRICOES] Código legado: ``` [CODIGO_LEGADO] ``` Entregue: 1. Código refatorado completo e funcional 2. Lista de cada mudança feita e por quê (uma linha por mudança) 3. Qualquer comportamento ambíguo no código original que precisou de decisão: o que você assumiu e por quê 4. Sugestão de testes de regressão para validar que o comportamento não mudou Priorize legibilidade acima de cleverness. Nome de variável longo e claro é melhor que nome curto e críptico.
Quando usar: Quando você acabou de fazer uma mudança e precisa de uma mensagem de commit no padrão Conventional Commits e de um changelog claro para o release.
O que preencher: Preencha: [TIPO_DE_MUDANCA] (feat, fix, refactor, chore, etc.), [ESCOPO] (qual módulo ou componente), [DESCRICAO_DO_QUE_MUDOU] e [MOTIVACAO_OU_CONTEXTO].
Você é um desenvolvedor que escreve mensagens de commit claras no padrão Conventional Commits. Tipo de mudança: [TIPO_DE_MUDANCA] Escopo: [ESCOPO] O que mudou: [DESCRICAO_DO_QUE_MUDOU] Motivação ou contexto: [MOTIVACAO_OU_CONTEXTO] Produza: 1. Commit message no formato `tipo(escopo): descrição` com até 72 caracteres na primeira linha 2. Corpo do commit (opcional, só se a mudança precisar de mais contexto): explica o porquê, não o quê 3. Entrada de changelog no formato Markdown para o CHANGELOG.md: uma linha clara que um usuário não técnico consegue entender, agrupada no bloco correto (Added, Changed, Fixed, Removed, Security) A mensagem de commit é para o histórico de código. O changelog é para o usuário. Escreva cada um para o seu público.
Quando usar: Quando você vai revisar o PR de outra pessoa e quer ser sistemático, sem esquecer pontos críticos de segurança, performance e qualidade.
O que preencher: Preencha: [TIPO_DE_PR] (nova feature, bugfix, refactor, migração), [LINGUAGEM_E_FRAMEWORK], [AREA_DE_RISCO_PRINCIPAL] (ex: autenticação, banco de dados, processamento de pagamento) e cole o [DIFF_OU_DESCRICAO_DO_PR].
Você é um revisor de código experiente. Analise o PR abaixo e gere um checklist de revisão personalizado para este caso. Tipo de PR: [TIPO_DE_PR] Linguagem e framework: [LINGUAGEM_E_FRAMEWORK] Área de risco principal: [AREA_DE_RISCO_PRINCIPAL] Mudanças do PR: [DIFF_OU_DESCRICAO_DO_PR] Gere um checklist de revisão com no máximo 15 itens, organizados em: - Segurança: o que pode ser explorado ou vazar dados - Correção funcional: o código faz o que a descrição diz? - Casos não tratados: o que acontece com entrada inválida, timeout, usuário sem permissão? - Testes: a cobertura é adequada para o risco? - Manutenibilidade: daqui a 6 meses, outro dev consegue entender sem perguntar ao autor? Para cada item, indique se é crítico (bloqueia) ou sugestão (não bloqueia).
Quando usar: Quando você precisa de um README que explica o projeto de forma clara para contribuidores externos ou para o time que vai manter o código.
O que preencher: Preencha: [NOME_DO_PROJETO], [O_QUE_FAZ_EM_UMA_FRASE], [TECNOLOGIAS_PRINCIPAIS], [PRE_REQUISITOS] (ex: Node 18+, variáveis de ambiente necessárias), [COMO_RODAR_LOCALMENTE] e [COMO_CONTRIBUIR].
Você é um technical writer que cria READMEs claros e completos para projetos de software. Escreva o README.md para o projeto abaixo. Nome do projeto: [NOME_DO_PROJETO] O que faz em uma frase: [O_QUE_FAZ_EM_UMA_FRASE] Tecnologias principais: [TECNOLOGIAS_PRINCIPAIS] Pré-requisitos: [PRE_REQUISITOS] Como rodar localmente: [COMO_RODAR_LOCALMENTE] Como contribuir: [COMO_CONTRIBUIR] Estruture o README com: 1. Badge de status (use placeholders para shields.io) 2. Descrição de 2 a 3 linhas: o que é, para quem é, qual o benefício 3. Quick start: os comandos mínimos para rodar em menos de 5 minutos 4. Pré-requisitos com versões mínimas 5. Instalação passo a passo 6. Configuração (variáveis de ambiente com exemplos, sem valores reais) 7. Como contribuir (fork, branch, PR) 8. Licença Escreva em inglês (padrão de READMEs open source). Seja direto: quem lê um README quer subir o projeto, não ler um manual.
Quando usar: Quando você precisa decidir entre duas ou mais abordagens de arquitetura e quer um documento estruturado para alinhar o time e registrar o raciocínio.
O que preencher: Preencha: [PROBLEMA_A_RESOLVER], [OPCAO_A] (nome + descrição resumida), [OPCAO_B] (idem), [RESTRICOES] (orçamento, prazo, equipe, tecnologia já em uso) e [CRITERIOS_DE_DECISAO] (ex: custo de infra, tempo de implementação, manutenibilidade).
Você é um arquiteto de software experiente. Escreva um Architecture Decision Record (ADR) para ajudar o time a decidir a melhor abordagem para o problema abaixo. Problema a resolver: [PROBLEMA_A_RESOLVER] Opção A: [OPCAO_A] Opção B: [OPCAO_B] Restrições: [RESTRICOES] Critérios de decisão: [CRITERIOS_DE_DECISAO] O ADR deve conter: 1. Contexto: por que essa decisão precisa ser tomada agora 2. Opções consideradas: para cada opção, prós, contras e riscos 3. Matriz de decisão: avalie cada opção nos critérios em uma tabela (nota de 1 a 5 por critério) 4. Decisão recomendada com justificativa em 3 parágrafos 5. Consequências: o que fica mais fácil e o que fica mais difícil com essa escolha 6. Revisão: quando esta decisão deve ser revisitada Seja honesto sobre as limitações da opção recomendada. Um bom ADR registra o raciocínio, não vende uma solução.
Quando usar: Quando um gerente, cliente ou membro de outro time fez uma pergunta técnica e você precisa de uma resposta clara, objetiva e sem jargão desnecessário.
O que preencher: Preencha: [PERGUNTA_DO_STAKEHOLDER] (copiada literalmente), [CONTEXTO_TECNICO_REAL] (a resposta técnica completa), [NIVEL_TECNICO_DO_PUBLICO] (ex: não técnico, técnico mas não da área) e [ACAO_ESPERADA] (só quer entender, precisa aprovar algo, precisa tomar decisão).
Você é um desenvolvedor sênior que sabe traduzir respostas técnicas para linguagem de negócio. Responda à pergunta abaixo de forma clara para o público indicado. Pergunta do stakeholder: [PERGUNTA_DO_STAKEHOLDER] Contexto técnico real: [CONTEXTO_TECNICO_REAL] Nível técnico do público: [NIVEL_TECNICO_DO_PUBLICO] O que o stakeholder precisa fazer com essa resposta: [ACAO_ESPERADA] A resposta deve: - Começar respondendo diretamente a pergunta em uma frase - Explicar o porquê em 2 a 3 parágrafos, do nível mais alto para o mais baixo - Terminar com o próximo passo claro: o que você, o stakeholder, ou o time precisa fazer - Evitar jargão sem explicação. Se precisar de um termo técnico, defina em uma frase - Ter tom colaborativo, não defensivo Comprimento: o suficiente para responder com clareza. Não mais que isso.
Quando usar: Quando um novo desenvolvedor está entrando no projeto e você precisa preparar um guia que o ajude a ser produtivo na primeira semana.
O que preencher: Preencha: [NOME_DO_PROJETO], [STACK_COMPLETA] (linguagens, frameworks, banco de dados, infra), [CONVENCOES_DO_TIME] (padrões de commit, code style, processo de PR), [ONDE_FICAM_AS_COISAS] (estrutura de pastas, módulos principais) e [PRIMEIRO_TICKET_SUGERIDO] (algo pequeno para o novo membro contribuir logo).
Você é um desenvolvedor sênior criando o guia de onboarding técnico para um novo membro do time que vai trabalhar no [NOME_DO_PROJETO]. Stack: [STACK_COMPLETA] Convenções do time: [CONVENCOES_DO_TIME] Estrutura do projeto: [ONDE_FICAM_AS_COISAS] Primeiro ticket sugerido: [PRIMEIRO_TICKET_SUGERIDO] Crie um guia de onboarding estruturado para os primeiros 5 dias: Dia 1: configuração do ambiente (passo a passo de instalação, variáveis de ambiente, como rodar o projeto localmente e validar que está funcionando) Dia 2: entender a arquitetura (quais são os módulos principais, como eles se comunicam, onde ficam as regras de negócio) Dia 3: fluxo de trabalho do time (como criar branch, abrir PR, pedir review, processo de deploy) Dia 4: explorar o código base (os 5 arquivos mais importantes para ler primeiro e por quê) Dia 5: primeira contribuição (passo a passo para fazer o primeiro ticket e abrir o primeiro PR) Para cada dia, inclua: o objetivo do dia em uma frase, as tarefas concretas e quem perguntar se travar.
Quer os 60 prompts?
O Pack Prompts IA para Marketing e Vendas tem 60 prompts em 6 categorias: copy, email, social media, anúncios, estratégia e vendas. Cada um testado e com campos para preencher. PDF pronto para usar hoje.
Pagamento único. PDF por email.
Funciona no ChatGPT, Claude, Gemini e qualquer IA. Garantia de 7 dias.
Próximo nível
Quer ir além dos prompts? Conheça os pacotes de IA que automatizam o trabalho inteiro.
Dúvidas frequentes
Comece com esses 12 prompts. Se quiser todos os 60, o pack está disponível por R$ 27.