Cómo Split to PRs organiza tu código automáticamente

Cuando llevas más de 2000 líneas de código sin haber hecho un solo commit, tu proyecto tiene un problema serio de revisión. Aquí entra en juego el skill Split to PRs de Cursor, una herramienta que automatiza la creación de pull requests organizados y te ahorra horas de trabajo manual antes de enviar tu código a producción.

¿Por qué necesitas dividir tu código en varios pull requests?

Imagina que tu compañero abre GitHub y se encuentra con 2055 líneas en review dentro de un solo pull request. Nadie quiere leer eso manualmente, y menos aprobarlo con la confianza de que nada se escapa.

Dividir el trabajo en PRs pequeños y temáticos permite revisiones más rápidas, feedback más preciso y un historial de Git limpio. En el proyecto del curso teníamos tres bloques claros: el PRD, los specs y las reglas. Cada uno merece su propio pull request.

¿Qué es un pull request? Es una solicitud para integrar cambios de una rama a otra (normalmente a main). Sirve para que tu equipo revise, comente y apruebe el código antes de fusionarlo.

¿Cómo funciona el skill Split to PRs de Cursor?

El skill lee todo el contexto de lo que has hecho, revisa el estado del repositorio, analiza los commits previos y propone una división lógica de los cambios [01:00]. No solo separa archivos: entiende la intención detrás de tu trabajo.

Antes de tocar nada, el agente genera un diagrama de lo importante y te da recomendaciones sobre qué debería llevar cada pull request. También incluye tips de seguridad que valen oro:

• Guardar un snapshot recuperable antes de mover archivos.
• No ejecutar comandos destructivos sin confirmación.
• Pedirte autorización explícita antes de acciones sensibles.

En nuestro caso ni siquiera existía un commit inicial, así que el agente propuso crearlo, generar los tres PRs y hacer push a origin. Tú apruebas paso a paso.

¿Qué pasa cuando el agente pide autorización para ejecutar comandos?

Cuando Cursor detecta que un comando es delicado, como firmar commits de Git con tu nombre y email, se detiene y te pide permiso [01:35]. Este comportamiento es intencional: los comandos que tocan tu identidad, tu historial o tu repositorio remoto no se ejecutan a ciegas.

Tú das el visto bueno una vez, el agente lo ejecuta y sigue con el flujo. Si aparece otro comando sensible más adelante, vuelve a pedirte confirmación. Nunca pierdes el control.

¿Cómo quedó la división de los pull requests en el proyecto?

El agente entendió la misma lógica que hemos seguido en el curso y creó tres pull requests alineados con las capas del proyecto [02:15]:

1. Documentación del feature flag y el PRD.
2. Los specs con los archivos técnicos.
3. Las Cursor rules junto con el archivo agents.md.

Cada PR llegó a GitHub con su summary, su scope y su test plan listos. Eso significa que un revisor puede entender de un vistazo qué cambió, hasta dónde llega el alcance y cómo validar que todo funciona.

¿Qué debe incluir un buen pull request? Un resumen claro de los cambios, el alcance de lo modificado y un plan de pruebas. Con esos tres bloques, cualquier compañero puede revisar sin adivinar.

Como no íbamos a enviar el código a code review en este ejercicio, hicimos merge directo de los tres PRs a la rama main. Uno por uno, sin fricción.

¿Qué haces después de mergear los pull requests?

Una vez todo está en main, le indicas al agente que ya hiciste merge de todos los PRs y le pides que actualice tu rama local [03:20]. Este paso mantiene tu entorno sincronizado con el remoto y evita conflictos cuando empieces la siguiente tarea.

Con la rama main actualizada, quedas listo para delegar el trabajo a los subagentes en el próximo módulo.

Qué habilidades aprendiste con Cursor hasta este punto

Este módulo te dejó varias capacidades concretas que puedes aplicar de inmediato en cualquier proyecto:

• Seleccionar distintos modelos de LLM según la tarea.
• Alternar entre los modos Ask, Plan y Agent según lo que necesites resolver.
• Crear reglas que direccionan el comportamiento de los subagentes.
• Usar skills como Split to PRs para automatizar commits y pull requests.

La próxima vez que abras tu editor con cientos de líneas sin commit, prueba este skill en tu propio repositorio. Cuéntame en los comentarios cómo dividió tu trabajo el agente y si respetó la estructura que tenías en mente.