Como Escrever Prompts para Codigo: 20

Melhore esse codigo

[Contexto] Este e um handler Express em TypeScript que processa pagamentos via Stripe.

[Instrucao] Refatore extraindo a validacao de input para um middleware Zod separado,
e a logica de negocio para um PaymentService.

[Formato] Retorne 3 arquivos: middleware, service e handler refatorado.
Inclua imports completos.

[Restricoes] Mantenha a mesma rota e response format.
Nao mude o schema do Stripe. Use injecao de dependencia no service.

Refatore [ARQUIVO] extraindo toda a logica de negocio para um service separado.

Regras:
- O handler/controller deve ficar so com parse de input, chamada do service e response
- O service deve ser uma classe com metodos tipados
- Use injecao de dependencia para repositorios/clients externos
- Mantenha o mesmo comportamento e response format
- Inclua tipos TypeScript para todos os parametros e retornos

Stack: [SUA_STACK]

Esta funcao tem [X] linhas e faz muitas coisas. Quebre em funcoes menores.

Regras:
- Cada funcao deve ter uma unica responsabilidade
- Nomes descritivos que explicam o que a funcao faz
- A funcao original deve virar uma orquestradora que chama as menores
- Mantenha a mesma interface publica (parametros e retorno)
- Adicione tipos TypeScript em cada funcao nova

Converta este codigo de callbacks/promises encadeadas para async/await.

Regras:
- Mantenha o tratamento de erro equivalente (try/catch onde tinha .catch)
- Nao mude a logica, apenas a sintaxe
- Se houver operacoes paralelas, use Promise.all
- Adicione tipagem nos retornos das funcoes async

Esses [N] arquivos tem logica duplicada. Identifique o codigo repetido e extraia
para funcoes/classes compartilhadas.

Regras:
- Crie um arquivo utils ou shared com as funcoes extraidas
- Mantenha a flexibilidade: use parametros para as diferencas entre os usos
- Nao force DRY onde a duplicacao e acidental (codigos parecidos mas com motivos diferentes)
- Atualize todos os arquivos originais para usar as funcoes compartilhadas

Adicione tipagem TypeScript completa neste arquivo JavaScript.

Regras:
- Infira tipos dos valores quando possivel
- Crie interfaces para objetos complexos
- Use generics onde fizer sentido
- Nunca use 'any' - use 'unknown' se nao souber o tipo
- Mantenha o mesmo comportamento, apenas adicione tipos
- Coloque interfaces e types no topo do arquivo ou num arquivo .d.ts separado

Crie testes unitarios para [ARQUIVO/CLASSE/FUNCAO].

Cubra:
- Cenario feliz (happy path) com dados validos
- Inputs invalidos (null, undefined, string vazia, numero negativo)
- Edge cases (lista vazia, item unico, valores no limite)
- Erros esperados (throws, rejects)

Stack: Jest + TypeScript
Padrao: describe > it, nomes em portugues
Mock: use jest.mock() para dependencias externas
Nao teste implementacao interna, teste comportamento

Crie testes de integracao para o endpoint [ROTA].

Cubra:
- Request valido retorna status [200/201] com body correto
- Request sem autenticacao retorna 401
- Request com body invalido retorna 400 com mensagem clara
- Request para recurso inexistente retorna 404
- Request com dados duplicados retorna 409

Stack: Jest + Supertest
Setup: use beforeAll para criar dados de teste, afterAll para limpar
Database: use banco de teste separado ou transactions com rollback

Crie testes para o componente [COMPONENTE].

Cubra:
- Renderiza sem crash com props obrigatorias
- Exibe texto/dados corretos baseado nas props
- Eventos de click/change disparam as funcoes corretas
- Estado condicional: loading, erro, vazio, com dados
- Acessibilidade: elementos tem roles e labels corretos

Stack: React Testing Library + Jest
Padrao: teste o que o usuario ve, nao a implementacao
Nao use: enzyme, shallow rendering, snapshot tests

Este codigo legado nao tem testes. Adicione testes SEM refatorar o codigo.

Abordagem:
1. Identifique os inputs e outputs publicos
2. Crie testes que documentam o comportamento atual (characterization tests)
3. Cubra os paths mais arriscados primeiro (pagamentos, auth, dados sensiveis)
4. Mocke dependencias externas de forma simples
5. Se o codigo e dificil de testar, documente por que num comentario

Objetivo: criar uma rede de seguranca para refatoracao futura
Nao tente 100% coverage, foque em 80% dos paths criticos

Crie factories e fixtures para os modelos do projeto.

Modelos: [LISTA_DE_MODELOS]

Regras:
- Use factory pattern: funcao que retorna objeto com valores default
- Permita override de qualquer campo via parametro
- Dados realistas (nomes, emails, datas plausíveis)
- IDs sequenciais ou UUID
- Relacionamentos: factory de pedido inclui factory de cliente

Exemplo de uso esperado:
const user = createUser({ name: 'Joao' })
const order = createOrder({ userId: user.id })

Este erro esta acontecendo em producao:

[COLE O STACK TRACE COMPLETO]

Contexto:
- Acontece quando [DESCREVA A ACAO DO USUARIO]
- Comecou a acontecer depois de [ULTIMA MUDANCA RELEVANTE]
- Frequencia: [SEMPRE / AS VEZES / RARO]

Investigue:
1. Qual a causa raiz (nao o sintoma)?
2. Onde no codigo esta o problema?
3. Qual o fix com menor risco?
4. Tem algum edge case que pode causar o mesmo erro de outra forma?

Esta funcao/query/pagina esta lenta. Tempo atual: [X ms/s].
Tempo aceitavel: [Y ms/s].

[COLE O CODIGO]

Analise:
1. Onde estao os gargalos?
2. Tem N+1 query? Loop desnecessario? Calculo repetido?
3. O que pode ser cacheado?
4. O que pode ser paralelizado?

Sugira o fix com o maior impacto e menor risco.
Nao mude a interface publica.

A aplicacao esta consumindo cada vez mais memoria ao longo do tempo.
Ambiente: [Node.js / Browser / React Native]

Suspeita: [DESCREVA ONDE VOCE ACHA QUE TA O PROBLEMA, SE SOUBER]

Analise estes arquivos procurando por:
- Event listeners nao removidos
- Closures que capturam referencias grandes
- Cache sem limite de tamanho
- Timers/intervals nao limpos
- Subscriptions nao canceladas (RxJS, WebSocket, etc)

Para cada problema encontrado, sugira o fix especifico.

Tenho um bug que aparece intermitentemente. Suspeito de race condition.

Sintoma: [DESCREVA O COMPORTAMENTO ERRATICO]
Quando acontece: [EM CARGA ALTA / QUANDO 2 REQUESTS CHEGAM JUNTOS / ETC]

Analise o codigo procurando por:
- Operacoes read-then-write sem lock
- Estado compartilhado entre requests
- Promises que deveriam ser sequenciais mas rodam em paralelo
- Cache invalidado no momento errado

Sugira fix usando: mutex, transacao, optimistic locking ou redesign do fluxo.

O TypeScript ta reclamando desse erro:

[COLE O ERRO DO TSC]

Codigo relevante:
[COLE O TRECHO]

Corrija o tipo sem usar 'any' ou 'as' (type assertion).
Se precisar criar tipos novos, crie.
Explique por que o tipo original estava errado.

Adicione JSDoc em todas as funcoes e classes exportadas deste arquivo.

Padrao:
- @description: o que a funcao faz (1-2 frases)
- @param: tipo e descricao de cada parametro
- @returns: tipo e descricao do retorno
- @throws: excecoes que podem ser lancadas
- @example: exemplo de uso realista

Tom: tecnico mas claro. Sem jargao desnecessario.
Nao documente getters/setters triviais.

Explique este codigo como se eu tivesse acabado de entrar no projeto.

[COLE O CODIGO]

Quero saber:
1. O que esse codigo faz (visao geral)
2. Por que ele existe (qual problema resolve)
3. Como ele funciona (passo a passo)
4. Quais sao as dependencias criticas
5. Onde estao os pontos de risco (bugs potenciais, acoplamento)
6. Se eu precisar mudar algo, por onde comecar

Nivel: desenvolvedor pleno que conhece a stack mas nao o projeto.

Gere documentacao de API para estes endpoints.

Formato por endpoint:
- Metodo + Rota
- Descricao curta
- Headers obrigatorios
- Body (JSON com tipos e descricao de cada campo)
- Response de sucesso (status + body)
- Responses de erro (status + body)
- Exemplo de request com curl

Leia os handlers e middlewares para inferir os detalhes.
Se alguma informacao nao for clara no codigo, marque com [VERIFICAR].

Gere um changelog a partir desses commits:

[COLE O GIT LOG]

Formato:
## [VERSAO] - DATA
### Novas features
- Descricao user-friendly da feature
### Correcoes
- Descricao do bug corrigido
### Mudancas internas
- Refatoracoes e melhorias que nao afetam o usuario

Regras:
- Agrupe commits relacionados num unico item
- Ignore commits de merge e formatacao
- Linguagem pra usuario final, nao pra dev (exceto em 'Mudancas internas')

Crie um Architecture Decision Record (ADR) para esta decisao:

Decisao: [DESCREVA A DECISAO. Ex: 'Usar Redis como cache em vez de cache em memoria']

Formato ADR:
- Titulo: [numero] - [titulo curto]
- Status: Proposto
- Contexto: Qual o problema que estamos resolvendo?
- Decisao: O que decidimos fazer?
- Alternativas consideradas: O que mais cogitamos? Por que descartamos?
- Consequencias: O que muda? Quais os riscos?
- Notas: Qualquer informacao adicional relevante

# .zshrc - aliases para prompts comuns
alias ai-test='f() { claude "Crie testes unitarios para $1. Stack: Jest + TypeScript. Cubra happy path, edge cases e erros. Siga o padrao dos testes existentes."; }; f'
alias ai-refactor='f() { claude "Refatore $1 extraindo logica de negocio pra service. Mantenha interface publica. TypeScript strict."; }; f'
alias ai-docs='f() { claude "Adicione JSDoc em todas as funcoes exportadas de $1. Inclua @param, @returns e @example."; }; f'