I open sourced a Claude Code skills library. It’s called hordev, and it exists because I kept losing the first ten minutes of every session to questions.

The pattern is familiar. You describe what you want. The agent comes back with five clarifying questions. Which state library. Should this throw or log. Do you want tests. By the time you’ve answered all of them, you’ve spent ten minutes specifying something that would have taken eight minutes to build, and you still have nothing to look at.

I don’t want to be interviewed. I want to see the thing and tell you what’s wrong with it.

Asking is how the model avoids being wrong

Every question the agent asks is a decision it no longer has to own. That’s the right trade when a wrong answer is expensive. Dropping the wrong table, charging the wrong card, emailing the wrong list. Ask me.

It’s the wrong trade for almost everything else. Library choice, file layout, naming, whether config lives in YAML or JSON. Getting one of those wrong costs a rebuild of something that took four minutes to build. Getting asked about all of them costs the session.

A wrong assumption you discover in ten minutes of building is cheaper than a right one extracted over ten minutes of questions.

What it does instead

hordev takes whatever you gave it, decides the rest, and writes a spec. It turns that spec into a test-driven design. It cuts the design into tasks that don’t write to the same files, dispatches all of them at once, merges what comes back, and runs QA on the result.

There is no sign-off anywhere in that chain. The spec goes to the design writer. The design goes to the horde. You see the result.

When the right approach isn’t obvious, it goes wide instead of deep. Two to four competing versions get built in parallel, under the same budget and the same judging criteria set in advance, and the winner gets picked on evidence from code that runs. That breadth is half of why I built it. A horde is good at exploring four directions at once, not just at doing one direction faster.

Every question it didn’t ask gets written down

Not asking is only honest if you can see what got decided for you.

So each skipped question becomes an entry in a ledger file: the assumption, how much breaks if it’s wrong, and what would prove it wrong. At the end of a run you get the open ones back, worst blast radius first, along with the branch the work is sitting on so you can review or discard the whole thing.

Without that ledger, skipping the interview is just an agent doing whatever it wants and not telling you.

Cheap agents do the volume

Model choice is architecture here, not a per-task judgment call.

Specs, designs, and implementation tasks run on Haiku. They’re high volume, well scoped, and template shaped, and QA catches what the speed costs. Orchestration, decomposition, merging, and QA run on Opus, because those are judgment and expensive to get wrong.

Fan out twelve tasks on the strongest model available and you’ve built something you can’t afford to run twice. That split is what makes a horde cheap enough to be worth having.

When not to use it

hordev descends from superpowers by Jesse Vincent, and it keeps that library’s tenets. Skills as version-controlled markdown. Tests before implementation. Artifacts that outlive the session. It diverges on pacing, and it is not an upgrade.

If you already have a spec you trust, use superpowers. Speed buys you almost nothing there, and you give up checkpoints you actually want. Same if you’re working inside a framework, or running long autonomous stretches on well-understood work. That structure is where superpowers earns its keep, and hordev deliberately gives some of it up.

hordev is for the other job. You don’t know what to build yet, several approaches look plausible, and the fastest way to find out is to have working versions of all of them in front of you.

It’s early

Version 0.1.0. Fourteen skills, two hooks, MIT licensed.

I haven’t run it across enough projects for its own self-improvement loop to have taught it anything, and that’s the part I’m most curious about. Runs append to a log. A hook notices when the log grows and asks whether anything should change a skill. The bar is a repeated failure, never a one-off.

Whether that produces better skills or just more of them, I don’t know yet.

Install it in Claude Code with two commands:

/plugin marketplace add heffrey/hordev
/plugin install hordev@hordev

Restart the session afterward. It needs bash and nothing else.

I built this the way I build everything else. I wanted it to exist, couldn’t buy it, and I’m the one who has to open it again tomorrow. Tell me where it’s wrong.