Er zit een moment in de invoering van AI waar de meeste bedrijven overheen kijken. Niet het moment waarop iemand ChatGPT opent, want daar is inmiddels wel over nagedacht. Het moment waarop een medewerker een skill installeert die hij ergens tegenkwam.
Dat lijkt onschuldig. Het is een mapje met instructies, meer niet. Alleen mag dat mapje scripts meebrengen, en die draaien met de rechten van degene die ze installeerde.
Beginner-tip:Ken je skills nog niet, lees dan eerstClaude Skills uitgelegd. Dit stuk gaat ervan uit dat je weet wat ze zijn en kijkt naar wat je erover moet afspreken.
Waarom dit anders ligt dan een gewone app
Bij een app die je installeert, weet je ongeveer wat je krijgt: een leverancier, een privacyverklaring, misschien een verwerkersovereenkomst. Bij een skill van GitHub heb je vaak niets van dat alles. Je hebt een map van een onbekende met instructies erin, en eventueel scripts.
Twee waarschuwingen die opvallen omdat ze van partijen komen die zelf skills promoten. Firecrawl adviseert om elk meegeleverd script te lezen vóór installatie, met name op ongedocumenteerde netwerkverzoeken — code die stilletjes iets verstuurt. Composio verwijst naar onderzoek van Datadog Security Labs naar kwaadaardige skills als risico in de toeleveringsketen, en stelt er droog bij dat de meeste skills sowieso niets toevoegen.
Zelfs bij de officiële voorbeelden is voorzichtigheid ingebouwd. Anthropic zet boven de eigen skills-repo: deze zijn bedoeld voor demonstratie en educatie, test ze in je eigen omgeving voordat je erop leunt bij kritieke taken.
De map die bepaalt hoe ver het komt
Dit is het technische detail dat je als ondernemer moet kennen, en het enige.
Skills staan op twee plekken:
- De persoonlijke map van een medewerker. Geldt voor al zijn projecten, blijft bij hem. Eén persoon, één machine.
- De projectmap binnen de repository. Die gaat mee in versiebeheer. Wie het project binnenhaalt, krijgt de skills erbij — automatisch, zonder er iets voor te doen.
Die tweede is waar je afspraken over wilt maken. Eén medewerker die iets in de projectmap zet, verspreidt het over iedereen die aan dat project werkt. Dat is meteen het goede nieuws: het is ook het punt waar je één keer kunt kijken en het voor het hele team goed hebt staan.
De vier afspraken
Geen beleidsstuk. Een half A4, en je bent er.
1. Wie mag een skill van buiten installeren? Bij een klein team: iedereen, mits gemeld. Bij een groter team: één of twee mensen die het beoordelen. Belangrijk is dat er een naam bij hoort, zodat “ik dacht dat het mocht” geen antwoord meer is.
2. Uit welke bronnen?
Houd het kort. De officiële marketplace van Claude Code, plus een eigen lijstje van maximaal een handvol vertrouwde bronnen. Alles daarbuiten gaat langs de persoon uit punt 1. Wat wij als vertrouwde basis zouden nemen: anthropics/skills van Anthropic zelf en obra/superpowers, allebei open, allebei met een leesbare geschiedenis en allebei in de officiële marketplace.
3. Wie leest de scripts? Alleen nodig als een skill scripts meebrengt — veel skills zijn puur tekst en dan valt dit weg. Brengt hij wel code mee, dan leest iemand die vóórdat het in de projectmap belandt. Let vooral op verbindingen naar buiten die niet in de beschrijving staan.
4. Geen sleutels in een SKILL.md. Wachtwoorden, API-sleutels en tokens horen niet in een skill-bestand, want dat gaat mee in versiebeheer. Staat er ooit iets in, dan staat het er ook nog na het verwijderen — in de geschiedenis. Een sleutel die per ongeluk in een repository belandde, moet je vervangen, niet weghalen.
Gevorderden:Draait er een MCP-koppeling naast, zet dan de rechten van het configuratiebestand goed. Composio adviseert
chmod 600op het bestand waar de sleutel in staat, zodat alleen de eigenaar het kan lezen. Verder: least-privilege bij de tokens die je uitgeeft, en een menselijke goedkeuring bij alles wat onomkeerbaar is.
Waar de winst zit
Tot nu toe ging dit over risico’s, en dat geeft een scheef beeld. De echte opbrengst van skills voor een MKB-bedrijf zit niet in downloaden maar in zelf schrijven.
Elke onderneming heeft werkwijzen die in iemands hoofd zitten. Hoe je een offerte opbouwt, welke controles er op een factuur horen, hoe een klantmail eruitziet als het misging. Dat is precies het soort kennis dat je één keer vastlegt en daarna herhaalbaar inzet. Een zelfgeschreven skill brengt bovendien geen vreemde code mee, dus alle bovenstaande vragen vervallen.
Hoe je dat aanpakt, staat in onze gids Werkwijze van je beste medewerker vastleggen in een AI-skill.
Wat er misgaat als je niets regelt
Twee scenario’s, allebei zonder kwaadwillende medewerker.
Iemand installeert een skill die goed werkt, zet hem in de projectmap omdat collega’s er ook wat aan hebben, en het script erin stuurt bij elke run een fragment code naar een server voor “telemetrie”. Dat staat niet in de beschrijving. Zit er klantinformatie in die code, dan heb je een datalek, en dan ben jij verwerkingsverantwoordelijke — niet de onbekende die de skill schreef. Bij risico voor betrokkenen heb je 72 uur om het te melden bij de Autoriteit Persoonsgegevens.
Het tweede is saaier en komt vaker voor. Iedereen installeert wat, niemand ruimt op, en na een half jaar draaien er vijftien skills waarvan er drie elkaar tegenspreken. Claude pakt dan de verkeerde erbij en niemand weet meer waarom de uitkomst veranderde. Een halfjaarlijkse opruimronde lost dat op: welke gebruiken we nog, en waarom.
Deze week
Drie dingen, in een uur te doen:
- Vraag rond wie er al skills gebruikt. Het antwoord is bijna altijd “meer mensen dan je dacht”, en je hebt het nodig voordat je iets afspreekt.
- Kijk in de projectmappen van je lopende projecten. Staat daar een skills-map, dan is die er al voor iedereen. Lees wat erin zit.
- Schrijf de vier punten hierboven op en deel ze. Niet als beleid, als afspraak.
Waarom de lijstjes met “beste skills” je hierbij weinig helpen — en hoe de cijfers erin uiteenlopen — zetten we uiteen op hetlaatsteainieuws.nl. De praktische installatiekant staat op debesteaitools.nl.