1. Januar 2026 · 6 Min

Eine Website nebenbei gebaut — KI-Workflow für Einsteiger

Eine moderne Website soll her. Aber nicht “modern” im Sinne von “sieht aus wie jedes SaaS-Startup”. Kein Theme von der Stange. Kein Template. Kein Tracking.

Also bekommt OpenCode den Auftrag: “Bau mir eine persönliche Website.” Und dann entsteht nicht nur das Design — sondern der gesamte Tech-Stack gleich mit: Hugo, Tailwind, Logo, Favicon. Alles aus dem Gespräch heraus. Einer gibt die Richtung vor, OpenCode setzt um.

Was ist OpenCode? Ein KI-gestütztes Entwicklungswerkzeug im Terminal. OpenCode nutzt KI-Modelle über beliebige Schnittstellen — gute Erfahrungen gibt es mit deepseek-v4-flash und deepseek-v4-pro. Es liest Projektdateien, schreibt Code und erledigt Aufgaben auf Zuruf. Das Besondere: Wiederholbare Anleitungen (Skills), eigene Werkzeug-Schnittstellen (MCPs) und automatisierte Workflows. → opencode.ai

Die Skills — der Motor des Workflows

Der wichtigste Teil sind nicht die einzelnen Werkzeuge, sondern die Skills — wiederholbare Anleitungen, die den Workflow steuern.

Ohne Skills müsste bei jedem Durchlauf der gleiche Prompt getippt werden: “Mach einen Screenshot. Bewerte das Layout. Verbessere. Wiederhole.” Mit Skills wird der Ablauf einmal definiert — und die KI führt ihn selbstständig aus, auch ohne dass jemand am Rechner sitzt.

Zwei Skills steuern den Prozess:

website-builder: “Bau eine Hugo-Seite. Screenshot. Review. Verbessere. Wiederhole.”

logo: “Generiere Logo-Varianten. Screenshot. Bewerte. Iteriere.”

Der Ablauf ist jedes Mal gleich:

Der Skill meldet: “Drei Logo-Varianten sind fertig”
Playwright erstellt Screenshots von jeder
Ein Subagent namens vision-reviewer bewertet sie — Abstände, Farben, Skalierung, Lesbarkeit bei 16×16 Pixeln
Der Skill verbessert — und startet von vorn

19 Iterationen später ist das Logo fertig. Alle automatisch geprüft, der Mensch entscheidet nur noch.

Das Entscheidende: Ein Skill funktioniert auch unbeaufsichtigt. Das Projekt wird angestoßen, dann arbeiten Skills und Agents über Stunden selbstständig — Screenshots vergleichen, Alternativen durchrechnen, Ergebnisse katalogisieren. Später heißt es nur noch: “Nummer 17.”

Warum Hugo? Hugo ist ein Generator für statische Webseiten — er baut aus Textdateien fertige HTML-Seiten. Er kommt als einzelnes Programm (Binary), braucht keine Datenbank und kein JavaScript-Framework. Das bedeutet: keine Updates, keine Sicherheitslücken, kein Wartungsaufwand.

Der Motor und seine Zahnrädchen

Ein Skill sagt: “Mach einen Screenshot” — aber er braucht ein Werkzeug, um das zu können. Diese Schnittstellen heißen in OpenCode MCPs (Model Context Protocol — “Model-Kontext-Protokoll”).

Für Nicht-Techies: Stell dir MCPs als Telefonleitungen vor. Zwischen OpenCode und Obsidian liegt eine Leitung (sagt: lies meine Notizen). Zwischen OpenCode und Playwright liegt eine (sagt: mach einen Screenshot). Die Skills wählen, welche Leitung sie wann nutzen. Der Skill ist der Motor, der die Arbeit macht. Die MCPs sind die Zahnrädchen, die den Motor mit den Werkzeugen verbinden.

Drei MCPs unterstützen den Prozess:

1. Obsidian-MCP — Wissen lesen

Warum Obsidian? Projekt-Notizen liegen in Obsidian — einem lokalen Markdown-Editor, der ohne Cloud auskommt. Die Notizen sind jederzeit durchsuchbar und gehören keinem Drittanbieter. Der Obsidian-MCP erlaubt OpenCode, diese Notizen direkt zu lesen, ohne dass jemand Inhalte kopieren oder zusammenfassen muss.

{
  "mcp": {
    "obsidian-vault": {
      "type": "local",
      "command": ["mcpvault", "[DEIN-VAULT-PFAD]"]
    }
  }
}

Ohne diesen MCP müsste OpenCode jedes Mal neu erklärt werden, worum es geht. Mit ihm liest es die Notizen direkt. Der Befehl: “Lies die Projekt-Notiz von gestern” — OpenCode tut es.

2. Playwright-MCP — Visuelles Review

Warum Playwright? Playwright ist ein Werkzeug, das automatisch Screenshots von Webseiten erstellt — in verschiedenen Größen, als ob jemand das Fenster aufzieht und ein Foto macht. So sieht der Entwickler, was die KI gebaut hat, ohne selbst im Browser klicken zu müssen.

{
  "mcp": {
    "playwright": {
      "type": "local",
      "command": ["npx", "@playwright/mcp@latest", "--headless"]
    }
  }
}

Der Skill sagt: “Ich will diesen Screenshot prüfen” — Playwright macht ihn, der vision-reviewer bewertet ihn. Alles automatisch. Ohne Playwright-MCP müsste jede Design-Entscheidung manuell im Browser geprüft werden.

3. Exa-MCP — Web recherchieren

{
  "mcp": {
    "exa": {
      "type": "remote",
      "url": "https://mcp.exa.ai/mcp"
    }
  }
}

Wird eher selten gebraucht — aber wenn die Frage aufkommt “wie machen andere ihre Navigation”, sucht Exa automatisch nach Referenzen. Mehr zu MCPs in OpenCode: opencode.ai/docs/mcp

Was der Stack tatsächlich baut

Die Skills designen nicht nur das Logo. Sie setzen das gesamte Layout um: Header mit Milchglas-Effekt, Karten-Layout für die Blog-Posts, Farbschema, Schriftgrößen, Responsive-Bruchpunkte. Der Mensch sagt nur: “Zu viel Abstand”, “Die Farbe passt nicht”, “Mehr Serif”. Die Skills arbeiten, die Agents prüfen die Qualität.

Und das Beeindruckendste: Der gesamte Tech-Stack — Hugo, Tailwind, CSS — wird von OpenCode vorgeschlagen und gebaut. Der Befehl ist nicht “nimm Hugo”. Sondern: “Eine Website, kein JavaScript-Framework, kein Cloud-Dienst”. OpenCode schlägt Hugo + Tailwind Standalone vor. Baut es. Deployed es.

Die Qualität kommt nicht durch langes Sitzen, sondern durch den Skill-Loop: Bauen, screenshotten, bewerten, verbessern. 19 Logo-Iterationen. Null Handarbeit.

So baust du das selbst — Schritt für Schritt

1. OpenCode installieren

OpenCode läuft auf Linux, macOS und Windows. Die Installation ist eine Zeile:

curl -fsSL https://opencode.ai/install.sh | bash

Kein Account, keine Konfiguration.

2. Hugo-Projekt anlegen

Entweder neu:

hugo new site blog --format yaml

Oder als Vorlage von GitHub klonen — dann sind die Skills bereits enthalten:

git clone https://github.com/steff-sson/blog.weitzelnet.com.git blog
cd blog
opencode

Die Skills unter .opencode/skills/ werden automatisch erkannt.

3. Website bauen mit website-builder

Sage OpenCode:

“Starte website-builder — ich will eine persönliche Seite.”

Der Skill durchläuft: Hugo-Struktur anlegen → Tailwind konfigurieren → Layout vorschlagen → Screenshots erstellen → Review durchführen → verbessern. Solange, bis es passt. Du entscheidest, der Skill arbeitet.

4. Logo erstellen mit logo (optional)

Kein Logo nötig, aber gewünscht? Einfach:

“Starte logo — ich brauche ein Icon für mein Projekt.”

Der Skill generiert Varianten, prüft sie per Screenshot und iteriert. 19 Runden sind normal.

5. Veröffentlichen

Hugo baut aus allen Dateien einen statischen HTML-Ordner:

blog/public/

Dieser Ordner enthält die komplette Website — keine Datenbank, kein PHP, kein JavaScript-Framework. Einfach HTML, CSS und Bilder.

Den Ordner public/ kann man auf jeden beliebigen Webserver hochladen. Welche Anforderungen muss ein Hoster erfüllen?

Statische HTML-Dateien ausliefern können (jeder Hoster kann das)
Keine Datenbank, kein PHP, kein Node.js
Ein FTP-Zugang oder SCP reicht
Kosten: ab 0 € (GitHub Pages, Netlify) bis ~5 €/Monat (eigener VPS)

Der einfachste Weg:

rsync -avz public/ benutzer@server:/verzeichnis/zum/ziel

Fertig. Die Seite ist live.

Alle Skills sind MIT-lizenziert. Du darfst sie kopieren, anpassen und für eigene Projekte nutzen.

Skill	Zweck	Fundort
`website-builder`	Hugo-Seite bauen + Review-Loop	`.opencode/skills/` im Blog-Repo
`logo`	Logo generieren + iterieren	`.opencode/skills/` im Blog-Repo
`blog-builder`	Blog-Posts schreiben (separat)	github.com/steff-sson/blog-builder

Was in Zukunft passieren könnte

Die Skills arbeiten heute schon selbstständig. Was noch fehlt, sind zwei Dinge:

Versionierte Skill-Bibliothek. Aktuell liegen die Skills lokal und werden von Hand aktualisiert. Ein Skill, der sich selbst aus GitHub updated — oder ein Verzeichnis mit mehreren Versionen — wäre der nächste Schritt. So könnte man zwischen “Stabil” und “Experimentell” wählen.

Automatische Überschriften und Teaser. Der Logo-Skill kann heute schon 19 Varianten durchrechnen bis ein Design passt. Der nächste Skill könnte das Gleiche für Blog-Posts machen: Aus einem Rohtext drei Überschriften-Varianten generieren, zwei Teaser-Formate vorschlagen und die beste Kombination per Review-Loop ermitteln. Ein Skill fürs Schreiben also — nicht fürs Layout.

Automatisches Deployment. Der hier beschriebene Workflow funktioniert auf jedem Rechner. Wer es bequemer will: Das Ganze läuft auch automatisch über eine CI/CD-Pipeline. Push auf main, Server baut neu, Seite ist live. Kein manuelles Hochladen mehr. Dazu folgt später ein eigener Blog-Eintrag.