claude-skills — repo de skills propios de Claude Code

Repo privado (github.com/ehalso/claude-skills) que distribuye los skills propios de Claude Code de Esteban hacia ~/.claude/skills en cada host de la flota. Reemplazó, el mismo día que se creó (2026-08-09), a un folder de Syncthing que hacía lo mismo en tiempo real — Esteban prefirió git: historial versionado, sin el paso de aprobación manual por GUI que requiere emparejar un dispositivo nuevo, y consistente con cómo ya se distribuye esta misma wiki (git pull, no un daemon de sincronización).

Deliberadamente no incluye las skills de Cloudflare (cloudflare, wrangler, agents-sdk, durable-objects, sandbox-sdk, turnstile-spin, web-perf, workers-best-practices, cloudflare-email-service, cloudflare-one, cloudflare-one-migrations) que ya viven en ~/.claude/skills en cada host — esas son copias manuales, sin versionar, de github.com/cloudflare/skills, distribuidas oficialmente vía el marketplace de plugins de Claude Code (claude-plugins-official, registrado en ~/.claude/plugins/known_marketplaces.json, plugin cloudflare). El mecanismo “correcto” a futuro para esas es instalarlas como plugin real en vez de copias sueltas — pero migrarlas quedó fuera de alcance por decisión explícita de Esteban; este repo las deja intactas y nunca las sobreescribe (ver más abajo).

Estructura

claude-skills/
  README.md
  skills/
    <nombre>/
      SKILL.md
  tools/
    pull.sh              # clone-or-pull + symlink hacia ~/.claude/skills
    bootstrap-auth.sh    # deploy key de solo lectura por host
    systemd/
      claude-skills-pull.service
      claude-skills-pull.timer
      install-timer.sh

Clonado en ~/proyectos/claude-skills en la mayoría de la flota — mismo patrón que ~/proyectos/wiki-personal. La carpeta skills/ anida cada skill igual que el repo upstream cloudflare/skills, mismo patrón que ya documentaba ~/.claude/skills/turnstile-spin/README.md para symlinkear skills de Cloudflare a mano.

vm-playground es la excepción desde 2026-08-15: ambos repos (este y wiki-personal) se movieron a ~/ehalso/<repo> en ese host — carpeta dedicada en el home, con nombre de la cuenta de GitHub dueña (ehalso), en vez de vivir bajo ~/proyectos/. Esto solo era seguro porque pull.sh/claude-skills-pull.service se generalizaron en el mismo cambio — ver “Ruta del repo configurable” abajo; sin eso, mover el directorio habría desincronizado este host de la ruta hardcodeada que usa el timer en el resto de la flota.

Ruta del repo configurable (desde 2026-08-15)

tools/pull.sh y claude-skills-pull.service traían proyectos/claude-skills hardcodeado — funcionaba mientras todos los hosts clonaran ahí, pero no dejaba que un host individual usara otra ruta sin editar el script compartido (rompiendo a todos los demás en el próximo pull). Ahora leen CLAUDE_SKILLS_REPO_PATH_REL (relativa a $HOME) con ese mismo valor como default, así que ningún host cambia de comportamiento a menos que se lo pida explícitamente:

• pull.sh: REPO_PATH_REL="${CLAUDE_SKILLS_REPO_PATH_REL:-proyectos/claude-skills}".
• claude-skills-pull.service: EnvironmentFile=-%h/.config/claude-skills/env (opcional, el - evita que falle si no existe) antes del ExecStart, que resuelve la ruta vía $HOME/${CLAUDE_SKILLS_REPO_PATH_REL:-proyectos/claude-skills}.
• install-timer.sh <alias|local> [ruta_repo_relativa_a_HOME] acepta la ruta como segundo argumento opcional y escribe ~/.config/claude-skills/env en el host de destino con ese valor — un solo paso, sin tocar el repo compartido.

vm-playground tiene ~/.config/claude-skills/env con CLAUDE_SKILLS_REPO_PATH_REL=ehalso/claude-skills ya escrito, aunque el timer sigue sin instalarse ahí (ver más abajo) — queda listo para cuando se instale.

Mecanismo de pull: manual + timer

tools/pull.sh <alias|local> clona el repo si falta o hace git pull --ff-only si ya existe, y por cada carpeta en skills/ crea (o confirma) un symlink en ~/.claude/skills/<nombre>. Nunca sobreescribe un nombre que ya exista ahí como carpeta real o symlink hacia otro lado — es el mecanismo concreto que protege las skills de Cloudflare de que este repo las pise por accidente.

Cada host además corre un timer systemd --user (claude-skills-pull.timer, unidades versionadas en tools/systemd/ y enlazadas a ~/.config/systemd/user/) que llama a pull.sh local cada 20 minutos — un skill nuevo queda disponible sin intervención dentro de la misma sesión de trabajo. Requiere loginctl enable-linger en el usuario del host (obligatorio en VMs sin sesión de escritorio persistente, como vm-personal; se verifica explícitamente antes de habilitar el timer, nunca se asume). Pendiente en vm-playground: el repo se movió ahí el 2026-08-10 pero no se configuró el timer (tools/bootstrap-auth.sh/install-timer.sh), solo el clon — quedó fuera de alcance del rediseño de infraestructura que motivó la mudanza.

Autenticación por host

pop-os y vm-playground reusan las credenciales HTTPS de gh (cuenta ehalso, ya autenticada — vm-playground la usa también para wiki-personal). vm-personal recibe una deploy key SSH de solo lectura, dedicada a este repo — generada en el propio host, registrada vía gh repo deploy-key add --allow-write=false corrido desde pop-os (el único host con gh autenticado en ese momento), y usada a través de un alias SSH dedicado (Host github-claude-skills en ~/.ssh/config de ese host, IdentityFile ~/.ssh/claude_skills_deploy).

vm-playground se sumó el 2026-08-10 (rediseño vm-producción/vm-workstation, mudó el repo desde vm-backup, decomisionada — ver hosts.md) vía gh repo clone directo, no el flujo de bootstrap-auth.sh/deploy key — más simple porque gh ya estaba autenticado ahí para otra cosa. El clon de vm-backup estaba desactualizado un commit (nunca corrió el pull automático); se tomó la versión de GitHub, no la de vm-backup.

Por qué un alias dedicado y no git@github.com a secas: en pop-os y vm-personal, el alias SSH por default hacia github.com ya está tomado — apunta a ~/.ssh/github_ck, que autentica como una cuenta de GitHub distinta a ehalso (ealcocer, la del trabajo en Conkafecito). Usar el default por error clonaría con la identidad equivocada y fallaría por permisos, ya que este repo es privado bajo ehalso.

Hallazgo del rollout: ~/.ssh/ está sincronizado por Syncthing entre pop-os y vm-personal (ver Syncthing) — la llave de deploy generada en vm-personal se replicó también a pop-os por esa vía (no a vm-backup, que no participa de ese folder). No representa un problema real al ser una llave de solo lectura, pero rompe la intención de “una llave por host” — queda documentado por si hace falta revisarlo más adelante.

tools/bootstrap-auth.sh <host> automatiza todo el flujo (llave, alias, host key de github.com en known_hosts, registro de la deploy key) y es idempotente — seguro de correr de nuevo en un host ya configurado.

ctunlinux se sumó el 2026-08-10 — primer host de Trivasa, primer skill real

Hasta entonces el repo solo tenía skills/_template/ (placeholder para probar el pipeline). El primer skill real, rich-output-checks (convención de salida rich/stdout-stderr para scripts de comprobación — ver Workflow de exploración de datos), se agregó el mismo día que se onboardeó ctunlinux, generalizando trivasa-bi-dev/exploracion/layout_gastos/helpers_output.py a un módulo sin dependencias del directorio original.

Por qué ctunlinux no siguió el patrón de auth existente tal cual: no tiene gh instalado ni autenticado (a diferencia de pop-os/vm-playground), así que en principio tocaba el patrón de deploy key SSH de vm-personal — pero bootstrap-auth.sh asume que se corre desde una máquina con gh ya autenticado como ehalso, apuntando hacia el host nuevo por SSH. Trabajando directo en ctunlinux (sin esa otra máquina a mano en la sesión), el flujo real fue distinto:

1. Se generó la llave dedicada (~/.ssh/claude_skills_deploy) y el alias github-claude-skills en ~/.ssh/config a mano en ctunlinux, mismo resultado que bootstrap-auth.sh pero corrido en sentido local, no remoto.
2. El registro de la deploy key en GitHub se hizo vía API REST directa (POST /repos/ehalso/claude-skills/keys), no gh repo deploy-key add — usando el mismo PAT que ya existía para wiki-personal (GITHUB_WIKI_PERSONAL_TOKEN), al que se le amplió el alcance para cubrir también claude-skills. Dos permisos hicieron falta, en dos rondas (el usuario amplió el token vía la web de GitHub cada vez, no hay endpoint para que un token se auto-amplíe): Contents: Read and write no alcanzó para el endpoint de deploy keys, que exige Administration: Read and write — error real visto: 403 "Resource not accessible by personal access token".
3. tools/pull.sh no soportaba “local” con deploy key — el script original asumía que local siempre significa HTTPS+gh (patrón pop-os) y que SSH+deploy-key solo aplica a hosts remotos orquestados desde otra máquina. Se generalizó remote_url_for(): si el host es local y existe ~/.ssh/claude_skills_deploy, usa la URL SSH en vez de asumir HTTPS — retrocompatible (pop-os no tiene ese archivo, sigue en HTTPS) y necesario para que cualquier host futuro que se onboardee vía deploy key (no solo orquestado desde otra máquina) pueda correr pull.sh local consigo mismo, que es justo lo que invoca el timer de systemd.

Resultado verificado end-to-end en ctunlinux: pull.sh local clonó, symlinkeó rich-output-checks y _template en ~/.claude/skills/, y el timer claude-skills-pull.timer quedó enabled+active (requirió loginctl enable-linger primero, no estaba activo en este host).

Segundo skill real, mismo día: trivasa-comprobacion — metodología completa de comprobación (filosofía, convenciones SQL contra TRIVASADB, semáforo de color, protocolo de diagnóstico), fusionando lo que hasta entonces vivía suelto en content/trivasa/estilo_comprobacion.md. Deliberadamente no se fusionó con rich-output-checks pese a usarse siempre juntos en la práctica — rich-output-checks ya lo usaba raw-checks/ (proyecto Trivasa distinto, sin nada de las reglas de negocio de layout_gastos) y meterle reglas de negocio específicas lo habría vuelto menos genérico para ese otro consumidor. trivasa-comprobacion depende de rich-output-checks para el formato de salida (lo referencia, no lo duplica).

ctunlinux: symlinks del timer rotos por la mudanza del repo (reparado 2026-08-25)

Cuando el repo se movió de ~/proyectos/claude-skills a ~/ehalso/claude-skills en este host (ver “Ruta del repo configurable” arriba), claude-skills-pull.service y .timer se quedaron symlinkeados hacia la ruta vieja — systemctl --user list-unit-files los reportaba en estado bad. El pull automático llevaba tiempo sin correr sin que nadie lo notara — mismo tipo de falla silenciosa que ya afectaba a vm-playground (nunca llegó a instalarse ahí, ver arriba), pero esta vez sobre un host que sí lo tuvo funcionando y se rompió después.

Reparado corriendo install-timer.sh local ehalso/claude-skills desde el propio host: reescribe ~/.config/claude-skills/env (CLAUDE_SKILLS_REPO_PATH_REL=ehalso/claude-skills), re-symlinkea ambas unidades hacia ~/ehalso/claude-skills/tools/systemd/ y re-habilita el timer.

Se reprodujo en vivo el gotcha de split-brain ya documentado más abajo (§ duckdb-html-explore): antes de correr install-timer.sh, se probó pull.sh local a mano sin exportar la env var primero — cayó al default hardcodeado y clonó un segundo repo divergente en ~/proyectos/claude-skills, symlinkeando ahí mpro-reporte-asp (skill nuevo desde la última vez que corrió el timer) mientras los demás seguían apuntando a ~/ehalso/claude-skills. Se corrigió borrando el clon accidental y re-corriendo con export $(cat ~/.config/claude-skills/env | xargs) && pull.sh local. Confirmado con una corrida real disparada por systemctl --user start claude-skills-pull.service (no solo el script a mano) y el timer reagendado correctamente (próxima corrida a 20 min de esa invocación).

Tercer skill real, 2026-08-17: duckdb-html-explore (deprecado 2026-08-18)

Deprecado un día después. Ver Cuarto skill real: torep abajo — al preguntarle a Esteban por qué necesitaba esto, salió que ya tenía una herramienta propia en ctunlinux (torep, 2026-08-14) que resolvía el mismo problema de forma más general (cualquier script, no solo queries DuckDB) y llevaba días sin promoverse a skill. Se retiró del repo en vez de mantener dos soluciones que se pisan. Queda esta sección como historial de por qué existió y qué se aprendió armándolo — el código ya no está en el repo, solo este relato.

Nace de una pregunta directa de Esteban (¿hay skill para exportar los prints de una exploración a HTML y servirlos?) que reveló que no existía nada así — solo rich-output-checks (tablas en terminal) y el patrón manual de Claude Code remoto — visualizar outputs (Rich) desde el cel (SVG + túnel público de Cloudflare, pensado para ver output desde el cel).

A diferencia de los dos skills anteriores, no nace de trivasa-bi-dev — es genérico desde el origen, sin depender de ningún proyecto puntual. Usa el CLI de DuckDB (duckdb -html, no el binding de Python — requiere instalarlo aparte, curl -fsSL https://install.duckdb.org | sh) para correr una o más queries y armar un reporte HTML único (una sección por query, SQL colapsado arriba de cada tabla, texto largo sin truncar a diferencia de rich en terminal). Se sirve con python -m http.server, solo por red local/NetBird — a propósito, sin túnel público por default a diferencia de visualizar-rich-remoto.md, porque las exploraciones que arma suelen ser sobre datos de negocio (Trivasa) y no vale el riesgo de una URL pública, aunque sea efímera, solo para verlas desde el cel.

Corrección encontrada al probarlo: el modo .mode html del CLI de DuckDB (1.5.5) emite filas <tr>/<th>/<td> sueltas, sin la etiqueta <table> envolvente — a diferencia de lo que hace sqlite3 (de donde DuckDB hereda el shell). El script las envuelve explícitamente en vez de asumir el fragmento ya válido.

Segundo hallazgo, al onboardear el skill en vm-playground con pull.sh local corrido a mano: la variable CLAUDE_SKILLS_REPO_PATH_REL (ver “Ruta del repo configurable” arriba) solo se carga sola vía el EnvironmentFile= del timer de systemd — que en vm-playground sigue sin instalarse. Sin exportarla a mano primero, pull.sh local cae al default hardcodeado y clona un segundo repo divergente en ~/proyectos/claude-skills, symlinkeando ahí cualquier skill nuevo mientras los ya existentes siguen apuntando a ~/ehalso/claude-skills — estado split-brain. Se corrigió borrando el clon accidental y re-corriendo con export $(cat ~/.config/claude-skills/env | xargs) && ./tools/pull.sh local. Cualquier pull manual futuro en vm-playground necesita ese export primero.

Detalle completo del skill (uso, ejemplos, requisitos) en su propio SKILL.md: claude-skills/skills/duckdb-html-explore/SKILL.md (ya no existe en el repo, ver historial de git en el commit que lo agregó, 2026-08-17).

Cuarto skill real, 2026-08-18: torep (promovido desde ctunlinux)

A diferencia de los tres anteriores, no nace en esta sesión — es una herramienta que Esteban ya tenía corriendo en ctunlinux desde el 2026-08-14 (~/torep/torep, bash, fuera de control de versiones), documentada en la wiki de arquitectura de trivasa-bi-core (trivasa.ehas.uk/arquitectura/stack-bi/#torep-..., sitio distinto a este). Salió a la luz al revisar por qué hacía falta duckdb-html-explore — Esteban la había creado justo para el caso de uso de Claude Code remoto desde el cel, pero nunca la conectó con los skills de este repo.

Qué hace: envuelve la ejecución de un script .py o .sql con script -qec (captura la sesión de pty completa: prints, tracebacks, tablas rich, colores) + aha --black (ANSI a HTML), y apila el resultado en un reporte HTML por carpeta de proyecto que crece con cada corrida (~/torep-www/<carpeta>.html, más un index.html autogenerado, ordenable por nombre o última corrida). Estrictamente más capaz que duckdb-html-explore: no limitado a DuckDB, y el reporte acumula historial en vez de generarse de cero cada vez.

Por qué se pudo promover sin reescribir nada: el script en sí ya no tenía nada hardcodeado a ctunlinux — ni rutas absolutas del host, ni credenciales. Solo dependía de que script y aha estuvieran en PATH (aha no viene por default, sudo apt install aha) y de la variable REPORT_DIR (default ~/torep-www, ya configurable). Se copió literal, agregando solo un chequeo de dependencias con mensaje de instalación — mismo patrón que el chequeo de duckdb en el skill anterior.

Cómo se obtuvo el código: vm-playground no tiene acceso SSH directo a ctunlinux (sin alias, sin llave dedicada para ese host) — se leyó vía vm-personal como jump host, que sí tiene el alias TRV_ctunlinux en su ~/.ssh/config (usuario ealcocer, llave ~/.ssh/trv_onprem_surface, red on-prem 192.168.117.x).

Decisión explícita: server manual, no systemd. A diferencia de tenerlo siempre activo, se mantiene el patrón original (python3 -m http.server 8000 --directory ~/torep-www, levantado a mano con nohup/disown) — no vale la pena dejar un puerto abierto todo el tiempo solo para el caso ocasional de revisar algo desde el cel.

Nota pendiente: la doc original en trivasa.ehas.uk (sitio de trivasa-bi-core, no este repo) sigue describiendo torep como “helper personal… fuera de control de versiones” — desactualizada desde esta promoción, pero corregirla queda fuera del alcance de esta wiki (repo distinto, sin acceso de escritura confirmado desde aquí).

Detalle completo del skill en su propio SKILL.md: claude-skills/skills/torep/SKILL.md.

Rediseño de formato, mismo día (2026-08-18)

Al usarlo en vivo desde el cel (sesión de Claude Code sobre trivasa-bi-dev, reconciliación de CONSUMO_INTERNO), el formato heredado de ctunlinux (texto monoespaciado, tema oscuro fijo, tabla ASCII de duckdb a stty cols 200) resultó ilegible en pantalla angosta — el navegador partía las columnas de la tabla a la mitad. Iterado en vivo, comparando screenshots reales del cel contra cada cambio:

1. append → prepend: el bloque más reciente se inserta justo después de <body> en vez de al final del archivo — evita tener que scrollear todo el historial acumulado para ver la última corrida.
2. stty cols 200 → 100: paliativo menor, no resolvió el problema de fondo (una tabla con muchas columnas sigue rompiéndose a cualquier ancho fijo en pantalla angosta).
3. Se probaron los modos nativos de duckdb (duckbox, markdown, line, list) contra la misma query real — line (un campo = valor por línea, sin tabla de ancho fijo) fue el único legible en el cel, pero sacrifica la vista tabular.
4. Se intentó .mode html de duckdb (que si emite HTML real, una <table> — ver hallazgo del skill retirado duckdb-html-explore más arriba) pasado por el pipeline script+aha existente — falla: aha escapa cualquier texto que capture, incluyendo HTML literal, así que la tabla salía como texto <tr><td>... en vez de renderizarse. aha está diseñado para convertir ANSI a HTML, no para dejar pasar HTML ya armado.
5. Fix real: para .sql, dejar de pasar por script/aha por completo — duckdb -mode html ya produce una <table> (fragmento sin <table> envolvente, hay que agregarla) sin necesidad de pty ni conversión ANSI. Envuelta en un <div overflow-x:auto> en vez de forzar width:100% (que es lo que comprimía las columnas) — el usuario scrollea horizontal en vez de que el navegador encoja cada celda. aha deja de ser dependencia dura: solo se exige si el archivo corrido no es .sql.
6. Para .py/genérico, se mantiene script+aha (sigue siendo el único mecanismo agnóstico a qué imprima el script — tabla rich, texto plano, traceback), pero con aha --no-header (flag que ya existía, sin usar) en vez de aha --black a secas — evita que cada bloque traiga su propio <html><head><body> completo, que generaba documentos anidados al insertarse dentro del reporte acumulado (mismo problema de fondo que tendría usar rich Console.save_html() completo en vez de Console.export_html(inline_styles=True), si se llegara a integrar rich directo algún día — se evaluó y descartó por ahora: cambiar de mecanismo solo para scripts que usan rich rompería la promesa de “cualquier script, sin que coopere”, que es la ventaja real de este flujo frente a una integración específica de rich).
7. Tema visual: se adoptó el mismo look de duckdb-html-explore (retirado el día anterior) — color-scheme: light dark, sans-serif, en vez del tema oscuro fijo/monoespaciado original de ctunlinux.
8. Estructura nueva — maestro + individuales:

   $REPORT_DIR/<carpeta>.html       <- maestro, como siempre (acumulado)
   $REPORT_DIR/<carpeta>/NNN-*.html <- un standalone por corrida, mismo
                                        bloque que se le hizo append al
                                        maestro, con su propio head/CSS
   

   Cada bloque del maestro trae un link ”↗ ver individual” al archivo standalone correspondiente — se puede compartir/abrir una sola corrida sin arrastrar todo el historial acumulado del proyecto.
9. Cada bloque además trae timestamp de la corrida (antes solo tenía el nombre del archivo y el exit code).

Validado end-to-end con ambos caminos (.sql con duckdb -mode html, .py con un traceback real a propósito) — confirmado un solo <html> en todo el archivo maestro (sin duplicación de head), exit code correcto detectado en rojo para el script que truena.

Quinto skill real, 2026-09-02: trivasa-sql-exploracion (reconstruido, no creado desde cero)

A diferencia de los cuatro anteriores, este skill no nació en la sesión que lo empaquetó — existía como referencia fantasma: trivasa-context/CLAUDE.md (sección “Regla de promoción”) menciona el patrón de nombre NN_slug.py y “el skill trivasa-sql-exploracion” desde que ese repo existe, pero el archivo nunca se creó. La convención completa (lista de slugs de referencia: columnas, conteo, agrupado, filtro, diff, drilldown, muestra, notebook, validacion) sí se había refinado a fondo, pero en una sesión de Claude Code sobre notificacion-solicitud-material (ctunlinux, 2026-08-13) cuyo PROGRESS.md anotó el ajuste con la coletilla “este chat, no en el repo” — se quedó documentado de pasada en el estado vivo de un proyecto, nunca en el skill al que nombraba.

Cómo salió a la luz: Esteban pidió localizar convencion_output_scripts.md (resuelto de inmediato, vive en wiki-personal/sources/trivasa/layout-gastos/) y, en el mismo hilo, preguntó por otra convención que recordaba haber armado — el prefijo numérico + tipo de script (01_check_ALGO, 02_baseline_ALGO) — que ya no encontraba en ningún lado. Búsqueda exhaustiva en ~/ehalso, ~/trivasa y el historial de conversaciones no encontró un documento así; sí encontró el patrón real en los nombres de archivo de tres proyectos (consumo_interno_trazabilidad, notificacion-solicitud-material, existencia_a_una_fecha) sin que ninguno documentara la regla. La pista que cerró el caso llegó al revisar ~/por_ordenar vía SSH a ctunlinux (ya no existe en el WS local): el CLAUDE.md de trivasa-context señalaba al skill fantasma, y su PROGRESS.md de origen tenía el detalle completo.

Contenido del skill: el workflow puntual-vs-reusable, patrón de conexión, heredoc y checklist de exploración, heredados casi literales de Workflow de exploración de datos (que queda como referencia histórica de origen para esas secciones, mismo patrón que estilo_comprobacion.md con trivasa-comprobacion) — más, por primera vez en un archivo real, la convención NN_slug.py completa: numeración correlativa (no es índice de etapas del proyecto — sufijos de letra como 08b_/08c_ para variantes del mismo hito), slugs de referencia documentados originalmente, y los que se ampliaron en la práctica (check, baseline, diagnostico, reconciliacion, test, verificar, load, resumen) con ejemplos reales de los tres proyectos citados arriba. Depende de trivasa-comprobacion (metodología de reconciliación) y rich-output-checks (formato de salida) en vez de duplicarlos — mismo principio de composición que ya seguía trivasa-comprobacion con rich-output-checks.

Detalle completo en su propio SKILL.md: claude-skills/skills/trivasa-sql-exploracion/SKILL.md.

Agregar un skill nuevo

Crear skills/<nombre>/SKILL.md en el repo, commitear y hacer push. Cada host lo recoge solo en el siguiente tick del timer (máx. 20 min), o al correr tools/pull.sh <host> a mano.

Véase también

• Syncthing — mecanismo que este repo reemplazó para este caso puntual; sigue vigente para .ssh entre pop-os y vm-personal
• Acceso SSH entre VMs — mismos hosts, mismo tipo de alias dedicados en ~/.ssh/config