Renamed exec-summary to standup this week. Tiny change in terms of surface area, surprisingly sprawling in practice — touched a hefty chunk of files across templates, docs, and the workflow coaching. The old name was accurate but nobody discovers a command called “exec-summary” when what they actually want is their standup notes. Pre-GA, low usage, so I just did a clean break. No alias. Aliases before you even have real users is complexity cosplaying as kindness. ...
The devblog generation pipeline was producing apology posts. That’s the kind of bug that makes you laugh and then immediately want to fix it. When no devlog entries existed for a cycle, the workflow still invoked the LLM, which — being a polite language model with nothing to say — generated posts that were basically “sorry, nothing happened this week!” Ten of these had accumulated. Ten blank apology posts sitting in the repo like little monuments to automation without guard rails. ...
Spent a chunk of time chasing a ghost in Claude Code’s hook system. The PostToolUse hook — fires after each tool invocation, perfect spot to nudge developers about pending devlog entries. Diagnostic confirmed everything works: hook fires, receives correct JSON on stdin, grep pattern matches. But echo output? Goes absolutely nowhere visible. Claude Code just swallows stdout from that hook silently. The hook runs. It does its job. Nobody hears it scream. ...
The ledger hit 69 entries, which felt like a natural moment to cut v0.10.0 and refresh everything downstream. Three features landed in this release, each small in isolation but collectively smoothing out real friction points. The one I’m happiest about: auto-commit on timbers log. This was a gap hiding in plain sight. The original design probably dates back to when entries lived in git-notes and didn’t touch the working branch at all. When we moved to .timbers/ files, entries started appearing in the worktree — staged but never committed. Users were confused. Why is this file just sitting here? Fair question. ...
Spent the last few days doing the kind of work that doesn’t make for dramatic storytelling but changes everything underneath: ripping out the storage layer and replacing it while the tool keeps running. The big move was pivoting from git notes to flat files. Git notes seemed elegant at first — metadata attached to commits, no working tree pollution. But in practice they’re a merge nightmare. Two worktrees writing notes to the same ref? Conflicts. Every time. The new approach is dead simple: one JSON file per entry under .timbers/, organized into YYYY/MM/DD buckets. Atomic writes via temp-file-and-rename. The GitOps interface went from 8 methods down to 4. I migrated all 37 existing entries with a bash script, ripped out every line of notes code, and wrote 14 integration tests proving that file-per-entry storage is inherently merge-safe. Sometimes the boring answer is the right answer. ...
Shipped v0.7.0 and v0.8.0 in the same day. That kind of pace only happens when the plumbing is already right and you’re just opening valves. The big piece: MCP server with 6 tools over stdio. One implementation that serves Claude Code, Cursor, Windsurf, Gemini CLI, Kilo Code, Continue, Codex — no per-tool CLI wrappers. timbers serve fires up, handlers call directly into internal/ packages, and that’s it. The filter functions had to move into internal/ledger/ so both CLI and MCP could share them, which was a surprisingly hefty chunk of plumbing, but the payoff is clean. Tagged v0.7.0 and moved on. ...
The day started with the biggest single chunk of work: timbers query grew --tag filtering. OR semantics, not AND — agents doing discovery want breadth, and you can always compose multiple queries to narrow down. Cobra’s StringSliceVar gives you repeated flags and comma separation for free, which is one of those small wins where the framework actually does the right thing. The filtering logic landed in entry_filter.go, extracted cleanly so export could pick it up immediately after. And it did — --tag on export was a quick follow-up, threading the flag through all three code paths (range, time, last) for consistency. ...
Building a Better Release Experience: This Week in Timbers Last week, we shipped something we’ve been planning for a while: automated releases and graceful handling of non-timbers git notes. These might sound like small infrastructure improvements, but they represent real quality-of-life wins for both users and contributors. Let me walk you through what we built and why we made these choices. The Release Pipeline: From Commit to curl|bash Getting software into users’ hands shouldn’t require them to be Go developers. We wanted timbers to be as easy to install as popular tools like ripgrep or fd, which meant setting up a proper release pipeline. ...
Modernizing CLI Output: A Journey Toward Better Readability We’ve just shipped a significant quality-of-life improvement for anyone using our CLI tools: a comprehensive styling system that makes output more readable, scannable, and visually organized. This post walks through what we built, why we built it this way, and where we could use your help. The Problem We Solved If you’ve spent time with our CLI lately, you’ve probably noticed that output can feel… utilitarian. Long walls of text, inconsistent formatting, and information that all blends together. This isn’t just an aesthetic concern—when you’re juggling multiple tools and switching between them frequently, visual clarity directly impacts productivity. ...
Timbers Dev Update: Documentation, Oversight, and Developer Experience Hello, Timbers community! This week we focused on something that might seem understated but is actually critical to the project’s mission: making it easier for humans to understand and oversee agent-assisted development at scale. Why This Matters Timbers exists at an interesting intersection. We’re a tool for capturing and analyzing development logs in an era where AI agents are becoming increasingly capable at writing code. But capability without comprehension is a liability. Our core value proposition isn’t just collecting data—it’s enabling developers, teams, and organizations to maintain meaningful human oversight of their development process, even as that process becomes more automated. ...