Blogpost-Pipeline
Diese Woche habe ich die Blogpost-Pipeline für mein Projektjournal gebaut. Statt Projektcode von Hand zusammenzustellen und den fertigen Text später in WordPress zu übertragen, führt mich jetzt eine Browseroberfläche vom Projektordner bis zur Vorschau und Übernahme in die neue Website. Die erste Version stand schnell, bei der Nutzung kamen aber viele Anpassungen hinzu. An Prompts, Sicherungen und Versionen möchte ich noch weiterarbeiten.
Ausgangslage
Vor Kurzem habe ich meine Website neu gebaut. Dabei wurde deutlich, dass nicht nur die Website selbst, sondern auch mein Weg zum nächsten Journalbeitrag eine neue Grundlage brauchte.
Eine frühere Beitrags-Pipeline gab es bereits. Sie lief in der Konsole und half mir mit Codex beim Formulieren. Vor jedem Lauf musste ich den Programmcode des Projekts selbst extrahieren und in einer einzelnen Datei bereitstellen. Das Ergebnis war eine Markdown-Datei. Anschließend legte ich den Beitrag trotzdem von Hand in WordPress und Elementor an und kopierte Text und Bilder an die richtigen Stellen. Dieser letzte Teil blieb aufwendig.
Mit der neuen Website sollte deshalb ein durchgängiger Ablauf entstehen. Die Pipeline sollte ein Projekt selbst untersuchen, meine Erzählung und Bilder aufnehmen, den Beitrag prüfen und direkt für die Website vorbereiten.
Planung und Vorgehen
Die Vorbereitung lief dieses Mal parallel zum Websitebau. Ich hatte die Blogpost-Pipeline bereits in einer HTML-Dokumentation geplant. Gleichzeitig berücksichtigte ich in der neuen Website, was die spätere Vorschau und Übergabe benötigen würden. Erst als die Website fertig war, gab ich Claude Code die vollständige Dokumentation und ließ die Anwendung umsetzen.
Anders als bei früheren Projekten begann die Arbeit damit nicht bei einer offenen Idee. Aufbau und Anforderungen waren schon weitgehend beschrieben. Neu war auch die Arbeitsteilung zwischen den LLM-Werkzeugen: Claude Code setzte die geplante Anwendung um. Codex untersucht später innerhalb der Pipeline das ausgewählte Softwareprojekt und formuliert auf Basis der bereitgestellten Quellen den Beitrag.
Eine zentrale Entscheidung betraf die Quelle für technische Informationen. Ich wollte keinen Programmcode mehr von Hand in eine Datei kopieren. Stattdessen gebe ich einen Projektordner an. Die Analyse läuft ausdrücklich nur lesend und fasst relevante Funktionen, Technik und Prüfungen zusammen.
Umsetzung
Die Anwendung führt im Browser durch sechs Schritte: Projekt, Erzählen, Bilder, Beitrag, Übernehmen und Teilen. Codex liest zunächst den Projektordner. Danach ergänze ich die Informationen, die nicht im Code stehen können, etwa Anlass, Entscheidungen und Zeitachse. Aus beiden Quellen entsteht der Entwurf. Eine Vorschau nutzt den Astro Entwicklungsserver des Websiteprojekts. Der fertige Beitrag kann anschließend in dieses separate Projekt übernommen werden.
Die erste Version stand relativ schnell. Viele Anforderungen wurden aber erst bei der Benutzung konkret. Ein Beispiel war die Reihenfolge der Bilder. Sie werden jetzt vor dem Schreiben des Beitrags ausgewählt. So liegen sie bereits vor, wenn Codex die Bildverweise und die verpflichtenden Alternativtexte erstellt. Auch Datum, Woche und der übliche Projektpfad werden passend vorgeschlagen, damit wiederkehrende Angaben nicht jedes Mal neu eingetragen werden müssen.
Ergebnis
Aus mehreren getrennten Handgriffen ist ein zusammenhängender Arbeitsablauf geworden. Die technische Bestandsaufnahme, meine eigene Erzählung und die Bilder bleiben als unterschiedliche Quellen erkennbar. Danach entstehen Entwurf, Stilprüfung und Vorschau innerhalb derselben Oberfläche. Für die Veröffentlichung muss ich den Beitrag nicht mehr aus einer Konsolenausgabe in Elementor nachbauen.
Praktisch spart das vor allem wiederkehrende Arbeit. Gleichzeitig kann ich den Inhalt vor der Übernahme bearbeiten und korrigieren. Der lokale Aufruf des Codex Kommandozeilenprogramms vermeidet dabei einen eigenen API-Zugang und die damit verbundenen API-Kosten.
Fertig ist die Pipeline noch nicht. Vor allem die Prompts und die Verwaltung verschiedener Sicherungen und Versionen möchte ich weiter verändern. Bereits wichtig ist mir, zu einer früheren Fassung zurückkehren zu können, wenn sie besser war.
Tech Stack
- Frontend HTML, CSS und JavaScript
- Backend Node.js mit ECMAScript Modulen und Node Standardbibliothek
- Website-Vorschau Astro Entwicklungsserver und Astro Bauprozess
- LLM-Einsatz Claude Code und Codex Kommandozeilenprogramm
- Werkzeuge PowerShell und Windows Stapeldatei
Fazit
Woche 37: ✅
Die Blogpost-Pipeline verbindet jetzt Projektanalyse, Erzählung, Bilder, Entwurf und Website-Vorschau in einer Oberfläche. Damit entfällt der bisherige Umweg über eine von Hand zusammengestellte Codedatei und Elementor. Die erste nutzbare Version steht, auch wenn Prompts, Sicherungen und Versionsverwaltung noch Arbeit brauchen. Ob ich daran direkt in der nächsten Woche weiterarbeite oder zunächst ein anderes Projekt beginne, ist noch offen.
P.S. Ja, dieser Beitrag wurde mithilfe der Pipeline verfasst. :)