01 El problema: código que pasa los tests y aun así empeora
Un agente de código puede entregarte una función que hace lo que pediste y supera todos los tests, pero que deja tras de sí un archivo de 1.200 líneas, tipos unknown donde antes había un contrato claro, conversiones de tipo encadenadas y un if especial metido en mitad de un flujo que no tenía nada que ver. Ningún test lo detecta porque el comportamiento es correcto; lo que se ha deteriorado es la facilidad del siguiente cambio.
Revisar cada diff a mano no escala cuando el agente produce cientos de líneas al día. Lo que sí escala son dos cosas complementarias: reglas automáticas que rechazan los patrones medibles y una revisión con criterio para lo que no se puede reducir a una regla.
| Anti-Slop | Thermos | |
|---|---|---|
| Qué es | Plugin de reglas para el linter Oxlint | Tres skills de revisión publicadas por Cursor |
| Cómo decide | De forma determinista: misma entrada, mismo resultado | Con criterio, leyendo el diff y los archivos completos |
| Qué hace al encontrar algo | Devuelve error y bloquea el paso | Redacta hallazgos ordenados por gravedad |
| Cuándo actúa | Cada vez que se ejecuta el lint, también dentro del ciclo del agente | Cuando la rama está lista, antes del merge |
| Coste | Ninguno, es un programa local | Consumo de tu plan o API de Claude |
02 Anti-Slop: reglas que el agente no puede saltarse
Anti-Slop es un conjunto de reglas para Oxlint (no para ESLint) que rechaza patrones de baja evidencia: funciones que aceptan o devuelven unknown, diccionarios con valores de cualquier tipo, conversiones de tipo sin comentario que justifique su seguridad, ampliar un tipo conocido para luego forzarlo, recorrer una lista dos veces con filter y map, copiar el acumulador en cada vuelta de un reduce o simular módulos enteros en los tests. Incluye además un grupo opcional para proyectos que usan la librería Effect.
Su autor lo presenta como sus preferencias, no como un estándar universal, y por eso no hay paquete npm: el código se copia dentro de tu repositorio para que lo leas, lo ajustes y lo mantengas tú.
npx skills add dmmulroy/anti-slop --skill install-anti-slopEse comando solo deja disponible la skill; tu código sigue intacto. El segundo paso es pedírselo a Claude. La skill copia las reglas en tu repositorio, instala Oxlint y @oxlint/plugins con versiones compatibles (respetando la versión de Oxlint si ya la usas), fusiona la configuración existente, activa todas las reglas genéricas y comprueba que el lint funciona.
Usa la skill install-anti-slop para configurar Anti-Slop en este repositorio.
Antes de modificar nada, dime qué linter usa el proyecto ahora, si ya tiene Oxlint y si depende de Effect.
Cuando termines, resume: archivos creados o modificados, dependencias añadidas con su versión exacta, reglas activadas y la salida de una primera ejecución del lint.
No corrijas todavía ningún error que salga: quiero ver el volumen antes de decidir.03 Thermos: una revisión que no regala aprobados
thermo-nuclear-review
Auditoría de corrección y seguridad: errores, cambios que rompen compatibilidad, regresiones para desarrolladores y fugas de funcionalidades tras flags.
thermo-nuclear-code-quality-review
Rúbrica de mantenibilidad: busca simplificaciones estructurales, impide que un archivo pase de menos de 1.000 a más de 1.000 líneas sin motivo y señala condicionales improvisados y lógica en la capa equivocada.
thermos
Orquestadora: lanza las dos revisiones en paralelo mediante subagentes y une los hallazgos en un único veredicto.
npx skills add cursor/plugins -a claude-code \
--skill thermos \
--skill thermo-nuclear-review \
--skill thermo-nuclear-code-quality-reviewPrepara una revisión completa de esta rama antes de integrarla.
1. Obtén una sola vez el diff contra main (git diff main...HEAD) y el contenido completo de cada archivo modificado.
2. Con ese material, aplica primero la skill thermo-nuclear-review y después la skill thermo-nuclear-code-quality-review.
3. Entrégame un único informe en español: hallazgos fusionados y sin duplicados, ordenados por impacto, con archivo y línea, la regla de la rúbrica que lo justifica y la corrección propuesta. Marca qué correcciones eliminan complejidad y cuáles solo la reorganizan.
4. Termina con una línea: «Se puede integrar» o «No se puede integrar todavía», y el motivo.
No modifiques ningún archivo en esta fase.De la revisión anterior, corrige únicamente los hallazgos de gravedad alta, de uno en uno. Antes de cada cambio, explícame qué vas a tocar. Mantén el comportamiento: los tests que pasaban deben seguir pasando y el lint debe quedar limpio tras cada corrección. Si un hallazgo exige reestructurar varios módulos, no lo hagas: descríbeme el plan y espera mi decisión.04 En qué orden usarlas
-
1
Mientras Claude programa
Pídele que ejecute el lint como parte de su verificación. Lo que Anti-Slop rechace lo reescribe él mismo sin que intervengas.
-
2
Antes de cada commit
Lint en limpio. Es gratis, tarda segundos y elimina el ruido que luego encarecería la revisión.
-
3
Con la rama terminada
Lanza Thermos. Si toca autenticación, pagos o datos personales, las dos revisiones; si es un cambio interno, basta con la de calidad.
-
4
Antes del merge
Aplica los hallazgos graves, vuelve a pasar lint y tests y deja anotados los menores para otra iteración.
El orden importa por coste. Si pides la revisión sobre una rama sin lint, buena parte de los hallazgos serán conversiones de tipo y contratos vagos que una regla habría marcado gratis, y pagas tokens por leerlos. Con el lint primero, el revisor dedica su atención a lo que de verdad necesita criterio. Por la misma razón, ramas pequeñas y frecuentes salen más baratas y obtienen revisiones más precisas que una rama de dos semanas.
05 Límites y cuándo no compensa
- ✓Anti-Slop solo cubre TypeScript y JavaScript y requiere Oxlint; puede convivir con ESLint, pero es una herramienta más que mantener.
- ✓Las reglas son opiniones de su autor: lee la lista con sus ejemplos y desactiva las que no encajen con tu equipo en lugar de silenciarlas con comentarios.
- ✓Una vez copiadas, las reglas son código tuyo: revisa sus cambios como cualquier otra dependencia interna.
- ✓Thermos funciona con cualquier lenguaje porque quien lee es Claude, pero propone y no corrige: aplicar es un paso aparte.
- ✓En ramas grandes la revisión lee mucho contexto y consume bastante cuota.
- ✓Ninguna de las dos sustituye a los tests ni a una revisión humana de decisiones de producto o seguridad críticas.
Preguntas frecuentes
Sí, se publica en el repositorio de plugins de Cursor, pero las skills son archivos de texto con instrucciones. El instalador abierto de skills las copia en la carpeta de Claude Code y funcionan igual; lo único que no se instala son los subagentes de la orquestadora.
Sí. Anti-Slop necesita Oxlint, pero ambos linters pueden convivir en el mismo proyecto. La skill de instalación añade Oxlint y fusiona la configuración sin borrar tus reglas existentes.
Están marcadas para invocación manual porque una revisión completa es larga y consume bastante. Tienes que nombrar la skill en el prompt; si no, Claude hará una revisión genérica sin la rúbrica.
Anti-Slop no, porque son reglas de Oxlint para TypeScript y JavaScript. Thermos sí, ya que la rúbrica la aplica Claude sobre cualquier diff, independientemente del lenguaje.
Sobre el autor
Equipo editorial de appyweb
Marketing, SEO y desarrollo con IA
Especialistas de appyweb en SEO, publicidad, desarrollo web y automatización con IA.