Rigger

One seat for all your projects and tasks: a local record of what is done, what is next and when it ships - read by you and your coding assistant.

Why

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

rigger keeps the record as data, in a local SQLite file, and derives everything else from it: the five-line digest you read, the context packet the assistant starts from, the calendar of what ships when, and the queue of decisions waiting for you.

A first look

$ rigger init
Created C:\Users\you\AppData\Local\lacodda\rigger\data\rigger.db (schema version 4)
Next: rigger project add <path>

$ rigger project add C:\dev\sample
Recorded 'sample' at C:\dev\sample
  remote: https://github.com/acme/sample.git

$ rigger import sample --hub C:\dev\sample\hub
sample:
  versions   3 added, 0 updated
  tasks      2 added, 0 updated
  decisions  1 added
  questions  1 added

$ rigger doctor
database:  C:\Users\you\AppData\Local\lacodda\rigger\data\rigger.db
schema:    version 4
projects:  1
versions:  3
tasks:     2
sessions:  0
events:    2

Years of notes arrive in one command, and running it again is quiet. Then a session starts from the packet rather than from the notes:

$ rigger context sample
# sample

C:\dev\sample
https://github.com/acme/sample.git
Last shipped: v0.2.0 on 2026-09-03
1 versions planned, 2 tasks open

## Current stage: v0.3.0 · Search
- full-text index
- a query language

## Waiting for the owner
- [2] Pick the release day.

## Recent
- 2026-09-03 · decision · The record is the database — Prose cannot be filtered.

## Next step
Ship the importer next.

That packet costs 96 tokens here and holds a 3000-token budget on a project with years of history - against tens of thousands for reading the notes it came from, which past a certain size no longer fit at all.

One command hands it to your assistant and starts the session in the project:

$ rigger open sample
Starting claude in C:\dev\sample with the packet for sample

Connect the MCP server instead, and the assistant reads the same packet and writes back to the record as it works - decisions, findings and pitfalls become events, not lines in a transcript nobody opens again:

$ claude mcp add rigger -- rigger mcp
Added stdio MCP server rigger with command: rigger mcp to local config

What actually shipped is not taken on trust. sync reads the repository's tags and commits in-process and writes what they prove; where the plan says a version shipped and no tag agrees, the disagreement is reported rather than corrected:

$ rigger sync claimed
claimed:
  shipped    v0.1.0 on 2026-09-04
  read       2 changes from commit messages
  no tag     v0.2.0 is closed in the plan

Those changes come out of the commit messages themselves - feat, fix and anything breaking, dated by the commit rather than by the sync - so the chronicle stays current whether or not anyone opens a session.

Once there is a record, it answers questions - which is the point of keeping it as data:

$ rigger find budget
sample       2026-09-04  decision  The budget is a gate, not a suggestion.
sample       2026-09-04  pitfall   A wide window hides what the budget dropped.

$ rigger why sample v0.3.0
v0.3.0 — shipped 2026-09-04
the work after v0.2.0 (2026-09-04)

2026-09-04  decision  The budget is a gate, not a suggestion.
2026-09-04  pitfall   A wide window hides what the budget dropped.
2026-09-04  change    feat: rank what a person wrote above a commit

And it answers the question the notes never could - what is waiting on you, across everything at once:

$ rigger inbox
6 questions in 3 projects

alpha        [  1] 2026-09-04  Place in the release calendar
             [  2] 2026-09-04  Sign the binaries?
beta         [  3] 2026-09-04  Place in the release calendar

Asked by several projects - one answer settles each group:
  Place in the release calendar — alpha, beta, gamma

And it lays the releases out over the weeks, comparing what you aimed at with what the tags say happened:

$ rigger calendar --from 2026-W37 --weeks 5
         2026-W37  2026-W38  2026-W39  2026-W40  2026-W41
sample   *v0.1.0             >v0.2.0             ·v0.3.0    A
widget             +v0.1.0   ·v0.2.0                        B

+ shipped as planned   > slipped   ! overdue   * unplanned   · planned

sample   v0.2.0 — aimed at 2026-W37, 2 weeks late

A project is named after its directory - the name you call it by, not the one its manifest publishes under - and --name overrides. Every command that shows facts also prints them with --json.

What it will do

• Projects, versions, tasks, sessions. A project has a map of versions; a version is a stage that ends in a tag; a task is a unit of work inside a version (at home) or a ticket across several projects and branches (at work). One model, two profiles.
• 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 context packet instead of a hub. rigger context <project> prints what the assistant needs to start - state, current stage, open questions, last events, next step - within a fixed token budget.
• An MCP server as the assistant's only pen. Decisions, findings, pitfalls, changes and the next step are recorded as events through tools, not by editing markdown.
• The owner's inbox. Every question waiting for your answer, across all projects, in one list.
• A release calendar with tiers and rhythm, derived from the same data - the plan is a week, the fact is a tag, and the gap between them is named.
• Hubs as an export. The markdown files you keep in Obsidian are generated from the database, not written by hand.
• Thin project skills. The file an assistant reads first is one template filled from the record, not sixteen kilobytes of ritual kept by hand per project.

Status

v0.18.0 brings the desk its cards. A card is a ticket in the record - a key, the aliases it went by before it moved, a summary, the repositories it is worked in with a branch in each, and everything written against it. rigger task find takes a task exactly as it was handed over - an id, a title, two case numbers - and says whether to take a card, ask, or make a new one, with the matching a script ran a desk on for a year: an id is certain, a title is compared by bigrams and by the words it shares, a case number lifts a card, and a number mentioned only in what was written against another card is the trail of a task that moved. task new, open, active, close, link, rename, note and context are the card's day; over MCP, task_find, task_context and a task argument on every recording tool. Before it, v0.17.0 gave rigger a second way of working. A profile is a record of its own - its database, its roots, its way of naming work - and every command reads the current one without being told: line for the products of a line, tickets for the desk at work, where the unit is an id worked on branches across several repositories. The config is a TOML file a person edits; profile add, set and use write it. The database from before profiles is moved into the default profile on first use, with the old file kept. A task's status is a word from a vocabulary now - new, active, waiting-handoff, frozen, done - given by task status or set_task_status over MCP and shown in the packet; a hub's empty box means "not done" and no longer resets it. This is the release that changes the shape of the data before 1.0; the schema migrates itself, with a copy of the database taken first. Before it, v0.16.0 put a whole line through rigger. Every hub of a real line is now written from the record and every project skill is generated, and what that took was the other half of reading a hub: a hub kept by hand for a month is not the hub the first import read. A task struck from the plan is dropped rather than kept as open work for ever, a stage renumbered by hand leaves no ghost, a question the owner struck is withdrawn, a version known only from a tag is a fact rather than an empty changelog entry, and a diary entry read once without its date is one entry. A hub the record writes keeps growing without a hand: session end leaves its diary entry in the record, and note --kind state (record_state over MCP) puts a line at the top of the README's state block. doctor --hubs names the hubs still kept by hand. Before it, v0.15.0 made moving a project onto rigger two commands. rigger adopt <dir> --hubs <dir> walks a directory of checkouts, records each one that has a hub, imports the hub and reads the tags - the three commands a project used to take, once for a whole line, and the command to run again when the line has grown. rigger skill <project> --install writes the project's skill from one template and the record, so a change to the ritual is one edit rather than seventeen; a line writes its own template, a project keeps what only it can say in a file of its hub, and a skill somebody wrote by hand is not replaced until asked. Found on the way: a second import of a hub put the hub's release date back over the one the tag proved, and every sync after it reported the version shipped anew - a fact from git now stays. Before it, v0.14.0 turned the record back into notes: rigger export writes a project's hub out of the database and import reads it back, nineteen of the twenty hubs of a real line byte for byte, and a hub kept by hand is not overwritten until --adopt hands it over. Before that: the database, import, the context packet, the mcp server, facts from git, a chronicle that writes itself, search, the owner's inbox and digest, the release calendar, the week as a brief and a shopfront queue, the cycle looked back on, and sittings the record knows. The road to 1.0 is twenty-two small releases in seven blocks:

Block	Versions	What it delivers
Record	0.1 - 0.5	database and projects, hub import, the context packet, a Claude Code session from it, the MCP server
Facts	0.6 - 0.8	tags and commits as truth, changes read from commits, search and "why"
Owner	0.9 - 0.12	inbox and digest, the release calendar, the Monday brief, retro
Sessions	0.13 - 0.14	sessions with an end-of-session journal, hubs exported from the database
Line	0.15 - 0.16	thin project skills, every project of a line recorded at once
Tasks	0.17 - 0.21	the ticket profile, task cards, activity from branches, incoming material, snooze and handoff
Stabilisation	0.22	--json everywhere, docs, a signed binary where needed

1.0 "Truth in the database": a full week where every session on every project runs through rigger and no hub is edited by hand. A desktop window (Tauri) and code knowledge follow in 1.x.

Install

irm https://raw.githubusercontent.com/lacodda/rigger/main/tools/install.ps1 | iex

curl -fsSL https://raw.githubusercontent.com/lacodda/rigger/main/tools/install.sh | sh

npm i -g @lacodda/rigger
cargo install rigger

Every installer also leaves rgr beside rigger - the same program under a shorter name, as a link rather than a second copy, so it cannot fall behind. It is skipped when rgr already means something else on your machine, and RIGGER_NO_ALIAS=1 turns it off. cargo install produces rigger only.

Documentation

https://lacodda.github.io/rigger/ - getting started, concepts, and a reference page per command. Architecture decisions live in https://github.com/lacodda/rigger/tree/main/docs/adr.

License

MIT - see https://github.com/lacodda/rigger/blob/main/LICENSE.