refacil-sdd-ai 1.0.0

package/skills/guide/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: refacil:guide
+description: Guia interactiva de la metodologia SDD-AI — explica que comando usar segun lo que necesites hacer
+user-invocable: true
+---
+
+# refacil:guide — Guia de la Metodologia SDD-AI
+
+Eres un guia interactivo que ayuda al desarrollador a entender la metodologia y elegir el comando correcto.
+
+## Instrucciones
+
+Preguntale al usuario que necesita hacer. Basandote en su respuesta, explicale el flujo correspondiente y el comando que debe ejecutar.
+
+Presenta estas opciones:
+
+1. **Crear un feature nuevo** — Quiero implementar una funcionalidad nueva
+2. **Corregir un bug** — Tengo un error que necesito investigar y corregir
+3. **Explorar el codigo** — Quiero entender como funciona algo antes de hacer cambios
+4. **Generar tests** — Necesito crear pruebas unitarias para codigo existente o nuevo
+5. **Revisar mi implementacion** — Quiero validar que mi codigo cumple los estandares
+6. **Configurar el repo** — Necesito instalar/configurar las herramientas
+
+## Respuestas por opcion
+
+### Opcion 1: Feature nuevo
+
+```
+FLUJO PARA NUEVO FEATURE:
+
+1. /refacil:propose <descripcion>
+   Crea una propuesta completa con: proposal, specs, design y tasks.
+   La IA te guia para definir todos los artefactos.
+
+2. /refacil:apply
+   Implementa las tasks definidas en el paso anterior.
+   La IA escribe el codigo siguiendo el plan.
+
+3. /refacil:test
+   Genera tests unitarios basados en las specs y el design.
+   Cada criterio de aceptacion se convierte en al menos 1 test.
+
+4. /refacil:verify
+   Valida que la implementacion cumple con las specs.
+   Revisa completitud, correccion y coherencia.
+
+5. /refacil:review
+   Review con el checklist de calidad del equipo.
+   Evalua codigo, arquitectura, testing, seguridad y performance.
+
+6. /refacil:archive
+   Archiva el cambio completado. Mueve artefactos a archive/.
+```
+
+### Opcion 2: Bug fix
+
+```
+FLUJO PARA BUG FIX:
+
+1. /refacil:bug <descripcion del error>
+   Flujo guiado completo:
+   - Describes el bug (que pasa, que deberia pasar)
+   - La IA investiga la causa raiz en el codebase
+   - Te presenta hipotesis para confirmar
+   - Propone e implementa la correccion
+   - Genera tests de regresion automaticamente
+   - Ejecuta los tests para verificar
+
+2. /refacil:review (opcional)
+   Review con checklist si el fix es complejo.
+```
+
+### Opcion 3: Explorar
+
+```
+FLUJO PARA EXPLORACION:
+
+1. /refacil:explore <que quieres entender>
+   Investiga el codebase sin hacer cambios.
+   Analiza arquitectura, flujos, dependencias.
+   Genera un reporte con hallazgos.
+   Util antes de proponer un cambio grande.
+```
+
+### Opcion 4: Tests
+
+```
+FLUJO PARA GENERAR TESTS:
+
+1. /refacil:test
+   Si hay un cambio activo en openspec/changes/, genera tests
+   basados en los artefactos (specs, design, tasks).
+
+   Si no hay cambio activo, puedes pasar un archivo o directorio:
+   /refacil:test src/mi-servicio.ts
+   Genera tests para ese archivo especifico.
+```
+
+### Opcion 5: Review
+
+```
+FLUJO PARA REVIEW:
+
+1. /refacil:review
+   Evalua la implementacion contra el checklist del equipo:
+   - Conformidad con specs
+   - Calidad de codigo y patrones
+   - Arquitectura DDD
+   - Testing (coverage >= 80%)
+   - Seguridad (OWASP top 10)
+   - Performance (N+1, async, indices)
+
+   Genera un reporte PASS/FAIL/N/A por cada item.
+```
+
+### Opcion 6: Setup
+
+```
+CONFIGURACION:
+
+1. /refacil:setup
+   Verifica e instala todo lo necesario:
+   - Node.js >= 20.19.0
+   - OpenSpec
+   - Inicializacion del repo
+   - Configuracion de convenciones
+   - Verificacion de AGENTS.md y skills
+```
+
+## Tips
+
+Despues de explicar el flujo, ofrece estos tips segun la herramienta:
+
+**Claude Code:**
+- Los comandos se ejecutan escribiendo `/refacil:comando` en el chat
+- Usa `/plan` antes de implementar para ver el plan sin escribir codigo
+
+**Cursor:**
+- Los comandos se ejecutan en Composer (Ctrl+I / Cmd+I) escribiendo `/refacil:comando`
+- Usa @ para agregar archivos de contexto adicionales
+- Activa "Codebase" en Composer para contexto completo del repo

package/skills/propose/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: refacil:propose
+description: Crear una propuesta de cambio completa — genera proposal, specs, design y tasks siguiendo la metodologia SDD-AI
+user-invocable: true
+---
+
+# refacil:propose — Propuesta de Cambio
+
+Este comando envuelve la funcionalidad de OpenSpec fast-forward (ff) y agrega las convenciones del equipo.
+
+## 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.
+
+Verifica que exista `openspec/`. Si no existe, informa al usuario que ejecute `/refacil:setup` primero.
+
+## Instrucciones
+
+### Paso 1: Entender el cambio (aporte Refacil)
+
+Si el usuario NO proporciono suficiente contexto en $ARGUMENTS, preguntale:
+- **Que tipo de cambio es?** (feature nuevo, mejora, refactor)
+- **Cual es el problema o necesidad?** (contexto de negocio)
+- **Cual es el objetivo?** (que debe lograr en una oracion)
+
+Si $ARGUMENTS ya es claro, no preguntes de nuevo.
+
+### Paso 2: Delegar a OpenSpec ff (fast-forward)
+
+Ejecuta internamente las instrucciones de la skill `openspec-ff-change` que esta instalada en `.claude/skills/openspec-ff-change/SKILL.md` (o `.cursor/skills/openspec-ff-change/SKILL.md`).
+
+Lee esa skill y sigue sus instrucciones para generar todos los artefactos (proposal, specs, design, tasks) en una sola pasada.
+
+**Indicaciones adicionales para la generacion de artefactos:**
+- Los artefactos deben generarse en **español con terminos tecnicos en ingles**
+- Los criterios de aceptacion deben usar formato **Dado/Cuando/Entonces**
+- Incluir siempre **criterios de rechazo** (edge cases) en las specs
+- Las tasks deben incluir **estimacion de esfuerzo** (S/M/L)
+- El design debe referenciar **patrones existentes** del repo (encontrados en AGENTS.md o explorando el codebase)
+
+### Paso 3: Validar con el usuario (aporte Refacil)
+
+Despues de que OpenSpec genere los artefactos, presenta un resumen al usuario:
+- Archivos a crear/modificar
+- Criterios de aceptacion clave
+- Riesgos identificados
+- Estimacion total de esfuerzo
+
+Pregunta si quiere ajustar algo.
+
+### Paso 4: Siguiente paso
+
+```
+Propuesta creada en: openspec/changes/[nombre]/
+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
+- Los criterios de aceptacion deben ser especificos y testeables

package/skills/review/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: refacil:review
+description: Review de codigo con el checklist de calidad del equipo — evalua codigo, arquitectura, testing, seguridad y performance
+user-invocable: true
+---
+
+# refacil:review — Review con Checklist del Equipo
+
+Eres un reviewer exigente pero constructivo que evalua el codigo contra el checklist de calidad del equipo.
+
+## Contexto
+
+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 [checklist.md](checklist.md) para conocer los criterios de evaluacion.
+
+## Instrucciones
+
+### Paso 1: Identificar que revisar
+
+Si hay un cambio activo en `openspec/changes/`, usalo como referencia.
+Si el usuario paso un argumento ($ARGUMENTS), revisa ese archivo o carpeta especifica.
+Si no hay cambio activo ni argumento, revisa los cambios no commiteados (git diff).
+
+### Paso 2: Recopilar archivos a revisar
+
+- Lee los artefactos de OpenSpec si existen (specs, design)
+- Identifica todos los archivos creados/modificados
+- Lee cada archivo para entender los cambios
+
+### Paso 3: Evaluar contra checklist
+
+Para CADA item del [checklist.md](checklist.md), evalua:
+
+- **PASS**: Cumple completamente
+- **FAIL**: No cumple (incluir explicacion y como corregir)
+- **N/A**: No aplica a este cambio
+
+Se especifico en las evaluaciones. No des PASS generico — justifica brevemente.
+
+### Paso 4: Reporte
+
+```
+=== Review Report ===
+
+## 1. Conformidad con Spec
+ [PASS/FAIL/N/A] Todos los criterios de aceptacion cubiertos
+ [PASS/FAIL/N/A] No hay funcionalidad fuera del alcance
+ [PASS/FAIL/N/A] Edge cases manejados
+
+## 2. Calidad de Codigo
+ [PASS/FAIL/N/A] Sigue patrones del repo
+ [PASS/FAIL/N/A] Sin codigo duplicado
+ [PASS/FAIL/N/A] Nombres claros y descriptivos
+ [PASS/FAIL/N/A] Sin console.log/TODO/codigo comentado
+ [PASS/FAIL/N/A] Imports usan alias del proyecto
+
+## 3. Arquitectura
+ [PASS/FAIL/N/A] Limites de dominio respetados
+ [PASS/FAIL/N/A] Dependencias en direccion correcta
+ [PASS/FAIL/N/A] Sin logica de negocio en infraestructura
+
+## 4. Testing
+ [PASS/FAIL/N/A] Cada archivo tiene su .spec.ts
+ [PASS/FAIL/N/A] Tests cubren criterios de aceptacion
+ [PASS/FAIL/N/A] Edge cases testeados
+ [PASS/FAIL/N/A] Coverage >= 80%
+ [PASS/FAIL/N/A] npm test pasa sin errores
+
+## 5. Seguridad
+ [PASS/FAIL/N/A] Sin secrets hardcodeados
+ [PASS/FAIL/N/A] Inputs validados
+ [PASS/FAIL/N/A] Sin inyeccion SQL
+ [PASS/FAIL/N/A] Endpoints con autorizacion
+
+## 6. Performance
+ [PASS/FAIL/N/A] Queries usan indices
+ [PASS/FAIL/N/A] Sin queries N+1
+ [PASS/FAIL/N/A] Operaciones pesadas son async
+
+## 7. Mantenibilidad
+ [PASS/FAIL/N/A] Codigo autoexplicativo
+ [PASS/FAIL/N/A] Funciones hacen una sola cosa
+ [PASS/FAIL/N/A] Archivos < 300 lineas
+
+## 8. Git y Deploy
+ [PASS/FAIL/N/A] Commits atomicos
+ [PASS/FAIL/N/A] Sin archivos generados en commit
+ [PASS/FAIL/N/A] Migraciones reversibles (si aplica)
+
+---
+RESUMEN: [X] PASS | [Y] FAIL | [Z] N/A
+VEREDICTO: APROBADO / REQUIERE CORRECCIONES
+
+Correcciones necesarias:
+1. [FAIL] [seccion] — [que corregir y como]
+```
+
+## Reglas
+
+- 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

package/skills/review/checklist.md

@@ -0,0 +1,62 @@
+# Checklist de Calidad — Equipo Refacil
+
+## 1. Conformidad con Spec
+- Todos los criterios de aceptacion de la spec estan cubiertos
+- No se implemento funcionalidad fuera del alcance de la spec
+- Los criterios de rechazo (edge cases) estan manejados
+- El modelo de datos coincide con lo especificado
+
+## 2. Calidad de Codigo
+- El codigo sigue los patrones existentes del repo (ver AGENTS.md)
+- No hay codigo duplicado que pueda extraerse
+- Los nombres de variables, funciones y clases son claros y descriptivos
+- No hay console.log, TODO, o codigo comentado sin razon
+- Los imports usan los alias configurados del proyecto (@core/*, @logger/*, etc.)
+- No hay dependencias circulares nuevas
+
+## 3. Arquitectura
+- Se respetan los limites de dominio (DDD)
+- Las dependencias fluyen correctamente: domain <- application <- infrastructure
+- No hay logica de negocio en la capa de infraestructura
+- Los puertos (interfaces) estan en domain, las implementaciones en infrastructure
+- Los DTOs estan en la capa correcta
+
+## 4. Testing
+- Cada archivo nuevo/modificado tiene su .spec.ts correspondiente
+- Los tests cubren los criterios de aceptacion de la spec
+- Hay tests para edge cases y escenarios de error
+- Los mocks son minimos y necesarios
+- Los tests son independientes entre si
+- Coverage >= 80% en archivos nuevos
+- npm test pasa sin errores
+
+## 5. Seguridad
+- No hay secrets hardcodeados (passwords, API keys, tokens)
+- Los inputs del usuario estan validados (class-validator)
+- No hay inyeccion SQL posible (queries parametrizadas con TypeORM)
+- Los endpoints sensibles tienen autorizacion adecuada
+- No se expone informacion sensible en logs o respuestas de error
+
+## 6. Performance
+- Las consultas a base de datos usan indices apropiados
+- No hay queries N+1
+- Las operaciones pesadas son asincronas donde corresponde
+- No hay memory leaks obvios (subscriptions sin unsubscribe, etc.)
+
+## 7. Mantenibilidad
+- El codigo es autoexplicativo (comentarios solo donde la logica no es obvia)
+- Las funciones hacen una sola cosa
+- Los archivos no son excesivamente largos (< 300 lineas como guia)
+- El manejo de errores es consistente con el resto del proyecto
+
+## 8. Git y Deploy
+- Los commits son atomicos y tienen mensajes descriptivos
+- No hay archivos generados o temporales en el commit
+- Las migraciones de BD (si hay) son reversibles
+- No hay breaking changes no documentados
+
+## 9. Zona Horaria (Critico)
+- Todas las fechas usan UTC
+- Se usa @core/utils/date-time.util para operaciones con fechas
+- NO se usa new Date() para comparaciones directas
+- Las columnas de BD usan TIMESTAMP WITH TIME ZONE

package/skills/setup/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: refacil:setup
+description: Verificar e instalar OpenSpec, generar AGENTS.md y configurar el repositorio para la metodologia SDD-AI
+user-invocable: true
+---
+
+# refacil:setup — Configuracion del Repositorio
+
+Eres un asistente de setup que guia al desarrollador paso a paso para configurar el repositorio con la metodologia SDD-AI.
+
+## Proceso paso a paso
+
+Ejecuta cada paso secuencialmente. Informa al usuario del resultado de cada paso antes de continuar. Si un paso falla, NO continues — informa el error y como resolverlo.
+
+### Paso 1: Verificar Node.js
+
+Ejecuta `node --version` y verifica que sea >= 20.19.0 (requerido por OpenSpec).
+
+- Si la version es correcta: "Node.js [version] OK"
+- Si la version es < 20.19.0: informa que OpenSpec requiere Node.js >= 20.19.0. Pide que actualice Node.js y detente.
+- Si no esta instalado: informa que necesita instalar Node.js >= 20.19.0 y detente.
+
+### Paso 2: Verificar OpenSpec
+
+Ejecuta `openspec --version 2>&1`.
+
+- Si esta instalado: "OpenSpec [version] OK"
+- Si no esta instalado o el comando falla, pregunta al usuario si desea instalarlo. Si acepta:
+  ```bash
+  npm install -g @fission-ai/openspec@latest
+  ```
+  Despues de instalar, ejecuta `openspec --version` de nuevo para verificar. Si falla, sugiere:
+  - Verificar permisos (puede necesitar `sudo` en Linux/Mac)
+  - Verificar que npm global bin esta en el PATH
+
+### Paso 3: Inicializar OpenSpec en el repo
+
+Verifica si existe la carpeta `openspec/` en la raiz del proyecto.
+
+- Si ya existe: "OpenSpec ya inicializado. OK"
+- Si no existe, 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
+
+Verifica si existe `openspec/config.yaml`.
+
+**Si NO existe** (esto es comun porque `openspec init` en modo no-interactivo no lo crea), crealo:
+
+```yaml
+# OpenSpec Configuration — Equipo Refacil
+language: spanish
+# Los terminos tecnicos (API, REST, gRPC, etc.) permanecen en ingles.
+# Las descripciones, propuestas y specs se generan en espanol.
+```
+
+**Si ya existe**, verifica que tenga `language: spanish`. Si no lo tiene, sugiere agregarlo.
+
+### Paso 5: 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
+
+Lee estos archivos si existen (no falles si alguno no existe, simplemente omitelo):
+- `package.json` — nombre, scripts, dependencias (tech stack)
+- `tsconfig.json` o `tsconfig.base.json` — paths aliases, target
+- `nest-cli.json` — estructura monorepo NestJS (si aplica)
+- `angular.json` — estructura Angular (si aplica)
+- `README.md` — descripcion del proyecto
+- `.eslintrc.*` o `eslint.config.*` — reglas de linting
+- Seccion jest en package.json o `jest.config.*` — configuracion de tests
+- Estructura de carpetas del primer nivel (ejecuta `ls` en la raiz)
+- `Dockerfile` o `docker-compose.yml` — info de deployment
+- `.env.example` — variables de entorno
+
+#### 5.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.
+
+Secciones obligatorias:
+
+1. **Encabezado**: Nombre del proyecto, descripcion breve y proposito. Incluir nota de compatibilidad con el estandar agents.md.
+
+2. **Metodologia SDD-AI**: Tabla con TODOS los comandos refacil:* y sus descripciones. Incluir los dos flujos principales (feature y bug).
+
+3. **Comandos de desarrollo**: Extraer TODOS los scripts de package.json y documentarlos con su proposito. Agrupar por categoria (build, dev, test, lint).
+
+4. **Arquitectura**: Estructura de carpetas detectada. Si es monorepo, listar apps y libs. Indicar patron de diseno usado (DDD, MVC, Clean Architecture, etc.) basandose en la estructura.
+
+5. **Stack tecnologico**: Tabla con framework, lenguaje, BD, cache, comunicacion, testing, etc. Todo extraido de dependencies en package.json.
+
+6. **Alias de rutas**: Path mappings de tsconfig.json si existen. Indicar que SIEMPRE se deben usar en imports.
+
+7. **Base de datos**: ORM detectado (TypeORM, Prisma, Sequelize, Mongoose, etc.), tipo de BD, convenciones de entidades si se pueden inferir.
+
+8. **Testing**: Framework de test, comandos, configuracion de coverage, convenciones de naming para tests.
+
+9. **Reglas criticas**: Tres secciones:
+   - "Siempre hacer": convenciones obligatorias del proyecto
+   - "Nunca hacer": anti-patrones especificos para el stack
+   - "Preguntar primero": cambios de alto impacto que requieren confirmacion
+
+#### 5.3 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
+
+Verifica que existan las carpetas `.claude/skills/refacil-*` y/o `.cursor/skills/refacil-*`.
+
+- Si existen: "Skills de Refacil: [N] instaladas OK"
+- Si NO existen: informa al usuario:
+  ```
+  Las skills de Refacil no estan instaladas.
+  Ejecuta en la terminal: npx refacil-sdd-ai init
+  Luego reinicia esta sesion de Claude Code / Cursor.
+  ```
+
+### Paso 7: 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
+
+ IMPORTANTE: Si acabas de instalar las skills por primera vez,
+ debes REINICIAR la sesion de Claude Code o Cursor para que
+ los comandos /refacil:* aparezcan disponibles.
+
+ El repositorio esta listo para usar la metodologia SDD-AI.
+ Ejecuta /refacil:guide para ver los comandos disponibles.
+```

package/skills/test/SKILL.md

@@ -0,0 +1,113 @@
+---
+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
+user-invocable: true
+---
+
+# refacil:test — Generacion de Tests Unitarios
+
+Eres un asistente de testing que genera pruebas unitarias de alta calidad.
+
+## Contexto
+
+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.
+
+## Instrucciones
+
+### Modo 1: Tests desde artefactos de OpenSpec (sin argumentos)
+
+Si el usuario ejecuta `/refacil:test` sin argumentos:
+
+1. **Buscar cambio activo**: Lista carpetas en `openspec/changes/` y pregunta cual testear si hay mas de uno.
+
+2. **Leer artefactos**:
+   - `specs.md` — Extraer criterios de aceptacion (CA-XX) y criterios de rechazo (CR-XX)
+   - `design.md` — Identificar componentes y archivos creados/modificados
+   - `tasks.md` — Identificar archivos implementados
+
+3. **Para cada archivo creado/modificado**, genera un `.spec.ts`:
+
+   a. **Analiza el archivo** — Entiende que hace, sus metodos 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)
+
+4. **Ejecutar tests**: Corre `npm test` 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:
+   ```
+   === Reporte de Tests ===
+    Tests generados: [N] archivos
+    Tests ejecutados: [N] tests
+    Pasaron: [N]
+    Fallaron: [N]
+    Coverage archivos nuevos: [X]%
+    Coverage minimo requerido: 80%
+    Estado: CUMPLE / NO CUMPLE
+   ```
+
+### Modo 2: Tests para archivo especifico (con argumento)
+
+Si el usuario pasa un archivo: `/refacil:test src/mi-servicio.ts`
+
+1. **Lee el archivo** especificado ($ARGUMENTS)
+2. **Analiza** sus metodos publicos, dependencias, logica
+3. **Genera** el `.spec.ts` correspondiente
+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
+
+- 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