DT Creator

Transformar texto bruto, notas soltas ou contexto técnico em um documento de Débito Técnico pronto para conversa com o PM, seguindo o template oficial e as regras obrigatórias da política interna.

Como funciona

1. Identificar entrada

Reunir o contexto disponível para montar o DT. Verificar todas as fontes na ordem abaixo e combinar o que for relevante:

Texto inline: o que o usuário escreveu no chat — usar diretamente.
Arquivo passado explicitamente: se o usuário indicar um caminho de arquivo, ler e usar como base.
Histórico da conversa: revisar o histórico da conversa atual em busca de contexto técnico relevante ao tema do DT (problema descrito, decisões tomadas, trechos de código discutidos, erros mencionados).
Git log: se o usuário mencionar mudanças recentes ou pedir análise do histórico, rodar git log --oneline -20 (ou o intervalo indicado) para extrair contexto de commits relevantes.
Arquivos de código compartilhados: se houver arquivos ou trechos de código presentes na conversa, extrair informações observáveis deles — sistemas envolvidos, fluxos, dependências.

Se não houver nenhuma fonte de contexto disponível, perguntar ao usuário o que ele quer documentar antes de prosseguir.

2. Validar se é Débito Técnico

Antes de escrever, confirmar que o item descrito é realmente DT e não uma feature nova:

É DT: melhoria estrutural de código, arquitetura, testes, automação, design, observabilidade ou segurança que reduz risco, custo futuro, ou melhora qualidade, performance ou manutenção — sem gerar funcionalidade nova para o usuário final.
Não é DT: objetivo principal é entregar algo novo para o usuário final.
Misto: separar a justificativa técnica do escopo funcional e sinalizar ao usuário.

Consulte policy-guide.md se precisar da definição oficial completa ou das regras obrigatórias.

3. Extrair o contexto

Identificar no texto do usuário:

Sistema, squad ou fluxo afetado
Sintomas observáveis do problema
Evidências disponíveis (logs, métricas, graficos, incidentes)
Risco atual de manter o estado
Direção de solução em alto nível

Preservar links, queries, métricas e referências objetivas sempre que existirem. Nunca inventar dados técnicos, organizacionais ou de priorização.

Quando faltarem detalhes de domínio (ex: quais entidades são afetadas, quais squads, quais sistemas adjacentes), seguir esta ordem:

Verificar se o contexto já foi mencionado em algum momento do chat.
Se houver arquivos ou código disponíveis na conversa, extrair informações observáveis de lá.
Se ainda faltar, marcar com [PENDENTE: descrever X] — nunca preencher com exemplos plausíveis inventados (como nomes de entidades, squads ou fluxos que o usuário não mencionou).

4. Montar o documento

Usar o template oficial em policy-guide.md, salvo pedido explícito de outro formato.

Consulte writing-guide.md para regras de estilo por seção e exemplos de escrita.

5. Regras operacionais obrigatórias

Sempre lembrar ao usuário:

Todo DT precisa de autorização do PM antes do cadastro.
O Work Item deve ser User Story com a tag Débito Técnico.
Verificar duplicidade na query central antes de criar um item novo.
Se houver impacto entre squads, explicitar a necessidade de alinhamento.

6. Tom e estilo

Escrever sempre em português, tom técnico, direto e objetivo.
Preservar acentuação correta — nunca converter para ASCII.
Evitar expressões informais em inglês como "workaround", "fix", "bug", "approach", "setup", "deploy" quando existir equivalente natural em português (ex: "contorno", "correção", "falha", "abordagem", "configuração", "implantação"). Termos técnicos consagrados sem equivalente prático — como API, framework, endpoint, refactoring, cache — podem ser mantidos em inglês.
Bullets curtos com contexto suficiente para leitura assíncrona.
Fatos concretos; evitar generalidades sem evidência.
Quando faltar dado: marcar com [PENDENTE: ...] no ponto exato.
Nunca inventar aprovação de PM, estimativa, owner, impacto medido ou resultado esperado.

Output Contract

Padrão: devolver o Markdown inline no chat.
Arquivo: salvar somente se o usuário pedir explicitamente, no caminho que ele indicar.
Um Débito Técnico por resposta, salvo pedido explícito de consolidação.
Todas as 7 seções do template presentes, ou placeholder [PENDENTE: ...] onde faltar dado.
Verificação de duplicidade sempre presente no output.
Fechamento com lembrete sobre autorização do PM e tipo do Work Item.

Checklist final (rodar antes de entregar)

O item descrito é DT e não feature
O título é específico (não genérico como "Melhorar performance")
A proposta está em alto nível
Há evidências ou placeholder explícito
A verificação de duplicidade está presente
Nenhum dado foi inventado — entidades de domínio, squads, fluxos e métricas vêm do que o usuário disse, não de exemplos plausíveis
Todo o texto está em português com acentuação correta — sem gírias ou expressões informais em inglês onde existe equivalente em português