Automatización para crear Pull Requests

Crear un Pull Request parece una tarea corta, pero al repetirla todos los días empecé a notar una secuencia constante: revisar el repositorio, actualizar las referencias remotas, identificar las ramas correctas, preparar el título, completar el cuerpo, seleccionar un label, asignar a una persona y confirmar que no existiera otro PR con el mismo origen y destino.

Completar el cuerpo también implicaba reunir información que seguía una estructura conocida: detalles de la historia de usuario, descripción de los cambios realizados, dependencias con otros repositorios y resultado final de la cobertura de pruebas unitarias.

Cada paso era sencillo por separado. El problema estaba en la repetición, en el cambio de contexto y en la posibilidad de cometer un error al escoger una rama o volver a crear algo que ya existía. Además, una misma feature debía avanzar por qa, staging y release, por lo que buena parte del proceso y de la información se repetía en cada nuevo Pull Request.

La automatización no empezó escribiendo código. Empezó observando con atención una tarea que hacía de forma manual y reconociendo qué decisiones podían convertirse en reglas.

Entender antes de automatizar

Antes de escribir una sola línea de código, me senté a descomponer el proceso que realizaba diariamente. Identifiqué qué información debía consultar, qué selecciones se repetían, qué partes del cuerpo podía reutilizar durante el recorrido entre ambientes y cuáles eran las validaciones necesarias para crear un Pull Request con confianza.

También dediqué tiempo a entender cómo funcionaba GitHub CLI. Para mí, no se trataba solamente de ejecutar gh pr create: necesitaba comprender cómo comprobar la autenticación, consultar metadatos del repositorio, obtener labels, detectar Pull Requests abiertos y pasar el título, el cuerpo, las ramas, el label y la persona asignada sin depender de preguntas interactivas.

Ese aprendizaje me permitió diseñar un flujo donde la herramienta:

• Detecta o permite seleccionar un repositorio Git.
• Consulta y actualiza las referencias de origin.
• Mantiene separada la rama local actual de la rama remota que será el origen del PR.
• Sugiere una rama destino según patrones identificados en el trabajo cotidiano.
• Permite elegir una plantilla Markdown para el cuerpo del Pull Request y revisar su contenido.
• Consulta los labels disponibles en el repositorio.
• Valida que las ramas existan y sean diferentes.
• Comprueba que no haya un Pull Request abierto con la misma combinación.
• Muestra una confirmación completa antes de ejecutar la creación.

Del patrón repetitivo a una interfaz

Construí una interfaz gráfica con Tkinter para reunir todo el proceso en un solo lugar. Desde ella puedo seleccionar las ramas remotas de origen y destino, revisar o modificar el título sugerido, escoger una plantilla, un label y una persona asignada.

Para construirla, usé Git para conocer el estado del repositorio, cambiar de rama local cuando se solicita y actualizar las referencias remotas. Decidí delegar la creación y consulta de Pull Requests a GitHub CLI, aprovechando su sesión autenticada sin leer, guardar ni administrar tokens propios.

Repositorio Git
  ↓
Consulta y actualización de ramas remotas
  ↓
Selección de origen, destino y metadatos
  ↓
Validaciones y búsqueda de PR duplicado
  ↓
Confirmación del usuario
  ↓
Creación mediante GitHub CLI

También decidí trabajar en detalles que, desde mi experiencia, hacen que una automatización sea realmente útil: carga de datos sin bloquear la interfaz, mensajes de progreso, manejo de errores y una vista previa de las plantillas Markdown.

Un proyecto construido con IA

Este proyecto fue construido con ayuda de inteligencia artificial, y agradezco esa capacidad porque me permitió convertir la idea en una herramienta funcional en pocas horas. Sin embargo, el proceso no fue escribir un prompt y aceptar un resultado terminado.

La IA aceleró la implementación, me ayudó a explorar alternativas y sirvió como compañera para revisar decisiones. Detrás hubo un trabajo manual previo: observar mi rutina, documentar el flujo, aprender los comandos de GitHub CLI, identificar casos límite, decidir qué acciones debían confirmarse y probar el comportamiento sobre repositorios reales.

El desarrollo fue iterativo. Cada versión revelaba una nueva pregunta: qué ocurría si la rama local no era el origen del PR, cómo evitar duplicados, cómo distinguir plantillas con el mismo nombre o cómo reaccionar si una rama remota desaparecía. Esas preguntas guiaron las mejoras y me ayudaron a entender el código que estaba construyendo con apoyo de IA.

Tecnologías usadas

• Python 3.10+ como lenguaje principal.
• Tkinter para la interfaz gráfica.
• Git para consultar el repositorio y sus ramas.
• GitHub CLI (gh) para autenticación, consultas y creación del Pull Request.
• Markdown para las plantillas reutilizables.
• Inteligencia artificial como apoyo durante el análisis, la implementación y la revisión.

La herramienta no necesita paquetes externos de Python. Además, ejecuta los comandos de forma controlada, con sus argumentos definidos explícitamente; no realiza push, no crea ramas remotas y siempre solicita confirmación antes de crear un Pull Request real.

Resultado

Terminé creando una herramienta personal que concentra en una sola interfaz las decisiones que antes debía repetir manualmente. Con ella puedo preparar un Pull Request con mayor rapidez, mantener consistencia en títulos y plantillas, reducir errores de selección y conservar el control sobre la acción final.

Para mí, el proyecto hizo algo más que ahorrar clics: convirtió una experiencia cotidiana en una solución reutilizable. La velocidad de la IA fue importante, pero su verdadero valor apareció después de haber entendido el problema y de poder darle contexto, restricciones y criterios claros.

Lo que aprendí

Este proyecto me reafirmó que automatizar no es saltarse el conocimiento del proceso. Para decidir qué delegar a una herramienta, primero tuve que comprender cada paso y reconocer cuáles requerían una decisión humana.

También confirmé que construir con IA sigue siendo construir: implica analizar, hacer preguntas, validar supuestos, probar casos reales, revisar el resultado y tomar decisiones técnicas. Gracias a esa combinación entre conocimiento del proceso, aprendizaje de GitHub CLI e iteración con IA, pude crear en pocas horas una solución que nació directamente de una necesidad que experimentaba todos los días.

Próximos pasos

El siguiente paso que quiero dar es crear una skill que reciba como parámetro un Pull Request. Quiero que la skill ejecute un script conectado a GitHub CLI para consultar el Pull Request, sus archivos modificados y los cambios realizados.

Con ese contexto, quiero que el LLM analice el cambio real y redacte en lenguaje natural la sección Cambios realizados del cuerpo del Pull Request. Busco que pueda explicar con claridad los ajustes, las correcciones o las nuevas funcionalidades incluidas, sin que tenga que escribir ese resumen manualmente desde cero.

Con esto, quiero que la automatización pase de preparar la estructura del Pull Request a ayudarme también a documentar su contenido a partir de la información técnica disponible.