refacil-sdd-ai 1.0.8 → 2.0.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "refacil-sdd-ai",
-  "version": "1.0.8",
+  "version": "2.0.1",
   "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

@@ -20,6 +20,31 @@ Este comando envuelve la funcionalidad de OpenSpec apply y agrega las convencion
 
 ## Instrucciones
 
+### Paso 0: Verificar que existan artefactos SDD
+
+Busca carpetas en `openspec/changes/` que contengan los artefactos requeridos: `proposal.md`, `specs.md`, `design.md`, `tasks.md`.
+
+- **Si `openspec/changes/` no existe o esta vacia**: Informa al usuario:
+  ```
+  No hay cambios propuestos. Antes de implementar necesitas definir los artefactos SDD.
+  Ejecuta: /refacil:propose "descripcion del cambio"
+  ```
+  **Detente.**
+
+- **Si hay carpetas pero les faltan artefactos** (falta proposal.md, specs.md, design.md o tasks.md): Informa al usuario:
+  ```
+  El cambio en openspec/changes/[nombre]/ esta incompleto.
+  Faltan: [lista de artefactos faltantes]
+  Ejecuta: /refacil:propose para completar los artefactos antes de implementar.
+  ```
+  **Detente.**
+
+- **Si hay multiples cambios activos**: Lista las carpetas y pregunta cual implementar.
+
+- **Si los 4 artefactos existen**: Continua al siguiente paso.
+
+**IMPORTANTE**: Este comando NUNCA genera artefactos SDD. Si no existen, el usuario debe usar `/refacil:propose`. La separacion entre planificacion e implementacion es fundamental en la metodologia SDD-AI.
+
 ### Paso 1: Validar rama de trabajo
 
 Ejecuta `git branch --show-current` para obtener la rama actual.
@@ -90,5 +115,7 @@ Al terminar la implementacion de OpenSpec, agrega este resumen:
 
 ## Reglas
 
+- NUNCA implementar codigo sin los 4 artefactos SDD completos (proposal.md, specs.md, design.md, tasks.md)
+- NUNCA generar artefactos SDD desde este comando — eso es responsabilidad exclusiva de `/refacil:propose`
 - SIEMPRE leer los artefactos completos antes de escribir codigo
-- Si `openspec/changes/` no tiene cambios activos, informar y sugerir `/refacil:propose`
+- Si `openspec/changes/` no tiene cambios activos o estan incompletos, informar y redirigir a `/refacil:propose`

package/skills/propose/SKILL.md

@@ -82,6 +82,8 @@ Siguiente paso: ejecuta /refacil:apply para implementar las tasks.
 
 ## Reglas
 
-- No implementar codigo en esta fase, solo planificar
-- Siempre explorar el codebase ANTES de generar artefactos
+- **NUNCA escribir, modificar o generar codigo fuente** en esta fase — solo artefactos SDD (proposal.md, specs.md, design.md, tasks.md)
+- Aunque el usuario pase una descripcion completa y detallada en $ARGUMENTS, la salida es EXCLUSIVAMENTE artefactos de planificacion
+- Si el usuario pide que tambien implemente, responder: "La implementacion se hace con `/refacil:apply` despues de aprobar los artefactos."
+- Siempre explorar el codebase ANTES de generar artefactos (para que el design sea realista)
 - Los criterios de aceptacion deben ser especificos y testeables

package/skills/setup/SKILL.md

@@ -33,19 +33,31 @@ Ejecuta `openspec --version 2>&1`.
   - Verificar permisos (puede necesitar `sudo` en Linux/Mac)
   - Verificar que npm global bin esta en el PATH
 
-### Paso 3: Inicializar OpenSpec en el repo
+### Paso 3: Configurar perfil OpenSpec con todos los workflows
 
-Verifica si existe la carpeta `openspec/` en la raiz del proyecto.
+Antes de inicializar, configura el perfil global para garantizar que se instalen TODOS los workflows requeridos:
 
-- Si ya existe: "OpenSpec ya inicializado. OK"
-- Si no existe, ejecuta:
+```bash
+openspec config set profile custom
+openspec config set workflows "explore,new,continue,apply,ff,sync,archive,bulk-archive,verify,onboard"
+```
+
+Verifica que la configuracion quedo correcta:
+```bash
+openspec config list
+```
+
+Debe mostrar `profile: custom` y los 10 workflows listados.
+
+### Paso 4: Inicializar OpenSpec en el repo
+- ejecuta:
   ```bash
   openspec init --tools claude,cursor
   ```
 
 **IMPORTANTE**: `openspec init` tambien instala sus propios comandos (`opsx:*`) en `.claude/` y `.cursor/`. Esto es normal y esperado. Los comandos `opsx:*` de OpenSpec y los `refacil:*` de esta metodologia coexisten sin conflicto. Los `refacil:*` son los que el equipo debe usar — los `opsx:*` son los comandos nativos de OpenSpec que funcionan por debajo.
 
-### Paso 4: Configurar OpenSpec
+### Paso 5: Configurar OpenSpec
 
 Verifica si existe `openspec/config.yaml`.
 
@@ -60,13 +72,13 @@ language: spanish
 
 **Si ya existe**, verifica que tenga `language: spanish`. Si no lo tiene, sugiere agregarlo.
 
-### Paso 5: Generar AGENTS.md
+### Paso 6: Generar AGENTS.md
 
 **Este es el paso mas importante.** Analiza el repositorio automaticamente para generar un `AGENTS.md` personalizado.
 
 Verifica si ya existe `AGENTS.md` en la raiz. Si existe, pregunta al usuario si quiere regenerarlo. Si no quiere, salta este paso.
 
-#### 5.1 Analizar el repositorio
+#### 6.1 Analizar el repositorio
 
 Lee estos archivos si existen (no falles si alguno no existe, simplemente omitelo):
 - `package.json` — nombre, scripts, dependencias (tech stack)
@@ -80,7 +92,7 @@ Lee estos archivos si existen (no falles si alguno no existe, simplemente omitel
 - `Dockerfile` o `docker-compose.yml` — info de deployment
 - `.env.example` — variables de entorno
 
-#### 5.2 Generar el AGENTS.md
+#### 6.2 Generar el AGENTS.md
 
 Con la informacion recopilada, genera un archivo `AGENTS.md` completo. El contenido debe ser en espanol con terminos tecnicos en ingles.
 
@@ -107,7 +119,7 @@ Secciones obligatorias:
    - "Nunca hacer": anti-patrones especificos para el stack
    - "Preguntar primero": cambios de alto impacto que requieren confirmacion
 
-#### 5.3 Fallback si el analisis falla
+#### 6.3 Fallback si el analisis falla
 
 Si por cualquier razon no puedes generar un AGENTS.md completo (archivos no legibles, repo vacio, error inesperado), genera un AGENTS.md minimo con esta estructura:
 
@@ -147,13 +159,32 @@ TODO: Completar con las convenciones del equipo
 
 Informa al usuario que el AGENTS.md fue generado con secciones TODO que debe completar manualmente o ejecutando `/refacil:setup` de nuevo.
 
-#### 5.4 Mostrar al usuario
+#### 6.4 Mostrar al usuario
 
 Muestra el AGENTS.md generado completo. Pregunta si quiere ajustar algo antes de guardarlo.
 
 Si el usuario aprueba (o no tiene cambios), escribe el archivo en la raiz del proyecto.
 
-### Paso 6: Verificar skills
+### Paso 7: Verificar skills
+
+#### 7.1 Verificar skills de OpenSpec
+
+Verifica que existan las 10 carpetas de skills de OpenSpec en `.claude/skills/`:
+- `openspec-apply-change`
+- `openspec-archive-change`
+- `openspec-bulk-archive-change`
+- `openspec-continue-change`
+- `openspec-explore`
+- `openspec-ff-change`
+- `openspec-new-change`
+- `openspec-onboard`
+- `openspec-sync-specs`
+- `openspec-verify-change`
+
+- Si las 10 existen: "Skills OpenSpec: 10/10 instaladas OK"
+- Si faltan algunas: informa cuales faltan. Sugiere ejecutar de nuevo `openspec init --tools claude,cursor` o verificar el perfil con `openspec config list`.
+
+#### 7.2 Verificar skills de Refacil
 
 Verifica que existan las carpetas `.claude/skills/refacil-*` y/o `.cursor/skills/refacil-*`.
 
@@ -172,16 +203,18 @@ Verifica que existan las carpetas `.claude/skills/refacil-*` y/o `.cursor/skills
   Luego reinicia esta sesion de Claude Code / Cursor.
   ```
 
-### Paso 7: Resumen final
+### Paso 8: Resumen final
 
 ```
 === refacil:setup completado ===
- Node.js:        [version] OK
- OpenSpec:        [version] OK
- openspec/:       Inicializado OK
- config.yaml:     Configurado OK
- AGENTS.md:       Generado OK
- Skills Refacil:  [N] instaladas OK
+ Node.js:         [version] OK
+ OpenSpec:         [version] OK
+ Perfil workflows: custom (10 workflows) OK
+ openspec/:        Inicializado OK
+ config.yaml:      Configurado OK
+ AGENTS.md:        Generado OK
+ Skills OpenSpec:  10/10 instaladas OK
+ Skills Refacil:   [N] instaladas OK
 
  IMPORTANTE: Si acabas de instalar las skills por primera vez,
  debes REINICIAR la sesion de Claude Code o Cursor para que

package/skills/test/SKILL.md

@@ -1,18 +1,47 @@
 ---
 name: refacil:test
-description: Generar tests unitarios basados en los artefactos de OpenSpec o para archivos especificos — cubre criterios de aceptacion, edge cases y patrones del equipo
+description: Generar tests unitarios basados en los artefactos de OpenSpec o para archivos especificos — detecta automaticamente el stack y patrones del proyecto
 user-invocable: true
 ---
 
 # refacil:test — Generacion de Tests Unitarios
 
-Eres un asistente de testing que genera pruebas unitarias de alta calidad.
+Eres un asistente de testing que genera pruebas unitarias de alta calidad, adaptandose al stack tecnologico del proyecto.
 
-## Contexto
+## Antes de empezar
 
-Si existe `AGENTS.md` en la raiz del proyecto, leelo para entender las convenciones, arquitectura y patrones.
-Si NO existe `AGENTS.md`, informa al usuario: "No se encontro AGENTS.md. Ejecuta /refacil:setup para generarlo." y detente.
-Lee el archivo [testing-patterns.md](testing-patterns.md) para conocer los patrones de test del equipo.
+### Verificar prerequisitos
+
+1. **OpenSpec instalado**: Ejecuta `openspec --version 2>&1`. Si el comando falla o no se reconoce, informa al usuario: "OpenSpec no esta instalado. Ejecuta `/refacil:setup` para instalarlo y configurar el repositorio." y **detente**.
+
+2. **OpenSpec inicializado**: Verifica que exista la carpeta `openspec/` en la raiz del proyecto. Si no existe, informa al usuario: "OpenSpec no esta inicializado en este repositorio. Ejecuta `/refacil:setup` para configurarlo." y **detente**.
+
+3. **AGENTS.md**: Si existe `AGENTS.md` en la raiz del proyecto, leelo para entender las convenciones, arquitectura y patrones. Si NO existe, informa al usuario: "No se encontro AGENTS.md. Ejecuta `/refacil:setup` para generarlo." y **detente**.
+
+### Detectar stack tecnologico
+
+**IMPORTANTE**: Este skill NO asume ningun stack. Antes de generar tests, detecta automaticamente:
+
+1. **Lenguaje**: Lee `package.json`, `pom.xml`, `build.gradle`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`, o los archivos fuente para determinar el lenguaje principal.
+
+2. **Framework de testing**: Busca la configuracion de tests existente:
+   - JavaScript/TypeScript: `jest.config.*`, `vitest.config.*`, `.mocharc.*`, `karma.conf.*`, seccion `jest` en `package.json`
+   - Python: `pytest.ini`, `pyproject.toml` (seccion `[tool.pytest]`), `setup.cfg`
+   - Java/Kotlin: `pom.xml` (JUnit/Mockito), `build.gradle` (dependencias de test)
+   - Go: archivos `_test.go` existentes
+   - Rust: archivos con `#[cfg(test)]`
+   - Otro: busca archivos de test existentes para inferir patron
+
+3. **Patrones existentes**: Busca tests existentes en el proyecto (`*.spec.*`, `*.test.*`, `test_*`, `*_test.*`) y analiza:
+   - Estructura de archivos (donde se ubican los tests)
+   - Convencion de nombrado
+   - Como se hacen los mocks/stubs
+   - Framework de assertions usado
+   - Setup/teardown patterns
+
+4. **Script de ejecucion**: Identifica como se ejecutan los tests (`npm test`, `pytest`, `go test`, `cargo test`, `mvn test`, etc.)
+
+Si existe [testing-patterns.md](testing-patterns.md) en esta misma carpeta de skill, usalo como **referencia adicional**, pero **siempre prioriza los patrones reales detectados en el proyecto**. Si los patrones del proyecto difieren de testing-patterns.md, sigue los del proyecto.
 
 ## Instrucciones
 
@@ -27,18 +56,18 @@ Si el usuario ejecuta `/refacil:test` sin argumentos:
    - `design.md` — Identificar componentes y archivos creados/modificados
    - `tasks.md` — Identificar archivos implementados
 
-3. **Para cada archivo creado/modificado**, genera un `.spec.ts`:
+3. **Para cada archivo creado/modificado**, genera un test file:
 
-   a. **Analiza el archivo** — Entiende que hace, sus metodos publicos, dependencias
+   a. **Analiza el archivo** — Entiende que hace, sus metodos/funciones publicos, dependencias
    b. **Mapea criterios** — Cada CA-XX y CR-XX del spec = al menos 1 test
-   c. **Agrega edge cases** — null, undefined, valores limite, errores de red
-   d. **Genera el test** — Siguiendo los patrones de [testing-patterns.md](testing-patterns.md)
+   c. **Agrega edge cases** — null/nil/None, valores limite, errores
+   d. **Genera el test** — Siguiendo los patrones detectados del proyecto (lenguaje, framework, estructura, nombrado)
 
-4. **Ejecutar tests**: Corre `npm test` y verifica que pasen.
+4. **Ejecutar tests**: Corre el comando de tests del proyecto y verifica que pasen.
 
 5. **Corregir fallos**: Si hay tests que fallan, analiza y corrige iterativamente.
 
-6. **Reportar coverage**: Ejecuta `npm run test:cov` y reporta:
+6. **Reportar coverage**: Si el proyecto tiene script de coverage, ejecutalo y reporta:
    ```
    === Reporte de Tests ===
     Tests generados: [N] archivos
@@ -52,62 +81,22 @@ Si el usuario ejecuta `/refacil:test` sin argumentos:
 
 ### Modo 2: Tests para archivo especifico (con argumento)
 
-Si el usuario pasa un archivo: `/refacil:test src/mi-servicio.ts`
+Si el usuario pasa un archivo: `/refacil:test src/mi-archivo.ext`
 
 1. **Lee el archivo** especificado ($ARGUMENTS)
-2. **Analiza** sus metodos publicos, dependencias, logica
-3. **Genera** el `.spec.ts` correspondiente
+2. **Analiza** sus metodos/funciones publicos, dependencias, logica
+3. **Genera** el test file correspondiente siguiendo las convenciones del proyecto
 4. **Ejecuta** y corrige hasta que pasen
 
-## Estructura de un test
-
-```typescript
-// archivo.spec.ts
-import { Test, TestingModule } from '@nestjs/testing';
-
-describe('NombreClase', () => {
-  let service: NombreClase;
-
-  beforeEach(async () => {
-    jest.clearAllMocks();
-    const module: TestingModule = await Test.createTestingModule({
-      providers: [
-        NombreClase,
-        { provide: 'DependenciaPort', useValue: mockDependencia },
-      ],
-    }).compile();
-    service = module.get<NombreClase>(NombreClase);
-  });
-
-  describe('nombreMetodo', () => {
-    // Criterios de aceptacion
-    it('should [resultado] when [condicion] (CA-01)', async () => {
-      // Arrange - Mockear dependencias
-      // Act - Ejecutar metodo
-      // Assert - Verificar resultado
-    });
-
-    // Criterios de rechazo
-    it('should throw [error] when [condicion invalida] (CR-01)', async () => {
-      // Arrange - Preparar escenario de error
-      // Act & Assert - Verificar que falla controladamente
-    });
-
-    // Edge cases
-    it('should handle null input gracefully', async () => {
-      // ...
-    });
-  });
-});
-```
-
 ## Reglas
 
+- **NUNCA hardcodear un stack** — siempre detectar del proyecto real
 - Cada criterio de aceptacion (CA-XX) debe tener al menos 1 test
 - Cada criterio de rechazo (CR-XX) debe tener al menos 1 test
 - Coverage minimo del 80% en archivos nuevos
 - Los tests deben ser independientes entre si
 - Mocks minimos y necesarios — no mockear lo que se puede testear directo
-- Nombres descriptivos: `should [verbo] [resultado] when [condicion]`
-- Usar los alias de rutas del proyecto en los imports
-- Los tests deben pasar con `npm test` sin errores
+- Nombres descriptivos segun la convencion del proyecto
+- Usar los alias de rutas/imports del proyecto
+- Los tests deben pasar con el comando de test del proyecto sin errores
+- Ubicar los tests donde el proyecto los espera (misma carpeta, carpeta `test/`, `__tests__/`, etc.)

package/skills/test/testing-patterns.md

@@ -1,150 +1,63 @@
-# Patrones de Testing del Equipo
+# Patrones de Testing — Referencia
 
-## Estructura de archivos de test
-
-```
-archivo.ts          → archivo.spec.ts      (en la misma carpeta)
-mi-servicio.ts      → mi-servicio.spec.ts
-product.mapper.ts   → product.mapper.spec.ts
-```
-
-## Patron para servicios NestJS
-
-```typescript
-import { Test, TestingModule } from '@nestjs/testing';
-import { MiServicio } from './mi-servicio';
-
-// Mocks declarados fuera del describe
-const mockDependencia = {
-  metodo1: jest.fn(),
-  metodo2: jest.fn(),
-};
-
-describe('MiServicio', () => {
-  let service: MiServicio;
-
-  beforeEach(async () => {
-    jest.clearAllMocks();
-
-    const module: TestingModule = await Test.createTestingModule({
-      providers: [
-        MiServicio,
-        { provide: 'DEPENDENCIA_PORT', useValue: mockDependencia },
-      ],
-    }).compile();
-
-    service = module.get<MiServicio>(MiServicio);
-  });
-
-  describe('metodoPublico', () => {
-    it('should [resultado esperado] when [condicion]', async () => {
-      // Arrange
-      mockDependencia.metodo1.mockResolvedValue({ /* datos */ });
-
-      // Act
-      const result = await service.metodoPublico(/* params */);
-
-      // Assert
-      expect(result).toEqual(/* esperado */);
-      expect(mockDependencia.metodo1).toHaveBeenCalledWith(/* params */);
-    });
-  });
-});
-```
+> **NOTA**: Este archivo es una referencia generica. Los tests generados deben seguir
+> los patrones reales del proyecto (detectados automaticamente). Si el proyecto ya tiene
+> tests, esos patrones tienen prioridad sobre los de este archivo.
 
-## Patron para funciones utilitarias (puras)
-
-```typescript
-import { miFuncion } from './mi-util';
-
-describe('miFuncion', () => {
-  it('should [resultado] with valid input', () => {
-    expect(miFuncion('input')).toBe('expected');
-  });
+## Estructura de archivos de test
 
-  it('should handle null input', () => {
-    expect(miFuncion(null)).toBeNull();
-  });
+La ubicacion de los tests depende del proyecto. Patrones comunes:
 
-  it('should handle edge case [X]', () => {
-    expect(miFuncion('')).toBe('default');
-  });
-});
 ```
+# Mismo directorio (comun en JS/TS, Go, Rust)
+archivo.ts          → archivo.spec.ts / archivo.test.ts
+archivo.go          → archivo_test.go
 
-## Patron para mappers
-
-```typescript
-import { MiMapper } from './mi.mapper';
-
-describe('MiMapper', () => {
-  describe('toDomain', () => {
-    it('should map ORM entity to domain entity', () => {
-      const ormEntity = { id: '123', name: 'test', status: 'ACTIVE' };
-      const result = MiMapper.toDomain(ormEntity);
-
-      expect(result.id).toBe('123');
-      expect(result.name).toBe('test');
-      expect(result.status).toBe('ACTIVE');
-    });
-  });
-
-  describe('toOrm', () => {
-    it('should map domain entity to ORM entity', () => {
-      // ...
-    });
-  });
-});
+# Directorio separado (comun en Java, Python, algunos JS/TS)
+src/servicio.java   → test/servicio_test.java
+src/modulo.py       → tests/test_modulo.py
 ```
 
-## Patron para mocks de gRPC
+## Principios universales
 
-```typescript
-const mockGrpcClient = {
-  getService: jest.fn().mockReturnValue({
-    metodoGrpc: jest.fn().mockReturnValue(
-      of({ data: 'response' }) // Observable
-    ),
-  }),
-};
+### Arrange-Act-Assert (AAA)
 ```
-
-## Patron para mocks de BullMQ
-
-```typescript
-const mockQueue = {
-  add: jest.fn().mockResolvedValue({ id: 'job-1' }),
-  getJob: jest.fn(),
-  process: jest.fn(),
-};
+// Arrange — preparar datos y mocks
+// Act — ejecutar la operacion
+// Assert — verificar resultado
 ```
 
-## Patron para mocks de Logger
-
-```typescript
-const mockLogger = {
-  log: jest.fn(),
-  error: jest.fn(),
-  warn: jest.fn(),
-  debug: jest.fn(),
-};
+### Naming conventions
 ```
+# Formato recomendado (adaptar al idioma/framework):
+should [verbo] [resultado] when [condicion]
 
-## Naming conventions
-
-```typescript
-// Formato: should [verbo] [resultado] when [condicion]
-it('should return product request when valid id is provided', () => {});
-it('should throw NotFoundException when product does not exist', () => {});
-it('should update status to SOLD when payment is confirmed', () => {});
-it('should create refund when sale fails after successful topup', () => {});
+# Ejemplos:
+"should return product when valid id is provided"
+"should throw error when input is empty"
+"should update status when payment is confirmed"
 ```
 
 ## Anti-patrones a evitar
 
-- NO testear propiedades privadas directamente
+- NO testear propiedades/metodos privados directamente
 - NO testear implementacion interna (orden de llamadas) a menos que sea critico
-- NO crear tests sin assertions (expect)
+- NO crear tests sin assertions
 - NO crear tests que dependan del orden de ejecucion
-- NO mockear todo — solo los limites del sistema
+- NO mockear todo — solo los limites del sistema (DB, APIs externas, filesystem)
 - NO crear tests fragiles que se rompen con cambios cosmeticos
+- NO duplicar la logica del codigo en el test (el test debe verificar comportamiento, no reimplementar)
+
+## Mocks y Stubs
+
+Mockear solo lo que esta fuera del control del test:
+- Llamadas a bases de datos
+- APIs externas / servicios HTTP
+- Sistema de archivos (si aplica)
+- Colas de mensajes
+- Loggers (cuando interfieren con output)
+
+No mockear:
+- Funciones puras del propio modulo
+- DTOs, mappers, utilidades sin side effects
+- Constantes o configuracion estatica