@saulwade/swl-ses 1.0.0

package/habilidades/meta-skills-estandar/SKILL.md

@@ -0,0 +1,298 @@
+---
+name: meta-skills-estandar
+description: >
+  Referencia extendida del estándar de skills SWL. Complementa la regla
+  obligatoria `reglas/skills-estandar.md` con: Response Discipline,
+  Anti-substitution Guardrails, campo dual `herramientasPermitidas`/
+  `allowed-tools`, nivel de control de instrucciones, reglas detalladas
+  para scripts/ y recursos/, y recursos/ con anti-patrones, leyes de diseño,
+  idiomas de framework y mapeo a frameworks de seguridad. Cargar cuando se
+  esté escribiendo o auditando un SKILL.md y se necesiten patrones avanzados
+  que no están en la regla core.
+version: "1.0.0"
+herramientasPermitidas: [Read, Write, Edit]
+exclusiones:
+  - "No cargar si solo se necesita el frontmatter obligatorio, el límite de líneas o la estructura de directorio — eso está en la regla core `reglas/skills-estandar.md` que se carga siempre."
+  - "No cargar para crear un skill simple de dominio conceptual sin comandos prescritos ni herramientas específicas — las reglas core bastan."
+  - "No cargar para consultar el checklist de auditoría, la convención de naming o el proceso de creación — los tres viven en la regla core."
+  - "No cargar para skills fuera del dominio seguridad — el mapeo a frameworks (NIST, MITRE) solo aplica al dominio seguridad."
+evolvable: true
+---
+
+# meta-skills-estandar — Referencia extendida del estándar de skills
+
+Complementa la regla `reglas/skills-estandar.md` con detalles, ejemplos y
+tablas que no son estrictamente obligatorios para cualquier skill pero sí
+son referencia crítica cuando aplican. Separar este contenido de la regla
+core reduce el costo de contexto por sesión ~7,000 tokens cuando no se
+escriben skills activamente.
+
+## Cuándo cargar
+
+- Al escribir un skill nuevo cuya descripción prescribe comandos, snippets
+  o verdicts específicos → Response Discipline + Anti-substitution.
+- Al auditar un skill existente contra leyes de diseño de alta señal.
+- Al escribir skills de framework específico (FastAPI, Django, NestJS,
+  Spring Boot) que requieren patrones idiomáticos.
+- Al agregar mapeos de seguridad (NIST, MITRE) al frontmatter.
+- Al configurar el campo dual `herramientasPermitidas` / `allowed-tools`.
+- Al migrar skills viejos a nombres de campo en español.
+- Al diagnosticar falsos positivos del evaluador `evaluar-skill`.
+
+## Cuándo NO cargar
+
+- Solo se necesita frontmatter obligatorio o estructura de directorio.
+- Se consulta el checklist de auditoría (vive en la regla core).
+- Skill sin comandos prescritos ni herramientas específicas.
+- Skill fuera del dominio seguridad → no necesita mapeo a frameworks.
+
+---
+
+## Nivel de control de instrucciones
+
+Calibrar la especificidad de las instrucciones según el costo de error:
+
+| Nivel | Cuándo usar | Técnica |
+|-------|-------------|---------|
+| Alto (libertad máxima) | Code review, texto, análisis | Objetivos + restricciones, sin pasos |
+| Medio | Runbooks, deploys | Preferencias explícitas, pasos sugeridos |
+| Bajo (control máximo) | Migraciones BD, operaciones destructivas | Pasos exactos, scripts precisos, sin variación |
+
+Skills de nivel bajo DEBEN incluir:
+- Checklist de ejecución progresiva (no solo verificación post-hoc).
+- Sección Known Gotchas con modos de falla concretos.
+- Preferentemente un script en `scripts/` que ejecute la operación determinista.
+
+El tono del skill (persona al inicio, si la hay) también es un control:
+establece la rúbrica de juicio del modelo.
+
+---
+
+## Response Discipline (OBLIGATORIO para skills de comando)
+
+Aplica a skills cuyo producto principal es un comando, snippet o verdict
+token (ej: `swl-markitdown`, `dbml-experto`, `likec4-experto`). **No aplica**
+a skills de dominio conceptual (patrones, testing, seguridad).
+
+### Reglas
+
+1. **Command-first / snippet-first**. Si el prompt pide `"minimal"`, `"strict"`,
+   `"exact"`, `"paste-ready"` o una línea específica: responde con un solo
+   comando/snippet/verdict como primera línea, sin preámbulo ni alternativas.
+2. **Una sola respuesta canónica**. No dar "opción A vs opción B" en prompts
+   strict.
+3. **Primera línea es autoridad**. Si el prompt requiere un token específico
+   (`VALIDATE OK`, `npx X`), esa es la primera línea. Explicación después.
+4. **Prose-only es falla** cuando se pide snippet/comando. Una explicación
+   sin el comando exacto es incorrecta aunque el contenido sea acertado.
+5. **Documentar el patrón** con sección `## Response Discipline` listando qué
+   keywords activan respuesta estricta en ese dominio.
+
+### Ejemplo
+
+Prompt: *"Minimal command to validate schema.dbml strictly."*
+
+MAL: *"Para validar un esquema DBML puedes usar varias opciones..."*
+BIEN: `npx @dbml/cli validate schema.dbml --strict`
+
+---
+
+## Anti-substitution Guardrails (OBLIGATORIO para skills que prescriben herramientas)
+
+Las skills que prescriben comandos, flags o APIs DEBEN listar sustituciones
+prohibidas más comunes para prevenir que el LLM invente alternativas plausibles
+pero incorrectas.
+
+### Formato obligatorio
+
+```markdown
+## Anti-substitution guardrails
+
+- Familia <nombre>: usar `<comando-canónico>` (nunca sustituir con
+  `<alternativa-plausible-1>`, `<alternativa-plausible-2>`).
+- Flag de <propósito>: usar `--<flag-canónico>` (nunca `--<flag-parecido>`).
+- API de <propósito>: usar `<método.canónico>` (nunca `<método.parecido>`).
+```
+
+### Criterios para incluir una entrada
+
+Una sustitución se lista solo si **TODAS** son verdaderas:
+
+- La alternativa es plausible (existe, funciona para algo).
+- La alternativa es incorrecta en el contexto específico de la skill.
+- Un LLM sin la guardrail la produciría con probabilidad >5%.
+
+No listar sustituciones obvias (`cd` vs `ls`) ni imposibles (`curl` vs `cat`).
+
+### Ejemplo — skill `/swl:cron`
+
+```markdown
+## Anti-substitution guardrails
+
+- Schedule recurrente: usar `every 2h` (nunca `@every 2h`, `*/2 * * * *`
+  cuando el usuario pidió "cada 2 horas" sin constraints específicos).
+- Crear job: usar subcomando `add` (nunca `create`, `new`, `register`).
+- Eliminar job: usar `remove <id>` (nunca `delete`, `rm`, `drop`).
+```
+
+---
+
+## Reglas detalladas para `scripts/`
+
+**Cuándo crear un script**: la lógica es determinista, costosa de regenerar,
+no requiere razonamiento contextual y se reutiliza ≥2 veces por sesión.
+
+**Cuándo NO crearlo**: la lógica cambia por proyecto, necesita acceso runtime
+a sistema, es simple (<5 líneas), o no se reutilizaría.
+
+**Detección empírica**: ejecutar el skill en 3 casos de uso. Si el modelo
+regeneró el mismo helper 2+ veces independientemente, ese helper es candidato
+a `scripts/`.
+
+**Referencia desde SKILL.md**:
+
+```markdown
+`python scripts/validar-frontmatter.py ruta/al/SKILL.md`
+```
+
+Los scripts NUNCA entran en contexto automáticamente. Claude los ejecuta vía
+bash y procesa solo el output. Los scripts deben:
+
+- Imprimir resultados claros en stdout.
+- Usar exit codes estándar (0 = éxito, 1 = error).
+- Documentar su uso en las primeras 5 líneas.
+
+---
+
+## Reglas detalladas para `recursos/`
+
+**Cuándo crear un recurso**: plantilla reutilizable, ejemplo de código completo,
+esquema de referencia, documentación extendida que no cabe en SKILL.md, o
+lista de referencia extensa.
+
+**Referencia desde SKILL.md**:
+
+```markdown
+Usar la plantilla en [recursos/claude-md-template.md](recursos/claude-md-template.md)
+```
+
+Los paths SIEMPRE son relativos al directorio de la skill.
+
+**ToC obligatoria si supera 200 líneas**: incluir tabla de contenido al inicio
+para que lecturas truncadas sigan siendo útiles:
+
+```markdown
+## Contenido
+
+- [Sección A](#sección-a)
+- [Sección B](#sección-b)
+```
+
+---
+
+## Campo dual: `herramientasPermitidas` y `allowed-tools`
+
+**Principio de 3 capas**: `herramientasPermitidas` es el campo autoritativo del
+sistema SWL (español). `allowed-tools` es el campo del protocolo Anthropic que
+Claude Code lee (inglés, no negociable). Ambos coexisten con la misma semántica.
+
+### Cuándo usar cada campo
+
+- **Skills propios de swl-ses**: declarar solo `herramientasPermitidas`.
+- **Skills exportados fuera de swl-ses** (paquetes Anthropic-compatibles):
+  declarar también `allowed-tools` explícitamente.
+
+### Ejemplo
+
+```yaml
+---
+name: mi-skill-analisis
+description: >
+  Analiza estructura de código. Cargar al revisar código antes de merge.
+herramientasPermitidas: [Read, Grep, Glob]
+# Solo agregar allowed-tools si se distribuye fuera de swl-ses:
+# allowed-tools: [Read, Grep, Glob]
+---
+```
+
+**Validación cruzada**: si ambos están presentes deben tener el mismo contenido.
+El evaluador `evaluar-skill` emite W011 si divergen.
+
+### Aclaración crítica: pre-aprobación vs restricción real
+
+Ambos campos son **pre-aprobación de UX**, NO restricción de seguridad real.
+Las restricciones reales provienen de permission rules en `.claude/settings.json`
+y matchers en hooks PreToolUse.
+
+---
+
+## Skills as agents pattern (variant técnico avanzado)
+
+Patrón Anthropic nativo: `agent: true` + `model:` en el frontmatter ejecuta
+el skill como sub-agente independiente, aislado del contexto del padre.
+Aplica cuando el skill consume input grande y devuelve output acotado;
+NO aplica para skills passive (reglas, knowledge). Detalles completos
+(cuándo usarlo, ejemplo de skill, reglas del frontmatter, candidatos SWL)
+en [recursos/skills-as-agents.md](recursos/skills-as-agents.md).
+
+---
+
+## Relación con otros componentes del sistema
+
+| Componente | Relación con skills |
+|-----------|-------------------|
+| Agentes SWL | Invocan skills con `Skill("nombre")` antes de implementar |
+| Comandos `/swl:*` | Pueden invocar skills para guiar su comportamiento |
+| Reglas en `reglas/` | Las reglas aplican a código/proceso; los skills a conocimiento de dominio |
+| Hooks | Los hooks no invocan skills — trabajan a nivel de herramientas |
+| CLAUDE.md | Registra el inventario de skills disponibles |
+
+---
+
+## Contenido extendido (cargar bajo demanda)
+
+Los siguientes bloques viven en `recursos/` y se consultan cuando se necesite
+el contenido específico, sin inflar el contexto con cada invocación:
+
+- **Anti-patrones al crear skills + leyes de diseño de alta señal** —
+  6 anti-patrones y 6 leyes con ejemplos MAL/BIEN completos. Ver
+  [recursos/anti-patrones-y-leyes.md](recursos/anti-patrones-y-leyes.md).
+- **Principio de idiomas de framework** — tabla para Django, FastAPI, NestJS,
+  Spring Boot, Laravel, Rails, Go, Rust con anti-patrón de código. Ver
+  [recursos/idiomas-framework.md](recursos/idiomas-framework.md).
+- **Mapeo a frameworks de seguridad (NIST CSF, NIST AI RMF, MITRE ATT&CK/ATLAS/
+  D3FEND)** + **migración a nombres de campo en español (REC-S15)**. Ver
+  [recursos/frameworks-seguridad.md](recursos/frameworks-seguridad.md).
+
+Cada recurso tiene ToC al inicio y es autocontenido — leer solo el relevante
+al caso en cuestión en lugar de los tres.
+
+---
+
+## Gotchas / Errores comunes no obvios
+
+- **Confundir Response Discipline con skills de dominio conceptual**: aplicar
+  el patrón "command-first" a un skill de patrones de diseño produce respuestas
+  truncadas sin contexto. Response Discipline SOLO aplica a skills que
+  prescriben comandos, snippets o tokens específicos.
+- **Escribir Anti-substitution sin criterio de plausibilidad**: listar
+  sustituciones imposibles o obvias diluye la señal. Aplicar los 3 criterios
+  (plausible + incorrecta + prob >5%) antes de listar una entrada.
+- **Mapear skills no-seguridad a frameworks NIST/MITRE**: genera ruido en
+  reportes de cobertura. Reservar el mapeo para el dominio seguridad.
+- **Copiar ambos campos (`herramientasPermitidas` y `allowed-tools`) en skills
+  internos**: genera duplicación de mantenimiento. Solo el campo español es
+  autoritativo en swl-ses; la copia en inglés se hace al exportar.
+- **Documentar idioma de framework en skills transversales**: un skill de
+  `compactacion-contexto` no debe usar `@Transactional` como ejemplo. El
+  principio aplica solo cuando la skill cubre UN framework específico.
+- **Cargar este skill cuando la regla core basta**: esto invierte el trade-off
+  de context budget. Cargar `meta-skills-estandar` solo cuando se necesita
+  contenido extendido, no por defecto.
+
+## Referencias
+
+- Regla core (se carga siempre): `reglas/skills-estandar.md`.
+- Evaluador de skills: `comandos/swl/evaluar-skill.md` (usa W009, W010, W011).
+- Schema: `schemas/skill-frontmatter.schema.json`.
+- Normalizador de campos legacy: `scripts/lib/skill-normalizer.js`.

package/habilidades/meta-skills-estandar/recursos/anti-patrones-y-leyes.md

@@ -0,0 +1,205 @@
+# Anti-patrones y leyes de diseño de skills
+
+Complemento a `SKILL.md` de `meta-skills-estandar`. Contiene ejemplos MAL/BIEN
+detallados para cada anti-patrón y ley. Referenciado desde el skill principal.
+
+## Contenido
+
+- [Anti-patrón 1: description pasiva](#anti-patrón-1-description-que-solo-describe-no-activa)
+- [Anti-patrón 2: SKILL.md como dump](#anti-patrón-2-skillmd-como-dump-de-documentación)
+- [Anti-patrón 3: scripts embebidos](#anti-patrón-3-scripts-dentro-de-skillmd)
+- [Anti-patrón 4: paths absolutos](#anti-patrón-4-paths-absolutos-que-rompen-portabilidad)
+- [Anti-patrón 5: skill con 1-2 reglas](#anti-patrón-5-skill-con-solo-1-2-reglas)
+- [Anti-patrón 6: directivas sin justificación](#anti-patrón-6-directivas-sin-justificación)
+- [Ley 1: description como trigger](#ley-1-la-description-es-un-trigger-no-un-resumen)
+- [Ley 2: Gotchas como mayor señal](#ley-2-la-sección-gotchas-es-el-contenido-de-mayor-señal)
+- [Ley 3: no declarar lo obvio](#ley-3-no-declarar-lo-obvio)
+- [Ley 4: objetivos + restricciones](#ley-4-dar-objetivos-y-restricciones-no-pasos)
+- [Ley 5: CLAUDE_PLUGIN_DATA](#ley-5-usar-claude_plugin_data-para-datos-persistentes-entre-sesiones)
+- [Ley 6: hooks bajo demanda](#ley-6-hooks-bajo-demanda-no-permanentes)
+
+---
+
+## Anti-patrones comunes al crear skills
+
+### Anti-patrón 1: Description que solo describe, no activa
+
+```yaml
+# MAL — solo describe, no dice cuándo usar
+description: Skill sobre autenticación con JWT y manejo de tokens en APIs.
+
+# BIEN — dice qué hace y cuándo cargar
+description: >
+  Patrones de autenticación JWT para APIs FastAPI: generación, validación,
+  refresh tokens y revocación. Cargar cuando se implementen endpoints de
+  login/logout, middleware de autenticación o manejo de sesiones con tokens.
+```
+
+### Anti-patrón 2: SKILL.md como dump de documentación
+
+Un SKILL.md que lista 200 endpoints de una API externa no es una skill, es
+una copia de documentación. Las skills contienen instrucciones de comportamiento,
+no documentación raw. La documentación raw va en `recursos/`.
+
+### Anti-patrón 3: Scripts dentro de SKILL.md
+
+```markdown
+# MAL — script embebido en SKILL.md (satura el contexto)
+## Script de validación
+```python
+#!/usr/bin/env python3
+# ... 80 líneas de código ...
+```
+
+# BIEN — referencia al script externo
+Para validar el frontmatter antes de guardar:
+`python scripts/validar-frontmatter.py archivo.md`
+```
+
+### Anti-patrón 4: Paths absolutos que rompen portabilidad
+
+```markdown
+# MAL
+Ver la referencia en D:\Python\mi-proyecto\habilidades\mi-skill\recursos\ref.md
+
+# BIEN
+Ver la referencia en [recursos/ref.md](recursos/ref.md)
+```
+
+### Anti-patrón 5: Skill con solo 1-2 reglas
+
+Una skill con menos de 3 reglas concretas no justifica un directorio separado.
+Agregar ese conocimiento al skill más cercano en dominio.
+
+### Anti-patrón 6: Directivas sin justificación
+
+Las directivas en mayúsculas (MUST, NEVER, ALWAYS, NUNCA, SIEMPRE) sin
+justificación son obedecidas pero no generalizables — el modelo sigue la regla
+en el caso exacto documentado, pero no puede aplicar el principio a variantes
+no anticipadas.
+
+```markdown
+# MAL — directiva sin justificación
+NUNCA usar `lazy="select"` en SQLAlchemy async.
+
+# BIEN — directiva con justificación
+NUNCA usar `lazy="select"` en SQLAlchemy async — lanza MissingGreenlet
+en contexto async sin aviso claro porque el ORM intenta resolver la
+relación fuera de la sesión activa.
+```
+
+**Regla**: toda directiva absoluta DEBE incluir en la misma línea o en la
+siguiente una frase que comience con "porque", "ya que", "para evitar",
+"si no". Si no cabe en una línea, usar formato de lista:
+
+```markdown
+NUNCA usar `pickle.loads()` con datos externos.
+  — Razón: permite ejecución arbitraria de código; los datos externos no son
+    de confianza por definición. Usar `json.loads()` con schema validado.
+```
+
+El evaluador `evaluar-skill` detecta ausencia de justificaciones con W009
+(-8 en `output_quality`).
+
+---
+
+## Leyes de diseño de skills de alta señal
+
+### Ley 1: La description es un TRIGGER, no un resumen
+
+La description es la señal que el modelo usa para decidir si debe cargar la
+skill. Redactar como condición de activación:
+
+```yaml
+# MAL — resumen pasivo
+description: Conocimiento sobre caching en aplicaciones web.
+
+# BIEN — trigger con situaciones concretas
+description: >
+  Estrategias de caching (Redis, CDN, HTTP cache, in-memory) para APIs REST.
+  Cargar cuando el tiempo de respuesta de un endpoint supere 200ms, cuando se
+  diseñe invalidación de caché, o cuando se configure un CDN.
+```
+
+### Ley 2: La sección Gotchas es el contenido de mayor señal
+
+Los errores no obvios que un desarrollador experimentado comete son el contenido
+más valioso de una skill. Toda skill de implementación DEBE incluir `## Gotchas`
+o `## Errores comunes no obvios`:
+
+```markdown
+## Gotchas
+
+- `selectinload` en SQLAlchemy async es OBLIGATORIO — `lazy="select"` lanza
+  `MissingGreenlet` en contexto async sin aviso claro
+- `Depends()` en FastAPI crea UNA instancia por request — no es singleton
+- `response_model` valida la SALIDA, no la entrada — usar `Body()` para input
+```
+
+Si la skill no tiene gotchas documentados, probablemente no aporta valor
+diferencial sobre lo que el modelo ya sabe.
+
+### Ley 3: No declarar lo obvio
+
+El modelo ya sabe qué es React, FastAPI o cómo funciona un for loop. Una skill
+que repite conocimiento general del training data desperdicia tokens. El
+contenido de una skill debe ser:
+
+- Lo que el modelo hace **mal** sin la skill (gotchas, anti-patrones).
+- Lo que el modelo **no sabe** por ser reciente o específico del proyecto.
+- Las **decisiones de diseño** que el equipo ya tomó (no re-evaluar cada vez).
+
+### Ley 4: Dar objetivos y restricciones, no pasos
+
+El modelo razona mejor cuando recibe QUÉ lograr y QUÉ evitar, no una lista
+de pasos. Los pasos rígidos fallan cuando el contexto cambia:
+
+```markdown
+# MAL — pasos rígidos
+1. Crear archivo en src/api/
+2. Importar FastAPI
+3. Definir router
+4. Agregar endpoint GET
+
+# BIEN — objetivo + restricciones
+## Objetivo
+Implementar endpoints CRUD que cumplan el contrato OpenAPI del proyecto.
+
+## Restricciones
+- Usar `APIRouter` con prefix y tags (no montar en app directamente)
+- Validación de input con Pydantic v2 `model_validator`
+- Responses tipadas con `response_model` para auto-documentación
+- Tests de integración con httpx antes de marcar como completado
+```
+
+### Ley 5: Usar `${CLAUDE_PLUGIN_DATA}` para datos persistentes entre sesiones
+
+Cuando una skill necesita recordar estado entre sesiones (métricas acumuladas,
+configuración del usuario, caché de resultados), usar el directorio de datos
+persistentes del plugin en lugar de paths hardcodeados:
+
+```markdown
+Guardar métricas acumuladas en `${CLAUDE_PLUGIN_DATA}/metricas.json`.
+Este directorio persiste entre sesiones y es exclusivo de esta skill.
+```
+
+No usar `.planning/` ni directorios del proyecto para datos internos de la skill.
+
+### Ley 6: Hooks bajo demanda, no permanentes
+
+Si una skill necesita comportamiento event-driven, definir el hook en el
+frontmatter con `hooks` en lugar de registrarlo en `settings.json`:
+
+```yaml
+---
+name: mi-skill
+hooks:
+  PostToolUse:
+    - matcher: "Write"
+      command: "node ${CLAUDE_SKILL_DIR}/scripts/validar.js"
+---
+```
+
+Ventaja: el hook no consume recursos cuando la skill no está activa. Reservar
+`settings.json` para hooks que SIEMPRE deben ejecutarse (seguridad global,
+auditoría, formateo).

package/habilidades/meta-skills-estandar/recursos/frameworks-seguridad.md

@@ -0,0 +1,107 @@
+# Mapeo a frameworks de seguridad (REC-C01)
+
+Complemento a `SKILL.md` de `meta-skills-estandar`. Aplicable SOLO a skills
+del dominio seguridad.
+
+---
+
+Skills del dominio de seguridad pueden declarar mapeos opcionales a cinco
+frameworks estándar en el frontmatter. El propósito es enriquecer reportes
+(`/swl:salud`, `/swl:dashboard`) con cobertura de control y alinear el sistema
+con vocabulario de la industria. **No es evolución — es metadata aditiva que
+no cambia comportamiento.**
+
+## Campos disponibles (todos opcionales, todos propios SWL en español)
+
+| Campo | Framework | Formato | Ejemplo |
+|-------|-----------|---------|---------|
+| `nist_csf` | NIST CSF 2.0 | `GV\|ID\|PR\|DE\|RS\|RC.XX[-NN]` | `[GV.SC-07, PR.PS-01]` |
+| `nist_ai_rmf` | NIST AI RMF 1.0 | `GOVERN\|MAP\|MEASURE\|MANAGE-N.N` | `[GOVERN-1.1, MEASURE-2.5]` |
+| `atlas_techniques` | MITRE ATLAS v5.4 | `AML.TNNNN[.NNN]` | `[AML.T0051, AML.T0080]` |
+| `attack_techniques` | MITRE ATT&CK v18 | `TNNNN[.NNN]` | `[T1190, T1552]` |
+| `d3fend_techniques` | MITRE D3FEND v1.3 | `D3-XXX` | `[D3-MFA, D3-NTA]` |
+
+## Cuándo declarar cada framework
+
+- **NIST CSF 2.0**: skills que cubren controles organizacionales o funciones
+  (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER). Aplicable a casi
+  cualquier skill de seguridad.
+- **NIST AI RMF 1.0**: skills específicas de sistemas agénticos o IA. Todos
+  los skills de seguridad del sistema SWL (que ES agéntico) deberían declararlo.
+- **MITRE ATLAS v5.4**: skills que defienden contra amenazas adversarias sobre
+  modelos o pipelines LLM (prompt injection, context poisoning, jailbreak).
+- **MITRE ATT&CK v18**: skills de defensa contra TTPs de atacantes en la
+  infraestructura desplegada (no en el código). Más útil para operaciones
+  que para SDLC, pero aplicable a skills que documentan detección en logs.
+- **MITRE D3FEND v1.3**: contramedidas defensivas específicas. Útil para
+  autenticación (D3-MFA), rotación de credenciales (D3-CR), análisis de
+  tráfico (D3-NTA).
+
+## Ejemplo de uso en frontmatter
+
+```yaml
+---
+name: checklist-seguridad
+description: ...
+version: "1.0.0"
+nist_csf: [PR.PS-01, PR.DS-02, PR.DS-10, DE.CM-09, RS.MI-01]
+attack_techniques: [T1190, T1059, T1556]
+---
+```
+
+## Qué NO hacer
+
+- **No inventar mapeos**: verificar cada ID en la fuente oficial del framework
+  antes de declararlo. Un mapeo incorrecto es peor que ausencia de mapeo.
+- **No saturar**: 3-6 entradas por framework son suficientes. Listar 20
+  controles diluye la señal.
+- **No mezclar capas**: un skill de SDLC no debe mapear a tácticas ofensivas
+  fuera de contexto (T1059 Command Execution en un skill de revisión de código
+  es válido porque describe el vector defendido; T1021 Remote Services no es
+  apropiado para un skill que nunca toca red).
+- **No mapear skills que no son de seguridad**: el mapeo es para el dominio
+  seguridad, no para todos los skills.
+
+## Auditoría de cobertura
+
+El script `scripts/auditar-cobertura-frameworks.js` reporta cobertura agregada
+del sistema por framework. Ver `comandos/swl/salud.md` para el paso opt-in que
+expone el reporte con `SWL_AUDIT_FRAMEWORKS=1`.
+
+## Referencias a fuentes oficiales
+
+- NIST Cybersecurity Framework 2.0: https://www.nist.gov/cyberframework
+- NIST AI Risk Management Framework: https://airc.nist.gov/AI_RMF
+- MITRE ATT&CK: https://attack.mitre.org
+- MITRE ATLAS: https://atlas.mitre.org
+- MITRE D3FEND: https://d3fend.mitre.org
+
+---
+
+## Migración a nombres propios en español (REC-S15)
+
+Los campos `provenance`, `targets`, `evolvable`, `evolvable_scope` del schema
+de skills están en transición a sus equivalentes en español: `procedencia`,
+`destinos`, `evolucionable`, `evolucionable_alcance`.
+
+**Nuevos skills**: usar solo los nombres en español (propios de SWL). El módulo
+`scripts/lib/skill-normalizer.js` promueve el campo en inglés si solo ese está
+presente (fallback no-breaking).
+
+**Skills existentes**: sin cambio obligatorio. El validador emite W010 (-2 en
+`robustness`) como señal de migración pendiente, no como error bloqueante. Tras
+2 releases con coexistencia, los campos en inglés se marcarán deprecated.
+
+**Validación cruzada**: si ambos campos están presentes deben coincidir en
+valor. La divergencia entre `targets` y `destinos` (o cualquier par) emite
+W010 ALIAS_DIVERGENTE.
+
+**Campos excluidos de migración** (permanecen en inglés por contrato con el
+protocolo Anthropic):
+
+- `name`, `description`, `user-invocable`, `allowed-tools`, `when_to_use`,
+  `disable-model-invocation`.
+
+**Herramienta de detección**: `scripts/lib/skill-normalizer.js` expone
+`detectarUsoLegacy()` y `detectarDivergencias()` — usados por el validador
+`/swl:evaluar-skill` en el Paso 1.3.

package/habilidades/meta-skills-estandar/recursos/idiomas-framework.md

@@ -0,0 +1,60 @@
+# Principio de idiomas de framework
+
+Complemento a `SKILL.md` de `meta-skills-estandar`. Tabla extensa por framework
+y anti-patrón de código a detectar. Referenciado desde el skill principal.
+
+---
+
+## Regla
+
+> Las convenciones del framework toman **precedencia** sobre la consistencia
+> cross-proyecto. Si el framework provee un mecanismo oficial para resolver un
+> problema, ese mecanismo ES la solución correcta — no una alternativa genérica.
+
+## Ejemplos por framework
+
+| Framework | Patrón idiomático correcto | Anti-patrón genérico a evitar |
+|-----------|---------------------------|-------------------------------|
+| **Django** | Middleware global de errores, signals para side effects, `select_related`/`prefetch_related` | Try/except en cada vista, queries N+1, actualizaciones manuales de estado |
+| **FastAPI** | `Annotated` + `Depends` para DI, `selectinload` explícito en async, `lifespan` para startup/shutdown | Parámetros manuales de DI, lazy loading en contexto async (MissingGreenlet) |
+| **NestJS** | Constructor injection con `@Injectable()`, DTOs con `class-validator`, `@Module` para encapsulación | Field injection con `@Autowired`, validación manual de inputs |
+| **Spring Boot** | `@Transactional` de Spring, constructor injection con `@RequiredArgsConstructor`, `@Transactional(readOnly=true)` para lecturas | Field injection, manejo manual de transacciones, SQL raw sin justificación |
+| **Laravel** | Eager loading con `->with()`, API Resources para transformación, Jobs para operaciones largas | N+1 con Eloquent, lógica de negocio en controladores, sync para operaciones costosas |
+| **Rails** | `includes`/`eager_load` para N+1, service objects para lógica compleja, `strong_parameters` para inputs | Lazy loading no controlado, lógica en controladores, params sin filtrar |
+| **Go** | `context.Context` para cancellation, error wrapping con `fmt.Errorf("...: %w", err)`, `sync.WaitGroup` para concurrencia | Panics para errores de negocio, goroutines sin control de lifecycle |
+| **Rust** | `?` operator para propagación de errores, `Arc<Mutex<T>>` para estado compartido, `thiserror` para error types | Panics en código de biblioteca, `unwrap()` en producción, `clone()` innecesario |
+
+## Cómo aplicar al escribir o revisar una skill
+
+1. **Identificar el mecanismo oficial** del framework para el problema.
+2. **Verificar** que el ejemplo de código en la skill usa ese mecanismo.
+3. **Marcar como anti-patrón** cualquier alternativa genérica que ignore el
+   mecanismo del framework.
+4. **Documentar el "por qué"**: explicar qué errores específicos evita.
+
+## Anti-patrón a detectar
+
+```markdown
+# MAL — skill que describe patrones genéricos
+## Manejo de errores
+try:
+    resultado = operacion()
+except Exception as e:
+    logging.error(e)
+    raise
+
+# BIEN — skill que usa el idioma de Django
+## Manejo de errores (Django)
+# Usar el middleware global de Django para errores inesperados:
+# MIDDLEWARE = ['django.middleware.common.CommonMiddleware', ...]
+# Para errores esperados, usar excepciones específicas de DRF:
+raise ValidationError({"campo": "El valor no es válido"})
+# DRF las convierte automáticamente en respuestas 400 con formato estándar
+```
+
+## Gotcha: aplicar solo cuando el skill cubre UN framework
+
+Un skill transversal (p.ej. `compactacion-contexto`) NO debe usar ejemplos
+de framework específico. El principio aplica únicamente cuando la skill
+cubre un solo framework y tiene como propósito documentar patrones
+idiomáticos de ese framework.