Claude Code Harness Smoke Test: 15 Minuten Nachweis, bevor du einem Agenten vertraust

Die erste produktionsnahe Claude-Code-Aufgabe braucht keine riesige Automatisierung. Sie braucht einen kleinen Smoke Test. Lege fest, welche Dateien gelesen, welche bearbeitet und welche Bereiche nicht berührt werden dürfen.

Die Suchabsicht ist praktisch: Anfänger und Fortgeschrittene wollen wissen, wie viel sie einem Agenten geben können. Bei einer Umsatzseite zählen PDF, Gumroad und Beratung genauso wie ein lokaler Build.

Weiterlesen: Claude Code harness engineering, first repo audit checklist, permission safety ladder.

Warum dieses Muster funktioniert

Ein Harness Smoke Test beweist nicht, dass das Modell immer sicher ist. Er beweist, dass die Umgebung Grenzen hat. Ein kleiner Artikel kann Formular, Produktlink oder Beratungspfad beschädigen.

15 Minuten lassen sich täglich wiederholen. Erst Lesebereich, kleine Änderung, Build, öffentliche URL und Screenshot, dann mehr.

Praktischer Ablauf

Ziel in einem Satz schreiben und editierbare Dateien auf höchstens drei begrenzen
Secrets, Zahlung, Kundendaten und Deployment als Sperrbereiche notieren
Vor der Änderung Befehl, Diff, URL und Screenshot als Nachweis wählen
Bei Artikeln und Seiten PDF, Gumroad und Beratung als CTA-Prüfung aufnehmen
Run Card behalten, damit die nächste Arbeit mit Belegen startet

Situation	Sicherer Schritt	Nachweis
Neuer Artikel	Nur Text und Frontmatter erlauben; Layouts und APIs bleiben lesend	Build und öffentliche URL
Produktseite	Nur Text und Kartenreihenfolge ändern; Kauf-URLs abgleichen	Gumroad-Linkcheck
Team-Rollout	Lesend beginnen, dann eine risikoarme Änderung erlauben	Diff und Screenshot

Kopierbarer Prompt und Code

Führe einen 15-minütigen Harness Smoke Test für dieses Repository aus. Noch keine breite Änderung. Gib Ziel, editierbare Dateien, Sperrbereiche, Nachweisbefehle, öffentliche URL-Prüfungen und CTA-Prüfungen für PDF/Gumroad/Beratung zurück.

const runCard = {
  slug: "claude-code-harness-smoke-test-loop",
  goal: "publish one safe content change",
  allowedFiles: ["site/src/content/blog-en/example.mdx"],
  blockedAreas: [".env", "billing/", "cloudflare/"],
  proof: ["npm.cmd run build", "public URL screenshot"],
  ctas: ["free PDF", "Setup Guide", "consultation"]
};

function readyForAgent(card) {
  return card.allowedFiles.length > 0 &&
    card.blockedAreas.length > 0 &&
    card.proof.some((item) => item.includes("build")) &&
    card.ctas.length >= 3;
}

console.log(readyForAgent(runCard) ? "ready" : "tighten scope");

Der Code macht aus einer vagen Agentenaufgabe eine Run Card. Dieselbe Form passt für PR-Vorlagen, Veröffentlichungschecks und Beratungsnotizen.

Drei echte Beispiele

Astro-Artikel veröffentlichen

Die Änderung bleibt bei Text, heroImage und CTA. Ein grüner Build reicht nicht, wenn h1 oder CTA in Produktion zu einer anderen Seite gehören.

Kleine UI-Änderung

Auch bei Buttontext mobile Umbrüche und Touchfläche prüfen. Führt der Button zum Produkt, wird die URL geprüft.

Erster Teamtermin

Nicht mit Code beginnen. README, Berechtigungen, Tests und Sperrbereiche werden kartiert. Das wird zur Agenda.

Fehler, die du vermeiden solltest

Alles auf einmal verbessern zu lassen macht den Scope zu groß.
Nur lokaler Build übersieht Fallback-Seiten und alte CTAs.
Ohne Gumroad-Prüfung landet Anfänger-Traffic beim falschen Angebot.

Bei mehreren Sprachen kann der Slug stimmen, obwohl Text und CTA alt sind. Die öffentliche Seite zählt.

PDF, Gumroad und Beratung verbinden

Wer Befehle übt, startet mit dem kostenlosen Cheatsheet. Bei Permissions, CLAUDE.md, hooks, MCP oder CI passt die Setup Guide.

Für wiederholte Review- und Debug-Prompts nutze 50 Prompt Templates. Für Team-Rollout führt der Weg zur Beratung. Optionen stehen unter products.

Vor und nach dem Veröffentlichen prüfen

Vor Veröffentlichung frontmatter, heroImage, interne Links und Gumroad prüfen. Danach mobil h1, Textanfang und CTA ansehen. HTTP 200 reicht nicht, wenn es ein Fallback ist.

Nächste Kennzahlen

Suche, PDF-Starts, Gumroad-Klicks, Produktbesuche und Beratungsbesuche beobachten. Steigen PV ohne Produktklicks, passt die CTA-Stufe nicht.

30 Minuten Betriebsreview

Wenn der Harness Smoke Test in echte Arbeit geht, ist das Review am nächsten Tag am wertvollsten. Lies das Protokoll und notiere erlaubten Scope, geänderte Dateien, Prüfkommandos und geprüfte öffentliche Seiten. Nicht nur “geprüft” schreiben, sondern den Beleg: mobiles h1, Einstieg, CTA-Bereich, Gumroad-Link und Beratungspfad.

Trenne Sicherheit des Bearbeiters von Verhalten des Lesers. Bearbeiterseitig zählen Sperrbereiche, Build-Nachweis, gleicher öffentlicher Slug und keine englischen Alttexte in Übersetzungen. Leserseitig zählt der passende nächste Schritt: kostenloses PDF für Befehle, Gumroad bei wiederholbarem Engpass, Beratung bei Workflow-Design.

Mach aus dem Review eine künftige Regel. Nicht zehn Regeln nach jedem Problem hinzufügen. Eine Regel reicht: vor Layout-Änderungen fragen, jede Gumroad-URL in Produktion klicken oder den Texteinstieg je Sprache erfassen. Kleine tägliche Regeln sind stärker als lange Policies.