# Meet Sidequest, the Kanban Board Where the Cards Work Themselves > Source: > Published: 2026-09-02 00:00:00+00:00 # Meet Sidequest, the Kanban Board Where the Cards Work Themselves I’ve written about [how Sidequest started](https://eigenwise.io/writing/a-quick-sidequest-became-my-most-powerful-claude-code-plugin) 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](https://github.com/Eigenwise/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](https://eigenwise.io/writing/the-quest-for-local-model-routing-inside-claude-code) 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](https://eigenwise.io/writing/claude-code-can-do-things-its-own-docs-dont-mention) 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](https://eigenwise.io/writing/the-quest-for-local-model-routing-inside-claude-code) 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](https://eigenwise.io/contact).