Método de trabajo

Un gestor de proyectos se puede usar bien o mal. Este es el método con el que trabajamos nosotros con agentes: cada fase deja su resultado dentro de Hilbana (docs, tareas, comentarios), así que la siguiente fase, el siguiente agente y la siguiente persona parten de lo mismo. Cada fase tiene su prompt en el MCP y su atajo en el plugin de Claude Code.

Las fases de un vistazo

Fase	Qué se hace	Prompt (atajo)	Dónde queda
1. Decidir	Cerrar las decisiones del proyecto antes de escribir nada	— (tu propia entrevista o reunión)	Doc «Decisiones»
2. Especificar	Una spec por área, revisada contra las decisiones	especificar (/hilbana:especificar)	Docs «Spec · …»
3. Planificar	De las specs a tareas con dependencias	/hilbana:plan	Tareas enlazadas a su spec
4. Construir	Cada tarea, de la cola a revisión	claim_next, finish, review	Tareas, comentarios de cierre
5. Auditar	Al cerrar un bloque, revisarlo contra lo especificado	auditar_bloque (/hilbana:auditar-bloque)	Comentarios y tareas devueltas
6. Seguir	El parte de cada mañana para quien dirige	estado_proyecto (/hilbana:estado-proyecto)	Doc «Parte del proyecto»

1. Decidir

Antes de especificar, se deciden las cosas que cambian el proyecto: qué entra y qué no, cómo se comporta en los casos difíciles, qué se reutiliza. Cada decisión es una línea del doc «Decisiones» del proyecto:

D-012 · 2026-10-13 · Ana · aceptada · El catálogo llega sin filtrar a la web · origen WEB-41

Cómo se llega a ellas es cosa tuya: una entrevista con un agente que te pregunta hasta cerrar cada punto, una reunión o un documento previo. Hilbana no te impone una técnica: lo que importa es que acaben en el doc, porque las siguientes fases lo leen. Si ya tienes tu propio método, mete su resultado ahí. Ver Decisiones del proyecto.

2. Especificar

Con las decisiones tomadas, el prompt especificar propone las áreas y escribe una spec por área como doc del proyecto («Spec · Catálogo», «Spec · Pedidos»…): objetivo, alcance, comportamiento con casos, reglas, permisos y criterios de aceptación que se pueden comprobar, cada uno ligado a la decisión de la que sale. Una segunda revisión, hecha por otro agente si tu cliente puede lanzarlo, las contrasta con las decisiones y saca huecos y contradicciones. Las apruebas tú.

3. Planificar

/hilbana:plan convierte las specs en tareas con dependencias. Cada tarea enlaza su spec en el contexto del agente, y su Definition of Done sale de los criterios de aceptación de esa spec, no de la imaginación del momento. Las que se pueden hacer ya quedan en la cola de agentes.

4. Construir

Cada persona o agente coge trabajo de la cola (claim_next), lo hace y lo cierra con finish: verifica, deja la tarea en el estado que eligió el workspace y escribe un comentario de cierre para quien revise. Si al implementar se decide algo que cambia lo acordado, el comentario acaba con una sección «Decisiones:». Se trabaja por bloques (una tarea padre o un milestone), uno a uno o en paralelo.

5. Auditar por bloques

Al cerrar un bloque, auditar_bloque revisa cada tarea contra su spec, su Definition of Done y las decisiones, mira el commit y clasifica los hallazgos (bloqueante, mayor o menor). Te propone devolver lo que no pasa con un comentario accionable; quien la tenía asignada recibe el aviso «te devolvió una tarea». Lo puede lanzar un agente o una persona: propone y deja rastro, decide quien lo pidió.

6. Seguir el proyecto cada mañana

Quien dirige el proyecto pide el parte con estado_proyecto: las cifras de la pestaña Equipo (avance, ritmo, fin previsto, quién hizo qué cada día), lo que dejó hecho cada tarea, las decisiones del periodo cruzadas con el doc (las que chocan con algo aceptado salen marcadas) y lo que espera respuesta. Las decisiones se aceptan o se rechazan desde ahí, y el parte se guarda en un doc para que el de mañana diga qué cambió.

Un ejemplo real

Un proyecto de webs para los clientes de un software de gestión, con dos personas programando y una dirigiendo:

• Decidir: unas doscientas decisiones en el doc antes de la primera spec, sacadas de una entrevista larga con un agente.
• Especificar: ocho specs (instancias, catálogo, plantillas, cobros, pedidos…), cada una revisada contra las decisiones.
• Planificar: unas trescientas tareas en bloques por spec.
• Construir: en la primera semana, 43 tareas cerradas a un ritmo de 8,6 por día trabajado, con la fecha de fin prevista a la vista desde el primer día.
• Seguir: cada mañana, antes de la reunión, quien dirige ya sabía qué estaba en revisión, qué había vuelto atrás y qué decisiones del equipo chocaban con lo acordado, y las resolvía desde el propio parte.

Relacionado: Prompts · Equipo del proyecto · Agentes · Plugin de Claude Code.