1. Ein- und Ausgabe im Terminal, nicht im Browser.
2. Zugriff auf alle Dateien im aktuellen Projektverzeichnis.
3. Führt Systembefehle aus — generisch alles, was auch eure Shell kann: git, ls, grep, mvn (wie das technisch abläuft: Modul 1).
4. Liest eine eigene Projektstruktur: CLAUDE.md, .claude/ (Kapitel 5, Modul 2).

1. Wegwerf-Verzeichnis anlegen und hineinwechseln.
2. claude starten — beim ersten Aufruf folgt die Anmeldung, danach die Workspace-Trust-Abfrage zum Verzeichnis.
3. Die beiden Prompts rechts absetzen. Claude Code führt dafür Befehle aus und fragt vorher um Freigabe.
4. Antworten vergleichen: Was davon hat das Werkzeug nachgesehen — und was angenommen?
5. Session offen lassen — die folgenden Folien bauen darauf auf.

1. Am einfachsten: /statusline mit einer Beschreibung — Claude Code erzeugt das Skript und trägt es in die Settings ein.
2. Manuell: ein statusLine-Feld in den Settings, type: "command", das ein Skript aufruft.
3. Das Skript bekommt Session-Daten als JSON auf stdin und druckt die Zeile.
4. Pro Projekt übersteuerbar: dieselbe Angabe in .claude/settings.json im Projekt sticht die persönliche aus ~/.claude/.

1. claude — interaktive Session; -p/--print — einmalige Ausgabe (Skript/CI).
2. -c/--continue, -r/--resume — letzte bzw. gewählte Session fortsetzen.
3. --model, --add-dir, --permission-mode, --agent.
4. Unterbefehle: claude mcp, plugin, agents, doctor, update.

1. Task — eine Arbeitseinheit der laufenden Sitzung. /tasks oder Ctrl+T zeigt die Liste.
2. Subagent (/subtask) — Teilaufgabe in eigenem Kontext, erbt die Unterhaltung. Ihr wartet, zurück kommt nur das Ergebnis.
3. /fork dupliziert — erbt die Unterhaltung, blockiert nicht: die Kopie läuft ab, ihr arbeitet hier weiter.
4. /bg verschiebt — diese Sitzung geht in den Hintergrund und gibt das Terminal frei.
5. claude --bg startet frisch — neue Sitzung, nur euer Auftrag, keine Vorgeschichte.

Gefahren wird hier einer: /loop — weil man ihm beim Wachsen zusehen kann.

1. Was beobachtet wird — Datei, Kommando oder Endpunkt.
2. Wann er stören soll. Der Filter ist der eigentliche Entwurf: jede gemeldete Zeile wird zu einer Nachricht in eurem Kontext.
3. Wie lange — „für die ganze Sitzung" hält ihn dauerhaft; sonst endet er mit dem Skript, spätestens an der Zeitgrenze.

Nachsehen mit /tasks, beenden mit „stopp den Monitor".

1. In der Session: /model öffnet den Picker. Beim Start: claude --model <name>.
2. Die Familien: Opus (gründlich), Sonnet (Balance), Haiku (schnell/günstig), Fable.
3. Faustregel: mechanische Kleinaufgabe — schnelles Modell; schwierige Analyse/Architektur — gründliches.
4. Zweite Stellschraube: /effort setzt, wie gründlich das Modell nachdenkt (low bis max) — unabhängig vom Modell.
5. Aktuelle Generationen & Spezifikationen: Modul 1.

1. /context — zeigt als farbiges Raster, was das Fenster gerade füllt. Welche Blöcke das im Einzelnen sind: Modul 3.
2. /status — Session-Status (Modell, Verzeichnis, Kontext) auf einen Blick.
3. /usage (alias /cost) — Verbrauch und Kosten der Session.
4. Die Context-% in der Statusleiste — dauerhaft sichtbar (siehe Statusleisten-Folie).
5. Läuft es voll: /compact (kürzen) oder /clear (neu) — gegen „Context Rot".

1. Das Modell hat kein Gedächtnis zwischen Anfragen. Jede Anfrage enthält System-Prompt, Projektkontext und den ganzen Verlauf.
2. Der unveränderte Anfang dieser Anfrage wird aus dem Cache gelesen — deutlich schneller und rund 90 % günstiger als frischer Input.
3. Deshalb ist ein Modellwechsel mitten in der Arbeit teuer: der ganze Verlauf wird einmal neu verarbeitet. Verloren geht dabei nichts — der Kontext bleibt vollständig, er wird nur nicht mehr aus dem Cache gelesen.
4. Faustregel: Modell am Anfang wählen, /compact an der Aufgabengrenze — nicht mittendrin.

1. Modi (--permission-mode): manual, acceptEdits, auto, plan, bypassPermissions, dontAsk.
2. Plan Mode (/plan): erst denken und planen, kein Code — Freigabe, dann Umsetzung.
3. Regeln mit /permissions setzen, statt jede Aktion einzeln zu bestätigen.

1. Regelform Tool(Muster) — z. B. Read(**), Bash(git *), Bash(*DROP DATABASE*).
2. Sicher arbeiten: Lesen, Schreiben, Bauen/Testen erlauben — das ist reversibel.
3. Verbieten, was nicht rückholbar ist: Datei-Löschen, Force-Push, DB-Drop, Massen-Löschen, Exfiltration (curl zu Fremd-Diensten).
4. deny sticht allow — die Denylist schützt selbst im freien Modus.

1. Liste vs. Hook: allow/deny matcht Muster; ein PreToolUse-Hook sieht den vollen Tool-Input und entscheidet mit Logik.
2. Für Kontextabhängiges: „docker compose down -v nur gegen Prod blocken", „Edits außerhalb des Scopes verbieten".
3. exit 2 blockt den Call; die stderr-Meldung wird dem Modell als Begründung gezeigt.

1. Credentials liegen im User-Home: SSH-Keys (~/.ssh), Cloud-Tokens (~/.aws), Umgebungsvariablen — nie im Repo, nie eingecheckt.
2. Der Agent kann darauf zugreifen wie ihr — darum die Denylist gegen gefährliche/exfiltrierende Befehle (Modul 8).
3. Secrets gehören nicht in Prompts — alles im Kontext fährt bei jedem Schritt mit.

1. Ein Ordner je Projekt, eine Datei je Session — benannt nach der Session-Kennung.
2. Je Zeile ein Ereignis: Frage, Antwort, Werkzeug-Aufruf, Werkzeug-Ergebnis.
3. Je Antwort die Abrechnung: Modell, verbrauchte Tokens, Cache-Anteil, Zeitstempel.
4. Dieselbe Datei liest --resume wieder ein — sie ist die Session.

1. Persönliche Claude-Config: .claude/settings.local.json (die Team-settings.json wird dagegen eingecheckt).
2. Secrets & Credentials: .env, *.pem, Token-Dateien.
3. Lokale/Build-Artefakte: target/, node_modules/, Logs.

1. CLAUDE.md — Dauerwissen, fährt bei jedem Aufruf mit (Modul 7).
2. .mcp.json — MCP-Server des Projekts (Modul 8b).
3. .claude/ — die Konfiguration: Team- und persönliche Settings + die Primitive.