¡Hola developer 👋🏻!
Justo acabo de grabar un vídeo que sale la semana que viene 😅, donde cuento qué flujos estoy utilizando yo a día de hoy con GitHub Copilot CLI para hacerme la vida más fácil.

👉 En cuanto el vídeo esté publicado, lo enlazaré directamente en este artículo.

Y casi al mismo tiempo, ayer se anunció la disponibilidad en technical preview de una nueva iniciativa para crear flujos agénticos automatizados apoyados en GitHub Actions… pero no exactamente de la forma que quizá esperabas.

No, no estamos hablando (todavía 😏) de integrar directamente GitHub Copilot CLI dentro de los workflows —de eso hablaremos en el vídeo de la semana que viene —, sino de algo bastante diferente y, en mi opinión, muy potente:
👉 definir workflows usando Markdown, olvidándote (en gran parte) de escribir YAML a mano como veníamos haciendo hasta ahora.

En este artículo te cuento:

• Qué es esta nueva aproximación
• Qué necesitas instalar
• Cómo crear tu primer flujo agéntico
• Y cómo funciona la “magia” por debajo ✨

🎥 Antes de seguir: cómo funcionaba GitHub Actions hasta ahora

Antes de entrar en este nuevo enfoque, es importante tener claro cómo hemos estado definiendo workflows en GitHub Actions hasta hoy.

Si necesitas refrescar conceptos o entender bien la base sobre la que se construye todo esto, tengo una playlist completa en YouTube sobre GitHub Actions “clásicos” 🤭, definidos en YAML.

👉 En esa playlist explico:

• Cómo funciona GitHub Actions por dentro
• Triggers, jobs y steps
• Cómo se estructura un workflow en YAML
• Patrones habituales y buenas prácticas

📺 Playlist: GitHub Actions desde cero (enfoque tradicional)

💡 Precisamente por eso este artículo es interesante:
todo lo que ves en esa playlist sigue siendo válido, pero ahora aparece una nueva capa que nos permite definir workflows de forma más declarativa y agéntica, sin escribir directamente el YAML.

Y ahora sí, vamos al lío 👇

🧠 ¿Qué es un flujo agéntico en GitHub Actions?

Hasta ahora, cuando queríamos automatizar algo en GitHub Actions, lo normal era definir un workflow en YAML: eventos, jobs, pasos, condiciones, permisos… todo de forma bastante explícita.

Con esta nueva iniciativa en technical preview, la idea cambia ligeramente.

En lugar de describir cómo debe ejecutarse cada paso, pasamos a describir qué queremos que ocurra.

La base es sencilla:

• Creas un archivo Markdown
• En ese archivo defines la intención del flujo
• Describes las tareas que debe realizar
• Y GitHub se encarga de generar el workflow real por debajo

Es decir, el YAML sigue existiendo, pero deja de ser algo que tengas que escribir y mantener a mano.

Este enfoque encaja especialmente bien con flujos más agénticos, donde lo importante no es tanto la secuencia exacta de pasos, sino el objetivo final y las reglas que deben cumplirse.

🧩 Requisitos previos: GitHub CLI + extensión aw

Para crear este tipo de flujos no basta con añadir un .md dentro de .github/workflows.
Antes necesitas preparar tu entorno local.

1️⃣ Instalar GitHub CLI

Si no lo tienes ya, instala GitHub CLI.
En macOS, por ejemplo:

brew install gh

2️⃣ Instalar la extensión aw (Agentic Workflows)

Esta nueva funcionalidad vive en una extensión llamada aw.

gh extension install github/gh-aw

Si este comando falla y ves un error como:

X Could not find extension 'github/gh-aw' on host github.com

puedes instalarla manualmente así:

curl -sL https://raw.githubusercontent.com/github/gh-aw/main/install-gh-aw.sh | bash

Una vez hecho esto, ya estás list@ para crear y compilar workflows agénticos 🎉

🤖 Un flujo agéntico para GitHub Actions (ejemplo práctico)

Vamos a verlo con un ejemplo sencillo y muy realista.

👉 Imagina que alguien crea un Issue “de aquella manera”
👉 Quieres que automáticamente se mejore: formato, idioma, claridad, labels…

Para ello he creado este archivo dentro de mi repositorio: .github/workflows/issue-quality-enhancer.md con el siguiente contenido:

---
on:
  issues:
    types: [opened]
permissions:
  issues: read
safe-outputs:
  update-issue:
    title:
    body:
tools:
  github:
    toolsets: [issues]
---
# Issue Quality Enhancer
Enhance new issues to make them clear, well-structured, and easy to understand.
## Issue to enhance
| Field  | Value          |
| ------ | -------------- |
| Number | #$ISSUE_NUMBER |
| Author | @$ISSUE_AUTHOR |
| Title  | $ISSUE_TITLE   |
| Body   | $ISSUE_BODY    |
## Your tasks
### 1. Get context
- Read the README to understand the project
- List the repository labels (you'll need them later)
### 2. Translate if needed
- If the issue is NOT in English, translate it to English
- Keep all technical details intact
### 3. Improve the title
Add an emoji prefix based on the issue type:
- 🐛 Bug
- ✨ Feature
- 📝 Docs
- 🔧 Refactor
- ⚡ Performance
Example: `🐛 Fix login error when password contains special characters`
### 4. Restructure the body
Use clear sections with emoji headers:
**For bugs:**
```
## 🐛 Description
## 📋 Steps to Reproduce
## ✅ Expected vs ❌ Actual Behavior
```
**For features:**
```
## ✨ Description
## 🎯 Why is this needed?
## 📐 Proposed Solution
```
### 5. Add footer
```
---
> ✍️ *Enhanced by Copilot. Original author: @$ISSUE_AUTHOR*
```
### 6. Apply changes
- **Update** issue #$ISSUE_NUMBER with the new title and body
- **Assign** 1-3 relevant labels
- **Comment** with a brief summary of improvements
## Rules
- Never change the original meaning
- If already well-written, make minimal changes
- Keep it helpful, not verbose

📌 Importante: aquí no estamos escribiendo YAML, estamos describiendo el comportamiento esperado del flujo.

Si lo revisamos detenidamente encontramos:

• Como en cualquier otro flujo, necesito indicarle cuándo se va a ejecutar el mismo a través de la propiedad on. Esto es casi igual que un flujo de GitHub Actions convencional.
• La sección de permissions se combiba con la de safe-outputs para limitar el scope del agente, es decir qué puede hacer.
• Como cualquier otro agente de IA es posible que necesite usar algunas tools. En este ejemplo estamos usando el MCP server de GitHub pero le tengo restringido únicamente al toolset que tiene que ver con los issues.

De esta forma puedes ver que no puede hacer cualquier cosa pero a la vez facilitarnos la vida 😃

⚙️ Compilar el flujo agéntico

El archivo Markdown que acabamos de crear no es todavía un workflow ejecutable por GitHub Actions.

Antes, es necesario un paso intermedio: compilar el flujo.

Al compilarlo, GitHub traduce la intención que hemos definido en Markdown a un workflow real de GitHub Actions, generando automáticamente los archivos necesarios.

Para ello, basta con ejecutar el siguiente comando desde el repositorio:

gh aw compile

Tras ejecutar este comando, verás que ocurren varias cosas:

• Se crea un nuevo directorio .github/aw
• Se genera un archivo .lock.yml dentro de .github/workflows
• Ese .lock.yml contiene el workflow real en YAML, listo para ser ejecutado por GitHub Actions

🔍 Lo importante aquí es que:

• El YAML sigue existiendo
• GitHub Actions sigue funcionando igual
• Pero tú ya no tienes que escribir ni mantener ese YAML a mano

A partir de este momento, cualquier cambio que hagas en el Markdown y vuelvas a compilar actualizará automáticamente el workflow generado.

🔐 Crear un PAT con scope Copilot Requests para tu repositorio

Estos flujos hacen uso de tu suscripción de GitHub Copilot, así que necesitas un Personal Access Token con el permiso adecuado.

Lo único que tienes que hacer es ir a https://github.com/settings/personal-access-tokens/new y crear un token con el scope ✅ Copilot Requests

Puedes configurarlo en tu repositorio con el siguiente comando:

gh aw secrets set COPILOT_GITHUB_TOKEN --value TU_PAT

🧪 Probando el resultado

En mi caso, simplemente creé un Issue con:

• Título: Añadir endpoint para gestionar productos
• Descripción: hacer el CRUD completo

Vamos… bastante justito 😅

En la pestaña Actions puedes ver que el flujo se ejecuta como cualquier otro workflow.

Si te fijas en los pasos, verás que por debajo se apoya en GitHub Copilot CLI, aunque tú no hayas tenido que invocarlo directamente 👀

Y, finalmente…
🎉 el Issue aparece mejorado, estructurado y etiquetado automáticamente.

¡Nos vemos 👋🏻!
(y ojo al vídeo de la semana que viene 😉)