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
The MCP server is how the assistant reads that packet and writes back to the record as it works - decisions, findings and pitfalls become events, not lines in a transcript nobody opens again. The installer registers it, along with the hook that closes a sitting when the assistant stops:
$ irm https://raw.githubusercontent.com/lacodda/rigger/main/tools/install.ps1 | iex
...
Registered the rigger MCP server with claude.
Added the Stop hook: a sitting now closes itself.
And for you, rather than for the assistant, the project's own screen - what it is, where it stands, what it has written down:
$ rigger show sample
sample
A sample product
path C:\dev\sample
gate cargo fmt --all --check && cargo clippy --all-targets -- -D warnings && cargo test
Last shipped v0.2.0 on 2026-09-03, 2 commits since
1 versions planned, 2 tasks open
Current stage: v0.3.0 · Search
> full-text index
a query language
Written down:
vision Vision of sample 2026-09-12 rigger doc show sample vision
Next step
Ship the importer next.
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 you get
- 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).
- 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.
- 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 and a release calendar, both derived from the same record rather than kept by hand.
- 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.
Status
The record, the context packet, the MCP server, facts from git, the owner's inbox, the release calendar and thin project skills are in daily use across the whole line. The rules a line and a project state about themselves, and the gate a project runs, are documents in the record rather than pasted into every project's skill.
Released versions and what landed in each: CHANGELOG.
Install
irm https://raw.githubusercontent.com/lacodda/rigger/main/tools/install.ps1 | iex
|
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 (c) Kirill Lakhtachev