De snelste versnelling die ik dit jaar in Claude Code kreeg, was geen modelupgrade. Het was leren om één schuine streep te typen, gevolgd door vier letters.
Ik gebruikte Claude Code al meer dan een jaar dagelijks voordat ik iets gênants toegaf: ik liet het grootste deel van het potentieel onbenut. Ik opende een sessie, typte een hele paragraaf aan instructies, keek hoe het werkte, liep vast, en begon een gloednieuwe sessie door de terminal helemaal af te sluiten. Elke. Keer. Weer. Ik betaalde voor context die ik steeds weggooide, legde hetzelfde project telkens opnieuw uit vanuit nul, en verspilde verbruik aan gesprekken die zo ver waren afgedwaald dat Claude eigenlijk aan het gokken was.
Toen begon ik de slash-commando's daadwerkelijk te gebruiken. Niet zoals de documentatie ze opsomt — alfabetisch, vlak, als een woordenlijst die niemand leest. Ik bedoel de vier of vijf waar ik nu zo reflexmatig naar grijp dat mijn vingers bewegen voordat mijn brein de gedachte heeft afgemaakt. De commando's die bepalen of een bouwsessie van twee uur aanvoelt als flow of als vechten tegen het gereedschap.
Dit is de praktische versie daarvan. De Claude Code slash-commando's die ik oprecht elke dag gebruik, gegroepeerd op het daadwerkelijke probleem dat elk ervan oplost — context die verouderd is, een build die is ontspoord, een plan dat ik wilde zien voordat er ook maar één regel code werd geschreven. Voor elk commando: wat het doet, de exacte manier waarop ik het aanroep, en het specifieke moment waarop ik ernaar grijp bij echt werk.
Een paar van de "commando's" die rondzweven in tutorials en video's bleken gemeenschapsjargon te zijn of functies die net iets anders werken dan mensen beschrijven. Ik zal die eerlijk markeren terwijl we doorgaan, want het kennen van het accurate beeld is het hele punt — een commando waarvan je denkt dat het bestaat maar dat niet zo is, is erger dan helemaal geen commando.
Laten we beginnen waar elke goede sessie begint en eindigt: bij context.
Wat zijn slash-commando's in Claude Code?
Slash-commando's zijn snelkoppelingen die je activeert door / te typen in de Claude Code-prompt, wat een automatisch aanvulmenu opent met acties die je kunt uitvoeren zonder lange instructies te schrijven. Ze besturen de sessie zelf — context wissen, code terugdraaien, oude gesprekken hervatten, de interface configureren — in plaats van prompts te zijn die je naar het model stuurt.
Dat onderscheid is belangrijker dan het klinkt. Een normaal bericht vraagt Claude om iets in je codebase te doen. Een slash-commando vraagt Claude Code om iets met de sessie te doen waarin je werkt. Het ene bewerkt bestanden; het andere beheert de omgeving waarin die bewerkingen plaatsvinden.
Het automatisch aanvullen verschijnt zodra je / typt — in de terminal en in de desktop-app — dus je hoeft geen exacte schrijfwijzen te onthouden. Typ /re en je ziet /rewind en /resume samen verschijnen. Dat is ook hoe ik commando's ontdek die ik was vergeten, wat de helft van de reden is waarom ik überhaupt de slash typ in plaats van naar een sneltoets te grijpen die ik half onthoud.
Hier is wat de meeste spiekbriefjes fout doen: ze behandelen alle veertig-en-nog-wat commando's als even leerzaam. Dat zijn ze niet. Ik gebruik er misschien zes dagelijks en de rest bijna nooit. Dus ik ga niet alles opsommen. Ik ga je door de handvol leiden die hun plek in het spiergeheugen verdienen — en je vertellen welke het internet fout heeft.
Het eerste is het commando dat ik op dag één had moeten leren.
Contextbeheer: /clear, /resume en /rewind
Het meeste ongemak dat ik vroeger voelde in Claude Code was terug te voeren op één enkele grondoorzaak: ik was slecht in het beheren van context. Ofwel had ik er te veel van (een opgeblazen gesprek waarbij Claude steeds struikelde over oude, irrelevante instructies) of ik was de context kwijtgeraakt die ik eigenlijk wilde (een sessie die ik te vroeg had gesloten en niet terug kon krijgen). Drie commando's losten bijna alles op.
/clear — de reset die ik veel te lang vermeed
/clear wist de huidige gespreksgeschiedenis uit het contextvenster en laat je fris beginnen — zonder je projectgeheugen te verwijderen.
Die tweede helft is het deel dat ik maandenlang fout had, en het is de moeite waard om er precies over te zijn omdat het verandert hoe agressief je het commando zou moeten gebruiken. Wanneer je /clear uitvoert, verwijdert het alles uit het actieve contextvenster: het heen-en-weer, de bestanden die Claude las, de doodlopende wegen. Maar het raakt niet je CLAUDE.md-bestand. CLAUDE.md wordt bij het begin van elke sessie opnieuw geladen, dus het overleeft een /clear en wordt opnieuw geïnjecteerd. Je projectbriefing blijft. Alleen de conversationele ballast verdwijnt.
Ik dacht vroeger dat wissen betekende "alles verliezen en het hele project opnieuw uitleggen." Dat klopt niet — niet als je de duurzame zaken (architectuur, conventies, het databaseschema) in CLAUDE.md hebt gezet waar ze thuishoren. Die realisatie is wat me er uiteindelijk toe bracht om voortdurend te wissen in plaats van het te vrezen.
Nu de regel die ik volg: het moment dat ik één logische taak afmaak en naar een ongerelateerde overstap, wis ik. Klaar met het opzetten van authenticatie, op het punt om de factureringspagina te bouwen? /clear. Twee redenen. Ten eerste maakt een verouderd contextvenster vol authenticatiedetails Claude slechter in het factureringswerk — het herkent patronen op de verkeerde dingen, verwijst naar bestanden die er niet toe doen, en bewerkt af en toe "behulpzaam" iets waar ik nooit om heb gevraagd. Ten tweede is elke token van die dode context een token waarvoor ik betaal en een token die mijn verbruikslimieten opeet. Een lange, afdwalende sessie is in beide opzichten duur.
Als je maar één commando uit dit hele bericht overneemt, laat het dit zijn. Wis tussen taken. Je outputkwaliteit gaat omhoog en je verbruik gaat omlaag tegelijkertijd, wat bijna nooit samen voorkomt.
Er is een verwant commando dat het waard is om te kennen: /compact. Waar /clear het gesprek volledig weggooit, vat /compact het samen in een gecomprimeerde vorm zodat je de essentie behoudt terwijl je context vrijmaakt. Ik grijp naar /compact midden in een taak wanneer een enkel stuk werk lang is geworden maar ik nog steeds de geschiedenis nodig heb; ik grijp naar /clear wanneer ik echt klaar ben en van versnelling wissel. Verschillende gereedschappen voor verschillende momenten.
/resume — een gesprek terugkrijgen waarvan je dacht dat het weg was
/resume laat je een eerder Claude Code-gesprek heropenen door het uit een lijst te selecteren, zodat een sessie die je sloot — of zelfs wiste — niet noodzakelijk verloren is.
Dit is het commando dat me echt verdriet heeft bespaard. Stel je het scenario voor: ik wis een sessie, schakel over naar een andere taak, en twintig minuten later realiseer ik me dat ik iets nodig had uit het gesprek dat ik zojuist heb gewist — een beslissing die we namen, een codefragment dat Claude genereerde, de redenering achter een aanpak. Vóór /resume was dat weg en voelde ik het.
Met /resume voer ik het commando uit, krijg een lijst van recente sessies, en kies degene die ik terug wil. Het is anders dan terugdraaien binnen een actief gesprek — /resume reikt over sessies heen om een eerdere volledig te herstellen. Zie het als het verschil tussen het ongedaan maken van je laatste paar bewerkingen in een document versus het heropenen van een bestand dat je gisteren sloot.
De workflow die ik heb ontwikkeld: ik wis agressief omdat ik weet dat /resume mijn rug dekt. De angst om context te verliezen was wat me deed hamsteren. Zodra ik erop vertrouwde dat ik een oude sessie terug kon halen wanneer ik die echt nodig had, voelde wissen niet meer riskant maar als hygiëne.
/rewind — ongedaan maken voor code, niet alleen voor gesprekken
/rewind draait je sessie terug naar een eerder controlepunt, en het kan je code, je gesprek, of beide herstellen — onafhankelijk van elkaar.
Dit is het commando dat veranderde hoe ambitieus ik Claude laat werken. Claude Code maakt automatisch een controlepunt van de staat van je code vóór elke bewerking, telkens wanneer je een prompt verstuurt. Dus wanneer een wijziging over meerdere bestanden de mist in gaat — en bij een grote refactoring gebeurt dat soms — raak ik niet in paniek en begin ik niet handmatig bestanden terug te zetten. Ik open /rewind.
Je kunt het op twee manieren activeren: typ /rewind, of druk twee keer op Esc wanneer het promptinvoerveld leeg is. Beide openen het terugdraaimenu met je recente controlepunten. Vervolgens kies je wat je wilt herstellen:
- Code en gesprek herstellen — draai beide terug naar dat punt, alsof de laatste paar minuten nooit zijn gebeurd.
- Gesprek herstellen — draai de chat terug naar een eerder bericht maar behoud je huidige code. Handig wanneer de code prima is maar het gesprek een verwarrend pad volgde.
- Code herstellen — draai de bestandswijzigingen terug maar ga door met praten. Dit is degene die ik het meest gebruik: "die aanpak was fout, draai de bestanden terug, maar laten we blijven bespreken waarom."
Er zijn ook opties "samenvatten vanaf hier" / "samenvatten tot hier" die een deel van het gesprek comprimeren om context terug te winnen — een mooie overlap met het /compact-idee.
Eén beperking die je absoluut moet kennen, want het heeft mensen verbrand: /rewind volgt alleen bewerkingen die Claude heeft gemaakt via zijn bestandsbewerkingstools. Bash-commando's worden niet gecontrolepunt. Als Claude rm, mv of cp heeft uitgevoerd, zijn die wijzigingen permanent — terugdraaien brengt ze niet terug. Controlepunten blijven ook bestaan over sessies heen en worden na 30 dagen automatisch opgeruimd. Dus terugdraaien is een vangnet voor bewerkingen, geen vervanging voor git. Ik commit nog steeds vaak. Terugdraaien is voor de tussentijdse momenten; git is voor de grondwaarheid.
Als je dieper wilt duiken in hoe ik tokenverbruik rond al dit wissen en comprimeren structureer, heb ik dat apart uitgewerkt in mijn gids voor het verlagen van Claude Code-tokenkosten met de holbewonersaanpak — contextdiscipline en kostendiscipline zijn dezelfde vaardigheid met twee petten.
Dat is context afgehandeld. De volgende groep gaat over kwaliteit — Claude laten nadenken voordat het handelt.
Planning en kwaliteit: planmodus en verduidelijk-dan-plan
De grootste sprong in mijn outputkwaliteit kwam niet van een contextcommando. Het kwam doordat ik Claude dwong om te plannen voordat het ook maar één regel schrijft. Er zijn twee manieren waarop ik dit doe — één ingebouwd, één die ik zelf bouw — en de tweede is het middelpunt van dit hele bericht.
Planmodus — de aanpak zien voordat er code wordt geschreven
Planmodus is een alleen-lezen status waarin Claude je codebase analyseert en een volledig implementatieplan voorstelt voordat het bestanden aanraakt, zodat je de aanpak kunt beoordelen en aanpassen voordat de uitvoering begint.
Even een nauwkeurigheidsnoot, want dit brengt mensen in verwarring: veel video's en transcripties noemen dit "het /plan-commando," en dat is maar half juist. Planmodus is al lange tijd ingebouwd in de machtigingscyclus van Claude Code — je activeert het door twee keer op Shift+Tab te drukken om op ⏸ planmodus aan onderaan je terminal te landen. Vanaf Claude Code v2.1.0 is er ook een letterlijk /plan-commando dat dezelfde modus inschakelt, plus je kunt opstarten met claude --permission-mode plan of het een projectstandaard maken in .claude/settings.json. Dus als je "/plan" hoorde en het leek niets te doen in een oudere versie — dat is waarom. Het Shift+Tab-pad werkt altijd.
Hier is wat planmodus daadwerkelijk doet. Terwijl het actief is, behoudt Claude volledige toegang tot zijn lees-tools — Read, Glob, Grep, WebSearch, WebFetch — maar elk schrijf-tool is geblokkeerd: geen Edit, geen Write, geen Bash-uitvoering. Het leest je codebase, brengt afhankelijkheden in kaart, redeneert door de hele aanpak, en geeft je een genummerd plan. Je leest het. Je past het aan als het fout is. Dan keur je het goed, en pas dan voert het uit.
Het moment waarop ik naar planmodus grijp: elke taak die meer dan twee of drie bestanden raakt, of alles waarbij ik niet 100% zeker ben dat Claude en ik hetzelfde mentale model delen van hoe de wijziging moet gebeuren. Een databasemigratie. Een refactoring over componenten. Het aansluiten van een nieuwe API op een bestaande stroom. Daarvoor vangt het bekijken van Claudes plan de misvatting op voordat het dertig minuten verkeerde code wordt die ik vervolgens moet terugdraaien.
De fout die ik mensen zie maken is planmodus voor alles gebruiken, inclusief triviale bewerkingen in één bestand, waar het alleen maar wrijving toevoegt. Planmodus verdient zijn plek bij ambiguïteit en schaal. Voor "voeg hier een console.log toe," sla het over.
Planmodus is krachtig, maar het is reactief — Claude plant op basis van wat ik het vertelde. De volgende techniek lost het diepere probleem op: wat gebeurt er wanneer mijn prompt zelf onvolledig was.
Aangepaste slash-commando's — een "verduidelijk, dan plan, dan voer uit"-commando bouwen
Dit is het gedeelte waarvan ik je zou zeggen het twee keer te lezen. Aangepaste slash-commando's zijn de functie met het hoogste hefboomeffect in Claude Code die de meeste mensen nooit aanraken, en ze zijn oprecht eenvoudig te bouwen.
Een aangepast slash-commando is gewoon een Markdown-bestand. Je maakt een bestand aan in .claude/commands/ (projectgebonden, gedeeld met iedereen in de repo) of ~/.claude/commands/ (persoonlijk, volgt je over elk project). De bestandsnaam wordt de commandonaam. De inhoud van het bestand wordt de prompt die naar Claude wordt gestuurd wanneer je het aanroept. Dat is het hele mechanisme.
Dus als ik dit uitvoer:
mkdir -p .claude/commands
en een bestand maak genaamd .claude/commands/build.md, dan injecteert het typen van /build in elke sessie binnen dat project wat ik in dat bestand heb geschreven als mijn prompt. Het commando verschijnt automatisch in het /-aanvulmenu.
Nu — waarom is dit belangrijk? Omdat de grootste kwaliteitsmoordenaar bij AI-codering niet het model is. Het is de kloof tussen wat ik vroeg en wat ik daadwerkelijk bedoelde. Ik schrijf een vage prompt, Claude maakt redelijke-maar-verkeerde aannames om de kloof te vullen, en ik krijg zelfverzekerde, schone code die het verkeerde probleem oplost.
De oplossing is een commando dat Claude dwingt die kloof te dichten voordat het iets schrijft. Hier is het daadwerkelijke commando dat ik in mijn repo's bewaar. Noem het .claude/commands/scope.md:
# Verduidelijk het verzoek, maak dan een plan, bouw dan.
Je staat op het punt te implementeren: $ARGUMENTS
Schrijf nog GEEN code. Werk deze stappen in volgorde door:
1. VERDUIDELIJK. Stel me maximaal 5 specifieke vragen over alles wat ambigu
is in het verzoek — datastructuren, randgevallen, naamgeving, waar dit past in
de bestaande architectuur, hoe "klaar" eruitziet. Als iets oprecht ondubbelzinnig
is, vul de lijst dan niet aan — vraag alleen wat je nodig hebt.
2. PLAN. Zodra ik antwoord, herformuleer de taak in één zin en geef me dan een
genummerd implementatieplan: de bestanden die je gaat maken of wijzigen, de
volgorde waarin je ze doet, en elke beslissing die je neemt die ik nu zou moeten
afwijzen in plaats van nadat de code bestaat.
3. WACHT. Stop en laat me het plan goedkeuren of corrigeren voordat je ook maar
één bestand aanraakt.
Begin pas met implementeren nadat ik goedkeur.
De $ARGUMENTS-placeholder is de echte truc — alles wat ik na de commandonaam typ, wordt daar ingevoegd. Dus ik voer /scope voeg teamuitnodigingen toe aan de instellingenpagina uit en Claude neemt "voeg teamuitnodigingen toe aan de instellingenpagina" als het ding om te verduidelijken en rond te plannen.
Wat levert dit me op in de praktijk? De verduidelijkende vragen zijn waar de magie zit. De helft van de tijd brengen Claudes vragen iets aan het licht dat ik nog niet had besloten — "moeten uitgenodigde gebruikers direct een rol krijgen of in afwachting blijven totdat ze accepteren?" — en het hardop beantwoorden voordat er code bestaat betekent dat ik nooit de verkeerde implementatie krijg. De planstap laat me vervolgens goedkoop een aanpak afkeuren, terwijl het nog woorden op een scherm zijn in plaats van bestanden op schijf.
Ik kan je geen schoon percentage geven van hoeveel dit de output verbetert — en ik wil daar eerlijk over zijn, want ik heb de bewering zien rondzweven dat aangepaste verduidelijk-dan-plan-commando's de kwaliteit "met maximaal 43% verbeteren op basis van interne rapportage," en ik kon nooit een echte basis voor dat getal vinden. Dus ik ga niet doen alsof. Wat ik je wel kan vertellen uit dagelijks gebruik is kwalitatief en consistent: het forceren van de verduidelijk-dan-plan-dan-voer-uit-reeks vermindert het aantal "dat is niet wat ik bedoelde"-herschrijvingen dat ik doe aanzienlijk. Het herwerk dat ik bespaar is het volledige rendement op de investering. Dat het getal niet verifieerbaar is, maakt de techniek niet minder reëel — het betekent alleen dat ik het niet ga opsmukken met een statistiek waar ik niet achter kan staan.
Als je dieper wilt duiken in het bouwen hiervan, heb ik een volledige uiteenzetting geschreven van het /advisor aangepaste slash-commando en de metacognitieve laag die het toevoegt — dezelfde bouwstenen, ander doel. En de reden dat deze hele aanpak werkt, sluit direct aan bij waarom context-engineering een kernvaardigheid aan het worden is die toekomstbestendig is: de ontwikkelaars die winnen met deze tools zijn niet degenen die het snelst typen, het zijn degenen die context en intentie het best structureren.
Als je liever iemand hebt die een complete aangepaste-commando- en agent-setup bouwt die is afgestemd op jouw stack in plaats van het zelf samen te stellen, is dat het soort werk dat ik rechtstreeks aanneem — je kunt zien wat ik heb gebouwd op mijn Fiverr-profiel.
Een kort woord over een commando waar mensen naar vragen dat niet bestaat zoals ze denken.
Over "/goal" — een patroon dat je bouwt, geen knop waarop je drukt
Ik krijg vragen over een "/goal"-commando dat je zogenaamd een taak plus een definitie van "klaar" laat instellen en Claude laat doorwerken totdat een tweede agent verifieert dat het compleet is. Ik heb dit zorgvuldig onderzocht, en hier is het eerlijke beeld: er is geen ingebouwd /goal slash-commando in Claude Code dat dit doet. Ik kon het niet bevestigen in de huidige documentatie, en je zou er niet naar moeten zoeken als een standaardfunctie.
Wat wel echt is, is het patroon erachter — en het is een goed patroon. Je kunt absoluut zelf een verificatiegedreven workflow bouwen: een aangepast commando dat Claude een taak geeft plus expliciete "definitie van klaar"-criteria, gecombineerd met een subagent wiens enige taak is om het werk te controleren aan de hand van die criteria voordat het als afgerond wordt verklaard. Dat is iets dat je kunt bouwen, niet iets dat ingebouwd is. (OpenAI's Codex, apart, levert een letterlijk /goal-commando voor autonome runs — ik heb het getest en beschreven hoe het /goal-commando van Codex zich daadwerkelijk gedraagt. Verwar de twee niet; het zijn verschillende tools.)
De conclusie: als een tutorial je een magische Claude Code /goal-knop belooft, wees dan sceptisch. De mogelijkheid is voor jou om samen te stellen met aangepaste commando's en subagenten — wat sowieso flexibeler is.
Nu het kleine spul dat elke sessie stilletjes verbetert.
Omgeving en UX: /statusline en het gereedschap leren kennen
Deze veranderen niet wat Claude doet. Ze veranderen hoeveel ik kan zien terwijl het dat doet — en hoe snel ik functies ontdek waarvan ik niet wist dat ze bestonden.
/statusline — een eenmalige instelling die elke sessie rendeert
/statusline configureert de statusbalk onderaan je terminal, waarmee je zaken kunt weergeven zoals het actieve model, contextverbruik en kosten — zodat je in één oogopslag kunt zien wat er gebeurt zonder te gokken.
Nogmaals een nauwkeurigheidsnoot: mensen schrijven het als "/status line" (twee woorden). Het echte commando is /statusline, één woord, in het aanvulmenu. Je voert het één keer uit, configureert wat je wilt zien, en dan is het er gewoon elke sessie.
Waarom ik de moeite neem: zichtbaarheid van contextverbruik en kosten. Wanneer mijn statusbalk me laat zien hoe vol het contextvenster aan het raken is, weet ik dat het tijd is voor /clear of /compact voordat Claude begint te degraderen — in plaats van de degradatie achteraf op te merken. Het actieve model zien herinnert me eraan of ik op de juiste laag zit voor de taak. Het is een kleine, eenmalige configuratie die een hoop onzichtbare status omzet in iets dat je in een oogwenk kunt aflezen. Voor de diepere filosofie van "alles zien en sturen wat Claude doet" ben ik dieper ingegaan in mijn uiteenzetting van de agentische OS visuele laag.
/powerup en /radio — de twee die ik noem maar niet zal oversellen
Twee meer echte commando's, opgenomen voor volledigheid en eerlijkheid.
/powerup (geïntroduceerd in Claude Code v2.1.90) is een interactieve tutorial in de terminal — geanimeerde lessen die elk één ding leren dat Claude Code kan doen dat de meeste mensen missen. Het is oprecht nuttig voor het ontdekken van functies, en ik heb het zijn eigen volledige eerste indruk gegeven in mijn artikel over wat /powerup daadwerkelijk leert, dus ik zal dat hier niet herhalen.
/radio is ook echt, en het is precies wat het klinkt: het opent Claude FM, een lo-fi radiostation dat Anthropic draait, in je browser. Is het een productiviteitscommando? Nee. Gebruik ik het tijdens de saaie delen van een build? Soms. Ik neem het op omdat ik je vertelde dat ik het accurate beeld zou geven, en het accurate beeld is dat het bestaat en het een leuk klein niets is. Behandel het dienovereenkomstig.
Er is ook /btw — een lichtere manier om een zijvraag te stellen of context toe te voegen zonder dat het je hoofdgesprek opblaast, wat lange sessies slanker houdt. Het is een echt mechanisme dat het waard is om te kennen als je jezelf wilt verduidelijken midden in een taak zonder de stroom te laten ontsporen.
Dat is het eerlijke overzicht. Laat me je nu laten zien hoe dit eruitziet wanneer het aan elkaar geregen wordt bij echt werk.
Hoe een echte sessie eruitziet met deze commando's aan elkaar geregen
Commando's in een lijst zijn abstract. Hier is hoe ze daadwerkelijk aan elkaar schakelen op een normale bouwdag voor mij.
Ik open Claude Code in een project. CLAUDE.md laadt automatisch, dus Claude kent al de stack en conventies — ik leg niets opnieuw uit. Ik wil een functie toevoegen, dus ik typ /scope voeg CSV-export toe aan de rapportenpagina. Mijn aangepaste commando treedt in werking: Claude stelt me vier vragen (welke kolommen, welk datumformaat, server-side of client-side generatie, wat de bestandsnaam moet zijn), ik antwoord, het geeft me een vijfstappenplan, ik pas stap drie aan, ik keur goed.
Het bouwt. Halverwege raakt de exportlogica verstrikt met de bestaande paginering en de output klopt niet. Ik ga niet handmatig uitzoeken — ik open /rewind, herstel de code naar vóór de verstrikkeling terwijl ik het gesprek behoud, en zeg "die aanpak conflicteerde met paginering, laten we de volledige dataset apart genereren." Schoon herstel, misschien negentig seconden verloren.
Functie klaar. Ik /clear. Fris venster, projectgeheugen intact, nul verouderde context die doorbloeit naar de volgende taak. Mijn statusbalk — weken geleden eenmalig geconfigureerd met /statusline — laat zien dat ik amper context gebruik, wat precies is hoe een frisse taak zou moeten beginnen.
Drie taken later realiseer ik me dat ik een beslissing nodig heb uit een sessie die ik eerder heb gewist. /resume, kies het uit de lijst, pak wat ik nodig had, ga weer aan het werk.
Vijf commando's. Geen ervan schreef code. Allemaal vormden ze de omstandigheden waaronder de code goed werd geschreven. Dat is het hele punt — de slash-commando's zijn niet het werk, ze zijn de werkplaats.
Het eerlijke deel: waar ik het fout had, en wat je tijd waard is
Laat me eerlijk zijn over de correcties, want het bekijken van een praktijkmens die zijn eigen aannames terugneemt is nuttiger dan een schone lijst die doet alsof alles bevestigd is.
Ik heb te lang /clear behandeld als een verlies in plaats van hygiëne — dat was een echte workflow-belasting die ik maandenlang betaalde. "/plan" als een zelfstandig commando is nieuwer (v2.1.0) dan de Shift+Tab-planmodus waarop het gebouwd is, dus als je op een oudere versie zit, grijp naar de sneltoets. "/statusline" is één woord, niet twee. En het "/goal-commando" dat mensen beschrijven als ingebouwd in Claude Code is dat niet — het is een patroon dat je samenstelt, en het verwarren met het daadwerkelijke /goal-commando van Codex vertroebelt het water. Het "43% kwaliteitsverbetering"-getal dat aan aangepaste commando's wordt gekoppeld heeft geen basis die ik kon vinden, dus ik heb het laten vallen en je verteld waarom in plaats van een niet-verifieerbaar getal te verwerken tot een zelfverzekerde bewering.
Wat oprecht je tijd waard is, in prioriteitsvolgorde: /clear tussen taken (grootste, makkelijkste winst), een aangepast verduidelijk-dan-plan-commando (grootste kwaliteitswinst), /rewind om te herstellen van slechte bewerkingen (grootste stressvermindering), en planmodus voor alles dat ambigu of multi-bestand is (grootste voorkomers van "verkeerde code"). De rest — /resume, /statusline, /compact, /btw — zijn echt, nuttig en het waard om te kennen, maar ze zijn de bijrollen.
Als je Claude Code-sessies momenteel aanvoelen als lange, afdwalende gesprekken die slechter worden naarmate ze langer duren, is de oplossing geen beter model. Het is een schuine streep, vier letters, en de discipline om te wissen wat je niet nodig hebt. Ga deze week één aangepast commando bouwen — het /scope-voorbeeld hierboven, rechtstreeks gekopieerd naar .claude/commands/scope.md — en gebruik het bij je volgende echte taak. De eerste keer dat Claudes verduidelijkende vragen een verkeerde aanname opvangen voordat het verkeerde code wordt, zul je begrijpen waarom ik die schuine streep typ voordat mijn brein de gedachte heeft afgemaakt.
Veelgestelde vragen
Wat is het verschil tussen /clear en /rewind in Claude Code?
/clear wist je huidige gespreksgeschiedenis om een frisse taak te beginnen terwijl je CLAUDE.md-projectgeheugen behouden blijft, terwijl /rewind terugdraait naar een eerder controlepunt binnen een actieve sessie en je code, gesprek of beide kan herstellen. Gebruik /clear wanneer je overschakelt naar een ongerelateerde taak; gebruik /rewind wanneer een bewerking fout ging en je het ongedaan moet maken. Zie het gedeelte over contextbeheer hierboven voor de volledige uiteenzetting.
Verwijdert /clear mijn CLAUDE.md-projectgeheugen?
Nee — /clear verwijdert alleen het actieve gesprek uit het contextvenster; je CLAUDE.md-bestand wordt bij het begin van elke sessie opnieuw geladen, dus het overleeft het wissen. Dat is precies waarom je agressief kunt wissen tussen taken zonder de duurzame context van je project te verliezen, zolang het belangrijke spul in CLAUDE.md staat.
Hoe maak ik een aangepast slash-commando in Claude Code?
Maak een Markdown-bestand in .claude/commands/ (projectgebonden) of ~/.claude/commands/ (persoonlijk), en de bestandsnaam wordt de commandonaam terwijl de inhoud van het bestand de prompt wordt die naar Claude wordt gestuurd. Gebruik de $ARGUMENTS-placeholder om invoer door te geven na de commandonaam. Het volledige /scope verduidelijk-dan-plan-voorbeeld staat in het planningsgedeelte hierboven.
Is er een /plan-commando of is het planmodus in Claude Code?
Beide — planmodus is al lang ingebouwd in de machtigingscyclus (druk twee keer op Shift+Tab), en vanaf Claude Code v2.1.0 is er ook een letterlijk /plan-commando dat dezelfde alleen-lezen planstatus activeert. Als /plan niets doet op jouw setup, zit je waarschijnlijk op een oudere versie; de Shift+Tab-sneltoets werkt altijd.
Is er een ingebouwd /goal-commando in Claude Code?
Nee, er is geen standaard /goal-commando in Claude Code dat een taak uitvoert tot een definitie van "klaar" met automatische verificatie. Die mogelijkheid is een patroon dat je zelf bouwt met een aangepast commando plus een verificatie-subagent. OpenAI's Codex levert een apart /goal-commando, maar dat is een heel ander gereedschap.
Laten we samenwerken
Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows, of het opschalen van je technische infrastructuur? Ik help je graag.
- Fiverr (maatwerkbouw & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (ontwerp & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
