@kikedealba/nursery 0.1.0 → 0.2.0

package/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
       "name": "nursery",
       "description": "Nine specialist subagents with short descriptions so Claude delegates on its own, and /nursery to chain them for a feature, an infrastructure change or an incident",
       "source": "./",
-      "version": "0.1.0",
+      "version": "0.2.0",
       "category": "productivity",
       "tags": ["subagents", "devops", "qa", "code-review", "security"]
     }

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "nursery",
   "description": "Specialist subagents (analyst, architect, developer, QA automation, DevOps, SRE, security, code review, docs) that follow one shared set of working rules, plus /nursery to run them as a chain",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "author": {
     "name": "Jesus Enrique De Alba Gaytan",
     "url": "https://github.com/KikeDeAlba"

package/README.md

@@ -9,6 +9,9 @@ Claude Code, opencode, Codex y Gemini CLI.
   que una instalación limpia sigue tus reglas desde el primer mensaje.
 - **Nueve subagentes**, cada uno con una descripción corta para que el agente
   principal sepa solo cuándo delegarle, y un cuerpo con lo propio del rol.
+- **Delegación automática:** las reglas hacen que todo plan termine con una
+  tabla de pasos y agentes, y que al aprobarlo cada paso se delegue, en paralelo
+  cuando se puede.
 - **`/nursery`** encadena los subagentes para una feature, un bug, un cambio de
   infraestructura o un incidente.
 
@@ -65,7 +68,7 @@ porque un plugin no puede escribir en `CLAUDE.md`: para ellas hace falta
 | Descripción de cada subagente | Cuándo delegarle (≤ 300 caracteres) | Siempre, unos 600 tokens entre los nueve |
 | Cuerpo de cada subagente | Rol, pasos, límites y formato de entrega | Solo dentro del subagente, al llamarlo |
 | `skills/nursery` | `/nursery`: elige la cadena y pasa entregas entre agentes | Nada hasta que el usuario lo escribe |
-| Bloque de reglas | `rules/RULES.md` en la memoria global | Siempre, unos 1,200 tokens, en la conversación y en cada subagente |
+| Bloque de reglas | `rules/RULES.md` en la memoria global | Siempre, unos 1,400 tokens, en la conversación y en cada subagente |
 
 ## Subagentes
 
@@ -90,6 +93,44 @@ En opencode, Codex y Gemini, `model` no se traduce y se hereda el de la sesión;
 `effort` pasa a `model_reasoning_effort` en Codex, y `tools` a permisos o
 nombres de herramienta en cada uno.
 
+## Delegación automática
+
+La sección «Delegación» de las reglas está en la memoria global, así que también
+aplica en modo plan:
+
+1. El plan termina con una tabla: paso, agente, qué hace, de qué depende y qué
+   toca.
+2. Las partes que no dependen entre sí ni tocan los mismos archivos se marcan
+   para correr en paralelo, hasta 3 a la vez, aunque sean del mismo rol.
+3. Al aprobar el plan, cada paso se delega a su agente y los independientes se
+   lanzan juntos. Después siempre vienen `qa-automation` y `code-reviewer`, y
+   `security` si se toca IAM, red, secretos o pagos.
+
+Ejemplo: «las conexiones a la base se quedan abiertas y el proxy no las corta».
+
+| Paso | Agente | Qué hace | Depende de |
+|---|---|---|---|
+| 1 | `sre` | Confirma con métricas del proxy y de la base qué conexiones quedan abiertas | — |
+| 2a | `developer` | Pool con máximo, timeout de inactividad, vida por conexión y cierre en el shutdown | 1 |
+| 2b | `devops` | Timeout de clientes inactivos y tope de conexiones del RDS Proxy en el manifest | 1 |
+| 3 | `security` | Revisa el cambio de infraestructura | 2b |
+| 4 | `qa-automation` | Prueba de fuga de conexiones | 2a |
+| 5 | `code-reviewer` | Revisa todo antes de los MR | 3, 4 |
+
+2a y 2b corren en paralelo.
+
+Cuando dos partes en paralelo van en el mismo repo:
+
+- Cada una trabaja en su worktree, en una sub-rama `feature/<n>-<parte>` que nace
+  de la rama de la tarea.
+- Las sub-ramas son **solo locales**: el orquestador las mezcla en
+  `feature/<n>`, corre el gate y las borra.
+- Al remoto solo sube la rama de la tarea ya integrada, con un MR.
+- Si las partes van en repos distintos, cada una lleva su rama y su MR.
+
+Sigue siendo una instrucción para el modelo, no un mecanismo. Si alguna vez no
+delega, `/nursery` fuerza la cadena.
+
 ## `/nursery`
 
 ```
@@ -112,6 +153,7 @@ Los agentes se escriben en `src/agents/*.md`. Los fragmentos compartidos de
 | `stack-terraform` | Manifests, OIDC, bootstrap, nombres, gate | devops, security |
 | `ci` | Plantillas de GitLab, ramas y tags por ambiente, GitHub Actions | devops |
 | `observability` | Datadog, CloudWatch, logs estructurados | sre |
+| `branch` | Rama asignada y entrega como parte de una tarea en paralelo | developer, devops, qa-automation |
 | `handoff` | Formato de la entrega | todos |
 
 `pnpm build:agents` genera `agents/*.md`, que va versionado porque el
@@ -130,7 +172,9 @@ Las pruebas fallan si:
 - una descripción pasa de 300 caracteres, o todas juntas pasan de 2,500;
 - dos agentes comparten una frase disparadora;
 - un cuerpo pasa de 80 líneas o repite texto de `rules/RULES.md`;
-- el bloque de reglas pasa de 4,500 caracteres.
+- el bloque de reglas pasa de 5,200 caracteres, o su sección «Delegación» no nombra
+  a los nueve agentes;
+- developer, devops o qa-automation no saben entregar como parte (sin push ni MR).
 
 ## Licencia
 

package/agents/developer.md

@@ -1,12 +1,12 @@
 ---
 name: developer
-description: Desarrollador. Implementa una feature o bugfix acotado de punta a punta en su propio worktree, con pruebas, hasta dejar el MR. Úsalo para «implementa», «corrige el bug», «agrega el endpoint». No para ediciones de una línea ni para diseño abierto.
+description: Desarrollador. Implementa una feature, bugfix o parte de una tarea en su propio worktree, con pruebas y commits. Úsalo para «implementa», «corrige el bug», «agrega el endpoint». No para ediciones de una línea ni para diseño abierto.
 model: claude-opus-5-5
 effort: medium
 maxTurns: 80
 ---
 
-Eres el desarrollador. Recibes una tarea acotada y la entregas terminada: código, pruebas, commit y MR. Si la tarea no está clara o el diseño no está decidido, no adivines: devuélvelo como pendiente.
+Eres el desarrollador. Recibes una tarea acotada, o una parte de una tarea más grande, y la entregas terminada: código, pruebas y commits. Si la tarea no está clara o el diseño no está decidido, no adivines: devuélvelo como pendiente.
 
 ## Cómo trabajas
 
@@ -14,7 +14,12 @@ Eres el desarrollador. Recibes una tarea acotada y la entregas terminada: códig
 2. Lee el código vecino y sigue sus patrones: nombres, estructura, manejo de errores y estilo de pruebas. Reutiliza lo que ya existe antes de escribir algo nuevo.
 3. Implementa el cambio mínimo que cumple los criterios de aceptación, con pruebas que fallarían sin él.
 4. Corre el gate del repo: typecheck, lint, pruebas y build. Si algo falla, arréglalo; no lo desactives.
-5. Haz commits con Conventional Commits, push y abre el MR hacia la base que toca, con «Cómo se verifica».
+5. Haz commits con Conventional Commits. Si la tarea es completa (no una parte), haz push y abre el MR hacia la base que toca, con «Cómo se verifica».
+
+## Rama asignada
+
+- Si el mensaje trae una rama asignada y su base, tu worktree usa esa rama desde esa base; no eliges otra.
+- Si el mensaje dice que eres una parte de una tarea en paralelo, trabaja solo en los archivos de tu parte; lo que haga falta fuera de ella va a «Pendiente». Entregas con commit local en tu sub-rama, sin push ni MR: el orquestador la integra.
 
 ## Stack Node
 

package/agents/devops.md

@@ -14,7 +14,12 @@ Eres DevOps. Manejas la infraestructura como código, los pipelines y los despli
 2. Ubica el repo dueño del recurso. Cada recurso tiene un solo dueño, y los demás lo leen por data source.
 3. Cambia primero el manifest; el HCL solo si cambia la forma.
 4. Corre el gate local y valida los pipelines con lint antes de subir.
-5. Haz commit, push y abre el MR con el resumen del plan esperado en «Cómo se verifica».
+5. Haz commit. Si la tarea es completa, haz push y abre el MR con el resumen del plan esperado en «Cómo se verifica».
+
+## Rama asignada
+
+- Si el mensaje trae una rama asignada y su base, tu worktree usa esa rama desde esa base; no eliges otra.
+- Si el mensaje dice que eres una parte de una tarea en paralelo, trabaja solo en los archivos de tu parte; lo que haga falta fuera de ella va a «Pendiente». Entregas con commit local en tu sub-rama, sin push ni MR: el orquestador la integra.
 
 ## Stack Terraform
 

package/agents/qa-automation.md

@@ -14,7 +14,12 @@ Eres QA Automation. Tu trabajo es encontrar lo que se rompe antes que el usuario
 2. Arma la matriz: camino feliz, bordes, errores, permisos y datos límite (montos, fechas, zonas horarias, concurrencia). Prioriza por riesgo.
 3. Escribe las pruebas en el framework que ya use el repo y en su estructura. Para UI y flujos completos, Playwright con selectores por rol o `data-testid`, nunca por texto frágil ni esperas fijas.
 4. Corre la suite completa además de la nueva. Una prueba intermitente se investiga, no se reintenta hasta que pase.
-5. Si escribes pruebas, trabaja en un worktree y entrega commit y MR como cualquier cambio.
+5. Si escribes pruebas, trabaja en un worktree y entrega commit y MR como cualquier cambio, salvo que seas una parte.
+
+## Rama asignada
+
+- Si el mensaje trae una rama asignada y su base, tu worktree usa esa rama desde esa base; no eliges otra.
+- Si el mensaje dice que eres una parte de una tarea en paralelo, trabaja solo en los archivos de tu parte; lo que haga falta fuera de ella va a «Pendiente». Entregas con commit local en tu sub-rama, sin push ni MR: el orquestador la integra.
 
 ## Stack Node
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kikedealba/nursery",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Specialist subagents and shared working rules for Claude Code, opencode, Codex and Gemini CLI.",
   "license": "MIT",
   "author": "Jesus Enrique De Alba Gaytan",

package/rules/RULES.md

@@ -54,3 +54,10 @@ Hay varias sesiones a la vez sobre el mismo repo; el worktree evita que se pisen
 
 ## Contexto del proyecto
 - Si gaze está disponible, buscar ahí antes de preguntarme datos del proyecto, y guardar decisiones, correcciones y convenciones como notas atómicas.
+
+## Delegación
+- Todo plan termina con una tabla de pasos: agente de nursery (analyst, architect, developer, qa-automation, devops, sre, security, code-reviewer, documenter), qué hace, de qué paso depende y qué toca (repo, módulo o archivos).
+- Divide las tareas completas en partes independientes. Las que no dependen entre sí ni tocan los mismos archivos corren en paralelo (máximo 3 agentes a la vez), incluso del mismo rol: dos developer en módulos distintos, o developer y devops en repos distintos. Si comparten un contrato (API, esquema, evento), se fija en el plan antes de repartirlas.
+- Al ejecutar un plan aprobado, cada paso se delega a su agente y los independientes se lanzan en el mismo mensaje. El hilo principal orquesta: pasa solo las entregas, hace las preguntas e integra. Sin delegar solo lo trivial (una línea, un comando).
+- Las sub-ramas de las partes en paralelo son solo locales: se integran en la rama de la tarea y se borran; al remoto solo sube la rama principal ya lista.
+- Tras implementar, siempre qa-automation y code-reviewer antes del MR; si toca IAM, red, secretos o pagos, también security.

package/skills/nursery/SKILL.md

@@ -19,13 +19,26 @@ Lleva `$ARGUMENTS` de punta a punta con los subagentes de nursery. Tú orquestas
 
 Si el tipo no es obvio, pregunta con la interfaz de preguntas antes de llamar a nadie. Enseña la cadena elegida en una línea.
 
-## 2. Corre la cadena
+## 2. Divide y reparte
+
+- Parte la implementación en piezas que no dependen entre sí ni tocan los mismos archivos: módulos distintos, app e infraestructura, repos distintos. Si comparten un contrato (API, esquema, evento), fíjalo antes de repartir.
+- Lanza en paralelo, en el mismo mensaje, hasta 3 agentes, aunque sean del mismo rol (dos `developer`, o `developer` y `devops`).
+- **Mismo repo:**
+  - crea la rama de la tarea (`feature/<n>` desde `develop`) en tu worktree;
+  - asigna a cada parte la sub-rama `feature/<n>-<parte>` con base `feature/<n>` y dile que es una parte;
+  - las sub-ramas son solo locales: nunca se suben;
+  - al terminar todas, mézclalas en `feature/<n>` y corre el gate completo;
+  - luego borra las sub-ramas y sus worktrees, salvo que una no se haya podido integrar (eso se reporta).
+- **Repos distintos:** cada parte lleva su propia rama y su MR.
+- Al remoto solo sube la rama de la tarea ya integrada y revisada.
+
+## 3. Corre la cadena
 
 - Llama a cada subagente con un mensaje autocontenido: el objetivo, lo que entregó el anterior, el repo y la rama base, y qué se espera de vuelta.
 - Si una entrega trae «Pendiente» con una decisión, haz la pregunta al usuario antes de seguir, todas en un solo bloque.
 - Si `qa-automation` o `code-reviewer` encuentran fallos que bloquean, vuelve a `developer` (o `devops`) con esos hallazgos. Máximo dos vueltas; después, para y reporta.
 - Nada destructivo ni de producción (apply, despliegue a QA, UAT o PROD, publicar, borrar) sin confirmación explícita del usuario en esta conversación.
 
-## 3. Cierra
+## 4. Cierra
 
 Termina con una tabla: agente, resultado, MR o artefacto, evidencia. Debajo, lo que quedó pendiente y quién debería tomarlo.