Lunes por la mañana. Abro Timeview — mi gestor de tareas — y hay un ticket nuevo: migrar un listado de scroll virtual a paginación tradicional. Hace unos meses, este momento significaba 10 o 15 minutos de fricción antes de poder siquiera pensar en el cambio. Copiar el título, crear la issue en GitLab, etiquetarla, asignarla, crear la rama, abrir el MR en draft, hacer checkout, abrir VSCode. Secretariado.
Ahora escribo tres palabras:
"Trabaja en la tarea 6283"
Me voy a por un café. Cuando vuelvo, la issue está creada en GitLab con las mismas etiquetas que tenía en Timeview, hay un MR en draft enlazándola, la rama está activa en VSCode, y Claude Code me espera con un análisis del componente actual y un plan de cambios. Yo reviso lo que propone, ajusto un detalle, y lo implementa.
No es magia. Es @timeview/cli — un CLI que escribí con Ink y React, el mismo stack que usa Claude Code — y un CLAUDE.md que le enseña a usarlo. En este artículo te cuento cómo funciona y, sobre todo, cuánto tiempo me ahorra de verdad.
El problema: 15 minutos de secretariado por ticket
Mi flujo manual, paso a paso:
- Leer el ticket en Timeview
- Copiar título y descripción
- Ir a GitLab self-hosted, crear la issue, etiquetas, milestone, asignación
- Crear la rama desde
developcon naming consistente - Abrir MR en draft enlazando la issue
- Hacer checkout en el terminal
- Abrir VSCode en esa rama
- Por fin: empezar a pensar en el problema
- Desarrollar
- Mergear, checkout a
develop, pull, borrar rama local - Volver a Timeview, estado a completado, registrar tiempo, comentario resumen con link al MR
Los pasos 1–7 son 10 o 15 minutos. Los pasos 10–11, otros 5. Son 15 o 20 minutos de overhead por ticket, multiplicado por 3 a 5 tickets al día.
Pero el coste real no se mide en minutos. Cada salto entre Timeview, el navegador, el terminal y el editor rompe el foco. Cuando llegas al paso 8, ya no estás al 100% — estás llegando cansado antes de empezar.
La idea: darle manos al agente fuera del editor
Claude Code ya es un buen pair programmer dentro del editor. La pregunta que me hice fue: ¿y si le doy manos fuera del editor también?
No un plugin, no una integración oficial. Un CLI propio — tv — que habla con Timeview, con GitLab y con git local. Claude Code tiene permiso para invocarlo. Le explico el flujo en un CLAUDE.md y el agente decide cuándo leer la tarea, cuándo abrir el MR, cuándo mergear, cuándo actualizar Timeview.
Yo solo apruebo.
El flujo, seis fases
Todo empieza con una frase: "Trabaja en la tarea 6283". A partir de ahí, el agente ejecuta esto:
Fase 1 — Leer la tarea
tv tasks work 6283 --status
Devuelve un JSON con título, notas, estado, etiquetas y MR vinculado si existe. Claude lo digiere.
Hay una regla de esta fase que tardé un par de iteraciones en dejar bien: las notas tienen prioridad sobre el título. Un ticket se abre con un título rápido y luego la conversación lo refina en los comentarios. Esa regla vive en el CLAUDE.md y evita que el agente trabaje sobre un enunciado obsoleto.
Fase 2 — Iniciar el trabajo
tv tasks start 6283
Un único comando que:
- Crea la issue en GitLab self-hosted copiando las etiquetas desde Timeview (
bugfix,feature,new…) - Abre el MR en draft y lo enlaza a la issue
- Crea la rama con naming consistente
- Hace checkout automático
El detalle de las etiquetas parece cosmético pero no lo es. Cuando preparo una release, el changelog se genera agrupando por etiqueta. Mantenerla sincronizada entre Timeview y GitLab significa que clasifico el ticket una sola vez, al crearlo, y la clasificación viaja sola hasta las release notes.
tv tasks work <id> --status # Ver estado actual de tarea + MR
tv tasks comment <id> <texto> # Añadir nota por ID (desde cualquier rama)
tv tasks state <id> <stateId> # Cambiar estado por ID (desde cualquier rama)
tv tasks new --title <título> # Crear nueva tarea en Timeview + GitLab
tv notes <texto> # Nota en la tarea de la rama actual
tv spend <minutos> # Registrar tiempo en la tarea actual
tv status # Ver contexto: proyecto, rama, tarea, MR
Fase 3 — Analizar con el código delante
Aquí pasa algo que no diseñé consciente, pero que resultó clave: Claude propone los cambios después del checkout, no antes. Con la rama activa, puede leer los archivos reales del repo y solo entonces me presenta:
- Qué archivos va a tocar
- Qué cambios propone y por qué
Si le pidiera el plan antes del checkout, sería un plan a ciegas sobre suposiciones. Con el código delante, es un plan sobre hechos. Yo apruebo o corrijo.
Fase 4 — Implementar
Claude Code haciendo su trabajo habitual: edita el código según lo acordado. Nada nuevo aquí; lo relevante es que llega con todo el contexto del ticket ya cargado, no con un prompt genérico que yo haya tenido que improvisar.
Fase 5 — Commit, push, merge
git add <archivos>
git commit -m "refactor: migrar listado a paginación"
git push origin <rama>
tv tasks work 6283 --merge
El --merge es mi favorito. Mergea el MR, cierra la issue de GitLab, hace checkout a develop, pull, borra la rama local y limpia la referencia del config. Cinco pasos aburridos en uno.
Fase 6 — Cerrar la tarea
tv tasks comment 6283 "Añadida paginación a la página de noticias. Cambiado de listado virtual con filtrado client-side a query paginada server-side. Destacados se obtienen en query separada. Búsqueda y filtro por tags resetean a página 1. Componente Pagination integrado. MR: <url>"
tv tasks state 6283 completed
Comentario con el resumen, URL del MR, estado a completado. Fin del ciclo.
La arquitectura, en una imagen mental
Tres piezas:
-
@timeview/cli(invocado comotv): el CLI propio. Hecho con Ink + React — el mismo stack que usa Claude Code. Wrappea la API de Timeview, la API de GitLab y los comandos de git locales. Una sola responsabilidad: traducir intenciones de alto nivel ("trabaja en la tarea 6197") en las llamadas concretas que hay debajo. -
Claude Code: con permisos para ejecutar
tvy git. -
CLAUDE.mddel proyecto: el runbook del agente. Describe el flujo, los comandos, el orden y las reglas que no puede romper (como la de "las notas tienen prioridad").
Autenticación local: nada que desplegar
Un detalle importante si otro dev del equipo quiere usarlo: la autenticación es local. Para Timeview, el usuario introduce sus credenciales una vez y el CLI guarda el token. Para GitLab, un access token personal. Todo en ~/.timeview/config.json.
No hay servidor intermedio, no hay credenciales compartidas, no hay infraestructura que montar. Un compañero instala el paquete, se autentica con lo suyo y tiene exactamente el mismo flujo en su máquina. Esa es la diferencia entre una herramienta personal y una que puede adoptar el resto del equipo sin pedir permisos ni levantar nada.
Los números
Separo por tipo de tarea porque el ahorro es muy distinto.
Bug
- Antes: ~10 min de setup antes de empezar + 20–60 min de resolución = 30–70 min totales
- Ahora: 1–5 min leyendo el ticket en Timeview + 1–2 min revisando el plan + ~1 min de ejecución = 3–8 min totales
Ahorro por bug: entre 25 minutos y una hora larga.
Feature nueva
- Antes: 4–16 horas según tamaño
- Ahora: hasta 1 hora siendo precavido con las pruebas
Ahorro por feature: varias horas. En las más grandes, casi un día entero.
Caso real: la tarea 6283 de este artículo
Las capturas que ves en este post son de una tarea real — el ticket #6283, migrar un listado de scroll virtual a paginación tradicional. La completé en 5 minutos de trabajo efectivo.
Los otros 10 minutos que me llevó la sesión los gasté recolocando datos de prueba y esperando el momento adecuado para pulsar "captura". El cronómetro no miente: el trabajo en sí fueron 5 minutos de punta a punta.
Dónde paro de prometer
Estas cifras son estimaciones basadas en mi experiencia, no medidas cronometradas. Comparan cómo trabajaba antes y cómo trabajo ahora sobre tickets parecidos. El ahorro real será algo menor en los casos buenos y algo mayor en los malos, pero el orden de magnitud es sólido.
Tampoco incluyen el tiempo de pensar, revisar y decidir. Y eso es lo que quería: el agente se come el secretariado, no el diseño.
Lo que no aparece en los números pero se siente todos los días es el fin del context-switching. Antes saltaba varias veces por ticket entre cuatro ventanas. Ahora el único salto es leer el plan y aprobarlo. No sale en el cronómetro, pero al final del día queda más energía.
Lecciones no obvias
Tres cosas que no esperaba al construir esto:
1. El cuello de botella no eran los minutos, era el foco. Lo pensaba como un problema de tiempo; resultó ser un problema de atención. Eliminar los saltos entre herramientas tiene más impacto que los minutos que ahorra.
2. Dar manos al agente te obliga a documentar tu propio flujo. Para que Claude supiera qué hacer, tuve que escribir el CLAUDE.md. Para escribirlo, tuve que explicitar cosas que hacía por intuición y nunca había puesto por escrito. Reglas como "las notas tienen prioridad sobre el título" no existían en ningún sitio hasta que tuve que enseñárselas a una máquina. El proceso de documentar, por sí solo, ya mejoró el flujo.
3. Las etiquetas compartidas cierran el ciclo hasta el changelog. Que la etiqueta viaje de Timeview a GitLab y de ahí a las release notes parece un detalle. No lo es: clasificar el ticket una sola vez y ver esa clasificación llegar intacta al documento que lee el cliente es uno de los beneficios más infravalorados del sistema.
Una nota antes de seguir: este patrón no es exclusivo de Claude Code. Cualquier agente con permisos de shell podría invocar un CLI así — Cursor, Aider, Codex CLI, lo que uses. Lo interesante no es qué agente eliges, sino que dejes de usarlo solo dentro del editor.
Qué viene después
Browser-agent. Quiero que Claude pruebe él mismo los cambios de UI antes de pedirme review: que abra el navegador, cargue la pantalla, haga clic entre páginas, verifique que la paginación responde como debe. Hoy esa parte todavía la hago yo. Cuando esté, el bucle entero — desde el ticket hasta el "funciona de verdad" — estará cerrado sin que yo tenga que abrir una sola pestaña.
Cierre
No voy a decirte que esto es el futuro del desarrollo. No lo sé, cada día que pasa, algo cambia. Lo que sí sé es que el desarrollo tiene un porcentaje sorprendentemente alto de trabajo de secretario: mover tickets, crear ramas, rellenar formularios de estado, escribir comentarios resumen. Ese trabajo nunca me hizo mejor ingeniero.
Darle ese trabajo a un agente no me convierte en un dev mejor. Me convierte en un dev que pasa más minutos del día pensando en código y menos rellenando casillas.
Con eso me vale.
Top comments (0)