RijksICTGilde
diff --git a/‎docs/oefeningen.md‎
Lines changed: 1 addition & 1 deletion b/‎docs/oefeningen.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎docs/oefeningen/claude-code.md‎
Lines changed: 9 additions & 9 deletions b/‎docs/oefeningen/claude-code.md‎
Lines changed: 9 additions & 9 deletions
diff --git a/‎docs/oefeningen/plugins-skills-tools.md‎
Lines changed: 11 additions & 11 deletions b/‎docs/oefeningen/plugins-skills-tools.md‎
Lines changed: 11 additions & 11 deletions
@@ -4,7 +4,7 @@ Leren gaat het best door experimenteren in een afgeschermde sandbox. Deze oefeni
 
 ## Vier categorieën
 
-Kies waar je mee aan de slag wil — je voorkennis met Claude Code bepaalt mede je instap.
+Kies waar je mee aan de slag wil — je ervaring met Claude Code bepaalt mede je instap.
 
 1. **[Werken met Claude Code](oefeningen/claude-code.md)** — slash-commands, plan mode, `--dangerously-skip-permissions`, subagents, zelf-review, etc.
 2. **[Plugins, skills en tools](oefeningen/plugins-skills-tools.md)** — wat de meegeleverde overheid-marketplace, `superpowers`, `rtk`, `ralph-loop` en andere features toevoegen aan een kale Claude Code-installatie.
 
@@ -6,11 +6,11 @@ Deze categorie gaat over Claude Code zelf — niet over wat je bouwt, maar over
 
 ### Wanneer gebruik je `/clear` of `/compact`?
 
-**Achtergrond:** Bij lange sessies loopt context vol — Claude haalt details door elkaar of mengt eerdere conclusies door latere antwoorden. `/clear` gooit de context weg; `/compact` laat Claude eerst samenvatten en gaat verder met die samenvatting. Kies `/clear` voor onderwerpwisseling, `/compact` voor doorlopend werk dat te lang werd.
+**Achtergrond:** Bij lange sessies loopt de context vol — Claude haalt details door elkaar of vermengt eerdere conclusies met latere antwoorden. `/clear` gooit de context weg; `/compact` laat Claude eerst samenvatten en gaat verder met die samenvatting. Kies `/clear` voor onderwerpwisseling, `/compact` voor doorlopend werk dat te lang werd.
 
 **Vergelijk:**
-- *Bad practice:* één sessie open houden voor de wc-challenge, daarna een JSON-parser, daarna een bug fixen in de wc-code — Claude trekt conclusies door alle drie de contexten heen.
-- *Good practice:* `/clear` tussen ongerelateerde taken (en als Claude afdwaalt); `/compact` als je context-bar bijna vol is maar je nog in dezelfde taak zit en de rode draad wil behouden.
+- *Bad practice:* één sessie open houden voor de wc-challenge, daarna een JSON-parser, daarna een bug fixen in de wc-code — Claude trekt conclusies over alle drie de contexten heen.
+- *Good practice:* `/clear` tussen ongerelateerde taken (en als Claude afdwaalt); `/compact` als de context bijna vol is maar je nog in dezelfde taak zit en de rode draad wil behouden.
 
 **Probeer zelf:** Kies een eenvoudige challenge van [codingchallenges.fyi](https://codingchallenges.fyi/). Houd één sessie open, wissel midden in de implementatie van onderwerp en ga daarna verder met de challenge — observeer waar Claude afdwaalt. Herhaal met `/clear` op het wisselmoment en vergelijk de kwaliteit. Werk daarna door tot je context merkbaar gevuld is en probeer `/compact`: herken je je eigen aanpak nog in de samenvatting?
 
@@ -20,7 +20,7 @@ Deze categorie gaat over Claude Code zelf — niet over wat je bouwt, maar over
 
 ### Hoe bouw je een goede `CLAUDE.md` op?
 
-**Achtergrond:** `CLAUDE.md` is het per-project instructiebestand dat Claude in elke sessie meeneemt. Een goed bestand vangt projectconventies, pijnpunten, hoe je tests draait en wat Claude juist *niet* moet doen — kort, concreet, niet doublerend met code die hij toch al ziet. `/init` levert een eerste schets; daarna verfijn je hem zelf. Naast project-`CLAUDE.md` bestaat ook een globale `~/.claude/CLAUDE.md` voor instructies die voor al je werk gelden (taalvoorkeur, default review-stijl). De project-versie heeft voorrang bij conflict.
+**Achtergrond:** `CLAUDE.md` is het per-project instructiebestand dat Claude in elke sessie meeneemt. Een goed bestand vangt projectconventies, pijnpunten, hoe je tests draait en wat Claude juist *niet* moet doen — kort, concreet, geen herhaling van code die hij toch al ziet. `/init` levert een eerste schets; daarna verfijn je het zelf. Naast project-`CLAUDE.md` bestaat ook een globale `~/.claude/CLAUDE.md` voor instructies die voor al je werk gelden (taalvoorkeur, default review-stijl). De project-versie heeft voorrang bij conflict.
 
 **Vergelijk:**
 - *Bad practice (leeg):* geen `CLAUDE.md` — Claude moet bij elke sessie raden hoe je tests draait, welke conventies tellen en wat een goede commit-message is. Iedere keer opnieuw uitleggen.
@@ -44,7 +44,7 @@ Voor onderhoud van een groeiend bestand — opschonen, tegenstrijdigheden signal
 
 ### Wat onthoudt Claude tussen sessies via memory?
 
-**Achtergrond:** Naast `CLAUDE.md` heeft Claude Code automatisch geheugen: tijdens je werk noteert hij wat hij in een volgende sessie nuttig acht — een correctie, een conventie die uit een bug bleek, een herhaalde voorkeur. Verschil met `CLAUDE.md`: dat schrijf jij bewust; memory bouwt Claude zelf op. Opslag in `~/.claude/projects/<project>/memory/` — alle worktrees binnen dezelfde repo delen één memory-directory ([Anthropic docs: Storage location](https://code.claude.com/docs/en/memory#storage-location)). Met `/memory` bekijk en bewerk je wat er staat.
+**Achtergrond:** Naast `CLAUDE.md` heeft Claude Code automatisch geheugen: tijdens je werk noteert hij wat hij in een volgende sessie nuttig acht — een correctie, een conventie die uit een bug bleek, een herhaalde voorkeur. Verschil met `CLAUDE.md`: dat schrijf jij bewust; memory bouwt Claude zelf op. Memory wordt opgeslagen in `~/.claude/projects/<project>/memory/` — alle worktrees binnen dezelfde repo delen één memory-directory ([Anthropic docs: Storage location](https://code.claude.com/docs/en/memory#storage-location)). Met `/memory` bekijk en bewerk je wat er staat.
 
 **Vergelijk:**
 - *Bad practice:* dezelfde correctie meerdere sessies geven ("gebruik `pnpm` niet `npm`") — zonder memory blijft Claude de fout maken.
@@ -70,13 +70,13 @@ Deze drie samen geven je een knop om verbruik en kwaliteit per taak af te stemme
 - *Bad practice:* default-instellingen voor alles — Opus + xhigh op een rename verbrandt budget; Haiku op complexe refactor mist diepte.
 - *Good practice:* per taak bewust kiezen — zwaarder model/hogere effort voor planning, ontwerp, complex debuggen; lichter voor mechanische edits, kleine fixes, eenvoudige scripts. `/cost` af en toe checken.
 
-**Probeer zelf:** Pak een challenge en voer dezelfde substantiële taak (feature met meerdere stappen) twee keer uit: één keer op default model+effort, één keer op een lichter model of lager effort-level (effort werkt niet op Haiku). Noteer doorlooptijd en `/cost` van beide. Doe dan ook een lichte taak (typo-fix, rename) op default én omlaag-gezet — zie je verschil?
+**Probeer zelf:** Pak een challenge en voer dezelfde substantiële taak (feature met meerdere stappen) twee keer uit: één keer met de standaardinstellingen voor model en effort, één keer met een lichter model of een lager effort-level (effort werkt niet op Haiku). Noteer doorlooptijd en `/cost` van beide. Doe daarna ook een lichte taak (typo-fix, rename) op de standaardinstellingen én op een lager niveau — zie je verschil?
 
 **Wat je leert:** Je krijgt gevoel voor welke combinatie bij welk soort werk past, en voor de prijs/kwaliteit-curve van het model+effort-paar.
 
 ---
 
-### Wanneer schakelt plan mode iets toe wat je anders mist?
+### Wanneer voegt plan mode iets toe dat je anders mist?
 
 **Achtergrond:** Plan mode dwingt Claude een expliciet plan voor te leggen vóórdat hij code aanpast, zodat jij kunt bijsturen voordat er werk verzet is dat je toch niet wilt.
 
@@ -88,7 +88,7 @@ Deze drie samen geven je een knop om verbruik en kwaliteit per taak af te stemme
 
 **Wat je leert:** Je ervaart wanneer een expliciet plan totale doorlooptijd verlaagt doordat je minder werk hoeft terug te draaien.
 
-> Plan mode en subagents werken vaak goed samen: laat Claude in main het plan opstellen en delen van de uitvoering — typisch breed-zoeken, samenvatten — delegeren aan een subagent. Zie de [subagent-oefening](#wanneer-delegeer-je-aan-een-subagent) hieronder.
+> Plan mode en subagents werken vaak goed samen: laat Claude in de hoofdsessie het plan opstellen en delen van de uitvoering — denk aan brede zoekacties of samenvatten — aan een subagent delegeren. Zie de [subagent-oefening](#wanneer-delegeer-je-aan-een-subagent) hieronder.
 
 ---
 
@@ -139,7 +139,7 @@ Vergelijk wat elke vorm oplevert.
 **Achtergrond:** De Task/Agent-tool start een subagent in een eigen contextvenster. Die doet zijn werk — bestanden zoeken, logs uitpluizen, diff analyseren — en stuurt alleen een samenvatting terug. Verbose tussenstappen (search-output, logregels, file-dumps) belanden niet in jouw hoofdcontext. Bij brede zoektaken op grote codebases scheelt dat vaak ruimte voor de implementatie zelf. Review-plugins zoals `pr-review-toolkit` werken intern via subagents — maar je kunt de Agent-tool ook expliciet zelf inroepen.
 
 **Vergelijk:**
-- *Bad practice:* Claude in je hoofdsessie laten zoeken naar "alle plekken waar functie X aangeroepen wordt" in een grote codebase — `grep`-resultaten en file-fragmenten vullen je context, en de daadwerkelijke fix moet daarna plaatsvinden in een al volgelopen sessie.
+- *Bad practice:* Claude in je hoofdsessie laten zoeken naar "alle plekken waar functie X aangeroepen wordt" in een grote codebase — `grep`-resultaten en file-fragmenten vullen je context, en de daadwerkelijke fix moet daarna plaatsvinden in een sessie waarvan de context al vol is.
 - *Good practice:* "Gebruik een subagent om alle aanroepen van X in kaart te brengen en alleen een lijst van bestand:regel-paren terug te geven" — de zoektocht blijft in de geïsoleerde context, jij krijgt een nette tabel terug en houdt ruimte voor de fix.
 
 **Probeer zelf:** Pak een [codingchallenges.fyi](https://codingchallenges.fyi/)-challenge waar al wat code in zit. Doe dezelfde verkenning twee keer:
 
@@ -1,6 +1,6 @@
 # Oefeningen: plugins, skills en tools
 
-Deze categorie gaat over de skills, plugins en CLI-tools die in de container zitten. Ze bouwen voort op een kale Claude Code-installatie met domeinkennis, gespecialiseerde review-agents en context-optimalisatie. Wie ze bewust inzet haalt meer uit de container dan wie ze links laat liggen.
+Deze categorie gaat over de skills, plugins en CLI-tools die in de container zitten. Ze bouwen voort op een kale Claude Code-installatie met domeinkennis, gespecialiseerde review-agents en context-optimalisatie. Wie ze bewust inzet, haalt meer uit de container dan wie ze links laat liggen.
 
 ## Snelle vs diepe vergelijking
 
@@ -17,7 +17,7 @@ De oefeningen hieronder gebruiken standaard de snelle variant en noemen de diepe
 
 ### Wat doet de overheid-marketplace voor je werk?
 
-**Achtergrond:** De container bevat skills uit `developer-overheid-nl/skills-marketplace`: `standaarden`, `nerds`, `internet`, `geo`, `developer-overheid` en `zad-actions`. Relevant als je werk dicht bij NL-overheidsstandaarden ligt — API-design, authenticatie, berichtenuitwisseling, geodiensten. Zonder deze skills leunt Claude op generieke kennis en mist NL-specifieke regels (problem+json, ADR, OIN, Digikoppeling).
+**Achtergrond:** De container bevat skills uit `developer-overheid-nl/skills-marketplace`: `standaarden`, `nerds`, `internet`, `geo`, `developer-overheid` en `zad-actions`. Deze zijn relevant als je werk dicht bij NL-overheidsstandaarden ligt — API-design, authenticatie, berichtenuitwisseling, geodiensten. Zonder deze skills leunt Claude op generieke kennis en mist hij NL-specifieke regels (problem+json, ADR, OIN, Digikoppeling).
 
 **Vergelijk:**
 - *Bad practice:* REST-API bouwen zonder skills aan te roepen — generieke API zonder ADR, ADR-linting of problem+json.
@@ -38,11 +38,11 @@ Welke skills bij welk werk passen: REST API → `standaarden:ls-api` (ADR/lintin
 
 ### Wanneer voegt rtk (token reduction) merkbaar waarde toe?
 
-**Achtergrond:** `rtk` verkort verbose CLI-output (witruimte, comments, herhalingen) voordat die in Claude's context belandt. Werkt via een hook die commando's automatisch herschrijft (`git status` → `rtk git status`). Helpt bij grote codebases of lange bestanden; bij kleine gerichte vragen weinig extra.
+**Achtergrond:** `rtk` verkort verbose CLI-output (witruimte, comments, herhalingen) voordat die in Claude's context belandt. Het werkt via een hook die commando's automatisch herschrijft (`git status` → `rtk git status`). Dit helpt bij grote codebases of lange bestanden; bij kleine, gerichte vragen voegt het weinig toe.
 
 **Vergelijk:**
-- *Bad practice:* groot project automatisch laden terwijl je 5% nodig hebt — context vol, Claude verliest overzicht.
-- *Good practice:* rtk inzetten op grote bestanden/mappen waar je het exacte relevante deel nog niet weet.
+- *Bad practice:* een groot project automatisch laden terwijl je maar 5% nodig hebt — de context loopt vol en Claude verliest het overzicht.
+- *Good practice:* rtk inzetten op grote bestanden of mappen waar je het exacte relevante deel nog niet weet.
 
 **Probeer zelf:** Pak een lange context (bv. een groot README plus meerdere source-bestanden), stuur dezelfde vraag eenmaal met en eenmaal zonder rtk. Vergelijk de antwoordkwaliteit en het tokenverbruik — gebruik `/cost` om het verschil meetbaar te maken (zie de [oefening over runtime-instellingen](claude-code.md#hoe-stuur-je-per-sessie-het-model-de-denkdiepte-en-de-kosten)). Probeer dit bij [codingchallenges.fyi](https://codingchallenges.fyi/) met een challenge waarvan de codebase al flink gegroeid is.
 
@@ -61,7 +61,7 @@ Welke skills bij welk werk passen: REST API → `standaarden:ls-api` (ADR/lintin
 **Achtergrond:** De `superpowers`-plugin levert process-skills: `brainstorming`, `test-driven-development`, `systematic-debugging`, `writing-plans`, `executing-plans`. Elke skill stuurt Claude's aanpak en redeneer-volgorde, niet alleen de output — dat onderscheidt ze van een gewone prompt-instructie.
 
 **Vergelijk:**
-- *Bad practice:* meteen code schrijven voor een feature die nog niet is uitgedacht — Claude bouwt op aannames die jij later corrigeert, veel herwerk.
+- *Bad practice:* meteen code schrijven voor een feature die nog niet is uitgedacht — Claude bouwt op aannames die jij later corrigeert, met veel extra werk tot gevolg.
 - *Good practice:* `superpowers:brainstorming` vóór de eerste regel code; `systematic-debugging` bij een hardnekkige bug; `test-driven-development` voor algoritmes met duidelijke acceptatiecriteria.
 
 **Probeer zelf:** Pak één van je oefen-challenges van [codingchallenges.fyi](https://codingchallenges.fyi/) en doe hem twee keer:
@@ -79,7 +79,7 @@ Wat verandert aan tempo en kwaliteit?
 
 ### Wat doet de Ralph-loop voor je en wanneer gebruik je hem?
 
-**Achtergrond:** De Ralph-loop, oorspronkelijk beschreven door [Geoffrey Huntley](https://ghuntley.com/ralph/), zet Claude in een loop met dezelfde prompt zodat hij vanzelf blijft itereren tot een taak af is. Perfect voor challenges waar je gewoon wilt dat het eindresultaat er komt zonder dat je zelf elke iteratie hoeft te starten. In deze container zit Anthropic's officiële [`ralph-loop`](https://claude.com/plugins/ralph-loop)-plugin standaard mee (de broncode op GitHub staat onder de naam [`ralph-wiggum`](https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum)). Hij levert de slash-commands `/ralph-loop` en `/cancel-ralph`, een Stop-hook die sessie-exits onderschept, en `--max-iterations` als veiligheidsnet. De [zelf-review-oefening](claude-code.md#wat-verandert-er-als-je-claude-zijn-eigen-werk-laat-reviewen) is een natuurlijke bouwsteen: een sterke review-prompt geeft de loop iets concreets om elke iteratie aan af te meten.
+**Achtergrond:** De Ralph-loop, oorspronkelijk beschreven door [Geoffrey Huntley](https://ghuntley.com/ralph/), zet Claude in een loop met dezelfde prompt zodat hij vanzelf blijft itereren tot een taak af is. Perfect voor challenges waar je gewoon wilt dat het eindresultaat er komt zonder dat je zelf elke iteratie hoeft te starten. In deze container zit Anthropic's officiële [`ralph-loop`](https://claude.com/plugins/ralph-loop)-plugin standaard mee (de broncode op GitHub staat onder de naam [`ralph-wiggum`](https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum)). Deze plugin levert de slash-commands `/ralph-loop` en `/cancel-ralph`, een Stop-hook die sessie-exits onderschept, en `--max-iterations` als veiligheidsnet. De [zelf-review-oefening](claude-code.md#wat-verandert-er-als-je-claude-zijn-eigen-werk-laat-reviewen) is een natuurlijke bouwsteen: een sterke review-prompt geeft de loop iets concreets om elke iteratie aan af te meten.
 
 **Vergelijk:**
 - *Bad practice:* een vage prompt loslaten zonder iteratielimiet — Claude itereert eindeloos zonder richting, verbrandt tokens en convergeert niet.
@@ -135,15 +135,15 @@ Gebruik voor de codebase een [codingchallenges.fyi](https://codingchallenges.fyi
 
 ### Wanneer helpt `caveman` en wanneer hindert het?
 
-**Achtergrond:** `caveman` (third-party) drukt Claude's antwoordstijl in ultra-compacte vorm: lidwoorden weg, fragmenten oké, geen beleefdheidsfrasen. Doel ~75% token-reductie in output. Helpt bij iteratieve debug-loops met korte beurten; werkt tegen bij uitleg, code review of onboarding waar volledige zinnen de leesbaarheid bepalen. Heeft niveaus (licht tot chinese tekens) en is mid-sessie te schakelen.
+**Achtergrond:** `caveman` (third-party) drukt Claude's antwoordstijl in een ultra-compacte vorm: lidwoorden weglaten, fragmenten zijn toegestaan, geen beleefdheidsfrasen. Het doel is ~75% token-reductie in de output. Helpt bij iteratieve debug-loops met korte beurten; werkt tegen je bij uitleg, code review of onboarding waar volledige zinnen de leesbaarheid bepalen. De plugin heeft niveaus (van licht tot chinese tekens) en is tijdens een sessie te schakelen.
 
 **Vergelijk:**
-- *Bad practice:* caveman aan tijdens lange architectuur-uitleg of code review — moeilijk leesbaar voor collega's; *waarom*-details verdwijnen tussen de fragmenten.
-- *Good practice:* caveman aan tijdens snelle debug-cyclus (10+ korte beurten); uit zodra je een schrijftaak doet (commit, PR-beschrijving, ticket-uitleg).
+- *Bad practice:* caveman aan tijdens lange architectuur-uitleg of code review — moeilijk leesbaar voor collega's; *waarom*-details gaan tussen de fragmenten verloren.
+- *Good practice:* caveman aan tijdens een snelle debug-cyclus (10+ korte beurten); uit zodra je een schrijftaak doet (commit, PR-beschrijving, ticket-uitleg).
 
 **Probeer zelf:** Doe één sessie in twee helften:
 
-1. Caveman aan: start met `/caveman full`. Werk 10–15 minuten aan een iteratieve taak (bv. een bug stap voor stap pinpointen, of een functie tot tests groen krijgen). Let op tempo en token-verbruik.
+1. Caveman aan: start met `/caveman full`. Werk 10–15 minuten aan een iteratieve taak (bv. een bug stap voor stap pinpointen, of een functie zo aanpassen dat de tests slagen). Let op tempo en token-verbruik.
 2. Caveman uit: vraag Claude in chat "stop caveman" (chat-instructie, geen shell-commando). Doe daarna een uitleg- of review-taak (bv. "leg uit waarom deze test faalde" of "review deze diff"). Vergelijk leesbaarheid en informatiedichtheid.
 
 Voor een zuiverder vergelijking (zonder de skill-discovery hook): `claude plugin disable caveman` en herstart Claude — dan is de plugin volledig stil.