Genera tu Jira desde markdown, no al revés
Para la mayoría de equipos chicos y medianos, mover el project tracking a live docs es más barato, más fiel y más auditable que pelear con Jira o Monday.
Tu equipo pasa entre 3 y 5 horas a la semana actualizando Jira, Monday, Linear, ClickUp o Notion. Tickets que abren, comentarios que copian del Slack, status que mueven a mano. Información que ya existe en commits, PRs y conversaciones — pero la replicas en otro sistema porque el dashboard ejecutivo la pide en su formato.
Hay otra forma. Genera el sitio de tracking desde el repo, no desde un PMO tool externo.
La idea, en una línea
Tus PRs, commits, ADRs, daily logs y backlog ya viven en markdown versionado en git. Un script (o un agente) los lee y genera un sitio estático que muestra el estado del proyecto. Sin re-capturar nada. Cuando el código se mueve, el sitio se mueve.
No es una idea nueva — Hugo, MkDocs y Jekyll han hecho esto por años.
Lo nuevo es que con un agente decente, el sitio se mantiene solo.
El agente lee los commits, identifica qué cambió, qué tickets cerró,
qué decisiones implícitas tomó, y actualiza la lista correspondiente
en docs/backlog.md.
Por qué funciona
Tres razones, todas relevantes para equipos de 2-15 personas:
1. Versionado real. Cuando alguien borra un “ticket” (línea en
backlog.md), tienes la historia en git log. Cuando Jira pierde
un ticket — o alguien lo edita y nadie nota — no hay recuperación
fácil.
2. Fricción cero para developers. Un PR puede incluir el ajuste al backlog en el mismo commit. “Cierra item RX2, agrega item KJ9” en el mismo diff que la implementación. No hay context switch a otra herramienta.
3. Auditable por la IA y por el equipo. Tu agente puede leer el backlog, los ADRs y el código simultáneamente. Si tu backlog dice “item completado” pero el código no muestra evidencia, el agente te lo dice. Lo mismo aplica para humanos haciendo review.
Cuándo SÍ vale la pena Jira
Sería deshonesto decir que markdown reemplaza a Jira en todos los casos. Hay situaciones donde la herramienta enterprise gana:
- Equipos de 50+ con múltiples proyectos en paralelo y dependencias cross-team
- Integraciones obligatorias con Salesforce, SAP, ServiceNow donde el ticket tiene que vivir en el sistema corporativo por compliance
- Workflows multi-org con SLAs contractuales donde el ticket es un artefacto legal
- Equipos no-técnicos que no abren un editor de texto plano y necesitan UI con drag-and-drop
Si tu equipo cae en alguno de esos casos, Jira/ServiceNow ganan. Para todo lo demás — startups, equipos de producto chicos, agencias, consultorías — el costo-beneficio se inclina al lado del markdown.
Cómo se ve en práctica
En Agentic, nuestro propio backlog vive en
agenticmx-operator-docs/v0.X/backlog.md. Cada bloque tiene un
tracker ID corto de 3 caracteres (e.g. g6V, aFc). Los ADRs viven
en decisions.md. Las bitácoras en bitacora.md.
Cuando un PR cierra un item, el commit message lo declara explícitamente. El agente puede leer toda esa estructura cuando necesita contexto histórico — “¿por qué el handler de Telegram tiene ese retry tan agresivo?” — y responde con el ADR original que lo justificó.
¿Cuánto nos toma “mantener” eso? Cero tiempo dedicado. La actualización sucede dentro del flujo normal de trabajo. La fricción es menor que abrir Jira y arrastrar un ticket.
Cómo empezar
No tienes que migrar todo de golpe. Empieza chico:
- Mueve una sola lista — bugs activos, roadmap del trimestre, o
ADRs — a un
.mden tu repo. - Genera el sitio con MkDocs, Astro Content Collections, o Docusaurus. Una hora de setup.
- Observa por dos semanas cuánto extrañas la herramienta original. Si no la extrañas, migras la siguiente lista.
La mayoría de equipos descubre que extrañan menos de lo que pensaban. Y que el tiempo recuperado — esas 3-5 horas semanales — vale más que todo el polish del dashboard ejecutivo.
Si están pensando en repensar su stack de project tooling y quieren discutir si el patrón aplica a su caso, conversemos — el chat está abierto.