Árbitros del código

Le pides una función, te la entrega, la corres y sirve. Las pruebas pasan en verde. Y aun así el proyecto quedó peor: un archivo que creció doscientas líneas, un condicional nuevo metido en un flujo que no tenía nada que ver, tres tipos que dicen desconocido donde antes se sabía exactamente qué venía.

Nada de eso rompe una prueba. Las pruebas comprueban comportamiento, y el comportamiento está bien. Lo que se degradó fue otra cosa: qué tan difícil va a ser el siguiente cambio. Y eso no lo mide nadie hasta que duele.

Dos problemas distintos que se confunden

Esta página es sobre la columna de la derecha. La de la izquierda ya tiene quien la atienda.

Por qué revisarlo tú no alcanza

La respuesta obvia es leer más el código antes de aceptarlo. Funciona un rato y después no: el volumen es demasiado, la mayoría del diff se ve razonable línea por línea, y el problema casi nunca está en una línea — está en la forma del conjunto.

Lo que sí escala es no dejarlo a criterio. Poner una condición que el agente no pueda cruzar, y un revisor con una rúbrica más dura que la tuya al final del día.

Y antes de instalar nada: Claude Code ya trae sus propios comandos de revisión y de seguridad, que están explicados en Revisa tu código con Claude. Siguen sirviendo y esta página no los reemplaza — lo que agrega es lo que ninguno de ellos puede ser.

El slop de diseño y de prosa —lo que se ve hecho con IA— es otro problema y tiene su propia guía en Stop AI Slop. Aquí solo hablamos de código.

Hay dos maneras de frenar código mal construido, y se parecen tan poco que conviene no llamarlas igual. Una mide: aplica una regla escrita, siempre igual, sin interpretar nada. La otra juzga: lee el cambio completo y opina sobre si está bien planteado.

Ninguna puede hacer el trabajo de la otra. Una máquina no sabe si una abstracción vale la pena; un juez no puede correr en cada guardado sin que te cueste una fortuna.

La fila que más se subestima es la tercera. Un linter no te manda un reporte para que lo leas después: devuelve error. Y como el agente corre el lint dentro de su propio ciclo, se topa con la pared y reescribe sin que tú digas nada.

Por qué rechazar funciona mejor que avisar

Un aviso depende de que alguien lo lea y decida hacerle caso. Un rechazo no: el paso falla, y la única forma de avanzar es cumplir. Cuando ese muro está dentro del ciclo del agente, el que lo cumple es el agente, en el momento, sin que tú intervengas.

Ese es el mecanismo completo. No es que las reglas sean mágicas: es que están del lado correcto de la puerta.

Es un juego de reglas de linter escritas a propósito para los vicios que la IA escribe de más: tipos que dicen «desconocido» para no comprometerse, conversiones encadenadas que fabrican una certeza que nadie comprobó, comprobaciones defensivas en lugares donde no hacía falta desconfiar.

Es gratis, licencia MIT, y lleva más de cuatro mil cuatrocientas estrellas. Su autor es claro sobre lo que es: su gusto y el de su equipo, no un estándar universal. Esa honestidad importa para la §09.

Qué rechazan las dieciocho

Las otras cinco reglas son solo para proyectos que usan Effect, una librería concreta. Viven aparte a propósito: quien no la usa no hereda sus opiniones de arquitectura.

La lista completa, con un ejemplo de código rechazado por cada regla, está en el README del proyecto. Vale leerlo antes de encenderlas todas.

Son dos movimientos y solo el primero es un comando. El segundo se hace hablando, y es donde pasa lo interesante: quien instala las reglas es el agente, leyendo tu proyecto y adaptándose a lo que ya tienes.

Agrega -g al final si la quieres disponible en todos tus proyectos y no solo en este. El comando te pregunta para qué agente la instalas: elige Claude Code.

Lo que hace la skill cuando se lo pides

• Copia las reglas dentro de tu repositorio, en su propia carpeta.
• Instala Oxlint y su complemento de plugins; si ya tenías Oxlint, iguala las versiones en vez de romperlas.
• Mezcla la configuración nueva con la que ya tenías, sin borrar tus reglas.
• Enciende las dieciocho reglas generales, y las cinco de Effect solo si tu proyecto usa Effect.
• Corre el lint al final para comprobar que la instalación quedó funcionando.

Lo que te queda instalado

Una carpeta con las reglas dentro de tu repo —tuya, para leerla y cambiarla— y una configuración de linter que las llama. A partir de ahí, cada vez que se corra el lint las reglas corren: en tu terminal, en tu integración continua, y dentro del ciclo del agente cuando Claude verifica su propio trabajo.

Lo soltó el equipo de Cursor dentro de su repositorio de plugins oficiales, con licencia MIT. Se cuenta casi siempre como «la skill de revisión brutal», y es un error útil de corregir: son tres skills y dos subagentes, y revisan cosas distintas.

La rúbrica, en español

Las tres skills y los dos subagentes viven en cursor/plugins, en la carpeta thermos. Están escritas en texto plano: se pueden leer en diez minutos y vale la pena.

El plugin está pensado para Cursor, donde se instala con un comando propio. En Claude Code se traen las skills con el mismo instalador de la §04, y funcionan igual — son archivos de texto con instrucciones, no código atado a un editor.

El repositorio de Cursor trae 88 skills en total; el comando de arriba se lleva solo las tres. Agrega -g si las quieres en todos tus proyectos.

Dos detalles que no salen en ninguna documentación

El instalador es el CLI abierto de skills, el mismo que usa media bóveda. Es de Vercel Labs y tiene licencia MIT.

Seis, en el orden en que se usan. Los dos primeros son de Anti-Slop y los cuatro siguientes de Thermos. Los de Thermos nombran la skill a propósito: si no la nombras, no se activa y te devuelve una revisión normal sin la rúbrica dura.

Con Anti-Slop

Instala anti-slop en este repositorio usando la skill install-anti-slop.

Antes de tocar nada, dime:
- si el proyecto ya usa Oxlint o si hay que agregarlo, y si ya tiene otro
  linter que se vaya a quedar conviviendo
- si usa Effect, para saber si entran también las reglas de Effect

Al terminar, explícame en español y en una lista corta:
1. qué archivos creaste o modificaste, y qué carpeta quedó con las reglas
2. qué dependencias instalaste y en qué versión
3. cuántas reglas quedaron encendidas
4. el resultado de correr el lint una vez

No arregles todavía nada de lo que el lint rechace. Solo instala y reporta:
quiero ver el tamaño del problema antes de que empieces a cambiar código.

Corre el lint y arregla todo lo que anti-slop esté rechazando.

Reglas del trabajo:
- el comportamiento no cambia. Si para cumplir una regla tendrías que
  cambiar lo que el código hace, párate y pregúntame.
- nada de silenciar reglas con comentarios de excepción para salir del paso.
  Si una regla te parece equivocada para este proyecto, dímelo y lo
  discutimos: el código de las reglas es nuestro y se puede editar.
- de a poco: arregla, corre el lint, y sigue. No una tanda gigante.

Cuando termines, muéstrame el lint en limpio y dime qué reglas fueron las
que más aparecieron. Eso es lo que me dice qué está aprendiendo mal el
proyecto, no solo qué se arregló hoy.

Con Thermos

Usa la skill thermo-nuclear-code-quality-review sobre los cambios de esta
rama contra main.

Antes de empezar, junta el diff completo y el contenido de los archivos que
toca, para que no tengas que adivinar nada.

Quiero los hallazgos en español, ordenados por gravedad, y cada uno con:
- el archivo y la línea
- qué está mal según la rúbrica, con la regla concreta que lo señala
- el arreglo que propones, y si es code judo dilo: quiero saber cuáles
  borran complejidad y cuáles solo la mueven de lugar

No cambies ni un archivo todavía. Esta vuelta es solo el veredicto.

Usa la skill thermo-nuclear-review sobre los cambios de esta rama contra
main.

Junta el diff y el contenido de los archivos tocados antes de juzgar nada.

Busca sobre todo:
- cosas que esta rama rompe sin que ninguna prueba se entere
- cambios que rompen algo para quien ya usaba esto
- problemas de seguridad: datos que se filtran, entradas que nadie valida
- permisos de funciones nuevas que se quedaron abiertos cuando no deberían

En español, ordenado por gravedad, y con el archivo y la línea de cada uno.
Si algo no lo puedes confirmar sin correr el código, dilo en vez de
afirmarlo.

Antes de integrar esta rama quiero las dos revisiones de Thermos.

Junta una sola vez el diff contra main y el contenido de los archivos que
toca. Después haz dos pasadas sobre ese mismo material:

1. con la skill thermo-nuclear-review, para bugs, cosas rotas y seguridad
2. con la skill thermo-nuclear-code-quality-review, para estructura

Al final dame UN solo veredicto en español, no dos reportes pegados:
- junta los hallazgos repetidos en uno, y si las dos pasadas señalan lo
  mismo, súbelo de prioridad: eso es lo más sólido que vas a encontrar
- si se contradicen, dilo y toma partido, con tu razón
- ordénalo por lo que más duele, no por el orden en que apareció
- cierra con una sola línea: se integra, o no se integra todavía

De los hallazgos de la revisión, aplica solo los de gravedad alta.

Uno por uno, no todos de golpe. Para cada uno:
- dime qué vas a cambiar antes de cambiarlo
- hazlo sin tocar comportamiento: las pruebas que pasaban siguen pasando
- corre el lint después de cada arreglo

Los de gravedad media y baja los dejamos anotados y no los tocas hoy.

Si un hallazgo pide reestructurar algo grande, no lo hagas: descríbeme el
cambio, dime qué archivos moverías y cuánto crece la rama, y lo decido yo.

Las dos herramientas no compiten por el mismo momento, y ponerlas en el orden correcto cambia lo que cuestan. El lint primero, la revisión después.

Por qué en ese orden y no al revés

Seis cosas que cambian lo que puedes esperar. Ninguna es motivo para no usarlas; todas son mejores sabidas antes.

Si lo que quieres es que Claude escriba menos código de entrada, en vez de filtrarlo después, eso vive en Ponytail y es un problema distinto del de esta página.