Dieselben Build-Befehle, Linter-Regeln und Architekturregeln in jedem Prompt zu wiederholen verlangsamt deine Arbeit. Lagere diesen festen Kontext einmal in Repository-Dateien und Tool-Integrationen aus. Dein Prompt beschreibt dann nur noch die aktuelle Aufgabe.
Projektregeln einmal mit # speichern
Drücke # in Claude Code, um eine Regel direkt in CLAUDE.md zu speichern. CLAUDE.md enthält Anweisungen, die Claude Code zu Beginn jeder Sitzung lädt. Regeln für ein einzelnes Repository speicherst du in ./CLAUDE.md, damit das Team sie über die Versionskontrolle teilt. Persönliche Regeln für alle Repositories speicherst du in ~/.claude/CLAUDE.md.
# Project rules
- Run `npm test` after any route or schema change.
- Keep SQL queries inside `src/db/`, never inside UI components.Eine kurze Regelliste ersetzt dieselbe Erinnerung über zehn Chat-Verläufe hinweg. Wenn sich eine Projektregel ändert, aktualisiere CLAUDE.md direkt in demselben Commit wie den Code.
Slash-Commands für wiederkehrende Aufgaben bauen
Speichere Markdown-Prompt-Vorlagen in .claude/commands/, um wiederkehrende Aufgaben in Slash-Commands zu verwandeln. Jede Datei erzeugt einen Befehl, den du mit /name aufrufst. Unterordner in .claude/commands/ ordnen verwandte Befehle, und $ARGUMENTS übergibt Eingaben wie einen Dateipfad oder einen Routennamen.
Review the endpoint in `$ARGUMENTS` against `eslint.config.mjs`.
Check input validation, status codes, and error responses.
List failing checks before proposing edits.Speichere diese Vorlage unter .claude/commands/review-endpoint.md und starte dann /review-endpoint src/routes/orders.ts. Du tippst nicht mehr jeden Tag dieselben Linter- und Endpoint-Anweisungen neu.
MCP-Server für aktuelle Dokumentation und Tools verbinden
Verbinde externe Tools über das Model Context Protocol, kurz MCP, damit Claude Code echte Daten liest statt veralteter Beispiele aus dem Training. Du konfigurierst diese Server über Claude Code MCP. Vier häufige Server decken unterschiedliche Teile eines Setups ab:
- Context7 lädt aktuelle Bibliotheksdokumentation, sodass das Modell die heutige API nutzt statt eines veralteten Trainingsbeispiels.
- Supabase prüft Datenbankschemata und führt Migrationen direkt in deinem Projekt aus.
- Playwright oder Chrome DevTools steuert einen Browser, um gerenderte Seiten, Netzwerkanfragen und Konsolenfehler zu prüfen.
- Stripe oder Vercel liest Zahlungsstatus und Deployment-Logs, sodass du keine Logs von Hand aus Dashboards kopierst.
Aktuelle Dokumentation und echte Tool-Ausgaben verhindern, dass das Modell Methoden aufruft, die in deinen Abhängigkeiten nicht existieren.
Subagenten parallel mit konkreten Aufgaben starten
Übergib getrennte Aufgaben an Subagenten, die parallel laufen. Jeder Subagent arbeitet in seinem eigenen Kontextfenster, sodass gelesene Dateien und Testausgaben deine Hauptsitzung nicht füllen.
Gib jedem Subagenten eine konkrete Aufgabe statt eines erfundenen Jobtitels. Lass einen Subagenten eine langsame Abfrage optimieren, einen zweiten die API-Dokumentation ergänzen und einen dritten die UI-Zustände im Browser prüfen. Eine konkrete Aufgabe gibt dem Subagenten ein klares Ziel, eine Rolle wie „Senior Backend Architect“ dagegen nicht.
Das Setup als Plugin verpacken
Bündle deine Slash-Commands, Subagenten und die MCP-Server-Konfiguration in einem einzigen Plugin. Wenn du ein neues Repository startest, installierst du das gesamte Setup mit einem Befehl, statt versteckte Konfigurationsdateien von Hand zu kopieren.
Versionierte Plugins halten außerdem ein Team auf demselben Setup. Wenn jemand einen Review-Befehl verbessert oder einen MCP-Server ergänzt, erhält jedes Teammitglied diese Änderung beim nächsten Installieren.
Spezifikation zuerst schreiben und in einer neuen Sitzung prüfen
Schreibe die Spezifikation, bevor du Code anforderst. Zerlege größere Arbeit in kleine Schritte, wie ich es in KI-gestütztes Coding braucht kleinere Schleifen beschrieben habe. Wenn eine Anforderung noch unklar ist, aktiviere den Plan Mode, damit Claude Code Fragen stellt, bevor es eine Datei ändert.
Öffne vor dem Ausliefern eine frische Sitzung, die git diff prüft, also die zeilenweise Übersicht aller Änderungen. Lass diese neue Sitzung den Diff gezielt auf Sicherheitslücken, Performance-Rückschritte und fehlende Fehlerbehandlung prüfen. Die Sitzung, die den Code geschrieben hat, kennt ihre eigene Absicht und übersieht oft Fehler, die sie zuvor selbst begründet hat.
Schneller Code, der in Produktion ausfällt, ist nicht schneller.