Fase 2: 04_sanitize.py - scrubbing de secretos de skills/agentes/plans (10 secretos unicos, gate en verde)

data/raw/sanitized/plans/quiero-crear-una-skill-bright-honey.md

@@ -0,0 +1,73 @@
+# Plan: skill `spark-ssh` para conectarse y ejecutar comandos en spark vía SSH
+
+## Contexto
+
+El usuario quiere que Claude Code pueda operar directamente sobre su servidor "spark" (<<SPARK_IP_1>>)
+ejecutando comandos remotos vía SSH, sin tener que pedir manualmente la contraseña cada vez. Verificado
+en el entorno actual:
+
+- `~/.ssh/config` ya tiene un host `spark` configurado (`HostName <<SPARK_IP_1>>`, `User aleleba`), pero
+  la autenticación falla por key (`ssh -o BatchMode=yes spark` → `Permission denied (publickey,password)`)
+  — spark solo acepta password.
+- La variable de entorno `SPARK_PASSWORD` ya existe en este entorno de desarrollo.
+- `sshpass` **no está instalado**, pero está disponible vía `apt` (`sshpass 1.09-1`) y hay sudo sin
+  password (`sudo -n true` → OK), así que se puede instalar como parte del preflight de la skill.
+- `/mnt/docker-nas` no existe en este entorno de desarrollo — es un mount NFS que solo existe **del lado
+  de spark**. Dentro de él, `/mnt/docker-nas/projects` es el mismo storage que `~/projects` aquí. Es
+  decir: un proyecto en `~/projects/<nombre>` en este entorno de desarrollo es exactamente
+  `/mnt/docker-nas/projects/<nombre>` visto desde spark (mismo filesystem compartido vía NAS).
+
+El objetivo es crear una skill global (en `~/.claude/skills/`, siguiendo el patrón de las skills
+existentes como `web-ui-test`, `aleleba-pr`) que documente el patrón de conexión y las convenciones de
+seguridad/rutas para que Claude la use de forma consistente cada vez que el usuario pida ejecutar algo en
+spark.
+
+## Archivo a crear
+
+`~/.claude/skills/spark-ssh/SKILL.md`
+
+## Contenido de la skill
+
+**Frontmatter:**
+- `name: spark-ssh`
+- `description`: explica que conecta a spark por SSH con password vía `SPARK_PASSWORD`, y que traduce
+  rutas entre `/mnt/docker-nas/projects` (en spark) y `~/projects` (en este entorno). Incluye triggers en
+  español: "conéctate a spark", "ejecuta esto en spark", "corre este comando en spark", "revisa spark".
+- `effort: low`
+- `argument-hint: "[comando o tarea a ejecutar en spark]"`
+
+**Cuerpo (en español, consistente con el resto de skills del usuario):**
+
+1. **Contexto fijo**: host `spark` ya está en `~/.ssh/config`; autenticación es por password (no key);
+   password vive en `$SPARK_PASSWORD`; mapeo de rutas `~/projects/<x>` ↔ `/mnt/docker-nas/projects/<x>`.
+
+2. **Preflight — instalar `sshpass` si falta** (idempotente):
+   ```bash
+   which sshpass >/dev/null 2>&1 || sudo apt-get install -y sshpass
+   ```
+
+3. **Ejecutar un comando remoto**, usando siempre `sshpass -e` (nunca `-p`, que expone la password en
+   `ps`):
+   ```bash
+   SSHPASS="$SPARK_PASSWORD" sshpass -e ssh spark '<comando remoto>'
+   ```
+   Para comandos multilínea o con comillas complejas, usar heredoc remoto vía `ssh spark bash -s <<'EOF'`.
+
+4. **Regla de rutas compartidas**: si el comando remoto opera sobre un proyecto que también existe
+   localmente en `~/projects/<nombre>`, la ruta equivalente en spark es
+   `/mnt/docker-nas/projects/<nombre>`. Para *editar* código de esos proyectos, preferir las tools locales
+   (Read/Edit) ya que es el mismo filesystem; usar SSH solo para **ejecutar** (builds, procesos, comandos
+   específicos del entorno/hardware de spark).
+
+5. **Seguridad**: nunca imprimir/loggear `$SPARK_PASSWORD`; aplicar las reglas generales de confirmación
+   antes de comandos destructivos ejecutados en spark (rm -rf, docker rm, kill, etc.).
+
+## Verificación
+
+Después de crear el archivo:
+```bash
+which sshpass >/dev/null 2>&1 || sudo apt-get install -y sshpass
+SSHPASS="$SPARK_PASSWORD" sshpass -e ssh spark 'hostname && whoami && ls /mnt/docker-nas/projects | head -5'
+```
+Confirmar que devuelve el hostname de spark y que `/mnt/docker-nas/projects` lista el mismo contenido que
+`~/projects` localmente.