Tanto en mi trabajo de consultoría como en mis proyectos personales, uso git y en particular GitHub como infraestructura principal para tareas (issues), pull requests, y repositorio de código. Siempre fui muy amigo de automatizar todo lo posible usando el comando gh para poder interactuar con todo desde la línea de comandos. Este workflow funciona en forma inmediata con Claude Code, y de hecho, en mi opinión, es la mejor forma de usar GitHub.

GitHub Projects y Sprints

Normalmente uso GitHub Projects con una lista priorizada y ordenada de tareas, como se debe. Tengo un script TUI¹ que corro y que busca la lista de issues que tengo asignados al sprint actual. Selecciono en que quiero trabajar y el script automáticamente me crea un worktree, copia archivos de configuración, bases de datos y todo lo necesario para poder empezar a trabajar.

Git Worktrees

Si no los conocés, los git worktrees son una forma de tener múltiples copias de trabajo del mismo repositorio sin tener que clonar todo de nuevo. Cada worktree es una carpeta separada con su propio branch, pero a su vez están todos conectados entre sí por el mismo .git.

Cada issue tiene su propio worktree, su propia copia de la base de datos y su propio branch, si estoy trabajando en web, uso el numero de issue como puerto del server de desarrollo, para que no haya colisión con los otros worktrees. La idea principal es que pueda trabajar en múltiples cosas a la vez sin que se pisen.

El script que mencioné antes crea el worktree automáticamente y copia todo lo necesario. Cuando el PR se mergea, tengo otro script que limpia los worktrees de PRs mergeados.

Conectando Claude Code con GitHub

En mi CLAUDE.md tengo una convención para nombrar los branches: [issue-number]-branch-name. Esto me permite simplemente decirle a Claude "buscá la descripción del issue" y ya sabe dónde encontrar el número del issue a partir del nombre del branch.

Una vez que Claude tiene la información del issue, el workflow de definición de requerimientos empieza. Pero eso lo cuento en el post sobre especificaciones.

Rebase interactivo con Claude Code

Esto es algo que me sorprendió: Claude Code es muy bueno haciendo rebase interactivo. Es excelente identificando el estado final que deberían tener los conflictos.

El truco es decirle que si tiene dudas me pregunte y no asuma nada. A veces los conflictos son ambiguos y es mejor que pregunte antes de tomar una decisión incorrecta.

GitHub Actions

Claude Code puede leer directamente los resultados de GitHub Actions. Cuando un pipeline falla, le digo que revise los errores y los arregle.

También uso pre-commit hooks extensivamente para evitar subir código problemático, pero eso lo desarrollo más en el post sobre code review.

Futuro

Hay cosas que todavía quiero automatizar:

• Releases automáticos: ahora estoy haciendo tags y releases a mano cuando hago deployment a Render.
• Integración con Render: el deployment a producción es "manual" (un botón igual eh, nada loco).

Quiero mejorar esto para automatizar todo con un comando bin/deploy, que me genere los tags, releases y dispare el deployment en los servicios adecuados en render. Sigue siendo manual, pero con un sólo script que hace todo, y voy a poder decirle a Claude Code "hace deploy a producción y revisá que todo esté bien en Render" (render tiene un mcp server y un CLI, así que debería funcionar de una forma u otra).

Lo que viene

Con el workflow de GitHub integrado, tengo todo lo necesario para elegir una tarea y empezar a trabajar. Pero antes de escribir código, hay un paso crucial: definir qué vamos a construir.

Mencioné antes que le pido a Claude que lea la descripción del issue. Pero un issue de GitHub rara vez tiene toda la información necesaria para implementar algo bien. Ahí es donde entran las especificaciones: documentos que escribo con Claude donde definimos exactamente qué hay que hacer, cómo debe comportarse, y qué casos edge considerar.

En el próximo post voy a contar cómo uso Claude Code para generar y refinar especificaciones antes de escribir una sola línea de código.

---