Enterprise-grade Claude Code setup voor teams

Als je Claude Code een week of langer gebruikt hebt, ben je waarschijnlijk tegen dezelfde muur gelopen als ik. De agent is briljant in het abstracte en verrassend onhandig in het specifieke. Hij weet niet hoe jullie team Spring Boot schrijft. Hij weet niet dat security een mening heeft over CSP-headers. Hij weet niet welke commit-stijl, welke branch-naming, welke definitie van "klaar" jullie hanteren. Je kan dat elke sessie opnieuw vertellen. Of je kan het één keer aanleren.

Dit is een post over die tweede optie. Over een klein framework dat ik bouwde, Claude Good Boy, en hoe we het concreet uitwerkten.

Wat is Claude Code precies?

Claude Code is de officiële CLI van Anthropic (zie de Claude Code-documentatie). Een AI-agent die in je terminal draait en meewerkt aan code, commits, docs en processen. Hij leest je repo, past bestanden aan, draait tests, opent PRs, beantwoordt vragen over de codebase. Out of the box is dat al nuttig. De truc is dat hij dramatisch nuttiger wordt zodra je hem niet langer behandelt als een generieke assistent, maar als een teamlid dat je kan trainen.

Het idee

Het idee is makkelijk te formuleren en verrassend glibberig in de praktijk:

De conventies, security-richtlijnen en terugkerende workflows van je team horen op een plek waar de AI ze kan lezen. En die plek moet zichzelf updaten.

De meeste engineering teams hebben al conventies. Die leven in Confluence-pagina's, onboarding-docs, README-bestanden en in de hoofden van senior developers. Het probleem is niet dat de kennis niet bestaat. Het probleem is dat ze niet staat waar het werk gebeurt. Tegen de tijd dat iemand het "wij parameteriseren altijd SQL"-document leest, hebben ze de concat-versie al geschreven.

Claude Code levert daar de juiste primitives voor. Er is een CLAUDE.md voor project-identiteit, een rules/-folder voor guardrails, een SKILL.md-mechanisme voor herbruikbare workflows. In één enkele repo werkt dat prima. Je zet je conventies naast de code, je commit, klaar.

Het wordt pas pijnlijk zodra je in meerdere repo's tegelijk werkt. Backend in de ene, frontend in de andere, infra-scripts in een derde, een klantproject in een vierde. Dezelfde commit-stijl, dezelfde security-reflex, dezelfde definitie van "klaar". En die rules in elke repo apart onderhouden? Dat houdt niemand consequent vol. Wat in repo A wordt aangescherpt, drift in repo B binnen de week weer uit elkaar.

Wat ontbreekt is de gedeelde laag: de team-brede conventiebibliotheek die buiten elk individueel project leeft en met elke developer over al hun repo's mee reist. Da's het gat dat Claude Good Boy vult.

Vier bouwblokken

Voor we naar de uitvoering gaan, helpt de woordenschat. Claude Code geeft je vier manieren om gedrag te sturen.

CLAUDE.md en rules vormen de fundering. Skills en agents erven daarvan. Ze stapelen, ze concurreren niet. Van die vier zijn de twee die er voor team-brede kennisdeling toe doen de rules en de skills. De andere twee zijn project-lokaal of sessie-lokaal. De interessante vraag is dus: hoe bouw je een gedeelde bibliotheek van rules en skills die elke developer op je team automatisch krijgt?

Vier ankers van de uitvoering

Wat is een rule, precies?

Een rule is een korte Markdown-instructie die voor elke prompt in de sessiecontext geladen wordt:

• Zonder paths:-frontmatter: altijd actief.
• Met paths:-frontmatter: enkel actief als er matchende files in scope zijn (bv. **/*.java).
• Klein en uitvoerbaar. Geen uitleg, een instructie.

De path-scoping is het onderschatte stuk. Het betekent dat je honderden rules kan hebben zonder het contextvenster op te blazen. Een Java-rule vuurt alleen als er Java in het spel is. Een Cypress-rule alleen als er E2E-code op tafel ligt.

Wanneer schrijf je een rule? Wanneer de instructie klein is, altijd geldt en niet uit de codebase zelf af te leiden valt. Een voorbeeld dat we voor commits gebruiken:

type(scope): description, Conventional Commits, nooit force-pushen, geen Co-Authored-By. Die rule staat nu voor de agent elke keer iemand een commit vraagt. Hij wordt niet vergeten. Hij drift niet tussen developers.

Wat is een skill?

Een skill is een gestructureerde workflow die Claude stap voor stap volgt voor een specifieke taak:

• Wordt getriggerd via een slash-command (bv. /cs-security-review) of automatisch wanneer Claude herkent dat de skill past.
• Groot genoeg dat je hem niet permanent in sessiecontext wil. Hij laadt on demand.
• Herbruikbaar, geversioneerd, per skill gedocumenteerd in skills/<name>/SKILL.md.

Het helpt om scherp te zijn over wat een skill niet is: niet een permanente instructie (da's een rule), niet een ad-hoc prompt die je één keer typt (een skill is gedeeld en herbruikbaar), niet code die zichzelf draait (een skill stuurt Claude, Claude voert de stappen uit), niet een mini-agent (een skill blijft in dezelfde Claude-sessie).

Wanneer schrijf je een skill? Zodra een taak drie of meer stappen heeft, herhaalbaar is, en je de instructies niet elke keer wil hertypen. Een goed voorbeeld: een skill loodst Claude door "review deze change set tegen onze secure coding checklist, classificeer elke bevinding op severity, en produceer een rapport". Dat is een taak van een halfuur voor een developer. Met een skill is het een slash-command.

Wat het je oplevert

Wat ik niet had zien aankomen toen ik begon: het verandert hoe je over coding standards nadenkt. Coding standards leven meestal in een Confluence-pagina die niemand leest. Of in een linter die de syntactische dingen vangt en de semantische mist. Of in code review, achteraf, nadat de auteur al drie keer de verkeerde keuze maakte.

Wanneer je standaarden leven als Claude Code-rules, gelden ze terwijl de code geschreven wordt. De agent leest ze en schrijft de eerste keer correct. Security-reviews vinden minder bevindingen omdat de agent de slechte patronen niet meer genereert. Onboarding gaat sneller omdat nieuwe devs de conventies niet uit het hoofd moeten leren. De agent past ze toe. Da's het dichtste dat ik tot nu toe ben gekomen bij "we hebben onze standaarden gedocumenteerd" ook echt waarde laten opleveren.

Een paar lessen uit het bouwen ervan

• Korte rules werken beter dan lange rules. Een tweeliner "doe X, nooit Y" verandert gedrag betrouwbaarder dan een paragraaf uitleg. De agent moet niet overtuigd worden. Hij moet verteld worden.
• Path-scoping verandert de rekensom. Zodra rules enkel laden wanneer ze relevant zijn, daalt de kost van een rule toevoegen naar bijna nul. De bibliotheek groeit organisch.
• Skills zijn de grotere hefboom. Rules duwen de agent. Skills geven hem een draaiboek. Een goed geschreven skill maakt van een meeruurs senior-taak een slash-command.
• De sync-hook is wat het echt maakt. Zonder auto-sync heb je een mooie repo die niemand pulled. Met auto-sync heb je een levende conventiebibliotheek.

Probeer het eens

Gebruik je Claude Code op een team, zelfs van twee, dan is er een echt argument om je rules en skills op deze manier te centraliseren. Het patroon werkt of je nu fork wat ik bouwde, de structuur kopieert, of een eigen variant vanaf nul verzint. Het framework is opinionated over hoe je Claude Code je conventies aanleert. Het is bewust niet opinionated over welke die conventies moeten zijn. Bring your own.