refacil-sdd-ai 4.2.1 → 4.2.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "refacil-sdd-ai",
-  "version": "4.2.1",
+  "version": "4.2.3",
   "description": "SDD-AI: Specification-Driven Development with AI — metodologia de desarrollo con IA usando OpenSpec, Claude Code y Cursor",
   "bin": {
     "refacil-sdd-ai": "./bin/cli.js"

package/skills/review/SKILL.md

@@ -95,6 +95,22 @@ Parsea el bloque ` ```refacil-review-result ` del sub-agente. Si `verdict` es **
 - `changeName` es null.
 - El sub-agente retorno `SCOPE_ERROR`.
 
+### Paso 4: Recomendar siguiente paso
+
+Segun el `verdict` parseado, agrega al final de tu respuesta:
+
+**Si APROBADO o APROBADO CON OBSERVACIONES:**
+```
+El siguiente paso es archivar el cambio.
+Quieres que continue con /refacil:archive?
+```
+
+**Si REQUIERE CORRECCIONES:**
+```
+Una vez aplicadas las correcciones, el siguiente paso es re-verificar la implementacion.
+Quieres que continue con /refacil:verify?
+```
+
 ## Reglas
 
 - **Siempre construye el briefing (Paso 0.5) antes de delegar** — es la pieza clave que reduce el costo del sub-agente.

package/skills/test/SKILL.md

@@ -61,15 +61,19 @@ El sub-agente usara el briefing para generar tests directamente sin re-leer spec
 
 Retorna UN solo mensaje con el reporte + bloque JSON fenced como ` ```refacil-test-result `.
 
-### Paso 3: Presentar el reporte
+### Paso 3: Presentar el reporte y procesar resultado
 
 Muestra al usuario el **reporte** (todo lo anterior al bloque `refacil-test-result`). No muestres el bloque JSON — es metadata interna.
 
-Si el sub-agente retorno algo fuera de formato, informa al usuario: "El tester retorno un reporte no estructurado — revisa los tests manualmente."
+Si el sub-agente retorno algo fuera de formato, informa al usuario: "El tester retorno un reporte no estructurado — revisa los tests manualmente." y detente.
 
-### Paso 4: Continuidad del flujo
+Parsea el bloque `refacil-test-result` del sub-agente:
+- **Si `passed: false`** (tests fallaron): presenta los `issues` del JSON y pregunta al usuario como quiere proceder. **No continues al Paso 4** hasta que los tests pasen.
+- **Si `passed: true`**: continua al Paso 4.
 
-Despues del reporte, agrega:
+### Paso 4: Continuidad del flujo (solo si tests pasaron)
+
+Agrega:
 
 ```
 El siguiente paso es validar la implementacion vs specs.
@@ -82,7 +86,7 @@ Quieres que continue con /refacil:verify?
 - **Siempre delega al sub-agente**. No repliques aqui la logica de deteccion de stack ni de generacion.
 - **No invoques con scope ambiguo**. Si hay multiples cambios activos, pide seleccion primero.
 - **No muestres el bloque JSON al usuario**. Es solo metadata interna.
-- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad, invocar inmediatamente el **Skill tool** con `skill: "refacil:verify"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:verify`. (Ver `METHODOLOGY-CONTRACT.md §5`.)
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad **y los tests pasaron (`passed: true`)**, invocar inmediatamente el **Skill tool** con `skill: "refacil:verify"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:verify`. (Ver `METHODOLOGY-CONTRACT.md §5`.)
 
 ## Ver tambien
 

package/skills/up-code/SKILL.md

@@ -78,10 +78,12 @@ Ejecuta `git push -u origin [rama-actual]` para subir los cambios.
  Remote: origin/[nombre-rama]
 ```
 
-2. **Pregunta al usuario** a que rama quiere crear el PR. Sugiere `testing` como destino por defecto para validacion funcional:
-```
-A que rama quieres crear el PR? (recomendado: testing)
-```
+2. **Pregunta al usuario** a que rama quiere crear el PR. Sugiere `testing` como destino por defecto:
+   ```
+   A que rama quieres crear el PR? (recomendado: testing)
+   ```
+
+   Si el usuario indica una rama distinta a `testing`, verifica que exista en el remoto con `git branch -r | grep <rama-indicada>` antes de generar el link. Si no existe, informa al usuario y pide que confirme o corrija el nombre.
 
 3. Obtén la URL del repositorio remoto con `git remote get-url origin` y determina el hosting para generar el link correcto:
    - **GitHub** (url contiene `github.com`): `https://github.com/[owner]/[repo]/compare/[rama-destino]...[rama-actual]?expand=1`