CGS IT Solutions GmbH — Claude Code Training · Modul 3 · v0.1.0

Modul 3

Prompting & Context Engineering

Tag 1 · ca. 105 Minuten

Lernziel Modul 3

Der Teilnehmer kann Prompts strukturieren, den Context bewusst kuratieren und Qualitätsverfall bei vollem Context-Window erkennen und vermeiden.

Drei Verben: strukturieren, kuratieren, erkennen. Das dritte ist das, was die meisten Teams nie lernen — und das teuerste.

Inhalt

Prompt-Strukturierung

Vom Zuruf zum Auftrag

Context Engineering & Context Gathering

Was in die Session darf — und was nicht

Context Window & Context Degradation

Lost in the Middle / „Context Rot"

LLM Knowledge Gaps & Hallucinations

Die Lücke, die selbstsicher klingt

Autoregressive Generierung

„Make the Next Token Obvious"

Instruktions-Überladung vermeiden

„Overshooting Prompts"

QRSPI-Prinzipien

Prompting als Haltung, nicht als Formel

Prompt-Strukturierung — fünf Bausteine

Ziel

Was soll am Ende anders sein? Ein Satz, im Ergebnis formuliert — nicht in Tätigkeiten.

Kontext

Wo im Projekt? Welche Dateien, welche Konvention, welches Vorwissen fehlt ihm?

Randbedingungen

Was er nicht anfassen darf. Grenzen sind wertvoller als Wünsche.

Abnahmekriterium

Woran messen wir Erfolg? Test grün, Endpoint antwortet, Build läuft.

Ergebnisform

Diff? Plan? Antwort mit Belegstelle? Sag es, sonst rät er.

Prüffrage: Könnte ein neuer Kollege mit genau diesem Text loslegen, ohne zurückzufragen? Wenn nein, fehlt einer der fünf Bausteine.

Paar 1 — vom Zuruf zum Auftrag

VorherSomething is wrong with the bookings, seats don't add up. Can you fix it?
NachherGoal: a seminar must never be overbooked. Context: BookingResource -> BookingService -> BookingRepository. Seat capacity lives on Seminar.maxSeats. We suspect a race between two concurrent POST /bookings for the last seat. Constraints: do not change the REST contract, do not add new dependencies, stay inside the booking package. Acceptance: a new test that fails on main and passes after the fix, plus `mvn test` green. Output: first a short diagnosis (max 10 lines) with file and line references. Wait for my OK before changing code.

Der Prompt darf länger sein als die Aufgabe

1Ergebnis vor Tätigkeit. „Ein Seminar darf nicht überbucht werden" schlägt „prüf mal die Kapazität".
2Einstiegspunkt nennen. Eine Klasse, ein Endpoint, ein Testname — das spart ihm zehn Suchläufe und euch die Tokens dafür.
3Negative Grenzen setzen. „Nicht das Schema ändern" verhindert mehr Schaden als drei positive Wünsche.
4Zwischenstopp einbauen. Erst Diagnose, dann Code. Ein falscher Plan kostet 30 Sekunden, ein falscher Umbau eine Stunde.
Zwei Minuten Prompt schreiben ist billiger als zwanzig Minuten Diff lesen, der in die falsche Richtung geht.

Context Engineering & Context Gathering

Der Prompt ist nur ein Teil der Eingabe

Was beim Modell ankommt, ist weit mehr als das, was ihr getippt habt. Alles davon konkurriert um dasselbe Fenster:

System
CLAUDE.md
Gelesene Dateien, Tool-Ausgaben, Historie
Prompt
frei
Prompt Engineering ist das Formulieren einer Nachricht. Context Engineering ist die Entscheidung, was überhaupt im Fenster liegt — und was rausbleibt.

Context Gathering — wie Kontext hineinkommt

Ihr liefert

Dateien nennen, Ausschnitte einfügen, Fehlermeldung reinkopieren. Präzise, aber Handarbeit.

Er sucht selbst

Grep, Dateibaum, Lesen. Bequem — und die häufigste Quelle für unbemerkt vollgelaufene Fenster.

Werkzeuge liefern

Build-, Test- und Git-Ausgaben. Ein einziger roter Build kann tausende Tokens bedeuten.

Das Repo liefert

CLAUDE.md fährt bei jedem Aufruf mit — der einzige Kontext, der nie vergessen wird (Modul 7).

Kuratieren heißt: das Wenigste hineingeben, mit dem die Aufgabe lösbar ist — nicht das Meiste, das hineinpasst.

Paar 2 — Kontext einsammeln lassen

VorherRead the whole project and explain how the booking flow works.
NachherQuestion: what happens between POST /bookings and the row being written to the database? Start at BookingResource. Follow only the call chain, do not read tests, do not read the frontend module. Answer in at most 12 lines, one line per hop, each with file:line as evidence. If a hop is unclear, say so instead of guessing.
Nicht „lies alles" — sondern Startpunkt, Suchrichtung, Abbruchkriterium und Antwortlänge.

Context Window & Context Degradation

Das Fenster ist eine Obergrenze — kein Ziel

Jedes Modell hat ein maximales Fenster in Tokens. Zwei Missverständnisse sind weit verbreitet:

Mythos

„Großes Fenster = ich kann alles reinkippen."

„Solange nichts abgeschnitten wird, ist alles gleich gut nutzbar."

„Volles Fenster ist nur ein Kostenproblem."

Realität

Die Aufmerksamkeit verteilt sich über alles, was drin liegt.

Je mehr Irrelevantes, desto mehr Konkurrenz für das Relevante.

Volles Fenster ist ein Qualitätsproblem — die Rechnung ist nur der sichtbare Teil.

Konkrete Fenstergrößen stehen bewusst nicht auf dieser Folie — sie ändern sich pro Modellgeneration. Aktuellen Stand vor dem Kurs in der offiziellen Dokumentation prüfen und mündlich ergänzen; die Auslastung der laufenden Session lässt sich in Claude Code live zeigen. — geprüft am 2026-07-21

Lost in the Middle / „Context Rot"

Information am Anfang und am Ende des Kontexts wird zuverlässiger verwertet als Information in der Mitte. Der Effekt heißt Lost in the Middle.

Anfang des KontextsMitteEnde
„Context Rot": Je voller und je länger eine Session läuft, desto mehr verrottet der Kontext — Vorgaben aus der Mitte verlieren ihre Wirkung, ohne dass irgendetwas sichtbar abgeschnitten wird.

Woran ihr „Context Rot" erkennt

Wiederholungen

Er erklärt dieselbe Sache nochmal, schlägt eine bereits verworfene Lösung erneut vor, dreht sich im Kreis.

Vergessene Vorgaben

Die Regel von vor einer Stunde („keine neuen Dependencies") gilt plötzlich nicht mehr.

Alte Dateiversionen

Er argumentiert mit einem Stand, den ihr längst geändert habt — die alte Fassung liegt noch im Kontext.

Erfindungen

Methoden und Felder, die es im Projekt nicht gibt. Je voller das Fenster, desto häufiger.

Zähe Antworten

Längere Wartezeiten bei kleiner werdenden Fortschritten.

Themendrift

Er beantwortet eine Frage von vor zehn Schritten statt der aktuellen.

Zwei dieser Symptome hintereinander sind kein Prompt-Problem — sie sind das Signal, die Session zu schneiden.

Gegenmittel — Kontext-Hygiene

1Kurze Sessions pro Aufgabe. Eine Aufgabe, eine Session. Neu anfangen ist ein Werkzeug, kein Scheitern.
2Wichtiges nach vorn oder nach hinten. Dauerhafte Regeln ins Repo (fahren immer am Anfang mit), aktuelle Vorgaben in den letzten Prompt wiederholen.
3Große Ausgaben draußen halten. Volle Testläufe und Logs gehören gefiltert in die Session — oder in einen Subagenten (Modul 8).
4Schriftlicher Übergabepunkt. Vor dem Schnitt Stand und offene Punkte in eine Datei schreiben lassen — dann ist der Reset verlustfrei.
Die Werkzeuge dafür — /compact, /clear, --continue, --resume — behandelt Modul 4 im Detail. Hier zählt die Diagnose, dort die Bedienung.

LLM Knowledge Gaps & Hallucinations

Drei Lücken, ein Symptom

Zeitliche Lücke

Alles nach dem Trainingsstichtag: neue Library-Versionen, geänderte APIs (Modul 1).

Private Lücke

Euer Repo, eure Konventionen, eure Entscheidungen. Nie im Training gewesen.

Situative Lücke

Was in dieser Session nicht im Kontext liegt, existiert für ihn nicht — auch wenn es im Projekt steht.

Alle drei Lücken produzieren dasselbe Symptom: eine flüssige, selbstsichere, plausible und falsche Antwort. Es gibt keinen Tonfall-Unterschied zum richtigen Fall.

Paar 3 — Verifikation erzwingen

VorherAdd rate limiting to POST /bookings. Use the Quarkus annotation for it.
NachherGoal: limit POST /bookings to 10 requests per minute per client. Step 1: check what is actually available in this project. Read pom.xml and list the extensions we already have. Do not assume an annotation exists - name the source (dependency, config key or docs page) for whatever you propose. Step 2: if nothing suitable is present, say so and give me two options with their cost, instead of inventing an API. Only after my decision: implement, plus a test that proves the 11th request within a minute is rejected.

Autoregressive Generierung verstehen

Ein Token nach dem anderen — und jedes zählt

Das Modell erzeugt keine Antwort als Ganzes. Es erzeugt ein Token, hängt es an die Eingabe an und erzeugt daraus das nächste. Autoregressiv heißt: die eigene Ausgabe wird sofort wieder zur Eingabe.

Kontext
Verteilung über
nächstes Token
Token ziehen
anhängen
Zwei Konsequenzen: Ein früh gezogenes falsches Token bleibt stehen und beeinflusst alles Weitere — und ihr könnt die Verteilung nur über den Kontext beeinflussen.

„Make the Next Token Obvious"

Wenn ihr die Fortsetzung nicht erzwingen könnt, macht sie naheliegend. Gebt dem Modell etwas, das nur noch fortgesetzt werden muss:

Vorher — Prosa lässt alles offenWrite a method that checks whether a seminar still has free seats. Make it clean and add a test.
Nachher — Anker statt ProsaImplement exactly this method in BookingService: boolean hasFreeSeats(Long seminarId) Follow the style of the existing method cancelBooking: same transaction handling, same logging, same exception type for "seminar not found". Write the test first, in BookingServiceTest, named hasFreeSeats_returnsFalse_whenSeminarIsFull.
Jeder Anker — Signatur, Nachbarklasse als Muster, Testname — halbiert den Raum der plausiblen Fortsetzungen.

Instruktions-Überladung vermeiden

„Overshooting Prompts"

Der Reflex nach den ersten guten Erfahrungen: „Wenn Kontext hilft, hilft mehr Kontext mehr." Also 15 Anweisungen in einen Prompt. Was tatsächlich passiert:

1–3Die ersten Anweisungen werden erfüllt — sie stehen ganz oben.
4–12Die Mitte verwässert: teilweise erfüllt, teilweise stillschweigend übergangen. Niemand meldet das.
13–15Die letzten Anweisungen werden erfüllt — sie stehen direkt vor der Generierung.
Das ist Lost in the Middle im Kleinen — derselbe Effekt wie beim vollen Fenster, nur innerhalb einer einzigen Nachricht.

Overshooting entschärfen — drei Schnitte

1Zerlegen. Fünfzehn Anweisungen sind meistens drei Aufgaben. Drei Prompts nacheinander schlagen einen Prompt mit fünfzehn Punkten.
2Verlagern. Was in jedem Prompt steht, ist keine Anweisung, sondern eine Konvention — ab damit ins Repo (CLAUDE.md, Modul 7).
3Sortieren. Was übrig bleibt: das Unverzichtbare an den Anfang und als kurze Abnahmeliste ans Ende. Die Mitte trägt nur Details.
Faustregel: Was nicht im Abnahmekriterium steht, wird vermutlich nicht geprüft — weder von ihm noch von euch.

QRSPI-Prinzipien als Prompting-Haltung

QRSPI — die Phasenkette

QFrage — Was ist eigentlich das Problem? Offene Punkte klären, bevor irgendetwas gebaut wird.
RRecherche — Wie ist es heute im Code gelöst? Belegstellen sammeln statt aus dem Gedächtnis argumentieren.
SStructure — Was genau soll gelten? Abnahmekriterien und Struktur schriftlich, bevor es Code gibt.
PPlan — In welchen Schritten? Reviewbar, bevor eine Zeile geändert wird.
IImplement — Erst jetzt Code, gegen eine Struktur, die schon steht.
Questions → Research → Structure → Plan → Implement. Modul 6 ordnet QRSPI im Vergleich zu BMAD und OpenSpec ein — mit derselben Auflösung.

Haltung, nicht Formular

QRSPI ist an dieser Stelle kein Prozess, den man abarbeitet — sondern die Frage, die man sich vor jedem Prompt stellt: „In welcher Phase bin ich gerade?"

Phasen vermischt

„Finde raus, warum das langsam ist, und mach es schneller."

Recherche und Umsetzung in einem Zug — er baut um, bevor irgendwer die Ursache kennt.

Phasen getrennt

„Finde die drei wahrscheinlichsten Ursachen mit Belegstelle. Kein Code."

Danach entscheidet ihr, was spezifiziert und umgesetzt wird.

Der wirksamste Satz in eurem Prompt-Repertoire lautet: „Kein Code, bevor wir uns einig sind."

Modul 3 in fünf Sätzen

1Ein Prompt braucht Ziel, Kontext, Grenzen, Abnahmekriterium und Ergebnisform — nicht Höflichkeit.
2Context Engineering schlägt Prompt-Formulierung: der getippte Text ist der kleinste Teil der Eingabe.
3Lost in the Middle / „Context Rot" ist erkennbar — an Wiederholungen, vergessenen Vorgaben, alten Dateiständen und Erfindungen.
4Autoregressiv heißt: „Make the Next Token Obvious" — Signatur, Muster und Testfall wirken stärker als Prosa.
5„Overshooting Prompts" zerlegen, Dauerregeln ins Repo verlagern, den Rest an Anfang und Ende sortieren.
Alles in diesem Modul folgt aus einem Satz: Das Modell arbeitet mit dem, was im Fenster liegt — und mit sonst gar nichts.

Übung 3 — „Overshooting Prompt" entschärfen

Ausgangsprompt (absichtlich überladen)Please refactor the booking feature in seminar-api. Use constructor injection everywhere. Also add validation. Rename BookingDto to BookingRequest. Make sure a seminar cannot be overbooked. Add javadoc to all public methods. Use records where possible. Also switch the logging to structured logging. Write tests for everything. Update the OpenAPI description. Make sure the code is clean and readable. Don't break anything. Also check if the repository queries are efficient. Add a cancellation endpoint. Use English for all identifiers. And finally update the README.

Aufgabe

1. Lasst den Prompt einmal so in einer frischen Session laufen und protokolliert, welche der Anweisungen tatsächlich umgesetzt wurden.
2. Baut ihn um: zerlegen, Dauerregeln verlagern, sortieren, Abnahmekriterium ergänzen.
3. Lasst die umgebaute Fassung in einer zweiten frischen Session laufen.

Verifizierbares Ergebnis: Eine Gegenüberstellung mit Erfüllungsquote vorher/nachher (wie viele der Anweisungen wurden nachweislich umgesetzt) plus eine schriftliche Begründung, was ihr entfernt, verlagert oder umgestellt habt — und warum.

Dauer ca. 30 Minuten · 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 3 · v0.1.0