claude-code/09-anhang-a-stabile-kernvorlagen.md

Anhang A

Stabile Kernvorlagen

Kern: Diese Kernvorlagen sind bewusst minimal und stabil gehalten. Vollständige, aktuelle und erweiterte Versionen findest du im Begleit-Service unter Material (versionierte ZIPs) und im Repo unter vorlagen/. Bei Abweichungen gilt der Lesevertrag: Konzept behalten, Syntax der aktuellen Doku folgen.

---

Wozu dieser Anhang – und was er nicht ist

Gedruckte Bücher und PDFs altern bei CLI-Flags, JSON-Feldern und UI-Labels. Was nicht altert, ist der Harness-Kern: Scope eng, Diff lesen, Deny vor Allow always, weich (CLAUDE.md) vs. hart (settings.json, Permissions, Hooks).

Dieser Anhang liefert kopierfertige Minima, die in 12–18 Monaten noch sinnvoll bleiben sollen. Er ersetzt weder die Kapitel 0–7 noch die vollständigen Materialien online.

Solo vs. Team: A.1 hat eine Solo-Minimal- und eine **Team-**Variante derselben Root-CLAUDE.md. Team heißt hier: strenger im Git (Review, keine Force-Pushes, gemeinsame Verify-Commands) – nicht Managed Policy der Org (Kap. 6). Für CI, längere Skills/Hooks und MCP bleibt der Begleit-Service / vorlagen/ zuständig.

Begleit-Service (ZIPs mit MANIFEST und SHA256, Stand & Drift, Errata, Hilfe):

https://books.maatini.space/projects/claude-code-harness/

Dort unter Material: beispiele.zip und vorlagen.zip (sobald freigeschaltet) – oder die gleichen Pfade im Buch-Repository.

Im Anhang A (dieses Buch)	Nur online / im Repo-ZIP
Minimale Project- und Local-CLAUDE.md	Team-Rules, nested Rules, lange Stack-Essays
Enge Permissions-Baseline + Settings-Kern	vollständige Team-Policies, Managed-MDM-Details
Ritual Explore → Plan → Code → Verify → Commit	Session-Rezepte, Subagent-Playbooks
Permission-Faustregeln (deny / ask / allow)	exakte UI-Labels, Screenshots
todo-cli: Tag-1-Schnellstart ohne Code	Projektcode, Tests, verdrahtetes Harness
—	Hook-Scripts, Skill-Bibliothek, CI-Workflows im Detail

Achtung: Wenn Buch und aktuelle CLI-Hilfe widersprechen, gewinnt die Hilfe der installierten Version – nicht der Anhang. Konzept und Reihenfolge bleiben; Syntax passt du an.

Die Konzepte dahinter stehen in den Kapiteln 1–3 (Trust, Memory vs. Policy, Zyklus). Hier kopierst und pinnt du – nicht erklärst du sie neu.

---

A.1 Minimale Projekt-CLAUDE.md

Wofür: Project-Kompass im Repo-Root (./CLAUDE.md) – weich, reviewbar, kurz. Keine Stack-Romane, keine Dateibaum-Listen.

Vier Hebel im Text (bewusst generisch): Scope eng halten · Permissions/Policy ernst nehmen · Verify vor „fertig“ · Diff lesen, bevor du mergst.

Solo-Minimal (kopierfertig) – stack-neutral; Build/Test durch die echten Commands des Repos ersetzen:

# CLAUDE.md

This file provides guidance to Claude Code when working in this repository.

## Project compass

- Prefer small, reviewable changes over broad refactors
- Scope: only the files/modules named in the task; ask before expanding
- Permissions: respect denies; never invent secrets or commit `.env*`
- Verify: run the project's real test/lint command before claiming done
- Diff: summarize what changed and residual risks before commit

## Build & Test

- Install: (fill in — package manager / lockfile of *this* repo)
- Test: (fill in — one command from repo root)
- Lint: (fill in or omit)

## Do / Don't

- Do: match existing patterns; keep commits focused
- Don't: add dependencies without asking; don't mass-refactor beside the task
- Don't: put secrets in prompts, notes, or this file

Team-Variante (Kern, etwas strenger) – weiterhin weich (Memory), nicht Managed Policy:

# CLAUDE.md — Team baseline

This file provides guidance to Claude Code when working in this repository.

## Stack & conventions

- (language, package manager, branch strategy)
- Public APIs: document when behavior changes

## Build & Test

- Install: (team command from root)
- Test: (one command CI also runs)
- Lint: (team default)

## Always

- Enger Scope pro Auftrag; Plan vor großen Diffs
- Diff lesen vor Commit; Tests nach Code-Änderungen
- Secrets nur über Env / Secret Manager

## Never

- Secrets in Dateien, Prompts oder Commits
- `rm -rf` / force-push auf shared branches ohne explizite Freigabe
- Production-Deploy aus der Agent-Session
- blindes `/init` committen – Team-CLAUDE.md ist Source of Truth

## Review

- PR: kurze Beschreibung + Testplan
- Mensch merged; Agent darf vorschlagen, nicht freigeben

Warum so dünn: Jede stackspezifische Zeile veraltet. Build/Test füllst du aus dem echten Repo – einmal lesen schlägt fünf Halluzinationen pro Session (Kap. 2). Team-Strenge hier = Git-Normen, nicht Org-MDM.

Vollständig und aktuell: ZIP-Vorlage vorlagen/CLAUDE.md.minimal.md und ausführliche Team-Vorlage vorlagen/CLAUDE.md.team.md über Begleit-Service → Material.

---

A.2 CLAUDE.local.md-Gerüst

Wofür: private Ergänzungen neben dem Team-CLAUDE.md – nicht committen.

# CLAUDE.local.md

## Personal prefs
- (tone, explanation depth, languages you prefer)

## Local paths / services
- (localhost URLs, fixture user ids — no production secrets)

## Personal deny reminders
- (things *you* often almost allow too broadly — e.g. force-push, network tools)

CLAUDE.local.md
.claude/settings.local.json

Warum getrennt: Project bleibt team-reviewbar; Local hält Hostnamen, Prefs und „nur bei mir“ aus der History und aus Forks (Kap. 2.6, 4.2).

Vollständig und aktuell: erweiterte Beispiele und Team-Setups im Begleit-Service → Material.

---

A.3 Enge Permissions-Baseline

Wofür: harte Policy in .claude/settings.json – Deny first, kein YOLO/bypassPermissions auf dem Alltags-Laptop.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)"
    ]
  }
}

Wie du sie schärfst: Allow nur um euren Test-/Lint-Befehl ergänzen (ein Pattern, nicht Bash(*)). Deny für Netz-Tools (curl/wget) bewusst wählen – Kap. 2.3.

Warum eng: Zu breites Allow und session-weite „Allow always“-Gewohnheiten sind die Alltagsform von YOLO. Deny schützt Secrets und Destruktives im Harness, nicht nur in Prosa.

Achtung: bypassPermissions und Bash(*) auf dem Rechner mit Cloud-CLIs, SSH-Keys oder Prod-Zugang sind echte Risiken – nur isolierte CI-/Wegwerf-Umgebungen.

Vollständig und aktuell: vorlagen/settings.permissions.json (inkl. typischer Test-Allows) über Begleit-Service → Material.

---

A.4 Settings-Kern

Hierarchie (Skalare, vereinfacht): Managed > CLI-Flags > Local > Project > User.
Permission-Regeln mergen über Schichten (Allow/Deny sammeln sich); Deny bleibt der Sicherheitsanker – Details Kap. 4.

Schalter / Ort	Rolle (stabil)
permissions.defaultMode	Alltagsprofil: für Laptop default (fragt nach)
permissions.deny	Harte Verbote (Secrets, Destruktives)
permissions.allow	Gezielte Auto-Freigaben gegen Prompt-Müdigkeit
Project-Datei	.claude/settings.json – teamgeteilt, reviewbar
Local-Datei	.claude/settings.local.json – privat, gitignoren
Managed	Org/IT – nicht von User/Project aushebelbar

Nach Edits: geladene Quellen prüfen (/status bzw. doctor – Labels driftfähig). JSON-Fehler können ganze Settings verwerfen.

Nicht hier: vollständige Schema-Liste, experimentelle UI-Flags, Managed-MDM-Details → Doku + Kap. 4/6 + Begleit-Service.

---

A.5 Explore → Plan → Code → Verify → Commit – Kurzrezept

Kanon im Buch: Dieses Kurzrezept ist die pinbare Fassung. Spickzettel (kompakt): § 8.5. Vertiefung und Alltag: Kapitel 3.

Drift-resistentes Ritual (Slash-Commands optional – dieselben Grenzen gehen als Klartext-Prompt):

1. Scope nennen – Dateien/Module, Nicht-Ziele, Erfolgskriterium in einem Satz.
2. Explore – lesen und erklären lassen; explizit: keine Dateiänderungen.
3. Plan – Schritte, Dateiliste, Verify-Command, Out-of-Scope; freigeben bevor Code.
4. Code – nur freigegebener Scope; keine „hilfreichen“ Extra-Refactors.
5. Verify – echten Projekt-Test/Lint laufen lassen; nicht nur Modell-Selbstaussage.
6. Diff lesen – Inhalt und Restrisiken; bei Unklarheit zurück zu Plan/Explore.
7. Commit – kleine, nachvollziehbare Message; du mergst.
8. Bei Drift – Wichtiges in Dateien (PLAN.md/Notizen), Kontext verkleinern; Session neu, wenn unscharf.
9. Stop-Regel – ungelesener Shell-Befehl oder unbekannter Ordner → ablehnen, erklären lassen.

Warum: Phasen bremsen Fehlerakkumulation in Tool-Ketten (Kap. 3). Labels (/plan, …) dürfen driften – die Grenzen bleiben.

---

A.6 Permission-Faustregeln

Wahl	Wann	Warum
deny	Secrets, Destruktives, force-push, oft Netz-Tools	Harness blockt – Prosa allein reicht nicht
ask (Default)	Unklare oder seltene riskante Ops	Du bleibst Gelenkstelle
allow	Häufig und relativ harmlos (Test, git status/diff)	Gegen Prompt-Müdigkeit – eng patternen
nie alltags	bypassPermissions, Bash(*), blind „Allow always“	YOLO mit Höflichkeitsformular

Session-weite / „always“-Freigaben: bequem, landen oft in Local-Settings und gelten weiter als du denkst. Zu breites Pattern = dauerhaft offene Tür. Lieber ein enges Allow in Project-Settings reviewen als fünf mal „always“ im Eifer.

Merksatz (Buch-Spirale): Deny vor Allow always · Scope eng · Diff lesen · CLAUDE.md weich / settings hart.

---

A.7 Schnellstart (ohne Code)

Tag-1-Folge – Befehle und Checkliste, kein Beispielprojekt:

1. Install (Native empfohlen) → claude --version → claude doctor (oder Desktop/IDE-Login, Kap. 1).
2. In einen bekannten Arbeitsordner wechseln – nicht Downloads mit fremden ZIPs, nicht Prod.
3. Session starten (claude bzw. Workspace in Desktop/IDE).
4. Workspace Trust nur für diesen bekannten Ordner.
5. Erste Session: lesen/erklären lassen; Edits nur mit engem Scope; jeden Shell-Vorschlag lesen.
6. Optional am selben Tag: A.1 + A.3 ins Repo legen und geladene Quellen prüfen.
7. Volle Übungen/todo-cli: Begleit-Service → Material + Kapitel 1.

Checkliste erster Tag

• Version/doctor (bzw. App/Extension) ok
• Nur bekannter Ordner + bewusste Trust-Entscheidung
• Kein bypassPermissions, kein blindes Allow always
• Mindestens eine Session mit gelesenem Diff bzw. Deny-Übung
• (Optional) Minimale CLAUDE.md + Deny für .env*

---

Was du jetzt kannst

• Einordnen, was im PDF pinbar ist und was nur online im Begleit-Service lebt
• Solo- und Team-Minimal-CLAUDE.md sowie Local-Gerüst ohne Stack-Ballast anlegen
• Eine enge Permissions-Baseline (Deny-first, defaultMode: default) begründen und pinnten
• Settings-Hierarchie und die stabilen Schalter grob einordnen
• Explore→Plan→Code→Verify→Commit und Permission-Faustregeln ohne Produkt-UI ausführen
• Tag 1 sicher starten

Nächste Schritte

1. Vollständige, versionierte Vorlagen und Beispiele aus dem Begleit-Service holen: https://books.maatini.space/projects/claude-code-harness/ (Material, MANIFEST/SHA256).
2. Kapitel 2–3 im echten Repo anwenden (nicht nur Kern anpinnen).
3. Bei Bedarf Skills/Hooks/MCP/CI aus dem ZIP – erst wenn der Basis-Workflow sitzt (Roadmap § 8.9).
4. Spick und Index: Kapitel 8 (Vorlagen-Index, Cheatsheets; Ritual-Spick § 8.5 ↔ A.5).