agentic-board: agentes de Claude Code en tu board de GitHub

csalcedodatabi Claude Code GitHub Herramientas
Board de agentic-board en GitHub Projects — issues con assignees, status y sub-issues progress; el plugin de Claude Code gobernando su propio roadmap

Plugin de Claude Code

Tus agentes de código trabajan desde tu board real de GitHub.

agentic-board es un plugin de Claude Code que toma el siguiente issue, lo arranca en su propia rama y lo lleva por pull request y revisión hasta Done.

Instalar en Claude Code Una a una
  1. /plugin marketplace add CSalcedoDataBI/agentic-board
  2. /plugin install agentic-board
Licencia
MIT
Versión
v0.44.0
Se instala desde
su propio marketplace

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í.

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 («¿qué hay pendiente?», «arranca el #42», «mueve estos a Done») o ejecutas /board work y deja que lleve el ciclo completo.

Míralo en acción

agentic-board en uso: pregunta qué hay pendiente en el board, arranca el issue 17 en su rama, abre la pull request, pasa la revisión, el CI y los hilos, y fusiona con el issue en Done.
Del issue a Done: qué hay pendiente, arrancar un issue, abrir la PR con revisión y fusionar. Reproducción guionizada del README del plugin: los comandos son los reales.

Antes y después

Sin agentic-board Con agentic-board
Crear campos y mover tarjetas a mano «Mueve el #42 a Done»
Triar issues uno por uno /board bulk close label:stale, con simulación y confirmación antes
Vigilar la rama, la PR y el merge /board work lo lleva por PR y revisión
Un issue a la vez Varios issues independientes, cada uno en su worktree
Retomar de memoria al día siguiente /board handoff guarda y recupera el contexto

Cómo funciona

GITHUBTU MÁQUINA① /board work② abre la PR③ filtrosínoIssue en tu boardRama y worktree propiosEl agente trabajaPull requestFiltro: revisión, CI e hilosFusión y Done
  1. Paso 1: /board work elige el issue por prioridad, lo pasa a In Progress, te lo asigna y crea su rama issue-<n>-<slug> en un worktree propio, sin tocar tu copia principal.
  2. Paso 2: El agente trabaja en ese worktree y abre la pull request con Closes #<n>: nunca empuja directo a main.
  3. Paso 3: El filtro exige una revisión sobre el último commit, el CI en verde y ningún hilo sin resolver. Si algo falla, vuelve al agente; si pasa, se fusiona, se borra la rama y el issue queda en Done.
Cómo lleva /board work un issue hasta Done
  • Tu board
  • Agente
  • Fusionado
Un issue del board pasa, con /board work, a una rama en su propio worktree de tu máquina. El agente trabaja ahí y abre una pull request en GitHub. El filtro comprueba la revisión, el CI y los hilos abiertos: si todo está en orden se fusiona y el issue queda en Done; si no, vuelve al agente.

Lo que lo hace distinto

Tu board real, no una copia

Trabaja con las APIs de GitHub Projects e Issues a través de gh. Es el mismo board que ya usa tu equipo, no un Kanban desechable en una pestaña.

Reparte según la cuota disponible

Puede arrancar varios issues independientes a la vez, cada uno en su worktree, y antes de repartirlos sondea la cuota de cada CLI: Claude, Antigravity, Codex, Jules y Copilot.

Nada se fusiona sin pasar el filtro

Cada issue termina en una PR que exige revisión sobre el último commit, CI en verde y ningún hilo sin resolver. La higiene la impone el flujo, no la fuerza de voluntad.

Y un modo experto que frena antes de lo irreversible. /expert toma un issue del board y lo ejecuta solo, con un rol especializado, test-first y dejando evidencia de cada prueba en el PR y en el issue. Llega a “PR listo” y ahí para: el freno es mecánico, no una instrucción (lo explico en Diseño de seguridad).

Cómo instalar y probarlo en cinco minutos

Antes de empezar: PowerShell 7 y el CLI gh con sesión iniciada y el scope project (gh auth login y luego gh auth refresh --scopes project). El detalle está en Requisitos y límites.

01 Instala el plugin

En Claude Code Una a una
  1. /plugin marketplace add CSalcedoDataBI/agentic-board
  2. /plugin install agentic-board

Resultado

Terminal tras instalar: el marketplace añadido, el banner AGENTIC BOARD y el menú de /board con work, plan, fill, field y handoff.

Reproducción guionizada del README del plugin: los comandos y el banner son los reales.

02 Crea el board y añade tu primer issue

Escribe Una a una
  1. /board init
  2. /board add #42

Resultado

En GitHub aparece un board de Projects nuevo, enlazado a este repositorio, con el issue #42 dentro. Es tu board real: lo ves y lo editas en GitHub como cualquier otro.

03 Arranca el trabajo

Escribe
  1. /board work

Resultado

Terminal: lista lo pendiente, arranca el issue 17 en su rama, abre la PR, pasa revisión, CI e hilos, y fusiona con el issue en Done.

Reproducción guionizada del README del plugin: los comandos son los reales.

¿Tu repo no tiene nada en el board? /scan convierte los TODO del código, las listas sin tachar y los planes en issues, con una sola confirmación.

Comandos

/board
El día a día: work, plan, fill, init, add, move, bulk, handoff y más. Sin argumentos muestra el menú.
/scan
Del trabajo sin registrar (TODO, listas, planes) a un board listo, con una confirmación.
/expert
Ejecuta un plan del board solo, con un rol experto, y se detiene antes de lo irreversible.
/skills
Ciclo de vida de Agent Skills: crear, mejorar, organizar, auditar y preparar toolkits.
/knowledge
Registro de referencias del proyecto por dominio, versionado en el repo.
/tools
Catálogo de las herramientas externas del proyecto: ver, investigar e instalar.
/docs
Publica la wiki del proyecto en un solo push.
/cleanup
Limpieza de la máquina para Claude Code: sesiones, transcripciones, disco y plugins.

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 resume los comandos de primer nivel, no sus sub-acciones.

Qué más incluye

Además de los comandos, estas piezas trabajan por debajo o como sub-acciones de /board:

CapacidadPara qué sirve
/board workEl loop diario: elige, arranca en rama+worktree, PR, review gate y merge — en serie o en paralelo
/board planConvierte un plan en un epic con sub-issues nativos, listo para trabajar
gh-accountResuelve el token activo sin llamar a gh auth switch — varias cuentas GitHub desde una misma máquina
projects-adminCrea, configura y opera boards: campos, items, presets ES/EN, automáticos de CI
handoffGuarda y retoma el contexto entre sesiones (save/resume) para continuar días después, incluso en otra máquina
changelogGenera el bloque de CHANGELOG (Added/Changed/Fixed) desde los issues en Done
tmdl-reviewRevisa el diff TMDL de un cambio PBIP/Fabric y clasifica cambios de esquema BREAKING/WARNING/INFO
abios-feedbackCaptura mejoras encontradas en proyectos privados de forma sanitizada, sin filtrar datos privados de vuelta al repo público

Requisitos y límites

Necesitas

  • Claude Code con el plugin instalado y activado en sus plugins.
  • PowerShell 7.
  • El CLI gh con sesión iniciada (gh auth login).
  • El scope project en ese token: gh auth refresh --scopes project (o un PAT clásico con project y repo).
  • Solo si usas varias cuentas de GitHub: /board setup.

No hace

  • Vistas, gráficos ni plantillas de proyecto: GitHub no ofrece API para eso.
  • Paralelizar issues que dependen entre sí: los marcados [BLOCKED] se rechazan al arrancar.
  • Fusionar sin pasar el filtro de revisión, CI e hilos.
  • Cambiar tu cuenta global de gh: nunca llama a gh auth switch.

Con una sola cuenta no hay nada más que configurar: el plugin usa GH_TOKEN o, si no existe, gh auth token, y el dueño del board por defecto es la cuenta con la que gh tiene la sesión iniciada.

Diseño de seguridad

El plugin nunca modifica tu estado global de gh: nunca llama a gh auth switch. Con varias cuentas, /board setup escribe ~/.agentic-board/accounts.json, un mapa de qué variable de entorno guarda el token de cada cuenta — solo los nombres, nunca el token. 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.44.0 — publicada el 2026-09-30 (notas de la versión).

Ú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 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 (estado según el README del repositorio):

MóduloDescripción
M1 (actual)Gobernanza cross-account de GitHub Projects e issues
M2 (entregado)Revisión de diff TMDL: detección de cambios de esquema que rompen, enganchada al review gate
M3 (actual)Toolkit de BI: referenciar, instalar y vigilar las herramientas de Microsoft Fabric y Power BI por perfil (/skills bootstrap bi, /skills freshness)
M4 (entregado)Automatización de releases de BI: checklist de release para artefactos de BI y generación de changelog desde los issues en Done
M5Knowledge-ops — registro de referencias por proyecto y dominio, ya disponible como /knowledge

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-11-06 — página renovada

La página estrena el formato de presentación de plugins: comando de instalación con botón de copiar, demo, antes y después, diagrama del ciclo con pasos numerados y preguntas frecuentes. Corregido: los requisitos decían que hacía falta un token en GITHUB_TOKEN_PERSONAL; basta con gh auth login y el scope project, como dice el README. La versión actual es la v0.44.0 y la lista de comandos pasa a ocho, con /cleanup.

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.
  • 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

Preguntas frecuentes

¿Sustituye a GitHub Projects?
No. Trabaja sobre tu board real de GitHub Projects, a través de gh: el mismo que ya usa tu equipo.
¿Puede fusionar sin revisión?
Por defecto, no. El merge pasa por el filtro: revisión sobre el último commit, CI en verde y ningún hilo sin resolver. Las sesiones que lanza en paralelo se detienen en la PR revisada salvo que pases -AllowMerge.
¿Funciona en macOS y Linux?
Sí, con PowerShell 7. Allí cada sesión paralela corre como un proceso pwsh en segundo plano, con su log en launch-<n>.console.log.
¿Y si tengo varias cuentas de GitHub?
Ejecuta /board setup: guarda qué variable de entorno tiene el token de cada cuenta. Con una sola cuenta no hace falta.
¿Es solo para Power BI?
No: sirve a quien lleve su trabajo en GitHub Projects. La revisión de diffs TMDL y el toolkit de Fabric y Power BI son un extra.
¿Cuánto cuesta?
El plugin es MIT y gratuito. Corre dentro de Claude Code, así que necesitas tu propio acceso a Claude Code.

Prueba agentic-board en tu próximo issue.

Instalar en Claude Code Una a una
  1. /plugin marketplace add CSalcedoDataBI/agentic-board
  2. /plugin install agentic-board

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

¿Te resultó útil este artículo?

Si este contenido te ha ayudado, considera apoyarme con un café. Tu apoyo me permite seguir creando contenido de calidad.

¡Contáctame!