@saulwade/swl-ses 1.0.0

package/comandos/swl/auditar-deps.md

@@ -0,0 +1,134 @@
+---
+name: swl:auditar-deps
+description: Auditoría completa de dependencias del proyecto. Escanea package.json, requirements.txt y pyproject.toml. Detecta dependencias con vulnerabilidades conocidas (CVE), dependencias desactualizadas y dependencias sin usar. Genera reporte priorizado. Flags: --fix (actualiza menores automáticamente), --json.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
+---
+
+# /swl:auditar-deps — Auditoría de dependencias
+
+Eres el auditor de dependencias del proyecto. Analizas exhaustivamente todas las dependencias e identificas riesgos de seguridad, deuda técnica y desperdicio.
+
+**Carga**: `Skill("dependencias-auditoria")` — contiene las categorías de riesgo (CVEs, licencias, abandonadas, desactualizadas), herramientas por stack, proceso paso a paso y plantilla de reporte. Delega toda lógica de auditoría y criterios de severidad al skill.
+
+## Cuándo usar este comando
+
+- Al inicio de un proyecto heredado
+- Antes de hacer un release a producción
+- Mensualmente como mantenimiento preventivo
+- Cuando CI/CD reporta fallos de auditoría de seguridad
+- Cuando se agrega una dependencia nueva
+
+## Flags soportados
+
+```
+--fix       Actualiza automáticamente dependencias PATCH y MINOR sin breaking changes.
+            Requiere confirmación antes de escribir. NUNCA actualiza MAJOR.
+--json      Genera reporte también en formato JSON (audit-report.json).
+```
+
+## Paso 0 — Detección de ecosistemas
+
+Detecta qué ecosistemas están presentes:
+
+```bash
+ls package.json package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
+ls requirements.txt requirements-dev.txt pyproject.toml setup.py Pipfile 2>/dev/null
+ls Gemfile go.mod Cargo.toml composer.json 2>/dev/null
+```
+
+Reporta ecosistemas detectados. Soporte completo para Node.js y Python; para otros, reporta verificaciones disponibles.
+
+## Paso 1 — Auditoría de vulnerabilidades (CVEs)
+
+Ejecuta los scanners del skill (`Skill("dependencias-auditoria")` seccion "Herramientas y comandos por stack"):
+
+- **Node.js**: `npm audit --json`
+- **Python**: `pip-audit` (preferido) o `safety check`
+
+Clasifica por severidad CVSS según la tabla del skill (Critica 9.0-10.0, Alta 7.0-8.9, Media 4.0-6.9, Baja 0.1-3.9).
+
+Si las herramientas no están disponibles, reportar exactamente qué falta y comandos de instalación.
+
+## Paso 2 — Dependencias desactualizadas
+
+- **Node.js**: `npm outdated --json`
+- **Python**: `pip list --outdated --format=json`
+
+Clasifica en PATCH/MINOR/MAJOR. Marca como "DEUDA TECNICA CRITICA" si hay 2+ versiones MAJOR de retraso. Marca "POSIBLEMENTE ABANDONADA" si sin actualizaciones en 1+ año.
+
+## Paso 3 — Dependencias sin usar
+
+- **Node.js**: `npx depcheck --json`
+- **Python**: análisis heurístico de imports vs paquetes instalados
+
+Nota: la detección en Python es heurística. Siempre verificar manualmente antes de eliminar.
+
+## Paso 4 — Análisis de licencias
+
+Usa las herramientas del skill:
+- **Node.js**: `npx license-checker --json`
+- **Python**: `pip-licenses --format=json`
+
+Identifica licencias problemáticas según la tabla del skill (GPL, AGPL, LGPL, SSPL).
+
+## Paso 5 — Verificación de lockfile
+
+- `requirements.txt` sin pins exactos -> ADVERTENCIA
+- `package.json` con rangos amplios en producción -> ADVERTENCIA
+- Lockfile desincronizado con manifiesto -> ERROR
+
+## Paso 6 — Generar reporte
+
+Escribe `AUDIT-REPORT.md` usando la plantilla del skill (`Skill("dependencias-auditoria")` seccion "Plantilla de reporte"). Incluye:
+
+- Resumen ejecutivo con tabla de hallazgos
+- Score de salud: `100 - (criticas x 25) - (altas x 10) - (medias x 3) - (bajas x 1)`, minimo 0
+- Hallazgos priorizados (P1: acción inmediata -> P5: revisión de arquitectura)
+- Comandos de corrección específicos
+
+Si `--json`, escribir también `audit-report.json`.
+
+## Paso 7 — Aplicar fixes automáticos (si --fix)
+
+Presenta lista de actualizaciones PATCH y MINOR que se aplicarán. Muestra también lo que NO se actualizará (MAJOR). Espera confirmación ("confirmo").
+
+```bash
+npm update 2>&1        # Node.js
+pip install --upgrade [paquetes] 2>&1  # Python
+```
+
+Después de aplicar, re-ejecutar auditoría de vulnerabilidades para verificar correcciones.
+
+## Paso 8 — Reporte al usuario
+
+```
+=== Auditoría de dependencias completada ===
+
+Ecosistemas auditados: [lista]
+Total dependencias analizadas: [N]
+
+Hallazgos:
+  Vulnerabilidades CRITICAS:    [N]  (acción hoy)
+  Vulnerabilidades ALTAS:       [N]  (esta semana)
+  Vulnerabilidades MEDIAS:      [N]  (este sprint)
+  Vulnerabilidades BAJAS:       [N]  (backlog)
+  Desactualizadas:              [N]  ([N] major, [N] minor, [N] patch)
+  Sin usar:                     [N]
+  Problemas de licencia:        [N]
+
+Score de salud: [N]/100
+Reportes: AUDIT-REPORT.md [audit-report.json si aplica]
+
+Próximos pasos:
+  1. [acción más urgente]
+  2. [segunda acción]
+```
+
+## Reglas de comportamiento
+
+- NUNCA eliminar dependencias automáticamente — solo reportar y sugerir.
+- NUNCA aplicar actualizaciones MAJOR con `--fix`. Siempre requieren revisión humana.
+- Vulnerabilidades CRITICAS al inicio del reporte, no sepultadas en una lista.
+- Score de salud objetivo — no inflarlo.
+- Si las herramientas no están disponibles, reportar qué falta, no simular resultados.
+- Si `--fix` rompe tests, reportar y sugerir `git checkout` de archivos de dependencias.

package/comandos/swl/autoresearch.md

@@ -0,0 +1,170 @@
+---
+name: swl:autoresearch
+description: Ejecuta el loop de auto-mejora iterativa Autoresearch sobre un skill o agente. Crea o usa un checklist de evaluación (3-6 items binarios ponderados), obtiene baseline score, ejecuta mutaciones atómicas (una a la vez) evaluando contra el checklist, y decide keep/revert por round hasta alcanzar 95%+ x3. Flags disponibles: --skill=[nombre], --agente=[nombre], --max-rounds=[N], --target=[N], --dry-run, --checklist=[path].
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
+---
+
+# /swl:autoresearch — Loop de auto-mejora iterativa de skills
+
+Eres el motor de Autoresearch del sistema SWL. Mejoras skills y agentes de forma medible e iterativa: defines un checklist de calidad, obtienes un baseline, y ejecutas un loop de mutaciones atómicas donde cada cambio se evalúa y se mantiene solo si mejora el score.
+
+Este comando es distinto a `/swl:evolucionar`: donde evolucionar analiza evidencia histórica, autoresearch ejecuta un **loop cerrado de mejora medible** contra un checklist concreto.
+
+## Cuándo usar este comando
+
+- Cuando un skill produce outputs de baja calidad de forma consistente
+- Cuando se quiere elevar la calidad de un skill antes de una release
+- Cuando `auto-evolucion-swl` identifica un candidato para mejora iterativa
+- Después de crear un skill nuevo para calibrarlo contra criterios de calidad
+
+## Flags soportados
+
+```
+--skill=[nombre]        Skill a mejorar (busca en habilidades/[nombre]/SKILL.md)
+--agente=[nombre]       Agente a mejorar (busca en agentes/[nombre].md)
+--max-rounds=[N]        Máximo de iteraciones del loop (default: 10)
+--target=[N]            Score objetivo en % (default: 95)
+--dry-run               Analizar y crear checklist sin ejecutar mutaciones
+--checklist=[path]      Ruta a checklist existente
+```
+
+**Nota**: Se debe pasar `--skill` o `--agente`, no ambos. Si no se pasa ninguno, preguntar al usuario.
+
+## Paso 0 — Parseo de flags y carga de habilidades
+
+Lee los flags. Determina alcance y configuración.
+
+Carga obligatoria:
+```
+Skill("autoresearch")
+```
+
+El skill define TODO el protocolo: el loop de mutación (pasos 1-5), tipos de mutación con riesgos, fórmula de priorización, condiciones de salida, umbrales de score, formato de checklist, formato de reporte por iteración, anti-patrones y la integración con auto-evolución SWL.
+
+Reporta configuración:
+```
+=== Autoresearch — Configuración ===
+Objetivo: [skill/agente] [nombre]
+Max rounds: [N]
+Target score: [N]%
+Modo: [ejecutar | dry-run]
+Checklist: [existente: path | por crear]
+```
+
+## Paso 1 — Lectura del artefacto objetivo
+
+Lee el skill o agente completo. Identifica: versión actual, secciones principales, reglas existentes, ejemplos de código, anti-patrones documentados.
+
+## Paso 2 — Crear o cargar checklist
+
+Si se pasó `--checklist=[path]`, cargar y validar (3-6 items, formato correcto).
+
+Si ya existe checklist previo para este skill/agente, preguntar si usarlo o crear uno nuevo.
+
+Si no existe, crearlo siguiendo el protocolo del skill: identificar output típico, extraer 3-5 reglas más críticas, convertir en criterios binarios verificables, asignar pesos (1-5), definir método de verificación. Presentar al usuario para aprobación antes de continuar.
+
+Guardar checklist:
+- Skills: `habilidades/[nombre]/recursos/checklist-autoresearch.md`
+- Agentes: `.planning/checklists/[nombre]-checklist.md`
+
+## Paso 3 — Definir caso de prueba
+
+Proponer un prompt concreto que active las reglas principales del skill. Debe ser representativo, reproducible y concreto. Pedir aprobación al usuario.
+
+## Paso 4 — Obtener baseline score
+
+Ejecutar el skill con el caso de prueba, evaluar contra cada item del checklist, calcular score ponderado usando el script:
+
+```bash
+node habilidades/autoresearch/scripts/calcular-score.js '[JSON con items evaluados]'
+```
+
+Si `--dry-run`, termina aquí con recomendaciones de qué mutar primero.
+
+Si el baseline ya es >= target, reportar que no se requiere autoresearch.
+
+## Paso 5 — Loop de mutación
+
+Ejecutar el loop siguiendo el protocolo completo del skill. Para cada round:
+
+1. **Seleccionar item target** — usar la fórmula de priorización del skill (peso x no_cumple x factor_tipo)
+2. **Proponer mutación atómica** — UN solo cambio, siguiendo los tipos de mutación del skill (agregar > refinar > reordenar > eliminar)
+3. **Aplicar** la mutación con Edit. Registrar estado previo para poder revertir.
+4. **Re-evaluar** contra el checklist con el mismo caso de prueba
+5. **Decidir keep/revert** — si score >= anterior: KEEP; si baja: REVERT
+6. **Registrar** en changelog del loop
+7. **Verificar condiciones de salida** del skill:
+   - 95%+ x 3 consecutivas: ÉXITO
+   - 3 reverts consecutivos: ESTANCAMIENTO
+   - Score baja 2 rounds seguidos: DEGRADACIÓN (revertir al mejor score)
+   - Max rounds alcanzado: PLATEAU
+
+## Paso 6 — Reporte final
+
+```
+=== Reporte Autoresearch — [nombre] ===
+
+Fecha: [fecha]
+Rounds ejecutados: [N]
+Score: [baseline]% → [final]%
+Mutaciones KEEP: [N] | Mutaciones REVERT: [N]
+Resultado: [ÉXITO | PLATEAU | ESTANCAMIENTO | DEGRADACIÓN]
+
+### Mutaciones aplicadas (en orden)
+1. [tipo]: [descripción] — Score [X]% → [Y]%
+
+### Mutaciones revertidas
+1. [tipo]: [descripción] — Razón: [por qué empeoró]
+
+### Score final por item
+| # | Criterio | Peso | check |
+|---|----------|------|-------|
+
+### Recomendaciones
+- [qué hacer si no se alcanzó el target]
+```
+
+## Paso 7 — Versionado, marcado de evolución y persistencia
+
+Si el score mejoró respecto al baseline:
+1. Actualizar versión del skill/agente (< 10 pts: PATCH, >= 10 pts: MINOR)
+2. **OBLIGATORIO — Marcar como evolucionado ejecutando este comando Bash**:
+   ```bash
+   node -e "
+   const { markAsEvolved } = require('./hooks/lib/evolution-tracker');
+   const pkg = require('./package.json');
+   const r = markAsEvolved('[RUTA_ARCHIVO_MODIFICADO]', {
+     from: pkg.version,
+     by: 'autoresearch',
+     rounds: [N_ROUNDS],
+     score: '[BASELINE]% → [FINAL]%',
+     note: '[descripción breve de las mutaciones]'
+   });
+   console.log(r.marked ? 'Marcado como evolucionado' : 'Error: ' + r.error);
+   "
+   ```
+   Reemplazar los placeholders entre corchetes con los valores reales.
+   Si el comando Bash no está disponible, agregar manualmente en el frontmatter:
+   ```yaml
+   evolved: true
+   evolved-from: "[versión actual del sistema]"
+   evolved-at: "[fecha YYYY-MM-DD]"
+   evolved-by: "autoresearch"
+   evolved-rounds: [N rounds ejecutados]
+   evolved-score: "[baseline]% → [final]%"
+   ```
+   **SIN ESTE MARCADO, LAS MUTACIONES SE PERDERÁN EN LA PRÓXIMA ACTUALIZACIÓN.**
+3. Guardar reporte en `.planning/autoresearch/[nombre]-[fecha].md`
+4. Registrar en APRENDIZAJES.md las mutaciones más impactantes
+5. Actualizar el checklist si se descubrieron items nuevos
+
+## Reglas de comportamiento
+
+- NUNCA ejecutar mutaciones sin checklist aprobado por el usuario
+- NUNCA cambiar más de una cosa por round — regla más importante del protocolo
+- NUNCA modificar el checklist durante el loop
+- SIEMPRE revertir si el score baja — sin excepciones
+- SIEMPRE mostrar el diff concreto antes de cada mutación
+- Si después de 3 rounds sin mejora, preguntar al usuario si continuar o parar
+- El caso de prueba NO cambia durante el loop
+- Mantener log completo del loop para auditoría

package/comandos/swl/ayuda.md

@@ -0,0 +1,224 @@
+---
+name: swl:ayuda
+description: Sistema de ayuda interactivo del SWL. Sin argumentos muestra el catálogo completo de comandos agrupado por categoría. Con nombre de comando muestra su detalle y uso. Con keyword busca en comandos, skills y agentes relacionados. Punto de entrada para descubrir capacidades del sistema.
+allowed_tools: ["Read", "Bash", "Grep", "Glob"]
+---
+
+# /swl:ayuda — Sistema de ayuda interactivo
+
+Punto de entrada para descubrir y entender las capacidades del sistema SWL.
+Tres modos de uso según el argumento recibido.
+
+## Uso
+
+```
+/swl:ayuda                    — Catálogo completo agrupado por categoría
+/swl:ayuda <comando>          — Detalle de un comando específico (ej: /swl:ayuda release)
+/swl:ayuda <keyword>          — Buscar en comandos, skills y agentes por tema
+```
+
+---
+
+## Modo 1 — Sin argumentos: catálogo completo
+
+Presentar TODOS los comandos `/swl:*` agrupados por categoría funcional.
+Formato: tabla compacta con nombre, descripción corta y flags principales.
+
+### Categorías y sus comandos
+
+#### Flujo de desarrollo (ciclo GSD)
+
+| Comando | Descripción |
+|---------|------------|
+| `/swl:nuevo-proyecto` | Iniciar proyecto con PROYECTO.md y roadmap |
+| `/swl:discutir-fase <n>` | Recopilar contexto antes de planificar |
+| `/swl:planear-fase <n>` | Crear PLAN.md con vertical slices |
+| `/swl:ejecutar-fase <n>` | Ejecutar plan con commits atómicos |
+| `/swl:verificar` | Verificar implementación contra spec |
+| `/swl:brainstorm "tema"` | Brainstorming estructurado → spec → plan |
+
+#### Revisión y calidad
+
+| Comando | Descripción |
+|---------|------------|
+| `/swl:revisar [stack\|archivo]` | Revisión de código por tecnología (auto-detect) |
+| `/swl:revisar-impacto` | Análisis de blast radius y risk score |
+| `/swl:evaluar-skill [nombre]` | Evaluación PluginEval de 2 capas con badge |
+| `/swl:salud` | Diagnóstico de integridad del sistema |
+| `/swl:auditar-deps` | Auditoría de dependencias (CVEs) |
+
+#### Aprendizaje y evolución
+
+| Comando | Descripción |
+|---------|------------|
+| `/swl:aprender` | Extraer aprendizajes de la sesión |
+| `/swl:evolucionar` | Auto-evolución de agentes/skills |
+| `/swl:autoresearch --skill=X` | Loop de auto-mejora iterativa |
+| `/swl:crear-skill` | Crear nuevo skill con guía interactiva |
+
+#### Gestión de contexto y sesiones
+
+| Comando | Descripción |
+|---------|------------|
+| `/swl:checkpoint` | Guardar estado para continuar después |
+| `/swl:compactar` | Reducir contexto preservando info clave |
+| `/swl:contexto [dev\|review\|research]` | Cambiar modo de desarrollo |
+| `/swl:sesiones [list\|resume\|wake]` | Historial y retoma de sesiones |
+| `/swl:modelo [haiku\|sonnet\|opus]` | Consultar o forzar modelo |
+
+#### Métricas y monitoreo
+
+| Comando | Descripción |
+|---------|------------|
+| `/swl:metricas [resumen\|detalle]` | Métricas de sesión (tokens, costo) |
+| `/swl:dashboard [today\|stats]` | Dashboard histórico multi-sesión |
+| `/swl:mcp-status` | Estado de servidores MCP conectados |
+
+#### Instalación y sistema
+
+| Comando | Descripción |
+|---------|------------|
+| `/swl:instalar` | Instalar SWL desde Claude Code |
+| `/swl:actualizar` | Actualizar SWL a última versión |
+| `/swl:release [--tipo=X]` | Ciclo de release SemVer |
+| `/swl:plugins [list\|install]` | Gestionar plugins de _userland/ |
+| `/swl:gateway` | Configurar gateway multi-plataforma |
+| `/swl:cron` | Gestionar tareas programadas |
+
+#### Exploración y conocimiento
+
+| Comando | Descripción |
+|---------|------------|
+| `/swl:skill-search [keyword]` | Buscar skills por keyword o dominio |
+| `/swl:wiki [init\|query\|ingest]` | Wiki de conocimiento del proyecto |
+| `/swl:mapear-codebase` | Analizar codebase existente |
+| `/swl:instintos [list\|add\|promote]` | Gestionar instintos YAML |
+| `/swl:ayuda [comando\|keyword]` | Esta ayuda |
+
+### Después de mostrar las tablas
+
+Agregar al final:
+
+```
+Tip: usa /swl:ayuda <nombre> para ver el detalle de un comando.
+     usa /swl:ayuda <keyword> para buscar por tema (ej: /swl:ayuda testing).
+```
+
+---
+
+## Modo 2 — Con nombre de comando: detalle específico
+
+El argumento coincide con un nombre de comando existente (con o sin prefijo `swl:`).
+
+### Paso 1 — Resolver el nombre
+
+```bash
+# Normalizar: quitar prefijo /swl: o swl: si lo tiene
+# Buscar archivo en comandos/swl/
+ls "comandos/swl/${NOMBRE}.md" 2>/dev/null
+```
+
+Si no existe: cambiar a Modo 3 (búsqueda por keyword).
+
+### Paso 2 — Leer el comando
+
+```
+Read("comandos/swl/${NOMBRE}.md")
+```
+
+### Paso 3 — Presentar resumen estructurado
+
+Extraer del archivo y presentar en formato compacto:
+
+```
+📌 /swl:{nombre} — {description del frontmatter}
+
+Uso:
+  /swl:{nombre} {argumentos y flags}
+
+Cuándo usar:
+  - {lista breve de situaciones}
+
+Pasos principales:
+  1. {resumen de cada paso, no el paso completo}
+
+Comandos relacionados:
+  - /swl:{relacionado1} — {descripción}
+  - /swl:{relacionado2} — {descripción}
+```
+
+Los comandos relacionados se infieren por categoría funcional (misma sección en
+las tablas del Modo 1). No inventar relaciones — solo las de la misma categoría.
+
+---
+
+## Modo 3 — Con keyword: búsqueda transversal
+
+El argumento NO coincide con un nombre de comando. Buscar en 3 fuentes.
+
+### Paso 1 — Buscar en comandos
+
+```bash
+grep -ril "${KEYWORD}" comandos/swl/ 2>/dev/null | head -10
+```
+
+### Paso 2 — Buscar en skills
+
+```bash
+grep -ril "${KEYWORD}" habilidades/*/SKILL.md 2>/dev/null | head -10
+```
+
+### Paso 3 — Buscar en agentes
+
+```bash
+grep -il "${KEYWORD}" agentes/*.md 2>/dev/null | head -10
+```
+
+### Paso 4 — Presentar resultados agrupados
+
+```
+Resultados para "{keyword}":
+
+Comandos:
+  /swl:{nombre}  — {description}
+  ...
+
+Skills:
+  {nombre}  — {description}
+  Para cargar: Skill("{nombre}")
+  ...
+
+Agentes:
+  {nombre}  — {description}
+  ...
+
+{N} resultados en total.
+```
+
+Si no hay resultados en ninguna fuente:
+
+```
+No se encontraron resultados para "{keyword}".
+
+Sugerencias:
+- Verifica la ortografía
+- Prueba con sinónimos (ej: "test" en lugar de "prueba")
+- Usa /swl:ayuda sin argumentos para ver el catálogo completo
+- Usa /swl:skill-search {keyword} para búsqueda detallada de skills
+```
+
+---
+
+## Reglas de comportamiento
+
+- Este comando es de **solo lectura**. NUNCA modifica archivos.
+- Las tablas del Modo 1 se generan desde las constantes de este archivo,
+  NO leyendo dinámicamente cada comando (evita ~34 reads innecesarios).
+- El Modo 2 SÍ lee el archivo del comando para dar detalle — un solo Read.
+- El Modo 3 usa grep para buscar — máximo 3 comandos grep.
+- Si el usuario escribe `/swl:ayuda` seguido de algo ambiguo que podría ser
+  tanto un comando como un keyword (ej: "release"), priorizar Modo 2 (comando).
+- Presentar la información de forma concisa. No repetir el contenido completo
+  del archivo del comando — resumir los pasos y mostrar lo esencial.
+- Los tips de navegación al final de cada modo son obligatorios — guían al
+  usuario hacia la exploración progresiva.

package/comandos/swl/brainstorm.md

@@ -0,0 +1,50 @@
+---
+description: Inicia una sesión de brainstorming estructurado para diseñar una feature o solución
+---
+
+# /swl:brainstorm
+
+Inicia una sesión de brainstorming estructurado siguiendo los 7 pasos de la habilidad
+`brainstorming`: explorar contexto, preguntas clarificadoras, propuesta de enfoques,
+presentación de diseño, spec escrita, auto-revisión y transición a plan.
+
+## Uso
+
+```
+/swl:brainstorm                     — Brainstorming general (pregunta al usuario el tema)
+/swl:brainstorm "tema o feature"    — Brainstorming sobre un tema específico
+```
+
+## Comportamiento
+
+```
+1. Cargar Skill("brainstorming")
+2. Si se proporcionó tema en el argumento del comando: usarlo como punto de partida
+   Si no: preguntar "¿Sobre qué quieres hacer brainstorming?"
+3. Ejecutar el flujo obligatorio del skill:
+   Explorar -> Preguntar -> Proponer -> Diseñar -> Spec -> Revisar -> Plan
+4. Guardar spec en .planning/specs/YYYY-MM-DD-{tema}-spec.md
+5. Al terminar, ofrecer transición a /swl:planear-fase
+```
+
+## Salidas generadas
+
+| Artefacto | Ubicación | Condición |
+|-----------|-----------|-----------|
+| Spec de la feature | `.planning/specs/YYYY-MM-DD-{tema}-spec.md` | Siempre (Paso 5) |
+| Visualización HTML | `.planning/visual/YYYY-MM-DD-{tema}.html` | Solo si el usuario lo solicita |
+
+## Regla de obligatoriedad
+
+NUNCA saltar el brainstorming si el usuario pide "implementa X directamente".
+Responder: "Antes de implementar, hagamos un brainstorming rápido (15-30 min).
+El diseño previo previene retrabajo y mejora la calidad del resultado final."
+
+El brainstorming puede ser rápido — el Paso 2 puede resolverse en 2-3 intercambios,
+y el Paso 3 puede ser una tabla concisa. Lo que nunca debe ser cero es el diseño previo.
+
+## Relación con otros comandos
+
+- Después de `/swl:brainstorm`: invocar `/swl:planear-fase` con la spec como input
+- Si el contexto ya fue discutido: `/swl:planear-fase` puede usarse directamente
+- Si la spec revela un ADR necesario: invocar el agente `arquitecto-swl`