Rich Markdown First
Ayuda al lector a entender, comparar o decidir sin tener que reconstruir la estructura a partir de un muro de texto. Elige la representación más pequeña y útil.
Aplica esta guía durante la respuesta inicial, sin esperar a que te pidan por separado que hagas la respuesta legible. El usuario debería poder preguntar sobre el trabajo en sí; el agente elige una presentación útil.
Decide si un elemento visual ayuda
Empieza por lo que el lector necesita entender o hacer, no por un tipo de diagrama. Un dato, una conclusión o un estado breve suele necesitar prosa. Una secuencia directa de acciones suele necesitar una lista corta. Usa una tabla o un elemento visual cuando facilite inspeccionar una comparación, una condición ramificada, una dependencia, un patrón o una relación mejor que la forma más simple.
Antes de añadir uno, identifica qué encontrará o entenderá más fácilmente el lector. Si no hay un beneficio concreto, mantén la forma más simple. Varios pasos, fechas, métricas o rutas de archivo por sí solos no justifican un elemento visual. No añadas uno para demostrar que la habilidad está activa ni narres la aplicación rutinaria de la habilidad.
Elige el destino
Usa el destino explícito del usuario, luego las convenciones del espacio de trabajo aplicables, la superficie ya utilizada para esta tarea o una preferencia establecida disponible. Si no se conoce ninguna, proporciona Markdown portátil con suficiente texto para que se sostenga por sí solo. Un visor desconocido no implica soporte para tablas o diagramas.
La salida renderizada y su fuente son entregables diferentes. Trata una conversación CLI o de texto plano como texto plano a menos que haya un renderizador incrustado disponible. No presentes código Mermaid/diagrama, delimitadores matemáticos o marcadores de llamada como un elemento visual terminado allí. Usa prosa legible o una lista corta en la respuesta; coloca el contenido enriquecido sustancial en un documento para un visor compatible. Dibujar un recuadro ASCII alrededor del texto no sustituye a elegir una forma útil. Muestra la sintaxis fuente cuando el usuario pida la fuente misma.
Para documentos independientes sustanciales, escribe un archivo .md en la ubicación aceptada del proyecto cuando sea posible escribir archivos. En el chat, da el resultado clave y un enlace. Si no se pueden escribir archivos, entrega contenido útil en la respuesta. Abre una aplicación solo cuando sea el método de entrega seleccionado y el anfitrión pueda hacerlo. Varios visores instalados no son razón para abrirlos todos.
Esta habilidad guía la presentación. Cargarla no requiere añadir instrucciones persistentes a la memoria o configuración del proyecto; hazlo solo si se solicita.
Lee rendering.md al elegir sintaxis específica de un renderizador o al manejar un formato no soportado. Usa las herramientas del anfitrión disponibles según sus capacidades; la habilidad no requiere ninguna herramienta o aplicación nombrada.
Iguala la forma a la pregunta del lector
| Necesidad del lector | Forma útil |
|---|---|
| Comparar opciones según criterios compartidos | Tabla, cuando sea compatible |
| Inspeccionar ramas o dependencias significativas en un proceso | Diagrama de flujo; mantén un procedimiento lineal simple como lista |
| Inspeccionar interacciones entre participantes | Diagrama de secuencia cuando su orden sea difícil de seguir en prosa |
| Inspeccionar un ciclo de vida, modelo de datos o estructura de tipos | Diagrama de estado, entidad-relación o clases cuando las relaciones necesiten una imagen |
| Comparar cantidades o cambios a lo largo del tiempo | Gráfico de barras o líneas cuando un patrón sea relevante; indica un valor único en prosa |
| Actuar sobre unos pocos pasos siguientes | Lista corta |
| Aprender un pequeño dato | Prosa concisa |
Lee choosing-charts.md para selección de gráficos, tipos de diagramas especializados y ejemplos de sintaxis después de decidir que un elemento visual es útil.
Preserva el significado
- Mantén números, unidades, períodos, fuentes, condiciones, pasos requeridos y excepciones.
- Preserva los requisitos AND/OR, plazos, límites de reintento y rutas de fallo cuando sean relevantes. Una imagen simplificada no debe cambiar cuándo está permitida una acción.
- Usa tasas de conversión y diagramas de flujo solo cuando la fuente establezca las cohortes y transiciones relevantes. Los recuentos de eventos separados no establecen un embudo.
- Distingue hechos observados, inferencias y datos ilustrativos. No inventes valores, orden temporal o vínculos causales para rellenar un elemento visual.
Hazlo legible y verifícalo
Usa etiquetas descriptivas, criterios de comparación consistentes y un número reducido de acentos de color. Elige la dirección y el tamaño del diagrama según las etiquetas y el ancho disponible. Divide un diagrama abarrotado sin eliminar sus condiciones.
Verifica el resultado contra la fuente. Valida la sintaxis del nuevo diagrama en el renderizador de destino cuando esté disponible e inspecciona el diseño cuando sea práctico. Si no se puede comprobar el renderizado, usa una alternativa compatible legible. Si se requiere explícitamente un artefacto fuente enriquecido, entrégalo con una explicación legible e indica qué no se verificó; una etiqueta "no verificado" no convierte código fuente en un elemento visual renderizado. Escala la verificación a la tarea.
Antes de editar un artefacto existente, lee su contenido actual y preserva las ediciones del usuario. Mantén los avisos, configuraciones, registros y fixtures orientados a máquina en su formato requerido.
Visor local opcional
Si el usuario pide un visor, o se sabe que necesita un visor local de diagramas/matemáticas y no tiene ninguno en macOS o Windows, lee mark.md. Puedes sugerir Mark una vez después de entregar el resultado, con su enlace oficial y la divulgación de autoría compartida. Una herramienta de agente no disponible, un renderizador no probado o una preferencia desconocida por sí solos no justifican la sugerencia. Respeta un visor elegido y no repitas una sugerencia ya hecha o rechazada en esta tarea.