Du hast gerade einen Nachmittag damit verbracht, ein Dashboard, ein Portfolio oder eine Doku-Site zu bauen – und jetzt kommt der Teil, den niemand mag: das Ding online zu bekommen. Du brauchst einen Host, einen Deploy-Befehl, eine Möglichkeit, vor der Veröffentlichung vorzuschauen, und die Gewissheit, dass du zurückrollen kannst, wenn etwas kaputtgeht. Wer je um 23 Uhr eine Site deployed hat und auf der Live-URL einen kaputten Asset-Pfad fand, kennt den Schmerz. Hermes bringt jetzt eine optionale Skill mit, die dieses ganze Ritual in eine Fünf-Schritte-Pipeline mit einem Befehl verwandelt: publish-site.

Am 27. August 2026 gemergt (PR #72189), ist publish-site eine Skill ohne Kern-Fußabdruck – keine neuen Tools, keine Änderungen am Hermes-Kern – die dir dasselbe Ergebnis liefert wie ChatGPT Works „Sites“: eine Version speichern, deployen und bei Bedarf zurückrollen, auf Infrastruktur, die dir gehört. Es ist eine disziplinierte Pipeline: lokale Vorschau zur Freigabe, Version-vor-Deploy, eine Provider-Leiter, verpflichtende HTTP-200-Verifikation vor der Erfolgsmeldung – und Rollback einen Befehl entfernt.

Was die Skill tut

Die Pipeline besteht immer aus denselben fünf Schritten, und die SKILL.md der Skill schreibt jeden einzelnen mit exakten Befehlen vor:

1. Bauen – deinen Build-Schritt ausführen (npm run build usw.) und das Ausgabeverzeichnis identifizieren (dist/, build/).
2. Vorschau zur Freigabe – lokal servieren oder einen teilbaren Tunnel öffnen, damit jemand anderes vor dem Livegang zustimmen kann.
3. Committen + Tagen – jeden Deploy mit einem Git-Tag versionieren (Version-vor-Deploy).
4. Über die Provider-Leiter deployen – standardmäßig GitHub Pages; Cloudflare Pages oder Netlify, wenn du mehr brauchst.
5. Die Live-URL verifizieren – ein echter HTTP-Check, der 200 erwartet, bevor du Erfolg meldest.

Installieren mit:

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

Schritt für Schritt

1. Lokal vorschauen, bei Bedarf teilen

Bei Bedarf bauen und das Ausgabeverzeichnis servieren:

python3 -m http.server 8080 --directory dist

Für einen teilbaren Vorschau-Link – Nutzer auf einem anderen Rechner, oder du willst ihre Freigabe vor dem Livegang – öffne einen schnellen Tunnel in einer Hintergrund-Terminal-Session:

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

Du bekommst eine https://*.trycloudflare.com-URL zum Weiterreichen. Nach der Freigabe den Tunnel killen.

2. Version vor dem Deploy

Jeder Deploy bekommt einen Git-Tag – genau das macht Rollback später zu einem Einzeiler:

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

3. Durch die Provider-Leiter deployen

Die Skill prüft der Reihe nach authentifizierte Provider-CLIs:

Provider	Befehl	Voraussetzung
GitHub Pages (Standard)	git subtree push --prefix dist origin gh-pages	gh auth status gelingt
Cloudflare Pages	npx wrangler@latest pages deploy dist --project-name <name>	wrangler whoami gelingt oder CLOUDFLARE_API_TOKEN ist gesetzt
Netlify	netlify deploy --prod --dir dist	netlify status gelingt

Wenn du GitHub Pages in einem Repo aktivierst, das es noch nicht hat:

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

4. Mit einem echten HTTP-Check verifizieren

Vor der Erfolgsmeldung verlangt die Skill einen tatsächlichen HTTP-Check auf der Live-URL:

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

5. Bei Bedarf zurückrollen

Ein schlechter Deploy ist einen Befehl von weg: Den vorherigen Tag auschecken und neu deployen.

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

Wann sie nutzen (und wann nicht)

Lade die Skill, wenn du eine Site online bringen willst – „veröffentliche das“, „hoste das irgendwo“, „gib mir einen Link, den ich teilen kann“ – ein Dashboard/Report/Portfolio/Doku-Site deployen willst, das du gerade erzeugt hast, eine bereits veröffentlichte Site aktualisieren willst (Redeploy = neue Version), einen schlechten Deploy zurückrollen willst – oder einfach einen Host auswählen willst, weil dir egal ist, wo sie lebt. Sie deckt statische Sites und SPA-Build-Ausgaben ab: einfaches HTML/CSS/JS oder den dist//build/-Ordner von Vite, Next export, Astro usw.

Sie deckt nicht Server-seitige Runtimes ab. Für Wegwerf-Serverless-Deploys ganz ohne Konto-Einrichtung ist die Schwester-Skill cloudflare-temporary-deploy das richtige Werkzeug. Die Skill setzt außerdem mindestens eine authentifizierte Provider-CLI voraus – prüfe zuerst gh auth status, wrangler whoami oder netlify status.

Warum sich dieses Muster lohnt

Drei Gewohnheiten, die in der Skill stecken, sind es wert, übernommen zu werden, selbst wenn du sie nie installierst:

• Vorschau vor der Öffentlichkeit. Der teilbare Tunnel verwandelt „raus damit und beten“ in „erst Freigabe“ – ein Zwei-Minuten-Schritt, der kaputte Assets, falsche Base-Pfade und fehlende Fonts abfängt, bevor sie die Welt sehen.
• Jeden Deploy versionieren. Ein Git-Tag pro Deploy bedeutet: Jede Version ist reproduzierbar, und jeder Rollback ist ein Checkout entfernt. „Welche Version ist live?“ hat eine exakte Antwort.
• Verifizieren, bevor du fertig erklärst. Der HTTP-200-Check tötet die klassische Lüge: „Ich hab deployt“, wenn die Site eigentlich 404 liefert. Ein curl auf der Live-URL ist die einzige ehrliche Definition von Erfolg.

In deinen Hermes-Workflow einpassen

Die Skill ist dafür gebaut, vom Agenten automatisch geladen zu werden, wenn die Anfrage passt („veröffentliche das“, „deploye das“, „gib mir einen Link“) – dasselbe Trigger-basierte Modell wie bei anderen Hermes-Skills. Wenn du neu im Skill-System bist, wirf einen Blick auf unseren Guide zu projektlokalen Skills dafür, wie .hermes/skills/ funktioniert und wie Trust-Gates greifen, sowie auf unsere Übersicht der Top-Skills für das weitere Ökosystem. Für eine Tour, wie optionale Skills Hermes erweitern, ohne den Kern anzufassen, ist der publish-site-PR selbst eine saubere Lektüre – 476 Zeilen Ergänzungen, größtenteils SKILL.md plus Testsuite, null Kernänderungen.

Installieren und Nutzen der Skill ist ein Befehl, und die Disziplin, die sie kodiert – Vorschau, Tag, Deploy, Verifikation, Rollback – ist derselbe Workflow, für den professionelle Teams viel Tooling bezahlen. Jetzt ist es eine Skill, die du on demand laden kannst, auf Infrastruktur, die dir gehört. Wenn du das nächste Mal um 23 Uhr eine Site fertig hast, wird „deploye es“ eine Fünf-Schritte-Pipeline mit einer 200 am Ende sein – kein Gebet.