There's a common issue in Claude Code communities on Reddit: someone is a few weeks into a project, the code is starting to sprawl, and they want a framework that will keep it from turning into a mess that eats most of their context tokens before they get started. And while there are countless options, two answers come up almost every time—the first is Superpowers, the second is ouroboros—and for good reason. They're both incredibly powerful.
If you're looking for a planning system that moves you through a workflow, end to end, Superpowers and ouroboros are both great options. But, they aren't for everyone. Not everyone wants to be moved along a set of rails, with only some control over where they go next, for example.
For those of us that want the capabilities of a tried and true planning system (and more), I want to introduce you to Han—the agentic research, planning, and implementation skill set I've been building for my own client work over the last six months.
Why any of this matters
Claude and other agentic coding tools repeat the patterns they already see in your code. They treat your current code as the canonical example of how things are done, and they will reproduce the same patterns—and mistakes—over and over until they receive instructions that say otherwise. If you let the tool write forty separate queries to populate one screen, for example, it will repeat that with forty more on the next screen.
This isn't a design or implementation flaw on the part of the coding agents. It's how they are built and optimized. Agents like Claude Code, Codex, etc, see the existing code as the way the project works.
Fortunately, the fix for repeating bad patterns and mistakes is nothing new. The same set of practices that have always made software maintainable for human teams, is also what makes for successful AI coding agents:
- writing architectural decision records so the reasons behind your structure are known
- writing coding standards so the conventions are explicit and repeatable
- pulling both of these into the planning step
- and reviewing the plan before any code gets written.
Generally speaking, if it's good for people doing software development, it's good for agentic coding. This includes the notion that if you wait until the code is already written to ask whether it's any good, you've waited too long. The work that pays off most is the research and the plan, before any human or agent writes a single line of code.
The "rails" question
Software development practices arguably matter more in the world of agentic coding. And because these agents can't truly learn from the work they've already done, we must teach them how every time we want them to do anything. This is where skills and plugins come in. But the availability of skills doesn't mean all are created equal, or use the same flow of work that you and your team would use.
The real question, then, is how a given plugin asks you to apply these practices.
Superpowers and ouroboros are powerful precisely because they have a strong opinion about the path: they know the order things should happen, and they move you through that order, as long as you don't mind doing things the way they want them done. Think of a train on rails, where the track is well engineered and the ride is smooth, and it will get you there reliably, as long as the track already goes where you need to go.
Han takes a different approach. There's no executable to run and no sequence it marches you through. Instead, you pick the skill you want, when you want it. This approach is more closely aligned to a car and a good map than a train on rails: you choose the route and can change it at any intersection. And when you do that, the map still tells you which roads connect and which one to take, but it never takes control out of your hands.
There is a trade-off for this, though. A train on rails asks less of you and gives you less control in some ways. Having a map, on the other hand, requires you to know where you're going while giving you the freedom to decide how you want to get there. Neither option—rails vs maps—is the right one for all situations. Options exist because different teams and different people want different approaches, depending on the context of what they're doing.
What Han is
Han is a suite of AI skills and custom agent definitions, focused on solo engineers and small-teams, providing both a map and some direction on how to get to your destination. It offers guidance without forcing you down any given path. And it offers options that may or may not be what you need, next.
Much of the Han skill set sits on top of a team of specialized agent definitions. When you run a skill, it dispatches the agents that fit the job: project managers, adversarial reviewers, investigators, architectural analysts, testing and security specialists, etc. They do the judgment-heavy work, and the skill folds their findings into one or more evidence based artifacts.
These skills are designed to be composed, while also allowing you to run them independently and out of order. A typical run through building a feature may look like this:
- planning a feature
- iterating on that plan to ensure it's correct
- planning its implementation
- Implementing with test driven development
- reviewing the resulting code
- and writing the PR description
Each one of these steps is a named skill that hands off cleanly to the next. You can also run any one of them on its own and ignore the rest. Both options are first-class supported methods of using these skills.
Han is more than just a set of skills and agents, though. A few key guiding principles run through all of it:
- Evidence is required: Nearly every skill cites evidence before it commits a claim to an artifact
- Adversarial by default: Skills and agents argue with the work and stress-test the plan instead of agreeing with it
- YAGNI is built in: The "you aren't gonna need it" rule runs in the planning, review, and architecture skills, so they push back on speculative scope
- Skills size themselves: The planning and review skills decide how deep to go, then dispatch a small, medium, or large swarm of agents to match the problem
That last point is why the output tends to beat a single pass skill: a swarm of custom agents looks at the work from several different angles, and the skill reconciles what they find into one result.
Han is purpose-built to solve real problems
I built Han out of my own needs for client work, where agentic coding is a requirement rather than a nice-to-have. It's grounded in more than thirty years of building software and consulting, which mostly means it encodes the practices I have watched succeed and fail on real projects. It's focused on solo engineers and small teams, but it's flexible enough to use with teams of nearly any size in organizations that can scale across the globe.
Han isn't just my opinion set, though. Many people at Test Double use it at their own clients, and they're getting high praise for the quality of the work it produces. And being open source, Han has received and incorporated feedback from coworkers, from clients, and from the developer community at large.
How to get started with Han
Han contains nearly twenty skills and more than twenty agents, which is a lot to take in. To simplify getting started—and avoid trying to memorize every piece up front—I recommend installing Han from the marketplace and starting small.
/plugin marketplace add testdouble/han
/plugin install han@han
I recommend you start with these skills in Han:
- The iterative plan review skill is the one I keep coming back to, and neither Superpowers nor ouroboros has a direct equivalent. It takes a plan you already have and stress-tests it through several codebase-grounded passes, editing it in place and recording every finding, so the plan you hand to implementation is consistent, complete, and correct.
- The investigate skill has been widely praised by my coworkers and their clients for doing real root cause analysis instead of pattern-matching to the nearest plausible answer. It is evidence-based research into a bug or behavior, with an adversarial check on the proposed fix.
- The architectural decision record, coding standard, and project documentation skills tie straight back to why this matters. They write the ADRs, the standards, and the feature docs into the repository, where Han's own planning and review skills pick them up on the next run. That is how you stop the tool from repeating the same mistake on every new feature or fix.
- And plan a phased build keeps you from building too much at once. It splits a large feature into a numbered sequence of vertical slices, each one independently demo-able, allowing you to ship and learn iteratively and incrementally.
These planning and investigation skills will produce well structured documents that focus on human-readability and understandability, while also giving you complete traceability on the evidence used, the decisions made by the custom agents, and other artifacts that influence the final output.
Where you go from here is entirely up to you. Use a Ralph-loop to implement the plans. Use a coding agent to augment what you're writing. Use tried and true, human engineering principles and practices to write the code by hand. Han gave you the tools to read the map and make plans for how to get to your destination. The choice of how you get there is yours.
Use Han if you want research, planning, and implementation skills, without the rails
I won't claim Han is better than Superpowers or ouroboros. They're both excellent choices, as are countless other options. They're popular for good reasons, and a lot of people are doing great work with them. At the end of the day, Han isn't better or worse. It's different—and the difference is mostly the rails: if you want a strong path that carries you through, riding a train on rails is a good and valid option. If you would rather keep the wheel under your control, though, Han fits that perspective.
Whichever you pick, the core of my advice doesn't change. Treat your project like software engineering if you want it to last, and to be maintainable:
- Writing decisions down
- Setting and following standards
- Reviewing plans before coding
- Building iteratively and incrementally
Plenty of plugins help you do that, and each does it a little differently. Find what works for you, and use it.
River Lynn Bailey is a Senior Software Consultant at Test Double, and has experience in building agentic workflows and plugins for solo and small team environments.
