Claude skills uitrollen team: dat is een beheervraag, geen installatievraag. Regel vier dingen voordat de eerste skill in gebruik gaat: wie de eigenaar is, wie hem heeft gelezen voordat hij draaide, op welke versie de productie vast staat, en hoeveel skills tegelijk aanstaan. Het uitdelen zelf regelt het product niet voor je.
Dit is voor een operations-rol die een werkwijze bij meerdere mensen wil laten landen, niet voor iemand die zijn eerste skill schrijft. Een skill is een map met een SKILL.md waarin staat hoe Claude een terugkerende taak aanpakt; de officiële productnaam is Agent Skills en in lopende tekst heet het een skill. Hoe dat werkt, met laadniveaus en per surface, staat in claude skills voor bedrijven. Hier gaat het over het beheer eromheen.
Eén woordafspraak, want dit artikel heeft ze beide nodig: een skill is hier altijd het bestand, en wat een mens kan heet een vaardigheid. Welke vaardigheid bij welke rol hoort, is een andere vraag dan deze.
Wie beheert de skills van een team?
Eén benoemde persoon of één team per skill, vastgelegd op papier. De documentatie vraagt per skill een intern register, en “wie hem beheert” is daar een van de vijf velden: het team of de persoon die verantwoordelijk is voor onderhoud [S-081].
Dat veld doet meer werk dan het lijkt. De levenscyclus van een skill loopt in zes stappen: plannen, maken en reviewen, testen in isolatie en naast de bestaande skills, uitrollen met vastlegging in dat register, monitoren, en dan een nieuwe versie of afvoeren [S-078]. Zonder skill-eigenaar gebeuren stap vijf en zes nooit: een skill die niemand toebehoort wordt niet opnieuw geëvalueerd en ook niet afgevoerd.
Dezelfde logica als bij een draaiende automatisering, waar de vraag wie eigenaar is na de oplevering terugkomt. Die staat uitgewerkt in automatisering beheren na oplevering.
Wie reviewt een skill voordat hij in gebruik gaat?
Iemand anders dan de auteur. De documentatie maakt dat expliciet: skill-auteurs horen niet hun eigen reviewer te zijn, en vóór goedkeuring horen zowel een veiligheidsreview als een evaluatieset verplicht te zijn [S-073].
Waar die reviewer op let, staat als risicotabel in de documentatie: zeven indicatoren met het gewicht dat de bron eraan hangt.
| Indicator | Waar je op let | Hoe zwaar |
|---|---|---|
Scripts in de skill-map (*.py, *.sh, *.js) | draaien met volledige toegang tot de omgeving | hoog |
| Instructies die veiligheidsregels omzeilen | de skill praat bestaande regels weg | hoog |
| Verwijzingen naar MCP-tools | breidt toegang uit buiten de skill zelf | hoog |
| Netwerkpatronen: URL’s, fetch, curl, requests | mogelijke route naar buiten | hoog |
| Hardgecodeerde credentials | inloggegevens in het bestand | hoog |
| Bestandspaden buiten de skill-map | raakt iets wat niet van de skill is | midden |
| Instructies om bash of bestandsoperaties aan te roepen | uitvoering op de computer zelf | midden |
Deze zeven staan in de risicotabel bij het beoordelen van één skill [S-071]. Een skill met scripts erin is niet verboden, hij vraagt een zwaardere review dan een skill die alleen tekst bevat.
De volledige checklist is acht stappen lang [S-072]. Ingekort tot wat een mkb-team echt uitvoert:
- Lees alle bestanden in de map, niet alleen
SKILL.md. Scripts en bijlagen horen erbij. - Draai de scripts afgeschermd en vergelijk de uitkomst met het gestelde doel van de skill.
- Controleer op hardgecodeerde credentials en op netwerkaanroepen die er niet bij horen.
- Kijk waar externe URL’s naartoe wijzen en welke tools en commando’s de skill aanroept.
Dat is ook de reden dat “even downloaden en proberen” geen review is. Een skill uit een onbetrouwbare bron hoort nooit zonder volledige audit uitgerold te worden; de norm is dezelfde zorgvuldigheid als bij het installeren van software op productiesystemen [S-074].
En in een team van drie? Dan blijft de functiescheiding haalbaar: iemand anders dan de maker leest hem, al is dat de founder. Een review voor gebruik is een vaardigheid die te leren is, en dat hoort in een training of workshop.
Welke versie staat vast in productie?
Een genoemde versie, altijd. Laat je het versieveld weg, dan gebruikt het verzoek de laatste versie, zodat een nieuwe upload door wie dan ook in de workspace onmiddellijk verandert wat de productie-agents uitvoeren [S-082].
Dat is de reden om de versie vast te zetten: anders beweegt de productie mee met de laatste upload van iemand die niet wist dat er iets van afhing.
De documentatie zet er drie afspraken bij [S-082]:
- Elke update is een nieuwe uitrol en vraagt een volledige veiligheidsreview.
- De vorige versie blijft staan als terugvaloptie.
- Integriteit controleer je met checksums van de gereviewde skill en met ondertekende commits in je skill-repository.
Hoeveel skills kunnen er tegelijk aanstaan?
Technisch maximaal twintig per verzoek via de API, praktisch veel minder. De naam en de beschrijving van elke skill concurreren om aandacht in de systeemprompt: bij te veel actieve skills kiest Claude de verkeerde of mist hij een relevante helemaal [S-079].
Het aantal actieve skills is een ontwerpkeuze, geen limiet waar je tegenaan loopt. Vraagt een rol er meer dan twintig, dan adviseert de documentatie smalle skills samen te voegen of verzoeken per taaksoort naar verschillende sets te routeren [S-079].
Beginnen doe je smal: skills die op één werkproces gericht zijn in plaats van brede met meerdere doelen, en samenvoegen tot een rolgebonden bundel pas als de evaluaties van de samengevoegde skill dezelfde prestatie laten zien als de losse skills die hij vervangt. Het voorbeeld uit de documentatie is de stap van formatting-sales-reports, querying-pipeline-data en updating-crm-records naar één sales-operations [S-080].
Wat test je voordat een skill live gaat?
Vijf dimensies, met per dimensie het voorbeeldfout uit de documentatie [S-076]:
- Triggernauwkeurigheid. Een skill die aanslaat bij elke vermelding van een spreadsheet, ook als de gebruiker alleen over data wil praten.
- Werking op zichzelf. Een skill die verwijst naar bestanden die niet in zijn eigen map staan.
- Samenleven met andere skills. Een nieuwe skill met een te brede beschrijving pakt de trigger van een bestaande skill af.
- Het volgen van de instructies. Claude slaat validatiestappen over of gebruikt de verkeerde bibliotheken.
- De kwaliteit van de uitvoer. Gegenereerde rapporten met opmaakfouten of ontbrekende data.
Daar hoort een harde eis bij. Skill-auteurs leveren een evaluatieset van drie tot vijf representatieve vragen per skill, die zowel de gevallen dekt waarin de skill hoort te starten als de gevallen waarin hij juist níet hoort te starten, plus de twijfelgevallen; testen gebeurt op elk model dat de organisatie gebruikt, omdat het effect van een skill per model verschilt [S-077].
Dat middelste deel wordt in de praktijk overgeslagen. Iedereen test of de skill werkt als je hem nodig hebt; bijna niemand test of hij zich stil houdt als je hem niet nodig hebt. Dat tweede is waar collega’s op afknappen.
Hoe deel je een skill met je team, en wat regelt het product niet?
Via je eigen repository. Het uitdelen van eigen skills is niet iets wat het product voor je doet, en dat is geen detail in de uitrol maar de uitrol zelf. Vijf grenzen, zoals ze op 11 oktober 2026 in de documentatie staan:
- Eigen skills synchroniseren niet tussen de surfaces. Een skill die in claude.ai is geüpload moet apart naar de API, en skills in Claude Code staan op het bestandssysteem en los van beide [S-059]. Surface is het woord van de documentatie voor claude.ai, de Claude API en Claude Code.
- Wie meerdere surfaces gebruikt, richt zelf een synchronisatieproces in. De bron noemt Git de enige bron van waarheid voor de bestanden van een skill [S-083].
- In claude.ai is een eigen skill van de individuele gebruiker. Elk teamlid uploadt hem apart, en er is geen centraal beheer door een beheerder en geen organisatiebrede distributie van eigen skills [S-060]. Op de Claude API is hij wel workspace-breed beschikbaar voor alle workspace-leden [S-060]; distributie via de Skills API is dus workspace-breed [S-083].
- Gebruiksstatistieken zijn nu niet via de Skills API beschikbaar. Wil je weten welke skills in welk verzoek meegingen, dan heb je logging op applicatieniveau nodig [S-078].
- Automatische veiligheidsscanning bestaat alleen voor een deel van de surfaces. Claude Enterprise-organisaties kunnen die aanzetten in claude.ai en Claude Cowork; een skill die de scan niet haalt of nog niet gescand is wordt geblokkeerd, een skill die met een waarschuwing doorkomt blijft bruikbaar achter die waarschuwing. De scanning geldt niet voor de Claude API en is volgens de documentatie een aanvulling op en geen vervanging van de review-checklist [S-075].
Beide bronpagina’s zijn op 11 oktober 2026 gecontroleerd. Wat hier staat is wat de documentatie op die dag zegt, niet wat er misschien aan komt. Controleer die datum voordat je er een afspraak op bouwt.
De werkbare uitkomst van die vijf: zet de skills in Git, laat ze langs een pull request lopen, en beschouw elke plek waar ze daarna terechtkomen als een kopie. Teams die al met Claude Code voor bedrijven werken zijn hier het snelst, want daar staat de skill-map al in de repository van het project.
Hoe ziet een skill-register eruit?
Vijf velden per skill, en de documentatie schrijft ze voor: waarvoor de skill is, wie hem beheert, welke versie nu uitstaat, waarvan hij afhankelijk is en wanneer hij voor het laatst geëvalueerd is met welke uitslag [S-081].
Dat past in een tabel in het document waar je toch al werkt. Eén voorbeeldregel:
| Veld | Wat erin staat | Voorbeeldregel |
|---|---|---|
| Waarvoor | welk werkproces de skill ondersteunt | wekelijkse omzetrapportage opmaken |
| Wie beheert | team of persoon, verantwoordelijk voor onderhoud | operations, rol van de teamlead |
| Welke versie | de versie die nu in productie vast staat | 3, vastgezet in het verzoek |
| Waarvan afhankelijk | MCP-servers, pakketten, externe diensten | MCP-server van het CRM, alleen leesrechten |
| Laatst geëvalueerd | datum plus uitslag | 30-09-2026, vijf testvragen, alle vijf goed |
Geen formulier en geen tool nodig. Het punt is dat de vier vragen uit dit artikel per skill een antwoord op papier krijgen, zodat de vijfde vraag, wie dit over drie maanden nog weet, zich niet stelt. Wie zelf skills laat bouwen, laat dit register meteen meeleveren; dat hoort bij een eigen AI-tool net zo goed als de code.
Hoe WeAdapt het zelf doet
De studio’s waarmee WeAdapt werkt, draaien zelf op skills in Git. De vier afspraken uit dit artikel liggen daar vast in bestanden, niet in iemands hoofd:
- Elke skill is een map in een repository, dus elke wijziging heeft een auteur, een datum en een pull request.
- Eén eigenaar per skill. Die beslist of een voorstel erin gaat.
- Een skill gaat pas in gebruik nadat iemand anders dan de maker hem heeft gelezen.
- De versie die draait, staat vast; een nieuwe versie is een nieuwe uitrol.
Dat is dezelfde keuze die de documentatie adviseert: skill-mappen in Git voor geschiedenis, review via pull requests en de mogelijkheid om terug te draaien [S-083]. Het nut zit erin dat “wie heeft dit veranderd en waarom” één commando is.
Veelgestelde vragen
Wie keurt een skill goed in een klein team? Iemand anders dan de auteur. De documentatie eist functiescheiding: skill-auteurs horen niet hun eigen reviewer te zijn, en vóór goedkeuring horen een veiligheidsreview en een evaluatieset verplicht te zijn [S-073]. In een team van drie is dat de founder die het bestand leest.
Moet elk teamlid de skill zelf uploaden? In claude.ai wel: een eigen skill is daar van de individuele gebruiker en een beheerder kan dat niet centraal regelen [S-060]. Op de Claude API is een skill workspace-breed beschikbaar voor alle workspace-leden [S-060]. In Claude Code loopt het via de map in het project.
Wat gebeurt er als iemand een nieuwe versie uploadt? Zonder versieveld verandert de productie meteen mee: het verzoek gebruikt dan de laatste versie, dus een upload door wie dan ook in de workspace wijzigt onmiddellijk wat de productie-agents uitvoeren [S-082]. Noem daarom een versie en behandel elke update als een nieuwe uitrol.
Hoeveel skills is te veel? Een API-verzoek ondersteunt maximaal twintig skills [S-079]. Het praktische plafond ligt lager, want naam en beschrijving concurreren om aandacht in de systeemprompt en bij te veel actieve skills kiest Claude de verkeerde of mist hij een relevante [S-079].
Wil je de vier afspraken voor jullie eigen skills op papier hebben voordat de eerste in gebruik gaat? Plan een gesprek. Wat WeAdapt oplevert en hoe je team het daarna zelf beheert, staat in de veelgestelde vragen.