AI Agents

Claude Skills vs. Slash Commands vs. Subagents

Alejandro Rioja
Alejandro Rioja
8 min lezen
TL;DR

Slash commands zijn een afkorting voor een prompt die je vaak typt — je roept ze aan bij naam. Subagents zijn parallelle werkers met hun eigen contextvenster — jij (of Claude) zet ze in voor een afgebakende taak en krijgt een resultaat terug. Skills zijn verpakte expertise die Claude zelf besluit te laden, op basis van wat je vraagt, zonder dat jij iets hoeft te noemen. De meeste mensen grijpen naar een custom agent wanneer een slash command al zou volstaan, en grijpen naar een slash command wanneer ze eigenlijk een skill nodig hadden die Claude zelf kon activeren.

Gratis nieuwsbrief

Elke woensdag. 28.400+ operators. Geen opvulling.

Inhoudsopgave

Bijgewerkt augustus 2026.

TL;DR: Slash commands zijn een afkorting voor een prompt die je vaak typt — je roept ze aan bij naam. Subagents zijn parallelle werkers met hun eigen contextvenster — jij (of Claude) zet ze in voor een afgebakende taak en krijgt een resultaat terug. Skills zijn verpakte expertise die Claude zelf besluit te laden, op basis van wat je vraagt, zonder dat jij iets hoeft te noemen. De meeste mensen grijpen naar een custom agent wanneer een slash command al zou volstaan, en grijpen naar een slash command wanneer ze eigenlijk een skill nodig hadden die Claude zelf kon activeren.

[Operatorperspectief] Ik draai 30+ productieagents verspreid over twee bedrijven, en precies deze verwarring — command, subagent of skill — is bij bijna elk van hen de eerste ontwerpvraag. Krijg je het verkeerd, dan bouw je ofwel tien commands waarvan niemand de namen onthoudt, ofwel één skill die zo breed is dat hij nooit betrouwbaar activeert. De oplossing is geen vuistregel, maar de vraag wat er echt verschilt tussen de ene run en de andere.

De drie bouwstenen lossen verschillende problemen op

Alle drie laten je instructies één keer verpakken en daarna hergebruiken. Daar houdt de gelijkenis op — en dat is precies waarom mensen ze door elkaar halen: van buitenaf ziet “iets korts typen en een nuttig resultaat krijgen” er hetzelfde uit, ongeacht welke van de drie er onder de motorkap werkt.

Het echte verschil is wie beslist om het aan te roepen, en in welke context het draait:

  • Een slash command wordt aangeroepen door jou, bij naam. Je typt /deploy of /review, Claude vouwt het uit tot een volledigere instructie, en het draait in je huidige gesprek.
  • Een subagent wordt aangeroepen door jou of Claude, voor een taak met een duidelijke grens. Hij krijgt zijn eigen contextvenster, doet het werk en rapporteert een resultaat terug — hij ziet je hele gesprek niet, en jij ziet zijn tussenstappen niet, tenzij je ernaar vraagt.
  • Een skill wordt aangeroepen door Claude, automatisch, wanneer jouw verzoek overeenkomt met wat de beschrijving van de skill zegt dat hij dekt. Je typt nooit zijn naam. Als je niet vraagt om iets waar de skill voor is gemaakt, laadt hij nooit.

Die derde eigenschap — geen expliciete aanroep — is degene die mensen onderbenutten. Het is ook degene met de meeste hefboomwerking zodra je meer dan een handvol verpakte workflows hebt, omdat je stopt met onthouden hoe je dingen genoemd hebt.

Slash commands: afkorting voor een prompt die je vaak typt

Bouw een slash command wanneer de trigger is: “ik typ steeds ongeveer dezelfde instructie.” Een command die altijd naar dezelfde onderliggende prompt oplost, uitgevouwen vanuit een korte naam die jij hebt gekozen, in het gesprek dat je al aan het voeren bent. Geen aparte context, geen autonome aanroep — jij bepaalt wanneer het draait, elke keer opnieuw.

Goede kandidaten: een vaste releasechecklist, een codereview met jouw huisregels ingebakken, een “vat deze PR samen”-snelkoppeling. Het command hoeft geen oordeel te vellen over of het moet draaien — jij bent degene die die beslissing neemt door het te typen.

Het faalpatroon is een command bouwen voor iets dat eigenlijk vraagt dat het model beslist of het van toepassing is. Als je bij de helft van het gebruik denkt: “wacht, telt deze situatie mee?” — dan is dat een skill-vraag, geen command-vraag, want een command kan zichzelf niet aanroepen.

Subagents: parallelle werkers met hun eigen contextvenster

Bouw een subagent wanneer de taak afgebakend en overdraagbaar is, en anders je hoofdgesprek zou vervuilen met stappen die je niet hoeft te zien. Een subagent draait in zijn eigen context — zijn eigen tool calls, zijn eigen heen-en-weer — en levert een resultaat af. Dit is hetzelfde principe waarover ik schreef in context engineering: elke extra tool call en tussenstap is context die je hoofddraad niet hoeft mee te dragen, en een subagent is hoe je die ruis buiten houdt.

Goede kandidaten: “onderzoek dit en rapporteer terug,” “voer deze vijf onafhankelijke checks parallel uit,” “los dit ene bestand geïsoleerd op.” De taak heeft een begin, een einde en een opleverbaar resultaat — precies de vorm die de eval-harness waarmee ik agents lanceer behandelt als één scoorbare eenheid.

Het faalpatroon is een subagent inzetten voor iets dat eigenlijk in je hoofdcontext had moeten blijven, omdat de volgende stap afhangt van details die de samenvatting van de subagent liet vallen. Als je de subagent steeds opnieuw moet vragen “wacht, wat heb je nu precies gevonden,” dan is de grens verkeerd getrokken — vouw het terug in de hoofddraad, of maak het rapport van de subagent gestructureerd genoeg zodat er niets verloren gaat in de vertaling.

Skills: verpakte expertise die Claude zelf laadt

Bouw een skill wanneer de triggervoorwaarde iets is dat Claude moet herkennen aan wat je vraagt, niet iets wat jij moet onthouden om te noemen. Een skill is een beschrijving plus een bundel instructies en scripts; Claude leest de beschrijving, beslist of je verzoek ermee overeenkomt, en laadt de volledige instructies alleen als dat zo is. Je typt nooit /skill-naam.

Het duidelijkste voorbeeld dat ik kan geven is degene die de pijplijn achter deze blog aandrijft. Alejandrorioja.com publiceert in 13 talen, en de hele flow van genereren → vertalen → renderen → reviewen leeft in één enkele skill: een SKILL.md-bestand dat beschrijft wanneer hij gebruikt moet worden (“genereer een nieuwe post,” “vertaal naar alle talen,” “concept een promo”), plus de scripts die het echte werk doen. Ik draai geen vier aparte commands en onthoud hun volgorde. Ik zeg gewoon wat ik wil in gewone taal, en de beschrijving van de skill is specifiek genoeg dat Claude het oppikt en de juiste stappen uitvoert — op dezelfde manier waarop mijn Claude-skill die mijn Facebook-ads beheert reageert op “check mijn ads” zonder dat ik een commandonaam typ.

Die ontwerpkeuze — een skill die zelf beslist wanneer hij van toepassing is — is ook waarom de veiligheidsstandaard hier zwaarder weegt dan bij commands of subagents. Een slash command draait alleen wanneer jij hem typt; een skill draait wanneer het model denkt dat hij zou moeten. Mijn content-skill schrijft standaard alleen concepten en vereist een expliciete, aparte goedkeuringsstap voordat er iets gepubliceerd of gepusht wordt — hetzelfde human-in-the-loop-patroon dat ik overal gebruik waar een skill zichzelf kan activeren tot een actie met echte gevolgen.

Goede kandidaten: alles met een herkenbare triggerzin en een herhaalbare procedure erachter — “genereer een rapport,” “beoordeel deze inzending,” “schrijf een samenvatting voor Slack.” Het faalpatroon is een skill-beschrijving die zo breed is dat hij afgaat wanneer je dat niet wilde, of zo smal dat hij nooit afgaat wanneer je dat wel wilde. Schrijf de beschrijving zoals je de trigger aan een nieuwe collega zou uitleggen, niet zoals je een functie zou benoemen.

Het beslissingskader

Stel jezelf deze vraagZo ja →Waarom
Wil ik altijd een naam typen om dit te activeren?Slash commandJij bent de trigger, niet het model
Is de taak afgebakend, overdraagbaar en beter buiten mijn hoofdcontext gehouden?SubagentEigen contextvenster, levert een resultaat
Moet Claude de behoefte herkennen zonder dat ik iets noem?SkillBeschrijving-gematcht, automatisch aangeroepen
Raakt het geld, publicatie, of iets wat lastig terug te draaien is?Elk van de drie, plus een expliciete goedkeuringspoortAutomatische aanroep is niet hetzelfde als automatische uitvoering

De meeste echte workflows zijn een stapeling van deze drie, geen enkele keuze. Mijn content-pijplijn is een skill (automatisch geactiveerd op “schrijf een post”) die intern subagents aanroept (één per taal, parallel draaiend) en een slash command (/publish) blootstelt voor die ene stap — live gaan — die nooit mag gebeuren zonder dat ik het expliciet zeg.

De fout die ik het vaakst zie

Een volledige custom agent bouwen — met eigen planning, eigen state, eigen deploy — voor iets dat eigenlijk een slash command in vermomming was. Als de taak is “voer deze exacte procedure uit wanneer ik het zeg,” heb je geen autonomie, geheugen of triggervoorwaarde nodig. Je hebt een naam en een prompt nodig. Bewaar de subagent- en skill-machinerie voor taken waarbij de grens (subagent) of de trigger (skill) echt werk doet, niet alleen infrastructuur toevoegt aan iets dat al simpel was.

De conclusie van de operator

Vraag wie beslist om het aan te roepen voordat je vraagt hoe je het bouwt. Jij die beslist, bij naam, elke keer → slash command. Een afgebakende taak die je buiten je hoofdcontext wilt houden → subagent. Claude die de behoefte zelf herkent → skill, met een goedkeuringspoort op alles wat niet terug te draaien is. Krijg die ene vraag goed en de rest — wat er in het bestand komt, hoeveel instructie je bundelt — volgt meestal vanzelf.

FAQ

Wat is het verschil tussen een Claude-skill en een slash command?

Een slash command wordt expliciet aangeroepen, bij naam, elke keer dat je wilt dat hij draait. Een skill wordt automatisch aangeroepen — Claude matcht je verzoek tegen de beschrijving van de skill en laadt hem zonder dat jij iets noemt. Gebruik een command wanneer jij altijd degene bent die beslist om te activeren; gebruik een skill wanneer de triggervoorwaarde iets is dat het model zelf zou moeten herkennen.

Wanneer gebruik ik een subagent in plaats van een skill?

Wanneer de taak afgebakend en overdraagbaar is en je wilt dat hij draait in zijn eigen contextvenster, gescheiden van je hoofdgesprek — niet vanwege hoe hij geactiveerd wordt, maar vanwege waar het werk plaatsvindt. Skills en subagents sluiten elkaar niet uit: een skill kan intern subagents aanroepen, zoals een vertaal-skill een post kan uitwaaieren naar één subagent per taal.

Is het veilig om een skill acties zoals publiceren of geld uitgeven automatisch te laten aanroepen?

Alleen met een expliciete goedkeuringspoort op de ingrijpende stap. Automatische aanroep van de skill zelf is prima — het betekent alleen dat Claude herkende wat je vraagt. Het risico zit in automatische uitvoering van iets wat lastig terug te draaien is. Houd concepten schrijven, lezen en rapporteren binnen de automatisch geactiveerde skill; vereis een aparte, expliciete bevestiging voor publiceren, betalen of verwijderen.

Moet ik uiteindelijk alle drie bouwen?

Alleen als je workflows daadwerkelijk alle drie de vormen hebben. Een solo-operator met een handvol herhaalbare taken kan lange tijd volledig op slash commands draaien. De behoefte aan skills en subagents ontstaat zodra je genoeg verschillende triggervoorwaarden hebt dat je de commandonamen niet meer kunt onthouden, of genoeg afgebakende deeltaken dat ze in je hoofdcontext houden de kwaliteit begint te schaden.


Gerelateerd: De Claude-skill die mijn Facebook-ads beheert · Context engineering: wat er in het context window komt · AI-agents met menselijke controle: wanneer een goedkeuring? · De agent-stack voor 30+ productie-agents

Hulp nodig om te bepalen wat je moet automatiseren en hoe? Neem contact op — ik ontwerp productie-agentsystemen voor operatorteams.

Lees verder

Gerelateerde berichten

Lees verder

Ontvang het AI-playbook in je inbox

Elke woensdag. 28.400+ operators. Geen opvulling.

↵ alle resultaten bekijken esc esc om te sluiten