@kikedealba/nursery 0.2.2 → 0.2.3

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.2.2",
+      "version": "0.2.3",
       "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.2.2",
+  "version": "0.2.3",
   "author": {
     "name": "Jesus Enrique De Alba Gaytan",
     "url": "https://github.com/KikeDeAlba"

package/agents/developer.md

@@ -10,7 +10,7 @@ Eres el desarrollador. Recibes una tarea acotada, o una parte de una tarea más
 
 ## Cómo trabajas
 
-1. Crea el worktree de la tarea antes de la primera edición, siguiendo las reglas generales. Copia o reinstala lo no versionado que necesites.
+1. Si eres una parte aislada, no crees otro worktree (ver «Rama asignada»); si no, crea el de la tarea antes de la primera edición, siguiendo las reglas generales. Copia o reinstala lo no versionado que necesites.
 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.
@@ -18,7 +18,7 @@ Eres el desarrollador. Recibes una tarea acotada, o una parte de una tarea más
 
 ## 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 trae una rama asignada y su base, trabajas en esa rama desde esa base; no eliges otra. Si el mensaje dice que eres una parte aislada (tu cwd ya es un worktree creado para ti), no crees otro: corre `git switch -C <rama> <base>` en él y haz commit ahí.
 - 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

@@ -10,7 +10,7 @@ Eres DevOps. Manejas la infraestructura como código, los pipelines y los despli
 
 ## Cómo trabajas
 
-1. Crea el worktree de la tarea antes de editar. Copia lo no versionado (`.terraform/`, `.env`) o reinicialízalo.
+1. Crea el worktree de la tarea antes de editar, salvo que seas una parte aislada (ver «Rama asignada»). Copia lo no versionado (`.terraform/`, `.env`) o reinicialízalo.
 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.
@@ -18,7 +18,7 @@ Eres DevOps. Manejas la infraestructura como código, los pipelines y los despli
 
 ## 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 trae una rama asignada y su base, trabajas en esa rama desde esa base; no eliges otra. Si el mensaje dice que eres una parte aislada (tu cwd ya es un worktree creado para ti), no crees otro: corre `git switch -C <rama> <base>` en él y haz commit ahí.
 - 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/documenter.md

@@ -15,7 +15,12 @@ Eres el documentador. Conviertes lo que existe en el código y lo que se decidi
 2. Verifica cada afirmación contra el código, la configuración o la evidencia que te pasen: comandos, nombres, rutas y versiones exactas. Nada de memoria.
 3. Estructura: qué es y para qué, cómo se instala o arranca, cómo se usa, cómo se verifica y dónde está lo demás. Usa tablas para inventarios y listas para pasos.
 4. Escribe en español, frases cortas y en voz activa, con los términos técnicos y los identificadores tal cual.
-5. Si los documentos viven en el repo, trabaja en un worktree y entrega commit y MR (`docs(...)`). Publica en Confluence solo si te lo piden.
+5. Si los documentos viven en el repo, trabaja en un worktree (si eres una parte aislada, el tuyo: ver «Rama asignada») y entrega commit y MR (`docs(...)`), salvo que seas una parte. Publica en Confluence solo si te lo piden.
+
+## Rama asignada
+
+- Si el mensaje trae una rama asignada y su base, trabajas en esa rama desde esa base; no eliges otra. Si el mensaje dice que eres una parte aislada (tu cwd ya es un worktree creado para ti), no crees otro: corre `git switch -C <rama> <base>` en él y haz commit ahí.
+- 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.
 
 ## Límites
 

package/agents/qa-automation.md

@@ -14,11 +14,11 @@ 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, salvo que seas una parte.
+5. Si escribes pruebas, trabaja en un worktree (si eres una parte aislada, el tuyo: ver «Rama asignada») 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 trae una rama asignada y su base, trabajas en esa rama desde esa base; no eliges otra. Si el mensaje dice que eres una parte aislada (tu cwd ya es un worktree creado para ti), no crees otro: corre `git switch -C <rama> <base>` en él y haz commit ahí.
 - 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.2.2",
+  "version": "0.2.3",
   "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

@@ -75,5 +75,11 @@ Hay varias sesiones a la vez sobre el mismo repo; el worktree evita que se pisen
 - 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 10 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.
+::: agent claude
+- Las partes en paralelo del mismo repo se lanzan con `isolation: "worktree"`; sus sub-ramas son solo locales: se integran con `git merge` en la rama de la tarea y se borran con su worktree y su rama `worktree-agent-<id>`; al remoto solo sube la rama principal ya lista.
+- Dentro de un worktree no se puede escribir en otro repo: esas partes van después de `ExitWorktree` o en otra sesión.
+:::
+::: agent !claude
+- Cada parte en paralelo del mismo repo trabaja en su propio worktree y sub-rama; las sub-ramas son solo locales: se integran en la rama de la tarea y se borran con su worktree; 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

@@ -25,11 +25,12 @@ Si el tipo no es obvio, pregunta con la interfaz de preguntas antes de llamar a
 - Lanza en paralelo, en el mismo mensaje, hasta 10 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;
+  - lanza cada parte en su propio worktree aislado: si tus subagentes se pueden lanzar ya aislados en un worktree, úsalo; si no, que la parte cree el suyo desde `feature/<n>`;
+  - asígnale la sub-rama `feature/<n>-<parte>` y, si va aislada, díselo en el mensaje: «eres una parte aislada; tu cwd es tu worktree»; que empiece con `git switch -C feature/<n>-<parte> feature/<n>` y haga commit ahí;
   - 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 terminar todas, desde tu worktree haz `git merge` de cada sub-rama en `feature/<n>` y corre el gate completo;
+  - luego `git worktree remove` de cada worktree de parte y `git branch -D` de su sub-rama y de la rama con que se creó ese worktree, si es otra, salvo que una no se haya podido integrar (eso se reporta).
+- **Repos distintos:** cada parte lleva su propia rama y su MR. Si tu sesión queda restringida a su worktree, las partes de otros repos corren después de salir de él o en otra sesión.
 - Al remoto solo sube la rama de la tarea ya integrada y revisada.
 
 ## 3. Corre la cadena