# I couldn't find a simple agent framework, so I wrote one

> Source: <https://dev.to/anmarhaniv1/i-couldnt-find-a-simple-agent-framework-so-i-wrote-one-39jp>
> Published: 2026-07-26 03:43:08+00:00

I keep finding a new agent skill I want to add to my library. Each one is a good addition on

its own, and that is exactly the trap. Skills are not free. Every one you add takes context,

and at some point it stops helping and may start making the model worse.

A bigger library looks like progress. I am not convinced it is.

The frameworks I looked at had the same problem, further along. All of them were cluttered with

dozens of features, a configuration surface to learn, and a cast of agents to keep straight

before writing any code. I wanted something small enough to hold in my head.

So I combined the best of what I already knew into one set and stopped there.

```
git clone https://github.com/AnmarHani/swarmvault && cd swarmvault && ./install.sh
```

13 is not a target. It is what was left after I took the skills I actually used or saw as good and rewrote (with the help of Claude)

them to fit together, cutting the overlap. What survived should be enough for most tasks.

If something is missing, the answer should be a thin extension, not another full skill

competing for the same context. That constraint is the whole idea, and it is the thing I would

ask you to judge it on.

Every skill also runs alone. Copy one into any agent's skills directory and it works with no

vault, no script, and no siblings.

The flow runs a requirements interview that ends in a real SRS, then design with the decisions

written down, then tickets in dependency order with tests in the definition of done. The point

is that the spec is not a document the agent writes and forgets. The agents follow it exactly,

and at every milestone a strong model audits the work back against it.

The same standard applies to what comes out. A lot of agent output is filler: code with

ceremony it does not need, docs written to look complete rather than to be read. Cutting that,

in code and in documentation, is part of the flow rather than something you clean up after.

The vault is a plain folder: `10 Projects`

, `20 Memory`

, `30 Plans`

, `40 Sessions`

,

`50 Decisions`

. The agent records what it decides is worth recording, and any later session on

any platform reads it back. One zero-dependency script gives every agent `query`

, `sync`

,

`claim`

, and `context`

over it.

Practically, that means you can open a fresh session and say "continue project X" and it picks

up where the last one stopped. A ticket belongs to whoever claims it first, so two agents

working in parallel do not land on the same work.

Optional, off unless you turn it on. It knows which agentic platforms you have, say Claude

Code and Codex and Cursor, and distributes work across them based on what each model is good

at, while taking usage limits into account.

There is a central board for watching it, and it is meant to work with any CLI rather than a

fixed list. Adding one is a launch-command template, not a plugin.

No dashboard, no hosted service, no plugin system. Claude Code and Codex are the verified

platforms; Gemini CLI, OpenCode, Cursor, and Copilot work from the same vault on a best-effort

basis. Linux, macOS, and WSL are first-class, native Windows is best-effort.

Nothing runs in the background unless you enable the orchestrator. No network calls, no

telemetry. Plain markdown on your disk, MIT.

The whole thing is small enough to read in an afternoon before you trust it with anything. That

was the point.
