Cuando trabajas en un proyecto con Cursor y acumulas cambios sin hacer commits, el skill Split to PRs te ayuda a dividir el código en pull requests ordenados y generar los commits automáticamente. Es ideal para quienes delegan tareas a subagentes y quieren evitar que un compañero revise miles de líneas de golpe.

En este punto del proyecto ya tenemos el PRD, los specs y las reglas listos, pero aparece un problema concreto en pantalla: la terminal marca 2055 líneas en review [00:12]. Eso significa que no hicimos ningún commit inicial ni creamos un pull request, y alguien tendría que leer todo ese código manualmente antes de enviarlo a producción.

Qué hace el skill Split to PRs en Cursor

El skill lee el contexto completo de lo que hiciste y divide ese trabajo en varios pull requests, generando además los commits correspondientes. Lo invocas, le das enter y esperas a que trabaje [00:40].

Antes de mover nada, el agente revisa el estado del repositorio, los commits previos y la situación actual. Luego arma un diagrama de lo importante y recomienda qué debería llevar cada pull request.

¿Qué es un pull request? Es una solicitud para integrar tus cambios de código a la rama principal del proyecto. Permite que otra persona revise tu trabajo antes de que llegue a producción.

Un detalle que da mucha tranquilidad: el skill incluye tips de seguridad. Antes de actuar guarda un snapshot recuperable, evita comandos destructivos y te pide confirmación explícita [00:57].

Por qué el agente pide autorización antes de ejecutar comandos

Al aprobar el plan, el agente no actúa en automático con todo. Primero crea el commit inicial, porque el repositorio ni siquiera tenía uno [01:08]. Después pide autorización para ejecutar comandos delicados.

Uno de esos comandos pertenece a Git y sirve para firmar los commits con tu nombre y tu email [01:30]. Cuando el agente considera que un comando es sensible por seguridad, se detiene y te pide permiso antes de ejecutarlo.

¿Por qué Cursor pide confirmación en ciertos comandos? Porque algunos comandos de Git pueden ser delicados o irreversibles. El agente frena y espera tu aprobación para que mantengas el control sobre cada acción crítica.

Al terminar, el agente reporta que abrió tres pull requests y que dejó un backup con un commit recuperable por si algo salió mal [01:53].

Cómo quedó la división en tres pull requests

Al entrar a GitHub, en el tab de pull request, aparecen los tres PRs creados con una lógica que respeta la misma estructura del proyecto:

• El primero contiene la documentación sobre el feature flag y el PRD.
• El segundo reúne los specs.
• El tercero agrupa las cursor rules y el archivo AGENTS.md.

Lo interesante es que el agente entendió por sí solo la misma división que venimos trabajando en el curso: PRD, specs y reglas [02:11]. Cada pull request llega listo para code review con tres elementos clave.

• Un summary que resume el cambio.
• Un scope que define el alcance.
• Un test plan con el plan de pruebas.

Como en este caso no vamos a enviar el code review a un compañero, hacemos merge directo de cada uno a la rama main [02:40]. Primero el PR de la documentación, luego el de los specs y al final el de las reglas.

Qué hacer después de hacer merge de los PRs

Una vez que integras todos los pull requests a main, queda un último paso para mantener todo sincronizado. Le dices al agente: "Ya hice merge de todos los PR. Actualiza mi rama main" [03:10].

Con eso tu rama local queda al día y el proyecto listo para empezar a delegar tareas a los subagentes en el siguiente módulo.

En este recorrido aprendiste varios poderes de Cursor que ahorran trabajo real: seleccionar distintos modelos de LLM, preguntar en los modos ask, plan o agent mode, crear reglas para direccionar a los subagentes y automatizar la creación de PRs y commits con los skills. Te invito a probar Split to PRs en tu propio proyecto y comentar cuánto tiempo te ahorró.