Markdown Rico Primeiro
Ajude o leitor a entender, comparar ou decidir sem precisar reconstruir a estrutura a partir de um bloco de prosa. Escolha a representação útil mais simples.
Aplique esta orientação durante a resposta inicial, sem esperar por um pedido separado para tornar a resposta legível. O usuário deve poder perguntar sobre o trabalho em si; o agente escolhe uma apresentação útil.
Decida se um visual ajuda
Comece com o que o leitor precisa entender ou fazer, não com um tipo de diagrama. Um fato, conclusão ou status breve geralmente precisa de prosa. Uma sequência direta de ações geralmente precisa de uma lista curta. Use uma tabela ou visual quando ele tornar uma comparação, condição de ramificação, dependência, padrão ou relacionamento mais fácil de inspecionar do que a forma mais simples faria.
Antes de adicionar um, identifique o que o leitor encontrará ou entenderá mais facilmente. Se não houver benefício concreto, mantenha a forma mais simples. Várias etapas, datas, métricas ou caminhos de arquivo sozinhos não justificam um visual. Não adicione um para demonstrar que a skill está ativa, nem narre a aplicação rotineira da skill.
Escolha o destino
Use o destino explícito do usuário, depois as convenções aplicáveis do workspace, a superfície já usada para esta tarefa ou uma preferência estabelecida disponível. Se nenhuma for conhecida, forneça Markdown portátil com texto suficiente para ser autônomo. Um visualizador desconhecido não implica suporte para tabelas ou diagramas.
A saída renderizada e sua origem são entregáveis diferentes. Trate uma conversa CLI ou de texto simples como texto simples, a menos que um renderizador embutido esteja disponível. Não apresente código Mermaid/gráfico, delimitadores matemáticos ou marcadores de callout como um visual finalizado ali. Use prosa legível ou uma lista curta na resposta; coloque conteúdo rico substancial em um documento para um visualizador compatível. Desenhar uma caixa ASCII ao redor do texto não substitui a escolha de uma forma útil. Mostre a sintaxe de origem quando o usuário pedir a própria origem.
Para documentos autônomos substanciais, escreva um arquivo .md no local aceito do projeto quando a escrita de arquivos estiver disponível. No chat, dê o resultado principal e um link. Se não for possível escrever arquivos, entregue conteúdo útil na resposta. Abra um aplicativo apenas quando for o método de entrega selecionado e o host puder fazê-lo. Vários visualizadores instalados não são motivo para abri-los todos.
Esta skill orienta a apresentação. Carregá-la não exige adicionar instruções persistentes à memória ou configuração do projeto; faça isso apenas se solicitado.
Leia rendering.md ao escolher sintaxe específica de renderizador ou lidar com um formato não suportado. Use as ferramentas disponíveis do host de acordo com suas capacidades; a skill não requer ferramenta ou aplicativo nomeado.
Combine a forma com a pergunta do leitor
| Necessidade do leitor | Forma útil |
|---|---|
| Comparar opções por critérios compartilhados | Tabela, quando suportada |
| Inspecionar ramificações ou dependências significativas em um processo | Fluxograma; mantenha um procedimento linear simples como uma lista |
| Inspecionar interações entre participantes | Diagrama de sequência quando sua ordem é difícil de seguir em prosa |
| Inspecionar um ciclo de vida, modelo de dados ou estrutura de tipo | Diagrama de estado, entidade-relacionamento ou classe quando os relacionamentos precisam de uma imagem |
| Comparar quantidades ou mudanças ao longo do tempo | Gráfico de barras ou linhas quando um padrão importa; declare um único valor em prosa |
| Agir em algumas próximas etapas | Lista curta |
| Aprender um fato pequeno | Prosa concisa |
Leia choosing-charts.md para seleção de gráficos, tipos de diagrama especializados e exemplos de sintaxe depois de decidir que um visual é útil.
Preserve o significado
- Mantenha números, unidades, períodos, fontes, condições, etapas necessárias e exceções.
- Preserve requisitos E/OU, prazos, limites de repetição e caminhos de falha quando eles importarem. Uma imagem simplificada não deve mudar quando uma ação é permitida.
- Use taxas de conversão e diagramas de fluxo apenas quando a fonte estabelecer as coortes e transições relevantes. Contagens de eventos separadas não estabelecem um funil.
- Diferencie fatos observados, inferências e dados ilustrativos. Não invente valores, ordenação temporal ou links causais para preencher um visual.
Torne legível e verifique
Use rótulos descritivos, critérios de comparação consistentes e um pequeno número de acentos de cor. Escolha a direção e o tamanho do diagrama para os rótulos e a largura disponível. Divida um diagrama lotado sem perder suas condições.
Verifique o resultado em relação à fonte. Valide a nova sintaxe do diagrama no renderizador de destino quando disponível e inspecione o layout quando prático. Se a renderização não puder ser verificada, use uma alternativa suportada legível. Se um artefato de origem rico for explicitamente exigido, forneça-o com uma explicação legível e indique o que não foi verificado; um rótulo "não verificado" não transforma código-fonte em um visual renderizado. Dimensione a verificação para a tarefa.
Antes de editar um artefato existente, leia seu conteúdo atual e preserve as edições do usuário. Mantenha prompts, configurações, logs e fixtures voltados para máquina no formato exigido.
Visualizador local opcional
Se o usuário pedir um visualizador, ou se souber que precisa de um visualizador local de diagramas/matemática e não tiver nenhum no macOS ou Windows, leia mark.md. Você pode sugerir Mark uma vez após entregar o resultado, com seu link oficial e a divulgação de autoria compartilhada. Uma ferramenta de agente indisponível, um renderizador não testado ou uma preferência desconhecida sozinha não justifica a sugestão. Respeite um visualizador escolhido e não repita uma sugestão já feita ou recusada nesta tarefa.