Desarrollo Lean Task-First: Beads, LeanSpec y Taskmaster en la Práctica

Lectura relacionada: Paradigmas Alternativos en Ingeniería de Software con IA · Spec-Driven Development con IA Agéntica · Análisis de Frameworks SDD: Spec Kit, OpenSpec y BMAD

Hay una frustración particular que te golpea alrededor del tercer día de un proyecto con asistencia de IA. La primera sesión fue gloriosa: el agente entendió el objetivo, generó código sensato, hizo las preguntas correctas. Pero para el tercer día ya estás empezando cada sesión con un prólogo largo: “Okay, el proyecto es una app de gestión de tareas, decidimos usar PostgreSQL en vez de SQLite porque X, eliminamos la capa de Redux porque Y, y la última vez nos atascamos en Z.” El agente asiente educadamente y luego procede a regenerar el archivo de Redux.

Esto es context rot: la erosión gradual del estado acumulado del proyecto a medida que los agentes de IA empiezan cada sesión con la memoria en blanco. No es un problema de alucinaciones en el sentido tradicional — el modelo funciona exactamente como fue diseñado. Es un problema de infraestructura de workflow. La solución no es un modelo más inteligente; es un arnés más inteligente.

Este artículo cubre tres herramientas que atacan el context rot desde ángulos distintos: Beads, un rastreador de issues distribuido y nativo de git construido como un DAG para agentes de IA; LeanSpec, un sistema de workflow spec-driven minimalista con integración MCP; y Taskmaster, un motor de orquestación PRD-a-tareas que se conecta a los editores que ya usas. No son herramientas competidoras — son capas complementarias de un enfoque de desarrollo lean y task-first que mantiene a ti y a tus agentes orientados en cada paso.

---

🦠 El Problema del Context Rot a Fondo

Antes de entrar en las herramientas, vale la pena detenerse un momento en el enemigo que todas atacan.

Una sesión típica de desarrollo con asistencia de IA tiene un inicio, un desarrollo y un final. El inicio es genial: explicas el contexto, el agente se orienta, avanzas. El final es donde se complica. Cierras el IDE, el historial del chat desaparece, la memoria de trabajo del agente se resetea. La próxima vez, empiezas desde cero — o peor aún, das un briefing incompleto y el agente hace suposiciones plausibles pero incorrectas.

El problema se amplifica con la complejidad. Una app CRUD simple puede sobrevivir unas pocas sesiones de pérdida de contexto sin daño mayor. Pero ¿un proyecto con decisiones arquitectónicas, enfoques rechazados, restricciones descubiertas y concerns transversales? Para la segunda semana, estás gastando más tiempo reexplicando que construyendo.

Las herramientas de gestión de proyectos tradicionales (GitHub Issues, Jira, Trello) fueron construidas para humanos. Asumen que una persona leerá el tablero, entenderá el contexto y tomará decisiones. Los agentes de IA necesitan algo diferente: contexto consultable por máquinas que pueda ser inyectado al inicio de cada sesión sin re-narración manual. Las herramientas a continuación están construidas con esta restricción en mente.

---

🔵 Beads — Un Rastreador de Issues DAG para Agentes de IA

Beads fue creado por Steve Yegge (sí, ese Steve Yegge, el de “Stevey’s Blog Rants”) y representa una perspectiva genuinamente fresca sobre qué debería ser un rastreador de issues en un mundo nativo de IA. La idea central es simple pero profunda: tus issues son un grafo, no una lista.

El Modelo DAG

En los rastreadores de issues tradicionales, los issues son planos. Puede que tengas una relación de “bloquea” o una jerarquía padre-hijo, pero el modelo mental sigue siendo fundamentalmente una lista con algunos bordes añadidos encima. Beads construye un Directed Acyclic Graph (DAG) como su estructura de datos primaria, lo que significa que cada tarea es un nodo, cada dependencia es un borde dirigido, y el grafo completo se computa y se puede consultar en tiempo de ejecución.

¿Por qué esto importa para los agentes de IA? Porque el grafo codifica qué trabajo está actualmente desbloqueado. Al inicio de una sesión, un agente no necesita que hagas una triaje manual del backlog — consulta el DAG en busca de nodos listos (tareas sin dependencias insatisfechas) y obtiene una lista legible por máquinas de los próximos pasos válidos. El contexto no se re-narra; se rehidrata desde el grafo.

Almacenamiento y Arquitectura

Beads almacena el grafo completo del proyecto en un archivo JSONL compacto que vive en tu repositorio git. Esta es una elección arquitectónica deliberada con varios beneficios derivados:

• Historia versionada: cada cambio al grafo de issues es un commit de git. Puedes hacer git blame a una tarea.
• Compatible con ramas: diferentes ramas pueden tener diferentes estados de tareas, que se fusionan naturalmente.
• Sin servicio externo: sin servidor, sin internet, sin API key. El archivo es la base de datos.
• IDs basados en hash: los IDs de tareas son hashes de contenido, no enteros secuenciales, lo que elimina los conflictos de fusión cuando múltiples agentes crean tareas simultáneamente.

SQLite se usa internamente para consultas rápidas sin recargar todo el archivo JSONL en cada comando — actúa como un índice efímero, reconstruido desde la fuente de verdad JSONL cuando es necesario.

Workflow Práctico

Empezar con Beads es intencionalmente rápido:

# Inicializar un proyecto Beads en tu repositorio
bd init

# Crear un nodo de tarea
bd add "Implementar middleware de autenticación"

# Añadir una dependencia (el middleware de auth depende del modelo de usuario)
bd add "Crear modelo de usuario"
bd add "Implementar middleware de autenticación" --after "Crear modelo de usuario"

# Consultar el trabajo listo (tareas sin dependencias pendientes)
bd ready

# Mostrar el grafo actual
bd graph

# Marcar una tarea como hecha y desbloquear dependientes
bd done <task-hash>

El comando bd ready es el clave para los workflows de agentes de IA. Al inicio de una sesión, un agente puede ejecutar bd ready, obtener la lista de tareas desbloqueadas, elegir una y empezar a trabajar — sin ningún briefing humano. El agente rehidrata su contexto desde el grafo en lugar de desde tu memoria.

El Bucle de Rehidratación de Contexto

El workflow que Beads habilita es un bucle:

1. El agente inicia sesión → ejecuta bd ready → elige la tarea desbloqueada prioritaria
2. El agente lee la descripción de la tarea y cualquier nota enlazada → tiene suficiente contexto para actuar
3. El agente implementa el trabajo → hace commit del código → ejecuta bd done <hash>
4. Nuevas tareas quedan desbloqueadas → el agente puede continuar inmediatamente o detenerse limpiamente

Cada tarea puede llevar una descripción lo suficientemente rica como para ser autosuficiente como un mini-spec. Los IDs basados en hash significan que puedes referenciar tareas desde comentarios de código, mensajes de commit u otros documentos sin preocuparte por colisiones de IDs entre agentes o ramas. Esto es especialmente poderoso cuando estás ejecutando múltiples sesiones de agentes de IA en paralelo en diferentes feature branches.

Dónde Beads Brilla

Beads no intenta ser todo tu sistema de gestión de proyectos. Es una capa de coordinación nativa de git para secuenciación de tareas. Sobresale en proyectos donde:

• El grafo de dependencias entre tareas es complejo y evoluciona rápidamente.
• Quieres que los agentes de IA se autodirijan dentro de una sesión sin supervisión constante.
• Necesitas paralelismo multi-agente sin overhead de coordinación.
• Prefieres mantener todo en el repositorio en lugar de levantar servicios externos.

La filosofía es deliberadamente minimalista: Beads le da a los agentes un grafo de tareas consultable. Lo que va en esas tareas, y cómo el agente las ejecuta, depende de ti y de tus otras herramientas.

---

🟡 LeanSpec — Specs Mínimos, Máximo Alineamiento

Si Beads resuelve la coordinación de tareas, LeanSpec resuelve el problema upstream: ¿qué se supone que debe hacer la tarea realmente? Trae principios ágiles al Spec-Driven Development (SDD) con una restricción dura que fuerza la claridad: cada spec debe permanecer bajo los 2,000 tokens.

El Presupuesto de Tokens como Restricción de Diseño

Ese techo de 2,000 tokens no es arbitrario. Es una función de fuerza. Cuando no puedes escribir más de 2,000 tokens, te ves obligado a articular lo que realmente importa. No puedes rellenar. No puedes hedgear con cinco enfoques alternativos. Tienes que comprometerte con un diseño.

Esta restricción también mantiene los specs dentro de la ventana de contexto que la mayoría de los modelos de IA manejan cómodamente como un documento inyectado. Un spec que cabe en 2,000 tokens puede cargarse completo al inicio de una sesión de agente — sin chunking, sin recuperación, sin artefactos de resumidores. El agente obtiene el panorama completo de una sola vez.

Esto contrasta directamente con los frameworks SDD más pesados que producen documentos arquitectónicos de 20 páginas. Esos documentos pueden ser exhaustivos, pero son demasiado grandes para inyectarlos completos en una ventana de contexto, demasiado lentos de actualizar y demasiado intimidantes de mantener. La filosofía de LeanSpec: un spec pequeño que siempre está actualizado vale más que un spec perfecto que siempre está obsoleto.

Para una comparación más profunda con esos frameworks más pesados, consulta Análisis de Frameworks SDD: Spec Kit, OpenSpec y BMAD-METHOD.

Workflow Central: Descubrir → Diseñar → Implementar → Validar

LeanSpec estructura el trabajo alrededor de cuatro fases que se mapean naturalmente a cómo los desarrolladores indie realmente construyen cosas:

Descubrir: Captura el problema. ¿Qué intentan hacer los usuarios? ¿Qué restricciones existen? Todavía no hay solución — solo el espacio del problema. Un spec en esta fase puede ser tres puntos y una pregunta.

Diseñar: Elige un enfoque. Toma decisiones explícitas. Documenta lo que fue rechazado y por qué — esta es la memoria institucional que evita que los agentes vuelvan a sugerir enfoques ya rechazados.

Implementar: El spec se convierte en la fuente de verdad para la implementación. El agente lee el spec, implementa contra él y lo referencia cuando toma micro-decisiones.

Validar: Se verifican los criterios de aceptación. El spec se actualiza con cualquier descubrimiento. El spec se convierte en un registro de lo que se construyó, no solo de lo que se planeó.

# Instalar LeanSpec globalmente
npm install -g lean-spec

# Inicializar un proyecto
lean-spec init

# Ver el tablero Kanban (specs por fase)
lean-spec board

# Crear un nuevo spec (abre el editor)
lean-spec new "Flujo de autenticación de usuarios"

# Buscar specs por palabra clave
lean-spec search "autenticación"

# Ver estadísticas (conteos de tokens, distribución por fase)
lean-spec stats

# Lanzar la interfaz web
lean-spec ui

# Instalar el skill de agente de IA (integración MCP)
lean-spec skill install

Integración MCP y Skills de Agente

El comando lean-spec skill install instala un servidor Model Context Protocol (MCP) que expone tu biblioteca de specs a los agentes de IA en los editores compatibles. Una vez instalado, Claude Code, VS Code Copilot, Cursor, Windsurf y Gemini CLI pueden consultar tu biblioteca de specs directamente, sin copiar y pegar manualmente.

Cuando un agente empieza a trabajar en una tarea, puede consultar el servidor MCP: “¿Cuál es el spec actual para la autenticación de usuarios?” y obtener el documento relevante inyectado directamente en su contexto. El agente no necesita adivinar la intención ni depender de comentarios en el código — lee el spec vivo.

El skill de agente “leanspec-sdd” va más lejos: codifica el workflow Descubrir → Diseñar → Implementar → Validar como comportamiento del agente. El agente sabe verificar la fase del spec antes de tomar acción, actualizar el spec a medida que aprende, y señalar cuando una decisión de implementación diverge del spec.

Rastreo de Dependencias y el Documento Vivo

LeanSpec también rastrea dependencias entre specs. Si tu spec de “procesamiento de pagos” depende de que el spec de “autenticación de usuarios” esté en la fase Implementar o Validar, LeanSpec puede mostrar esa dependencia en el tablero y bloquear trabajo prematuro.

# Añadir una dependencia entre specs
lean-spec dep add procesamiento-pagos --depends-on autenticacion-usuarios

# Ver specs bloqueados por dependencias no resueltas
lean-spec board --blocked

# Ver el grafo de dependencias
lean-spec deps

Este rastreo de dependencias entre specs complementa el grafo de dependencias a nivel de tareas de Beads. LeanSpec maneja las relaciones entre specs (decisiones de diseño y alineamiento arquitectónico); Beads maneja las relaciones entre tareas (secuenciación de implementación y orden de ejecución).

Por Qué Importa lo de “Lean”

La palabra “lean” en LeanSpec es deliberada. El principio de manufactura lean de reducir el desperdicio — en este caso, desperdicio en documentación, overhead de planificación y ceremonia de alineamiento — es la filosofía que lo impulsa. Cada spec debe contener exactamente lo necesario para construir la funcionalidad correctamente y nada más. El techo de 2,000 tokens impone esta disciplina en cada entrada.

Para desarrolladores indie que trabajan solos o en equipos muy pequeños, esto significa que puedes mantener una biblioteca de specs sin que se convierta en un segundo trabajo. Escribes el spec, el agente lee el spec, construyes la cosa. Sin reuniones de planificación de 90 minutos. Sin comités de revisión de specs. Solo tú, el spec y el agente — todos apuntando al mismo objetivo.

---

🟠 Taskmaster — Del PRD al Grafo de Tareas Ejecutable

Mientras Beads y LeanSpec manejan el ciclo de vida continuo de tareas y specs, Taskmaster aborda un momento diferente: el inicio de un proyecto, cuando tienes un Product Requirements Document (PRD) o una idea vaga y necesitas convertirla en una lista de tareas concreta y secuenciada que un agente de IA pueda ejecutar.

Taskmaster fue desarrollado por Eyal Toledano y está disponible como paquete npm (task-master-ai). Es una herramienta de workflow con opiniones claras: le das un PRD, te da un grafo de tareas. Está diseñada para la realidad del desarrollo moderno asistido por IA, donde podrías empezar un proyecto escribiendo tu idea en un chat con Claude y luego necesitas hacer el puente entre esa conversación y trabajo estructurado real.

Instalación e Inicialización

# Instalar globalmente
npm install -g task-master-ai

# O instalar localmente en un proyecto
npm install task-master-ai

# Inicializar Taskmaster en un proyecto
task-master init

# Sigue las instrucciones para configurar tus proveedores de IA

El proceso de inicialización te pide configurar tres roles de modelo:

• Modelo principal: el modelo primario para generación y expansión de tareas (típicamente Claude Sonnet o GPT-4)
• Modelo de investigación: usado para las consultas de task-master research (típicamente un modelo con capacidad de búsqueda como Perplexity)
• Modelo de respaldo: usado cuando el modelo principal alcanza límites de rate o tiene errores

Taskmaster soporta Anthropic, OpenAI, Google Gemini, Perplexity, xAI, OpenRouter y modelos locales vía Ollama. Puedes mezclar proveedores — usar Claude como tu modelo principal pero Perplexity para investigación, por ejemplo.

El Pipeline PRD-a-Tareas

El workflow central es:

# Escribe tu PRD (Product Requirements Document)
# No necesita ser hermoso — Taskmaster es bueno interpretando intención
# Puede ser un archivo Markdown, texto plano o incluso notas borrosas

# Parsear el PRD y generar el grafo de tareas inicial
task-master parse-prd ./docs/prd.md

# Ver la lista de tareas generadas
task-master list

# Ver qué trabajar a continuación (respeta dependencias entre tareas)
task-master next

# Inspeccionar una tarea específica en detalle
task-master show <task-id>

# Expandir una tarea de alto nivel en subtareas
task-master expand <task-id>

# Investigar una pregunta técnica relevante para una tarea
task-master research "¿Cuál es el mejor enfoque para rotación de JWT refresh tokens?"

El comando parse-prd es donde ocurre la magia. Taskmaster envía tu PRD al modelo principal con un prompt estructurado que le pide descomponer los requerimientos en un grafo de tareas ordenado por dependencias. Cada tarea obtiene un ID, un título, una descripción, criterios de aceptación y una lista de dependencias. El resultado se almacena como JSON estructurado en tu proyecto.

Estados de Tareas y el Grafo de Workflow

Cada tarea en Taskmaster pasa por estados:

pendiente → en-progreso → hecha
                ↓
           bloqueada (si una dependencia no está hecha)

El comando task-master next es tu herramienta de navegación principal. Consulta el grafo de tareas, encuentra la tarea desbloqueada de mayor prioridad y te dice qué trabajar. Un agente de IA integrado vía MCP puede llamar a next al inicio de cada sesión y saber inmediatamente qué abordar sin dirección humana.

# Mover una tarea a en-progreso
task-master set-status <task-id> in-progress

# Marcar una tarea como hecha
task-master set-status <task-id> done

# Añadir una nueva tarea no incluida en el PRD original
task-master add-task "Añadir rate limiting a los endpoints de autenticación"

# Mover tareas entre grupos de tags (ej. v1.0 vs v2.0)
task-master move <task-id> --tag v2.0

Modos de Carga de Herramientas y Eficiencia de Contexto

Una de las decisiones de diseño más reflexivas de Taskmaster son sus modos de carga de herramientas para integraciones MCP. Cuando los agentes de IA se conectan vía MCP, cargan las herramientas de Taskmaster en su contexto. Más herramientas = más ventana de contexto consumida:

Modo	Herramientas Disponibles	Tokens Aprox.
all	36 herramientas	~21,000 tokens
standard	15 herramientas	~10,000 tokens
lean / core	7 herramientas	~5,000 tokens

Para agentes con presupuestos de contexto ajustados, el modo lean expone solo las herramientas esenciales (list, next, show, set-status, add-task, research, expand). Este es el modo por defecto correcto para la mayoría de las sesiones — raramente necesitas las 36 herramientas en una sola sesión de agente.

Desarrollo Aumentado con Investigación

El comando task-master research es una funcionalidad de primera clase, no una idea de último momento. Enruta las consultas a tu modelo de investigación configurado, permitiendo al agente responder preguntas técnicas fundamentadas en documentación actual, mejores prácticas o APIs de bibliotecas — y luego incorporar esas respuestas en descripciones de tareas o notas de implementación.

# Investigar una decisión técnica específica
task-master research "Prisma vs Drizzle para un proyecto Next.js en 2025"

# Investigación asociada al contexto de una tarea específica
task-master research "Mejor enfoque para reconexión WebSocket" --task <task-id>

Esto cierra una brecha que las herramientas básicas de gestión de tareas ignoran: durante la implementación, frecuentemente encuentras sub-preguntas que requieren investigación antes de poder proceder. Taskmaster trata la investigación como un paso de workflow de primera clase en lugar de pedirte que hagas alt-tab al navegador e incorpores manualmente la respuesta.

---

⚖️ Comparando las Tres Herramientas

Estas herramientas no son competidoras — operan en capas diferentes del ciclo de vida del desarrollo. Pero ayuda entender los límites:

Dimensión	Beads	LeanSpec	Taskmaster
Propósito principal	Grafo de tareas y coordinación de agentes	Autoría de specs y ciclo de vida	Parseo de PRD y orquestación de tareas
Almacenamiento	JSONL en git	Archivos Markdown	JSON en el proyecto
Punto de partida	Proyecto vacío o a mitad	Momento de diseño de features	Documento PRD/requerimientos
Eficiencia de tokens	JSONL ultra-compacto	Límite de 2k tokens impuesto	Configurable (lean/standard/all)
Integración MCP	Comandos consultables por agentes	Servidor MCP + skill install	Servidor MCP completo
Modelo de dependencias	DAG a nivel de tarea	Dependencias a nivel de spec	Grafo a nivel de tarea
Soporte de investigación	Ninguno (enfocado)	Limitado	Comando research de primera clase
Mejor para	Coordinación de tareas en curso	Specs de features y decisiones de diseño	Inicio de proyecto y PRD → tareas
Resolución de conflictos	IDs basados en hash	Basado en archivos, compatible con git	Archivo de estado JSON

El punto óptimo es usar los tres en conjunto:

1. LeanSpec a nivel de diseño: escribe specs pequeños para cada feature, capturando decisiones y enfoques rechazados.
2. Taskmaster para parsear la colección de specs o un PRD en un grafo de tareas inicial.
3. Beads para coordinación continua de tareas una vez que el proyecto está en marcha, especialmente si tienes dependencias complejas o sesiones de agentes paralelas.

---

🔗 Combinando los Tres: Un Workflow Práctico para Desarrolladores Indie

Así es como podrías usar los tres juntos en un proyecto real — digamos, construir una app Android con una API backend:

Fase 1: Inicio del Proyecto (Taskmaster)

Escribe un PRD. No necesita ser hermoso — solo honesto:

# MiApp PRD

## Problema
Los usuarios necesitan registrar su ingesta diaria de agua.
Las apps existentes son demasiado bloatware.

## Solución
App Android mínima con backend en Kotlin. Tres pantallas: vista de hoy,
historial, configuración. Sin cuentas — almacenamiento local primero,
sincronización opcional después.

## Stack Tecnológico
- Android: Kotlin, Jetpack Compose, Room
- Backend (opcional): Ktor, PostgreSQL
- Target: API 26+

## Alcance v1.0
- Añadir entradas de ingesta de agua (volumen + hora)
- Barra de progreso diaria
- Gráfico de historial de 30 días
- Notificaciones de recordatorio

task-master parse-prd ./docs/prd.md
task-master list
# → 12 tareas generadas, ordenadas por dependencias

Fase 2: Diseño de Features (LeanSpec)

Para las features más complejas, escribe specs enfocados en LeanSpec:

lean-spec new "Rastreo de progreso diario"
# Escribe el spec: modelo de datos, comportamiento UI, casos borde — todo bajo 2,000 tokens
lean-spec new "Notificaciones de recordatorio"
# Captura la decisión: usar WorkManager, no AlarmManager; documentado por qué

Fase 3: Implementación (Beads + agentes)

A medida que comienza la implementación, usa Beads para coordinación de tareas de grano fino:

bd init
bd add "Crear esquema de base de datos Room"
bd add "Implementar DailyEntryDao" --after "Crear esquema de base de datos Room"
bd add "Construir composable de barra de progreso" --after "Implementar DailyEntryDao"

# La sesión del agente comienza:
bd ready
# → "Crear esquema de base de datos Room" — sin dependencias, empieza aquí

El agente lee el spec de LeanSpec para contexto, ejecuta la tarea de Beads, hace commit, marca como hecha y toma la siguiente tarea desbloqueada. Sin re-narración necesaria.

Fase 4: Descubrimientos a Mitad del Proyecto

Beads captura cambios en el grafo de tareas. Taskmaster captura cambios en los estados de las tareas. LeanSpec captura cambios en las decisiones de diseño. Nada se pierde porque cada capa persiste independientemente en git.

---

🧪 Cuándo Usar Estas Herramientas

No todos los proyectos necesitan las tres. Aquí hay una guía aproximada:

• Proyecto paralelo, hack de fin de semana: probablemente solo Taskmaster para obtener una lista de tareas desde tu idea aproximada.
• Proyecto mediano (2–4 semanas): Taskmaster para el inicio + LeanSpec para las features más complicadas.
• Proyecto de larga duración (meses): los tres — Beads especialmente se vuelve valioso a medida que el grafo de dependencias crece en complejidad.
• Multi-agente o sesiones paralelas: Beads es esencial; sus IDs basados en hash y el modelo DAG fueron construidos específicamente para esto.

El hilo común en los tres es el principio de hacer legible por máquinas el estado del proyecto. El objetivo no es generar documentación por sí misma — es crear un arnés que permita a los agentes de IA rehidratar el contexto de manera confiable al inicio de cada sesión, sin tu intervención manual.

Esa es la filosofía lean, task-first: en lugar de combatir el context rot sesión a sesión, construyes infraestructura que hace el context rot estructuralmente imposible.

---

🎯 Reflexiones Finales

El context rot es un problema real que todo desarrollador que trabaje con agentes de IA eventualmente encontrará. Las herramientas en este artículo no son balas de plata — requieren que inviertas tiempo por adelantado en estructurar el estado de tu proyecto. Pero esa inversión se recupera inmediatamente: sesiones de agentes más rápidas, menos errores de orientación, más trabajo en paralelo y un historial de proyecto sobre el que realmente puedes razonar.

La ventaja del desarrollador indie aquí es real. Sin reuniones, sin emails de actualización de estado, sin una instancia de Jira gestionada por otra persona, eres libre de construir un sistema de gestión de tareas que sea exactamente tan lean o tan estructurado como necesitas. Beads, LeanSpec y Taskmaster están todos construidos por desarrolladores que querían herramientas que se sintieran nativas al cómo el desarrollo asistido por IA realmente funciona — no retroadaptadas a procesos pre-IA.

Empieza pequeño. Elige la que resuelve tu punto de dolor más inmediato. Construye el hábito. Luego incorpora las otras a medida que tus proyectos crecen.

---

📚 Referencias

• Repositorio GitHub de Beads — El rastreador de issues DAG nativo de git de Steve Yegge
• Beads Workflow en dev.to — Artículo introductorio y guía de workflow
• LeanSpec (lean-spec) — Herramienta de desarrollo spec-driven minimalista con integración MCP
• Taskmaster (claude-task-master) — Motor de orquestación PRD-a-tareas por Eyal Toledano
• task-master-ai en npm — Paquete npm oficial
• Spec-Driven Development con IA Agéntica — Lectura fundamental sobre principios SDD
• Paradigmas Alternativos en Ingeniería de Software con IA — Contexto más amplio sobre metodologías emergentes
• Análisis de Frameworks SDD: Spec Kit, OpenSpec, BMAD-METHOD — Comparación de frameworks SDD más pesados
• Yegge, S. (2024). Distributed Issue Tracking for the AI Age. Blog personal.
• Toledano, E. (2025). Task-Driven Development with Claude. GitHub README.