The Wolfpack kit: how my Claude Code team works

How it started

On 26 Sep 2026 I ran my first release on autopilot, in Hutzup, my planner for board game and movie nights. One session, the navigator, wrote the plan itself, made the branch and handed the steps to agents. Builders took the screens and another agent did the database. A reviewer and a deploy agent came at the end.

It planned right the first time and never stopped to ask me for a decision before the pull request was ready. My verdict after it shipped was to keep the navigator and tune the agents.

The tuning was mostly about reading. Every agent read far more than its step needed, and that was the cost. So the work orders started naming the few files an agent should open, and that's still how they're written.

From one project to a kit

By early October I had a list of other projects I wanted to build the same way. On 4 Oct 2026 I took the agents and their skills out of Hutzup and packaged them as plugins in a repo of their own.

There are four packs, one for the shared crew and the habits, one for releases, one for design and one for the database, plus a fifth that installs them all. A project adds one small settings file with its own values, like its name and its dev port. The kit itself only carries placeholders.

On 11 Oct I asked for two rules in every project. The kit should always do as much as possible and only ask me for something I really have to do, like a password or a payment. And it should make sure we never end up paying for a service by accident. The same day the general lessons moved from Hutzup into the kit, so every project reads them. By 15 Oct the repo had 36 commits.

This site was started with the kit's project starter and built with the kit, which the other write-up tells step by step.

How a release runs

One session is the navigator. It talks with me and plans the release step by step, then hands each step to a named agent: a builder, a reviewer, a designer or the deploy agent. Each one runs on its own model and effort, picked for the job.

Before a big release a planning session goes through the plan with me. I answer its open questions and stamp it ready to build. Every step gets a row with what to build, who builds it on which model, what to check and a budget.

That's the row that ordered this post. The builder gets the row, the files it may touch and the check that says it's done, and it doesn't see the rest of the conversation. It commits and pushes its work and reports back in a few lines. Then the navigator hands out the next step.

When the navigator needs me it asks a pick-one question, with the option it recommends first. A step only I can do comes one at a time, one command and then it waits for me. Merges always wait for my go.

Budgets and the guard

Every job carries a token budget in its order, and a hook holds the agent to it. On this site a page-sized step costs about 1.7M to 4.2M tokens, so a new page gets a 5M budget.

The budgets for a whole release don't always hold. V0.1 of this site used about 13.5M tokens of a 15M budget. V0.2 used 26M to the draft against 36M planned, then 64M more on seven batches of my notes and the fix release V0.2.1 after the merge. V0.3 planned 38M and used 71.6M, and the navigator alone used 47.1M of that.

A second hook, the production guard, stands between every agent and the production database. Only the deploy agent gets through, and only with my yes for that change, after a backup.

How it learns

After each release a wrap-up session goes over the run's token use and its rework. What went wrong becomes a lesson of one line, and the next release reads it. The kit's own lessons file holds 70 of them now, learned in the projects that use it.

A lesson the builders should run as a check goes into a checks file with a grep beside it. On this site that file has five, like opening every outbound link before a commit and keeping every cube size a whole pixel.

My design sendbacks work the same way. Each one becomes a rule in a taste file with my words beside it, and the builders and QA read it before they touch a page. Two of those rules came from this site's first write-up, and they're why this post names roles instead of the agents' nicknames and why every figure says its unit.

What I'd change

A lesson in a file doesn't always change what the agents do. When the same mistake comes back release after release, the skill itself has to change, not only the notes around it.

The navigator also still carries the most, as the V0.3 numbers show. Giving it less to hold is the next thing I tune.

Every agent and skill in the kit is in the Wolfpack repo (opens in a new tab) on GitHub.