Revisión de código con /review y Thermonuclear en Cursor

Antes de enviar un pull request a tu equipo, puedes usar Cursor para hacer una revisión de código automática que detecte errores, drift de tipos y problemas de calidad. Aquí aprenderás a usar el comando /review, el marketplace de Cursor y el skill Thermonuclear Code Quality Review para validar que tu código cumpla las mejores prácticas antes de ir a producción.

Esta guía es para desarrolladores que ya trabajan con specs y quieren cerrar su ciclo con una revisión previa antes del merge.

Cómo hacer una revisión previa con el comando /review

Después de que el agente termina las tareas de un spec, el flujo natural es hacer commit y generar un pull request en GitHub. En este caso se cerraron cuatro todos y se sumaron 868 líneas nuevas en el pull request número 20 [00:30].

Con el código ya subido, entra el comando /review. Le indicas a qué apuntar (el pull request 20) y el agente hace un diff entre main y tu branch [01:35].

El veredicto que devolvió fue aprobar con comentarios menores: cumple la spec 10, buena cobertura de test y alineado con los patrones del repo. Pero también marcó un hallazgo importante.

¿Qué hace el comando /review en Cursor? Compara tu pull request contra la rama principal, resume qué está bien y lista los hallazgos de calidad y seguridad. Devuelve un veredicto claro: aprobar, aprobar con comentarios o rechazar.

Qué hallazgos encontró la primera revisión

Los puntos que detectó el /review fueron concretos:

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

Al pedirle reparar los hallazgos importantes, el agente eliminó los stubs que devolvían enable false, corrió los tests y todos pasaron [03:00].

Y aquí viene lo interesante: los checks de TypeScript fallaron por el hook creado en clases anteriores. El agente iteró solo, corrigió los types y volvió a validar hasta que pasaron.

Qué es el marketplace de Cursor y cómo instalar herramientas

Cursor permite ampliar su capacidad de revisión con customizaciones. En la parte superior izquierda del editor está el tab Customize, que te lleva al marketplace [04:15].

El marketplace es una sección donde empresas comparten herramientas para desarrollar código. Por ejemplo, Figma ofrece un MCP que trae diseños directamente al editor.

¿Qué es un MCP en Cursor? Es una herramienta que conecta tu editor con servicios externos. El MCP de Figma, por ejemplo, hace request al diseño y lo trae a tu entorno de código sin salir de Cursor.

La herramienta clave aquí es el Cursor Team Kit, el set que usan los propios desarrolladores de Cursor para validar la calidad de su código. Incluye 18 skills, dos subagentes y dos reglas [05:20].

Cómo instalar el Cursor Team Kit

Instalarlo toma pocos pasos:

1. Entra a Customize y abre el marketplace.
2. Selecciona el Cursor Team Kit y da clic en Add to Cursor.
3. Elige el proyecto donde lo quieres instalar y confirma con Add plugin.

Una vez instalado, entre los skills aparece uno especial: Thermonuclear Code Quality Review.

Cómo usar el skill Thermonuclear Code Quality Review

El Thermonuclear no solo evalúa que tu código funcione, sino que cumpla las mejores prácticas de desarrollo de software. Puedes usarlo de dos formas [06:40]:

• Como skill, dentro de la misma conversación.
• Como subagent, delegando la evaluación a un subagente aparte.

Al correrlo sobre el pull request 20, el veredicto cambió: no aprobar todavía. Y aquí está la diferencia con el /review, que sí lo había aprobado.

Thermonuclear detectó que el PR mezclaba dos specs, introducía drift de tipos y dejaba oportunidades de simplificación. Ese drift nació de una decisión previa: al corregir los tipos en el /review, se mezcló el spec 9 con el 10.

Qué problemas detectó Thermonuclear

El detalle fue mucho más profundo:

• Regresión estructural por mezclar dos specs.
• Drift de tipos, ya identificado.
• Normalización de contexto triplicada: tres implementaciones independientes del mismo concepto.
• Complejidad muerta en la UI del match rule que debería eliminarse.

Esa normalización triplicada se puede resolver con una sola función. Ese es el tipo de mejora que un review básico no siempre marca.

Cómo planear las correcciones con el plan mode

Como son varios cambios, conviene cambiar al plan mode en lugar de ejecutar directo. Primero planeas, luego construyes [09:30].

Al pedirle crear un plan, el agente hizo preguntas concretas: cómo abordar la mezcla del PR 9 y 10 y qué hacer con el scaffolding del MatchRule. La decisión fue mantener un solo PR con commits atómicos separados e implementar el ciclo end-to-end sin eliminar código antes de validarlo con QA manual.

¿Por qué usar plan mode antes de corregir varios hallazgos? Porque separa la estrategia de la ejecución. Defines fases, riesgos y mitigaciones primero, y así evitas romper el pull request con cambios desordenados.

El plan quedó dividido en fases: normalización, alineación de tipos con el domain y limpieza transversal de los commits. También contempló riesgos como el force push, necesario porque se modificaba el historial de commits.

Tras aprobar el plan y dar clic en build, el agente modificó 24 archivos, actualizó el summary y dejó checks para el QA manual [12:00]. Lo que sigue en un flujo real es abrir staging, probar, hacer QA manual y recién ahí enviar a master.

Tu reto es navegar el marketplace de Cursor, encontrar herramientas para tu flujo diario, instalar el Cursor Team Kit y correr Thermonuclear. Déjame en los comentarios cuántos hallazgos encontró en tu código.