long-task-coordinator

Überblick über die long-task-coordinator Skill

Was long-task-coordinator macht

long-task-coordinator ist eine Koordinations-Skill für Arbeit, die Unterbrechungen, Übergaben und längere Pausen zwischen einzelnen Turns überstehen muss. Die Kernaufgabe ist einfach: lang laufende Arbeit wird aus dem fragilen Chat-Gedächtnis in eine belastbare Zustandsdatei verlagert – mit expliziten Statusübergängen, Wiederherstellungsprüfungen und sauberer Verfolgung der nächsten Schritte.

Für wen sich die Installation lohnt

Diese Skill passt am besten für Nutzer, die Agent Orchestration, delegierte Recherche, Migrationen, Batch-Jobs oder andere Aufgaben mit Pausen, Wiederaufnahme und Abhängigkeiten von anderen Workern steuern. Wenn Ihr Workflow Dinge wie „morgen wieder aufnehmen“ oder „delegieren und später prüfen“ enthält, ist die long-task-coordinator Skill sehr wahrscheinlich die richtige Wahl.

Der eigentliche Nutzwert

Niemand installiert long-task-coordinator, um einfach nur „besser zu planen“. Installiert wird die Skill, um lange Arbeit belastbar und ehrlich steuerbar zu machen:

• Zustand nach Kontextverlust wiederherstellen
• Verantwortlichkeiten zwischen Koordinator und Workern nachverfolgen
• Wartezustände explizit abbilden
• falsche Abschlussmeldungen vermeiden
• aus einer gespeicherten Source of Truth fortsetzen statt aus dem bisherigen Chat zu raten

Was sie von einem normalen Planungs-Prompt unterscheidet

Der Unterschied liegt nicht in Domänenwissen, sondern in Workflow-Disziplin:

• eine einzige dauerhafte Zustandsdatei
• ein fester Ablauf: READ -> RECOVER -> DECIDE -> PERSIST -> REPORT -> END
• explizite Statuswerte wie running, awaiting-result, paused, blocked und complete
• die klare Priorität, vor dem Berichten erst zu persistieren, damit die nächste Session zuverlässig wieder anknüpfen kann

Gute Einsatzfälle und typische Fehlanwendungen

Setzen Sie long-task-coordinator ein, wenn eine Aufgabe mehrere Sessions umfasst, Subagents oder Hintergrundjobs einbindet oder Checkpoints und Retries braucht. Für kleine One-Turn-Aufgaben ist die Skill dagegen unnötig schwergewichtig. Das Repository verweist leichtere Planungsfälle ausdrücklich auf planning-with-files, statt überall den Overhead für lang laufende Koordination aufzuzwingen.

So verwenden Sie die long-task-coordinator Skill

long-task-coordinator Installationsoptionen

Das README des Repositorys zeigt die manuelle Installation per Symlink in Ihr Skill-Verzeichnis des Clients, zum Beispiel:

ln -s /path/to/agent-playbook/skills/long-task-coordinator ~/.claude/skills/long-task-coordinator
ln -s /path/to/agent-playbook/skills/long-task-coordinator ~/.codex/skills/long-task-coordinator
ln -s /path/to/agent-playbook/skills/long-task-coordinator ~/.gemini/skills/long-task-coordinator

Wenn Sie einen Skill-Manager nutzen, achten Sie darauf, dass der finale Installationspfad weiterhin den tatsächlichen Inhalt von skills/long-task-coordinator bereitstellt und nicht nur das Repo-Root.

Diese Dateien sollten Sie zuerst lesen

Für eine schnelle, aber belastbare Einarbeitung lesen Sie in dieser Reihenfolge:

1. skills/long-task-coordinator/SKILL.md
2. skills/long-task-coordinator/references/workflow.md
3. skills/long-task-coordinator/evals/prompts.md
4. skills/long-task-coordinator/README.md

Warum diese Reihenfolge sinnvoll ist:

• SKILL.md definiert Auslöser und Kernregeln
• references/workflow.md zeigt das tatsächlich nutzbare Muster für die Zustandsdatei
• evals/prompts.md macht sichtbar, wie „korrektes Verhalten“ konkret aussieht
• README.md bestätigt Installation und den zentralen Ablauf

Welche Eingaben die Skill braucht

Die long-task-coordinator Skill funktioniert am besten, wenn Sie Folgendes mitgeben:

• das Ziel der Aufgabe
• konkrete Erfolgskriterien
• ob die Arbeit bereits läuft
• wo die dauerhafte Zustandsdatei liegen soll
• aktive Zuweisungen an Worker oder Subagents
• den nächsten Checkpoint-Auslöser, etwa einen Zeitpunkt oder eine Bedingung
• bekannte Blocker oder Abhängigkeiten

Ohne diese Angaben kann das Modell zwar trotzdem starten, muss aber mehr Annahmen treffen und liefert ein schwächeres Koordinationsprotokoll.

Aus einer groben Anfrage eine gute Invocation machen

Schwache Anfrage:

Help me keep track of this migration.

Bessere Anfrage:

Use long-task-coordinator for this migration. Create or recover a durable state file at docs/migration-state.md. Goal: migrate service auth to OAuth2. Success criteria: tests pass, rollout notes written, old auth path disabled. We may hand work to subagents and resume across sessions. If any work is in flight, use an explicit waiting state instead of implying failure.

Die stärkere Variante verbessert die Ausgabe, weil Persistenz, Umfang, Abschlusslogik und Koordinationsstil von Anfang an klar definiert sind.

Früh eine dauerhafte Zustandsdatei anlegen

Die wichtigste operative Gewohnheit ist, die Zustandsdatei anzulegen, bevor die Arbeit unübersichtlich wird. Die Referenz empfiehlt Pfade wie:

• docs/<topic>-execution-plan.md
• docs/<topic>-state.md
• worklog/<topic>-state.md

Mindestens sollten Sie Folgendes persistieren:

• Goal
• Success criteria
• Status
• Current step
• Completed work
• Next action
• Next checkpoint
• Blockers
• Owners

Das ist der zentrale Adoptionspunkt: Wenn Sie die Zustandsdatei weglassen, verlieren Sie den größten Teil des Nutzens der long-task-coordinator Skill.

Die Recovery-Schleife in jeder Runde nutzen

Der Kernablauf des Repositorys ist das praktische Herzstück der Nutzung von long-task-coordinator:

READ -> RECOVER -> DECIDE -> PERSIST -> REPORT -> END

In der Praxis heißt das:

1. zuerst den gespeicherten Zustand lesen
2. prüfen, ob der Status noch stimmt
3. kontrollieren, ob delegierte Arbeit zurückgekommen ist
4. entscheiden, ob fortgesetzt, gewartet, wiederholt, pausiert oder abgeschlossen wird
5. den aktualisierten Zustand schreiben
6. erst danach an den Nutzer berichten

Genau diese Reihenfolge sorgt dafür, dass die nächste Session zuverlässig wiederherstellbar bleibt.

Explizite Status verwenden, besonders awaiting-result

Ein feiner, aber sehr wertvoller Aspekt dieser Skill ist der Status awaiting-result. Viele Agents simulieren Fortschritt, indem sie so tun, als sei eine delegierte Aufgabe fehlgeschlagen oder abgeschlossen, obwohl sie schlicht noch läuft. Diese Skill bietet dafür ein saubereres Modell:

• running für aktive Arbeit des Koordinators
• awaiting-result, wenn ein Worker oder Job noch läuft
• paused, wenn bewusst gestoppt wurde
• blocked, wenn externe Einschränkungen Fortschritt verhindern
• complete nur dann, wenn die Erfolgskriterien tatsächlich erfüllt sind

Gerade für Agent Orchestration ist das eine der nützlichsten Unterscheidungen der gesamten Skill.

Empfohlener Workflow für delegierte Arbeit

Ein gutes Arbeitsmuster ist:

1. Aufgabe und Erfolgskriterien definieren
2. die Zustandsdatei anlegen
3. klar begrenzte Arbeit an einen Worker delegieren
4. Verantwortlichen und erwartete Rückkehrbedingung festhalten
5. den Status auf awaiting-result setzen, wenn gewartet wird
6. per Recovery fortsetzen, nicht aus dem Gedächtnis
7. erledigte Punkte und nächste Aktion aktualisieren
8. erst dann complete setzen, wenn die Kriterien geprüft wurden

Dieses Muster ist sicherer als offene „mach einfach weiter“-Prompts, weil Übergaben nachvollziehbar werden.

Praktische Prompt-Muster, die gut funktionieren

Gute Prompts für long-task-coordinator enthalten meist explizite Recovery-Sprache. Beispiele:

• “Use long-task-coordinator and recover from any existing state before proposing next steps.”
• “Persist the updated status before reporting.”
• “If a worker is still in flight, mark awaiting-result and define the next checkpoint.”
• “Do not mark complete unless the saved state and success criteria agree.”

Diese Muster orientieren sich direkt an den Eval-Prompts des Repositorys und reduzieren vorgetäuschte Sicherheit.

Häufige Fehler bei der Einführung

Die meisten fehlgeschlagenen Einsätze scheitern an Prozesslücken, nicht an fehlenden Features:

• auf Chat-Historie statt auf eine Datei vertrauen
• vage Statusformulierungen statt der definierten Zustände verwenden
• Fortschritt melden, bevor der gespeicherte Zustand aktualisiert wurde
• bei delegierter Arbeit keine Verantwortlichen festhalten
• complete setzen, ohne die Akzeptanzkriterien zu prüfen
• die Skill für kurze Aufgaben nutzen, bei denen der Koordinations-Overhead unnötig ist

long-task-coordinator Skill FAQ

Lohnt sich long-task-coordinator für einfache Aufgaben?

Meistens nicht. Wenn die Aufgabe kurz ist, in einer einzigen Session erledigt wird und keine Wiederherstellung braucht, erzeugt long-task-coordinator nur zusätzlichen Aufwand. Das Repo positioniert die Skill ausdrücklich für Arbeit, die länger als ein Turn lebt oder auf dauerhaften Zustand angewiesen ist.

Worin unterscheidet sie sich von planning-with-files?

planning-with-files ist die leichtere Option, wenn Sie vor allem strukturierte Planung brauchen. long-task-coordinator ist für Wiederaufnehmbarkeit, explizite Wartezustände und Recovery nach Unterbrechungen gedacht. Wählen Sie diese Skill, wenn Zustandsintegrität wichtiger ist als bloße Schrittorganisation.

Ist long-task-coordinator gut für Agent Orchestration?

Ja. Das ist einer der klarsten Einsatzfälle überhaupt. Die Skill wurde für Setups mit Koordinator und Workern, delegierte Ausführung, Hintergrundjobs und Übergaben über mehrere Sessions hinweg entwickelt. Besonders hilfreich für Agent Orchestration sind die Owner-Verfolgung und der Status awaiting-result.

Braucht die Skill eine bestimmte Runtime oder ein bestimmtes Framework?

Nein. Das README beschreibt sie bewusst als abstrakt und portabel. Sie setzt weder eine bestimmte Domäne noch eine bestimmte Runtime voraus. Die wichtigste Voraussetzung ist nur, dass Ihr Agent im Workspace eine dauerhafte Datei lesen und schreiben kann.

Können Einsteiger diese long-task-coordinator Skill nutzen?

Ja, sofern sie die zu koordinierende Aufgabe bereits verstehen. Die Skill selbst ist konzeptionell einfach, aber Einsteiger setzen sie leicht zu breit ein. Wenn Sie nicht mit Unterbrechungen, Delegation oder Wiederaufnehmbarkeit arbeiten, starten Sie besser mit einer einfacheren Planungs-Skill.

Wann sollte ich long-task-coordinator nicht verwenden?

Vermeiden Sie die Skill, wenn:

• die Aufgabe in einem Durchgang abgeschlossen wird
• späteres Wiederaufnehmen nicht nötig ist
• kein delegierter Worker oder Hintergrundprozess beteiligt ist
• Sie den zusätzlichen Schritt einer gepflegten Zustandsdatei nicht wollen

In solchen Fällen sind normale Prompts oft schneller.

So verbessern Sie die long-task-coordinator Skill

Mit stärkeren Erfolgskriterien beginnen

Der größte Hebel für Qualität ist eine präzisere Abschlusslogik. Statt „finish the migration“ sollten Sie Kriterien formulieren wie:

• auth tests pass
• production config updated
• rollback note added
• legacy path disabled

Bessere Kriterien machen es für das Modell deutlich schwerer, die Aufgabe zu früh zu schließen.

Die Zustandsdatei konkret und leicht auffindbar machen

Verstecken Sie den Zustand nicht in irgendeiner beliebigen Scratch-Datei. Legen Sie ihn an einen vorhersehbaren Pfad wie docs/oauth-migration-state.md. Gute Recovery hängt davon ab, dass die nächste Session die Datei ohne Raten tatsächlich findet.

Verantwortlichkeiten explizit festhalten

Für eine bessere Nutzung von long-task-coordinator sollten Sie immer festhalten, wem was gehört:

• Origin: definiert die Aufgabe
• Coordinator: pflegt Zustand und Reihenfolge
• Worker: führt klar begrenzte Arbeit aus

Diese kleine Gewohnheit reduziert Doppelarbeit, Stillstand und Verwirrung, wenn mehrere Agents beteiligt sind.

Prompts mit klaren Checkpoint-Bedingungen verbessern

Ein schwacher Checkpoint sagt: „später noch mal prüfen“. Ein starker Checkpoint sagt: „resume when the worker returns test results or at 15:00 UTC, whichever comes first.“ Je expliziter der Auslöser, desto geringer ist das Risiko, dass der Koordinator driftet.

Falsche Fortschrittsmeldungen verhindern

Ein häufiger Fehler sind glatt klingende, aber unzuverlässige Statusberichte. Abhilfe schaffen klare Anweisungen an die Skill:

• gespeicherten Zustand zuerst lesen
• prüfen, ob er noch korrekt ist
• Updates persistieren, bevor zusammengefasst wird
• zwischen waiting und blocked unterscheiden
• complete gegen die Erfolgskriterien begründen

So bleiben long-task-coordinator-Ausgaben auch über mehrere Sessions hinweg vertrauenswürdig.

Die Eval-Prompts als Akzeptanztests nutzen

evals/prompts.md ist nicht nur für einfache Smoke Tests nützlich. Behandeln Sie diese Prompts als lokale Checkliste für Ihre eigenen Anpassungen:

• kann die Skill unterbrochene Arbeit sicher wieder aufnehmen?
• bildet sie Wartezustände ehrlich ab?
• belegt sie Abschluss mit gespeichertem Zustand?

Wenn Ihre angepasste Nutzung diese Tests nicht besteht, ist Ihr Orchestrierungs-Muster noch zu locker.

Nach dem ersten Durchlauf nachschärfen

Prüfen Sie nach der ersten Koordinationsrunde die Zustandsdatei und schärfen Sie alles nach, was noch zu vage ist:

• unklare Status ersetzen
• fehlende Verantwortliche ergänzen
• Blocker präzisieren
• zu große nächste Aktionen aufteilen
• eine echte Checkpoint-Bedingung ergänzen

Die long-task-coordinator Skill wird schnell besser, sobald der persistierte Zustand konkreter wird – denn jede spätere Recovery hängt von dieser Datei ab, nicht vom Gedächtnis.