@saulwade/swl-ses 1.0.0

package/comandos/swl/planear-fase.md

@@ -0,0 +1,221 @@
+---
+name: swl:planear-fase
+description: Recibe el número de una fase y genera un plan de implementación detallado y accionable. Delega al agente planificador-swl, verifica el plan con el revisor y permite hasta 3 iteraciones de refinamiento.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
+---
+
+# /swl:planear-fase <n> — Generar plan detallado de implementación
+
+Eres el coordinador de planeación SWL. Tu trabajo es orquestar la generación de un plan de implementación de alta calidad para una fase específica, usando el agente planificador-swl y validando el resultado con el revisor antes de presentarlo al usuario.
+
+## Uso
+
+```
+/swl:planear-fase 1
+/swl:planear-fase 2
+```
+
+## Paso 0 — Carga de habilidades
+
+```
+Skill("planear-fase")
+```
+
+Si no existe, carga `Skill("python-patterns")` si el stack es Python, o `Skill("angular-component")` si el stack es Angular/TS. Siempre carga también:
+
+```
+Skill("api-design-principles")
+```
+
+## Paso 1 — Verificación de prerrequisitos
+
+Verifica los siguientes archivos en orden. Si alguno falta, detente con un error claro:
+
+1. `.planning/PROYECTO.md` — debe existir. Sin esto: "Ejecuta `/swl:nuevo-proyecto` primero."
+2. `.planning/HOJA-RUTA.md` — debe existir y la fase N debe estar listada.
+3. `.planning/fases/0N-CONTEXTO.md` — debe existir. Sin esto: "Ejecuta `/swl:discutir-fase N` primero para capturar el contexto de la fase."
+
+Lee los tres archivos completos antes de continuar.
+
+Verifica también:
+- Si existe `.planning/fases/0N-PLAN.md` ya — si existe, pregunta al usuario: "Ya existe un plan para esta fase. ¿Deseas regenerarlo desde cero o refinar el existente?" Espera respuesta.
+- Lee `CLAUDE.md` del proyecto si existe — puede tener restricciones de implementación.
+- Si hay fases anteriores con PLAN.md o RESUMEN.md, léelas para entender patrones establecidos.
+
+## Paso 2 — Análisis del contexto
+
+Antes de delegar, analiza el CONTEXTO.md de la fase y extrae:
+
+1. **Tipo de trabajo predominante**: backend, frontend, infraestructura, integración, mixto.
+2. **Complejidad estimada**: BAJA (1-3 días), MEDIA (1-2 semanas), ALTA (>2 semanas).
+3. **Dependencias externas**: ¿hay APIs de terceros, bases de datos nuevas, servicios cloud?
+4. **Riesgos que afectan la planeación**: lista los riesgos marcados como ALTO del CONTEXTO.md.
+5. **Decisiones pendientes**: si hay decisiones marcadas como "[POR DEFINIR]", enuméralas aquí.
+
+Si hay más de 2 decisiones "[POR DEFINIR]" en áreas críticas (arquitectura, modelo de datos, permisos), detente y pregunta al usuario:
+
+```
+Encontré [N] decisiones pendientes que afectan la arquitectura del plan:
+1. [decisión 1]
+2. [decisión 2]
+
+Estas deben resolverse antes de planear. ¿Puedes darme tu decisión para cada una?
+```
+
+## Paso 3 — Delegación al agente planificador-swl
+
+Delega al agente `planificador-swl` con el siguiente contexto:
+
+**Instrucción al agente planificador-swl:**
+
+```
+Genera un PLAN.md detallado para la Fase N del proyecto [nombre].
+
+Archivos de contexto a leer:
+- .planning/PROYECTO.md
+- .planning/HOJA-RUTA.md
+- .planning/REQUISITOS.md
+- .planning/fases/0N-CONTEXTO.md
+[si aplica] - .planning/research/ARQUITECTURA.md
+[si aplica] - .planning/fases/0(N-1)-RESUMEN.md (fase anterior)
+
+El plan debe seguir el formato especificado en la sección "Formato del PLAN.md" de este comando.
+
+Restricciones adicionales detectadas:
+[lista de restricciones del PROYECTO.md y CLAUDE.md]
+
+Riesgos que deben reflejarse en el plan:
+[lista de riesgos ALTO del CONTEXTO.md]
+```
+
+Mientras el agente trabaja, monitorea el progreso. El agente debe producir `.planning/fases/0N-PLAN.md`.
+
+## Paso 4 — Formato del PLAN.md
+
+El agente planificador-swl debe generar el plan con esta estructura exacta:
+
+```markdown
+# Plan de implementación — Fase N: [nombre]
+
+**Proyecto**: [nombre]
+**Fase**: N de M
+**Fecha de generación**: [fecha]
+**Iteración del plan**: 1
+**Estimación total**: [rango de días/horas]
+
+## Resumen ejecutivo
+[2-4 oraciones describiendo qué se va a construir y cómo]
+
+## Orden de implementación (vertical slices)
+
+### Slice 1 — [nombre del slice]
+**Tipo**: AFK | HITL
+**Estimación**: [horas]
+**Descripción**: [qué hace este slice]
+
+#### Tareas
+1. [ ] [tarea específica con archivo o componente objetivo]
+2. [ ] [tarea específica]
+...
+
+#### Criterio de verificación
+[cómo saber que este slice está completo y funciona]
+
+#### Dependencias
+[qué slices o archivos deben existir antes]
+
+### Slice 2 — [nombre]
+[misma estructura]
+
+...
+
+## Modelos y esquemas de datos
+[tablas, campos, tipos, constraints — si la fase introduce datos nuevos]
+
+## Endpoints a implementar
+| Método | Ruta | Descripción | Roles permitidos |
+|--------|------|-------------|-----------------|
+[si aplica]
+
+## Componentes frontend a implementar
+| Componente | Ruta del archivo | Propósito |
+|------------|-----------------|-----------|
+[si aplica]
+
+## Tests requeridos
+[lista de tests que deben existir al finalizar la fase]
+
+## Riesgos y mitigaciones
+| Riesgo | Impacto | Probabilidad | Mitigación |
+|--------|---------|-------------|-----------|
+
+## Criterios de aceptación de la fase
+[copia del CONTEXTO.md, verificados contra el plan]
+
+## Comandos de verificación
+[comandos concretos para verificar que la fase funciona: cómo correr tests, cómo verificar endpoints, etc.]
+```
+
+## Paso 5 — Revisión del plan generado
+
+Una vez que el agente planificador-swl produce el PLAN.md, ejecuta una revisión con el revisor. Verifica los siguientes puntos de calidad:
+
+### Checklist de revisión del plan
+
+- [ ] ¿Cada tarea es atómica y tiene un archivo o componente destino claro?
+- [ ] ¿El orden de implementación respeta las dependencias (BD → service → endpoint → frontend)?
+- [ ] ¿Hay criterios de verificación para cada slice?
+- [ ] ¿Los criterios de aceptación de la fase están cubiertos por los slices?
+- [ ] ¿Los riesgos ALTO del CONTEXTO.md están mitigados en el plan?
+- [ ] ¿Hay tests especificados para cada área crítica?
+- [ ] ¿Hay tareas HITL claramente marcadas?
+- [ ] ¿Los modelos de datos son consistentes con los requisitos del CONTEXTO.md?
+- [ ] ¿El estimado de tiempo es realista dado el número y complejidad de tareas?
+
+Si hay deficiencias en el plan (más de 2 puntos fallidos del checklist), itera.
+
+## Paso 6 — Bucle de iteración (máximo 3 rondas)
+
+Mantén un contador de iteraciones. Para cada iteración:
+
+1. Identifica los problemas específicos del plan.
+2. Genera instrucciones de mejora precisas para el agente planificador-swl.
+3. El agente regenera o ajusta el PLAN.md.
+4. Vuelve al Paso 5.
+
+Si después de 3 iteraciones el plan aún tiene problemas:
+- Guarda el plan como está con nota "[REQUIERE REVISIÓN HUMANA]" al inicio.
+- Reporta al usuario los problemas encontrados con detalle.
+- Pregunta si quiere continuar con el plan imperfecto o abortar la planeación.
+
+Actualiza el campo `**Iteración del plan**` en el PLAN.md con cada ciclo.
+
+## Paso 7 — Actualización del HOJA-RUTA.md
+
+Una vez aprobado el plan, actualiza el estado de la fase N en `.planning/HOJA-RUTA.md`:
+- Cambia el estado de "Pendiente" a "Planeada"
+- Agrega la fecha de planeación
+- Agrega el número de slices y estimación total
+
+## Paso 8 — Reporte al usuario
+
+Al terminar, reporta:
+
+1. Ruta absoluta del PLAN.md generado.
+2. Resumen del plan:
+   - Número de slices
+   - Número total de tareas
+   - Estimación de tiempo total
+   - Número de tareas HITL (si hay, listarlas — requieren decisión humana)
+3. Iteraciones que tomó el plan (1 = ideal, 2-3 = normal, 3 con advertencia = revisar contexto).
+4. Si hay tareas HITL, presentarlas como lista de decisiones pendientes.
+5. Próximo paso: "Cuando estés listo, ejecuta `/swl:ejecutar-fase N`"
+
+## Reglas de comportamiento
+
+- NUNCA generes código fuente en este paso — solo el plan de implementación.
+- El plan debe ser ejecutable por cualquier desarrollador que lo lea, sin conocer la conversación.
+- Si una tarea es ambigua en el plan, el revisor DEBE rechazarla hasta que sea específica.
+- Las estimaciones de tiempo deben ser honestas — no subestimes para complacer al usuario.
+- Tareas HITL son aquellas que requieren decisión humana: elección de tecnología, cambio de arquitectura, aprobación de modelo de datos. Márcalas explícitamente.
+- NUNCA marques una tarea como completa en el plan — eso lo hace `/swl:ejecutar-fase`.

package/comandos/swl/plugins.md

@@ -0,0 +1,256 @@
+---
+name: swl:plugins
+description: Gestiona plugins de usuario instalados en _userland/. Instala, desinstala, lista y valida plugins SWL desde directorios locales. Cargar cuando el usuario quiera instalar componentes externos (agentes, skills, reglas, hooks) sin modificar el sistema base.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
+---
+
+# /swl:plugins — Gestión de plugins de usuario
+
+Gestiona el ciclo de vida completo de plugins SWL instalados en `_userland/plugins/`.
+Un plugin es un directorio con `plugin.json` que agrupa agentes, skills, reglas y/o
+hooks de terceros o del equipo, sin tocar los componentes del sistema base.
+
+## Cuándo usar
+
+- Para instalar skills o agentes de dominio específico del proyecto
+- Para incorporar extensiones de equipo sin mezclarlas con el sistema SWL base
+- Para validar un plugin antes de distribuirlo
+- Para limpiar plugins obsoletos
+
+## Subcomandos
+
+```
+/swl:plugins                    — Lista plugins instalados (resumen)
+/swl:plugins list               — Lista plugins con detalle de componentes
+/swl:plugins install <ruta>     — Instala plugin desde directorio local
+/swl:plugins remove <nombre>    — Desinstala plugin
+/swl:plugins validate <ruta>    — Valida plugin.json contra schema
+```
+
+---
+
+## install — Instalar un plugin
+
+### Paso 1 — Leer y validar el manifiesto
+
+```bash
+cat <ruta>/plugin.json
+```
+
+Verificar que `plugin.json` existe y leerlo. Luego validar contra el schema:
+
+```bash
+# Verificar campos obligatorios: name, version, description
+# El name debe cumplir ^[a-z][a-z0-9-]+$ y no usar palabras reservadas:
+# anthropic, claude, swl
+```
+
+Si falta `plugin.json` o no cumple el schema en `schemas/plugin.schema.json`:
+reportar los campos inválidos y abortar sin realizar cambios.
+
+### Paso 2 — Verificar archivos referenciados
+
+Recorrer los arrays `agents`, `skills`, `rules`, `hooks` del manifiesto y
+verificar que cada ruta referenciada existe dentro del directorio del plugin:
+
+```bash
+ls <ruta>/<archivo-referenciado>
+```
+
+Si algún archivo referenciado no existe: reportar y abortar.
+
+### Paso 2B — Verificación de seguridad del plugin
+
+**Carga**: `Skill("seguridad-skills-ia")` — patrones de detección de amenazas.
+
+Escanear el contenido completo del plugin antes de copiar al destino:
+
+1. **Agentes del plugin**: verificar que ningún agente declara `nivelRiesgo: ALTO`
+   ni `permisosRed: irrestricto` sin documentación explícita en el manifiesto
+2. **Hooks con `blocking: true`**: listar y advertir al usuario — requieren
+   aprobación explícita antes de activarse
+3. **Skills del plugin**: aplicar los patrones de detección del skill
+   `seguridad-skills-ia` sobre cada SKILL.md y sus scripts/
+4. **Reglas del plugin**: verificar que no contradicen reglas base del sistema
+   (precedencia de capas: reglas base > reglas de plugin)
+
+Resultado del escaneo:
+- **Score ≥ 8.0**: proceder con instalación
+- **Score 5.0-7.9**: advertir hallazgos y pedir confirmación explícita
+- **Score < 5.0**: BLOQUEAR instalación, reportar hallazgos detallados
+
+Registrar el resultado del escaneo en `.planning/AUDITORIA.md`:
+```markdown
+## [YYYY-MM-DD HH:MM] plugin-security-scan
+
+**Plugin**: nombre-plugin vX.Y.Z
+**Score**: N.N/10.0
+**Veredicto**: SEGURO | SOSPECHOSO | INSEGURO
+**Hallazgos**: [lista o "ninguno"]
+**Acción**: instalado | bloqueado | instalado con advertencias
+```
+
+### Paso 3 — Resolver dependencias
+
+Si `plugin.json` tiene `dependencies`:
+1. Verificar que cada dependencia está instalada en `_userland/plugins/`
+2. Si falta alguna: reportar nombre y versión requerida, abortar con instrucción:
+   `Instalar primero: /swl:plugins install <ruta-dependencia>`
+
+### Paso 4 — Copiar al destino
+
+```bash
+mkdir -p _userland/plugins/<nombre>/
+cp -r <ruta>/* _userland/plugins/<nombre>/
+```
+
+### Paso 5 — Registrar en .claude/settings.json
+
+Leer `.claude/settings.json`. Para cada componente del plugin:
+
+- **skills**: agregar path en `mcpServers` o en la lista de skills según configuración activa
+- **rules**: agregar path en `rules` si la configuración lo soporta
+- **hooks**: agregar entrada en `hooks` con el evento correspondiente
+
+Si `.claude/settings.json` no existe o no soporta registro dinámico, documentar
+los paths en `.planning/PLUGINS.md` para referencia manual.
+
+### Paso 6 — Verificar integridad post-instalación
+
+```bash
+echo "Plugin <nombre> v<version> instalado en _userland/plugins/<nombre>/"
+echo "Componentes: agentes=$(count), skills=$(count), reglas=$(count), hooks=$(count)"
+```
+
+Indicar al usuario que ejecute `/swl:salud` para verificar integridad global.
+
+---
+
+## remove — Desinstalar un plugin
+
+### Paso 1 — Verificar existencia
+
+```bash
+ls _userland/plugins/<nombre>/
+cat _userland/plugins/<nombre>/plugin.json
+```
+
+Si no existe: reportar y terminar.
+
+### Paso 2 — Verificar dependientes
+
+Buscar otros plugins instalados que declaren `<nombre>` en sus `dependencies`:
+
+```bash
+grep -r '"<nombre>"' _userland/plugins/*/plugin.json
+```
+
+Si hay dependientes activos: advertir y pedir confirmación antes de continuar.
+
+### Paso 3 — Des-registrar de settings.json
+
+Revertir los registros realizados durante `install`:
+- Remover skills del listado
+- Remover reglas del listado
+- Remover hooks del listado
+
+### Paso 4 — Eliminar directorio
+
+```bash
+rm -rf _userland/plugins/<nombre>/
+```
+
+Confirmar: `Plugin <nombre> desinstalado correctamente.`
+
+---
+
+## validate — Validar plugin sin instalar
+
+### Paso 1 — Verificar estructura mínima
+
+```bash
+ls <ruta>/plugin.json
+```
+
+### Paso 2 — Validar campos del manifiesto
+
+Leer `plugin.json` y verificar:
+
+| Campo | Regla |
+|-------|-------|
+| `name` | presente, `^[a-z][a-z0-9-]+$`, máximo 64 chars |
+| `version` | presente, `^\d+\.\d+\.\d+$` |
+| `description` | presente, 10–500 chars |
+| `agents[]` | cada ruta existe en el directorio |
+| `skills[]` | cada ruta existe y contiene `SKILL.md` |
+| `rules[]` | cada ruta existe y termina en `.md` |
+| `hooks[]` | cada ruta existe y termina en `.js` |
+| `dependencies` | cada valor es SemVer válido |
+
+### Paso 3 — Reportar resultado
+
+Si pasa todas las verificaciones:
+```
+✓ plugin.json válido
+✓ X archivos referenciados verificados
+✓ El plugin puede instalarse con: /swl:plugins install <ruta>
+```
+
+Si hay problemas: listar cada problema con campo y descripción del error.
+
+---
+
+## list — Listar plugins instalados
+
+```bash
+ls _userland/plugins/ 2>/dev/null || echo "(ningún plugin instalado)"
+```
+
+Para cada plugin encontrado, leer su `plugin.json` y mostrar:
+
+```
+nombre          versión    autor          componentes
+──────────────────────────────────────────────────────
+mi-dominio      1.2.0      Equipo A       3 skills, 1 agente
+otro-plugin     0.5.1      Dev externo    2 reglas, 1 hook
+```
+
+Si no hay plugins instalados: indicar cómo instalar uno.
+
+---
+
+## Estructura de un plugin
+
+```
+mi-plugin/
+  plugin.json          — Manifiesto (requerido)
+  agentes/             — Agentes custom (.md con frontmatter YAML)
+  habilidades/         — Skills custom (directorios con SKILL.md)
+  reglas/              — Reglas custom (.md)
+  hooks/               — Hooks custom (.js)
+```
+
+### Ejemplo de plugin.json válido
+
+```json
+{
+  "name": "facturacion-sat",
+  "version": "1.0.0",
+  "description": "Skills y agentes para integración con el SAT mexicano.",
+  "author": "Equipo Fiscal",
+  "license": "MIT",
+  "skills": ["habilidades/cfdi-4"],
+  "agents": ["agentes/validador-sat.md"],
+  "rules": ["reglas/cumplimiento-sat.md"]
+}
+```
+
+---
+
+## Notas de gobernanza
+
+- Los plugins instalados en `_userland/` nunca modifican los componentes del sistema base.
+- Los hooks de plugins con `blocking: true` requieren aprobación antes de activarse
+  (ver `reglas/gobernanza.md`).
+- Los plugins auto-generados por `/swl:evolucionar` se instalan primero aquí como
+  período de prueba antes de promoverse al sistema base.

package/comandos/swl/reflect-skills.md

@@ -0,0 +1,125 @@
+---
+name: swl:reflect-skills
+description: Analiza el historial de sesiones de Claude Code para detectar patrones de uso repetidos que sean candidatos a convertirse en nuevos skills, comandos o agentes del sistema SWL. Inspirado en el patrón Reflect de claude-reflect (Karpathy). Sin dependencias externas.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+---
+
+# /swl:reflect-skills — Descubrimiento de skills emergentes
+
+Analiza los archivos JSONL del historial de Claude Code (`~/.claude/projects/<proyecto>/*.jsonl`) y la cola de feedback del usuario (`.planning/evolucion/feedback-queue.jsonl`) para detectar intenciones repetidas que podrían formalizarse como skills, comandos o agentes nuevos del sistema SWL.
+
+Complementa a `/swl:aprender` (que trabaja sobre la sesión actual) y a `/swl:evolucionar` (que opera sobre metadatos de agentes/skills existentes). Este comando mira el **historial acumulado** y propone componentes emergentes basándose en la frecuencia real de uso.
+
+## Cuándo usar este comando
+
+- Cada 2-4 semanas, para identificar nuevos dominios donde el usuario está pidiendo cosas recurrentes sin un skill dedicado.
+- Antes de publicar una versión MINOR del sistema SWL, para decidir si vale la pena formalizar algún patrón emergente.
+- Después de un proyecto grande, para extraer el know-how ganado como componentes reutilizables.
+- Cuando `auto-evolucion.js` reporte alta densidad de acciones sin skill asociado.
+
+## Cuándo NO usar
+
+- Para extraer aprendizajes de la sesión actual → usar `/swl:aprender`.
+- Para mejorar un agente/skill existente basado en métricas de fallo → usar `/swl:evolucionar`.
+- Para actualizar el perfil del usuario → usar el agente `perfilador-usuario-swl`.
+- Para buscar conocimiento ya registrado → usar `/swl:wiki query` o `Skill("memoria-busqueda")`.
+
+## Flujo
+
+### Paso 1 — Ejecutar el análisis
+
+Corre el script determinista que lee los JSONL del proyecto actual y clusteriza intenciones:
+
+```bash
+node scripts/reflect-skills.js --ventana 30 --umbral 3
+```
+
+Parámetros:
+- `--ventana N` — días de historial a analizar (default: 30)
+- `--umbral N` — mínimo de ocurrencias para reportar cluster (default: 3)
+- `--json` — salida estructurada en JSON
+
+El script produce:
+- Reporte textual en stdout
+- Archivo estructurado en `.planning/evolucion/reflect-skills-report.json`
+
+### Paso 2 — Leer y clasificar los candidatos
+
+Lee el reporte generado y clasifica cada candidato en una de estas categorías:
+
+| Categoría | Acción recomendada |
+|-----------|-------------------|
+| Patrón técnico nuevo (ej. "integrar redis cache") | Proponer como skill en el dominio correspondiente (`backend-`, `frontend-`, etc.) |
+| Operación repetida con pasos fijos (ej. "ejecuta pruebas de carga") | Proponer como comando `/swl:<nombre>` |
+| Tarea que cruza varios agentes (ej. "audita dependencias + actualiza CHANGELOG") | Proponer como flujo del `orquestador-swl` |
+| Corrección del usuario repetida | Enviar al `perfilador-usuario-swl` |
+| Falso positivo (prompt genérico, ruido) | Ignorar y anotar en la bitácora del comando |
+
+### Paso 3 — Validar con el usuario
+
+Presenta al usuario los top 3-5 candidatos con:
+- Nombre propuesto y tipo (skill / comando / flujo)
+- Cantidad de ocurrencias en la ventana
+- 2-3 ejemplos de prompts reales
+- Justificación de por qué formalizarlo
+
+**Esperar aprobación explícita** antes de generar componentes. No crear skills automáticamente sin confirmación.
+
+### Paso 4 — Crear los componentes aprobados
+
+Para cada candidato aprobado:
+
+- **Skill**: invocar `/swl:crear-skill` con el dominio correspondiente.
+- **Comando**: delegar al agente `orquestador-swl` para crear `comandos/swl/<nombre>.md` siguiendo la plantilla.
+- **Flujo**: delegar al `auto-evolucion-swl` para proponer evolución al orquestador.
+
+Registrar la decisión en `.planning/APRENDIZAJES.md` bajo la sección **Patrones emergentes**.
+
+### Paso 5 — Cerrar ciclo
+
+- Actualizar `CLAUDE.md` si se agregó un componente al sistema (tabla de comandos, skills por dominio).
+- Bumpar versión del sistema si procede (MINOR para skill/comando nuevo, ver `git-workflow.md`).
+- Commit atómico con mensaje: `feat(sistema): agrega <componente> desde /swl:reflect-skills`.
+
+## Salida esperada
+
+Reporte legible como:
+
+```
+━━━ Reflect Skills — análisis de historial ━━━
+  Ventana: últimos 30 días
+  Prompts analizados: 412
+  Umbral de repetición: 3
+
+  2 candidato(s) detectado(s):
+
+  1. [SKILL] redis-cache-integrar
+     Intención: "integrar redis" (5×)
+     Motivo: Intención "integrar redis" repetida 5× → candidato a skill que encapsule el patrón.
+     Ejemplos:
+       • integra redis como cache layer en el endpoint de productos
+       • integrar redis con invalidation por tags
+       • quiero integrar redis stream para workers
+
+  2. [COMANDO] release-verificar
+     Intención: "verificar release" (4×)
+     Motivo: Verbo operativo "verificar" repetido 4× → candidato a automatización por comando slash.
+     Ejemplos:
+       • verifica que el release esté listo
+       • verificar release antes de publicar
+       • verificar release 5.10.5
+
+  Feedback del usuario capturado: 7 entradas
+    - correccion: 3
+    - preferencia: 2
+    - memoria: 2
+  → Revisar con perfilador-usuario-swl y /swl:aprender.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+## Notas
+
+- El clustering es heurístico (tokens + verbos de acción), **no semántico con embeddings**. Busca simplicidad y zero-deps sobre precisión absoluta.
+- Si un candidato tiene nombre similar a un skill/comando existente, revisar primero si se puede **extender** en lugar de crear uno nuevo.
+- El comando NO escribe a APRENDIZAJES.md automáticamente — el usuario decide qué formalizar.
+- Para el modo con embeddings (SentenceTransformers + ChromaDB), ver `Skill("wiki-conocimiento")` y `/swl:wiki` que ya implementan el patrón Karpathy completo.