Cómo revisar tu pull request con Thermonuclear

Antes de enviar un pull request al equipo, puedes apoyarte en Cursor para hacer una revisión de código automatizada que detecte errores, tipos duplicados y hasta problemas de calidad de software. Con el comando /review y el skill Thermonuclear del Cursor Team Kit vas a validar tu PR con dos niveles de rigor distintos.

¿Cómo funciona el comando /review en Cursor?

El comando /review compara el branch de tu pull request contra main y emite un veredicto sobre si vale la pena mergear los cambios [02:00].

En el ejemplo, tras crear el pull request número 20 desde el agente, se ejecuta /review apuntando a ese PR. Cursor hace un diff del código, revisa cobertura de tests, alineación con los patrones del repo y devuelve un resumen con hallazgos importantes y menores.

¿Qué hace el comando /review? Genera un diff entre tu branch y main, evalúa cobertura de tests, patrones del repo y posibles issues de seguridad. Luego entrega un veredicto: aprobar, aprobar con comentarios o no aprobar.

¿Qué hallazgos detecta el review básico?

En la ejecución del PR 20, el agente encontró dos tipos de problemas:

• Un hallazgo importante: el código no funcionaba contra la API actual porque los endpoints de evaluate seguían siendo stubs del spec 05.
• Un hallazgo menor: tipos duplicados y lógica duplicada entre archivos.

Al pedirle repara los hallazgos importantes y actualiza el pull request, el agente eliminó los stubs que devolvían enable false, corrió los tests y detectó que los checks de TypeScript fallaban por un hook creado en clases anteriores. Iteró, corrigió los tipos y volvió a pasar la validación.

¿Qué es el Cursor Team Kit y cómo se instala?

El Cursor Team Kit es un set de herramientas que los propios desarrolladores de Cursor usan para validar la calidad de su código. Se instala desde el marketplace del editor, ubicado en el tab customize en la parte superior izquierda.

Dentro del marketplace vas a encontrar recursos compartidos por otras empresas, como el MCP de Figma que trae diseños directo al editor. El Team Kit incluye 18 skills, dos subagentes y dos reglas listas para usar.

¿Qué skills incluye el Team Kit?

Entre las herramientas disponibles al ampliar la lista de skills encuentras utilidades para:

• Chequear el compilador de errores.
• Controlar el CLI del proyecto.
• Controlar la UI durante pruebas.
• Ejecutar el skill Thermonuclear Code Quality Review.

Para instalarlo das clic en Add to Cursor, seleccionas el proyecto donde lo quieres agregar y confirmas con Add plugin [05:30].

¿Qué es Thermonuclear Code Quality Review?

Thermonuclear es un skill que no solo evalúa que el código funcione, sino que cumpla las mejores prácticas de desarrollo de software. Al invocarlo con /thermonuclear te aparecen dos variantes: el skill para usar en la conversación actual y el subagent para delegar la tarea a un agente independiente.

Corriendo el skill sobre el PR 20, el veredicto fue distinto al del /review: no aprobar todavía. El motivo: el pull request mezclaba dos specs, introducía drift de tipos y dejaba oportunidades claras de simplificación.

¿Cuál es la diferencia entre /review y Thermonuclear? El /review valida funcionalidad, cobertura y patrones. Thermonuclear va más profundo: detecta regresiones estructurales, código muerto, normalizaciones triplicadas y drift entre specs.

¿Qué tipo de hallazgos encuentra Thermonuclear?

En el análisis del PR aparecieron varios patrones que un review estándar no habría marcado:

• Regresión estructural de dos specs mezcladas en un solo PR.
• Drift de tipos entre archivos del dominio y del simulador.
• Normalización de contexto triplicada: tres implementaciones independientes del mismo concepto, resolvible con una única función matchRule.
• Complejidad muerta en la UI dentro de batchEvaluate.

¿Cómo reparar los hallazgos con plan mode?

Cuando hay varios cambios de fondo, conviene cambiar al plan mode antes de ejecutar. Al pedirle crea un plan para reparar los hallazgos encontrados, el agente hace preguntas para acordar la estrategia:

• ¿Dividir el PR de spec 9 y spec 10 en dos, mantenerlo en uno o dejarlo con commits atómicos separados?
• ¿Qué hacer con el scaffolding de matchRoute, column y tipos UI que la API no devuelve?

La decisión fue mantener un solo PR con commits atómicos e implementar el ciclo end-to-end sin eliminar código antes de validarlo con QA manual [09:40].

¿Qué contiene un plan de refactor generado por Cursor?

El plan que devolvió el agente estructuró el trabajo en fases claras:

1. Fase uno: dividir el trabajo por olas.
2. Fase dos: normalización de la lógica duplicada.
3. Fase tres: alinear los tipos con el dominio, simplificar el estado del simulador y conectar la regla.

Incluyó también riesgos y mitigaciones: si el rebase rompe el PR, se hace force push; si Next no devuelve el dominio, se añade al workspace. Al aprobar con build, el agente modificó 24 archivos, actualizó el summary del PR y dejó una checklist para QA manual.

Tu reto es navegar el marketplace de Cursor, instalar el Team Kit, correr Thermonuclear sobre tu propio pull request y contarme en los comentarios cuántos hallazgos apareció.