📄 Architecture Decision Record (ADR)
O Architecture Decision Record documenta decisoes arquiteturais de forma estruturada. Cada decisao importante (banco de dados, framework, padrao de API) recebe um registro que explica o contexto, as opcoes avaliadas e o racional da escolha.
🎯 Template do Prompt
Crie um ADR (Architecture Decision Record) para esta decisao: Decisao: [o que precisa ser decidido] Contexto: [por que estamos tomando essa decisao agora] Formato do ADR: # ADR-[numero]: [titulo] ## Status: [Proposto | Aceito | Deprecado | Substituido] ## Contexto: [situacao que motiva a decisao] ## Opcoes Consideradas: - Opcao A: [descricao] | Pros: [...] | Cons: [...] - Opcao B: [descricao] | Pros: [...] | Cons: [...] - Opcao C: [descricao] | Pros: [...] | Cons: [...] ## Decisao: [opcao escolhida e por que] ## Consequencias: [o que muda com essa decisao] ## Metricas: [como vamos medir se a decisao foi boa]
💡 Dica Pratica
Crie uma pasta docs/adr/ no projeto e salve cada ADR como arquivo. Quando alguem perguntar "por que usamos X?", a resposta esta documentada. Referencie os ADRs no CLAUDE.md.
🔌 API Design Prompt
O API Design Prompt guia o Claude para projetar APIs que sao consistentes, versionaveis e faceis de usar. Ele cobre naming, status codes, error formats, pagination e autenticacao.
🎯 Template do Prompt
Projete a API para [RECURSO/FEATURE]: 1. Liste todos os endpoints necessarios (CRUD + acoes especiais) 2. Para cada endpoint defina: - Metodo HTTP e path (RESTful) - Request body/params (com tipos e validacoes) - Response body (com exemplos) - Status codes possiveis (sucesso e erro) - Autenticacao necessaria 3. Defina o formato padrao de erro 4. Defina a estrategia de paginacao 5. Considere versionamento (v1, v2) 6. Identifique rate limits necessarios Siga os padroes das APIs existentes no projeto. Consistencia > perfeicao.
💡 Dica Pratica
A frase final "Consistencia > perfeicao" e intencional. O Claude tende a propor o design "ideal" que pode ser inconsistente com o que ja existe. Forca-lo a seguir padroes existentes evita uma API Frankenstein.
⚖️ Comparacao de Opcoes
O prompt de comparacao de opcoes forca o Claude a analisar alternativas de forma objetiva com trade-offs explicitos. Ideal para decisoes como "qual banco usar", "qual padrao adotar" ou "build vs buy".
🎯 Template do Prompt
Compare estas opcoes para [DECISAO]: - Opcao A: [descricao] - Opcao B: [descricao] - Opcao C: [descricao] Para cada opcao, avalie em escala 1-5: | Criterio | Opcao A | Opcao B | Opcao C | |-----------------|---------|---------|---------| | Complexidade | | | | | Performance | | | | | Escalabilidade | | | | | Manutencao | | | | | Curva de aprend.| | | | | Custo | | | | IMPORTANTE: Nao tenha favoritos. Seja objetivo. Para a opcao RECOMENDADA, explique o trade-off principal que estamos aceitando.
💡 Dica Pratica
A instrucao "nao tenha favoritos" e essencial porque o Claude tem bias para tecnologias populares. Pedir que explicite o trade-off da opcao recomendada garante que voce toma a decisao informada, nao ele.
📈 Analise de Escalabilidade
O prompt de analise de escalabilidade faz o Claude avaliar como a arquitetura atual se comporta sob carga crescente e identificar gargalos antes que se tornem problemas em producao.
🎯 Template do Prompt
Analise a escalabilidade da nossa arquitetura atual: Cenarios de carga: - Atual: [X usuarios/requests por dia] - 10x: [10X usuarios] - o que quebra primeiro? - 100x: [100X usuarios] - o que precisa ser re-arquitetado? Para cada gargalo identificado: 1. Componente afetado 2. Tipo de gargalo (CPU, memoria, I/O, rede, banco) 3. Quando vai comecar a ser problema (qual volume) 4. Solucao proposta (cache, sharding, queue, scale out) 5. Esforco estimado para implementar Priorize: o que devo resolver AGORA vs o que pode esperar?
💡 Dica Pratica
A pergunta "o que devo resolver AGORA vs o que pode esperar" e a mais valiosa. Otimizacao prematura e o inimigo - voce quer saber o que precisa de atencao imediata e o que pode ser planejado para o futuro.
🔧 Manutencao e Divida Tecnica
O prompt de manutencao e divida tecnica faz o Claude inventariar a divida tecnica existente, calcular o "custo de juros" (tempo gasto trabalhando ao redor dos problemas) e priorizar o que pagar primeiro.
🎯 Template do Prompt
Faca um inventario da divida tecnica do projeto: 1. Identifique todas as areas com divida tecnica 2. Para cada area: - Tipo: [codigo legado | falta de testes | arquitetura inadequada | dependencia desatualizada] - Impacto diario: [quanto tempo perdemos trabalhando ao redor disso] - Risco: [o que acontece se nao resolvermos] - Esforco para pagar: [horas/dias estimados] - ROI: [impacto / esforco] 3. Ordene por ROI (maior ROI = pagar primeiro) Regra: Priorize divida que ATRAPALHA o trabalho diario sobre divida "estetica".
💡 Dica Pratica
Rode esse inventario mensalmente e compare com o anterior. Se a divida esta crescendo, voce precisa alocar mais tempo para paga-la. Se esta diminuindo, sua estrategia esta funcionando.
📚 Documentacao Arquitetural
A documentacao arquitetural e o prompt que faz o Claude gerar documentacao viva da arquitetura do projeto. Diferente de documentacao estatica, essa documentacao e gerada a partir do codigo real e se mantem atualizada.
🎯 Template do Prompt
Gere documentacao arquitetural baseada no codigo REAL do projeto: 1. Diagrama de componentes (em texto/mermaid) - Quais sao os modulos principais - Como eles se comunicam - Quais sao as dependencias 2. Fluxos criticos (top 3) - Request → Response para os endpoints mais importantes - Fluxo de dados do input ao banco 3. Decisoes arquiteturais ativas - Padroes usados e por que (inferir do codigo) - Convencoes de naming e organizacao 4. Pontos de extensao - Onde adicionar novas features - Onde NAO tocar (areas criticas) Baseie TUDO no codigo real. Nao invente nada que nao esteja no projeto.
💡 Dica Pratica
Salve a documentacao gerada e adicione ao CLAUDE.md como referencia. Regenere a cada mudanca arquitetural grande. A frase "baseie TUDO no codigo real" previne documentacao fantasiosa.
📋 Resumo do Modulo
Proximo Modulo:
4.7 - Prompts de Deployment