Prompts

Catálogo de prompts listos para copiar y pegar en un agente conectado a Hilbana por MCP: arrancar un proyecto, planificar una épica, tirar de la cola, revisar y más.

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 a "In Review" y release_issue.

Regla que no se salta: NO cierres la issue a "Done". Eso lo decide quien revisa.

Qué esperar: la issue en In Review, con su commit registrado y el rastro para que otro pueda juzgarla. El framework de trabajo explica por qué 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.

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.

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.

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. «No cierres a Hecho», «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.