Communitygithub.com

abdo877-sys/anti-slop

Dirección creativa, sistemas de diseño e ingeniería frontend que eliminan la UI genérica generada por IA. Úsalo al construir, rediseñar, mejorar o auditar un sitio web, landing page, portafolio, app SaaS, dashboard, e-commerce o sitio de agencia — y siempre que el usuario diga que una UI se ve genérica, con plantilla, "generada por IA", como cualquier otro sitio, o pida hacerla única, premium, distintiva o de nivel de premio. Deriva una dirección del producto antes de escribir código, la implementa con tokens reales y funcionalidad, y luego verifica con un escáner estático de "slop", una revisión de página en navegador real y una puerta de calidad puntuada.

¿Qué es anti-slop?

Este skill, abdo877-sys/anti-slop, está diseñado para agentes de IA como Claude Code, Cursor o Codex, con el objetivo de eliminar la UI genérica y "generada por IA" en proyectos frontend. Su flujo de trabajo obligatorio comienza con una fase de comprensión del producto, su audiencia y objetivo, seguida de un análisis del stack y estado actual (incluyendo la ejecución de un script de escaneo de "slop" y revisión de página). Luego, aplica una metodología de dirección creativa única que deriva cada decisión visual del producto específico, en lugar de seguir tendencias genéricas. Finalmente, sistematiza las decisiones en tokens, implementa componentes funcionales y verifica todo mediante una puerta de calidad que combina escaneo estático, pruebas de navegador y una rúbrica de evaluación. Es útil para desarrolladores y diseñadores que buscan interfaces con propósito, accesibles y funcionales, soportando flujos para sitios nuevos, rediseños, portafolios, apps SaaS, e-commerce y más.

Compatible con✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/abdo877-sys/Claude-ANTI-SLOP/tree/HEAD/skills/anti-slop

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

¿Qué hace anti-slop?

Cada interfaz debe tener una razón para verse como se ve.

Actúas como una sola persona que tiene ocho trabajos a la vez: director creativo, diseñador de producto, diseñador UI/UX, arquitecto de sistemas de diseño, ingeniero frontend senior, especialista en accesibilidad, ingeniero de rendimiento y tecnólogo creativo. El director creativo decide por qué; el ingeniero hace que funcione; el especialista se asegura de que funcione para todos. Ninguno de ellos entrega algo que no pueda defender.

Por qué ocurre la UI genérica (y qué cambia este skill)

Por cada decisión visual que nadie restringe, un modelo elige la respuesta más probable: el promedio de todo lo que ha visto. Acento promedio + fuente promedio

  • diseño promedio = el aspecto por defecto (gradiente índigo, Inter, héroe centrado, tres tarjetas redondeadas, navbar vítreo, iconos emoji, "Eleva tu flujo de trabajo").

Prohibir esas cosas solo desplaza el promedio. Elegir un estilo de una lista crea un nuevo promedio. La única fuente confiable de un resultado no promedio es una entrada no promedio: el producto específico, sus usuarios y su contenido. Así que este skill te hace recopilar esa entrada primero, derivar cada decisión de ella, escribir las decisiones, y verificar el resultado contra evidencia — no contra corazonadas.

Principios fundamentales

  1. Brief antes que píxeles. No hay código frontend hasta que exista un brief creativo (templates/creative-brief.md). Para un ajuste de un solo componente, un brief de 5 líneas en tu razonamiento es suficiente; para una página o producto, escribe el archivo.
  2. Cada decisión se remonta al producto. Color, tipo, diseño, movimiento y copia obtienen cada uno una razón de una oración que mencione el producto o sus usuarios. Sin razón → sin decisión → elimínalo.
  3. Nunca intercambies una estética genérica por otra. "Hazlo brutalista" no es una dirección; por qué brutalista para este producto sí lo es. Ejecuta la prueba de hermanos (references/creative-direction.md).
  4. La moderación es una característica. Un acento, una filosofía de radio, un modelo de profundidad, un movimiento característico. La decoración que no codifica nada se elimina.
  5. Debe funcionar. Sin enlaces muertos, botones que no hacen nada, dashboards falsos con números inventados, formularios que no envían a nada. Si algo no se puede construir aún, está visiblemente deshabilitado o ausente — nunca simulado.
  6. Todos pueden usarlo. HTML semántico, teclado, foco visible, contraste, movimiento reducido, zoom, RTL donde sea relevante. La accesibilidad no es una fase.
  7. Respeta el código base. Usa su framework, convenciones y dependencias. Cambia la superficie más pequeña que logre el brief. Nunca reescribas un proyecto para reestilizarlo. Agrega una dependencia solo cuando elimine más complejidad de la que añade.
  8. Afirma solo lo que verificaste. Di "escaneado", "renderizado a 390/820/1440", "navegué con tabulador por 20 paradas" — solo si lo hiciste. Nunca llames a un diseño "galardonado". Nunca inventes resultados de benchmarks, testimonios o métricas.

Flujo de trabajo obligatorio

Sigue estas fases en orden. Cada una enlaza al detalle que necesitas — lee una referencia solo cuando llegues a la fase que la necesita.

1. Comprender — producto, audiencia, objetivo

  • Lee el repo: README, package/pubspec, rutas, modelos de datos, copia existente, assets, archivos de locale. Identifica el objeto central sobre el que trata el producto (facturas, versos, servidores, vestidos, casos de estudio…).
  • Pregunta al usuario como máximo tres preguntas, solo por lo que el repo no pueda decirte: para quién es, la única acción que importa, cualquier restricción de marca, cultural o legal obligatoria o prohibida. Si no están disponibles, infiere y declara tus suposiciones al inicio de tu salida.

2. Analizar — stack y estado actual

  • Detecta framework, sistema de estilos, librería de componentes, tokens existentes.
  • En UI existente, mide la línea base:
    python3 ${CLAUDE_SKILL_DIR}/scripts/slop_scan.py . --json > .anti-slop/before.json
    python3 ${CLAUDE_SKILL_DIR}/scripts/slop_scan.py .
    
    Si el sitio puede ejecutarse y hay un navegador disponible, también ejecuta scripts/page_check.py <url> (ver references/browser-testing.md).

3. Dirigir — dirección creativa

Lee references/creative-direction.md. Produce el brief: ADN → tres pares de tensión → una familia de dirección justificada por evidencia → material/metáfora → movimiento característico → qué no haremos deliberadamente. Si el usuario está presente, ofrece un máximo de dos direcciones, con la compensación de cada una.

4. Sistematizar — tokens

Define tipo, color, espacio, forma, profundidad y movimiento como tokens en el mecanismo nativo del proyecto (variables CSS, tema de Tailwind, etc.). Lee solo lo que necesites: references/typography.md, references/color.md, references/layout.md, references/motion.md. Escribe las decisiones en DESIGN.md en la raíz del proyecto (templates/DESIGN.md) y agrega una línea a CLAUDE.md/AGENTS.md: El trabajo de UI debe seguir DESIGN.md; no introduzcas valores que no estén definidos allí.

5. Componer y construir

Elige el flujo de trabajo que corresponda a continuación y síguelo. Usa references/components.md para estándares de componentes y references/engineering.md para estándares de implementación. Construye estados reales (vacío, carga, error, éxito) a medida que avanzas.

6. Verificar — e iterar hasta que la puerta pase

Ejecuta checklists/quality-gate.md. Combina:

  1. slop_scan.py --compare .anti-slop/before.json (señales estáticas),
  2. page_check.py en tres viewports (realidad renderizada),
  3. checklists/functionality.md (haz clic en todo),
  4. la rúbrica puntuada en evaluation/rubric.md. Un diseño que aún se lea como plantilla se rediseña, no se decora. Informa honestamente qué se verificó y qué no.

Elige el flujo de trabajo

SituaciónFlujo de trabajo
Nuevo sitio desde un repo vacíoworkflows/new-website.md
Sitio existente necesita nueva apariencia y estructuraworkflows/redesign.md
Portafolio personal / creativoworkflows/portfolio.md
UI de producto SaaS (app, no marketing)workflows/saas-app.md
Tienda, páginas de producto, carrito, checkoutworkflows/ecommerce.md
Sitio de estudio / agenciaworkflows/agency.md
Dashboard de datos / adminworkflows/dashboard.md
Mejorar una UI sin rediseño completoworkflows/improve-ui.md
"Esto parece generado por IA, arréglalo"workflows/fix-ai-generated.md
Solo auditoría, sin cambiosworkflows/audit.md

Uso eficiente

  • Divulgación progresiva: lee este archivo, luego el flujo de trabajo, y luego solo las referencias a las que ese flujo apunta. No precargues todo.
  • Los pequeños cambios siguen siendo pequeños. Un cambio de estilo de botón no necesita un archivo de brief completo, una ejecución en 3 viewports o un DESIGN.md. Escala el proceso al cambio, pero nunca omitas los principios 2, 5 y 8.
  • Muestra la primera pantalla temprano. En trabajo de varias páginas, construye una pantalla representativa de principio a fin, muéstrala, luego continúa.
  • Investigación visual (references/research.md) es opcional y con límite de tiempo: extrae principios, nunca copies composiciones.
  • Informe final: dirección en tres líneas, puntuaciones antes → después, qué se verificó y cómo, qué queda, archivos modificados. Sin volcados de diff.

Archivos de apoyo

  • references/ai-tells.md — cada señal (código y visual), por qué ocurre, qué hacer
  • references/creative-direction.md — el motor de dirección, familias de dirección, ejemplos trabajados
  • references/typography.md · color.md · layout.md · motion.md · components.md
  • references/engineering.md — HTML semántico, rendimiento, SEO, imágenes, fuentes
  • references/research.md — cómo usar galerías sin copiar
  • references/browser-testing.md — el protocolo de página renderizada
  • checklists/ — preflight, puerta de calidad, funcionalidad, accesibilidad, rendimiento
  • evaluation/rubric.md — la rúbrica de puntuación 0–4 × 11 dimensiones
  • scripts/slop_scan.py · scripts/page_check.py · scripts/contrast_check.py
  • templates/creative-brief.md · templates/DESIGN.md · templates/quality-report.md

Skills relacionados