CGS IT Solutions GmbH — Claude Code Training · Modul 4 · Praktische Arbeit mit Claude Code · v0.11.5

Modul 4

Praktische Arbeit mit Claude Code

Tag 2 · ca. 105 Minuten

Inhalt

1Iterative Workflows — der tägliche Zyklus und sein Zuschnitt 2Self-Check, Review Loops & Human in the Loop — was der Agent prüft, wo der Mensch hingehört 3Approvals & Approval Fatigue — Permissions bewusst statt reflexhaft, auto-Modus 4Verifiable Outputs — beendet ist nicht abgeschlossen 5Long-running & Recurring Tasks — lange Läufe und wiederkehrende Prüfungen 6Session & Context-Lebenszyklus — /clear, /compact, Handoff, Caching 7Daily AI Usage — ein realistischer Arbeitstag, dann die Zusammenfassung Übung 4 — über einen Context-Reset hinweg

Lernziel Modul 4

Der Teilnehmer beherrscht den täglichen iterativen Arbeitszyklus inkl. Review-Loops, Approvals und Session-Management.

  1. In kleinen Schritten arbeiten — ein iterativer Zyklus statt einem Riesen-Auftrag; jeder Schritt bleibt überprüfbar (Verifiable Outputs).
  2. Jeden Schritt abnehmen — Review-Loops und Approvals bewusst setzen (Human in the Loop) und merken, wann ständiges Bestätigen zur „Approval Fatigue" wird.
  3. Die Session bewusst führen — --continue/--resume, /compact//clear, Token-Budget und Prompt-Caching im Blick.
„Beherrscht" heißt hier Bedienkompetenz, nicht nur Verständnis — deshalb ist Modul 4 das mit dem höchsten Live-Demo-Anteil.

Iterative Workflows

Der tägliche Zyklus

Die Schleife selbst kennt ihr aus dem Chat.
Geändert hat sich, was am Ende herauskommt: kein Text zum Überfliegen, sondern ein Artefakt (Datei, Test, RFC) — und das kostet Prüfzeit statt Lesezeit.

eine Iteration — bis es passt
Daten
Promptwas du willst
Prozess
Claude arbeitetCode · Diff · Testlauf
Daten
ArtefaktRFC · Java · Test
Antwortwas gemacht wurde
passt nicht? — Refinement-Prompt zurück zum Anfang  ·  passt? — fertig
Prozess Daten
Die richtige Iterationsgröße:
a) Ergebnis in 2 Minuten beurteilbar — genau richtig.
b) Dauert es länger — zu großer Schritt, zu viel des Guten (aufteilen).

Zuschnitt einer Iteration

Zwei Hebel machen einen Schritt abnehmbar: der Zuschnitt bestimmt die Größe, die Formulierung nennt die konkreten Abnahmebedingungen.

Zu groß — nicht abnehmbarImplement booking cancellation for the seminar API.
Eine Iteration — abnehmbarAdd a failing test for cancelling a booking that is already cancelled. It must expect HTTP 409 and the message "booking already cancelled". Do not touch BookingService yet. Run `mvn test -Dtest=BookingCancelTest` and show me the failure output.

Ein abnehmbarer Zuschnitt nennt drei der fünf Bausteine (Modul 3):

  1. Was genau — das Ziel, klein gehalten (ein Test, kein ganzes Feature).
  2. Was ausdrücklich nicht — die Randbedingung: „Do not touch BookingService yet".
  3. Woran man Fertig sieht — das Abnahmekriterium: HTTP 409, Test-Output.

Kopierfertig: Anhang · Vorlagen

AI Self-Check, Review Loops & Human in the Loop

Was der Agent selbst prüfen kann

Vier Selbstprüfungen, absteigend nach Objektivität.
Die ersten drei nutzt jeder; der stärkste Hebel ist der vierte — und er fehlt in der Praxis fast immer.

  1. Kompilieren und Tests laufen lassen — der objektivste Self-Check überhaupt: das Ergebnis kommt nicht vom Modell.
  2. Den eigenen Diff nochmal lesen — „Read your own diff and list anything that doesn't belong" findet erstaunlich viel: Debug-Ausgaben, halbe Umbenennungen, vergessene TODOs.
  3. Gegen eine Checkliste prüfen — eine Liste im Repo schlägt eine Liste im Kopf: sie ist bei jedem Lauf dieselbe.
  4. Einen frischen Reviewer ansetzen — ein Subagent ohne die Vorgeschichte sieht den Code, nicht die Begründung dafür. Er ist nicht auf die Lösung eingeschworen, weil er sie nicht mitentwickelt hat (Modul 8).
Grenze aller vier: Wer den Code geschrieben hat, hat auch die Annahme geschrieben, unter der er richtig aussieht.
Selbstprüfung findet Schlampigkeit — nicht Missverständnisse.

Definierte Punkte statt permanenter Kontrolle

„Human in the Loop" heißt nicht danebensitzen und zusehen — wer dauernd zusieht, hat keinen Produktivitätsgewinn und wird trotzdem unaufmerksam.

  1. Vor dem Losgehen — ist das überhaupt die richtige Aufgabe? Der teuerste Fehler ist der perfekt umgesetzte falsche Plan.
  2. Beim Abbiegen — der Agent nimmt einen Weg, den ihr nicht wolltet. Sofort stoppen, nicht „mal schauen, wo der Agent rauskommt".
  3. Vor dem Wirksamwerden — Commit, Push, Deploy, Migration, Datenlöschung. Alles, was außerhalb eures Rechners Folgen hat.
vor dem Losgehen
der Agent arbeitet
beim Abbiegen
der Agent arbeitet weiter
vor dem Wirksamwerden
Commit · Push · Deploy
orange: hier steht ein Mensch — dazwischen nicht
Dazwischen darf der Agent arbeiten.
In Modul 5 werden aus diesen drei Punkten formale Gates — dieselben Stellen, nur aufgeschrieben.

Den Diff lesen — die Mindestpflicht

Was nicht reicht

„Tests sind grün, passt."

Die Zusammenfassung des Agenten lesen statt den Diff.

400 geänderte Zeilen durchscrollen und nicken.

Was reicht

Jede geänderte Datei einmal angesehen — warum ist sie geändert?

Jede Datei, die euch überrascht, ist ein Fund.

Änderungen, die nicht zur Aufgabe gehören, gehören raus.

Die Zusammenfassung des Agenten ist generierter Text über den Code, nicht der Code.
Beides klingt gleich überzeugend (Modul 1).

Approvals & Approval Fatigue

Permissions sind eine Vertrauensgrenze

Bevor der Agent ein Werkzeug benutzt, entscheidet eine Regel: erlaubt, nachfragen oder verboten.

allow

Läuft ohne Rückfrage. Für alles Harmlose und Häufige: lesen, suchen, Tests laufen lassen.

ask

Der Standardfall. Der Agent hält an und fragt — das ist die Voreinstellung für Unbekanntes.

deny

Wird gar nicht erst angeboten. Für alles, was ihr nie bestätigen wollt.

Die Regeln liegen als Konfiguration im Repo — damit sind sie versioniert, reviewbar und für das ganze Team gleich (Modul 10).
checked am 2026-07-21 gegen claude --help

Approval Fatigue

Was tatsächlich passiert

Minute 1–5: jede Rückfrage wird gelesen.

Minute 5–20: überflogen.

Ab Minute 20: Enter, Enter, Enter.

Die Rückfrage, auf die es ankam, war Nummer 47.

Die Gegenmaßnahme

Die Zahl der Rückfragen so weit senken, dass jede einzelne wieder Aufmerksamkeit verdient.

Das Harmlose freigeben, das Gefährliche verbieten — nicht abfragen.

Wer alles einzeln bestätigen muss, bestätigt nach 20 Minuten blind.
Das ist gefährlicher als weniger Rückfragen — weil es sich sicher anfühlt.

Wege aus der Rückfrage-Flut

Weniger Rückfragen bekommt ihr auf drei Arten — und sie unterscheiden sich darin, wer die Entscheidung trifft.

/permissions
Regeln vorab
ihr entscheidet, einmalschriftlich und nachlesbar
Harmloses erlauben, Gefährliches verbieten — der Standardweg
acceptEdits
ihr entscheidet, pro Diffnur Dateien; Befehle fragen weiter
gut, solange ihr ohnehin jeden Diff lest
auto-Modus
ein Klassifikator entscheidetprüft im Hintergrund, statt zu fragen
bequem — aber die Entscheidung ist nicht mehr nachlesbar
bypassPermissions
niemand entscheidetkein Weg aus der Flut, sondern der Verzicht auf die Grenze
Modul 9
von oben nach unten wandert die Entscheidung von euch weg
Regeln sind Entscheidungen, die stehen bleiben; ein Klassifikator ist eine Einschätzung pro Fall.
Für alles, was unumkehrbar ist, wollt ihr die Entscheidung — nicht die Einschätzung.
checked am 2026-07-26 gegen code.claude.com/docs/permission-modes

Echtes Beispiel: das Gefährliche verbieten

Ausschnitt aus einem produktiv genutzten Projekt (cgsit-finance) — .claude/settings.json.

{
  "permissions": {
    "allow": [ "Read(**)", "Write(**)", "Bash(**)" ],
    "deny": [
      "Bash(rm -rf /)",
      "Bash(git push --force *)",
      "Bash(git reset --hard*)",
      "Bash(git clean -fd*)",
      "Bash(docker compose down -v*)",
      "Bash(*DROP TABLE*)",
      "Bash(aws rds delete-db-instance*)",
      "Bash(aws s3 rm*--recursive*)",
      "Bash(*pastebin*)", "Bash(*transfer.sh*)"
    ]
  }
}
Breit erlauben, gezielt verbieten.
Die deny-Liste ist kurz, lesbar und beantwortet die Frage: „Was darf hier nie passieren?"

Die Grenze schriftlich ziehen

„Push & Deploy Policy" aus CLAUDE.md desselben Projekts.

Aktion Regelung
Lokale Builds, Tests, Commits autonom, keine Rückfrage
CI-Status abfragen, Logs lesen, Backups ziehen autonom, nur ankündigen
git push origin main autonom, wenn Commits fertig sind
git push --no-verify (Hook übergehen) vorher fragen
Deploy auf Produktion immer fragen
git push --force, alles Destruktive immer fragen
Die Entscheidung fällt einmal — nicht bei jeder Rückfrage neu.

Verifiable Outputs

Beendet ist nicht abgeschlossen

Beide Sätze heißen „fertig" — aber sie kommen aus verschiedenen Quellen, und nur eine davon ist überprüfbar.

beendet
der Agenthört auf zu arbeiten
„Done“
eine Aussage des Modells
über sich selbst
abgeschlossen
der Agentliefert einen Stand ab
Test · Build · Endpoint
grün
eine Aussage der Welt
über den Code
links urteilt der Beurteilte selbst
Ohne objektives Abnahmekriterium ist eine Agentenaufgabe nicht abgeschlossen, sondern nur beendet.

Modul 1: Der Weg ist nicht-deterministisch — also darf nur das Ergebnis das Abnahmekriterium sein, nie der Weg dorthin.

Das Abnahmekriterium gehört in den Prompt

Ein Test

Der stärkste Kandidat — und der einzige, der beim nächsten Mal automatisch wieder prüft.

Ein Build

Kompiliert, verlinkt, gepackt. Fängt halluzinierte APIs sofort ab.

Ein laufender Endpoint

curl gegen die gestartete Anwendung: erwarteter Status, erwartete Antwort.

Ein gelesener Diff

Schwächer, aber legitim — und für Doku oder Konfiguration oft das einzig Mögliche.

Eine Suche mit Erwartung

„grep auf das alte Symbol liefert null Treffer" — perfekt für Aufräumarbeiten.

Nicht geeignet

„Sieht gut aus." — „Der Agent sagt, es funktioniert." — „Keine Fehlermeldung."

Kriterium in den Auftrag schreiben Done when: `mvn test -Dtest=BookingCancelTest` passes, `mvn clean compile` is green, and `git diff --stat` touches only BookingService.java and its test. Show me all three outputs.

Long-running & Recurring Tasks

Was passiert, wenn niemand zusieht

Long-running & Recurring Tasks

Long-running

Große Migration, Testsuite nachrüsten, Abhängigkeiten heben. Läuft lange, produziert viel.

Regeln: in Etappen mit eigenem Abnahmekriterium zerlegen · Zwischenstand ins Repo schreiben, nicht in die Session · laute Ausgaben (Test-Logs, Builds) in einen Subagenten auslagern.

Ohne offenes Fenster: claude --bg startet neu, /bg verschiebt die laufende Sitzung, /fork dupliziert sie. Verwaltet wird alles mit claude agents.

Vorsicht: der Freigabe-Modus wandert mit. Wer vorher auf acceptEdits geschaltet hat, lässt die Sitzung unbeaufsichtigt so weiterarbeiten.

Recurring

Immer gleich, immer wieder: Security-Review vor dem Release, Doku-Abgleich, Abhängigkeits-Check.

Regeln: nicht jedes Mal neu formulieren — als Command oder Skill ins Repo legen (Modul 8) und, wo möglich, in die CI hängen (Modul 9).

Zwei Taktgeber: /loop 5m /befehl wiederholt lokal in dieser Sitzung; /schedule legt einen entfernten Agenten auf Cron-Basis an.

Ein langer Lauf ist vor allem ein Kontext-Problem: Die Session, in der er endet, ist nicht mehr die, in der er begann.
checked am 2026-07-27 gegen CLI 2.1.220 (--bg, claude agents)

Session & Context-Lebenszyklus

Die Session ist ein Budget

Aus Modul 1: Sessions wachsen nur — Systemprompt, CLAUDE.md, jede gelesene Datei und jede Testausgabe bleiben drin und fahren bei jedem weiteren Schritt mit.

System + CLAUDE.md gelesene Dateien Tool-Ausgaben, Tests, Logs Verlauf frei
Wer den Füllstand nicht kennt, merkt das Problem erst an der schlechter werdenden Antwortqualität.
Dann ist es zu spät.
checked am 2026-07-21 gegen Doku

Die Hebel beim Token-Sparen

Erst messen lassen, dann eingreifen: /context rechnet vor, wohin die Tokens gehen — und schlägt die Korrektur gleich mit vor.

  1. Gezielt lesen statt ganze Dateien — der mit Abstand größte Posten in langen Sessions.
  2. Große Ausgaben auslagern: Testläufe und Log-Analysen an einen Subagenten (Modul 8) — nur dessen Ergebnis kommt zurück.
  3. Hooks als Vorfilter: ein Hook grept die Fehlerzeilen heraus, statt 10.000 Zeilen Log durchzureichen.
  4. CLI statt MCP, wo es geht; ungenutzte Server abschalten (Modul 8b).
  5. CLAUDE.md schlank halten — Spezialwissen in Skills, das lädt erst bei Bedarf.
  6. Aufgabenwechsel = /clear; /compact mit Fokus-Anweisung statt blind.
/context
System prompt 4.2k (0.4%)
System tools 18.4k (1.8%)
Memory files 10.9k (1.1%)
Skills 2.0k (0.2%)
Messages 519.6k (52.0%)
Free space 444.8k (44.5%)

Suggestions
Read results using 3.4m tokens (336%)
-> save ~1m
Use offset and limit to read only the
sections you need.
checked am 2026-07-26 gegen code.claude.com/docs/costs

Welches Werkzeug wann

Zwei wirken innerhalb der laufenden Sitzung, zwei sind Startoptionen am Terminal.
Das ist die häufigste Verwechslung — und die rechte Spalte ist die eigentliche Entscheidung.

Werkzeug Was passiert Wann ihr es nehmt
/clearNeue Session mit leerem Kontext; die alte bleibt gespeichertThemenwechsel — immer. Der alte Kontext hilft nicht, er kostet und lenkt ab.
/compactDer Verlauf wird durch eine Zusammenfassung ersetztGleiches Thema, Kontext wird eng — erst den Zwischenstand ins Repo, dann kompaktieren.
claude --continueDie letzte Unterhaltung in diesem Verzeichnis läuft weiterTerminal war zu, morgen genau da weiter.
claude --resumeAuswahl einer früheren Unterhaltung (Picker oder Session-ID)„Welche von den fünfen war das nochmal?"
/compact ist verlustbehaftet — aus dem Verlauf wird generierter Text, und niemand sagt euch, was gefehlt hat.
Zweimal hintereinander komprimiert ihr die Zusammenfassung einer Zusammenfassung: dann lieber Handoff schreiben und /clear.
checked am 2026-07-21 gegen Doku

Vor dem /compact: extrahieren

Aus der Praxis In der Session wurde eine Konvention vereinbart, ein Fehlschlag analysiert und eine Architektur-Entscheidung begründet. Nach dem /compact stand in der Zusammenfassung: „Diverse Verbesserungen besprochen." Was nur im Verlauf lebt, überlebt die Kompaktierung nicht. Es muss vorher in eine Datei.
Was in der Session entstanden ist Wohin es gehört
Projektweite Regel, Policy, WorkflowCLAUDE.md
Konvention für einen bestimmten BereichRules-Datei im Projekt
Architektur-Entscheidung mit Begründungdocs/<thema>.md bzw. RFC
Stand der laufenden AufgabeHandoff-Datei (nächste Folie)
Nichts davon — nur Rauschendarf verschwinden

Vorbild: docs/compaction-checklist.md aus einem produktiven Projekt.

Der Handoff

Ein Handoff ist das, was ihr einem Kollegen hinlegen würdet, der die Aufgabe morgen ohne euch zu Ende bringt — genau das ist die nächste Session auch.

Prompt vor dem Context-Reset Write HANDOFF.md before we reset the context. Include: 1. Goal — what we are building, in two sentences 2. State — what is done, what is not, which files changed 3. Decisions — what we chose and what we rejected, with the reason 4. Verification — the exact commands that must pass when it is done 5. Next step — the single next action for a fresh session Facts only. No summary prose. Anything not written down is lost.
Der Test für einen guten Handoff: Die frische Session macht damit weiter — ohne dass ihr etwas nacherzählen müsst.

Wo Kosten und Kontext-Hygiene sich widersprechen

Dieses Modul gibt euch zwei Ratschläge, die gegeneinander ziehen: Eine lange stabile Session ist billiger, weil der unveränderte Anfang wiederverwendet statt neu verarbeitet wird — und jeder Themenwechsel gehört trotzdem in ein /clear.
Beides stimmt.

  1. Der Konflikt ist echt, nicht scheinbar — ein /clear wirft den wiederverwendbaren Anfang weg. Ihr zahlt ihn beim nächsten Schritt noch einmal.
  2. Auflösung: Qualität gewinnt. Sobald die Antworten schlechter werden, ist der Kontext teurer als der Cache. Tokenkosten sind fast immer kleiner als eine Stunde Entwicklerzeit für einen Fehllauf.
  3. Was beide Ziele bedient: Modell, Aufwandsstufe und Werkzeuge vor der Arbeit festlegen. Ein Wechsel mittendrin zerreißt den Anfang, ohne dass ihr etwas dafür bekommt.
Wie der Cache technisch funktioniert — Präfix-Prinzip, was ihn zerreißt, wie lange er hält: Modul 3.
Hier zählt nur die Konsequenz für den Arbeitstag.
checked am 2026-07-26 gegen code.claude.com/docs/prompt-caching

Daily AI Usage

Ein realistischer Tag — und die Zusammenfassung

Daily AI Usage — ein realistischer Tag

1Session starten, Kontext setzen. Im Projektverzeichnis, damit CLAUDE.md und Regeln greifen. Erste Frage: Was ist der Stand?
2Aufgabe zuschneiden. Ein Ticket, nicht ein Projekt. Abnahmekriterium vorher festlegen und in den Prompt schreiben.
3Iterieren. Arbeiten lassen, Diff lesen, verifizieren, korrigieren. Zwei Minuten pro Abnahme.
4Commit als Wasserstandsmarke. Kleine Commits sind der billigste Rückwärtsgang — und die einzige Stelle, an der der Agent nichts kaputtmachen kann.
5Themenwechsel = /clear. Nicht „ich mach im selben Fenster noch schnell was anderes".
6Bei langen Aufgaben: Zwischenstand ins Repo, dann kompaktieren oder neu starten. Nie ungesichert weiterlaufen lassen.
7Tagesende: aufräumen. Gelerntes in CLAUDE.md oder docs/, offener Stand in den Handoff, Commits gepusht.

Modul 4 in fünf Sätzen

  1. Arbeitet in Iterationen, die ihr in zwei Minuten abnehmen könnt.
  2. Der Self-Check des Agenten findet Schlampigkeit — Missverständnisse findet nur der Mensch.
  3. Konfiguriert Permissions bewusst: das Gefährliche verbieten, statt das Harmlose einzeln zu bestätigen.
  4. Ohne objektives Abnahmekriterium ist eine Aufgabe beendet, nicht abgeschlossen.
  5. Führt die Session bewusst: extrahieren, dann /compact oder /clear — und alles Wichtige liegt im Repo, nicht im Verlauf.
Das sind die fünf Handgriffe für Montag.
Modul 5 macht daraus einen durchgehenden Phasen-Workflow mit Gates und Artefakten.

Übung 4 — über einen Context-Reset hinweg

Aufgabe

Beginnt in seminar-api eine Aufgabe mit klarem Abnahmekriterium — zum Beispiel: Stornieren einer bereits stornierten Buchung liefert HTTP 409 mit einer verständlichen Meldung, abgesichert durch einen Test.

Arbeitet bis etwa zur Hälfte. Dann: HANDOFF.md schreiben lassen /clear in der frischen Session nur mit dem Handoff weiterarbeiten. Keine Nacherzählung aus dem Kopf.

Verifizierbares Ergebnis: Der Test ist grün und der Handoff hat gereicht — ihr könnt benennen, welche Information gefehlt hat und in welchen der fünf Abschnitte sie gehört hätte.

Dauer ca. 30 Minuten · Einzel- oder Paararbeit

© 2026 CGS IT Solutions GmbH

Alle Rechte vorbehalten

Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung, Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.

cgsit-claude-training · Modul 4 · v0.11.5