Claude Code Skills Stack van een Senior Engineer

Claude Code Skills Stack van een Senior Engineer

De eerste keer dat ik een Claude Code-agent een Jira-ticket zag oppakken, de bug reproduceerde in een echte browser, een diagnose stelde, een falende test schreef, de fix uitvoerde, pushte naar main en QA op de hoogte bracht — allemaal zonder dat ik tussendoor het toetsenbord aanraakte — kreeg ik dat ongemakkelijke gevoel dat elke werkende engineer vroeg of laat herkent. Niet “dit gaat mij vervangen.” Eerder: “ik doe hier nu al drie jaar een slechte versie van.”

De engineer die ik bekeek was geen AI-YouTuber. Het was een voormalige senior bij Amazon en Microsoft, nu bezig met het ontwikkelen van een product genaamd BookZ.AI, en hij heeft waarschijnlijk de meest gedisciplineerde Claude Code skills stack gebouwd die ik in 2026 heb gezien. Acht skills. Elk lost een specifiek faalpatroon in de “pure Claude Code”-ervaring op. Samen vormen ze iets dat in de documentatie nauwelijks benoemd wordt: ze veranderen Claude Code van een slimme autocomplete in iets wat meer lijkt op een junior- tot mid-level engineeringteam dat toevallig om 3 uur 's nachts beschikbaar is.

Ik heb het weekend besteed aan het uitpluizen van die stack, het installeren van alle onderdelen, en het testen ervan op een kleine SaaS die ik aan het bouwen ben. Sommige onderdelen leverden echt op. Sommige zijn overschat. De Fixed Ticket-skill verraste me oprecht. De marketingstack — waarvan ik dacht dat het overbodige opsmuk was — bleek het meest onderschatte onderdeel van de hele setup.

Hier volgt de complete analyse: wat elke skill doet, wanneer ik ze inzet, hoe ze combineren, en de plekken waar de pure Claude Code-ervaring zonder deze stack uit elkaar valt.

Waarom "Ruwe" Claude Code Uiteindelijk Breekt

Claude Code op zichzelf is krachtig. Je wijst het naar een repo, beschrijft wat je wilt, en het schrijft code. Dat werkt prima voor een weekendproject. Het begint echter uit elkaar te vallen zodra je codebase een tweede bijdrager krijgt, je de code in productie zet, en er gebruikers komen die bugs opmerken.

De drie faalmodi waar ik steeds opnieuw tegenaan loop:

1. Het slaat stappen over. Ruwe Claude Code schrijft graag zowel de feature als de tests — maar alleen als je streng bent, het op de juiste volgorde vraagt, en de eerste poging weigert. Laat je het z'n gang gaan, dan vervalt het al snel in "vibe coding" — de feature shippen, de tests later schrijven, en refactoren komt daarna, maar de initiële stappen worden zelden herzien.
2. Het verliest context tussen sessies. Elke nieuwe sessie begint blanco. Je projectconventies, je design language, je buggeschiedenis — dat alles moet het telkens opnieuw ontdekken uit CLAUDE.md en wat je erin plakt.
3. Het sluit geen lussen. Het schrijft code, maar draait het die ook daadwerkelijk? Treedt de bug nog steeds op? Is de deployment gelukt? Iemand — meestal ik — moet dat verifiëren, en juist bij die verificatiestap vallen de meeste "AI shipt code"-demo's stilletjes door de mand.

De skills die ik hier behandel zijn geen algemene productiviteitstrucs. Elke skill sluit een specifieke lus. Samen zorgen ze ervoor dat Claude Code zich minder gedraagt als een stagiair met een cafeïneprobleem, en meer als een team dat echt verantwoordelijkheid neemt.

Als je nog geen mentaal model hebt opgebouwd voor wat skills eigenlijk zijn in 2026, lees dan mijn agent skills gids voor Claude Code waarin de onderliggende mechanics worden uitgelegd — dit artikel gaat ervan uit dat je die basis al beheerst en wil zien hoe een productie-stack eruitziet.

Vaardigheid 1: Superkrachten — De Discipline Laag

De basisvaardigheid. Degene zonder welke de andere zeven slechts leukere manieren zijn om chaos te verzenden.

Superkrachten is een open-source Claude Code plugin, gebouwd door obra (Jesse Vincent), die binnen drie maanden na de lancering in januari 2026 meer dan 99k GitHub-sterren behaalde — wat absurd is voor een plugin, en wat iets zegt over hoe groot de vraag is naar precies dit probleem. Kort daarna werd het officieel opgenomen in de Anthropic plugin-marktplaats.

Wat het doet, in één zin: het laat Claude Code een echte senior-engineering workflow volgen in plaats van gewoon wat het snelst lijkt.

De workflow die het afdwingt:

1. Brainstormen — maak van een vage aanvraag een beslissingsspecificatie
2. Specificeren — leg vast wat je daadwerkelijk gaat bouwen, en ook wat je expliciet niet bouwt
3. Plannen — splits het werk op in taken van 2-5 minuten met exacte bestandslocaties
4. TDD — red-green-refactor; tests moeten falen vóór implementatie
5. Subagent Development — elke taak wordt gedraaid in een nieuwe subagent om contextafwijkingen bij langdurige processen te voorkomen
6. Review — geautomatiseerde code review vóórdat iets als gereed wordt beschouwd
7. Afronden — PR aanmaken, branches opschonen, worktree management

Het niet-onderhandelbare deel is de TDD-cyclus. Superkrachten zegt niet "je mag TDD volgen." Het zegt "je gaat TDD volgen," en dwingt dat af via de architectuur van de vaardigheid, niet via vriendelijk geformuleerde instructies. Tests worden als eerste geschreven. Ze moeten falen. Pas daarna mag de implementatie geschreven worden. Als je test in de rode fase niet faalde, markeert de vaardigheid het als een valse green en blokkeert verdere voortgang.

Die ene regel alleen al loste ongeveer 60% van de “Claude schreef code die compileerde maar niet deed wat ik vroeg”-problemen op waarmee ik te maken had. Want als de test was geschreven naar het werkelijke gedrag dat ik wilde, en je zag dat de test faalde voordat de code werd geschreven, dan zorgt de code ervoor dat de test slaagt — of niet. Er is geen tussenweg waarin Claude een functie verzint die iets vaags, maar geen juist resultaat oplevert.

Wanneer ik het gebruik: letterlijk elke sessie waarin ik aan productiecode werk. De enige plek waar ik het niet inzet is bij wegwerpscripts en verkennende notebooks, waar de formaliteiten meer kosten dan ze opleveren.

Als je precies één vaardigheid uit deze hele stack installeert, kies dan deze. Alles in deze post gaat er vanuit dat Superkrachten al doet wat nodig is om de development loop eerlijk te houden. Ik schreef een uitgebreidere review van de Superkrachten-plugin als je dieper wilt duiken in de TDD-handhaving specifiek.

Vaardigheid 2: Skill Creator — De Meta Laag

Hier komt het deel dat mij tot mijn schaamte veel te lang heeft verward: Skill Creator is een vaardigheid die andere vaardigheden bouwt. Het is in wezen de vaardigheid-ontwikkelfabriek.

Anthropic heeft het ontwikkeld. Het wordt geleverd met vier bedieningsmodi: Create, Eval, Improve en Benchmark. Samen dekken die de volledige levenscyclus van een vaardigheid — van "ik heb een idee" tot "ik heb deze vaardigheid getest op een realistische workload en weet of het daadwerkelijk helpt."

Waarom is dit belangrijk? Omdat de echte kracht van het skills-ecosysteem niet ligt in het installeren van de skills van anderen. Het gaat om het samenstellen van je eigen vaardigheden. De senior engineer die BookZ.AI runt, zag Superpowers niet als het eindpunt. Hij gebruikte Superpowers, nam delen van GSD (Get Stuff Done), nam delen van GStack, en bouwde een custom geïntegreerde vaardigheid die precies aansloot op zijn specifieke workflow: zijn favoriete fasering, zijn favoriete testframeworks, zijn gewenste review-cadans.

De bouw-je-eigen aanpak is belangrijk omdat vaardigheden per fase worden toegepast. Je kunt bijvoorbeeld een ander brainstormmodule inbouwen zonder je TDD-fase te verliezen. Je kunt een custom reviewfase toevoegen die de lint-regels van jouw team afdwingt. De Eval-modus van Skill Creator laat je elke versie meten aan de hand van een benchmark — "levert deze bijgewerkte vaardigheid daadwerkelijk betere code op in mijn echte codebase, of krijg ik gewoon meer code?"

Wat de meeste tutorials missen, is hoeveel waarde het Eval-loopje heeft. Een vaardigheid schrijven is eenvoudig. Een vaardigheid schrijven die aantoonbaar betere resultaten oplevert voor jouw werk, dat is het verschil tussen een speelgoedvaardigheid en één die je daadwerkelijk blijft gebruiken.

Wanneer ik het inzet: elke keer dat ik merk dat ik vijf zinnen of meer steeds opnieuw aan het prompten ben over meerdere sessies. Die herhaling is het signaal — er wil een vaardigheid geboren worden.

Skill 3: UI/UX ProMax — Het Design Systeem On Tap

Dit was degene waar ik het meest sceptisch over was. "UI/UX-skill" betekent meestal "willekeurige Tailwind-dashboard." ProMax is juist het tegenovergestelde.

De onderliggende database bevat volgens de officiële skill-documentatie meer dan 50 visuele stijlen, 161 kleurenpaletten, 57 lettertypecombinaties, 161 producttypes, 99 UX-richtlijnen en 25 grafiektypen verspreid over 10 doelstacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui, plain HTML/CSS). De skill wordt automatisch geactiveerd wanneer de taak betrekking heeft op UI-structuur, component-refactor, keuze van het kleursysteem of typografie — je hoeft deze niet handmatig aan te roepen.

Het onderdeel dat mij overtuigde: industrie-specifieke standaardinstellingen. Zeg je "fintech-dashboard," dan worden de stijl-, kleur- en typografiekeuzes van de skill direct beperkt tot wat fintech-dashboards daadwerkelijk gebruiken — high-density tabellen, gedempte paletten die overeind blijven in slecht verlichte handelsruimtes, monospace-typografie voor numerieke contexten. Zeg je "rustige productiviteitsapp," dan verschuiven de defaults naar hoger contrast, royale spatiëring en lettertypen die de ogen niet vermoeien bij lange sessies.

ProMax werkt met Google's "Stitch"-patroon, waarbij je de skill een design.md-bestand aanreikt waarin je de gewenste ervaring beschrijft. Het resultaat is een compleet design system: patronen, kleurentokens, lettertypecombinaties, toegankelijkheidsaudit (standaard minimaal WCAG AA), SEO-metastructuur en budgetten voor prestaties. De Awesome Design MD-repo op GitHub bevat voorgebouwde design.md-voorbeelden voor gangbare producttypes, zodat je niet met een leeg canvas hoeft te beginnen.

De constraint mode is waar het praktisch wordt. Je zegt tegen ProMax: "behoud het bestaande kleurenpalet en de lay-outgrid, maar herontwerp alles binnen die grenzen." En dat respecteert het daadwerkelijk — niet in de zin van "suggereert wijzigingen en hoopt dat je het opmerkt," maar als harde beperkingen waar het niet van afwijkt. Ik testte dit op een bestaande landingspagina waar ik het kleursysteem geweldig vond, maar de hero-sectie haatte. ProMax leverde vijf hero-varianten op die allemaal exact de bestaande tokens gebruikten. Dat is precies de test waarop andere design tools bij mij meestal de mist in gaan.

Wanneer ik het inzet: gloednieuwe UI-werkzaamheden, een rewrite van een landingspagina, of iedere keer dat ik een designbeslissing ga nemen die doorwerkt in de rest van het product. Ik gebruik het niet bij kleine chirurgische bewerkingen aan een al bestaand design system — de meningen van de skill zijn daar niet relevant en het toevoegen ervan levert alleen maar ruis op.

Als je dit leest en denkt "ik heb toch al Figma," dat is prima. Maar de meerwaarde hier is niet het vervangen van Figma. Het is dat Claude Code ontwerp-bewuste beslissingen in de code kan nemen, in plaats van jou te vragen welke kleur die knop moet hebben. Mijn Claude Code AI design system workflow post beschrijft hoe ik ProMax in de rest van mijn pipeline integreer.

Vaardigheid 4: Playwright — De Test-Loop Sluiter

Hier houdt “AI engineer” op een marketingterm te zijn.

Claude Code met de Playwright-integratie kan daadwerkelijk een browser openen, naar je app navigeren, knoppen aanklikken, formulieren invullen, screenshots maken, de DOM lezen en verifiëren of hetgeen het zojuist gebouwd heeft daadwerkelijk werkt. Er zijn twee varianten in omloop: de Microsoft Playwright MCP-server (installeer met claude mcp add playwright npx @playwright/mcp@latest) en community-gebaseerde CLI-skills zoals lackeyjb/playwright-skill.

De keuze tussen CLI en MCP is belangrijker dan veel mensen denken. MCP behoudt persistent browser state — ideaal voor exploratief testen, zelfherstellende tests, lange autonome loops. CLI-gebaseerde skills zijn token-efficiënter — ze roepen Playwright per taak aan en bewaren geen context tussen runs. Voor de “feature schrijven → in een echte browser verifiëren → itereren”-loop die de meeste engineers daadwerkelijk draaien, is CLI doorgaans de betere keus. Voor agent-driven QA-sessies met complexe logica over meerdere paginastaten is MCP juist geschikter.

De demo uit de video van de BookZ.AI engineer maakte dat concreet. Hij gaf Claude Code de opdracht op een Replit-app los te laten die niet van hem was — rauwe URL, geen broncode — en zei “vind bugs.” De skill doorliep wat de maker 16 testfases noemde. Daarbij werden 81 screenshots vastgelegd. Het produceerde een QA-rapport met specifieke, reproduceerbare defecten: gebroken form validatie op een specifiek veld, een modal die de focus verkeerd vasthield, een knop waarvan het klikbare gebied 4px kleiner was dan de visuele weergave. (Alle genoemde cijfers komen uit de walkthrough van de maker — ik heb het kleiner getest op mijn eigen app en toen vond de skill drie echte defects die ik zelf gemist had, maar BookZ-schaal haal ik op mijn setup niet.)

Daarna namen Superpowers en Fixed Ticket het over: sub-agents planden de fixes, schreven falende tests die elk defect reproduceerden, losten deze op, verifieerden ze, committen, en deployden.

Dat is de hele loop. Eén enkele instructie — “vind bugs en los ze op” — en de skills droegen het werk estafette-gewijs over via rollen waar ik normaal drie mensen voor nodig heb.

Wanneer ik het inzet: iedere keer als een feature een UI heeft. Ik koppel het nu ook direct aan CI — een Playwright-gedreven smoketest is een deploy gate voor alles wat de user-facing app raakt.

Skill 5: Telegram — Remote Control

De vaardigheid waarvan ik zeker wist dat ik die nooit zou gebruiken. Drie weken later gebruik ik hem dagelijks.

De installatie is eenvoudig — start Claude Code met claude --channels plugin:telegram@claude-plugins-official, stuur een DM naar de bot, je krijgt een 6-cijferige koppelcode terug, plak die code, klaar. Vanaf dat moment wordt elk bericht dat je vanaf je telefoon naar de bot stuurt doorgestuurd naar je lokale Claude Code-sessie, verwerkt op je echte bestanden, en krijg je antwoord terug via Telegram. Het werk draait op je machine. De controle draag je op zak.

Drie concrete use-cases die het de moeite waard maakten:

1. Lange taken starten op afstand. "Voer de volledige test-suite uit en laat weten of er iets stuk is" stuur ik vanaf een café. Twintig minuten later ontvang ik een notificatie met de samenvatting.
2. Sessie resetten en context wisselen. Je kunt je Claude Code-sessie resetten vanuit Telegram, of wisselen welk project-context actief is. Handig als ik aan het avondeten ineens besef dat ik Claude op het verkeerde repo ben gestart.
3. Cognitieve ontlasting. Ik heb een idee. In plaats van het in een notitie-app te schrijven en het daarna te vergeten, stuur ik het naar de bot. Claude logt het idee in de Obsidian vault van het project (zie volgende skill), voorzien van tags en links, zodat het er morgen nog is.

Het beveiligingsmodel is hier belangrijk. Alleen gekoppelde Telegram-gebruikers kunnen berichten doorsturen. Je moet expliciet --channels aanvinken bij het starten — er is geen permanente "altijd aan het luisteren"-modus, wat een regelrechte ramp zou zijn. Ongeautoriseerde berichten worden stilletjes genegeerd.

Wanneer ik deze skill inzet: elke keer dat ik het huis uitga terwijl er een langdurige taak draait. En steeds vaker, naarmate het ‘offloaden’ een tweede natuur wordt, telkens als er een idee opborrelt dat ik niet wil kwijtraken.

Skill 6: Obsidian — Lichte RAG Zonder de RAG

Dit is degene die mijn kijk op projectgeheugen compleet heeft veranderd.

De Obsidian-skill is afkomstig van kepano — de CEO van Obsidian. Je plaatst het bestand in een map in je vault en Claude Code krijgt zo de mogelijkheid om markdown-notities te lezen, schrijven, taggen en linken in je volledige kennisbasis. Geen vector-database. Geen embeddings-pijplijn. Geen chunk-and-retrieve infrastructuur. Gewoon simpele .md-bestanden met wikilinks.

Het ontwerpprincipe is nét die waar Andrej Karpathy steeds publiekelijk op hamert: traditionele RAG-pijplijnen zijn overkill voor persoonlijk kennismanagement. Het probleem dat RAG oplost — "vind de drie paragrafen in 10.000 documenten die het meest relevant zijn voor deze query" — is níet het vraagstuk waar de meeste engineers daadwerkelijk tegenaan lopen. De meeste engineers hebben 200 notulen, 40 projectplannen en 15 architectuurbeslissingsrecords, en willen die met elkaar kunnen linken met een agent die de graf kan navigeren.

De Obsidian-skill verandert Claude Code in een agent die precies die navigatie kan uitvoeren. Je vraagt: "wat hebben we beslist over de auth-refactor?" De agent doorloopt je vault — leest het ADR, volgt de wikilink naar het vergaderverslag, volgt de wikilink naar het ticket, volgt de wikilink naar de commit — en levert een samenvatting die de specifieke notities citeert. Wanneer er iets nieuws wordt geleerd, schrijft het een nieuwe notitie en linkt die direct terug in het netwerk. De graf groeit met je project.

Het kostenverschil is het onopvallende, maar reële voordeel. Een volwaardige embeddings-pijplijn over een middelgrote kennisbasis brengt aanhoudende rekentijd-kosten met zich mee. Een markdown-vault kost $0 aan compute en is eenvoudig te versiebeheerden met git. Karpathy’s gepubliceerde vergelijking zette ophalen van dezelfde kwaliteit op circa 95% goedkoper dan een conventionele RAG-opzet. Voor een solo-founder of klein team is dat geen afrondingsverschil — het is het verschil tussen "ik heb een kennisbasis" en "ik heb er geen".

Ik draai dit al zo’n zes weken op mijn eigen projecten. Notion is daardoor volledig overbodig geworden. Mijn Karpathy-style Obsidian RAG writeup gaat dieper in op de opzet als je het stap-voor-stap wilt volgen.

Wanneer ik het gebruik: altijd actief. Dit is geen "haal erbij" vaardigheid — het is omgevingsinfrastructuur. Elk project waar ik aan werk krijgt nu een /vault-directory en de skill is standaard actief.

Skill 7: Het Marketing Skill Pack — 43 Vaardigheden Die Ik Bijna Oversloeg

Ik dacht dat dit het zwakste deel van de stack zou zijn. Het is het sterkste.

Dit pack bevat ongeveer 43 Claude Code-vaardigheden die het volledige SaaS-marketinglandschap bestrijken: SEO-onderzoek, keywordplanning, on-page optimalisatie, copy voor landingspagina’s, CRO-experimenten, e-mail nurture sequences, contentstrategie, analytics (GA4-integratie, omzet per kanaal), funnelmonitoring en performance reporting. Anthropic’s eigen marketingplugin levert de slashcommando’s /performance-report, /seo-audit en /email-sequence; het community pack coreyhaines31/marketingskills breidt de mogelijkheden nog verder uit.

De BookZ.AI-engineer claimt dat dit skill pack zijn product van 0 naar 1.000 gebruikers bracht. Ik kan het gebruikersaantal niet onafhankelijk verifiëren — het is zijn interne cijfer en ik rapporteer het als zijn claim, geen benchmark. Wat ik wel kan verifiëren is de richting van wat het pack daadwerkelijk doet: het voert echte audits uit, levert concrete on-page verbeteringen en integreert met GA4 om de attributielus te sluiten. De gerapporteerde Lighthouse-scores van zijn site — SEO 100, Best Practices 100, Accessibility 100, Performance 97 — zijn de cijfers die een bekwame technische marketeer in twee weken gefocust werk kan neerzetten. Dit pack samenvat dat werk naar enkele uren.

Hier is zijn gerapporteerde scorecard:

Het onverwachte: de vaardigheden combineren met engineering. Je kunt /seo-audit uitvoeren op je echte codebase, waarna het specifieke HTML/meta-wijzigingen voorstelt die de engineering skills vervolgens implementeren via de TDD-flow van Superpowers — eerst testen, dan de fix, dan herdeployen, daarna opnieuw auditen. De cirkel is rond. Marketing is geen los workflowonderdeel dat achteraf aan engineering wordt geplakt. Het is dezelfde workflow, met andere vaardigheden.

Als je een solo-founder bent van een SaaS zonder aparte marketeer, doet dit pack waarschijnlijk meer werk per euro dan alles wat je verder geïnstalleerd hebt. Ik schreef een uitgebreider build-a-marketing-team-with-Claude-Code artikel dat direct bovenop deze stack is gebouwd.

Wanneer ik hem inzet: marketingmodus, één keer per week, op vrijdagochtend. Het skill pack voert de audits uit, plant de CRO-experimenten in, stelt de wekelijkse e-mails op. Ik review, keur goed en het wordt verstuurd.

Skill 8: Fixed Ticket — De Bug-Fix Pipeline

Bewaar het beste voor het laatst. Dit is de vaardigheid die mij deed heroverwegen hoe ik denk over takenverdeling voor junior engineers.

Fixed Ticket neemt een Jira-ticket-URL als invoer. Het levert een gedeployde fix en een overdracht naar QA. Elke stap daartussen is geautomatiseerd, met één menselijke checkpoint in de goedkeuringsfase.

Dit is de workflow met zeven fasen, rechtstreeks uit de walkthrough van de maker:

De maker claimt dat deze skill ongeveer 90% van het bug-fixwerk van een junior engineer vervangt. Met dat getal ben ik voorzichtig, omdat het zijn observatie over zijn team is — jouw ervaring zal variëren afhankelijk van codebase-complexiteit, testdekking en de kwaliteit van je Jira-tickets. Een rampzalig Jira-ticket ("app werkt niet, fix het") doet de skill al vastlopen bij Fase 1.

Wat ik na eigen tests kan bevestigen: tickets met een duidelijke reproduceerbare stap en een Sentry-log werden helemaal automatisch afgehandeld zonder dat ik zelf code hoefde te schrijven. Tickets die vaag of architectonisch onduidelijk waren, liepen vast bij Fase 3 (diagnose) en vroegen mij om verduidelijking — precies zoals het hoort. Het verzon geen fix. Het leverde niets verkeerds uit. Het stelde vragen.

De goedkeuringscheckpoint is de belangrijkste feature. Elk fix-plan komt op je bureau voordat er één regel code wordt geschreven. Je ziet de hypothese, de voorgestelde wijziging, de test die toegevoegd wordt en de deployment-target. Jij keurt goed, of stuurt bij. Die ene checkpoint maakt het verschil tussen een "geautomatiseerde bug-pipeline" en een "geautomatiseerde rampenmachine".

Wanneer ik het inzet: de maandagse triage van het Jira-backlog. Ik keur fix-plannen in bulk goed bij de duidelijke tickets, stuur de twijfelgevallen bij, en op woensdag is het backlog zichtbaar kleiner zonder dat ik ergens code voor heb hoeven schrijven.

Hoe de Acht Vaardigheden Zich Combineren

Individueel pakt elke vaardigheid één faalmodus aan. In de stack leveren ze samen iets op dat functioneert als een klein engineeringteam:

• Superpowers is de methodologie. Niet-onderhandelbaar, vormt de basis voor alles.
• Skill Creator is hoe de methodologie wordt aangepast aan jouw werkwijze in plaats van de generieke flow.
• UI/UX ProMax neemt de ontwerpbeslissingen uit handen, zodat jij dat niet hoeft te doen.
• Playwright sluit de cirkel tussen "code is geschreven" en "code werkt."
• Telegram maakt de agent los van het bureau, zodat lange jobs op de achtergrond kunnen draaien.
• Obsidian geeft de agent projectgeheugen zonder infrastructurele afhankelijkheid.
• Het marketingpack sluit de cirkel tussen "product bestaat" en "gebruikers arriveren."
• Fixed Ticket is de compressor van de foutenlevenscyclus — hier vindt de meeste tijdbesparing plaats.

De belangrijkste observatie: geen van deze is een “algemene productiviteitsvaardigheid.” Ze zijn stuk voor stuk doelgericht en pakten elk één specifiek probleem aan dat standaard in de Claude Code-ervaring kapot is. De reden dat deze stack werkt als stack, is dat de oplossingen elkaar niet overlappen — elke oplossing heeft een ander stadium van de productschippipeline in eigendom, en ze vullen elkaar aan in plaats van elkaar tegen te werken.

Als je een vergelijkbare stack wilt bouwen, zou ik ze in deze volgorde installeren:

1. Superpowers (week 1 — doe niks anders tot dit een gewoonte is)
2. Playwright (week 1 — sluit de belangrijkste feedbacklus)
3. Obsidian (week 2 — ambient; instellen en vergeten)
4. Fixed Ticket (week 2 — grootste tijdbesparing op bestaande backlogs)
5. UI/UX ProMax (week 3 — wanneer je met UI werkt)
6. Het marketingpack (week 3 — wanneer je product klaar is voor marketing)
7. Telegram (week 4 — als bovenstaande routine genoeg is om onbemand te laten draaien)
8. Skill Creator (voortdurend — als je je eigen patronen begint te zien, ga bouwen)

Waar Deze Stack Tekortschiet

Tijd voor intellectuele eerlijkheid, want elke "Ik heb 8 skills geïnstalleerd en nu ben ik een 10x engineer"-post is niet waarheidsgetrouw.

De stack is specifiek voor het Claude-ecosysteem. Als jouw team meerdere code-agents gebruikt of je wilt overstapmogelijkheid tussen providers, zit je bij sommige van deze (Superpowers, Skill Creator, de Claude-specifieke plugins) vast aan het platform. De skills die de open Agent Skills-specificatie volgen zijn wél portabeler.

De setupkosten zijn reëel. Niet de installatie — die kost minuten. De kosten zitten in de tijd die je besteedt aan het leren van de conventies van elke skill, het schrijven van de design.md-bestanden, het koppelen van Sentry aan je Jira, het opzetten van de Obsidian vault-structuur, het samenstellen van marketing-baselines. Reken op een week gefocuste setup voordat de stack zichzelf terugbetaalt. Ben je dit aan het evalueren voor een 3-daagse sprint, begin er dan niet aan.

De 90%-junior-vervangingsgraad van Fixed Ticket komt uit de koker van de maker, niet uit universeel bewijs. In mijn codebase lag het eerst rond de 60% en klom het misschien naar 75% nadat ik mijn Jira-hygiëne en Sentry-koppeling had aangescherpt. Dat is nog steeds enorm. Maar het is geen 90%, en ik zou niemand vertrouwen die zegt dat jij op dag één 90% haalt.

De marketing-skills zijn slechts zo goed als je analytics-configuratie. Als GA4 niet correct gekoppeld is, zijn de funnelrapportages waardeloos. Heb je geen tracking van omzet per kanaal, dan zijn de optimalisatie-adviezen een slag in de lucht. Het skill-pack versterkt een juiste setup — het lost een gebroken setup niet op.

Playwright faalt soms. Echte browsers zijn onvoorspelbaar. Iedere setup die hier in CI-pijplijnen op vertrouwt, heeft retry-logica en screenshot-capture bij falen nodig, anders ben je je winst kwijt aan het debuggen van valse negatieven.

Wat Gebeurt Er Als Je Niets Installeert

Je blijft lekker doorcoderen. Je levert features op zonder tests. Je Jira-backlog groeit sneller dan je hem kunt wegwerken. Je landingspagina scoort “Best Practices: 78” in Lighthouse en je houdt jezelf voor dat je het volgende kwartaal wel fixt. Je Obsidian vault telt 14 notities en groeit langzamer dan je het overzicht kwijtraakt. Je stuurt jezelf Telegram-berichten waar je nooit op reageert, omdat er geen agent aan de andere kant zit.

Dat is de Claude Code-ervaring die de meeste engineers in 2026 zullen hebben. Het is productief. Het is écht sneller dan programmeren zonder AI. Maar het is niet kwalitatief anders dan wat een ervaren engineer in 2023 met een goede autocomplete kon doen. De skills stack is wat het verschil maakt — de sprong van “AI helpt me sneller te coderen” naar “AI levert features terwijl ik slaap.”

Ik herinner me dat moment aan het begin nog goed — die Fixed Ticket-skill die live ging terwijl ik zat te kijken. Het ongemakkelijke gevoel is inmiddels verdwenen. Wat ervoor in de plaats kwam: elke uur dat ik deze stack niet aan het werk heb, is een uur waarin ik werk doe dat een goed geconfigureerde agent voor me zou kunnen doen. Dat is de rekensom waar ik steeds op terugkom. Als jij in 2026 als solo-engineer een product oplevert, is de vraag niet of je een skills stack moet installeren. Het is: welke, en hoe snel.

Kies deze week drie skills uit deze lijst. Superpowers, Playwright en Obsidian zijn mijn aanbeveling als je het meeste uit je start wilt halen. Installeer ze vanavond. Gebruik ze maandag. Kom over twee weken terug en vertel me wat jij anders zou doen.

Laten We Samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (ondernemingsoplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io