Handoff Skill: Der Claude Code Workflow, Der Mein Kontextproblem Löste

Handoff Skill: Der Claude Code Workflow, Der Mein Kontext-Problem Löste

Die Sitzung war bei 142.000 Tokens, als ich bemerkte, dass Claude begonnen hatte, sich zu wiederholen.

Ich steckte tief in einem Planungsgespräch über eine neue Aria Content-Pipeline — drei Marken, vier Beitragstypen, ein gemeinsames Forschungsprotokoll, das volle Programm. Auf halbem Weg bat ich es, ein kleines Refactoring eines unverwandten Cron-Skills auszuarbeiten, der nichts mit der Pipeline zu tun hatte. Fünfundvierzig Minuten später widersprach Claude höflich Entscheidungen, die wir zweihundert Nachrichten zuvor festgelegt hatten, vermischte die Cron-Logik mit der Content-Spezifikation und zitierte meine eigenen ADRs leicht falsch zurück. Das 1M Kontextfenster war technisch noch offen. Praktisch arbeitete das Modell im Nebel.

Diese Sitzung ist der Grund, warum ich den Handoff-Skill aufgegriffen habe. Und sobald ich anfing, handoff statt /compact für diese Momente zu verwenden, war der Unterschied nicht subtil — es war der Unterschied zwischen einem fokussierten Ingenieur, der eine Aufgabe sauber abschließt, und einem müden, der immer wieder denselben Slack-Thread öffnet.

Dies ist der Beitrag, den ich mir wünschte, jemand hätte ihn mir vor sechs Wochen gegeben. Wir werden den Handoff-Skill auseinandernehmen: wie er funktioniert, warum er Komprimierung bei Multi-Thread-Arbeit übertrifft, was die Markdown-Datei tatsächlich enthält, wann man ihn verwenden sollte, und wie ich ihn in meinen eigenen Aria + Claude Code Workflow auf dieser Seite integriert habe. Am Ende werden Sie genau wissen, wo in Ihren aktuellen Sitzungen Sie einen Handoff schreiben sollten und wo nicht.

Das Kontextfenster ist größer, und das hat das Problem verschlimmert

Lassen Sie mich die Szene richtig setzen, denn die Rahmung ist wichtig.

Claude Code wird jetzt mit einem 1M Token Kontextfenster ausgeliefert. Das klingt nach einem gelösten Problem — alles hineinwerfen, das Modell wird es schon herausfinden. Es ist kein gelöstes Problem. Anthropics eigene Dokumentation bestätigt es: Genauigkeit und Erinnerung verschlechtern sich, wenn der Kontext voll wird. Unabhängige Tests von Teams, die Claude Code in Produktion betreiben, setzen den praktischen Degradationspunkt viel früher als die Obergrenze an — die Qualität beginnt bei etwa 120.000 Tokens zu sinken, weit bevor das Fenster technisch voll ist. Einige Teams berichten über messbaren Qualitätsverlust bereits bei 50% der Kapazität.

Ich betrachte jedes Kontextfenster als zwei übereinander gestapelte Schichten:

• Die smarte Zone — die frühen Tokens, der System-Prompt, die neuesten Austausche. Die Aufmerksamkeit ist hier scharf. Das Modell weiß, was Sie gefragt haben, was es geantwortet hat und was gerade auf dem Tisch liegt.
• Die dumme Zone — die späteren Tokens, die veraltete Mitte, die Teile, bei denen der Aufmerksamkeitsmechanismus kämpfen muss, um sie richtig zu gewichten. Sie sind noch "im Kontext." Sie bekommen nur nicht den Fokus, den Sie denken.

Sobald eine Sitzung in die dumme Zone eintritt, bemerken Sie es nicht immer. Die Antworten klingen weiterhin selbstbewusst. Sie zitieren möglicherweise noch frühere Austausche. Aber die Präzision sinkt. Entscheidungen, die Sie getroffen haben, werden vergessen oder leise rückgängig gemacht. Tool-Auswahlen werden unscharf. Code beginnt wie eine Zusammenstellung aus drei verschiedenen Designentscheidungen auszusehen, auf die Sie sich fast geeinigt hatten.

Die ehrliche Version von "1M Kontext" ist eher: 1M Obergrenze, ~120K an zuverlässiger smarter Zone, dann eine lange Degradationskurve. Die Budgetierung der Aufmerksamkeit innerhalb des Fensters ist genauso wichtig wie die Obergrenze selbst — und ich würde argumentieren, sogar wichtiger. Ich habe ausführlich über diesen Kompromiss geschrieben in meiner Analyse von Claude Codes 1M Kontextverwaltung und in dem Stück über Kontexthygiene bei Token-Limits. Beide gelten noch.

Was Handoff in einem Satz macht: Es gibt Ihnen einen sauberen Weg, Arbeit über mehrere Sitzungen aufzuteilen, sodass jede in ihrer eigenen smarten Zone bleibt, anstatt so zu tun, als gäbe es die dumme Zone nicht.

Was der Handoff-Skill tatsächlich macht

Hier ist die Workflow-Verschiebung, die bei mir klickte.

Wenn der Handoff-Skill aufgerufen wird, komprimiert die aktuelle Claude Code-Sitzung alles Relevante — was wir versuchten zu tun, was wir entschieden, was wir ausprobierten, was noch offen ist, welche Dateien wir berührten, welche Skills die nächste Sitzung holen sollte — in eine einzelne Markdown-Datei. Diese Datei wird im temporären Verzeichnis des Betriebssystems gespeichert (damit sie den Arbeitsbereich nicht überfüllt), und dann öffnet eine frische Claude Code-Sitzung diese Datei und setzt die Arbeit fort, ohne den Ballast zu erben.

Einige Details, die ich erst nach ein paar Versuchen zu schätzen wusste:

Die Handoff-Datei ist zweckbestimmt, nicht generisch. Der Skill akzeptiert ein Argument, das den Fokus der nächsten Sitzung beschreibt. "API-Design fortsetzen" erzeugt ein ganz anderes Handoff als "einen UI-Prototyp für das Design bauen, das wir gerade skizziert haben" — selbst wenn beide von derselben Elternsitzung kommen. Die Komprimierung ist bewusst, keine dumme Zusammenfassung.

Es ist eine echte Markdown-Datei, kein versteckter JSON-Blob. Ich kann sie öffnen, lesen, bearbeiten, einen Absatz hinzufügen, einen Abschnitt entfernen, ein Token redigieren, bevor ich sie weitergebe. Das ist eine Eigenschaft, die ich unterschätzt habe, bis ich dasselbe mit der Zusammenfassung von /compact versuchte, die undurchsichtig und verlustbehaftet ist auf Weisen, die man nicht prüfen kann.

Es verweist statt zu duplizieren. Wenn wir ein GitHub-Issue oder ein ADR für die Arbeit geschrieben hatten, verweist die Handoff-Datei darauf, anstatt die Inhalte einzufügen. Klingt offensichtlich — außer dass /compact das Gegenteil tut. Es fasst alles neu zusammen, sodass die nächste Sitzung mit einer unscharfen Paraphrase des Issues endet, das Sie bereits präzise geschrieben hatten.

Es enthält einen Abschnitt "Vorgeschlagene Skills". Das ist der Teil, den ich mir wünsche, dass jedes Framework kopiert. Die aktuelle Sitzung weiß, welche Tools, Skills oder Sub-Agent-Muster die nächste Sitzung wahrscheinlich benötigt — TDD, Brainstorming, Worktrees, Verifikation — und schreibt diesen Hinweis in das Handoff. Die frische Sitzung kommt bereits auf den richtigen Werkzeugkasten ausgerichtet an.

Sensible Daten werden vor dem Speichern redigiert. API-Schlüssel, Geheimnisse, persönliche Informationen — der Skill entfernt sie, bevor die Datei auf der Festplatte landet. Ich scanne Handoffs trotzdem manuell, bevor ich sie weitergebe, aber das als eingebauten Standard zu haben, ist besser als zu hoffen, dass ich daran gedacht habe.

Wenn Sie Obras Superpowers-Framework verwendet haben (etwa 195k Sterne auf GitHub zum Zeitpunkt des Schreibens, schnell wachsend), wird sich dies nativ anfühlen — Handoff ist genau die Art von diszipliniertem, methodologiegetriebenem Skill, der das gesamte Ökosystem zum Funktionieren bringt. Ich habe das breitere Muster in meinem Superpowers Plugin Review behandelt. Der Handoff-Skill ist das Teil, das ich in den ersten Wochen zu wenig genutzt habe, bis mich die Multi-Sitzungs-Mathematik einholte.

Komprimierung vs Handoff: der Vergleich, der meine Arbeitsweise verändert hat

/compact und handoff sehen aus der Ferne ähnlich aus. Beide erzeugen eine komprimierte Ansicht davon, wo Sie waren. Sie lösen sehr unterschiedliche Probleme.

Hier ist der direkte Vergleich, wie ich sie jetzt verwende:

Lesen Sie diese Tabelle einmal quer. Komprimierung ist ein Gedächtnis-Tool — es versucht, einen einzelnen Thread passend zu machen. Handoff ist ein Workflow-Tool — es teilt Threads, damit jeder von Natur aus passt. Das erste ist ein Pflaster; das zweite ist strukturell.

Wenn Ihre Aufgabe ist "verfeinere diese API-Spezifikation noch drei Stunden lang, nur weniger wortreich" — komprimieren. Wenn Ihre Aufgabe ist "ich muss einen Prototyp ausprobieren, um eine Frage zu beantworten, die beim Spezifizieren der API aufkam" — Handoff. Sie zu verwechseln ist der Fehler, den ich wochenlang gemacht habe.

Es gibt eine noch einfachere Faustregel, die ich jetzt verwende. Fragen Sie: "Wird der nächste Teil dieses Gesprächs 80%+ des Kontexts teilen, der sich aktuell im Fenster befindet?" Wenn ja, komprimieren. Wenn nein, Handoff. Die meisten Male, als ich früher zu Compact griff, war die ehrliche Antwort nein.

Wann man zum Handoff greifen sollte

Drei Muster haben sich einen festen Platz in meinem Workflow verdient.

1. Die Versuchung des Mid-Session-Refactorings

Ich stecke tief im Bau von Feature A. Mir fällt etwas in einem gemeinsam genutzten Modul auf, das offensichtlich schlecht designt ist — eine Funktion, die drei Dinge tut, ein Config-Flag mit dem falschen Standardwert, ein Test, der seit sechs Commits stillschweigend übersprungen wird. Der alte Ich hätte es sofort gefixt. Die aktuelle Sitzung hätte zwanzig Nachrichten über das Refactoring geerbt, von denen die Hälfte noch im Fenster wäre, wenn ich zu Feature A zurückkehrte und mich erinnern müsste, was wir über dessen Randfälle entschieden hatten.

Der neue Ich schreibt ein Handoff. "Refactoring von RoutePlanner.normalize(), um Pfadvalidierung von Formatierung zu trennen. Tests unter tests/router/normalize.test.ts decken die Fälle bereits ab. Skills: Brainstorming, TDD." Die frische Sitzung nimmt es auf, liefert das Refactoring, kommt sauber zurück. Die Sitzung von Feature A bleibt die ganze Zeit in der smarten Zone.

Das ist der günstigste einzelne Workflow-Gewinn, den ich dieses Jahr aus irgendeiner AI-Tooling-Änderung gezogen habe. Die Kosten, eine tiefe Sitzung mit einem unverwandten Refactoring zu verschmutzen, sind viel höher als die Kosten, eine Handoff-Datei zu schreiben.

2. Grilling-Sitzungen, die sich verzweigen

Grilling-Sitzungen — interaktive, fragengesteuerte Erkundung, bei der ich Claude einen Plan oder ein Design unter Druck testen lasse — sind dort, wo Handoff seinen Wert wirklich beweist. Eine gute Grilling-Sitzung geht absichtlich in die Breite. Sie stochert in Randfällen. Sie bringt Unterfragen an die Oberfläche. Und hin und wieder braucht eine dieser Unterfragen ihre eigene fokussierte Sitzung, um tatsächlich beantwortet zu werden.

Beispiel von letzter Woche. Ich grillte einen Plan für eine neue Content-Cluster-Automatisierung. Auf halbem Weg fragte Claude: "Haben Sie bestätigt, dass der Markdown-Renderer verschachtelte Admonitions verarbeitet, wenn der Beitrag über Ihr CMS geladen wird?" Hatte ich nicht. Die Antwort war ein neunzigminütiger Prototyping-Umweg, den ich nicht innerhalb der Grilling-Sitzung laufen lassen wollte.

Handoff. "Prototyp: Drei verschachtelte Admonition-Testbeiträge durch die lokale CMS-Vorschau schicken und die Rendering-Ausgabe erfassen. Skills: Prototyp, Verify. Ergebnisse als Ein-Absatz-Ergebnis zurück an die Grilling-Sitzung melden." Die Prototyp-Sitzung läuft separat, erstellt eine Markdown-Zusammenfassung, die Grilling-Sitzung liest diese Zusammenfassung und macht weiter, ohne jemals die Testbeiträge oder die Renderer-Abhängigkeiten in ihren eigenen Kontext geladen zu haben.

Dieses zweite Handoff — das, das zurückgeht vom Prototyp zur Grilling-Sitzung — ist der Teil, der mich überrascht hat. Handoffs sind bidirektional. Die Prototyp-Sitzung schreibt ihre Ergebnisse in ein Handoff-Dokument und gibt sie zurück. Die Grilling-Sitzung liest drei Absätze destillierte Antwort, nicht neunzig Minuten Trial-and-Error.

3. Planungssitzungen, die sich von Build-Sitzungen trennen

Das andere Muster, auf das ich mich stark stütze: die Trennung von was bauen und wie es bauen. Planungssitzungen drehen sich um Entscheidungen — was ist im Scope, was ist das Datenmodell, welche Kompromisse sind wichtig. Build-Sitzungen drehen sich um die Ausführung — Code schreiben, Tests ausführen, Ausgabe verifizieren.

Diese beiden Aktivitäten verschmutzen sich gegenseitig stark, wenn sie sich ein Fenster teilen. Planungsgespräche erzeugen Dutzende kleiner "was wäre, wenn wir X machen"-Verzweigungen, die den Kontext aufblähen, aber die Entscheidung nicht überleben. Build-Sitzungen akkumulieren Testausgaben, Fehlermeldungen und Datei-Diffs, die nichts mit der ursprünglichen Spezifikation zu tun haben.

Ich führe sie jetzt als zwei Sitzungen aus. Die Planungssitzung erzeugt ein Handoff: die festgelegten Entscheidungen, die offenen Fragen, den strukturellen Plan. Die Build-Sitzung nimmt dieses Handoff, führt aus, und — wenn irgendetwas während des Builds eine Planungsentscheidung ungültig macht — schreibt ein Handoff zurück. Die Planungssitzung öffnet sich erneut, nimmt das Feedback auf und verfeinert. Schleife, bis die Build-Sitzung nichts mehr hat, was sie zurückschieben muss.

Das ist dasselbe Iterationsmuster, das ich im Beitrag über Spec-Workflow-Agents beschrieben habe, nur portabel gemacht über Sitzungen. Handoff ist das, was diese Schleife laufen lässt, ohne dass irgendjemandes Kontextfenster voll läuft.

Was in eine gute Handoff-Datei gehört

Wenn Sie jemals nur einen Abschnitt dieses Beitrags lesen, machen Sie es diesen.

Das Handoff-Dokument hat eine spezifische Aufgabe: Geben Sie einer frischen Sitzung genug, um die Arbeit fortzusetzen, ohne das Rauschen mitzuschleppen, das die Elternsitzung angesammelt hat. Bekommen Sie den Inhalt falsch und Sie haben das Problem von /compact in einer neuen Datei nachgebaut. Bekommen Sie es richtig und die frische Sitzung kommt wie ein Senior-Ingenieur an, der mitten im Sprint zu einem Projekt stößt — eingewiesen, orientiert, produktiv in zehn Minuten.

Hier ist die Struktur, die ich jetzt für jedes Handoff verwende, egal ob der Skill es generiert oder ich es von Hand bearbeite:

Zwei Muster, die Menschen beim manuellen Schreiben von Handoffs übersehen:

Wiederholen Sie nicht, was im Issue steht. Wenn es ein GitHub-Issue mit der User Story, den Akzeptanzkriterien und der Designbegründung gibt, sollte die Handoff-Datei "siehe Issue #142" sagen — nicht das Issue paraphrasieren. Paraphrasieren ist der Weg, wie Wahrheit abdriftet.

Seien Sie ehrlich bei offenen Fragen. Die Versuchung ist, das Handoff vollständig klingen zu lassen. "Wir müssen nur noch das hier ausliefern." Wenn es offene Fragen gibt, listen Sie sie auf. Die nächste Sitzung wird sie sowieso entdecken, und Sie möchten, dass sie sie in der smarten Zone des neuen Kontexts entdeckt, nicht nachdem sie sich bereits auf eine falsche Richtung festgelegt hat.

Ich halte eine kleine mentale Vorlage bereit. Ziel, Anker, Stand, festgelegt, offen, Sackgassen, Skills, Start, Redigierungen. Neun Abschnitte. Die meisten meiner Handoffs haben weniger als 600 Wörter. Der ganze Punkt ist, dass sie wegwerfbar sind — klein genug, um in einer Minute gelesen zu werden, fokussiert genug, um sofort danach zu handeln.

Wie ich Handoffs in meinem eigenen Workflow verwende

Lassen Sie mich das konkretisieren mit meiner tatsächlichen Nutzung auf mejba.me und dem breiteren Aria Content-System.

Meine typische Content-Produktionssitzung hat mindestens drei Phasen. Das Thema recherchieren. Den Artikel planen. Den Artikel schreiben. Jede dieser Phasen will andere Tools, anderen Kontext, andere Aufmerksamkeit. Die Recherchephase zieht Suchergebnisse, gescrapte Konkurrenten-URLs und Statistiken heran. Die Planungsphase will die Markenstimme-Datei, die Cluster-Taxonomie und die bestehende interne Verlinkungskarte. Die Schreibphase will den Plan, die Recherche und einen leeren Editor.

Vor ein paar Monaten versuchte ich, alle drei in einer Claude Code-Sitzung zu erledigen. Als ich den dritten Artikel in einem Cluster schrieb, hatte der Kontext ~80.000 Tokens an Recherche aus den Artikeln eins und zwei noch herumliegen, plus die Pläne für beide, plus alle drei Markenstimme-Ladungen, plus meine laufenden Notizen. Die Qualität rutschte beim zweiten Artikel sichtbar ab.

Der neue Ablauf sieht so aus:

1. Recherchesitzung — aktuelle Daten abrufen, Lücken finden, bestehende Beiträge nach internen Links durchsuchen. Erzeugt ein Handoff: "Plane einen Artikel über X mit diesen 6 verifizierten Fakten, diesen 3 internen Linkzielen und diesem Wettbewerbswinkel." Datei im temporären Verzeichnis gespeichert.
2. Planungssitzung — frisches Fenster. Lädt das Recherche-Handoff. Markenstimme und Cluster-Map kommen sauber herein. Erzeugt ein weiteres Handoff: "Schreibe einen Artikel über X nach dieser Gliederung, mit diesen spezifischen Statistiken, mit diesen internen Links, mit diesen emotionalen Akzenten."
3. Schreibsitzung — wieder ein frisches Fenster. Lädt das Planungs-Handoff. Schreibt den Artikel. Kein Recherche-Rauschen, kein Planungs-Rauschen, nur der Plan und ein Ziel.

Jede Sitzung bleibt unter ~60K Tokens, tief in der smarten Zone, fokussiert auf ihre Aufgabe. Die Qualität der Ausgabe ist merklich besser als beim Ansatz mit einer Sitzung, und die Fehlermodi — wenn etwas schiefgeht — sind leichter zu debuggen, weil ich jede Handoff-Datei lesen und genau sehen kann, was weitergegeben wurde.

Für Code-Arbeit lehne ich mich auf dieselbe Aufteilung. Die Architektur planen ist eine Sitzung. Die erste Komponente bauen ist eine Sitzung. Die zweite bauen ist eine Sitzung. Wenn ein Komponenten-Build eine Frage aufwirft, die die Architektur nicht vorhergesehen hat, ist das ein Handoff zurück zur Planungssitzung. Das ist dieselbe Logik, die Git Worktrees mit parallelen Agents und geforkte Sub-Agents so natürlich erscheinen lässt — es ist alles dasselbe Prinzip: Arbeit entlang von Grenzen aufteilen, die das Modell getrennt halten kann, anstatt das Modell zu zwingen, getrennte Grenzen innerhalb eines aufgeblähten Kontexts aufrechtzuerhalten.

Cross-Tool Handoffs: Warum Markdown wichtiger war, als ich erwartet hatte

Ich hätte die Wahl von Markdown-als-Substrat fast als offensichtlich abgetan. Es ist der größte praktische Hebel im gesamten Skill.

Markdown ist portabel. Eine von Claude Code generierte Handoff-Datei kann ohne Modifikation von Codex CLI gelesen werden. Sie kann an Copilot CLI weitergegeben werden. Sie kann in Gemini CLI geladen werden. Ich habe Arbeit zwischen drei verschiedenen Agent-Tools in einem einzigen Projekt verschoben, indem ich einfach dieselbe Markdown-Datei herumgereicht habe. Keine Formatkonvertierung, kein Verbindungscode, keine Agent-SDK-Gymnastik.

Hier werden adversariale Überprüfungsmuster interessant. Ich habe früher über das Ausführen von Codex adversarialem Review gegen die Ausgabe von Claude Code geschrieben. Die Handoff-Datei ist die perfekte Eingabe für dieses Muster. Claude Code erzeugt die Arbeit und ein Handoff, das beschreibt, was es getan hat und was noch offen ist. Codex nimmt das Handoff auf, führt Kritik durch, erzeugt sein eigenes Handoff, das beschreibt, was es gefunden hat. Claude Code nimmt mit der Kritik in der Hand wieder auf. Jeder Agent arbeitet in seiner smarten Zone. Die Markdown-Datei ist das Einzige, was Grenzen überschreiten muss.

Dieselbe Logik für DIY Sub-Agents. Sie brauchen keinen ausgefallenen Multi-Agent-Orchestrator, um spezialisierte Aufgaben parallel auszuführen. Sie brauchen eine Möglichkeit, einen Sub-Agent einzuweisen, ihn arbeiten zu lassen und seine Ergebnisse zu reintegrieren. Markdown-Handoffs tun das ohne Framework. Das "Framework" ist die Datei.

Die andere Sache, die Markdown Ihnen gibt: Überprüfen-vor-Senden. Jedes Handoff, das ich schreibe, bekommt einen dreißigsekündigen Scan, bevor ich es weitergebe. Ich überprüfe die offensichtlichen Dinge — hat die Redigierung alle Geheimnisse erfasst, sind die festgelegten Entscheidungen wirklich festgelegt, hat es Sackgassen aufgelistet, die sich im Nachhinein als der richtige Weg herausstellten. Dieser Überprüfungsschritt hat im letzten Monat mindestens drei schlechte Handoffs abgefangen. JSON oder binäre Blobs lassen Sie das nicht tun.

Was Handoff nicht ist

Es lohnt sich, ehrlich über die Grenzen zu sein, denn der Skill ist keine universelle Antwort.

Handoff ersetzt keine gute In-Session-Disziplin. Wenn Sie eine Sitzung über sechs unverwandte Themen ausufern lassen, ohne jemals zu teilen, wird der Handoff-Skill Sie nicht retten. Er gibt Ihnen nur eine etwas sauberere Zusammenfassung der ausgeuferten Sitzung am Ende. Die Disziplin, zu erkennen, wann man teilen sollte, liegt bei Ihnen — der Skill macht die Teilung nur billig, sobald Sie sich entscheiden.

Handoff ist nicht für trivial kurze Aufgaben. Wenn die gesamte Arbeit in 20K Tokens und eine Sitzung passt, sind Sie besser dran, sie zu beenden, als ein Handoff zu schreiben. Der Overhead des Handoff-Formats ist nicht kostenlos. Ich verwende es, wenn die Arbeit wirklich mehrere Sitzungen umfassen wird, nicht als Zeremonie.

Handoff repariert keine schlechten Upstream-Artefakte. Wenn Ihre ADRs falsch sind, Ihre Issue-Templates vage sind und Ihre Pläne schwammig, wird das Handoff das widerspiegeln. Verweise sind nur so gut wie das, worauf sie verweisen. Ich bemerkte, dass meine eigenen ADRs schärfer wurden, nachdem ich anfing, Handoffs zu schreiben, die auf sie verwiesen — zu wissen, dass die nächste Sitzung diese Dokumente kalt lesen würde, ließ mich sie besser schreiben.

Handoff ist kein Ersatz für Verifikation. Ein Handoff sagt "wir sind hierher gekommen." Es beweist nicht, dass der Code funktioniert. Frische Sitzungen sollten trotzdem Tests ausführen, trotzdem verifizieren, bevor sie Fertigstellung beanspruchen. Das Handoff beschreibt Absicht und Stand. Die Realität muss trotzdem überprüft werden.

Die ehrliche Zusammenfassung: Handoff ist ein Koordinierungstool. Es koordiniert Arbeit über Sitzungen, die sonst schlecht Kontext teilen würden. Es ersetzt nicht die Arbeit selbst, die Verifikation der Arbeit oder die Upstream-Dokumente, von denen die Arbeit abhängt.

Was sich ändert, wenn Sie auf diese Weise anfangen zu arbeiten

Einige Muster, die mir in meiner eigenen Arbeit aufgefallen sind, seit Handoff zur Routine wurde.

Ich plane mehr, bevor ich baue. Zu wissen, dass ich am Ende der Planungssitzung ein Handoff schreiben muss, zwingt mich, den Plan tatsächlich fertigzustellen, anstatt in "lass mich einfach mal das Erste ausprobieren" abzudriften. Wenn ich das an eine Build-Sitzung weitergeben werde, muss der Plan vollständig genug sein, um danach zu handeln. Das ist eine erzwingende Funktion, die der Ansatz mit einer Sitzung nicht hatte.

Ich bemerke Scope Creep schneller. Mitten in einer Sitzung, wenn ich mich dabei ertappe zu denken "lass mich auch noch schnell dieses Ding fixen" — dieser Gedanke wird jetzt reflexartig "lass mich ein Handoff dafür schreiben." Die Kosten eines Abstechers in der aktuellen Sitzung sind hoch. Die Kosten, ein Handoff zu schreiben und mit meiner aktuellen Arbeit fortzufahren, sind niedrig. Die Mathematik neigt sich dem Fokus zu.

Meine Sitzungen sind kürzer. Früher ließ ich routinemäßig stundenlange Claude Code-Sitzungen laufen. Jetzt dauern die meisten Sitzungen 20-40 Minuten. Die Arbeit ist dieselbe; die Sitzungen passen nur zum tatsächlichen Umfang der Aufgabe, anstatt drei Aufgaben in ein Fenster zu bündeln.

Ich vertraue meinen Agents mehr. Wenn eine frische Sitzung ein straffes Handoff lädt und die Arbeit sauber fortsetzt, fühlt sich die Ausgabe zuverlässiger an, als wenn eine einzelne Sitzung seit einer Stunde läuft und das Modell sich halb erinnert, was wir entschieden hatten. Die smarte Zone ist real. Arbeit darin zu halten ist eine Qualitätsinvestition, keine Steuer.

Häufig Gestellte Fragen

Was ist der Handoff-Skill in Claude Code?

Der Handoff-Skill komprimiert den relevanten Kontext einer Claude Code-Sitzung in eine Markdown-Datei, die eine frische Sitzung verwenden kann, um die Arbeit fortzusetzen, ohne Kontext-Ballast zu erben. Er speichert die Datei im temporären Verzeichnis des OS, verweist auf bestehende Dokumente statt sie zu duplizieren, redigiert sensible Daten und schlägt vor, welche Skills die nächste Sitzung verwenden sollte. Für die vollständige Einrichtung und Nutzungsmuster siehe den Workflow-Abschnitt oben.

Wie unterscheidet sich Handoff von /compact?

/compact fasst die aktuelle Sitzung zusammen und ersetzt deren Historie durch die Zusammenfassung, wobei Sie im selben Gespräch bleiben. handoff erzeugt eine portable Markdown-Datei, die auf den spezifischen Fokus der nächsten Sitzung ausgerichtet ist, und lässt Sie dann frisch starten. Compact dient dem Kürzen einer langen Aufgabe; Handoff dem Aufteilen unverwandter Arbeit über mehrere Sitzungen.

Wann sollte ich Handoff verwenden statt einfach die Sitzung fortzusetzen?

Verwenden Sie Handoff, wenn der nächste Arbeitsabschnitt weniger als 80% des Kontexts teilt, der sich aktuell in Ihrem Fenster befindet — Mid-Session-Refactorings unverwandten Codes, Prototyping-Spikes, die von einer Grilling-Sitzung abzweigen, oder die Trennung von Planung und Ausführung. Wenn die Arbeit eine direkte Fortsetzung dessen ist, was Sie bereits tun, ist Komprimierung normalerweise die bessere Wahl.

Was ist das praktische Kontextfenster, bevor Claude Code anfängt zu degradieren?

Die 1M Token-Obergrenze von Claude Code ist die Marketing-Zahl. Praktische Qualitätsdegradation beginnt typischerweise bei etwa 120.000 Tokens, wobei einige Teams merkliches Abdriften bereits bei 50% des Fensters berichten. Die Budgetierung der Aufmerksamkeit innerhalb der smarten Zone ist wichtiger als die Obergrenze selbst.

Kann ich Handoff bei verschiedenen AI-Coding-Agents verwenden?

Ja. Die Handoff-Ausgabe ist einfaches Markdown, was sie portabel zwischen Claude Code, Codex CLI, Copilot CLI, Gemini CLI und jedem anderen Agent macht, der Text liest. Das ist es, was Cross-Agent-Muster ermöglicht, wie das Ausführen von Codex adversarialem Review gegen die Ausgabe von Claude Code, ohne benutzerdefinierten Verbindungscode zu schreiben.

Lassen Sie Uns Zusammenarbeiten

Sie möchten KI-Systeme aufbauen, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich helfe Ihnen gerne.

• Fiverr (individuelle Entwicklung & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io