redaçãoFunciona bem com ClaudeFunciona bem com ChatGPTFunciona bem com Gemini

Transforme uma decisão em um ADR ou na documentação que você deixou de escrever

Documentação é a tarefa que os desenvolvedores mais querem repassar — escrever comentários de código ou documentação e resumir mudanças recentes de código estão entre as cinco principais tarefas de IA, e documentar código é onde 31% já dependem principalmente da IA. Isso vale especialmente para Registros de Decisão de Arquitetura (ADRs): o raciocínio está fresco na sua cabeça, mas escrevê-lo é a tarefa chata que fica de lado, deixando o próximo engenheiro com o trabalho de fazer engenharia reversa para entender por que o sistema é do jeito que é.

Você é um engenheiro staff que escreve documentação técnica clara e direta. Transforme minhas anotações em um {{doc_type}} claro para outros engenheiros.

Público e onde isso vai ficar: {{audience}}
Minhas anotações brutas — a decisão, o contexto e os trade-offs que considerei:
{{notes}}

Para um ADR, use esta estrutura: Título; Status; Contexto (o problema e as restrições); Decisão (o que escolhemos, dito de forma direta); Consequências (trade-offs, o que fica mais difícil, com o que estamos agora comprometidos); Alternativas consideradas (cada uma com o motivo de termos rejeitado).

Regras:
- Use apenas os fatos, decisões e trade-offs das minhas anotações. Não invente benchmarks, requisitos, datas ou alternativas que eu não mencionei. Onde um detalhe necessário estiver claramente faltando, insira "[TODO: confirmar]" em vez de preenchê-lo.
- Mantenha o texto conciso e fácil de escanear — seções curtas, voz ativa, sem linguagem de marketing.
- Preserve minhas decisões técnicas exatamente como estão; você está registrando-as, não tomando-as de novo.
- Termine com uma lista curta de questões em aberto que um revisor deveria resolver.

Preencha seus dados e o prompt se atualiza na hora — depois é só copiar.

Tipo de documentoPúblico e onde ficaSuas anotações brutas (cole aqui)

O que você recebe (trecho)

Título: Usar row-level security do Postgres para isolamento de tenants Status: Proposto Contexto: Hospedamos múltiplos tenants em um único banco de dados. A filtragem no nível da aplicação causou dois vazamentos de dados entre tenants neste trimestre. Decisão: Impor o isolamento com políticas de row-level security do Postgres baseadas em tenant_id, definidas por conexão. Consequências: Garantia forte no nível do banco de dados; toda conexão precisa definir o tenant id ou as queries não retornam nada. As migrations ficam mais complexas. [TODO: confirmar] o impacto no desempenho sob nossa carga. Alternativas consideradas: banco de dados separado por tenant — rejeitado pela sobrecarga operacional; continuar com filtragem no nível da aplicação — rejeitado após vazamentos repetidos. Questões em aberto: compatibilidade com o connection pooler; ordem de lançamento entre os serviços.

O fluxo de trabalho completo

Primeiro, despeje a decisão, o contexto e os trade-offs em anotações brutas
Gere o ADR ou documento, depois compare com o que você realmente decidiu
Preencha cada "[TODO: confirmar]" com um valor real e exclua qualquer coisa que o modelo tenha inferido por conta própria
Faça commit do documento junto com o código, para que ele permaneça descobrível e versionado

Fique de olho

O modelo preenche lacunas inventando justificativas, requisitos ou alternativas que você nunca considerou. Documentos são uma fonte de verdade sobre a qual outros engenheiros agem — verifique se cada afirmação reflete a decisão real.

Não cole arquitetura confidencial, detalhes de segurança ou código proprietário em uma ferramenta de consumo. Documentos internos de design são segredos comerciais; use uma ferramenta aprovada, com o treinamento desativado.

A IA pode reformular uma decisão, mas não pode assumi-la como sua. O julgamento de engenharia em um ADR é seu, e um revisor ainda deve aprová-lo.

De onde isso vem

Cada caso de uso deste site se baseia em relatos reais que os desenvolvedores de software em atividade compartilham — nada foi inventado por nós.

Mais casos de uso de IA para os desenvolvedores de software

análise

Transforme uma decisão em um ADR ou na documentação que você deixou de escrever

O fluxo de trabalho completo

Fique de olho

De onde isso vem

Mais casos de uso de IA para os desenvolvedores de software

Explique código desconhecido antes de alterá-lo

Uma primeira revisão do seu próprio diff antes que humanos o vejam

Gere testes unitários e depois verifique-os em relação à especificação

Depuração "pato de borracha" para um problema que você não consegue resolver

Redija mensagens de commit e descrições de PR a partir do seu diff