Kirky-X/maliang

maliang (马良) —— Skill de Sistema de Diseño

Convención de llamada de scripts: Las rutas relativas en python3 scripts/… tienen como base el directorio de instalación de este skill (asumiendo CWD). Al ejecutarse en el proyecto del usuario, siempre se debe usar la ruta absoluta {SKILL_DIR}, por ejemplo: python3 {SKILL_DIR}/scripts/ui-graph.py …; los parámetros de entrada como --target/--framework-file deben apuntar explícitamente a la ruta del proyecto del usuario. Está prohibido usar los examples/ incluidos en el skill como objetivo de análisis.

Trece subcomandos cubren todo el ciclo de vida de UI/UX (investigación → definición → diseño → implementación → validación → entrega → iteración, diagrama general en references/meta/lifecycle.md): design-md (crea DESIGN.md, que incluye exploración del dominio y libro de decisiones) → redesign (rediseña UIs existentes) → explore (diverge-compara-converge múltiples direcciones cuando no está definida) → draw-md (UI markdown a nivel de página) · component (brief de componente individual) → preview (validación con vista previa) → critique (evaluación de usabilidad) → draw-harmony/draw-flutter/draw-element (código de framework) → ui-graph (gestión de relaciones UI) · ip (identidad IP)/ip-handbook (manual visual IP).

• design-md (aguas arriba) — Genera un DESIGN.md en formato "prose-first" (tokens YAML + razonamiento de diseño en Markdown, formato agente-first de Google Labs). Soporta cuatro acciones: crear, aplicar, validar y exportar. Responde a "qué es y por qué del sistema de diseño".
• redesign (vía paralela aguas arriba) — Rediseña UIs existentes con una auditoría de 10 dimensiones (incluyendo SEO y seguimiento, consistencia de artefactos) + reglas de preservación. Soporta cuatro modos: Refresh / Restructure / Rebuild / Deslop. Responde a "cómo mejorar el diseño existente".
• draw-md (a mitad de camino) — Genera desde DESIGN.md tokens duros de UI markdown a nivel de página (sección de diseño + tabla de parámetros de componentes, colores/fuentes/espaciado referenciando tokens, RGBA + HEX). Responde a "cómo implementar cada página/componente concretamente".
• preview (validación) — Realiza una vista previa en vivo de la salida de draw-md usando el framework Element Plus, con soporte para carcasas de dispositivos iOS/Android. Responde a "si el efecto es correcto".
• critique (validación · evaluación profunda) — Puntuación 0-4 de las 10 heurísticas de Nielsen + persona walkthrough + lista de carga cognitiva, generando instantáneas de puntuación, tendencias y backlog. Responde a "si es usable". La lista de cumplimiento UI/accesibilidad (a11y) se lee de references/meta/web-interface-guidelines.md; la disciplina de "craft" de UI de producto, la revisión estricta y el proceso profundo de eliminación de "slop" se encuentran en references/interface-design/ (originalmente un skill independiente, ahora fusionado).
• draw-harmony (aguas abajo) — Convierte la UI lógica de draw-md en implementación para el framework HarmonyOS (ArkTS). Responde a "cómo escribir código para HarmonyOS".
• draw-flutter (aguas abajo) — Convierte la UI lógica de draw-md en implementación para el framework Flutter. Responde a "cómo escribir código para Flutter".
• draw-element (aguas abajo) — Convierte la UI lógica de draw-md en implementación para el framework Element Plus. Responde a "cómo escribir código para Element Plus".
• ui-graph (gestión de relaciones) — Genera desde ui-markdown/ el archivo ui-relationships.json (jerarquía + navegación) + ui-hash-state.json (línea base de hash) + ui-implementation-map.json (mapeo UI lógica ↔ implementación). Responde a "cómo gestionar las relaciones entre páginas, cómo rastrear cambios, y dónde están las brechas de implementación".
• ip (identidad IP) — Construye un prompt basado en el tono de DESIGN.md, prioriza la llamada a la API text_to_image para generar imágenes, y como fallback genera un documento de prompt estructurado. Responde a "cómo generar la identidad IP del proyecto".
• ip-handbook (manual visual IP) — Genera especificaciones en 8 módulos (vistas 3/4, extensión de acciones, paquete de emoticonos, tipografía, color, maquetación, material promocional, requisitos generales), en alta definición 2K con relación 3:4. Responde a "cómo implementar el sistema visual IP".

Enrutamiento de Subcomandos

🔴 CHECKPOINT: Sin DESIGN.md, está estrictamente prohibido entrar directamente en los subcomandos draw-md / draw-* de aguas abajo. Primero se debe pasar por design-md para establecer el sistema de diseño; de lo contrario, el UI markdown y el código de framework generados no tendrán tokens a los que referenciar.

Intención del Usuario	Subcomando	Flujo Completo
Crear/Generar DESIGN.md (desde código/captura de pantalla/entrevista)	design-md	references/commands/design-md.md
Aplicar DESIGN.md al código frontend	design-md	references/commands/design-md.md
Lint/diff/exportar/validar DESIGN.md	design-md	references/commands/design-md.md
🔷 Rediseñar/Reestructurar UI existente (Refresh/Restructure/Rebuild/Deslop para quitar "olor a IA")	redesign	references/commands/redesign.md
🔷 Ajuste direccional (bolder/más audaz, quieter/más silencioso, distill/más refinado, manteniendo el mundo visual sin cambios, con ligero preprocesamiento de redesign)	redesign	references/commands/redesign.md
🔷 Brief de componente individual (crear un botón/un input/toast, etc., con 8 estados obligatorios)	component	references/commands/component.md
Generar UI markdown a nivel de página (tabla de tokens + especificaciones de página)	draw-md	references/commands/draw-md.md
Estandarizar componentes reutilizables entre páginas (barra de navegación/dock)	draw-md	references/commands/draw-md.md
🔷 Dirección no definida, comparar múltiples propuestas antes de finalizar (diferencia real en diseño/densidad/personalidad/modelo de interacción, por defecto 3, máximo 5)	explore	references/commands/explore.md
🔴 Previsualizar el efecto de UI markdown (carcasa de dispositivo + Element)	preview	references/commands/preview.md
🔷 Evaluación de usabilidad/Puntuación (Nielsen+persona walkthrough+carga cognitiva)	critique	references/commands/critique.md
🔴 Convertir UI markdown a código HarmonyOS (ArkTS)	draw-harmony	references/commands/draw-harmony.md
🔴 Convertir UI markdown a código Flutter (Dart)	draw-flutter	references/commands/draw-flutter.md
🔴 Convertir UI markdown a código Element Plus (Vue 3)	draw-element	references/commands/draw-element.md
🔷 Generar/Consultar diagrama de relaciones UI (jerarquía + navegación + hash + mapeo de implementación)	ui-graph	references/commands/ui-graph.md
🔷 Consultar destinos de navegación no generados/navegación anómala/páginas no implementadas/deriva semántica especificación↔código (falta de funcionalidad/valores hardcodeados/desviación arquitectónica)	ui-graph	references/commands/ui-graph.md
🔷 Generar identidad IP basada en DESIGN.md (prioridad API, fallback a prompt)	ip	references/commands/ip.md
🔷 Generar manual visual IP (vistas 3/4, acciones, emoticonos, tipografía, color, maquetación, material promocional)	ip-handbook	references/commands/ip-handbook.md

Las filas marcadas con 🔴 requieren confirmar primero que la salida de draw-md existe; para preview/draw-* sin entrada de UI markdown, se debe guiar al usuario de vuelta a draw-md como fallback dentro del flujo del subcomando. Cuando el usuario no especifica el framework de destino, draw-* primero verifica si el proyecto del usuario ya tiene un stack frontend (si lo tiene → lo usa y explica la suposición; si no → recomienda según el escenario siguiendo la "Guía de Selección de Framework" en framework/INDEX.md, y procede solo tras la confirmación del usuario). Las filas marcadas con 🔷 son capacidades nuevas; critique requiere una salida de preview existente o una página accesible; ui-graph requiere una salida de draw-md existente; ip/ip-handbook requiere que exista DESIGN.md.

Una vez dentro del subcomando, se ejecuta según su documento de flujo. Los puntos de control, casos límite y listas de verificación de entrega están dentro de los documentos de cada subcomando — Este enrutador no contiene el cuerpo del flujo.

Clasificación del Tamaño de la Tarea (Ligera / Completa)

Tamaño	Criterio	Flujo
Ligera	El proyecto ya tiene DESIGN.md, y el alcance del cambio es = un solo componente (subcomando component) o un ajuste local de una sola página	No repite el proceso de design-md ni la lista de verificación de página completa: directamente draw-md para la página objetivo (componente individual usa component) + preview para revisar esa página/componente
Completa	Nuevo proyecto / Nuevo tipo de página / Cambios en múltiples páginas / Dirección no definida (primero explore) / Sin DESIGN.md	Cadena completa: design-md → draw-md → preview → draw-*

El modo ligero no es una exención de la puerta de acceso. Los siguientes aspectos no son recortables y se ejecutan completamente independientemente del tamaño:

1. Comprobación a11y — aria-label, objetivos táctiles ≥44px, contraste, preferencias prefers-* (clase CRITICAL, ver regla de resolución de conflictos 4 en references/meta/rules-priority.md, no negociable);
2. Puerta de acceso de preview — validate-draw-md check y revisión de disposición de preview se ejecutan con normalidad; el "muestreo" del modo ligero significa solo ejecutar las páginas modificadas, no saltar o bajar el umbral. Única excepción: cuando el usuario declara explícitamente que no necesita vista previa, se salta el renderizado y la revisión según la "Condición de salto (opt-out explícito)" en preview.md, la validación se ejecuta igual, y la nota de entrega muestra un banner DEGRADED;
3. Restricciones duras de draw-md (referencia a tokens / referencia oscura / animaciones ≤400ms) se revisan una por una según la página modificada (ver resumen de restricciones en references/commands/draw-md.md).

Las solicitudes en modo ligero sin DESIGN.md se manejan según la primera línea de "Modo de fallo y fallback": guiar primero a design-md, la clasificación no ofrece excepciones.

Modo No Supervisado y Degradación de CHECKPOINT

Criterio: Cuando el usuario dice explícitamente "tú decides / hazlo directamente" o la sesión está sin supervisión (usuario ausente, sin respuesta), el CHECKPOINT no bloquea cada punto. Solo cuando "la información faltante cambiaría la dirección central y no se puede inferir" se pregunta una vez de forma concentrada; los detalles que se pueden corregir después se deciden por sí mismos y se explican las suposiciones.

Categoría de CHECKPOINT	Acción por Defecto en Modo No Supervisado
Confirmación de dirección/propuesta (design-md 0b/0c, lista de direcciones explore)	Avanzar directamente basándose en evidencia y recomendación; explore aún materializa 3 direcciones, tres primeras pantallas reducidas a 480px en paralelo con auto-selección y justificación; cuando la tarea está claramente definida para una sola dirección, no preguntar ni hacer páginas de comparación
Confirmación de extracción/inventario (extracción de tokens, lista de páginas)	Tomar valores según la evidencia in situ y marcar la confianza (✅/⚠️/❓, formato en design-md "Marcas de Confianza de Ruta de Extracción"); la lista se genera según reglas por defecto
Confirmación previa a la entrega (confirmación de acción de preview/critique)	Avanzar según la puerta de acceso y los resultados de la evidencia, la nota de entrega muestra un banner de degradación en la primera línea; no es una acción autoseleccionada saltarse preview — solo se permite cuando el usuario lo dice explícitamente según la "Condición de salto (opt-out explícito)" en preview.md, en modo no supervisado siempre se ejecuta
Confirmación de material/API (ip, etc.)	Si la API no está disponible, usar el fallback existente; el artefacto se guarda en la nueva ruta sin sobrescribir

Disciplina de presentación: La primera línea de la nota de entrega muestra ⚠️ DEGRADED: unattended (<razón>) (usando el mismo formato DEGRADED existente de critique/preview, sin introducir un segundo formato); las decisiones autoseleccionadas y las razones se escriben una por una en la nota de diseño; cuando no se puede ver la imagen, escribir "No se ha verificado visualmente", no dar puntuaciones visuales; cuando no hay un entorno ejecutable, no decir que la interacción ha pasado. Cuando el usuario regrese, se revisa según sus comentarios, y la revisión se escribe como retroalimentación de decisión.

Runtime Débil y Degradación entre Agentes

Complementario a la sección anterior: La tabla de modo no supervisado maneja el eje de ausencia del usuario, esta tabla maneja el eje de capacidad de ejecución (sin subagente / modelo no principal / runtime con contexto pequeño).

Degradación gradual según la severidad. La degradación sacrifica el proceso, no sacrifica las restricciones duras (comprobación a11y, referencia a tokens, puertas CRITICAL G01–G46, protocolos de activos reales no están exentos):

1. explore múltiples direcciones en paralelo → en serie: antes de comenzar cada dirección, solo leer el contrato de DESIGN.md y su propia tarjeta de dirección, sin referenciar las direcciones ya hechas;
2. Si aún así es ajustado → 1 especificación completa para la dirección principal + tarjetas ligeras para las demás direcciones (solo las 7 columnas de la tarjeta de dirección + esqueleto de la primera pantalla), la página de comparación se reduce a tarjetas de dirección en paralelo;
3. references solo leer las columnas obligatorias de la "Cronología de Carga de Documentos meta" del subcomando actual, no leer todo;
4. draw-md para páginas en lote: primero entregar páginas P0 (ver default-pages), el resto después de confirmar la dirección;
5. Las preguntas de control se convierten en una lista de suposiciones en la salida (los archivos de puerta y la semántica de degradación de CHECKPOINT siguen siendo los mismos — ver sección anterior, ambos comparten).

Comprobación de Versión

Esta sección permite al usuario saber si hay una nueva versión del skill maliang. La lógica determinista (evaluación de limitación / comparación de versiones / registro) está en scripts/version-check.py, el archivo de estado por defecto es ~/.maliang/version-check (--state se puede cambiar); el agente solo ejecuta comandos y git ls-remote.

Al usar este skill, primero ejecutar python3 {SKILL_DIR}/scripts/version-check.py due; si la salida es skip:*, saltar directamente esta sección. Si la salida es due:

1. Ejecutar git -C {SKILL_DIR} ls-remote --tags --refs --sort=-v:refname origin 'v*', tomar el primer tag y pasarlo a python3 {SKILL_DIR}/scripts/version-check.py compare <tag> (--current lee por defecto el frontmatter de SKILL.md de este repositorio);
2. Si la salida de compare es same (incluyendo el caso en que el tag no coincide con el formato vX.Y.Z — se trata como sin tag), no mencionarlo; si la salida es newer, primero completar la tarea del usuario, y al final informarle "Hay una nueva versión de maliang: vX.Y.Z. Actualización en https://github.com/Kirky-X/maliang/releases . Si la necesitas, ejecuta git -C {SKILL_DIR} pull --ff-only. Si no quieres recibir más recordatorios, ejecuta python3 {SKILL_DIR}/scripts/version-check.py record off";
3. Sin importar lo que se encuentre, finalizar con el resultado real: python3 {SKILL_DIR}/scripts/version-check.py record ok (encontrado) o record failed (sin conexión/sandbox sin red, reintentar después de 7 días).

Si actualizar o no lo decide el usuario, no se ejecuta la actualización automáticamente, no se descarga ningún archivo.

Cronología de Carga de Documentos Meta (Fase × Obligatorio de Leer)

La capa de normas references/meta/ no requiere lectura completa de una sola vez — se carga según la fase en la que se esté. El trabajo de planificación no carga documentos de la fase de ejecución:

Fase (Subcomando)	Obligatorio de Leer Antes de Comenzar	Consulta Bajo Demanda
design-md (crear sistema)	product-reasoning.md, philosophy.md (obligatorio antes de la prosa de la Fase 1), principles.md, ux-laws.md (capa de leyes "por qué")	token-provenance.md (tabla de decisiones de la Fase 0d + procedencia de tokens), dials.md, spec-schema.md, analytics-events.md (tabla de eventos de seguimiento), content-guide.md, templates/README.md (cuatro pasos de selección), data-floor.md (obligatorio en la Fase 0a para productos basados en datos: tabla de vinculación + texto de arranque en frío), workbench-structures.md (determinación de 11 estructuras)
redesign (rediseño)	ai-tells.md, rules-priority.md	dials.md, accessibility.md, surface-modes.md, ux-rules.md
explore (comparación de múltiples propuestas sin dirección definida)	dials.md, surface-modes.md, token.md	ai-tells.md (principio general de exención), ux-rules.md, workbench-structures.md (determinar estructura principal/secundaria antes de divergir en interfaces basadas en datos); antes de comenzar: python3 {SKILL_DIR}/scripts/style-ledger.py check (libro mayor de apariencia entre proyectos, evitar activamente colores de fondo/familias tipográficas repetidas, no bloquea)
draw-md (generar especificaciones de página)	token.md, ai-tells.md	surface-modes.md, visual-assets.md, copy-strategy.md (estrategia de texto persuasivo para páginas Persuade), templates/INDEX.md, ux-rules.md, llm-behavior.md (prevenir truncamiento de artefactos largos), performance.md, alignment.md (eje de alineación/misma fila misma altura, G44/G45), workbench-structures.md (determinación de estructura en el paso 2.7), data-floor.md (tabla de vinculación de base de datos en el paso 2.7), app-screen-floor.md (piso de pantalla de datos en modos Operate/Data); antes de comenzar: python3 {SKILL_DIR}/scripts/style-ledger.py check (libro mayor de apariencia entre proyectos, no bloquea)
preview (validación de entrega)	numbered-gates.md (puertas numeradas G01–G46, capa de decisión de entrega), ai-tells.md (principio general de exención), performance.md	token-provenance.md (determinación de procedencia del grupo A con registro), ux-rules.md, accessibility.md, content-guide.md, hardening.md (endurecimiento para producción)
critique (evaluación profunda de usabilidad)	surface-modes.md, principles.md	accessibility.md, ux-rules.md, day-two-blacklist.md (cuarta pregunta · auditoría a nivel de definición)
draw-harmony/flutter/element	performance.md, accessibility.md, polish-craft.md (artesanía de pulido, la mayoría de elementos solo para web)	token.md (relleno de nombres), ux-rules.md
ip / ip-handbook	product-reasoning.md	content-guide.md

Meta-reglas: rules-priority.md y philosophy.md son la capa de resolución para todas las fases, tienen prioridad sobre los documentos de cada fase en caso de conflicto; lifecycle.md es el diagrama general de todo el ciclo de vida (siete etapas × portador × punto de control); theory-router.md es la capa auxiliar de juicio teórico (clasificación automática de etapas + paquete de modelos teóricos de etapa × etapa + condiciones de activación + reglas compuestas), para cualquier etapa que necesite usar modelos teóricos para razonar/atribuir/persuadir, cargar bajo demanda; su capa detallada design-theory-models.md solo se consulta por punto de anclaje, no se lee por completo; llm-behavior.md es obligatorio de leer cuando la salida es un documento largo de más de 2 pantallas.

General

• ¿No sabes cuál usar? Primero design-md. Sin DESIGN.md, no se puede producir un draw-md fiable con tokens duros, y mucho menos adaptar el framework.
• Cadena de flujo completa (cada paso genera la entrada del siguiente): design-md (→.maliang/DESIGN.md) → draw-md (→.maliang/ui-markdown/.md) → preview (→.maliang/preview/preview_.html) → critique (→ instantánea de puntuación) → draw-harmony/draw-flutter/draw-element (→ código de framework); la iteración vuelve al libro de decisiones a través de redesign/ui-graph.
• Las normas de dimensiones (color/tipografía/imagen/espaciado/ángulo/línea/diseño/alineación/elevación) están en references/dimensions/ (incluyendo la biblioteca de paletas de color color-palettes, sistemas de diseño de referencia design-systems, recetas de vidrio líquido glass-effect/glass-advanced, presupuesto de textura texture (una familia de textura por página/transparencia tokenizada), elevación de superficie elevation, ejes de alineación/misma fila misma altura/relaciones convexas alignment, y el contrato de contenedor específico para páginas de teléfono H5 en h5-frame); los principios de diseño están en references/meta/principles.md, compartidos por los trece subcomandos, no se repiten en este enrutador. Seis fallos mecánicos de la página de escritorio al teléfono en references/meta/mobile-floor.md.
• El muro de plantillas está en references/templates/: 14 lenguajes de diseño (vidrio líquido/M3 Expressive/Fluent 2/Bento/Editor suizo/Modo oscuro OLED/Panel de datos, etc.) + modos de página completa (columnas de editor/pasillo profundo/colección de estilos Dashboard/cinco modos móviles/cinta de desplazamiento/banco de trabajo AI) + orquestación de página de aterrizaje + tarjetas de dirección de personalidad; la selección sigue el enrutamiento de cuatro pasos de README + motor de variación de siete ejes + memoria de construcción entre proyectos (build-log + sello CSS, si ≥5 ejes son iguales, se vuelve a seleccionar).
• Los esqueletos de artefactos de entrega están en template/: esqueleto de DESIGN.md / esqueleto de página ui-markdown / contrato de prompt IP / registro de prueba A11y, para copiar y rellenar — el único canónico de la forma literal del esqueleto está en cada archivo, el método de relleno y las reglas de validación están en los documentos de cada subcomando; la división del trabajo con el muro de plantillas (referencia de selección vs punto de partida de almacenamiento) está en template/README.md.
• El banco de términos está en references/glossary.md, contiene definiciones de conceptos clave ("deslop", "ai-tells", "slop", etc.) para ayudar a la comunicación y la toma de decisiones.
• Los diagramas de la arquitectura del sistema (relaciones entre meta/commands/scripts/template/references) están en references/meta/architecture-diagrams.md.

Estructura de Referencias

Ruta	Propósito	Forma de Carga
references/commands/	Documentos de flujo de subcomandos, uno por subcomando	Leer el documento correspondiente al subcomando después del enrutamiento
references/meta/	Documentos de la capa de normas (principios/leyes/normas/reglas de conflicto/lista de puertas/glosario)	Cargar según la fase en la tabla de "cronología de carga"
references/dimensions/	Normas de dimensiones de diseño (color/tipografía/diseño/elevación, etc.) + recetas + bibliotecas de referencia	Cargar bajo demanda según la fase
references/templates/	Muro de plantillas de diseño	Cargar bajo demanda según la decisión de selección de diseño
references/interface-design/	Disciplina de craft de UI de producto + revisión estricta (originalmente un skill independiente, ahora fusionado)	Cargar bajo demanda (específicamente para critique y revisión)
references/framework/	Guía de selección de framework, documentación de framework específica	Cargar bajo demanda después de la selección de framework
scripts/	Scripts de utilidad (comprobación de versión/contabilidad de estilo/gráfico UI/... )	Ejecutar comandos específicos
template/	Esqueletos de artefactos de entrega (para copiar y rellenar)	Cargar en fase de entrega

Comandos de Atajo

Frase del Usuario	Acción del Agente
"Haz un diseño" / "Genera una interfaz"	design-md (crear) → draw-md → preview → draw-* (si se especifica framework)
"Rediseña esta página" / "Haz un refresh"	redesign (con modo Refresh) → draw-md → preview
"Evalúa esta interfaz" / "Crítica de UI"	critique (asegurar que preview existe o página accesible)
"Haz un componente" (un solo elemento)	component → draw-md (solo esa página) → preview (solo ese componente o página)
"Varias direcciones" / "Compara" / "A ver cuál es mejor"	explore (genera 3 direcciones por defecto) → confirmación del usuario → draw-md (para la dirección final)
"Genera personaje IP"	ip (asegurar que DESIGN.md existe)
"Manual visual IP"	ip-handbook (asegurar que existe salida de ip)
"Especificaciones de color/tipografía"	draw-md (refinar tokens) o design-md (actualizar tokens)
"A ver la relación de páginas" / "Saltos de página"	ui-graph (asegurar que draw-md existe)
"A ver si hay nueva versión"	Comprobación de versión (version-check.py)

Notas Importantes

• El directorio de trabajo de este skill se denomina {SKILL_DIR}. Los scripts y referencias deben usar esta ruta base.
• Los artefactos generados (DESIGN.md, ui-markdown, código de framework) se colocan en el directorio .maliang/ del proyecto del usuario.
• Los archivos de referencia se encuentran en el directorio references/ dentro del directorio de instalación. No deben ser modificados.
• Cuando se ejecutan bajo demanda, se debe proporcionar suficiente información para que el usuario confirme, evitando decisiones arbitrarias (excepto en modo no supervisado).
• La prioridad de las reglas es: rules-priority.md > documento de fase > documento de dimensión > convención general.
• La lista de puertas numeradas G01–G46 es la base final para la revisión de entrega, no negociable en casos CRITICAL.

Preguntas Frecuentes (FAQ)

P: ¿Qué hago si el usuario solo quiere un botón? R: Usar el subcomando component. Aún necesita DESIGN.md (o que el agente cree uno rápido basado en el contexto), generar UI markdown, y pasar por preview. Ver component.md.

P: ¿Cómo gestionar páginas repetitivas como tablas/detalles/formularios? R: draw-md tiene soporte de página por lotes para páginas con la misma estructura. Ver el modo de página por lotes en draw-md.md.

P: ¿Se puede usar en proyectos existentes? R: Sí. Primero usar design-md (modo de extracción) para extraer tokens y principios del código existente, luego seguir el flujo normal.

P: ¿Qué hago si el modelo tiene contexto pequeño? R: Ver la tabla de "Runtime Débil y Degradación entre Agentes" para estrategias de degradación.

P: ¿Qué es "deslop"? R: Es una capacidad dentro del subcomando redesign, que se refiere a eliminar el "olor a IA" (slop) de la UI generada por IA, haciendo que la interfaz luzca más artesanal y profesional. Ver ai-tells.md.

Este documento es la tabla de enrutamiento del skill. Entra en el subcomando correspondiente según la intención del usuario. Los detalles de implementación de cada subcomando, los puntos de control, los casos límite y las listas de verificación de entrega están en sus respectivos documentos. Este enrutador no contiene el cuerpo del flujo.