Zum Hauptinhalt springen

Pro-Workflows & Power-Moves

Experte
What you'll learn
  • 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:

WerkzeugWer entscheidet, was als Nächstes läuftWo Ergebnisse liegenSkalierung
SubagentsClaude, Turn für TurnClaudes KontextfensterEinige pro Turn
SkillsClaude, dem Prompt folgendClaudes KontextfensterGenauso wie Subagents
Agent-TeamsEin Lead-Agent, Turn für TurnEine gemeinsame AufgabenlisteEine Handvoll langlebiger Peers
Dynamische WorkflowsDas SkriptSkriptvariablenDutzende 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.

Pro tip
  • 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:

Guided walkthrough1 of 3
  1. 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.

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.
Watch out
  • 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, gcloud und sentry-cli sind 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")'
Watch out
  • 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:

Guided walkthrough1 of 4
  1. 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.'

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:

  • /clear zwischen unzusammenhängenden Aufgaben; eine saubere Session mit einem besseren Prompt schlägt eine lange, verunreinigte.
  • Nach zwei gescheiterten Korrekturen hör auf zu korrigieren — /clear und 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:

Guided walkthrough1 of 6
  1. 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.

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 aufnehmenHeraushalten
Bash-Befehle, die Claude nicht erraten kannAlles, was Claude durch Lesen des Codes findet
Code-Stil-Regeln, die von den Defaults abweichenStandardkonventionen, die Claude bereits kennt
Test-Runner + wie man einen einzelnen Test ausführtVollstä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
  1. Du brauchst eine Migration über 500 Dateien, koordiniert mit adversarieller Querprüfung. Welches Werkzeug passt am besten?
  2. Was ist der entscheidende Unterschied zwischen einem Hook und einer CLAUDE.md-Anweisung?
  3. Welches Flag grenzt ein, was Claude während eines unbeaufsichtigten `claude -p`-Batch-Laufs tun darf?
  4. Warum verbessert das Beschneiden von CLAUDE.md die Einhaltung?
Power-Move-Abruf — drehe jede Karte um
Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.
1 / 5
Key takeaways
  • 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