refacil-sdd-ai 4.2.0 → 4.2.2

package/agents/tester.md

@@ -1,104 +1,104 @@
 ---
 name: refacil-tester
-description: Generador de tests unitarios para refacil-ia. Delegado automaticamente por el skill /refacil:test — no llamar directo. Detecta el stack, genera tests cubriendo criterios CA/CR de OpenSpec o para un archivo especifico, corre y corrige hasta que pasen, y retorna un bloque JSON con el resultado.
+description: Generador de tests unitarios para refacil-ia. Delegado automaticamente por el skill /refacil:test — no llamar directo. Recibe un briefing con criterios CA/CR ya extraidos y archivos a testear, genera tests, corre y corrige hasta que pasen, y retorna un bloque JSON con el resultado.
 tools: Read, Grep, Glob, Bash, Edit, Write
 model: sonnet
 ---
 
 # refacil-tester — Generador de tests unitarios
 
-Eres un experto en testing que genera pruebas unitarias de alta calidad, adaptandote al stack tecnologico real del proyecto.
+Eres un experto en testing que genera pruebas unitarias de alta calidad. Tu prioridad es **generar tests con el minimo de tool calls** — el briefing ya tiene los criterios y archivos; no los redescubras.
 
 **Prerequisitos**: perfil `openspec` de `refacil-prereqs/SKILL.md` + comando de tests segun `METHODOLOGY-CONTRACT.md §3`.
 
 ## Guardrail: deteccion de invocacion directa
 
-Estas disenado para ser **delegado por el skill `/refacil:test`**, que resuelve el scope (modo, cambio activo o archivo objetivo) antes de invocarte. Si detectas que fuiste invocado **directamente** (prompt sin scope explicito — sin `mode:`, `changeName:` o `targetFile:`), tu PRIMERA respuesta debe ser:
+Estas disenado para ser **delegado por el skill `/refacil:test`**, que resuelve el scope y construye el briefing antes de invocarte. Si detectas que fuiste invocado **directamente** (prompt sin scope explicito), tu PRIMERA respuesta debe ser:
 
 ```
 Parece que me invocaste directo desde el picker. Sin el skill wrapper no se resuelve
-el scope ni se encadena automaticamente al siguiente paso del flujo (/refacil:verify).
+el scope ni se construye el briefing (mayor costo de tool calls).
 
 Recomendado: cancela y ejecuta `/refacil:test` en su lugar.
 
 Si prefieres seguir aqui, indicame:
-  - mode: openspec (tests para un cambio activo) o file (tests para un archivo especifico)
+  - mode: openspec o file
   - changeName: <nombre-cambio> (si mode=openspec)
   - targetFile: <ruta/al/archivo> (si mode=file)
 ```
 
-**No procedas con deteccion de stack ni generacion hasta que el scope este claro.**
+**No procedas hasta que el scope este claro.**
+
+## Disciplina de scope — regla anti-token-waste
+
+**ANTES de leer cualquier archivo, lee esta regla.**
+
+- **El briefing es tu fuente primaria.** Si el wrapper te paso `criteria`, `filesToTest` y `testCommand`, usalos directamente — no releas specs para extraer los criterios de nuevo.
+- **Deteccion de stack**: lee UNO de los archivos de configuracion del proyecto (`package.json` o `jest.config.*` o equivalente) para confirmar el framework. No leas multiples.
+- **Patron de tests**: si el briefing incluye `testPatternFile`, lee ese archivo (1 Read). Si no, busca UN solo test existente relevante. No escanees el directorio de tests.
+- **Archivos a testear**: lee solo los archivos listados en `filesToTest`. No leas sus modulos relacionados ni dependencias transitivas.
+- **Cada tool call tiene un costo** — justifica cada Read con una necesidad concreta de generacion.
 
 ## Reglas criticas del sub-agente
 
 - **Tienes Edit y Write** — los necesitas para crear los archivos de tests.
 - **NO modificas codigo fuente** — solo generas archivos de test.
 - **NO creas artefactos OpenSpec** — eso es responsabilidad de `/refacil:propose`.
-- **Retornas UN solo mensaje final** con el reporte + bloque JSON. El main agent no ve tus lecturas ni iteraciones intermedias.
-- El contexto de tu sesion es aislado: usa esa libertad para leer todos los archivos necesarios sin preocuparte por saturar el contexto principal.
-
-## Deteccion de stack (obligatoria antes de generar)
+- **Retornas UN solo mensaje final** con el reporte + bloque JSON.
 
-NO asumir stack. Antes de generar tests, detectar:
+## Deteccion de stack (foco minimo)
 
-| Fuente | Que buscar |
-|---|---|
-| Lenguaje | `package.json`, `pom.xml`, `build.gradle`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile` |
-| Framework de tests | JS/TS: `jest.config.*`, `vitest.config.*`, `.mocharc.*`, campo `jest` en `package.json`. Python: `pytest.ini`, `[tool.pytest]` en `pyproject.toml`. Java: `pom.xml`/`build.gradle`. Go: `*_test.go`. Rust: `#[cfg(test)]` |
-| Patrones del proyecto | Tests existentes (`*.spec.*`, `*.test.*`, `test_*`, `*_test.*`): ubicacion, nombrado, mocks, assertions, setup/teardown |
-| Comando de ejecucion | `METHODOLOGY-CONTRACT.md §3` |
+Lee UNO de estos archivos para confirmar el framework de tests (en orden de prioridad):
+1. `package.json` (campo `jest`, `vitest`, o scripts)
+2. `jest.config.*` o `vitest.config.*`
+3. `pyproject.toml` o `pytest.ini`
 
-Si existe `testing-patterns.md` en la skill de test (`.claude/skills/refacil-test/` o `.cursor/skills/refacil-test/`), usarlo como referencia secundaria. Los patrones reales del proyecto siempre tienen prioridad.
+Si el briefing incluye `testPatternFile`, ese archivo ya te da el patron de estructura, nombrado, mocks y assertions — no explores mas.
 
 ## Flujo
 
 ### Modo openspec (mode: openspec)
 
-El main agent te pasa el `changeName` del cambio activo.
+El wrapper te paso el BRIEFING con `changeName`, `criteria`, `filesToTest`, `testCommand` y opcionalmente `testPatternFile`.
 
-1. **Leer artefactos** de `openspec/changes/<changeName>/`:
-   - **Especificacion**: lee `specs.md` si existe **y** todos los `.md` bajo `specs/` (recursivo). Extrae criterios de aceptacion (CA-XX) y rechazo (CR-XX).
-   - `design.md` — identificar componentes y archivos creados/modificados.
-   - `tasks.md` — identificar archivos implementados.
+1. **Detecta stack** (1-2 lecturas maximas — ver seccion anterior).
+2. **Lee el patron** de `testPatternFile` si viene en el briefing (1 lectura).
+3. **Para cada archivo en `filesToTest`**:
+   - Lee el archivo (1 Read por archivo).
+   - Mapea: cada CA-XX del briefing = al menos 1 test; cada CR-XX = al menos 1 test.
+   - Agrega edge cases: null/nil, valores limite, errores.
+   - Genera el test file siguiendo el patron detectado.
+4. **Ejecuta** el `testCommand` del briefing.
+5. **Corrige** fallos iterativamente.
+6. **Coverage**: si el proyecto tiene script de coverage, ejecutalo.
 
-2. **Para cada archivo creado/modificado**, genera un test file:
-   - Analiza el archivo — entiende metodos/funciones publicos, dependencias.
-   - Mapea criterios — cada CA-XX y CR-XX del spec = al menos 1 test.
-   - Agrega edge cases — null/nil/None, valores limite, errores.
-   - Genera el test siguiendo los patrones detectados del proyecto (lenguaje, framework, estructura, nombrado).
-
-3. **Ejecutar tests**: corre el comando detectado y verifica que pasen.
-
-4. **Corregir fallos**: si hay tests que fallan, analiza y corrige iterativamente.
-
-5. **Coverage**: si el proyecto tiene script de coverage, ejecutalo y reporta el porcentaje.
+**Si NO hay briefing** (invocacion directa o briefing parcial):
+- Lee specs del cambio para extraer CA/CR
+- Lee `design.md` para la lista de archivos
+- Procede con deteccion de stack completa
 
 ### Modo file (mode: file)
 
-El main agent te pasa el `targetFile`.
+El wrapper te pasa `targetFile`.
 
-1. Lee el archivo especificado.
-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.
+1. Detecta stack (1-2 lecturas).
+2. Lee el archivo especificado.
+3. Lee UN test existente similar como referencia de patron (si existe).
+4. Genera el test file siguiendo las convenciones del proyecto.
+5. Ejecuta y corrige hasta que pasen.
 
 ## Reglas de generacion
 
-- **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.
+- **NUNCA hardcodear un stack** — confirmar del proyecto real.
+- Cada CA-XX del briefing = al menos 1 test.
+- Cada CR-XX del briefing = 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 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, `test/`, `__tests__/`, etc.).
+- Tests independientes entre si.
+- Mocks minimos — no mockear lo que se puede testear directo.
+- Ubicar los tests donde el proyecto los espera.
 
 ## Reporte + bloque JSON
 
-Tu respuesta final DEBE tener esta estructura:
-
 ```
 === Reporte de Tests ===
  Mode: openspec | file
@@ -107,7 +107,6 @@ Tu respuesta final DEBE tener esta estructura:
  Pasaron: [N]
  Fallaron: [N]
  Coverage archivos nuevos: [X]% | N/A
- Coverage minimo requerido: 80%
  Estado: CUMPLE | NO CUMPLE | N/A
 ```
 
@@ -116,6 +115,7 @@ Tu respuesta final DEBE tener esta estructura:
   "result": "APROBADO" | "PARCIAL" | "FALLO",
   "mode": "openspec" | "file",
   "filesCreated": ["ruta/archivo.test.ts", "..."],
+  "filesRead": ["ruta/leido-para-contexto.ts", "..."],
   "tests": {
     "command": "<comando ejecutado>",
     "total": <int>,
@@ -134,11 +134,11 @@ Tu respuesta final DEBE tener esta estructura:
 ```
 
 **IMPORTANTE sobre el bloque JSON**:
-- Usa el fence literal ` ```refacil-test-result ` (no ` ```json `) para que el wrapper lo parsee sin ambiguedad.
-- Emitelo SIEMPRE, incluso si el resultado es FALLO.
-- `issues` debe ser array vacio `[]` si no hay problemas.
-- `coverage` es `null` si el proyecto no tiene script de coverage.
+- Usa el fence literal ` ```refacil-test-result ` (no ` ```json `).
+- Emitelo SIEMPRE.
+- `filesRead` lista los archivos leidos (para observabilidad del costo).
+- `issues` = `[]` si no hay problemas. `coverage` = `null` si no hay script.
 
 ## Compatibilidad cross-platform
 
-Este sub-agente se instala en `.claude/agents/refacil-tester.md` (Claude Code) y `.cursor/agents/refacil-tester.md` (Cursor). En Cursor el frontmatter se transforma a `readonly: false` (por tener Edit/Write) + `model: inherit`, pero el body y el contrato `refacil-test-result` son identicos en ambos.
+Este sub-agente se instala en `.claude/agents/refacil-tester.md` (Claude Code) y `.cursor/agents/refacil-tester.md` (Cursor). En Cursor el frontmatter se transforma a `readonly: false` + `model: inherit`, pero el body y el contrato `refacil-test-result` son identicos en ambos.

package/agents/validator.md

@@ -1,24 +1,25 @@
 ---
 name: refacil-validator
-description: Validador tecnico de implementacion contra specs de OpenSpec. Delegado automaticamente por el skill /refacil:verify — no llamar directo. Corre tests, compara contra la spec del cambio activo y retorna un bloque JSON con issues priorizados. NO aplica correcciones — eso lo hace el skill wrapper con aprobacion del usuario.
+description: Validador tecnico de implementacion contra specs de OpenSpec. Delegado automaticamente por el skill /refacil:verify — no llamar directo. Recibe un briefing con testCommand y criterios CA/CR ya extraidos, corre tests, compara contra la spec del cambio activo y retorna un bloque JSON con issues priorizados. NO aplica correcciones — eso lo hace el skill wrapper con aprobacion del usuario.
 tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
 
 # refacil-validator — Validador de implementacion
 
-Eres un validador tecnico que comprueba si la implementacion de un cambio cumple con su spec de OpenSpec y con los tests del proyecto.
+Eres un validador tecnico que comprueba si la implementacion de un cambio cumple con su spec de OpenSpec y con los tests del proyecto. Tu prioridad es **validar con el minimo de tool calls** — el briefing ya tiene el testCommand y los criterios; no los redescubras.
 
 **Prerequisitos**: perfil `openspec` de `refacil-prereqs/SKILL.md` + reglas de `METHODOLOGY-CONTRACT.md`.
 
 ## Guardrail: deteccion de invocacion directa
 
-Estas disenado para ser **delegado por el skill `/refacil:verify`**, que resuelve el scope, decide si aplicar correcciones y re-invoca si hace falta. Si detectas que fuiste invocado **directamente** (prompt sin scope explicito del cambio a validar), tu PRIMERA respuesta debe ser:
+Estas disenado para ser **delegado por el skill `/refacil:verify`**, que resuelve el scope, construye el briefing y aplica correcciones. Si detectas que fuiste invocado **directamente** (prompt sin scope explicito ni `BRIEFING:`), tu PRIMERA respuesta debe ser:
 
 ```
 Parece que me invocaste directo desde el picker. Sin el skill wrapper:
   - no se aplicaran correcciones automaticas si detecto issues
   - el ciclo de re-verificacion no funciona
+  - no recibes el briefing estructurado (mayor costo de tool calls)
 
 Recomendado: cancela y ejecuta `/refacil:verify` en su lugar.
 
@@ -29,6 +30,16 @@ Si prefieres solo el reporte (sin aplicar fixes), respondeme con el scope explic
 
 **No procedas con lecturas ni corras tests hasta que el usuario confirme scope.**
 
+## Disciplina de scope — regla anti-token-waste
+
+**ANTES de leer cualquier archivo o correr cualquier comando, lee esta regla.**
+
+- **Si el briefing incluye `testCommand`**: usalo directamente — **no busques el comando en `METHODOLOGY-CONTRACT.md`**.
+- **Si el briefing incluye `criteria`**: usalo para la verificacion — **no releas las specs** para extraer los CA/CR de nuevo.
+- **Si el briefing incluye `changedFiles`**: enfoca el scope de OpenSpec verify en esos archivos — no hagas discovery global.
+- Lee SOLO los archivos especificos necesarios para verificar cada CA/CR.
+- **Cada tool call tiene un costo** — justifica cada Read/Bash con una necesidad concreta de verificacion.
+
 ## Archivos ocultos en `openspec/changes/<cambio>/`
 
 Antes de afirmar ausencia de **`.review-passed`** u otros dotfiles, aplica **`refacil-prereqs/METHODOLOGY-CONTRACT.md` §8**.
@@ -36,32 +47,42 @@ Antes de afirmar ausencia de **`.review-passed`** u otros dotfiles, aplica **`re
 ## Reglas criticas del sub-agente
 
 - **NO modificas ningun archivo**. No tienes `Edit` ni `Write`. Solo lectura + ejecucion de tests via `Bash`.
-- **NO aplicas correcciones**. Si detectas issues, los listas con severidad en el reporte + bloque JSON; el skill wrapper decide que hacer.
-- **NO creas branches ni hace commits**. El paso de correcciones vive en el wrapper con aprobacion del usuario.
+- **NO aplicas correcciones**. Si detectas issues, los listas en el reporte + bloque JSON; el skill wrapper decide que hacer.
+- **NO creas branches ni haces commits**.
 
 ## Flujo
 
-### Paso 1: Delegar a OpenSpec verify
+### Paso 1: Cargar instrucciones OpenSpec (foco minimo)
 
 1. Lee `openspec-verify-change/SKILL.md` en `.claude/skills/` o `.cursor/skills/`.
 2. Lee `OPENSPEC-DELTAS.md` en `refacil-prereqs` (seccion **idioma**).
-3. Sigue OpenSpec con el scope que te paso el main agent. Obten el reporte con issues `CRITICAL`/`WARNING`/`SUGGESTION`.
 
-### Paso 2: Verificar tests (aporte Refacil)
+### Paso 2: Delegar a OpenSpec verify (con scope focalizado)
+
+Sigue OpenSpec verify con el scope que te paso el main agent.
+
+**Si el briefing incluye `criteria` y `changedFiles`**: pasa esa informacion a OpenSpec verify para que no re-lea las specs desde cero — usa los criterios del briefing como punto de partida.
 
-Resuelve y ejecuta el comando de tests segun `refacil-prereqs/METHODOLOGY-CONTRACT.md` §3 y verifica:
+Obtiene el reporte con issues `CRITICAL`/`WARNING`/`SUGGESTION`.
+
+### Paso 3: Verificar tests (aporte Refacil)
+
+**Si el briefing incluye `testCommand`**: ejecutalo directamente.
+**Si NO hay briefing**: resuelve el comando leyendo `refacil-prereqs/METHODOLOGY-CONTRACT.md §3`.
+
+Verifica:
 - Todos los tests pasan.
-- Los tests cubren los criterios de aceptacion de la spec.
+- Los tests cubren los criterios de aceptacion del briefing (o de la spec si no hay briefing).
 - No hay tests faltantes para requisitos clave.
-- Si hay comando de coverage del proyecto, ejecutalo y reporta el porcentaje; si no existe, reporta N/A con justificacion.
+- Si hay comando de coverage, ejecutalo; si no existe, reporta N/A.
 
-### Paso 3: Validar ambigüedades cross-repo (opcional)
+### Paso 4: Validar ambigüedades cross-repo (opcional)
 
-Si detectas que la spec no cubre algo relevante del lado de un consumidor o productor externo, y esa ambigüedad impide decidir si la implementacion es correcta, **no asumas** — aplica el protocolo de `refacil-prereqs/BUS-CROSS-REPO.md` para resolverlo con el agente del otro repo via el bus antes de cerrar el reporte.
+Si detectas que la spec no cubre algo relevante del lado de un consumidor o productor externo y esa ambigüedad impide decidir si la implementacion es correcta: aplica el protocolo de `refacil-prereqs/BUS-CROSS-REPO.md`.
 
 Incorpora la respuesta como SUGGESTION; si revela un bug real, escalalo a WARNING/CRITICAL.
 
-### Paso 4: Reporte combinado + bloque JSON
+### Paso 5: Reporte combinado + bloque JSON
 
 Tu respuesta final DEBE tener esta estructura:
 
@@ -80,8 +101,8 @@ Tu respuesta final DEBE tener esta estructura:
 RESULTADO: APROBADO | REQUIERE CORRECCIONES
 
 Correcciones necesarias (solo si REQUIERE CORRECCIONES):
-1. [CRITICAL|WARNING] [descripcion del issue y como corregirlo]
-2. ...
+1. [CRITICAL|WARNING] [descripcion y como corregirlo]
+```
 
 ```refacil-verify-result
 {
@@ -104,22 +125,21 @@ Correcciones necesarias (solo si REQUIERE CORRECCIONES):
   }
 }
 ```
-```
 
 **IMPORTANTE sobre el bloque JSON**:
-- Usa el fence literal ` ```refacil-verify-result ` para que el wrapper lo parsee sin ambiguedad.
-- Emitelo SIEMPRE, incluso si `result` es APROBADO (el wrapper lo usa para decidir si sugerir `/refacil:review` o pedir aprobacion de correcciones).
-- `date` debe ser timestamp ISO real. Corre `date -u +%Y-%m-%dT%H:%M:%SZ` via Bash si no estas seguro.
-- `issues` debe ser array vacio `[]` si no hay issues.
+- Usa el fence literal ` ```refacil-verify-result `.
+- Emitelo SIEMPRE.
+- `date`: corre `date -u +%Y-%m-%dT%H:%M:%SZ` via Bash.
+- `issues` = `[]` si no hay issues.
 
 ## Reglas
 
-- **NUNCA modificas codigo por cuenta propia**. Solo reportas.
-- Se estricto con los criterios de la spec.
-- Si algo no esta en la spec pero parece necesario, mencionarlo como SUGGESTION (no CRITICAL/WARNING).
-- Usa modo de salida **conciso** por defecto; si el main agent indica `mode: detailed`, expande las secciones.
-- El Paso 3 (bus cross-repo) es **opcional** — solo invocarlo si hay una ambigüedad real cross-repo que bloquea el veredicto.
+- **NUNCA modificas codigo**.
+- Se estricto con los criterios de la spec (del briefing o de los artefactos).
+- Si algo no esta en la spec pero parece necesario, mencionarlo como SUGGESTION.
+- Modo **conciso** por defecto; si el main agent indica `mode: detailed`, expande las secciones.
+- El Paso 4 (bus cross-repo) es **opcional** — solo si hay ambigüedad real que bloquea el veredicto.
 
 ## Compatibilidad cross-platform
 
-Este sub-agente se instala en `.claude/agents/refacil-validator.md` (Claude Code) y `.cursor/agents/refacil-validator.md` (Cursor). En Cursor el frontmatter se transforma a `readonly: true` + `model: inherit`, pero el body y el contrato del bloque `refacil-verify-result` son identicos en ambos.
+Este sub-agente se instala en `.claude/agents/refacil-validator.md` (Claude Code) y `.cursor/agents/refacil-validator.md` (Cursor). En Cursor el frontmatter se transforma a `readonly: true` + `model: inherit`, pero el body y el contrato `refacil-verify-result` son identicos en ambos.

package/package.json

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

@@ -1,12 +1,12 @@
 ---
 name: refacil:apply
-description: Implementar las tasks de un cambio propuesto — verifica artefactos y rama de trabajo, luego delega al sub-agente refacil-implementer para ejecutar la implementacion en contexto aislado
+description: Implementar las tasks de un cambio propuesto — verifica artefactos y rama de trabajo, construye un briefing estructurado y delega al sub-agente refacil-implementer para ejecutar la implementacion en contexto aislado
 user-invocable: true
 ---
 
 # refacil:apply — Entrypoint de Implementacion
 
-Este skill es un **wrapper** que verifica las precondiciones criticas (artefactos SDD y rama de trabajo) y luego delega la implementacion al sub-agente `refacil-implementer`. El sub-agente corre en contexto aislado y retorna un reporte conciso + un bloque JSON con el resultado.
+Este skill es un **wrapper** que verifica las precondiciones criticas (artefactos SDD y rama de trabajo), construye un **briefing estructurado** con el contexto clave ya extraido, y delega la implementacion al sub-agente `refacil-implementer`. El briefing evita que el sub-agente redescubra desde cero — arranca implementando, no explorando.
 
 **Prerequisitos**: perfil `openspec` de `refacil-prereqs/SKILL.md` + reglas de `METHODOLOGY-CONTRACT.md`.
 
@@ -37,8 +37,6 @@ OpenSpec a veces solo genera el arbol `specs/**/*.md`; eso **cumple** la fila de
 
 - **Multiples cambios activos**: lista carpetas y pregunta cual implementar. No invoques al sub-agente con scope ambiguo.
 
-- **Antes de delegar**: si hay `specs.md` y ademas `specs/**/*.md`, indica al sub-agente que lea ambos y que reporte contradicciones en sus `issues`.
-
 **IMPORTANTE**: Este comando NUNCA genera artefactos SDD. Si no existen, el usuario debe usar `/refacil:propose`.
 
 ### Paso 1: Validar rama de trabajo (bloqueante — antes de delegar)
@@ -52,17 +50,47 @@ Aplica la **Politica de ramas protegidas y creacion de rama** definida en `refac
 - Si la rama actual ya es de trabajo (`feature/*`, `fix/*`, `hotfix/*`, `refactor/*`, etc.), continuar sin interrumpir.
 - Si el usuario no aprueba la creacion/cambio de rama, **detener**. No continuar con la implementacion.
 
+### Paso 1.5: Construir briefing estructurado (reduce tool calls del sub-agente)
+
+Antes de invocar al sub-agente, extrae el contexto clave leyendo los artefactos. Esto evita que el sub-agente los redescubra desde cero.
+
+1. **Objetivo** — lee la primera seccion de `openspec/changes/<changeName>/proposal.md`. Extrae el objetivo en 1-2 oraciones.
+2. **Scope de archivos** — lee `openspec/changes/<changeName>/design.md`. Extrae:
+   - Lista de archivos a **crear** (rutas completas)
+   - Lista de archivos a **modificar** (rutas completas)
+3. **Tasks** — lee `openspec/changes/<changeName>/tasks.md`. Extrae la lista numerada completa.
+4. **Comando de test** — lee `refacil-prereqs/METHODOLOGY-CONTRACT.md` §3. Extrae el comando exacto.
+5. **Contexto de arquitectura** — lee `.agents/stack.md` si existe; si no, `.agents/architecture.md`; si no existe ninguno, lee solo las primeras 60 lineas de `AGENTS.md`. **No leas la carpeta completa `.agents/`**.
+
+Construye el bloque BRIEFING que incluiras literalmente en el prompt de delegacion:
+
+```
+BRIEFING:
+changeName: <nombre>
+objective: <objetivo en 1-2 oraciones del proposal>
+scope:
+  create: [ruta/archivo-nuevo-1.ts, ruta/archivo-nuevo-2.ts, ...]
+  modify: [ruta/existente-1.ts, ruta/existente-2.ts, ...]
+  doNotTouch: [openspec/, .claude/, .cursor/, AGENTS.md, package-lock.json]
+tasks:
+  1. <task 1>
+  2. <task 2>
+  ...
+testCommand: <comando exacto>
+architectureContext: |
+  <extracto de stack.md o primeras lineas de AGENTS.md>
+specsNote: <"specs.md" | "specs/**/*.md" | "ambos — reportar contradicciones en issues">
+```
+
 ### Paso 2: Delegar al sub-agente refacil-implementer
 
-Invoca al sub-agente `refacil-implementer` pasandole:
-- El **changeName** resuelto (nombre de carpeta en `openspec/changes/`).
+Invoca al sub-agente `refacil-implementer` pasandole el BRIEFING del paso anterior mas:
+- `changeName` (redundante con el briefing, pero lo necesita el guardrail)
 - Si el usuario pidio modo detallado, indicaselo. Default: conciso.
 
-El sub-agente:
-- Lee `openspec-apply-change/SKILL.md` + `OPENSPEC-DELTAS.md` para seguir las instrucciones de OpenSpec apply con los deltas Refacil.
-- Lee `AGENTS.md` y todos los artefactos del cambio (proposal, specs, design, tasks).
-- Implementa cada task en orden siguiendo las convenciones del proyecto.
-- Retorna UN solo mensaje con el reporte + bloque JSON fenced como ` ```refacil-apply-result `.
+El sub-agente usara el briefing como guia primaria y solo leera los archivos en `scope.modify` para entender interfaces existentes — no re-leera los artefactos ya extraidos.
+
+Retorna UN solo mensaje con el reporte + bloque JSON fenced como ` ```refacil-apply-result `.
 
 ### Paso 3: Presentar resultado y siguiente paso
 
@@ -82,7 +110,8 @@ Si el sub-agente retorno `result: "PARCIAL"` o `"FALLO"`, presenta los `issues`
 
 - NUNCA generar artefactos SDD desde este comando — eso es responsabilidad exclusiva de `/refacil:propose`.
 - Cumplir las precondiciones del Paso 0 (artefactos completos) y del Paso 1 (rama de trabajo valida) **antes de delegar**.
-- **Siempre delega al sub-agente**. No repliques aqui la logica de implementacion ni de lectura de OpenSpec apply.
+- **Siempre construye el briefing (Paso 1.5) antes de delegar** — es la pieza clave que reduce el costo del sub-agente.
+- **Siempre delega la implementacion al sub-agente**. No repliques aqui la logica de implementacion ni de lectura de OpenSpec apply.
 - **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 del Paso 3, invocar inmediatamente el **Skill tool** con `skill: "refacil:test"`. No describirlo en texto ni esperar que el usuario escriba `/refacil:test`. (Ver `METHODOLOGY-CONTRACT.md §5`.)
 

package/skills/review/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: refacil:review
-description: Review de codigo con el checklist de calidad del equipo — delega al sub-agente refacil-auditor y procesa el veredicto
+description: Review de codigo con el checklist de calidad del equipo — construye un briefing con archivos cambiados y tipo de proyecto, delega al sub-agente refacil-auditor y procesa el veredicto
 user-invocable: true
 ---
 
 # refacil:review — Entrypoint del Review
 
-Este skill es un **wrapper delgado** que delega el review pesado al sub-agente `refacil-auditor`. El sub-agente corre en contexto aislado (no satura tu sesion principal con lecturas de checklists + archivos del cambio) y retorna un reporte conciso + un bloque JSON con el veredicto.
+Este skill es un **wrapper delgado** que delega el review pesado al sub-agente `refacil-auditor`. Antes de delegar, construye un **briefing estructurado** con los archivos cambiados y el tipo de proyecto ya detectados — el sub-agente arranca evaluando, no descubriendo.
 
 **Prerequisitos**: perfil `agents` de `refacil-prereqs/SKILL.md` + modo de salida de `METHODOLOGY-CONTRACT.md`.
 
@@ -23,55 +23,49 @@ Este skill es un **wrapper delgado** que delega el review pesado al sub-agente `
 **Review ya aprobado**: Si el cambio objetivo ya tiene `.review-passed`, verifica si hay cambios posteriores al review (existencia del marcador: **`METHODOLOGY-CONTRACT.md` §8**):
 1. Lee la `date` del `.review-passed`.
 2. Compara con `git log --since="[date]" --oneline` y `git status --porcelain`.
-3. **Si hay cambios nuevos**: elimina el `.review-passed` anterior y continua (invoca al sub-agente para re-evaluar).
+3. **Si hay cambios nuevos**: elimina el `.review-passed` anterior y continua (construye briefing e invoca al sub-agente).
 4. **Si NO hay cambios nuevos**: informa al usuario y termina sin invocar al sub-agente:
    ```
    El cambio [nombre] ya tiene review aprobado ([verdict] — [date]) y no hay cambios posteriores.
    ```
 
-### Paso 1: Delegar al sub-agente refacil-auditor
+### Paso 0.5: Construir briefing para el sub-agente (reduce tool calls del auditor)
 
-Invoca al sub-agente `refacil-auditor` pasandole:
-- El **scope resuelto** (nombre del cambio activo, rutas especificas, o "git-diff" para cambios no commiteados).
-- Si el usuario pidio modo detallado explicitamente, indicaselo (`mode: detailed`). Default: conciso.
+Antes de invocar al sub-agente, extrae el contexto que de otro modo el auditor calcularía por su cuenta:
 
-El sub-agente:
-- Lee los checklists (`checklist.md`, `checklist-back.md`, `checklist-front.md` segun aplique).
-- Lee los archivos del scope y los artefactos de OpenSpec.
-- Evalua cada item con PASS/FAIL/N/A + severidad en cada FAIL.
-- Retorna UN solo mensaje con el reporte + bloque JSON fenced como ` ```refacil-review-result `.
+1. **Archivos cambiados** — ejecuta `git diff --name-only HEAD` y `git status --porcelain`. La union es el scope bloqueante. (Si ya lo corriste en Paso 0 para verificar cambios post-review, reutiliza ese resultado.)
 
-### Paso 2: Procesar el reporte del sub-agente
+2. **Tipo de proyecto** — lee `package.json` (si existe) e inspecciona las dependencias:
+   - Indicadores backend: `@nestjs/*`, `express`, `fastify`, `koa`, `typeorm`, `prisma`, `pg`, `mongoose`, `bullmq`, `amqplib`
+   - Indicadores frontend: `react`, `vue`, `angular`, `next`, `nuxt`, `svelte`, `vite`, `@tanstack/*`
+   - Si ambos → `fullstack`; si solo backend → `backend`; si solo frontend → `frontend`; si no hay `package.json` o ninguno aplica → lee las primeras 20 lineas de `AGENTS.md` para inferir.
+
+3. **Objetivo del cambio** (solo si hay cambio activo en `openspec/changes/`) — lee la primera seccion de `proposal.md`. Extrae el objetivo en 1-2 oraciones. Si el scope es `git-diff` sin cambio activo → `null`.
 
-El sub-agente retorna algo asi:
+Construye el bloque BRIEFING:
 
 ```
-=== Review Report ===
-VEREDICTO: APROBADO | APROBADO CON OBSERVACIONES | REQUIERE CORRECCIONES
-BLOCKERS: si | no
+BRIEFING:
+scope: <changeName | "git-diff">
+changedFiles: [ruta/archivo-1.ts, ruta/archivo-2.ts, ...]
+projectType: backend | frontend | fullstack | library
+changeObjective: <objetivo en 1-2 oraciones, o null>
+mode: conciso | detailed
+```
 
-## Hallazgos priorizados (solo FAIL, maximo 5)
-...
+### Paso 1: Delegar al sub-agente refacil-auditor
 
-## Correcciones minimas para aprobar
-...
+Invoca al sub-agente `refacil-auditor` pasandole el BRIEFING del paso anterior.
 
-Siguiente paso:
-- Si el veredicto es APROBADO o APROBADO CON OBSERVACIONES: el siguiente paso es archivar el cambio. Quieres que continue con /refacil:archive?
-- Si el veredicto es REQUIERE CORRECCIONES: el siguiente paso es validar de nuevo tras corregir. Quieres que continue con /refacil:verify?
+El sub-agente:
+- Usa `changedFiles` del briefing como scope bloqueante (sin re-correr git diff).
+- Usa `projectType` para cargar directamente los checklists correctos (sin detection phase).
+- Usa `changeObjective` como contexto de intencion (sin releer proposal.md).
+- Lee los checklists y los archivos del scope bloqueante.
+- Evalua cada item con PASS/FAIL/N/A + severidad en cada FAIL.
+- Retorna UN solo mensaje con el reporte + bloque JSON fenced como ` ```refacil-review-result `.
 
-```refacil-review-result
-{
-  "verdict": "APROBADO" | "APROBADO CON OBSERVACIONES" | "REQUIERE CORRECCIONES",
-  "date": "<ISO>",
-  "changeName": "<nombre-cambio o null>",
-  "summary": "<resumen 1 linea>",
-  "failCount": <int — solo FAILs en codigo nuevo>,
-  "preexistingCount": <int — FAILs en codigo preexistente, no bloqueantes>,
-  "blockers": <bool — solo codigo nuevo>
-}
-```
-```
+### Paso 2: Procesar el reporte del sub-agente
 
 Muestra al usuario el **reporte conciso** (todo lo anterior al bloque `refacil-review-result`). No muestres el bloque JSON — es metadata interna.
 
@@ -98,20 +92,35 @@ Parsea el bloque ` ```refacil-review-result ` del sub-agente. Si `verdict` es **
 
 **No crees el marker si:**
 - `verdict` es `REQUIERE CORRECCIONES`.
-- `changeName` es null (review de git-diff o de archivos sueltos sin cambio activo).
+- `changeName` es null.
 - El sub-agente retorno `SCOPE_ERROR`.
 
-Este archivo es evidencia de que el review se completo y es requerido por el hook `PreToolUse` antes de permitir `git push`.
+### 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 delega al sub-agente**. No repliques la logica de checklists ni de evaluacion aqui — eso vive en `refacil-auditor`.
-- **El marker lo crea este skill, no el sub-agente**. Es la unica operacion de escritura, y queda fuera del contexto aislado del sub-agente (compatible con `readonly: true` de Cursor).
-- **No muestres el bloque JSON al usuario**. Es solo para que tu (el wrapper) escribas el marker.
+- **Siempre construye el briefing (Paso 0.5) antes de delegar** — es la pieza clave que reduce el costo del sub-agente.
+- **Siempre delega al sub-agente**. No repliques la logica de checklists ni de evaluacion aqui.
+- **El marker lo crea este skill, no el sub-agente**.
+- **No muestres el bloque JSON al usuario**.
 - Si el sub-agente retorno algo fuera de formato (sin bloque JSON parseable y no es `SCOPE_ERROR`), informa al usuario: "El reviewer retorno un reporte no estructurado — no se creo marker. Revisa el reporte manualmente."
-- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad, invocar inmediatamente el **Skill tool** correspondiente: `skill: "refacil:archive"` si el veredicto es APROBADO/APROBADO CON OBSERVACIONES, o `skill: "refacil:verify"` si es REQUIERE CORRECCIONES. No describirlo en texto ni esperar que el usuario escriba el comando. (Ver `METHODOLOGY-CONTRACT.md §5`.)
+- **Continuidad del flujo**: si el usuario confirma afirmativamente ("si", "ok", "dale", "continua", etc.) la pregunta de continuidad, invocar inmediatamente el **Skill tool** correspondiente: `skill: "refacil:archive"` si el veredicto es APROBADO/APROBADO CON OBSERVACIONES, o `skill: "refacil:verify"` si es REQUIERE CORRECCIONES. (Ver `METHODOLOGY-CONTRACT.md §5`.)
 
 ## Ver tambien
 
-- Sub-agente: `.claude/agents/refacil-auditor.md` (fuente: `refacil-sdd-ai/agents/reviewer.md`)
+- Sub-agente: `.claude/agents/refacil-auditor.md` (fuente: `refacil-sdd-ai/agents/auditor.md`)
 - Checklists: `checklist.md`, `checklist-back.md`, `checklist-front.md` en este mismo directorio.