Handoff Skill: De Claude Code Workflow Die Mijn Context-Overbelasting Oploste
De sessie zat op 142.000 tokens toen ik merkte dat Claude zichzelf begon te herhalen.
Ik zat diep in een planningsgesprek over een nieuwe Aria content-pipeline — drie merken, vier berichttypen, een gedeeld onderzoeksprotocol, het hele pakket. Halverwege vroeg ik om een kleine refactor uit te werken van een ongerelateerde cron-skill die niets met de pipeline te maken had. Vijfenveertig minuten later sprak Claude mij beleefd tegen over beslissingen die we tweehonderd berichten eerder hadden vastgelegd, vermengde de cron-logica met de content-specificatie en citeerde mijn eigen ADR's net iets verkeerd terug. Het 1M context-venster stond technisch gezien nog open. In de praktijk werkte het model in mist.
Die sessie is de reden waarom ik de handoff-skill ben gaan gebruiken. En zodra ik handoff in plaats van /compact begon te gebruiken voor dit soort momenten, was het verschil niet subtiel — het was het verschil tussen een gefocuste engineer die een taak netjes afrondt en een vermoeide die steeds dezelfde Slack-thread heropent.
Dit is het bericht dat ik wou dat iemand me zes weken geleden had gegeven. We gaan de handoff-skill helemaal uit elkaar halen: hoe het werkt, waarom het compactie overtreft voor multi-thread werk, wat het markdown-bestand werkelijk bevat, wanneer je het moet gebruiken, en hoe ik het in mijn eigen Aria + Claude Code workflow op deze site heb geïntegreerd. Aan het einde weet je precies waar in je huidige sessies je een handoff zou moeten schrijven en waar niet.
Het context-venster is groter, en dat maakte het probleem erger
Laat me de scene goed schetsen, want de inkadering is belangrijk.
Claude Code wordt nu geleverd met een 1M token context-venster. Dat klinkt als een opgelost probleem — gooi alles erin, het model zoekt het wel uit. Het is geen opgelost probleem. Anthropic's eigen documentatie bevestigt het: nauwkeurigheid en herinnering nemen af naarmate de context vol raakt. Onafhankelijke tests van teams die Claude Code in productie draaien plaatsen het praktische degradatiepunt veel eerder dan het plafond — de kwaliteit begint te dalen rond de 120.000-token grens, ruim voordat het venster technisch vol is. Sommige teams rapporteren meetbaar kwaliteitsverlies al bij 50% van de capaciteit.
Ik beschouw elk context-venster als twee lagen die op elkaar gestapeld zijn:
- De slimme zone — de vroege tokens, de systeemprompt, de meest recente uitwisselingen. De aandacht is hier scherp. Het model weet wat je vroeg, wat het antwoordde en wat er nu op tafel ligt.
- De domme zone — de latere tokens, het verouderde midden, de delen waar het aandachtsmechanisme moeite mee heeft om ze goed te wegen. Het zit nog steeds "in de context." Het krijgt alleen niet de focus die je denkt.
Zodra een sessie de domme zone betreedt, merk je het niet altijd. De antwoorden klinken nog steeds zelfverzekerd. Ze citeren misschien nog eerdere uitwisselingen. Maar de precisie daalt. Beslissingen die je nam worden vergeten of stilletjes teruggedraaid. Toolselecties worden vaag. Code begint eruit te zien als een samenstelling van drie verschillende ontwerpkeuzes waar je bijna op geconvergeerd was.
De eerlijke versie van "1M context" is meer zoiets als: 1M plafond, ~120K aan betrouwbare slimme zone, dan een lange degradatiecurve. Het budgetteren van aandacht binnen het venster is net zo belangrijk als het plafond zelf — en ik zou beweren zelfs belangrijker. Ik schreef hier uitgebreid over in mijn analyse van Claude Code's 1M contextbeheer en in het stuk over contexthygiëne bij tokenlimiten. Beide zijn nog steeds van toepassing.
Wat handoff doet, in één zin: het geeft je een schone manier om werk over meerdere sessies te verdelen zodat elke sessie in zijn eigen slimme zone blijft in plaats van te doen alsof de domme zone niet bestaat.
Wat de handoff-skill werkelijk doet
Hier is de workflow-verschuiving die bij mij klikte.
Wanneer de handoff-skill wordt aangeroepen, comprimeert de huidige Claude Code-sessie alles wat relevant is — wat we probeerden te doen, wat we besloten, wat we probeerden, wat nog open staat, welke bestanden we aanraakten, welke skills de volgende sessie moet ophalen — in één enkel Markdown-bestand. Dat bestand wordt opgeslagen in de tijdelijke map van het besturingssysteem (zodat het de werkruimte niet vervuilt), en dan opent een nieuwe Claude Code-sessie dat bestand en gaat verder met het werk zonder de ballast over te nemen.
Een paar details die ik pas na een paar keer proberen waardeerde:
Het handoff-bestand is doelgericht, niet generiek. De skill accepteert een argument dat de focus van de volgende sessie beschrijft. "Ga door met het API-ontwerp" levert een heel ander handoff op dan "bouw een UI-prototype voor het ontwerp dat we net geschetst hebben" — zelfs wanneer beide uit dezelfde oudersessie komen. De compressie is intentioneel, niet een domme samenvatting.
Het is een echt Markdown-bestand, geen verborgen JSON-blob. Ik kan het openen, lezen, bewerken, een alinea toevoegen, een sectie verwijderen, een token redigeren voordat ik het doorgeef. Dat is een eigenschap die ik onderschatte totdat ik hetzelfde probeerde met de samenvatting van /compact, die ondoorzichtig en verliesgevend is op manieren die je niet kunt controleren.
Het verwijst in plaats van te dupliceren. Als we een GitHub-issue of een ADR voor het werk hadden geschreven, verwijst het handoff-bestand ernaar in plaats van de inhoud te plakken. Klinkt logisch — behalve dat /compact het tegenovergestelde doet. Het hervat alles, waardoor de volgende sessie eindigt met een vage parafrase van het issue dat je al precies had geschreven.
Het bevat een sectie "voorgestelde skills". Dit is het deel dat ik wil dat elk framework kopieert. De huidige sessie weet welke tools, skills of sub-agent patronen de volgende sessie waarschijnlijk nodig heeft — TDD, brainstorming, worktrees, verificatie — en schrijft die hint in de handoff. De nieuwe sessie arriveert al gericht op de juiste gereedschapskist.
Gevoelige gegevens worden geredigeerd voor het opslaan. API-sleutels, geheimen, persoonlijke informatie — de skill verwijdert ze voordat het bestand op schijf terechtkomt. Ik scan handoffs nog steeds handmatig voordat ik ze doorgeef, maar dat als ingebouwde standaard hebben is beter dan hopen dat ik eraan dacht.
Als je Obra's superpowers-framework hebt gebruikt (ongeveer 195k sterren op GitHub op het moment dat ik dit schrijf, snel groeiend), zal dit native aanvoelen — handoff is precies het soort gedisciplineerde, methodologie-gedreven skill dat dat hele ecosysteem laat werken. Ik behandelde het bredere patroon in mijn superpowers plugin review. De handoff-skill is het onderdeel dat ik de eerste weken te weinig gebruikte totdat de multi-sessie wiskunde me inhaalde.
Compactie vs handoff: de vergelijking die veranderde hoe ik werk
/compact en handoff lijken van een afstand op elkaar. Beide produceren een gecomprimeerde weergave van waar je bent geweest. Ze lossen heel verschillende problemen op.
Hier is de directe vergelijking zoals ik ze nu gebruik:
| Dimensie | /compact (compactie) |
handoff skill |
|---|---|---|
| Sessietopologie | Enkele langlopende sessie | Meerdere doelgerichte sessies |
| Wat het comprimeert | De volledige geschiedenis van de huidige sessie | Alleen wat de volgende sessie moet weten |
| Waar de uitvoer naartoe gaat | Terug in de context van dezelfde sessie | Een Markdown-bestand in de tijdelijke map van het OS |
| Controleerbaarheid | Ondoorzichtige samenvatting, niet bewerkbaar | Leesbaar bestand, bewerkbaar voor doorgifte |
| Cross-sessie continuïteit | Hetzelfde gesprek, alleen korter | Frisse aandacht, gerichte focus, slimme zone reset |
| Cross-tool portabiliteit | Geen — gebonden aan die sessie | Markdown werkt in Claude Code, Codex CLI, Copilot CLI |
| Omgang met gevoelige gegevens | Standaard geen | Redigeerstap voor opslaan |
| Verwijzing vs duplicaat | Hervat alles | Verwijst naar bestaande artefacten (issues, ADR's, plannen) |
| Het beste voor | Inkorten van één sessie die te lang liep op een enkele coherente taak | Opsplitsen van ongerelateerd werk, prototypen van zijpaden, cross-agent flows |
| Faalmodus bij verkeerd gebruik | Verliesgevende compressie van werk dat je nog nodig hebt | Twee sessies die afdrijven als het handoff-document niet strak is |
Lees die tabel eens zijdelings. Compactie is een geheugentool — het probeert een enkele thread passend te maken. Handoff is een workflowtool — het splitst threads zodat elk er van nature in past. Het eerste is een pleister; het tweede is structureel.
Als je taak is "blijf dezelfde API-spec nog drie uur verfijnen, alleen minder breedsprakig" — compacteer. Als je taak is "ik moet een prototype uitproberen om een vraag te beantwoorden die opkwam tijdens het specificeren van de API" — handoff. Ze door elkaar halen is de fout die ik wekenlang maakte.
Er is een nog simpelere vuistregel die ik nu gebruik. Vraag: "Zal het volgende deel van dit gesprek 80%+ van de context delen die momenteel in het venster zit?" Zo ja, compacteer. Zo nee, handoff. De meeste keren dat ik vroeger naar compact greep, was het eerlijke antwoord nee.
Wanneer je naar een handoff moet grijpen
Drie patronen hebben een vaste plek in mijn workflow verdiend.
1. De verleiding van de mid-sessie refactor
Ik zit diep in het bouwen van feature A. Ik merk iets op in een gedeelde module dat duidelijk slecht ontworpen is — een functie die drie dingen doet, een config-vlag met de verkeerde standaardwaarde, een test die al zes commits stilletjes wordt overgeslagen. De oude ik zou het meteen gefixed hebben. De huidige sessie zou twintig berichten over die refactor erven, waarvan de helft nog in het venster zou zitten wanneer ik terugkeerde naar feature A en moest herinneren wat we over diens randgevallen hadden besloten.
De nieuwe ik schrijft een handoff. "Refactor RoutePlanner.normalize() om padvalidatie van opmaak te scheiden. Tests op tests/router/normalize.test.ts dekken de gevallen al. Skills: brainstorming, TDD." De nieuwe sessie pakt het op, levert de refactor, komt schoon terug. De sessie van feature A blijft de hele tijd in de slimme zone.
Dit is de goedkoopste enkele workflowwinst die ik dit jaar van welke AI-toolingwijziging dan ook heb gekregen. De kosten van het vervuilen van een diepe sessie met een ongerelateerde refactor zijn veel hoger dan de kosten van het schrijven van een handoff-bestand.
2. Grilling-sessies die vertakken
Grilling-sessies — interactieve, vraaggestuurde verkenning waarbij ik Claude een plan of ontwerp laat testen — zijn waar handoff echt zijn waarde bewijst. Een goede grilling-sessie gaat bewust breed. Het prikt in randgevallen. Het brengt subvragen naar boven. En af en toe heeft een van die subvragen zijn eigen gefocuste sessie nodig om daadwerkelijk te beantwoorden.
Voorbeeld van vorige week. Ik was een plan aan het grillen voor een nieuwe content-cluster automatisering. Halverwege vroeg Claude: "Heb je bevestigd dat de markdown-renderer geneste admonitions verwerkt wanneer het bericht via je CMS wordt geladen?" Dat had ik niet. Het antwoord was een negentig minuten durende prototyping-omweg die ik niet binnen de grilling-sessie wilde uitvoeren.
Handoff. "Prototype: voer drie testberichten met geneste admonitions door de lokale CMS-preview en leg de renderinguitvoer vast. Skills: prototype, verify. Rapporteer bevindingen terug naar de grilling-sessie als een resultaat van één alinea." De prototype-sessie draait apart, dumpt een markdown-samenvatting, de grilling-sessie leest die samenvatting en gaat verder zonder ooit de testberichten of de renderer-afhankelijkheden in zijn eigen context te hebben geladen.
Die tweede handoff — degene die terugaat van het prototype naar de grilling-sessie — is het deel dat me verraste. Handoffs zijn bidirectioneel. De prototype-sessie schrijft zijn bevindingen in een handoff-document en geeft ze terug. De grilling-sessie leest drie alinea's gedestilleerd antwoord, niet negentig minuten trial-and-error.
3. Planningssessies die splitsen van bouwsessies
Het andere patroon waar ik zwaar op leun: het scheiden van wat te bouwen van hoe het te bouwen. Planningssessies gaan over beslissingen — wat is in scope, wat is het datamodel, welke afwegingen zijn belangrijk. Bouwsessies gaan over uitvoering — schrijf de code, voer de tests uit, verifieer de uitvoer.
Deze twee activiteiten vervuilen elkaar ernstig wanneer ze een venster delen. Planningsgesprekken produceren tientallen kleine "wat als we X doen" vertakkingen die de context opblazen maar de beslissing niet overleven. Bouwsessies accumuleren testuitvoer, foutmeldingen en bestandsdiffs die niets met de oorspronkelijke specificatie te maken hebben.
Ik voer ze nu als twee sessies uit. De planningssessie produceert een handoff: de vastgelegde beslissingen, de open vragen, het structurele plan. De bouwsessie neemt die handoff, voert uit, en — als iets tijdens het bouwen een planningsbeslissing ongeldig maakt — schrijft een handoff terug. De planningssessie opent opnieuw, neemt de feedback op en verfijnt. Loop totdat de bouwsessie niets meer heeft om terug te duwen.
Dit is hetzelfde iteratiepatroon dat ik beschreef in het bericht over spec workflow agents, alleen draagbaar gemaakt over sessies. Handoff is wat die lus laat draaien zonder dat iemands context-venster volloopt.
Wat er in een goed handoff-bestand hoort
Als je ooit maar één sectie van dit bericht leest, laat het deze zijn.
Het handoff-document heeft een specifieke taak: geef een nieuwe sessie genoeg om het werk voort te zetten zonder de ruis mee te slepen die de oudersessie had opgebouwd. Krijg de inhoud verkeerd en je hebt het probleem van /compact opnieuw opgebouwd in een nieuw bestand. Krijg het goed en de nieuwe sessie arriveert als een senior engineer die halverwege een sprint bij een project komt — gebrieft, georiënteerd, productief binnen tien minuten.
Hier is de structuur die ik nu voor elke handoff gebruik, of de skill het genereert of ik het met de hand bewerk:
| Sectie | Wat erin gaat | Wat er NIET in gaat |
|---|---|---|
| Doel | Eén zin die aangeeft waarvoor de volgende sessie verantwoordelijk is | Achtergrondverhaal over hoe we hier kwamen |
| Contextanker | Links naar ADR's, GitHub-issues, ontwerpdocumenten, eerdere handoffs — niet de inhoud, alleen de verwijzingen | Geplakte inhoud van die documenten |
| Waar we staan | Huidige status: branch, aangeraakte bestanden, wat gedeployed is, wat teruggedraaid is | Stapsgewijze geschiedenis van elke wijziging |
| Vastgelegde beslissingen | Dingen die al besloten zijn en die de volgende sessie niet opnieuw mag betwisten | Het gesprek dat de beslissingen produceerde |
| Open vragen | De 2-5 dingen die nog onopgelost zijn en die de volgende sessie moet beantwoorden | Speculatie over elke mogelijke vraag |
| Wat we geprobeerd hebben (en waarom het niet werkte) | Doodlopende wegen die vermeden moeten worden, geschreven als éénregelers | Lange fouttranscripten of stacktraces |
| Voorgestelde skills | TDD, brainstorming, verify, prototype, worktrees — welke skills de volgende sessie waarschijnlijk zal gebruiken | "Misschien deze aanpak proberen" proza |
| Snelle start | Het eerste commando, het eerste bestand om te openen, de eerste vraag om te beantwoorden | Een volledige tutorial |
| Redigeringen van gevoelige gegevens | Markering die toont wat geredigeerd is en waar het te vinden is | De daadwerkelijke gevoelige gegevens |
Twee patronen die mensen missen wanneer ze handoffs met de hand schrijven:
Herhaal niet wat in het issue staat. Als er een GitHub-issue is met het gebruikersverhaal, de acceptatiecriteria en de ontwerprationale, zou het handoff-bestand moeten zeggen "zie issue #142" — niet het issue parafraseren. Parafraseren is hoe waarheid afdrijft.
Wees eerlijk over open vragen. De verleiding is om de handoff compleet te laten klinken. "We hoeven alleen dit nog te leveren." Als er open vragen zijn, lijst ze op. De volgende sessie ontdekt ze toch, en je wilt dat het ze ontdekt in de slimme zone van de nieuwe context, niet nadat het zich al heeft vastgelegd op een verkeerde richting.
Ik houd een klein mentaal sjabloon bij. Doel, anker, status, vastgelegd, open, doodlopende wegen, skills, start, redigeringen. Negen secties. De meeste van de mijne zijn minder dan 600 woorden. Het hele punt is dat ze wegwerpbaar zijn — klein genoeg om in een minuut te lezen, gefocust genoeg om er direct naar te handelen.
Hoe ik handoffs gebruik in mijn eigen workflow
Laat me dit concreet maken met hoe ik het daadwerkelijk gebruik op mejba.me en het bredere Aria content-systeem.
Mijn typische contentproductiesessie heeft minstens drie fases. Het onderwerp onderzoeken. Het artikel plannen. Het artikel schrijven. Elk van die fases wil andere tools, andere context, andere aandacht. De onderzoeksfase haalt zoekresultaten, gescrapete concurrenten-URL's en statistieken op. De planfase wil het brand voice-bestand, de clustertaxonomie en de bestaande interne-linkinmap. De schrijffase wil het plan, het onderzoek en een lege editor.
Een paar maanden geleden probeerde ik alle drie in één Claude Code-sessie te doen. Tegen de tijd dat ik het derde artikel in een cluster schreef, had de context ~80.000 tokens aan onderzoek van artikelen één en twee nog rondzweven, plus de plannen voor beide, plus alle drie de brand voice-ladingen, plus mijn lopende notities. De kwaliteit gleed zichtbaar weg bij het tweede artikel.
De nieuwe flow ziet er zo uit:
- Onderzoekssessie — haal actuele data op, vind hiaten, scan bestaande berichten voor interne links. Produceert een handoff: "Plan een artikel over X met deze 6 geverifieerde feiten, deze 3 interne linkdoelen en deze concurrentiehoek." Bestand opgeslagen in tijdelijke map.
- Planningssessie — nieuw venster. Laadt de onderzoekshandoff. Brand voice en clustermap komen schoon binnen. Produceert nog een handoff: "Schrijf een artikel over X volgens dit overzicht, met deze specifieke statistieken, met deze interne links, met deze emotionele accenten."
- Schrijfsessie — weer een nieuw venster. Laadt de planningshandoff. Schrijft het artikel. Geen onderzoeksruis, geen planningsruis, alleen het plan en een doel.
Elke sessie blijft onder ~60K tokens, diep in de slimme zone, gefocust op zijn taak. De kwaliteit van de uitvoer is merkbaar beter dan de aanpak met één sessie, en de faalwijzen — wanneer er iets misgaat — zijn gemakkelijker te debuggen omdat ik elk handoff-bestand kan lezen en precies kan zien wat er werd doorgegeven.
Voor codework leun ik op dezelfde splitsing. De architectuur plannen is een sessie. Het eerste component bouwen is een sessie. Het tweede bouwen is een sessie. Als een componentbouw een vraag oproept die de architectuur niet had voorzien, is dat een handoff terug naar de planningssessie. Dit is dezelfde logica die git worktrees met parallelle agents en geforkte sub-agents zo natuurlijk laat aanvoelen — het is allemaal hetzelfde principe: splits werk langs grenzen die het model gescheiden kan houden, in plaats van het model te dwingen gescheiden grenzen te bewaren binnen één opgeblazen context.
Cross-tool handoffs: waarom Markdown belangrijker bleek dan ik verwachtte
Ik had de keuze voor Markdown-als-drager bijna afgedaan als vanzelfsprekend. Het is de grootste praktische hefboom in de hele skill.
Markdown is draagbaar. Een handoff-bestand gegenereerd door Claude Code kan zonder aanpassing door Codex CLI worden gelezen. Het kan aan Copilot CLI worden doorgegeven. Het kan in Gemini CLI worden geladen. Ik heb werk verplaatst tussen drie verschillende agent-tools in één enkel project door simpelweg hetzelfde Markdown-bestand rond te geven. Geen formaatconversie, geen lijmcode, geen agent SDK-gymnastiek.
Dit is waar adversarial review-patronen interessant worden. Ik heb eerder geschreven over het uitvoeren van Codex adversarial review tegen de uitvoer van Claude Code. Het handoff-bestand is de perfecte input voor dat patroon. Claude Code produceert het werk en een handoff die beschrijft wat het deed en wat nog open staat. Codex pakt de handoff op, voert kritiek uit, produceert zijn eigen handoff die beschrijft wat het vond. Claude Code hervat met de kritiek in de hand. Elke agent werkt in zijn slimme zone. Het Markdown-bestand is het enige dat grenzen moet oversteken.
Dezelfde logica voor DIY sub-agents. Je hebt geen fancy multi-agent orchestrator nodig om gespecialiseerde taken parallel uit te voeren. Je hebt een manier nodig om een sub-agent te briefen, het te laten werken en de resultaten te herintegreren. Markdown handoffs doen dat zonder framework. Het "framework" is het bestand.
Het andere dat Markdown je geeft: beoordelen-voor-verzending. Elke handoff die ik schrijf krijgt een scan van dertig seconden voordat ik het doorgeef. Ik controleer de voor de hand liggende dingen — heeft de redigering alle geheimen gevangen, zijn de vastgelegde beslissingen echt vastgelegd, heeft het doodlopende wegen opgenoemd die achteraf het juiste pad bleken te zijn. Die beoordelingsstap heeft in de afgelopen maand minstens drie slechte handoffs gevangen. JSON of binaire blobs laten je dat niet doen.
Wat handoff niet is
Het is de moeite waard eerlijk te zijn over de beperkingen, want de skill is geen universeel antwoord.
Handoff vervangt geen goede in-sessie discipline. Als je één sessie laat uitwaaieren over zes ongerelateerde onderwerpen zonder ooit te splitsen, zal de handoff-skill je niet redden. Het geeft je alleen een iets schonere samenvatting van de uitgewaaierde sessie aan het einde. De discipline om te herkennen wanneer je moet splitsen is van jou — de skill maakt de splitsing alleen goedkoop zodra je je vastlegt.
Handoff is niet voor triviaal korte taken. Als de hele klus in 20K tokens en één sessie past, kun je het beter afmaken dan een handoff schrijven. De overhead van het handoff-formaat is niet gratis. Ik gebruik het wanneer het werk daadwerkelijk meerdere sessies zal beslaan, niet als ceremonie.
Handoff repareert geen slechte upstream-artefacten. Als je ADR's verkeerd zijn, je issue-templates vaag zijn en je plannen halfbakken, zal de handoff dat weerspiegelen. Verwijzingen zijn alleen zo goed als waarnaar ze verwijzen. Ik merkte dat mijn eigen ADR's scherper werden nadat ik handoffs begon te schrijven die ernaar verwezen — wetende dat de volgende sessie die documenten koud zou lezen maakte dat ik ze beter schreef.
Handoff is geen vervanging voor verificatie. Een handoff zegt "we zijn hier gekomen." Het bewijst niet dat de code werkt. Nieuwe sessies moeten nog steeds tests uitvoeren, nog steeds verifiëren voordat ze voltooiing claimen. De handoff beschrijft intentie en status. De werkelijkheid moet nog steeds gecontroleerd worden.
De eerlijke samenvatting: handoff is een coördinatietool. Het coördineert werk over sessies die anders slecht context zouden delen. Het vervangt niet het werk zelf, de verificatie van het werk, of de upstream-documenten waar het werk van afhangt.
Wat er verandert wanneer je op deze manier gaat werken
Een paar patronen die ik in mijn eigen werk heb opgemerkt sinds handoff routine werd.
Ik plan meer voordat ik bouw. Wetende dat ik aan het einde van de planningssessie een handoff moet schrijven dwingt me om het plan daadwerkelijk af te maken in plaats van af te dwalen naar "laat ik maar gewoon het eerste ding proberen." Als ik dit aan een bouwsessie ga overhandigen, moet het plan compleet genoeg zijn om ernaar te handelen. Dat is een dwingende functie die de aanpak met één sessie niet had.
Ik merk scope creep sneller op. Midden in een sessie, wanneer ik mezelf betrap op de gedachte "laat ik ook dit dingetje even snel fixen" — die gedachte wordt nu reflexmatig "laat ik een handoff schrijven voor dat ding." De kosten van een zijpad in de huidige sessie zijn hoog. De kosten van het schrijven van een handoff en doorgaan met mijn huidige werk zijn laag. De wiskunde kantelt naar focus.
Mijn sessies zijn korter. Ik draaide vroeger standaard uurlange Claude Code-sessies. Nu duren de meeste sessies 20-40 minuten. Het werk is hetzelfde; de sessies passen alleen bij de werkelijke omvang van de taak in plaats van drie taken in één venster te bundelen.
Ik vertrouw mijn agents meer. Wanneer een nieuwe sessie een strakke handoff laadt en het werk netjes voortzet, voelt de uitvoer betrouwbaarder dan wanneer een enkele sessie al een uur draait en het model half-herinnert wat we besloten. De slimme zone is echt. Werk erin houden is een kwaliteitsinvestering, geen belasting.
Veelgestelde Vragen
Wat is de handoff-skill in Claude Code?
De handoff-skill comprimeert de relevante context van een Claude Code-sessie in een Markdown-bestand dat een nieuwe sessie kan gebruiken om het werk voort te zetten zonder context-ballast over te nemen. Het slaat het bestand op in de tijdelijke map van het OS, verwijst naar bestaande documenten in plaats van ze te dupliceren, redigeert gevoelige gegevens en stelt voor welke skills de volgende sessie moet gebruiken. Voor de volledige opzet en gebruikspatronen, zie de workflow-sectie hierboven.
Hoe verschilt handoff van /compact?
/compact vat de huidige sessie samen en vervangt de geschiedenis met de samenvatting, waarbij je in hetzelfde gesprek blijft. handoff produceert een draagbaar Markdown-bestand gericht op de specifieke focus van de volgende sessie en laat je dan opnieuw beginnen. Compact is voor het inkorten van één lange taak; handoff is voor het opsplitsen van ongerelateerd werk over meerdere sessies.
Wanneer moet ik handoff gebruiken in plaats van gewoon de sessie voort te zetten?
Gebruik handoff wanneer het volgende deel van het werk minder dan 80% van de context deelt die momenteel in je venster zit — mid-sessie refactors van ongerelateerde code, prototyping-spikes die aftakken van een grilling-sessie, of het scheiden van planning van uitvoering. Als het werk een directe voortzetting is van wat je al doet, is compactie meestal de betere keuze.
Wat is het praktische context-venster voordat Claude Code begint te degraderen?
Het 1M token plafond van Claude Code is het marketingcijfer. Praktische kwaliteitsdegradatie begint typisch rond 120.000 tokens, waarbij sommige teams merkbare drift rapporteren al bij 50% van het venster. Het budgetteren van aandacht binnen de slimme zone is belangrijker dan het plafond zelf.
Kan ik handoff gebruiken bij verschillende AI-codeeragents?
Ja. De handoff-uitvoer is platte Markdown, waardoor het draagbaar is tussen Claude Code, Codex CLI, Copilot CLI, Gemini CLI en elke andere agent die tekst leest. Dit is wat cross-agent patronen mogelijk maakt zoals het uitvoeren van Codex adversarial review tegen de uitvoer van Claude Code zonder aangepaste lijmcode te schrijven.
Laten We Samenwerken
Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur opschalen? Ik help u graag.
- Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
