agentic-board: agentes de Claude Code en tu board de GitHub | Cristobal Salcedo

Llevo meses gestionando repositorios de Power BI y Fabric en GitHub y el patrón siempre se repite: crear los issues, mover tarjetas en el board, configurar campos de prioridad, empezar la rama, abrir el PR, cuidar la revisión, mergear… todo a mano. Decidí automatizarlo.

Nota: este proyecto nació como agentic-bi-ops y desde la v0.16 se llama agentic-board. Esta página se movió a /blog/agentic-board/ para que la dirección coincida con el nombre real; si tenías guardado el enlace anterior (/blog/agentic-bi-ops/), sigue funcionando y te trae aquí. El alias agentic-bi-ops también sigue vivo dentro del plugin por compatibilidad.

agentic-board es un plugin para Claude Code que convierte pedidos en lenguaje natural en operaciones reales sobre GitHub Projects v2 — y va más allá de administrar el board: corre agentes de código sobre él. Le pides en texto plano lo que necesitas:

/board work                      # elige el próximo issue y lo lleva de principio a fin
/board plan                      # convierte un plan en epic + sub-issues nativos
/board move #42 to Done          # mueve la tarjeta
/board bulk close label:stale    # cierre masivo con dry-run previo
/expert auto 123                 # ejecuta un plan del board de forma autónoma
/scan                            # detecta trabajo sin trackear en el repo

(Una muestra, no la lista completa: /board tiene una veintena de sub-acciones.)

Son siete comandos de primer nivel:

Comando	Para qué
`/board`	Administra y automatiza el board y sus issues — es el que más sub-acciones tiene
`/expert`	Modo experto autónomo: coge un plan y lo ejecuta solo
`/scan`	Detecta trabajo sin trackear en el repo actual y lo convierte en issues
`/skills`	Ciclo de vida de Agent Skills: organizar, auditar, bootstrapear
`/knowledge`	Registro de referencias del proyecto por dominio
`/tools`	Catálogo unificado de herramientas externas: ver, investigar e instalar
`/docs`	Publica la documentación del proyecto al wiki en un solo push

La lista completa y siempre al día está en el README del repositorio: esa tabla se genera desde el código y CI falla si se queda desactualizada, así que no puede mentir. Este artículo no la duplica a propósito — ya se quedó viejo dos veces por intentarlo.

Lo que lo hace distinto

Tu board real, no una copia local. Opera las APIs de GitHub Projects (v2) e Issues a través del gh CLI — el mismo board que ya usa tu equipo, no un Kanban desechable en una pestaña.
/board work: el loop completo. Elige el próximo issue por prioridad, lo arranca en su propia rama y worktree, lo lleva por un PR y un review gate, y lo mergea. El ciclo issue → branch → PR → gate → merge sin que tengas que hilar cada paso a mano.
Trabajo en paralelo. /board work puede arrancar varios issues independientes a la vez, cada uno en su propio git worktree, y opcionalmente lanzar una sesión de agente por issue.
Fleet multi-CLI. El coordinador puede sondear la cuota y disponibilidad de varios CLIs (Claude, Gemini, Codex, Jules, Copilot) antes de repartirles trabajo — usar el que esté disponible en vez de chocar contra un límite.
Modo experto autónomo (/expert). Le das un issue del board y lo ejecuta solo: adopta un rol especializado según el dominio del plan, investiga antes de construir, trabaja test-first, deja evidencia de cada prueba en el PR y en el issue, y se auto-usa el propio board para el trabajo lateral que va encontrando. Tú te liberas y lo sigues con /board work -Sessions -Watch.

Y frena antes de lo irreversible. El freno no es una instrucción en un texto que el agente pueda reinterpretar: es un marcador en su worktree y un hook que intercepta la llamada antes de ejecutarla. Cubre merge, deploy, refresh, publish y delete — incluido el git push directo a la rama principal — y el propio agente no puede desarmarlo, porque tocar su marcador también está bloqueado. Llega a “PR listo” y ahí para.
Review-gated por defecto. Cada issue termina pasando por un PR y un review gate (revisión de Copilot + checks de CI + verificación de hilos sin resolver) antes de poder mergear. La higiene de GitHub la impone el flujo, no la fuerza de voluntad.

Qué incluye

Capacidad	Para qué sirve
`/board work`	El loop diario: elige, arranca en rama+worktree, PR, review gate y merge — en serie o en paralelo
`/board plan`	Convierte un plan en un epic con sub-issues nativos, listo para trabajar
`gh-account`	Resuelve el token activo sin llamar a `gh auth switch` — varias cuentas GitHub desde una misma máquina
`projects-admin`	Crea, configura y opera boards: campos, items, presets ES/EN, automáticos de CI
`project-scan` (`/scan`)	Escanea el repo buscando TODOs, checklists sin tachar y planes sin trackear — los convierte en issues
`skills-ops` (`/skills`)	Ciclo de vida de Agent Skills: organizar, auditar y bootstrapear buenas prácticas
`knowledge-ops` (`/knowledge`)	Registro de referencias del proyecto por dominio (`add` / `harvest` / `list` / `wiki`), versionado en `knowledge/registry.json`
`board-expert` (`/expert`)	Ejecuta un plan del board de forma autónoma con un rol experto, evidencia registrada y freno mecánico ante lo irreversible
`tools-catalog` (`/tools`)	Catálogo unificado de las herramientas externas que referencia el proyecto: ver, investigar e instalar
`handoff`	Guarda y retoma el contexto entre sesiones (`save`/`resume`) para continuar días después, incluso en otra máquina
`changelog`	Genera el bloque de CHANGELOG (Added/Changed/Fixed) desde los issues en Done
`tmdl-review`	Revisa el diff TMDL de un cambio PBIP/Fabric y clasifica cambios de esquema BREAKING/WARNING/INFO
`abios-feedback`	Captura mejoras encontradas en proyectos privados de forma sanitizada, sin filtrar datos privados de vuelta al repo público

Cómo instalar

/plugin marketplace add CSalcedoDataBI/agentic-board
/plugin install agentic-board

Luego actívalo en los plugins de Claude Code. Necesitas el gh CLI autenticado y un Personal Access Token con los scopes repo y project, configurado como variable de entorno del sistema (GITHUB_TOKEN_PERSONAL por defecto).

Diseño de seguridad

El plugin nunca modifica tu estado global de gh: resuelve el token correcto por cuenta desde variables de entorno del sistema operativo, no desde gh auth. Para operaciones destructivas siempre presenta un resumen antes de ejecutar y pide confirmación, y hace un backup del board antes de cualquier delete. Incluye un hook de pre-commit/pre-push que bloquea commits con secretos o términos privados configurables por repo.

Cuando un agente trabaja solo, el plugin le arma un freno mecánico: un marcador en su worktree y un hook que intercepta la llamada antes de ejecutarla. No es una instrucción en un texto que el agente pueda reinterpretar — es una negativa a nivel de herramienta. El freno cubre merge, deploy, refresh, publish y delete, incluido el git push directo a la rama principal, y el propio agente no puede desarmarlo: tocar su marcador también está bloqueado.

Continuidad entre sesiones

Un flujo de agentes se corta cuando cierras la sesión. /board handoff save compone un contexto curado —próximo paso, qué se hizo, hilos abiertos, trampas, archivos clave— lo guarda y lo deja como comentario durable en el issue enlazado. Días después, en una sesión nueva, /board handoff resume lo rehidrata, reporta si la rama o el PR cambiaron, y ofrece retomar el issue donde quedó. El trabajo no se pierde entre sesiones.

Dogfooding

La herramienta se gobierna a sí misma: su roadmap vive en su propio board de GitHub. Cada bug que aparece mientras la uso en proyectos reales se captura como issue público a través del skill abios-feedback. Eso mantiene el ciclo honesto — no hay mejoras que se queden enterradas en un repo privado.

Board sync automático

El repo incluye un workflow de GitHub Actions (board-sync.yml) que mantiene el board siempre lleno sin intervención manual:

on:
  issues:    [opened, closed, reopened]
  pull_request: [opened, closed]
  schedule:  # lunes 9am UTC — health check semanal

Cada vez que se abre o cierra un issue, o se mergea un PR, el workflow corre en segundos y sincroniza automáticamente: asigna responsable, actualiza Status y refleja el progreso de sub-issues.

Estado actual

Versión 0.30.0 — 2026-07-31

Últimas adiciones desde la primera publicación: el loop completo /board work (issue → branch → PR → review gate → merge), trabajo en paralelo con un worktree por issue, fleet multi-CLI (Claude/Gemini/Codex/Jules/Copilot con sondeo de cuota), session handoff (save/resume), el módulo skills-ops, generación de changelog desde el board y el skill tmdl-review para diffs de modelos semánticos.

El fleet dejó de ser un simple lanzador: ahora coordina el trabajo. Un supervisor detecta y termina sesiones estancadas, las dependencias entre issues se pasan con un hand-off automático, y un governor lanza las sesiones en olas según la capacidad real de la máquina (CPU, RAM, núcleos) en vez de arrancarlas todas de golpe.

Ver el CHANGELOG completo en GitHub.

Roadmap de módulos

Este es el Módulo 1 de una suite mayor de GitOps para BI, sobre la misma base:

Módulo	Descripción
M1 (entregado)	Gobernanza cross-account de GitHub Projects e issues
M2 (en progreso)	Git ops para PBIP/Fabric: branch-por-reporte y revisión de diff TMDL (detección de cambios de esquema que rompen, enganchada al review gate)
M3	Agentes de revisión de modelos semánticos enlazados al board
M4 (en progreso)	Automatización de releases de BI — generación de changelog desde los issues en Done
M5 (entregado)	Knowledge-ops — registro de referencias por proyecto y dominio, con `/knowledge add` + `harvest`

Construida con Claude — y no soy programador

Quiero ser honesto sobre algo que creo que vale la pena decir: no soy desarrollador de software. Mi trabajo es Power BI, modelado de datos y análisis. No escribo Python ni JavaScript de manera profesional.

agentic-board la construí junto a Claude — el asistente de IA de Anthropic. Cada skill, cada script de PowerShell, cada mutation de GraphQL en esta herramienta fue escrita en colaboración directa: yo describía el problema en lenguaje natural, Claude proponía la solución, yo la probaba en mi propio board y reportaba qué funcionaba y qué no.

Esto no es un detalle menor. Significa que si tienes un problema de flujo de trabajo en GitHub — aunque no sepas programar — probablemente puedes construir tu propia solución. El conocimiento de dominio que yo aporté (entender cómo funciona un proyecto de BI, qué información necesita un board de GitHub, cómo se estructura un roadmap real) fue igual de importante que el código.

Si te interesa explorar este modelo de desarrollo, empieza por Claude Code.

Actualizaciones

2026-07-31 — v0.30.0

Tres arreglos, y los tres a agujeros que ya estaban en la versión publicada. Ninguno lo introdujo el trabajo reciente: aparecieron al probar la herramienta a fondo contra sí misma.

El revisor automático de PRs se estaba muriendo en silencio. Su tope de turnos era 20 y una revisión real necesita hasta 23, así que cualquier PR mediano se quedaba sin revisar y el check salía rojo sin explicación. Medido sobre ejecuciones reales y subido con holgura. En cuanto volvió a funcionar encontró cinco defectos reales el mismo día.
El freno ya vigila el git push directo a main. Vigilaba gh pr merge y los endpoints REST de merge, pero no la ruta más simple: un comando, trabajo en la rama principal, y ningún patrón lo miraba.
El cierre autónomo de PRs queda explícitamente cerrado. La idea era que un agente al que le dieras la orden pudiera terminar el trabajo él mismo. No funcionaba, y al intentar abrirlo aparecieron dos formas completas de saltarse las comprobaciones. Se cerró a conciencia y el rediseño quedó escrito. La orden se sigue registrando y ahora se le explica al agente por qué no puede ejecutarla, para que un rechazo se lea como el control haciendo su trabajo.

Cambio de comportamiento: el freno ahora rechaza comandos que antes dejaba pasar. Si tienes un script propio que empuje a main desde un worktree con freno armado, dejará de funcionar.

Además, el hook del freno —la pieza que Claude Code ejecuta de verdad y la única que puede negar algo— pasó de cero pruebas a diecisiete.

Corregido en el artículo: decía que eran cuatro comandos y son siete — faltaban /expert (el modo autónomo), /tools y /docs. El bloque de ejemplos pasa a estar marcado como muestra, y la lista completa ahora enlaza al README del repositorio, que se genera desde el código y CI mantiene al día. Este artículo ya se había quedado viejo dos veces por enumerar comandos a mano; esta vez apunta a la fuente en vez de copiarla.

2026-07-16 → 2026-07-30 — de la v0.20 a la v0.29

Resumen de once versiones que este artículo no había recogido:

Modo experto (/expert). Toma un plan del board y lo ejecuta de forma autónoma adoptando un rol especializado: investiga, construye, prueba dejando evidencia y se auto-usa el board. Los roles son extensibles por proyecto, no una lista fija.
Catálogo de herramientas (/tools). Un único sitio para ver, investigar e instalar las herramientas externas que el proyecto referencia.
Telemetría (/board telemetry). La herramienta mide cómo se comportó de verdad en uso real, en vez de asumirlo.
Endurecimiento de fallos silenciosos. Varias operaciones respondían con confianza en lugar de fallar cuando gh fallaba por debajo: un backup vacío que parecía correcto, issues que se reportaban creados sin haberlo sido. Ahora un fallo es un fallo.
Supervivencia a la compactación en sesiones largas, y release automatizado (tag y publicación al cambiar la versión).

2026-07-15 — corrección de documentación

Este artículo se había quedado atrás respecto al plugin. Correcciones, sin cambio de versión:

/skills ahora está documentado. Existe desde la v0.16 pero el artículo solo nombraba skills-ops como módulo, nunca el comando.
/knowledge sale del roadmap. Estaba listado como M5 pendiente y en realidad ya venía entregado: es el registro de referencias del proyecto por dominio.
Añadido el resumen de que son cuatro comandos: /board, /scan, /skills y /knowledge.
M1 y M5 marcados como entregados en la tabla de módulos.

2026-07-14 — v0.19.0

Governor de fleet: lanza las sesiones en olas según la capacidad real de la máquina (CPU, RAM libre, núcleos) y un tope de concurrencia, en vez de arrancarlas todas de golpe.
Ciclo de vida del fleet: -Stop, -Relaunch, -Reap, -KillAll y -MaxConcurrent; reaper de sesiones huérfanas y dashboard -Sessions con CPU/RAM por proceso y cola de log.
Gate de docs-freshness en CI: regenera la documentación y falla el build si el README quedó desactualizado.

2026-07-13 — v0.18.0

Migración del directorio de estado: el estado interno pasó de .agentic-bi-ops a .agentic-board, con migración automática y fallback — nada que hacer del lado del usuario.
Automatización de releases: bump de versión y changelog enganchados al proceso de release, con un solo plugin.json consolidado.

2026-07-10 — v0.17.0

Fleet multi-CLI (coordinador heterogéneo): registro de adaptadores (Claude por defecto + Gemini/Codex/Copilot/Jules) con sondeo de disponibilidad y clasificación cuota/auth/error, y selector por issue con fallback automático a Claude.
Coordinación de trabajo (fase 3): supervisor que detecta y termina sesiones estancadas, hand-off de dependencias entre issues con briefing, y un planner “board-lead” que asesora el orden de ejecución.

2026-07-09 — v0.16.0

Rebrand: agentic-bi-ops ahora es agentic-board (el alias viejo sigue funcionando).
Nuevo loop /board work: elige el issue, lo lleva de rama a PR, review gate y merge.
Trabajo en paralelo (un worktree por issue) y fleet multi-CLI (Claude/Gemini/Codex/Jules/Copilot con sondeo de cuota).
Session handoff (/board handoff save|resume) para continuar entre sesiones.
Módulo skills-ops, generación de changelog desde el board y revisión de diffs TMDL.

Referencias

agentic-board — repositorio oficial — código fuente, CHANGELOG y documentación del plugin
GitHub Projects v2 — REST API — endpoints para crear y operar boards programáticamente
GitHub Projects v2 — GraphQL API — mutations para campos, items y vistas (addProjectV2ItemById, updateProjectV2ItemFieldValue, addSubIssue, removeSubIssue)
GitHub Sub-issues — documentación — cómo estructurar issues padre/hijo con la API REST y GraphQL
Claude Code — documentación oficial — sistema de plugins, skills y hooks de Claude Code
gh CLI — GitHub — interfaz de línea de comandos oficial de GitHub usada internamente por el plugin
GitHub Actions — documentación — plataforma de CI/CD donde corre el workflow board-sync.yml
Conventional Commits — convención de mensajes de commit usada en el repo (feat:, fix:, refactor:)
Claude — Anthropic — asistente de IA con el que fue construida esta herramienta; par de desarrollo por lenguaje natural
Anthropic — empresa de seguridad en IA detrás de Claude

Este post se actualiza con cada versión relevante de la herramienta.