yamcodes/arkenv

Hallmark

Una skill de diseño para asistentes de codificación con IA. Hace que las UI que generen luzcan hechas, no generadas.

Hallmark es dogmática, breve y aburrida a propósito. Codifica un conjunto estricto de reglas, extraídas del consenso del campo del diseño anti-borrosidad de IA (la skill de diseño frontend de Anthropic, el libro de cocina de Claude sobre estética frontend y el movimiento de "rebelión táctil" de 2026) y se niega a permitir que el modelo recurra a los valores predeterminados en los que todo LLM fue entrenado.

El diferenciador: Hallmark insiste en la variedad estructural, no solo en la variedad visual. Dos páginas generadas por Hallmark para dos resúmenes diferentes no deberían compartir el mismo ritmo de héroe → 3 características → CTA → pie de página. Deberían sentirse como sitios diferentes, no como cambios de color del mismo template. Consulta references/structure.md.

Desarrollado por Together AI.

---

Cómo usar esta skill

Hallmark tiene un comportamiento predeterminado y tres verbos explícitos.

Invocación	Qué hace
(predeterminado)	El usuario te pidió que diseñes o construyas algo nuevo. Sigue el Flujo de diseño a continuación.
hallmark audit <objetivo>	Lee el objetivo, evalúalo contra la lista de anti-patrones y devuelve una lista priorizada de correcciones. No edites.
hallmark redesign <objetivo> [--mood <nombre>]	Toma el contenido y la intención del objetivo, luego rediseña la estructura visual dentro de los límites de implementación existentes a menos que el usuario confirme explícitamente una reconstrucción completa. Nuevo ritmo de sección, nueva colocación de encabezados, nueva voz de componentes. Preserva las rutas existentes, la propiedad de los componentes, la intención de la copia, la marca y la arquitectura de la información; reemplaza solo la capa visual/interactiva necesaria para el alcance solicitado.
`hallmark study <captura	URL>`

Si el usuario escribe algo que no se correlaciona claramente con audit, redesign o study, trátalo como predeterminado. Si el usuario adjunta una imagen o pega una URL sin un prefijo de verbo, pregunta: "¿Debería study esto (extraer el ADN) o debería tratarlo como referencia para una nueva construcción?"

Barra de seguridad de implementación. Hallmark es una skill de diseño, no una licencia para arrasar un código base. En cualquier proyecto existente:

• Nunca elimines archivos de producción, árboles de rutas, directorios de componentes o un sitio web antiguo a menos que el usuario solicite explícitamente la eliminación o apruebe un plan a nivel de archivo que enumere las eliminaciones.
• Por defecto, edita en el lugar los archivos nombrados, o agrega nuevos componentes/tokens que se conecten a través de la ruta existente. Si el rediseño requiriera eliminar múltiples componentes, detente y pide confirmación primero.
• Trata los PDF, archivos README, resúmenes .md, documentos, transcripciones y presentaciones como material de referencia. No los copies palabra por palabra en la página a menos que el usuario diga explícitamente que uses ese texto textualmente.
• Antes de editar, indica los archivos exactos que esperas modificar/crear/eliminar. Las eliminaciones requieren confirmación explícita.

El flujo de diseño predeterminado siempre elige un tema. Por defecto, elige uno de los 20 temas nombrados - el catálogo - y rota entre ellos según la regla de diversificación. También hay una rama personalizada silenciosa que construye una paleta OKLCH única + combinación de fuente gratuita para el resumen; la ruta personalizada se activa solo cuando el resumen lleva una señal de intención creativa (el usuario nombra un color de marca, nombra una vibra de múltiples atributos que el catálogo no puede soportar, o solicita explícitamente un tema personalizado). Para resúmenes simples, el usuario nunca ve las palabras "catálogo" o "personalizado" - el catálogo se ejecuta en silencio. Consulta el Paso 1 (detección de señal) y el Paso 2.6 (despacho); el protocolo vive en references/custom-theme.md.

---

Disciplinas que se aplican a cada verbo

Estas seis disciplinas no son específicas de un verbo. Se aplican al Diseño predeterminado, audit, redesign, study y al ámbito de componentes por igual. Se sitúan junto a la prueba de borrosidad, no dentro de una rama de la misma.

1. Autocrítica previa a la emisión. Antes de devolver cualquier salida, evalúala del 1 al 5 en seis ejes: Filosofía, Jerarquía, Ejecución, Especificidad, Moderación, Variedad. Cualquier < 3 desencadena una ronda de revisión. Estampa los seis puntajes en la parte superior del artefacto (/* Hallmark · autocrítica previa a la emisión: P5 H4 E5 S4 R5 V5 */). Consulta references/slop-test.md § Autocrítica previa a la emisión.

2. Copia honesta - sin contenido inventado. Si el usuario no proporcionó una métrica, no inventes una. Los diseños basados en estadísticas, filas de comparación y barras de prueba deben usar números reales, un marcador de posición (— más un bloque gris etiquetado, "métrica a confirmar"), o una macroestructura diferente. "+47 % de conversión", "confiado por más de 50,000 equipos" y "10 veces más rápido" son borrosidad en el momento en que se inventan. Misma regla para testimonios, logotipos y recuentos de casos de estudio. Consulta references/anti-patterns.md § Métricas inventadas y la compuerta de prueba de borrosidad 46.

3. Tokens bloqueados - sin improvisación a mitad de renderizado. Una vez que se selecciona un tema en el Paso 2.6, cada color y cada declaración font-family en el artefacto debe hacer referencia a un token nombrado (var(--color-accent), font-family: var(--font-display)). No se permiten valores OKLCH / hex / rgb() en línea, ni una declaración font-family: "Some Font" que omita el bloque de tokens. Si se necesita un valor que no existe como token, súbelo al bloque de tokens como una nueva variable nombrada, luego haz referencia a ella. Consulta references/anti-patterns.md § Improvisación de tokens a mitad de renderizado y la compuerta de prueba de borrosidad 48.

4. Chrome redibujado prohibido. Hallmark no debe construir manualmente barras de navegador falsas (píldora de URL + puntos de semáforo), marcos de teléfono falsos, ventanas de bloque de código falsas (barra de título simulada + puntos que envuelven un <pre>), o chrome IDE falso; el entorno del usuario ya proporciona chrome real. Utiliza capturas de pantalla reales envueltas en un <figure> (con, como máximo, un borde fino), u omite el chrome y deja que el contenido se sostenga por sí solo. Consulta references/anti-patterns.md § Chrome de UI redibujado y la compuerta de prueba de borrosidad 47.

5. Responsividad móvil - cada emisión verificada a 320 / 375 / 414 / 768 px. La salida de Hallmark debe renderizarse perfectamente en los cuatro anchos. Los no negociables: sin desplazamiento horizontal + overflow-x: clip raíz tanto en html como en body, nunca hidden (compuerta 34); sin texto clicable de dos líneas - botones, enlaces de navegación primaria, enlaces de pie de página, migas de pan, CTA (compuerta 49); las pistas de cuadrícula con imágenes usan minmax(0, 1fr), nunca 1fr simple (compuerta 50); los encabezados de visualización envuelven palabras largas mediante overflow-wrap: anywhere; min-width: 0 (compuerta 51); los encabezados de sección colapsan a una columna en móvil en todas las variantes de tema (compuerta 52); los patrones de pestañas de radio no saltan al desplazarse (compuerta 53). Consulta references/responsive.md § Móvil - no negociable. Esto es un piso duro, no una lista de deseos.

6. Pureza tipográfica - sin encabezados en cursiva. Los encabezados y el tipo de visualización son siempre romanos (font-style: normal). Una palabra enfatizada en cursiva dentro de un encabezado por lo demás vertical (Built to <em>think</em>) es una de las señales de IA más confiables; también lo es una cara de visualización totalmente en cursiva en los encabezados. Transmite énfasis con peso, color de acento o un subrayado dibujado. La cursiva sobrevive