No me gustan mucho los gestores de tareas, (hablo de los centrados en desarrollo) porque habitualmente añaden una capa más de trabajo a la ejecución de un proyecto, suelen acabar llenos de tareas sin completar y acaban siendo, (al menos en mi caso), un cajón donde acabo metiendo un montón de problemas que debería haber solucionado en el proyecto o funcionalidades que debería haber desarrollado y no llegué a montar.
Pero a veces, tengo que reconocer que, en proyectos largos, compartidos o en aquellos que dependen de acciones de otro, usar un gestor puede ser la diferencia entre sacar el proyecto bien y no sacarlo jamás.
Los deberes son aburridos.
Aún así, gestionar tareas siempre me ha parecido un rollo.
En mi vida profesional he probado la mayoría de los sistemas de tareas con más o menos éxito, Desde una simple nota, a enviarme correos; changelogs y todolists, software y aplicaciones, Notion, Trello, Jira...
En todos llevar el tracking de las tareas es bastante aburrido y gestionarlas un doloroso trabajo en sí mismo.
El problema del foco.
Todas las aplicaciones o sistemas que he probado sufren en mayor o menor medida el mismo problema gordo cuando los usas para desarrollo y es lo que yo llamo: la fricción con el código.
Lees una tarea, en un entorno y luego te tienes que ir a tu entorno otra vez a entender qué te está pidiendo, a veces cuenta cosas sobre un bloque de código y ese código viene sin formato. Tienes que ir a la aplicación, volver al código mirar, volver a la aplicación de tareas, explicar algo...
Todo esto te desconcentra, tienes que estar con dos contextos a la vez y hace que inevitablemente pierdas tiempo y concentración, transportando ideas de una aplicación a otra.
Es cierto que hay sistemas que producen menos fricción y están más integrados con tu zona de trabajo, tener a veces un sencillo archivo de texto sobre el que vas añadiendo y quitando cosas es bastante útil, no tienes que salir del area de concentración, tenerlo siempre disponible y si lo haces un poco profesional, puedes ir convirtiéndolo en un TODO-List/Changelog del proyecto directamente según resuelves o levantas tareas.
Lamentablemente eso también tiene el problema de que es poco potente y no te permite enlazar tareas de distintos proyectos.
El paraíso del procrastinador.
El otro gran problema que tienen los sistemas de gestión de tareas es que acaban siendo muy complejos y sirven para que ciertos perfiles de trabajo aprendan a vivir casi exclusivamente en esas aplicaciones de tareas, convirtiendo su labor en un ejercicio constante de levantar tareas y complejidad alrededor del trabajo pendiente.
Así las aplicaciones de tareas se vuelven complejas, se llenan de etiquetas y convenciones, niveles de urgencia o importancia.
Se crean tarjetas para todo y cada vez te consume más tiempo llevar el orden de lo que está pasando.
Para un procrastinador avezado una aplicación de tareas así se convierte en el paraíso porque puede dedicarse todo el día a explicar qué tiene que hacer sin llegar realmente nunca a hacerlo.
Hacer la cosa de la procrastinación.
Yo, reconozco que tengo cierta tendencia a la procrastinación, me descubro a menudo merodeando alrededor de un problema sin llegar a pegarle un mordisco definitivo para resolverlo.
Pensando a veces que son demasiado bocado para atacarlo de una vez, creo tareas y defino y preparo un montón de cosas que deberían estar listas para poder hacer de ese problema un bocado asequible. En realidad, pura procrastinación.
He aprendido con el tiempo a detectar cuando estoy siendo productivo y cuando estoy revoloteando alrededor de un problema sin atreverme a hincarle el diente.
Darme cuenta de eso me hace algo más resistente a la pereza y la procrastinación pero no inmune.
Así que cuando trabajo, busco procesos y herramientas que no me permitan detenerme mucho a contar los detalles, sobre todo ahora que ya no desarrollo en equipo, casi prefiero acometer una tarea que sé que tengo que realizar antes de pararme a documentarla y dejarla de hacer, perdiendo el tiempo en explicar cómo hacerla en lugar de hacerla.
La contrapartida de esa manera de funcionar es que a veces paras tareas importantes para realizar otras y pierdes un poco el control sobre lo que estás desarrollando, corriendo el riesgo de no cerrar tampoco tareas importantes, por una indefinición clara de qué debería estar hecho.
Buscando el santo grial.
Analizando todas estas cosas, me he puesto a buscar durante unos días una solución que cubriese ciertos puntos para gestionar el tipo de proyectos que estoy ahora mismo desarrollando.
Como trabajar en equipo ya no es un punto a tener en cuenta, la búsqueda de la aplicación se puede centrar en lo que me gusta a mí en concreto. Y a ello me he puesto.
Primeramente, los puntos importantes que debía cumplir esta herramienta han sido:
- Que estuviera en mi entorno de desarrollo, es decir que viviera al mismo nivel que el código en el que estoy trabajando.
- Que fuera minimalista, con las mínimas funcionalidades, para no perder el tiempo añadiendo etiquetas.
- Que fuera muy extensible, si necesito una funcionalidad que no tenía, por ejemplo enlazar tareas de dos proyectos, tiene que ser fácil cambiarlo.
- Que permitiera enlazar proyectos y tareas que dependen de otras. Desarrollo varias cosas a la vez y unas dependen de otras, si necesitas una funcionalidad debes saber de qué depende, o conocer cuando una funcionalidad desbloquea cambios en otros proyectos.
- Que fuera muy rápida, y pueda acceder a las tareas pendientes sin perder mucho tiempo buscándolas.
- Que fuera muy sencilla de usar, sin menús sin niveles de profundidad.
- Y sobre todo, transparente que no tenga la sensación de estar usando una aplicación más sino que se convierte en parte de mi flujo de trabajo escribiendo en el mismo lugar en el que lo hago todo.
La solución.
La respuesta y después de buscar soluciones y propuestas de otros desarrolladores, como todo buen programador ya debería haber anticipado, es: construir mi propia aplicación de tareas y eso es lo que he hecho aprovechando las dos cosas que tengo ahora siempre abiertas al trabajar: un editor de texto y Claude Code.
Ya tiene hasta nombre.
Se llama Los Deberes porque me sigue produciendo el mismo sentimiento llevarme los deberes del colegio a casa que resolver estas tareas de un proyecto.
Dicho todo esto, paso a explicar por encima lo que he hecho y cómo funciona.
Cómo funciona
La idea es simple: cada tarea es una carpeta con un archivo Markdown dentro. Nada de bases de datos, nada de servicios externos. En esas carpetas guardo todo lo necesario para esa tarea, otros trozos de código, texto por elaborar, referencias...
Todo vive en local, en mi disco, versionado con git y subida de vez en cuando a remoto para poder hacer backup por si rompo algo.
Utilizo Claude (aunque puedes montarlo con cualquier otra IA) para interpretar y manejar todas esas tareas.
Ejemplo
datos/tareas/
├── bedrock/
│ └── BDR-001-importacion-tipografias/
│ └── tarea.md
├── mixes.0057/
│ └── MIX-001-mejoras-ui-movil/
│ └── tarea.md
└── rutina/
└── RUT-001-configurar-prettier/
└── tarea.md
Formato de la tarea
Cada tarea.md tiene un frontmatter mínimo: id, título, proyecto, fecha, importancia y estado. El resto es texto libre.
Este es un ejemplo real de una tarea que tenía abierta.
---
id: MIX-003
titulo: Sindicar el RSS
proyecto: mixes.0057
fecha: 2026-05-26
importancia: media
estado: pendiente
---
## Descripción
Generar y publicar un feed RSS para el proyecto mixes.0057, de forma que los usuarios puedan suscribirse y recibir notificaciones cuando se publique un nuevo mix.
## Criterios / pasos
- [ ] Decidir formato del feed (RSS 2.0 o Atom)
- [ ] Definir los campos a incluir (título, fecha, descripción, portada, enlace al mix)
- [ ] Generar el feed a partir del `index.json` existente (estático o con script de build)
- [ ] Publicar el feed en una URL fija (ej. `/feed.xml` o `/rss.xml`)
- [ ] Añadir `<link rel="alternate">` en el `<head>` del HTML para autodescubrimiento
- [ ] Verificar el feed con un validador (W3C Feed Validator o similar)
Lo interesante aquí es que Claude Code lee esa estructura y la entiende. El proyecto incluye un CLAUDE.md con las convenciones del sistema, así que Claude sabe cómo crear tareas, calcular IDs, mover carpetas al completar, y listar pendientes por proyecto o importancia.
Yo puedo también editar directamente cosas que ya no aplican o necesidades nuevas. La aplicación es tan sencilla que hacer un cambio en una tarea consiste simplemente editar un texto o pedírle a Claude que lo haga.
Los comandos
Lo importante ocurre a través de dos slash commands que he instalado globalmente en Claude Code:
Comando /deberes
/deberes gestiona la lista. Funciona desde cualquier proyecto, sin necesidad de abrir la carpeta de mi gestor de tareas.
El modo de uso es sencillo, con lenguaje natural describes las cosas importantes de la tarea, ejemplo: añade esto a éste proyecto, es importante.
/deberes añade una tarea a bedrock: revisar sistema de importación de tipografías, importancia alta
/deberes lista las tareas pendientes
/deberes tareas críticas
/deberes marca como completada BDR-001
Comando /tarea
/tarea carga una tarea concreta y analiza cómo abordarla en el proyecto que tengas abierto en ese momento. Útil cuando sabes lo que tienes que hacer pero quieres que Claude te ayude a arrancar:
Este comando sirve para arrancar con el desarrollo de una tarea o analizarla en detalle, Su uso es sencillo, después de listar, por ejemplo, los ids de varias tareas, usas ese Id para comenzar a trabajar en ella.
/tarea MIX-001
Claude lee la descripción y los criterios, revisa el código del proyecto actual y te explica por dónde empezar, además es capaz de avisarte de las dependencias por si necesitas acabar antes con otra tarea.
Tareas de rutina
Algunos cambios hay que aplicarlos en varios proyectos a la vez: actualizar una dependencia, añadir un archivo de configuración, aplicar un nuevo estándar de código. Para eso he extendido las funcionalidades añadiendo un tipo nuevo de tarea transversal, las tareas de rutina.
Una rutina tiene una lista de proyectos donde debe aplicarse.
Cuando la completas en uno, lo eliminas de la lista.
Cuando la lista queda vacía, la tarea se archiva automáticamente.
Pueden ser tareas que tienen que ser completadas todos los días o que van a repetirse a lo largo de varios proyectos.
Lo bueno es que todo esto lo detallas en lenguaje natural y si en algún momento descubres que una funcionalidad como esta no es útil la eliminas del flujo con un par de frases y ya tienes gestor más ajustado a tus necesidades.
A mí me funciona trabajar con rutinas así:
/deberes añade una rutina: configurar prettier en bedrock, mixes.0057 y plantillas
/deberes he aplicado RUT-001 en bedrock
→ RUT-001 actualizada. Pendiente en: mixes.0057, plantillas.
Tareas vinculadas
A veces terminar una tarea en un proyecto abre trabajo en otro. Por ejemplo: implemento un componente en mi librería de UI y ese componente debería integrarse después en tres proyectos distintos.
El campo desbloquea captura esa relación:
---
id: PLT-003
titulo: Componente tabla ordenable
proyecto: plantillas
desbloquea: MIG-007
---
Al completar PLT-003, Claude me avisará de que MIG-007 está lista para empezar y me pregunta si quiero arrancar con ella ahora.
Changelog automático
Otro punto que puede beneficiarse de esta automatización es el changelog. El changelog es una cosa difícil de mantener que exige disciplina y cuyo beneficio solo puedes ver si eres persistente añadiendo tareas completadas, cosas qeu en los proyectos en solitario supone una carga de trabajo innecesario y que a menudo abandonas a la tercera release.
En Los Deberes mantener el changelog te sale gratis porque se encarga automáticamente la aplicación de hacerlo por ti cuando se lo indicas, sin perder tiempo ni aplicar esfuerzo.
Como en Los Deberes tengo las tareas completadas guardadas con fecha, título e importancia, es muy sencillo automatizar todo. El camino para hacerlo que encontré es añadir un tercer comando que convierte ese historial en una entrada de changelog.
Comando /changelog
/changelog bedrock
El comando lee las tareas completadas del proyecto, detecta cuáles son nuevas desde la última entrada del CHANGELOG.md, sugiere una versión semver según la importancia más alta de las tareas (crítica → major, alta → minor, media/baja → patch) y te muestra un borrador para que lo apruebes o ajustes la versión antes de escribir nada.
## [0.2.0] - 2026-05-30
### Added
- BDR-003 Sistema de tokens de color con soporte dark mode
### Fixed
- BDR-001 Corregir sistema de importación de tipografías
El CHANGELOG.md vive en cada proyecto, no en el gestor. Es exactamente donde debe estar: versionado junto al código, accesible para cualquiera que clone el repo.
El flujo real.
Cómo es trabajar con en un proyecto entonces con este gestor?
Cuando quiero trabajar en un proyecto arranco Claude Code en ese directorio, al arrancar Claude ya tiene los comandos guardados y sabe qué hacer si le solicito algo a través de ellos.
Puedo escribir en la linea de comandos: /tarea BLG-001.
Entonces un skill lee el archivo, me muestra el resumen y me pregunta por dónde quiero empezar.
Cuando termino una tarea, la muevo a datos/completadas/ y listo. Con Git guardo el historial de todo.
Si quiero actualizar el changelog, con un comando está hecho.
Lo que me resulta especialmente útil es que puedo añadir contexto a las tareas. Si hay una decisión que tomé, una referencia que encontré o una restricción que descubrí mientras trabajaba, la apunto directamente en el tarea.md. La próxima vez que retome esa tarea, Claude tiene todo el contexto sin que yo tenga que recordar nada.
Es, básicamente, una memoria externa que vive junto al código.
Por qué funciona (para mí).
Para alguien que trabaja solo, en varios proyectos pequeños, con un asistente de IA siempre abierto en el terminal, tener las tareas en texto plano con git es lo más cómodo y transparente que he podido diseñar.
Las tareas están versionadas. Puedo ver cuándo creé algo, cuándo lo modifiqué, cuándo lo completé. No dependo de que una plataforma cambie sus condiciones ni de que el servicio esté disponible. Y si en algún momento quiero cambiar algo del sistema, lo cambio yo directamente porque son solo archivos.
El sistema tiene sus limitaciones, claro. No hay notificaciones, no hay fechas límite que me avisen, no hay integración con calendarios. Pero tampoco las necesito. Si algo es urgente, ya lo sé sin que me lo diga una app, y si necesito extenderla y tener más control puedo añadir nuevas reglas.
La aplicación entonces es un repositorio de archivos de texto plano, se interactúa con ella a través de Claude en el propio IDE, y solicitando cosas en lenguaje natural, puedes ver las dependencias con otras tareas, abrir nuevas incidencias sobre otro proyecto directamente en el proyecto en el que estás trabajando y sin salir de la pantalla de trabajo, puedes guardar trozos de código o textos dentro de cada tarea, pues cada tarea reside en su propia carpeta, es prácticamente transparente y muy sencilla de usar.
Y eso es todo amigos.
En mi condiciones y para el tipo de proyectos que estoy montando ahora mismo, se ha convertido en el flujo de trabajo ideal, cero fricción y mínimo tiempo perdido en gestionar incidencias.
No digo que sea para todo el mundo pero si crees que encaja con tu modo de trabajar, aquí te dejo el repositorio donde la he subido github.com/Katamo/losdeberes.
Un detalle a tener en cuenta es que la herramienta es pública, las tareas son privadas(*). El repo que instalas no contiene ninguna tarea: la carpeta datos/ está en el .gitignore. Puedes gestionarla como un repo git privado independiente, o simplemente dejarla en local.
(*) Suponiendo claro que todo lo que subes a claude es compartido para entrenar su modelo. Aunque nada te impide adaptar este proyecto para usarlo con un modelo local ya que no necesita ser muy potente.
En definitiva, Deberes es un sistema de trabajo más que un producto. No tiene interfaz, no tiene servidor, no tiene cuenta que crear y es totalmente personalizable.
Funciona porque Claude Code ya sabe leer texto y seguir instrucciones y porque los archivos Markdown son lo suficientemente flexibles como para modelar casi cualquier flujo de trabajo, puedes modificarla a tu gusto simplemente añadiéndole o quitándole funcionalidades.
No tengo planes de hacerle interfaz gráfica ni de complicarla, sencillez máxima e ir adaptando el flujo de trabajo según lo necesite, creo que he encontrado una gran solución para gestionar proyectos de desarrollo y la iré puliendo según avance en su uso.
Cuando lleve un tiempo con ella espero escribir otro post sobre cómo ha ido.
Si la pruebas cuéntame qué te parece y qué cambios le hiciste.