Referenz · Beispiel-Repo
Claude Code Setup: Beispiel-Repo und Pro-Checkliste
Eine kommentierte Referenzkonfiguration zum Lernen und Übernehmen: Permissions, Hooks, Subagents, Skills, MCP, Worktrees, CI und Kosten-Monitoring. Kein Starter-Kit, kein App-Code.
Status Das öffentliche Repo (MIT-Lizenz) ist in Vorbereitung. Sobald es veröffentlicht ist, steht hier der Link. Die Checkliste und die Snippets unten kannst du schon jetzt nutzen.
Geplante Struktur
So würde das Repo aufgebaut sein. Jede Datei soll mit der getesteten Tool-Version kommentiert werden, jeder Artikel im Blog auf die passende Datei verweisen.
Geplante Inhalte – Entwurf
vibecodingpro-setup/ ├── CLAUDE.md # Projektregeln, kurz gehalten ├── .claude/ │ ├── settings.json # Permissions, Hooks, Statuszeile │ ├── statusline.sh │ ├── hooks/ │ │ ├── block-dangerous.sh # PreToolUse │ │ ├── format.sh # PostToolUse │ │ ├── tests-green.sh # Stop │ │ └── audit-log.sh # Logging │ ├── agents/ │ │ ├── test-runner.md │ │ └── researcher.md │ ├── skills/release-notes/SKILL.md │ └── commands/review.md ├── .mcp.json ├── tools/docs-mcp/ # Minimal-MCP-Server ├── scripts/agent-worktree.sh ├── evals/ # Mini-Eval-Harness ├── .devcontainer/devcontainer.json └── .github/workflows/claude.yml
Permissions
- Secrets per deny gesperrt (.env, Schlüsseldateien)
- Häufige, harmlose Befehle in allow, damit der Agent nicht ständig fragt
- Alles mit Außenwirkung (push, deploy) in ask
- Projekt-Settings eingecheckt, persönliche in settings.local.json
{
"permissions": {
"allow": ["Bash(npm run test:*)", "Bash(npm run lint)", "Bash(git diff:*)"],
"ask": ["Bash(git push:*)"],
"deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
}
}deny gewinnt gegen allow. Profile für „lokal“ und „CI“ würden im Repo getrennt liegen.
Hooks
- PreToolUse-Guardrail für destruktive Bash-Befehle
- PostToolUse: Formatter und Linter nach jedem Edit
- Stop-Hook prüft, ob die Tests grün sind
- Hook-Skripte sind schnell und haben eindeutige Exit-Codes
#!/usr/bin/env bash
# PreToolUse, matcher "Bash": Eingabe kommt als JSON auf stdin
cmd=$(jq -r '.tool_input.command // ""')
if grep -Eq 'rm -rf /|git push (-f|--force)|DROP TABLE' <<<"$cmd"; then
echo "Blockiert durch Hook: $cmd" >&2
exit 2 # 2 = blockieren, stderr geht an den Agenten zurück
fi
exit 0Ein Hook ist deterministisch, CLAUDE.md nur eine Bitte. Was nie passieren darf, gehört in einen Hook.
Subagents
- Jeder Agent hat eine enge Aufgabe und eine präzise description
- Tools pro Agent eingeschränkt
- Modellwahl pro Agent bewusst getroffen
- Ergebnisse kommen als knappe Zusammenfassung zurück, nicht als Log-Dump
---
name: test-runner
description: Führt die Test-Suite aus und fasst Fehler knapp zusammen. Nach Code-Änderungen proaktiv nutzen.
tools: Bash, Read, Grep, Glob
model: haiku
---
Führe die Tests aus. Gib nur fehlgeschlagene Tests mit Datei, Zeile
und vermuteter Ursache zurück. Keine Fixes, keine vollständigen Logs.Der Kontext des Subagents bleibt beim Subagent. Zurück kommt nur, was der Hauptagent wirklich braucht.
Skills & Commands
- Wiederkehrende Abläufe als Skill statt als Absatz in CLAUDE.md
- description so formuliert, dass der Skill zuverlässig auslöst
- Slash Commands nur für explizit gestartete Abläufe
- Projekt- vs. User-Ebene bewusst gewählt
---
name: release-notes
description: Schreibt Release Notes aus den Commits seit dem letzten Tag. Nutzen, wenn nach Release Notes, Changelog oder "was ist neu" gefragt wird.
---
1. Letzten Tag mit `git describe --tags --abbrev=0` finden.
2. Commits seitdem gruppieren: Features, Fixes, Breaking Changes.
3. Ergebnis als Markdown ausgeben, keine Commit-Hashes.Ob ein Skill auslöst, ist testbar. Genau dafür wäre der Eval-Ordner im Repo gedacht.
MCP
- Nur Server im Projekt-Scope, die alle im Repo brauchen
- Tokens per Umgebungsvariable, nie im Klartext
- Anzahl der Tool-Definitionen im Blick (Kontextkosten)
- Remote-Server über HTTP bewusst statt stdio gewählt
{
"mcpServers": {
"docs": {
"command": "node",
"args": ["./tools/docs-mcp/server.js"]
},
"tracker": {
"type": "http",
"url": "https://mcp.example.com/mcp",
"headers": { "Authorization": "Bearer ${TRACKER_TOKEN}" }
}
}
}Jedes Tool eines Servers belegt Kontext, auch wenn es nie aufgerufen wird.
Worktrees & CI
- Ein Worktree pro paralleler Aufgabe, eigener Branch
- Headless-Läufe mit maschinenlesbarer Ausgabe
- CI-Workflow mit minimalen Rechten
- Klarer Merge-Pfad: Agent öffnet PR, Mensch reviewt
#!/usr/bin/env bash
# Eine Aufgabe = ein Worktree = ein Branch
task="$1"; prompt="$2"
git worktree add "../wt-$task" -b "agent/$task"
cd "../wt-$task" || exit 1
claude -p "$prompt" --output-format json > "../wt-$task.result.json"Parallelität lohnt sich nur, wenn sich die Aufgaben nicht dieselben Dateien teilen.
Kosten-Monitoring
- Token-Verbrauch in der Statuszeile sichtbar
- Telemetrie per OpenTelemetry, wenn mehrere Leute im Repo arbeiten
- Kleine Modelle für Routine-Subagents
- Stabiler Kontextanfang, damit Prompt Caching greift
{
"statusLine": { "type": "command", "command": ".claude/statusline.sh" },
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp"
}
}Erst messen, dann optimieren. Ohne Zahlen ist jede Kostenoptimierung Raten.
Die Grundlagen-Artikel
Pro Themenblock ein ausführlicher Artikel. Was noch nicht erschienen ist, ist als „in Arbeit“ markiert.
- hooks Claude Code Hooks: deterministische Regeln für einen nicht-deterministischen Agenten
- subagents Claude Code Subagents: Architektur, Kontext-Isolation und wann sie sich lohnen
- mcp MCP-Server bauen und betreiben: Tools, Transport, Konfiguration und Debugging in Arbeit
- parallel Parallele Coding-Agenten: Worktrees, Headless Mode und Orchestrierung in der Praxis in Arbeit
- evals Evals für Coding-Agenten: messen, ob dein Setup wirklich besser wird in Arbeit
- kosten Token-Kosten von Coding-Agenten kontrollieren: Caching, Modellwahl, Budgets in Arbeit
Setup-Review anfragen
Das Agent-Setup-Review startet gerade. Sag kurz, wo dein Setup steht und was du lösen willst. Wir melden uns, sobald es losgeht, und vorher nur, wenn wir Rückfragen haben.
- Anfrage mit Rolle, Tool und größter Baustelle
- Rückfrage nur, wenn etwas unklar ist
- Nachricht, sobald das Review startet
Du willst ein ganzes Team schulen? Dann ist vibecodingtraining.de die richtige Adresse.