Claude Skills: Anthropic's 32-Pagina Gids Ontcijferd
Ik heb acht maanden lang dezelfde instructies naar Claude geschreven. Elke maandagochtend, dezelfde sprintplanningsprompt. Bij elk klantgesprek, dezelfde sjabloon voor vergadernotities. Bij elke deployment, dezelfde checklist geplakt in het chatvenster als een soort digitale Groundhog Day.
Toen bracht Anthropic een 32-pagina gids uit over iets dat Claude Skills heet — en binnen één middag verwijderde ik elke opgeslagen prompt die ik had.
Niet gearchiveerd. Verwijderd. Want zodra je begrijpt wat Skills eigenlijk zijn, voelt teruggaan naar het kopiëren en plakken van prompts als teruggaan naar het schrijven van brieven nadat je e-mail hebt ontdekt. Het concept is bedrieglijk eenvoudig: je leert Claude eenmaal iets, binnen een map met een markdown-bestand en optionele scripts, en het weet gewoon hoe dat ding te doen vanaf dat moment. Geen heruitleg. Geen "hier is mijn stijlgids opnieuw." Geen "onthoud, we gebruiken Tailwind, niet Bootstrap."
Eén SKILL.md-bestand. Wat YAML bovenaan. Klaar.
Maar — en hier wil ik op ingaan — de gids zelf is zowel briljant als frustrerend. Briljant omdat het raamwerk dat het uiteenzet werkelijk krachtig is. Frustrerend omdat de belangrijkste implementatiedetails begraven zijn onder lagen gepolijst documentatiespeak, en sommige van de hardst bevochten lessen over het daadwerkelijk laten werken van Skills worden terloops vermeld of helemaal niet.
Ik heb drie dagen besteed aan het lezen van de gids, het bouwen van Skills, het breken van Skills en het herbouwen ervan. Wat volgt is alles wat ik had willen weten voordat ik begon — de delen die Anthropic goed heeft gedaan, de delen die ze hebben afgedaan, en de vijf patronen die er echt toe doen zodra je de marketingtaal hebt verwijderd.
Het Concept Dat Alles Laat Klikken
Dit is het mentale model dat Claude Skills eindelijk voor mij begrijpelijk maakte, en het is niet het model waarmee Anthropic begint.
Je kent waarschijnlijk MCP al — het Model Context Protocol dat Claude verbindt met externe gereedschappen zoals Notion, Linear, Figma, GitHub, Slack en vrijwel alles met een API. MCP gaat over toegang. Het geeft Claude de sleutels tot je gereedschappen. De deur openen, naar binnen lopen, rondkijken.
Skills zijn anders. Skills gaan over oordeel.
Denk er zo over na. Je huurt een nieuwe ontwikkelaar en geeft hen beheerderstoegang tot je volledige stack — je projectbeheertool, je CI/CD-pipeline, je ontwerpsysteem, je communicatiekanalen. Ze kunnen technisch alles aanraken. Maar ze kennen de conventies van je team niet. Ze weten niet dat je sprintsnelheidsberekening bugfixes onder twee story points uitsluit. Ze weten niet dat ontwerp-handoffs altijd via een specifieke Figma-naar-Linear workflow gaan met verplichte toegankelijkheidsannotaties. Ze weten niet dat deployment-aankondigingen een bepaald formaat volgen in een bepaald Slack-kanaal.
Toegang zonder oordeel creëert chaos. MCP geeft Claude toegang. Skills geven Claude oordeel.
Dat onderscheid is de hele gids in één zin. Al het andere — de YAML frontmatter, de mapstructuur, de vijf patronen, het debugging-advies — is implementatiedetail dat aan dat kernidee hangt.
Zodra dit voor mij klikte, stopte ik Skills te denken als "mooie prompts" en begon ze te denken als institutionele kennis vastgelegd in code. En die herformulering veranderde hoe ik elke afzonderlijke bouwde.
De praktische vraag is natuurlijk hoe je die kennis werkelijk vastlegt in een formaat dat Claude kan gebruiken. De gids besteedt veel pagina's hieraan, en sommige ervan zijn werkelijk nuttig. Maar er is een snelkoppeling waar niemand je over vertelt, en ik kom er straks op terug nadat we de mechanica hebben doorlopen.
Wat Er Werkelijk In de Map Zit — En Wat Elk Stuk Doet
Een Claude Skill leeft in een map. Minimaal bevat die map één bestand: SKILL.md. Dat is het. Eén markdown-bestand, en je hebt een werkende Skill.
Bovenaan dat markdown-bestand zit YAML frontmatter — het metadatablok tussen drievoudige streepjes dat Claude vertelt wat deze Skill is, wat die doet en cruciaal, wanneer die te activeren. De rest van het bestand bevat de daadwerkelijke instructies: hoe de taak uit te voeren, welke standaarden te volgen, welke gereedschappen te gebruiken en welke valkuilen te vermijden.
Optioneel kun je scripts, referentiedocumenten en sjablonen toevoegen aan de map. Een stijlgids PDF. Een bash-script dat linting uitvoert. Een JSON-schema voor je API-responses. Claude zal deze raadplegen bij het uitvoeren van de Skill.
Hier is een minimaal voorbeeld — een Skill die wekelijkse statusrapporten genereert voor mijn projecten:
---
name: weekly-status-report
description: >
Generates a formatted weekly status report by pulling data
from Linear and GitHub. Trigger when user asks for a status
report, weekly update, or progress summary.
---
## Weekly Status Report Generator
### What This Skill Does
Produces a concise weekly status report covering completed work,
in-progress items, blockers, and next-week priorities.
### Data Sources
1. Pull completed issues from Linear for the current sprint
2. Pull merged PRs from GitHub for the past 7 days
3. Pull open blockers tagged with "blocked" label in Linear
### Report Format
- **Summary** (2-3 sentences, biggest wins and risks)
- **Completed** (bullet list with ticket references)
- **In Progress** (bullet list with percentage estimates)
- **Blockers** (bullet list with owner and age in days)
- **Next Week** (top 3 priorities)
### Style Rules
- No jargon — this goes to stakeholders, not engineers
- Lead each section with the most impactful item
- Blockers must include who owns the resolution
- Keep total length under 500 words
Dat is een complete Skill. Wanneer ik Claude vraag "geef me de statusupdate van deze week," herkent het de trigger uit het beschrijvingsveld, laadt de Skill, maakt verbinding met Linear en GitHub via MCP en produceert een rapport dat mijn exacte formaat en stijlregels volgt.
Geen prompt engineering. Geen onthouden waar ik de sjabloon heb opgeslagen. De kennis leeft in de Skill, en Claude weet wanneer die te pakken.
Maar hier is het deel dat de gids in een zijbalk begraaft dat op pagina één had moeten staan: het beschrijvingsveld in je YAML frontmatter is de belangrijkste regel die je ooit zult schrijven. Krijg dit verkeerd en niets anders telt.
De Twee Regels Die Je Skill Maken of Breken
Ik verloor vier uur hieraan. Vier uur bouwen aan een perfect gedetailleerde Skill die Claude nooit triggerde. De instructies waren duidelijk. Het formaat was precies. De referentiedocumenten waren uitgebreid. En elke keer dat ik Claude vroeg om het ding te doen waarvoor de Skill was ontworpen, gebruikte het gewoon zijn algemene kennis. Negeerde de Skill volledig.
Het probleem was mijn beschrijvingsveld.
Mijn oorspronkelijke beschrijving luidde: "Helpt bij code review processen." Zes woorden. Vaag. Passief. Claude had geen idee wanneer die te activeren omdat "helpt bij code review processen" letterlijk van alles kan betekenen.
Ik herschreef het: "Voert gestructureerde code review uit op pull requests. Trigger wanneer gebruiker een PR-link deelt, om code review vraagt, om een PR-review verzoekt of een diff plakt. Controleert op beveiligingslekken, prestatieproblemen, naamgevingsconventies per teamstandaarden en hiaten in testdekking."
Werkte onmiddellijk. Elke keer.
Het patroon dat ik ontdekte door vallen en opstaan — en de gids hints hierop maar stelt het niet duidelijk genoeg — is dat je beschrijving drie dingen nodig heeft:
1. Wat het doet (actief werkwoord, specifieke output): "Genereert wekelijkse rapporten" niet "Helpt bij rapportage."
2. Wanneer te triggeren (expliciete trigger-zinnen): "Trigger wanneer gebruiker om X, Y of Z vraagt." Maak een lijst van de werkelijke woorden en zinnen die een mens zou gebruiken. Wees niet slim. Wees letterlijk.
3. Wat het dekt (scopegrenzen): "Controleert op A, B, C en D." Dit vertelt Claude wat binnen het domein van de Skill valt en, impliciet, wat niet.
Het naamveld telt ook — gebruik kebab-case, geen spaties, en maak het beschrijvend. weekly-status-report verslaat report-v2 verslaat wsr. Claude gebruikt de naam als aanvullend signaal voor matching, dus beschrijvende namen verbeteren de triggernauwkeurigheid.
Ik ging terug en herschreef de beschrijvingen voor alle zeven Skills die ik had gebouwd. Zes ervan begonnen onmiddellijk correct te triggeren. De zevende had nog een ronde verfijning nodig — het bleek dat mijn triggerzinnen overlapten met een andere Skill, en Claude raakte in de war over welke te laden.
Drie Gebruiksscenario's — En de Eén die Anthropic Onderschat
De gids verdeelt Claude Skills in drie kerntoepassingen. Elk lost een werkelijk ander probleem op, en ze met elkaar verwarren is een fout die ik vroeg maakte.
Gebruiksscenario 1: Documentcreatie
Dit is de meest eenvoudige toepassing. Je hebt een specifiek type document — een presentatie, een technische specificatie, een klantvoorstel, een ontwerpbriefing — dat elke keer consistente standaarden moet volgen. Lettertypen, structuur, toon, vereiste secties, verboden zinnen. In plaats van een stijlgids in elk gesprek te plakken, codeer je het eenmaal in een Skill.
Ik bouwde er een voor klantvoorstellen die onze prijslagen, standaard scopetaal, vereiste juridische disclaimers en opmaakregels bevat. Wat me vroeger 20 minuten prompt-crafting per voorstel kostte, duurt nu één zin: "Schrijf een voorstel voor [klant] over [scope]." De Skill regelt al het andere.
Gebruiksscenario 2: Workflow-automatisering
Dit is waar Skills serieuze tijd terugverdienen. Meerstaps processen die elke keer op dezelfde manier moeten plaatsvinden — sprintplanning, deployment-checklists, onboarding-sequenties, procedures voor incident-respons.
Mijn sprintplanning Skill is de ene waar ik het meest trots op ben. Die maakt verbinding met Linear om de huidige projectstatus op te halen, analyseert onze snelheid over de afgelopen drie sprints, identificeert carry-over items die blijven glippen, suggereert prioriteiten op basis van deadline-nabijheid en afhankelijkheidsketens, en maakt de eigenlijke sprint-tickets met geschatte punten. Een proces dat vroeger 90 minuten van mijn maandagochtend in beslag nam, vindt nu plaats in ongeveer vier minuten, waarbij ik de output reviewt en goedkeurt in plaats van die vanaf nul te genereren.
De belangrijkste les voor workflow Skills: je moet expliciet zijn over de volgorde van bewerkingen en de beslissingslogica bij elke stap. "Analyseer snelheid" is te vaag. "Bereken gemiddelde story points voltooid per sprint over de laatste 3 sprints, exclusief sprints korter dan 8 dagen. Als de snelheid gedurende 2+ opeenvolgende sprints daalt, markeer dit in de planningsoutput met het percentagedalingen" — dat is wat Claude nodig heeft.
Gebruiksscenario 3: MCP-verbetering
Dit is het gebruiksscenario waar Anthropic het meest enthousiast over is, en eerlijk gezegd, het ene waarvan ik denk dat ze het potentieel onderschatten. MCP-verbetering betekent domeinexpertise laag leggen bovenop gereedschapstoegang. Je Skill gebruikt Figma niet alleen — die kent je ontwerpsysteem, je componentnaamgevingsconventies, je toegankelijkheidseisen en de specifieke workflow voor het overhandigen van ontwerpen aan engineering.
Ik bouwde een ontwerp-naar-ontwikkeling overdrachts-Skill die de nieuwste ontwerpen van Figma ophaalt, componentspecificaties extraheert, die koppelt aan onze bestaande React-componentenbibliotheek, hiaten identificeert waar nieuwe componenten nodig zijn, Linear-tickets maakt voor het engineeringswerk met acceptatiecriteria afgeleid van de ontwerpspecificaties, en een samenvatting plaatst in ons Slack-ontwikkelingskanaal.
Zes verschillende gereedschappen. Eén Skill. Eén triggerphrase: "Verwerk de nieuwe ontwerpen."
Hier is wat Anthropic onderschat over dit gebruiksscenario: de samengestelde waarde. Elke keer dat een domeinexpert in je team de output van de Skill reviewt en zegt "eigenlijk moeten we ook X controleren voor de overdracht," voeg je die controle toe aan het SKILL.md-bestand. In de loop van weken en maanden accumuleert de Skill institutionele kennis die anders alleen in de hoofden van mensen zou leven. Het wordt een levend document van hoe je team werkelijk werkt — niet hoe de gereedschappen zijn ontworpen om te werken, maar hoe jouw mensen die gereedschappen gebruiken in jouw specifieke context.
Dat is geen automatisering. Dat is organisatiegeheugen met uitvoeringsmogelijkheid. En ik denk niet dat de meeste teams hebben begrepen hoe krachtig dat is.
Vijf Patronen Die 90% Van Echte Skills Dekken
De gids presenteert vijf "bewezen patronen" voor het structureren van Skills. Na het bouwen van elf Skills over drie projecten, zou ik zeggen dat deze patronen echt zijn — het zijn geen marketingcategorieën. Elk lost een structureel ander probleem op, en een Skill in het verkeerde patroon dwingen creëert subtiele bugs die moeilijk te diagnosticeren zijn.
Patroon 1: Sequentiële Workflow
Stappen vinden plaats in een vaste volgorde. Stap 2 is afhankelijk van de output van stap 1. Stap 3 is afhankelijk van stap 2. Geen vertakkingen, geen conditionelen — gewoon een betrouwbare pipeline.
Het beste voor: deployment-procedures, compliance-checklists, onboarding-sequenties, datamigratieoplossingen.
Patroon 2: Multi-MCP Coördinatie
De workflow omspant meerdere externe diensten. Figma naar Linear naar Slack. GitHub naar Jira naar Confluence. De Skill orkestreert gegevensstroom tussen gereedschappen die niet van nature met elkaar praten.
Het beste voor: cross-tool workflows, ontwerp-handoffs, release-beheer, cross-team meldingen.
Mijn grootste les hier: voeg expliciete gegevenstransformatie-instructies toe tussen gereedschapsaanroepen. Het formaat waarin Figma componentspecificaties exporteert, is niet het formaat dat Linear accepteert voor ticketbeschrijvingen. Je Skill moet specificeren hoe gegevens precies te hervormen terwijl die tussen gereedschappen beweegt.
Patroon 3: Iteratieve Verfijning
Genereer output, valideer die tegen criteria, verbeter die, valideer opnieuw. De Skill bevat zijn eigen kwaliteitslus in plaats van een enkelvoudig-pass resultaat te produceren.
Het beste voor: rapportgeneratie, contentcreatie, code review waarbij je uitgebreide dekking wilt, elke output die profiteert van zelfkritiek.
Patroon 4: Context-bewuste Selectie
Zelfde doel, verschillende uitvoeringspaden op basis van context. Upload een PNG en het gebruikt één workflow. Upload een SVG en het gebruikt een andere. Klein bestand wordt inline verwerkt; groot bestand wordt in stukken geknipt.
Het beste voor: bestandsverwerking, contentgeneratie over verschillende formaten, deployment-scripts die variëren per omgeving.
Patroon 5: Domein-intelligentie
De Skill belichaamt diepe expertise in een specifiek domein — financiële compliance-regels, beveiligingsprotocollen, medische coderingsstandaarden, juridische reviewcriteria. De waarde zit niet in de workflow; die zit in de kennis zelf.
Het beste voor: compliance-controle, beveiligingsaudits, gespecialiseerde reviewprocessen, elke taak waarbij "de regels kennen" het moeilijke deel is.
Dit is het patroon waarbij referentiedocumenten in je Skill-map hun waarde verdienen. Een SKILL.md-bestand dat verwijst naar een 50-pagina beveiligings-compliance-checklist kan Claude tot een werkelijk nuttige eerste-pass auditor maken. Geen vervanging voor menselijke expertise — maar een onvermoeibare eerste reviewer die nooit vergeet item 47 op pagina 12 te controleren.
Vier Fouten Die Ik Maakte Zodat Jij Dat Niet Hoeft
Fout 1: Vage beschrijvingen die nooit triggeren.
Dit al behandeld, maar het verdient herhaling want het is de meest voorkomende mislukking. Als je Skill nooit activeert, is de beschrijving bijna altijd het probleem. Schrijf triggerzinnen die overeenkomen met de exacte woorden die een mens zou gebruiken. "Voer mijn deployment-checklist uit" niet "assisteer bij deployment-processen."
Fout 2: Instructies begraven in muren van tekst.
Mijn eerste paar Skills waren romans. Pagina's context, achtergrondinformatie, randgevallen, filosofie over waarom we dingen op een bepaalde manier doen. Claude zou ze verwerken, maar de signaal-ruis verhouding was verschrikkelijk. Belangrijke instructies werden verdund door verklarende tekst.
Wat beter werkt: zet de kritieke instructies vooraan. Doe de niet-onderhandelbare regels in de eerste 20 regels. Gebruik kopteksten agressief. Bewaar achtergrondcontext voor een apart referentiedocument in de map dat Claude kan raadplegen wanneer nodig maar niet bij elke aanroep hoeft te verwerken.
Fout 3: Ontbrekende foutafhandeling voor MCP-aanroepen.
Dit beet me hard. Mijn sprintplanning Skill werkte prachtig — totdat de Linear API op een maandagochtend een rate limit-fout retourneerde, en de Skill gewoon... stopte. Geen fallback. Geen retry. Geen graceful degradation. Gewoon een verwarde Claude die zei dat het het verzoek niet kon voltooien.
Je Skill moet gereedschapsfouten anticiperen. Voeg expliciete instructies toe: "Als de Linear API-aanroep mislukt, wacht 10 seconden en probeer eenmaal opnieuw. Als die opnieuw mislukt, ga dan door met gecachte gegevens van de laatste succesvolle run en merk op dat gegevens verouderd kunnen zijn."
Fout 4: Te veel proberen in één Skill.
Ik bouwde een Skill genaamd "project-manager" die sprintplanning, statusrapporten, retrospectief-generatie, backlog-grooming en stakeholder-updates probeerde te verwerken. Het waren 400 regels instructies die vijf afzonderlijke workflows dekte.
Het was verschrikkelijk. Claude zou de juiste Skill activeren maar de verkeerde workflow erin volgen. Triggerzinnen voor verschillende subtaken overlapten. De instructies voor sprintplanning spraken sommige conventies die werden gebruikt in retrospectief-generatie tegen.
Ik splitste het in vijf afzonderlijke Skills. Elk werd eenvoudiger, betrouwbaarder en gemakkelijker te onderhouden. De overhead van vijf mappen in plaats van één is verwaarloosbaar. De verbetering in nauwkeurigheid en consistentie was dramatisch.
Het onderliggende principe: één Skill, één taak. Als je "ook" of "bovendien" schrijft in je SKILL.md, heb je misschien een tweede Skill nodig.
Het Inzicht Dat Verandert Hoe Je Denkt Over AI op het Werk
De gids eindigt met een gedachte die ik bijna heb overgeslagen, maar het is eigenlijk het belangrijkste idee in alle 32 pagina's.
De meeste mensen gebruiken AI als een allesomvattende assistent. Elk gesprek begint vanaf nul. Je legt je context, je voorkeuren, je standaarden, je gereedschappen, je workflows uit — en dan krijg je een respons gevormd door al die uitleg. Morgen doe je het opnieuw. En opnieuw. En opnieuw.
Claude Skills draaien dit model om. In plaats van de context in elk gesprek naar de AI te brengen, embed je de context permanent binnen de omgeving van de AI. De AI begint elk relevant gesprek al kennende je standaarden, al verbonden met je gereedschappen, al je workflows begrijpende.
Dit is geen productiviteitshack. Het is een architecturele verschuiving in hoe mensen en AI samenwerken.
Wanneer ik kijk naar de elf Skills die ik de afgelopen drie dagen heb gebouwd, kijk ik naar een gecomprimeerde versie van hoe mijn team werkt. Onze code review-standaarden. Ons deployment-proces. Onze klantcommunicatiestijl. Onze sprintplanneringsmethodologie. Onze ontwerp-handoff workflow. Allemaal gecodeerd, uitvoerbaar en verbeterend elke keer dat iemand in het team een regel toevoegt aan een SKILL.md-bestand.
De organisaties die dit vroeg uitzoeken — die beginnen Skills-bibliotheken te bouwen die hun best practices en institutionele kennis vastleggen — gaan een samengesteld voordeel hebben dat elke maand groeit. Niet omdat de AI slimmer is. Omdat de AI hen beter kent.
Ik begon dit bericht met het praten over het verwijderen van mijn opgeslagen prompts. Dat was het symptoom. De echte verandering is dieper. Ik ben gestopt met Claude te zien als een gereedschap dat ik instrueer en begon het te zien als een teamlid dat ik onboard. De Skills-map is het onboarding-handboek. En net als het onboarden van een mens, betaalt de initiële investering van het schrijven van duidelijke instructies zich terug elke dag dat die persoon — of die Skill — opduikt en het werk doet zonder twee keer te worden verteld.
Anthropic bouwde het raamwerk. De 32 pagina's leggen de mechanica uit. Maar de waarde zit niet in het raamwerk — die zit in wat je erin stopt.
Dus hier is mijn vraag: wat is de ene workflow die je elke week herhaalt die je Claude eenmaal zou kunnen leren en nooit meer hoeft uit te leggen? Begin daar. Eén map. Eén SKILL.md. Eén beschrijving die werkelijk triggert.
Alles else bouwt voort op die eerste Skill die werkt.
🤝 Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je tech-infrastructuur schalen? Ik help je graag.
- 🔗 Fiverr (custom builds & integraties): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (zakelijke oplossingen): ramlit.com
- 🎨 ColorPark (design & branding): colorpark.io
- 🛡 xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
