Vincent van Deth 

A year ago I bolted a small helper onto another project. For fun. No plan, no framework in mind. One thing annoyed me, so I automated it.

What kept me up was not whether the AI could write code. It could do that already. It was a different question: what exactly did it do, who looked at it, and can I reconstruct that a month from now?

So I followed that one question. Evening after evening. Solo.

Today that helper is VNX, and I am open-sourcing it as 1.0.

## What it actually is

> 📖 **Read also:** **[Glass-Box Governance: why your AI orchestrator should treat the receipt ledger as the database](/blog/2026-05-03-glass-box-governance-receipt-ledger-database)**: the governance model VNX 1.0 is built on

VNX is a local control plane for AI coding CLIs. Not a framework you import. A runtime that drives the CLI tools already on your machine.

Each piece of work becomes a dispatch. Each dispatch gets an isolated tmux worker and its own git worktree. Work passes through human and reviewer gates. Every dispatch produces an append-only, hash-chained NDJSON receipt, so there is a forensic trail from dispatch to review to merge.

It drives Claude Code, Codex CLI, Gemini CLI, Kimi CLI, OpenRouter, and local Ollama. Not through vendor SDK imports. The runtime drives the provider CLIs directly, and provider constraints live in a machine-readable YAML so routing can pick a capable lane per dispatch.

The gap I kept hitting: everyone is building AI agents. Almost nobody is building a control plane for the AI CLI tools already installed on your machine. That is the thing I needed, so that is what I built.

## What works today

I am going to be precise about maturity, because a launch is the wrong place to overclaim. These pieces are in production and have evidence behind them:

- Append-only, hash-chained [NDJSON receipts](/blog/ndjson-receipt-ledger-ai-audit-trail). Thousands of them in my own ledger. Tamper-evident by chain, not by trust.
- A multi-CLI provider hub. Claude, Codex and Kimi all produce receipts in the same shape. No vendor SDK imports.
- Review gates. Codex and Gemini review dispatches before merge. I gated this release's own pull requests through them.
- Per-dispatch git worktree isolation, with a teardown classifier that distinguishes clean, committed, and dirty worktrees instead of treating cleanup as one state.
- An interactive tmux worker lane, a provider-constraint YAML as the single source of truth, deterministic context injection with a repo map, and cost tracking per provider.
- Memory in two tenses that hold up: the receipt ledger is the past, a SQLite WAL database is the live present.

One honest caveat inside this tier: provider maturity varies per lane, and worktree creation is solid for a single dispatch but races under parallel creation. I know exactly where that edge is, because I hit it building this.

> 📖 **Read also:** **[Why architecture beats models: lessons from 2400+ AI agent dispatches](/blog/architecture-beats-models-ai-agent-dispatches)**: the dispatch-level evidence behind VNX's design decisions

## What is opt-in and still burning in

These ship, but off by default. They work mechanically. They are not battle-tested enough for me to call them proven:

- Cost-aware routing that picks the cheapest capable model per dispatch.
- An elastic worker pool.
- A track layer for planning work, and a roadmap autopilot that advances features under human gates. The autopilot ships dark.
- A self-learning loop that consolidates past review findings into context for future dispatches.
- The future tense of memory: a roadmap graph the system can plan against.

If you turn these on, treat them as experimental. I do.

## What is designed but not built

True parallel execution of multiple feature tracks at once. I designed it this week with three independent model reviews, and the design is honest about what is missing: a wave scheduler, a merge lease, and verified file-scope enforcement. It is on the roadmap. It does not work yet, and I am not going to pretend otherwise.

## Where this came from

VNX was incubated inside a private product repository before it became its own project. The early evolution is not publicly replayable commit by commit. The public repository is the extraction, hardening, and packaging.

I wrote that history down before launch, in the repository, as an evolution timeline. The casual tinkering started about a year ago. The serious architecture is roughly six months. The public repo is about three and a half months old and 1027 commits in. A project about provenance should be able to show its own.

## The timely part

On June 15, 2026, Anthropic moves headless `claude -p` and Agent SDK usage to API credits, while interactive Claude Code stays on the subscription. VNX's default Claude lane runs as interactive tmux operation, so it is built around the interactive product path rather than the headless SDK path. That has cost consequences. I am not claiming it is a loophole or future-proof. It is a consequence of using CLIs as workers, and vendors can change terms.

## What this is not

It is not a security sandbox. It isolates work with tmux sessions and git worktrees, not hostile code. It is not compliance certification. It produces a local forensic audit trail, not a legal attestation. It is optimized for human-gated coding workflows, not fully autonomous merges.

## Try it

It is pip-installable, has 6,200+ tests, and ships sample receipts you can inspect as NDJSON. It is open source because the architecture is portable, not because I am running a company on it.

I would most value feedback on the audit model, the provider-constraint YAML, and whether the install path makes sense from a clean machine.

The best thing I built started as a joke I could not let go of. Here it is.

[VNX repo](https://github.com/Vinix24/vnx-orchestration) is open source. If you want to build something similar for your own organisation, see [my AI architecture work](/ai-architectuur).

vnx open source control plane ai cli cover

large_vnx-open-source-control-plane-ai-cli_cover

medium_vnx-open-source-control-plane-ai-cli_cover

small_vnx-open-source-control-plane-ai-cli_cover

thumbnail_vnx-open-source-control-plane-ai-cli_cover

vnx-open-source-control-plane-ai-cli_cover

I Started a Joke Helper a Year Ago. Today I Open-Source It as a Control Plane for AI Coding CLIs.

Thirty-one days. Thirty-two blogs published. One SaaS launch. Multi-AI pipeline running autonomously while I slept.

This is the honest May 2026 build log. What shipped. What slipped. What the receipt ledger actually shows when I run `jq` over the month. The good and the parts I am still working out.

If you have been following along, through the [VNX evolution](/blog/2026-05-01-vnx-evolution-tmux-to-autonomous-orchestrator), the [seven-part NL Claude Code tutorial series](/blog/2026-05-04-claude-md-uitleg-beginners), and the [multi-AI code review deep-dive](/blog/2026-05-11-multi-ai-code-review-codex-gemini-data), this is the recap.

## The numbers

Counted via `wc -l` and `jq` over the receipt ledger. As of May 31, 2026, 18:00 CET:

| Metric | May 2026 |
|--------|----------|
| Blogs published | **32** (target: 31, actual: 32 with the dual May 1 publication) |
| Blog words written | ~46,000 |
| Languages | NL: 22, EN: 10 |
| Categories covered | 5 (EN VNX, NL Claude tutorials, NL MKB GEO/AEO, Mission Control, Opinion/Listicles) |
| New dispatches in receipt ledger (May only) | 1,847 |
| Dispatches across all repos in May | ~3,200 |
| Cost (Claude + Codex + Gemini Vertex) | €146 |
| New skills added | 4 |
| New hooks added | 1 (improved context monitor) |
| PRs merged in VNX repo | 31 |
| SEO tool: paying customers post-launch | (target: 25, actual: see below) |

> 📖 **Read also:** **[From a tmux pane to an autonomous orchestrator: 8 months of VNX](/blog/2026-05-01-vnx-evolution-tmux-to-autonomous-orchestrator)**: the full 8-month build history behind these numbers

## What shipped

The big ones, in order of how proud I am:

### 1. SEO tool 1.0 (May 19), SaaS launch

Eight months of build culminated in a public SaaS launch. SEO crawler with 26 deterministic extractors plus AI-powered actionable suggestions. For MKB and agencies. Not open source.

What worked: launch hype from the GEO/AEO blog cluster (May 2, 6, 14) brought ~340 trial signups in the first 36 hours. Of those, ~150 ran a full scan in the first week.

What slipped: I had targeted 25 paying customers by May 31. Actual: 14. Conversion from trial to paying is taking longer than I projected. Not a disaster, it is the launch, not the steady state. Adjusting messaging in June.

What surprised me: 6 of the first 14 paying customers are agencies (€299/mo tier), not single MKB owners (€39-99/mo tier). That is upside, higher ARR per customer, and changes my June marketing focus.

### 2. The May blog cluster, 32 posts in 31 days

Thirty-two posts. Five thematic threads (EN VNX deep-dive series, NL Claude Code tutorial series, NL MKB GEO/AEO series, Mission Control series, opinion/listicle stack). Multiple posts cross-link into a coherent month of content rather than 32 isolated pieces.

What worked: the [orchestrator pipeline](/blog/2026-05-16-agentic-os-centrale-bediening-bedrijf) ran consistently. Throughput went from 6-8 blogs per month in April to 32 in May without me working more hours. The systems compound.

What slipped: image generation lagged. Most posts have placeholder image references that I will fill in across June. The tooling for that is not where I want it yet.

What surprised me: the [VNX evolution post](/blog/2026-05-01-vnx-evolution-tmux-to-autonomous-orchestrator) became one of the highest-traffic posts of the month. Eight-month build stories outperform individual feature deep-dives, at least in my niche.

### 3. Mission Control V2 → V2.1

The [Telegram-based agentic OS](/blog/2026-05-16-agentic-os-centrale-bediening-bedrijf) went through three minor versions in May. New `/dig` command for on-demand research. Smart URL detection (paste a LinkedIn URL, bot picks the right action). Daily digest improvements.

What worked: I am now using Mission Control for ~75% of all daily operations. It compounds, each new command makes the next one more valuable.

What slipped: multi-user support is still on the roadmap, not shipped. Solo-only for now.

### 4. Autonomous orchestrator metrics

The autonomous mode that shipped on March 17, 2026 is now mature. May numbers:

- Dispatches that passed without my popup approval: ~94%
- Dispatches that fell to popup confirmation: ~6%
- Dispatches that required manual intervention after start: 1.2%
- Mean time from crash → recovery (with [unified supervisor](/blog/2026-05-15-unified-supervisor-self-healing-multi-agent)): 3.2 seconds

That last number is the one I am most pleased with. In April I was still doing manual `kill -9 + UPDATE` cycles. In May the system genuinely self-heals.

Receipts are now provider-aware. Each carries provider, model, and token or cost data. When the supervisor recovers a crashed worker, it now logs which lane failed, not just that "a worker" failed. This matters because the tmux-spawn lane fails differently than the claude-subprocess lane. The idle-worker bug, where the instruction was pasted but never submitted, showed up as a zero-activity receipt from an interactive lane. Provider-aware logging turned a silent stall into a recoverable event.

## What slipped (honest)

Three commitments I missed.

**1. Weekly LinkedIn-post pipeline integration.** I had targeted full integration of the LinkedIn pipeline (intelligence → write → carousel → publish) by May 24. Got it to ~70%. Carousel-builder is not yet skill-orchestrated. Pushing to mid-June.

**2. Multi-language SEO tool support.** Target was DE/FR/ES support by end of May. Slipped. Crawl works for all languages, but AI-suggestion layer for non-NL/EN needs more validation. Realistic: late June or early July.

**3. F57 dispatch parameter tracker analysis.** I shipped the tracker post, but the actual continuous-correlation dashboard is not in production. The data is being recorded; the live analysis is manual jq queries. Building the dashboard in June.

## What surprised me

Three findings that landed differently than I expected.

**One: chat beats dashboard for nearly everything.** I built a Next.js dashboard in March-April. It sees use ~10% of my workflow, max. Telegram chat handles 90%. The dashboard's use case is image review and big-batch operations, and even those I am questioning.

**Two: cross-blog linking matters more than individual post quality.** Posts that weave into a serie (the NL Claude Code tutorial chain, the EN VNX deep-dive series) outperform posts that stand alone, even when individual quality is similar. The compounding is real; the editorial discipline matters.

**Three: codex catches genuine bugs at a rate I underestimated.** The April assessment was that codex finds real bugs on most PRs. May data confirmed: 27 PRs reviewed in May, codex flagged blocking issues on 19. Of those, 14 turned out to be real (data integrity, idempotency, scope leaks). Five were severity-overcalls. Net: codex catches one out of two real-bug-classes I would otherwise have missed.

**Four: the 4-architect panel catches design gaps I miss.** Feature design now runs through codex + kimi + deepseek + opus writing independent plans that I synthesize. Real multi-model design catches contradictions a single model misses. In May, the panel flagged a scope-leak pattern in a new skill before it reached production. Single-model review passed it. The panel did not. That is a different error surface, not just more compute.

> 📖 **Read also:** **[Multi-AI code review at the merge gate: what the data says](/blog/2026-05-11-multi-ai-code-review-codex-gemini-data)**: the Codex + Gemini review setup behind May's 27 PRs

## What I learned about my own pipeline

Three lessons for me, June onward.

**Lesson 1:** Image generation is the bottleneck. My text pipeline is humming. Image creation is still 30-40% of the total time per blog. Investing in image-pipeline improvements has higher ROI than another text-skill.

**Lesson 2:** Niche depth beats topic breadth. The five-track May cluster was actually four tracks deep + one (opinion) shallow. The four deep tracks compounded. The opinion stack felt like overhead. Thinking about cutting to four tracks for June.

**Lesson 3:** Public-facing content + private build velocity is the right ratio. May had ~70% public-facing blog work and ~30% internal VNX/system improvements. That balance feels right, too much private work and the blog suffers; too much public work and the system stops compounding.

**Lesson 4:** Lane choice matters more than model choice for cost. The June 15 Anthropic billing change moves headless `claude -p` to paid API credits while interactive Claude Code stays on subscription. The ephemeral tmux-spawn lane costs zero API dollars but has interactive startup overhead. I am routing batch work to tmux-spawn and urgent dispatches to subprocess. The cost per dispatch is shifting, not just the model.

## What is next (June 2026 sneak preview)

Five priorities, in order:

1. **Image-pipeline improvements**, bring image generation time per blog from 60-90 min to 20-30 min
2. **LinkedIn pipeline full integration**, finish the carousel-builder skill orchestration
3. **SEO tool: multi-language + agency dashboard**, DE/FR/ES, plus Agency-tier UI features
4. **F57 dashboard**, continuous correlation analysis, not manual jq
5. **Mission Control multi-user prototype**, for the SEO tool's agency customers who want a similar interface for their team

Realistic. Not 32 blogs in 30 days again. Probably 18-22 in June, with more focus on image-pipeline and SEO tool growth.

## Sources of the numbers (because trust requires verification)

Every claim above can be verified.

- **Blog count:** `ls Content/blog/2026-05-* | wc -l` → 32
- **Dispatches:** `grep "2026-05".vnx-data/state/t0_receipts.ndjson | wc -l` → 1,847 (in standalone VNX repo only); ~3,200 across both repos combined
- **Cost:** Claude Pro + Codex usage + Vertex Gemini metered → invoices total €146
- **PRs merged:** `gh pr list --state merged --search "merged:2026-05-01..2026-05-31" --repo Vinix24/vnx-orchestration | wc -l` → 31
- **Skills added:** `git log --since="2026-05-01" --oneline -- '.claude/skills/' | wc -l` (filtered to "feat" prefix) → 4

If you want to verify any of these yourself: the [VNX repo](https://github.com/Vinix24/vnx-orchestration) is open source. Run the queries.

## Closing

Thirty-one days. Thirty-two blogs. One SaaS launch. €146 in AI costs. 14 paying SEO-tool customers. A self-healing orchestrator that recovers in seconds. A Telegram interface I use 75% of operations through.

Eight months ago this was a pair of tmux panes copy-pasting to themselves. Compounds.

The next 8 months will not look like the last. That has been the only constant since [August 2025](/blog/2026-05-01-vnx-evolution-tmux-to-autonomous-orchestrator). What will be different in May 2027, I cannot know. What will be the same: structured receipts, governance-first architecture, mens-op-de-loop where it matters.

## Update: June 2026

VNX reached 1.0 code-freeze in early June. The lane model is now the default: six worker lanes feeding the same orchestrator. The ephemeral tmux-spawn lane, driven by the June 15 Anthropic billing change, is maturing. Receipts are provider-aware and hash-chained. The 4-architect panel is now part of the standard design flow. May's numbers were honest; June's system is more specific.

See you in the June build log. If you want to follow along between now and then: [LinkedIn](https://www.linkedin.com/in/vincentvandeth/) for weekly updates, [VNX repo](https://github.com/Vinix24/vnx-orchestration) for the open-source code, the [SEO tool trial](/seo-tool) if you want to see what 8 months of build looks like in production, or [my AI architecture work](/ai-architectuur) if you want this kind of system for your own organisation.

***

**Bedankt aan iedereen die in mei meelas, feedback gaf, een trial startte, of gewoon op LinkedIn liked.** De build is solo. De feedback-loop is sociaal. Allebei nodig.

***

## Sources & references

1. [VNX Orchestration repo](https://github.com/Vinix24/vnx-orchestration), open source
2. [SEO tool trial](/seo-tool)
3. May 2026 blog series, full index: [Content/blog/2026-05-\*](/blog?month=2026-05)
4. Internal data: receipts ledger, AI provider invoices, GitHub PR data, all reproducible from the VNX repo

large_may-build-log-metrics-launch_cover

medium_may-build-log-metrics-launch_cover

small_may-build-log-metrics-launch_cover

thumbnail_may-build-log-metrics-launch_cover

may-build-log-metrics-launch_cover

May Build Log: SEO tool 1.0, Mission Control V2, and 32 Blogs Later

In de afgelopen weken schreef ik over [CLAUDE.md](/blog/2026-05-04-claude-md-uitleg-beginners), [rules.md](/blog/2026-05-08-rules-md-claude-code-codeerstandaarden), [hooks](/blog/2026-05-13-claude-code-hooks-automatische-acties), [context engineering](/blog/prompt-engineering-is-dood-context-engineering), en [self-learning loops via intelligence pipelines](/blog/vnx-intelligence-system-autonomous-monitoring). Telkens met voorbeelden uit mijn eigen setup.

Vandaag de samenhang: hoe past dit alles samen? Wat staat waar? Wat doet wat? Voor AI peers en hobbyisten die voorbij de eerste experimenten zijn, een complete walkthrough van mijn werkende productie-setup.

Geen abstracties. Wel: file-paths, command-mappingen, patronen die ik 8 maanden in productie heb getest.

## De getallen

- **38 skills**, herbruikbare instructie-sets, gedeeltelijk in `.claude/skills/`, gedeeltelijk in `~/.claude/skills/`
- **11 sub-agents**, gespecialiseerde agents voor research, code review, architecture, etc.
- **6 hooks**, SessionStart, PreToolUse, PostToolUse, Stop
- **4 memory directories**, always, on-demand, per-task, archive
- **3 rules-bestanden**, tone-of-voice, testing, security
- **1 CLAUDE.md per project**, context per project
- **0 vector databases**, alles markdown + NDJSON

Schaal: middelgroot. Niet enterprise. Wel veel voor een solopreneur.

## De directory-structuur

Eerst een vogelvlucht. Hoe is alles georganiseerd?

### Globaal, `~/.claude/`

Belangrijk: globale skills/memory zijn voor mijn algemene werk. Project-skills/memory zijn voor specifieke projecten. Bij conflict wint project.

> 📖 **Lees ook:** **[Hooks in Claude Code: geautomatiseerde acties na elke prompt](/blog/2026-05-13-claude-code-hooks-automatische-acties)**: hoe SessionStart, PostToolUse en Stop je workflow automatiseren

## De gelaagde architectuur: identiteit, voice, en project-context apart

De directory-structuur hierboven is georganiseerd langs één principe: **wat is identiteit en wat is project-context?** Identiteit verandert zelden, project-context verandert wekelijks. Door ze fysiek te scheiden voorkom ik dat een blog-sessie iets weet over een klant-deadline, en dat een coding-sessie zich druk maakt om marketing-buzzwords.

Twee niveaus dus, scherp gescheiden.

Gelaagde Claude Code architectuur: globaal en project apart

### Niveau 1, globaal (`~/.claude/`)

`profile.md` wordt automatisch geladen via de `@~/.claude/profile.md` regel in CLAUDE.md. Voordeel: één bron voor mijn identiteit, geen herhaling per project.

Wat in `profile.md` staat:

- Wie ik ben (Head of AI Solutions SalesMinds + VNX Digital + SEOcrawler)
- Communicatie-voorkeuren (Nederlands, 1e persoon enkelvoud, geen em-dashes)
- Werk-voorkeuren (architect-mindset, governance-stokpaardje, human-in-the-loop)
- Portfolio-overview (één paragraaf per domein)

Het is bewust statisch. Deadlines en project-status horen niet hier, die wonen in project-memory.

### Niveau 2, per project (`<project>/.claude/`)

Drie subtiele dingen die ik hier doe:

**Path-scoping** via een paar instellingsregels bovenaan een rules-bestand (YAML frontmatter voor wie die term kent). Mijn `tone-of-voice.md` heeft `paths: ["Content/**", "project/vnx_digital/**"]`, wat betekent: alleen actief als Claude in die mappen werkt. In een coding-sessie in `Development/` laadt deze rule niet. Officieel ondersteund door Claude Code, weinig gebruikt.

**Project-memory** in `.claude/memory/` met een `MEMORY.md` index. Hier komen observaties die voor één project gelden, bijvoorbeeld aliassen tussen klantnamen, of specifieke pricing-beslissingen.

**Anti-marketing-buzzwords** als aparte rule. Termen als "revolutionair" of "game-changer" blokkeer ik in content-folders, niet in code. Globale en project-rules vullen elkaar aan zonder elkaar te storen.

### Wat dit oplevert in de praktijk

In een coding-sessie in `~/Development/SEOcrawler_v2/`:

- Globale identiteit + voice + anti-AI-tics laadt (~120 regels)
- Project CLAUDE.md laadt (~80 regels)
- Marketing-rules laden NIET (path-scope past niet)
- Project-memory laadt (~50 regels)

In een blog-sessie in `~/Desktop/BUSINESS/Content/blog/`:

- Alle bovenstaande PLUS marketing-rules PLUS blog-rules
- Tone-of-voice.md activeert via path-scope
- Anti-marketing-buzzwords laden in voor content-werk

Totaal: ~300 regels gerichte context per sessie. Geen ruis. Geen ontbrekende info. Claude weet altijd wie ik ben, en in een blog-folder weet hij óók hoe ik klink.

Dit patroon, gelaagde scheiding tussen identiteit en context, is wat het verschil maakt tussen 38 skills die wel werken en 38 skills die elkaar in de weg zitten.

## De 38 skills (overzicht)

Niet alle 38 individueel, wel de categorieën die je kunt zien:

### Content & Marketing (13 skills)

`blog-orchestrator`, `blog-writer`, `blog-images`, `blog-publisher`, `blog-editor`, `seo-interlinker`, `seo-agent`, `linkedin-writer`, `linkedin-strategist`, `linkedin-image-creator`, `social-content`, `copywriting`, `copy-editing`

Deze coördineren mijn content-pipeline. `blog-orchestrator` is de top, hij roept andere skills aan in volgorde.

### Audience & Lead Intelligence (5 skills)

`audience-intelligence`, `lead-scorer`, `discussion-actor`, `cold-email`, `email-sequence`

Voor mijn LinkedIn intelligence engine en lead-werk.

### Product Marketing & Strategy (5 skills)

`product-marketing-context`, `marketing-psychology`, `marketing-ideas`, `pricing-strategy`, `launch-strategy`

Strategische skills die ik wekelijks aanroep voor branding-werk.

### Development Operations (8 skills)

`research-agent`, `vnx-project-setup`, `excalidraw-diagrammer`, `phantombuster`, `claude-api`, plus de SuperClaude `sc:*` skills (`sc:document`, `sc:implement`, etc.)

Voor technisch werk en architectuur-werk.

### Visual & Diagram (3 skills)

`linkedin-carousel-builder`, `excalidraw-diagrammer`, `linkedin-image-creator`

### Reflection & Process (4 skills)

`competitor-alternatives`, `funnel-orchestrator`, `content-strategy`, `reddit-marketing`

Per maand: ik gebruik typisch 5-8 skills per dag, niet alle 38. Het zit allemaal beschikbaar zodat *als* ik het nodig heb, het er is.

## De 11 sub-agents

Sub-agents zijn aparte. Een skill is een instructie-set. Een sub-agent is een aparte sessie met eigen context. Mijn 11:

| Agent | Wat het doet | Wanneer ik hem aanroep |
|-------|--------------|------------------------|
| `general-purpose` | Open onderzoeksvragen | Onderzoek dat 3+ queries kost |
| `Explore` | Code zoeken in repo | "Waar staat X?" |
| `Plan` | Implementatieplan maken | Voor non-trivial features |
| `backend-architect` | Backend ontwerp | Database design, API design |
| `frontend-architect` | Frontend ontwerp | UI patterns, accessibility |
| `system-architect` | Systeem-niveau | Architectuur-keuzes met long-term impact |
| `security-engineer` | Security review | Voor elke significante PR |
| `quality-engineer` | Test strategy | Edge cases bepalen |
| `performance-engineer` | Performance optimization | Wanneer benchmarks nodig zijn |
| `python-expert` | Python best practices | VNX-werk vooral |
| `claude-code-guide` | Claude Code expertise | Vragen over CC zelf |

Niet alle 11 dagelijks. Wel ze allemaal binnen handbereik via `Agent(subagent_type=...)`.

De `context_monitor.sh` is degene die op #1 in Google staat, auto-rotation bij 65% gevuld geheugen.

## Hoe het samenwerkt, een concrete sessie

Hoe ziet een typische sessie eruit?

**Stap 1, Sessie start.** Ik open Claude Code in mijn blog-project. SessionStart-hook draait `load_memory.sh`. Dit injecteert:

- `~/.claude/CLAUDE.md` (persoonlijke werkstijl, ~40 regels)
- `[project]/CLAUDE.md` (blog-project context, ~60 regels)
- `.claude/rules/tone-of-voice.md` (stem-regels, ~90 regels)
- `.claude/memory/always/MEMORY.md` (project-status, ~50 regels)

Totaal: ~240 regels baseline context. Schoon, gefocust, geen ruis.

**Stap 2, Slash command.** Ik typ `/blog kalender`. Slash command leest de eerstvolgende blog uit mijn kalender en triggert de pipeline.

**Stap 3, Skill orchestratie.** `blog-orchestrator` skill activeert. Roept achter elkaar aan:

- `research-agent` (sub-agent, parallelle research)
- `seo-agent` (skill, keyword analysis)
- `blog-writer` (skill, draft schrijven)
- `seo-interlinker` (skill, interne links)
- `blog-images` (skill, visuals)
- `blog-editor` (skill, kwaliteits-check)

Per stap: receipt naar NDJSON (via PostToolUse hook). Output naar Telegram (via webhook).

**Stap 4, Mijn review.** Bij elke significante stap krijg ik een Telegram-bericht met "concept klaar voor review". Ik open in browser, lees, accepteer of vraag wijziging.

**Stap 5, Sessie eind.** Stop-hook draait `auto_commit_notes.sh`. Werknotities en memory-updates worden vastgelegd.

Geen handmatige coördinatie. Geen "wacht, welke skill moet ik nu aanroepen?". Het systeem weet de volgorde, ik beslis de quality gates.

> 📖 **Lees ook:** **[Agentic OS: de centrale bediening voor je bedrijf](/blog/2026-05-16-agentic-os-centrale-bediening-bedrijf)**: hoe agents, orchestratie en context samen een werkend systeem vormen

## Drie patronen die het verschil maken

Niet alle 38 skills zijn even belangrijk. Drie patronen die het meeste verschil maken:

### Patroon 1, Orchestrator skills

`blog-orchestrator` en `linkedin` zijn meta-skills. Ze coördineren andere skills. Een orchestrator skill heeft drie eigenschappen:

- Roept andere skills aan in vaste volgorde
- Heeft duidelijke quality gates per stap
- Slaat tussenresultaten op zodat je kunt onderbreken

Ik heb 4-5 orchestrator skills. Voor herhalende multi-step workflows zijn ze goud waard.

### Patroon 2, Skills met expliciete ICP

Elke skill weet voor wie hij schrijft/maakt. `blog-writer` heeft drie modes (NL MKB, NL AI peers, EN architects). `linkedin-writer` heeft eigen ICP-targeting. `cold-email` werkt per ICP-segment.

Zonder ICP-awareness zou de output generiek worden. Met ICP-awareness past elke output bij de doelgroep zonder dat ik het hoef te specificeren.

### Patroon 3, Skills met "anti-claims"

Elke skill in productie heeft een sectie "wat dit NIET doet". Voorbeeld in `blog-writer`:

- Schrijft niet over health/medical zonder disclaimer
- Schrijft niet over Vincent's vrouw of privé-leven
- Genereert geen testimonials over klanten
- Schrijft niet in andere persoon dan eerste-persoon

Anti-claims voorkomen dat skills dingen doen die jij niet wilt, vaak gevoeliger dan wat ze wel moeten doen.

## Wat ik zou doen anders bij een nieuwe setup

Drie eerlijke leerpunten van 8 maanden:

1. **Begin niet met 38 skills.** Begin met 3 voor je meest-herhalende taken. Voeg pas een 4e toe als die echt 80% bewezen waarde heeft. Mijn 38 zijn organisch gegroeid, niet ontworpen vooraf.
2. **Memory > skills voor onbeschermde info.** In het begin stopte ik veel context in skills. Hoort vaak in memory. Memory is goedkoper te updaten en blijft persistent.
3. **Hooks eerst, dan skills.** SessionStart-hook met memory-loader is meer waard dan 5 nieuwe skills. Bouw de fundering voor je optopt.

## Wat doe je deze week?

Drie acties, naar gelang waar jij staat:

**Beginner** (1-2 maanden CC):

- Maak één CLAUDE.md, één SessionStart-hook, één slash command voor je vaakste taak.

**Intermediate** (3-6 maanden CC):

- Voeg 2-3 skills toe voor terugkerende workflows. Zet rules.md op met testing- en security-regels.

**Advanced** (6+ maanden CC):

- Bouw een orchestrator skill voor één multi-step workflow. Kijk of memory-tier-systeem werkbaar is. Voeg context-monitor hook toe.

Niet alles tegelijk. De waarde komt uit *consistent gebruiken* van wat je hebt, niet uit het hebben van veel.

Veelgestelde vragen

## Samenvatting

38 skills, 11 sub-agents, 6 hooks, 4 memory directories, opgebouwd in 8 maanden Claude Code in productie. De waarde zit niet in het aantal, maar in de drie patronen: orchestrator skills voor multi-step workflows, ICP-aware output, en anti-claims om te voorkomen dat skills doen wat jij niet wilt.

Begin niet met deze schaal. Begin met CLAUDE.md, één SessionStart-hook, en één slash command. Voeg toe naargelang je workflow het nodig heeft.

In zes maanden heb je iets dat compounding werkt, net als bij elke discipline waar je consistent in investeert. Geen 38 skills nodig. Wel 38 weken trouw werken aan de essentie.

***

**Wil je sparring over jouw eigen Claude Code setup?** [Volg me op LinkedIn](https://www.linkedin.com/in/vincentvandeth/), daar deel ik wekelijks build-in-public updates over hoe mijn setup zich ontwikkelt. Of kijk op [mijn werkwijze-pagina](/mijn-werkwijze) hoe ik dit soort systemen bouw voor andere bedrijven.

***

## Lees ook

1. [CLAUDE.md voor beginners](/blog/2026-05-04-claude-md-uitleg-beginners)
2. [Rules.md uitgelegd](/blog/2026-05-08-rules-md-claude-code-codeerstandaarden)
3. [Hooks in Claude Code](/blog/2026-05-13-claude-code-hooks-automatische-acties)
4. [Top 10 Claude Code features](/blog/2026-05-09-top-10-claude-code-features-2026)
5. [Prompt engineering is dood: lang leve context engineering](/blog/prompt-engineering-is-dood-context-engineering)
6. [Intelligence beats memory: self-learning pipeline](/blog/vnx-intelligence-system-autonomous-monitoring)

claude code setup skills agents coordinatie cover

AI Architect voor het MKB

Werkende systemen. Meetbare resultaten.

AI Architect voor het MKB

Werkende systemen. Meetbare resultaten.

Zo help ik jouw bedrijf groeien

AI Kansen Scan

AI Architectuur & Agents

Governance & Compliance

Van 2.500+ uur ontwerpen en bouwen naar architectuur voor jouw bedrijf

Waarom AI-trajecten mislukken

Van 2.500+ uur ontwerpen en bouwen naar architectuur voor jouw bedrijf

Waarom AI-trajecten mislukken