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. ...
Timbers: Building a Development Log That Works for Humans and AI We’re excited to share progress on Timbers, an open-source development logging tool that bridges the gap between how developers actually work and how teams need to document that work. Over the past few weeks, we’ve shipped the core functionality, and we want to pull back the curtain on what we built, why we made certain tradeoffs, and where we need community help. ...