CLAUDE.md schreef ik vorige week, het bestand dat Claude Code vertelt hoe jouw project werkt. Vandaag de logische vervolgstap: rules.md.
Het verschil is subtiel maar belangrijk. CLAUDE.md is informatie: dit is mijn project, deze framework, deze conventies. Rules.md is regels: dit mag niet, dit moet altijd, dit is een rode lijn. Claude leest CLAUDE.md als context. Rules.md leest hij als wet.
Voor AI peers en hobbyisten die net voorbij de eerste kennismaking zijn, is dit het bestand dat het verschil maakt tussen "Claude maakt af en toe een fout die ik moet corrigeren" en "Claude maakt nooit meer dezelfde fout twee keer."
Waar staat rules.md?
Rules.md leeft in .claude/rules/ in je project. Niet één bestand, meerdere, op onderwerp.
.claude/
└── rules/
├── tone-of-voice.md
├── testing.md
├── security.md
└── commit-style.mdPer sessie laadt Claude automatisch alle markdown-bestanden uit .claude/rules/. Net als CLAUDE.md gaan ze als context mee in elke prompt, maar ze worden behandeld als hardere richtlijnen, niet als zachte suggesties.
In mijn eigen VNX systeem heb ik vier topic-specifieke rules-bestanden, elk gericht op één rode lijn. Dat werkt veel beter dan één lange rules.md met dertig regels.
Het verschil tussen CLAUDE.md en rules.md (concreet)
CLAUDE.md:
"Dit project gebruikt Tailwind CSS en shadcn/ui voor UI components."
rules.md (.claude/rules/styling.md):
"## Geen inline styles
NOOIT
style={{...}}props in React components. Reden: Tailwind moet de single source of truth blijven voor styling. Bij conflicten: gebruikcn()helper om Tailwind-klassen te combineren."
CLAUDE.md is "wat we gebruiken". Rules.md is "wat je niet mag breken, met reden, en hoe je conflicten oplost".
Drie typen regels die echt werken
Niet elke regel is even effectief. Ik heb in 8 maanden Claude Code gebruik geleerd dat drie soorten regels het verschil maken, en de rest meestal niet.
Type 1, Verboden patronen
Het meest concrete type. "Doe dit nooit." Met een korte reden erbij zodat Claude weet wanneer er uitzonderingen zijn.
## Verboden in productie code
### Geen `console.log` in committed code
Reden: lekt naar productie en vervuilt logs.
Uitzondering: `console.log` in tests of debug-scripts is OK.
### Geen `any` type in TypeScript
Reden: ontkracht het hele typesysteem.
Uitzondering: bij externe APIs zonder types kun je `unknown` gebruiken,
nooit `any`.Werkt omdat: Claude kan een verboden patroon detecteren bij het schrijven en zichzelf bijsturen voordat de fout in jouw code staat.
Type 2, Workflow afdwingen
Niet wat de code zegt, maar wat Claude moet doen voordat hij iets oplevert.
## Workflow regels
### Tests draaien voor commit
VERPLICHT voordat je `git commit` voorstelt:
1. `npm run test:unit`, moet groen zijn
2. `npm run lint`, moet zonder errors zijn
3. `npm run typecheck`, moet zonder errors zijn
Bij falende tests: STOP, rapporteer falen, vraag wat te doen.
NOOIT commits voorstellen met falende tests.Werkt omdat: het maakt het verschil tussen "Claude schrijft code" en "Claude levert geverifieerde code op". De workflow staat letterlijk in zijn instructies.
Type 3, Beslis-regels (wanneer kies je wat)
De moeilijkste, maar vaak de waardevolste. Wat moet Claude doen als er een keuze is?
## Beslisregels: nieuwe component vs bestaande aanpassen
Vraag jezelf in deze volgorde:
1. Bestaat er al een component met >70% overlap qua functionaliteit?
→ Pas die aan, voeg een prop toe. NOOIT een tweede maken.
2. Is dit een eenmalige variant in één pagina?
→ Inline het, geen apart component.
3. Wordt dit op 3+ plekken gebruikt?
→ Maak een herbruikbaar component in `components/ui/`.
4. Bij twijfel: STOP en vraag de operator.Werkt omdat: Claude maakt impliciet keuzes. Door de keuze expliciet te maken voorkom je dat hij steeds je codebase opblaast met varianten van dezelfde component.
Drie regels die NIET werken (en waarom)
Eerlijke tegenhanger. Een paar typen regels die ik heb geprobeerd en weer heb verwijderd.
"Schrijf clean code"
Te vaag. Claude weet niet wat jij verstaat onder "clean". Specifieer in plaats daarvan: maximale functielengte, naamgeving-conventies, comment-stijl.
"Gebruik geen unnecessary abstractions"
Subjectief. Wat is "unnecessary"? Vervang door beslis-regels (zie Type 3 hierboven).
"Test alle edge cases"
Niet handhaafbaar. Schrijf een specifiekere regel: "Voor elke publieke functie minimaal 3 unit tests: happy path, één foutpad, één edge case zoals lege input." Dat is testbaar.
Hoe weet je of rules.md werkt?
Een simpele test: doe wat je vroeger fout zag gaan. Vraag Claude om iets te doen waarvan je weet dat hij eerder de regel zou breken.
Concreet voorbeeld uit mijn praktijk: ik had een regel geen console.log in committed code. Test: ik vraag Claude een snelle debug-uitspoel toe te voegen. Vroeger: console.log("debug:", data); zonder verder commentaar. Met de regel: hij voegt de log toe maar zegt erbij "let op: deze console.log staat in productie-code; wil je dat ik hem omzet naar de logger uit lib/logger.ts of een TODO toevoeg om hem voor de commit te verwijderen?"
Dat is het verschil tussen een AI-assistent en een AI-assistent die jouw standaarden begrijpt.
Mijn rules.md-volgorde
In mijn projecten orden ik altijd zo:
tone-of-voice.md, voor content/copy projecten: hoe schrijf iktesting.md, wanneer wel/niet, welke typessecurity.md, secrets, OWASP, gevoelige datacommit-style.md, conventional commits, breaking changesnaming.md, file/variable conventiesarchitecture.md, patronen we volgen, anti-patronen we vermijden
Niet allemaal in elk project. Per project vraag ik me af: welke 3-4 regelbestanden hebben we echt nodig? Beginnen met te weinig is beter dan met te veel.
Globale rules + path-scoping (advanced)
Net als CLAUDE.md werken rules op meerdere niveaus. Project-rules staan in .claude/rules/. Maar je kunt ook globale rules maken in ~/.claude/rules/ die in elk project actief zijn. Daar zet ik bijvoorbeeld:
voice-profile.md, hoe ik schrijf (geldt in elk project)anti-ai-tics.md, generieke AI-zinnen die ik nooit wil (geldt overal)
En path-scoping is het ene element wat ik in geen enkele tutorial tegenkwam: een rules-bestand kun je laten gelden voor alleen specifieke mappen, via een paar instellingsregels bovenaan het bestand (YAML frontmatter voor wie die term kent). Marketing-buzzwords blokkeer ik in content-mappen, niet in code-mappen. Officieel ondersteund door Claude Code, weinig gebruikt.
De volledige uitleg, inclusief hoe globale identiteit, voice, en anti-AI-rules samenwerken met project-rules, staat in mijn complete-setup blog van 30 mei.
Wat doe je deze week?
Drie acties. 30 minuten elk.
- Maak
.claude/rules/aan in je actieve project. Kies één onderwerp dat je vaak moet corrigeren, bijvoorbeeld testing, of imports, of error handling. Schrijf één regelsbestand met 3-5 regels van Type 1, 2, of 3 hierboven. - Test het. Doe in een nieuwe Claude Code sessie iets waarvan je weet dat de regel relevant is. Werkt het? Niet? Scherp aan.
- Update wekelijks. Iedere keer dat je een correctie geeft die voor altijd zou moeten gelden, leg vast.
Volgende week: hooks in Claude Code, waar ik laat zien hoe je automatische acties kunt triggeren bij elke prompt, een laag dieper dan rules.md.
Veelgestelde vragen
Samenvatting
Rules.md is de stap voorbij CLAUDE.md. Drie type regels werken: verboden patronen, workflow-afdwingers, beslis-regels. Vage regels werken niet, wees specifiek. Update wekelijks op basis van correcties die je geeft.
Doe dit deze week. Het is twee uur werk en bespaart je over een maand uren aan repetitieve correcties, maar dieper dan CLAUDE.md alleen kan.
Lees ook: De 10 Claude Code features die elke developer in 2026 zou moeten gebruiken, de complete roadmap waarin rules.md positie krijgt.
Voor teams die hun complete setup willen professionaliseren: zie AI-architectuur.
Vragen, sparring of feedback over je eigen Claude Code setup? Volg me op LinkedIn, daar deel ik wekelijks build-in-public updates over hoe ik mijn eigen AI-systeem inricht.
Bronnen & referenties
- Claude Code documentation, Memory & Rules
- CLAUDE.md voor beginners (vorige post)
- Claude Code Configuratie: CLAUDE.md, rules en skills
- Eigen praktijk: VNX rules-structuur op GitHub