Der erste Auftrag an Claude Code: so schreibst du den Brief

„Mach mal das README in diesem Repo schön.”

Dreißig Minuten nach der Installation war das mein allererster Auftrag an Claude Code. Zurück kam ein Diff, der eigentlich nur das README betreffen sollte, aber gleich die Skriptnamen in der package.json mit umgeschrieben hatte. Lief zwar, doch geändert waren drei Dateien an Stellen, die ich nie anfassen wollte. „Darf ich das so veröffentlichen?” Ich saß erstarrt vor dem Bildschirm.

Warum fasst das angeblich so schlaue Claude Code Stellen an, nach denen niemand gefragt hat? Es ist keine Frage der Fähigkeit. Ich hatte mit keinem Wort gesagt, wie weit es gehen darf. Das ist, als sagst du einer neuen Aushilfe „Mach den Laden mal schön” und gehst raus, und wenn du zurückkommst, ist das ganze Regal umsortiert.

In diesem Artikel geht es genau um dieses „wie weit”, festgehalten auf einem einzigen Blatt. Ich nenne das den Auftragsbrief für die erste Aufgabe.

Das Wichtigste in Kürze

• Der erste Auftrag entgleist, weil man „mach mal schön” sagt, ohne Ziel, erlaubten Bereich, Prüfung und Rückweg festzulegen.
• In den Brief gehören neun Punkte: Ziel, Leserlage, darf lesen, darf bearbeiten, darf ausführen, nicht anfassen, Prüfung, Rückweg und nächster Schritt.
• Claude Code übernimmt „lesen, ändern, Prüfbefehle ausführen”. Löschen, Produktivschaltung und kostenpflichtige Aktionen entscheidet der Mensch.
• Es gibt eine Copy-paste-Vorlage für den Brief plus ein lauffähiges JavaScript, das fehlende Punkte automatisch findet.
• Wähle als Erstes genau eine kleine Aufgabe, die du im Zweifel mit git zurücksetzen kannst, das ist das schnellste Erfolgserlebnis.

Warum gerade der erste Auftrag entgleist

Direkt nach der Installation machen die meisten dasselbe: einen weiten Auftrag. „Räum das Repo auf”, „Reparier das README”. Verständlich, man will ja sehen, was das Ding kann.

Doch bei einem weiten Auftrag verpuffen die ersten zehn Minuten im Erkunden. Claude Code liest kreuz und quer in den Dateien, repariert eigenmächtig alles, was verwandt aussieht, und schließt mit einem schwammigen „läuft vermutlich”. Du darfst danach den kompletten Diff noch einmal durchlesen und landest am Ende bei „hätte ich es selbst gemacht, wäre ich schneller gewesen”.

Die Ursache ist nicht die Intelligenz des Modells. Du hast ihm Ziel und Grenzen nicht mitgegeben. Selbst ein menschlicher Neuling, dem man am ersten Tag „mach einfach mal” sagt, erstarrt entweder oder läuft Amok. Schon das Festlegen der Grenzen vorab lässt diese Unfälle fast verschwinden.

Wenn dir die reine Bedienung noch Bauchschmerzen macht, lies vorher einmal Claude Code: der Einstieg und komm dann zurück, dann sitzt das mit dem Auftragsbrief sofort.

Die neun Punkte im Auftragsbrief

Was ich jedes Mal auf ein Blatt schreibe, sind diese neun Punkte. Keine Fachwörter nötig. Du füllst pro Zeile genau eine Antwort aus.

Punkt	Was reinkommt	Schlechtes Beispiel → gutes Beispiel
Ziel	Wann gilt es als gelungen	„README reparieren” → „README-Anleitung an package.json angleichen”
Leserlage	Für wen ist die Arbeit	(leer) → „Anfänger, will einmal sicher gelingen”
Darf lesen	Welche Dateien eingesehen werden dürfen	(alle) → „nur README.md und package.json”
Darf bearbeiten	Welche Dateien geändert werden dürfen	(alle) → „nur README.md”
Darf ausführen	Welche Befehle laufen dürfen	(alles) → „nur npm run build”
Nicht anfassen	Was auf keinen Fall geändert wird	(offen) → „package-lock, Deploy-Konfig, Preise”
Prüfung	Was als Beweis für Erfolg zählt	„läuft = ok” → „build geht durch / Diff nur README”
Rückweg	Wie man im Fehlerfall zurückkommt	(keiner) → „README per git zurücksetzen”
Nächster Schritt	Ein einziges Ziel für den Leser danach	(drei nennen) → „erst nur das kostenlose Einsteiger-Material”

Der Schlüssel sind „Nicht anfassen”, „Prüfung” und „Rückweg”. In dem Moment, in dem du die hinschreibst, wird aus einer „Bitte” eine „Arbeit, die man sicher delegieren kann”.

Die Copy-paste-Vorlage für den Brief

Hier die direkt verwendbare Vorlage. Sie steht in einem Codeblock, damit du sie Claude Code unverändert einfügen kannst. Tausch nur deinen Repo-Namen und die zu reparierende Stelle aus.

# Auftragsbrief für die erste Aufgabe

Ziel: Die Setup-Anleitung im README an den Inhalt der package.json angleichen.
Leserlage: Anfänger. Soll genau einmal sicher gelingen.
Darf lesen:
- README.md
- package.json
Darf bearbeiten:
- nur README.md
Darf ausführen:
- npm run build
Nicht anfassen:
- package-lock.json
- Deploy-Konfiguration (Umgebungsvariablen, Veröffentlichungseinstellungen)
- Preise oder Anmelde-Links
Prüfung:
- npm run build läuft durch
- git diff zeigt nur Änderungen an README.md
Rückweg:
- Bei fehlgeschlagener Prüfung README.md per git zurücksetzen
Nächster Schritt:
- Zunächst nur das kostenlose Einsteiger-Material empfehlen

Am konkreten Beispiel: Wenn nur die README-Anleitung an die package.json angeglichen werden soll, liest du README und package.json, bearbeitest nur das README, und der Beweis ist npm run build. Bei dieser Granularität setzt dich ein einziges git checkout -- README.md im Fehlerfall zurück. Der erste Durchlauf darf ruhig so eng sein. Je enger, desto besser kannst du selbst beurteilen, ob es geklappt hat.

Was Claude Code übernimmt und was der Mensch entscheidet

Beim Schreiben des Briefs ziehe ich im Kopf genau diese Linie. Ist die Grenze unscharf, überschreitet Claude Code sie „aus Hilfsbereitschaft”.

Darf Claude Code übernehmen	Entscheidet der Mensch (nicht automatisieren)
Angegebene Dateien lesen	Entscheidung, welche Dateien angefasst werden
Nur angegebene Dateien ändern	Dateien löschen
Prüfbefehle wie npm run build ausführen	Produktivschaltung, Deployment
Eine Zusammenfassung des Diffs liefern	Kostenpflichtige Aktionen
Die Fehlerursache melden	Unumkehrbares wie git push --force

Die linke Seite gibst du ab. Die rechte stellst du am Anfang komplett auf „vor Ausführung beim Menschen rückfragen”. Nur Aktionen, die sich als sicher erwiesen haben, schiebst du später Stück für Stück auf die automatische Seite. Allein diese Reihenfolge senkt drastisch, wie oft dir nachts der Schreck in die Glieder fährt.

Wenn du den Auftrag übergibst, hängst du diesen Satz dran.

Führe innerhalb dieses Auftragsbriefs nur eine einzige kleine Aufgabe aus.
Was du als außerhalb des Bereichs einschätzt, führe nicht aus, sondern schlage es nur vor.

Liefere zuerst diese fünf Punkte:
1. Welche Dateien du jetzt liest
2. Welche Dateien du jetzt bearbeitest
3. Welche Prüfbefehle du vorher und nachher ausführst
4. Eine Zusammenfassung der Änderungen im Diff
5. Den Rückweg für den Fehlerfall

Der Kniff ist: „Liefere vor der Umsetzung den Plan und die Prüfung.” Geht der zurückgemeldete Plan über den Auftragsbrief hinaus, kannst du ihn an Ort und Stelle stoppen. Stoppst du, bevor gearbeitet wird, fällt kein Aufräumen an.

Code, der Lücken im Auftragsbrief automatisch findet

Auch wenn man meint, den Brief vollständig geschrieben zu haben, fehlen oft Punkte. Ich prüfe das Vorhandensein der Punkte maschinell. Hier ein lauffähiges JavaScript. Du startest es mit Node.js etwa per node check-brief.mjs.

// Maschinell prüfen, ob im Auftragsbrief alle nötigen Punkte vorhanden sind
const requiredFields = [
  "Ziel",
  "Darf lesen",
  "Darf bearbeiten",
  "Darf ausführen",
  "Nicht anfassen",
  "Prüfung",
  "Rückweg",
  "Nächster Schritt",
];

export function validateFirstTaskBrief(markdown) {
  // Die nicht enthaltenen Punkte herausfiltern
  const missing = requiredFields.filter((field) => !markdown.includes(field));

  // Auch prüfen, ob der Prüfbefehl (hier npm run build) drinsteht
  const hasProofCommand = markdown.includes("npm run build");

  return {
    ok: missing.length === 0,
    missing,
    readyForClaudeCode: missing.length === 0 && hasProofCommand,
  };
}

// Beispiel zur Funktionsprüfung
const sample = `
Ziel: README an package.json angleichen
Darf lesen: README.md
Darf bearbeiten: README.md
Darf ausführen: npm run build
Nicht anfassen: package-lock.json
Prüfung: npm run build läuft durch
Rückweg: README.md per git zurücksetzen
Nächster Schritt: kostenloses Einsteiger-Material
`;

const result = validateFirstTaskBrief(sample);
console.log(result);
// → { ok: true, missing: [], readyForClaudeCode: true }

Wenn du den Brief erst durch diese Prüfung schickst, verschwindet das Vergessen von „Nicht anfassen” und „Rückweg”. Verlässt du dich nur auf das menschliche Auge, fehlt an einem hektischen Tag garantiert irgendwo etwas. Was die Maschine wissen kann, überlässt man bequem der Maschine.

In diesen Situationen zahlt es sich aus (drei Beispiele)

1. README oder Anleitungen korrigieren „Halte die Doku aktuell” hat keinen Rand. „Nur das Setup-Kapitel im README an die Skriptnamen der package.json angleichen” engt es ein, der Diff bleibt in einer Datei und lässt sich mit npm run build belegen. Am besten als allererste Aufgabe geeignet.

2. Erstes Review eines Pull Requests Nicht „Schau dir diesen PR an”, sondern „Lies von den geänderten Dateien nur die unter src/ und nenne Stellen, an denen Tests fallen könnten. Repariere den Code nicht, gib nur Hinweise.” Das Lesen gibst du ab, die Reparaturentscheidung bleibt beim Menschen. So verhinderst du den Unfall „repariert eigenmächtig und erzeugt einen neuen Bug”.

3. CTA austauschen (der Wegweiser zum nächsten Leserschritt) Selbst beim Austausch eines einzigen Buttons unter einem beliebten Artikel ist „Such die zugehörige Komponente und repariere sie” zu weit. Lege vorher im Brief fest: „erlaubte Datei”, „zu prüfende Live-URL”, „auszutauschender Link”. Aus „sieht irgendwie gut aus” wird „mit diesem Beweis kann ich es rausgeben”.

Drei Fehler, die ich selbst gebaut habe

Ich schreibe es ehrlich. Bevor ich den Auftragsbrief benutzte, wiederholte ich immer dieselben Fehler.

Erstens, „Nicht anfassen” nicht hingeschrieben. Ich wollte nur das README repariert haben, doch Claude Code hat aus Hilfsbereitschaft die package.json mitaufgeräumt, und der build ging nicht mehr durch. Drei Zeilen Nicht anfassen: package-lock.json, Deploy-Konfig ergänzt, und das passierte nie wieder.

Zweitens, die Prüfung mit „läuft = ok” abgehakt. Weil nicht festgelegt war, woran „läuft” sich bemisst, verfolgte ich jedes Mal den ganzen Diff mit den Augen. Mit dem konkreten Befehl Prüfung: npm run build läuft durch / Diff nur README war die Kontrolle in zehn Sekunden erledigt.

Drittens, drei nächste Schritte nebeneinandergestellt. Als ich am Artikelende Material, Kurs und Beratung alle gleichzeitig verlinkte, verschwamm die Reaktion der Leser. Beschränkst du es passend zur Leserlage auf eines, wird am Ende genau dieses eine auch zuverlässig geklickt. Was reingehört, hältst du als Projektregel in CLAUDE.md richtig schreiben fest, dann gerät es nicht jedes Mal ins Wanken.

Häufige Fragen

F. Ist es nicht lästig, jedes Mal alle neun Punkte zu schreiben? Nur die ersten paar Male. Leg dir eine Vorlage als first-task-brief.md ab, danach tauschst du nur drei bis vier Zeilen Inhalt aus. Die Zeit zum Schreiben ist weit kürzer als die Zeit, einen entglittenen Diff nochmals durchzulesen.

F. Braucht es auch bei einer einfachen Arbeit einen Brief? Auf dem Niveau „Tippfehler in einer Datei” reicht der mündliche Auftrag. Der Brief zahlt sich bei Arbeiten aus, die womöglich mehrere Dateien berühren, oder bei denen Produktiv, Kosten oder Löschen mit hineinspielen. Im Zweifel schreiben, das kostet dich nichts.

F. Sollte ich die Schlüsselnamen auf Englisch schreiben (Goal, May edit usw.)? Wenn du im Team Logs nebeneinanderlegst und vergleichst, sind einheitliche englische Schlüssel praktisch, doch allein für dich reicht Deutsch. Claude Code versteht beides. Wichtig ist nicht die Sprache, sondern dass kein Punkt fehlt.

F. Können das auch Leute nutzen, die nicht programmieren? Ja. Auch beim Schreiben von Artikeln oder Aufbereiten von Material ist die Denkweise „darf lesen, darf bearbeiten, nicht anfassen” dieselbe. Den Einstieg für Nicht-Entwickler habe ich in Claude Code für Nicht-Entwickler zusammengefasst.

F. Was, wenn Claude Code den Brief ignoriert und etwas außerhalb des Bereichs anfasst? Bitte zuerst „Liefere erst Plan und Prüfung” und stoppe, bevor gearbeitet wird, das ist die Grundregel. Überschreitet es trotzdem, ist dein „Nicht anfassen” wahrscheinlich nicht konkret genug. Bis hinunter zu Ordner- und Dateinamen anzugeben wirkt zuverlässig.

Was ich tatsächlich ausprobiert habe

Am anschaulichsten war es, diesen Brief an der kleinen Arbeit zu testen, das README an die package.json anzugleichen. Hatte ich vorher Darf bearbeiten: nur README.md notiert, wurde der Lauf, in dem Claude Code nach package-lock oder Konfigurationsdateien greifen wollte, schon im Plan vor der Ausführung gestoppt. Dass der Aufwand des erneuten Diff-Lesens damit komplett wegfiel, war groß.

Auch dass ich in die Prüfung die zwei Belege npm run build und git diff aufgenommen habe, wirkte. Aus dem Urteil nach der Arbeit wurde statt „sieht nach Gefühl gut aus” ein klares „build ist grün, Diff nur README, also kann ich es rausgeben”. Umgekehrt: in den Durchläufen, in denen ich den Nächsten Schritt leer ließ, war ich selbst unsicher, „was empfehle ich jetzt gleich noch?”, und der Wegweiser am Artikelende verschwamm.

Am Ende habe ich verstanden: Claude Code große Freiheit zu geben, ist nicht der Wert. Die erste Aufgabe klein schneiden, sodass Erfolg, Misserfolg und nächste Handlung für die eigenen Augen sichtbar werden. Das ist am schnellsten. Die Mühe, eine Grenze auf ein Blatt zu schreiben, ist gegen die Mühe, einen entglittenen Diff später nochmals durchzulesen, so gut wie nichts.

Wer die äußere Mechanik weiter ausreizen will, prüft im offiziellen Claude-Code-Dokument von Anthropic das Verhalten der Berechtigungseinstellungen, dann wird die Rollenteilung zwischen Brief und Konfiguration klar. Wer Claude Code im Unternehmen einführen und gleich die Betriebsregeln mitordnen will, kann in Schulung und Beratung gemeinsam mit mir bei der auf die echte Arbeit zugeschnittenen Brief-Vorlage anfangen.