Claude Code para gestión de proyectos: el PM que no se le olvida nada

Claude Code sirve para gestión de proyectos porque hace el trabajo que un PM humano detesta: crear las issues, mantenerlas al día y avisar cuando algo se está cayendo. Es Claude corriendo en tu terminal: lee tus archivos y ejecuta tareas directo en las herramientas que ya usas, como Linear.

La mayoría de la gente conoce Claude Code para escribir software. Lo que casi nadie cuenta es cómo lo usas para coordinar el trabajo, no solo para producirlo. Eso es justo lo que llevo haciendo en GNB.

Hoy corro todos mis proyectos en Linear, con una regla que no negocio: si algo no está en Linear, no se trabaja. Te muestro el flujo real que opero, sin teoría.

¿Qué es Claude Code para gestión de proyectos?

Un PM pasa la mayor parte del día en trabajo de plomería: pasar una junta a tareas, asignar responsables, poner estimados, perseguir status. Es necesario y es lento.

Claude Code toma ese trabajo de plomería y lo automatiza. Le describes el proyecto o le pasas el transcript de una llamada, y el agente crea las issues con su estimado y su responsable directamente en tu gestor.

La diferencia con un asistente de chat es que Claude Code ejecuta. No te devuelve una lista para que tú la copies a mano. Crea las tareas en Linear, registra las horas, manda el status update. El proceso completo, no la sugerencia.

¿Cómo convierto una idea o una junta en un PRD?

Antes de crear una sola tarea, existe un PRD. Esa es la regla que sigo sin excepción: no hay milestone sin PRD aprobado.

Un PRD es el documento que define qué se va a construir y para quién, sin meterse en el cómo técnico. El problema de siempre es que escribirlo a mano, desde un brain dump o una nota de voz del cliente, toma horas.

Para eso uso un skill que convierte una idea cruda en un PRD estructurado mediante una entrevista guiada de 10 fases. Le paso la nota de voz o la transcripción de la junta y el agente me va proponiendo el propósito, los features en scope, lo que queda fuera, el modelo de datos y los milestones. Yo confirmo o corrijo en cada paso.

Al final no sale solo el PRD. Salen también los archivos que un agente necesita para construir sin perderse: las instrucciones del proyecto, el contexto para la IA y el prompt de cada milestone.

Si quieres ver cómo se ve un stack de agentes con nombre por dentro, armé un documento gratis: El Skill Stack GNB. Explica qué hace cada agente y qué prompt repetido reemplaza. Es lectura, no pitch.

¿Cómo convierto el PRD en issues de Linear?

Con el PRD aprobado, un segundo skill rompe el documento en tareas que se pueden tomar una por una. No las parte por capas sueltas; las parte en vertical slices.

Una vertical slice es una tajada angosta que cruza todo el camino —datos, lógica e interfaz— y se puede demostrar sola. Empiezas por la más fina que prueba que el flujo corre de punta a punta, y de ahí la engruesas. Cada tarea se marca como AFK, que un agente hace solo, o HITL, que necesita una persona.

Lo que me gusta del flujo es que el agente no publica nada hasta que apruebo la granularidad. Reviso si las tareas están muy gruesas o muy finas y si las dependencias tienen sentido, y solo entonces se crean en Linear.

Ahí entra Elias. Cuando cierro una cotización, toma ese backlog y crea el proyecto completo en Linear, con issues, estimados y asignaciones, en unos 10 minutos. Antes era media tarde de copiar y pegar.

Naira se queda con el seguimiento: registra horas, manda los status updates y pre-califica prospectos antes de que yo los vea. Hasta el blog tiene su parte, porque mi CMS detecta una página en posición 4 a 10 en Google y crea sola la tarea en Linear con el brief y las keywords. Yo reviso y decido; el agente hace el resto.

¿Cómo ve el cliente el avance del proyecto?

El cliente entra a Linear como invitado, con acceso de solo lectura y permiso para crear issues. Ve el avance real, sin que yo le arme un reporte aparte cada semana.

La regla que pongo desde el primer día es simple: todo feedback entra como issue, no por WhatsApp ni por correo. Así nada se pierde en un chat de las once de la noche, y cada petición queda con su responsable y su estado.

Linear se vuelve el Dev Portal del proyecto, el lugar único donde se ve qué está pasando. Cada milestone es un cycle, y el cliente sigue el trabajo en el mismo tablero donde el equipo lo ejecuta. Una sola fuente de verdad, no cinco hilos paralelos.

¿Qué es un radar semanal y por qué tu gestión de proyectos lo necesita?

Un dashboard te dice lo que pasó. Un radar te dice lo que viene. Esa es la parte que la gestión de proyectos tradicional no resuelve.

El reporte semanal del founder es de los trabajos peor pagados que existen: 3 horas consolidando datos para que en la junta se vean dos minutos. Y cuando el reporte llega tarde, las decisiones de la semana se toman con instinto.

El radar que opero cambia eso. Cada domingo a las 9 de la noche me llega un reporte que no solo junta los KPIs: la IA lee los números y me dice qué cambió contra la semana pasada, qué tendencia trae y qué requiere atención. Un cliente en riesgo, una métrica desviada, una oportunidad que está apareciendo.

Aplicado a proyectos, el radar detecta lo que se está cayendo antes de la junta de los lunes. No persigues el problema; el sistema te lo pone enfrente.

¿Cuánto tiempo ahorra gestionar proyectos con agentes de IA?

Los números que veo en mi propia operación son concretos. El reporte semanal pasó de 2 a 4 horas a cero: se entrega solo. La creación de un proyecto en Linear bajó de media tarde a unos 10 minutos de revisión.

Eso es plomería automatizada, nada más. La diferencia se acumula semana con semana, que es justo donde la gestión de proyectos manual te sangra el tiempo.

Lo importante no es solo recuperar las horas. Es que el trabajo se hace igual cada vez. Un humano cansado un viernes olvida poner un estimado; el agente nunca lo olvida porque el proceso está escrito en un skill.

Por eso insisto tanto en terminar lo que se inicia: un sistema que no se le olvida nada es lo que convierte un proyecto en algo que de verdad se cierra y se vuelve ingreso recurrente.

¿Por dónde empiezo si nunca he usado Claude Code?

Empieza por el proceso que más repites a mano. No intentes automatizar todo el primer día. Si dudas cuál elegir, escribí una guía sobre qué skill de IA construir primero.

Mi recomendación concreta, en orden:

1. Elige una tarea repetitiva con reglas claras: crear issues desde una junta, armar el reporte semanal, pasar una cotización a proyecto.
2. Conéctalo a la herramienta que ya usas, no a una nueva. Si tu equipo vive en Linear, ahí.
3. Conviértelo en un skill una vez. A partir de ahí el agente lo repite con la misma calidad, sin que se lo expliques de nuevo.

El error más común es empezar por el caso más complejo. El radar semanal, por ejemplo, es de los sistemas más rápidos de montar y de los que más impacto se sienten, justo por eso es buen primer proyecto.

El siguiente paso

De las formas que comparé aquí para gestionar proyectos, la única que sale con agentes corriendo en tu propia herramienta es montar un stack a tu medida, no copiar skills sueltas de un directorio gratis. Si quieres ver cómo está armado el mío —Elias en ventas, Naira en seguimiento, el radar avisando— el documento El Skill Stack GNB lo explica agente por agente. Es gratis y lo lees en una sentada.