A decision for everything you own on GitHub
casebook
Decide what happens to every repo, pull request, issue, branch and worktree.
casebook records a decision for each of them in a private git repo you own. It watches GitHub and your clones for the moment a decision comes due or the world drifts from it, and shows you only what needs you, on a local page where an agent works beside you. You decide. Rules and the agent propose. Nothing changes outside your machine until you approve a plan, and casebook checks the world before and after every step.
the problem
A backlog across many repos, and the decisions are nowhere.
After a few years of work you own hundreds of repos across your account and a few orgs. There are pull requests from bots that nobody merged, issues waiting on your reply, forks you made to land one fix upstream, branches on two laptops that may or may not have landed, and worktrees you forgot. GitHub shows you each of them. Nothing records what you meant to do with them, so every cleanup starts from zero, and the work that lives on only one machine is the easiest to lose.
casebook keeps that record. Each item gets one decision, keep, archive, close, delete, merge, wait, watch or ignore, with a note and, where it helps, a condition such as merged(pr:owner/repo#97). From then on casebook compares the decision with what it observes. An item reaches your attention when it is new, when its condition comes due, when the world drifts from what you decided, or when a policy flags it: an incoming pull request with no reply from you for a week, or local commits on no remote for three days. Everything else stays quiet.
three ideas
You decide. Everything else proposes or checks.
1
you decide
Every decision is yours. The agent can investigate, attach evidence and propose, but it has no tool that decides. Accepting a proposal is one click, for one item or a whole selection.
2
rules propose, never decide
A standing rule is a filter plus a proposed decision. Its matches arrive as proposals that wait for you. It never overrides a decision you made, and it never proposes again an item you rejected, unless you edit the rule.
3
nothing outward without a plan
Carrying decisions out starts from a plan that shows the exact command for every step. Nothing runs until you approve it. Each step re-checks the world just before it runs, and is done only when a fresh observation shows it.
the page
One page, four parts.
casebook serve opens a page on your machine, bound to loopback. The bar and the agent panel stay where they are; the middle shows Attention, Rules or To apply, each as a list beside a reading column.
attention
What needs you, in views: waiting on you, new, due, proposed, and a board with the same items in lanes. Filter by kind, repo, relation, bot or human, age and rule. Select with a click, shift-click or x, then decide the whole selection in one sheet. Each decision is one commit to your casebook repo, and the selection goes out in one push.
the agent panel
The session working with you, its threads, and your messages as cards that show where each one is: queued, delivered, answered. Messages wait for the end of the agent's turn and arrive together, so it reads them all before it acts. A batch tray holds drafts you send as one, and a progress line shows what the agent is doing now.
rules
A rule as a document: its conditions, the decision it proposes, and its live matches, broken down by how they qualify. Untick a match to exclude it. A draft proposes nothing until you activate it, and only you can.
to apply
Decided items become a plan, and an approved plan becomes a job. Local, reversible steps run in casebook's own lane. Outward steps go to the agent's lane, and any public text waits on a needs you card until you post it, edit it or skip it. A verified step shows undo when its restore is automatic.
with an agent
Work with the agent you already use.
casebook never calls a model. An agent session joins through casebook channel, an MCP server that brings your page messages into the session as channel events and gives the agent casebook's tools: read the attention list, show an item, propose, attach evidence, draft a rule, report progress, and work the steps of a job you approved.
pi
The channel connects through channels.tools: name casebook channel in ~/.pi/agent/channels.json. pi-casebook does the rest. It journals the session's git and gh calls, briefs the first turn on the repo, syncs in the background, and tells casebook when a turn ends so queued messages go out.
claude code
Register casebook channel as an MCP server and launch Claude with the channel enabled. A Stop hook runs casebook settled --harness claude at the end of each turn, and two more hooks journal Bash calls and brief the session on its repo.
The agent page has the configuration for both, and every tool the agent gets.
install
Install with one command.
casebook is a single binary for macOS and Linux, on Apple silicon and x86-64. It is built in the tackle monorepo and published at tackle.tools/dl/casebook/. This installer downloads it from there, verifies its checksum, and puts it in ~/.local/bin.
# downloads casebook, verifies its checksum, installs it to ~/.local/bin $ curl -fsSL https://casebook.tools/install.sh | sh # then, once on each machine $ casebook init $ casebook hooks install $ casebook sync
casebook init uses <your GitHub login>/casebook-data, creating it as a private repo when it does not exist. casebook works through gh, so sign in to it first. On macOS, kempt can do the whole setup from casebook's manifest: the binary, the Claude Code hooks and channel, the pi channel, and a sync every 30 minutes. For pi, add pi install npm:pi-casebook. The docs cover each.
your data
The record is a git repo you own.
Decisions, rules, restore records, a journal of git and gh activity, and a snapshot of each machine's clones all live in casebook-data: a private GitHub repo that only casebook writes, with linear history and one commit per decision. Every machine that runs casebook keeps a clone, so a decision made on one machine reaches the others at their next sync.
items/. The only intent casebook keeps.rules/<id>.toml, one file per standing rule.restores/<date>.tsv, written and committed before each destructive step in casebook's lane.journal/<machine>/: the verbs and targets of git and gh actions. Never command lines, messages or bodies.machines/<machine>.json: each machine's clones, branches and worktrees.README.md, CONTRIBUTIONS.md and MACHINES.md, rendered at each sync and readable on github.com.The page's working state (your messages to the agent, its proposals and evidence, jobs and their steps) stays on the machine in a local database. A proposal becomes part of the record only when you accept it. The format page documents every file.
read on
Guide and reference.
guide →
A first triage from install to an applied plan: sync, decide a batch, ask the agent, write a rule.
docs →
Install, every command, casebook serve, configuration, paths and keys.
agent →
The channel, its delivery queue, the agent's tools, pi-casebook, and setup for pi and Claude Code.
rules →
Conditions, fields and operators, the until forms, and which decisions each kind allows.
apply →
Plans, the two lanes, preconditions, confirmations, restore records, verification, pause and undo.
format →
The casebook-data repository, file by file.