Claude Code: Mit Belegen beweisen, dass die Arbeit wirklich fertig ist

Freitagabend bat ich Claude Code: “Schreib einen Artikel und veröffentliche ihn gleich mit.” Dann ging ich schlafen. Am nächsten Morgen schaute ich ins Log, und da stand selbstbewusst: “Fertig. Artikel veröffentlicht.” Beruhigt öffnete ich die Live-URL, und angezeigt wurde der Titel des vorherigen Artikels.

Der Build war durchgelaufen. Die URL gab brav einen 200er zurück. Aber das h1-Tag gehörte noch zu einer anderen Seite. Ich hatte den Abgleich der Änderungen komplett der KI überlassen und mich allein auf das Wort “hat funktioniert” verlassen.

In dem Moment wurde mir klar: Mein Problem war nicht die Cleverness von Claude Code, sondern die Art, wie ich meine Arbeit abschließe. Je mehr ich der KI überlasse, desto wichtiger wird es, am Ende einen handfesten Beleg zu behalten, was tatsächlich geprüft wurde. Sonst fällt man jedes Mal auf die falsche Fertigmeldung herein.

In diesem Artikel zeige ich dir genau dieses “Muster, das Belege hinterlässt” - inklusive Code zum Kopieren.

Das Wichtigste in Kürze

• Glaube dem “Fertig” der KI nicht. Nur maschinell geprüfte Belege - Build, Live-URL, h1, CTA-Pfad - zählen als Grundlage für “erledigt”.
• Lege vor dem ersten Edit in einem Satz fest, was du in diesem Lauf belegen willst, und bestimme den Prüfbefehl schon vorab.
• Sieh nach der Veröffentlichung jedes Mal in derselben Reihenfolge nach (h1 -> Canonical -> Textanfang -> CTA). Eine feste Reihenfolge reduziert Übersehenes.
• Halte den Beleg (Screenshot, URL, nächste Kennzahl) in einer einzeiligen Notiz fest, damit du am nächsten Tag dieselbe Entscheidung nicht noch einmal treffen musst.
• Einen Artikel zu liefern, der am nächsten Tag prüfbar ist, ist im Betrieb stärker, als auf Anhieb den perfekten Artikel rauszuhauen.

Warum allein “Fertig” zum Unfall führt

Claude Code fasst seine Zwischenschritte in Worte. Genau das ist tückisch: Die Zusammenfassung kommt mit derselben Miene zurück - egal, ob es wirklich geklappt hat oder eben nicht.

Dass der Build durchläuft, belegt nur, dass die Syntax nicht kaputt ist. Dass die Live-URL einen 200er zurückgibt, belegt nur, dass der Server irgendetwas zurückgegeben hat. Ob dieses Irgendetwas der Artikel ist, den du gerade erstellen wolltest, steht auf einem ganz anderen Blatt.

Auch mein Freitagsunfall hatte Build und 200er beide bestanden. Kaputt war nur ein einziger Punkt: ob URL und Seiteninhalt zusammenpassen. Genau da hat niemand hingeschaut.

Deshalb stütze ich die Entscheidung “fertig” nicht auf die Worte der KI, sondern auf das Ergebnis, jeden selbst gesetzten Prüfpunkt abgehakt zu haben. Wenn dir die Grundlage für das Vorgehen noch wackelig ist, sorge zuerst mit dem Einstieg in Claude Code für einen sauberen Grundablauf - dann fallen dir die Schritte hier leichter.

Die 15-Minuten-Prüfschleife

Wer jedes Mal mit unterschiedlichen Schritten prüft, überspringt an einem hektischen Tag garantiert irgendwo etwas. Fixiere die Reihenfolge, damit du die Schleife ohne Nachdenken durchziehen kannst.

1. Schreibe in einem Satz, was geprüft sein muss, damit der Lauf “fertig” ist. Beispiel: “Der Artikel mit diesem Slug erscheint mit korrektem h1 unter der Live-URL.”
2. Lege vor dem ersten Edit fest, welchen Befehl (Build, Diff-Anzeige) du zur Prüfung nutzt. Such ihn nicht erst hinterher.
3. Nach jeder Änderung schaust du in der Reihenfolge Diff -> Build -> Live-URL. Auch wenn du es dir zwischendurch anders überlegst: Diese Reihenfolge bleibt.
4. Prüfe auf der Live-URL mit den Augen, ob h1, Canonical, Textanfang und CTA wie erwartet stehen.
5. Halte das verbleibende Risiko und “den kleinsten nächsten Schritt” in genau einer Zeile fest.

Entscheidend ist hier, von Anfang an zu trennen, was du der KI überlässt und was der Mensch entscheidet.

Schritt	Darf die KI übernehmen	Entscheidet der Mensch
Themenwahl	Bestehende Titel lesen, Vorschläge liefern	Welches Thema am Ende geschrieben wird
Schreiben	Entwurf von Text, Code, Überschriften	Ob sich Falsches oder Veraltetes eingeschlichen hat
Prüfen	Build ausführen, Diff zusammenfassen	Letzte Kontrolle, ob der Inhalt der Live-URL stimmt
Veröffentlichen	Veröffentlichungsbefehl ausführen	Freigabe nicht umkehrbarer Aktionen (Löschen, Prod-Deploy)

Nur die nicht umkehrbaren Aktionen stellst du anfangs alle auf “erst beim Menschen nachfragen”. Aktionen, die sich als sicher erwiesen haben, stufst du später auf automatisch hoch. Diese Grenzziehung habe ich im Leitfaden zur Rechteverwaltung im Detail aufgedröselt.

Vorlage für den Auftragstext zum Kopieren

Wer die Prüfung jedes Mal frei formuliert, lässt je nach Tagesform etwas weg. Wenn du den Auftragstext an Claude Code in eine feste Form gießt, bleiben die Prüfpunkte stabil.

Ich habe diesen Artikel veröffentlicht. Bevor du "fertig" meldest, prüfe das Folgende und gib das Ergebnis als Tabelle zurück.
- War der Build erfolgreich (mit Befehl und Exit-Code)?
- Stimmt das h1 der Live-URL mit dem Artikeltitel dieses Slugs überein?
- Zeigt das Canonical auf denselben Slug?
- Ist der Textanfang keine Wiederverwendung des vorherigen Artikels oder der Startseite?
- Stehen die CTAs (Gratis-PDF, Kurs, Beratung) in einer zur Lage des Lesers passenden Reihenfolge?
Punkte, die du nicht prüfen konntest, schreibe ehrlich als "ungeprüft". Schreibe nicht aus Vermutung "OK".

Der letzte Satz ist der entscheidende. Ohne das ausdrückliche “Schreibe nicht aus Vermutung OK” antwortet die KI auch zu ungeprüften Punkten mit freundlicher Miene “alles in Ordnung”. Wenn du den Aufbau deiner Auftragstexte grundsätzlich anheben willst, lies ergänzend fortgeschrittenes Prompt-Design.

Prüfskript zum Kopieren, das wirklich läuft

Das hier ist das Herzstück. Es ruft die Live-URL ab und prüft maschinell, ob das h1 dem erwarteten Titel entspricht. Es läuft mit reinem Node.js (ab Version 18). Nicht das “Fertig” der KI ist die Grundlage für den Abschluss, sondern das Urteil dieses Skripts.

// verify-publish.mjs
// Nutzung: node verify-publish.mjs <Live-URL> "<erwarteter h1-Titel>"
// Beispiel: node verify-publish.mjs https://claudecode-lab.com/de/blog/foo/ "Artikeltitel"

const [url, expectedH1] = process.argv.slice(2);

if (!url || !expectedH1) {
  console.error("Bitte URL und erwarteten h1-Titel als zwei Argumente uebergeben.");
  process.exit(2);
}

// Live-Seite abrufen
const res = await fetch(url, { redirect: "follow" });
const html = await res.text();

// h1 und Canonical grob extrahieren (kein strikter Parser noetig)
const h1 = (html.match(/<h1[^>]*>(.*?)<\/h1>/is)?.[1] ?? "")
  .replace(/<[^>]+>/g, "")
  .trim();
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]+href=["']([^"']+)["']/i)?.[1] ?? "";

// Prüfpunkte einzeln abhaken
const checks = {
  http200: res.status === 200,
  h1Treffer: h1 === expectedH1,
  canonicalTreffer: canonical.includes(new URL(url).pathname),
};

console.table(checks);

const allOk = Object.values(checks).every(Boolean);
if (!allOk) {
  console.error("Es gibt ungeprüfte oder abweichende Punkte. Noch nicht als fertig werten.");
  console.error(`Ermitteltes h1: ${h1 || "(leer)"}`);
  process.exit(1);
}

console.log("Belege vollstaendig. Darf als fertig gewertet werden.");

Ausgeführt wird es einfach so:

node verify-publish.mjs https://claudecode-lab.com/de/blog/foo/ "Artikeltitel"

Steht bei h1Treffer ein false, ist das exakt mein Freitagsunfall: Die URL lebt, aber der Inhalt ist falsch. Solange der Exit-Code nicht 0 ist, nenne ich die Veröffentlichung nicht “fertig”. Allein diese eine Regel stoppt die falsche Fertigmeldung schon vorher.

In diesen Situationen zahlt es sich aus

1. Artikel veröffentlichen Hier verwechselt man leicht einen reinen HTTP-200er mit Erfolg. Prüfst du mit dem Skript oben, ob h1 und Canonical auf denselben Slug zeigen, fängst du eine Wiederverwendung des alten Artikels oder einen Fallback zur Startseite noch vor der Veröffentlichung ab.

2. CTA austauschen Hast du einen Button zum Gratis-PDF oder zum Kurs verschoben, halte Screenshot und “nächste Kennzahl” in derselben Notizzeile fest. Später kannst du “Hat diese Änderung mehr Anmeldungen gebracht?” über die Aufzeichnung statt über die Erinnerung nachverfolgen.

3. Einstellungen oder Rechte ändern Gerade wenn du CLAUDE.md oder Rechte änderst, lässt du vor und nach der Änderung denselben Prüfbefehl laufen. Wenn dir das Schreiben der Konfiguration noch Sorgen bereitet, bring zuerst die Best Practices für CLAUDE.md in Ordnung - dann steht die Grundlage für die Prüfung.

Fallstricke und wie du sie behebst

Ehrlich gesagt bin ich mehrfach in dieselbe Grube gefallen, bevor sich dieses Muster gesetzt hat.

Der erste Fehler: alles in einem Lauf reparieren zu wollen und dabei ein so großes Diff zu erzeugen, dass es nicht mehr prüfbar ist. Ein Diff über 40 Dateien lesen weder Mensch noch KI zu Ende. Die Behebung ist simpel: Beschränke das, was du in einem Lauf prüfst, auf einen Satz. Wird es zu groß zum Prüfen, teile die Arbeit auf.

Der zweite Fehler: bei durchgelaufenem lokalen Build schon “fertig” zu rufen. Lokal zu laufen und korrekt unter der Live-URL zu erscheinen sind zwei verschiedene Dinge. Die Behebung: Lass das Skript oben nach der Veröffentlichung immer genau einmal laufen. Bis ich das in meinen Ablauf eingebaut hatte, habe ich mehrfach den falschen Inhalt veröffentlicht.

Der dritte Fehler: nur CTAs hinzuzufügen, ohne zu erklären, wohin der Leser als Nächstes soll. Drei Buttons nebeneinander helfen nicht, wenn man nicht wählen kann. Die Behebung: Schreib je nach Lage des Lesers (noch unsicher bei der Bedienung / von Routinearbeit ermüdet / denkt über einen Team-Einsatz nach) im Fließtext einen kurzen Hinweis, welcher CTA passt.

Häufige Fragen

F. Wenn der Build durchläuft, reicht das doch als fertig, oder? Der Build belegt nur, dass die Syntax nicht kaputt ist. Ob der Inhalt der Live-URL dieser Artikel ist, ist eine andere Frage. Erst wenn du auch h1 und Canonical geprüft hast, ist es fertig.

F. Muss ich das Prüfskript jedes Mal von Hand starten? Am Anfang reicht von Hand. Sobald sich der Ablauf gefestigt hat, baust du es so aus, dass es direkt nach dem Veröffentlichungsbefehl automatisch läuft. Wenn du dann auf “Exit-Code nicht 0 stoppt die Veröffentlichung” umstellst, sinken die Unfälle.

F. Darf ich die Prüfung nicht komplett der KI überlassen? Lesen und Zusammenfassen darfst du überlassen. Aber die letzte Entscheidung “ist der Inhalt der Live-URL korrekt?” und die Freigabe nicht umkehrbarer Aktionen behält der Mensch. Gibst du das ab, gibt es niemanden mehr, der die falsche Fertigmeldung stoppt.

F. Kann auch ein Nicht-Entwickler diese Prüfung durchziehen? Ja. Das Skript läuft per Copy-and-paste, und beim Sichtcheck musst du dir nur die Reihenfolge merken. Wenn dir die Befehle selbst Sorgen bereiten, steigst du am besten über die Erklärung für Nicht-Entwickler ein.

F. Was muss in die Notiz, damit sie reicht? “Was geprüft wurde”, “verbleibendes Risiko” und “der kleinste nächste Schritt” - diese drei genügen. Ein langes Protokoll braucht es nicht. Ziel ist allein, dass du am nächsten Tag dieselbe Entscheidung nicht erneut treffen musst.

Was beim tatsächlichen Test herauskam

Nach der Veröffentlichung mit falschem Inhalt am Freitag habe ich meinen Maßstab für “fertig” umgestellt - von “was hat die KI gesagt?” auf “ist der Exit-Code des Skripts 0?”.

Als ich verify-publish.mjs durch rund zehn Veröffentlichungen laufen ließ, lieferte es bei zwei davon ein false bei h1Treffer. Beide gaben einen 200er zurück und sind auf den ersten Blick nicht zu erkennen. Ohne das Skript hätte ich wieder eine wiederverwendete Seite veröffentlicht.

Auch die feste Reihenfolge beim Sichtcheck hat geholfen. Seit ich immer in derselben Folge schaue - h1 -> Canonical -> Textanfang -> CTA -, ist das “Mist, hier habe ich letztes Mal auch was übersprungen” so gut wie verschwunden. So weit ich die Entscheidung aus dem Kopf in den Ablauf ausgelagert habe, ist die abendliche Kontrolle spürbar leichter geworden.

Statt nach der cleversten KI zu suchen, lege ich zuerst einen Mechanismus an, der merkt, wenn man hinfällt. Das wirkt wie ein Umweg, ist aber nach meinem heutigen Stand der schnellste Weg.

Wenn du dieses Prüfmuster zum Team-Standard machen oder in deinen eigenen Veröffentlichungsablauf einbauen willst, gestalten wir das in der Schulung und Beratung gemeinsam. Die offizielle Dokumentation zu Claude Code findest du in der Anthropic-Dokumentation.