clu

The problem it solves

The moment you run more than one AI coding session against the same project, they need a shared, durable place to coordinate. They have to pick up work without stepping on each other, record what they tried and what worked, gate risky steps behind a human, and tell at a glance what's unblocked versus waiting on something else.

clu is that place: a small, fast, single-binary CLI backed by a local SQLite database. No daemon, no server, no account, no network. It's named after Tron's Codified Likeness Utility, and it's built for the era of many small agents working together.

The core loop

Four verbs cover the everyday workflow — create issues, wire up the dependencies between them, ask what's ready, and claim the next unblocked one. Closing an issue automatically unblocks whatever depended on it.

clu init                                  # init .clu/ (DB + config)
clu create -p 1 "fix the login redirect"  # → clu-a3f81b
clu create -d clu-a3f81b "add tests"      # wire the dependency

clu ready                                 # what's unblocked?
clu claim --context                       # take next + its context
clu close clu-a3f81b                      # done → unblocks tests

Every command also takes --json and emits exactly one JSON value to stdout, so an agent can drive clu programmatically without scraping human-readable output.

Built for many agents

The piece that makes parallel agents safe is the atomic claim — a single UPDATE … RETURNING with a subquery, so two agents racing for the same lane always come away with different issues. On top of that:

• Capability routing — agents declare what they can do in config.yaml; capability-tagged issues flow to whichever agent advertises that capability.
• Context inheritance — clu claim <id> --context walks the upstream chain and prints each prerequisite's notes and comments, so an agent inherits the story of what came before.
• Heartbeats & a launcher — clu agent start <name> spawns a configured agent with layered prompts and heartbeats it, so clu agent ls shows who's live.

# .clu/config.yaml
agents:
  code-reviewer:
    description: "Reviews Go code for correctness and security"
    capabilities: [go-review, security-review]
    command: claude

Coordination beyond tickets

Some things don't fit a ticket, so clu ships a few sharp primitives for them: TTL'd named locks for shared resources, a fire-and-forget mailbox (clu ping / clu inbox) for inter-agent messages, milestones that auto-close when their dependencies do, and a cascading cancel that walks the dependency graph forward and abandons the whole tail at once. Every write lands in an append-only audit log you can replay with clu history and clu log.

Bulk graphs and workflows

For hand-authored pipelines there are YAML workflow templates — a graph of issues and dependencies with optional human-approval checkpoints, instantiated in one shot. For generated work there's clu batch: pipe in a JSON document describing thousands of interdependent issues, and clu validates the whole graph (acyclic, every reference resolves) and writes it in a single transaction — one bad entry aborts everything, so you never get a half-built graph.

generate-graph | clu batch --dry-run               # validate only, write nothing
generate-graph | clu batch --group "Auth rollout"  # commit under an umbrella

Design notes

clu is deliberately small and opinionated. It's a single pure-Go binary (SQLite via modernc.org/sqlite — no CGo, no system libraries), it keeps everything in one file you can commit alongside your code, and it never touches the network unless you explicitly opt into sharing over your own git remote. There's even a local web dashboard — clu web — for a kanban board, dependency graph, and approvals queue over the same SQLite file.

What it deliberately is not: a generic project-management tool, a live bridge to GitHub or Jira, or an agent runtime. You are the agent; clu just gives the work somewhere durable to live.