@damiangilgonzalez/harness 1.3.20 → 1.3.22

package/README.md

@@ -107,7 +107,7 @@ Empiezas pequeño. El resto se carga bajo demanda: el harness te propone una ski
 la pide, con la evidencia que lo justifica.
 
 ```bash
-rsc install --profile minimal   # la base: orient + suggest + bro + unslop + show-me + eli5 + harness + init + teach
+rsc install --profile minimal   # la base: orient + suggest + bro + unslop + show-me + eli5 + harness + init + teach + tunel-ngrok + hardening
 rsc install --profile core      # la base + el método completo
 rsc install --profile full      # todo el catálogo
 ```
@@ -126,12 +126,12 @@ Lo que se comparte va a git; el estado de la máquina, no.
 Hooks que vigilan por ti: recuerdan la cadena, piden confirmación antes de un `rm -rf` o un
 `git push --force` y paran antes de volver a `main` sin abrir la PR.
 
-![Plugins de serie: superpowers, skins, savvy-progress, filetree y cache-tax](docs/img/readme/readme-16-plugins.png)
+![Plugins de serie: superpowers, skins, savvy-progress y cache-tax](docs/img/readme/readme-16-plugins.png)
 
-En Claude Code quedan activados `skins`, `savvy-progress`, `filetree` y `cache-tax`
+En Claude Code quedan activados `skins`, `savvy-progress` y `cache-tax`
 (mantiene caliente la caché, y eso gasta tokens). `superpowers` llega cuando el proyecto usa el método.
 
-En cifras: 294 skills, 34 agentes y 43 entradas de comando, para 17 asistentes
+En cifras: 296 skills, 34 agentes y 43 entradas de comando, para 17 asistentes
 (Claude Code, Codex, Cursor, Copilot, Gemini…). Detalle en la [referencia técnica](docs/referencia-tecnica.md).
 
 ---
@@ -249,9 +249,9 @@ Guía completa: [la memoria del harness](docs/como-funciona/memoria.md).
 
 ## Catálogo
 
-![294 skills por dominio](docs/img/readme/readme-15-catalogo.png)
+![296 skills por dominio](docs/img/readme/readme-15-catalogo.png)
 
-294 skills en 25 dominios: software, negocio, contenido, datos e IA.
+296 skills en 25 dominios: software, negocio, contenido, datos e IA.
 Cada una se activa sola cuando la tarea encaja.
 
 **[Ver el catálogo completo →](docs/catalogo.md)** · [Referencia técnica](docs/referencia-tecnica.md) ·

package/manifest.json

@@ -1,7 +1,7 @@
 {
-  "version": "1.3.20",
+  "version": "1.3.22",
   "counts": {
-    "skills": 294,
+    "skills": 296,
     "agents": 34,
     "commands": 43,
     "fixedCommands": 10
@@ -2341,6 +2341,31 @@
         "full"
       ]
     },
+    {
+      "id": "hardening",
+      "description": "Use when the user asks for hardening, a security or privacy audit of the product, or aligning it with SOC 2, ISO 27001 or ISO 27701: audits by zones with read-only subagents, checks every finding by hand, gives the list by severity, the user decides, and the chosen fixes go to spec and tickets. NOT a quick scan of a diff (that is `security-scan`), NOT secure-coding rules while writing code (that is `secure-coding`).",
+      "tags": [
+        "security",
+        "hardening",
+        "soc2",
+        "iso27001",
+        "iso27701",
+        "privacy",
+        "audit"
+      ],
+      "recommends": [
+        "to-spec",
+        "to-tickets",
+        "write-adr",
+        "implement-spec"
+      ],
+      "profiles": [
+        "minimal",
+        "core",
+        "ui",
+        "full"
+      ]
+    },
     {
       "id": "harness",
       "description": "Use when governing a workspace's control plane, code or not — the `01-TOOLS/` tooling layer, the `docs/` chaos→knowledge wiki, the root Knowledge map. Audits it, migrates legacy `XX-*` folders, scaffolds provider tooling, sweeps the inbox, writes root CLAUDE.md/AGENTS.md. NOT the bootstrap front door (that is `init`, which hands off here).",
@@ -3805,7 +3830,7 @@
     },
     {
       "id": "pr",
-      "description": "Use when writing a PR body or opening a PR: a visual summary, before/after evidence, the merge danger (one-way or two-way door, blast radius), and a title checked against the repo's CI title rule before `gh pr create`.",
+      "description": "Use when writing a PR body or opening a PR: a short plain-language story of what was broken or missing and why it changed, a visual summary, before/after evidence, the merge danger (one-way or two-way door, blast radius), and a title checked against the repo's CI title rule before `gh pr create`.",
       "tags": [
         "pull-request",
         "review",
@@ -5351,6 +5376,26 @@
       ],
       "profiles": []
     },
+    {
+      "id": "tunel-ngrok",
+      "description": "Use when the user wants to open a local project's frontend on their phone without deploying, share the local environment through a public URL, get HTTPS for the microphone or camera, or set up ngrok in a project. One ngrok tunnel to the frontend port; the frontend proxies the API so the phone sees a single HTTPS origin. NOT deploying to a real host (that is `deployment`).",
+      "tags": [
+        "ngrok",
+        "tunnel",
+        "mobile",
+        "https",
+        "local-dev"
+      ],
+      "recommends": [
+        "deployment"
+      ],
+      "profiles": [
+        "minimal",
+        "core",
+        "ui",
+        "full"
+      ]
+    },
     {
       "id": "typescript",
       "description": "Use when writing or fixing TypeScript type code (.ts/.tsx/.d.ts), modeling data with generics/unions/branded types, diagnosing narrowing failures, or configuring tsconfig and the build toolchain. NOT runtime code, fs/streams/http (that is `nodejs`); NOT component/route typing (that is `react`/`nextjs`); NOT ORM type-gen (that is `drizzle-orm`).",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@damiangilgonzalez/harness",
-  "version": "1.3.20",
+  "version": "1.3.22",
   "description": "A guided harness builder that turns your goal into a minimal, verified AI-agent setup using strict best practices.",
   "type": "module",
   "bin": {

package/scripts/lib/domains.js

@@ -27,7 +27,7 @@ export const DOMAINS = [
   { title: 'Motion & interface craft', ids: ['motion-craft', 'ui-engineering', 'variant-explorer'] },
   { title: 'Design & content craft', ids: ['design-loop', 'design', 'design-dna', 'presentations', 'course-storytelling', 'course-builder', 'technical-writing', 'translation-l10n'] },
   { title: 'Knowledge & meta', ids: ['knowledge-ops', 'codebase-onboarding', 'research-ops', 'continuous-learning', 'skill-scout', 'context-budget', 'roast-me', 'show-me', 'eli5', 'fable-operator'] },
-  { title: 'Personal catalog — workflow (Spanish)', ids: ['grill-me', 'grill-with-docs', 'grilling', 'wayfinder', 'to-spec', 'to-tickets', 'to-questionnaire', 'implement', 'implement-spec', 'pr', 'retro', 'revision-de-cambios', 'code-review', 'research', 'prototype', 'domain-modeling', 'handoff', 'write-adr', 'wait-what', 'writing-for-agents', 'claude-project-setup', 'muscle-memory', 'teach'] },
+  { title: 'Personal catalog — workflow (Spanish)', ids: ['grill-me', 'grill-with-docs', 'grilling', 'wayfinder', 'to-spec', 'to-tickets', 'to-questionnaire', 'implement', 'implement-spec', 'pr', 'retro', 'revision-de-cambios', 'code-review', 'research', 'prototype', 'domain-modeling', 'handoff', 'write-adr', 'wait-what', 'writing-for-agents', 'claude-project-setup', 'muscle-memory', 'teach', 'tunel-ngrok', 'hardening'] },
   { title: 'Personal catalog — interface design (Spanish)', ids: ['flujo-interfaz', 'animar', 'diseno-apple', 'diseno-landing', 'ingeniero-diseno-web', 'leyes-de-percepcion', 'leyes-de-retencion', 'mejor-accesibilidad', 'mejor-colores', 'mejor-layout', 'mejor-redaccion', 'mejor-tipografia', 'mejor-ui', 'sitios-calidad-premio', 'tastemaker', 'video-a-superprompt', 'vocabulario-animacion', 'revision-interfaz'] },
 ];
 

package/skills/hardening/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: hardening
+description: "Use when the user asks for hardening, a security or privacy audit of the product, or aligning it with SOC 2, ISO 27001 or ISO 27701: audits by zones with read-only subagents, checks every finding by hand, gives the list by severity, the user decides, and the chosen fixes go to spec and tickets. NOT a quick scan of a diff (that is `security-scan`), NOT secure-coding rules while writing code (that is `secure-coding`)."
+tags: [security, hardening, soc2, iso27001, iso27701, privacy, audit]
+recommends: [to-spec, to-tickets, write-adr, implement-spec]
+profiles: [minimal, core, ui, full]
+origin: damiangil
+---
+
+# Hardening
+
+Proceso de cinco pasos: alcance, auditoría, comprobación, lista y decisión, y arreglo. El usuario dicta por voz y quiere frases cortas y sin jerga. Cada decisión es suya; la gravedad y el arreglo son propuestas.
+
+## 1. Alcance
+
+Pregunta todo de una vez, con opciones:
+
+- **Normas.** El dictado deforma los números («ISO 27101» era 27701). Confirma cuáles son.
+- **Qué cubre.** Solo el producto (código, base, accesos, secretos, registros, dependencias, contenedores, CI) o también las políticas de empresa.
+- **Qué entregar.** Auditar y luego arreglar lo que elija (recomendado), solo auditar, o arreglarlo todo.
+
+**Hecho cuando** las tres respuestas son del usuario.
+
+## 2. Auditoría en tres zonas
+
+Lee primero el documento de estado del proyecto (el que diga su `AGENTS.md` o `CLAUDE.md`): manda sobre lo que encuentren los agentes. Lanza **tres subagentes en paralelo, solo de lectura**, uno por zona, con el encargo de [`zonas.md`](zonas.md). Mientras trabajan, crea un worktree para el informe si otra sesión usa la carpeta.
+
+**Hecho cuando** las tres zonas han devuelto sus hallazgos con evidencia `fichero:línea`.
+
+## 3. Comprobación a mano
+
+Un agente auditor se equivoca con el mismo aplomo con que acierta. Abre tú el código de **cada hallazgo alto o crítico y de cada medio**, y contrasta cada uno con el estado del proyecto. Ejemplo real: un agente dio por vivas dos tablas que una migración ya había borrado.
+
+- Se confirma: márcalo con ✔ en el informe.
+- No se sostiene: corrígelo o quítalo, y dile al usuario qué cambió.
+- El mismo fallo en dos zonas: une los hallazgos en uno.
+
+**Hecho cuando** cada hallazgo medio o superior está confirmado, corregido o quitado.
+
+## 4. Informe y lista
+
+Escribe el informe en la wiki o en `docs/` del proyecto (por ejemplo, `docs/wiki/seguridad/auditoria-hardening.md`, o con fecha si ya existe) y enlázalo desde su índice. Lleva lo siguiente:
+
+- resumen;
+- hallazgos por gravedad, cada uno con controles, evidencia, escenario y arreglo;
+- «Bien hecho» y «No aplica todavía»;
+- inventario de datos personales.
+
+Al usuario dale **la lista entera, numerada, de más a menos grave**, cada hallazgo en una o dos frases llanas: qué pasa y qué podría hacer alguien con ello. Que la conteste a su manera, punto por punto. Si un punto no se entiende, explica qué programa es y cómo pasa, con una imagen cotidiana.
+
+**Hecho cuando** el usuario ha respondido a cada número o lo ha dejado expresamente para después.
+
+## 5. Decisión y arreglo
+
+Dale a cada número un destino y escríbelo en «Decisión del usuario», con fecha, en el informe:
+
+| Destino | Qué haces |
+|---|---|
+| Se arregla | Entra en la tanda de arreglos |
+| Anotado | Una fila en el roadmap del proyecto con «Anotado, sin preocupar por ahora» |
+| Pendiente que ya existía | Busca su ticket abierto (`gh issue list --search`); si no lo hay, créalo y enlázalo en el roadmap |
+| Aceptado o descartado | Una línea con su razón |
+
+La tanda de arreglos sigue la cadena del proyecto, en una rama aparte:
+
+1. Spec y tickets (`to-spec` y `to-tickets`), con un ticket por arreglo independiente.
+2. Un ADR (`write-adr`) para lo difícil de revertir, como los roles de la base.
+3. Desarrollo con agentes en paralelo (`implement-spec`). Cada arreglo lleva su prueba, que falla antes del arreglo y pasa después.
+
+La PR queda sin fusionar.
+
+**Hecho cuando** cada número tiene su destino escrito y la tanda está en tickets.

package/skills/hardening/evals/cases.yaml

@@ -0,0 +1,32 @@
+skill: hardening
+
+should_trigger:
+  - prompt: "Haz un hardening del producto."
+    why: "Disparador directo de hardening."
+  - prompt: "Audita la seguridad y la privacidad de la aplicacion."
+    why: "Disparador directo de hardening."
+  - prompt: "Quiero alinear el producto con SOC 2 e ISO 27001."
+    why: "Disparador directo de hardening."
+  - prompt: "Run a security and privacy audit against ISO 27701."
+    why: "Disparador directo de hardening."
+  - prompt: "Revisa por zonas que fallos de seguridad tiene el proyecto y dame la lista por gravedad."
+    why: "Disparador directo de hardening."
+
+should_not_trigger:
+  - prompt: "Abre el front en el movil con ngrok."
+    route_to: "tunel-ngrok"
+    why: "Abrir el front en el movil es el trabajo de tunel-ngrok, no de hardening."
+  - prompt: "Documenta la decision de arquitectura."
+    route_to: "write-adr"
+    why: "Documentar una decision de arquitectura es el trabajo de write-adr, no de hardening."
+  - prompt: "Parte esta spec en tickets."
+    route_to: "to-tickets"
+    why: "Partir una spec en tickets es el trabajo de to-tickets, no de hardening."
+  - prompt: "Configura el pipeline de CI para que pase los tests en cada push."
+    route_to: "github-actions"
+    why: "Montar la CI es el trabajo de github-actions, no de hardening."
+
+capability:
+  - scenario: "El usuario pide una auditoria de seguridad del producto."
+    must_include:
+      - "gravedad"

package/skills/hardening/zonas.md

@@ -0,0 +1,75 @@
+# Zonas de la auditoría
+
+Encargo de cada subagente del paso 2 de [`SKILL.md`](SKILL.md). Copia el **marco común** en los tres encargos y añade la zona.
+
+## Marco común
+
+- Auditoría **solo de lectura**. Prohibido modificar ficheros.
+- Prohibido lanzar pruebas o comandos que rehagan bases compartidas. Busca en el proyecto cuáles son y nómbralas en el encargo (por ejemplo, los tests de la base y `supabase db reset`).
+- De `.env` y de los secretos, solo si la variable existe. Nunca su valor.
+- Cada hallazgo, con evidencia `fichero:línea`. Lo que esté bien, una línea en «Bien hecho».
+- Formato de cada hallazgo:
+  - título;
+  - gravedad (crítica, alta, media o baja);
+  - controles afectados;
+  - evidencia;
+  - escenario concreto de ataque o de fallo;
+  - arreglo en una o dos líneas.
+- Hallazgos de más a menos grave, y después «Bien hecho» y «No aplica todavía (sin despliegue)».
+
+## Zona 1. Identidad, autenticación y autorización
+
+**Controles.**
+- SOC 2: CC6.1, CC6.2, CC6.3, CC6.6 y CC6.7.
+- ISO 27001: 5.15, 5.16, 5.17, 5.18, 8.2, 8.3, 8.4 y 8.5.
+- ISO 27701: el acceso a datos personales.
+
+**Qué revisar.**
+- Rutas sin sesión.
+- El rol, comprobado en el servidor en cada ruta.
+- Acceso a registros ajenos (IDOR).
+- Rutas de desarrollo o dobles que una variable de entorno pueda activar.
+- RLS, `GRANT` y roles de la base, `SECURITY DEFINER` sin `search_path` y el uso de `service_role`.
+- Fuentes externas que deban ser de solo lectura.
+- Configuración de Auth: registro abierto, contraseñas, MFA y duración de los tokens.
+- Registro de los accesos rechazados.
+
+## Zona 2. Datos personales, retención y registros
+
+**Controles.**
+- ISO 27701: minimización, finalidad, retención y borrado, subencargados, transferencias y derechos del interesado.
+- SOC 2: C1.1, C1.2, la serie P y CC7.2.
+- ISO 27001: 5.12, 5.33, 5.34, 8.10, 8.11, 8.12, 8.15 y 8.24.
+
+**Qué revisar.**
+- Qué datos personales hay: voz, nombres, texto libre y conversación.
+- Qué se manda a terceros (proveedores de IA), con `store` o la retención que se pida.
+- Qué se escribe en los registros: trazas con variables locales, tokens, frases y ficheros de depuración.
+- Si se puede borrar o caduca.
+- Cifrado en tránsito.
+- Si la pista de auditoría es de verdad inmutable.
+- `.gitignore` y `git ls-files`, por si se ha colado algo sensible.
+
+**Además entrega** la tabla «Inventario de datos personales»: dato, dónde vive, a qué tercero va y cuánto se guarda.
+
+## Zona 3. Desarrollo seguro, secretos, dependencias y CI
+
+**Controles.**
+- SOC 2: CC6.8, CC7.1 y CC8.1.
+- ISO 27001: 8.4, 8.7, 8.8, 8.9, 8.20, 8.25, 8.26, 8.27, 8.28, 8.29, 8.31 y 8.32.
+
+**Qué revisar.**
+- Secretos en git, también en el historial.
+- Entrada no confiable:
+  - subidas: tamaño, tipo y ruta;
+  - SQL construido a mano;
+  - longitud de los textos;
+  - inyección de prompt con efecto en las herramientas;
+  - fórmulas en el Excel.
+- Límite de peticiones y de gasto.
+- Errores que filtran detalles internos, cabeceras, CSP y CORS.
+- Front: `innerHTML` y dónde se guarda la sesión.
+- Dependencias: si están fijadas y si algo las escanea. `npm audit` se puede lanzar porque solo lee.
+- Docker: si corre como administrador, imágenes sin digest y puertos abiertos a `0.0.0.0`.
+- CI: permisos del token, acciones sin SHA, Dependabot, SAST y búsqueda de secretos.
+- SSH sin verificar la clave del servidor.

package/skills/pr/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pr
-description: "Use when writing a PR body or opening a PR: a visual summary, before/after evidence, the merge danger (one-way or two-way door, blast radius), and a title checked against the repo's CI title rule before `gh pr create`."
+description: "Use when writing a PR body or opening a PR: a short plain-language story of what was broken or missing and why it changed, a visual summary, before/after evidence, the merge danger (one-way or two-way door, blast radius), and a title checked against the repo's CI title rule before `gh pr create`."
 tags: ["pull-request", "review", "evidence", "risk"]
 profiles: [core, ui, full]
 origin: damiangil
@@ -15,6 +15,10 @@ metadata:
 Usa esta plantilla para escribir el cuerpo de la PR:
 
 ```markdown
+## La historia
+
+<tres a cinco frases, en coloquial: qué fallaba o faltaba, qué se ha hecho y qué cambia ahora>
+
 ## Resumen
 
 <diagrama, esbozo de diff o árbol>
@@ -39,6 +43,22 @@ Usa esta plantilla para escribir el cuerpo de la PR:
 
 Sáltate los preámbulos y deja la prosa breve. Usa el lenguaje del dominio del usuario que está en `GLOSSARY.md`.
 
+### La historia
+
+Va siempre, la primera. Cuenta el porqué y el qué como se lo contarías a un amigo que no ha visto el código: cercano, coloquial y entendible de un vistazo. Tres a cinco frases que siguen este hilo:
+
+1. El problema: qué fallaba o qué faltaba, y a quién le afectaba.
+2. Lo que se ha hecho, en palabras de la calle.
+3. Cómo queda ahora.
+
+Habla de lo que nota quien usa el producto. Los nombres de ficheros, funciones y la jerga técnica van en las secciones de abajo.
+
+Ejemplo del tono:
+
+> Vamos a ver: cuando alguien guardaba un formulario dos veces seguidas, se creaban dos pedidos iguales y luego tocaba borrarlos a mano. Lo que pasaba es que el botón no se bloqueaba mientras se guardaba. Ahora el botón se desactiva hasta que termina, y si aun así llega un pedido repetido, se ignora. Resultado: un clic, un pedido.
+
+**Hecha cuando** alguien que no ha visto el código entiende, solo con leerla, qué pasaba y qué cambia.
+
 ### Resumen
 
 Elige la vista más pequeña que deje clara la idea clave.

package/skills/pr/evals/cases.yaml

@@ -31,6 +31,7 @@ should_not_trigger:
 capability:
   - scenario: "El usuario quiere el cuerpo de una PR que se revise de un vistazo."
     must_include:
+      - "La historia"
       - "Peligro de fusión"
       - "Radio de impacto"
   - scenario: "El repo tiene un check de título de PR en sus workflows."

package/skills/tunel-ngrok/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: tunel-ngrok
+description: "Use when the user wants to open a local project's frontend on their phone without deploying, share the local environment through a public URL, get HTTPS for the microphone or camera, or set up ngrok in a project. One ngrok tunnel to the frontend port; the frontend proxies the API so the phone sees a single HTTPS origin. NOT deploying to a real host (that is `deployment`)."
+tags: [ngrok, tunnel, mobile, https, local-dev]
+recommends: [deployment]
+profiles: [minimal, core, ui, full]
+origin: damiangil
+---
+
+# Túnel ngrok al front
+
+**Un solo túnel, al puerto del front.** El front reenvía la API (y el login, si va por el mismo servidor) a sus destinos, así que el móvil ve un único origen HTTPS: sin CORS, sin IPs, sin certificados.
+
+## Pasos
+
+1. **Explora y enseña el plan antes de tocar nada.** Localiza y anota:
+   - el servidor del front y su puerto: Vite, Angular, Next, o un nginx/Caddy en Docker que sirve el build;
+   - el prefijo de la API (`/api`…) y de cualquier otra ruta del backend (`/auth/v1`, `/ws`…);
+   - dónde define el front la URL de la API;
+   - si ya existe un reenvío (`server.proxy` de Vite, `proxyConfig` de Angular, `rewrites` de Next, `location` de nginx);
+   - si el login usa un proveedor externo con lista de redirecciones (Supabase OAuth, Auth0, Google…);
+   - si hay otro ngrok abierto: `curl -s http://127.0.0.1:4040/api/tunnels`.
+   Termina con la lista de ficheros que tocarás y sus riesgos, y espera el visto bueno.
+2. **Reenvío en el front**, solo si falta. El destino sale de una variable de entorno (reusa la que tenga el proyecto; si no hay, `API_PROXY_TARGET`): dentro de Docker, el nombre del servicio (`http://backend:8000`); en el host, el puerto publicado. Incluye cada prefijo del backend que llame el navegador, websockets con `ws: true`.
+3. **URL relativa solo en desarrollo:** el front llama a `'/api'`. Producción queda como está.
+4. **CORS intacto:** con un solo origen sobra; ningún dominio de ngrok entra en la lista.
+5. **Script del túnel:** copia [`tunel.sh`](tunel.sh) a donde el proyecto guarde sus scripts (por defecto `scripts/dev/tunel-movil.sh`) y ajusta `DEFAULT_PORT` y los mensajes de cómo levantar el front. Respeta las reglas del repo sobre dónde van los scripts y regístralo donde se listen.
+6. **Login externo:** si hay redirecciones de OAuth o enlaces mágicos, dile al usuario que añada el dominio de ngrok a la lista del proveedor, y recomienda `NGROK_DOMAIN` (dominio fijo gratuito) para añadirlo una sola vez. Con usuario y contraseña no hace falta nada.
+7. **Documenta** en dos líneas cómo usarlo, donde el proyecto explique el entorno local, avisando de que la URL es pública mientras está abierta.
+8. **Verifica**; el trabajo está hecho cuando todo esto da lo esperado:
+   - `curl localhost:<puerto>/api/...` responde el backend (un 401 en JSON del backend vale);
+   - con el túnel abierto, `curl -H 'ngrok-skip-browser-warning: 1' <url-ngrok>/` da 200 y `<url-ngrok>/api/...` responde el backend;
+   - si hay login, un login real por la URL de ngrok devuelve token y una ruta protegida responde con él;
+   - el script falla con mensaje claro si ya hay otro ngrok abierto y si el front no responde.
+
+## Trampas
+
+- **Host desconocido:** Vite (`server.allowedHosts`), Angular y webpack rechazan el dominio de ngrok. `--host-header=rewrite` lo resuelve sin tocar la configuración.
+- **Un túnel por cuenta gratuita:** si hay otro abierto, ciérralo solo con permiso del usuario.
+- **Aviso de ngrok:** el navegador ve una página intermedia la primera vez («Visit Site»); `curl` la salta con `ngrok-skip-browser-warning: 1`.
+- **Micrófono, cámara o ubicación** necesitan HTTPS: ngrok lo da, la IP local por HTTP no.
+- **Windows:** el script es bash para Git Bash; lánzalo con `bash ruta/al/script.sh`.

package/skills/tunel-ngrok/evals/cases.yaml

@@ -0,0 +1,32 @@
+skill: tunel-ngrok
+
+should_trigger:
+  - prompt: "Quiero probar el front desde el movil sin desplegar."
+    why: "Disparador directo de tunel-ngrok."
+  - prompt: "Monta ngrok en este proyecto."
+    why: "Disparador directo de tunel-ngrok."
+  - prompt: "Necesito HTTPS en local para que el microfono funcione en el movil."
+    why: "Disparador directo de tunel-ngrok."
+  - prompt: "Open my local frontend on my phone through a public URL."
+    why: "Disparador directo de tunel-ngrok."
+  - prompt: "Comparte mi entorno local con una URL publica para ensenarselo a alguien."
+    why: "Disparador directo de tunel-ngrok."
+
+should_not_trigger:
+  - prompt: "Despliega la app en produccion."
+    route_to: "deployment"
+    why: "Desplegar de verdad es el trabajo de deployment, no de tunel-ngrok."
+  - prompt: "Configura los registros DNS de mi dominio."
+    route_to: "domains-dns"
+    why: "El DNS de un dominio propio es el trabajo de domains-dns, no de tunel-ngrok."
+  - prompt: "Haz una auditoria de seguridad del producto."
+    route_to: "hardening"
+    why: "Auditar la seguridad es el trabajo de hardening, no de tunel-ngrok."
+  - prompt: "Configura el pipeline de CI para que pase los tests en cada push."
+    route_to: "github-actions"
+    why: "Montar la CI es el trabajo de github-actions, no de tunel-ngrok."
+
+capability:
+  - scenario: "El usuario quiere abrir el front local en el movil."
+    must_include:
+      - "ngrok"

package/skills/tunel-ngrok/tunel.sh

@@ -0,0 +1,52 @@
+#!/usr/bin/env bash
+# Front local en el móvil por un túnel de ngrok, sin desplegar nada. Un solo túnel al puerto del front:
+# el front reenvía la API a su destino, así que todo va por el mismo origen y no hace falta CORS.
+# ngrok da HTTPS, que el micrófono y la cámara exigen.
+#
+#   bash scripts/dev/tunel-movil.sh            # puerto por defecto (DEFAULT_PORT o FRONT_PORT)
+#   bash scripts/dev/tunel-movil.sh 5173       # otro puerto
+#
+# NGROK_DOMAIN (entorno o .env de la raíz) fija un dominio propio de ngrok. Ctrl+C cierra el túnel.
+set -euo pipefail
+
+DEFAULT_PORT=5173  # AJUSTAR: el puerto del front del proyecto
+PORT="${1:-${FRONT_PORT:-$DEFAULT_PORT}}"
+INSPECT="http://127.0.0.1:4040"
+ENV_FILE="${ENV_FILE:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)/.env}"
+
+fail() { echo "✗ $*" >&2; exit 1; }
+
+command -v ngrok >/dev/null || fail "ngrok no está instalado: https://ngrok.com/download"
+ngrok config check >/dev/null 2>&1 || fail "ngrok no tiene configuración válida: ngrok config add-authtoken <TOKEN>"
+grep -q "authtoken" "$(ngrok config check 2>&1 | sed -n 's/.*file at //p')" 2>/dev/null \
+  || fail "ngrok no tiene authtoken: ngrok config add-authtoken <TOKEN>"
+
+curl -s -o /dev/null -m 3 "http://localhost:$PORT/" || fail "El front no responde en localhost:$PORT. Levántalo:
+  AJUSTAR: el comando que levanta el front del proyecto"
+
+if curl -s -m 2 "$INSPECT/api/tunnels" >/dev/null 2>&1; then
+  fail "Ya hay otro ngrok abierto ($INSPECT). Ciérralo antes; el plan gratuito admite uno."
+fi
+
+if [ -z "${NGROK_DOMAIN:-}" ] && [ -f "$ENV_FILE" ]; then
+  NGROK_DOMAIN="$(sed -n 's/^NGROK_DOMAIN=//p' "$ENV_FILE" | tr -d '"\r' | tail -n 1)"
+fi
+ARGS=(http "$PORT" --host-header=rewrite --log=stdout --log-level=warn)
+[ -n "${NGROK_DOMAIN:-}" ] && ARGS+=("--url=https://$NGROK_DOMAIN")
+
+ngrok "${ARGS[@]}" >/dev/null &
+NGROK_PID=$!
+trap 'kill "$NGROK_PID" 2>/dev/null; echo; echo "Túnel cerrado."' EXIT INT TERM
+
+URL=""
+for _ in $(seq 1 30); do
+  URL="$(curl -s -m 2 "$INSPECT/api/tunnels" 2>/dev/null | grep -o '"public_url":"https://[^"]*' | head -n 1 | cut -d'"' -f4 || true)"
+  [ -n "$URL" ] && break
+  kill -0 "$NGROK_PID" 2>/dev/null || fail "ngrok se cerró al arrancar; lánzalo a mano para ver el error: ngrok ${ARGS[*]}"
+  sleep 1
+done
+[ -n "$URL" ] || fail "ngrok no dio una dirección pública en 30 s."
+
+echo "✓ En el móvil: $URL"
+echo "  La primera vez ngrok enseña un aviso: pulsa «Visit Site». Ctrl+C para cerrar."
+wait "$NGROK_PID"

package/targets/claude.js

@@ -14,7 +14,6 @@ const SHELL_TOOLS = 'Bash|PowerShell';
 export const CLAUDE_CODE_MODS = Object.freeze([
   { id: 'skins@hellosverre-mods', marketplace: 'hellosverre-mods', repo: 'hellosverre/claude-skins' },
   { id: 'savvy-progress@claude-kit', marketplace: 'claude-kit', repo: 'johnnyvizz/claude-kit' },
-  { id: 'filetree@claude-code-filetree', marketplace: 'claude-code-filetree', repo: 'data-goblin/claude-code-filetree' },
   { id: 'cache-tax@claude-code-mods', marketplace: 'claude-code-mods', repo: 'karanb192/claude-code-mods' },
 ]);