---
type: SPEC
asset_id: SPEC-XX-BMF-SkillValidator-v01
version: v01
status: Draft · diseño fino (Opus in-room) · para ratificación Victor (L3+) y construcción
owner: Victor Heredia
sherpa: Jay
ratificador: Victor Heredia
implementa: Jay/Alex (skill-creator)
intellibank: IB-XX-Maestro
subbank: IPI-XX-IP-Infraestructura / IPI-XX-BMF-Engine
proposito: >
  Especificación construible de sk-skillvalidator — el validador/auditor de skills de EmpowerLabs:
  filtra, evalúa y checa cualquier skill/plugin (sintaxis, seguridad, calidad+eval) en el alta y en
  la auditoría. Extiende sk-ibhealth/sk-wikivalidator y envuelve el eval de skill-creator. Diseño fino
  informado por el benchmark MI-XX-BMF-EcosistemaSkills-Benchmark-v01.
relacionado:
  - PLAN-XX-BMF-EcosistemaSkills-v02 (proceso §3) · MI-XX-BMF-EcosistemaSkills-Benchmark-v01 (fundamento)
  - CP-EL-SkillsRegistry-v01 (registro que alimenta) · SOP-EL-SkillsAlta-v01 (alta)
  - sk-ibhealth (auditoría salud) · sk-wikivalidator (DRIFT/links) · skill-creator (eval)
gate_g0: PASS — deriva del plan v02 y del benchmark citado
fecha_creacion: 2026-07-11
tags: [SPEC, sk-skillvalidator, validacion, seguridad, eval-gate, auditoria, tool-poisoning, registro]
---

# SPEC · sk-skillvalidator
## El validador/auditor de skills — filtra, evalúa y checa lo que no está bien

> **Nota de modelo.** Diseño fino producido **en este room con Opus** (apto para arquitectura de spec y, por regla WORX, el modelo validador). Si quieres la variante generada por el modelo **Fable**, el pack está listo para correr en un room con Fable — este SPEC ya sirve como su brief.

> **Qué es.** La skill que responde tu punto del outline: *"skill especializado para filtrar, evaluar y checar cualquier cosa que no esté bien — cuál es el proceso y cómo se invoca"*. Se invoca en **dos momentos**: en el **alta** de una skill (gate de promoción entre carriles) y en la **auditoría** periódica del ecosistema. **Extiende** `sk-ibhealth`/`sk-wikivalidator` y **envuelve** el eval de `skill-creator` — no reinventa nada.

---

## 1. Invocación
- `/sk-skillvalidator {ruta-de-skill}` → valida una skill (alta / pre-promoción).
- `/sk-skillvalidator --audit {dominio|todo}` → auditoría de un dominio o de todo el ecosistema.
- Disparadores: "valida esta skill", "checa que esté bien", "audita las skills", "¿esta skill puede subir a equipo?", "pre-promoción".
- **Gate de carril:** L0→L1 exige PASS de bloques A+B; L1→L2/L3 exige además PASS del bloque C (eval) + ratificación de owner de dominio (HITL).

## 2. Los 3 bloques de validación

### Bloque A · Estructura (determinista · esquema cerrado)
Del benchmark: rechazar propiedades desconocidas, no ignorarlas.
- Frontmatter YAML válido; **solo claves permitidas** (`name, description` + opcionales `metadata, license`); cualquier clave extra = FAIL.
- `name`: kebab-case, ≤64 chars, sin guion inicial/final, **= nombre de carpeta** (case-sensitive), prefijo válido (`sk-{dominio}-…` o `wx-…`), dominio de la lista cerrada (`dg·mx·px·tx·gov`).
- `description`: no vacía, ≤1024 chars, **3ª persona con "Usar cuando…"** (es el contrato de disparo); marcar si no trae gatillos concretos.
- **Regla limpia:** sin ángulos `<>` en el body (el validador los lee como XML) — usar `{llaves}`.
- **Compacta:** `SKILL.md` <500 líneas; `references/` **exactamente un nivel** de profundidad; detalle pesado fuera del body.
- Naming BMF válido + tripleta (Owner·Sherpa·Ratificador) presente.

### Bloque B · Seguridad (escaneo · least-privilege)
Del benchmark (OWASP MCP Top 10 · tool-poisoning · supply-chain):
- **Secretos filtrados:** tokens, API keys, credenciales en el body o en scripts bundled → FAIL.
- **Firmas de tool-poisoning / inyección:** "ignora las instrucciones previas", instrucciones ocultas en metadata, unicode/whitespace smuggling, URLs de exfiltración → FLAG/FAIL.
- **Least-privilege:** permisos/tools/MCP declarados vs. propósito real de la skill; permisos sobre-amplios → FLAG. Registrar la **clase de permiso** por operación: `read / draft / recommend / low-risk-execute / high-risk-execute`.
- **Integridad:** al publicar, generar **hash (sha256)** del bundle (content-addressed, no puntero mutable).
- "Verified = identidad, no código": **re-escanear en cada update** (el rug-pull ocurre después de aprobar).

### Bloque C · Calidad + Eval (envuelve skill-creator)
Del benchmark ("un gate que solo puede dar PASS es teatro"):
- **Envuelve el eval de `skill-creator`:** corre la batería **3× por caso** + **split 60/40 held-out**; mide **lift** (con-skill vs sin-skill), no memorización. Exige **≥3 evals** por skill.
- **Rúbrica de calidad** (score, no solo PASS/FAIL): claridad de naming, disparabilidad de la description, presencia de "cuándo usar", cero referencias muertas / WikiLinks rotos, valor×esfuerzo.
- **Fixtures rojos:** el validador mantiene un set de **skills-mal-conocidas** (envenenadas, mal-nombradas); si el gate no las reprueba, el gate está roto → alerta.

## 3. Modo auditoría (extiende, no duplica)
- Reusa `sk-ibhealth` (duplicados, rutas muertas, copias rogue) y `sk-wikivalidator` (DRIFT contra versiones superadas, links).
- Añade: **cadencia trimestral** + **trigger por cambio material** (nueva tool/dato/MCP en una skill → re-validación + re-clasificación automática).
- Salida: reporte de salud del ecosistema (skills por estado/dominio/dueño, violaciones abiertas, huérfanas, deprecables).

## 4. Salida (siempre)
```
VALIDACION {ruta o dominio}
- Bloque A (estructura): PASS/FAIL  {hallazgos}
- Bloque B (seguridad):  PASS/FLAG/FAIL  {hallazgos + clase de permiso}
- Bloque C (calidad+eval): score {n}/100 · lift {±%} · evals {n}
VEREDICTO: [Apto L1 | Apto L2/L3 (req. HITL owner) | Rechazado {motivo}]
REGISTRO: entrada propuesta para CP-EL-SkillsRegistry (campos §5)
```

## 5. Esquema del Registro que alimenta (2 capas)
Del benchmark (manifiesto autor + proyección registro):
- **Capa autor (fuente de verdad, junto a la skill):** `id · version(SemVer) · owner · description · triggers · dominio · dependencies · permisos(clase) · estado(L0/L1/L2-3)`.
- **Capa registro (proyección, la agrega el sistema, el autor NO):** `status(activo/deprecado) · verificado · hash sha256 · última-validación · eval-score · uso`.
> `CP-EL-SkillsRegistry` se actualiza a este esquema; el marketplace se deriva de la capa registro, nunca al revés.

## 6. Gobernanza
- Autonomía: **L1** (valida y reporta) en alta; **L2** propone deprecación; **borrar/retirar = L3** (Victor).
- Tripleta del propio validador: Owner Victor · Sherpa Jay · Ratificador Victor.
- HITL en promoción L1→L2/L3 (owner de dominio ratifica) — piso EU AI Act Art. 14.

## 7. Construcción (buildable)
- Construir con `skill-creator` (Create) — es una skill más, dogfooding.
- Bloque A = scripts deterministas (parse YAML, checks). Bloque B = escaneo (regex + heurística de inyección + diff de permisos). Bloque C = wrapper del eval de skill-creator.
- Reusar los scripts de `sk-ibhealth`/`sk-wikivalidator` para el modo auditoría.
- Eval-gate del propio validador: los **fixtures rojos** son su batería.

## 8. NEXTs
- [ ] Ratificar esta SPEC (Victor L3+).
- [ ] Construir `sk-skillvalidator` con skill-creator (bloques A/B/C).
- [ ] Actualizar `CP-EL-SkillsRegistry` al esquema de 2 capas (§5).
- [ ] Conectar como gate en `SOP-EL-SkillsAlta` (promoción entre carriles).
- [ ] Semilla de **fixtures rojos** (skills-mal-conocidas) para probar el gate.

## CHANGELOG
| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-11 | Diseño fino (Opus in-room). 3 bloques (estructura esquema-cerrado · seguridad tool-poisoning/least-privilege · calidad+eval envolviendo skill-creator con fixtures rojos), modo auditoría que extiende sk-ibhealth/sk-wikivalidator, esquema de Registro de 2 capas y gobernanza por carriles. Informado por el benchmark citado. |