Os 5 prompts que economizam minha semana como dev solo

Não vou listar “prompt pra escrever emails” ou “prompt pra gerar nomes de variáveis”. Encontra isso em qualquer lugar.

Vou mostrar o SISTEMA de prompts que eu uso toda semana e que economiza 6-8 horas do meu tempo. Cada prompt resolve um problema específico do meu workflow como dev solo.

Prompt 1: Analisar brief de cliente (e extrair pontos obscuros)

Cliente manda uma mensagem tipo: “Preciso de um site que venda cursos. Integra com Stripe, mostra progresso do aluno, manda certificado no final”.

3 horas depois, durante o desenvolvimento, descobri que ele quer certificado em PDF customizado com logotipo. E que o “progresso” inclui um sistema de pontos que converte pra cupom. Coisas que não estavam no brief.

Agora eu faço isso:

Você é um product manager experiente.

Um cliente pediu o seguinte:
[cole o brief aqui]

Sua tarefa é:
1. Listar EXPLICITAMENTE cada feature pedida
2. Identifique 5-7 perguntas que o brief deixa em aberto
3. Peça esclarecimentos sobre:
   - Integrações (quais exatamente?)
   - Fluxo de usuário (o que acontece depois que...?)
   - Casos de edge (e se o usuário tiver problema X?)
   - Dados sensíveis (qual segurança é necessária?)
   - Budget/timeline (é realista com as features?)

Formato: enumerate as features, depois a lista de perguntas com bullet.

Output típico:

FEATURES PEDIDAS:
- Venda de cursos
- Integração Stripe
- Rastreamento de progresso
- Certificado ao final

PERGUNTAS ABERTAS:
- Certificado em PDF ou apenas link?
- Precisa de customização de logotipo?
- Como funciona o refund?
- E-mail automático ao completar?

Isso economiza 1-2 horas de clarificação depois. Porque agora sei as perguntas certas pra fazer.

Prompt 2: Gerar escopo de proposta (e precificar automaticamente)

Depois de esclarecer o brief, preciso escrever o escopo da proposta. Antigamente: digitava tudo na mão.

Agora:

Você é um desenvolvedor experiente que escreve propostas de escopo.

Com base nessas features:
[cole as features confirmadas aqui]

Gere um ESCOPO DE PROJETO que:
1. Lista cada feature como um "item de escopo"
2. Para cada item, estime HORAS de desenvolvimento
3. Calcule: total de horas * R$150/hora = valor do projeto
4. Adicione contingência de 20%
5. Valor final

Formato:
- Feature: Descrição
  Horas: X
  Valor: R$ Y

TOTAL: X horas
VALOR BASE: R$ Y
CONTINGÊNCIA (20%): R$ Z
VALOR FINAL: R$ W

Assuma tecnologia React + TypeScript + Supabase.

Output:

- Autenticação com email/senha
  Horas: 6
  Valor: R$ 900

- Integração Stripe
  Horas: 8
  Valor: R$ 1.200

- Dashboard do professor
  Horas: 12
  Valor: R$ 1.800

...

TOTAL: 38 horas
VALOR BASE: R$ 5.700
CONTINGÊNCIA (20%): R$ 1.140
VALOR FINAL: R$ 6.840

Isso leva 10 minutos pra gerar. Sem Claude, seria 1-2 horas digitando e pensando.

Prompt 3: Refatoring e cleanup de PR (antes de fazer merge)

Um dev junior (ou eu mesmo) abre um PR com código que “funciona” mas não está otimizado.

Antes de mergear, eu rodo este prompt:

Você é um senior developer fazendo code review.

Analize este código:
[cole o código ou a função aqui]

Identifique:
1. Pontos de performance (tem loop duplicado? pode ser otimizado?)
2. Violações de padrão (segue as convenções do projeto?)
3. Potenciais bugs (falta tratamento de erro? pode quebrar em edge cases?)
4. Readability (alguém novo entenderia isso?)
5. Type safety (se for TypeScript, tipos estão corretos?)

Para CADA achado, sugira uma mudança específica com código.

Formato:
PROBLEMA: descrição
SUGESTÃO: código novo
ANTES: trecho atual
DEPOIS: trecho melhorado

Output típico:

PROBLEMA: Loop desnecessário que roda N vezes
SUGESTÃO: Use .find() em vez de loop com break
ANTES:
let found = null;
for (let i = 0; i < users.length; i++) {
  if (users[i].id === targetId) {
    found = users[i];
    break;
  }
}

DEPOIS:
const found = users.find(u => u.id === targetId);

Isso economiza review time e garante que o código que entra é decente. Levo 15 minutos pra passar pelo review ao invés de 45.

Prompt 4: Revisar contrato (e achar cláusulas problemáticas)

Clientes às vezes mandam um NDA ou contrato de parceria. Antes eu ignorava ou lia rapidinho.

Agora:

Você é um advogado analisando contratos.

Analize este contrato:
[cole o texto aqui]

Identifique:
1. Cláusulas que favorecem uma parte sobre outra
2. Ambiguidades legais (o que é vago ou pode ser interpretado de duas formas?)
3. Riscos pra mim como desenvolvedor (sou responsável por quê?)
4. Red flags (exclusividade? confidencialidade abusiva? restrição geográfica?)
5. Recomendações (o que deveria estar aqui e não está?)

Aviso: não sou advogado, isso é uma análise técnica, não jurídica.
Procure orientação profissional pra contratos críticos.

Formato:
CLÁUSULA: número/título
RISCO: nível (ALTO/MÉDIO/BAIXO)
PROBLEMA: descrição
RECOMENDAÇÃO: o que mudar

Output:

CLÁUSULA: 3.2 - Confidencialidade
RISCO: ALTO
PROBLEMA: "Qualquer informação compartilhada fica confidencial indefinidamente"
RECOMENDAÇÃO: Limitar a 3-5 anos. Adicionar exceção pra informação pública.

CLÁUSULA: 5.1 - Responsabilidade
RISCO: MÉDIO
PROBLEMA: "Desenvolvedor é responsável por bugs até 12 meses após deployment"
RECOMENDAÇÃO: Reduzir pra 30 dias e apenas bugs críticos (segurança).

Economiza 2-3 horas de leitura/análise. E me previne de cair em cláusulas abusivas.

Prompt 5: Gerar SQL pra migração complexa

Tenho um banco em produção. Preciso migrar dados de uma forma, mudar schema. Migração é sempre arriscada.

Este prompt ajuda:

Você é um DBA expert em PostgreSQL.

Preciso migrar dados:
TABELA ORIGINAL: [descreve a estrutura]
TABELA NOVA: [descreve a estrutura]

Gere:
1. Validação: contar registros antes e depois (deve ser igual)
2. Transformação: SQL pra copiar e transformar dados
3. Cleanup: apagar dados redundantes/antigos
4. Verificação: query pra auditar a migração

Assuma dados sensíveis. Inclua:
- Backup antes de rodar
- Validação de integridade (foreign keys)
- Teste em staging first
- Rollback plan

Formato:
-- BACKUP
-- VALIDAÇÃO PRÉ-MIGRAÇÃO
-- TRANSFORMAÇÃO
-- LIMPEZA
-- VERIFICAÇÃO PÓS-MIGRAÇÃO

Output:

-- BACKUP
pg_dump seu_banco > backup_$(date +%Y%m%d).sql

-- VALIDAÇÃO PRÉ-MIGRAÇÃO
SELECT COUNT(*) FROM tabela_antiga; -- Guardar esse número

-- TRANSFORMAÇÃO
INSERT INTO tabela_nova (id, nome, email, criado_em)
SELECT id, nome, email, created_at FROM tabela_antiga
WHERE deleted_at IS NULL;

-- VERIFICAÇÃO
SELECT COUNT(*) FROM tabela_nova; -- Deve ser igual ao COUNT anterior

Isso evita que eu esqueça de algum passo crítico e acabe corrompendo dados. Economia: tempo de debugging se algo der errado, que pode ser horas.

Sistema, não lista

A razão desses prompts funcionarem é que não são “genéricos”. São ESPECÍFICOS do meu workflow:

• Prompt 1 resolve o problema de brief vago
• Prompt 2 resolve o problema de precificação manual
• Prompt 3 resolve o problema de code review lento
• Prompt 4 resolve o problema de contratos obscuros
• Prompt 5 resolve o problema de migração arriscada

Cada um economiza tempo no ponto exato aonde eu mais gasto tempo.

Como você encontra SEUS prompts

Rastreie uma semana. Aonde você gasta mais de 1 hora em tarefas repetitivas?

• Escrever emails similares? Crie um prompt pra estruturar a resposta.
• Debugar o mesmo tipo de bug? Crie um prompt que faz análise automática.
• Revisar documentação antiga? Crie um prompt que resume e atualiza.

Depois que encontra, refine 3-4 vezes. O primeiro output raramente é perfeito.

Tempo total economizado

Estimativa semanal detalhada:

• Brief (1-2h) -> 10-15 min com prompt = 1h economizada
• Escopo (1-2h) -> 15 min com prompt = 1h economizada
• Code review (2-3h) -> 30-45 min com prompt = 1.5h economizada
• Contrato (2-3h) -> 20 min com prompt = 2h economizada
• SQL migration (1-2h) -> 20 min com prompt = 1h economizada

Total: 6.5-7 horas economizadas por semana.

Num mês, são 26-28 horas. Num ano, 338 horas. Isso é 8-9 semanas de trabalho inteiro que voltam pro seu calendário.

Mas tem um detalhe maior: essas 7 horas não são só “economia”. São horas aonde você estava operando em modo reativo (debugando, tentando entender email de cliente confuso, esperando pela migração terminar). Agora você opera em modo criativo: arquitetura real, code novo que importa, conversas estratégicas. Sua qualidade de vida sobe mesmo que o tempo “économizado” fosse só 2 horas.

Por isso que prompts funcionam melhor que hacks pontuais: eles reorganizam seu workflow pra deixar espaço pro trabalho que importa.

Por que esses 5 funcionam quando outros prompts não funcionam

A razão desses prompts funcionarem �

Quando os prompts falham (e como consertar)

Usar prompt bom nem sempre funciona. Aqui est�o 3 situa��es onde mesmo prompts excelentes falham e como recuperar:

Falha 1: O modelo n�o entendeu o contexto

Voc� tem um prompt que funciona 80% das vezes. Outras 20%, o modelo desvia completamente do esperado. Motivo: faltou contexto espec�fico. Um prompt que funciona pra “gerar c�digo” pode falhar pra “gerar c�digo que funcione em ambientes de produ��o com Sentry enabled”.

Solu��o: adicione limita��es negativas. Em vez de “gere c�digo”, diga “gere c�digo que n�o use console.log, que registre erros no Sentry, que n�o fa�a logging em produ��o, que valide entrada do usu�rio”.

O prompt fica mais longo, mas funciona 95% das vezes. Testei isso com c�digo de integra��o Stripe, c�digo de autentica��o, c�digo de query Postgres.

Falha 2: O modelo come�ou bem, depois desviou

Voc� manda um prompt de 500 caracteres. Primeiras 3 linhas da resposta s�o �timas. Depois vira bagun�a. Motivo: o modelo come�ou bem mas perdeu o fio da meada no meio da resposta.

Solu��o: divida em sub-prompts. Em vez de um prompt gigante, crie 3-4 prompts menores, sequenciais. Prompt 1: estrutura. Prompt 2: detalhe A. Prompt 3: detalhe B.

Exemplo: ao inv�s de “gere um sistema completo de autentica��o”, pe�a “1) listar requisitos de autentica��o”, depois “2) desenhe o schema”, depois “3) escreva a rota de login”.

Falha 3: O modelo alucinrou dados

Voc� pediu um exemplo de integra��o com API de Lispay (fintech brasileira real). O modelo inventou 3 endpoints que n�o existem. Voc� copiou o c�digo, n�o funciona, perde 2 horas debugando.

Solu��o: sempre diga “pesquise antes de responder” ou “assuma que voc� n�o sabe, pergunte antes”. O modelo vai dizer “n�o tenho certeza da vers�o atual dessa API” em vez de inventar.

Melhor ainda: mande a documenta��o da API junto no prompt. “Aqui est� a documenta��o de Lispay: [colar doc]. Use isto como fonte verdadeira, ignore conhecimento anterior”.

Esse detalhe pode economizar 4-5 horas por semana quando se trabalha com APIs obscuras ou financeiras.

Padr�o: prompts bons vs ruins

Bom: “Voc� � especialista em precifica��o de freelancer. Gere uma tabela de pre�os por servi�o com base em: experi�ncia (5 anos), localiza��o (S�o Paulo), mercado (alto padr�o)”.

Ruim: “Crie uma tabela de pre�os”. (Muito gen�rico. Pode voltar coisa aleat�ria.)

Bom: “Gere c�digo para validar email em TypeScript. Regras: padr�o RFC 5322, mas rejeite emails com dom�nios .dev que terminam em .dev.fake ou similares. Retorne true/false, n�o lance exce��o”.

Ruim: “Valide email em TypeScript”. (Pode retornar qualquer coisa.)

Padr�o: prompts ruins deixam espa�o para interpreta��o. Prompts bons eliminam interpreta��o.

Quanto mais espec�fico o prompt, melhor a resposta.

Leia também: MCP server caseiro pro Claude | Vibe coding vs pair programming com IA | Entregar projetos rápido com IA