README
¶
daybook
Your git log is an incomplete record of your day. This is the rest of it.
Reads your Claude Code sessions and your git history, and writes one report: what you actually worked on, what of it shipped, what broke, and what is still sitting on your laptop where nobody else can see it.
curl -fsSL https://github.com/humanikio/daybook/releases/latest/download/install.sh | sh
daybook init && daybook backfill 7
The report is written for someone else to read
The top of every day is grouped by capability, not by commit — because fourteen commits that together let you do one new thing are one thing that happened, not fourteen.
You can now test an ingest transform against payloads that actually arrived, choose which ones to run it against, and see how old each is.
readRecentPayloads.tsreads live rows alongside stored test sends,collectSamples.tsmerges the two and accepts an explicit list of payload ids, and the controller returns provenance per sample. The frontend addsPayloadPicker.tsx, a multi-select modelled on the field mapping editor.Look at:
src/ingest/services/collectSamples.ts·src/app/sources/[sourceId]/transform/page.tsx
api@7d26888f·web@0949b796on main
Plain language, then the mechanism for whoever maintains it, then the files and the branch. Every commit lands in exactly one entry — a day with sixty commits does not get five bullet points.
Hand it to a teammate and they know what changed and where to look.
Why your commit log undersells you
Measured over one real week: commits per hour swung 13× between days.
That is not effort. The heaviest day — twelve hours, 143 prompts — produced six commits, because the output was an architecture decision. The next day, the same threads executing, produced 34. Work also lands a day after it happens.
So a commit graph lags reality and inverts exactly when the thinking was hardest. daybook reads both sides and says which is which.
What it sees that git cannot
| Decisions | "Excluded shared infra costs from the P&L on the grounds they are not this product's." Recorded nowhere else. |
| What broke | A failing build or type check, separated from the tool calls you declined and the paths the agent mistyped. One real day reported 45 failures; one of them was the software. |
| Work that never committed | Research, an ops run, a client call, a data room. Days that look empty in git and were not. |
| What is stuck on your machine | Unpushed commits with their subjects, uncommitted files, per branch. "14 unpushed" is a number nobody can act on. |
| What is unproven | A running ledger of shipped-but-untested work, closed only against citable evidence, sorted oldest first. |
Four states, because done / not done is not enough
shipped |
on the remote |
local |
committed, never pushed — at risk |
open |
active, changes still in the tree |
stale |
silent for days, never shipped |
No git fetch needed: git push updates the local tracking ref, so the
unpushed count is already right for anything sent from this machine.
Honest about what it is guessing
Commits are matched to work in two tiers, and the report always prints the split rather than one clean number:
- exact — the session touched a file this commit changed. Provable.
- inferred — same repo, and the session was live nearest the commit.
Measured across eight real days: 55% exact overall, ranging 28–67% by day. The report prints the split per entry, so you always know which half you are reading. A commit nothing can claim is listed as unattributed rather than guessed at. Once matched it is pinned and never re-judged, so today's run cannot quietly rewrite yesterday's report.
Prose summaries, without the hallucinations
daybook scan --narrate
Uses the claude you are already signed in with — no key, no setup — or the
Anthropic API if you would rather not spend that quota. Neither passes a
credential through daybook.
Every sha and path in the model's output must appear in its input, or the narration is thrown away and the deterministic report stands alone. A record of what you did is worthless if it can invent a commit.
Everything else
daybook init guided setup, about a minute
daybook backfill 2w build the days from before you installed it
daybook scan today, against the last 24h
daybook day [date] read it — date, "today" or "yesterday"
daybook week rollup, with a per-day table
daybook open work that has not finished proving itself
daybook shoot photograph where the work lives — off by default
daybook config edit change settings with the arrow keys
daybook upgrade check whether a newer release exists
daybook service install run it nightly, as you, never as root
daybook verify check everything in one pass
A scan over a 1.1 GB transcript corpus and 23 repositories takes about two seconds. Backfilling a week takes fourteen.
Privacy
No telemetry, no sync, nothing phones home. The scan is entirely local.
Two features are exceptions, and both are opt-in. Narration sends the day's derived facts — your prompts, the assistant's replies, the commit subjects — to Anthropic through your own account. It never sends raw transcripts, the report, or anything about you.
Screenshots go further: they drive your real browser, as you, and write pictures of real screens into your reports folder. Redaction runs over text before it reaches disk and cannot run over a photograph. Leave both off and nothing ever leaves the machine.
Redaction runs before anything is written: AWS keys, bearer tokens, GitHub
tokens, private keys. Add your own patterns, or set
privacy.keep_raw_prompts: false to keep the whole shape of your day and none
of the words.
Output is 0600. Keep the folder private — it holds your prompt history.
The honest caveat
This parses ~/.claude/projects/*.jsonl, which is internal to Claude Code
and carries no compatibility guarantee — one reference corpus spanned 27 CLI
versions. Parsing fails soft per line rather than per file, and daybook verify
reports the parse-failure rate so breakage is visible instead of silent.
It will break eventually. Please open an issue when it does.
Docs
setup · narration · schedule · privacy · screenshots · record format · troubleshooting · releasing · browser detection
Install with Go instead: go install github.com/humanikio/daybook/cmd/daybook@latest
Every release binary is cosign-signed and shipped with checksums.
Releases
Every version is described in CHANGELOG.md, and the release workflow refuses to publish a tag that has no entry there. The procedure is docs/releasing.md.
Licence
MIT.
A note on names
daybook is an independent open-source project. It is not built, endorsed, sponsored by, or affiliated with Anthropic. "Claude" and "Claude Code" are trademarks of Anthropic, referred to here only to describe what this tool reads.
The transcript reader is one adapter behind an interface — other coding agents can be added without touching the join or the renderer. Today there is one, and it reads Claude Code.
Directories
¶
| Path | Synopsis |
|---|---|
|
cmd
|
|
|
daybook
command
Command daybook reports what you actually worked on each day, read from your Claude Code transcripts and joined against what genuinely shipped.
|
Command daybook reports what you actually worked on each day, read from your Claude Code transcripts and joined against what genuinely shipped. |
|
internal
|
|
|
config
Package config loads ~/.daybook/config.yaml.
|
Package config loads ~/.daybook/config.yaml. |
|
derive
Package derive is the join: streams on one side, commits on the other, and the rules that decide how far each piece of work has got.
|
Package derive is the join: streams on one side, commits on the other, and the rules that decide how far each piece of work has got. |
|
ledger
Package ledger keeps the running list of work that has not finished proving itself.
|
Package ledger keeps the running list of work that has not finished proving itself. |
|
model
Package model is the single definition of daybook's schema.
|
Package model is the single definition of daybook's schema. |
|
narrate
Package narrate turns the derived facts into prose.
|
Package narrate turns the derived facts into prose. |
|
platform
Package platform detects the parts of this machine daybook depends on but does not control.
|
Package platform detects the parts of this machine daybook depends on but does not control. |
|
preview
Package preview finds the way to see a change, rather than guessing it.
|
Package preview finds the way to see a change, rather than guessing it. |
|
render
Package render turns a day into something to read, and into the facts it was read from.
|
Package render turns a day into something to read, and into the facts it was read from. |
|
schedule
Package schedule decides when the next run is due.
|
Package schedule decides when the next run is due. |
|
selfupdate
Package selfupdate reports whether a newer daybook release exists.
|
Package selfupdate reports whether a newer daybook release exists. |
|
source
Package source is the adapter seam.
|
Package source is the adapter seam. |
|
source/claudecode
Package claudecode reads Claude Code's session transcripts.
|
Package claudecode reads Claude Code's session transcripts. |
|
svc
Package svc runs daybook as a native OS service — launchd on macOS, systemd on Linux, a logon task on Windows — and drives install/uninstall/start/stop.
|
Package svc runs daybook as a native OS service — launchd on macOS, systemd on Linux, a logon task on Windows — and drives install/uninstall/start/stop. |
|
tui
Package tui is the small amount of interactivity daybook needs: a list you move through with the arrow keys.
|
Package tui is the small amount of interactivity daybook needs: a list you move through with the arrow keys. |
|
vcs
Package vcs reads git — repository discovery, commit history, and how far each piece of work has travelled.
|
Package vcs reads git — repository discovery, commit history, and how far each piece of work has travelled. |
|
wizard
Package wizard is the guided first-run setup.
|
Package wizard is the guided first-run setup. |