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.
- Prompts strukturieren — dem Auftrag Ziel, Kontext, Grenzen und Abnahmekriterium mitgeben, statt nur zuzurufen.
- Kontext gezielt auswählen (das meint „kuratieren") — nur reingeben, was die Aufgabe braucht; nicht alles, was reinpasst.
- Qualitätsverfall erkennen — merken, wenn ein volles Context-Window die Antworten verschlechtert, und rechtzeitig gegensteuern.
Das dritte Können ist das teuerste: ein volles Fenster ist ein Qualitäts-Problem, nicht nur ein Kostenproblem — und die meisten Teams lernen es nie.
Prompt-Strukturierung
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 Claude Code?
Randbedingungen
Was Claude Code 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 das Modell.
Prüffrage: Könnte ein neuer Kollege mit genau diesem Text loslegen, ohne zurückzufragen? Wenn nein, fehlt einer der fünf Bausteine.
Kopierfertiges Gerüst dieser fünf Bausteine: Anhang · Vorlagen · Prompt-Templates
Paar 1 — vom Zuruf zum Auftrag
Derselbe Auftrag als Zuruf und als strukturierter Prompt — die fünf Bausteine machen aus „fix it" einen ausführbaren 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; capacity on Seminar.maxSeats; suspected race on the last seat.
Constraints: keep the REST contract, no new dependencies, stay in the booking package.
Acceptance: a new test that fails on main and passes after the fix; `mvn test` green.
Output: short diagnosis first (max 10 lines, file:line), then wait for my OK.
Alle fünf Bausteine drin: Goal=Ziel · Context=Kontext · Constraints=Grenzen · Acceptance=Abnahme · Output=Ergebnisform.
Der Prompt darf länger sein als die Aufgabe
- Ergebnis vor Tätigkeit — „Ein Seminar darf nicht überbucht werden" schlägt „prüf mal die Kapazität".
- Einstiegspunkt nennen — eine Klasse, ein Endpoint, ein Testname: das spart Claude Code zehn Suchläufe und euch die Tokens dafür.
- Negative Grenzen setzen — „Nicht das Schema ändern" verhindert mehr Schaden als drei positive Wünsche.
- Zwischenstopp 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
Die aktuelle Eingabe der Benutzerin (der Prompt) ist nur ein Teil des Input-Context-Arrays.
Neben dem System-Prompt und dem Inhalt der CLAUDE.md werden die gesamte Chat-Historie sowie gelesene Dateien und Dokumente mitgesendet.
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.
Was wirklich im Kontextfenster liegt
System-Prompt und CLAUDE.md sind nur der Anfang: sieben Blöcke laden automatisch, bevor ihr das erste Wort tippt — und der Rest wächst beim Arbeiten dazu.
beim Start — automatisch
System-Prompt + Werkzeug-Definitionen
Umgebung: Verzeichnis, OS, Shell, Git-Branch
Skill-Katalog — je Skill eine Zeile
MCP-Werkzeuge — nur die Namen, Schemas auf Abruf
Projekt-CLAUDE.md
persönliche ~/.claude/CLAUDE.md
Auto-Memory: Notizen aus früheren Sessions
während der Arbeit — wächst
euer Prompt
gelesene Dateien, Grep-Treffer
Tool-Ausgaben: Tests, Builds, Logs
Regeln, die beim Anfassen einer Datei laden
Hook-Ausgaben
Ergebnis eines Subagenten — nur dessen Zusammenfassung
frei
Nicht schätzen — nachsehen: /context zeigt die aktuelle Aufteilung als farbiges Raster, inklusive der Frage, welche CLAUDE.md-Dateien tatsächlich geladen wurden.
checked am 2026-07-26 gegen code.claude.com/docs/context-window
Wie Kontext hineinkommt
Ihr liefert
Dateien nennen, Ausschnitte einfügen, Fehlermeldung reinkopieren. Präzise, aber Handarbeit.
Claude Code 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.
Paar 3 — was das Repo schon weiß
Derselbe Auftrag an seminar-api — einmal in einem Repo ohne CLAUDE.md, einmal mit.
Der Unterschied ist genau das Dauerwissen.
ohne CLAUDE.mdGoal: GET /api/kunden?firma=<name> filters customers by company.
Build and test with mvn test. Java 21, Quarkus.
REST classes live in at.cgs.training.seminar.api, DTOs are records in api/dto.
Every query is bound to the tenant from the X-Mandant header (default cgs).
Go through KundeRepository, never the EntityManager.
A record of another tenant answers 404, not 403.
Errors go through an ExceptionMapper, not a raw 500.
Tests are @QuarkusTest with RestAssured, one class per resource.
Acceptance: mvn test green, including a test for the tenant case.
mit CLAUDE.md und Skill im RepoGoal: GET /api/kunden?firma=<name> filters customers by company.
Constraint: the filter must not widen the tenant scope.
Acceptance: a test proving a customer of another tenant is not returned.
Was im Repo steht, muss nicht mehr in den Prompt — übrig bleibt, was nur für diese eine Aufgabe gilt: Auftrag, Randbedingung, Abnahmekriterium.
Context Window & Context Degradation
Das Fenster ist eine Obergrenze — kein Ziel
Jedes Modell hat ein maximales Fenster in Tokens — und dazu sind zwei Missverständnisse 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.
checked am 2026-07-21 gegen Doku
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
Claude Code 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
Das System 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
Claude Code 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.
Kontext-Hygiene
- Kurze Sessions pro Aufgabe — eine Aufgabe, eine Session. Neu anfangen ist ein Werkzeug, kein Scheitern.
- Wichtiges nach vorn oder nach hinten — dauerhafte Regeln ins Repo (fahren immer am Anfang mit), aktuelle Vorgaben in den letzten Prompt wiederholen.
- Große Ausgaben draußen halten — volle Testläufe und Logs gehören gefiltert in die Session, oder in einen Subagenten (Modul 8).
- Erst schreiben, dann schneiden — was in einer Datei steht, muss der Verlauf nicht mehr tragen. Das Artefakt macht den Reset verlustfrei (Modul 5 und 6).
Die Werkzeuge dafür — /compact, /clear, --continue, --resume — behandelt Modul 4 im Detail.
Hier zählt die Diagnose, dort die Bedienung.
Jeder Turn schickt alles mit — bezahlt wird das Neue
Die Schnittstelle ist zustandslos: bei jedem Schritt geht die komplette Eingabe erneut ans Modell.
Neu verarbeitet wird trotzdem nur, was sich seit dem letzten Schritt geändert hat.
System & Tools
CLAUDE.md
Verlauf bisher
neuer Prompt
aus dem Cache gelesen — rund 90 % günstigerneu
- Verglichen wird der Anfang der Anfrage — das Präfix. Stimmt es mit dem zuletzt Verarbeiteten überein, wird es aus dem Cache gelesen statt neu berechnet.
- Der Vergleich ist exakt und von vorne: eine Änderung weit vorne entwertet alles, was dahinter liegt.
- Deshalb ordnet Claude Code die Eingabe nach Änderungshäufigkeit: selten Wechselndes zuerst, der neue Prompt zuletzt.
- Es gibt kein Caching pro Datei oder pro Abschnitt — nur diese eine Präfix-Übereinstimmung zählt.
Das ist der technische Grund für „Stabiles nach vorn": Dauerhaftes gehört ins Repo (CLAUDE.md, Regeln), nicht in die Mitte einer Session — sonst wird es in jedem Schritt neu bezahlt.
checked am 2026-07-25 gegen code.claude.com/docs/prompt-caching
Was den Cache zerreißt
Alles, was am Anfang der Anfrage etwas ändert, macht den nächsten Schritt einmalig langsam und teuer.
Alles, was nur hinten anhängt, kostet nichts extra.
Zerreißt das Präfix
/model — jedes Modell hat einen eigenen Cache.
Andere Aufwandsstufe (/effort), Fast Mode einschalten.
MCP-Server verbinden oder trennen (bei fest geladenen Werkzeugen).
Ein ganzes Werkzeug per deny-Regel sperren.
/compact und ein Update von Claude Code.
Hängt nur hinten an
Dateien im Projekt bearbeiten — Claude Code liest bei Bedarf neu.
Skills und Commands aufrufen, Plan Mode, Permission-Modus wechseln.
/rewind — springt auf ein Präfix zurück, das schon im Cache liegt.
CLAUDE.md bearbeiten — wirkt dafür erst nach Neustart oder /clear.
Praxisregel: Modell und Aufwandsstufe am Anfang festlegen, /compact an der Aufgabengrenze — nicht mitten in der Arbeit.
checked am 2026-07-25 gegen code.claude.com/docs/prompt-caching
Wie lange der Cache hält
Der Cache verfällt nur durch Untätigkeit.
Jeder Treffer setzt die Uhr zurück — teuer ist immer nur die erste Nachricht nach einer Pause.
- Wie lang die Pause sein darf, hängt am Zugang: im Abo fordert Claude Code automatisch eine Stunde an, mit API-Key oder bei Cloud-Anbietern sind es fünf Minuten.
- Umstellbar über Umgebungsvariablen — auch organisationsweit über die verwalteten Einstellungen.
- Ob es funktioniert, zeigen zwei Zahlen je Antwort: viel gelesen und wenig geschrieben ist gut. Dauerhaft hohes Schreiben heißt: vorne ändert sich ständig etwas.
- Sichtbar machen: eigene Statusleiste oder
/usage.
# Lebensdauer erzwingen (settings.json, env)
ENABLE_PROMPT_CACHING_1H=1 # 1 Stunde
FORCE_PROMPT_CACHING_5M=1 # 5 Minuten
# Kennzahlen je Antwort
cache_read_input_tokens # aus dem Cache
cache_creation_input_tokens # neu geschrieben
Ein Subagent baut seinen eigenen Cache auf und belastet euren nicht — noch ein Argument, große Wühlarbeit dorthin auszulagern (Modul 8).
checked am 2026-07-25 gegen code.claude.com/docs/prompt-caching
LLM Knowledge Gaps & Hallucinations
Drei verschiedene Lücken erzeugen ein und dasselbe 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 das Modell nicht — auch wenn es im Projekt steht.
Alle drei Lücken produzieren dasselbe Symptom: eine flüssige, selbstsichere, plausible und falsche Antwort.
Paar 4 — 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
Autoregressiv heißt: das Modell erzeugt ein Token nach dem anderen — und 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" — packt 15 Anweisungen in einen Prompt.
Was tatsächlich passiert:
- Anweisung 1–3 — die ersten werden erfüllt: sie stehen ganz oben.
- Anweisung 4–12 — die Mitte verwässert: teilweise erfüllt, teilweise stillschweigend übergangen. Niemand meldet das.
- Anweisung 13–15 — die letzten 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
- Zerlegen — fünfzehn Anweisungen sind meistens drei Aufgaben. Drei Prompts nacheinander schlagen einen Prompt mit fünfzehn Punkten.
- Verlagern — was in jedem Prompt steht, ist keine Anweisung, sondern eine Konvention: ab damit ins Repo (
CLAUDE.md, Modul 7).
- Sortieren — 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 vom Modell 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.
QRSPI: vom Prompt zum Workflow
QRSPI (ein offener Community-Workflow) verlässt den einzelnen Prompt: es ist ein Workflow über mehrere Prompts — jede Phase hält ihr Zwischenergebnis als Markdown-Artefakt fest.
- Mehrere Prompts statt einem Mega-Prompt: Q, R, S, P, I sind eigene Schritte, oft eigene Sessions — „control flow, not prompts".
- Artefakt pro Phase: das Zwischenergebnis wird als Markdown gespeichert (z. B.
research.md, spec.md, plan.md) — die nächste Phase startet daraus, nicht aus einem vollen Fenster.
- Das wirkt gegen „Context Rot": statt alles in ein wachsendes Kontextfenster zu stopfen, hält jede Phase nur, was sie braucht — die direkte Antwort auf den Context-Window-Teil dieses Moduls.
# jede Phase -> ein Artefakt
Q questions.md
R research.md (Subagent)
S spec.md (Design-Gate: 0 Code)
P plan.md
I Code + Tests
# Start je Phase aus dem Artefakt,
# nicht aus vollem Kontext
In Claude Code: Plan Mode + Recherche im Subagenten (sauberer Kontext).
Modul 5 baut daraus den vollen Gate-Workflow, Modul 6 vergleicht QRSPI mit BMAD und OpenSpec.
checked am 2026-07-24 gegen cgsit-finance
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 — Claude Code 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
- Ein Prompt braucht Ziel, Kontext, Grenzen, Abnahmekriterium und Ergebnisform — nicht Höflichkeit.
- Context Engineering schlägt Prompt-Formulierung: der getippte Text ist der kleinste Teil der Eingabe — und diese Eingabe fährt bei jedem Schritt komplett mit.
- Lost in the Middle / „Context Rot" ist erkennbar — an Wiederholungen, vergessenen Vorgaben, alten Dateiständen und Erfindungen.
- Autoregressiv heißt: „Make the Next Token Obvious" — Signatur, Muster und Testfall wirken stärker als Prosa.
- „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 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.11.5
