A fresh plugin dropped for Claude Code, and the twist is who does what. Your expensive Opus session stops reading files and writing boilerplate. Cheaper subagents handle that. Opus keeps its context for judgment and a review gate before anything gets accepted.
The project is claude-agent-kit, open source under MIT. If you run Opus as your main session, you’ve probably watched it burn context on grepping and routine code. You ask for a small refactor, and half the window disappears into directory listings, file dumps, and scaffolding. That leaves less room for the part you actually want from it: deciding what to do and checking the result. This plugin packages the split so you don’t have to hand-build it in every repo. Think of it like a senior engineer who stops fixing typos and starts reviewing pull requests. Same brain, better use of its time.
What’s in the box:
- Seven Claude Code subagents
- Orchestration rules for the main session
- A read-budget hook
- A CLAUDE.md template
Each piece covers a different failure mode. The subagents take the legwork, like searching the codebase, reading files, and drafting routine code. The orchestration rules tell the main session when to delegate instead of doing it itself. The CLAUDE.md template gives you a starting point so the rules live in your repo and not in your head.
The twist is the read-budget hook. Instead of trusting the main session to stay disciplined, the kit enforces a limit on how much it reads itself. That matters because prompts alone drift. A rule like “delegate reading to subagents” works for the first ten minutes, then a long session gets busy and the main model starts opening files again. A hook doesn’t get tired or forget. It sits in the loop and pushes the work back where it belongs. One early commenter said the hook alone is worth the install, and they already build agents this way at work.
Here’s the mini-workflow:
- 🔌 Inside Claude Code, run
/plugin marketplace add FlaviusBurghila/claude-agent-kit - 📦 Then run
/plugin install agent-kit@agent-kit - 📝 Run
/agent-kit:initto write an “## Agent contract” section into your project’s CLAUDE.md - 🩺 Run
/agent-kit:doctorto check the setup. It only inspects and changes nothing.
You can also install from a shell with claude plugin marketplace add and claude plugin install. It needs Claude Code 2.1.293 or later, so check your version first if the commands don’t show up. After init, open your CLAUDE.md and read the new Agent contract section before you do anything else. It’s your project’s rulebook now, and you should know what it says. If your repo already has a long CLAUDE.md, read how the new section sits next to your existing rules, because conflicting instructions are the quickest way to get odd behavior.
Pro tip: add --scope project when you install. That records the plugin in the repo’s .claude/settings.json, so everyone on the team gets the same setup without extra steps. A new teammate clones the repo, opens Claude Code, and gets the same delegation habits as everyone else. No “works on my machine” drift, and no one has to remember a setup checklist.
Pro tip two: run doctor first on any repo where you’re nervous about config drift. It’s read-only, so there’s no downside. It’s also a handy habit after you edit your settings or upgrade Claude Code. If something stops behaving the way it did last week, doctor is the cheapest first check, and it takes seconds.
Pro tip three: judge the kit with a real task, not a toy one. Pick something you’d normally hand to Opus that mixes reading and writing, like adding a small feature that touches three or four files. Watch which steps go to subagents and what comes back for review. If Opus is still reading a lot of files itself, tighten the budget. If it rejects too much of the subagent output, your task descriptions are probably too vague.
The author also asked a good question worth stealing: where do you draw the line between what a cheaper model may implement and what must go back to Opus for review? And does that rule live in CLAUDE.md or in the subagent definitions? Worth deciding on purpose before you scale this up. A simple starting point: let cheap models write tests, boilerplate, renames, and docs, and send anything touching auth, payments, data migrations, or public APIs back through review. Then adjust after a week of real use. Putting the rule in CLAUDE.md makes it visible to humans and the main session. Putting it in the subagent definitions makes it harder to bypass. Many teams will end up with a bit of both.
Heads up: the post was shared on behalf of the kit’s own team, so test it on a small repo before rolling it out wide. Early enthusiasm from commenters is encouraging, but it isn’t a benchmark. Measure for yourself. Track how fast Opus burns context before and after, and note any review step that catches something the cheaper agents got wrong. That’s your real evidence.
Repo: https://github.com/FlaviusBurghila/claude-agent-kit
Try it on one project this week and tell me where you drew the review line. 🏴☠️
Open-source Claude Code plugin: cheaper subagents do the I/O and implementation, Opus does judgment and review
by u/investigatormaker in PromptEngineering