Claude Code Automatisering: Hooks, Skills en Rules Uitgelegd
Je gebruikt Claude Code al een tijdje. Het leest je bestanden, schrijft code, voert commando's uit. Dat is goed. Maar je doet nog steeds handmatig dingen die automatisch zouden kunnen — code formatteren na elke bewerking, gevaarlijke commando's controleren voordat ze draaien, hetzelfde meerstaps deploy-proces keer op keer doorlopen.
Claude Code heeft drie systemen die dit oplossen: hooks, skills en rules. Slechts 12% van de setups in onze analyse gebruikt hooks, maar die behalen gemiddeld 6.8/10 versus 2.1 zonder. Het verschil is niet klein — en de setup is niet moeilijk.
Laten we beginnen met iets concreets.
Je eerste hook: elk bestand dat Claude aanraakt automatisch formatteren
Hier is het probleem. Claude bewerkt een TypeScript-bestand. De code werkt, maar de opmaak klopt niet — verkeerde inspringing, ontbrekende puntkomma's, wat je Prettier-configuratie ook afdwingt. Je vraagt Claude de opmaak te fixen. Dat is een verspilde beurt.
Laten we in plaats daarvan formattering automatisch laten gebeuren na elke bewerking.
Maak dit bestand aan op .claude/hooks/format-on-save.sh:
#!/bin/bash
# Draait nadat Claude een bestand bewerkt of aanmaakt
INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.input.file_path // empty')
if [ -z "$FILE" ]; then
exit 0
fi
# Formatteren op basis van bestandstype
case "$FILE" in
*.ts|*.tsx|*.js|*.jsx)
npx prettier --write "$FILE" 2>/dev/null
;;
*.py)
ruff format "$FILE" 2>/dev/null
;;
*.go)
gofmt -w "$FILE" 2>/dev/null
;;
esac
Maak het uitvoerbaar:
chmod +x .claude/hooks/format-on-save.sh
Registreer het nu in .claude/settings.json:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"command": ".claude/hooks/format-on-save.sh"
}
]
}
}
Dat is alles. De volgende keer dat Claude een bestand bewerkt, draait Prettier (of ruff, of gofmt) automatisch. Geen extra prompts, geen handmatig opruimen.
Probeer het. Vraag Claude om een eenvoudige functie te maken in een TypeScript-bestand. Let op de uitvoer — het bestand wordt automatisch geformateerd na de bewerking. Je hoeft nooit meer aan formattering te denken.
Wat zijn hooks, skills en rules precies?
Voordat we verder gaan, laten we het mentale model verduidelijken. Deze drie dingen verwarren bijna iedereen in het begin, dus hier is de korte versie:
- Hooks draaien code voor of na elke tool-aanroep. Ze zijn automatisch — jij activeert ze niet, ze vuren gewoon. Denk aan "event listeners".
- Skills zijn slash-commando's die je intypt.
/deploy,/review,/ticket PROJ-123. Ze verpakken een meerstaps-workflow die je op naam kunt activeren. - Rules zijn instructies die automatisch laden op basis van welke bestanden Claude bewerkt. Wanneer Claude een
.tsx-bestand aanraakt, verschijnen je frontend-rules. Wanneer het SQL raakt, verschijnen je database-rules.
| Functie | Wanneer het draait | Wat het doet | Activeer jij het? |
|---|---|---|---|
| Hooks | Voor/na elke tool-aanroep | Onderscheppen, blokkeren of transformeren | Nee — automatisch |
| Skills | Wanneer je een slash-commando typt | Meerstaps-workflow uitvoeren | Ja — jij roept het aan |
| Rules | Wanneer Claude overeenkomende bestanden raakt | Bestandsspecifieke instructies injecteren | Nee — automatisch |
Laten we nu elk in detail bekijken.
Hooks: het vangnet en de automatische piloot
Een hook is een shell-script dat Claude Code op een specifiek moment uitvoert. Er zijn vier typen:
- PreToolUse — draait voor een tool-aanroep. Kan deze blokkeren.
- PostToolUse — draait na een tool-aanroep. Kan de uitvoer transformeren.
- Stop — draait wanneer Claude zijn beurt afrondt.
- SessionStart — draait eenmalig bij het starten van een sessie.
Je hebt PostToolUse al gezien met de formatter. Laten we de belangrijkste bekijken: een beveiligingsguard.
De PreToolUse beveiligingsguard
Deze hook vangt gevaarlijke commando's op voordat ze worden uitgevoerd. Kopieer dit naar .claude/hooks/pre-tool-guard.sh:
#!/bin/bash
# Destructieve shell-commando's blokkeren
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool')
COMMAND=$(echo "$INPUT" | jq -r '.input.command // empty')
if [ "$TOOL" = "Bash" ]; then
if echo "$COMMAND" | grep -qE 'rm -rf /|git push --force|git reset --hard|DROP TABLE'; then
echo '{"blocked": true, "reason": "Destructief commando geblokkeerd door beveiligingsguard"}'
exit 0
fi
fi
echo '{"blocked": false}'
chmod +x .claude/hooks/pre-tool-guard.sh
Registreer het in settings.json:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"command": ".claude/hooks/pre-tool-guard.sh"
}
]
}
}
Als Claude nu rm -rf / of git push --force probeert uit te voeren, onderschept de hook het, retourneert blocked: true, en Claude ziet de reden. Het commando wordt nooit uitgevoerd.
Je kunt het nu testen zonder Claude:
echo '{"tool":"Bash","input":{"command":"rm -rf /"}}' | .claude/hooks/pre-tool-guard.sh
Je zou {"blocked": true, "reason": "Destructief commando geblokkeerd door beveiligingsguard"} moeten zien. Je vangnet werkt.
SessionStart: Claude vanaf het begin context geven
Deze hook draait eenmalig wanneer je Claude Code opent. Perfect om context te injecteren die Claude helpt zich te oriënteren:
#!/bin/bash
# .claude/hooks/session-start.sh
echo "## Huidige Git-status"
echo "Branch: $(git branch --show-current)"
echo "Laatste commit: $(git log --oneline -1)"
echo "Gewijzigde bestanden:"
git status --short
echo ""
echo "## Recente TODOs"
grep -r "TODO\|FIXME\|HACK" src/ --include="*.ts" -l 2>/dev/null | head -10
Elke sessie begint met Claude die weet op welke branch je zit, wat de laatste commit was, en welke bestanden open TODOs hebben. Geen "op welke branch zit ik?" meer als eerste vraag.
Skills: je persoonlijke slash-commando's
Hier wordt het leuk. Je schrijft een markdown-bestand dat een workflow beschrijft, en het wordt een slash-commando dat je op elk moment kunt intypen.
Je eerste skill: een deploy-commando
Maak .claude/skills/deploy.md aan:
---
name: deploy
description: De huidige branch deployen naar staging of productie
---
# Deploy Workflow
1. `npm run build` uitvoeren om de build te verifiëren
2. `npm run test` uitvoeren om alle tests te bevestigen
3. Huidige branch controleren: `git branch --show-current`
4. Als op `main`:
- Naar productie deployen: `railway up --service production`
- Health check verifiëren: `curl -s https://api.example.com/health`
5. Als op andere branch:
- Naar staging deployen: `railway up --service staging`
- Staging-URL tonen voor review
Altijd de deployment-status en URL melden.
Typ /deploy in Claude Code. Claude bouwt, test, controleert de branch, deployt naar de juiste omgeving, en verifieert de health check. Eén commando in plaats van vijf handmatige stappen.
Een code review skill
Deze is praktisch voor dagelijks gebruik. Sla op als .claude/skills/review.md:
---
name: review
description: Staged wijzigingen reviewen voor commit
---
# Code Review
1. `git diff --staged` uitvoeren om alle wijzigingen te zien
2. Per bestand controleren:
- Foutafhandeling: zijn async operaties in try/catch?
- Beveiliging: hardcoded secrets, SQL-injectie of XSS?
- Types: zijn er `any` die specifiek moeten zijn?
- Tests: hebben gewijzigde functies test-updates?
3. Mechanische problemen AUTO-FIXEN (opmaak, ontbrekende types, duidelijke bugs)
4. KRITIEKE issues (moet opgelost) en INFORMATIEVE (overweeg) rapporteren
5. Als geen kritieke issues: een commit-bericht voorstellen
Typ /review voor het committen en Claude controleert je werk. Mechanische problemen worden automatisch opgelost. Ambigue beslissingen worden gemarkeerd zodat jij beslist.
Skills die argumenten accepteren
Skills kunnen invoer ontvangen. Sla op als .claude/skills/ticket.md:
---
name: ticket
description: Werk starten aan een specifiek ticket
---
De gebruiker geeft een ticket-ID (bijv. `/ticket PROJ-123`).
1. Ticketdetails ophalen van de issue tracker
2. Nieuwe branch aanmaken: `git checkout -b feat/PROJ-123-beschrijving`
3. Relevante bestanden uit het ticket lezen
4. Implementatieplan voorstellen voor er code geschreven wordt
5. Op goedkeuring wachten voor verder te gaan
Typ /ticket PROJ-123 en Claude leest het ticket, maakt een branch aan, vindt de relevante bestanden, en stelt een plan voor — allemaal voordat er een enkele regel code geschreven wordt.
Rules: instructies die op het juiste moment laden
Je kent rules al van de setup-handleiding. Hier is waarom ze belangrijk zijn voor automatisering: ze houden Claudes context schoon.
Stel je voor dat je 200 regels frontend-conventies hebt, 150 regels backend-rules en 100 regels database-standaarden. Als je alle 450 regels in CLAUDE.md zet, laadt Claude alles bij elke interactie — zelfs wanneer je alleen een CSS-bestand bewerkt.
Met rules laadt Claude de frontend-conventies alleen bij .tsx-bestanden, database-rules alleen bij migraties, en beveiligingswaarschuwingen alleen bij gevoelige bestanden.
Hier is een beveiligingsrule die ertoe doet:
<!-- .claude/rules/security.md -->
---
globs: [".env*", "*.pem", "*.key", "*secret*", "*credential*"]
---
- Dit bestand NOOIT committen naar versiebeheer
- De inhoud van dit bestand NOOIT loggen
- Deze waarden NOOIT opnemen in foutmeldingen of API-responses
- Als dit bestand gewijzigd moet worden, leg uit welke wijzigingen nodig zijn maar toon de huidige waarden niet
Wanneer Claude een bestand raakt dat aan die patronen voldoet, verschijnen deze rules automatisch. Wanneer het aan ongerelateerde code werkt, blijven ze op de achtergrond.
Het spiekbriefje: wanneer wat gebruiken
Dit is de vraag die iedereen stelt. Zo beslis je:
Gebruik een hook wanneer de actie elke keer moet gebeuren, zonder dat iemand eraan hoeft te denken. Formatteren bij opslaan. Gevaarlijke commando's blokkeren. Elke tool-aanroep loggen. Als een mens er niet aan zou moeten denken, is het een hook.
Gebruik een skill wanneer je een meerstaps-proces hebt dat je regelmatig herhaalt. Deployen. Code reviewen. Nieuw ticket starten. Migratie schrijven. Als je er een checklist voor zou schrijven, is het een skill.
Gebruik een rule wanneer de instructies afhangen van aan welk bestand Claude werkt. Frontend-conventies voor .tsx-bestanden. SQL-beveiliging voor migraties. Beveiligingswaarschuwingen voor .env-bestanden. Als het advies is "wanneer je aan X werkt, volg deze richtlijnen", is het een rule.
Alle drie combineren: een voorbeeld uit de praktijk
Zo werken hooks, skills en rules samen bij een database-migratie workflow:
-
Rule (
.claude/rules/database.md) — wanneer Claude migratiebestanden raakt, laadt het automatisch je conventies: geparametriseerde queries, rollback-vereisten, naamgevingspatronen. -
Hook (PreToolUse op
Bash) — als Claude een migratie-commando probeert, controleert de hook of er een rollback-bestand bestaat. Blokkeert het commando als er geen rollback is. -
Skill (
/migrate) — een slash-commando dat het migratiebestand aanmaakt vanuit een template, de bijbehorende rollback genereert, tegen een testdatabase draait, en het resultaat rapporteert.
De rule levert de kennis. De hook handhaaft de beperking. De skill verpakt de workflow. Elk onderdeel doet één ding goed.
Wanneer dingen niet werken
Als je hooks, skills of rules niet activeren, zo debug je:
# Claude in verbose modus draaien om hook-uitvoering te zien
claude --verbose
# Een hook onafhankelijk testen
echo '{"tool":"Bash","input":{"command":"rm -rf /"}}' | .claude/hooks/pre-tool-guard.sh
De gebruikelijke verdachten:
- Hook-script zonder uitvoerrechten. Fix met
chmod +x .claude/hooks/jouw-hook.sh - Glob-patroon dat niet matcht. Het patroon
**/api/**/*.tsverschilt vanapi/**/*.ts. Test het jouwe tegen echte bestandspaden. - Skill niet gevonden. Zorg dat het in
.claude/skills/staat met de juistename:in de frontmatter.
Wat je hebt gebouwd
Als je hebt meegedaan, heb je nu:
- Een beveiligingsguard die destructieve commando's blokkeert voordat ze draaien
- Een auto-formatter die elk bestand opruimt dat Claude aanraakt
- Een deploy-skill die je hele deploy-workflow in één commando verpakt
- Een review-skill die je code controleert voordat je commit
- Rules die de juiste conventies op het juiste moment injecteren
De meeste Claude Code gebruikers komen hier nooit. Je hebt zojuist een op maat gemaakte ontwikkelomgeving gebouwd die automatisch voor je werkt.
Klaar voor meer? Hier ga je naartoe:
- Claude verbinden met je tools — MCP-servers die Claude je database laten bevragen, GitHub doorzoeken en Sentry-fouten ophalen
- Geavanceerde workflow-patronen — subagents, parallelle uitvoering en de debugging-patronen van power users
- Beoordeel je setup om te zien waar je automatisering precies staat
Veelgestelde vragen
Vertragen hooks de boel?
Een eenvoudige grep-gebaseerde beveiligingsguard voegt 10-50 milliseconden toe per tool-aanroep — je merkt het niet. Maar een PostToolUse-hook die Prettier draait voegt 200-500ms toe per bewerking. Houd hooks snel. Als een hook zwaar werk moet doen, draai het proces op de achtergrond zodat Claude niet wacht.
Kan ik hooks delen over al mijn projecten?
Ja. Plaats gedeelde hooks in ~/.claude/hooks/ en verwijs ernaar met absolute paden in je globale ~/.claude/settings.json. Projectspecifieke hooks gaan in .claude/hooks/ met relatieve paden in de projectinstellingen.
Wat gebeurt er als een hook crasht?
Claude Code vangt hook-fouten op en gaat door alsof de hook niet bestaat — de tool-aanroep draait normaal. De fout verschijnt in verbose modus. Dit is safety-first design: een kapotte hook voorkomt nooit dat Claude werkt. Maar test je hooks grondig — een kapotte beveiligingsguard die stil faalt is erger dan helemaal geen guard.
Kan een skill een andere skill aanroepen?
Niet rechtstreeks. Er is geen mechanisme waarbij /deploy automatisch /review aanroept. Als je een samengestelde workflow nodig hebt, bouw dan één skill die alle stappen bevat. Of gebruik een hook om extra logica te triggeren nadat een skill klaar is.
Hoe werken rules samen met CLAUDE.md?
Beide worden in de context geladen, en Claude volgt alles. Als een rule iets in CLAUDE.md tegenspreekt, wint meestal de specifiekere instructie. Maar vermijd tegenspraken om te beginnen — gebruik CLAUDE.md voor projectbrede instructies en rules voor bestandsspecifieke overschrijvingen.