/sprint-development lleva una historia de Jira hasta código desplegado. Planea antes de escribir una línea, verifica lo que construye contra la app que corre, pasa el diff por un revisor que no lo escribió, y recién ahí lo lleva a staging. Producción es un evento aparte, con tu aprobación.
Plan publicado en Jira y leído de vuelta.
Código por pasos, lint + tipos + tests en verde.
PR abierto, revisor adversarial, hallazgos juzgados.
Merge con tu OK, deploy verificado, pase a QA.
Opcional y con compuerta: QA en verde + negocio.
Es el loop de desarrollo del repo. El mismo pipeline corre para una historia nueva, un bug o una implementación que quedó a mitad: solo cambian la entrada y lo que se le pasa a cada etapa.
Las etapas van siempre en el mismo orden porque cada una alimenta a la siguiente: el plan lo lee la implementación, el diff lo lee el revisor, la aprobación abre el deploy. El paralelismo pasa adentro de una etapa, nunca entre etapas.
| Si el ticket es… | Entra por |
|---|---|
| Historia nueva | Stage 1 con el plan de historia (story-plan.md) |
| Feature de 3 historias o más | Stage 1 macro (feature-plan.md), después Stage 1 + 2 por historia |
| Bug | Stage 2 con bug-fix-workflow.md: causa raíz, reproducir, corregir |
| Implementación interrumpida | Stage 2 con continue-implementation.md, reusa el plan |
| Feedback de PR o CI en rojo | Stage 3 → Stage 2 con fix-issues.md, sin reescribir historia |
| Promover a producción | Stage 5, solo con QA en verde y aprobación de negocio |
Los tres chequeos corren en la conversación principal, sin subagentes, y corren siempre: también la primera vez, para que retomar o arrancar de cero sea una decisión explícita.
El scope es la key de Jira. Si existe .session/sprint-development/<KEY>/progress.md, la IA lee el plan sincronizado y te muestra el objetivo, la última etapa cerrada y lo que bloquea. Espera tu respuesta: retomar, reiniciar (archiva lo anterior) o abortar. Bajo .session/ solo se escribe progress.md: el plan vive en Jira.
Lee .context/dev-roadmap.md (si no existe, lo genera /project-context dev-roadmap) para tomar las dependencias, el Execution Sprint y las compuertas de mockup del ticket. Después consulta Jira en vivo por el ticket y sus bloqueantes directos. Si un bloqueante no está terminado, o el ticket ya pasó de desarrollo, frena y te pregunta.
Confirma que la épica padre tenga sus dos planes macro (feature-test-plan.md y feature-implementation-plan.md). Si falta uno, te ofrece generarlo o seguir sin él: eliges tú.
Esta skill no diseña y nunca escribe un mockup. Hace el chequeo y la derivación, en el Stage 1, para cada historia con UI, antes de planear código.
| Lo que encuentra en master-design-plan.md | Lo que hace |
|---|---|
| Fila §8 y su mockup existen | Construye con la spec de pantalla (§4) y los tokens congelados (§2). Un desvío deliberado se ratifica en §5 antes de codear. |
| Fila §8 marcada 🔒 mockup-gated | La fila ya dice qué falta: es la entrada de la compuerta, no un bloqueo. Una de las tres rutas. |
| No hay fila §8 | Las mismas tres rutas, y además se escribe la fila. |
| El proyecto no tiene master design plan | Fidelidad solo con DESIGN.md (tokens, sin pantalla de referencia), y lo dice en el plan. |
Deriva a la fase de pantallas de /design-system: arma el brief, encarga las pantallas con el mejor método disponible y devuelve un bundle. Una persona ratifica cada mockup.
Válida cuando no hay herramienta de diseño a mano o la pantalla es trivial frente a patrones existentes. Si el desvío es arquitectónico, también un ADR.
Fidelidad de tokens, sin pantalla de referencia, con tu aprobación explícita.
Si la pantalla encierra una decisión irreversible (una confirmación de borrado es la política de borrado), primero se ratifica el ADR. Dibujar primero deja la política en manos de quien compuso la pantalla.
Nunca se saltea, ni para un bug: aunque sea un párrafo de causa raíz antes del diff. Una feature de tres historias o más arranca con un plan macro; si no, directo al plan de historia.
Cada caso del Acceptance Test Plan se mapea a un paso de implementación. El ATP se lee siempre sincronizado con bun run jira:sync-issues get <KEY> --include-comments: del campo de la historia en jira-native, del issue Test Plan en jira-xray. Nunca con un view del campo.
Los ADRs de .context/ADR/ y el SRS son obligatorios si el plan toca una migración o un camino de auth, permisos, sesión o tenancy. Una decisión técnica nueva que es arquitectónica y difícil de revertir se promueve a un ADR antes de codear; el plan deja el backlink.
El plan va al campo spec_implementation_plan de la historia (o a un comentario de respaldo si el campo no existe). Antes de publicar, se convierte a ADF y se mide: más de 30.000 caracteres es un STOP con propuesta de qué sacar, nunca un recorte. Después, sync y lectura del implementation-plan.md materializado.
Ready For Dev → In Progress con el slug start_working, leyendo el assignee antes y después. Un slug que el catálogo no tiene sigue el protocolo de respaldo de artifact-lifecycle.md: nunca un id recordado.
Lee historia, ATP, ADRs y glosario; descompone en pasos; publica y sincroniza.
La ruta de diseño, si se sigue sin un plan macro, y qué sale del plan si no entra.
El plan en Jira, su copia en .context/PBI/ y el ticket en In Progress.
Al final del plan, el planner estima cuántas líneas va a mover el cambio. Pasadas unas 400 líneas de diff, la revisión deja de encontrar defectos. La decisión de partir se toma antes de escribir código.
| Estimado | Riesgo | Qué pasa |
|---|---|---|
| menos de 200 | Low | Pasa al Stage 2. |
| 200 a 400 | Medium | Pasa, con aviso de que el PR se acerca al presupuesto. |
| más de 400 | High | Compuerta: hace falta una estrategia de cadena de PRs decidida y con su traza. |
La implementación camina el plan un paso a la vez. Toca solo lo que la historia dice: nada de refactors de paso. Si una función pide TDD, se le pasa a /unit-testing y se vuelve cuando la unidad está en verde.
Una historia con UI se valida contra la app que corre, no contra una lectura del mockup más lint, tipos y tests en verde. Una historia sin UI saltea todo esto.
| Nivel | Sirve para | No alcanza para |
|---|---|---|
| Tier 0 · probe HTTP autenticado | Rutas y status, redirecciones de auth, contenido que renderiza el servidor, datos en el markup, re-chequeos rápidos. | Layout, tokens computados, estados del cliente, breakpoints, flujos interactivos, capturas. |
| Tier 1 · navegador (/playwright-cli) | Todo lo que se renderiza, se toca o se ve, y toda captura que se cita como evidencia. | Nunca contra un build de producción: siempre el dev server. |
La IA entra a la app solo como la cuenta que declara el proyecto. Si no está declarada, se detiene: nunca improvisa otra.
La rama se pushea y el PR se abre con /git-flow-master, que elige la base según la estrategia del repo. La automatización de Jira debería pasar el ticket a In Review en unos 30 segundos; si no lo hace, la skill dispara pull_request y avisa del hueco.
Un subagente nuevo, sin contexto de la implementación, recorre el checklist de review-pr.md: criterios cubiertos, lint y build, estándares, seguridad, autorización de RPCs si hay migraciones, fidelidad de UI. Devuelve hallazgos con severidad y evidencia archivo:línea. Sin evidencia no hay hallazgo.
Cada hallazgo se verifica contra el diff y los criterios: legitimate se corrige (vuelve al Stage 2 por fix-issues.md), false-positive se descarta con una línea de motivo. Aplicar un falso positivo es tan defecto como ignorar uno real. Un retrabajo arquitectónico vuelve al Stage 1.
Una fila por escenario de criterio, con qué lo prueba (test:, manual:, exempt: con motivo concreto, review-approved:) y su evidencia. Una fila uncovered sin justificación frena el merge.
| Severidad | Significa |
|---|---|
| BLOCKER | Frena el merge: criterio que falla, hueco de seguridad, build roto, riesgo de pérdida de datos. |
| MAJOR | Se corrige antes del merge: defecto real, violación de estándares con impacto. |
| MINOR | Impacto bajo: se corrige o se abre un follow-up. |
| NIT | Cosmético o de preferencia: opcional. |
El merge del PR pasa solo con tu OK: la skill nunca mergea sola. Después, el CI corre y el deploy de staging se vigila hasta que el deployment de ese commit dice READY.
La automatización debería mover In Review → Ready For QA; si no lo hace, la skill dispara deployed (bugs: fixed_and_deployed; tech items sin QA: complete) y relee el estado. Nunca marca Ready For QA sin CI en verde y smoke test pasado.
Comenta en el ticket con la URL del PR, la rama y una mención a quien hizo el shift-left. Reasigna la historia a esa persona de QA, porque la automatización del merge suele dejarla en el desarrollador; si no hay nadie identificable, la deja sin asignar. Verifica que el cambio haya quedado.
Con el ticket en Ready For QA y el smoke en verde, la sesión se archiva en .session/.archive/ y queda un resumen en memoria. Espera que le digas cuál es el próximo ticket.
Nunca se encadena desde el Stage 4. Corre solo con QA en verde en staging y aprobación explícita de negocio. Si la sesión ya se archivó, la Phase 0 la reabre y suma las entradas del Stage 5.
pre-deploy-checklist.md: tests, tipos, lint y build de producción; review aprobada; variables y secretos de producción; migraciones listas; backup reciente; monitoreo y alertas; PM y QA con su go.
Un subagente despliega y otro, en segundo plano, vigila la salud. La orquestadora se queda en línea al menos durante la ventana en la que se decide un rollback, antes de dar el deploy por bueno.
rollback-plan.md: volver al último deployment sano, validar producción, investigar la causa, corregir y re-testear en staging. No se arranca otra feature hasta que el rollback terminó.
Los dos modos corren las mismas etapas, las mismas compuertas y la misma verificación, en el mismo orden. Solo cambia la delegación. El modo se resuelve una vez y queda fijo para toda la corrida.
| Orquestado (default) | Solo (opt-in) | |
|---|---|---|
| Trabajo de cada etapa | Un subagente nuevo por etapa, con el briefing de 7 componentes | Inline, en la conversación principal; cero subagentes |
| Verificación cap=3 | Tres verificadores en paralelo | Los tres chequeos inline, uno después del otro |
| Corrección tras la review | Un subagente de fix | El fix inline |
| Review | Revisor independiente, después adjudicación | Una pasada deliberada con ojos nuevos, después la misma adjudicación |
| Conviene para | Todo lo que toca varios archivos | Tickets chicos, de un archivo, o cuando lo pides |
Hay dos ejes. El alcance: una historia o un sprint (batch). Los ejecutores: uno o varios. Con un ejecutor, el loop recorre los tickets en esta sesión. Con varios, cada historia tiene su propia sesión y la conversación que habla contigo es la conductora.
Cada fila del reporte avanza con cada transición de Jira; BLOCKED sale de costado desde cualquier estado activo. En flota, solo la conductora escribe el reporte.
| Solo la conductora | Por qué |
|---|---|
| Merge + deploy de staging + su verificación | Un solo staging y un solo orden de merge correcto: por dependencias, de a uno, cada deploy en READY antes del siguiente. |
| Migraciones a la base compartida | Irreversibles y pegan a todos a la vez; el worker manda su SQL y espera. |
| Regenerar desde la instancia viva | Tipos de Supabase o bun run api:sync: un worker absorbería el schema sin mergear de otro. |
| Reporte del sprint, sync masivo, registros generados | Archivos de todo el repo con un solo escritor. |
La lista completa vive en SKILL.md (Compact Rules y antipatrones). Estos son los que se notan primero desde afuera.
La skill no tiene modos con nombre: la entrada sale de tu frase. Nombras la skill, el ticket o el sprint, y lo que quieres hacer, en español o en inglés.
La barra carga la skill; el resto de la frase elige la entrada y el modo.
Sin barra: nombras la skill en la frase.
Mismo patrón que OpenCode, en CLI o Desktop.
| Si dices algo como… | Corre |
|---|---|
| "implementar esta historia" · "trabajar el ticket PROJ-123" | Stages 1 a 4 sobre una historia |
| "fix this bug and merge" | Stage 2 con el flujo de bugs, después 3 y 4 |
| "continue implementation" | Phase 0, y retomar en el Stage 2 |
| "code review for PR" | Stage 3 con su loop de correcciones |
| "process sprint N" · "continue sprint" | Batch: reporte del sprint y loop de tickets |
| "parallelize the sprint" · "una sesión por historia" | Batch en flota |
| "production deployment" · "rollback" | Stage 5 o su runbook de rollback |
Si no hay historia o los criterios no están claros, se refina ahí primero y se vuelve. Ver el deck.
Abre el PR, resuelve conflictos, decide la cadena de PRs con su traza y resuelve la política de push a ramas protegidas.
Rojo, verde, refactor sobre una función, y de vuelta al Stage 2. Ver el deck.
Su fase de pantallas produce el mockup justo a tiempo (ruta a). Ver el deck.
Si no hay ni PRD y SRS ni mapas de negocio, la skill corta y deriva a /project-foundation o a /project-context data; en una app existente el camino es /project-adoption y nunca escribe un PRD ni un SRS para pasar el chequeo. Si en un proyecto nuevo falta la infraestructura, deriva a /project-bootstrap. Ver el deck de bootstrap.
Genera y re-ordena .context/dev-roadmap.md; esta skill solo hace cambios puntuales cuando un ticket termina.
Usa el mismo checklist y la misma escala de severidad que el Stage 3, con su propio nivel de exigencia y un comentario publicado.
Un flujo de QA separado toma la historia desde Ready For QA. Queda fuera de esta skill.