rigger

The problem

Run more than a handful of projects and the record scatters: a plan here, a changelog there, a session log the assistant writes for itself, a release calendar kept by hand. You stop reading it, because prose cannot be filtered or summed across projects. The assistant reads it every session at full price, and the biggest project no longer fits in a context window. The facts about what shipped live in git, where nobody looks.

rigger keeps the record as data in a local SQLite file and derives everything else from it.

What rigger does

One model, two profiles

Projects, versions, tasks and sessions. At home a version is a stage that ends in a tag; at work a task is a ticket across several projects and branches. The same binary serves both through a profile.

Facts from git

A pushed tag means the version shipped, on that date. Commits since the last tag are activity. The plan cannot claim more than git confirms; a mismatch is reported, never silently fixed.

A context packet, not a hub

rigger context prints what the assistant needs to start - state, current stage, open questions and wishes a line each, last events, next step - inside a fixed token budget that is tested, not hoped for. rigger event reads any line whole.

An MCP server as the only pen

Decisions, findings, pitfalls, changes and the next step are recorded through tools, as events with a date and a session. Nothing is written by editing markdown.

The owner's inbox

Every question waiting for your answer, across all projects, in one list. Answer it and the answer becomes a decision on record.

What to work on now

rigger pick names one project across the line, the stage it is on and the one reason it comes first - the calendar, work no sitting has seen, an answer waiting, a tier behind, or simply its turn. The same answer is an MCP tool.

Hubs as an export

The markdown you keep in your notes is generated from the database: stable bytes for a stable database, so the history in git stays readable. The end of every sitting writes it again wherever nobody touched it, and doctor --hubs names a file somebody wrote in.

Nothing left over

Every file of every hub is in the record - the texts, the samples and scripts beside them byte for byte, a retired project’s notes, the line’s own files beside the hubs. doctor --hubs says in one line whether the directory may go, and export --all --docs writes it back.

Status

In daily use across a line of products ahead of 1.0: the record, the context packet, the MCP server, facts from git, the owner’s screens and the pick of what comes next, task cards at work, hubs kept as a view of a record that holds every file in them, and a JSON contract for every command. The command reference says which release brought what, and the CHANGELOG what landed in each.