Claude Skills en SKILL.md voor ontwikkelaars: VS Code, JetBrains, Cursor

De meeste teams misbruiken Claude Skills op één van de twee manieren. Ze maken van SKILL.md ofwel een stortbak, of ze stappen nooit over naar het gebruik van grote, gekopieerde en geplakte prompts.

Beide aanpakken zijn slordig. Als je wilt dat Skills werken in een echte ontwikkelworkflow, moet je ze behandelen als code en operationele logica, niet als prompt-poëzie.

Claude Skills zijn mappen die worden verankerd door SKILL.md, met optionele scripts, referenties en assets. Ze werken vanwege progressieve openbaarmaking. De agent start met het laden van alleen compacte metadata, zoals de skill-naam en beschrijving, en leest de volledige instructies pas wanneer de taak overeenkomt. Dit stelt een agent in staat om veel skills beschikbaar te houden zonder elke sessie vanaf het begin op te blazen.

De eigen richtlijnen van Anthropic maken de beoogde taakverdeling vrij duidelijk. CLAUDE.md is bedoeld voor duurzaam, altijd-actief projectcontext. Skills zijn bedoeld voor herbruikbare kennis, playbook’s en aanroepbare workflows die op verzoek moeten worden geladen. Claude Code heeft zelfs oude aangepaste commands in dezelfde mechanisme opgenomen, zodat legacy .claude/commands/*.md-bestanden nog steeds werken, maar Skills zijn nu de betere langetermijnstructuur — en het meest herbruikbare bouwblock in elke AI-aangedreven ontwikkelworkflow.

Wanneer Claude Skills gebruiken: CLAUDE.md versus Skills versus Hooks

Het is de moeite waard om een Claude Skill te maken als je steeds dezelfde checklist, hetzelfde deploy-playbook, dezelfde code-review-rubriek of dezelfde interne API-valkuilen in de chat plakt. Anthropic adviseert expliciet een skill te maken als je eenzelfde procedure voortdurend hergebruikt, of als een sectie in CLAUDE.md is uitgegroeid tot een proces in plaats van een feit. Dat is het praktische antwoord op de veelgestelde vraag: “Wat is een Claude Skill en wanneer moet je er een gebruiken?”. Gebruik een Skill voor herhaalbare procedures, niet voor algemene smaak of brede repo-regels.

De echte winst is controle over contextkosten en gedrag. Een goede Skill wordt alleen geladen wanneer relevant, terwijl een opgeblazen CLAUDE.md in elke sessie wordt geladen. Anthropic adviseert CLAUDE.md kort te houden en domeinkennis of procedures naar Skills te verplaatsen, precies omdat laden op verzoek de agent gefocust houdt op de taak waarvoor hij wordt gebruikt.

Mijn eigen mening is simpel. Als de instructie in elke sessie van toepassing zou moeten zijn, hoort het in CLAUDE.md. Als de instructie een herbruikbare methode, checklist of workflow is die alleen soms relevant is, hoort het in een Skill. Als de actie automatisch moet plaatsvinden bij elk overeenkomend evenement, hoort het waarschijnlijk in een hook, niet in een Skill. De functieoverzicht van Anthropic plaatst deze tools in vrijwel exact hetzelfde gelaagde model.

Een praktische indicator voor elk: als je merkt dat je dezelfde instructies in elke chat plakt, is dat een Skill. Als een sectie in CLAUDE.md is uitgegroeid tot een stap-voor-stap proces, haal het dan uit en maak er een Skill van. Als je wilt dat iets stil wordt uitgevoerd elke keer dat een bestand wordt opgeslagen, schrijf dan een hook in plaats daarvan.

Claude Skills IDE-ondersteuning: VS Code, JetBrains, Cursor en Codex

Claude Code werkt via CLI, Desktop, VS Code, JetBrains, web en mobiele besturingsstromen. Anthropic beschrijft de CLI als de meest volledige lokale interface, terwijl de IDE-integraties enkele CLI-alleen-mogelijkheden ruilen voor editor-native review, bestandscontext en betere workflow-ergonomie. Configuratie, projectgeheugen en MCP-servers worden gedeeld over de lokale oppervlakken, zodat je .claude-opzet met je meegaat in plaats van gevangen te zitten in één editor.

Voor VS Code zegt Anthropic dat de extensie de aanbevolen interface binnen de editor is. Het biedt planreview, inline diffs, ondersteuning voor bestandsgedrag en geïntegreerde toegang tot de CLI. Dezelfde installatiestroom biedt ook een directe route voor Cursor. Voor JetBrains omvat de huidige ondersteunde lijst IntelliJ IDEA, PyCharm, Android Studio, WebStorm, PhpStorm en GoLand, met ingebouwde functies voor diff-bekijken, selectie delen, bestandreferenties en diagnostische sharing.

JetBrains-ondersteuning is beter dan veel ontwikkelaars beseffen. Als je claude uitvoert vanuit de geïntegreerde terminal van de IDE, zijn de integratiefuncties automatisch actief. Als je start vanuit een externe terminal, documenteert Anthropic het /ide-commando om Claude Code terug te verbinden met de JetBrains-sessie, en het adviseert expliciet om te starten vanuit dezelfde projectroot, zodat Claude dezelfde bestanden ziet als je IDE. Als je automatische bewerkingsmodi in JetBrains gebruikt, waarschuwt Anthropic ook dat IDE-configuratiebestanden onderdeel van de bewerkbare oppervlakte kunnen worden, dus handmatige goedkeuringen zijn de veiligere standaard in dat omgeving.

Nu het grotere punt. Claude Skills zijn niet alleen iets voor Claude Code. Agent Skills is een open standaard. De officiële Agent Skills-quickstart zegt dat dezelfde skill kan werken in VS Code met GitHub Copilot, Claude Code en OpenAI Codex, en de eigen Codex-documentatie van OpenAI zegt dat Skills beschikbaar zijn in de Codex CLI, IDE-extensie en app. De implementatiegids voor Agent Skills voegt een belangrijk detail toe over draagbaarheid: .agents/skills is ontstaan als de cross-client conventie, hoewel sommige clients ook .claude/skills scannen voor praktische compatibiliteit.

Dus hier is de praktische compatibiliteitsregel die ik aanbeveel. Als je eerst en alleen voor Claude Code bouwt, schrijf dan in .claude/skills. Als je echt cross-client-draagbaarheid wilt, target de open Agent Skills-structuur en gebruik .agents/skills als het canonieke pad. Doe niet alsof die twee doelen identiek zijn. Ze zijn gerelateerd, maar niet identiek.

Snelle compatibiliteitsverwijzing:

SKILL.md-bestandsstructuur, mapindeling en opslaglocaties

Een juiste Skill is een map, niet een willekeurig markdown-bestand dat bij de repo-root ligt. De kernspecificatie vereist een directory met een SKILL.md-bestand en staat optionele scripts/, references/ en assets/-directories toe. SKILL.md moet YAML-frontmatter bevolgen door markdown-instructies. In de specificatie zijn name en description verplicht, name is beperkt tot 64 karakters met kleine letters, cijfers en koppeltekens, compatibility is alleen voor echte omgevingsvereisten, en allowed-tools is expliciet experimenteel over implementaties heen.

Claude Code is wat losser dan de draagbare specificatie, omdat het een naam kan afleiden van de directory en terugschakelt naar de eerste paragraaf als description ontbreekt. Je moet daar niet op vertrouwen als je om draagbaarheid of voorspelbaarheid geeft. Claude.ai vereist dat de directorynaam overeenkomt met het name-veld, en zijn pad voor het uploaden van aangepaste skills beperkt beschrijvingen tot 200 karakters, hoewel de bredere specificatie veel meer toestaat. De draagbare keuze is om een expliciete name in te stellen, de directory identiek te houden en een precieze beschrijving te schrijven die binnen strakke limieten past. Dit beantwoordt het FAQ-onderwerp “Wat moet een SKILL.md-bestand bevatten” zonder te zwijgen.

Begin met een structuur die zo saai is:

repo/
  .claude/
    skills/
      review-pr/
        SKILL.md
        scripts/
          review.sh
        references/
          checklist.md
        assets/
          comment-template.md

Als draagbaarheid over Skills-compatibele clients belangrijker is dan Claude Code-gemak, behoud dan dezelfde interne vorm en vervang .claude/skills/ door .agents/skills/. De mapstructuur is in beide gevallen hetzelfde idee.

Voor Claude Code zijn de opslaglocaties rechtstreeks. Projectskills leven bij .claude/skills/<skill-naam>/SKILL.md. Persoonlijke skills leven bij ~/.claude/skills/<skill-naam>/SKILL.md. Door plugins gedistribueerde skills leven onder <plugin>/skills/<skill-naam>/SKILL.md. Anthropic documenteert prioriteit over de ingebouwde scopes als enterprise boven persoonlijk boven project, terwijl pluginskills botsingen vermijden door een genamespaced vorm zoals plugin-naam:skill-naam te gebruiken. Op Windows lost ~/.claude op naar %USERPROFILE%\.claude, en CLAUDE_CONFIG_DIR kan de hele basisdirectory verplaatsen.

De keuze tussen project- en persoonlijke scope is rechtstreeks. Gebruik .claude/skills/ binnen de repo wanneer de Skill sterk gekoppeld is aan die codebase — bijvoorbeeld een deploy-playbook dat je specifieke cluster-namen kent of een review-rubriek afgestemd op de conventies van je team. Gebruik ~/.claude/skills/ voor Skills die met je meegaan over projecten heen: persoonlijke checklists, generieke changelog-generators, voorkeurige debug-workflows. Alles wat je in een dotfiles-repo zou zetten, hoort in persoonlijke scope.

Enkele scherpe randjes zijn het waard om te onthouden. SKILL.md moet exact met die hoofdlettergevoeligheid worden genoemd. De PDF-gids van Anthropic beveelt kebab-case mapnamen aan en zegt expliciet niet om een README.md in de skill-map te plaatsen, omdat de operationele documentatie in SKILL.md of references/ moet leven. Dezelfde gids benadrukt ook dat SKILL.md-naamsgevoeligheid hoofdlettergevoelig is. Dit zijn saaie beperkingen, maar saaie beperkingen zijn wat tooling betrouwbaar maakt.

Claude Code doet ook het juiste voor monorepos. Het ontdekt automatisch geneste .claude/skills/-directories wanneer je in subdirectories werkt, wat ideaal is voor pakket- of service-level skills. Het bewaakt ook bestaande skill-directories voor live wijzigingen tijdens de huidige sessie. De enige herstartval is het maken van een top-level skills-directory die niet bestond toen de sessie begon. Anthropic documenteert dit als het geval waarin je wel moet herstarten zodat de nieuwe directory bewaakt kan worden.

Beste praktijken voor Claude Skills: Beschrijvingen, Scripts en Scope

De snelste manier om een nutteloze Skill te creëren, is om een LLM er een te laten uitvinden uit generieke trainingskennis. De beste-praktijken-gids van Anthropic waarschuwt precies daarvoor. De waardevolle stukken zijn de domeinspecifieke correcties, randgevallen, tool-keuzes en conventies die het model niet betrouwbaar zou uitvinden op eigen kracht. De juiste workflow is om de taak één keer op te lossen met de agent, het te corrigeren tot het werkt, en dan de methode te extraheren naar een Skill.

Scope de Skill als een goede functie, niet als een wiki. Anthropic zegt dat Skills een coherent eenheid van werk moeten incapsuleren. Te smal, en je dwingt meerdere skills om voor één taak te stapelen. Te breed, en de agent kan ze niet precies activeren. De beste-praktijken-gids is bot dat overmatig uitgebreide skills meer kwaad kunnen doen dan goed, omdat het model irrelevante instructies achtervolgt en het signaal kwijtraakt.

De kwaliteit van de beschrijving is geen cosmetisch probleem. Het is de routeringslaag. Zowel Anthropic als de Agent Skills-documentatie zeggen dat het description-veld het primaire mechanisme is dat het model gebruikt om te beslissen of het een Skill überhaupt moet laden. Goede beschrijvingen zeggen wat de Skill doet, wanneer je het moet gebruiken, en de trigger-zinnen of bestandstypen die een gebruiker daadwerkelijk zou noemen. Slechte beschrijvingen zijn vaag, te technisch, of breed genoeg om nonsens te matchen. Dat is het echte antwoord op de FAQ-vraag “Waarom activeert een Claude Skill niet”. Meestal is de router slecht, niet het model.

Het contrast is duidelijk naast elkaar:

Slechte beschrijvingen — te vaag om betrouwbaar te routeren:

• Helps with code review — matcht alles, onderscheidt niets
• Useful for development tasks — breder dan een zoekopdracht
• Assists with writing — geen router, alleen een categorie-label

Goede beschrijvingen — specifieke trigger-taal:

• Review pull requests for security issues, migration risk, and missing tests. Use when reviewing a PR, git diff, or release critical change.
• Generate a changelog from git log output. Use when preparing a release, writing release notes, or summarising commits since last tag.
• Scaffold a new Go HTTP handler with request validation and error middleware. Use when adding a new endpoint or route to a Go service.

Het patroon is elke keer hetzelfde: geef aan wat de Skill doet, noem de exacte gebruikerszinnen die het moeten activeren, en noem optioneel bestandstypen of tools die relevant zijn. Als je beschrijving een generieke Google-zoekopdracht zou matchen, is het niet specifiek genoeg.

Als een workflow neveneffecten heeft, maak het handmatig. Claude Code exposeert dat direct. disable-model-invocation: true maakt een Skill alleen door de gebruiker aan te roepen, wat Anthropic aanbeveelt voor acties zoals deploys, commits of uitgaande berichten. user-invocable: false gaat de andere kant op en verbergt de Skill in het slash-menu terwijl het Claude nog steeds toestaat om het als achtergrondkennis te gebruiken. Dit beantwoordt het FAQ-onderwerp “Wanneer moet een skill handmatig zijn in plaats van automatisch” in één zin: handmatig voor risico, automatisch voor veilige herhaalbare begeleiding.

Houd SKILL.md klein genoeg om begrijpelijk te blijven. Anthropic beveelt aan om het onder de 500 regels en rond de 5.000 tokens te houden, en gedetailleerd materiaal naar references/ of vergelijkbare bestanden met expliciete laadinstructies te verplaatsen. “Read references/api-errors.md if the API returns a non-200” is een goed patroon. “See references/” is lui. Claude Code injecteert de gerenderde Skill ook als bericht in het gesprek en leest het bestand niet herhaaldelijk in latere beurten. Na context-compressie wordt alleen recente Skill-content meegenomen binnen token-budgets. Enorme Skills zijn daarom niet alleen lelijk. Ze zijn bros over lange sessies.

Een goede SKILL.md kan zeer eenvoudig blijven:

---
name: review-pr
description: Review pull requests for security issues, migration risk, and missing tests. Use when reviewing a PR, git diff, or release critical change.
compatibility: Designed for Claude Code. Requires git and gh.
disable-model-invocation: true
allowed-tools: Bash(git diff *) Bash(gh pr diff *) Read Grep Glob
---
# Review PR

Read references/checklist.md before running any commands.

1. Collect the diff and changed files.
2. Flag correctness, security, and test coverage issues.
3. Return findings grouped by severity with file references.
4. Suggest the smallest safe fix first.

Gebruik scripts wanneer determinisme belangrijker is dan welsprekendheid. De gids voor Skills-scripts is hier uitstekend. Het zegt dat scripts gericht op agents interactieve prompts moeten vermijden, gebruik documenteren via --help, behulpzame foutberichten moeten uitzenden, gestructureerde output zoals JSON of CSV op stdout moeten prefereren, diagnostiek naar stderr moeten sturen, en veilig herbruikbaar gebruik moeten ondersteunen. Het beveelt ook aan om eenmalige toolversies vast te zetten en runtime-eisen expliciet te beschrijven in SKILL.md of het compatibility-veld, in plaats van aan te nemen dat de omgeving de juiste pakketten heeft.

Een minimale maar correcte agent-gerichte script ziet er zo uit:

#!/usr/bin/env bash
# scripts/collect-diff.sh — called by review-pr skill
# Usage: collect-diff.sh <base-ref> [<head-ref>]
set -euo pipefail

BASE="${1:?Usage: collect-diff.sh <base-ref> [<head-ref>]}"
HEAD="${2:-HEAD}"

# Structured output to stdout so the agent can parse it
git diff "${BASE}...${HEAD}" --stat --name-only \
  | jq -Rs '{
      "changed_files": split("\n") | map(select(length > 0))
    }' \
  || { printf '{"error":"git diff failed"}\n' >&2; exit 1; }

Drie dingen maken dit agent-veilig. set -euo pipefail zorgt ervoor dat het script hard stopt bij elke fout in plaats van stil door te gaan. JSON op stdout geeft de agent een formaat dat het zonder raden kan parseren. Diagnostiek gaat naar stderr zodat de stdout-stroom van de agent schoon blijft. Niets van dit is slim. Het is allemaal noodzakelijk.

Een subtiele val is allowed-tools. In de specificatie is het experimenteel en ondersteuning varieert. In Claude Code pre-approveert het specifieke tools terwijl de Skill actief is, maar het beperkt het universum van aanroepbare tools niet, en deny-regels behoren nog steeds tot de Claude Code-permissies. In de Claude Agent SDK zegt Anthropic expliciet dat het allowed-tools-frontmatter in SKILL.md niet van toepassing is, dus SDK-apps moeten tool-toegang afdwingen in de hoofdkonfiguratie allowed_tools of allowedTools. Als je dat verschil negeert, zal je Skill anders gedragen in de CLI en in SDK-aangedreven automatisering.

Een meer geavanceerd patroon is het waard om te stelen. Wanneer een workflow je hoofdthread zou overspoelen met logs, bestandszoeken of lange onderzoeksoutput, laat Claude Code een Skill draaien in een afgebroken subagent met behulp van context: fork en een agent zoals Explore. Anthropic toont dit voor onderzoekswerkflows, waar het zware werk in geïsoleerde context gebeurt en het hoofdgesprek de samenvatting krijgt. Voor diepe codebase-verkenning is dat een veel beter ontwerp dan een enorme inline Skill die de hoofd-sessie vervuilt.

Een afgebroken Skill ziet er in frontmatter zo uit:

---
name: explore-codebase
description: Deep exploration of an unfamiliar codebase. Use when onboarding to a new repo, auditing architecture, or mapping module dependencies.
context: fork
agent: Explore
compatibility: Requires Claude Code CLI.
---
# Explore Codebase

1. Walk the directory tree and summarise the top-level modules.
2. Identify the main entry points and their responsibilities.
3. Map the dependency graph between packages.
4. Return a structured summary to the main session — not the raw file list.

De sleutelregel is context: fork. Zonder dit landt de verkenningsooutput inline in je gesprek. Met het draait de subagent in zijn eigen contextvenster en geeft een samenvatting terug. Het verschil maakt uit bij grote repos waar verkenning alleen al duizenden tokens kan consumeren.

Testen van Claude Skills: Triggers, Correctheid en Basisvergelijkingen

Een Skill is niet getest omdat één happy-path-demo één keer werkte. De gids van Anthropic breekt testen op in drie lagen: handmatig testen in Claude.ai, gescripte testen in Claude Code, en programmatische testen via de Skills API. De aanbevolen evaluatiegebieden zijn triggeren, functionele correctheid en prestaties ten opzichte van een baseline zonder de Skill. Dat is ook het beste antwoord op de FAQ-vraag “Hoe test je of een skill betrouwbaar is”. Je test route-selectie, outputkwaliteit en efficiëntie, niet alleen of het model zelfverzekerd klonk.

De officiële evaluatiegids geeft een schone structuur voor testgevallen. Elk geval moet een realistische gebruikersprompt bevatten, een mens-leesbare beschrijving van de verwachte output, en optionele inputbestanden. De docs slaan deze op in evals/evals.json binnen de Skill-directory, wat een zinvolle conventie is, zelfs als je je eigen harnas bouwt.

Gebruik een fixture-bestand en een no-nonsense eval-layout zoals dit:

{
  "skill_name": "review-pr",
  "evals": [
    {
      "id": 1,
      "prompt": "Review this PR for security issues and missing tests",
      "expected_output": "Findings grouped by severity with file references and at least one test recommendation.",
      "files": ["evals/files/pr-diff.patch"]
    },
    {
      "id": 2,
      "prompt": "Summarise last week's commits",
      "expected_output": "The skill should not activate.",
      "files": []
    }
  ]
}

Mijn eigen testregel is strenger dan de meeste teams gebruiken, maar het komt overeen met de officiële richtlijnen. Elke serieuze Skill moet should-trigger queries, should-not-trigger queries, ten minste één randgevaltest, en een basisvergelijking zonder de Skill hebben. De voorbeelden van Anthropic vergelijken tool-oproepen, mislukte API-oproepen, verduidelijkingsloops en token-gebruik met en zonder de Skill, omdat “werken” niet hetzelfde is als “de workflow verbeteren”.

Als je test via de Claude Agent SDK, onthoud dan de leiding. Skills zijn daar bestandssysteem-artefacten, geen programmatische registraties. Anthropic zegt dat je het "Skill"-tool moet inschakelen en de relevante bestandssysteeminstellingen moet laden via settingSources of setting_sources. Als je user of project overlaat, of cwd naar de verkeerde plek wijst, zal de SDK de Skill niet ontdekken. Anthropic beveelt zelfs aan om “What Skills are available?” te vragen als een directe ontdekkingcontrole.

Test ook op het model en de client waarmee je daadwerkelijk wilt leveren. De open Agent Skills-quickstart waarschuwt expliciet dat betrouwbaarheid van tool-gebruik varieert tussen modellen, en sommige modellen kunnen direct antwoorden in plaats van het commando uit te voeren dat de Skill beoogt. Dat is niet altijd een Skill-ontwerpprobleem. Soms is het een model-selectieprobleem, en je testmatrix moet het blootleggen.

Probleemoplossing voor Claude Skills: Veelvoorkomende Mislukkingen en Oplossingen

Wanneer een Skill zich verkeerd gedraagt, veronderstel verpakking voordat je intelligentie aannimt. De meest voorkomende mislukkingen zijn nog steeds de saaie dingen.

• Als de Skill helemaal niet wordt gevonden, verifieer dan dat het bestand exact SKILL.md wordt genoemd, met de juiste hoofdlettergevoeligheid, binnen de juiste directory. De probleemoplossingsgids van Anthropic noemt bestandsnaamhoofdlettergevoeligheid expliciet, en zijn Claude Code- en SDK-docs wijzen je direct naar .claude/skills/*/SKILL.md en ~/.claude/skills/*/SKILL.md als de eerste controles.
• Als frontmatter ongeldig is, controleer dan eerst de YAML-scheiders en aanhalingstekens. De voorbeelden van Anthropic tonen de klassieke fouten: ontbrekende ---, niet-gesloten aanhalingstekens, of ongeldige namen met spaties en hoofdletters. Skill-namen moeten in kleine letters en met koppeltekens zijn.
• Als de Skill bestaat maar niet trigger, is de beschrijving meestal te vaag. De eigen probleemoplossing van Claude Code zegt om trefwoorden op te nemen die gebruikers natuurlijk zouden zeggen, te verifiëren dat de Skill verschijnt als je vraagt “What skills are available?”, en te proberen de zin dichter bij de beschrijving te herformuleren. De PDF-gids van Anthropic voegt een geweldig diagnostisch trucje toe: vraag Claude wanneer hij de Skill zou gebruiken en luister naar hoe hij de beschrijving terug voor je herschrijft.
• Als de Skill te vaak trigger, versmal de scope. Anthropic beveelt aan om de beschrijving specifieker te maken, negatieve triggers toe te voegen, en disable-model-invocation: true te gebruiken voor workflows die je alleen wilt bij expliciete commando. Over-triggeren is meestal gewoon ondergespecificeerde routetaal.
• Als de Skill lijkt zijn invloed te verliezen in lange sessies, onthoud dan dat beschrijvingen kunnen worden ingekort in de Claude Code-catalogus wanneer veel skills aanwezig zijn, en aangevraagde Skills later worden meegenomen binnen token-budgets na compressie. Anthropic beveelt aan om trefwoorden in de beschrijving voor te zetten, overbodige tekst te trimmen, en, specifiek voor Claude Code, SLASH_COMMAND_TOOL_CHAR_BUDGET aan te passen als beschrijvingslijsten te agressief worden samengeperst.
• Als een gebundeld script hangt of erratisch gedraagt, controleer dan of het interactieve input verwacht. De scriptsgids zegt dat agents in niet-interactieve shells draaien, dus TTY-prompts, wachtwoorddialogs en bevestigingsmenu’s zijn ontwerpbugs. Accepteer input via vlaggen, omgevingsvariabelen of stdin en maak fouten expliciet.
• Als de SDK je Skill niet ziet, bevestig dan dat allowed_tools "Skill" bevat, dat settingSources of setting_sources user en project bevat, en dat cwd naar de directory wijst die .claude/skills/ daadwerkelijk bevat. Zonder die opzet is het Skillsysteem niet ingeschakeld, hoe correct je markdown ook lijkt.
• Als een MCP-gebackte Skill laadt maar de tool-oproepen falen, is de probleemoplossingscontrolelijst van Anthropic zinvol: verifieer dat de MCP-server is verbonden, bevestig authenticatie en scopes, test de MCP-tool direct zonder de Skill, en controleer de exacte toolnamen omdat ze hoofdlettergevoelig zijn.

De saaie waarheid is dat goede Claude Skills eruitzien als goed operationeel engineering. Duidelijke namen. Kleine bestanden. Expliciete triggers. Deterministische scripts waar nodig. Echte tests. Als je Skill leest als een strak runbook, heeft de agent een vechtkans. Als het leest als een brainstorm, heb je simpelweg chaos in een map verborgen.