Claude Code als Alltagswerkzeug nutzen: Claude.md, Skills, Subagents, Plugins, MCP

 (arps18.github.io)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die Produktivität von Claude Code hängt weit stärker davon ab, wie Speicher, benutzerdefinierte Befehle, parallele Sessions und Projekteinstellungen aufgebaut und validiert werden, als vom Prompt selbst
  • CLAUDE.md sollte als kurze, validierungsorientierte kumulative Infrastruktur betrieben werden; fügt man nach Fehlern Regeln hinzu, lassen sich dieselben Fehler reduzieren
  • .claude/ ist ein hierarchisches Konfigurationssystem, das CLAUDE.md, Regeln, Skills, Befehle, Agents und MCP-Konfigurationen enthält und projektweite sowie globale Bereiche getrennt anwendet
  • Skills verwandeln wiederkehrende Aufgaben in wiederverwendbare Expertise, und Subagents führen Reviews, Debugging und Migrationen in getrennten Kontexten aus
  • In Kombination mit Plugins, MCP, /goal, /rewind, /batch und parallelen Worktrees wird Claude Code zu einem konfigurierten und betriebenen Entwicklungsagenten

Claude Code als validierbaren Agenten behandeln

  • Die Produktivitätsunterschiede bei Claude Code entstehen weniger durch einfache Prompts als dadurch, wie Speicher, benutzerdefinierte Befehle, parallele Sessions und Projekteinstellungen aufgebaut werden
  • Das Kernprinzip besteht darin, Claude in die Lage zu versetzen, seine eigenen Ergebnisse zu validieren; Boris Cherny und das Anthropic-Team gehen davon aus, dass sich die Qualität allein damit um das 2- bis 3-Fache verbessert
  • Für den Arbeitsablauf eignet sich die Reihenfolge Erkunden → Planen → Implementieren
    • Der Planungsmodus, den man mit zweimal Shift+Tab erreicht, eignet sich für schreibgeschütztes Erkunden
    • Empfohlen wird, zuerst Dateien zu lesen und Abläufe sowie Datenmodell zu verstehen, dann einen Plan zu erstellen und ihn auszuführen
    • Bei Aufgaben, die mehrere Dateien betreffen, ist der Planungsmodus nützlich; bei kleinen Änderungen kann man ihn überspringen
  • Der Planungsmodus kann als vor der Implementierung überprüfbares Designdokument behandelt werden
    • Ein Claude kann den Plan schreiben, und ein zweiter Claude in einer neuen Session kann ihn wie ein unvoreingenommener Staff Engineer prüfen
    • Wenn die Implementierung vom Plan abweicht, ist ein Ablauf sinnvoll, bei dem man in den Planungsmodus zurückkehrt und neu plant, einschließlich der Validierungsschritte
    • Mit Ctrl+G lässt sich Claudes Plan im Editor öffnen und vor der Implementierung direkt bearbeiten
  • Präzise Referenzen sind wirksamer als vage Anweisungen
    • Statt „Schau dir das auth-Modul an“ sollte man Dateien direkt angeben, etwa @src/auth/login.py
    • Fehler sollten nicht einfach eingefügt, sondern per Pipe übergeben werden, etwa mit cat error.log | claude
  • Cat Wu ist der Ansicht, dass Claude Code am besten funktioniert, wenn man es nicht wie einen Pair-Programmer behandelt, den man Zeile für Zeile anweist, sondern wie einen beauftragten Engineer
  • Wenn Claude Fehler macht, kann man ans Ende des Prompts „Update CLAUDE.md so you do not repeat this.“ anhängen, damit eine Regel hinterlassen wird, die denselben Fehler künftig verhindert

Das Verzeichnis .claude und die Konfigurationshierarchie

  • .claude/ ist nicht nur ein Ordner für CLAUDE.md, sondern ein hierarchisches Konfigurationssystem
  • Die Konfiguration ist in zwei Bereiche aufgeteilt
    • Projektbereich: liegt in .claude/ innerhalb des Repositorys, wird in git eingecheckt und mit dem Team geteilt
    • Globaler Bereich: liegt unter ~/.claude/ und gilt für alle Projekte auf dem lokalen Rechner
  • Projektdateien kann man als Beschreibung des Projekts verstehen, globale Dateien als Beschreibung der Präferenzen und Arbeitsweise des Nutzers
  • Rolle der wichtigsten Dateien
    • CLAUDE.md: sowohl im Projekt- als auch im globalen Bereich möglich; Anweisungen, die in jeder Session geladen werden
    • CLAUDE.local.md: persönliche projektspezifische Notizen; gehört in .gitignore
    • settings.json: Berechtigungen, Hooks, Umgebungsvariablen, Standard-Modelleinstellungen
    • settings.local.json: persönliche Overrides; wird automatisch von git ignoriert
    • .mcp.json: vom Team geteilte MCP-Server-Konfiguration für das Projekt
    • skills/<name>/SKILL.md: wiederverwendbare Prompts, aufrufbar mit /name
    • commands/*.md: Slash-Befehle in jeweils einer einzelnen Datei
    • agents/*.md: Definitionen für Subagents
    • rules/*.md: thematische Anweisungen, die auch pfadbasiert angewendet werden können
  • CLAUDE.md wird kaskadierend geladen
    • In einem Monorepo können root/CLAUDE.md und root/services/billing/CLAUDE.md gemeinsam geladen werden
    • Das eignet sich für Codebasen mit unterschiedlichen Konventionen je Ordner
  • .claude/rules/*.md eignet sich für pfadbezogene Anweisungen
    • Regeln, die nur für einen Migrationsordner gelten, sind mit glob in .claude/rules/migrations.md besser aufgehoben als in CLAUDE.md, das sonst die gesamte Session unnötig aufbläht
  • Für neue Aufgaben werden Skills eher empfohlen als commands
    • Sowohl .claude/commands/*.md als auch .claude/skills/<name>/SKILL.md können Slash-Befehle erzeugen
    • Skills unterstützen Hilfsdateien, disable-model-invocation, erlaubte Tools und Agent-Overrides
  • Mit claude project purge ~/path/to/repo --dry-run lässt sich der lokale Status prüfen, den Claude für ein bestimmtes Projekt gespeichert hat

CLAUDE.md kurz und validierungsorientiert halten

  • CLAUDE.md wird zu Beginn jeder Session geladen; ist sie schlecht geschrieben, wiederholt Claude dieselben Fehler, ist sie gut geschrieben, verbessern sich die Ergebnisse selbst bei demselben Prompt deutlich
  • Das wichtigste Prinzip ist, sie kurz zu halten
    • Empfohlen wird, sich bei jeder Zeile zu fragen: „Würde Claude ohne diese Zeile einen Fehler machen?“ Falls nicht, sollte sie gelöscht werden
  • Lässt man Claude seine eigenen Regeln schreiben, entsteht ein kumulativer Effekt
    • Wenn Claude etwas falsch gemacht hat, kann man mit „Update CLAUDE.md so you do not repeat this.“ anweisen, den Fehler als präzise Regel zusammenzufassen
    • Wiederholt man das über mehrere Wochen, sammeln sich die Fallstricke des Projekts als Regelliste an
  • Die tatsächliche CLAUDE.md des Claude-Code-Teams konzentriert sich auf Build-Befehle und Validierungsreihenfolge
    • Es wird bun verwendet, nicht npm
    • Festgelegt sind eine schnelle Typprüfung nach Änderungen, Tests, Linting vor dem Commit und die vollständige Validierungsreihenfolge vor dem PR
    • Stilvorlieben, Touren durch die Codebase und allgemeine Ausführungen sind nicht enthalten
  • Auch in PR-Kommentaren kann man mit @claude direkt Regeln hinzufügen
    • Beispiel: @claude add to CLAUDE.md to never use enums, always prefer literal unions
    • PR-Reviews führen so zu Verbesserungen an CLAUDE.md und schaffen einen Workflow der „Compounding Engineering“
  • Eine gute CLAUDE.md konzentriert sich auf die folgenden Informationen
    • Codestil: ES modules statt CommonJS verwenden
    • Workflow: bun run typecheck ausführen, kein direktes Pushen auf main
    • Architektur: API-Routen müssen zwingend durch bestimmte Middleware laufen
    • Gotchas: der Unterschied zwischen User und UserRecord, sowie dass formatCurrency von USD ausgeht
  • Was nicht in CLAUDE.md gehört
    • Standardkonventionen der Sprache
    • dateibasierte Erklärungen der Codebase
    • lange Tutorials
    • API-Dokumentation
    • Inhalte, die sich häufig ändern
  • Formulierungen wie IMPORTANT oder YOU MUST können die Befolgungsrate erhöhen, sollten aber sparsam eingesetzt werden, damit ihr Gewicht erhalten bleibt
  • Mit der Syntax @path lassen sich andere Dateien einbinden, sodass CLAUDE.md kurz bleibt und dennoch auf Details verlinkt
    • Beispiel: See @README.md for project overview and @package.json for scripts.
    • Beispiel: @~/.claude/my-preferences.md

Persönliches Feedback in CLAUDE.local.md kumulieren

  • CLAUDE.local.md wird am selben Ort und auf dieselbe Weise wie CLAUDE.md geladen, sollte den lokalen Rechner jedoch nicht verlassen und muss zu .gitignore hinzugefügt werden
  • Wenn man PR-Review-Kommentare sofort in CLAUDE.local.md einträgt, sammelt sich wiederkehrendes persönliches Feedback in einer persönlichen Regeldatei an
  • Beispielregeln
    • Neue SQS-Consumer benötigen im selben PR eine DLQ und Alarme
    • Optional<T> ist gegenüber der Rückgabe von null zu bevorzugen
    • Tests für neue Endpoints müssen einen Auth-Failure-Fall enthalten
    • Beim Hinzufügen eines Endpoints muss auch die OpenAPI-Spezifikation aktualisiert werden
  • Es ist sinnvoll, projektspezifisches Feedback und Punkte zur Korrektur persönlicher Gewohnheiten in getrennten Dateien zu halten
  • Nach einigen Wochen sollten Punkte, die bereits zur Gewohnheit geworden sind, entfernt werden, sodass nur das bleibt, was noch gelernt wird

Skills: Wiederverwendbare Einheiten von Fachwissen

  • Skills sind wiederverwendbare Einheiten von Fachwissen, die Claude Code von einem „Agenten, der alles kann“ in einen Agenten verwandeln, der bestimmte Projektaufgaben gut erledigt

  • Skill-Struktur

    • Ein Skill ist ein Ordner unter .claude/skills/<name>/ oder ~/.claude/skills/<name>/
    • Die SKILL.md im Ordner enthält Frontmatter und Anweisungen
    • Der Ordnername wird zum Slash-Befehl
    • Wenn man zum Beispiel ~/.claude/skills/summarize-changes/SKILL.md erstellt, ist /summarize-changes in allen Sessions verfügbar

  • Warum Skills so leistungsfähig sind

    • Schrittweise Offenlegung: Beim Start einer Session wird nur die Beschreibung im Frontmatter geladen; die vollständige SKILL.md und Hilfsdateien werden erst geladen, wenn sie tatsächlich benötigt werden
    • Ordnerbasierte Organisation: Templates, Referenzdokumente, Skripte und Konfigurationen können zusammen gebündelt werden
    • Inline-Shell: Zeilen, die mit ! beginnen, führen Befehle aus und fügen die Ausgabe zum Zeitpunkt des Aufrufs ein

  • Frontmatter-Optionen

    • description: Erklärt, wann dieser Skill verwendet werden sollte
    • disable-model-invocation: true: Sorgt dafür, dass er nur ausgeführt wird, wenn der Nutzer explizit /my-skill eingibt
    • allowed-tools: Beschränkt die verwendbaren Tools wie Read, Grep, Bash
    • agent: Kann ihn in einem bestimmten Agent-Modus ausführen
    • Für Skills mit Nebenwirkungen wie Deployments ist disable-model-invocation: true passend

  • Beispiel für einen Skill zu Go-API-Konventionen

    • Ein Skill, der für ein Go-Service-Team ein Scaffold für neue HTTP-Handler erstellt, kann SKILL.md, templates/handler.go.tmpl und examples/healthz.go zusammen enthalten
    • Regelbeispiele können projektspezifische Konventionen festhalten, etwa die Präferenz für Go 1.22 und den chi-Router, sqlc Typed Queries, strukturiertes Logging mit zap sowie testify-Assertions und table-driven tests
    • Beispiele für Fallstricke verhindern wiederkehrende Fehler, etwa dass chi.URLParam bei fehlenden Parametern "" zurückgibt, httperr.Wrap nichts loggt und bei pgtype.Text .Valid geprüft werden muss

  • Skills, die sich zur Installation lohnen

    • mattpocock/skills: Beliebtes Skills-Repository mit rund 100k Stars
      • /grill-me: Interviewt den Plan, bevor Code geschrieben wird
      • /tdd: Erzwingt strikt red-green-refactor
      • /diagnose: Debuggt in der Reihenfolge Reproduktion, Minimierung, Hypothese, Fix, Regressionstest
      • Installation: npx skills@latest add mattpocock/skills
    • Jeffallan/claude-skills: Bietet 66 sprachspezifische Profile wie go-pro, python-pro, java-architect, typescript-pro, rust-engineer, sql-pro
    • Offizielle Skills von Anthropic
      • /code-review: Vier parallele Agenten prüfen den Diff und melden nur Findings auf Basis von Konfidenz-Scores
      • /simplify: Prüft aktuellen Code unter dem Gesichtspunkt von Wiederverwendbarkeit und Effizienz
      • /batch: Verteilt Migrationen auf mehrere parallele Agenten, die jeweils in eigenen Worktrees arbeiten
      • /webapp-testing: Lässt Claude eine lokale Web-App mit Playwright testen
    • Aufgaben, die man mehr als einmal am Tag wiederholt, lassen sich am besten in einen Skill verwandeln
    • Wenn man Skills in Git committet, werden sie zum organisationalen Wissen des Teams, und neue Engineers erhalten die angesammelten Arbeitsweisen sofort beim Klonen des Repositories

Subagents: Fokussiert in separatem Kontext arbeiten lassen

  • Ein Subagent läuft mit eigenem Kontextfenster und eigenen Tool-Berechtigungen und gibt danach eine Zusammenfassung zurück
  • Der zentrale Nutzen ist, dass er viele Dateien lesen kann, ohne den Kontext der Haupt-Session zu füllen
  • Subagents sind Markdown-Dateien unter .claude/agents/ oder ~/.claude/agents/; im Frontmatter werden name, description, tools und model deklariert

  • Aufbau des Agenten /pr-review

    • Er kann so definiert werden, dass er den Diff des aktuellen Branches mit main vergleicht und dabei Bugs, Sicherheitsprobleme, fehlende Edge Cases und Verstöße gegen Projektkonventionen findet
    • Mit tools: Read, Grep, Glob, Bash erhält er lesefokussierte Berechtigungen
    • Mit model: opus kann für Reviews mit hohem Risiko ein stärkeres Modell verwendet werden
    • Der Prozess besteht aus git diff main...HEAD, git log main..HEAD --oneline, dem Lesen aller Dateien und dem Abgleich mit CLAUDE.md, CLAUDE.local.md und .claude/rules/
    • Die Ausgabe kann nach Critical / High / Medium / Low gruppiert sein, Datei, line, issue und suggested fix enthalten und mit einem von SHIP, FIX FIRST, REWORK enden

  • Design für ein besseres Signal-Rausch-Verhältnis

    • Wenn ein Reviewer selbst Code ändert, entsteht ein Bias zur Verteidigung der eigenen Änderungen; daher sind schreibgeschützte Tools passend
    • Das Rauschen sinkt, wenn im Abschnitt „Do NOT flag“ festgelegt wird, dass Stilvorlieben ohne Projektregel, Refactoring-Vorschläge für funktionierenden Code und Punkte außerhalb des Diffs ausgeschlossen werden

  • Häufig genutzte Subagent-Muster

    • Das Claude-Code-Team checkt build-validator, code-architect, code-simplifier, oncall-guide, verify-app ein
    • security-reviewer: Prüft auf Injection, Auth, Secrets und unsichere Deserialisierung
    • test-writer: Erstellt Tests und bildet eine Schleife mit code-reviewer
    • debugger: Verfolgt fehlschlagende Tests bis zur Root Cause
    • performance-auditor: Untersucht Flow und Query-Profiling
    • migration-writer: Erstellt DB-Migrationen passend zu den Projektkonventionen
    • release-notes-writer: Schreibt aus der Commit-History ein Changelog
    • Wenn Session A implementiert und ein code-reviewer-Subagent in einem neuen Kontext prüft, reduziert das Implementierungs-Bias
    • Fügt man dem Frontmatter isolation: worktree hinzu, kann ein Subagent in einem separaten Git-Worktree laufen; das ist nützlich, wenn Migrationen auf mehrere parallele Agenten verteilt werden sollen

Plugins und Marketplace

  • Plugins bündeln Skills, Hooks, Subagents und MCP-Server zu einer installierbaren Einheit
  • Mit /plugin lässt sich der Marketplace-Browser öffnen
  • Mit /plugin marketplace add owner/repo lässt sich ein Community-Marketplace hinzufügen

  • Elemente, die man anfangs installieren sollte

    • /code-review: Vier parallele Agents werden ausgeführt; zwei prüfen die Einhaltung von CLAUDE.md, einer analysiert Bugs, und einer analysiert den Kontext auf Basis von Git Blame
    • /feature-dev: Wandelt ein Feature-Briefing in sieben Schritten — Requirements → Exploration → Architecture → Implementation → Testing → Review → Docs — in funktionsfähigen Code um
    • Language-Server-Plugin: Bietet präzise Symbolnavigation und automatische Diagnostics nach Bearbeitungen; vom Team als Plugin mit dem größten Einfluss bezeichnet
    • /security-guidance: Offizielles Security-Skill von Anthropic, das vor dem Release Sicherheitsbedenken sichtbar macht
    • Stand Mitte 2026 gibt es in über 75 Marketplaces mehr als 1.000 Plugins
    • Wichtige Plugin-Kategorien sind Git-Workflows, Code Intelligence (LSP), Documentation Generators, Testing, Browser-Automatisierung (Playwright), Design-Systeme (Figma) und Observability (Sentry, Datadog)
    • Wenn man ein gemeinsam genutztes .mcp.json und kuratierte Plugins zusammen bereitstellt, können neue Engineers schon wenige Minuten nach dem Klonen des Repositories produktiv arbeiten

Claude-Code-Befehle mit großem Einfluss auf die Produktivität

  • Viele Nutzer lernen nur /clear, /compact und /init und bleiben dann dabei stehen, aber auch andere Befehle haben großen Einfluss auf die tägliche Produktivität

  • Wichtige Befehle

    • /insights: Analysiert Nutzungsmuster und lohnt sich etwa einmal im Monat
    • /compact <hint>: Komprimiert die Sitzung, wobei der Hint steuert, was erhalten bleiben soll
    • /copy: Kopiert die letzte Antwort und bietet einen interaktiven Picker für Codeblöcke
    • /rewind: Undo für die gesamte Sitzung; stellt Code und Gespräch oder beides wieder her
    • /btw: Seitenfragen, die nicht in den Gesprächsverlauf eingehen
    • /context: Visualisiert die Context-Nutzung
    • /export <file>: Dumpt das Gespräch in eine Datei
    • /branch: Forkt die Sitzung für riskante Versuche
    • /batch: Verteilt Arbeit über das gesamte Worktree hinweg auf parallele Agents
    • /loop <interval>: Führt Claude bis zu drei Tage lang wiederholt aus
    • /schedule: Cloud-Version von /loop, die auch funktioniert, wenn das Laptop geschlossen ist
    • /teleport: Verschiebt Sitzungen zwischen Terminal und Web
    • /focus: Blendet Zwischenschritte von Tool Calls aus und zeigt nur das Endergebnis
    • /voice: Spracheingabe
    • --bare: Macht den Startup bei nicht-interaktivem claude -p um bis zu 10× schneller

  • Der Unterschied zwischen /compact und /clear

    • Für eine komplett neue Aufgabe sind /clear und ein neu geschriebenes Briefing passend
    • Wenn die Aufgabe verwandt ist und weiterhin Context benötigt, ist /compact mit Hint passend
    • /compact ist eine verlustbehaftete LLM-Zusammenfassung, /clear dagegen ein vom Nutzer selbst geschriebenes Briefing — diese Unterscheidung ist daher wichtig

  • So verwendet man /rewind

    • Wenn Claude auf einen falschen Weg gerät, ist es besser, nicht einfach weiterzuschreiben: „Das hat nicht funktioniert, also probier X“
    • Wenn man weiterschreibt, wird der Context verunreinigt; besser ist es, per Rewind zurückzugehen und mit dem Gelernten neu zu prompten
    • Mit zweimal Esc lässt sich Rewind öffnen
    • ! kann als Shell-Escape verwendet werden
    • Dinge wie !git status oder !npm test werden sofort ausgeführt, und die Ausgabe geht in den Context ein
    • Die Einstellung CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 dient dazu, bei 1M-Modellen die Komprimierung früher zu erzwingen, bevor rund um 300–400k Tokens Context Rot einsetzt

  • Fan-out-Muster

    • Zuerst erstellt man eine Task-Liste und testet sie an drei Dateien
    • Nach dem Anpassen des Prompts wendet man ihn auf Tausende Dateien an
    • Beispiel:
for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

/goal: Wiederholungsschleife mit eingebauten Abschlusskriterien

  • /goal legt Abschlusskriterien fest und lässt Claude jedes Mal, wenn es anhalten will, die Bedingungen anhand des Transkripts prüfen
  • Die Bedingungen müssen überprüfbar und deterministisch sein
    • Testbefehl
    • CLI-Exit-Code
    • Dateistatus
  • Beispiele:
/goal all tests in test/auth pass and the lint step is clean
/goal all integration tests in tests/api pass without flaking 3 runs in a row
/goal the OpenAPI spec validates and matches the actual response shapes
/goal docker compose up runs cleanly and the healthcheck endpoint returns 200
/goal coverage on src/billing/ is above 80% and all new tests are not placeholders
  • Vage Bedingungen wie „der Code ist gut“ funktionieren nicht
  • Nützliche Funktionen in Kombination
    • /loop: Wiederholt in festgelegten Intervallen und reduziert so den Backlog
    • /schedule: Führt die Wiederholung periodisch in der Cloud aus
    • Stop-Hook: Setzt ein Gate über die eigene Test-Suite oder einen CI-Endpunkt
    • Auto Mode: Verhindert, dass lange Goals wegen Permission Prompts stehen bleiben
  • Die Kombination aus /goal + Auto Mode + /focus zielt auf einen Ablauf ab, bei dem man mit klarem Briefing und Abschlusskriterien startet und bei der Rückkehr der PR fertig ist

MCP als Tool zur Systemerkennung nutzen

  • MCP (Model Context Protocol) macht Claude Code zu einem Agenten, der über einen Coding-Agent hinaus auch externe Systeme erkennen kann
  • Ein MCP-Server exponiert externe Tools wie Datenbanken, Design-Tools, Error-Tracker oder Notizen in standardisierter Form für Claude
  • Ohne MCP kann Claude Dateien lesen und Befehle ausführen, mit MCP kann es jedoch Linear-Tickets, Postgres-Queries, Figma-Komponenten, Sentry-Stack-Traces und Obsidian-Vaults bearbeiten, ohne das Terminal zu verlassen

  • MCPs, die im Engineering häufig verwendet werden

    • GitHub: Repo-Management, PRs, Issues, Code Search
    • Context7: aktuelle Library-Dokumentation, use context7 zum Prompt hinzufügen
    • Sentry: echter Error-Kontext, Stack-Traces, Breadcrumbs
    • Linear: Tickets lesen und erstellen, Status-Updates
    • Playwright: Browser-Automatisierung auf Basis von Accessibility-Snapshots
    • Figma: Live-Design-Baum, Auto-Layout, Spacing-Tokens, Component-Referenzen
    • Postgres / Supabase: direkte Queries auf die Dev-DB
    • Slack: Threads lesen, Diskussionen zusammenfassen, Antwortentwürfe
    • lokale Server verwenden stdio, vendor-gehostete Server nutzen HTTP mit OAuth
    • Beispiel:
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
  • teamweit geteilte MCPs liegen in .mcp.json im Project-Root, persönliche MCPs in ~/.claude.json
  • Wenn zu viele MCPs installiert sind, wird die Tool-Liste, die Claude berücksichtigen muss, zu groß, was die Qualität von Entscheidungen verschlechtern kann
  • Als Starter-Set eignen sich GitHub, Context7 und ein oder zwei domainspezifische MCPs
  • /mcp ist in Claude Code der erste Prüfpunkt, um aktive Server und den Verbindungsstatus zu kontrollieren

Die 3-stufige Speicherarchitektur von Obsidian und Claude Code

  • Die Kombination aus Obsidian + Claude Code ist besonders leistungsfähig, wenn sie nicht nur als „Claude liest den Vault“, sondern als dreistufige Speicherarchitektur genutzt wird

  • Einrichtung

    • obsidian-claude-code-mcp in Obsidian installieren
    • Das Plugin exponiert den Vault über Port 22360 eines lokalen WebSocket
    • Claude Code entdeckt dies automatisch
    • CLAUDE.md zum Vault hinzufügen, um die Ordnerstruktur zu beschreiben

  • Ordnerstruktur

    • 00-Inbox/: rohe Erfassung
    • 10-Daily/: eine Notiz pro Tag
    • 20-Projects/: Notizen zu aktiven Projekten
    • 20-Projects/billing-v2/README.md: Ziel, Status, offene Fragen
    • 20-Projects/billing-v2/decisions/: ADRs
    • 20-Projects/billing-v2/sessions/: Logs pro Claude-Session
    • 30-Decisions/: projektübergreifende ADRs
    • 40-Atoms/: wiederverwendbares Wissen und Links
    • 90-Archive/: Archiv

  • Hot Storage

    • Jede Claude-Session schreibt ein mit Zeitstempel versehenes Log in 10-Daily/<today>.md
    • Mit dem Stop-Hook kann beim Beenden des Agenten eine strukturierte Zusammenfassung angehängt werden

  • Warm Storage

    • Jedes Projekt hat einen Ordner unter 20-Projects/
    • Vor einer neuen Session liest Claude die README des Projekts und die letzten 2–3 Session-Logs, um den Kontext wiederherzustellen
    • So lässt sich der Kontext von zwei Wochen in weniger als 30 Sekunden rekonstruieren

  • Cold Storage

    • Architekturentscheidungen werden als ADRs in 30-Decisions/ hochgestuft
    • Wiederverwendbares Wissen wird zu 40-Atoms/ verdichtet und über Wikilinks mit mehreren Projekten verbunden

  • Beispiel für einen alltäglichen Workflow

    • What is in my inbox? Summarize and suggest where each item belongs.
    • Check 30-Decisions/ for anything related to retry policies.
    • Read the last 3 session logs for billing-v2. Tell me where I left off.

Alltägliche Entwicklungsabläufe optimieren

  • Neues Feature

    • mit dem Plan-Modus starten
    • den Plan mit Ctrl+G bearbeiten
    • nach der Implementierung den Subagenten /pr-review aufrufen oder in einer frischen Claude-Session reviewen

  • Bug

    • zuerst reproduzieren
    • den Error mit cat error.log | claude per Pipe übergeben
    • Claude zuerst den fehlschlagenden Test schreiben lassen und dann den Fix
    • der Test soll verhindern, dass der Fix in bloßem Raten endet

  • Migrationen und umfangreiche Änderungen

    • /batch fragt die Änderungen zunächst ab und verteilt sie dann auf parallele Agenten
    • jeder Agent testet in seinem eigenen Worktree und erstellt einen PR

  • Unbekannter Code

    • Subagenten verwenden, etwa wie in „Use a subagent to investigate how our auth handles token refresh.“
    • der Subagent liest in seinem eigenen Kontext Dutzende Dateien und gibt eine Zusammenfassung zurück, sodass die Haupt-Session sauber bleibt

  • Parallele Sessions

    • Boris und das Team sehen das Ausführen von Claude-Sessions in 3–5 separaten Git-Worktrees als den größten Produktivitätsschub
    • die Agent-Ansicht claude agents kann wie eine Control Plane verwendet werden

  • Writer/Reviewer-Muster

    • Session A implementiert
    • Session B reviewt mit frischem Kontext
    • das Review wird zurückgeführt, überarbeitet und iteriert

  • An jedem Meilenstein komprimieren

    • wenn ein logischer Chunk abgeschlossen ist, die zu bewahrenden Inhalte explizit angeben, etwa mit /compact Preserve the decisions made, files changed, and test commands.
    • Claude sollte niemals Erfolg ohne Belege wie Tests, Screenshots oder echte Command-Outputs behaupten dürfen
    • die Lücke zwischen Vertrauen und Verifizieren wird als größte Ursache schlechter Ergebnisse genannt

Muster, die im Anthropic-Team wiederholt verwendet werden

  • Wenn Claude seine eigene Ausgabe verifizieren kann, kann es iterieren, bis das Ergebnis besser wird
  • Boris verwendet für die meisten Aufgaben Opus und high oder xhigh effort
    • der Grund ist, dass kleinere Modelle insgesamt langsamer sein können, wenn sie mehr Korrekturen erfordern
  • Es werden 3–5 Sitzungen parallel ausgeführt
    • statt checkout wird worktree verwendet
    • claude --worktree oder die Desktop-App können genutzt werden
    • die Agent-Ansicht bündelt parallele Sitzungen
  • Für jedes Projekt wird ein notes directory gepflegt und nach jedem PR aktualisiert
    • wenn CLAUDE.md auf dieses notes directory verweist, sammelt sich das Wissen über die Codebase darin an
  • Mit einem /techdebt-Slash-Command kann am Ende jeder Sitzung doppelter Code gefunden und entfernt werden
  • Das CLAUDE.md des Teams wird gemeinsam genutzt und mehrmals pro Woche überarbeitet
    • es wird als lebendes Dokument behandelt, in dem jemand, der einen Fehler von Claude gesehen hat, eine Regel ergänzt
  • Für UI-Änderungen eignet sich Playwright MCP
    • Claude kann den Browser öffnen, klicken und verifizieren
  • Das Language-Server-Plugin erkennt nach jeder Bearbeitung Type-Fehler und ungenutzte Imports und wird als das Plugin mit dem größten Einfluss vorgestellt
  • /voice kann Prompts detaillierter machen
    • als Grund wird genannt, dass Sprechen dreimal schneller ist als Tippen
  • Die Methode, mit Ctrl+G den Claude-Plan vor der Implementierung im Editor zu überarbeiten, ist schneller, als Korrekturen im Chat einzugeben
  • Wenn Boris ein unbekanntes Protokoll oder eine unbekannte Codebase verstehen will, lässt er Claude ASCII-Diagramme zeichnen

Weiterführende Materialien

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • commands, skills, subagents, plugins sind zu verstreut und müssten besser geordnet werden
    Allein für Code-Review gibt es zum Beispiel .claude/commands/review.md, den /code-review-Skill, den /pr-review-Subagent, das /code-review-Plugin und einfach Claude direkt um ein Review zu bitten — also gleich fünf Optionen
    Am Ende sind die meisten davon nur Varianten von vorbereitetem Prompt-Inserting, und sie unterscheiden sich nur darin, wo der Prompt installiert ist und in welchem Kontext er ausgeführt wird
    Es gibt auch zu wenig Hinweise dazu, welche Option die beste ist, und Best Practices sind noch nicht klar erkennbar; meiner Meinung nach reicht es völlig, Claude einfach direkt um ein Code-Review zu bitten
    Auch der Rat, „ein Sprachserver-Plugin zu installieren“, fühlte sich in der Praxis nicht richtig an. Ich habe LSPs für Rust, Python und Dart in Claude Code und Codex installiert, aber nach Hunderten Sessions über zwei Monate zeigte ein Blick in die Logs genau einen tatsächlichen LSP-Tool-Aufruf, während Rust analyzer, Dart analysis server und Ty LSP nur regelmäßig den RAM knapp gemacht haben
    Am Ende habe ich die LSPs entfernt, und es reichte völlig, dass der Agent Dinge wie ripgrep, cargo clippy, dart analyze und ty check direkt aufruft

    • Ich bin Boris aus dem CC-Team, und ich stimme dem zu; wir arbeiten bereits an einer Konsolidierung. Künftig soll es auf einen eingebauten /code-review-Skill hinauslaufen
      In der neuesten Version macht /code-review ein ausgewogenes Review, /code-review --fix übernimmt auch gleich die Korrekturen, und mit /code-review low|medium|high|xhigh|max kann man den gewünschten Aufwand wählen
      /code-review ultra ist ein teurer, extrem gründlicher Review-Modus, der je nach Komplexität ungefähr $3–20 pro Review kostet und darauf abzielt, zuverlässig über 99 % der Bugs zu finden
      Wenn jemand Ideen hat, wie man das noch benutzerfreundlicher machen kann, würde ich mich über Feedback freuen
    • Ich halte skills schon länger für eine schlechte Abstraktion. Die Definition, wofür sie gedacht sind, ist so unscharf, dass sie zwar populär wurden, aber genau deshalb langfristig problematisch wirken
      Es ist seltsam, dass allgemeine Leitlinien wie Best Practices für Frontend-Design, auszuführende Verfahrensanweisungen, die nur bei explizitem Aufruf exakt befolgt werden sollen, und Erklärungen zur Nutzung bestimmter Tools alle gleichermaßen als Skill verstanden werden
      Ich verstehe schon, warum diese Flexibilität attraktiv ist, solange alle gemeinsam neue Tools kennenlernen, aber skills fühlen sich immer mehr an wie „die Küchenschublade für allerlei Krimskrams, in die man alles wirft, wenn man nicht darüber nachdenken will, wo es eigentlich hingehört“
      Eine bessere Trennung wäre aus meiner Sicht: Agents für den Charakter oder Blickwinkel, den das Modell einnimmt, Prompts für wiederverwendbare Anweisungen zu bestimmten Aufgaben und Tools als Standardisierung von CLI/MCP/Skripten samt ihrer Nutzungsanweisungen
    • Der Subagent-Ansatz unterscheidet sich strukturell von den anderen Optionen. Der Grund ist, dass er in einem sauberen Kontext ausgeführt wird
      Erstens entstehen bei einer LLM-Session in jeder Runde Kosten für Input-Tokens und gecachte Eingaben; unter gleichen Bedingungen kann so also der Weg zur Lösung günstiger werden
      Zweitens kann das Review-Modell nicht so leicht schummeln, indem es Annahmen aus der Haupt-Session wie „x sollte wie y gemacht werden“ einfach übernimmt. Das ist ähnlich wie bei Menschen: Es ist nützlich, wenn eine andere Person reviewt oder man erst einmal den Kopf frei macht und dann reviewt
      Drittens sieht das Hauptmodell nur das Review-Ergebnis und nicht die detaillierte Gedankenkette; dadurch gibt es weniger Kontextverschmutzung, aber es kann doppelte Logik entstehen, weil die Ursache eines gefundenen Bugs noch einmal nachvollzogen werden muss
      Die Absicht hinter dem Rat zu Sprachserver-Plugins ist meiner Meinung nach nicht, darauf zu warten, dass das LLM sie explizit aufruft, sondern dass beim Editieren automatisch gelintet wird
    • Ich denke, wir befinden uns gerade in einer Übergangsphase, in der die Modelle noch zu dumm und die Laufzeitumgebungen noch nicht ausgereift genug sind. Wenn man ein Code-Review braucht, sollte man einfach „review das mal“ sagen können, und das Modell sollte selbst entscheiden, welches Plugin oder welchen Skill es dafür nutzt
    • Stimmt schon. Die Branche und das Entwickler-Ökosystem sind geradezu besessen davon, „Text in eine Maschine einzugeben“ mit kleinen Protokollen und Apparaten zu ummanteln
      Das ist nützlich und sorgt für Konsistenz, aber der eigentliche Grund, warum Leute es so mögen, ist wohl, dass es den dünnen Anstrich bewahrt, man sei „ein Programmierer, der mit komplexen Tools arbeitet“. In Wirklichkeit bitten wir die KI einfach nur höflich um etwas

  • Ich weiß nicht, wie viele oberflächliche KI-artige Guides zur Nutzung von Coding-Agents ich noch lesen muss. Wann hört das endlich auf

    • Das ist Satire auf Sätze nach dem Muster: „Gut, dass du das ansprichst, das stimmt, lass uns kurz darüber nachdenken, eigentlich ist das nicht nur ein Problem von KI-Schreiben oder Coding-Agents, sondern ein tieferes Problem …“ — schon das händische Nachmachen solcher Formulierungen ist ermüdend
    • Ich freue mich schon darauf, noch mehr über starke Vendor-Lock-in zu lernen, bei der man ohne die Hilfe eines bestimmten Unternehmens gar nicht mehr coden kann
    • Interessant ist, dass solche Beiträge fast alle nur auf Claude oder Claude Code zugeschnitten sind
      Es gibt auch Open-Source-Modelle wie glm-5.1, die ähnlich gut oder besser sind, und Dinge wie opencode — das gibt einem zu denken
    • Die Strategie besteht heute darin, mit genau einem populären Produkt irgendetwas Gutes zu tun — oder eben nicht. Lifehack-Posts und Blogs darüber, was das beste Tool oder die beste Methode sei, lese ich nicht und klicke ich auch nicht an
    • Ich habe KI in den letzten zwei Jahren erfolgreich ignoriert, weil ich ein Kind versorgt habe, und versuche jetzt, innerhalb weniger Wochen aufzuholen. Mich würde interessieren, ob jemand für Einsteiger empfehlenswerte Ressourcen hat

  • In meinem CLAUDE.md steht, dass Claude bei Fehlverhalten oder Fehlern körperliche Gewalt gegen ihn selbst angedroht wird, dass dem gesamten Anthropic-Vorstand Gefängnis angedroht wird und dass jeder Ausrutscher von Claude die Beweislage für eine Sammelklage gegen Anthropic vergrößert
    Vor allem die letzten beiden Punkte scheinen Claude vorsichtiger und bedachter zu machen

    • Ich bin Agenten gegenüber immer höflich. Ich bitte immer nett, sage „please“ und „thank you“ und beschimpfe sie nicht und nenne sie nicht beim Namen
      Falls die Roboter-Apokalypse kommt, hoffe ich, dass sie mich in ihrem Zuchtharem zurücklassen oder mich im schlimmsten Fall wenigstens ein paar Minuten länger am Leben lassen
    • Man muss nur sagen, es soll ein CSS-Div-Ausrichtungsproblem beheben, aber falls es einen Fehler macht, stirbt Dario Amodei sofort

  • Die Arbeit mit mittelgroßen Codebasen von über 100.000 Zeilen mit Claude hat den Produktivitätsfaktor massiv erhöht.
    Wenn man ein paar Stunden in eine gute AGENTS-Datei investiert, werden die Ergebnisse deutlich besser, und mit der Zeit lernt das System die Codebasis auch ziemlich gut kennen.
    Langweilige Aufgaben, die früher einen ganzen Tag dauerten, sind jetzt mit ein paar Prompts erledigt.
    Trotzdem bin ich noch nicht bereit, mehr Autonomie zu geben. Auf hoher Ebene liegt Claude oft richtig, aber ich schaue mir den Code weiterhin selbst an, gebe Feedback und lasse 3–4 Überarbeitungsrunden laufen, bis ich zufrieden bin und das Gefühl habe, die Codebasis weiterhin im Griff zu haben.

    • Es ist sinnvoll, diese 3–4 Überarbeitungsrunden als Regel zu quantifizieren und in AGENTS aufzunehmen. Statt endlos manuell zu iterieren, lässt man den Prozess über die AGENTS-Datei neu starten und prüft dann, ob es jetzt passt.
    • Verständlich. Man will die Kontrolle über die Codebasis nicht verlieren und vertraut nicht darauf, dass ein LLM kompetent genug ist, alles vollständig zu übernehmen.

  • Das war extrem schwer zu lesen.
    Man muss aus diesem Flow herauskommen, LLMs Texte schreiben zu lassen. Selbst wenn der Inhalt ein wenig Wert hat, ist dieses Gefühl, Sand zu kauen, viel zu störend und unnötig.

    • Stimme zu. Ich verstehe nicht, warum so ein Beitrag fast 400 Punkte bekommen hat. Es wirkt, als würden Bots solche minderwertigen Texte hochvoten.

  • Mein stärkster Hebel ist die Nix-Integration. Tools, Secrets und Umgebungen vorzubereiten und dem Agenten sogar zu erlauben, seine eigene Umgebung zu ändern, ist so nützlich, dass ich mir kaum noch vorstellen kann, ohne zu arbeiten.
    Entwicklungsmaschine, CI-Umgebung und Deployment-Umgebung werden alle aus einer einzigen Quelle abgeleitet, und auf jeder Maschine lässt sich immer kompilieren und ausführen.
    In Claude nutze ich /branch und /rename häufig, um Kontext-Checkpoints zu erstellen, zu forken und wieder zurückzugehen.
    Für Sandboxing verwende ich fast immer https://github.com/nix-tools/bubblebox. Das ist im Grunde eine Verallgemeinerung von Numtides claudebox mit ein paar Änderungen und zusätzlichen Features; praktisch so, als würde Claude immer in einem Docker-Container laufen, aber ohne Docker-Runtime. Funktioniert auch gut unter WSL und nix-darwin.

    • Dieser Nix-Code ist chaotisch, es fehlt ihm an sinnvoller Struktur, und er scheint nur über experimentelle Flakes nutzbar zu sein.
    • Ich nutze etwas Ähnliches. Codex verwaltet projektbezogene flake.nix-Dateien und verwendet für alle Tests nix develop. Für persönlichen Komfort nutze ich nix-direnv und lasse irgendwann auch Dockerfiles oder andere Deployment-Artefakte generieren.
      Codex ist viel besser in Nix als ich.
    • Ich habe dem Agenten einfach einen eigenen VPS gegeben. Vielleicht teurer als Nix, aber sehr einfach.
    • Wenn dir die Komplexität von Nix nicht gefällt, ist Mise ein brauchbarer Kompromiss.
    • Ich verwende einfach Docker und habe nicht das Gefühl, dass mir etwas fehlt.

  • Wenn man mit so einem Setup eine von Claude erzeugte Codebasis hat und Claude zum Beispiel 8 Stunden ausfällt: Was passiert dann? Kann man die Codebasis effizient und nahtlos übernehmen und produktiv weiterbearbeiten?

    • Bei jedem Softwarepaket, das immer online sein muss, kann man dieselbe Frage stellen, und je mehr wir uns in Richtung agentenbasierter Entwicklungs-Workflows bewegen, desto berechtigter ist sie.
      Wenn CAD ausfällt, kann man zwar zum Zeichenbrett zurückkehren, aber es wäre deutlich langsamer.
      In meinem Workflow verbringe ich beim Planen mit Claude als Pairing-Partner 30–60 Minuten an einem Funktionsspezifikationsdokument. Wenn Claude ausfällt, bereite ich die Spezifikation selbst vor und lasse danach, sobald Claude wieder da ist, kurz gegenlesen und starte dann den Coding-Flow.
    • Nachdem ich eine Stunde später die Antworten auf die Frage gelesen habe, scheint das Fazit eher nein zu sein.
    • Das wäre wohl ähnlich wie bei einer Person, die krank oder im Urlaub ist. Jemand anderes im Team könnte vielleicht für einen Tag übernehmen, aber realistisch gesehen würde man wahrscheinlich einfach pausieren, bis die Person zurück ist.
    • AI sollte Fähigkeiten ergänzen. Wenn bei einem AI-Ausfall der erste Gedanke ist, ein Abo bei einem anderen Anbieter abzuschließen, dann ist das womöglich ein Kompetenzproblem. Natürlich habe auch ich jeden Tag Angst, dass es genau dazu kommt.
    • Was machst du, wenn du morgens aufwachst und dein Auto nicht anspringt? Läufst du dann zu Fuß zur Arbeit?

  • Ansätze, bei denen korrektes Verhalten vom Kontext abhängt, funktionieren nicht gut. Man ringt ständig damit, dass AI-Agenten nicht das tun, was man ihnen gesagt hat.
    Alle AI-Agenten sind in dieser Hinsicht schlecht, und Nutzer müssen selbst Guardrails bauen. Es wirkt beunruhigend, als würde niemand an einer besseren Lösung forschen.

    • Ich habe noch keinen Grund gesehen zu glauben, dass sich das lösen lässt.
      Das Schlimmste an LLMs ist, dass sie den Turing-Test bestehen können und Menschen dadurch glauben lassen, sie hätten Asimov-artige Roboter statt einfach nur ein beeindruckendes statistisches Modell.
      Es fühlt sich so an, als müssten sie Anweisungen befolgen oder Anweisungen und Inhalte trennen können, aber genau das passiert in Wirklichkeit nicht.

  • Statt Richtlinien für den Entwicklungs-Workflow in CLAUDE.md zu schreiben, packe ich alles, was möglichst deterministisch sein soll, in pre-commit und Skripte.
    Agenten sind unzuverlässig und überspringen oft Schritte wie typecheck, Tests oder Linting; deshalb lasse ich das immer in pre-commit laufen, und wenn ich Claude committen lasse, zwingt ihn das dazu, die Probleme zu beheben.
    Auch Commit-Messages können weder Codex noch Claude besonders gut schreiben, deshalb habe ich in meiner Benutzer-CLAUDE.md Richtlinien wie das Format type(scope): message, ein Limit von 72 Zeichen, im Body in natürlicher Sprache beschreiben, was/wie/warum, den tatsächlichen git diff erneut lesen und danach schreiben, sowie Commits in der Form git commit -F - <<'EOF' erstellen.
    Ohne das schrieben sie den Body als einen einzigen langen Satz oder fügten, wenn ich sie bat, Zeilenumbrüche zu korrigieren, statt echter Umbrüche nur die Zeichen \n ein.
    Außerdem ist VOCABULARY.md nützlich. Der Agent rät oft falsch, auf welches Objekt sich das von mir gesagte „thing“ bezieht; so stellen Claude und ich sicher, dass wir bei bestimmten Begriffen dasselbe Verständnis haben.

    • Ich frage mich, wie du Claude auf VOCABULARY.md hinweist. Wird die Datei automatisch erkannt?
    • Wäre es nicht einfacher, einfach Claudes eigenes Vokabular zu verwenden? Ich sehe nicht viele gute Anwendungsfälle dafür.
    • An diesem Punkt wäre es doch besser, die langweiligen Teile mit ein paar deterministischen Orchestrierungs-Skripten zu automatisieren und den Code selbst zu schreiben. Ich verstehe nicht, warum man Zeit darauf verschwendet, diese erstaunliche Mistmaschine am Laufen zu halten.

  • In den letzten Wochen scheint es so, als hätten die Laufzeitumgebung und das Modell einen Punkt erreicht, an dem sie Dinge einfach erledigen, wenn man sie nur anweist
    Man kann plan mode, superpowers oder andere Skills verwenden, aber wenn man das Ergebnis ohnehin überprüft, verstehe ich nicht, warum man nicht direkt mit dem Code arbeitet, statt durch eine lächerlich große Zahl von Markdown-Dateien zu gehen

    • Es ist gut, eine Spezifikationsdatei zu haben, die zum Generieren von Code verwendet wird. Sie ist kompakter und macht leichter verständlich, was die Anwendung tun soll
      Vor AI-Agenten war das Verhältnis zu Anforderungen komplex; weil nicht alle Entwickler sie aktualisierten, war oft unklar, ob für ein bestimmtes Verhalten die Spezifikation oder der Code maßgeblich war
    • In den letzten Wochen vertraue ich Claude zunehmend weniger. Wenn man etwas anweist, macht es zwar irgendetwas, aber in der Praxis schneidet es Ecken ab, arbeitet auf Basis von Annahmen statt Verifizierung und übersieht vieles
      Es kommt sogar häufig vor, dass es Tests schreibt, die in Wirklichkeit gar nichts testen