---
name: verificacion-evidencia
description: >
  Gate function que impide afirmar éxito sin evidencia verificada. Obliga a ejecutar
  el comando de prueba, leer la salida completa y verificar antes de cualquier
  afirmación positiva. Cargar SIEMPRE al terminar una tarea o slice, antes de
  reportar éxito al usuario o al orquestador.
version: "1.0.0"
herramientasPermitidas: [Read, Write, Edit, Bash, Glob, Grep]
exclusiones:
  - "No cargar como sustituto de `verificar-trabajo` — este skill es el gate de afirmaciones puntuales, no la verificación end-to-end de un plan completo."
  - "No cargar para generar evidencia de métricas de negocio (conversiones, retención); eso requiere datos de analytics, no comandos de build."
  - "No cargar si el usuario pide solo un resumen del estado del plan — leer ESTADO.md directamente es más eficiente."
evolvable: true  # default para skill estandar
---
# Verificación por Evidencia

Ninguna afirmación de éxito es válida sin evidencia fresca obtenida en esta sesión.
El silencio no es éxito. La ausencia de error visible no es éxito. La confianza en
el código no es evidencia. Solo el output del comando ejecutado ahora es evidencia.

## Cuándo cargar este skill

Invoca `Skill("verificacion-evidencia")` cuando:

## Cuándo NO cargar

- Se necesita verificar un plan completo con múltiples artefactos; usar `verificar-trabajo` que aplica los 4 niveles sistemáticamente.
- El usuario pide reportar el estado del PLAN.md — leer ESTADO.md es suficiente, no se necesita ejecutar comandos de verificación.
- Se busca validar que el plan tiene buena estructura antes de ejecutarlo; eso es parte de `planear-fase`.

- Se va a reportar al usuario que una tarea está terminada
- Se va a marcar un slice como completado en el PLAN.md
- Se va a afirmar que los tests pasan, el build compila o el lint está limpio
- Se detecta el impulso de escribir "debería funcionar" o "se ve correcto"
- Un agente termina una fase y va a pasarle el control al siguiente

## La Ley de Hierro

> **NO AFIRMAR ÉXITO SIN EVIDENCIA FRESCA**

Esta ley no tiene excepciones. No importa si:
- El código "se ve correcto"
- Funcionó en el último intento hace 10 minutos
- Es un cambio trivial o de una sola línea
- El agente tiene alta confianza

La evidencia vence a la confianza. Siempre.

## Protocolo de 5 pasos

Antes de cualquier afirmación positiva, ejecutar este protocolo completo:

### Paso 1 — IDENTIFICAR

Responder: ¿qué comando demuestra que esto funciona?

- Tests: `pytest`, `npm test`, `go test ./...`, `cargo test`
- Build: `npm run build`, `cargo build --release`, `mvn package`
- Lint: `ruff check .`, `eslint src/`, `golangci-lint run`
- Type check: `mypy .`, `npx tsc --noEmit`
- Servidor: verificar que responde con `curl` o en el navegador

Si no existe un comando que lo demuestre, la tarea no está terminada.

### Paso 2 — EJECUTAR

Correr el comando completo. No:
- Correr solo un subconjunto de tests
- Usar resultados cacheados
- Omitir flags que estuvieron presentes antes (`--coverage`, `--all-features`)
- Interrumpir el comando antes de que termine

### Paso 3 — LEER

Revisar el output completo:
- Leer hasta el final, no solo las primeras líneas
- Verificar el exit code (0 = éxito, cualquier otro = fallo)
- Buscar WARNINGS que indiquen degradación silenciosa
- Contar: cuántos tests corrieron, cuántos pasaron, cuántos fallaron

### Paso 4 — VERIFICAR

¿El output confirma lo que se va a afirmar?

| Afirmación | Evidencia requerida |
|---|---|
| "Los tests pasan" | Output con `N passed, 0 failed` y exit code 0 |
| "El build compila" | Output de compilación exitosa y exit code 0 |
| "No hay errores de lint" | Output vacío o con solo warnings, exit code 0 |
| "El endpoint responde" | Respuesta HTTP con status 200 y body esperado |
| "La migración aplicó" | Output confirmando tablas/columnas creadas |

### Paso 5 — SOLO ENTONCES AFIRMAR

Con evidencia en mano, afirmar con precisión:

- Mal: "Los tests pasan"
- Bien: "Los tests pasan: 47 passed, 0 failed, 0 errors (pytest 3.2s)"
- Mal: "El build está listo"
- Bien: "Build exitoso: bundle de 234KB en dist/ (npm run build, 8.4s)"

Incluir siempre: resultado numérico + comando usado + tiempo si es relevante.

## Red flags que activan este skill

Detener y aplicar el protocolo si se detecta cualquiera de estos pensamientos:

- "debería funcionar" -> ejecutar para verificar que funciona
- "se ve correcto" -> ejecutar para confirmar que es correcto
- "probablemente pasa" -> ejecutar para saber si pasa
- "es un cambio trivial" -> los cambios triviales también pueden romper cosas
- "funcionó antes" -> el estado actual puede ser diferente al de antes
- "no necesito correr los tests para esto" -> sí necesitas

## Anti-patrones

### Verificación parcial

Correr solo el test del módulo modificado cuando la afirmación es "los tests pasan".
Si la afirmación es parcial, hacerla explícita: "los tests del módulo X pasan".

### Leer output incompleto

Leer solo las primeras líneas del output. Los errores frecuentemente aparecen al final.
Siempre leer hasta el final, especialmente la línea de resumen.

### Silencio como éxito

Asumir que la ausencia de output de error significa éxito. Algunos comandos fallan
silenciosamente. Verificar siempre el exit code.

### Build cacheado

Asumir que el resultado del build anterior sigue siendo válido. Si hubo cambios
desde el último build, correr el build de nuevo.

### Confianza en el modelo mental

Confiar en que se entiende el código lo suficiente para saber que funciona.
El modelo mental puede estar incompleto. La ejecución no miente.

## Gotchas / Errores comunes no obvios

- **Exit code ignorado en favor del output textual**: el comando devuelve "OK" en stdout pero el exit code es 1 (fallo). El agente lee "OK" y afirma éxito. Causa: el Paso 3 no incluye verificación explícita del exit code. Solución: verificar el exit code siempre (`echo $?` o capturar en el Bash tool) — el exit code es la fuente de verdad, no el texto del output.
- **Subset de tests citado como "los tests pasan"**: el agente corre `pytest tests/modulo_nuevo/` y afirma que los tests pasan sin verificar si los tests de otros módulos afectados también pasan. Causa: el Paso 2 dice "no correr solo un subconjunto" pero el agente optimiza por velocidad. Solución: si la afirmación es global ("los tests pasan"), el comando debe ser `pytest` sin filtro de módulo; si es parcial, la afirmación debe ser explícitamente parcial.
- **Output cacheado de build anterior**: en proyectos TypeScript con `tsc`, el compilador puede usar caché y no detectar el error introducido en la sesión actual. Causa: no se pasó `--force` ni se limpió el caché. Solución: para verificación post-cambio usar `npx tsc --noEmit` sin caché, o `rm -rf dist/ && npm run build`.
- **Warning elevado a evidencia de éxito**: el agente cita el output de ruff como evidencia de limpieza pero el output contiene 3 warnings de `W503`. Causa: se confundió "sin errores" con "sin warnings". Solución: definir el umbral antes de ejecutar — si el criterio es "sin warnings", el exit code de ruff con warnings es 1 en modo strict.

## Checklist de verificación

Antes de reportar cualquier éxito:

- [ ] Se identificó el comando que demuestra el éxito
- [ ] El comando se ejecutó completo (no parcial, no cacheado)
- [ ] Se leyó el output hasta el final
- [ ] Se verificó el exit code
- [ ] La afirmación incluye evidencia numérica concreta

---
*Skill creado con swl:crear-skill el 2026-03-31. Versión 1.0.0.*
