Suporte upstream incluído

Arquivos de suporte são incluídos em caminhos relativos à skill. Veja UPSTREAM-NOTICE.md para suas fontes fixadas, licenças, hashes e alterações de importação.

Gerador de Diagramas

Quando Usar

• Transformar análises textuais em visuais Mermaid/Graphviz/PlantUML.
• Produzir diagramas de caminhos de ataque ou arquitetura para relatórios.

Propósito

Criar diagramas claros e editáveis a partir de entradas confusas ou estruturadas. Prefira a fonte do diagrama baseada em texto primeiro, para que o resultado possa ser revisado, versionado e refinado. Renderize para arquivos apenas quando o usuário solicitar uma imagem/PDF ou quando um artefato para download ajudar materialmente.

Fluxo de trabalho padrão

1. Identifique a intenção do usuário, o público e o material de origem.
2. Escolha a família e a linguagem do diagrama usando a tabela de decisão abaixo.
3. Normalize entidades, relacionamentos, rótulos, estados, ramificações e informações de tempo/ordem antes de escrever o código do diagrama.
4. Gere código de diagrama conciso e legível.
5. Valide a sintaxe mentalmente e, ao criar arquivos, execute scripts/render_diagram.py.
6. Retorne o código do diagrama mais uma breve nota sobre as suposições. Ao gerar arquivos, inclua links para os arquivos de saída.

Não peça esclarecimentos em excesso. Se a solicitação for subespecificada, faça suposições razoáveis e rotule-as brevemente.

Tabela de decisão de linguagem de diagramas

Use Mermaid, a menos que outra linguagem seja claramente melhor.

Política de saída

• Sempre forneça código editável, a menos que o usuário solicite explicitamente apenas uma imagem.
• Padrão para um único diagrama melhor. Ofereça alternativas apenas quando genuinamente úteis.
• Prefira sintaxe estável e simples em vez de recursos sofisticados que podem não renderizar em versões mais antigas do Mermaid/PlantUML.
• Use rótulos curtos. Divida textos longos em notas fora do diagrama quando necessário.
• Evite IDs de nó ambíguos. Use IDs ASCII e rótulos legíveis por humanos.
• Preserve a terminologia do usuário, mas padronize a capitalização dentro de um diagrama.
• Para diagramas técnicos, inclua limites como cliente, serviço, banco de dados, fila, API externa e operador/usuário quando eles forem implícitos.
• Para diagramas de processos de negócios, distinga o caminho feliz, pontos de decisão, falhas, novas tentativas e etapas manuais quando presentes.
• Para diagramas criados a partir de texto incerto, inclua uma seção Assumptions após o código.

Regras de geração do Mermaid

Consulte references/diagram-patterns.md para modelos compactos.

Regras gerais do Mermaid:

• Comece com a diretiva de diagrama correta, por exemplo flowchart TD, sequenceDiagram, erDiagram, gantt, mindmap ou journey.
• Para fluxogramas, use flowchart TD, a menos que o usuário solicite da esquerda para a direita; use flowchart LR para arquitetura e pipelines.
• Use subgrafos para raias ou camadas de arquitetura. Nomeie subgrafos com rótulos legíveis.
• Mantenha os IDs dos nós estáveis e apenas em ASCII, por exemplo ingest_service[Ingest Service].
• Coloque entre aspas os rótulos que contêm pontuação que provavelmente confundirá o analisador.
• Use diamantes de decisão para ramificação: decision{Condition?}.
• Use rótulos de aresta consistentes: -- yes -->, -- no -->, -. async .-> ou == critical ==> apenas quando significativos.

…