/product-management es el trabajo continuo de producto: convierte el PRD en épicas e historias dentro de Jira, las refina hasta que cualquiera del equipo pueda tomarlas, y calcula en qué orden se pueden empezar. La calidad del backlog decide todo lo que viene después.
Lo que dejó /project-foundation.
Directo en Jira, con clave real.
Gherkin, bordes, voz de negocio.
Orden topológico de dependencias.
/sprint-development toma cada historia.
A diferencia de /project-foundation, que corre una vez, esta skill se vuelve a invocar siempre que surja trabajo de producto: una feature nueva, un criterio ambiguo, una historia que no cumple INVEST a mitad de sprint.
Cada flujo tiene su propia referencia con el protocolo exacto. No los eliges por nombre: describes lo que necesitas y la skill enruta al flujo que corresponde.
Todo lo que la skill escribe va a Jira. Lo que ves en .context/PBI/ es una caché de solo lectura que materializa un script. Nadie la escribe a mano: ni tú ni la IA.
Los tres flujos que crean issues siguen el mismo contrato de sesión: primero se fija si hay trabajo a medio hacer, después escriben un plan, y recién con tu aprobación tocan Jira.
El scope es seed (A) o el slug de la épica (B, C). Si existe progress.md, la IA te muestra el objetivo, la última fase cerrada y la próxima, y espera: retomar, reiniciar (archiva lo anterior) o abortar.
Escribe .session/product-management/<scope>/plan.md: objetivo, entradas, enfoque, fases, riesgos y checklist de verificación. Nace en draft y pasa a approved solo cuando tú lo apruebas.
Cada épica creada (A), cada historia sumada (B) o cada parte de la épica descompuesta (C) deja una entrada en progress.md. Si se corta, se retoma desde ahí.
Con el checklist del plan en verde, la carpeta se mueve a .session/.archive/ y queda un resumen en la memoria persistente para encontrarla después.
Corre una vez, cuando hay PRD y SRS frescos y cero issues en Jira. Avanza épica por épica para mantener el contexto acotado.
Sale de .agents/project.yaml. Si falta o está mal formada, la IA se detiene: nunca adivina una clave.
Épicas con sus historias fundacionales, prioridad y orden provisional. Es un borrador de trabajo para que tú detectes épicas de más o de menos antes de gastar números de ticket.
Crea la épica y la pasa a su estado por defecto ({{jira.statuses.epic_default}}, Planning si el slug no está). Crea las historias hijas validadas con INVEST y las pasa a {{jira.statuses.story_default}} (Shift-Left QA por defecto). Después, bun run jira:sync-issues pull --epic.
Compara el alcance de las historias hermanas. Si dos comparten un bullet literal, levanta un overlap_alert y no lo arregla sola: tú eliges mover el bullet, extraer una historia compartida o aceptar el duplicado con su razón.
Con todo creado, corre el descubrimiento de dependencias, publica los links en Jira y cierra con la secuenciación (ver §11).
Lee PRD, personas, journeys y specs funcionales; arma el borrador; crea en Jira.
Apruebas el árbol, resuelves cada solapamiento y confirmas la matriz de dependencias.
Issues en Jira, la caché en .context/PBI/ y .context/dev-roadmap.md §4.
Un pedido del PO, una oportunidad, feedback de un cliente. Antes de crear nada, la IA clasifica la idea en uno de tres niveles. La clasificación decide el camino.
Extiende algo que existe, entra en una épica actual, no pide cambios de arquitectura. Se crea la historia bajo esa épica.
Capacidad nueva que no entra en ninguna épica, con alcance acotado y entre 3 y 8 historias. Se crea la épica con sus hijas, links, chequeo de solapamiento y secuenciación.
Dos o más épicas, dependencias complejas, cambios de arquitectura. No se crea nada: sale un plan de división. Aprobado el plan, se corre el nivel 2 una épica a la vez.
Agrupa historias relacionadas bajo un mismo padre, cuenta el "por qué" de la capacidad y mide el avance a escala de feature. Si no se describe en dos oraciones, son dos épicas.
El título de una historia no es la frase "Como… quiero… para…". Esa frase es larga para una tarjeta y entierra la acción. Va en la descripción; el título usa otro formato.
{Feature} | {Action} · en inglés · sin persona ni beneficio
esto va en la descripción, sección "User story", nunca en el título
Una buena historia entra en un sprint, está en la voz de la persona y no deja dudas sobre qué es "terminada". Si dos devs la leen e imaginan cosas distintas, no está refinada.
| INVEST | La pregunta | Si falla |
|---|---|---|
| Independent | Se completa sin depender de otras historias? | Resecuenciar, o extraer la dependencia compartida a su propia historia. |
| Negotiable | Queda flexibilidad en cómo se implementa? | Sacar detalle de implementación de la descripción. |
| Valuable | El "para que…" es un beneficio claro? | Hablar con producto; sin valor, no se construye. |
| Estimable | El equipo podría dimensionarla con lo que hay? | Un spike acotado en tiempo, y después refinar de nuevo. |
| Small | Entra en un sprint? | Partirla en rebanadas verticales. |
| Testable | Los escenarios son claros y medibles? | Reescribir en Gherkin: mínimo uno feliz, uno de error y uno de borde. |
Un criterio sin un "dado", un "cuando" y un "entonces" concretos no es un criterio: es un deseo. El objetivo es quitar cada "depende" antes de que la historia entre al sprint.
un escenario de error, en su bloque gherkin, con texto concreto
El orden sale del grafo de links de Jira, no de una intuición. Por eso antes de ordenar hay que descubrir las dependencias reales y publicarlas.
Antes de crear o editar una historia, la IA arma una matriz (desde, hacia, fuente) leyendo el árbol de épicas, los links que ya existen y el mapa de datos. Fuentes válidas: el orden del PRD o del SRS, el master plan, las relaciones entre entidades y lo que declaró una persona.
"Necesita que exista el login" o "necesita la base de datos" es una propiedad del proyecto, no una dependencia entre dos historias. La prueba: si la dependencia desaparece al reordenar sprints, era ruido.
La matriz filtrada se te muestra antes de escribir un solo link. Cada link se crea de a uno y se relee para verificar la dirección: "A depende de B" tiene que leerse así desde A.
Si el workspace no tiene el tipo de link de dependencias, el respaldo relates pierde la dirección: la IA te lo avisa con nombre y apellido.
Con los links publicados, el flujo H hace un orden topológico: lo que no espera a nadie va al Execution Sprint 1; lo que solo espera al 1, al 2; y así hasta vaciar el grafo.
Nada los bloquea: se empiezan en paralelo.
Cada uno espera a una historia del sprint 1.
1 + el sprint más alto de sus predecesoras.
ejemplo ilustrativo · solo cuentan los links de dependencia y de bloqueo
Una foto del sprint y del backlog orientada a desarrollo. Es de solo lectura: no cambia estados, no crea issues, no escribe en .context/. Se muestra en la conversación y se guarda solo si lo pides.
el orden de los grupos sigue la urgencia de desarrollo
Una historia se escribe, se refina y queda lista sin que exista ninguna pantalla dibujada. No se posterga, no se bloquea y no se degrada por eso.
La lista completa de antipatrones vive en SKILL.md. Estos son los que un PM nota primero.
Esta skill no tiene modos con nombre: el flujo sale de tu frase. Nombras la skill y describes lo que quieres, en español o en inglés.
La barra carga la skill; el resto de la frase elige el flujo.
Sin barra: nombras la skill en la frase.
Mismo patrón que OpenCode, CLI o Desktop.
| Si dices algo como… | Corre |
|---|---|
| "seed the product backlog" | A · siembra inicial |
| "agregar feature al backlog" | B · feature incremental |
| "crear épica" | C · creación de épica |
| "INVEST a esta historia" · "3 amigos" | D · refinamiento |
| "refine acceptance criteria" | E · criterios de aceptación |
| "enumerar edge cases" | F · edge cases |
| "reporte de sprint" · "estado del sprint" | G · reporte |
| "qué historias trabajamos primero" | H · secuenciación |
Toma cada historia lista y la lleva de plan a código, review y deploy. Si los criterios no están claros, te devuelve aquí a refinar primero.
Escribe la §4 de .context/dev-roadmap.md con el orden que calcula el flujo H.
TDD sobre una función, dentro de /sprint-development.
Deja el PRD y el SRS de los que sale la siembra inicial.