Prompts

Estos son los prompts que usamos nosotros. Se copian, se rellenan los huecos y se pegan en un agente que tenga el MCP de Hilbana conectado. Cada uno ejecuta un flujo de trabajo completo contra tu workspace: no son ejemplos de juguete.

Sustituye lo que va entre corchetes antes de enviar. Los datos variables aparecen siempre igual ([nombre del proyecto], [stack], [objetivo en una frase], [DRAPPS-N]) para que se vean de un vistazo. DRAPPS-N es el identificador de una issue: el prefijo es el de tu equipo, el número el de la issue.

Si usas Claude Code, instala primero el plugin. La mayoría de estos flujos vienen ya como comandos (/hilbana-plan, /hilbana-claim-next, /hilbana-review, /hilbana-crear-docs), que además traen memoria por proyecto y contabilidad de tokens. El texto en bruto queda debajo para quien use otro agente o no tenga el plugin.

Una nota sobre el endpoint: si tienes una instalación propia, donde ponga https://app.hilbana.com/mcp va https://<tu-host>/mcp.

1. Iniciar un proyecto

Para qué: pasar de «tengo una idea y un repo» a un proyecto con documentos de contexto y las primeras issues ejecutables, sin escribir nada a mano.

Herramientas: save_project, save_doc, save_issue, list_workflow_states.

Vas a montar un proyecto nuevo en Hilbana usando las herramientas MCP. No me
preguntes nada que puedas deducir leyendo el repositorio.

Proyecto: [nombre del proyecto]
Objetivo en una frase: [objetivo en una frase]
Stack: [stack]
Repositorio: [ruta local o URL del repo]

Hazlo en este orden:

1. Crea el proyecto con save_project, con una descripción de tres o cuatro líneas
   que explique para quién es y qué problema resuelve.
2. Crea tres documentos con save_doc en ese proyecto:
   - "Visión y alcance": el problema, a quién sirve, qué queda fuera.
   - "Arquitectura y stack": cómo está montado, dónde se despliega, qué decisiones
     técnicas ya están tomadas y por qué.
   - "Convenciones": estilo de código, ramas, commits, criterios de revisión.
   Sácalo del repositorio (README, CLAUDE.md, configuración, código). Si algo no
   está y hace falta, escríbelo como pregunta abierta al final del documento, no te
   lo inventes.
3. Crea entre 5 y 8 issues con save_issue para el primer tramo de trabajo. Cada una
   con description, agentContext (ficheros que hay que tocar y contexto necesario),
   definitionOfDone y verifyCommand. Marca agentReady=true solo en las que no
   dependen de otra.
4. Devuélveme una tabla con lo creado: identificador, título y si está lista para
   agente.

Qué esperar: el proyecto creado con sus tres documentos y un primer tramo de issues con la Definición de Ready rellena. Revísalas antes de dejar que un agente las coja: lo que quede flojo en el definitionOfDone se paga después.

2. Convertir una idea en épica

Con el plugin: /hilbana-plan

Para qué: partir un objetivo grande en un grafo de sub-issues, con las dependencias declaradas y la frontera encolada.

Herramientas: save_issue (con parentId), link_issues, list_projects.

Convierte este objetivo en una épica con sub-issues en Hilbana.

Objetivo: [objetivo en una frase]
Proyecto: [nombre del proyecto]
Restricciones: [plazos, dependencias externas, lo que NO hay que tocar]

1. Crea la issue padre con el objetivo, el alcance y lo que queda fuera.
2. Pártela en sub-issues (parentId) de un tamaño que un agente pueda cerrar de una
   sentada. Cada una con definitionOfDone verificable y verifyCommand real: un
   comando que se pueda ejecutar, no "revisar a mano".
3. Declara las dependencias con link_issues (blocks / blocked_by). No inventes
   dependencias que no existan: lo que pueda ir en paralelo, va en paralelo.
4. Marca agentReady=true SOLO en las que no están bloqueadas por ninguna otra.
5. Muéstrame el grafo resultante y dime cuáles arrancan ya.

Qué esperar: una épica con sus hijas y solo la primera oleada en la cola. Las demás se van encolando conforme se cierran sus bloqueantes.

3. Documentar este repo en Hilbana

Con el plugin: /hilbana-crear-docs

Para qué: que el contexto que hoy vive en la cabeza de alguien (o en un CLAUDE.md) quede en los documentos del proyecto, que es lo que leen los agentes al empezar.

Herramientas: list_projects, list_docs, get_doc, save_doc.

Documenta este repositorio en su proyecto de Hilbana.

Proyecto: [nombre del proyecto]

1. Lee el repo: README, CLAUDE.md, ficheros de configuración, scripts, estructura
   de carpetas.
2. Mira con list_docs qué documentos existen ya. Actualiza los que estén
   desfasados en vez de crear duplicados.
3. Deja al menos: visión y alcance, arquitectura y despliegue, convenciones del
   código y cómo se prueba y se publica.
4. Escribe solo lo que puedas verificar en el código. Lo que sea suposición va en
   una sección final "Por confirmar", separado del resto.
5. Al terminar, dime qué has creado, qué has actualizado y qué preguntas te quedan.

Qué esperar: documentos con lo que de verdad está en el repo y una lista corta de dudas para ti. Ojo con la fecha: la documentación envejece, y un documento que afirma lo contrario de lo que hace el código es peor que no tenerlo.

4. ¿Qué hago hoy?

Para qué: el plan del día sacado de las issues reales, no de la memoria.

Herramientas: list_issues, search_issues, list_members, list_cycles.

Móntame el plan de hoy con lo que tengo en Hilbana.

Persona: [tu nombre o correo en el workspace]
Tiempo disponible: [horas]

1. Saca mis issues abiertas, con su prioridad, vencimiento y estado.
2. Ordénalas por lo que arde primero: vencidas, luego las que vencen hoy o mañana,
   luego prioridad.
3. Propón un plan que quepa en el tiempo disponible. Di explícitamente qué NO entra
   y por qué.
4. Marca las que estén bloqueadas por otra persona: eso no es trabajo mío, es un
   recordatorio que tengo que mandar.
5. Formato: lista corta. Nada de párrafos.

Qué esperar: una lista priorizada y, casi siempre, un par de sorpresas: issues vencidas que dabas por hechas o bloqueos que llevan días parados.

5. Coger la siguiente tarea y hacerla

Con el plugin: /hilbana-claim-next y /hilbana-finish

Para qué: el ciclo completo en modo pull. El tracker es la cola; el agente tira de ella.

Herramientas: next_ready_issue, get_issue, change_issue_state, add_comment, record_run, release_issue.

Coge la siguiente tarea de la cola de Hilbana y hazla de principio a fin.

1. next_ready_issue para reclamarla. Si devuelve null, dímelo y para: no busques
   trabajo por tu cuenta.
2. Lee su descripción, su agentContext y su definitionOfDone antes de tocar código.
   Si la Definición de Ready está incompleta o el enunciado es ambiguo, NO improvises:
   comenta en la issue qué falta, libérala y para.
3. Muévela a "In Progress" con change_issue_state y trabájala.
4. Ejecuta el verifyCommand. Si no pasa, arréglalo. Si no puedes, comenta por qué.
5. Al terminar: record_run con el resultado y el commit o la PR, un comentario con
   el resumen para quien revise, la issue al estado que indica agentCloseState y
   release_issue.

Regla que no se salta: deja la issue en el estado de agentCloseState y en ningún
otro. Lo eligen el dueño o un admin del workspace, no tú.

Qué esperar: la issue en el estado que eligieron el dueño o un admin del workspace (por defecto, In Review), con su commit registrado y el rastro para que otro pueda juzgarla. Ese estado se configura en Ajustes → Estados. El framework de trabajo explica por qué, por defecto, el trabajador no aprueba lo suyo.

6. Revisar lo que está en revisión

Con el plugin: /hilbana-review

Para qué: cerrar el ciclo que abre el prompt anterior, contrastando contra el definitionOfDone y no contra la impresión general. Tiene sentido mientras los agentes dejen el trabajo en revisión, que es lo que pasa por defecto; si el workspace ha elegido que lo cierren en Done, no queda nada en In Review que revisar.

Herramientas: list_issues, get_issue, list_comments, change_issue_state, add_comment.

Revisa lo que está en "In Review" en Hilbana.

Proyecto: [nombre del proyecto]

Para cada issue:
1. Lee su definitionOfDone y su verifyCommand, y el run que dejó registrado el
   trabajador (commit o PR).
2. Comprueba el trabajo contra el DoD punto por punto. Ejecuta el verifyCommand.
3. Decide:
   - Cumple: muévela a "Done" con un comentario corto de qué se validó.
   - No cumple: devuélvela a "In Progress" con un comentario que diga QUÉ falta y CÓMO
     comprobarlo. Nada de "revisar esto" a secas.
4. Si el DoD estaba mal escrito y por eso el trabajo se fue de sitio, dilo: el
   problema es la issue, no quien la hizo.

Al final, dame un resumen: aprobadas, devueltas y por qué.

Qué esperar: cada issue movida con un motivo escrito. El valor está en los comentarios de las devueltas: son los que evitan la segunda vuelta.

7. Higiene del backlog

Para qué: pasar la escoba cada pocas semanas. Los backlogs no se pudren de golpe.

Herramientas: list_issues, search_issues, get_issue, save_issue, link_issues, add_comment.

Haz una revisión de higiene del backlog de Hilbana.

Proyecto: [nombre del proyecto]

Búscame:
1. Duplicados o issues que se solapan (compara títulos y descripciones, no solo
   títulos).
2. Issues sin definitionOfDone o con uno que no se puede verificar.
3. Issues sin proyecto, sin responsable o sin prioridad.
4. Issues paradas: sin actividad desde hace [número] días.
5. Issues que ya no tienen sentido porque el producto cambió.

No borres ni cierres nada por tu cuenta. Devuélveme una lista por categorías, con
el identificador, el título y qué propones para cada una. Donde veas duplicados,
dime cuál conservarías y por qué.

Qué esperar: una lista para decidir en diez minutos. La regla importante está en el prompt: el agente propone, tú cierras.

8. Informe de estado semanal

Para qué: contarle a alguien que no vive en el tracker qué ha pasado, sin abrir el tracker.

Herramientas: list_issues, list_cycles, list_milestones, get_issue.

Escribe el informe semanal de este proyecto para gente que no usa el gestor.

Proyecto: [nombre del proyecto]
Periodo: últimos [número] días
Destinatario: [cliente, dirección, equipo]

Estructura:
1. Qué se ha cerrado, en una frase por cosa y en lenguaje de negocio, no de código.
2. Qué está en curso y cuándo se espera.
3. Qué está bloqueado, por qué y quién lo desbloquea.
4. Riesgos y decisiones que necesito tomar yo.

Sin identificadores de issue en el cuerpo (déjalos en un anexo al final), sin jerga
técnica y sin adjetivos comerciales. Si una semana no ha avanzado nada, dilo.

Qué esperar: algo enviable tal cual. El anexo con los identificadores está para quien quiera tirar del hilo.

Si diriges el proyecto día a día, usa el parte diario: el prompt estado_proyecto del MCP (con el plugin, /hilbana:estado-proyecto WEBS desde ayer). Toma las cifras de la pestaña Equipo (avance, ritmo, fin previsto, quién hizo qué cada día), lee los comentarios de cierre para sacar las decisiones y lo que espera respuesta, y te lo enseña en un panel. Si rechazas algo, propone devolver la tarea o avisar a quien toque, y solo lo hace cuando le dices que sí.

9. Bug a issue con causa raíz

Para qué: que un fallo no se quede en «no va». Una issue de bug sin reproducción es un ticket que alguien tendrá que investigar dos veces.

Herramientas: save_issue, search_issues, mem_save.

Convierte esto en una issue de bug bien formada en Hilbana.

Proyecto: [nombre del proyecto]
Síntoma: [qué has visto]
Cómo llegar ahí: [pasos, si los sabes]
Entorno: [navegador, versión, entorno]

1. Antes de crearla, busca con search_issues si ya está reportada. Si lo está,
   dímelo y no crees otra.
2. Investiga la causa raíz en el código. No te quedes en el síntoma: dime qué línea
   lo provoca y por qué se comporta así.
3. Crea la issue con save_issue: reproducción paso a paso, comportamiento esperado
   frente al real, causa raíz, ficheros implicados en agentContext, definitionOfDone
   verificable y verifyCommand (el test que hoy falla y mañana tiene que pasar).
4. Guarda la causa raíz en la memoria del proyecto con mem_save (type: bug), para
   que la próxima sesión no vuelva a investigarlo desde cero.

Qué esperar: una issue que otra persona (o un agente) puede coger sin preguntarte nada, y un apunte en la memoria que sobrevive a la sesión.

Los cuatro apartados siguientes son las piezas del método de trabajo: ahí se ve cómo encajan, de las decisiones al parte diario.

De las decisiones a las specs

Con el plugin: /hilbana:especificar WEBS. Sin él: el prompt especificar del MCP.

Con las decisiones del proyecto ya tomadas, el agente 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 las contrasta con las decisiones y saca los huecos y las contradicciones. Cuando las apruebas, pasa a planificar: cada tarea que crea enlaza su spec y su Definition of Done sale de los criterios de esa spec.

Auditar un bloque cerrado

Con el plugin: /hilbana:auditar-bloque WEBS-12. Sin él: el prompt auditar_bloque del MCP.

Cuando se cierra un bloque (una tarea padre o un milestone), el agente revisa cada tarea contra su spec, su Definition of Done y su comando de verificación, mira el commit, y comprueba que no contradice ninguna decisión del proyecto. Te enseña una tabla con lo que pasa y lo que no, con cada hallazgo clasificado (bloqueante, mayor o menor), y te propone devolver lo que no pasa con un comentario accionable. Solo lo hace cuando le dices que sí, y vale tanto si la auditoría la hace un agente como una persona.

Decisiones del proyecto

Lo que se decide en un proyecto se queda en un doc del proyecto titulado «Decisiones», una línea por decisión:

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

El estado es propuesta, aceptada, rechazada o sustituida por D-0NN. Dos prompts lo mantienen:

• finish: si quien implementa decide algo que cambia el alcance o se aparta de lo acordado, su comentario de cierre acaba con una sección «Decisiones:», una línea por decisión y con el porqué.
• estado_proyecto: cruza esas secciones con el doc, te señala las que chocan con una decisión aceptada («choca con D-015») y las nuevas, y al aceptarlas las añade al doc. Si rechazas una, te propone devolver la tarea.

Adaptarlos a tu equipo

Ninguno de estos prompts es sagrado. Lo que sí conviene conservar cuando los toques:

• Los huecos explícitos. Un prompt que hace quince preguntas antes de empezar cansa más que rellenar cuatro corchetes.
• El orden de las herramientas. Primero leer (get_issue, list_docs), después escribir. Un agente que escribe antes de leer duplica.
• Los límites. «Deja la issue en el estado de agentCloseState», «no borres nada», «si falta contexto, para y comenta». Son las frases que evitan los desastres silenciosos.

Relacionado: Agentes · Plugin para Claude Code · API y MCP · Memoria de agentes · Framework de trabajo.