Claude Code ha incorporado discretamente /artifact-diagramming, una nueva skill orientada a convertir explicaciones técnicas en diagramas dentro de Artifacts. La función resulta especialmente interesante porque no busca dibujar simples esquemas con componentes conectados, sino representar el mecanismo real que se quiere explicar: por dónde circulan los datos, qué componente escribe sobre otro, dónde cambia una petición o qué ocurre cuando falla una pieza del sistema.
Las claves de los diagramas de Claude Code en 20 segundos
- La skill aparece como
/artifact-diagrammingen versiones recientes de Claude Code. - Está pensada para generar diagramas que expliquen mecanismos, flujos y relaciones dentro de Artifacts.
- Puede recibir la petición directamente después del comando.
- En HTML puede recurrir a SVG integrado, sin necesitar un servidor MCP externo para dibujar.
- Anthropic documenta Artifacts, pero la información pública sobre esta skill concreta sigue siendo limitada.
La novedad encaja con una evolución más amplia de Claude Code. Artifacts permite transformar el trabajo realizado desde una sesión del asistente de programación en páginas web interactivas alojadas en Claude.ai, que pueden mantenerse privadas o compartirse según el tipo de cuenta. Anthropic los plantea para casos como explicar pull requests, mostrar investigaciones o presentar información que resulta incómoda de consumir directamente desde el terminal.
El problema aparece cuando esos artefactos vuelven a convertirse en documentos enormes. Una explicación de arquitectura de varios cientos de líneas puede estar mejor presentada que la salida original del terminal y seguir siendo difícil de comprender.
Ahí es donde los diagramas empiezan a tener sentido.
/artifact-diagramming: dibujar el mecanismo y no el componente
La idea detrás de la nueva skill es sencilla: un rectángulo que dice «cache» explica muy poco.
Un diagrama donde se observa que una petición consulta primero esa caché, continúa hacia un almacenamiento cuando se produce un fallo y muestra posteriormente cómo se invalida la entrada explica realmente el comportamiento del sistema.
La diferencia puede parecer menor, pero afecta directamente a la utilidad de los diagramas generados mediante IA.
Los LLM tienden a producir diagramas arquitectónicos donde cada tecnología acaba convertida en una caja:
Usuario
|
v
API
|
v
Cache
|
v
DatabaseEl dibujo ordena los componentes, pero apenas aporta información que no pudiera comunicarse con una frase.
Un esquema útil debería mostrar cuestiones como qué datos pasan entre ellos, qué ocurre cuando la caché responde, cuál es el camino alternativo cuando no encuentra el dato, quién escribe posteriormente el resultado y qué componente provoca su invalidación.
/artifact-diagramming intenta orientar a Claude precisamente hacia ese segundo tipo de representación.
La filosofía puede resumirse en varias reglas: dibujar mecanismos en lugar de nombres, representar la diferencia cuando se comparan alternativas, etiquetar las flechas y ajustar la complejidad del dibujo a la complejidad real del problema.
También introduce una restricción saludable para un modelo generativo: si una frase explica algo mejor que un diagrama, debe utilizarse la frase.
El detalle poco evidente está en cómo se utiliza
Ejecutar simplemente:
/artifact-diagrammingno equivale necesariamente a pedir un dibujo concreto.
La skill funciona como una instrucción especializada que proporciona a Claude criterios sobre cómo debe construir este tipo de contenido. Para sacarle más partido puede añadirse el problema que debe representar después del propio comando.
Por ejemplo:
/artifact-diagramming muestra cómo una petición consulta Redis,
qué ocurre en un cache miss, cómo llega a PostgreSQL
y quién invalida posteriormente la entrada almacenadaEsta forma de escribir el prompt tiene otra ventaja: obliga al desarrollador a pensar qué quiere demostrar.
Pedir «un diagrama de esta arquitectura» puede terminar produciendo una colección de componentes.
Pedir «muestra qué ocurre con una petición cuando Redis no contiene el dato y cómo se actualiza después la caché» define un mecanismo.
La diferencia entre ambos prompts parece pequeña, pero el resultado visual puede ser completamente distinto.
SVG y Mermaid sin convertir el diagrama en otra infraestructura
Otro aspecto interesante es que utilizar esta capacidad no implica necesariamente desplegar herramientas externas de diagramación.
Mermaid lleva tiempo siendo una de las soluciones habituales para generar diagramas desde texto. También es frecuente encontrar desarrolladores que conectan Claude Code con Mermaid, Draw.io, Excalidraw o herramientas especializadas mediante Model Context Protocol (MCP).
La comunidad de Claude Code utiliza precisamente Mermaid, HTML y SVG como algunas de las alternativas más habituales para documentar arquitecturas generadas por agentes.
Pero para diagramas integrados en una página HTML, Claude puede generar directamente SVG.
Eso permite construir una figura mediante elementos estándar como rect, circle, line, path y text, manteniendo todo dentro del propio artefacto.
La aproximación tiene ventajas técnicas.
SVG es vectorial, por lo que mantiene la nitidez independientemente de la resolución. También puede adaptarse al tema visual mediante propiedades CSS como currentColor, no necesita una imagen rasterizada y permite que el gráfico forme parte de la propia estructura HTML.
Además, elimina una dependencia.
Si el objetivo es únicamente explicar visualmente una arquitectura dentro de un Artifact, desplegar un servidor MCP exclusivamente para generar el dibujo puede añadir más complejidad de la que resuelve.
Artifacts empieza a parecerse a una capa de documentación técnica
La aparición de esta skill también muestra hacia dónde está evolucionando Claude Code.
Artifacts convierte resultados de una sesión en páginas web interactivas que pueden actualizarse y compartirse, en lugar de dejar todo el trabajo atrapado en el historial del terminal. Anthropic ha ampliado además su disponibilidad a los planes Pro y Max, además de Team y Enterprise.
Esto permite imaginar un flujo bastante diferente al tradicional.
Un desarrollador puede pedir a Claude que investigue un repositorio, seguir dependencias, analizar el recorrido de una petición y publicar después un Artifact donde se combinen explicaciones, fragmentos de código y diagramas.
El resultado puede ser mucho más útil para una revisión técnica que cientos de líneas generadas en Markdown.
También puede servir antes de modificar el código.
Por ejemplo, ante una migración de arquitectura podría pedirse al agente que represente el flujo actual y el propuesto. Si el diagrama no permite explicar claramente dónde se escribe un dato, qué sistema mantiene el estado o qué ocurre durante un fallo, probablemente todavía falte comprender alguna parte del diseño.
El dibujo pasa así de ser documentación posterior a convertirse en una herramienta para comprobar el razonamiento arquitectónico antes de ejecutar cambios.
El límite sigue estando en saber cuándo no dibujar
La generación automática introduce una tentación evidente: convertir cualquier explicación en un gráfico.
Eso tampoco mejora necesariamente la documentación.
Una relación sencilla entre dos componentes puede explicarse mejor con una línea de texto. Añadir cinco cajas, seis flechas y una leyenda solo aumenta el tiempo necesario para entenderla.
Los diagramas tienen más valor cuando existe un recorrido que seguir, varias rutas posibles, cambios de estado, fronteras de seguridad, procesos asíncronos o diferencias arquitectónicas difíciles de reconstruir mentalmente desde el texto.
Una arquitectura de microservicios, una estrategia de caché, el funcionamiento de una cola, un proceso de autenticación, una replicación de bases de datos o el comportamiento de una aplicación después de un reload son buenos candidatos.
Una lista de tecnologías probablemente no lo sea.
Ese criterio puede acabar siendo más importante que la propia capacidad técnica de Claude para generar SVG.
Los modelos ya podían escribir SVG, HTML o Mermaid antes de /artifact-diagramming. La diferencia está en proporcionarles unas reglas específicas para decidir qué merece dibujarse y qué información debe contener el dibujo.
Una función todavía poco visible
Conviene separar lo documentado oficialmente de lo observado en Claude Code.
Anthropic sí mantiene documentación pública sobre Artifacts y sus requisitos, funcionamiento y posibilidades de publicación. La compañía explica que estas páginas pueden utilizarse para transformar resultados de una sesión en una representación visual e interactiva.
Sin embargo, /artifact-diagramming todavía tiene una presencia pública mucho menor. Las búsquedas en la documentación oficial no ofrecen actualmente una página equivalente dedicada específicamente a esta skill.
Eso explica que pueda pasar desapercibida incluso para usuarios habituales de Claude Code.
También aconseja cierta prudencia con detalles internos de implementación que pueden cambiar rápidamente entre versiones.
Lo interesante para los desarrolladores no es tanto que Anthropic haya añadido otro comando al menú, sino la idea que introduce: la salida de un agente de programación no tiene por qué terminar siendo otra pared de Markdown.
Cuando Claude necesita explicar un sistema complejo, ahora dispone de instrucciones específicas para convertir parte de ese razonamiento en una representación visual.
Y en arquitectura de software, entender correctamente tres flechas puede ahorrar bastante más tiempo que leer otras cien líneas generadas por una IA.
Preguntas frecuentes
¿Qué es /artifact-diagramming en Claude Code?
Es una skill disponible en versiones recientes de Claude Code que proporciona instrucciones especializadas para crear diagramas útiles dentro de Artifacts, con especial atención a representar mecanismos y flujos en lugar de simples cajas con nombres.
¿Hay que instalar Mermaid MCP para utilizarla?
No necesariamente. Claude puede generar diagramas mediante SVG directamente dentro de un Artifact HTML. Mermaid continúa siendo útil para documentación basada en Markdown y otros flujos de trabajo.
¿Cómo se puede pedir un diagrama?
El encargo puede escribirse después de /artifact-diagramming. Resulta más efectivo explicar qué comportamiento o decisión debe aclarar el dibujo que limitarse a pedir «un diagrama de la arquitectura».
¿Para qué resultan útiles estos diagramas?
Especialmente para flujos de datos, sistemas de caché, colas, autenticación, arquitecturas distribuidas, migraciones, estados de una aplicación y otros procesos donde comprender las relaciones entre componentes resulta más difícil mediante texto.
