Ich baue immer wieder Webseiten. Der Hinweis auf die drei Design-Skills, um die es hier geht, kam allerdings nicht aus einer Dokumentation, sondern aus einem TikTok-Video. Dort wurden sie im Zusammenhang mit Claude Code vorgestellt. Ich wollte sie mit Codex ausprobieren und ließ Codex deshalb nach den vorgestellten Skills suchen.
Codex wurde fündig. Ich habe die drei Skills anschließend bei einer Website eingesetzt. Wie ich dabei vorgegangen bin und was beim ersten Versuch herauskam, zeige ich im nächsten Abschnitt. Hier beginnt die Geschichte erst einmal mit diesem Weg: ein Hinweis aus einem Video, die Suche mit Codex und schließlich der Einsatz bei einer eigenen Website-Arbeit.
Diesen Versuch möchte ich mit euch teilen, weil ihr vielleicht ebenfalls Webseiten baut und etwas damit anfangen könnt. Dabei interessiert mich nicht nur meine eigene Erfahrung. Ich möchte auch wissen, ob euch die drei Skills bei euren Projekten helfen. Deshalb stelle ich sie einzeln vor und zeige anschließend einen möglichen Ablauf für eine WordPress-Oberfläche.
Ausprobiert habe ich die drei Skills bei der Arbeit an einer Website, die ich bereits kannte. Dafür habe ich Codex die Branche genannt und den Auftrag gegeben, sich die besten Seiten dieser Branche hier in der Gegend anzuschauen. Dieser Vergleich sollte als Orientierung dienen, auch für die Erstellung passender Texte. Gemeint ist dabei nicht, fremde Formulierungen zu übernehmen, sondern eigene Inhalte für die Website zu entwickeln.
Dazu kamen einige Designvorgaben von mir. Die steckten ebenfalls im ersten Prompt – und tatsächlich kam schon mit dieser einen Eingabe ein sehr vernünftiges Ergebnis heraus. Gerade beim Design hat das für mich auf Anhieb gut funktioniert. Mit diesem ersten Einsatz war ich wirklich sehr zufrieden.
Das heißt nicht, dass damit eine fertige, fehlerfreie Website vorlag. Aber ich hatte eine gute Ausgangsbasis für die weitere Arbeit. Wie viel davon auf welchen der drei Skills zurückging, lässt sich aus diesem einen Versuch nicht ableiten. Der erste Eindruck war jedenfalls sehr positiv.
Der Skill frontend-design von Anthropic setzt bei der gestalterischen Grundrichtung an. Welche Wirkung soll die Website haben? Wie passen Schrift, Farbpalette und Seitenaufbau dazu? Statt beliebige Standardoptik zu erzeugen, soll der Coding-Agent eine eigenständige, zusammenhängende Gestaltung entwickeln. Ein solcher Skill ist dabei kein WordPress-Plugin und kein Theme. Er enthält Arbeitsanweisungen für den Agenten, der die Oberfläche umsetzt. Er liefert also keine fertige Vorlage, die man in WordPress einfach einschaltet.
Für eine Unternehmenswebsite könnte ein beispielhafter Auftrag lauten: „Entwickle eine zur Branche passende visuelle Richtung. Begründe die Wahl von Typografie, Farben und Layout. Stelle die wichtigsten Leistungen klar heraus und vermeide austauschbare Gestaltung.“ Damit wird aus „Mach die Seite moderner“ eine konkretere Aufgabe. Bestehende Vorgaben wie Logo, Hausschrift oder Unternehmensfarben gehören ebenfalls in diesen Auftrag.
Das Ergebnis lässt sich anschließend an einfachen Fragen anschauen: Ist auf den ersten Blick klar, was wichtig ist? Sind die Texte gut lesbar? Wirken Überschriften, Abstände und Farben über die Seite hinweg einheitlich? Das sind keine Nachweise für den späteren Erfolg der Website. Sie helfen aber, den Entwurf nicht nur nach „gefällt mir“ zu beurteilen.
Wenn die gestalterische Richtung steht, rücken einzelne Bedienelemente und ihr Verhalten in den Mittelpunkt. emil-design-eng aus Emil Kowalskis Skill-Sammlung setzt bei dieser Detailarbeit an: bei der Ausarbeitung von Komponenten, dem Feinschliff der Oberfläche und Entscheidungen über Animationen. Damit ergänzt der Skill den visuellen Entwurf. Es geht nicht um eine neue Farbwelt, sondern darum, wie sich die vorhandene Gestaltung in konkreten Elementen fortsetzt und wie diese auf Eingaben reagieren.
Ein hypothetisches Beispiel wäre das Kontaktformular einer Website. Hier könnte ein Arbeitsauftrag lauten: „Arbeite die Zustände der Absenden-Schaltfläche und die Rückmeldungen des Formulars aus. Mache erkennbar, wann eine Eingabe fehlt, eine Anfrage verarbeitet wird oder der Versand abgeschlossen ist. Setze Bewegung nur ein, wenn sie eine Veränderung verständlicher macht.“ Das wäre ein Vorschlag für die Arbeit mit dem Skill, kein Bericht über einen durchgeführten Test.
Am Ergebnis ließe sich dann fragen: Passen die Zustände zusammen? Ist eine Rückmeldung eindeutig der jeweiligen Aktion zugeordnet? Erklärt eine Animation etwas, oder lenkt sie nur ab? Solche Fragen helfen bei der Detailarbeit, ersetzen aber keine Prüfung der tatsächlichen Bedienbarkeit und Barrierefreiheit.
Der Skill web-design-guidelines von Vercel Labs setzt beim vorhandenen UI-Code an. Er gibt einen Prüfablauf anhand der Web Interface Guidelines vor. Vor jedem Review sollen die aktuellen Regeln neu abgerufen werden. Dafür braucht Codex Zugriff auf den relevanten Quellcode und die Möglichkeit, die Regeln aus dem Web zu laden. Sind sie nicht erreichbar, muss diese Lücke im Ergebnis stehen; ein Review nach frisch abgerufenen Regeln lässt sich dann nicht behaupten.
Die Prüfpunkte sind konkret: Ein Button, der nur ein Symbol zeigt, braucht einen zugänglichen Namen, etwa über aria-label. Formularfelder benötigen eine zugängliche Beschriftung, möglichst durch ein zugeordnetes label. Aktionen gehören auf Buttons, Navigation auf Links. Bilder brauchen einen Alternativtext; bei rein dekorativen Bildern bleibt er leer. Befunde sollen mit Datei und Zeile ausgegeben werden. So lässt sich nachvollziehen, welche Stelle beanstandet wird, statt nur eine pauschale Bewertung der Oberfläche zu erhalten.
Das ist eine Prüfung, keine automatische Reparatur. Welche Änderungen sinnvoll sind, muss anschließend entschieden und überprüft werden. Auch ein Review ohne Befunde ist weder eine Zertifizierung noch eine Garantie für vollständige Barrierefreiheit oder Rechtssicherheit.
Für WordPress würde ich daraus folgenden Ablauf ableiten. Der konkrete nachfolgende Ablauf ist ein Beispielvorschlag: zuerst ein Backup anlegen und auf einer lokalen Kopie oder Staging-Version arbeiten. Für diesen codebasierten Beispielweg benötigt Codex Zugriff auf die relevanten Projektdateien. Änderungen über den WordPress-Admin oder einen Pagebuilder hängen von den verfügbaren Werkzeugen und Zugriffsrechten ab; die Skills allein schaffen diesen Zugriff nicht.
Vor dem Einsatz würde ich die Skills anhand ihrer vertrauenswürdigen Originalquellen prüfen und die benötigten Ressourcen und Werkzeugzugriffe klären. Die Codex-Dokumentation beschreibt, wie vorhandene Skills in CLI und IDE über /skills oder $ ausgewählt beziehungsweise erwähnt werden können. Im Auftrag würde ich trotzdem ausdrücklich festlegen, welche Skills Codex lesen und anwenden soll. Ein anpassbarer Beispielprompt könnte so aussehen:
Aufgabe: Entwickle einen Startseitenentwurf für eine WordPress-Website aus der Branche [Branche] in [Region]. Berücksichtige diese Designvorgaben: [Designvorgaben].
Arbeite ausschließlich in der bereitgestellten lokalen Kopie oder Staging-Umgebung. Prüfe zunächst die Projektstruktur und benenne die bearbeitbaren Dateien sowie technische Grenzen, etwa durch einen Pagebuilder. Erhalte bestehende Funktionen.
Lies und verwende die Skills frontend-design, emil-design-eng und web-design-guidelines. Melde vor der Umsetzung, wenn ein Skill, eine benötigte Ressource oder ein Werkzeugzugriff fehlt.
Recherchiere öffentlich zugängliche Branchenbeispiele zur Orientierung. Nenne die Quellen, aber kopiere weder deren Gestaltung noch Texte. Verwende für Unternehmensangaben nur vorhandene, belegte Informationen. Erfinde keine Leistungen, Referenzen oder Werbeaussagen; frage bei wichtigen Lücken nach.
Nutze frontend-design für die visuelle Richtung, Typografie und das Layout. Stelle den Entwurf zunächst zur Abstimmung vor. Verfeinere nach Freigabe mit emil-design-eng die Komponenten und Interaktionen; setze Animationen nur ein, wenn sie sinnvoll sind.
Prüfe den entstandenen UI-Code anschließend mit web-design-guidelines anhand der dafür frisch abgerufenen Richtlinien. Liste Befunde mit Datei und Zeile auf. Dokumentiere Änderungen und offene Punkte. Nimm aus dem Review keine ungefragten Reparaturen vor und veröffentliche nichts live.
Vor einer Übernahme würde ich den Entwurf auf Smartphone und Desktop ansehen sowie Navigation, Formulare und Tastaturbedienung selbst prüfen.
Ich bin mit dem Design des ersten Entwurfs sehr zufrieden. Das ist meine Erfahrung mit diesem einen Einsatz, kein Versprechen für jedes Projekt. Wenn ihr selbst Webseiten baut, probiert die Skills ruhig einmal mit euren eigenen Vorgaben aus. Dafür muss es nicht gleich die komplette neue Website sein: Auch ein Entwurf für eine einzelne Seite kann zeigen, ob euch die Gestaltung weiterhilft und was ihr noch ändern möchtet.
Inzwischen habe ich die Skills auch an vorhandenen WordPress-Blogs ausprobiert. Dabei ging es nicht um einen großen Umbau, sondern um Feinarbeit: Abstände anpassen und kleine Änderungen am Farbschema und an den Tabs vornehmen. Codex hat dabei auch die Überschriftengrößen von Seite zu Seite verglichen und sich Feinheiten angeschaut, die mir selbst manchmal gar nicht auffallen.
Ich habe Codex dabei so vorgehen lassen, dass ich zunächst sehen konnte, was geändert werden soll. Anschließend hat Codex nach meiner Freigabe gefragt und die Änderungen erst danach tatsächlich umgesetzt. Mit diesen kleinen Anpassungen an meinen bestehenden WordPress-Blogs bin ich sehr zufrieden.
Ein erster brauchbarer Entwurf ist aber noch keine fertige Seite. Gerade generierte Texte und Unternehmensangaben gehören vor einer Übernahme sorgfältig geprüft. Branchenbeispiele können bei der Orientierung helfen, sollten aber nicht als Vorlage zum Kopieren dienen. Am Ende muss die Seite zum jeweiligen Unternehmen passen – nicht nur auf den ersten Blick gut aussehen.
Ich teile diese Erfahrung, weil ich anderen Webseitenbauern damit helfen möchte. Hat euch das Ausprobieren weitergebracht? Schreibt gern in die Kommentare, was gut funktioniert hat, was nicht und wo noch Nacharbeit nötig war.
Die Skills enthalten Arbeitsanweisungen für den Coding-Agenten. Sie sind keine WordPress-Plugins oder Themes und liefern keine fertige Vorlage, die man in WordPress einfach einschaltet.
Ich habe die Skills für Feinarbeit ausprobiert: für Abstände sowie kleine Änderungen am Farbschema und an den Tabs. Codex hat auch die Überschriftengrößen verschiedener Seiten verglichen. Die Änderungen wurden erst nach meiner Freigabe umgesetzt. Mit diesen kleinen Anpassungen bin ich sehr zufrieden.
Der konkrete Ablauf mit lokaler Kopie oder Staging-Version und dem anpassbaren Beispielprompt ist ein Beispielvorschlag. Davon getrennt stehen meine beschriebenen Erfahrungen mit einer Website und der Feinarbeit an bestehenden WordPress-Blogs.
Nein. Der Skill gibt einen Prüfablauf vor. Welche Änderungen sinnvoll sind, muss anschließend entschieden und überprüft werden. Auch ein Review ohne Befunde garantiert weder vollständige Barrierefreiheit noch Rechtssicherheit.
]]>Manchmal ist ein bestehendes Git-Repository ein guter Ausgangspunkt, um einem Agenten zu zeigen, was man sich vorstellt. Genau dafür habe ich Gitingest bisher genutzt. Nicht als fertigen Bauplan, sondern als Bezugspunkt für die Frage: So etwas hätte ich gerne – was davon passt zu meiner Idee?
Gitingest bereitet die Struktur und Dateiinhalte eines Repositories als Text auf. Für meine Arbeit mit eigenen Agenten und OpenClaw finde ich daran vor allem interessant, den Aufbau eines Projekts als zusätzlichen Kontext nutzen zu können. Daraus könnten sich auch Ansatzpunkte ergeben, um ähnliche Funktionen bauen zu lassen. Wie hilfreich das tatsächlich ist, möchte ich noch herausfinden.
Ein Repository ist die Projektablage mit ihren Dateien und Ordnern. Gitingest erzeugt daraus einen sogenannten Digest: einen zusammenhängenden Textauszug mit Dateibaum, Dateiinhalten und Angaben zur Tokenzahl. Der Dateibaum zeigt, welche Ordner und Dateien vorhanden sind. Darunter folgen die ausgelesenen Inhalte. „Digest“ bedeutet hier also nicht, dass Gitingest den Code in eigenen Worten erklärt oder inhaltlich zusammenfasst. Die Tokenzahl hilft einzuschätzen, welchen Umfang der Text für ein Sprachmodell hat.
Für den Einstieg lässt sich eine Repository-URL auf der Website eingeben. Bei GitHub-Adressen gibt es außerdem einen kurzen Weg: Im Domainnamen wird „hub“ durch „ingest“ ersetzt. Für das Repository von Gitingest selbst sieht das so aus:
https://github.com/coderamp-labs/gitingest
https://gitingest.com/coderamp-labs/gitingest
Für die Arbeit mit einem Agenten könnte der Textauszug eine gemeinsame Gesprächsgrundlage schaffen: Welche Bausteine hat das Beispielprojekt, und welche davon passen zur eigenen Idee? Ein möglicher Ablauf wäre, einen relevanten Auszug bereitzustellen, die gewünschte Funktion konkret zu beschreiben und den Agenten zunächst mögliche Ansatzpunkte erläutern zu lassen.
Auch bei eigenen Vorhaben mit OpenClaw wäre Gitingest damit eine Kontextquelle, kein Entwicklungszugriff. Der bereitgestellte Text verschafft dem Agenten weder Zugriff auf die Projektdateien noch die Möglichkeit, sie zu verändern. Eine native OpenClaw-Integration ist damit ebenfalls nicht gemeint. Ob daraus brauchbare Vorschläge entstehen, müsste sich beim Ausprobieren zeigen.
Nicht jedes Repository muss vollständig in den Kontext eines Agenten wandern. Sinnvoller ist, mit den Filtern die Dateien auszuwählen, die zur eigenen Frage passen. Die Tokenanzeige hilft, den Umfang einzuschätzen. Ob der Auszug hineinpasst, sollte man am Kontextfenster des verwendeten Modells prüfen.
Für den Einstieg bieten sich öffentliche Repositories an. Öffentlich bedeutet allerdings nicht automatisch frei von sensiblen Inhalten. Deshalb den erzeugten Text vor der Weitergabe kurz prüfen: Zugangsdaten, Schlüssel und vertrauliche Inhalte gehören weder in dritte Dienste noch in die Eingabe eines LLMs.
Wer Gitingest ausprobieren möchte, kann auf gitingest.com mit einem kleinen öffentlichen Repository anfangen. Eine konkrete Frage dazu hilft beim Einstieg: Welche Informationen braucht der Agent dafür, und was lässt sich weglassen? So bleibt der Versuch überschaubar, ohne gleich einen ganzen Arbeitsablauf umzustellen.
Mich interessieren eure Erfahrungen: War der aufbereitete Text als Kontext hilfreich – und für welche Aufgabe habt ihr ihn verwendet? Wo fehlten Informationen oder lagen die Grenzen? Schreibt es gern in die Kommentare.
Er enthält Dateibaum, Dateiinhalte und Angaben zur Tokenzahl. Eine inhaltliche Zusammenfassung ist damit nicht gemeint.
Nein. Der Textauszug verschafft dem Agenten weder Zugriff auf die Projektdateien noch die Möglichkeit, sie zu verändern.
]]>Ich wollte meine Aktenordner loswerden und Platz schaffen. Papier sammelt sich leicht an. Irgendwann stehen mehrere Ordner im Regal, obwohl man viele Unterlagen nur selten braucht. Für mich war deshalb klar: Ein Teil der Dokumente sollte digital werden.
Der Weg dorthin besteht aus mehreren Schritten. Ich möchte ausmisten, wichtige Unterlagen digitalisieren und anschließend kontrollieren, ob alles richtig erfasst wurde. Wichtige Originale bleiben erhalten. Entbehrliches Papier kann danach in den Schredder. Eine pauschale Vernichtungsfreigabe ist das aber nicht. Bei manchen Unterlagen ist das Original weiterhin wichtig.
Paperless-ngx ist mein digitales Dokumentenarchiv. Es hilft mir, Unterlagen strukturiert abzulegen und später wiederzufinden. Hier beschreibe ich meinen Weg vom Ausmisten über das Digitalisieren und Kontrollieren bis zur Ablage der Originale, die bleiben. Wie Scanner, Posteingang, Dokumenttypen und Sicherung dabei zusammenspielen, zeigen die nächsten Abschnitte. Meine 19 bestehenden Artikel vertiefen die einzelnen Schritte.
Passend zum Einstieg: Von „Scannen auf die NAS“ zur strukturierten Dokumenten-Schatztruhe – Paperless-ngx (Teil 1)
Der bestehende Grundlagenartikel zeigt, wie aus einzelnen Scans eine geordnete Dokumentensammlung werden kann.
Für den Einstieg brauche ich einen Scanner für Papier und ein eingerichtetes Paperless-Archiv. Bei mir arbeitet ein weißer ScanSnap iX1600. Paperless läuft auf einer UGREEN-NAS, einem Netzwerkspeicher im Heimnetz, mit den von mir eingebauten Seagate-IronWolf-Festplatten. Eine UGREEN-NAS ist dafür nicht zwingend erforderlich. Beim Scanner ist nicht der Hersteller entscheidend, sondern dass er zuverlässig PDFs erzeugt und sie an Paperless übergeben kann. Paperless selbst sollte bereits laufen und sich im Browser öffnen lassen. Wer die Installation noch nicht erledigt hat, findet dazu weiter unten passende Detailartikel.
Der Scan landet bei mir als PDF im sogenannten Consume-Verzeichnis. Das ist ein Eingangsordner, den Paperless automatisch überwacht und anschließend importiert. Wie ein Dokument vom Scanner bis zum fertigen Eintrag gelangt, beschreibe ich im dritten Abschnitt. Zusätzlich wird mein Dokumentenarchiv nachts gesichert.
Bevor Papier vernichtet wird, sollte eine aktuelle Sicherung vorhanden sein und sichergestellt sein, dass das Dokument im Archiv wiedergefunden werden kann. Ein einzelner Archivordner allein ist dabei nicht automatisch eine vollständige Sicherung von Paperless.
Wer Paperless noch nicht eingerichtet hat, muss an dieser Stelle keine Installationsanleitung durcharbeiten. Die folgenden Artikel erklären die Einrichtung und die Compose-Variante separat. Einzelne Schritte können je nach Version oder Umgebung abweichen.
Wenn ich ein neues Dokument digitalisieren möchte, beginnt der Weg ganz unspektakulär mit dem Papier. Zum Beispiel eine Rechnung: Ich lege sie zum Scannen bereit, und der Scan landet als PDF automatisch über das Netzwerk im Consume-Verzeichnis, also im Eingangsordner von Paperless. Paperless holt die Datei dort ab und importiert sie. Ich muss sie nicht noch einmal von Hand in der Weboberfläche hochladen. So wird aus einem Blatt ein Dokument, das im System weiterverarbeitet werden kann.
Bei der Verarbeitung nutzt Paperless Texterkennung (OCR), um Text in gescannten Dokumenten durchsuchbar zu machen. Die Erkennung kann Fehler enthalten. Neue Dokumente bekommen bei mir den Tag „Posteingang“. Dafür gibt es eine gespeicherte Ansicht auf der Startseite. Dort prüfe ich später manuell den Korrespondenten, den Dokumenttyp, die Tags und die Lesbarkeit – nicht jede einzelne Seite sofort beim Scannen. Vor einer Vernichtung sollten alle Seiten auf Vollständigkeit und Lesbarkeit kontrolliert werden.
Nach dieser Sichtung kann ich ein Dokument über einen passenden Suchbegriff oder seine Zuordnung wiederfinden. Lesefehler oder eine unpassende Zuordnung können die Suche erschweren. Das Papier sammle ich zunächst zwischen; es wird nicht sofort geschreddert. Welche Originale ich behalte und wie ich sie ablege, beschreibe ich im späteren Abschnitt.
Papier-Workflow – Paperless-NGX Serie – Teil 5
Der Artikel beschreibt den anschließenden Umgang mit Eingang, Prüfung, Ablage und Originalen im Paperless-Workflow.
Praxisbeispiele – Paperless-NGX Serie – Teil 9
Der Artikel zeigt anhand mehrerer Dokumentarten, wie die spätere Suche und Nutzung des digitalen Archivs im Alltag aussehen kann.
In Paperless-ngx muss ich meine alten Papierordner nicht digital nachbauen. Die drei Begriffe helfen mir dabei: Ein Korrespondent beschreibt, von wem ein Dokument stammt oder mit wem ich korrespondiere. Das kann zum Beispiel ein Versorger, eine Bank, ein Arbeitgeber oder eine Versicherung sein. Ein Dokument vom Stromanbieter bekommt also den passenden Korrespondenten „Versorger XY“. Der Dokumenttyp beschreibt dagegen die Art des Dokuments: Rechnung, Vertrag oder Gehaltsabrechnung. Eine Rechnung des Versorgers ist damit einfach die Kombination aus Korrespondent „Versorger XY“ und Dokumenttyp „Rechnung“.
Tags sind zusätzliche, flexible Kennzeichnungen. Sie können ein Dokument etwa als „Beleg“ markieren oder – in meinem Fall – als „Posteingang“. Dieser Tag ist für mich eine Arbeitsliste und Kontrolle: Ich sehe, welche Dokumente noch geprüft und zugeordnet werden müssen. Andere Tags wie „Beleg“ sind hier nur Beispiele, keine feste Vorgabe. Die Zuordnung bleibt digital. Ich verschiebe keine Dateien zwischen nachgebauten Aktenordnern.
Paperless-ngx kann bei der Zuordnung Arbeit abnehmen. Die Ergebnisse kontrolliere ich trotzdem manuell. Bei meinen Gehaltsabrechnungen habe ich erlebt, dass das System nach ungefähr drei Zuordnungen den passenden Korrespondenten wiedererkannte. Das ist meine Einzelerfahrung, keine allgemeine Trainingsschwelle oder Erfolgsquote. Die Suche hilft später zusätzlich, wenn eine Zuordnung einmal nicht perfekt passt.
Kurz erklärt:
Wenn ein Dokument wirklich aufbewahrt werden muss, bekommt es bei mir einen ASN-Barcode-Aufkleber. ASN steht für Archiv-Seriennummer und verbindet das Papieroriginal mit dem digitalen Dokument in Paperless. Die Originale liegen in einem einzigen, numerisch geordneten Ordner – nicht nach Themen sortiert. Suche ich nach ASN 111, finde ich das digitale Dokument in Paperless und anschließend das Papieroriginal mit derselben Nummer im Ordner.
Papierlos bedeutet für mich trotzdem nicht, dass jedes Original weg darf. Gesetzliche Pflichten, empfohlene Nachweise und der mögliche Beweiswert eines Originals sind verschiedene Fragen. Das hängt vom Dokument und von der Situation ab. Eine pauschale Aussage, dass ein Scan immer denselben Wert wie das Original hat, wäre deshalb falsch. Wichtige Urkunden bleiben besser im Original. Papier, das später vernichtet werden soll, sammle ich zunächst ungeschreddert. Vor dem Schreddern arbeite ich den Posteingang durch und sehe die Lesbarkeit der digitalen Dokumente durch. Vor der Vernichtung sollten Vollständigkeit, Lesbarkeit, Sicherung und Aufbewahrungsbedarf geprüft sein. Zum Vernichten nutze ich einen Aktenvernichter. Mein Aktenvernichter (Werbe-/Affiliate-Link).
So muss ich keine zweite, komplizierte Papierorganisation pflegen: Ich suche digital und finde das Original über seine Nummer im Ordner. Die folgenden drei Artikel vertiefen die einzelnen Bausteine.
Kurzer Hinweis zur Stapeltrennung: Stapeltrennung teilt einen Sammelscan beim Import in einzelne digitale Dokumente. ASN kennzeichnet dagegen ein Papieroriginal für die spätere Wiederfindbarkeit. Beide Funktionen lösen unterschiedliche Aufgaben und sollten nicht miteinander verwechselt werden.
Nicht jede Rechnung kommt auf Papier. Bei mir markieren E-Mail-Filter Rechnungen und Nachrichten zu Onlinebestellungen, unter anderem von PayPal, mit „Beleg“. Der E-Mail-Import prüft alle vier Stunden, ob passende neue Mails vorliegen, und übernimmt den Rechnungstext oder die PDF ins Archiv. Auch diese Dokumente landen mit dem Tag „Posteingang“ in meiner Ansicht auf der Startseite. Lesbarkeit und Zuordnung prüfe ich anschließend wie bei den eingescannten Unterlagen.
Workflows sind regelbasierte Abläufe: Wenn festgelegte Bedingungen erfüllt sind, werden bestimmte Aktionen ausgeführt. Solche Regeln und der E-Mail-Import sind zusätzliche Möglichkeiten, keine Voraussetzung für den Einstieg. Der Grundablauf bleibt derselbe: Dokumente ins Archiv bringen, die Verarbeitung kontrollieren und sie später wiederfinden.
Auch KI-Erweiterungen wie Paperless GPT sind optional. Dabei lohnt sich die Unterscheidung: OCR erkennt den Text eines Scans, die Zuordnung ordnet ein Dokument etwa einem Korrespondenten oder Dokumenttyp zu. Ein zusätzliches Sprachmodell, oft als LLM bezeichnet, ist noch einmal ein eigener Baustein. Für den Einstieg muss daraus kein weiteres Projekt werden. Erst einmal reicht ein Archiv, dessen Dokumente lesbar, geprüft und auffindbar sind.
E-Mail-Import – Paperless-NGX Serie – Teil 6
Der eigene Artikel zum E-Mail-Import als zusätzlichem Weg ins Dokumentenarchiv.
Paperless GPT – Die perfekte Ergänzung zu Paperless-NGX
Der eigene Artikel zur optionalen Erweiterung Paperless GPT.
Ich prüfe den Posteingang und die Zuordnung weiterhin selbst. Mein Archivordner wird jede Nacht zusätzlich gesichert. Auch mit automatischem Import bleibt also etwas Handarbeit: Unklare Dokumente brauchen Aufmerksamkeit, und ein laufendes System braucht gelegentlich Wartung.
Für den Einstieg musst du nicht alle meine Paperless-Artikel hintereinander lesen. Die vier Lesepfade führen je nach Ausgangspunkt weiter. Die Setup-Beiträge beschreiben meine damalige Einrichtung; vor einer Neuinstallation solltest du die aktuellen Voraussetzungen prüfen. Die Update-Beiträge sind Erfahrungsberichte zu den jeweils genannten Versionen – keine aktuellen Installations- oder Updateanleitungen.
Das Update ist mir nicht bei einer geplanten Wartung aufgefallen, sondern mitten im normalen Arbeitsablauf. Ich wollte ein bereits abgelegtes Dokument wiederfinden und habe dabei erneut gemerkt, wie wichtig eine zuverlässige Suche in Paperless-ngx ist. Wenn sich Rechnungen, Verträge und technische Unterlagen über Jahre ansammeln, muss ein Dokument auf Anhieb auffindbar sein – gerade dann, wenn es schnell gehen soll.
Paperless-ngx läuft bei mir auf einem UGREEN NAS. Deshalb ist ein Update nicht nur ein Klick auf „Aktualisieren“. Container, Datenbank, Dokumente und die bestehende Konfiguration müssen weiterhin sauber zusammenspielen. Gleichzeitig möchte ich den laufenden Betrieb möglichst wenig beeinträchtigen. Der entscheidende Maßstab ist für mich daher nicht allein die neue Versionsnummer, sondern ob die Anwendung danach im Alltag zuverlässig weiterarbeitet.
Der Sprung von der 3.1.x-Reihe auf Version 3.2.1 ist in diesem Zusammenhang interessant, weil es sich nicht nur um eine kleine Korrektur handelt. Mit der neuen Version geht Paperless-ngx den eingeschlagenen Weg weiter: Die Anwendung wird bei Stabilität, Bedienung, Suche und dem allgemeinen Umgang mit Dokumenten kontinuierlich verbessert. Für Selfhoster bedeutet das vor allem, dass sich ein Blick auf die eigene Installation lohnt – insbesondere dann, wenn Paperless-ngx bereits länger unverändert auf dem NAS läuft.
In diesem Beitrag zeige ich, wie ich das Update von Paperless-ngx 3.1.x auf 3.2.1 auf dem UGREEN NAS durchgeführt und anschließend geprüft habe, ob Suche, Dokumentenverwaltung und der laufende Betrieb weiterhin zuverlässig funktionieren.
Der Wechsel von Paperless-ngx 3.1.x auf 3.2.1 ist mehr als ein reines Zwischenupdate. Die grundlegende Bedienung bleibt zwar vertraut, einige Verbesserungen wirken sich im täglichen Umgang mit dem Dokumentenbestand direkt aus. Besonders relevant sind die fehlertolerantere Suche und die Optimierungen bei der OCR-Verarbeitung. Gerade auf einem UGREEN NAS, auf dem Paperless-ngx viele Rechnungen, Verträge und gescannte Unterlagen automatisch verarbeitet, verbessern solche Details die Qualität der täglichen Arbeit.
Eine der praktischen Neuerungen ist die Fuzzy Search. Dabei sucht Paperless-ngx nicht mehr ausschließlich nach einer exakt passenden Zeichenfolge, sondern berücksichtigt auch ähnliche Schreibweisen. Das ist hilfreich, wenn sich beim Erfassen oder Suchen ein Tippfehler eingeschlichen hat.
Auch typische OCR-Fehler können dadurch besser abgefangen werden. Ein gescanntes Dokument kann beispielsweise ein kleines „l“ und eine Ziffer „1“ verwechseln oder einzelne Buchstaben falsch erkennen. Die fehlertolerante Suche erhöht in solchen Fällen die Wahrscheinlichkeit, das gewünschte Dokument trotzdem zu finden. Das gilt auch für Teilbegriffe, wenn man sich beispielsweise nur an einen Bestandteil eines Firmennamens oder einer Rechnungsnummer erinnert.
Wichtig ist die richtige Erwartung: Ob ein Treffer entsteht, hängt vom Suchindex und vom konkreten Fehlerbild ab. Fuzzy Search korrigiert keine OCR-Fehler und garantiert keine Treffer. Stark beschädigte Scans, stark abweichende Schreibweisen oder völlig falsch erkannte Wörter bleiben problematisch. In der Praxis reduziert die Funktion aber die Zahl der Fälle, in denen eine Suche wegen eines einzigen abweichenden Zeichens ohne Treffer bleibt.
Ebenfalls verbessert wurde die OCR-Verarbeitung durch die Aktualisierung auf OCRmyPDF 17.12. Dabei geht es unter anderem um sogenannte Ligaturen. Das sind verbundene Buchstaben, wie sie in vielen Schriftarten bei Kombinationen wie „fi“ oder „fl“ vorkommen.
Bei älteren OCR-Läufen konnten solche Buchstabenverbindungen teilweise fehlerhaft erkannt werden. Aus „Firma“ oder „flüssig“ konnten dadurch unvollständige oder falsch zusammengesetzte Textstellen entstehen. Die verbesserte Verarbeitung sorgt dafür, dass diese Kombinationen zuverlässiger in durchsuchbaren Text umgewandelt werden.
Die genannte Versionsangabe sollte vor der Veröffentlichung gegen die Release-Notes beziehungsweise das tatsächlich eingesetzte Image geprüft werden. Ebenso lässt sich der Effekt lokal nachvollziehen: Importiere ein neues Testdokument mit „fi“- und „fl“-Verbindungen und kontrolliere den extrahierten Text. Ein bereits vorhandenes Dokument dient dabei als unveränderter Vergleich.
Der Effekt betrifft vor allem neu verarbeitete Dokumente. Bereits importierte Dateien werden durch das Update nicht automatisch erneut per OCR verarbeitet. Wer von der Verbesserung für den vorhandenen Bestand profitieren möchte, muss die betreffenden Dokumente daher gezielt neu verarbeiten lassen und das Ergebnis anschließend separat prüfen. Für neu eingehende Scans greift die optimierte OCR-Verarbeitung dagegen direkt.
Bevor der erste Container neu erstellt wird, sollte der aktuelle Zustand des Paperless-ngx-Stacks dokumentiert werden. Dazu gehören mindestens die derzeit verwendete Paperless-Version, die Namen und Status aller Container, die gemounteten Verzeichnisse sowie die relevanten Einstellungen in der docker-compose.yml beziehungsweise der verwendeten YAML-Datei. Auch ein kurzer Funktionstest – etwa Anmeldung, Dokumentensuche und Upload – ist sinnvoll. So lässt sich nach dem Update eindeutig feststellen, ob die Anwendung wieder vollständig arbeitet.
Auf dem UGREEN NAS läuft die Datensicherung idealerweise automatisiert jede Nacht. Das ist eine wichtige Grundlage für Wartungsarbeiten, ersetzt aber nicht die Kontrolle vor einem Versionssprung. Entscheidend ist nicht, dass ein Backup-Auftrag existiert, sondern dass die letzte Sicherung tatsächlich erfolgreich abgeschlossen wurde.
Vor dem Update sollte daher geprüft werden:
In der Praxis heißt das, im Backup-Bereich des UGREEN NAS die Zeitstempel und den Status des letzten Laufs zu kontrollieren und die enthaltenen Daten nachzuvollziehen. Sinnvoll ist ein konsistenter Snapshot, der Datenbank und Dokumentenverzeichnisse zum gleichen Zeitpunkt abbildet. Ein Dump der Datenbank und ein davon zeitlich getrennter Kopiervorgang der Dokumente können im Fehlerfall zu einem inkonsistenten Stand führen.
Ein Update sollte erst begonnen werden, wenn eine aktuelle und nachvollziehbare Sicherung vorhanden ist. Besonders wichtig ist die Datenbank: Die Dokumente allein reichen nicht aus, da Zuordnungen, Tags, Korrespondenten und weitere Metadaten in der Datenbank gespeichert werden. Im Fehlerfall muss außerdem klar sein, wie sich der vorherige Stand wiederherstellen lässt.
Für den Versionswechsel wird nicht pauschal der Tag latest verwendet, sondern jede relevante Paperless-Komponente erhält einen festen Versionsstand, beispielsweise 3.2.1. Das macht den Stack reproduzierbar: Die gleiche YAML-Datei startet auch später genau die getestete Version und nicht automatisch einen möglicherweise inzwischen veröffentlichten Nachfolger.
Der Einsatz von latest birgt mehrere Risiken. Ein erneuter Image-Pull kann zu einem anderen Softwarestand führen, ohne dass die Konfiguration geändert wurde. Außerdem können einzelne Images zu unterschiedlichen Zeitpunkten aktualisiert werden. Dadurch entstehen schwer nachvollziehbare Inkonsistenzen zwischen Webserver, Hintergrundprozessen und anderen Bestandteilen des Stacks.
Ein fester Tag bietet dagegen:
Wichtig ist die Unterscheidung: Alle Paperless-Services – Webserver, Worker, Scheduler und die weiteren Paperless-Container – verwenden denselben festen Paperless-Tag, beispielsweise ghcr.io/paperless-ngx/paperless-ngx:3.2.1. Datenbank, Redis beziehungsweise Broker und weitere externe Komponenten tragen dagegen ihre eigenen Versionsschemata. Sie erhalten ebenfalls feste, aufeinander abgestimmte Tags – aber nicht denselben Paperless-Tag.
Die eigentliche Änderung erfolgt in der YAML-Datei des Paperless-Stacks. Dabei sollte nicht nur nach einer Zeile gesucht werden, die nach dem Webserver aussieht. Ein typischer Paperless-Stack besteht aus mehreren zusammengehörenden Komponenten: dem Webserver, Hintergrundprozessen für Aufgaben und Dokumentenverarbeitung, einem Scheduler oder ähnlichen Diensten sowie der Datenbank und Redis beziehungsweise dem verwendeten Broker.
Zunächst sollten alle Services und deren Image-Angaben vollständig geprüft werden. Wird nur der Webcontainer aktualisiert, können die übrigen Dienste weiterhin mit einem älteren Stand laufen. Das kann zu inkompatiblen Abhängigkeiten, fehlerhaften Hintergrundaufgaben oder einem uneinheitlichen Verhalten der Anwendung führen.
Vor dem Speichern empfiehlt sich eine kurze Bestandskontrolle:
Sobald die YAML-Konfiguration geprüft und ein Backup erfolgreich erstellt und geprüft wurde, folgt die technische Umsetzung. Auf dem UGREEN NAS erfolgt dies in einem strukturierten Ablauf.
Zunächst werden die neuen Container-Images geladen. Wichtig ist, den Pull-Vorgang vollständig abzuwarten und auf Fehlermeldungen zu achten. Ein erfolgreicher Download bedeutet, dass die Images lokal verfügbar sind. Prüfe, ob alle erwarteten Images mit dem vorgesehenen Versionsstand vorhanden sind.
Im nächsten Schritt werden die Container mit den neuen Images neu erstellt. Dabei kommt es zu einer kurzen Unterbrechung der Erreichbarkeit. Laufende Importe sollten vor dem Update abgeschlossen sein. Nach dem Deploy ist zu prüfen, ob alle Container den Status „running“ beziehungsweise „healthy“ melden.
Bevor die Weboberfläche getestet wird, lohnt sich ein Blick in die Logs. Besonders relevant sind erfolgreiche Datenbankmigrationen, der vollständige Start des Webservers sowie die Verbindung zu Datenbank und Redis.
Der finale Schritt ist die praktische Verifizierung:
Startet ein Container nicht oder ist Paperless-ngx nicht erreichbar, gilt: Keine hektischen Änderungen. Beginne mit den Container- und Anwendungslogs. Prüfe die Erreichbarkeit der Abhängigkeiten und die Schreibrechte auf dem UGREEN NAS.
Ein wichtiger technischer Hinweis: Ein Rollback des Container-Images stellt nicht automatisch den vorherigen Datenbankzustand wieder her. Wenn das Update das Datenbankschema verändert hat, ist eine ältere Anwendungsversion oft inkompatibel mit der neuen DB-Struktur.
Ein echtes Rollback erfolgt daher ausschließlich über ein geprüftes Backup:
Das Update von Paperless-ngx auf dem UGREEN NAS war technisch überschaubar. Entscheidend ist nicht, möglichst schnell auf Deploy zu klicken, sondern den Ablauf sauber vorzubereiten. Ein geprüftes Backup nimmt dem Update das Risiko, bei einem unerwarteten Fehler ohne Rückfallebene dazustehen.
Auch feste Tags in der YAML-Datei zahlen sich aus. Mit paperless-ngx:3.2.1 ist jederzeit nachvollziehbar, welche Version eingesetzt wird. Automatische Tags wie latest können dagegen unbeobachtet neue Änderungen einspielen. Die Kombination aus klarer Versionsangabe, geprüftem Backup und anschließender Funktionskontrolle macht den Betrieb planbarer.
Für UGREEN-NAS-Besitzer, die Paperless-ngx per Docker Compose betreiben, ist das Update von 3.1.x auf 3.2.1 eine sinnvolle Investition. Der Aufwand bleibt überschaubar, während die fehlertolerantere Suche und die OCR-Verarbeitung im Alltag konkrete Vorteile bringen.
Der bewährte Ablauf im Überblick:
Backup prüfen ? YAML-Tags festlegen ? Image pullen ? Stack deployen ? Logs prüfen ? Funktionstest.
Auf alleswasbewegt.de findest du außerdem weitere Beiträge zu Selfhosting, Docker, NAS-Systemen und dem zuverlässigen Betrieb eigener Dienste.
]]>Für mich gibt es dabei einen kleinen Kodex: Ich grüße jeden Menschen auf der Strecke. Spaziergänger, Passanten und natürlich auch die Menschen mit ihren Hunden bekommen ein kurzes „Hallo“ oder ein Nicken. Nicht, weil ich mir davon etwas verspreche. Es gehört für mich einfach dazu – und macht die Runde angenehmer.
Manche von ihnen kenne ich inzwischen gut, weil wir uns fast täglich begegnen. Auch die, die mir nie einen guten Tag zurücksagen, bekommen von mir trotzdem jeden Tag ein „Hallo“. Das ist für mich keine Frage der Erwartung, sondern der Haltung.
Auf dieser Strecke gibt es ein paar Engstellen, an denen man zwangsläufig aufeinandertrifft. Vor mir lief ein älterer Herr mit seinem sehr alten Hund. Der Hund war wackelig auf den Beinen, und jeder Schritt schien ihn Anstrengung zu kosten.
Ich wurde langsamer und wartete, bis der Weg wieder etwas breiter wurde. Dann beschleunigte ich ein wenig, um ihn nicht zu bedrängen, zog zügig vorbei und grüßte mit einem freundlichen „Hallo“.
Ich lief weiter, da hörte ich von hinten ein leises „Danke“. Irritiert drehte ich mich um. „Wofür bedankst du dich?“
Der Herr antwortete: „Dass du mich gegrüßt hast.“ Er streckte mir die Hand entgegen, wir schüttelten sie. Ich sagte: „Das ist für mich doch eine Selbstverständlichkeit.“ „Nein“, sagte er, „das ist nicht mehr selbstverständlich. Das ist eigentlich sehr selten geworden.“
Der Satz des Herrn blieb mir noch eine Weile im Kopf: „Das ist nicht mehr selbstverständlich.“ Für mich war es eine kleine Gewohnheit, kurz innezuhalten und freundlich zu sein. Für ihn aber war daraus ein besonderer Moment geworden.
Da habe ich gemerkt, dass eine kleine Geste manchmal viel weiter reicht, als man selbst denkt. Und die Freude, die ich ihm damit gemacht hatte, kam auch bei mir an. In diesem Moment spürte ich, dass mein eigener Kodex nicht nur anderen etwas gibt – sondern mir selbst auch.
Freundlichkeit muss dabei gar nichts Großes sein. Manchmal reicht ein Gruß, ein kurzer Blick, ein kleines Zeichen: Ich sehe dich. Solche Gesten kosten kaum etwas und können doch den Tag eines anderen heller machen – und den eigenen gleich mit.
Vielleicht probierst du es heute aus: Grüß bewusst eine Person, die du sonst vielleicht übersiehst.
]]>