Claude Code Tutorial: dein erstes Feature mit kontrolliertem Agenten-Workflow

Nutze für die Installation die aktuelle offizielle Anleitung von Anthropic, da Installationswege und unterstützte Oberflächen sich ändern können. Starte danach im Ordner eines kleinen Git-Projekts. Ein Verzeichnis mit privaten Dokumenten oder Secrets ist der falsche Ort.

cd mein-projekt
claude

• Git-Repository vorhanden
• Arbeitsbaum vor Start bekannt
• .env und Secrets ignoriert
• Build- und Testbefehl dokumentiert

Prüfe nach dem Start zuerst den Arbeitsbaum mit Git und lass dir unbekannte Änderungen erklären. Erteile Schreib- oder Befehlsrechte nur für den konkreten Schritt und lies Shell-Befehle vor der Ausführung. Besonders Installationsskripte, Datenbankmigrationen und rekursive Dateioperationen verdienen eine bewusste Freigabe, weil ihre Wirkung über die sichtbare Feature-Datei hinausgeht.

Ein guter Auftrag enthält Ziel, Nutzerverhalten, relevante Einschränkungen und Prüfkriterien. Bitte den Agenten zuerst, vorhandene Struktur und Konventionen zu untersuchen. So verhinderst du, dass er parallel zur bestehenden Architektur ein zweites Muster erfindet.

Analysiere zuerst die bestehende Authentifizierung.
Plane dann eine Funktion, mit der Nutzer ihr Passwort ändern.
Akzeptanzkriterien:
- altes Passwort wird serverseitig geprüft
- neues Passwort hat mindestens 12 Zeichen
- bestehende Fehlermeldungen und UI-Komponenten werden wiederverwendet
- relevante Tests laufen erfolgreich
Noch nichts ändern; zeige zuerst den Plan.

Lege dauerhafte Projektregeln in einer kurzen, versionierten Datei ab: Architekturgrenzen, Testbefehle, Formatierung, Umgang mit Migrationen und verbotene Zugriffe. Sitzungsbezogene Details gehören dagegen in den aktuellen Auftrag. Diese Trennung hält den Kontext klein und verhindert, dass alte Produktannahmen später wie unveränderliche technische Regeln behandelt werden.

1. 1

   Repository verstehen

   Relevante Dateien, Konventionen und Tests identifizieren lassen.

2. 2

   Plan freigeben

   Dateien, Datenfluss, Fehlerfälle und Verifikation prüfen.

3. 3

   Fokussiert implementieren

   Nur den vereinbarten Umfang ändern lassen.

4. 4

   Automatisch verifizieren

   Gezielte Tests, Typecheck oder Build ausführen.

5. 5

   Visuell prüfen

   Happy Path und wichtigsten Fehlerfall im Browser testen.

6. 6

   Diff und Commit

   Unnötige Änderungen entfernen, dann stabilen Stand sichern.

Nach jedem Teilstück sollte Claude Code den eigenen Diff gegen die Akzeptanzkriterien prüfen. Bitte um eine Liste geänderter Dateien, ausgeführter Tests und verbleibender Unsicherheiten. Führe den wichtigsten Nutzerablauf trotzdem selbst aus. Ein grüner Test beweist nur das codierte Verhalten; er erkennt nicht automatisch missverständliche Texte oder einen unpraktischen Ablauf.

• Claude im falschen oder zu breiten Verzeichnis starten
• Uncommittete eigene Arbeit mit Agenten-Änderungen vermischen
• Befehle mit weitreichenden Schreibrechten ungeprüft ausführen
• Nur auf die Aussage „Tests bestanden“ vertrauen, ohne Ausgabe zu kontrollieren
• Nach mehreren Reparaturversuchen keinen Schritt zurückgehen und Ursache neu analysieren

Bei einem Fehler ist die erste Aufgabe Reproduktion, nicht Reparatur. Sammle exakten Befehl, vollständige Meldung, Eingabe und erwartetes Verhalten. Lass Claude Code anschließend die wahrscheinlichste Ursache mit Belegen aus dem Repository erklären. Erst danach folgt eine kleine Korrektur samt Regressionstest, der vor dem Fix fehlschlägt und danach besteht.

Ziel: Nutzer können einen Projektnamen ändern.\nGrenzen: bestehende Authentifizierung und UI-Komponenten wiederverwenden.\nPrüfung: fremde Projekte liefern 404; leere Namen werden abgelehnt; vorhandene Tests bleiben grün.\nAblauf: erst relevante Dateien untersuchen, dann Plan zeigen, anschließend in einem kleinen Diff umsetzen.

Der Auftrag nennt absichtlich nicht jede Codezeile. Claude Code darf die passende Stelle im bestehenden Projekt finden, muss seine Entscheidung aber vor der Änderung begründen. Nach der Umsetzung vergleichst du das sichtbare Verhalten mit den drei Prüfpunkten und kontrollierst, dass weder Authentifizierung noch andere Projektfelder verändert wurden.

Arbeite für das Beispiel auf einem eigenen Git-Branch und sichere den unveränderten Ausgangspunkt. Wenn der erste Ansatz nicht passt, vergleiche ihn mit den Kriterien, statt sofort weitere Reparaturaufträge anzuhängen. Häufig ist ein sauberer Rücksprung mit einem präziseren Auftrag schneller als mehrere aufeinander aufbauende Korrekturen. Der abschließende Commit sollte nur das Feature und seinen Nachweis enthalten, damit Review und spätere Fehlersuche übersichtlich bleiben.

Beende die Sitzung mit aufgeräumtem Kontext: Entferne temporäre Dateien, prüfe den Git-Status und notiere nur tatsächlich verbleibende Aufgaben. Bitte Claude Code um keine spekulative Erfolgsmeldung, sondern um Befehle und Ergebnisse, die du selbst nachvollziehen kannst. So startet die nächste Sitzung auf einem bekannten Stand und muss nicht aus einem langen Chatverlauf erraten, welche Änderungen wirklich geprüft wurden.