Acabas de pasarte una tarde construyendo un dashboard, un portfolio o un sitio de documentación — y ahora llega la parte que nadie disfruta: ponerlo en línea. Necesitas un hosting, un comando de deploy, una forma de previsualizarlo antes de que sea público y la confianza de poder hacer rollback si algo se rompe. Si alguna vez desplegaste un sitio a las 11 de la noche y descubriste en la URL en vivo una ruta de assets rota, conoces el dolor. Hermes ahora incluye una skill opcional que convierte todo este ritual en un pipeline de cinco pasos y un solo comando: publish-site.

Fusionada el 27 de agosto de 2026 (PR #72189), publish-site es una skill con huella cero en el core — sin tools nuevas, sin cambios en el núcleo de Hermes — que te da el mismo resultado que los «Sites» de ChatGPT Work: guardar una versión, desplegar y hacer rollback si hace falta, en infraestructura tuya. Es un pipeline disciplinado: vista previa local para la aprobación, versionar antes de desplegar, una escalera de proveedores, verificación obligatoria de HTTP 200 antes de declarar el éxito y rollback a un comando de distancia.

Qué hace la skill

El pipeline siempre son los mismos cinco movimientos, y el SKILL.md de la skill detalla cada uno con comandos exactos:

1. Build — ejecuta tu paso de build (npm run build, etc.) e identifica el directorio de salida (dist/, build/).
2. Vista previa para la aprobación — sírvelo localmente, o abre un tunnel compartible para que otra persona pueda aprobarlo antes de que sea público.
3. Commit + tag — versiona cada deploy con un git tag (versionar antes de desplegar).
4. Deploy a través de la escalera de proveedores — GitHub Pages por defecto; Cloudflare Pages o Netlify cuando necesites más.
5. Verifica la URL en vivo — una comprobación HTTP real que espera 200 antes de que declares el éxito.

Instálala con:

hermes skills install official/web-development/publish-site

Paso a paso

1. Vista previa local, comparte si hace falta

Haz build si hace falta y sirve el directorio de salida:

python3 -m http.server 8080 --directory dist

Para un enlace de vista previa compartible — un usuario en otra máquina, o quieres su aprobación antes de que sea público — abre un tunnel rápido en una sesión de terminal en segundo plano:

cloudflared tunnel --url http://localhost:8080

Obtienes una URL https://*.trycloudflare.com para entregar. Mata el tunnel después de la aprobación.

2. Versionar antes de desplegar

Cada deploy recibe un git tag — esto es lo que convierte el rollback en una línea más adelante:

git add -A && git commit -m "deploy: <what>" && git tag deploy-YYYYMMDD-HHMM

3. Desplegar a través de la escalera de proveedores

La skill comprueba los CLIs autenticados de los proveedores en orden:

Proveedor	Comando	Requisito previo
GitHub Pages (por defecto)	git subtree push --prefix dist origin gh-pages	gh auth status tiene éxito
Cloudflare Pages	npx wrangler@latest pages deploy dist --project-name <name>	wrangler whoami tiene éxito o CLOUDFLARE_API_TOKEN está definido
Netlify	netlify deploy --prod --dir dist	netlify status tiene éxito

Si estás activando GitHub Pages en un repo que todavía no lo tiene:

gh api repos/{owner}/{repo}/pages -X POST -f 'source[branch]=gh-pages' -f 'source[path]=/'

4. Verificar con una comprobación HTTP real

Antes de declarar el éxito, la skill exige una comprobación HTTP real sobre la URL en vivo:

curl -sS -o /dev/null -w '%{http_code}' <url>    # se espera 200

5. Rollback cuando haga falta

Un deploy malo está a un comando de desaparecer: haz checkout del tag anterior y vuelve a desplegar.

git checkout <previous-tag> -- . && redeploy

Cuándo usarla (y cuándo no)

Carga la skill cuando quieras poner un sitio en línea — «publica esto», «aloja esto en algún sitio», «dame un enlace que pueda compartir» — desplegar un sitio de dashboard/informe/portfolio/docs que acabas de generar, actualizar un sitio ya publicado (redeploy = nueva versión), hacer rollback de un deploy malo, o simplemente elegir un hosting porque te da igual dónde viva. Cubre sitios estáticos y salidas de build de SPAs: HTML/CSS/JS plano, o la carpeta dist//build/ de Vite, Next export, Astro, etc.

No cubre los runtimes del lado del servidor. Para deploys serverless desechables sin configuración de cuentas, la skill opcional hermana cloudflare-temporary-deploy es la herramienta adecuada. La skill también asume que tienes al menos un CLI de proveedor autenticado — comprueba primero gh auth status, wrangler whoami o netlify status.

Por qué merece la pena adoptar este patrón

Tres hábitos incrustados en la skill merecen la pena copiarse aunque nunca la instales:

• Vista previa antes de publicar. El tunnel compartible convierte «subir y rezar» en «primero la aprobación» — un paso de dos minutos que detecta assets rotos, base paths incorrectos y fuentes que faltan antes de que sean visibles para el mundo.
• Versiona cada deploy. Un git tag por deploy significa que cualquier versión es reproducible y cualquier rollback está a un checkout de distancia. «¿Qué versión está en vivo?» tiene una respuesta exacta.
• Verifica antes de declarar terminado. La comprobación HTTP-200 mata la mentira clásica: «ya lo desplegué» cuando el sitio en realidad devuelve 404. Un curl sobre la URL en vivo es la única definición honesta de éxito.

Cómo encaja en tu workflow de Hermes

La skill está diseñada para que el agente la cargue automáticamente cuando la solicitud coincide («publica esto», «despliega esto», «dame un enlace») — el mismo modelo basado en triggers que el resto de skills de Hermes. Si eres nuevo en el sistema de skills, consulta nuestra guía de skills locales al proyecto para entender cómo funciona .hermes/skills/ y cómo se aplican los trust gates, y nuestra visión general de las mejores skills para el ecosistema más amplio. Para un recorrido de cómo las skills opcionales extienden Hermes sin tocar el core, el propio PR de publish-site es una lectura limpia — 476 líneas de adiciones, en su mayoría SKILL.md más su suite de tests, cero cambios en el core.

Instalar y usar la skill es un solo comando, y la disciplina que codifica — vista previa, tag, deploy, verificación, rollback — es el mismo workflow por el que los equipos profesionales pagan mucho tooling. Ahora es una skill que puedes cargar bajo demanda, en infraestructura tuya. La próxima vez que termines un sitio a las 11 de la noche, «despliégalo» será un pipeline de cinco pasos con un 200 al final — no una oración.