Schreibworkflow für den Blog

Der Blog läuft, Drafts lassen sich veröffentlichen, Cloudflare baut zuverlässig. Was fehlt, ist die Kerntätigkeit: das Schreiben.

Ich habe in den letzten Wochen verschiedene Wege ausprobiert, einen Post anzulegen, und gemerkt: Die Frage nach dem Wie lässt sich erst beantworten, wenn das Was klar ist. Sonst wechselt man alle zwei Wochen das Tooling und schreibt trotzdem keinen Post.

In diesem Post geht es um die Anforderungen an meinen Workflow, die Optionen, die ich evaluiert habe, und die Entscheidung, die am Ende dabei herauskam.

1) Anforderungen an meinen Workflow

Bevor ich Tools vergleiche, brauche ich eine Messlatte. Ein Workflow für diesen Blog soll:

• zweisprachig arbeiten, DE- und EN-Bundle in einem Schritt anlegen
• Reibung minimieren (ein Kommando, nicht fünf)
• lokal und in der Cloud identisch funktionieren
• mit Git und Versionskontrolle harmonieren
• Drafts klar von veröffentlichten Posts trennen
• sich aus jedem beliebigen Editor heraus nutzen lassen

Er soll nicht ein CMS sein, keine WYSIWYG-Oberfläche liefern und keine Abhängigkeit von einem externen Dienst aufbauen. Alles, was nicht in Git steht, existiert für mich nicht.

2) Option A — Direkt im Editor

Die simpelste Variante: Im Editor zwei Dateien anlegen, Front Matter aus einem bestehenden Post kopieren, lostippen.

Vorteile: keine Lernkurve, kein zusätzliches Tooling, volle Kontrolle über jede Zeile.

Nachteile: Jede Wiederholung ist eine mögliche Fehlerquelle. Man vergisst schnell ein Feld im Front Matter, benennt den Slug inkonsistent oder legt nur die deutsche Datei an und reicht die englische nie nach. Die bilinguale Paarbildung passiert im Kopf, nicht im Tool.

Für einen einmaligen Post tragbar. Für einen Blog, den ich langfristig pflegen will, zu fragil.

3) Option B — hugo new content

Hugo bringt ein eingebautes CLI mit, das aus einem Archetyp eine neue Content-Datei erzeugt.

hugo new content posts/mein-post/index.md

Der Archetyp unter archetypes/posts.md definiert, welches Front Matter vorgefüllt wird. Das Ergebnis ist eine Datei mit konsistentem Skelett, ohne dass ich Zeilen kopieren muss.

Vorteile: offiziell, gut dokumentiert, null Fremdabhängigkeiten.

Nachteile: Der Befehl legt nur eine Datei an. Für meine bilinguale Struktur müsste ich ihn doppelt ausführen und das englische Bundle manuell drumherum bauen. Der Publish-Schritt (draft auf false, Commit, Push) bleibt außen vor.

Als Baustein gut, als Workflow zu lückenhaft.

4) Option C — make draft

Die dritte Option ist ein Makefile-Target, das hinter den Kulissen ein Shell-Skript aufruft:

make draft SLUG=mein-post

Das Skript legt das Bundle an: content/posts/mein-post/index.md und content/posts/mein-post/index.en.md, beide mit korrekt vorbelegtem Front Matter und draft: true.

Zusätzlich gibt es make publish (setzt draft: false) und make push (commit und push). Die drei Targets zusammen decken den Lebenszyklus ab.

Der entscheidende Punkt: Dieselben Skripte laufen auch in GitHub Actions. Es gibt keine zwei Wahrheiten — die Logik liegt an einer Stelle und wird sowohl vom Makefile als auch vom Workflow aufgerufen.

Vorteile: ein Kommando für Setup, ein Kommando für Publish, zwangsläufig konsistente Bundles, keine Logik-Duplikation zwischen lokal und online.

Nachteile: Die Skripte muss man bauen und pflegen. Für einen generischen Hugo-Blog wäre das Overkill, für meinen spezifischen bilingualen Fall passt es.

5) Option D — GitHub Actions Web-UI

Option C hat einen Zwilling im Browser. Unter Actions → Create Draft Post / Publish Draft Post lassen sich dieselben Skripte direkt im GitHub-Web ausführen. Slug eintragen, auf Run workflow klicken, fertig — das Bundle entsteht, wird committet, Cloudflare baut.

Praktisch ist, dass die Aktionen denselben Code ausführen wie die lokalen Make-Targets. Ich muss mich nicht fragen, ob ein online erstellter Draft anders aussieht als ein lokaler. Tut er nicht.

Wofür ich das nutze: wenn ich an einem fremden Rechner sitze, kein Repo geklont habe oder schlicht faul bin. Für die eigentliche Schreibarbeit ist das Web-UI ungeeignet, aber zum Anlegen eines Platzhalter-Posts, während mir auf dem Spaziergang eine Idee kommt, reicht es.

6) Entscheidung

make draft ist der Hauptweg.

Drei Gründe: Erstens passt er exakt zu meiner bilingualen Struktur, ohne dass ich im Kopf nachrechnen muss. Zweitens vermeidet er Logik-Duplikation — das Shell-Skript ist die einzige Wahrheit, egal ob lokal oder in der Cloud. Drittens ist er einfach genug, um ihn bei Bedarf in zehn Minuten zu lesen und zu erweitern, und komplex genug, dass er mir Arbeit abnimmt.

hugo new content bleibt als Backup, falls ich jemals einen einzelnen Post außerhalb der Bundle-Struktur brauche. Option D springt ein, wenn ich das Terminal nicht erreiche.

7) Mein Workflow in der Praxis

So sieht ein typischer Post-Zyklus bei mir aus:

1. Idee notieren (Obsidian, Notizblock, egal wo)
2. Am Schreibtisch: make draft SLUG=neuer-post
3. Editor öffnet das DE-Bundle, ich schreibe los
4. Parallel hugo server -D laufen lassen, um Drafts live zu sehen
5. Englische Version im selben Bundle nachziehen
6. make publish SLUG=neuer-post setzt draft: false
7. make push MESSAGE="Post über X" committet und deployt

Unterwegs läuft dasselbe über Working Copy plus GitHub Actions Web-UI. Der Workflow ist robust genug, um auf beiden Wegen zu funktionieren, und einfach genug, dass ich ihn nach zwei Wochen Pause nicht neu lernen muss.

Fazit

Der Workflow ist Werkzeug, kein Selbstzweck. Jede Minute, die ich mit Tool-Tuning verbringe, ist eine Minute weniger beim Schreiben.

make draft hat bei mir gewonnen, weil es die Anforderungen am präzisesten abdeckt — nicht weil Makefiles per se überlegen wären. Für einen anderen Blog mit anderer Struktur wäre die richtige Antwort vielleicht hugo new content oder ein CMS.

Wichtig ist nur, dass die Reibung beim Anlegen eines Posts irgendwann gegen Null geht. Dann entsteht aus der Frage „Wie fange ich an?" keine Ausrede mehr.