Claude Code First-Task-Runbook: sichere Prompts, Diff-Prüfung und Review vor Commit

Die erste Aufgabe entscheidet, ob Claude Code sicher wirkt

Direkt nach der Installation von Claude Code ist es verlockend, eine ganze Funktion, ein großes Refactoring oder “repariere dieses Repo” zu verlangen. Genau dort scheitern viele erste Sitzungen. Meist liegt es nicht daran, dass Claude Code nicht helfen kann. Es fehlen noch abgestimmter Umfang, Prüfweg, Berechtigungen und Projektkontext.

Dieses Runbook ist für die erste praktische Aufgabe in einem echten Repository. Ein Runbook ist eine wiederholbare Arbeitscheckliste. Hier ist die erste Aufgabe nicht “baue das Feature”, sondern ein kleiner Ablauf: sauber anfragen, den Plan prüfen, eine begrenzte Änderung machen, den Diff lesen und eine Handoff-Notiz hinterlassen.

Wenn die Grundlagen noch neu sind, beginne mit dem Claude Code Einstiegsguide. Für Projektregeln kombiniere ihn mit den CLAUDE.md Vorlagen für Claude Code. Offizielle Referenzen sind Claude Code overview, memory und CLAUDE.md, permission modes, common workflows und die CLI reference.

flowchart LR
  A["Repository lesen"] --> B["3 sichere Optionen nennen"]
  B --> C["1 Aufgabe wählen"]
  C --> D["Plan zuerst prüfen"]
  D --> E["Kleinsten Diff erstellen"]
  E --> F["Tests und Diff prüfen"]
  F --> G["Handoff-Notiz schreiben"]

Was eine gute erste Aufgabe ausmacht

Die erste Aufgabe wird nicht vor allem an der Größe des Ergebnisses gemessen. Sie zeigt, ob der Ablauf vertrauenswürdig bleibt. Gute erste Aufgaben haben fünf Eigenschaften.

Eigenschaft	Einfache Bedeutung	Gutes Beispiel
Lokal	Keine Produktion, Kundendaten oder externen Nebenwirkungen	README-Kommandos prüfen oder eine Assertion ergänzen
Begrenzt	Dateien und Endpunkt sind sichtbar	Eine Komponente, ein Test, ein Dokument
Prüfbar	Kommando, Seite oder Diff belegt Erfolg	npm.cmd run test, git diff --check
Rückgängig machbar	Schlechtes Ergebnis lässt sich schnell verwerfen	Normale Quelldateien, keine generierten Exporte
Erklärbar	Ein Mensch versteht den Grund der Änderung	Grund, Risiko und offene Punkte sind notiert

Anfragen wie “mach Auth neu”, “modernisiere den ganzen Code” oder “repariere CI und deploye” sind schlechte erste Aufgaben. Sie vermischen fehlenden Kontext, Berechtigungsabfragen, schwache Tests und schwer prüfbare Diffs.

Menü sicherer Startaufgaben

Für Team-Onboarding wähle zuerst aus diesem Menü.

Aufgabe	Nutzen	Erfolgskriterium
Repo kartieren	Verständnis vor Änderungen prüfen	Entry Points, Kommandos und riskante Bereiche sind erkannt
Einen fehlschlagenden Test zusammenfassen	Debugging-Granularität sehen	Fehlerstelle, Hypothese und kleinster nächster Schritt sind klar
Ein veraltetes README-Kommando korrigieren	Echte risikoarme Änderung testen	Kommando läuft und Diff bleibt klein
Eine Assertion zu bestehendem Test hinzufügen	Absicht und Testurteil prüfen	Assertion schützt klares Verhalten
Einen UI-Text ändern	Suche und minimale Änderung prüfen	Nur die Zielkomponente ändert sich
Eine Lint-Warnung beheben	Lokale Änderungsdisziplin messen	Eine Warnung verschwindet ohne Verhaltensänderung
Minimales CLAUDE.md erstellen	Spätere Sitzungen verbessern	Kommandos, Grenzen und Review-Regeln sind kurz notiert

Wichtig ist “klein, aber echt”. Die Aufgabe sollte zu Onboarding, Bugdiagnose, Dokumentation, Tests oder Reviewqualität beitragen.

Kopierbare Prompt-Vorlagen

Bitte Claude Code zuerst um Lesen und Vorschläge, nicht um Bearbeitung.

Lies dieses Repository und editiere noch nicht.

Gib zurück:
1. wichtigste Entry Points
2. übliche build/test/lint-Kommandos
3. riskante Verzeichnisse oder generierte Dateien
4. 3 sichere Optionen für eine erste 30-Minuten-Aufgabe
5. wie jede Option geprüft und zurückgerollt wird

Nach den Optionen wählst du eine aus und verlangst einen Plan.

Fahre nur mit Option 2 fort. Noch nicht editieren.
Schreibe zuerst die Dateien, die du anfassen würdest, den Änderungsgrund,
den erwarteten Diff, das Prüfkommando und die Risiken.
Wenn der Umfang wächst, schlage eine kleinere Option vor.

Erst danach erlaubst du die Änderung.

Folge dem freigegebenen Plan und mache den kleinsten möglichen Diff.
Berühre keine Dateien außerhalb der Anfrage.
Fasse nach der Änderung ausgeführte Prüfkommandos, fehlgeschlagene oder ausgelassene Checks
und verbleibende Risiken zusammen.

Für den Review vor dem Commit nutzt du einen eigenen Prompt.

Führe einen Review vor dem Commit durch.

1. Lies git diff und suche Änderungen außerhalb der Anfrage
2. Finde fehlende Tests oder schwache Verifikation
3. Prüfe Sicherheits-, Datenverlust- und Konfigurationsrisiken
4. Finde Dateien, die nicht committet werden sollten
5. Benenne Entscheidungen, die noch ein Mensch treffen muss

Beende mit genau einem Urteil: "commit-bereit", "erst korrigieren" oder "stoppen".

Der 30-Minuten-Ablauf

Nutze die ersten fünf Minuten, um den aktuellen Zustand festzuhalten. Unter Windows PowerShell:

Get-Location
git status --short
git branch --show-current
rg --files | Select-Object -First 40

Unter macOS oder Linux:

pwd
git status --short
git branch --show-current
rg --files | head -n 40

Wenn der Worktree bereits Änderungen enthält, sage klar, welche Änderungen vom Menschen stammen und nicht angefasst werden dürfen. Sonst ist der finale Diff kaum zu beurteilen.

Nutze die nächsten zehn Minuten zur Auswahl einer Aufgabe. Gute erste Optionen sind ein veraltetes README-Kommando, eine Test-Assertion oder die Zusammenfassung eines fehlschlagenden Tests. Neue Features sind für die erste Sitzung zu früh.

Um Minute zwanzig zählt Nachweis mehr als zusätzliche Änderungen. Eine korrekte, erklärte Änderung ist wertvoller als drei ungeprüfte Änderungen.

git diff --stat
git diff --check
git diff
git status --short

Die letzten fünf Minuten gehören der Handoff-Notiz. Sie ist eine kurze Notiz für die nächste Person oder die nächste Claude-Code-Sitzung. Das ist wichtig, weil lange Gespräche Grenzen verlieren können und die nächste Sitzung einen sauberen Startpunkt braucht.

Vier konkrete Use Cases

Use Case 1: Onboarding neuer Entwickler

Gib am ersten Tag kein großes Issue. Bitte Claude Code um eine Repo-Karte, Schlüsselkommandos, gefährliche Verzeichnisse und die ersten Dateien zum Lesen.

Prompt: “Erstelle eine Onboarding-Notiz für einen neuen Entwickler. Trenne Fakten von Annahmen. Füge Kommandoausgaben hinzu, wenn möglich.” Erfolg bedeutet, dass die Notiz praktischen Kontext über das README hinaus liefert: generierte Dateien, lokale Einstellungen oder Unterschiede zwischen CI und lokal.

Use Case 2: Reproduktionsnotiz für sichtbaren Bug

Wenn der Bug “manchmal kaputt” ist, beginne nicht mit dem Fix. Frage nach Bedingungen, erwartetem Ergebnis, tatsächlichem Ergebnis, relevanten Dateien und fehlenden Logs. Das passt gut zur Claude Code Bug-Report-Vorlage.

Erfolg ist kein Patch. Erfolg ist eine Notiz, die ein Mensch prüfen kann. Wenn der Bug nicht reproduzierbar ist, soll die Ausgabe das sagen und die nächsten Logs oder Daten nennen.

Use Case 3: Dokumentation oder UI-Text

Marketingseiten, Admin-Tools und interne Dashboards eignen sich oft für die erste Sitzung, weil eine Textänderung sichtbar und reversibel ist. Halte sie eng: ein CTA, eine Einstellungsbeschreibung oder ein Absatz.

Erfolg heißt: Nur die Zieldateien änderten sich, die Bedeutung blieb erhalten, und das Ergebnis lässt sich lokal prüfen. Bei mehrsprachigen Sites prüfst du zusätzlich, dass nicht nur eine Sprache aktualisiert wurde.

Use Case 4: Kleine Testverbesserung

Wenn das Projekt Tests hat, ist eine Assertion sicherer als ein neues Feature. Ergänze einen Grenzfall, eine Erwartung für Fehlermeldungen oder einen leeren Listenfall.

Grüne Tests reichen nicht. Claude Code sollte erklären, welches Verhalten die Assertion schützt. Eine nicht erklärbare Assertion wird später Wartungsrauschen.

Diff-Review vor dem Commit

Nach den Änderungen kehrst du zum menschlichen Review zurück. Bei der ersten Aufgabe vermeidest du automatische Commits und Pushes. Permission modes tauschen Komfort gegen Aufsicht, also starte mit normalem Review oder plan mode. Starke Modi wie bypass permissions gehören nur in isolierte Umgebungen.

Checkliste vor dem Commit

[ ] Nur angefragte Dateien wurden geändert
[ ] Keine generierten Dateien, Secrets oder lokalen Settings sind enthalten
[ ] Test oder Ersatzprüfung ist dokumentiert
[ ] Fehlgeschlagene oder ausgelassene Checks sind genannt
[ ] Kein unerklärter Diff bleibt übrig
[ ] Die Handoff-Notiz enthält das nächste TODO

Beginne mit git diff --stat, um die Ausbreitung zu sehen. Führe git diff --check für Whitespace und Patch-Hygiene aus. Lies danach den Diff selbst und suche Überraschungs-Refactorings, Namensänderungen oder Verhaltensänderungen ohne Tests.

Häufige Fehler

Der erste Fehler ist zu großer Umfang. Sage “prüfe die Login-Fehlermeldung mit einem Test”, nicht “repariere Login”. Mehr Autonomie gibst du nach erfolgreichen kleinen Aufgaben.

Der zweite Fehler ist “fertig” ohne Nachweis. Wenn es keine Tests gibt, definiere Ersatznachweise: gerenderte Seite, Type Check, git diff --check, Logvergleich oder ein README-Kommando.

Der dritte Fehler ist schnelles Abnicken von Permission Prompts. Wenn ein Prompt erscheint, frage, welches Kommando läuft, welche Pfade es berührt und ob Netzwerk oder Löschung dabei sind. Wenn Prompts nerven, erlaube enge Kommandos statt alles zu öffnen.

Der vierte Fehler ist Kontextverlust. Lange Gespräche verwischen die Anfangsgrenze. Halte Grenze, ausgeführte Kommandos und Restrisiko in der Handoff-Notiz fest. Vermische permanente CLAUDE.md-Regeln nicht mit Sitzungsnotizen.

Der fünfte Fehler ist das Beschädigen uncommitteter Arbeit. In geteilten Repos können andere Entwickler oder Agenten schon Änderungen haben. Starte mit git status --short und schütze fremde Änderungen ausdrücklich.

Handoff-Vorlage

Füge dies am Ende der ersten Aufgabe ein.

## Handoff note

- Task:
- Changed files:
- Verification run:
- Verification not run:
- Important diff points:
- Remaining risks:
- Do not touch next time:
- Suggested next smallest task:

Diese Notiz ist breiter als eine Commit Message. Vor dem Commit wird sie Material für die PR-Beschreibung. Ohne Commit ist sie der Startpunkt der nächsten Sitzung.

Nächste Schritte und bezahlte Pfade

Nach der ersten erfolgreichen Aufgabe geht es um Wiederholbarkeit. Solo-Nutzer sollten wiederkehrende Regeln in CLAUDE.md Vorlagen überführen. Wenn Approvals und Sandbox noch unklar sind, lies den Claude Code Approval and Sandbox Guide.

Für fertige Vorlagen, Checklisten und Onboarding-Material siehe /products/. Für Team-Rollout, repository-spezifisches Onboarding, Permission Design und Review-Workflows nutze /training/. Eine sichere erste Aufgabe lässt sich mit diesem Artikel erledigen. Ein Team-Rollout braucht Regeln, Nachweise und Training, bevor die Nutzung wächst.

In Masas realem Test war das stabilste Muster: zuerst das Repo lesen, nur eine Datei editieren, git diff gemeinsam prüfen und eine Handoff-Notiz hinterlassen. Sitzungen mit großem Startauftrag erzeugten mehr Reviewarbeit, als sie sparten. Sitzungen mit einer erfolgreichen 30-Minuten-Aufgabe machten die zweite Aufgabe leichter zu begrenzen und dem Team zu erklären.