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.
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.
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.
O pack completo tem 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.
Não. A IA não entende o contexto do seu sistema, não conhece as decisões históricas do time e não assume responsabilidade pelo código que vai para produção. O que ela faz é acelerar tarefas repetitivas: rascunho de documentação, estrutura de testes, revisão de padrões óbvios. O julgamento arquitetural, a decisão de trade-off e a responsabilidade pelo sistema continuam com o desenvolvedor.
Sim. Os prompts foram escritos com campos para você especificar a linguagem e o framework. A IA adapta a saída para Python, TypeScript, Go, Java, Ruby ou qualquer outra. Quanto mais específico você for no campo [LINGUAGEM_E_FRAMEWORK], melhor será a resposta.
Nunca cole código com credenciais reais, tokens ou dados sensíveis de produção no prompt. Substitua por placeholders antes de enviar. Para revisão de código de sistemas críticos, use os prompts localmente com uma instância privada da IA, não com serviços públicos. Trate a IA como um estagiário brilhante: você revisa tudo antes de ir para produção.
Escrever documentação de uma função do zero leva em média 15 a 20 minutos; com o prompt, você tem o rascunho em 2 a 3 minutos e passa o tempo restante ajustando. Code review sem estrutura pode levar 30 a 45 minutos num PR médio; com o checklist gerado pela IA, você reduz para 15 a 20 minutos. Numa semana típica com 5 a 8 PRs e 3 a 5 documentações, a economia pode passar de 3 horas.
Comece com esses 12 prompts. Se quiser todos os 60, o pack está disponível por R$ 27.
Do Claude instalado ao atendimento com IA: rotina, redes, vendas, sites e apps, com kits prontos para usar e o grupo no WhatsApp desde o primeiro dia.
Ver o que tem dentro