Hallmark vs Impeccable: 118.552 estrellas, 259 watchers y el linter de cada uno suspende la vitrina del otro

Dos repositorios que prometen arreglar el mismo problema: los agentes de código producen páginas frontend que se notan generadas. Ambos publican una skill en markdown para Claude Code, Codex, Cursor y una lista creciente de harnesses. Ambos publican un linter determinista que corre sin modelo y sin clave de API. Entre los dos suman 118.552 estrellas en GitHub.

Tienen 259 watchers.

Esa proporción —0,22%— es lo primero que conviene entender de esta categoría. Una estrella es un marcador; un watcher es alguien que pidió que le avisaran cuando la cosa cambie. Una skill de diseño con 86.410 estrellas y 197 watchers es una skill que mucha gente instaló una vez.

Así que hice lo que los dos productos invitan a hacer y ninguno documenta: pasé el linter de cada uno contra la vitrina del otro, en un navegador real, y después repetí mis propias mediciones fuera de ambos programas.

El resultado no es una historia de ganador único. Son dos productos genuinamente competentes con puntos ciegos complementarios, y un fallo de medición que importa más que los dos.

Qué es cada uno en realidad

Hallmark (Nutlope, MIT, creado el 2026-04-27) es un sistema visual curado más un suelo mínimo. Su SKILL.md enumera 16 reglas numeradas descritas como «Binds every output in every harness, none of it waivable, even when nothing else is read» («Ata toda salida en todo harness, nada de eso es renunciable, incluso cuando no se lee nada más»). La primera regla es que cada color y cada tipografía pasan por un token declarado en :root. El linter es skills/hallmark/scripts/sloplint.mjs, un script Node 18+ sin dependencias que lee HTML/CSS/JSX/TSX/Vue/Svelte y, con --render, maneja un Chrome real a varios anchos de ventana.

La carga de diseño son 48 temas, cada uno un fichero de menos de 8 KB con una fotografía de referencia al lado, más 21 «macroestructuras» y un gates.md de 39.061 bytes que clasifica las comprobaciones en niveles Floor, Reflex y Finish.

Impeccable (Paul Bakaus, Apache-2.0, creado el 2025-11-16) es un motor en Rust más un vocabulario de comandos. Una skill, 24 comandos (craft, polish, audit, critique, distill, harden, live…) y 62 reglas de detección deterministas. El motor es un único binario; la CLI es un envoltorio fino sobre él. impeccable detect analiza ficheros o una URL renderizada; --json para salida de máquina, --github para anotaciones en Actions.

Su README es explícito sobre el linaje: «Anthropic’s frontend-design was the first widely-used design skill for Claude. Impeccable started from there».

Los dos son software de verdad. Ninguno es un volcado de prompts con un README.

Qué descargas exactamente

El tamaño del repositorio es el número equivocado para comparar, y ambos proyectos facilitan mirar el equivocado. Este es el árbol de trabajo que cloné el 2026-10-25, y lo que un usuario instala de verdad.

Los 64,9 MB de Hallmark no son una skill de diseño. Son una skill de diseño más la fototeca de su propio sitio de marketing: sólo site/themes/*/photos/ son 122 ficheros y 46.267.651 bytes. La barra de lenguajes de GitHub nunca muestra esto, porque cuenta código, no fotografías: la barra lateral dice «CSS 43.3%, HTML 37.4%, JavaScript 18.1%», y el 80,6% de los bytes son JPEG.

La duplicación de Impeccable es peor de lo que parece e igual de invisible. El repositorio versiona el mismo árbol de skill una vez por cada harness soportado:

22 × 1.100.013 B  font-index.json idéntico (sha256 47edbdfa…)  = 24.200.286 B
20 × ≈2.195.400 B copias de proveedor de skills/impeccable/     = ≈43,9 MB
26 × ficheros SKILL.md / SKILL.src.md versionados

Veintidós copias byte a byte idénticas de un índice de fuentes son 24,2 MB: el 79% de todos los bytes JSON del repositorio. AGENTS.md es honesto sobre el mecanismo: esas carpetas raíz de harness «are generated distribution artifacts that are tracked for direct repo installs, not hand-authored source». Un job de CI (sync-generated-output.yml) las regenera y las vuelve a commitear. Es una decisión defendible para usuarios de npx skills y de submódulos. Siguen siendo 24 MB del mismo fichero.

Ninguno de los dos números cambia lo que hace la herramienta. Los dos importan cuando haces git clone de un repositorio de 32.000 o 86.000 estrellas porque una entrada de blog te dijo que leyeras el código.

Cuánto texto de instrucciones pone cada uno delante del modelo

Este es el número que decide cómo se comporta una skill en una sesión larga, y ningún README lo pone al frente.

El propio paso 4 del flujo de Hallmark le dice al agente que cargue los ficheros de layout, imagery, craft, género y tema, más gates.md § 1–4. Sumando esos ficheros nombrados:

El árbol references/ completo son 98 ficheros markdown y 632.105 bytes: unos 158.000 tokens si alguna ejecución llegara a leerlo todo.

El SKILL.src.md de Impeccable son 12.459 bytes ≈ 3.100 tokens, y cada comando arrastra su propio fichero de referencia: reference/critique.md son 48.194 B (≈12.000 tokens), reference/new-work.md son 63.661 B (≈15.900 tokens), reference/live.md 36.916 B. Sumando los 24 comandos, el conjunto de referencias son 41 ficheros y 416.023 bytes; 30 de esos ficheros se nombran directamente en SKILL.md (348.715 B ≈ 87.000 tokens si se cargara todo a la vez, cosa que no ocurre).

Dos diseños distintos: Hallmark precarga un reglamento fijo de ~29.500 tokens por construcción; Impeccable mantiene la carga permanente en ~3.100 tokens y paga por comando. Si trabajas con un agente y un presupuesto de contexto ajustado, esa diferencia decide si la skill se puede usar o no.

Gobernanza: qué dicen los contadores

Todas las cifras son de la API de GitHub el 2026-10-25.

Hallmark no tiene releases ni tags. Su SKILL.md dice version: 2.0.0, su historial de commits dice «Hallmark 2.8.0, the launch pass» y GitHub dice «No releases published». Si necesitas fijar la versión de una compuerta que puede bloquear un merge, el único pin disponible es un SHA de commit. Eso es una diferencia operativa real frente a las 90 releases etiquetadas de Impeccable, no cosmética.

La distribución de contribuidores de Hallmark tiene una segunda consecuencia. El nombre del repositorio es Nutlope (Hassan El Mghari); quien ha escrito el 94,9% es Luffixos. Doce commits del propietario de 297 es un proyecto donde la cara pública y el mantenedor son personas distintas: conviene saberlo antes de abrir un issue contra la cuenta que viste en X.

La prueba cruzada, y cómo reproducirla

Ninguno de los dos productos afirma ser portable a la salida del otro, ni debería. sloplint.mjs espera el comentario de sello de Hallmark y la disciplina de tokens en :root; impeccable detect no espera nada en particular. Así que lee los dos resultados siguientes como «qué reporta cada compuerta sobre el mejor trabajo del otro», y separaré explícitamente los fallos de estilo propio de los fallos de oficio.

Reproducción, desde un clon limpio de cada repositorio:

# ambos repositorios, superficiales
git clone --depth 1 https://github.com/Nutlope/hallmark.git
git clone --depth 1 https://github.com/pbakaus/impeccable.git
npx -y impeccable@latest --version                            # o: npm i -g impeccable
npm i -g puppeteer-core

# sirve las dos vitrinas (son HTML estático con CSS enlazado)
(cd hallmark/site/made       && python3 -m http.server 8899) &
(cd impeccable/demos         && python3 -m http.server 8898) &

# el linter de Hallmark, nivel render activado, contra las demos de Impeccable
export HALLMARK_PUPPETEER="$(npm root -g)/puppeteer-core"
export CHROME_PATH=/path/to/chrome
node hallmark/skills/hallmark/scripts/sloplint.mjs --url http://127.0.0.1:8898/landing-demo/

# el detector de Impeccable contra las 21 páginas de la galería de Hallmark
impeccable detect --json http://127.0.0.1:8899/atelier-architect/

Las dos líneas de «servir» son importantes: el motor renderizado necesita un origen HTTP, y sloplint --url necesita una URL a la que navegar. Una ruta file:// sirve para el nivel estático y omite el renderizado en silencio.

Ronda 1 — cada linter contra su propia vitrina

Las 21 páginas de la galería de Hallmark, sloplint --render: 0 FAIL, 9 REFLEX, 0 WARN. Las 21 páginas pasan el suelo en un navegador real, con los anchos que comprueba el nivel de render (320, 375, 414, 1280, 1440, 1920). Los hallazgos REFLEX son el nivel renunciable, y las páginas los llevan por escrito: el sello de atelier-architect/style.css dice dismissed 58, nombrando la compuerta que anuló y por qué.

Ese es un resultado real, no de marketing. Una galería de 21 páginas que sobrevive a su propio suelo basado en navegador es evidencia de que el suelo lo aplica algo más que la intención.

Las 2 páginas de demo de Impeccable, impeccable detect (renderizado): 32 hallazgos entre demos/landing-demo/ y demos/landing-demo/classic/, cero páginas limpias.

Dos de ellos merecen citarse de vuelta contra el README, que dice:

Don’t use overused fonts (Arial, Inter, system defaults)

El escaneo renderizado reporta overused-font una vez en cada página de demo. El primer impacto del detector en landing-demo lee 'Inter', system-ui, sans-serif en body: exactamente la misma declaración que el linter estático de Hallmark marca como compuerta 48 en la línea 25. Dos linters independientes, escritos por personas distintas, coinciden en que la vitrina de Impeccable usa la tipografía que Impeccable te dice que no uses.

El mismo README incluye «the rounded-square icon tile above every heading» entre los tics que existe para eliminar. Sus dos demos acumulan seis hallazgos icon-tile-stack.

Ronda 2 — cada linter contra la vitrina del otro

sloplint --render de Hallmark contra las demos de Impeccable: 30 FAIL (9 en landing-demo, 21 en classic), más 4 REFLEX y 5 WARN.

Los fallos se separan con claridad, y esa separación es la parte honesta. Estos son los recuentos en modo estático (79 FAIL entre las dos páginas de demo), porque ese desglose es exacto:

En el nivel de render las mismas dos páginas suman 30 FAIL más en compuertas de maquetación que sólo existen cuando hay navegador: 26a (contraste del anillo de foco medido en 1,10:1), 34 (scroll horizontal en tres anchos), 49a (etiquetas de control que se parten en dos líneas), 40 (umbral de contraste) y 58 (presupuesto de texto del hero).

Aproximadamente la mitad de los FAIL estáticos son convenciones de Hallmark: 39 de 79 son el sello (2) y el bloque de tokens (37). Una página que no construyó Hallmark nunca llevará su sello, y cualquier sistema de diseño que no haga pasar cada literal por un único bloque :root va a disparar la compuerta 48 decenas de veces. Descuenta eso y la vitrina de Impeccable sigue fallando la mitad portable, incluidas cosas que su propio README dice evitar.

El hallazgo individual más consecuente es la compuerta 34, porque pude verificarlo sin ninguna de las dos herramientas:

imp landing   320px scrollWidth=693 clientWidth=320  OVERFLOW  ['DIV.nav-links right=524']
imp landing   375px scrollWidth=693 clientWidth=375  OVERFLOW
imp landing   390px scrollWidth=693 clientWidth=390  OVERFLOW
imp landing   768px scrollWidth=768 clientWidth=768  ok
imp classic   320px scrollWidth=689 clientWidth=320  OVERFLOW
hall atelier  320px scrollWidth=320 clientWidth=320  ok
hall bloom    320px scrollWidth=320 clientWidth=320  ok

Las dos páginas de demo de Impeccable se desplazan de lado de verdad en todo ancho de móvil: 693 px de contenido en una ventana de 320 px, con DIV.nav-links llegando a right=524, mientras que las páginas de Hallmark no lo hacen. Entre las 62 reglas de Impeccable están first-viewport-column-overflow y text-overflow, y ninguna detectó esto. La compuerta 34 de Hallmark sí, porque mide scrollWidth contra clientWidth en un navegador.

detect de Impeccable contra las 21 páginas de la galería de Hallmark: 41 hallazgos, 4 páginas limpias.

cream-palette en 9 de 21 páginas es el veredicto más interesante de todo el artículo, porque los temas de Hallmark se construyen exactamente sobre esa superficie: los tokens de atelier son papel oklch(94.5% 0.010 76). La paleta de materiales curada de un producto es el tic de IA del otro. Aquí no hay un hecho objetivo; hay un desacuerdo real sobre el gusto, y los dos bandos pueden citar su propio reglamento.

italic-serif-display en 6 páginas es el mismo tipo de desacuerdo (el género editorial de Hallmark se apoya en ella a propósito). straggler en 8 páginas y nested-cards en 5 se acercan más a defectos de oficio, medibles en el navegador y no obviamente estilísticos.

Ronda 3 — uno de esos 41 es un bug, no un hallazgo

El escaneo estático (sin render) de la galería de Hallmark reportó flat-type-hierarchy en 11 de 21 páginas, con este fragmento:

Role sizes: body 16px, h1 16px, h2 16px, h3 16px (largest adjacent step 1.00:1)

Todos los roles a 16 px, en una página cuyos encabezados se definen vía var(--text-display), que resuelve a clamp(2.75rem, 5vw + 1rem, 5.25rem). Dieciséis píxeles es el valor por defecto del navegador, no una medición.

La causa es estructural: la salida de Hallmark enlaza una hoja de estilos, y esa hoja hace @import del resto.

/* atelier-architect/style.css */
@import url("./tokens.css");   /* aquí vive la escala con clamp() */
@import url("./base.css");     /* h1 { font-size: var(--text-display); } */

Las reglas que viven en un fichero importado con @import son invisibles para el motor estático. Lo reproduje con tres fixtures:

Mismo HTML, mismo resultado renderizado, veredicto distinto. No tiene que ver con clamp() ni con variables CSS: el fixture de un solo fichero con clamp() pasa. Tiene que ver con en qué fichero vive el texto de la regla.

Pasa las mismas páginas por el motor renderizado y la regla desaparece por completo: 0 de 21 páginas reportan flat-type-hierarchy en modo URL. Así que este bug concreto sólo afecta a impeccable detect <dir>, el modo que su propio README muestra primero y el que usaría un job de CI. Los 11 hallazgos fantasma inflan el recuento estático que de otro modo habría citado, así que: 27 hallazgos en estático (11 de ellos este artefacto), 41 en renderizado (ninguno).

La documentación de Impeccable es inusualmente franca sobre el problema general —«A clean detector run is evidence, not proof of visual or accessibility quality: it does not replace inspecting the rendered experience across relevant viewports»—, pero nada en los documentos advierte que una hoja enlazada e importada derrota una regla.

Ronda 4 — la compuerta que falla abierta

El propio README de Hallmark dice:

The browser checks (sloplint --render, screenshots) also need npm i -g puppeteer-core and Chrome; without them the static checks still run.

Esa frase es verdadera para ficheros. Es falsa para URLs, y la diferencia importa, porque la regla 16 de SKILL.md le dice al agente que ejecute sloplint --render sobre lo que acaba de construir, que normalmente es la URL de un servidor de desarrollo.

$ node skills/hallmark/scripts/sloplint.mjs --url http://127.0.0.1:8898/landing-demo/
sloplint: clean. 0 FAIL, 0 REFLEX, 0 WARN across 0 file(s) and 1 URL(s).
render tier not run: no puppeteer-core found locally, globally or via HALLMARK_PUPPETEER
$ echo $?
0

0 file(s) es la pista: en modo URL la página nunca se descargó para el análisis estático. La misma página escaneada como fichero, en el mismo entorno, reporta 24 FAIL. Me topé con tres modos de fallo distintos y los tres imprimieron «clean» y salieron con 0:

Con los tres arreglados, el mismo comando encuentra 9 FAIL en esa página en 4 segundos.

Este es el patrón que conviene interiorizar, y no es específico de Hallmark: una compuerta que no puede ejecutar sus comprobaciones y reporta éxito es peor que una compuerta ausente, porque un agente que lee 0 FAIL va a publicar. Hallmark sí imprime una nota de una línea, y su salida JSON lleva "render": "not run: …", pero el número sobre el que actúa un agente es el cero, y SKILL.md dice «Fix every FAIL».

Compáralo con el contrato del otro lado. impeccable detect documenta tres códigos de salida —0 limpio, 2 hallazgos, 1 «at least one requested target could not be scanned»— con «operational failure takes precedence for a partial multi-target scan». Esa distinción entre «no encontré nada» y «no pude mirar» es exactamente la que sloplint colapsa.

Lo que ambos hacen bien, y queda por escrito

Una auditoría que sólo enumera defectos es una acusación, así que:

• Hallmark aplicó su suelo sobre su propio trabajo. 21/21 páginas, 0 FAIL, en navegador, a seis anchos de ventana. Los REFLEX que sí lleva están sellados con razones dentro del CSS. Ese es el comportamiento que quieres de una compuerta.
• La compuerta 34 de Hallmark encontró un bug móvil en la vitrina de su competidor que las 62 reglas del competidor no vieron. Medir scrollWidth no es glamuroso y funciona.
• El detector de Impeccable es un binario de verdad con un contrato de códigos de salida de verdad. --json, --github, --no-advisory, --viewport, --cdp, y 62 ids de regla enumerados por nombre en docs/CLI-CONTRACT.md. Un flag documentado no me funcionó: impeccable detect --list-rules, que el contrato describe como «prints the detector catalog to stdout», no imprimió nada en npm 4.7.0 (--json devolvió []), así que enumera las reglas desde el documento. Su documentación también declara los límites de su propia evidencia.
• Impeccable publica 90 releases etiquetadas sobre un historial de 2.534 commits, así que fijar versión es posible.
• Los dos envían el linter como código, no como promesa. Ninguno te pide confiar en una captura: sloplint.mjs son 231.622 bytes de JavaScript legible; el detector es un workspace de Rust que puedes compilar.
• Ninguno inventa métricas en el producto. La demo «26 issues → 0 issues» de Hallmark está etiquetada «The issue counts come from Hallmark’s linter»: se autoevalúa y lo dice. Los números promocionales de LCP y tamaño de bundle de Impeccable están etiquetados como demo, no como benchmark.

Cuál instalar

No es un ranking. Es una tabla de decisión.

Si instalas cualquiera de los dos, lee el modo de fallo de la herramienta antes de fiarte de su cero. En Hallmark eso significa comprobar que tu ejecución dice 1 file(s) y no 0 file(s), y que render tier no va precedido de not run. En Impeccable significa usar el modo URL cuando te importe la maquetación, porque el motor estático no puede ver una regla que vive detrás de un @import.

Lista de verificación

Unos veinte minutos, sin cuentas, sin claves de API:

# 1. Qué estás descargando de verdad
git clone --depth 1 https://github.com/Nutlope/hallmark.git
du -sb hallmark; find hallmark -name '*.jpg' -printf '%s\n' | awk '{s+=$1} END {print s}'

git clone --depth 1 https://github.com/pbakaus/impeccable.git
find impeccable -name font-index.json | xargs sha256sum | awk '{print $1}' | sort | uniq -c

# 2. Si los recuentos son recuentos
python3 -c "import json;d=json.load(open('impeccable/skill/scripts/command-metadata.json'));print(len(d))"
grep -o 'Registry ([0-9]* ids' impeccable/docs/CLI-CONTRACT.md   # 62 reglas, por nombre
ls hallmark/skills/hallmark/references/themes/*.md | wc -l        # 48 temas + README

# 3. Si la compuerta se ejecutó de verdad
node hallmark/skills/hallmark/scripts/sloplint.mjs <una página real> --json | jq .summary
#    files: 0 y render: "not run" significan que no se comprobó nada

# 4. Si el detector ve tu hoja de estilos
impeccable detect --json path/to/your/page.html
impeccable detect --json path/to/your/page/          # directorio, sigue el CSS enlazado
#    si los dos discrepan en reglas de escala tipográfica, tienes el punto ciego del @import

# 5. La comprobación cruzada que ninguna herramienta ofrece
#    mide el desbordamiento tú mismo, en el navegador, a 320 y 375

FAQ

¿Los 64,9 MB del repositorio de Hallmark son lo que instalo? No. El plugin publica «only the skill (7 MB, not the whole repo)». skills/hallmark/ son 6.841.340 bytes. Los otros 58 MB son el sitio de marketing y su fototeca. El número sólo importa si clonas para leer el código.

¿Impeccable necesita de verdad 22 copias de un índice de fuentes? Es una decisión de distribución, no un defecto de diseño. Las carpetas raíz de harness son artefactos generados que se mantienen en main para que npx skills, las instalaciones directas desde GitHub y los submódulos funcionen sin paso de build. AGENTS.md lo dice y nombra el workflow que las regenera. Sí cuesta 24,2 MB del clon.

¿Por qué discreparon tanto los dos linters? Porque miden cosas distintas a propósito. Hallmark califica una página contra un suelo propio fijo (tokens, sello, pliegue, wrap de controles) y exige navegador para las reglas de maquetación. Impeccable califica contra 62 tics de IA con nombre y reglas generales de calidad, y su modo más fuerte también es el navegador. La vitrina de cada uno está limpia según sus reglas y sucia según las del otro.

¿Es real el hallazgo flat-type-hierarchy en mi proyecto? Si tu escala tipográfica vive en una hoja importada con @import y escaneas un fichero o directorio, no: es un falso positivo, reproducible con tres ficheros y sin framework. Confírmalo renderizando la página y comparando: medí h1: 80px en una página que el detector insistía en que era 16 px en todas partes.

¿Basta con que sloplint diga «clean» para publicar? Sólo si el resumen dice files: ≥1 y el nivel de render se ejecutó. En modo URL sin puppeteer-core o sin un Chrome arrancable imprime clean. 0 FAIL … across 0 file(s) y sale con 0 para una página que falla 24 comprobaciones si la escaneas como fichero.

¿Cuál tiene mejor gusto? No se ponen de acuerdo, y el desacuerdo es un dato. Nueve de las 21 páginas de Hallmark le parecen a Impeccable cream-palette, «the default ’tasteful’ AI surface». Seis le parecen italic-serif-display. Todo el catálogo de temas de Hallmark se construye sobre esas dos elecciones. No es un bug de ninguno de los dos linters; es la señal más clara de que «anti-slop» no es una sola estética.

Conclusión

Dos productos que funcionan, de maneras legibles y comprobables, con 118.552 estrellas y 259 watchers.

El hallazgo útil no es que uno gane al otro. Es que las compuertas son complementarias y ninguna está completa: Hallmark mide la maquetación en un navegador y detecta un bug de desbordamiento móvil en la demo de Impeccable que las 62 reglas de Impeccable no vieron; Impeccable mide los tics de forma exhaustiva y lee la galería cuidadosamente tematizada de Hallmark como nueve páginas de crema. El cero de cada uno significa «no disparó nada de mi reglamento», y en el modo URL de Hallmark también puede significar «no se ejecutó nada».

Si eliges uno hoy: Impeccable para CI, fijar versiones y sistemas de diseño existentes; Hallmark para construir páginas nuevas en un estilo propio fijo y aplicado. Si eliges en abstracto, instala el linter antes que la skill, pásalo contra una página en la que ya confías y lee lo que dice de las partes de tu diseño de las que estás más orgulloso. Esa lectura te dice más de la herramienta que cualquier número de estrellas.

Apéndice: comandos exactos detrás de cada cifra

# mediciones del repositorio (árbol de trabajo, sin .git)
find . -path ./.git -prune -o -type f -printf '%s %p\n' | sort -rn | head

# detección de duplicados
find impeccable -name font-index.json -not -path './.git/*' -exec sha256sum {} \; | awk '{print $1}' | sort | uniq -c

# escaneo estático de la galería
impeccable detect --json hallmark/site/made/atelier-architect/index.html

# escaneo renderizado (la comparación justa)
(cd hallmark/site/made && python3 -m http.server 8899)
impeccable detect --json http://127.0.0.1:8899/atelier-architect/

# el linter de Hallmark, nivel render, sobre las demos de Impeccable
export HALLMARK_PUPPETEER="$(npm root -g)/puppeteer-core"
export CHROME_PATH=/path/to/chrome
node hallmark/skills/hallmark/scripts/sloplint.mjs --url http://127.0.0.1:8898/landing-demo/ --json

# medición de desbordamiento independiente (ninguna de las dos herramientas)
# Playwright: page.setViewportSize({width:320,height:800}); document.documentElement.scrollWidth