Você acabou de passar uma tarde construindo um dashboard, um portfólio ou um site de documentação — e agora vem a parte que ninguém gosta: colocá-lo no ar. Você precisa de um host, de um comando de deploy, de um jeito de pré-visualizar antes de publicar e da confiança de que consegue fazer rollback se algo quebrar. Se você já fez deploy de um site às 23h e só encontrou um caminho de asset quebrado na URL ao vivo, conhece essa dor. O Hermes agora traz uma skill opcional que transforma todo esse ritual num pipeline de cinco etapas em um único comando: publish-site.

Mesclada em 27 de agosto de 2026 (PR #72189), a publish-site é uma skill de pegada zero no core — sem novas tools, sem mudanças no core do Hermes — que entrega o mesmo resultado dos “Sites” do ChatGPT Work: salvar uma versão, fazer deploy e reverter se preciso, em infraestrutura sua. É um pipeline disciplinado: pré-visualização local para aprovação, versão antes do deploy, uma escada de providers, verificação obrigatória de HTTP 200 antes de reportar sucesso e rollback a um comando de distância.

O que a skill faz

O pipeline é sempre o mesmo, com cinco movimentos, e o SKILL.md da skill detalha cada um com comandos exatos:

1. Build — rode seu passo de build (npm run build, etc.) e identifique o diretório de saída (dist/, build/).
2. Pré-visualização para aprovação — sirva localmente, ou abra um túnel compartilhável para outra pessoa aprovar antes de ir ao ar.
3. Commit + tag — versione cada deploy com uma git tag (versão antes do deploy).
4. Deploy pela escada de providers — GitHub Pages por padrão; Cloudflare Pages ou Netlify quando você precisar de mais.
5. Verifique a URL ao vivo — uma checagem HTTP real esperando 200 antes de você reportar sucesso.

Instale com:

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

Passo a passo

1. Pré-visualize localmente, compartilhe se precisar

Faça o build se necessário e sirva o diretório de saída:

python3 -m http.server 8080 --directory dist

Para um link de pré-visualização compartilhável — usuário em outra máquina, ou você quer a aprovação dele antes de ir ao ar — abra um túnel rápido numa sessão de terminal em segundo plano:

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

Você recebe uma URL https://*.trycloudflare.com para entregar. Encerre o túnel depois da aprovação.

2. Versione antes do deploy

Todo deploy recebe uma git tag — é isso que torna o rollback um one-liner depois:

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

3. Faça deploy pela escada de providers

A skill verifica CLIs de providers autenticadas em ordem:

Provider	Comando	Pré-requisito
GitHub Pages (padrão)	git subtree push --prefix dist origin gh-pages	gh auth status com sucesso
Cloudflare Pages	npx wrangler@latest pages deploy dist --project-name <name>	wrangler whoami com sucesso ou CLOUDFLARE_API_TOKEN definido
Netlify	netlify deploy --prod --dir dist	netlify status com sucesso

Se você está ativando o GitHub Pages num repositório que ainda não tem:

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

4. Verifique com uma checagem HTTP real

Antes de reportar sucesso, a skill exige uma checagem HTTP de verdade na URL ao vivo:

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

5. Faça rollback quando precisar

Um deploy ruim está a um comando de distância: faça checkout da tag anterior e refaça o deploy.

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

Quando usar (e quando não usar)

Carregue a skill quando quiser colocar um site no ar — “publica isso”, “hospeda isso em algum lugar”, “me dá um link que eu possa compartilhar” — fizer deploy de um dashboard/relatório/portfólio/site de docs que você acabou de gerar, atualizar um site já publicado (redeploy = nova versão), reverter um deploy ruim, ou apenas escolher um host porque você não se importa onde ele vive. Ela cobre sites estáticos e saída de build de SPA: HTML/CSS/JS puro, ou a pasta dist//build/ do Vite, Next export, Astro, etc.

Ela não cobre runtimes server-side. Para deploys serverless descartáveis sem nenhuma configuração de conta, a skill irmã opcional cloudflare-temporary-deploy é a ferramenta certa. A skill também assume pelo menos uma CLI de provider autenticada — verifique gh auth status, wrangler whoami ou netlify status primeiro.

Por que vale a pena adotar esse padrão

Três hábitos embutidos na skill valem ser roubados mesmo que você nunca a instale:

• Pré-visualize antes de publicar. O túnel compartilhável transforma “publicar e rezar” em “aprovar primeiro” — um passo de dois minutos que pega assets quebrados, base paths errados e fontes faltando antes que fiquem visíveis para o mundo.
• Versione todo deploy. Uma git tag por deploy significa que qualquer versão é reproduzível e qualquer rollback está a um checkout de distância. “Qual versão está no ar?” tem uma resposta exata.
• Verifique antes de declarar pronto. A checagem de HTTP 200 mata a mentira clássica: “fiz o deploy” quando o site na verdade responde 404. Um curl na URL ao vivo é a única definição honesta de sucesso.

Como encaixá-la na sua workflow com o Hermes

A skill foi projetada para ser carregada pelo agente automaticamente quando a solicitação corresponder (“publica isso”, “faz deploy disso”, “me dá um link”) — o mesmo modelo baseado em gatilhos das outras skills do Hermes. Se você é novo no sistema de skills, veja o nosso guia de skills locais ao projeto para entender como funciona o .hermes/skills/ e como os trust gates se aplicam, e a nossa visão geral das principais skills para o ecossistema mais amplo. Para um tour de como skills opcionais estendem o Hermes sem tocar no core, o próprio PR do publish-site é uma leitura limpa — 476 linhas de adições, na maior parte SKILL.md mais a suíte de testes, zero mudanças no core.

Instalar e usar a skill é um comando, e a disciplina que ela codifica — preview, tag, deploy, verify, rollback — é a mesma workflow pela qual equipes profissionais pagam muito em tooling. Agora é uma skill que você pode carregar sob demanda, em infraestrutura sua. Da próxima vez que você terminar um site às 23h, “faz o deploy” será um pipeline de cinco etapas com um 200 no final — não uma prece.