Hoe ik mijn Claude Code skills zichzelf laat verbeteren

Ik gebruik Claude Code dagelijks voor complexe, herhalende workflows. Een van die workflows is een portfolio-coaching sessie: Claude haalt live koersdata op, controleert al mijn posities tegen een set spelregels, en geeft mij concrete aanbevelingen voor die dag.

De eerste versie van die skill werkte. Maar elke sessie ontdekte ik iets: een stap die onduidelijk was, een databron die beter kon, een aanbeveling die niet actionable genoeg was. Ik paste de skill aan, maar dat was reactief en ongestructureerd.

Toen bouwde ik een feedback loop in.

Wat is een feedback loop in een skill?

Een Claude Code skill is in de kern een set instructies — een markdown-bestand dat beschrijft hoe Claude een taak moet uitvoeren. Die instructies zijn statisch. Zonder expliciete aanpassing blijven ze hetzelfde, ongeacht of ze goed of slecht werken.

Een feedback loop voegt twee stappen toe aan het einde van elke run:

1. Output review — was de output van deze sessie volledig en actionable? Wat ontbrak?
2. Skill review — zijn de instructies die deze output produceerden scherp genoeg? Wat kan beter?

Het resultaat: na elke run presenteert Claude een gestructureerd overzicht van bevindingen en genummerde verbetervoorstellen voor de skill zelf.

Twee lagen, één doel

Ik maak bewust onderscheid tussen twee evaluatielagen:

Laag 1: output review Dit gaat over de kwaliteit van wat Claude die sessie heeft geproduceerd. Waren de aanbevelingen concreet? Heeft Claude alle posities gecheckt? Was de kalender volledig? Dit is een kwaliteitscheck op de uitkomst.

Laag 2: skill review Dit gaat over de kwaliteit van de instructies zelf. Was een stap te vaag geformuleerd? Ontbreekt er een fallback als een databron niet beschikbaar is? Klopt de volgorde van stappen nog? Dit is een kwaliteitscheck op het proces.

De twee lagen zijn bewust gescheiden. Een output kan goed zijn ondanks vage instructies (Claude heeft slim geïmproviseerd), of slecht ondanks scherpe instructies (de data was er gewoon niet). Door ze apart te evalueren zie je waar het werkelijk mis gaat.

De harde regel: goedkeuring vereist

Hier is de meest belangrijke ontwerpbeslissing: Claude past de skill nooit zelf aan.

Na elke run presenteert Claude de bevindingen en genummerde voorstellen:

Feedback run 2026-05-14:

Output review:
- Aanbeveling voor TRIN was niet actionable (geen concrete prijs genoemd)
- Ex-div kalender miste 2 posities uit de standby-lijst

Skil review:
- Stap 4: fallback voor TradingView ontbreekt als koers niet beschikbaar is
- Stap 7: instructie voor standby-posities is te vaag

Voorgestelde aanpassingen:
#1 Stap 4: voeg toe — gebruik IBKR markPrice als fallback als TradingView geen data levert
#2 Stap 7: specificeer — check ex-div kalender ook voor standby-kandidaten

Ik lees de voorstellen, denk erover na, en zeg: "ja, pas #1 en #2 aan" — of "alleen #1, #2 klopt niet." Claude past dan alleen de goedgekeurde punten aan.

Dit is geen bureaucratie. Het is controle. Een AI die zijn eigen instructies aanpast zonder toezicht kan snel in een richting gaan die je niet wilt. Elke aanpassing is traceerbaar en intentioneel.

Wat het in de praktijk oplevert

Na een paar weken zijn concrete verbeteringen die door de feedback loop naar boven kwamen:

• Databronnen geprioriteerd — ex-div datums komen nu uit IBKR Flex XML als eerste bron, dan TradingView, dan een lokaal overzichtsbestand als fallback. Voorheen was de volgorde onduidelijk.
• Preferred stocks en baby bonds — deze instrumenten hebben geen standaard koers in TradingView. De skill gebruikt nu IBKR markPrice als fallback specifiek voor dit type.
• Twijfelgevallen — een sectie in mijn alerts-overzicht die ik eerder had toegevoegd werd niet meegenomen in de analyse. Na één feedback-ronde staat er expliciet in de instructies dat die sectie altijd meegenomen wordt.
• Earnings automatisch ophalen — de skill vroeg me eerst handmatig om earnings-data aan te leveren. Nu haalt Claude die zelf op. Eén stap minder frictie per sessie.

Elk van deze verbeteringen is klein. Maar ze accumuleren. Na twintig sessies is een skill wezenlijk scherper dan na de eerste.

Hoe je dit zelf inbouwt

De implementatie is eenvoudiger dan het klinkt. Voeg aan het einde van je skill-instructies een vast blok toe:

## Feedback loop (elke run)

Evalueer na afloop:

**Output review**
- Was de output volledig en actionable?
- Wat ontbrak of was onduidelijk?

**Skill review**
- Welke stappen waren te vaag of ontbrak een fallback?
- Wat zou de volgende run verbeteren?

Presenteer bevindingen als genummerde voorstellen.
Pas de skill NOOIT zelf aan — wacht op expliciete goedkeuring.

Dat is het. Claude voert de evaluatie uit als onderdeel van elke run. Jij beslist wat er mee gebeurt.

De bredere les

Een skill is geen statisch document. Het is een levend instrument dat mee-evolueert met je werkwijze.

De feedback loop maakt dat evolutie zichtbaar en controleerbaar. Je hoeft niet zelf bij te houden wat er beter kan — Claude signaleert het. Maar jij houdt de regie over wat er daadwerkelijk verandert.

Dat onderscheid — signaleren versus beslissen — is precies hoe ik AI het liefst gebruik.