Zo deel je Claude-werk met je team

Als een collega je nu om de Claude-thread vraagt die je gebruikte om de campagnebrief op te stellen, kopieer je waarschijnlijk de uiteindelijke uitvoer naar Slack en beschouw je het als afgehandeld. Hij krijgt het antwoord zonder iets van de redenering, dus de volgende keer dat hij het moet bijstellen, begint hij een nieuwe chat en bouwt je context van nul af aan opnieuw op.

Dat is het deel dat de moeite waard is om te herstellen. De uitvoer is niet het waardevolle dat je overdraagt. De context is dat wel.

Het nuttigste wat je kunt delen is niet Claude's antwoord. Het is alles wat Claude tot dat antwoord bracht.

Wanneer je Claude-werk deelt (en wanneer niet)

Niet elk Claude-gesprek verdient een collega. Delen kost iets: iemand moet je context lezen, je kader begrijpen en beslissen of hij je opzet vertrouwt voordat hij erop kan voortbouwen. Dat is alleen de moeite waard als het werk ergens naartoe gaat.

Deel als:

• De uitvoer in de loop van de tijd door meer dan één persoon wordt herzien (een positioneringsdocument, een rapportstructuur, een campagnebrief).
• Meerdere teamleden variaties op hetzelfde basiswerk moeten maken (verschillende doelgroepen, verschillende formaten, hetzelfde onderliggende onderzoek).
• Je iets bouwt dat de huidige taak overleeft, zoals een stijlgids, een onderzoekssamenvatting of een terugkerend rapportsjabloon.

Doe geen moeite om te delen als:

• De taak eenmalig en wegwerpbaar is, zoals een enkele e-mail herschrijven of één artikel samenvatten.
• Je nog in de rommelige, verkennende fase zit en het gesprek vol doodlopende wegen staat. Ruim het eerst op, anders kan niemand zien wat ertoe deed.
• De collega sneller bij hetzelfde antwoord zou komen door Claude de vraag gewoon zelf te stellen met zijn eigen context.

Een goede vuistregel: als je de moeite zou nemen een alinea in Slack te schrijven die uitlegt “dit is wat ik deed en waarom”, is het werk deelbaar. Als je die moeite niet zou nemen, is het waarschijnlijk nog niet af genoeg om over te dragen.

Een gedeeld Project opzetten dat je team echt kan gebruiken

Een Claude-Project is de juiste container als het werk doorlopend is, maar alleen als je het zo opzet dat een collega er koud in kan stappen en kan gaan bijdragen. Dat betekent vooraf wat structureel werk doen in plaats van het als een hoop chatgeschiedenis te laten liggen.

1. Noem het Project naar zijn doel, niet naar zijn herkomst. “Q3-campagnebrief” wint van “Marketingchat 4”. Iemand zou moeten weten waarvoor het dient voordat hij het opent.
2. Voeg eerst een vastgepind contextdocument toe. Zet vóór elk gesprek een korte brief in de kennisbank van het Project: waar dit Project voor is, wie het gebruikt, hoe “klaar” eruitziet.
3. Neem bronmateriaal op, geen samenvattingen van bronmateriaal. Als het Project over een productlancering gaat, voeg dan de echte productspecificatie toe, niet je parafrase in drie zinnen. Collega's moeten beweringen kunnen verifiëren, niet alleen jouw lezing vertrouwen.
4. Stel verwachtingen over hoe men het moet gebruiken. Een notitie van één regel als “Begin voor elk concept nieuwe chats binnen dit Project, overschrijf de vastgepinde brief niet” voorkomt later verwarring.
5. Test het zelf als vreemde. Open het Project vers en vraag: zou iemand zonder herinnering aan deze taak kunnen bedenken wat er hierna moet gebeuren? Zo niet, voeg toe wat ontbreekt.

Dit opzetproces is dezelfde reden waarom Projects goed werken voor context die moet blijven bestaan: de context leeft in het Project zelf, niet in het hoofd van één persoon of de scrollgeschiedenis van één gesprek.

Een gesprek of een Project delen: welke container

Ze lossen verschillende problemen op, en de verkeerde kiezen is een veelvoorkomende bron van wrijving.

Deel één gesprek als:

• Het een eenmalige overdracht is. Iemand moet zien hoe je tot een beslissing kwam en dan verdergaan.
• De taak een duidelijk eindpunt heeft en niemand volgende maand op deze context terug hoeft te komen.
• Je een specifieke redeneerlijn precies wilt bewaren zoals ze verliep, zonder dat iemand anders nieuwe draden toevoegt die haar vertroebelen.

Zet een Project op als:

• Meer dan één persoon over meerdere sessies bijdraagt.
• De context (merkstem, brondocumenten, eerdere beslissingen) herbruikbaar moet zijn voor veel verschillende verzoeken, niet slechts één.
• Je verwacht dat het werk zich ontwikkelt. Een enkel gesprek wordt snel onhandelbaar zodra meerdere mensen niet-samenhangende vragen in dezelfde thread gooien.

Als je niet zeker weet welke van toepassing is, vraag je dan af of dit een momentopname of een werkruimte is. Een momentopname is een moment in de tijd dat het bewaren waard is. Een werkruimte is een plek waar mensen steeds naar terugkomen. Het is hetzelfde onderscheid als bij kiezen tussen een nieuwe chat, een Project of een oude thread oppakken, alleen toegepast op teamniveau in plaats van individueel niveau.

Context schrijven die je team kan oppakken en gebruiken

De grootste enkele mislukking in team-workflows met Claude is iemand een Project overhandigen en verwachten dat hij je denken uit de ruwe chatgeschiedenis reverse-engineert. Schrijf de context in plaats daarvan op. Het kost vijf minuten en bespaart alle anderen een uur.

Een goede overdrachtsnotitie beantwoordt drie vragen:

• Wat heb ik al geprobeerd? Neem aanpakken op die niet werkten, niet alleen die wel werkten. Dat houdt een collega ervan af een doodlopende weg opnieuw te testen.
• Wat werkt er nu echt? Wijs naar het specifieke concept, de beslissing of de uitvoer die als huidige basis moet gelden.
• Wat is de volgende stap? Laat niemand raden of hij moet verfijnen, uitbreiden of een heel nieuwe richting beginnen.

Hier is een formaat dat goed werkt bovenaan een gedeeld Project vastgepind:

Prompt voor de overdrachtsnotitie:

Vat dit gesprek samen voor een collega die dit werk vers
oppakt. Neem op:
1. Het oorspronkelijke doel in één zin.
2. Welke aanpakken zijn geprobeerd en verworpen, met een regel
   reden voor elk.
3. Het huidige beste concept of antwoord, volledig geciteerd.
4. De specifieke volgende stap, geformuleerd als taak (bijvoorbeeld
   “maak de tweede alinea strakker” in plaats van “blijf verbeteren”).
Houd het onder de 200 woorden. Geen beleefdheden of voorbehouden.

Dit levert een notitie op die een collega in dertig seconden leest in plaats van door veertig berichten te scrollen. Voor een herbruikbare versie van hetzelfde idee, zie een contextbrief maken die je niet meer opnieuw typt, die het formaat dieper behandelt.

Omgaan met feedback als je team Claude's uitvoer verfijnt

Zodra een collega een Claude-concept met de hand bewerkt, is die bewerking het waardevolste stuk context in de hele workflow, en het is makkelijk te verliezen zodra je terug in Claude gaat om verder te itereren.

De oplossing is menselijke bewerkingen als invoer te behandelen, niet alleen als een eindproduct dat door het volgende concept wordt vervangen.

1. Leg het verschil vast, niet alleen de eindversie. Voordat je het herziene concept van een collega terug in Claude plakt, noteer je wat er veranderde en waarom, ook kort (“tweede alinea geschrapt, de call-to-action strakker gemaakt, toon minder formeel gemaakt”).
2. Voed de redenering terug in de prompt, niet alleen de nieuwe tekst. Vraag Claude door te gaan in de richting van de bewerking, niet het alleen als nieuw ruwmateriaal te accepteren.
3. Werk de vastgepinde context bij als de bewerking een blijvende voorkeur weerspiegelt. Als je collega altijd bijvoeglijke naamwoorden schrapt, is dat een stijlregel die in de Project-brief hoort, niet iets om elke ronde opnieuw te ontdekken.
4. Bevestig dat het volgende concept de bewerking respecteert voordat je verdergaat. Een snelle controle als “behoudt dit de strakkere call-to-action uit de vorige ronde?” vangt regressies vroeg op.

Een nuttige prompt voor deze overdracht:

Hier zijn het vorige concept en de bewerkte versie die mijn collega
terugstuurde. Vergelijk ze en vertel me, in een korte lijst, wat er
is veranderd en waarom je denkt dat elke wijziging is gemaakt. Ga
daarna door met het opstellen van de volgende sectie op een manier
die consistent is met die wijzigingen, niet met het oorspronkelijke
concept.

[plak het oorspronkelijke concept]
[plak het bewerkte concept]

Zo stapelt het oordeel van het hele team zich op in dezelfde richting in plaats van te resetten elke keer dat het werk van hand wisselt. Het is dezelfde logica als bij één financieel rapport omvormen voor zowel de directie als het team: één onderliggend concept, verfijnd en opnieuw opgemaakt voor verschillende lezers, zonder elke keer opnieuw te beginnen.

Veelvoorkomende valkuilen bij samenwerking en hoe je ze vermijdt

Drie patronen verklaren het grootste deel van de wrijving in team-workflows met Claude. Elk heeft een herkenbaar moment waarop je het kunt opvangen voordat het echte tijd kost.

• De stille overdracht. Je deelt een link naar een Project of gesprek zonder notitie, in de veronderstelling dat de persoon “er gewoon doorheen kijkt”. Let op het moment dat je een link zonder context in Slack wilt plakken. Voeg twee zinnen toe voordat je verstuurt.
• Contextdrift. Persoon A verfijnt de brief, persoon B werkt vanuit een oudere, gecachete versie omdat ze sinds gisteren een tabblad open had. Dat toont zich als twee mensen die tegenstrijdige uitvoer produceren die allebei zelfverzekerd klinkt. De oplossing is het vastgepinde contextdocument de enige bron van waarheid te maken en elke kopie buiten het Project als tijdelijk te behandelen.
• Een Project behandelen als een groepschat. Iemand begint niet-samenhangende vragen in het gedeelde Project te gooien (“trouwens, kun je me helpen met deze andere e-mail?”) en de context verwatert met off-topic threads. Let op een Project dat gesprekken verzamelt zonder duidelijke relatie met het verklaarde doel. Als dat gebeurt, is het tijd om elders een verse chat te beginnen, of een tweede Project.

Geen van deze is een Claude-probleem. Het zijn coördinatieproblemen die toevallig binnen Claude zichtbaar worden. De oplossing is in elk geval dezelfde: maak de context expliciet, houd haar op één plek en zeg hardop wat de volgende stap is in plaats van aan te nemen dat die vanzelfsprekend is.

Lees verder

• Werken met Projects: context die blijft hangen voor een diepere blik op hoe Projects context over sessies heen behouden, de basis waarvan dit hele proces afhangt.
• Een herbruikbare contextbrief maken die je niet meer opnieuw typt als je een formaat voor overdrachtsnotities wilt dat verder werkt dan alleen teamdelen.
• Een campagnedoel omzetten in een brief van één pagina als concreet voorbeeld van het soort samenwerkingsuitvoer dat dit proces is gebouwd om te ondersteunen.