Custom Claude Code Commands: Mein persönliches Setup für maximale Produktivität

Ich bezahle 600 Dollar im Monat für Claude. Drei Max20-Accounts, jeder einzelne regelmäßig bei 100% der Wochengrenze. Einmal habe ich 12 Claude Code Sessions gleichzeitig auf meinem M4 Air gestartet. Das war zu viel. Aber 5 parallel? Das funktioniert einwandfrei.

Das klingt nach Overkill. Ist es wahrscheinlich auch. Aber ich schreibe kaum noch selbst Code. Claude macht das. Nicht weil ich faul bin. Nach 10 Jahren Rails-Entwicklung habe ich verstanden, dass mein Job nicht das Tippen ist. Mein Job ist das Orchestrieren, das Denken, die Architektur.

In diesem Artikel zeige ich dir mein komplettes Setup. Die Commands die mir täglich Stunden sparen, die Skills die Claude schlauer machen, die MCP Server die externe APIs anzapfen, und die Agents die spezialisierte Aufgaben übernehmen. Und vor allem: /generate-prompt. Den kennt kaum jemand, aber er ist vermutlich der wichtigste Command den ich habe.

Wer bin ich und warum sollte dich das interessieren

Kurzer Hintergrund: Ich bin Daniel Samer, Senior Rails Backend Developer bei Linkster GmbH. Über meine Karriere erfährst du mehr. Seit 2001 programmiere ich. Seit meinem 18. Lebensjahr baue ich Automationen. Über 50 Projekte, von WoW Auction House Bots bis Twitter-Armeen. Die Geschichte meiner Projekte zeigt wie das alles angefangen hat. RLTracker.pro, Golem Overlord, Splex.gg. Die meisten meiner bisherigen Projekte sind mittlerweile komplett mit Claude Code gebaut worden. Alles selbst gehostet, alles von mir alleine.

Die letzten zwei Jahre habe ich intensiv mit Claude gearbeitet. Zuerst die API, dann claude.ai, jetzt fast ausschließlich Claude Code. Mein Workflow hat sich komplett verändert. Früher habe ich Probleme verstanden, Code geschrieben, getestet, debugged. Heute verstehe ich das Problem, instruiere Claude, mache ein Review, und merge. Der Unterschied ist gewaltig.

Die Code Reviews bei der Arbeit mache ich noch selbst. Alles andere? Claude.

Der Workflow: 5 Sessions parallel, eine Codebase

Ich fahre regelmäßig 5 Claude Code Sessions gleichzeitig auf derselben Codebase. Ohne Git Worktrees. Das klingt nach Chaos. Ich war selbst skeptisch. Aber es funktioniert erstaunlich gut.

Ich sitze und plane in allen Sessions nacheinander. Die Sessions wissen nicht voneinander. Sie wissen nicht einmal, dass sie parallel laufen. Ich bin der Orchestrator. Nicht Claude.

Typische Aufteilung:

• Eine Session arbeitet an Feature A

• Eine andere an Feature B

• Eine aktualisiert die CLAUDE.md, baut Commands, Skills oder Agents

• Eine schreibt einen Blogpost

• Eine macht Code Review

Warum funktioniert das ohne Worktrees? Git-Konflikte passieren nie. Wirklich nie. Da wir keine Worktrees nutzen, arbeiten alle Sessions im selben Verzeichnis. Wenn zwei Sessions versuchen dieselbe Datei zu bearbeiten, passiert etwas anderes. Eine Session hat dann nicht sofort die neueste Version der Datei. Sie arbeitet mit dem Stand von vor der Änderung. Das ist kein Git-Konflikt-Problem. Es geht um Synchronisation.

Der Trick ist simpel. Ich achte darauf, dass Sessions an unterschiedlichen Bereichen arbeiten. Feature A fasst andere Dateien an als Feature B. Der Blogpost-Writer berührt keinen Code. Der Code Reviewer liest nur. Funktioniert nicht immer perfekt, aber meistens.

/generate-prompt: Der wichtigste Command den kaum jemand kennt

Ich erkläre dir jetzt den Command, der mir wahrscheinlich am meisten Zeit spart. Er löst das größte Problem von Claude Code: Kontext-Verlust.

Kennst du das? Du arbeitest zwei Stunden an etwas. Claude versteht den Kontext perfekt. Dann wird die Session zu groß. Du hast zwei Optionen. /compact nutzen und einen deutlich "dümmeren" Claude zurückbekommen. Oder neu starten und den Kontext mühsam wieder aufbauen. Beides ist frustrierend.

/generate-prompt löst das. Der Command analysiert den aktuellen Kontext und generiert einen strukturierten Prompt. Den kopierst du in eine neue Session. Der neue Claude hat sofort den relevanten Kontext. Ohne die ganze History, aber mit allem was wichtig ist.

Der Command analysiert die aktuelle Aufgabe, bereits erledigte Schritte, offene Punkte, relevante Dateipfade, und getroffene Entscheidungen. Das Ergebnis ist ein Markdown-Dokument, direkt kopierbar.

Ich nutze das mehrmals täglich. Besonders wenn ich zwischen Accounts wechsle oder Sessions sterben.

Es hat drei Iterationen gebraucht bis der Command vernünftig funktionierte. Die erste Version hat zu viel Kontext generiert. 2000 Zeilen die niemand lesen wollte. Die zweite war zu knapp. Die jetzige Version ist ein Kompromiss, und funktioniert für mich gut genug.

Die wichtigsten Built-In Features

Bevor wir zu den Custom Commands kommen, hier die eingebauten Features die ich ständig nutze.

--dangerously-skip-permissions: Startet Claude Code ohne Permission-Prompts. Ja, der Name ist absichtlich abschreckend. Aber wenn du weißt was du tust und Claude Code nur in lokalen Projekten nutzt, spart das enorm Zeit. Kein "May I read this file? May I run this command?" mehr. Ich nutze das immer.

/clear: Leert den Kontext. Wichtig wenn Sessions zu groß werden. Claude wird langsamer und unpräziser je größer der Kontext. Ein strategisches /clear hilft. Allerdings verlierst du dabei alles.

/compact: Komprimiert den Kontext. Behält wichtige Informationen, wirft Unwichtiges raus. Guter Kompromiss wenn du nicht alles verlieren willst. Die Qualität sinkt trotzdem spürbar.

Custom Commands die ich täglich nutze

/commit

Mein Custom Command für Commits. Claude analysiert die Änderungen und generiert eine sinnvolle Commit-Message. Spart mir das Nachdenken über Commit-Messages.

/deploy

Mein Deploy-Workflow in einem Command. Deutlich intelligenter als "Tests prüfen, deployen". Der Command folgt einem strikten Workflow. Erst wird automatisch /commit ausgeführt (Commit-First-Workflow), dann analysiert er die letzten Commits auf Asset-Änderungen. Hat sich JavaScript, CSS oder die Tailwind-Config geändert? Dann --full Deploy mit Asset-Recompilation. Nur Backend-Code? Dann --with-workers für einen schnelleren Deploy.

Der wichtigste Teil sind die Git-Sicherheitsregeln für Production. Der Command nutzt niemals git reset --hard auf dem Server, weil dort auto-generierte Inhalte (wie Blogposts) liegen können, die noch nicht gepusht wurden. Bei Konflikten wird erst committed, dann gemerged. Diese Regel existiert, weil ich einmal Blogposts verloren habe. Das passiert mir nicht nochmal.

/enhance-claude-md

Das ist ein Plugin, nicht nur ein einfacher Command. Es hat drei Modi. analyze bewertet den bestehenden CLAUDE.md. create generiert einen neuen. enhance verbessert einen bestehenden.

Was es besonders macht: Es kann modulare Architekturen generieren. Statt eines monolithischen CLAUDE.md erstellt es backend/CLAUDE.md, frontend/CLAUDE.md und eine Root-Datei als Navigation-Hub. Das ist wichtig bei größeren Projekten. 500+ Zeilen in einer Datei werden unübersichtlich.

Der Workflow ist interaktiv. Das Plugin erkundet erst das Repository, erkennt Tech-Stack und Projekttyp, zeigt die Erkenntnisse, und fragt um Bestätigung bevor es Dateien erstellt.

CLAUDE.md ist der Kontext den Claude bei jeder Session lädt. Je besser er ist, desto weniger muss ich erklären. Investition in CLAUDE.md zahlt sich aus.

/claude-factory:build

Das ist mein Meta-Command. Er ist selbst ein Orchestrator. Er schreibt nie selbst Dateien, sondern delegiert an vier spezialisierte Agents:

• skills-guide baut Custom Skills durch Q&A

• agents-guide baut Custom Agents durch Q&A

• hooks-guide baut Custom Hooks durch Q&A

• command-guide baut Custom Commands durch Q&A

Der Command unterstützt CREATE und UPDATE Modi. Will ich einen bestehenden Skill verbessern? /build update skill path/to/skill delegiert an den skills-guide mit dem Kontext der existierenden Dateien.

Meta-Automation auf Meta-Ebene. Ein Command der Commands baut, der selbst aus Commands besteht, die Agents nutzen. Das ist das Level auf dem ich mittlerweile arbeite. Manchmal frage ich mich selbst, ob das zu viel Abstraktion ist. Wahrscheinlich nicht.

Das Skills System erklärt

Skills sind technisch minimal anders als Commands. Aber konzeptuell sind sie wichtig. Der Hauptunterschied ist, dass Skills YAML-Frontmatter mit mehr Optionen haben, wie context: fork für isolierte Ausführung.

Commands leben in .claude/commands/. Skills können überall liegen. Funktional erstellen beide Slash-Commands.

Was Skills wirklich mächtig macht

Skills sind projekt-spezifische Knowledge-Dumps. Ein Beispiel aus meinem Setup: project-styling enthält mein komplettes Farbsystem mit auto-adaptierenden CSS-Variablen für Dark/Light Mode, die Terminal-inspirierte Ästhetik, und alle Komponenten-Patterns. Wenn Claude diesen Skill lädt, kennt er sofort surface-primary, content-secondary, border-default. Ich muss nichts mehr erklären.

Für Frontend-Arbeit lade ich immer vier Skills gleichzeitig. project-styling für das Farbsystem, design-principles für die Jony-Ive-inspirierte Minimal-Ästhetik, stimulus-patterns für JavaScript-Interaktivität, und tailwindcss für TailwindCSS v4 Patterns. Das macht Claude sofort produktiv für UI-Arbeit. Ohne diese Skills würde ich viel mehr Zeit mit Erklärungen verschwenden.

Wann Skills, wann Commands?

Ich habe anfangs alles als Skill gebaut. Das war Overkill. Jetzt nutze ich Commands für alles was unter 20 Zeilen ist. Deploy-Skripte, Quick Fixes, Git Commands. Skills nur wenn ich Sub-Tasks brauche, isolierten Kontext, oder einen großen Knowledge-Dump der geladen werden muss.

Warum? Commands sind schneller. Keine Dateiorganisation, keine YAML-Komplexität. Skills haben Features wie context: fork für isolierte Ausführung. Aber das braucht man nur bei komplexeren Workflows.

Meine Struktur:

.claude/
├── commands/           # Einfache Commands
│   ├── commit.md
│   ├── deploy.md
│   └── generate-prompt.md
├── skills/            # Komplexe Skills
│   ├── content-writer/
│   │   ├── SKILL.md
│   │   └── templates/
│   └── code-reviewer/
│       └── SKILL.md
└── agents/            # Custom Agents
    ├── rails-backend-engineer.md
    └── frontend-rails-engineer.md

MCP Server: Claude mit externen APIs verbinden

MCP (Model Context Protocol) macht Claude Code deutlich praktischer. Es verbindet Claude mit externen Datenquellen.

Es gibt über 1.200 verfügbare MCP Server da draußen. Ich nutze davon vielleicht 8 regelmäßig. Die meisten braucht man wahrscheinlich nie.

Meine aktiven MCP Server

context7: Lädt aktuelle Dokumentation für Libraries. Wenn ich mit einer Library arbeite die Claude nicht kennt (oder falsch kennt), zieht context7 die aktuelle Doku. Das spart viel Debugging.

nanobanana: KI-Bildgenerierung direkt in Claude Code. Für Blogpost-Banner, Screenshots, Visualisierungen. Die Qualität ist okay, nicht perfekt.

playwright: Browser-Automation. Claude kann Screenshots machen, auf Webseiten navigieren, Formulare ausfüllen. Nutze ich für Testing und Verification. Manchmal etwas wackelig.

dataforseo: SEO-Daten. Keyword-Recherche, SERP-Analyse, Backlink-Checks. Direkt in Claude Code ohne externes Tool. Vermutlich mein am häufigsten genutzter MCP für Content.

trello: Projektmanagement-Integration. Claude kann Cards lesen, erstellen, verschieben. Mein Content-Workflow läuft komplett über Trello-MCP.

filesystem: Erweiterter Dateizugriff. Der Standard ist limitiert. Filesystem MCP gibt Claude mehr Möglichkeiten.

MCP Server einrichten

Die Konfiguration liegt in .mcp.json:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@context7/mcp-server"]
    },
    "trello": {
      "command": "node",
      "args": ["./mcp-servers/trello/index.js"],
      "env": {
        "TRELLO_API_KEY": "xxx",
        "TRELLO_TOKEN": "xxx"
      }
    }
  }
}

Wichtig: MCP Server laden bei Session-Start. Je mehr Server, desto länger der Start. Ich aktiviere nur was ich wirklich brauche. Das Laden kann sonst einige Sekunden dauern.

Custom Agents: Spezialisierte KI-Instanzen

Agents sind delegierte Sub-Tasks mit isoliertem Kontext. Der Hauptagent sagt: "Geh und recherchiere X." Der Subagent macht das und kommt mit dem Ergebnis zurück. Das Konzept hat mir anfangs nicht eingeleuchtet. Aber nach ein paar Wochen Nutzung will ich es nicht mehr missen.

Mein /Users/danielsamer/agents/ Verzeichnis hat 15+ Agents. Hier die wichtigsten.

@rails-backend-engineer

Spezialisiert auf Rails-Backend-Code. Kennt meine Service-Object-Patterns, weiß wie ich Database-Queries strukturiere, versteht meine Testing-Konventionen. Wahrscheinlich mein am häufigsten genutzter Agent.

@frontend-rails-engineer

Für Frontend-Arbeit. Kennt Hotwire, Stimulus, TailwindCSS. Weiß dass ich surface-* und content-* CSS-Variablen nutze. Wird immer mit vier Skills geladen: project-styling, design-principles, stimulus-patterns, tailwindcss. Das Setup dauert eine Minute, spart aber Stunden.

@code-quality-guardian

Review-Agent. Prüft Code auf Qualitätsprobleme, fehlende Tests, Security Issues. Läuft nach jeder Implementation. Findet manchmal Dinge die ich übersehen habe.

@dead-code-detector

Findet ungenutzten Code. Orphaned References, unused Methods, deprecated Imports. Läuft nach Refactorings. Ehrlich gesagt nutze ich den nicht so oft wie ich sollte.

Die Agent-Delegation funktioniert ungefähr so:

Hauptagent: "Analysiere diese PR und prüfe auf Security Issues."
↓
Delegation an @code-quality-guardian
↓
Guardian arbeitet in isoliertem Kontext
↓
Ergebnis kommt zurück zum Hauptagent
↓
Hauptagent fasst zusammen oder delegiert nächste Aufgabe

Das ist der Workflow der mir erlaubt, mehrere Sessions parallel zu fahren. Ich orchestriere, die Agents arbeiten. Manchmal geht etwas schief, aber meistens funktioniert es überraschend gut.

Hooks: Automatische Aktionen bei Lifecycle-Events

Claude Code unterstützt 12 verschiedene Hook-Events. Ich nutze zwei davon intensiv, beide auf demselben Event: UserPromptSubmit. Das klingt komplizierter als es ist.

skill-forced-eval-hook

Das Problem ist bekannt. Claude "vergisst" manchmal Skills zu laden, obwohl sie verfügbar sind. Mein Hook erzwingt die Evaluation bei jeder einzelnen Nachricht, nicht nur beim Session-Start.

Der Hook liegt in ~/.claude/scripts/skill-forced-eval-hook.sh und wird bei UserPromptSubmit getriggert. Das bedeutet: Bevor Claude auf irgendeinen meiner Prompts antwortet, wird ein SKILL-EVALUATION Block injiziert. Der zwingt Claude, alle verfügbaren Skills zu evaluieren und die relevanten zu laden.

Der Unterschied zu SessionStart ist wichtig. UserPromptSubmit feuert bei jeder Nachricht. Das ist nötig, weil sich der Kontext während einer Session ändern kann. Was am Anfang nicht relevant war, kann später wichtig werden.

Der Orchestrator-Mode Hook (-s Flag)

Mein zweiter Hook auf UserPromptSubmit ist vermutlich noch interessanter: append-subagent.py. Er wird nur aktiv wenn mein Prompt mit -s endet.

Wenn ich eine Nachricht mit -s beende, wird Claude in den Orchestrator-Mode versetzt. Das bedeutet er schreibt nie selbst Dateien. Er delegiert alles an spezialisierte Subagents. Er nutzt erst einen prompter Agent um optimale Prompts zu generieren, dann die eigentlichen Arbeiter-Agents.

Warum ist das wichtig? Es ermöglicht mir, mehrere Claude-Sessions parallel auf derselben Codebase zu fahren ohne Konflikte. Der Orchestrator in einer Session weiß nicht von anderen Sessions. Aber weil er selbst keine Dateien anfasst, gibt es keine Race Conditions. Das ist zumindest die Theorie. In der Praxis funktioniert es meistens.

Weitere nützliche Hooks

PreToolUse: Validierung vor Tool-Ausführung. Ich nutze das um bestimmte Commands zu blocken oder zu warnen. Nützlich für Sicherheit.

PostToolUse: Logging, Notifications. Könnte Slack-Benachrichtigungen senden wenn bestimmte Actions passieren. Nutze ich ehrlich gesagt kaum.

Stop: Autonome Workflows. Der "Ralph Wiggum Loop" nutzt Stop-Hooks für iterative Entwicklung. Das ist ein Thema für einen eigenen Artikel.

Die Content Machine (kurzer Einblick)

Ich habe ein System gebaut das ich "Content Machine" nenne. Es generiert Blogposts, managed Recherche, optimiert für SEO. Das System ist komplex genug für einen eigenen Artikel. Vielleicht schreibe ich den irgendwann.

Hier nur soviel: Es kombiniert alles was ich beschrieben habe. MCP Server für Keyword-Recherche (dataforseo), Agents für verschiedene Schreibphasen (topic-researcher, seo-writer), Skills für Humanization (humanize-content), Trello-Integration für Workflow-Management.

Ein Blogpost wie dieser hier durchläuft mehrere Phasen. Topic-Idee, dann Trello-Card, dann Keyword-Recherche, dann Topic-Research, dann Draft, dann Optimization, dann Publish. Alles orchestriert durch Claude Code. Mit solchen Systemen biete ich auch AI Workflow Automation Dienstleistungen an, sowie ein Content Generation System für automatisierte Inhalte.

Die Details halte ich zurück. Aber das Prinzip ist simpel. Kombiniere die Tools zu Workflows die größer sind als ihre Teile. Das klingt abstrakt, ist aber in der Praxis erstaunlich mächtig.

Praktische Setup-Empfehlungen

Wenn du dein Claude Code Setup verbessern willst, hier meine Empfehlungen. Ich habe einige Fehler gemacht auf dem Weg. Vielleicht kannst du sie vermeiden.

Fang mit CLAUDE.md an

Das ist vermutlich der höchste ROI. Dokumentiere was wichtig ist.

• Projektstruktur

• Coding Conventions

• Häufige Patterns

• Was Claude NICHT tun soll

Dokumentiere alles. Das zahlt sich aus.

Bau deine ersten Commands

Starte mit einfachen Automationen. Ein Commit-Command mit deinen Präferenzen, ein Test-Command der dein Testframework kennt, ein Deploy-Command für deinen Workflow. Nichts Kompliziertes am Anfang.

Dann MCP Server

Fang mit einem an. context7 ist gut für Library-Docs. Oder filesystem für erweiterten Dateizugriff. Bau langsam aus. Zu viele Server auf einmal verwirren nur.

Agents später

Agents sind mächtig aber komplex. Versteh erst Commands und Skills bevor du Agents baust. Die Delegation ist ein anderes Paradigma. Ich habe Wochen gebraucht bis ich das verstanden habe.

Der wichtigste Tipp

Der wichtigste Tipp den ich gelernt habe: Plan Mode nutzen. Shift-Tab wechselt dazu. Claude erklärt was er vorhat bevor er es tut. Das spart Tokens und Frustration. Ich hätte das früher wissen sollen.

Warum das alles funktioniert

Ich habe am Anfang gesagt: Mein Job ist nicht das Tippen. Mein Job ist das Orchestrieren.

Das Setup das ich beschrieben habe ermöglicht genau das. Claude schreibt den Code. Ich definiere die Architektur. Claude implementiert. Ich reviewe. Claude korrigiert. Ich merge. Das ist der Loop.

600 Dollar im Monat klingt nach viel. Aber rechne es durch. Wenn ich dadurch 4 Stunden am Tag spare, und mein Stundensatz bei Freelance-Arbeit 100 Euro ist, spare ich theoretisch 8.000 Euro im Monat. Die 600 Dollar sind ein Rundungsfehler. Ob die Rechnung exakt so aufgeht, weiß ich nicht. Aber die Richtung stimmt.

Das ist der eigentliche Punkt. Es geht nicht um coole Tools. Die Tools multiplizieren meinen Output. Ich produziere in einer Woche was früher vermutlich einen Monat gedauert hätte. Zumindest fühlt es sich so an.

Und ja, manchmal läuft Claude gegen eine Wand. Manchmal versteht er nicht was ich will. Manchmal macht er Fehler die ich korrigieren muss. Das passiert öfter als ich zugeben möchte. Aber insgesamt ist die Produktivitätssteigerung real.

Der beste Moment ist wenn ich morgens aufwache und sehe dass die Overnight-Session ein Feature fertig implementiert hat. Während ich geschlafen habe. Das klingt nach Science Fiction. Ist es aber nicht.