Pro-Workflows & Power-Moves
- Parallele Subagents orchestrieren — und wissen, wann der Wechsel zu einem skriptgesteuerten dynamischen Workflow sinnvoll ist
- Hooks zum deterministischen Bindeglied machen: Lint beim Speichern, Stop absichern, verbotene Schreibvorgänge blockieren
- Deine wiederholten Prompts in eigene Slash-Commands, Skills und einen Output-Style verwandeln
- Einen MCP-Stack und Headless-Pipelines (claude -p) bauen, die unbeaufsichtigt in der CI laufen
- Die Schleife explore → plan → execute → review mit Disziplin durchlaufen und den Kontext schlank halten
- CLAUDE.md wie Code behandeln: kurz, beschnitten und signalstark
Dies ist die Seite, auf der die Primitive aufhören, einzelne Features zu sein, und anfangen, ein Workflow zu werden. Wenn du bereits weißt, was ein Subagent oder ein Hook ist, liegt der Hebel darin, wie du sie stapelst: ein Slash-Command, der einen Durchlauf im Plan-Modus anstößt, Subagents, die die Arbeit aufteilen, ein Hook, der den Turn nicht enden lässt, bis die Tests bestehen, und ein Headless-Aufruf, der das Ganze in der CI ausführt. Verdrahten wir es miteinander.
Das mentale Modell: Wer hält den Plan?
Jeder Power-Move weiter unten ist eine andere Antwort auf eine Frage — wer hält den Plan und die Zwischenergebnisse? Anthropics eigene Einordnung des neuen Features für dynamische Workflows legt es sauber dar:
| Werkzeug | Wer entscheidet, was als Nächstes läuft | Wo Ergebnisse liegen | Skalierung |
|---|---|---|---|
| Subagents | Claude, Turn für Turn | Claudes Kontextfenster | Einige pro Turn |
| Skills | Claude, dem Prompt folgend | Claudes Kontextfenster | Genauso wie Subagents |
| Agent-Teams | Ein Lead-Agent, Turn für Turn | Eine gemeinsame Aufgabenliste | Eine Handvoll langlebiger Peers |
| Dynamische Workflows | Das Skript | Skriptvariablen | Dutzende bis Hunderte |
Die Progression ist das ganze Spiel: Beginne mit einem Claude, delegiere an Subagents, um den Kontext zu schützen, und verlagere den Plan erst dann in Code, wenn eine Aufgabe mehr Agents braucht, als eine Konversation koordinieren kann.
Move 1 — Parallele Subagents, dann zum Workflow wechseln
Ein Subagent ist ein separater Claude mit eigenem Kontextfenster und einem abgegrenzten Toolset; er gibt ein Ergebnis zurück, nicht sein Transkript. Die Power-User-Gewohnheit ist es, unabhängige Arbeit aufzufächern:
Ein Review über Module auffächern
Review the changes in auth/, billing/, and api/ — use the code-reviewer subagent on each, in parallel. Report only correctness bugs and missing tests.
Drei Reviewer laufen gleichzeitig, jeder verbrennt seinen eigenen Kontext an den Diffs, und deine Hauptsession sieht drei saubere Berichte statt dreier roher Diffs. Der Haken: Parallelität hilft nur bei unabhängigen Teilaufgaben. Wenn Schritt B die Ausgabe von Schritt A braucht, führe sie nacheinander aus; wenn sie dieselben Dateien schreiben, isoliere sie in git worktrees.
Wenn die Aufgabe über eine einzige Konversation hinauswächst — eine Migration über 500 Dateien, ein codebase-weiter Bug-Sweep, eine über viele Quellen quergeprüfte Recherche — wechsle zu einem dynamischen Workflow. Claude schreibt ein JavaScript-Orchestrierungsskript (auffächern → reduzieren → synthetisieren), eine Laufzeitumgebung führt es im Hintergrund mit bis zu 16 gleichzeitigen Agents aus, und nur die finale Antwort landet in deinem Kontext. Stoße einen mit dem Schlüsselwort ultracode an oder frage einfach in einfachen Worten:
Einen dynamischen Workflow anstoßen
ultracode: audit every API endpoint under src/routes/ for missing auth checks, then cross-check each finding with a second agent before reporting
Das Killer-Feature ist nicht nur mehr Agents — es ist, dass ein Skript ein wiederholbares Qualitätsmuster anwenden kann, etwa unabhängige Agents, die die Befunde der jeweils anderen adversariell überprüfen, bevor irgendetwas berichtet wird. Probiere das gebündelte /deep-research <question>, um das Muster live zu sehen: Es stimmt über jede Behauptung ab und filtert diejenigen heraus, die die Querprüfung nicht überstehen.
- Speichere einen guten Workflow-Lauf als Command: öffne /workflows, wähle den Lauf aus, drücke s. Er wird in jeder zukünftigen Session zu /dein-name.
- Schätze die Kosten zuerst an einem Ausschnitt ab — ein Verzeichnis, nicht das ganze Repo. Ein Lauf kann weit mehr Agents (und Tokens) erzeugen als eine einzelne Konversation.
Move 2 — Hooks: das deterministische Bindeglied
CLAUDE.md-Anweisungen sind beratend — Claude folgt ihnen meistens. Hooks sind deterministisch — sie führen an einem festen Punkt der Schleife ein Skript aus, garantiert, jedes Mal. Greife zu einem Hook, wenn etwas mit null Ausnahmen passieren muss.
Die drei hebelstärksten Hook-Muster:
- Nachdem Claude eine Datei bearbeitet hat, lasse deinen Formatter oder Linter automatisch laufen, damit die Codebase niemals abdriftet. Das Feedback fließt auch zu Claude zurück, sodass er sich selbst korrigiert.
- Ein Stop-Hook führt dein Test-/Build-Skript aus und blockiert das Ende des Turns, bis es besteht. Genau das lässt einen unbeaufsichtigten Lauf korrekt abschließen, statt zu stoppen, wenn die Arbeit bloß 'fertig aussieht'.
- Verweigere Schreibvorgänge in einen geschützten Pfad (Migrationen, generierte Dateien, Secrets), bevor sie passieren, unabhängig davon, was Claude vorhat.
Du musst das JSON nicht von Hand schreiben. Bitte Claude, den Hook für dich zu verfassen:
Claude einen Hook schreiben lassen
Write a hook that runs eslint --fix after every file edit, and a second hook that blocks any Write or Edit to the db/migrations/ folder. Add them to .claude/settings.json and show me the config.
- Ein Stop-Hook, der weiter blockiert, wird nach mehreren aufeinanderfolgenden Blockaden außer Kraft gesetzt, damit die Session sich nicht selbst blockieren kann — deine Absicherung ist ein Sicherheitsgeländer, keine Endlosschleife.
- Hooks laufen mit den Berechtigungen deiner Shell. Überprüfe jedes Hook-Skript, bevor du es committest, genau wie du es bei CI-Konfiguration tun würdest.
Move 3 — Eigene Slash-Commands, Skills & Output-Styles
Alles, was du zweimal promptest, sollte ein Primitiv werden. Die Entscheidung ist einfach: Skills sind Wissen, Hooks sind Garantien, MCP ist Aktion, Slash-Commands sind Einstiegspunkte.
Ein Slash-Command (oder ein Skill mit disable-model-invocation: true) verpackt einen wiederholbaren Workflow, den du von Hand auslöst. $ARGUMENTS macht ihn parametrisierbar:
.claude/skills/fix-issue/SKILL.md
--- name: fix-issue description: Triage and fix a GitHub issue end-to-end disable-model-invocation: true --- Fix GitHub issue $ARGUMENTS: 1. gh issue view to read the issue 2. Search the codebase for the relevant files 3. Write a failing test that reproduces the bug 4. Implement the fix, then run tests and lint until green 5. Commit with a descriptive message and open a PR
Führe ihn mit /fix-issue 1234 aus. Verwende disable-model-invocation: true für alles mit Nebenwirkungen, das du bewusst auslösen möchtest, statt dass Claude von sich aus danach greift.
Output-Styles ändern, wie Claude über die gesamte Session hinweg kommuniziert — knapp für eine Expertin, ausführlich-mit-Erklärungen zum Lehren oder ein strukturiertes Format, das dein Tooling parsen kann. Kombiniere einen eigenen Slash-Command (das Was) mit einem Output-Style (das Wie), und du hast beide Enden der Interaktion geformt.
Der am meisten unterschätzte Power-Move aus der offiziellen Dokumentation: Lass dich von Claude interviewen, bevor du ein großes Feature angehst, und starte dann eine frische Session, um aus der schriftlichen Spec heraus zu bauen.
Spec-per-Interview, dann in sauberem Kontext bauen
I want to build [brief description]. Interview me in detail using the AskUserQuestion tool — technical implementation, UI/UX, edge cases, tradeoffs. Dig into the hard parts I might not have considered. When we've covered everything, write a complete, self-contained spec to SPEC.md.
Move 4 — Einen MCP-Stack bauen
MCP-Server sind ausführbare Prozesse, die Claude über JSON-RPC aufruft, um tatsächlich Dinge zu tun — deine Datenbank abfragen, Sentry lesen, ein Figma-Design ziehen, ein Linear-Issue anlegen. Ein Power-User-"Stack" ist ein kleines, bewusst gewähltes Set, nicht alles, was du finden kannst:
Server zu deinem Stack hinzufügen
claude mcp add --transport stdio sentry -- npx -y @sentry/mcp-server claude mcp add --transport http linear https://mcp.linear.app/sse
Zwei Prinzipien halten einen MCP-Stack schnell:
- Bevorzuge ein CLI, wenn es eines gibt.
gh,aws,gcloudundsentry-clisind die kontexteffizienteste Art, mit einem Dienst zu sprechen — Claude kennt sie bereits, und sie laden kein Tool-Schema in jeden Turn. Reserviere MCP für Dienste ohne gutes CLI oder dort, wo du strukturierten, typisierten Zugriff willst. - Halte die Serverliste schlank. Die Tool-Definitionen jedes verbundenen Servers verbrauchen vorab Kontext. Streiche Server, die du nicht aktiv nutzt; aufgeblähte Tool-Listen verdrängen deine eigentlichen Anweisungen.
Für das tiefere Warum siehe Context Engineering — dieselbe Attention-Budget-Logik, die CLAUDE.md regiert, regiert deine Tool-Liste.
Move 5 — Headless- & Agent-SDK-Pipelines
claude -p "prompt" führt Claude nicht-interaktiv aus — keine Session, parsebare Ausgabe — was die Tür zu CI, Pre-Commit-Hooks und Batch-Jobs ist. Das ist die Headless- / Agent-SDK-Oberfläche.
Das klassische Fan-out-über-Dateien-Muster aus dem offiziellen Best-Practices-Leitfaden:
Headless-Batch-Migration
# 1. Have Claude generate the work list first, then loop: for file in $(cat files.txt); do claude -p "Migrate $file from React to Vue. Return OK or FAIL." \ --allowedTools "Edit,Bash(git commit *)" done
Zwei Flags machen die Hauptarbeit: --output-format json (oder stream-json --verbose) macht Ergebnisse maschinenlesbar, und --allowedTools grenzt genau ein, was Claude anfassen darf, wenn kein Mensch zusieht. Leite es überallhin weiter:
Claude als Pipeline-Stufe
cat error.log | claude -p "Cluster these errors by root cause, output JSON" \ --output-format json | jq '.[] | select(.severity=="high")'
- Teste den Prompt immer an 2–3 Elementen, bevor du die Schleife auf 2.000 loslässt. Verfeinern, dann skalieren.
- Unbeaufsichtigte Läufe brauchen eingebaute Verifikation — einen Stop-Hook oder einen Test-Schritt im Prompt — sonst hast du gerade das Erzeugen plausibler-aber-falscher Ausgaben in großem Maßstab automatisiert.
Move 6 — Plan-Modus-Disziplin & Context Engineering
Der einzelne zuverlässigste Qualitätshebel ist das Trennen von Recherche und Ausführung. Die Vier-Phasen-Schleife aus Anthropics Best-Practices-Leitfaden:
- Geh in den Plan-Modus. Claude liest Dateien und beantwortet Fragen, nimmt aber keine Änderungen vor. Richte ihn auf die genauen Verzeichnisse: 'read /src/auth and explain how sessions work.'
- Bitte um einen detaillierten Implementierungsplan. Bearbeite ihn direkt, bevor du ihn freigibst — ein Plan, den du korrigiert hast, schlägt einen Plan, den du überflogen hast.
- Verlasse den Plan-Modus. Claude codet gegen den Plan und führt die von dir festgelegte Verifikation aus.
- Lass einen Subagent mit frischem Kontext den Diff gegen den Plan reviewen, Lücken schließen, dann committe und öffne einen PR.
Siehe Plan-Modus für die Disziplin und überspringe ihn, wenn der Diff in einen Satz passt — Planen hat Overhead. Der Grund, warum das funktioniert, ist Kontextökonomie: Die Leistung verschlechtert sich, je voller das Fenster wird, sodass eine 50-Token-Anweisung in einem 2.000-Token-Kontext weit härter einschlägt als dieselbe Anweisung vergraben in 50.000 Tokens. Praktische Gewohnheiten:
/clearzwischen unzusammenhängenden Aufgaben; eine saubere Session mit einem besseren Prompt schlägt eine lange, verunreinigte.- Nach zwei gescheiterten Korrekturen hör auf zu korrigieren —
/clearund schreibe den Prompt mit dem, was du gelernt hast, neu. - Delegiere Recherche an Subagents, damit das Lesen von Dateien in ihrem Kontext geschieht, nicht in deinem.
Der "Level-up dein Setup"-Pfad
Wenn du sonst nichts tust, tu diese Dinge in dieser Reihenfolge:
- Führe /init für einen Startpunkt aus, dann streiche jede Zeile, die den Test nicht besteht: 'Würde das Entfernen dazu führen, dass Claude einen Fehler macht?' Eine aufgeblähte Datei führt dazu, dass Claude die Regeln ignoriert, auf die es ankommt.
- Füge einen PostToolUse-Lint/Format-Hook und einen Stop-Hook hinzu, der auf Tests absichert. Jetzt schließt sich die Schleife selbst, statt auf dich zu warten.
- Wähle einen Workflow, den du zweimal getippt hast — fix-issue, write-tests, ship-pr — und lege ihn in .claude/skills/ oder .claude/commands/.
- Füge nur die Server hinzu, die du wöchentlich nutzt; bevorzuge gh-/aws-CLIs gegenüber MCP, wo es sie gibt. Streiche den Rest.
- Nutze den Plan-Modus für jede Mehrdatei- oder unbekannte Änderung und schließe mit einem Review-Subagent mit frischem Kontext ab.
- Führe claude -p in einem Pre-Commit-Hook oder einem kleinen Batch-Job mit --allowedTools aus, damit du Claude als Pipeline-Stufe erlebst, nicht nur als Chat.
CLAUDE.md-Meisterschaft
CLAUDE.md wird zu Beginn jeder Konversation geladen, ist also der häufigste Kontext, den du kontrollierst — und daher am leichtesten durch Überfüllung zu ruinieren.
| In CLAUDE.md aufnehmen | Heraushalten |
|---|---|
| Bash-Befehle, die Claude nicht erraten kann | Alles, was Claude durch Lesen des Codes findet |
| Code-Stil-Regeln, die von den Defaults abweichen | Standardkonventionen, die Claude bereits kennt |
| Test-Runner + wie man einen einzelnen Test ausführt | Vollständige API-Docs (stattdessen verlinken) |
| Repo-Etikette (Branch-/PR-Benennung) | Infos, die sich häufig ändern |
| Nicht offensichtliche Stolperfallen und Umgebungs-Eigenheiten | "Schreibe sauberen Code"-Plattitüden |
Behandle es wie Code: überprüfe es, wenn das Verhalten schiefgeht, beschneide es regelmäßig und nutze @path/to/file-Importe plus CLAUDE.md-Dateien pro Verzeichnis, damit jeder Teil eines Monorepos nur das bekommt, was relevant ist. Verlagere manchmal-relevantes Wissen in Skills, damit es bei Bedarf geladen wird, statt jeden Turn zu belasten.
Prüfe dich selbst
0/4- Die Progression ist die Kompetenz: ein Claude → parallele Subagents → skriptgesteuerte dynamische Workflows, gewählt danach, wer den Plan halten muss.
- Hooks sind das deterministische Bindeglied — Lint beim Speichern, Stop absichern, verbotene Schreibvorgänge blockieren — für das, was jedes Mal passieren muss.
- Verpacke wiederholte Prompts in Slash-Commands/Skills, forme die Ausgabe mit einem Output-Style und halte einen MCP-Stack schlank (bevorzuge CLIs).
- Headless claude -p mit --allowedTools macht Claude zu einer CI-/Pipeline-Stufe; baue für unbeaufsichtigte Läufe immer Verifikation ein.
- Plan-Modus-Disziplin plus aggressive Kontextökonomie (/clear, Subagent-Recherche, eine beschnittene CLAUDE.md) ist der zuverlässigste Hebel, den du hast.
Quellen & weiterführende Literatur
- Best practices for Claude Code — Anthropics offizieller Leitfaden: die explore→plan→execute-Schleife, CLAUDE.md-Regeln, Hooks, Subagents, Headless-Fan-out und Verifikation.
- Orchestrate subagents at scale with dynamic workflows — offizielle Dokumentation zu dynamischen Workflows, dem Schlüsselwort
ultracode,/deep-researchund der Wer-hält-den-Plan-Vergleichstabelle. - Effective context engineering for AI agents — Anthropic Engineering über Kontext als endliches Budget und Just-in-time-Abruf.
- hesreallyhim/awesome-claude-code — große, community-kuratierte Liste von Skills, Hooks, Slash-Commands, Agent-Orchestratoren und Plugins.
- qdhenry/Claude-Command-Suite — eine bekannte Bibliothek professioneller Slash-Commands und Agents (z. B.
/dev:code-review). - GWUDCAP/cc-sessions — ein meinungsstarkes Erweiterungs-Set, das Hooks zur Workflow-Durchsetzung plus Aufgaben-/Git-Management demonstriert.
- VoltAgent/awesome-claude-code-subagents — eine große Community-Sammlung spezialisierter Subagent-Definitionen.