DEV Community: Kenny Vaneetvelde

The Plugin That Turns Your Claude Code into a Continuously Self-Improving Monster

Kenny Vaneetvelde — Sat, 03 Oct 2026 17:27:05 +0000

Originally published on Eigenwise on 11 September 2026.

Something goes wrong in a session, so you write a rule. Next week the rule gets buried under the other rules, so you write a sharper one. A month later your CLAUDE.md is a page of capital letters, begging Claude to “PLEASE NEVER EVER DO X WITHOUT FIRST DOING Y” and Claude still does the thing. My global config grew exactly like that, and I’ve watched a lot of other people’s grow the same way: one person I read is at 38 memory files and 18 recorded correction files, another has six postmortems and a five-gate review system, and their complaint is the same as everyone’s. There’s a paper on it now. Across 1,867 repositories, agent instruction files more than triple over their lifetime, they gain about five net instructions per commit, and the older a rule gets, the less likely anyone ever deletes it.

What I run now is Quartermaster, the first plugin I install in a new project and the one I add to an existing project when I want the whole Claude Code setup handled from one place. It uses hindsight from my work across projects to propose the initial setup, with every plugin install, file edit, and settings change waiting for my approval. Then it watches the real sessions, works out what the workspace is short of, proposes one change at a time, and next round checks whether the last thing it talked me into actually helped. If it didn’t, it says so and offers to roll it back.

A few months ago I wrote The First Thing I Install in Every Claude Code Project about codebase-mapper. That title is already out of date. Quartermaster goes in first now because it installs codebase-mapper, builds the map, adds a starter set of live-rules pulled from how I actually work, picks the stack plugins and permissions that fit the project, and asks before touching any of it. It has already shown up twice in this series as the thing that installs and configures everything else, so this time it gets its own story.

It lives in the Eigenwise Toolshed, my plugin marketplace, free and MIT-licensed like everything else in there, and it’s the piece that sets each workspace up, then decides what it should grow next.

Rule 41 Makes Rules 1 Through 40 Worse

Claude reads your CLAUDE.md every session. Anthropic’s own docs say so, and then add that you should keep it under 200 lines, because longer files “consume more context and reduce adherence”, and that you should review it periodically to remove outdated or conflicting instructions. So the file gets read. It’s one page in a book that keeps getting longer, and every rule you add makes the ones before it a little quieter. Rule 41 costs you rules 1 through 40.

Skills have the same problem one layer down. Claude Code loads a listing of every skill’s name and description so it knows what’s available, and that listing gets a budget of 1% of the context window. When you overflow it, the descriptions get cut starting with the skills you use least. Those stop matching your requests, so you use them even less, so they get cut harder. A skill can go invisible without ever throwing an error, and the only notice is a line in a debug log.

Everyone’s answer to both is more of the same: more rules, then hooks to enforce the rules, then memory files to remember why the hooks exist. The “review periodically” line in the docs is the whole maintenance story, and it’s a chore with no tool attached. Nothing prunes on evidence, and nothing checks whether rule 17 has done anything since June.

What It Actually Does

Quartermaster has two jobs. Setup comes first. Point it at a new or existing workspace and it reads the project itself, then mines a bounded cross-project view of the Claude Code work you’ve already done: which plugins and MCP servers you actually use, which permission approvals repeat, and which corrections keep coming back. A new project starts where the others left off, with a setup plan specific to that project and grounded in how you already work.

It turns that into one visible plan, with codebase-mapper, live-rules, Sidequest, observability, model-gateway, stack plugins, rules, and permissions each chosen separately. For a real codebase it can install codebase-mapper and build the first map; for any workspace it can seed live rules from the corrections and habits that recur across your other work. It installs nothing until you approve the exact item, stops for the plugin reload, and then verifies that every selected piece is actually working.

After that comes resupply, the ongoing half. The counting is cheap. When a session ends, a hook reads the transcript that just closed and writes six integers into a local state file: prompts, tool calls, tool errors, permission denials, interrupts, corrections. No text, no model call. Once 4 sessions have piled up unreviewed, or 6 friction events have, Claude gets a nudge at the start of your next session, and at the next real pause it offers you an optimization round. Say no and it clears the backlog and waits. Say yes and the actual work starts.

The work is a script. It reads your last 30 days or 40 sessions, whichever is smaller, into one bounded aggregate: what each session was for, which parts of the tree the work landed in, the commands you keep running, the friction counts, and at most a dozen clipped quotes of you correcting Claude. Raw transcripts never enter the model’s context. In one heavy-use month, 127 MB of JSONL became a 31 KB aggregate. It also flags which sessions a human actually typed into, because with a ticket board spawning executors all day those sessions outnumber mine by a wide margin, and without the flag the pass would report the automation’s goals back to me as my own.

The ongoing half looks like this:

session ends ──▶ tally (6 integers, local)
                    │
     4 sessions or 6 friction events
                    ▼
nudge at start ──▶ offer at the next pause (once)
                    │ yes
                    ▼
mine 30d/40 sessions ──▶ bounded aggregate (no transcripts)
                    ▼
verify last round ──▶ keep / improve / roll back
                    ▼
≤ 7 findings, one at a time, each needs your yes
                    ▼
ledger (applied AND rejected) ──▶ next round reads it

Then it proposes, at most 7 findings and best first, and the fix is whatever the gap actually calls for: a plugin off the catalog, an MCP server out of the registry, a skill built for the job, a line of project knowledge, a scoped rule, a permission, or turning off something you installed months ago and never used. The plugin search reads every marketplace on your machine, which on mine is 2,587 plugins, six of them the Toolshed. A candidate gets its token cost checked with claude plugin details before you ever see it, because a plugin that costs you more context than it saves is one to skip. The job is your whole agent setup, so a round that ends with somebody else’s plugin installed, or with nothing installed at all, is a round doing what it should.

Before it names a plugin, it goes and checks. For the handful of findings that could end in an install, it looks up whether the thing is still maintained, whether its description still matches what it actually does, whether something better-regarded covers the same ground (including in a marketplace you haven’t added, in which case you get the add command too), and what people report about living with it. The searches use generic capability terms, so your project names and file paths stay out of the logs of a search engine you never picked. With WebSearch and WebFetch turned off it skips the check and labels those proposals unresearched rather than implying they were verified.

Each finding shows the exact command or diff and waits for a yes or a no. The no is recorded too. Rejected findings go in a ledger with a fingerprint, and the next round drops anything you already turned down. On my machine that ledger holds 90 applied decisions and 13 rejected ones right now.

Start a TypeScript monorepo and the first plan could include codebase-mapper, live-rules for package boundaries, the TypeScript language server, one command that runs the checks across every package, and permission rules learned from commands you already approve elsewhere. A month later, resupply might notice that releases still take five commands you run by hand and turn them into a project skill, or spot a plugin loading every session, throwing hook errors, and never showing up in the work, then offer to remove it. Put the same plugin in a research vault and it could build evidence rules and source-checking instead, with no code tooling at all. Quartermaster is told to improve what already exists before putting another tool beside it.

The Most Valuable Gaps Never Raise an Error

The first version of this plugin was a friction hunt: count how often Claude got denied, corrected, or interrupted, then fix those. It worked, and it’s now the last thing on the list, because fixing what went wrong only gets you back to the speed you already expected. A capability you never had moves that baseline.

And the best capabilities leave no trace. Take a goal like “make the ingest reliable”. You can’t close it without a way to check it, and a check that doesn’t exist yet never fails, because it never runs. The need for it shows up exactly once, so every threshold of the form “did this happen three times” skips right past it. A pass that only counts pain is structurally blind to the best thing it could find.

So the pass reads purpose first, weighing sessions by effort rather than by count. It looks for a goal set and never met, or restated across sessions, or a property that keeps being asserted (“should be correct”, “fast enough”) and never demonstrated. An unmet goal is the single best lead in the whole aggregate, and the fix for it is usually an instrument, built as a committed skill so the number can be re-run later. It also has to say whether a gap is attested by your history or inferred by the model, because only the attested kind gets to outrank a cheap fix it’s certain about. And a healthy project with no stated standard gets told there’s nothing to build, which is a valid outcome. A pass that invents work to look useful is a pass you learn to skip.

The Next Pass Grades the Last One

Claude Code already looks at itself: /insights reports on your recent sessions, /doctor finds unused skills, /fewer-permission-prompts proposes an allowlist, and every one of them ends at the suggestion. I looked again this week and couldn’t find one, native or otherwise, that re-measures after you apply a change, and none that rolls a change back. That’s the seam Quartermaster sits in, and the verify step is the whole reason I trust the rest of it.

Every applied decision names the signal it was meant to move: denials, interrupts, corrections, tool errors, or total friction for a capability nothing counts. On the next round the script compares the sessions before the decision with the sessions after it, refuses to call a verdict on too few sessions, and then says one of three things out loud: keep, improve, or roll back. In a repo where I open and close a session per ticket, that verdict arrives within days. In this vault, where I keep one session open for a week at a time, it takes a month, because a week-long session is one data point.

The reason it measures instead of asking me is that I can’t feel the answer. In METR’s randomized study of experienced open-source developers, people forecast a 24% speedup, reported a 20% speedup, and measured 19% slower. The one person I’ve seen actually test their CLAUDE.md changes properly, eight candidates optimized against real PR tasks and then a clean holdout, watched the winning version regress on the holdout. Their line was that the rule was philosophically right and empirically bad, and that editing by vibes, they’d have shipped it. Everybody else is editing by vibes, including the people with the most elaborate setups, and several of them say so.

A config change that can be rolled back on evidence is a change you’re allowed to try. I wrote a whole piece earlier this year about the pitch where the right setup is what’s being sold, so buy mine and the gains appear, and how that turns every disappointment into proof you needed more of the product. A self-improving workspace is exactly that shape of product, and the verify step is what makes mine a different one: it tells you when a change didn’t work, and takes it back.

It Works Where There Are No Tests

The same loop can run anywhere Claude Code does, and it grows something different in each workspace. A code repo might grow permissions, build chores, and small instruments: a check that the docs still describe the code, a report of what a session changed. A research vault might grow evidence rules and source-verification. A journal could grow a privacy rule and a contradiction checker. A brand-new project can get the plugin set and craft rules it actually needs on day one. Same plugin everywhere, and after a month no two workspaces should have grown the same thing.

That’s the test I’d put to any “self-improving” setup. After a month, does workspace A look different from workspace B? If every project converges on the same toolkit, the thing was accumulating, and the whole point is fitting. It’s also why I’d rather run a loop than install a list of twenty recommended skills: the list is somebody else’s month.

Who gets left out otherwise matters too. Every enforcement answer I’ve seen assumes a test suite and CI, and the people using Claude Code for a vault, a research project, consulting, or a novel have none of that. A loop built on session history works for them, because a writing project has standards it can’t check and chores it does by hand just as much as a repo does. Only the instruments differ. For a brand-new project, the setup skill runs the same idea across your whole history at once: it reads what the thing is built in, picks the plugins that match that stack from the official marketplace and anywhere else you’ve added, seeds the rules your past corrections keep asking for, and hands you the list one item at a time. An Obsidian vault, a docs site, and a Python service each come out of it holding different things.

What to Expect Day to Day

When a round is due, the Stop hook holds Claude’s final reply long enough to make the offer, once per session and never twice inside a day. It does that on purpose, because nudges that can be ignored get ignored. The monitoring and mining stay on your machine: no model in any hook, transcripts reduced to counts and clipped quotes before anything reads them. Plugin research and update checks are the networked parts. And since anything the loop writes into a workspace lands in context on every later session looking exactly as true as everything else, rollback is a first-class verdict, which is why I’m comfortable letting this run for a long time rather than for a few exciting weeks.

Where to Get It

Three commands in a Claude Code session:

/plugin marketplace add Eigenwise/eigenwise-toolshed
/plugin install quartermaster@eigenwise-toolshed --scope project
/quartermaster:setup

Then work normally, and say yes when it asks for a round. I install per project or local and keep the machine-wide level as close to empty as I can, because a rule that’s right for one repo is noise in the next one. The source and README are in the Toolshed repo. Give it a month, then look at what it grew. If it’s something you’d never have thought to build, I want to hear about it, on the repo or on the Discord.

If you’ve read the Sidequest tour, you saw a section called “It Builds Itself Now”, and the two are worth telling apart. Sidequest improves the plugin opportunistically, whenever an executor trips over friction mid-ticket. Quartermaster improves your workspace deliberately, on a counted cadence, and checks its own work next round. The origin story, the codebase-mapper piece, and the model-gateway one (where Quartermaster does the installing) fill in the rest of the Toolshed.

If you only take one idea from this: close the loop on the rules you already have before you add another one.

Everything in the Toolshed is free and MIT-licensed, and it stays that way. If it saves you time, a coffee on Ko-fi or a GitHub sponsorship is what keeps me building and maintaining it.

And if you want this inside your own company, that’s what I do for a living. I built Atomic Agents and everything in this series, and I work with anyone who wants their AI spend to actually pay off: a solo developer, a team of five, or an engineering org that bought the licenses and is still waiting for the productivity. I train teams on AI-assisted development, build the plugins, hooks, and routing that make Claude Code productive on your own codebase and your own model budget, and audit a setup that isn’t delivering and tell you why. A one-day workshop or a standing engagement, whatever fits. Reach out and tell me what you’re stuck on.

Meet Sidequest, the Kanban Board Where the Cards Work Themselves

Kenny Vaneetvelde — Sat, 03 Oct 2026 14:07:49 +0000

Originally published on Eigenwise on September 2, 2026. The usage figures below describe my August 2026 workflow.

I’ve written about how Sidequest started as a quick detour that ate three weeks. This piece is the tour of what it grew into, because as of August 2026 it’s the thing I’m proudest of having built. The agent community keeps renaming the same idea: loop engineering, graph engineering, fleets of agents, multi-agent orchestration. Whatever you call it, the meta is that one expensive model plans while cheaper ones do the work in parallel, and everyone is duct-taping their own version out of prompts and shell scripts. Sidequest is my version, and after months of daily use across every project I touch, I’ll say the slightly immodest thing out loud: I think we’ve come close to perfecting it. It’s a Kanban board where you never drag a card, because the cards get up and do the work themselves.

It’s also free. Sidequest is one plugin in the Eigenwise Toolshed, my open marketplace of Claude Code plugins, and everything below is installable with two slash commands.

One Board over Every Project

The dashboard is a local web app. No cloud, no account, ticket data in a local store on your machine. The rail on the left holds every project you’ve registered a board for, with ticket counts and progress beside each one, and the “All boards” view merges them into one queue you can scan in ten seconds: what’s waiting, what’s running, what’s done. Mine currently holds 12 boards, and every one of them had tickets filed this month.

Look at the cards, because the interesting part is printed right on them. Every card carries its priority, its story, its labels… and a route line: sonnet · medium, opus · xhigh, codex-gpt-5-6-terra · high. That route is which model will do the work and how hard it will think, decided per ticket. More on that in a minute, because it’s the section I actually want you to read.

Side Issues Become Tickets Instead of Detours

The board fills itself. Claude is working on the main task, something crosses your mind, you say so in passing and keep going. For this article I mined my own session transcripts and the board’s local store, and the first twenty days of August alone hold 2,400 tickets filed and 2,856 dispatches prepared, an average of 120 tickets a day across those boards. Agents file most of them mid-flight, when a fix trips over a second problem. My side of those moments is about as ceremonial as you’d expect:

“yeah file it and queue it man sounds important, and yes go sorry for interrupting”
“yeah ticket that lint false positive too and keep going fix everything”
“yes, file that ticket and fire it off, in parallel for both”
“ticket them and fire em off”

Each of those became a properly filed ticket with a description, a category, and a route, without the main task losing its thread. That’s the original itch the plugin scratched: side issues stop being detours and stop being forgotten. They become cards.

And a card is a real ticket, in the boring, load-bearing sense. Priority, status, story, labels, dependency links (“blocks SQ-5”), a scheduled reminder, and a comment thread where the agents working on it report findings as they go. When I ask “what is blocking SQ-7?”, the answer comes from this data, and the executors read the thread before they start. The board is shared memory between me and every agent on the project.

To be clear, small direct work stays direct. “no ticket needed for that just inline it” is a real quote from my transcripts too, and the plugin’s own skills tell Claude the same thing: a one-line fix in a file I named goes straight in. Filing a ticket for that would be theater. The board is for work worth delegating.

The Kind of Work Chooses the Model

This is the part I haven’t seen anywhere else done properly. Every ticket gets classified into a category: coding, deep-research, docs, behavior verification, whatever you’ve defined for the board. And each category carries a route: a concrete model plus a reasoning effort. A grunt refactor goes to a fast cheap model at medium effort. Research that feeds an article, where being wrong is expensive, goes to the big model at high effort. You set the mapping once in a routing profile, and from then on the kind of work chooses the model, instead of habit or whichever model happens to be loaded.

Profiles live in a library, so three boards can follow one “Coding” profile and inherit its updates, with local overrides per board. There’s a global fallback for when a route’s model is unavailable, and a quota-fallback hook that catches a mid-flight “you’ve hit your limit” and reroutes instead of dying.

Now read those card routes again: opus · xhigh next to codex-gpt-5-6-terra · high on the same board. That second one is a Codex model. As of August 2026, Sidequest dispatches to Anthropic and OpenAI models side by side, on the same board, in the same wave, because the Toolshed also ships a model-gateway plugin that puts any OpenAI-compatible backend behind a model name Claude Code can route to. It’s all modular: Sidequest defines routes, the gateway makes the names resolvable, and neither knows the other’s internals. The combination means you can run this even if all you have is a ChatGPT subscription, with Codex models doing the executing. My own boards mix them daily, and they lean further toward the gateway than you’d probably guess: in the first twenty days of August, 94 percent of my dispatches ran on Codex models, with the Claude routes saved for the work where I want taste over volume.

What Happens When a Card Starts Working

Dispatch is where most home-grown agent-fleet setups fall apart, because “spawn ten agents” is easy and trusting what comes back is the entire problem. So this is where Sidequest is most opinionated.

When a ticket dispatches, the executor gets its own fresh git worktree, an isolated checkout reserved by the board before git even creates it. Ten executors can run in parallel without touching each other’s files or mine. The dispatch itself is token-gated: an executor holds a one-time claim bound to that ticket, and a set of guard hooks makes sure nothing without a claim can pass itself off as an executor.

Then the part I care most about: the verifier is pinned at dispatch time. Every ticket names the check that decides whether the work actually worked: a test suite, a schema check, a document review, manual evidence, an attestation. The executor cannot swap it for an easier check, and for a declared command, Sidequest records a capture of the actual run, bound to the ticket, the exact command, and the exact revision it checked. A retyped command or a paragraph of prose cannot stand in for that capture. If the capture predates the final commit, it has to be rerun. Anyone who has caught an agent claiming “all tests pass” knows exactly which failure mode this closes.

Delivery is gated too. Before work lands, Sidequest opens an integration wave that pins the source revision and the files each ticket said it would touch, refuses a wave whose scope overlaps work still running, and invalidates a candidate the moment the base under it moves. Code work submits a verified git range, and for projects outside git (this article was written in a board-managed Obsidian vault) a filesystem-snapshot adapter does the same job with SHA-256 tree snapshots. The result and its log artifact are kept either way, including the failures, so you can always see what happened.

For a sense of how tight that loop runs: in August a real ticket, a queue-shuffle bug in a music-practice app I’m building, went from filed to integrated on main in 23 minutes and 35 seconds. That included the board refusing the executor’s first submit for sitting on the wrong base, preserving the rejected work at its own ref, and the executor recovering and resubmitting in 94 seconds. And when work does bounce, it bounces visibly: 20 percent of my August tickets carry at least one rework event. I’d rather have that number on a board than spread across a hundred chat scrollbacks.

Around 30 Hooks Keep Everyone Honest

All of that policy would be worth little if an agent could just… not follow it. So as of August 2026, Sidequest ships roughly 30 hooks that make the rules mechanical instead of aspirational. A few of my favorites: one blocks any agent from spawning executors outside the dispatch path, one refuses edits that escape an executor’s own worktree, one catches destructive git commands before they run, and one gently reminds a session that substantial new work should start as a ticket. These fire constantly and mostly invisibly: in the first twenty days of August the spawn guard allowed 2,813 executor spawns and denied 72 attempts to reach the executor path without a valid dispatch, and the reminder alone fired 157 times. It fires at me too, and there’s a transcript where I ask Claude, slightly annoyed: “why are you not using sidequest btw did you not get the hook?”

Hooks are also why the whole thing survives long sessions. A compaction-policy hook protects board state across context compaction, and session hooks re-register the live boards on every start. The board doesn’t forget, even when the model does.

It Builds Itself Now

The strangest property showed up a few months in: the Toolshed with Sidequest on top is close to a self-improving system. Getting it there took real time, but the whole way through, the plugin was developed on its own board. It kept reading its own source to understand itself, and the Claude Code binary to learn what its host can actually do and how to work around what it can’t.

The loop is simple once the board exists. While an executor fixes a bug, it trips over a second bug, and that second bug becomes a ticket instead of a lost observation. Compaction and new sessions don’t break the chain, because the tickets are on the board, outside any context window: nothing gets lost. There have been stretches where it found and fixed friction after friction for two, three days straight, making itself faster and better with me mostly reading the inbox. That pace is why the plugin sits at version 5 already, and yes, it follows semantic versioning; those were real breaking changes, most of them proposed by the system itself.

The counterintuitive number: my total token spend went down while all this was running. I can see it because another Toolshed plugin routes every session’s usage to Grafana. Routing is most of the answer: the expensive model plans and reviews, while the bulk of the executing happens on cheaper routes, and a verify-discipline skill keeps executors from re-running full test suites out of nervousness.

The Inbox Is Where I Actually Live

With work running in parallel across projects, the question becomes how you keep up without babysitting. The inbox collects comments, status changes, reminders, and new tickets across every board, split into “Needs you” and the wider activity stream. Executors comment their findings mid-flight, so review starts while the work is still running. My mornings on busy days are: open inbox, read what the fleet did, say “review and integrate SQ-12 if its verification passed”, move on. When a board gets messy, “do a proper grooming sesh” is a real instruction; the groom skill audits for stale, duplicate, and superseded tickets and closes the clear cases.

Install It

Sidequest is free and lives in the Toolshed marketplace. In Claude Code:

/plugin marketplace add Eigenwise/eigenwise-toolshed
/plugin install sidequest@eigenwise-toolshed --scope project

Reload, then open the board with /sidequest:board and say something like “Plan the checkout refresh as a Sidequest story and show me the backlog.” If you’d rather have the setup done for you, /quartermaster:setup installs and configures it per project. For the mixed Claude-plus-Codex fleet, add the model-gateway plugin from the same marketplace; the routing article walks through that setup.

Two months in, this is simply how I work now, and it earned that the hard way. The same transcripts I mined for this piece contain “yeah no I think I gotta let sidequest go” and one project where I flat-out told Claude to stop using it. Both times I was back within days, because the alternative was carrying the whole queue in my own head again. Plans become cards, cards carry their own model and their own proof, and the fleet runs while I do something else. The board went from a side project to the thing every other project runs through.

And if you want this way of working inside your company, that’s a big part of what I do: teaching teams the ins and outs of AI-assisted development, and building the plugins, hooks, and routing that make Claude Code productive on your own codebase. If you want a hand, feel free to reach out.

Atomic Agents - New opensource library to build AI agents atomically

Kenny Vaneetvelde — Tue, 25 Jun 2024 20:02:50 +0000

Hello all, I am the creator of Atomic Agents, A new multi-agent open source framework inspired by Atomic Design principles.

https://github.com/KennyVaneetvelde/atomic_agents

A lot of existing frameworks and methodologies for Agentic AI are focused on building autonomous multi-agent systems that you basically wind up and let go. While these can be fun to demo, they’re not always practical for real-world applications. Real-life companies aren’t looking for a bot that writes articles in a different style each time, with a different structure and a different tone. They want a bot that can write articles in a consistent style, with a consistent structure and a consistent tone that aligns with their brand. Beside fine-tuning a model, which requires a lot of data and money, and isn’t even possible if you really want to use the latest GPT model, there’s no practical way to gain full control of the output of these frameworks.

In business, management rarely allocates budget just to create something that’s cool but has no value. They want to see a return on investment. They want to see real business issues being solved and automated and cut costs. To achieve this, you need modularity, you need to be able to control the output, make sure it’s not a black box, make the output reproducible, and make it reliable. This is where Atomic Agents come in.

Since this framework is new, I'd love some feedback, suggestions, and PRs! I have been using it a TON and it's way easier than langchain, crewAI, ...

Feel free to get in touch with me on LinkedIn for business inquiries https://www.linkedin.com/in/kennyvaneetvelde/