refacil-sdd-ai 2.0.1 → 2.0.3

package/README.md

@@ -67,7 +67,7 @@ Una vez instalado, estos comandos estan disponibles en Claude Code y Cursor:
 | `/refacil:propose` | Crear propuesta de cambio (proposal + specs + design + tasks) |
 | `/refacil:apply` | Implementar las tasks del cambio propuesto |
 | `/refacil:test` | Generar tests unitarios desde los artefactos |
-| `/refacil:verify` | Validar implementacion vs specs |
+| `/refacil:verify` | Validar implementacion vs specs (con opcion de aplicar correcciones) |
 | `/refacil:review` | Review con checklist de calidad del equipo |
 | `/refacil:archive` | Archivar cambio completado |
 | `/refacil:up-code` | Subir codigo a rama de desarrollo (con validacion de ramas protegidas) |
@@ -83,6 +83,8 @@ Una vez instalado, estos comandos estan disponibles en Claude Code y Cursor:
 /refacil:apply
 /refacil:test
 /refacil:verify
+# → Si hay correcciones: verify pregunta si aplicarlas automaticamente
+# → Si aprueba: aplica fixes y re-verifica (max 2 rondas)
 /refacil:review
 /refacil:archive
 /refacil:up-code
@@ -118,7 +120,7 @@ refacil-sdd-ai init          →  Skills en .claude/ y .cursor/
 /refacil:propose             →  Artefactos en openspec/changes/
 /refacil:apply               →  Codigo implementado
 /refacil:test                →  Tests generados
-/refacil:verify              →  Validacion PASS/FAIL
+/refacil:verify              →  Validacion PASS/FAIL (puede aplicar fixes con aprobacion)
 /refacil:review              →  Review con checklist
 /refacil:archive             →  Cambio archivado
 /refacil:up-code             →  Push a rama de desarrollo

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "refacil-sdd-ai",
-  "version": "2.0.1",
+  "version": "2.0.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/apply/SKILL.md

@@ -111,6 +111,7 @@ Al terminar la implementacion de OpenSpec, agrega este resumen:
  Siguientes pasos:
  1. /refacil:test — Generar tests unitarios
  2. /refacil:verify — Validar implementacion vs specs
+    (si encuentra correcciones, te ofrece aplicarlas automaticamente)
 ```
 
 ## Reglas

package/skills/guide/SKILL.md

@@ -51,6 +51,17 @@ FLUJO PARA NUEVO FEATURE:
    Valida que la implementacion cumple con las specs.
    Revisa completitud, correccion y coherencia.
 
+   Si encuentra correcciones necesarias (CRITICAL o WARNING):
+   - Te muestra el reporte con los issues encontrados
+   - Te pregunta si quieres que aplique las correcciones automaticamente
+   - Si aceptas: aplica SOLO los fixes necesarios y re-verifica
+   - Maximo 2 rondas de correccion automatica
+   - Si despues de 2 rondas quedan issues, los lista para correccion manual
+   - Si no aceptas: lista los issues para que los corrijas manualmente
+     y luego ejecutes /refacil:verify de nuevo
+
+   Solo avanza a review cuando la verificacion pasa completamente.
+
 6. /refacil:review
    Review con el checklist de calidad del equipo.
    Evalua conformidad con specs, codigo, arquitectura, testing,

package/skills/review/SKILL.md

@@ -106,4 +106,4 @@ Correcciones necesarias:
 - Ser constructivo: no solo decir que falla, sino como corregirlo
 - No ser excesivamente estricto con N/A — si no aplica, marcarlo
 - Si todo es PASS, felicitar brevemente y sugerir `/refacil:archive`
-- Si hay FAILs criticos (seguridad, tests), marcar como bloqueantes
+- Si hay FAILs criticos (seguridad, tests), marcar como bloqueantes y sugerir `/refacil:verify` para aplicar correcciones con asistencia de la IA

package/skills/setup/SKILL.md

@@ -138,7 +138,7 @@ Si por cualquier razon no puedes generar un AGENTS.md completo (archivos no legi
 | `/refacil:propose` | Crear propuesta de cambio |
 | `/refacil:apply` | Implementar tasks del cambio |
 | `/refacil:test` | Generar tests unitarios |
-| `/refacil:verify` | Validar implementacion vs specs |
+| `/refacil:verify` | Validar implementacion vs specs (con opcion de aplicar correcciones) |
 | `/refacil:review` | Review con checklist de calidad |
 | `/refacil:archive` | Archivar cambio completado |
 | `/refacil:up-code` | Subir codigo a rama de desarrollo |
@@ -169,7 +169,7 @@ Si el usuario aprueba (o no tiene cambios), escribe el archivo en la raiz del pr
 
 #### 7.1 Verificar skills de OpenSpec
 
-Verifica que existan las 10 carpetas de skills de OpenSpec en `.claude/skills/`:
+Verifica que existan las 10 carpetas de skills de OpenSpec en `.claude/skills/` y `.cursor/skills/`:
 - `openspec-apply-change`
 - `openspec-archive-change`
 - `openspec-bulk-archive-change`

package/skills/test/SKILL.md

@@ -77,6 +77,9 @@ Si el usuario ejecuta `/refacil:test` sin argumentos:
     Coverage archivos nuevos: [X]%
     Coverage minimo requerido: 80%
     Estado: CUMPLE / NO CUMPLE
+
+   Siguiente paso: /refacil:verify — Validar implementacion vs specs
+   (si encuentra correcciones, te ofrece aplicarlas automaticamente)
    ```
 
 ### Modo 2: Tests para archivo especifico (con argumento)

package/skills/up-code/SKILL.md

@@ -79,15 +79,31 @@ Ejecuta `git status` para verificar si hay cambios para subir.
 
 Ejecuta `git push -u origin [rama-actual]` para subir los cambios.
 
-### Paso 6: Confirmar
+### Paso 6: Confirmar y crear PR
 
+1. Muestra el resumen del push:
 ```
 === Codigo subido ===
  Rama: [nombre-rama]
  Commit: [hash-corto] [mensaje]
  Remote: origin/[nombre-rama]
+```
+
+2. **Pregunta al usuario** hacia cual rama destino quiere crear el Pull Request. **No sugieras ni asumas** una rama por defecto. Simplemente pregunta:
+```
+Hacia cual rama quieres crear el Pull Request?
+```
 
- Siguiente paso: Crear Pull Request hacia la rama destino.
+3. Una vez el usuario responda, obtén la URL del repositorio remoto con `git remote get-url origin` y determina el hosting para generar el link correcto de creación del PR:
+   - **GitHub** (url contiene `github.com`): `https://github.com/[owner]/[repo]/compare/[rama-destino]...[rama-actual]?expand=1`
+   - **Bitbucket** (url contiene `bitbucket.org`): `https://bitbucket.org/[workspace]/[repo]/pull-requests/new?source=[rama-actual]&dest=[rama-destino]`
+   - Si no se puede determinar el hosting, muestra ambos formatos para que el usuario elija.
+
+   Nota: para URLs SSH (`git@github.com:owner/repo.git` o `git@bitbucket.org:workspace/repo.git`), extrae owner/workspace y repo del path tras el `:`.
+
+4. Muestra el link al usuario:
+```
+ Crea tu PR aqui: [link]
 ```
 
 ## Reglas

package/skills/verify/SKILL.md

@@ -58,13 +58,44 @@ Correcciones necesarias:
 2. [issues de tests]
 ```
 
-### Paso 4: Siguiente paso
+### Paso 4: Resultado y siguiente paso
 
-- Si APROBADO: "Ejecuta `/refacil:review` para el review con checklist del equipo."
-- Si REQUIERE CORRECCIONES: "Corrige los issues listados y ejecuta `/refacil:verify` de nuevo."
+#### Si APROBADO (sin issues CRITICAL ni WARNING):
+
+"Ejecuta `/refacil:review` para el review con checklist del equipo."
+
+#### Si REQUIERE CORRECCIONES (hay issues CRITICAL o WARNING):
+
+Presenta las correcciones necesarias y pregunta al usuario:
+
+```
+RESULTADO: REQUIERE CORRECCIONES
+
+Correcciones necesarias:
+1. [CRITICAL/WARNING] [descripcion del issue y como corregirlo]
+2. [CRITICAL/WARNING] [descripcion del issue y como corregirlo]
+
+Quieres que aplique estas correcciones? (si/no)
+- Si: aplicare los fixes y re-verificare automaticamente
+- No: puedes corregirlos manualmente y ejecutar /refacil:verify de nuevo
+```
+
+**Si el usuario acepta:**
+
+1. Aplica SOLO las correcciones listadas — no agregar funcionalidad nueva, no refactorizar codigo no relacionado, no cambiar nada fuera del alcance de los issues reportados.
+2. Si hay tests que necesitan ajuste por las correcciones, ajustarlos tambien.
+3. Muestra un resumen breve de los archivos modificados.
+4. Re-ejecuta automaticamente la verificacion completa (vuelve al Paso 1) para confirmar que las correcciones resolvieron los issues.
+5. Si la re-verificacion encuentra nuevos issues, repite este ciclo (maximo 2 rondas de correccion automatica). Si despues de 2 rondas aun hay issues, lista los pendientes para correccion manual.
+
+**Si el usuario no acepta:**
+
+Lista los issues para que el usuario los corrija manualmente. Sugiere ejecutar `/refacil:verify` de nuevo cuando termine.
 
 ## Reglas
 
-- NO modificar codigo durante la verificacion
+- Durante la fase de verificacion (Pasos 1-3): NO modificar codigo, solo analizar y reportar
+- Las correcciones SOLO se aplican en el Paso 4, despues del reporte completo y con aprobacion explicita del usuario
+- Las correcciones deben ser quirurgicas: solo lo necesario para resolver los issues reportados
 - Ser estricto con los criterios de la spec
-- Si algo no esta en la spec pero parece necesario, mencionarlo como observacion, no como fallo
+- Si algo no esta en la spec pero parece necesario, mencionarlo como SUGGESTION (observacion), no como CRITICAL/WARNING