Claude · Kern-Workflows: planen, editieren, ausführen, prüfen

Der größte Fehler im Umgang mit Claude Code ist, es wie einen Automaten zu behandeln: eine vage Anfrage einwerfen und hoffen, dass ein fertiges Feature herausfällt. Die Entwickler, die echten Hebel erzielen, fahren stattdessen einen engen Loop: Aufgabe abgrenzen, Claude planen lassen, kleine Edits machen, Tests laufen lassen und das Diff prüfen, bevor irgendetwas `main` berührt. Diese Lektion geht diesen Loop von Anfang bis Ende durch.

Falls Sie es noch nicht installiert haben: Claude Code ist der terminalbasierte Coding-Agent von Anthropic. Sie führen claude in einem Repo aus und es liest Ihre Dateien, schlägt Änderungen vor und führt mit Ihrer Erlaubnis Befehle aus. Die Claude Code Docs sind die mamaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßgebliche Referenz; hier geht es um die *Gewohnheiten*, die es zuverlässig machen.

Abgrenzen, bevor Sie tippen

Claude Code ist am schwächsten, wenn das Ziel unscharf ist. „Refaktoriere das Auth-Modul“ lädt zu einer ausufernden, schwer prüfbaren Änderung ein. Die Lösung ist, eng abzugrenzen, bevor Sie überhaupt etwas verlangen.

Eine gut abgegrenzte Aufgabe hat drei Eigenschaften:

• Eine klare Grenze. Ein Modul, ein Bug, ein Endpoint. Nicht „die ganze PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen →“.
• Eine Definition von fertig. Meist ein Test, der durchläuft, oder ein Verhalten, das Sie prüfen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen.
• Benannte Dateien, wenn Sie sie kennen. Claude auf src/auth/session.ts zu zeigen ist besser, als es blind greppen zu lassen.

Vergleichen Sie diese zwei Einstiege:

Behebe den Login-Bug.

In src/auth/session.ts verfallen Sessions nach der 30-Minuten-TTL nicht. Finde die Ursache und behebe sie. In session.test.ts gibt es einen fehlschlagenden Test, der am Ende durchlaufen soll.

Der zweite gibt Claude eine Grenze, eine Fertig-Bedingung und eine Startdatei. Sie bekommen eine kleinere, korrektere Änderung.

Plan mode: denken, bevor editiert wird

Plan mode ist das Feature, das Claude Code von einem Code-Generator zu einem Mitarbeiter macht. Wenn Sie ihn aktivieren, untersucht Claude Ihre Codebase und erstellt einen schriftlichen Plan, ohne Dateien zu verändern. Auf der Platte passiert nichts, bis Sie zustimmen.

Sie schalten ihn während einer Session um. Shift+Tab durchläuft die Permission-Modi (dazu unten mehr); einer davon ist plan mode. Sie können eine Session auch darin starten.

Hier der Unterschied, den das macht. Ohne plan mode schreibt Claude eventuell sofort drei Dateien auf Basis einer Vermutung um. Im plan mode kommt es mit so etwas zurück:

Plan: Der TTL-Check in validateSession() vergleicht createdAt mit Date.now(), nutzt aber auf einer Seite Sekunden und auf der anderen Millisekunden. Ich werde: (1) beides auf Millisekunden normalisieren, (2) einen Guard für fehlendes createdAt ergänzen, (3) prüfen, dass session.test.ts durchläuft. Soll ich fortfahren?

Jetzt können Sie den Ansatz korrigieren, *bevor* ein einziger Edit passiert. Wenn Claude den Bug falsch gelesen hat, verbringen Sie zehn Sekunden damit, es umzulenken, statt ein falsches 200-Zeilen-Diff zu prüfen. Bei allem Nichttrivialen: erst planen. Die Kosten sind ein paar Sekunden; der Nutzen ist Steuerung zum günstigsten möglichen Zeitpunkt.

Permission-Modi: wie viel Leine Sie geben

Claude Code läuft nicht wild auf Ihrer Maschine. Jede potenziell wirksame Aktion (Datei editieren, Shell-Befehl ausführen, Netzwerkzugriff) wird durch einen Permission-Modus kontrolliert: die Policy, die entscheidet, was Claude ohne Rückfrage tun darf.

Die Modi, die Sie praktisch nutzen werden:

• Default (ask). Claude schlägt jeden Edit und Befehl vor und wartet auf Ihre Zustimmung. Am sichersten. Nutzen Sie ihn bei unbekanntem Code oder allem in Produktionsnähe.
• Plan mode. Nur lesen und analysieren. Keine Edits, keine Befehle. Zum Abgrenzen und Entwerfen.
• Accept edits. Claude wendet Datei-Edits automatisch an, fragt aber vor Befehlen weiterhin nach. Gut, wenn Sie den Edits vertrauen, aber ein Gate bei der Ausführung wollen.
• Bypass / „dangerously skip permissions“. Claude handelt ohne zu fragen. Schnell und wirklich riskant. Reservieren Sie das für Sandboxes, Wegwerf-Branches oder Container, die Sie wegwerfen können.

Der Instinkt neuer Nutzer ist, Permissions zu überspringen, um „schneller zu sein“. Widerstehen Sie dem in echten Repos. Der ganze Wert des Loops liegt darin, dass Sie darin bleiben. Ein guter Default: plan mode zum Entwerfen, accept-edits zum Umsetzen, manuelle Zustimmung für jeden Befehl, der außerhalb des Arbeitsverzeichnisses schreibt.

Sie können auch bestimmte Tools vorab autorisieren, damit Sie nicht fünfzigmal denselben harmlosen Befehl bestätigen. Setzen Sie sie auf die Allowlist in `.claude/settings.json` im Repo-Root:

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint)",
      "Read(src/**)"
    ],
    "ask": ["Bash(git push:*)"]
  }
}

Das heißt: Test- und Lint-Befehle frei ausführen, alles unter src/ lesen, aber vor einem Push immer anhalten und fragen. Committen Sie diese Datei und Ihr ganzes Team erbt dieselben GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen →.

In kleinen, prüfbaren Schritten editieren

Die Versuchung ist, das ganze Feature auf einmal zu verlangen. Tun Sie es nicht. Die prüfbare Einheit ist das Diff, das *Sie* im Kopf behalten können, und das sind meist 50 bis 150 Zeilen, nicht 600.

Zerlegen Sie die Arbeit in Schritte und geben Sie jeden einzeln frei:

1. „Füge die Konstante SessionTTL hinzu und binde sie in den Config-Loader ein.“
2. „Behebe jetzt die Einheiten-Diskrepanz in validateSession().“
3. „Ergänze einen Regressionstest für den Expiry-Fall.“

Nach jedem Schritt sehen Sie, was sich geändert hat. Das ist keine Bürokratie; so fangen Sie eine falsche Abzweigung bei Schritt eins ab, statt sie bei Schritt fünf zurückzudrehen. Kleine Schritte halten auch Claudes Kontext fokussiert: es denkt über eine Änderung nach und jongliert nicht ein ganzes Epic.

Ein nützliches Prompt-Muster: beenden Sie Anfragen mit „Mache nur diese Änderung. Halte an und zeige es mir, bevor du etwas anderes tust.“ Das bremst ein eifriges Modell, das sonst drei Schritte vorausrennt.

Tests laufen lassen, Claude die Fehler lesen lassen

Sobald die Edits drin sind, lassen Sie Ihre Tests laufen. Der starke Zug ist, Claude sie selbst ausführen zu lassen (per Allowlist, wie oben) und die Ausgabe zu lesen. Fehlschlagende Tests sind das signalstärkste Feedback, das Sie einem Coding-Agenten geben können.

claude "Run the test suite. If anything fails, diagnose and fix it, then re-run until green. Show me the diff before committing."

Claude führt npm test aus (oder was Ihr Projekt nutzt), parst die Fehler, patcht und wiederholt. Dieser geschlossene Feedback-Kreis ist, wo Claude Code sich bezahlt macht: es vermutet nicht, ob der Fix funktioniert hat, es *prüft* es. Ihre Aufgabe ist sicherzustellen, dass die Tests sinnvoll sind. Wenn Ihr Test nichts Echtes prüft, bedeutet ein grüner Lauf nichts, und das liegt an Ihnen, nicht am Modell.

Slash-Commands: die Steuerelemente, die Sie wirklich nutzen

Slash-Commands sind getippte Shortcuts innerhalb einer Claude-Code-Session. Ein paar sollten Sie im Schlaf kennen:

• `/clear` löscht den Gesprächskontext. Nutzen Sie es zwischen unverwandten Aufgaben, damit alte Überlegungen nicht hineinsickern. Günstig und zu selten genutzt.
• `/review` bittet Claude, Code zu prüfen, oft ein anstehendes Diff oder PR.
• `/init` legt eine CLAUDE.md an: ein Projektgedächtnis, in dem Sie Build-Befehle, Konventionen und Fallstricke festhalten, damit Claude sie in jeder Session liest.
• `/model` wechselt, welches Claude-Modell die Session nutzt.
• `/permissions` öffnet die Permission-Einstellungen.

Der wertvollste ist der, den Sie selbst schreiben. Eigene Slash-Commands sind einfach Markdown-Dateien in .claude/commands/. Erstellen Sie .claude/commands/fix-issue.md:

Find the root cause of issue #$ARGUMENTS, scope a minimal fix,
write a failing test that reproduces it, then make it pass.
Show me the diff before committing.

Jetzt führt /fix-issue 412 diesen ganzen Workflow mit eingesetzter Issue-Nummer aus. Alles, was Sie wiederholt tun, sollte ein Command werden, den Ihr Team über das Repo teilt.

Prüfen Sie das Diff, als hätten Sie es geschrieben

Hier die Disziplin, die Profis von Prompt-and-pray-Nutzern trennt: Sie prüfen jedes Diff vor dem Commit, genauso wie Sie den Pull Request eines menschlichen Kollegen prüfen würden.

Fordern Sie das Diff explizit an oder nutzen Sie /review. Und lesen Sie es dann wirklich. Achten Sie auf die Fehlermuster, die für KI-generierten Code typisch sind:

• Stiller Scope Creep. Sie wollten einen TTL-Fix; das Diff hat „hilfsbereit“ auch drei Funktionen umbenannt. Weisen Sie die Extras zurück.
• Plausible, aber falsche Logik. Code, der sich gut liest und subtil falsch ist, ist Claudes gefährlichster Output. Die Tests fangen viel; Ihre Augen den Rest.
• Gelöschte Edge Cases. Ein „saubereres“ Rewrite, das stillschweigend einen Null-Check weggelassen hat.
• Verschluckte Fehler. Ein try/catch, das genau den Fehler versteckt, den Sie gerade debuggt haben.

Weil Sie in kleinen Schritten gearbeitet haben, geht diese Prüfung schnell. Ein 100-Zeilen-Diff gegen einen klaren Plan braucht ein paar Minuten. Ein 600-Zeilen-Diff gegen eine vage Anfrage ist, wo Bugs in main rutschen.

Committen, dann über GitHub pushen

Wenn das Diff stimmt, committen Sie es. Claude kann die Message schreiben; Sie bestätigen, dass sie zu dem passt, was sich tatsächlich geändert hat.

Für die letzte Meile bringt die Claude GitHub Integration Sie über Ihr Terminal hinaus. Taggen Sie @claude in einem Issue oder PR-Kommentar, und es kann Pull Requests öffnen, auf Review-Feedback antworten und als GitHub Action in CI laufen. Der lokale Loop, den Sie gerade geübt haben (planen, editieren, ausführen, prüfen), ist derselbe Loop, nur jetzt auf einem Pull Request, wo Ihre Teammitglieder das Diff mitprüfen.

Diese Symmetrie zählt. Die Gewohnheiten skalieren: ein enger Loop auf Ihrem Laptop ist ein enger Loop in CI.

Den Loop zusammensetzen

Eine echte Session von Anfang bis Ende:

1. Abgrenzen. „Sessions verfallen nach der 30-Min-TTL nicht. Behebe es in session.ts, sorge dafür, dass session.test.ts durchläuft.“
2. Planen (Shift+Tab für plan mode). Claudes Diagnose lesen, zustimmen oder korrigieren.
3. Editieren (accept-edits mode). Die minimale Änderung anwenden.
4. Ausführen. Claude die Suite laufen lassen und bis grün iterieren.
5. Prüfen. Das Diff lesen. Scope Creep zurückweisen.
6. Committen und pushen. Message bestätigen, PR öffnen.

Jeder Schritt ist ein Checkpoint, an dem eine falsche Abzweigung Sekunden statt Stunden kostet.

Wichtigste Erkenntnisse

• Grenzen Sie jede Aufgabe auf eine Grenze, eine Fertig-Bedingung und benannte Dateien ab. Vage Anfragen erzeugen ausufernde, nicht prüfbare Diffs.
• Planen, bevor Sie editieren. Nutzen Sie plan mode (Shift+Tab), damit Sie den Ansatz korrigieren können, bevor sich eine einzige Datei ändert, also wenn Steuern am günstigsten ist.
• Setzen Sie Permission-Modi bewusst und nehmen Sie harmlose Befehle in die Allowlist in .claude/settings.json. Plan mode zum Entwerfen, accept-edits zum Bauen, manuelle Zustimmung für alles, was außerhalb des Arbeitsverzeichnisses schreibt.
• Arbeiten Sie in Schritten von 50 bis 150 Zeilen und lassen Sie Claude die Tests laufen. Fehlschlagende Tests sind das signalstärkste Feedback, auf das ein Agent reagieren kann.
• Prüfen Sie jedes Diff vor dem Commit wie einen PR und achten Sie auf Scope Creep und plausible, aber falsche Logik. Machen Sie wiederkehrende Workflows zu eigenen Slash-Commands, die Ihr Team teilt.