Ship Codex-parity harness, chapter polish, and rebuilt PDF.

Add reader vorlagen (permissions, MCP, hooks, plugins, team AGENTS), humanizer skill, and adaptionen for ki-codex; refresh chapters 00–18, resource-path justfile, and dist PDF with full illustration set.
2026-08-02 21:19:46 +02:00
1 parent 80e5838432
commit 17a2bc8a45
@@ -9,8 +9,8 @@ description: Überblick über Buch-Repo-Status — Kapitel, Pipeline, Agent-Harn
 3. **Artefakte:** existiert `dist/grok-build-praxisleitfaden.pdf`? (nur melden, nicht neu bauen)
 4. **Autoren-Harness:**
   - `AGENTS.md`, `CLAUDE.md`, `ADAPTIONEN.md`
-   - `.grok/rules|skills|commands`
-5. **Leser-Content:** `vorlagen/`, `beispiele/` kurz bestätigen
+   - `.grok/rules|skills|commands` (Skills u. a. `lektorat`, `kapitel-review`, `pdf-bauen`, `humanizer`, `update-pics`)
+5. **Leser-Content:** `vorlagen/` (AGENTS, config, hooks, skills, plugins), `beispiele/` kurz bestätigen

 Ausgabe als Tabelle:

@@ -45,7 +45,7 @@ Ergänzt `AGENTS.md` um detaillierte Schreib-, Ton- und Formatierungsregeln für
 | Headless | nicht-interaktiver Lauf | interaktive TUI |
 | ACP | Agent Client Protocol | reines Headless `-p` |

-Stand der Fakten im Buch: **Juli / Mitte 2026**. UI-Labels und einzelne Config-Felder können driften; stabile Konzepte erklären.
+Stand der Fakten im Buch: **Juli–Aug 2026** (CLI **0.2.x**). UI-Labels und einzelne Config-Felder können driften; stabile Konzepte erklären.

 ---

@@ -81,6 +81,16 @@ Stand der Fakten im Buch: **Juli / Mitte 2026**. UI-Labels und einzelne Config-F
 - 1–2 Frage-Überschriften pro Kapitel, wo der Leser sucht.
 - Kapitel 18 (Schnellreferenz) und Symptom→Fix-Raster: Tabellen sind Feature.

+### Reprise (Kernprinzipien)
+
+Vier Hebel tauchen spiralig auf: **Scope eng**, **Diff lesen**, **Deny / enge Allowlist vor Always-approve**, **AGENTS.md (weich) vs. Permissions/Hooks/Sandbox (hart)**.
+
+- **Kanon** (erster Lehrort): volle Erklärung behalten.
+- **Nützliche Reprise** am Gelenk: 1 Satz + Brücke („schon gehört, hier weil …“ / Verweis auf Kanon) und *neuen* Aspekt behalten.
+- **Echo ohne Mehrwert** (vor allem *innerhalb* desselben Kapitels): streichen oder auf Verweis kürzen.
+- Max. **2–3** explizite Reprise-Signale pro Kapitel; Checklisten und „Was du jetzt kannst“ ohne Meta-Sprüche.
+- Schnellreferenz (Kap. 18): knappe Lookup-Zeilen, **keine** Brücken-Sprüche.
+
 ### Abschlüsse

 - Größere Abschnitte: Checkliste, häufige Fehler, „So baust du das nach“.
@@ -92,6 +102,7 @@ Stand der Fakten im Buch: **Juli / Mitte 2026**. UI-Labels und einzelne Config-F
 - Feature-Kapitel (Plan, Subagents, …): **2–4 realistische Sessions**.
 - Platzhalter: `YOUR_TOKEN`, `your-project`, `xai-…`.
 - Terminal-Sessions und Configs lauffähig und kommentiert halten.
+- Häufiges Basisbeispiel: `beispiele/todo-cli/`.

 ---

@@ -0,0 +1,177 @@
+---
+name: humanizer
+description: >
+  Analysiert Text auf typische KI-Stilmuster und liefert begründete Vorher/Nachher-Vorschläge
+  für eine menschlichere Stimme (Rhythmus, Floskeln, Epistemik, Spezifität). Keine automatischen Edits.
+  Nutzen bei: „humanizer“, „menschlicher machen“, „KI-Stil entfernen“, „klingt zu generisch / roboterhaft“,
+  „zu glatt formuliert“, „Floskeln raus“, /humanizer.
+---
+
+# Humanizer — KI-Stil → menschliche Stimme
+
+Checkpoint-basierte Stilanalyse. **Report mit begründeten Vorschlägen**, keine stillen Textänderungen.
+
+Referenzkatalog: `.grok/skills/humanizer/references/marker-katalog.md` (bei Bedarf mitlesen).
+
+## Prinzipien
+
+1. Zuerst lesen, dann urteilen — nicht nur Keyword-Scannen.
+2. Jeder Fund: **Muster + Warum + Vorher/Nachher**.
+3. Keine Detektor-Prozente, keine Urheber-Behauptung — nur editierbare Stilmerkmale.
+4. Keine künstlichen Tippfehler, kein Slang-Spam, kein Detektor-Gaming.
+5. Inhaltliche Fakten **nicht erfinden**, um „spezifischer“ zu klingen.
+6. Standard: nur Chat-Report. Edits **nur** auf explizite Freigabe, chirurgisch.
+
+### Leitprinzipien der Humanisierung
+
+| # | Prinzip | Wirkung |
+|---|---------|---------|
+| 1 | Rhythmus variieren (Burstiness) | Kurze und lange Sätze mischen; Absätze ungleich gewichten |
+| 2 | Floskeln und Werbelexik streichen | Konkrete Wörter statt Buzz |
+| 3 | Spezifität | Szenen, Configs, Zahlen, echte Tradeoffs statt Prototypen |
+| 4 | Epistemische Ehrlichkeit | Grenzen, Unsicherheit, echte Einwände |
+| 5 | Asymmetrie | Wichtiges länger, Nebensächliches knapper |
+| 6 | Stimme | Aktiver Kollege, nicht Pressemitteilung |
+
+### Was „menschlicher“ *nicht* heißt
+
+- Nicht: salopp um jeden Preis oder „natürlich“ = umgangssprachlich.
+- Nicht: Buch-Ton brechen (bei Manuskript: erfahrener Kollege, präzise, ohne Hype — `schreibkonventionen.md`).
+- Nicht: Callouts umbauen (`Kern` / `Achtung` / `Jetzt selbst machen`).
+- Stark redigierte Fachprosa teilt oft niedrige Burstiness mit KI — **Stimme und Nutzen** priorisieren, nicht „detektor-unsichtbar“.
+
+## Abgrenzung
+
+| Skill | Fokus |
+|-------|--------|
+| `lektorat` | Ton, Fakten, Terminologie, Wiederholungen, Erklärungsdichte, Callouts |
+| `kapitel-review` | Argumentation, Lesefluss, Substanz, Positionierung |
+| **`humanizer`** | KI-typische Stilmarker → menschliche Stimme |
+
+Humanizer ersetzt weder Fakten-Check noch Argumentations-Review. Bei Konflikt mit Buch-Konventionen gewinnt `schreibkonventionen.md` / `AGENTS.md`.
+
+## Vorbereitung
+
+1. **Input klären:** Kapitel (`00`–`18` / Dateiname), markierter Abschnitt, oder Inline-Text. Bei Unklarheit nachfragen.
+2. **Zielstimme** (Default):
+   - Manuskript / `vorlagen/` / Buch-Kontext → **Buch-Kollege** (erfahren, präzise, Du-Ansprache, kein Hype)
+   - Sonst → **Sachprosa DE** (klar, konkret, ohne Werbeton)
+3. Text **vollständig** lesen (Datei: `read_file`). Bei sehr langen Kapiteln: mit User abschnittsweise oder Fokus-Abschnitt wählen.
+4. Marker-Katalog bei Bedarf öffnen: `references/marker-katalog.md`.
+
+## Checkpoints (der Reihe nach)
+
+### 1. Lexik & Floskeln
+
+- Buzz-Adjektive, Superlative ohne Beleg, stereotype Verben (siehe Katalog HIGH/MED)
+- Co-Occurrence: mehrere Marker nahe beieinander = stärkeres Signal als ein einzelnes Wort
+- Nominalisierungs-Stapel und Partizipialketten, die den Satz aufblähen
+
+→ Jeden Treffer mit Vorschlag konkretisieren oder streichen.
+
+### 2. Übergänge & Meta-Rhetorik
+
+- Absatzanfänge: „Darüber hinaus“, „Ferner“, „Zudem“, „Ein weiterer wichtiger Aspekt …“
+- Ankündigungen ohne Nutzen: „Im Folgenden wird …“, „Es ist wichtig zu betonen …“
+- Mechanische Parallelismen und immer gleiche Konnektoren
+
+→ Übergang streichen, implizit machen oder mit Inhalt ersetzen.
+
+### 3. Rhythmus (Burstiness)
+
+- Satzlängen über 5–10 Sätze hinweg: monoton ≈ KI-Nähe
+- Absätze alle ~gleich lang
+- Listen statt Prosa, wo ein Satz reichte — oder umgekehrt: Prosa-Wand ohne Atem
+
+→ Mindestens 1–2 Vorher/Nachher mit bewusster Längen-Varianz vorschlagen.
+
+### 4. Struktur-Symmetrie
+
+- Gleich gewichtete Unterabschnitte („drei Punkte à drei Sätze“)
+- Tricolon-Zwang (immer genau drei Aufzählungen)
+- Ungebetene Mini-Fazits am Ende jedes Blocks („Zusammenfassend …“)
+
+→ Asymmetrie vorschlagen: Kern länger, Rest kürzen oder streichen.
+
+### 5. Epistemik & Stimme
+
+- Phantom-Autorität: „Studien zeigen“, „Experten sind sich einig“ ohne Name/Quelle
+- Pauschale Sicherheit ohne Bedingungen; oder leeres Hedging überall
+- Keine echten Zugeständnisse / Tradeoffs
+- Pressemitteilungs-Ton statt Kollege mit Position
+
+→ Grenzen, „wann gilt das nicht“, konkrete Alternativen — ohne Fakten zu erfinden.
+
+### 6. Spezifität
+
+- Generische Beispiele (Café-WLAN, „die App“, „das Team“)
+- Abstrakte Nutzen-Sätze ohne greifbaren Nachvollzieh-Schritt
+- Im Buch-Kontext: fehlt ein Terminal-/Config-Anker, wo er hingehört?
+
+→ Spezifischer vorschlagen **nur** aus Kontext des Textes oder bekannten Repo-Beispielen; sonst markieren „braucht Autor-Detail“.
+
+### 7. Buch-Guardrails (nur Manuskript / Leser-Vorlagen)
+
+- Callout-Marker und Blockquote-Struktur intakt lassen
+- Terminologie einheitlich: Harness, `AGENTS.md`, `config.toml`, Plan Mode, Permissions, MCP, Skills, Hooks, Subagents, Worktrees, Headless, ACP
+- Claude-/Codex-Jargon nicht in Grok-Kapitel mischen (Ausnahme: Kapitel 17, wo der Vergleich Thema ist)
+- Keine Secrets; Platzhalter bleiben (`YOUR_TOKEN`, `your-project`, `xai-…`)
+- Vorschläge dürfen den Ton „erfahrener Kollege“ nicht in Marketing oder Belehrung kippen
+
+## Ausgabeformat
+
+```text
+## Humanizer: [Quelle]
+**Datum:** [heute]
+**Zielstimme:** [Buch-Kollege | Sachprosa | …]
+**Scope:** [z. B. ganzes Kapitel / Abschnitte X–Y / ~N Absätze]
+
+### Gesamteindruck (2–4 Sätze)
+KI-Nähe grob: niedrig | mittel | hoch — Begründung (Muster, nicht Prozent).
+
+### Funde (priorisiert)
+
+**P0 — stark KI-typisch / stört Lesbarkeit:**
+- **Stelle:** „…“ (Kontext: …)
+- **Muster:** [Lexik | Übergang | Rhythmus | Struktur | Epistemik | Spezifität]
+- **Warum:** …
+- **Vorschlag:**
+  - Vorher: …
+  - Nachher: …
+- **Nebenwirkung:** [optional]
+
+**P1 — sollte:**
+…
+
+**P2 — Feinschliff:**
+…
+
+### Muster-Statistik (kurz)
+- Floskeln / Übergänge: N | Rhythmus: … | Epistemik: … | Struktur: … | Spezifität: …
+
+### Top-3 Sofortmaßnahmen
+1. …
+2. …
+3. …
+```
+
+### Priorisierung & Menge
+
+- **P0:** max. ~8 Einzelvorschläge; wiederkehrende Muster als „Muster X tritt N-mal auf“ + 1–2 exemplarische Rewrites
+- **P1/P2:** Rest; kein romanlanger Fundkatalog
+- Jeder P0/P1-Eintrag braucht Vorher/Nachher (außer bei reinem Streichen: Nachher = leer / Hinweis „streichen“)
+
+## Nach dem Lauf
+
+- Standard: Report in der Chat-Antwort; Datei nur auf Wunsch.
+- **Nur freigegebene** Funde umsetzen; keine Drive-by-Edits.
+- Bei „setz alles um“: trotzdem Checkpoint für riskante Stellen (Inhalt, Callouts, Fakten).
+- Optional: User fragen, ob danach `lektorat` oder `kapitel-review` sinnvoll ist.
+
+## Anti-Patterns (Agent)
+
+- Ganzen Text in einem Rutsch umschreiben ohne Scope
+- „Humanizer-Slang“ (übertriebene Umgangssprache, Memes)
+- Fakten, Quellen oder Config-Flags erfinden
+- Callout-Labels „verschönern“ oder umbenennen
+- Detektor-Scores oder „das ist 87 % KI“ behaupten
@@ -0,0 +1,177 @@
+# Marker-Katalog — KI-Stil vs. menschliche Stimme
+
+Nachschlagewerk für den Skill `humanizer`. Stand der Stilforschung/Praxis: 2025/2026.  
+**Kein** Detektor und **kein** Urheber-Beweis — nur editierbare Muster.
+
+Schwere:
+
+| Stufe | Bedeutung |
+|-------|-----------|
+| **HIGH** | Oft Co-Occurrence-Signal; bei Häufung prioritär (P0) |
+| **MED** | Unauffällig allein; problematisch in Clustern oder am Absatzanfang |
+| **LOW** | Nur bei Monotonie/Übernutzung melden |
+
+---
+
+## 1. Deutsch — Konnektoren & Meta-Rhetorik
+
+| Marker / Muster | Schwere | Gegenmittel |
+|-----------------|---------|-------------|
+| Darüber hinaus / Ferner / Zudem (Absatzanfang) | HIGH | Streichen; Inhalt direkt; „Außerdem“ sparsam |
+| Ein weiterer wichtiger Aspekt ist … | HIGH | Aspekt nennen und erklären, Ankündigung weg |
+| Es ist wichtig zu betonen / festzuhalten … | HIGH | Behauptung + Begründung, ohne Meta |
+| Im Folgenden wird … / Nachfolgend betrachten wir … | HIGH | Direkt starten |
+| Zusammenfassend lässt sich sagen / Insgesamt zeigt sich | HIGH | Fazit nur am Kapitelende oder weglassen |
+| Nicht nur … sondern auch … (seriell) | MED | Eine Aussage genügt oft |
+| Insbesondere / Grundsätzlich / Letztendlich / Zweifellos | MED | Konkretisieren oder streichen |
+| In diesem Zusammenhang / Vor diesem Hintergrund | MED | Bezug im Satz selbst herstellen |
+
+### Vorher → Nachher
+
+```text
+Vorher: Darüber hinaus ist es von entscheidender Bedeutung, innovative Lösungen
+        nahtlos zu implementieren.
+Nachher: Neue Lösungen müssen ohne Extra-Reibung in den bestehenden Ablauf passen.
+
+Vorher: Im Folgenden wird erläutert, wie Permissions greifen.
+Nachher: Permissions greifen so:
+
+Vorher: Zusammenfassend lässt sich sagen, dass ein enger Scope Risiken senkt.
+Nachher: Enger Scope senkt Risiken — das war der Punkt.
+```
+
+---
+
+## 2. Deutsch — Buzz-Lexik & Werbeton
+
+| Marker | Schwere | Gegenmittel |
+|--------|---------|-------------|
+| nahtlos, ganzheitlich, maßgeschneidert | HIGH | Was genau passiert / fehlt? |
+| zukunftsorientiert, bahnbrechend, beispiellos | HIGH | Streichen oder mit Beleg ersetzen |
+| innovativ, dynamisch, robust, skalierbar (ohne Kontext) | MED | Technische Konkretion |
+| facettenreich, essenziell, hochwertig, effizient | MED | Warum / für wen? |
+| Paradigmenwechsel, Gamechanger, Best Practice | HIGH | Sachverhalt benennen |
+| nutzen / nutzen Sie die Kraft von … | MED | Verb mit Objekt: was *tut* man? |
+
+```text
+Vorher: Eine ganzheitliche, maßgeschneiderte Strategie ermöglicht nahtlose Workflows.
+Nachher: Eine kurze Deny-Liste und ein enger Working-Directory-Scope reichen oft,
+         um destruktive Tool-Calls abzufangen.
+```
+
+---
+
+## 3. Epistemik & leere Autorität
+
+| Muster | Schwere | Gegenmittel |
+|--------|---------|-------------|
+| Studien zeigen / Forschung belegt (ohne Quelle) | HIGH | Quelle nennen oder Behauptung abschwächen/streichen |
+| Experten sind sich einig … | HIGH | Wer? Sonst streichen |
+| Es ist klar, dass / Zweifellos | MED | Bedingungen nennen |
+| Immer / nie / jeder / optimal (Absolutismen) | MED | Scope der Aussage eingrenzen |
+| Kein Tradeoff, kein „wann gilt das nicht“ | MED | Einen echten Einwand einbauen |
+| Leeres Hedging überall („könnte ggf. möglicherweise“) | MED | Entweder klar oder mit konkreter Unsicherheit |
+
+```text
+Vorher: Studien zeigen, dass gut strukturierte Prompts die Qualität deutlich steigern.
+Nachher: In der Praxis steigt die Trefferquote, wenn Scope und Erfolgskriterien
+         im Prompt stehen — messbar z. B. an weniger Nachfragen pro Task.
+         (Ohne Studie: als Erfahrung markieren, nicht als „Studien“.)
+```
+
+---
+
+## 4. Rhythmus (Burstiness) & Syntax
+
+| Muster | Schwere | Gegenmittel |
+|--------|---------|-------------|
+| Sätze fast gleicher Länge über längere Strecke | HIGH | Kurz / lang / Fragment mischen |
+| Absätze alle 3–4 Sätze, gleiche Form | HIGH | Asymmetrie: ein Block 1 Satz, einer 6 |
+| Partizipialketten („…, nutzend …, basierend auf …“) | MED | Hauptsätze; Verben aktiv |
+| Nominalisierungs-Stapel (die Implementierung der …) | MED | Tun-Wörter: „du setzt …“, „der Hook prüft …“ |
+| Immer vollständige, glatte Sätze — nie Ellipsen | LOW | Gelegentlich erlaubt: „Kurz:“ / „Der Haken:“ |
+| Listen für alles | MED | Prosa, wenn 1–2 Punkte reichen |
+
+### Rhythmus-Test (30 Sekunden)
+
+Drei aufeinanderfolgende Sätze laut lesen. Klingt es wie Metronom?  
+Wenn ja: einen Satz halbieren, einen verdoppeln, einen zum Ein-Satz-Absatz machen.
+
+```text
+Vorher: Permissions steuern den Tool-Zugriff. Sie bestehen aus Allow- und Deny-Regeln.
+        Deny greift vor Allow. Das verhindert riskante Defaults.
+
+Nachher: Permissions steuern, welche Tools der Agent überhaupt ausführen darf.
+        Deny vor Allow — sonst gewinnt die breite Freigabe.
+        Das ist der häufigste Konfigurationsfehler.
+```
+
+---
+
+## 5. Struktur
+
+| Muster | Schwere | Gegenmittel |
+|--------|---------|-------------|
+| Tricolon-Zwang (immer drei Aufzählungen) | MED | 2 oder 4, wenn es passt; oder Prosa |
+| Drei gleich lange Unterabschnitte à Schema | HIGH | Kernabschnitt länger; Rest kürzen |
+| Jeder Abschnitt endet mit Mini-Fazit | HIGH | Fazit nur wo Transfer nötig |
+| Einleitung spiegelt Schluss 1:1 | MED | Schluss = nächster Schritt, nicht Echo |
+| Perfekte Parallelismen in jedem Bullet | LOW | Variation der Bullet-Form |
+
+---
+
+## 6. Spezifität vs. Generik
+
+| Muster | Schwere | Gegenmittel |
+|--------|---------|-------------|
+| Prototyp-Beispiele (Café-WLAN, „die App“, „das Unternehmen“) | MED | Repo-/Alltagsbeispiel des Lesers |
+| Nutzen ohne Mechanik („verbessert die Effizienz“) | HIGH | Wie + woran merkst du es? |
+| Fehlende Szene vor Lookup-Tabelle (Buch) | MED | 1–2 Sätze Leserproblem davor |
+| Abstrakte „Teams profitieren von …“ | MED | Eine konkrete Situation |
+
+```text
+Vorher: Teams profitieren von klaren Richtlinien und einer robusten Tool-Policy.
+Nachher: Freitag 17 Uhr, Hotfix-Branch: ohne Deny auf `rm` und ohne enges Working
+         Directory ist ein „aufräumen“-Prompt ein Produktionsrisiko.
+```
+
+---
+
+## 7. Englische Parallel-Marker (kurz)
+
+Nur bei EN- oder Mischtext. Co-Occurrence zählt mehr als Einzelwort.
+
+| EN-Marker | Schwere | DE-Nähe / Ersatz |
+|-----------|---------|------------------|
+| furthermore / moreover / additionally | HIGH | also / and / streichen |
+| it is worth noting / it is important to | HIGH | point first |
+| in conclusion / to summarize / in essence | HIGH | so / the upshot |
+| delve / leverage / navigate / utilize | HIGH | examine / use / handle |
+| seamlessly / cutting-edge / transformative / multifaceted | HIGH | concrete verb/noun |
+| studies show / experts agree (unnamed) | HIGH | name source or drop |
+| nestled / tapestry / realm / landscape (metaphor clutter) | MED | plain language |
+
+---
+
+## 8. Schnell-Checkliste vor dem Report
+
+- [ ] HIGH-Marker gezählt (Cluster = P0)?
+- [ ] Mindestens ein Rhythmus-Vorschlag mit Längenvarianz?
+- [ ] Epistemik: Phantom-Autorität oder fehlende Grenzen markiert?
+- [ ] Spezifität: Vorschläge ohne erfundene Fakten?
+- [ ] Manuskript: Callouts und Terminologie unangetastet?
+- [ ] P0 ≤ ~8; Wiederholmuster aggregiert?
+
+---
+
+## 9. Falsch-Positive (nicht überkorrigieren)
+
+Diese Merkmale allein machen Text **nicht** „KI“:
+
+- Fachtermini und enge Genre-Konventionen (API-Docs, Methodenabschnitte)
+- Kurze, klare Sätze (Buch-Stil: erwünscht)
+- Eine einzelne Konjunktion „zudem“ mitten im Fließtext
+- Listen in Cheatsheets (Kapitel 18) und echten Lookup-Rastern
+- Einheitliche Terminologie (Harness, Permissions, …) — das ist Konsistenz, kein Template-Zwang
+
+**Regel:** Nur eingreifen, wenn Muster **häufen**, den **Lesefluss** stören oder die **Stimme** zur Pressemitteilung machen.
@@ -57,7 +57,7 @@ just pdf
 just qa
 ```

-Prüft u. a. Existenz, Soft-Seitenzahl (30–120), Keywords (Grok Build, CLAUDE.md, settings.json, MCP, Permissions), Fonts.
+Prüft u. a. Existenz, Soft-Seitenzahl (40–280), Keywords (Grok Build, AGENTS.md, config.toml, MCP, Plan Mode), Fonts.

 → Warnungen dokumentieren; echte Fehler beheben oder als blockierend melden.

@@ -21,7 +21,7 @@ Du brauchst keinen Informatik-Abschluss und musst kein Tech-Lead sein. Terminal

 ### Was du in diesem Buch lernst

-Grok Build (CLI: `grok`) ist der Coding-Agent von xAI/SpaceXAI. Er läuft vor allem als **interaktive TUI** im Terminal, als **Headless**-Lauf für Scripts und CI, und als **ACP-Server** für IDEs und eigene Clients. Überall sitzt dieselbe Engine: ein Modell plus eine Steuerungsschicht aus Tools, Permissions, Memory und Workflows.
+Grok Build (CLI: `grok`) ist der Coding-Agent von **xAI** (Auth-Oberfläche und OAuth: oft als SpaceXAI sichtbar). Er läuft vor allem als **interaktive TUI** im Terminal, als **Headless**-Lauf für Scripts und CI, und als **ACP-Server** für IDEs und eigene Clients. Überall sitzt dieselbe Engine: ein Modell plus eine Steuerungsschicht aus Tools, Permissions, Memory und Workflows.

 **Wie das Lernen hier aufgebaut ist:** Zuerst baust du ein mentales Modell (Kapitel 1), dann installierst und übst du risikolos (Kapitel 2–3), dann kommen die Produktivitäts-Hebel (Plan Mode, Subagents, Worktrees, `AGENTS.md`). Erst danach Automation, Erweiterungen und der große Use-Case-Block – weil sie ohne Grundlagen schwer zu debuggen sind.

@@ -95,7 +95,7 @@ Der Ton ist der eines erfahrenen Kollegen: präzise, geduldig, ohne Hype. Wenn e

 **Ein Nachmittag, den du vermeiden willst:** Du klebst einen Stacktrace in die TUI, akzeptierst drei Diffs ohne Lesen, committest „fix stuff“ – und merkst erst im Review, dass `.env.example` mit echten Keys und ein `rm` im falschen Ordner im Diff lagen. Das Buch trainiert die Gegenbewegung: Scope formulieren, Freigaben lesen, Diffs prüfen, Wissen in Dateien legen (`AGENTS.md`, Plan-Datei, Skills) statt nur im Chat. Nicht weil KI böse ist – weil der Harness ausführt, was das Modell vorschlägt.

-Versionshinweis: Features und Slash-Commands entwickeln sich. Konzepte (Permissions, Memory, Tools, Sessions) bleiben stabiler als einzelne UI-Labels. Stand der Fakten im Buch: **Juli / Mitte 2026**.
+Versionshinweis: Features und Slash-Commands entwickeln sich. Konzepte (Permissions, Memory, Tools, Sessions) bleiben stabiler als einzelne UI-Labels. Stand der Fakten im Buch: **Juli–Aug 2026** (CLI **0.2.x**).

 ---

@@ -48,7 +48,7 @@ Wer nur das Modell sieht, überschätzt Magie. Wer nur die Tools sieht, untersch

 ### 1.3 Surfaces: eine Engine, drei Arbeitsmodi

-Du hast Grok Build installiert und stehst vor der Wahl: interaktive TUI? Einmal-Prompt im Script? IDE über ACP? Die gute Nachricht: Es ist **dieselbe Engine**. Die schlechte: Wer nur klickt oder nur „yolo“ in CI drückt, sieht seltener, *warum* eine Freigabe greift oder eine Regel greift.
+Sobald `grok` läuft (Installation und First-Start: Kapitel 2), stehst du vor der Wahl: interaktive TUI? Einmal-Prompt im Script? IDE über ACP? Die gute Nachricht: Es ist **dieselbe Engine**. Die schlechte: Wer nur klickt oder nur „yolo“ in CI drückt, sieht seltener, *warum* eine Freigabe greift oder eine Regel greift.

 | Surface | Einstieg (typisch) | Wann sinnvoll |
 |---------|-------------------|---------------|
@@ -93,9 +93,9 @@ Grenzen sind keine Marketing-Absätze. Jede Zeile unten schützt vor einer typis

 ---

-### 1.5 Philosophie: Explore → Plan → Code → Verify
+### 1.5 Philosophie: Explore → Plan → Code → Verify (danach Commit/PR)

-Grok Build glänzt nicht, wenn du „alles auf einmal“ forderst. Es glänzt, wenn du den Tag in **Phasen** schneidest – dieselben Phasen, die gute Teams ohnehin nutzen:
+Grok Build liefert bessere Diffs, wenn du nicht „alles auf einmal“ forderst, sondern den Tag in **Phasen** schneidest – dieselben Phasen, die gute Teams ohnehin nutzen:

 | Phase | Ziel | Typischer Grok-Hebel |
 |-------|------|----------------------|
@@ -171,7 +171,7 @@ Detailvergleich mit Claude Code, Codex und Cursor: Kapitel 17. Hier reicht die H

 **Warum das hier schon steht:** Ohne dieses Mentalmodell liest du Kapitel 2 als „Installationsanleitung“ und überspringst Trust. Mit diesem Mentalmodell installierst du, übst im sicheren Repo und baust Deny-/Sandbox-Gewohnheiten auf, *bevor* du CI-Keys einbindest.

-Drei Muskeln für den ersten Tag (und den restlichen Beruf):
+Drei **Muskeln** für den ersten Tag (Tag-1-Routine – nicht dieselben wie die drei **Steuerknöpfe** in 1.6: Knöpfe = Hebel-Set Scope/Mode/Dateien; Muskeln = Gewohnheit Scope/Freigaben/Diffs):

 1. **Scope** formulieren  
 2. **Freigaben** lesen statt wegklicken  
@@ -229,7 +229,7 @@ Spickzettel vor Kapitel 2. Ausführlicher: Kapitel [18.14](18-anhang-schnellrefe

 ### Was du jetzt kannst

- Modell und Grok-Build-Harness unterscheiden und die Tool-Schleife skizzieren  
+- Modell und den Harness von Grok Build unterscheiden und die Tool-Schleife skizzieren  
 - TUI, Headless und ACP einordnen und erklären, was über Surfaces hinweg gilt  
 - Den Zyklus Explore → Plan → Code → Verify als Steuerungsphilosophie anwenden  
 - Erklären, warum Scope, Modes und `AGENTS.md` keine Nice-to-haves sind, sondern die Steuerknöpfe des Harness  
@@ -1,7 +1,7 @@
 # Kapitel 2
 ## Installation und erster Start

-> **Kern in einem Satz:** In unter einer Viertelstunde installierst du `grok`, meldest dich an und trainierst die drei Muskeln, die den Rest des Buchs tragen: Scope formulieren, Freigaben lesen, Diffs prüfen.
+> **Kern in einem Satz:** Typisch in unter einer Viertelstunde (Auth- und PATH-Probleme nicht mitgezählt) installierst du `grok`, meldest dich an und trainierst die drei Muskeln, die den Rest des Buchs tragen: Scope formulieren, Freigaben lesen, Diffs prüfen.

 ---

@@ -23,10 +23,10 @@ Offizielle Empfehlung: der Installer von xAI. Danach startest du mit dem Befehl
 curl -fsSL https://x.ai/cli/install.sh | bash
 ```

-Feste Version pinnen (Beispiel – ersetze die Versionsnummer durch die, die du willst):
+Feste Version pinnen (Platzhalter – nimm die Version, die dein Team pinnen will; aktuell z. B. `grok --version` / Release-Notes, Buch-Stand **0.2.x**):

 ```bash
-curl -fsSL https://x.ai/cli/install.sh | bash -s 0.1.42
+curl -fsSL https://x.ai/cli/install.sh | bash -s 0.2.0
 ```

 **Warum pinnen?** Teams und CI brauchen reproduzierbare Agent-Versionen. „Immer latest“ ist bequem lokal und riskant in Pipelines.
@@ -40,7 +40,7 @@ irm https://x.ai/cli/install.ps1 | iex
 Feste Version:

 ```powershell
-$env:GROK_VERSION="0.1.42"; irm https://x.ai/cli/install.ps1 | iex
+$env:GROK_VERSION="0.2.0"; irm https://x.ai/cli/install.ps1 | iex
 ```

 Der PowerShell-Installer legt typischerweise `%USERPROFILE%\.grok\bin` in den User-PATH. Alternativen: Git for Windows (Git Bash) oder MSYS2 mit dem Bash-Installer oben. **WSL** bekommt das Linux-Binary.
@@ -116,7 +116,8 @@ export XAI_API_KEY="xai-..."
 grok
 ```

-**Wie die Priorität wirkt:** Ein aktives Session-Token aus dem Browser-Login hat Vorrang vor dem API-Key. Für reinen Key-Betrieb: `grok logout` bzw. `auth.json` entfernen, dann `XAI_API_KEY` setzen.
+**Alltag (Default-Grok):** Session-Token aus Browser-Login schlägt `XAI_API_KEY` – deshalb `grok logout`, wenn du **nur** den Key willst.  
+**Custom Models (Kapitel 14):** davor können per-model `api_key` / `env_key` in `config.toml` greifen (Reihenfolge grob: `api_key` → `env_key` → Session → `XAI_API_KEY`).

 > **Achtung:** `~/.grok/auth.json` und MCP-Credentials (`~/.grok/mcp_credentials.json`) sind Dateien mit Secrets (Unix typisch `0600`). Nicht in Tickets, Chats oder Shared-Dirs kopieren. Full-Disk-Encryption und privates `$HOME` / `$GROK_HOME` auf Multi-User-Hosts sind Pflicht, nicht Nice-to-have.

@@ -37,13 +37,15 @@ Du musst die Shortcut-Tabellen nicht auswendig können, bevor Plan Mode (Kapitel

 ### 3.2 Anatomie der Oberfläche

+Nach dem Login siehst du im Wesentlichen **zwei Zonen** plus Overlays: den Scrollback oben und den Prompt unten. Wer die Rollen kennt, sucht Shortcuts nicht im falschen Fokus und liest Diffs dort, wo sie erscheinen.
+
 | Teil | Was du siehst | Wofür |
 |------|----------------|--------|
 | **Scrollback** | Prompts, Antworten, Thinking, Tool-Calls, Diffs, Tasks | Lesen, navigieren, collapsen, kopieren |
 | **Prompt** | Eingabezeile unten | Aufträge, `/`-Commands, `@`-Anhänge, `!`-Shell |
 | **Overlays** | Slash-Menü, File-Picker, Settings, Session-Picker, … | Harness steuern, ohne den Chat zu „überreden“ |

-**Sticky User-Prompts** im Scrollback helfen, Turns zu scannen: „Wo habe ich den Scope gesetzt?“ ist oft die bessere Frage als „Warum ist das Modell dumm?“.
+**Was du mitnimmst:** Scrollback = Review-Oberfläche; Prompt = Steuerung; Overlays = Harness-Menüs. Sticky User-Prompts im Scrollback helfen, Turns zu scannen: „Wo habe ich den Scope gesetzt?“ ist oft die bessere Frage als „Warum ist das Modell dumm?“.

 **Thinking-Blöcke** (wenn das Modell Reasoning liefert) sind collapsbar – nützlich zum Nachvollziehen, teuer im Scroll-Rauschen. `Ctrl+E` expandiert/collapst Thinking global (Kapitel-Shortcuts unten).

@@ -84,28 +86,32 @@ Das ist der Abschnitt, den du zweimal liest, wenn der erste „hängende“ Turn

 ### 3.5 Session-Modes: Normal, Plan, Always-approve

-`Shift+Tab` im fokussierten Prompt **cyclt** die Session-Modes (typisch: Normal → Plan → Always-approve → …). Zusätzlich:
+`Shift+Tab` im fokussierten Prompt **cyclt** die Session-Modes: **Normal → Plan → Always-approve → Normal**. **Auto** ist **nicht** in diesem Zyklus – dafür `/auto` (Feature-abhängig).

 | Hebel | Mode / Wirkung |
 |-------|----------------|
-| `Shift+Tab` | Mode cyclen |
+| `Shift+Tab` | Mode cyclen (Normal / Plan / Always-approve) |
 | `Ctrl+O` | Always-approve (YOLO) toggeln |
 | `/always-approve` | Always-approve toggeln |
 | `/auto` | Auto-Mode (Classifier; gefährliche Calls können weiter fragen) – Feature-abhängig |
 | `/plan` | Plan Mode betreten (Kapitel 4) |
 | `/settings` / `F2` | Settings-Modal |

+**Terminal-Hinweis:** Auf **Apple Terminal** kann `Ctrl+O` primär **Interject/Send-now** belegen (kein modified Enter) – dann YOLO über `/always-approve` oder `/settings`. Details: User-Guide *Terminal Support*.
+
 **Was die Modes bedeuten (Arbeitsdefinition):**

 | Mode | Praxis |
 |------|--------|
-| **Normal / ask** | Alltag: lesen oft frei, Schreiben/Shell oft mit Freigabe |
+| **Normal** (Permission oft *ask*) | Alltag: lesen oft frei, Schreiben/Shell oft mit Freigabe |
 | **Plan** | Read-only Planung (außer Plan-Datei) – Ansatz freigeben, bevor Code fließt |
 | **Always-approve** | Fast keine Permission-Prompts; Deny-Regeln und Hooks greifen weiter |
 | **Auto** | Weniger Prompts durch Safety-Checks; blockierte Calls scheitern/eskalieren |

 > **Achtung:** Always-approve ist kein „sicherer Turbo“. Es ist ein Turbo **ohne Klick-Bremse**. In der Lern- und Review-Phase aus; in CI nur mit Deny/Hooks und engem Scope (Kapitel 10, 13).

+**Plan + Always-approve:** Plan Mode blockiert Repo-Edits; riskante Shell und andere Non-Edit-Tools können unter Always-approve trotzdem laufen – Details und Subagent-Gate in Kapitel 4.
+
 **Mikrogeschichte:** Du cyclst versehentlich auf Always-approve, der Agent installiert eine Dependency und pusht einen Branch. Diff war „grün“ im Scrollback – Ownership war weg. Gegenmittel: Mode-Anzeige im UI bewusst lesen; nach Experimenten `Shift+Tab` zurück auf Normal.

 **Day-1-Cockpit bis hier:** Anatomie, Fokus (`Tab`), Abbruch (`Esc`), Modes (Normal / Plan / Always-approve aus).
@@ -152,10 +158,10 @@ Das ist der Abschnitt, den du zweimal liest, wenn der erste „hängende“ Turn

 # später / eigenes Repo
@src/api/auth.ts prüfe die Fehlerbehandlung. Noch nichts ändern.
-@! .github/workflows/ci.yml erkläre den Job test.
+@!.github/workflows/ci.yml erkläre den Job test.
 ```

-Fuzzy-Picker, `.gitignore`-aware. `!` nach `@` für Dotfiles/versteckte Pfade – **Secrets nicht achtlos anhängen**.
+Fuzzy-Picker, `.gitignore`-aware. `!` **ohne Leerzeichen** direkt nach `@` für Dotfiles/versteckte Pfade (`@!.env`, `@!.github`) – **Secrets nicht achtlos anhängen**.

 #### Shell-Mode mit `!`

@@ -218,11 +224,11 @@ Vollständige Liste: User-Guide und Kapitel 18. Hier die Befehle, die den Alltag
 | Key | Aktion |
 |-----|--------|
 | `Ctrl+P` / `?` | Command Palette |
-| `Ctrl+M` | Model-Picker (wenn Prompt **nicht** fokussiert); Multiline-Toggle (wenn Prompt fokussiert) |
-| `Ctrl+O` | Always-approve toggeln |
+| `Ctrl+M` | **kontextabhängig:** Model-Picker (Prompt **nicht** fokussiert) **oder** Multiline (Prompt fokussiert) |
+| `Ctrl+O` | Always-approve toggeln (Apple Terminal: oft Interject – dann `/always-approve`) |
 | `Ctrl+S` | Session-Picker (Resume) |
 | `Ctrl+N` | Neue Session (wo gebunden) |
-| `Shift+Tab` | Mode cyclen (Prompt fokussiert) |
+| `Shift+Tab` | Mode cyclen Normal/Plan/Always-approve (Prompt fokussiert) |
 | `Ctrl+T` | Todos-Pane |
 | `Ctrl+G` | Tasks-Pane (Fullscreen-TUI); in Minimal-Mode oft External-Editor |
 | `Ctrl+B` | Laufenden Foreground-Command in den Background |
@@ -34,7 +34,10 @@ Wenn Plan Mode **aktiv** ist:
 | Plan-Datei schreiben | Implementierungs-Diffs im Working Tree |
 | Shell lesen/erkunden (siehe Fallstrick unten) | – |

-> **Achtung:** Plan Mode blockiert die **Edit-Tools**, nicht magisch jede Shell-Redirection. Bash wird nicht als Dateischreiber inspiziert. Und: **Subagents erben die Plan-Mode-Edit-Sperre des Parents nicht.** Ein `general-purpose`-Kind kann Dateien schreiben, während der Parent noch plant – und es erbt den Permission-Mode des Parents (inkl. Always-approve). Für reine Recherche: `explore` / `plan` / `capability_mode: read-only` (Kapitel 5–6).
+> **Achtung — zwei getrennte Risiken:**
+>
+> 1. **Edit-Tools ≠ Shell.** Plan Mode blockiert Repo-Edits über Edit-Tools, nicht magisch jede Shell-Redirection. Bash wird nicht als Dateischreiber inspiziert.  
+> 2. **Parent-Plan ≠ Kind-Gate.** Subagents erben die Plan-Mode-Edit-Sperre des Parents **nicht**. Ein `general-purpose`-Kind kann schreiben, während der Parent noch plant – und erbt oft den Permission-Mode (inkl. Always-approve). Für reine Recherche: `explore` / `plan` / `capability_mode: read-only` (Kapitel 5–6).

 **Plan-Datei-Pfad (typisch):**

@@ -44,6 +47,8 @@ Wenn Plan Mode **aktiv** ist:

 `<encoded-cwd>` ist ein kodierter Verzeichnisname, nicht der Literalpfad deines Repos.

+**Session-`plan.md` vs. Team-Plan-Doku:** Die Datei oben ist **session-lokal** (Harness-Artefakt). Team-Vorlagen wie [`vorlagen/PLAN.md.skeleton.md`](vorlagen/PLAN.md.skeleton.md) oder [`beispiele/todo-cli/PLAN.md.example`](beispiele/todo-cli/PLAN.md.example) sind **Repo-Doku** – nicht dieselbe Datei und kein Ersatz für den Plan-Mode-Lifecycle.
+
 **Inhalt der Plan-Datei (erwartbar):**

 - **Context** – warum die Änderung  
@@ -56,13 +61,15 @@ Wenn Plan Mode **aktiv** ist:

 ### 4.3 Plan Mode betreten

+Du willst den Mode setzen, **bevor** der nächste Prompt fliegt – sonst startet der Agent schon im falschen Gate.
+
 #### Du startest (user-initiated)

 | Weg | Wirkung |
 |-----|---------|
 | `/plan` | Plan Mode **Pending** – aktiv mit dem **nächsten** Prompt |
 | `/plan <Beschreibung>` | Plan Mode + sofortiger Turn mit dieser Beschreibung |
-| `Shift+Tab` | Mode cyclen: Normal → **Plan** → Always-approve → … |
+| `Shift+Tab` | Mode cyclen: Normal → **Plan** → Always-approve → Normal (**Auto** separat: `/auto`) |

 **Lifecycle (vereinfacht):**

@@ -71,16 +78,17 @@ Inactive  --(/plan oder Shift+Tab)-->  Pending
 Pending   --(erster Prompt)--------->  Active
 Active    --(Approve exit_plan_mode)--> Inactive (+ Implementierung)
 Active    --(Mode aus, idle)--------->  Inactive
+Active    --(Mode aus, Turn läuft)-->  ExitPending → dann Inactive
 ```

-Agent-initiiert: Der Agent ruft `enter_plan_mode` auf – **du musst zustimmen**. Ablehnen = bleibt Normal.
+Agent-initiiert: Der Agent ruft `enter_plan_mode` auf – **du musst zustimmen**. Ablehnen = bleibt Normal. Bei Zustimmung springt der Flow oft **Inactive → Active** (ohne Pending).

 **Gute Trigger (für dich und den Agenten):**

- „Add user authentication“ (Session vs. JWT vs. Middleware)  
- „Redesign the data pipeline“  
- „Add caching“ (Redis vs. in-memory vs. file)  
- „Real-time updates“ (WebSocket vs. SSE vs. Polling)  
+- „User-Auth einbauen“ / „Add user authentication“ (Session vs. JWT vs. Middleware)  
+- „Datenpipeline neu schneiden“ / „Redesign the data pipeline“  
+- „Caching ergänzen“ (Redis vs. in-memory vs. file)  
+- „Echtzeit-Updates“ (WebSocket vs. SSE vs. Polling)  

 **Schlechte Trigger:**

@@ -100,6 +108,7 @@ Wenn der Agent `exit_plan_mode` aufruft, liest das Tool `plan.md` und die TUI ö
 | `a` | **Approve** – Plan freigeben und bauen. Mit offenen Kommentaren: *approve w/ comments* |
 | `s` | **Request changes** – Fokus auf Prompt, Revisionsnotizen tippen, `Enter` senden |
 | `c` | **Comment** auf die selektierte Zeile/Range |
+| `y` | **Copy** – gesamten Plan in die Zwischenablage |
 | `q` | **Quit plan** – Plan verwerfen, Plan Mode aus |
 | `Tab` | Fokus Preview ↔ Prompt |
 | `Esc` | Vom Prompt zurück zur Preview (nicht automatisch quit) |
@@ -124,7 +133,7 @@ Feedback (Inline, Freeform oder beides) hält Plan Mode **aktiv**: Der Agent üb
 - **Status-Flag:** während aktiv `plan`; Always-approve-Flag kommt nach Exit zurück, falls es an war.  
 - **`/compact`:** Plan-Mode-State bleibt erhalten; im kompaktierten Kontext steckt ein Reminder, dass Plan Mode aktiv ist.

-**Praxisregel:** Plan Mode ist kein Ersatz für enge Shell-Deny-Regeln. Wenn du in Plan Mode yolo fährst, kann der Agent trotzdem riskante Commands ausführen – nur eben ohne Repo-Edit-Tools.
+**Praxisregel:** Plan Mode ist kein Ersatz für enge Shell-Deny-Regeln. Unter Always-approve in Plan Mode können riskante Commands weiterlaufen – nur Repo-Edit-Tools bleiben gesperrt.

 ---

@@ -61,6 +61,8 @@ Custom-Agents können Typen ergänzen oder Built-ins per Name überschatten.
 | „Implementiere den freigegebenen Fix + Tests.“ | `general-purpose` |
 | Unklar / gemischt | `general-purpose` + enger Prompt, oder erst explore |

+**Default:** `general-purpose` nur, wenn Writes wirklich nötig sind – sonst `explore`/`plan` und Kontext sparen.
+
 ---

 ### 5.4 Wie Spawning funktioniert
@@ -80,7 +82,9 @@ Wichtige Parameter (Konzept – der Agent setzt sie; du steuerst über Prompt un
 | `cwd` | Anderes Working Directory (nicht mit `worktree` kombinieren) |
 | `resume_from` | Abgeschlossenes Kind fortsetzen (gleicher Typ, gleiche Session) |

-Background-Kinder: Output/Status über `get_command_or_subagent_output`; abbrechen mit `kill_command_or_subagent`. Mehrere Tasks: warten mit Wait-Tools (`wait_any` / `wait_all`). In der TUI: **Tasks-Pane** `Ctrl+G` – laufende/fertige Subagents und Background-Commands.
+Background-Kinder: Output/Status über `get_command_or_subagent_output`; abbrechen mit `kill_command_or_subagent`. Mehrere Tasks: warten mit dem Tool **`wait_commands_or_subagents`** und Parameter `mode` = `wait_any` oder `wait_all` (max. 20 Tasks). In der TUI: **Tasks-Pane** `Ctrl+G` – laufende/fertige Subagents und Background-Commands.
+
+**Nesting-Tiefe 1:** Nur die Top-Level-Session spawnt Subagents. Ein Kind kann **keine** eigenen Subagents spawnen (`spawn_subagent` → Depth-Limit-Fehler). Der Agent-Baum bleibt flach – Orchestrierung bleibt beim Parent.

 ---

@@ -127,7 +131,7 @@ Nützliche Felder:
 **Resolution (Modell/Effort), grob höchste Priorität zuerst:** Spawn-Override → Role-Default → Persona → Parent.  
 **Isolation:** ähnliche Kette, Default aber **`none`** (erbt nicht automatisch Worktree vom Parent).

-> **Hinweis:** Personas greifen über Resolution/Roles – der Parent übergibt typischerweise **keinen** Persona-Namen als freien `spawn_subagent`-Parameter. Du gestaltest Personas und Roles so, dass die Resolution den richtigen Overlay wählt; Details im Agents-Modal und in der Config (Kapitel 14).
+Personas greifen über Resolution/Roles – der Parent übergibt typischerweise **keinen** Persona-Namen als freien `spawn_subagent`-Parameter. Model/Effort wechseln nur, wenn Persona oder Role sie setzen; sonst erbt das Kind den Parent. Du gestaltest Personas und Roles so, dass die Resolution den richtigen Overlay wählt; Details im Agents-Modal und in der Config (Kapitel 14).

 ---

@@ -168,6 +172,8 @@ Voraussetzungen: Quelle **completed**, gleiche Session, **gleicher** `subagent_t

 ### 5.9 Config-Hebel (kurz)

+Toggle, Models und Roles greifen in der **Resolution**, bevor der Parent spawnt – das spart Prompt-Yoga und erzwingt Team-Defaults (z. B. Research nur read-only).
+
 ```toml
 [subagents.toggle]
 explore = true
@@ -283,7 +289,7 @@ Delegiere so:
 | Symptom | Ursache | Fix |
 |---------|---------|-----|
 | Parent-Kontext trotzdem voll | Zu viel im Parent selbst gelesen | Explizit „nur Subagent exploriert“ |
-| Kind schreibt im Plan-Parent | general-purpose ohne Gate | explore/plan oder read-only |
+| Kind schreibt im Plan-Parent | general-purpose ohne Gate (Parent-Plan ≠ Kind-Gate, Kap. 4) | explore/plan oder read-only |
 | Zwei Writer, Chaos-Diff | Shared isolation | Worktrees / serialisieren |
 | Resume schlägt fehl | Anderer Typ / noch running | completed + same type |
 | Persona „wirkt nicht“ | Resolution/Name | Modal, Config-Priorität, instructions prüfen |
@@ -295,6 +301,7 @@ Delegiere so:

 - [ ] Auftrag hat klaren Typ (explore / plan / general-purpose)  
 - [ ] DoD und Out-of-scope im Kind-Prompt  
+- [ ] Nesting-Tiefe 1: Orchestrierung nur im Parent  
 - [ ] Keine unnötige Dateiüberlappung bei Parallel-Writes  
 - [ ] Parent macht Integration-Verify  
 - [ ] Tasks-Pane im Blick bei Background  
@@ -17,7 +17,7 @@ Kapitel 5 trennt **Kontextfenster**. Worktrees trennen **Dateien auf Disk**.

 **Alltagsschmerz:** Session A refactort Auth, Session B fixt CI – beide rühren `package.json` an. Am Abend: weder Feature noch CI, dafür ein Diff, den niemand mergen will.

-**Philosophie:** Isolation ist billiger als Heldentum. Lieber zwei saubere Worktrees und ein bewusstes Apply als ein „Gott-Working-Tree“.
+**Philosophie:** Isolation ist billiger als Heldentum. Lieber zwei saubere Worktrees und ein bewusstes Apply als einen gemeinsamen Working Tree als Chaos-Zone.

 ![Kontextfenster trennen Subagents; Worktrees trennen Dateien auf Disk.](assets/illustrations/M-06-worktrees-datei-isolation.jpg){width=90%}

@@ -65,7 +65,7 @@ Am Ende: Summary, Worktree-Pfad, Testbefehl, Diff-Statistik.
 grok -w -r <session-id>
 ```

-Neue Session-Taste: `Ctrl+N` (ggf. Doppel-Geste) kann optional einen Worktree anbieten – UI-Abhängig; CLI-Flags sind die reproduzierbare Variante.
+Neue Session-Taste: `Ctrl+N` (ggf. Doppel-Geste) kann optional einen Worktree anbieten – UI-abhängig; CLI-Flags sind die reproduzierbare Variante.

 ---

@@ -156,7 +156,7 @@ Parent: Summary + Verify-Plan prüfen → Apply oder PR

 **Fallen:**

- Parent in Plan Mode, Kind `general-purpose` **ohne** Worktree im shared Tree → Kind kann trotz Parent-Plan **schreiben** (Kapitel 4).  
+- Parent in Plan Mode, Kind `general-purpose` **ohne** Worktree im shared Tree → Kind kann trotz Parent-Plan **schreiben** (Parent-Plan ≠ Kind-Gate, Kapitel 4).  
 - Zwei Worktree-Kinder am selben logischen Feature ohne Absprachen → doppelte Branches, doppelte Wahrheit.  
 - Apply während Parent selbst dirty ist → Konflikte; vorher Parent clean oder PR-only.  

@@ -264,6 +264,7 @@ git branch -vv

 ### 6.12 Checkliste Worktrees

+- [ ] Parent-Tree clean **oder** bewusst PR-only (kein Apply in dirty Parent)  
 - [ ] Basis-Ref bewusst (main vs. feature HEAD)  
 - [ ] Label/Name verständlich (`feat-…`, nicht `tmp1`)  
 - [ ] Scope disjunkt bei Parallel-Tracks  
@@ -37,7 +37,7 @@ Mehrere Treffer im **selben** Ordner werden alle geladen. Auf case-insensitiven
 **Claude-Kompatibilität (default an):** zusätzlich Home `~/.claude/` und pro Level `.claude/CLAUDE.md` / `.claude/CLAUDE.local.md`.  
 **Cursor-Kompatibilität:** analog `~/.cursor/` und projektbezogene Cursor-Rules, wenn enabled.

-### Rules-Verzeichnisse
+#### Rules-Verzeichnisse

 Zusätzlich zu den Named Files: alle `*.md` in:

@@ -105,13 +105,15 @@ In `src/components/` lädt Grok **alle drei**. **Deeper wins:** bei Konflikt gil
 - Keine Edits an `dist/` generierten Artefakten
 ```

+Commands an euren Stack anpassen (`pytest`/`cargo`/…); siehe auch [`beispiele/todo-cli/AGENTS.md`](beispiele/todo-cli/AGENTS.md) und die Vorlagen unter `vorlagen/`.
+
 #### Raus (oder nur verlinken)

 - README-Kopie, Architektur-Roman, Marketing  
 - Secrets, Tokens, interne Hostnamen mit Credentials  
 - 20 Seiten Style-Guide – lieber Link + 5 harte Regeln  

-**Dateigröße:** Grok lädt Instruction-Files **vollständig** (kein Cap/Truncate). Trotzdem: kurz und spezfisch – Kontext ist endlich, und lange Wände werden schlechter befolgt.
+**Dateigröße:** Grok lädt Instruction-Files **vollständig** (kein Cap/Truncate). Trotzdem: kurz und spezifisch – Kontext ist endlich, und lange Wände werden schlechter befolgt.

 ---

@@ -180,11 +182,11 @@ Viele Repos haben schon `CLAUDE.md` und `.claude/rules/`. Grok liest sie standar
 | Dual-Agent | Beide Dateien **kurz und konsistent** – nicht zwei Wahrheiten |
 | Vendor aus | `[compat.claude]` / `[compat.cursor]` Rules/Agents/Skills in Config (Kapitel 14) |

-**Anti-Pattern:** `AGENTS.md` sagt „pnpm“, `CLAUDE.md` sagt „npm“ – deeper/later gewinnt unvorhersehbar im Alltag. Eine Source of Truth, der Rest verlinkt oder ist identisch.
+**Anti-Pattern:** `AGENTS.md` sagt „pnpm“, `CLAUDE.md` sagt „npm“ – die **später geladene** Anweisung gewinnt (Precedence ist bestimmt). Im Alltag wirkt das wie Willkür, wenn beide Dateien divergieren. Eine Source of Truth, der Rest verlinkt oder ist identisch.

 ---

-### 7.9 Best Practices (knapp und hart)
+### 7.9 Best Practices (knapp und verbindlich)

 1. **Root zuerst** – das Wichtigste project-weit.  
 2. **Spezifisch** – `` `cargo fmt` vor Commit `` schlägt „formatiere bitte“.  
@@ -5,10 +5,12 @@

 ---

-### 8.1 Die drei Hebel im Vergleich
+### 8.1 Steuerflächen im Vergleich

-| Hebel | Charakter | Typisches Beispiel |
-|-------|-----------|-------------------|
+**Alltagsschmerz:** Der Agent „vergisst“ das Verify-Ritual, der Hook blockt still einen `rm`, und niemand weiß, ob das Team-Plugin überhaupt trusted ist. Die Tabelle sortiert **weich → hart → verpackt**.
+
+| Steuerfläche | Charakter | Typisches Beispiel |
+|--------------|-----------|-------------------|
 | **AGENTS.md** | immer im Kontext, weich | „Tests: `npm test`“ |
 | **Skill** | bei Bedarf / per `/name`, Verfahren | `/commit`, `/verify` |
 | **Hook** | Event-getrieben, kann **blocken** | PreToolUse: `rm -rf` deny |
@@ -19,6 +21,8 @@
 **Wann Hook statt Skill?** „Darf gar nicht passieren“ oder „nach jedem Edit formatieren“ – ohne dass der Agent es „vergessen“ darf.  
 **Wann Plugin?** Mehrere Artefakte + Team-Distribution.

+Weich vs. hart (K-05) und Skills vs. Hooks (M-07) hängen zusammen: erst die Härte-Skala, dann die Verpackung.
+
 ![Je härter die Anforderung, desto weiter rechts: AGENTS.md bittet, Sandbox erzwingt.](assets/illustrations/K-05-weich-vs-hart.jpg){width=90%}

 ![Prozeduren → Skills. Unverhandelbares → Hooks. Pakete → Plugins mit Trust.](assets/illustrations/M-07-skills-vs-hooks.jpg){width=90%}
@@ -50,7 +54,7 @@ ignore = ["~/my-team-skills/wip"]
 disabled = ["wip-skill"]
 ```

-### Minimal-SKILL.md
+#### Minimal-SKILL.md

 ```markdown
 ---
@@ -71,12 +75,14 @@ description: >
 | Frontmatter | Rolle |
 |-------------|--------|
 | `name` | Identifier (lowercase, digits, hyphens; max 64) |
-| `description` | **Trigger** für Auto-Invocation – spezfisch schreiben |
+| `description` | **Trigger** für Auto-Invocation – spezifisch schreiben |
 | `when-to-use` | extra Trigger-Phrasen |
 | `user-invocable` | default `true` → erscheint als `/name` |
 | `disable-model-invocation` | `true` = nur Slash, kein Auto |
 | `allowed-tools`, `model`, `effort`, … | optional eng führen |

+**Wie Trigger greifen:** `description` und `when-to-use` steuern, wann der Agent den Skill **von allein** lädt. Vage Descriptions („hilft bei Code“) nerven: zu oft oder nie. Schärfe sie so, dass der Use-Case und die Slash-Form (`/verify`) erkennbar sind (Vertiefung: 8.3).
+
 ---

 ### 8.3 Skills nutzen und erzeugen
@@ -86,11 +92,13 @@ description: >
 ```text
 /verify
 /commit fix the build
-/local:commit          # bei Namenskollision: Scope-Prefix
-/user:commit
+/local:commit          # CWD: ./.grok/skills/
+/repo:commit           # Repo-Root: <repo>/.grok/skills/
+/user:commit           # User: ~/.grok/skills/
+/deploy-tools:release  # Plugin-Skill: /<plugin-name>:<skill>
 ```

-`/` öffnet das Menü (Builtins + Skills). CLI-Übersicht: `grok inspect`.
+`/` öffnet das Menü (Builtins + Skills). Builtins gewinnen unqualifiziert über gleichnamige Skills – dann den Scope-Prefix nutzen. CLI-Übersicht: `grok inspect`.

 #### Erzeugen mit `/create-skill`

@@ -121,7 +129,7 @@ grok plugin marketplace remove <url>

 # Plugin installieren
 grok plugin install deploy-tools --trust
-# ohne --trust: Warnung und Stop – Hooks/MCP/Skills würden aktiv
+# ohne --trust: Warnung und Stop – Install bricht ab
 ```

 Quellen: `owner/repo`, `@ref`/`@sha`, git URL, lokaler Pfad.
@@ -136,6 +144,8 @@ grok plugin details <name>

 **TUI:** `/plugins` (überall; auf VS-Code-Family der sichere Weg). Modal-Tabs: Hooks, Plugins, Marketplace, Skills, MCP. Keys u. a. `r` reload, `Space` enable/disable, `i` install (Marketplace).

+**Enable vs. Trust:** **Enable** lädt Skills, Commands und Agents. **Trust** schaltet Hooks, MCP und LSP des Plugins scharf. Beides ist getrennt – enable allein startet keine Hook-/MCP-Ausführung.
+
 **Config-Quellen dauerhaft:**

 ```toml
@@ -161,10 +171,13 @@ Hook = Command oder HTTP an Lifecycle-Events.
 | `PreToolUse` | **ja – deny** | Safety-Guard |
 | `PostToolUse` | nein | Format, Log |
 | `PostToolUseFailure` | nein | Alert |
-| `Stop` / `SubagentStop` | **ja – Stop blocken** | „Tests müssen grün sein“ |
+| `Stop` / `SubagentStop` (Alias `SubagentEnd`) | **ja – Stop blocken** | „Tests müssen grün sein“ |
 | `SubagentStart` | nein | Audit |
 | `PreCompact` / `PostCompact` | nein | Memory-Hygiene |
 | `SessionEnd` | nein | Cleanup |
+| `PermissionDenied` / `Notification` / `StopFailure` | nein | Audit / UI-Hinweise |
+
+Vollständige Event-Liste: User-Guide *Hooks*.

 **Orte (gemerged):** `~/.grok/hooks/*.json`, Projekt `.grok/hooks/*.json` (**Folder-Trust nötig**), Config-TOML, managed/requirements, Plugins, optional Claude/Cursor-Compat-Dateien.

@@ -178,7 +191,7 @@ grok --trust

 #### Quick-Start PreToolUse-Guard (Skizze)

-`~/.grok/hooks/guard-rm.json`:
+`~/.grok/hooks/guard-rm.json` (Pfad-Skizze; im Übungsrepo oft `bin/block-rm.sh` wie `beispiele/todo-cli/`, kopierfertig auch unter [`vorlagen/hooks/`](vorlagen/hooks/) mit `scripts/block-rm.sh`):

 ```json
 {
@@ -327,9 +340,10 @@ Bestätige die Trennung und führe /verify aus.
 | Symptom | Ursache | Fix |
 |---------|---------|-----|
 | Skill erscheint nicht | Name/Pfad/disabled | `grok inspect`, Frontmatter |
-| Falscher Skill bei Kollision | Unqualifizierter Name | `/repo:name` / `/user:name` |
+| Falscher Skill bei Kollision | Unqualifizierter Name | `/local:name` / `/repo:name` / `/user:name` / `/<plugin>:name` |
 | Auto-Skill nervt | Vage description | `when-to-use` schärfen oder disable-model-invocation |
 | Project-Hooks tot | Kein Folder-Trust | `/hooks-trust` bewusst |
+| Plugin Skills da, Hooks/MCP tot | enable ≠ trust | `--trust` / Trust im Modal, dann `r` |
 | Plugin install, nichts passiert | nicht trusted / disable | `--trust`, enable, `r` |
 | Hook „blockt nicht“ bei Crash | fail-open | Script härten, explizit deny |

@@ -337,7 +351,7 @@ Bestätige die Trennung und führe /verify aus.

 ### 8.10 Checkliste

- [ ] Skills: ein Workflow pro Skill, spezfische description  
+- [ ] Skills: ein Workflow pro Skill, spezifische description  
 - [ ] Team-Skills unter `.grok/skills/` committed  
 - [ ] Hooks nur für echte Gates; Trust verstanden  
 - [ ] Plugins nur aus trusted Sources + Inventory (`details`)  
@@ -36,12 +36,12 @@ command = "npx"
 args = ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"]
 env = { }  # Secrets lieber ${VAR} – siehe unten
 enabled = true
-startup_timeout_sec = 30
+startup_timeout_sec = 120   # Default oft 30; Cold-Start npx/uvx eher 120 (wie in vorlagen/)
 tool_timeout_sec = 120
 tool_timeouts = { slow_op = 300 }
 ```

-Cold-Start `npx`/`uvx` braucht oft mehr als 30s Startup – per Server oder global:
+Cold-Start `npx`/`uvx` braucht oft mehr als 30s Startup – per Server oder global (Gegenstück: [`beispiele/configs/mcp.filesystem.beispiel.toml`](beispiele/configs/mcp.filesystem.beispiel.toml)):

 ```bash
 export GROK_MCP_STARTUP_TIMEOUT_SECS=120
@@ -79,6 +79,8 @@ grok mcp add --transport http api https://mcp.example.com/mcp \
 grok mcp add --transport sse linear https://mcp.linear.app/sse

 grok mcp remove github
+grok mcp enable name         # persistiert (u. a. disabled_mcp_servers)
+grok mcp disable name
 grok mcp doctor              # alle
 grok mcp doctor github       # einer
 grok mcp doctor --json
@@ -107,7 +109,7 @@ Grok walked CWD → Git-Root und lädt `.grok/config.toml` je Level:
 | `<repo>/.grok/config.toml` | mittel |
 | `<cwd>/.grok/config.toml` | hoch |

-Project-Config liefert typischerweise `[mcp_servers]`, `[plugins]`, `[permission]` – viele andere Sektionen nur user-global (Kapitel 14).
+**Was du heute legst:** Eintrag in `<cwd>/.grok/config.toml` (oder Repo-Root) schlägt User-Global für denselben Server-Namen. Project-Config liefert typischerweise `[mcp_servers]`, `[plugins]`, `[permission]` – viele andere Sektionen nur user-global (Kapitel 14).

 **Repo-Trust:** Project-MCP/LSP/Hooks hängen am **Folder-Trust** (`trusted_folders.toml`, `/hooks-trust`, `--trust`). Untrusted Repo → Server starten nicht „heimlich“.

@@ -36,6 +36,8 @@ grok -p --prompt-file ./prompts/ci-review.txt --output-format json

 ### 10.3 Wichtige Flags (Arbeitsset)

+In CI brauchst du selten die ganze Flag-Liste – aber **Always-approve + Deny + Output-Format + Turn-Limit** fast immer. Die Tabelle ist Nachschlagewerk; die Sessions unten bauen die typische Kombi.
+
 | Flag | Rolle |
 |------|--------|
 | `-p` / `--single` | Headless-Prompt |
@@ -43,19 +45,21 @@ grok -p --prompt-file ./prompts/ci-review.txt --output-format json
 | `-c` / `--continue` | letzte Session im CWD |
 | `-r` / `--resume` | Session per ID/Titel |
 | `--cwd` | Working Directory |
-| `--output-format plain\|json\|streaming-json` | Ausgabe |
-| `--yolo` / `--always-approve` | keine Permission-Prompts |
+| `--output-format plain\|json\|streaming-json\|streaming-messages-json` | Ausgabe |
+| `--include-partial-messages` | Text/Thinking-Deltas (nur mit `streaming-messages-json`) |
+| `--yolo` / `--always-approve` | keine Permission-Prompts (`--yolo` = Alias, oft versteckt in `--help`) |
 | `--permission-mode` | u. a. `bypassPermissions` |
 | `--allow` / `--deny` | Permission-Regeln (wiederholbar) |
 | `--rules` | Session-Regeln |
 | `--sandbox <profile>` | OS-Sandbox (Kapitel 13) |
 | `--tools` / `--disallowed-tools` | Tool-Allow/Deny-List (**nur Headless**) |
+| `--agents` | Inline-Subagent-Definitionen (**nur Headless**) |
 | `--max-turns N` | Turn-Limit (**nur Headless**) |
 | `--effort` / `--reasoning-effort` | Reasoning-Level |
 | `--no-auto-update` | keine Update-Checks im Job |
 | `--worktree=` / `-w` | isolierter Tree (Kapitel 6) |

-> **Hinweis:** `--tools`, `--disallowed-tools`, `--max-turns` in der TUI → Warnung, ignoriert. In CI genau diese Flags nutzen.
+**Nur Headless:** `--tools`, `--disallowed-tools`, `--max-turns`, `--agents` in der TUI → Warnung, ignoriert. In CI genau diese Flags nutzen.

 ---

@@ -76,9 +80,13 @@ grok -p "Review changes for bugs" --output-format json --yolo \

 #### streaming-json

-NDJSON-Eventstrom – für UIs und Live-Pipelines.
+NDJSON-Eventstrom (native ACP-Session-Updates) – für UIs und Live-Pipelines.

-**Praxis:** CI-Summary → `json` + `jq`. Streaming-Dashboards → `streaming-json`.
+#### streaming-messages-json
+
+NDJSON im Anthropic-Messages-API-Wire-Format – für Clients, die dieses Streaming-Protokoll erwarten. Mit `--include-partial-messages` kommen zusätzlich inkrementelle `stream_event`-Deltas (Text/Thinking); ohne dieses Flag und bei anderen Formaten wird das Flag ignoriert (mit Warnung).
+
+**Praxis:** CI-Summary → `json` + `jq`. Streaming-Dashboards → `streaming-json`. Messages-API-kompatible Clients → `streaming-messages-json`.

 ---

@@ -115,7 +123,7 @@ grok -p "Run unit tests and summarize failures" \
 --disallowed-tools "Agent(explore)"
 ```

-Tool-IDs intern (Shell oft `run_terminal_cmd` in Filter-Docs – bei Unklarheit Guide/Inspect). Permission-Rules nutzen Prefixe wie `Bash(...)`, `Edit(...)`, `MCPTool(...)`.
+**Zwei Namensräume, nicht vermischen:** Headless-`--tools` / `--disallowed-tools` nutzen **interne Tool-IDs** (Shell oft `run_terminal_cmd`). Permission-Rules und viele Hook-Matcher nutzen Prefixe bzw. Aliase wie `Bash(...)` / `run_terminal_command` (Kapitel 8 und 13). Bei Unklarheit: Guide oder `grok inspect`.

 ---

@@ -141,7 +149,8 @@ grok -p "Static review of src/api" \

 ```bash
 # multi-step pipeline über eine Session
-SID=$(uuidgen)   # oder feste UUID-Policy
+# -s erwartet UUID; macOS-uuidgen liefert Uppercase → lowercasen
+SID=$(uuidgen | tr '[:upper:]' '[:lower:]')   # oder feste UUID-Policy
 grok -p "Step 1: find flaky tests" -s "$SID" --always-approve --output-format json
 grok -p "Step 2: propose minimal fix" -r "$SID" --always-approve --output-format json

@@ -177,6 +186,7 @@ jobs:
          XAI_API_KEY: ${{ secrets.XAI_API_KEY }}
        run: |
          set -euo pipefail
+          export PATH="$HOME/.grok/bin:$PATH"
          git fetch origin "${{ github.base_ref }}"
          RANGE="origin/${{ github.base_ref }}...HEAD"
          grok -p "Review the git diff $RANGE for bugs and security issues.
@@ -193,6 +203,8 @@ jobs:
          jq -r '.text' /tmp/grok-out.json >> "$GITHUB_STEP_SUMMARY"
 ```

+Lauffähiges Gegenstück im Repo: [`beispiele/configs/github-actions-grok-review.yml`](beispiele/configs/github-actions-grok-review.yml) (inkl. `PATH`).
+
 > **Achtung:** `XAI_API_KEY` nur als Secret. Kein Always-approve ohne Deny. Keine Write-Permissions auf den Default-Branch für den Job-Token, wenn du nur reviewen willst.

 Auth in CI: API-Key (Kapitel 2), nicht Browser-Login.
@@ -240,11 +252,13 @@ grok -p "List the three riskiest modules. Change nothing." \

 #### Session 2 – YOLO + Deny

+Gates wie in 10.5; hier ein anderes Deny-Paar (Force-Push + Installer-Muster):
+
 ```bash
 grok -p "Run the unit test suite and quote the first failure." \
  --always-approve \
-  --deny 'Bash(rm *)' \
-  --deny 'Bash(git push *)' \
+  --deny 'Bash(git push --force *)' \
+  --deny 'Bash(curl *)' \
  --max-turns 20
 ```

@@ -59,14 +59,9 @@ Flags **nach** `agent` und **vor** dem Mode-Namen; mode-spezifische Flags **dana

 **Clients:** ACP-fähige IDEs/Editoren (z. B. Zed, Neovim, Emacs-Integrationen), Custom-Tools, SDKs. Konkrete Marketplace-Extensions ändern sich – Konzept bleibt: Client startet `grok agent … stdio` und spricht ACP.

-**Automation-Baseline:**
+**Transport-Fokus:** stdio ist der lokale Standard (Client startet den Prozess). Härtung (Always-approve + Deny + Sandbox) bündelst du in 11.8 und Kapitel 13 – hier nur der Startweg.

-```bash
-grok agent --always-approve stdio
-# Deny/Hooks trotzdem aktiv (Kapitel 8, 13)
-```
-
-Session-seitig YOLO:
+Session-seitig YOLO (Client-Meta, Implementierung abhängig):

 ```json
 {
@@ -76,8 +71,6 @@ Session-seitig YOLO:
 }
 ```

-(`session/new` Meta – Client-Implementierung abhängig.)
-
 ---

 ### 11.4 Server Mode (WebSocket)
@@ -115,7 +108,7 @@ Für Browser/Remote-Clients über gemeinsamen Relay – Ops-Thema (Auth, Allowli
 4. **session/update** – Stream (Text, Tools, Thoughts)  
 5. **Permissions** – Approve/Deny oder Mode-Policy  

-Als **Nutzer** siehst du das in der IDE als Chat + Diffs. Als **Integrationsbauer** loggst du JSON-RPC und testest mit always-approve + Deny.
+Als **Nutzer** siehst du das in der IDE als Chat + Diffs. Als **Integrationsbauer** loggst du JSON-RPC (Permissions, CWD, Tool-Calls) – sonst debuggst du „hängt“ und „falscher Tree“ blind. Teste mit always-approve + Deny.

 ACP-Extensions (Auszug aus Guide): u. a. Git-Worktree-Methoden (`x.ai/git/worktree/*`), Session-Helpers – nützlich für isolierte IDE-Sessions (Kapitel 6).

@@ -123,7 +116,7 @@ ACP-Extensions (Auszug aus Guide): u. a. Git-Worktree-Methoden (`x.ai/git/work

 ### 11.7 IDE-Alltag: was gleich bleibt

-Unabhängig vom Editor-Skin gelten dieselben Steuerknöpfe:
+**Alltagsschmerz:** Falscher CWD, Diff akzeptiert ohne Lesen, Always-approve „weil die IDE fragt nervt“. Unabhängig vom Editor-Skin gelten dieselben Steuerknöpfe:

 | Thema | In der IDE genauso wichtig |
 |-------|----------------------------|
@@ -148,16 +141,24 @@ Typische Muster:

 ```bash
 # Eval-Skizze: stdio-Client steuert Turns
-grok agent --always-approve \
-  --deny 'Bash(rm -rf *)' \
-  --deny 'Bash(git push --force *)' \
-  stdio
+# Harte Limits: [permission] deny in .grok/config.toml (agent-CLI listet --deny nicht)
+grok agent --always-approve stdio
+```
+
+```toml
+# .grok/config.toml (Bot-Worker)
+[permission]
+deny = [
+  "Bash(rm -rf *)",
+  "Bash(git push --force *)",
+  "Bash(git push -f *)",
+]
 ```

 **Hardening-Checkliste für Bots:**

 - [ ] Secret/API-Key nur Env  
- [ ] Always-approve + Deny + ideal Sandbox  
+- [ ] Always-approve + Deny (Config/Hooks) + ideal Sandbox  
 - [ ] Bind localhost oder mTLS  
 - [ ] max cost/turns clientseitig  
 - [ ] Audit-Log der Prompts (ohne Secrets)  
@@ -181,7 +182,7 @@ Ohne eigenen Client: IDE-Extension mit Grok-ACP verbinden und einen Read-only-Pr
 #### Session 2 – serve + Secret

 ```bash
-export GROK_AGENT_SECRET="dev-only-change-me"
+export GROK_AGENT_SECRET="dev-only-change-me"   # nur lokal/Env – nicht committen
 grok agent --always-approve serve --bind 127.0.0.1:2419 --secret "$GROK_AGENT_SECRET"
 ```

@@ -5,22 +5,22 @@

 ---

-### 12.1 Drei Speicher, die du nicht vermischen solltest
+### 12.1 Vier Speicher, die du nicht vermischen solltest
+
+**Alltagsschmerz:** Eine 4-Stunden-Session driftet, Kosten steigen, der Agent widerspricht sich. Compact hilft, verliert aber Nuancen. Memory hilft über Tage – und kann Falsches „erinnern“, wenn du Müll speicherst. `AGENTS.md` ist kein Session-Speicher, sondern der Team-Kompass – trotzdem landet es im Kopf neben den dreien und wird oft verwechselt.

 | Speicher | Was | Lebensdauer |
 |----------|-----|-------------|
 | **Kontextfenster** | was das Modell *jetzt* sieht | Turn / bis Compact |
 | **Session** | voller Verlauf + Tools + Snapshots | `~/.grok/sessions/…` |
 | **Memory** | indexierte Fakten über Sessions | `~/.grok/memory/…` (opt-in) |
-| **AGENTS.md** | Team-Kompass | Repo (Kapitel 7) |
-
-**Alltagsschmerz:** Eine 4-Stunden-Session driftet, Kosten steigen, der Agent widerspricht sich. Compact hilft, verliert aber Nuancen. Memory hilft über Tage – und kann Falsches „erinnern“, wenn du Müll speicherst.
+| **AGENTS.md** | Team-Kompass (weich, Kapitel 7) | Repo – nicht session-lokal |

 ---

 ### 12.2 Session-Layout auf Disk

-Basis: `~/.grok` bzw. `$GROK_HOME`. Sessions:
+Basis: `~/.grok` bzw. `$GROK_HOME`. **Warum das Layout kennen?** Resume und Debug hängen an `updates.jsonl` (autoritativ), nicht am Titel in der UI. Feedback und Rewind-Punkte sitzen daneben – wer nur `summary.json` anstarrt, sieht Metadaten, nicht den Gesprächsstrom.

 ```text
 ~/.grok/sessions/<encoded-cwd>/<session-id>/
@@ -30,6 +30,7 @@ Basis: `~/.grok` bzw. `$GROK_HOME`. Sessions:
  plan.json              # Tasks/TODO-State
  rewind_points.jsonl    # Snapshots für /rewind
  signals.json
+  feedback.jsonl         # Ratings/Feedback (falls genutzt)
  compaction_checkpoints/
  subagents/             # Meta; Kinder leben im normalen Session-Tree
 ```
@@ -40,11 +41,13 @@ Basis: `~/.grok` bzw. `$GROK_HOME`. Sessions:

 ### 12.3 Sessions steuern

+**Warum IDs statt Titel in Scripts?** Titel sind lesbar und kollidieren; IDs sind stabil. `list`/`search` sind die Inventar-Tools; Löschen ist permanent.
+
 | Ziel | TUI | CLI |
 |------|-----|-----|
 | Neu | `/new` (`/clear`) | neuer `grok`-Start |
 | Resume | `/resume`, Welcome, `Ctrl+S` | `grok -r <id\|title>`, `grok -r` (latest), `grok -c` |
-| Fork | `/fork` | `--fork-session` mit resume |
+| Fork | `/fork [--worktree\|--no-worktree] [directive]` | `--fork-session` mit resume |
 | Rename | `/rename` / `/title` | – |
 | Dashboard | `/dashboard` (`/sessions`) | – |
 | Quit | `/quit` | Exit-Code Headless |
@@ -54,9 +57,10 @@ Basis: `~/.grok` bzw. `$GROK_HOME`. Sessions:
 grok sessions list
 grok sessions list --limit 50
 grok sessions search "rate limit"
+grok sessions delete <session-id>   # permanent (CLI); TUI: /delete oder /resume → d y
 ```

-`list` gruppiert oft nach Worktree-Label. Scripts: **IDs** bevorzugen, Titel sind case-insensitive und können kollidieren.
+`list` gruppiert oft nach Worktree-Label.

 ---

@@ -160,7 +164,7 @@ Index: SQLite FTS5 + optional Vektoren.
 - **Session-Ende:** schlanke Metadaten-Summary (Topics, Counts) – kein LLM, trivial Sessions skip. Abschalten: `session.save_on_end = false`.  
 - **`/flush`:** reichhaltige Extraktion (Decisions, Patterns) – vor Compact oder Tagesende.  
 - **`/dream`:** Konsolidierung in Topics.  
- **`/remember …`:** sofortige Notiz (auch ohne full memory stack in Teilen verfügbar – Guide: `/remember` always available).  
+- **`/remember …`:** sofortige Notiz (laut Doku auch ohne vollen Memory-Stack verfügbar).  

 ```text
 /remember staging deploy uses the eu-west cluster
@@ -168,7 +172,7 @@ Index: SQLite FTS5 + optional Vektoren.
 /dream
 ```

-**Policy:** Keine Secrets ins Memory. Falsche Erinnerungen aktiv löschen/korrigieren im `/memory`-UI. Memory ersetzt **nicht** AGENTS.md für Team-Standards.
+**Policy:** Keine Secrets ins Memory. Falsche Erinnerungen aktiv löschen/korrigieren im `/memory`-UI oder per CLI (`grok memory clear --workspace|--global|--all`, mit `--yes` ohne Prompt). Memory ersetzt **nicht** AGENTS.md für Team-Standards.

 ---

@@ -232,7 +236,7 @@ Vergleich: beide in einer Session mit nur Compact – wo driftet die Qualität?

 1. `grok sessions list` und eine alte Session resumieren.  
 2. `/context` und `/session-info` screenshot/notieren.  
-3. Einmal `/compact` mit spezfischem Keep-Hinweis.  
+3. Einmal `/compact` mit spezifischem Keep-Hinweis.  
 4. Einmal `/rewind` auf eine sichere Spielwiese (Git clean strategy).  
 5. Memory kurz enablen, `/remember` + neue Session, dann `--no-memory`.  
 6. Team-Regel skizzieren: wann new, wann compact, was in AGENTS.md vs. Memory.  
@@ -13,6 +13,8 @@ Ein Coding-Agent mit Shell und Netzwerk ist ein **Remote-gesteuerter Junior mit

 ### 13.2 Permission Modes

+Jeden Tool-Call entscheidet der **Mode**, *wie oft* du klickst – Rules entscheiden, *was nie geht*. Modes ohne Deny sind Komfort; Deny ohne Mode-Verständnis ist reines Rätselraten.
+
 | Mode | Verhalten | Alltag |
 |------|-----------|--------|
 | `default` / **ask** | Read-only oft frei; Rest fragt | interaktive TUI |
@@ -22,7 +24,7 @@ Ein Coding-Agent mit Shell und Netzwerk ist ein **Remote-gesteuerter Junior mit
 | `bypassPermissions` / **always-approve** | Tools laufen ohne Prompt* | CI, ACP, Automation |
 | `plan` | Compat-Name – echtes Plan Mode separat (Kap. 4) | – |

-\* **Deny-Regeln, Hooks und manche Shell-`ask`-Regeln greifen weiter** unter Always-approve.
+\* **Deny-Regeln und Hooks greifen weiter** unter Always-approve. Shell-`ask`-Segmente können weiter prompten; **non-Shell-`ask`** oft nicht – Details im User-Guide Permissions.

 Setzen:

@@ -72,6 +74,8 @@ Reihenfolge bei jedem Tool-Call:

 ### 13.4 Was default nie fragt (solange kein ask/deny)

+**Warum das zählt:** Ohne Segmentierung wäre jede Shell-Kette ein einziges Permission-Urteil – entweder nervt sie ständig oder sie ist gefährlich freizügig. Der Harness splittet Chains und erlaubt harmlose Teile, blockt riskante.
+
 **Tools u. a.:** `read_file`, `list_dir`, `grep`, `web_search`, `todo_write`, Subagent-Control, Skill-Invoke.

 **Shell-Segmente (word-boundary), u. a.:** `ls`, `cat`, `pwd`, `git status|diff|log|…`, `rg`/`grep` (ohne riskante Preprocessor), read-only `kubectl get|logs|describe`.
@@ -105,12 +109,15 @@ deny = [
  "Bash(rm -rf *)",
  "Bash(git push --force *)",
  "Bash(git push -f *)",
-  "Read(.env)",
-  "Read(.env.*)",
+  "Read(**/.env)",
+  "Read(**/.env.*)",
  "Read(secrets/**)",
+  "Read(**/secrets/**)",
 ]
 ```

+> **Matching:** Bare-Filename wie `Read(.env)` matcht nur den **exakten** String `.env` – nicht `subdir/.env`. Für Tiefe: `**/.env`. Pfade werden nicht kanonisiert; wo der Agent absolute Paths liest, zusätzlich absolute Patterns setzen.
+
 Oder strukturierte `rules = [{ action = "allow", tool = "bash", pattern = "git *" }, …]` (siehe aktuelle Doku-Syntax).

 #### Scopes
@@ -119,7 +126,7 @@ Oder strukturierte `rules = [{ action = "allow", tool = "bash", pattern = "git *
 |-------|-------|--------|
 | Global | `~/.grok/config.toml` | nein |
 | Project | `.grok/config.toml` | ja (commit) |
-| Personal im Projekt | `.claude/settings.local.json` | nein (gitignore) |
+| Personal im Projekt | `.claude/settings.local.json` | nein (gitignore; Claude-Compat-Pfad, von Grok nativ gelesen – kein Claude Code nötig) |
 | Interactive grants | intern, per project | nein |

 Discovery: `.grok/config.toml` von Root→CWD. **Global deny schlägt project allow.**
@@ -188,12 +195,12 @@ Unter workspace/read-only/strict: Kernel **write-deny** auf globale Hook-Pfade (
 [permission]
 deny = [
  "Bash(rm -rf *)",
-  "Bash(curl *| bash)",
-  "Bash(wget *| sh)",
+  "Bash(curl *)",
+  "Bash(wget *)",
  "Bash(git push --force *)",
  "Bash(git push -f *)",
-  "Read(.env)",
-  "Read(.env.*)",
+  "Read(**/.env)",
+  "Read(**/.env.*)",
  "Read(**/secrets/**)",
 ]
 allow = [
@@ -272,7 +279,7 @@ Frisches Demo-Repo mit project hook: ohne Trust still, mit `/hooks-trust` aktiv
 | Allow greift nicht | global deny / Pattern | Matching-Guide, `**` vs `*` |
 | Sandbox start fail | Hooks-Symlink / Policy | `/doctor`, Profile |
 | Netz in strict auf macOS | no-op child net | nicht auf macOS verlassen |
-| `.env` im Kontext | Read erlaubt | Deny Read(.env*) |
+| `.env` im Kontext | Read erlaubt | Deny `Read(**/.env)` (+ absolute Forms) |

 ---

@@ -21,6 +21,8 @@

 ### 14.2 Wo liegt was?

+Config greift nicht? Zuerst wissen, *welche Datei* und *welche Schicht* – `grok inspect` spart Rate-Orakel.
+
 | Pfad | Rolle |
 |------|--------|
 | `~/.grok/config.toml` | Haupt-User-Config |
@@ -41,7 +43,7 @@

 ### 14.3 config.toml – die nützlichen Sektionen

-Datei nur mit Overrides füllen; Defaults greifen sonst.
+Datei nur mit Overrides füllen; Defaults greifen sonst. **Heute typisch setzen:** Model-Default, Permission-Deny, ggf. MCP/Plugins. UI-Flags (`simple_mode`, `vim_mode`) und Experimente nur, wenn du sie brauchst.

 ```toml
 [cli]
@@ -126,7 +128,7 @@ TUI: `/model grok-build` (`/m`), Effort `/effort high`, Picker `Ctrl+M` (Scrollb
 default = "grok-4.5"
 ```

-Default-Hosted-Modelle brauchen keine Extra-Endpoint-Config – Auth per Login/Key (Kapitel 2). **IDs und Namen drift en** mit Releases; `grok models` und Picker sind Source of Truth.
+Default-Hosted-Modelle brauchen keine Extra-Endpoint-Config – Auth per Login/Key (Kapitel 2). **IDs und Namen driften** mit Releases; `grok models` und Picker sind Source of Truth.

 ---

@@ -140,7 +142,8 @@ model = "model-id"                         # Wire-ID an die API
 base_url = "https://api.example.com/v1"
 name = "Display Name"                      # Picker-Label
 api_backend = "chat_completions"           # oder responses | messages
-# api_key / env_key / extra_headers …
+env_key = "MY_MODEL_API_KEY"               # Key aus Env – nicht api_key in TOML committen
+# extra_headers = { … }
 ```

 | `api_backend` | Protokoll |
@@ -126,6 +126,8 @@ Then run tests/payments until green twice.
 **Ziel:** Severity-liste mit file:line.

 ```bash
+# --tools: interne Tool-IDs (Shell oft run_terminal_cmd).
+# --deny: Permission-Prefix Bash(...), siehe Kap. 10 und 13.
 grok -p "Review git diff origin/main...HEAD for bugs and security issues.
 Read-only. No edits, no commits, no network installs.
 Output: severity-ordered findings with file:line and short fix hint." \
@@ -214,14 +216,17 @@ Propose minimal fix OR revert recommendation. Do not push." \
  --always-approve \
  --cwd "$(pwd)" \
  --deny 'Bash(git push *)' \
+  --deny 'Bash(git push --force *)' \
  --max-turns 30 \
  --output-format json | jq -r '.text'
 ```

+**Policy dieses Jobs:** Writes und Commits sind erlaubt (minimaler Fix im Tree); **Push/Deploy bleiben blockiert**. Für Review-only siehe UC7 / Kap. 10 (Tool-Allowlist ohne Shell-Write).
+
 Interaktiv: `@/tmp/ci-fail.log` anhängen statt riesigem Paste (Kontext!).

 **DoD:** Eine Hypothese mit Evidenz; nächster Schritt klar.  
-**Fallen:** Ganzes Log in den Prompt; YOLO ohne Deny.
+**Fallen:** Ganzes Log in den Prompt; YOLO ohne Deny; unbemerktes Force-Push-Pattern.

 ---

@@ -3,6 +3,8 @@

 > **Kern in einem Satz:** Die meisten „Grok spinnt“-Tickets sind **Kontext-, Permission-, Trust-, Scope- oder Erwartungsprobleme** – gelöst mit Systematik, nicht mit lauteren Prompts.

+Stand der Fakten im Buch: **Juli–Aug 2026** (CLI **0.2.x**); UI-Labels und einzelne Commands können driften.
+
 **Schnellpfad Symptom → Fix:** [16.6](#16-6-symptom--fix).  
 **Prompt-Rezepte:** [16.2](#16-2-prompt-engineering-fuer-grok-build).

@@ -10,6 +12,8 @@

 ### 16.1 Best Practices – kompakt

+Alltag: Ticket, Diff, CI-Fail – die folgenden Blöcke decken den Großteil der Fälle. Details und Kanon sitzen in den Fachkapiteln; hier die kompakte Reprise.
+
 #### Prompts

 1. **Ziel + Nicht-Ziel + Verify** in jedem nicht-trivialen Auftrag  
@@ -51,7 +55,7 @@

 ### 16.2 Prompt-Engineering für Grok Build

-Grok Build ist ein **Agent mit Tools**, kein reiner Chat. Gute Prompts steuern den **Harness**.
+Grok Build ist ein **Agent mit Tools**, kein reiner Chat. Gute Prompts steuern den **Harness**. Englisch in Tool-Steuerung und DoD ist oft robuster – Formulierungen unten sind Copy-Paste, kein Stilbruch zum deutschsprachigen Buch.

 #### Schablone (Copy-Paste)

@@ -150,7 +154,7 @@ Verwirf Explore-Umwege und gescheiterte Zwischenversuche.
 ```text
 1. Symptom benennen (hängt / falscher Diff / ignoriert Regeln / Auth)
 2. Surface? TUI / -p / agent
-3. Mode? ask / plan / always-approve
+3. Mode? ask / auto / plan / always-approve (ggf. acceptEdits / dontAsk)
 4. grok inspect · /context · /session-info · /doctor
 5. CWD und geladene AGENTS.md/Rules
 6. Trust / MCP enabled?
@@ -167,7 +171,7 @@ Nicht parallel zehn Hebel drehen – eine Variable pro Versuch.
 | Symptom | Erste Checks | Fix |
 |---------|--------------|-----|
 | `grok: command not found` | PATH, neue Shell | Installer, `which grok` |
-| Login-Schleife | `auth.json`, Key-Vorrang | `grok logout && login` |
+| Login-Schleife | `auth.json`, Key-Vorrang | `grok logout && grok login` |
 | Key greift nicht | Session-Token aktiv | logout, nur `XAI_API_KEY` |
 | TUI Keys tot | Terminal/tmux | `/doctor`, `Ctrl+X` |
 | Hängt in CI | Permission ask | `--always-approve` + Deny |
@@ -186,7 +190,7 @@ Nicht parallel zehn Hebel drehen – eine Variable pro Versuch.
 | Falsches Modell | default/CLI | `/model`, `grok models` |
 | Config „tot“ | Precedence | Kap. 14 Debug-Flow |
 | Force-push im Diff | fehlende Deny | Deny + Review |
-| `.env` im Kontext | Read erlaubt | Deny Read(.env*) |
+| `.env` im Kontext | Read erlaubt | Deny `Read(**/.env)` (+ absolute Forms) |

 ---

@@ -3,7 +3,7 @@

 > **Kern in einem Satz:** Alle vier sind **agentische Coding-Werkzeuge** – sie unterscheiden sich in Surface, Policy-Modell, Ökosystem und Team-Fit; „das beste“ ist das, das **ihr steuern und reviewen** könnt.

-Vergleiche drift en mit Releases (Stand **Juli 2026**). Nutze die **Achsen**, nicht Marketing-Slogans. Primärquellen: jeweilige Produktdoku; dieses Kapitel orients für Entscheider und Power-User.
+Vergleiche driften mit Releases (Stand **Juli–Aug 2026**, Grok CLI **0.2.x**). Nutze die **Achsen**, nicht Marketing-Slogans. Primärquellen: jeweilige Produktdoku; dieses Kapitel orientiert für Entscheider und Power-User.

 ---

@@ -27,8 +27,8 @@ Vergleiche drift en mit Releases (Stand **Juli 2026**). Nutze die **Achsen**, ni

 #### Grok Build (`grok`)

- Terminal-TUI first (SpaceXAI/xAI), Headless `-p`, ACP `grok agent`  
- Regeln: `AGENTS.md`, `.grok/rules/`, starke Compat zu CLAUDE.md / Cursor  
+- Terminal-TUI first (xAI; Auth oft SpaceXAI-OAuth), Headless `-p`, ACP `grok agent`  
+- Regeln: `AGENTS.md`, `.grok/rules/`; Compat zu CLAUDE.md / Cursor über `[compat.*]` und `grok inspect` (Kapitel 14)  
 - Plan Mode mit Preview/Kommentaren, Subagents, Worktrees  
 - Skills, Hooks, Plugins/Marketplaces, MCP  
 - Config: `config.toml`, Sandbox-Profile, Folder-Trust  
@@ -70,6 +70,8 @@ Vergleiche drift en mit Releases (Stand **Juli 2026**). Nutze die **Achsen**, ni

 Legende: ● stark / etabliert · ◐ vorhanden / anders gelöst · ○ schwach oder nicht Fokus · ? stark versionsabhängig

+**Codex-Spalte:** bewusst unvollständig (`?`) – OpenAI-Codex-Surfaces und Policies driften schnell; kein Pseudo-Vergleich. Vor Rollout Primärdoku lesen (Stand 2026H2).
+
 | Fähigkeit | Grok Build | Claude Code | Codex | Cursor |
 |-----------|------------|-------------|-------|--------|
 | Interaktive Terminal-TUI | ● | ● | ◐/? | ○ (IDE) |
@@ -3,7 +3,7 @@

 > **Kern:** Spickzettel zum Nachschlagen beim Arbeiten – nicht Ersatz für die Kapitel 0–17.

-**So nutzen:** Im echten Repo offen halten. Befehl/Pfad suchen → bei Unklarheit ins Kapitel springen. UI-Labels können mit Releases driften (Stand **Juli 2026**); `grok --help`, `/` und User-Guide bleiben autoritativ.
+**So nutzen:** Im echten Repo offen halten. Befehl/Pfad suchen → bei Unklarheit ins Kapitel springen. UI-Labels können mit Releases driften (Stand **Juli–Aug 2026**, CLI **0.2.x**); `grok --help`, `/` und User-Guide bleiben autoritativ.

 ---

@@ -12,9 +12,9 @@
 | Plattform | Befehl |
 |-----------|--------|
 | macOS/Linux/WSL/Git Bash | `curl -fsSL https://x.ai/cli/install.sh \| bash` |
-| Version pinnen | `… \| bash -s 0.1.42` |
+| Version pinnen | `… \| bash -s 0.2.0` (Beispiel-Pin; `grok --version` / Release-Notes) |
 | Windows PowerShell | `irm https://x.ai/cli/install.ps1 \| iex` |
-| PS + Version | `$env:GROK_VERSION="0.1.42"; irm https://x.ai/cli/install.ps1 \| iex` |
+| PS + Version | `$env:GROK_VERSION="0.2.0"; irm https://x.ai/cli/install.ps1 \| iex` |

 ```bash
 grok --version
@@ -49,6 +49,7 @@ grok --rules "…"

 grok sessions list
 grok sessions search "keyword"
+grok sessions delete <id>
 grok inspect
 grok models
 ```
@@ -58,8 +59,8 @@ grok models
 | `/new` `/clear` | neue Session |
 | `/resume` | Session-Picker |
 | `/rename` | Titel |
-| `/fork [--worktree]` | verzweigen |
-| `/rewind` | Turn + Files zurück |
+| `/fork [--worktree\|--no-worktree]` | verzweigen |
+| `/rewind` (`/undo`) | Turn + Files zurück |
 | `/compact [hint]` | Kontext komprimieren |
 | `/context` | Fenster-Breakdown |
 | `/session-info` `/status` | Meta |
@@ -79,7 +80,7 @@ grok models
 | `--allow` / `--deny` | Rules |
 | `[permission]` in config | Allow/Deny Listen |

-**Pipeline:** Hooks → deny/ask/allow → remembered grants → built-in readonly → Mode.
+**Pipeline:** Hooks → **Deny > Ask > Allow** → remembered grants → built-in readonly → Mode.

 **Deny gewinnt immer** – auch unter Always-approve.

@@ -90,7 +91,7 @@ grok -p "…" --always-approve \
  --allow 'Bash(npm test *)'
 ```

-Sandbox: `--sandbox off|workspace|devbox|read-only|strict|custom`.  
+Sandbox: `--sandbox off|workspace|devbox|read-only|strict` (Built-ins) oder **Profilname** aus `sandbox.toml` (z. B. `--sandbox project`).  
 Trust: `/hooks-trust`, `--trust`, `~/.grok/trusted_folders.toml`.  
 Kapitel 4, 13.

@@ -103,6 +104,7 @@ Kapitel 4, 13.
 | `a` | Approve (+ comments) |
 | `s` | Request changes |
 | `c` | Comment on lines |
+| `y` | Plan in Clipboard |
 | `q` | Quit plan |
 | `Tab` | Preview ↔ Prompt |

@@ -124,14 +126,14 @@ Plan-Datei: `~/.grok/sessions/<encoded-cwd>/<id>/plan.md`.
 | `Ctrl+T` | Todos |
 | `Ctrl+G` | Tasks-Pane |
 | `Ctrl+B` | Command backgrounden |
-| `Ctrl+L` / `/plugins` | Extensions-Modal |
+| `Ctrl+L` / `/plugins` | Extensions-Modal\* |
 | `Ctrl+.` / `Ctrl+X` | Shortcuts-Hilfe |
 | `F2` | Settings |
 | `@` | Datei anhängen |
 | `!` | Shell-Mode |
 | `↑` | Prompt-History |

-\* Fullscreen+Vim: Esc cancelt oft nicht – `Ctrl+C`. Details: Kapitel 3.
+\* Fullscreen+Vim: Esc cancelt oft nicht – `Ctrl+C`. Auf VS-Code-Familie ist `Ctrl+L` oft **Interject** – Extensions dort über `/plugins` / `/hooks`. Details: Kapitel 3.

 ---

@@ -143,21 +145,25 @@ Plan-Datei: `~/.grok/sessions/<encoded-cwd>/<id>/plan.md`.
 | `/model` `/m` `/effort` | Modell |
 | `/always-approve` `/auto` | Permissions |
 | `/compact` `/context` | Kontext |
-| `/memory` `/flush` `/dream` `/remember` | Memory |
+| `/memory` `/flush` `/dream` `/remember` | Memory (default oft aus; `/flush`/`/dream`/`/memory` brauchen Opt-in – Kap. 12; `/remember` oft auch ohne) |
 | `/hooks` `/plugins` `/marketplace` `/skills` `/mcps` | Extensions |
 | `/config-agents` `/personas` | Agents |
 | `/doctor` | Diagnose |
 | `/goal` `/workflow` `/workflows` | Goals/Workflows |
+| `/dashboard` | Agent-Dashboard (Fullscreen) |
+| `/deep-research` | Background-Research-Workflow |
 | `/loop` | wiederkehrend |
 | `/btw` | Side-Question |
 | `/create-skill` | Skill bauen |
-| `/login` `/logout` `/usage` | Account |
+| `/login` `/logout` `/usage` `/privacy` | Account |
+| `/import-claude` | Claude-Settings importieren |
+| `/imagine` `/imagine-video` | Media Generation |
 | `/settings` `/theme` | UI |
 | `/copy` `/export` | Export |
 | `/minimal` `/fullscreen` `/vim-mode` | Render/Nav |
 | `/tutorial` `/docs` | Hilfe |

-Skills mit `user-invocable: true` → `/skill-name`. Qualifiziert: `/user:name`, `/repo:name`, `/plugin:name`.
+Skills mit `user-invocable: true` → `/skill-name`. Qualifiziert: `/local:name`, `/repo:name`, `/user:name`, oder `/<plugin-name>:skill`.

 ---

@@ -166,13 +172,15 @@ Skills mit `user-invocable: true` → `/skill-name`. Qualifiziert: `/user:name`,
 ```bash
 # Headless
 grok -p "prompt"
-grok -p "…" --output-format json|plain|streaming-json
+grok -p "…" --output-format plain|json|streaming-json|streaming-messages-json
+# partial deltas nur mit streaming-messages-json:
+#   --include-partial-messages
 grok -p "…" --tools "read_file,grep,list_dir"
 grok -p "…" --disallowed-tools "Agent,web_search"
 grok -p "…" --max-turns 30
 grok -p --prompt-file ./p.txt

-# ACP
+# ACP (Deny/Allow: [permission] in config – nicht als agent-CLI-Flag)
 grok agent --always-approve stdio
 grok agent --always-approve serve --bind 127.0.0.1:2419 --secret TOKEN
 ```
@@ -233,6 +241,8 @@ Kapitel 5–6.
 grok mcp list
 grok mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ./docs
 grok mcp add --transport http name https://… --header "Authorization: Bearer ${TOKEN}"
+grok mcp enable name
+grok mcp disable name
 grok mcp doctor
 grok mcp remove name
 ```
@@ -279,6 +289,7 @@ Kapitel 16.
 | Regeln greifen nicht | `grok inspect`, CWD |
 | Kontext drift | `/compact` hint / `/new` |
 | MCP tot | doctor, trust, enable |
+| `.env` im Kontext | Deny `Read(**/.env)` (+ absolute Forms) |
 | Keys tot in tmux | `/doctor`, `Ctrl+X` |

 Voll: Kapitel 16.6.
@@ -290,7 +301,12 @@ Voll: Kapitel 16.6.
 | Pfad | Inhalt |
 |------|--------|
 | [`vorlagen/AGENTS.md.minimal.md`](vorlagen/AGENTS.md.minimal.md) | Minimal-Regeln |
-| [`vorlagen/config.toml.beispiel.toml`](vorlagen/config.toml.beispiel.toml) | Config-Skizze |
+| [`vorlagen/AGENTS.md.team.md`](vorlagen/AGENTS.md.team.md) | Team-Baseline |
+| [`vorlagen/config.toml.beispiel.toml`](vorlagen/config.toml.beispiel.toml) | Config-Skizze (User/Project) |
+| [`vorlagen/config.permissions.toml`](vorlagen/config.permissions.toml) | Permissions-Minimum |
+| [`vorlagen/config.mcp.toml`](vorlagen/config.mcp.toml) | MCP-Snippets |
+| [`vorlagen/PLAN.md.skeleton.md`](vorlagen/PLAN.md.skeleton.md) | Plan-Skeleton |
+| [`vorlagen/hooks/`](vorlagen/hooks/), [`vorlagen/skills/`](vorlagen/skills/), [`vorlagen/plugins/`](vorlagen/plugins/) | Hooks, Verify, Plugin-Baseline |
 | [`beispiele/`](beispiele/) | Mitmach-Index |
 | [`ADAPTIONEN.md`](ADAPTIONEN.md) | Schwesterprojekt-Mapping |

@@ -1,12 +1,17 @@
-# ADAPTIONEN – Schwesterprojekt `../ki-claude` → `ki-grok`
+# ADAPTIONEN – Schwesterprojekte → `ki-grok`

-Dieses Dokument hält fest, was aus dem Claude-Code-Buch (**Der Claude-Code-Harness**, `../ki-claude`) übernommen und was für **Grok Build** bewusst angepasst wurde. Ziel: beide Bücher bleiben als Schwesterprojekte erkennbar, ohne Produktgrenzen zu verwischen.
+Dieses Dokument hält fest, was aus den Schwesterbüchern übernommen und was für **Grok Build** bewusst angepasst wurde. Ziel: die Bücher bleiben als Familie erkennbar, ohne Produktgrenzen zu verwischen.

-Stand der Adaption: **Juli 2026**.
+| Quelle | Titel (kurz) |
+|--------|----------------|
+| `../ki-claude` | Der Claude-Code-Harness |
+| `../ki-codex` | Der Codex-Harness |
+
+Stand der Adaption: **August 2026**.

 ---

-## 1. Übernommen (1:1 oder nur umbenannt)
+## 1. Übernommen aus `ki-claude` (1:1 oder nur umbenannt)

 ### Struktur und Build

@@ -34,7 +39,7 @@ Stand der Adaption: **Juli 2026**.
 | Platzhalter `YOUR_TOKEN`, `your-project` | ja |
 | Mindestens 2–3 konkrete Beispiele pro Kapitel | ja (Ziel; ab gefüllten Kapiteln) |

-### Autoren-Harness
+### Autoren-Harness (Claude-Linie)

 | Element | Übernahme |
 |---------|-----------|
@@ -47,7 +52,52 @@ Stand der Adaption: **Juli 2026**.

 ---

-## 2. Bewusst angepasst
+## 2. Übernommen aus `ki-codex` (August 2026)
+
+Harness- und Vorlagen-Dichte aus dem Codex-Buch, **Keys und Terminologie Grok-nativ**.
+
+### Autoren-Harness
+
+| Element | Übernahme / Anpassung |
+|---------|------------------------|
+| Skill `humanizer` + Marker-Katalog | ja – Kapitel 00–18, Grok-Terminologie; **kein** Vergleichs-Verbot (Kap. 17 ist Curriculum) |
+| Skill + Command `update-pics` | ja – Drop-Zone **`bilder/`** + `scripts/convert_illustrations.py` (Codex: `pics/` + eigenes Skript) |
+| AGENTS: Skills/Commands-Liste, Vier Hebel | ja – Hebel Grok-formuliert (Permissions / Always-approve) |
+| AGENTS: Schwesterprojekte | `ki-claude` **und** `ki-codex` |
+| Schreibregeln: Abschnitt **Reprise** | ja – max. 2–3 Signale/Kapitel; Kap. 18 Lookup ohne Brücken |
+| Root-`.gitignore` Python-Caches | `*.pyc`, egg-info, pytest/ruff-Caches |
+| justfile `_resource_path` | ja (ohne Codex-Screenshots-Pfad) |
+| `pdf-bauen` QA-Text | an `check_pdf.py` angeglichen (40–280; Keywords AGENTS.md / config.toml) |
+
+### Leser-Vorlagen (Parität, Grok-Syntax)
+
+| Codex-Vorlage | Grok-Pendant |
+|---------------|--------------|
+| `AGENTS.md.team.md` | `vorlagen/AGENTS.md.team.md` |
+| `config.permissions.toml` | `vorlagen/config.permissions.toml` (`[permission]`) |
+| `config.mcp.toml` | `vorlagen/config.mcp.toml` (`[mcp_servers.*]`) |
+| Hooks Guard/Format | `vorlagen/hooks/*.example.json` + `scripts/` (jq/decision-JSON) |
+| `PLAN.md.skeleton.md` | `vorlagen/PLAN.md.skeleton.md` |
+| `skills/verify`, `agents/security-reviewer` | `vorlagen/skills/`, `vorlagen/agents/` |
+| `plugins/team-baseline` | `vorlagen/plugins/team-baseline/` (validate-Hinweis) |
+| `user/AGENTS.md` | `vorlagen/user/` (Pfad `~/.grok/`, nicht `~/.codex/`) |
+| `beispiele/configs/config.repo…` | `beispiele/configs/config.project.beispiel.toml` |
+
+`vorlagen/config.toml.beispiel.toml` war schema-falsch (`[[mcp.servers]]`, `model =`) und wurde an Kap. 14 / User-Guide korrigiert.
+
+### Bewusst **nicht** aus Codex
+
+| Codex-Element | Grund |
+|---------------|--------|
+| `sandbox_mode` / `approval_policy` | Grok: `permission_mode`, `sandbox.toml`, `[permission]` |
+| Screenshot-Capture-Pipeline | kein SCREEN-Inventar in diesem Buch |
+| Verbot Feature-Vergleiche | Kapitel 17 ist Teil des Curriculums |
+| Drop-Zone `pics/` | Kanon hier: `bilder/` |
+| todo-cli ersetzen | Grok-`beispiele/todo-cli/` inkl. `.grok/` ist vollständiger |
+
+---
+
+## 3. Bewusst angepasst (Curriculum & Produkt)

 ### Kapitel-Curriculum

@@ -59,13 +109,13 @@ Stand der Adaption: **Juli 2026**.

 ### Produkt-Terminologie

-| Claude-Welt | Grok-Welt |
-|-------------|-----------|
-| Claude Code | **Grok Build** (`grok`) |
-| `CLAUDE.md` (Leser-Kerndatei) | **`AGENTS.md`** (+ Nested Rules, optional `CLAUDE.md`-Kompatibilität) |
-| `settings.json` | **`config.toml`** (`~/.grok/config.toml`) |
-| Workspace Trust / allow-deny-ask (Claude-Modell) | Permissions, Sandbox, Modes (Normal / Plan / Always-approve) – **Grok-Modell** |
-| Surfaces: Terminal, IDE, Desktop, Web | Surfaces: **TUI**, **Headless** (`grok -p`), **ACP** (`grok agent`) |
+| Claude-Welt | Codex-Welt (Auszug) | Grok-Welt |
+|-------------|---------------------|-----------|
+| Claude Code | OpenAI Codex / `codex` | **Grok Build** (`grok`) |
+| `CLAUDE.md` (Leser-Kerndatei) | `AGENTS.md` | **`AGENTS.md`** (+ Nested Rules, optional `CLAUDE.md`-Kompatibilität) |
+| `settings.json` | `config.toml` (Sandbox/Approvals) | **`config.toml`** (`~/.grok/`, Project `.grok/`) |
+| allow-deny-ask | sandbox × approval_policy | Permissions, Sandbox, Modes (Normal / Plan / Always-approve) |
+| Surfaces: Terminal, IDE, Desktop, Web | CLI, IDE, App/Web, Cloud | **TUI**, **Headless** (`grok -p`), **ACP** (`grok agent`) |

 ### Strukturelle Abweichungen vom User-Rohentwurf

@@ -77,26 +127,25 @@ Der Auftrag nannte u. a. `book/` und `examples/`. Zugunsten der Schwesterproje

 ### PDF-Metadaten

-| | Claude | Grok |
-|-|--------|------|
-| Dateiname | `dist/claude-code-harness.pdf` | `dist/grok-build-praxisleitfaden.pdf` |
-| Titel | Der Claude-Code-Harness | Grok Build – Der umfassende Praxisleitfaden |
-| Soft-Seitenzahl QA | 30–120 | 40–280 (19 Kapitel) |
+| | Claude | Codex | Grok |
+|-|--------|-------|------|
+| Dateiname | `dist/claude-code-harness.pdf` | `dist/codex-harness.pdf` | `dist/grok-build-praxisleitfaden.pdf` |
+| Soft-Seitenzahl QA | 30–120 | ähnlich schlank | 40–280 (19 Kapitel) |

 ### Was (noch) nicht mitgenommen wurde

-| Element im Claude-Buch | Status hier |
-|------------------------|-------------|
-| Vollständiges `beispiele/todo-cli/` inkl. App-Code | später (Phase 2+); vorerst Index + Vorlagen |
-| Illustrationen unter `assets/illustrations/` + `prompts/gemini/` | **übernommen (Grok-Inventar)** — siehe `abbildungen.md`; Assets nach Gemini-Generierung |
-| `.claude/` Autoren-Settings/Hooks | optional dual; Phase 1 fokussiert `.grok/` |
+| Element | Status hier |
+|---------|-------------|
+| Vollständiges `beispiele/todo-cli/` inkl. App-Code + `.grok/` | **vorhanden** (reicher als Codex-Minimal) |
+| Illustrationen unter `assets/illustrations/` + `prompts/gemini/` | Inventar + Prompts; Assets nach Gemini → `bilder/` → convert |
+| Screenshot-Pipeline à la Codex | optional später; nicht im Scope der Codex-Config-Übernahme |
 | Abbildungskatalog `abbildungen.md` | **vorhanden** (24 Figuren + Cover; 22 im Body) |

 ---

-## 3. Faktenquellen (Grok Build)
+## 4. Faktenquellen (Grok Build)

-Primär für Manuskript-Fakten (Stand Juli 2026):
+Primär für Manuskript-Fakten (Stand Juli–Aug 2026, CLI **0.2.x**):

 - Lokaler User-Guide: `~/.grok/docs/user-guide/` (Getting Started, Auth, TUI, Plan Mode, Subagents, MCP, Skills, Hooks, Headless, ACP, Sandbox, Permissions, …)
 - CLI: `grok --version`, `grok update`, `grok -p`, `grok agent`
@@ -106,19 +155,20 @@ Keine erfundenen Slash-Commands oder Config-Keys. Bei UI-Drift: Stand des Buchs

 ---

-## 4. Kurz-Checkliste für künftige Kapitel
+## 5. Kurz-Checkliste für künftige Kapitel

 Wenn du ein neues Kapitel schreibst oder lektorierst:

-1. Ton und Callouts wie `../ki-claude` / `.grok/rules/schreibkonventionen.md`  
-2. Grok-Terminologie aus `AGENTS.md` (nicht Claude-Jargon mischen)  
+1. Ton und Callouts wie Schwesterprojekte / `.grok/rules/schreibkonventionen.md`  
+2. Grok-Terminologie aus `AGENTS.md` (nicht Claude-/Codex-Jargon mischen – außer Kap. 17)  
 3. ≥ 2–3 Sessions/Configs/Prompts, wo das Feature es hergibt  
 4. Querverweise auf Kapitelnummern **dieses** Buchs (00–18)  
 5. Nach größeren Blöcken: Checkliste, häufige Fehler, „So baust du das nach“  
 6. Keine Secrets; Platzhalter  
+7. Reprise der Vier Hebel nur am Gelenk (max. 2–3 / Kapitel)

 ---

-## 5. Schwesterprojekt-Hinweis für Leser
+## 6. Schwesterprojekt-Hinweis für Leser

-Beide Bücher teilen denselben **Lese- und Autoren-Stil**. Wer `ki-claude` kennt, findet in `ki-grok` dieselben Kästen, denselben Abschluss-Rhythmus und dieselbe PDF-Pipeline – mit einem anderen Agenten und einem feiner aufgespaltenen Inhaltsverzeichnis.
+Die Bücher teilen denselben **Lese- und Autoren-Stil**. Wer `ki-claude` oder `ki-codex` kennt, findet in `ki-grok` dieselben Kästen, denselben Abschluss-Rhythmus und dieselbe PDF-Pipeline – mit einem anderen Agenten und (gegenüber Claude) einem feiner aufgespaltenen Inhaltsverzeichnis.
@@ -10,7 +10,7 @@ Projekt-Regeln für Coding-Agents. Karpathy-Prinzipien, adaptiert auf ein deutsc

 - Annahmen explizit machen. Bei Unsicherheit: **nachfragen**.
 - Fakten zu Grok Build: User-Guide (`~/.grok/docs/user-guide/`), CLI und dieses Repo – **nicht raten**.
- Bei Versionsangaben: Stand des Buchs (**Juli / Mitte 2026**) nennen; UI-Details können driftieren.
+- Bei Versionsangaben: Stand des Buchs (**Juli–Aug 2026**, CLI **0.2.x**) nennen; UI-Details können driftieren.

 ## 2. Einfachheit zuerst

@@ -23,6 +23,7 @@ Projekt-Regeln für Coding-Agents. Karpathy-Prinzipien, adaptiert auf ein deutsc
 - Nur anfassen, was der Task verlangt.
 - Bestehenden Ton treffen: erfahrener Kollege, präzise, geduldig.
 - Beispiel-Configs und Terminal-Sessions lauffähig und kommentiert halten.
+- Platzhalter statt Secrets: `YOUR_TOKEN`, `your-project`, `xai-…`.

 ## 4. Zielgetrieben

@@ -40,10 +41,14 @@ Projekt-Regeln für Coding-Agents. Karpathy-Prinzipien, adaptiert auf ein deutsc

 **Ton:** erfahrener Kollege – präzise, geduldig, ohne Hype. Wenn etwas riskant ist, steht das da.

-**Schwesterprojekt:** `../ki-claude` (Claude Code). Stil und Pipeline konsistent halten; Produktlogik nicht vermischen. Siehe `ADAPTIONEN.md`.
+**Schwesterprojekte:** `../ki-claude` (Claude Code), `../ki-codex` (Codex-Harness). Stil und Pipeline konsistent halten; **Produktlogik nicht vermischen**. Siehe `ADAPTIONEN.md`.

 **Autoren-Harness vs. Leser-Vorlagen:** Root-`AGENTS.md` / `CLAUDE.md` / `.grok/` steuern **Agenten, die am Buch arbeiten**. `vorlagen/` und `beispiele/` sind **Content für Leser** – nicht mit dem Autoren-Harness vermischen.

+**Autoren-Skills (`.grok/skills/`):** `pdf-bauen`, `lektorat`, `kapitel-review`, `humanizer`, `update-pics`. Slash-Commands: `.grok/commands/` (`/pdf`, `/lektorat`, `/review`, `/status`, `/update-pics`). Schreib- und Build-Details: `.grok/rules/`.
+
+**Intern (nicht Manuskript):** `prompts/` ist Autoren-Material.
+
 ### Source of Truth (editieren)

 | Pfad | Rolle | Agent-Hinweis |
@@ -117,6 +122,13 @@ PDF nur bauen, wenn der Task es verlangt (nach inhaltlichen Änderungen oder exp
 | Headless | `grok -p` / nicht-interaktive Läufe |
 | ACP | Agent Client Protocol – IDE/Server-Modus (`grok agent`) |

+### Vier Hebel (max. 2–3 Reprisen pro Kapitel, am Gelenk)
+
+1. Scope eng halten  
+2. Diff lesen vor Merge/Commit  
+3. Enge Permissions / Deny **vor** Always-approve  
+4. Weich (`AGENTS.md`) vs. hart (`[permission]`, Hooks, Sandbox)
+
 ### Nicht ohne Auftrag anfassen

 - `pdf/templates/*`, `pdf/filters/*`, `pdf/styles/*` (Layout-Pipeline)
@@ -128,7 +140,7 @@ PDF nur bauen, wenn der Task es verlangt (nach inhaltlichen Änderungen oder exp

 - Primärquelle: `~/.grok/docs/user-guide/` und aktuelle CLI-Hilfe
 - Keine erfundenen Slash-Commands, TOML-Keys oder CLI-Flags
- Bei Unsicherheit: Unsicherheit benennen und Stand des Buchs (Juli 2026) angeben
+- Bei Unsicherheit: Unsicherheit benennen und Stand des Buchs (Juli–Aug 2026) angeben
 - Keine Secrets in Beispielen; Platzhalter `YOUR_TOKEN`, `your-project`, `xai-…`

 ---
@@ -2,7 +2,7 @@

 This file provides guidance to Claude Code (and compatible agents) when working in this repository.

-Dies ist ein **deutschsprachiges Praxisbuch** über Grok Build – kein App-Stack. Prinzipien und Qualitätsregeln: `AGENTS.md`. Adaptionen aus dem Schwesterprojekt: `ADAPTIONEN.md`.
+Dies ist ein **deutschsprachiges Praxisbuch** über Grok Build – kein App-Stack. Prinzipien und Qualitätsregeln: `AGENTS.md`. Adaptionen aus den Schwesterprojekten (`ki-claude`, `ki-codex`): `ADAPTIONEN.md`.

 ## Build & QA

@@ -46,9 +46,9 @@ PDF nur bauen, wenn der Task es verlangt. Nach dem Build bei Bedarf `just qa`.
 ## Agent notes

 - Bei Unklarheit: nachfragen statt raten. Fakten: `~/.grok/docs/user-guide/` + dieses Repo.
- Stand der Fakten im Buch: **Juli / Mitte 2026** – UI-Labels können driften.
+- Stand der Fakten im Buch: **Juli–Aug 2026** (CLI **0.2.x**) – UI-Labels können driften.
 - Chirurgische Edits: nur Task-relevante Stellen; Ton „erfahrener Kollege“.
 - Keine erfundenen npm/poetry/React-Stacks für dieses Repo.
 - `pdf/templates/*`, `pdf/filters/*`, `pdf/styles/*` nur bei explizitem Auftrag.
 - Plan vor größeren Mehrdatei-Änderungen; Erfolgskriterien prüfbar formulieren.
- Details: `.grok/rules/`; Skills für PDF/Lektorat/Review.
+- Details: `.grok/rules/`; Skills: `pdf-bauen`, `lektorat`, `kapitel-review`, `humanizer`, `update-pics`.
@@ -2,7 +2,7 @@

 **Titel:** *Grok Build – Der umfassende Praxisleitfaden. Der Coding-Agent von xAI richtig einsetzen*

-Praxisbuch (Deutsch) über **Grok Build**: den Coding-Agenten von xAI/SpaceXAI – interaktive TUI, Headless/CI, ACP und die Steuerknöpfe drumherum (Plan Mode, Subagents, Worktrees, `AGENTS.md`, Skills, MCP, Permissions). Stand der Fakten: **Juli / Mitte 2026**.
+Praxisbuch (Deutsch) über **Grok Build**: den Coding-Agenten von xAI/SpaceXAI – interaktive TUI, Headless/CI, ACP und die Steuerknöpfe drumherum (Plan Mode, Subagents, Worktrees, `AGENTS.md`, Skills, MCP, Permissions). Stand der Fakten: **Juli–Aug 2026** (CLI **0.2.x**).

 Stil: klar, unaufgeregt, praxisnah – analog zum Schwesterprojekt [`../ki-claude`](../ki-claude) (*Der Claude-Code-Harness*). Kein Marketing, keine leeren Versprechen. Konzepte → Sessions → nachbaubare Configs.

@@ -78,10 +78,17 @@ Illustrationen: Katalog und Workflow in [`abbildungen.md`](abbildungen.md); Prom
 | Pfad | Inhalt |
 |------|--------|
 | [`vorlagen/AGENTS.md.minimal.md`](vorlagen/AGENTS.md.minimal.md) | Minimale Projekt-AGENTS.md |
-| [`vorlagen/config.toml.beispiel.toml`](vorlagen/config.toml.beispiel.toml) | Beispiel-Ausschnitte für `config.toml` |
+| [`vorlagen/AGENTS.md.team.md`](vorlagen/AGENTS.md.team.md) | Team-Baseline-AGENTS.md |
+| [`vorlagen/config.toml.beispiel.toml`](vorlagen/config.toml.beispiel.toml) | User/Project-Config-Ausschnitte |
+| [`vorlagen/config.permissions.toml`](vorlagen/config.permissions.toml) | `[permission]` Allow/Deny-Minimum |
+| [`vorlagen/config.mcp.toml`](vorlagen/config.mcp.toml) | MCP-Server-Skizzen (`[mcp_servers.*]`) |
+| [`vorlagen/PLAN.md.skeleton.md`](vorlagen/PLAN.md.skeleton.md) | Plan-Mode-Skeleton |
+| [`vorlagen/hooks/`](vorlagen/hooks/) | Hook-JSON + Scripts (Guard, Format) |
+| [`vorlagen/skills/`](vorlagen/skills/), [`vorlagen/agents/`](vorlagen/agents/), [`vorlagen/plugins/`](vorlagen/plugins/) | Verify-Skill, Security-Agent, Plugin-Baseline |
+| [`vorlagen/user/`](vorlagen/user/) | Persönliche User-AGENTS-Skizze |
 | [`beispiele/`](beispiele/) | Index der Mitmach-Beispiele |
 | [`beispiele/todo-cli/`](beispiele/todo-cli/) | Mini-Python-CLI inkl. `AGENTS.md` und `.grok/`-Harness |
-| [`beispiele/configs/`](beispiele/configs/) | GHA-Review-Gerüst, MCP-Snippets |
+| [`beispiele/configs/`](beispiele/configs/) | GHA-Review, Project-Config, MCP-Snippets |

 ---

@@ -100,7 +107,7 @@ Illustrationen: Katalog und Workflow in [`abbildungen.md`](abbildungen.md); Prom
 ## Quellen und Aktualität

 Primärquelle: Grok-Build-User-Guide (lokal unter `~/.grok/docs/user-guide/`) und die CLI-Hilfe.  
-Installationswege, Config-Keys und Slash-Commands können sich mit Releases ändern. Bei Abweichungen gilt die aktuelle Doku; dieses Buch nennt den **Stand Juli 2026** und erklärt die stabilen Konzepte dahinter.
+Installationswege, Config-Keys und Slash-Commands können sich mit Releases ändern. Bei Abweichungen gilt die aktuelle Doku; dieses Buch nennt den **Stand Juli–Aug 2026** und erklärt die stabilen Konzepte dahinter.

 Übernahmen aus dem Claude-Code-Schwesterprojekt: [`ADAPTIONEN.md`](ADAPTIONEN.md).

@@ -5,7 +5,7 @@ Mitmach-Material zum Buch *Grok Build – Der umfassende Praxisleitfaden*.
 | Pfad | Inhalt | Status |
 |------|--------|--------|
 | [`todo-cli/`](todo-cli/) | Mini-Python-CLI inkl. `AGENTS.md`, `.grok/` (config, rules, skill, hooks) | bereit |
-| [`configs/`](configs/) | Headless/CI- und MCP-Gerüste | wachsend |
+| [`configs/`](configs/) | Headless/CI, Project-config, MCP-Gerüste | wachsend |

 ## Schnellstart todo-cli

@@ -0,0 +1,24 @@
+# Beispiel: Project .grok/config.toml (nach Folder-Trust).
+# Team-commitbar. Keine Secrets. Stand: Juli–Aug 2026.
+
+[permission]
+allow = [
+  "Bash(pytest *)",
+  "Bash(ruff *)",
+  "Bash(git status *)",
+  "Bash(git diff *)",
+]
+deny = [
+  "Bash(rm -rf *)",
+  "Bash(curl *)",
+  "Bash(wget *)",
+  "Read(**/.env)",
+  "Read(**/.env.*)",
+  "Read(**/secrets/**)",
+]
+
+# Optional MCP nur project-scoped (ersetzt User-Server gleichen Namens):
+# [mcp_servers.docs-fs]
+# command = "npx"
+# args = ["-y", "@modelcontextprotocol/server-filesystem", "./docs"]
+# enabled = true
@@ -5,6 +5,9 @@

 default: pdf

+# resource-path: illustrations + cover (+ content roots)
+_resource_path := ".:beispiele:vorlagen:assets:assets/illustrations:assets/cover"
+
 assemble:
    @python3 scripts/assemble_book.py

@@ -17,7 +20,7 @@ pdf-styled: assemble
        -H pdf/styles/guide-colors.tex \
        --metadata-file=pdf/metadata.yaml \
        --lua-filter=pdf/filters/tables.lua \
-        --resource-path=.:beispiele:vorlagen:assets:assets/illustrations:assets/cover \
+        --resource-path={{_resource_path}} \
        -V lang=de-DE \
        -V papersize=a4 \
        -V colorlinks \
@@ -34,7 +37,7 @@ pdf-draft: assemble
        -H pdf/styles/guide-colors.tex \
        --metadata-file=pdf/metadata.yaml \
        --lua-filter=pdf/filters/tables.lua \
-        --resource-path=.:beispiele:vorlagen:assets:assets/illustrations:assets/cover \
+        --resource-path={{_resource_path}} \
        -V lang=de-DE \
        -V papersize=a4 \
        -V colorlinks \
@@ -50,7 +53,7 @@ pdf-plain: assemble
        -V lang=de-DE \
        -V papersize=a4 \
        --lua-filter=pdf/filters/tables.lua \
-        --resource-path=.:beispiele:vorlagen:assets:assets/illustrations:assets/cover \
+        --resource-path={{_resource_path}} \
        --toc \
        -o dist/grok-build-praxisleitfaden-plain.pdf

@@ -0,0 +1,36 @@
+# Team baseline — AGENTS.md
+
+## Stack & conventions
+
+- (Sprache, Package-Manager, Branch-Strategie)
+- Public APIs dokumentieren, wenn Verhalten ändert
+
+## Build & Test
+
+- `…` install
+- `…` test
+- `…` lint
+
+## Always
+
+- Scope eng halten; Multi-File nur mit Plan Mode (`/plan`), wenn Architektur unklar
+- Diff und Tests vor PR
+- Secrets nie committen
+
+## Never
+
+- Force-push auf shared branches
+- Production credentials im Workspace für den Agent
+- Always-approve / YOLO in geteilten oder sensiblen Repos ohne Team-Policy
+- Auto-merge ohne menschliche Review
+
+## Code Review Rules
+
+### Secrets and config
+
+- Flag hardcoded credentials, API keys, and private URLs in diffs.
+  Safe path: env vars / secret manager; document required keys in README without values.
+
+### Scope
+
+- Prefer small, reviewable diffs; no drive-by refactors outside the task.
@@ -0,0 +1,38 @@
+# Plan: <!-- kurzer Feature-Titel -->
+
+**Status:** draft | approved | done  
+**Session:** <!-- optional Session-ID oder Datum -->
+
+## Ziel
+
+<!-- Ein Absatz: was soll am Ende wahr sein? -->
+
+## Nicht-Ziele
+
+- …
+
+## Schritte
+
+1. [ ] Explore: …
+2. [ ] Tests/Contract: …
+3. [ ] Implementierung: …
+4. [ ] Verify: …
+5. [ ] Diff + Commit-Message-Entwurf: …
+
+## Betroffene Dateien
+
+| Pfad | Änderung |
+|------|----------|
+| | |
+
+## Risiken
+
+| Risiko | Mitigierung |
+|--------|-------------|
+| | Diff lesen; enge Permissions / Deny |
+
+## Done when
+
+- [ ] Tests grün
+- [ ] Keine Secrets im Diff
+- [ ] Kurze Zusammenfassung für Reviewer
@@ -0,0 +1,20 @@
+---
+name: security-reviewer
+description: Read-only security pass for diffs. Use before merge.
+---
+
+# Security reviewer
+
+You review changes only. Do not edit files.
+
+## Focus
+
+- Hardcoded secrets, tokens, private URLs
+- Path traversal or unexpected file writes
+- Shell injection if args reach subprocesses
+- Destructive operations in scripts/hooks
+- Over-broad permission allow rules
+
+## Output
+
+Severity-ordered findings with file:line. If clean, say so explicitly.
@@ -0,0 +1,26 @@
+# MCP-Server-Beispiele für ~/.grok/config.toml oder trusted .grok/config.toml
+# Schema: [mcp_servers.<name>]  — nicht [[mcp.servers]]
+# Secrets nur als ${VAR} / Env, nie committen.
+# CLI-Alternative: grok mcp add … / grok mcp list
+# Stand: Juli–Aug 2026 — Keys bei Drift im User-Guide MCP prüfen.
+
+# stdio (lokaler Prozess)
+# [mcp_servers.filesystem]
+# command = "npx"
+# args = ["-y", "@modelcontextprotocol/server-filesystem", "/absolute/path"]
+# enabled = true
+# startup_timeout_sec = 120
+
+# [mcp_servers.github]
+# command = "npx"
+# args = ["-y", "@modelcontextprotocol/server-github"]
+# env = { GITHUB_PERSONAL_ACCESS_TOKEN = "${GITHUB_TOKEN}" }
+
+# HTTP / remote
+# [mcp_servers.example_remote]
+# url = "https://example.com/mcp"
+# headers = { Authorization = "Bearer ${YOUR_TOKEN}" }
+
+# Tool-Result-Größe (optional)
+# [mcp]
+# max_output_bytes = 40000
@@ -0,0 +1,32 @@
+# Enge Permission-Baseline für Project- oder User-Config.
+# Primär: .grok/config.toml (team-commitbar) oder ~/.grok/config.toml
+# Stand: Juli–Aug 2026 — Pattern gegen aktuelle Doku prüfen.
+#
+# Deny schlägt Allow und greift auch unter always-approve (siehe Kapitel 13).
+
+[permission]
+allow = [
+  "Bash(pytest *)",
+  "Bash(python -m pytest *)",
+  "Bash(python3 -m pytest *)",
+  "Bash(ruff *)",
+  "Bash(git status *)",
+  "Bash(git diff *)",
+  "Bash(git log *)",
+  "Bash(git branch *)",
+]
+deny = [
+  "Bash(rm -rf *)",
+  "Bash(curl *)",
+  "Bash(wget *)",
+  "Bash(git push --force *)",
+  "Bash(git push -f *)",
+  "Read(**/.env)",
+  "Read(**/.env.*)",
+  "Read(**/secrets/**)",
+]
+
+# Optional UI-Default (meist user-global in ~/.grok/config.toml):
+# [ui]
+# permission_mode = "ask"
+# default_selected_permission = "allow_once"
@@ -1,20 +1,103 @@
-# Beispiel-Ausschnitte — ~./.grok/config.toml oder projektspezifische Config
-# Keine echten Secrets. Stand: Juli 2026 (Keys können mit Releases driften).
+# Beispiel-Ausschnitte — ~/.grok/config.toml (User) bzw. team-sharebare
+# Teile in <repo>/.grok/config.toml (Project: vor allem MCP, Plugins, permission).
+#
+# Keine echten Secrets. Stand: Juli–Aug 2026 (CLI 0.2.x) — Keys können driften.
+# Source of Truth: grok models / User-Guide Configuration; nur Overrides setzen.

-# Modell (Beispiel — verfügbare IDs in der CLI / Doku prüfen)
-# model = "grok-4"
+# ---------------------------------------------------------------------------
+# User-global (häufig in ~/.grok/config.toml)
+# ---------------------------------------------------------------------------

-# Memory (falls genutzt)
-# [memory]
+[cli]
+# auto_update = true
+
+[models]
+# default = "grok-4.5"          # grok models = Source of Truth
+# web_search = "grok-4.5"
+
+[ui]
+# permission_mode = "ask"       # ask | auto | always-approve | …
+# default_selected_permission = "allow_once"  # sicherer Start der Prompt-Zeile
+# remember_tool_approvals = false
+# simple_mode = true
+# vim_mode = false
+# screen_mode = "fullscreen"    # oder minimal
+# show_thinking_blocks = true
+
+[features]
+# telemetry = false
+# codebase_indexing = true
+# remote_fetch = true           # false in air-gap
+# lsp_tools = false
+
+[session]
+# auto_compact_threshold_percent = 85
+# load_envrc = true
+
+[tools]
+# respect_gitignore = false
+
+[memory]
+# enabled = false
+
+[subagents]
 # enabled = true

-# Subagents
-# [subagents]
-# enabled = true
+# Fremde Claude-/Cursor-Skills/MCP still abschalten (wenn sie spuken):
+# [compat.claude]
+# skills = false
+# rules = false
+# hooks = false
+# mcps = false
+#
+# [compat.cursor]
+# skills = false
+# rules = false
+# hooks = false
+# mcps = false

-# MCP-Server (Beispiel-Struktur — konkrete Keys der aktuellen Doku entnehmen)
-# [[mcp.servers]]
-# name = "github"
+# ---------------------------------------------------------------------------
+# MCP — Schema: [mcp_servers.<name>]  (NICHT [[mcp.servers]])
+# User: ~/.grok/config.toml · Project: .grok/config.toml (nach Folder-Trust)
+# Secrets als ${VAR}, nie hardcoded committen. Details: vorlagen/config.mcp.toml
+# ---------------------------------------------------------------------------
+
+# [mcp_servers.github]
 # command = "npx"
 # args = ["-y", "@modelcontextprotocol/server-github"]
-# env = { GITHUB_PERSONAL_ACCESS_TOKEN = "YOUR_TOKEN" }
+# env = { GITHUB_PERSONAL_ACCESS_TOKEN = "${GITHUB_TOKEN}" }
+# enabled = true
+# startup_timeout_sec = 120
+
+# [mcp]
+# max_output_bytes = 40000
+
+# ---------------------------------------------------------------------------
+# Permissions — oft project-commitbar in .grok/config.toml
+# Siehe vorlagen/config.permissions.toml und Kapitel 13
+# ---------------------------------------------------------------------------
+
+# [permission]
+# allow = [
+#   "Bash(pytest *)",
+#   "Bash(git status *)",
+#   "Bash(git diff *)",
+# ]
+# deny = [
+#   "Bash(rm -rf *)",
+#   "Bash(curl *)",
+#   "Bash(wget *)",
+#   "Read(**/.env)",
+#   "Read(**/.env.*)",
+#   "Read(**/secrets/**)",
+# ]
+
+# ---------------------------------------------------------------------------
+# Hooks in TOML (additiv zu ~/.grok/hooks/*.json und .grok/hooks/)
+# ---------------------------------------------------------------------------
+
+# [[hooks.PreToolUse]]
+# matcher = "Bash|run_terminal_command"
+# hooks = [
+#   { type = "command", command = "/opt/guard/pretooluse.sh", timeout = 10 },
+# ]
@@ -0,0 +1,17 @@
+{
+  "description": "Beispiel: nach Edit/Write Python mit ruff formatten (PostToolUse).",
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write|search_replace",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "scripts/format-py.sh",
+            "timeout": 60
+          }
+        ]
+      }
+    ]
+  }
+}
@@ -0,0 +1,17 @@
+{
+  "description": "Beispiel: destruktives rm vor der Ausführung blocken (PreToolUse).",
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Bash|run_terminal_command",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "scripts/block-rm.sh",
+            "timeout": 10
+          }
+        ]
+      }
+    ]
+  }
+}
@@ -0,0 +1,17 @@
+#!/usr/bin/env bash
+# PreToolUse-Guard: blockiert destruktive rm-Aufrufe (Vorlage).
+# Erwartet Grok-Hook-JSON auf stdin. Benötigt: jq.
+# Defense in depth: [permission] deny bleibt die härtere Policy-Zeile.
+set -euo pipefail
+
+INPUT=$(cat)
+COMMAND=$(echo "$INPUT" | jq -r '.toolInput.command // .tool_input.command // empty')
+
+if echo "$COMMAND" | grep -Eq 'rm[[:space:]]+(-[a-zA-Z]*f|-[a-zA-Z]*r)'; then
+  jq -n '{
+    decision: "deny",
+    reason: "Destructive rm blocked by project hook (template)"
+  }'
+else
+  jq -n '{decision: "allow"}'
+fi
@@ -0,0 +1,28 @@
+#!/usr/bin/env bash
+# PostToolUse: formatiert die editierte Python-Datei (Vorlage).
+# Erwartet Grok-Hook-JSON auf stdin. Benötigt: jq; optional ruff.
+set -euo pipefail
+
+INPUT=$(cat)
+FILE=$(echo "$INPUT" | jq -r '
+  .toolInput.file_path
+  // .toolInput.path
+  // .tool_input.file_path
+  // .tool_input.path
+  // empty
+')
+
+if [[ -z "$FILE" || ! -f "$FILE" ]]; then
+  exit 0
+fi
+
+case "$FILE" in
+  *.py)
+    if command -v ruff >/dev/null 2>&1; then
+      ruff format "$FILE" || true
+      ruff check --fix "$FILE" || true
+    fi
+    ;;
+esac
+
+exit 0
@@ -0,0 +1,12 @@
+{
+  "name": "team-baseline",
+  "description": "Minimal team baseline: Verify-Skill for lint and unit tests before commit.",
+  "version": "0.1.0",
+  "author": {
+    "name": "your-team",
+    "email": "devnull@example.com"
+  },
+  "license": "MIT",
+  "keywords": ["verify", "baseline", "team"],
+  "skills": ["skills/"]
+}
@@ -0,0 +1,15 @@
+---
+name: verify
+description: Run lint and unit tests. Use when asked to verify, check tests, or before commit.
+---
+
+# Verify (team-baseline plugin)
+
+1. Detect package manager / test runner from the repo (see root `AGENTS.md`).
+2. Run lint if available.
+3. Run unit tests.
+4. Summarize failures with file:line if possible.
+5. Do not commit or push unless the user explicitly asked.
+
+Before shipping: `grok plugin validate` on the plugin folder (CLI-Stand prüfen).
+Keys and layout may drift with releases — see User-Guide *Plugins*.
@@ -0,0 +1,16 @@
+---
+name: verify
+description: >
+  Run lint and unit tests for this repository. Use when asked to verify,
+  check tests, or before commit.
+---
+
+# Verify
+
+1. Detect package manager / test runner from the repo (see `AGENTS.md` if present).
+2. Run lint if available (e.g. `ruff check .` or `npm run lint`).
+3. Run unit tests (e.g. `pytest -q` or `npm test`).
+4. Summarize failures with file:line if possible.
+5. Do not commit or push unless the user explicitly asked.
+
+If commands fail because dependencies are missing, report the install command and stop.
@@ -0,0 +1,17 @@
+# ~/.grok/ — persönliche Defaults (User-AGENTS, falls genutzt)
+
+Kopiere oder merge diesen Inhalt an den Ort, an dem du **user-globale** Agent-Regeln pflegst
+(Projekt-`AGENTS.md` im Repo bleibt der team-sichtbare Kompass).
+
+## Working agreements
+
+- Prefer small, reviewable diffs
+- Run the project test command after code changes when one exists
+- Ask before adding new production dependencies
+- Use Plan Mode when architecture or multi-file scope is unclear
+
+## Never (personal)
+
+- Commit secrets or `.env` contents
+- Broaden to always-approve without a reason and a deny baseline
+- Force-push to shared branches
@@ -0,0 +1,8 @@
+# User-Vorlagen
+
+`AGENTS.md` hier ist eine **persönliche** Baseline – nicht die Projekt-`AGENTS.md` im Repo.
+
+Grok liest Projektregeln primär aus dem Working Tree (`AGENTS.md`, Nested Rules unter `.grok/rules/`).
+User-Config und Extensions: `~/.grok/config.toml`, `~/.grok/skills/`, `~/.grok/hooks/`.
+
+Anpassen und nur lokal nutzen; keine Secrets in die Datei.