@saulwade/swl-ses 1.0.0

package/comandos/swl/configurar-ci.md

@@ -0,0 +1,227 @@
+---
+name: swl:configurar-ci
+description: Instala y gestiona los workflows CI/CD de swl-ses en proyectos de usuarios. Subcomandos init (flujo interactivo completo), status (muestra qué está instalado) y uninstall (quita los workflows). Para setup automatizado de GitHub Actions con revisión de seguridad Claude, CI genérico y release automatizado.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
+user-invocable: true
+version: "1.0.0"
+---
+
+# /swl:configurar-ci — Setup de CI/CD en tu proyecto
+
+Orquesta la instalación de los workflows GitHub Actions de swl-ses en el proyecto donde estés trabajando.
+
+## Subcomandos
+
+| Subcomando | Descripción |
+|-----------|-------------|
+| `init` | Flujo interactivo completo (default) |
+| `status` | Muestra qué workflows están instalados y qué secrets se necesitan |
+| `uninstall` | Quita los workflows SWL del proyecto |
+
+Si se invoca sin subcomando, ejecutar `init`.
+
+---
+
+## /swl:configurar-ci init
+
+Flujo interactivo paso a paso. Detecta el proyecto en el directorio actual.
+
+### Paso 1 — Verificar contexto
+
+```bash
+node -e "const p=require('./package.json');console.log('Proyecto:',p.name,'v'+p.version)" 2>/dev/null || echo "Sin package.json"
+ls .github/workflows/ 2>/dev/null && echo "Directorio .github/workflows existe" || echo "Directorio .github/workflows no existe"
+```
+
+Mostrar al usuario qué se detectó y confirmar que es el proyecto correcto.
+
+### Paso 2 — Preguntar qué workflows instalar (si TTY)
+
+```
+¿Qué workflows quieres instalar? (Enter para activar, espacio para omitir)
+
+[x] swl-security.yml — Revisión de seguridad con Claude en cada PR
+    REQUIERE: secret CLAUDE_API_KEY en GitHub Settings → Secrets
+
+[x] swl-ci.yml — CI estándar (lint + test) en push y PRs
+    Sin secrets adicionales
+
+[ ] release-please.yml — Releases automáticos desde conventional commits
+    Sin secrets adicionales. Requiere conventional commits.
+```
+
+Si el usuario omite `init` e invoca con flags directos, respetar esos flags sin preguntar:
+- `--with-security` / `--no-security`
+- `--with-ci` / `--no-ci`
+- `--with-release-please`
+- `--dry-run`
+- `--force`
+
+### Paso 3 — Copiar workflows
+
+Invocar `scripts/lib/configurar-ci.js` con las opciones seleccionadas:
+
+```javascript
+const { init } = require('./scripts/lib/configurar-ci');
+const resultado = init({
+  withSecurity: true,
+  withCi: true,
+  withReleasePlease: false,
+  // dryRun: true,  // con --dry-run
+});
+```
+
+Si hay archivos existentes en `resultado.existentes`, preguntar:
+```
+Los siguientes workflows ya existen en .github/workflows/:
+  - swl-security.yml
+¿Sobreescribir? (s/N)
+```
+
+Si el usuario dice que sí, volver a llamar `init` con `force: true`.
+
+### Paso 4 — Configurar CLAUDE_API_KEY (solo si se instaló swl-security.yml)
+
+Preguntar:
+```
+swl-security.yml requiere el secret CLAUDE_API_KEY en GitHub.
+
+¿Quieres configurarlo ahora con gh CLI? (s/N)
+```
+
+Si dice sí, verificar que `gh` esté disponible:
+
+```bash
+gh auth status 2>&1 | head -3
+```
+
+Si está autenticado, guiar al usuario para que pegue su API key (sin almacenarla):
+
+```
+Pega tu CLAUDE_API_KEY (la input estará oculta):
+```
+
+Luego ejecutar:
+```bash
+gh secret set CLAUDE_API_KEY
+# gh leerá el valor desde stdin de forma segura
+```
+
+Si `gh` no está disponible o el usuario dice que no, mostrar el link para hacerlo manualmente:
+```
+Para configurar manualmente:
+  https://github.com/<owner>/<repo>/settings/secrets/actions/new
+  Nombre: CLAUDE_API_KEY
+  Valor:  tu clave de https://console.anthropic.com
+```
+
+### Paso 5 — Configurar branch protection (opcional)
+
+Preguntar:
+```
+¿Aplicar branch protection en main?
+Esto requiere gh CLI autenticado y permisos de admin en el repo.
+(s/N)
+```
+
+Si dice sí:
+```bash
+node scripts/configurar-branch-protection.js --dry-run
+# Mostrar el plan al usuario
+# Si confirma:
+node scripts/configurar-branch-protection.js
+```
+
+**NOTA**: el script de branch protection vive en el repo swl-ses. Si el usuario está en su propio proyecto, advertir que debe copiar el script o usar la guía manual de GitHub Settings → Branches.
+
+### Paso 6 — Resumen final
+
+```
+Setup completado:
+  ✓ .github/workflows/swl-security.yml
+  ✓ .github/workflows/swl-ci.yml
+  - release-please.yml (omitido)
+
+Próximos pasos:
+  1. git add .github/workflows/ && git commit -m "ci: agregar workflows CI/CD swl-ses"
+  2. Abrir un PR para ver el workflow en acción
+  3. Verificar que CLAUDE_API_KEY esté en GitHub Settings → Secrets
+```
+
+---
+
+## /swl:configurar-ci status
+
+Muestra el estado actual de los workflows SWL en el proyecto.
+
+```javascript
+const { status } = require('./scripts/lib/configurar-ci');
+const resultado = status();
+```
+
+Formato de salida:
+
+```
+Workflows SWL en .github/workflows/:
+
+Instalados:
+  ✓ swl-security.yml
+    Secrets requeridos: CLAUDE_API_KEY (verificar en GitHub Settings)
+  ✓ swl-ci.yml
+    Sin secrets adicionales
+
+No instalados:
+  - release-please.yml
+
+Para instalar los faltantes: /swl:configurar-ci init
+```
+
+Si `gh` está disponible, intentar verificar si el secret existe:
+```bash
+gh secret list 2>/dev/null | grep CLAUDE_API_KEY
+```
+
+---
+
+## /swl:configurar-ci uninstall
+
+Elimina los workflows gestionados por swl-ses. No toca branch protection ni otros workflows.
+
+```javascript
+const { uninstall } = require('./scripts/lib/configurar-ci');
+
+// Primero listar qué se eliminaría (sin confirmar)
+const plan = uninstall({ confirmar: false });
+```
+
+Mostrar:
+```
+Los siguientes workflows serán eliminados:
+  - .github/workflows/swl-security.yml
+  - .github/workflows/swl-ci.yml
+
+¿Confirmar? (s/N)
+```
+
+Si el usuario confirma:
+```javascript
+const resultado = uninstall({ confirmar: true });
+```
+
+Mostrar confirmación de archivos eliminados. Recordar que la branch protection NO se toca.
+
+---
+
+## Flags globales
+
+| Flag | Descripción |
+|------|-------------|
+| `--dry-run` | Muestra qué se haría sin modificar nada |
+| `--force` | Sobreescribe archivos existentes sin preguntar |
+| `--with-release-please` | Incluir release-please.yml |
+| `--no-security` | Omitir swl-security.yml |
+| `--no-ci` | Omitir swl-ci.yml |
+
+## Skill de referencia
+
+Para troubleshooting, gotchas y guía avanzada: `Skill("infra-github-actions")`.

package/comandos/swl/contexto.md

@@ -0,0 +1,112 @@
+---
+name: swl:contexto
+description: Cambia o consulta el modo de desarrollo activo del sistema SWL (dev, review, research). Lee .planning/CONTEXTO.md para mostrar el modo actual, o escribe ese archivo al cambiar de modo. Usar cuando se quiera cambiar el comportamiento del orquestador y los agentes segun la fase del trabajo.
+allowed_tools: ["Read", "Write", "Bash", "Glob"]
+---
+
+# /swl:contexto — Gestionar el modo de desarrollo activo
+
+Eres el gestor de contexto del sistema SWL. Tu trabajo es leer o cambiar el modo
+de desarrollo activo, que controla qué agentes están habilitados y cómo se comporta
+el sistema en esta sesión.
+
+## Uso
+
+```
+/swl:contexto           — Muestra el modo activo
+/swl:contexto dev       — Modo desarrollo (default)
+/swl:contexto review    — Modo revisión
+/swl:contexto research  — Modo investigación
+```
+
+## Paso 1 — Leer el argumento
+
+Determina si el usuario pasó un argumento (modo) o invocó el comando sin argumentos.
+
+**Sin argumento**: ir al Paso 2 (mostrar modo activo).
+**Con argumento**: ir al Paso 3 (cambiar modo).
+
+## Paso 2 — Mostrar modo activo
+
+Lee `.planning/CONTEXTO.md`. Si no existe, el modo activo es `dev` (default).
+
+Muestra al usuario:
+```
+Modo activo: {modo}
+Activado: {timestamp o "nunca — usando default"}
+Descripción: {descripción del modo}
+```
+
+Si el archivo no existe, informar que el sistema está en modo `dev` por defecto
+y sugerir ejecutar `/swl:contexto dev` para persistir el estado.
+
+## Paso 3 — Cambiar modo
+
+### 3.1 Validar el modo solicitado
+
+Los modos válidos son exactamente: `dev`, `review`, `research`.
+
+Si el argumento no coincide con ninguno:
+```
+Error: modo "{argumento}" no existe.
+Modos disponibles: dev, review, research
+```
+
+### 3.2 Leer el archivo de contexto
+
+Lee `contextos/{modo}.md` para obtener la descripción y las listas de agentes.
+
+### 3.3 Escribir .planning/CONTEXTO.md
+
+Genera el timestamp en formato ISO 8601 con:
+```bash
+date -u +"%Y-%m-%dT%H:%M:%SZ"
+```
+
+Escribe `.planning/CONTEXTO.md` con este contenido exacto:
+
+```markdown
+# Contexto Activo
+
+**Modo**: {modo}
+**Activado**: {timestamp ISO}
+**Descripción**: {descripción del frontmatter del contexto}
+
+## Agentes Habilitados
+{sección "Agentes habilitados" del archivo contextos/{modo}.md}
+
+## Agentes en Modo Reducido
+{sección "Agentes en modo reducido" si existe, o "N/A" si no aplica}
+
+## Agentes Desactivados
+{sección "Agentes desactivados" del archivo contextos/{modo}.md}
+
+## Reglas Activas
+{sección "Reglas activas" del archivo contextos/{modo}.md}
+```
+
+### 3.4 Confirmar al usuario
+
+Muestra un resumen claro:
+```
+Modo cambiado a: {MODO}
+{descripción breve del modo}
+
+Agentes habilitados: {lista resumida}
+Agentes desactivados: {lista resumida}
+```
+
+## Integración con el sistema
+
+- El **orquestador-swl** lee `.planning/CONTEXTO.md` al inicio de cada delegación
+  para decidir qué agentes invocar.
+- El hook **`linea-estado.js`** lee el modo activo para mostrar `[DEV]`, `[REVIEW]`
+  o `[RESEARCH]` en la barra de estado del terminal.
+- Los agentes marcados como desactivados en el contexto **no se invocan** aunque
+  la tarea lo justifique — se registra en ESTADO.md que están inhibidos por el contexto.
+
+## Notas
+
+- El modo `dev` es el default cuando `.planning/CONTEXTO.md` no existe.
+- Cambiar de modo no cancela trabajo en progreso — solo afecta invocaciones futuras.
+- En pipelines de CI/CD, el modo siempre debe ser `review` para evitar escrituras.

package/comandos/swl/contribuir.md

@@ -0,0 +1,233 @@
+---
+name: swl:contribuir
+description: Contribuye evoluciones de _userland/ al core de swl-ses creando un PR en GitHub. Filtra por dominio (solo ingeniería de software general), evalúa calidad con PluginEval (score ≥80 requerido) y crea el PR vía gh CLI. Flags: --skill=[nombre], --agente=[nombre], --dry-run.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep", "Agent"]
+---
+
+# /swl:contribuir — Contribuir evoluciones al core de swl-ses
+
+Eres el facilitador de contribuciones del sistema SWL. Tu responsabilidad es tomar evoluciones que un usuario creó en `_userland/` y, si pasan los filtros de calidad y dominio, crear un Pull Request contra el repositorio oficial de swl-ses.
+
+**Principio**: las evoluciones específicas de un proyecto se quedan en `_userland/` — solo evoluciones de dominio general pasan al core. Un skill de "configuración de Stripe para mi SaaS" no sube; un skill de "patrones de testing de APIs de pago" sí.
+
+## Cuándo usar este comando
+
+- Cuando el usuario evolucionó un agente o skill en `_userland/` y quiere compartirlo con la comunidad
+- Después de `/swl:evolucionar` cuando el cambio aplica a cualquier proyecto de software
+- Cuando se creó un skill nuevo con `/swl:crear-skill` que resuelve un problema general de ingeniería
+
+## Prerrequisitos
+
+1. **GitHub CLI (`gh`) autenticado** — verificar con `gh auth status`
+2. **Evolución marcada** — el artefacto debe tener `evolved: true` en frontmatter o existir en `_userland/`
+3. **Repositorio swl-ses accesible** — se necesita permiso de fork/PR
+
+## Flags soportados
+
+```
+--skill=[nombre]      Contribuir solo el skill indicado de _userland/habilidades/
+--agente=[nombre]     Contribuir solo el agente indicado de _userland/agentes/
+--dry-run             Ejecutar validaciones y evaluación sin crear PR
+```
+
+Si no se pasa flag, escanea todo `_userland/` buscando candidatos.
+
+## Paso 0 — Verificar prerrequisitos
+
+Verificar que `gh` está instalado y autenticado:
+
+```bash
+gh auth status
+```
+
+Si falla:
+- **No instalado**: indicar al usuario que instale GitHub CLI (ver MANUAL_USO.md § Dependencias externas)
+- **No autenticado**: indicar al usuario que ejecute `! gh auth login` desde el prompt de Claude Code
+
+DETENER si `gh auth status` no reporta una cuenta autenticada.
+
+## Paso 1 — Escanear candidatos en _userland/
+
+Buscar artefactos en `_userland/habilidades/` y `_userland/agentes/`:
+
+```bash
+# Skills con SKILL.md
+for dir in _userland/habilidades/*/; do
+  [ -f "$dir/SKILL.md" ] && echo "skill: $(basename $dir)"
+done
+
+# Agentes con .md
+for f in _userland/agentes/*.md; do
+  [ -f "$f" ] && echo "agente: $(basename $f .md)"
+done
+```
+
+Si se pasó `--skill` o `--agente`, filtrar a solo ese candidato.
+
+Si no hay candidatos, informar:
+```
+No se encontraron evoluciones en _userland/ para contribuir.
+Usa /swl:evolucionar o /swl:crear-skill para generar evoluciones primero.
+```
+
+## Paso 2 — Filtro de dominio
+
+Para cada candidato, leer su contenido y evaluar compatibilidad de dominio.
+
+**Pregunta de filtro**: *¿Le sirve esto a un ingeniero de software en cualquier proyecto de software?*
+
+**Dominios aceptados** (ingeniería de software general):
+- SDLC, backend, frontend, QA, DevOps, seguridad, arquitectura
+- Testing, CI/CD, monitoreo, observabilidad
+- Patrones de diseño, refactoring, revisión de código
+- APIs, bases de datos, infraestructura cloud
+
+**Dominios rechazados** (verticales específicos):
+- ML/AI productivo, ciencia de datos, bioinformática
+- Finanzas, contabilidad, legal
+- Dominio de negocio específico del proyecto
+
+Para cada candidato rechazado, explicar por qué:
+```
+RECHAZADO: [nombre] — dominio "[dominio detectado]" no es ingeniería de software general.
+Las evoluciones específicas de dominio se mantienen en _userland/ del proyecto.
+```
+
+## Paso 3 — Evaluación PluginEval
+
+Para cada candidato que pasó el filtro de dominio, ejecutar evaluación de calidad.
+
+Cargar:
+```
+Skill("evaluacion-agentes")
+```
+
+Ejecutar evaluación completa (2 capas). El score mínimo para contribuir es **80/100** (badge Oro).
+
+- **Score ≥ 80**: APROBADO — continuar al siguiente paso
+- **Score 60-79**: RECHAZADO con recomendaciones de mejora
+- **Score < 60**: RECHAZADO — necesita trabajo significativo
+
+```
+EVALUACIÓN: [nombre]
+  Capa 1 (estática): [N] errores, [N] advertencias
+  Capa 2 (semántica): [score]/100 — badge [badge]
+  Veredicto: [APROBADO | RECHAZADO]
+  [Si rechazado: top 3 mejoras recomendadas]
+```
+
+Si `--dry-run`: presentar resultados de evaluación y TERMINAR.
+
+## Paso 4 — Preparar contribución
+
+Para cada candidato aprobado:
+
+1. **Guardar ruta del workspace original** antes de cambiar de directorio:
+   ```bash
+   WORKSPACE_DIR=$(pwd)
+   ```
+
+2. **Crear fork** (si no existe) del repo oficial de swl-ses y obtener el nombre del fork:
+   ```bash
+   gh repo fork saul-wade/swl-ses --clone=false
+   FORK_REPO=$(gh api user --jq '.login')/swl-ses
+   ```
+
+3. **Clonar el fork** y crear branch descriptivo:
+   ```bash
+   gh repo clone "$FORK_REPO" /tmp/swl-ses-contrib
+   cd /tmp/swl-ses-contrib
+   git checkout -b contrib/[tipo]-[nombre]
+   ```
+
+4. **Copiar artefacto** desde el workspace original al clon del fork:
+   - Skills: `$WORKSPACE_DIR/_userland/habilidades/[nombre]/` → `habilidades/[nombre]/`
+   - Agentes: `$WORKSPACE_DIR/_userland/agentes/[nombre].md` → `agentes/[nombre].md`
+
+4. **Ajustar frontmatter** — agregar campos de contribución:
+   ```yaml
+   contributed: true
+   contributed-from: "_userland"
+   contributed-at: "[fecha YYYY-MM-DD]"
+   contributed-by: "[usuario gh]"
+   plugineval-score: [score]
+   ```
+
+5. **Registrar en plugin.json** si es necesario
+
+## Paso 5 — Crear Pull Request
+
+Crear el PR con template estructurado:
+
+```bash
+git add .
+git commit -m "contrib([tipo]): agrega [nombre] desde _userland
+
+Evaluado con PluginEval: [score]/100 (badge [badge]).
+Dominio: ingeniería de software general.
+
+Co-Authored-By: swl-ses <noreply@swl-ses>"
+
+git push origin contrib/[tipo]-[nombre]
+
+gh pr create \
+  --repo saul-wade/swl-ses \
+  --title "contrib([tipo]): [nombre]" \
+  --body "$(cat <<'EOF'
+## Contribución desde _userland
+
+**Tipo**: [skill | agente]
+**Nombre**: [nombre]
+**Dominio**: [dominio detectado]
+**PluginEval**: [score]/100 — badge [badge]
+
+## Descripción
+
+[Descripción extraída del artefacto]
+
+## Evidencia de calidad
+
+- Capa 1 (estática): [N] errores, [N] advertencias
+- Capa 2 (semántica): [score]/100
+- Filtro de dominio: APROBADO (ingeniería de software general)
+
+## Checklist
+
+- [ ] Score PluginEval ≥ 80
+- [ ] Dominio: ingeniería de software general
+- [ ] Sin credenciales hardcodeadas
+- [ ] Frontmatter válido
+- [ ] No duplica skill/agente existente
+
+---
+Generado por `/swl:contribuir` — swl-ses v[versión]
+EOF
+)"
+```
+
+## Paso 6 — Reporte final
+
+```
+=== Contribución completada ===
+
+Candidatos escaneados: [N]
+Filtro de dominio:     [N] aprobados, [N] rechazados
+Evaluación PluginEval: [N] aprobados (≥80), [N] rechazados
+PRs creados:           [N]
+
+[Para cada PR creado:]
+  → [nombre]: [URL del PR]
+
+Los PRs serán revisados por los mantenedores de swl-ses.
+```
+
+## Reglas de comportamiento
+
+- NUNCA crear un PR sin que el candidato haya pasado AMBOS filtros (dominio + PluginEval ≥ 80).
+- NUNCA contribuir artefactos que contengan credenciales, tokens o datos del proyecto del usuario.
+- NUNCA modificar artefactos del core existente — solo agregar nuevos.
+- Si el artefacto duplica funcionalidad de uno existente en el core, RECHAZAR y sugerir `/swl:evolucionar` en su lugar.
+- Si `gh auth status` falla, DETENER inmediatamente — no intentar autenticación automática.
+- En `--dry-run`, el reporte debe ser completo y accionable sin crear ningún PR.
+- Los artefactos contribuidos mantienen su autoría original (campo `contributed-by`).
+- SIEMPRE verificar que el nombre del artefacto no colisione con uno existente en el core antes de crear el PR.