Session: Auditing Git Histories to Build a tmux Toolkit

Posted by on

claude-codetmuxdeveloper-toolingworkflow-audit

Session: Auditing Git Histories to Build a tmux Toolkit

The False Start

The session started with a simple goal: check the Cinder project board on GitHub. The gh CLI was installed but the auth token had expired. Rather than re-authenticate (which would have taken 30 seconds), the conversation pivoted. If we’re going to do project management, let’s do it properly — let’s understand the workspace first.

That pivot turned into a full audit of how this Mac mini gets used as a development machine.

Discovery: What’s Actually Here

First pass was checking ~/Local_Dev/projects/ by modification date. Fifteen-plus project directories, some active, some dormant. The question was: which ones actually matter, and what does the work pattern look like?

The obvious approach — ls -lt — gives you recency but not volume. A project you touched once yesterday ranks above one you hammered for two weeks straight last month. We needed commit counts.

The Git History Audit

The core technique: iterate every project directory with a .git folder, extract commit timestamps, and aggregate.

for dir in ~/Local_Dev/projects/*/; do
  if [ -d "$dir/.git" ]; then
    git -C "$dir" log --format="%aI" --all 2>/dev/null
  fi
done

This produces one ISO 8601 timestamp per line, per commit, across all branches, for every project. Pipe it through cut to extract the hour, sort | uniq -c for the histogram.

The results were unambiguous:

  • 321 commits between midnight and 4am — 35% of all work output. The single largest block.
  • 230 commits between 1pm and 5pm — the afternoon burst, 25%.
  • 255 commits between 5pm and 11pm — the evening ramp, 28%.
  • 71 commits in the morning — 8%. Mornings are for coffee, not code.

This is a night-owl builder with a bimodal distribution: afternoon warm-up, then the real work happens after midnight.

Project Activity Ranking

Sorting projects by commit count since March 2026 produced a clear ranking:

  1. soma-chat-ai — 154 commits. The most active project by a wide margin.
  2. claude-relay — 101 commits. Second place, heavy sprint activity in March-April.
  3. NARSSR — 61 commits. The iOS RSS reader with visionOS extensions.
  4. bythewei — 49 commits. This site, the sprint board.
  5. threads-analysis — 48 commits. Observatory build.
  6. ByTheWeiCo — 34 commits. The portfolio/essay site.
  7. fire-my-lawyer — 26 commits. Newer project.
  8. cinder — 13 commits. Lower volume but active.

This ranking matters for tooling. The most active projects should have the shortest access paths.

Sprint-Burst Pattern

The commits don’t arrive in a steady stream. They cluster into bursts: 10-20 commits over 2-6 hours, then silence for 1-3 days. This is sprint-driven development. Each burst corresponds to a Claude Code session where multiple agents run in parallel.

The sprint.json file in bythewei confirmed the pattern. The stats array tracks “~20 agents spawned” as a metric. The scope_creep incidents array shows sessions that started as single-task fixes and exploded into multi-feature sprints. The Co-Authored-By: Claude lines in git logs map 1:1 with agent sessions.

We also found conventional commit prefixes in soma-chat-ai (feat:, docs:, security:, fix:) but not in other projects. The most active project has the most discipline. Makes sense — at 154 commits, you need structure.

Existing Tooling Audit

Before building anything, we checked what already existed:

  • ~/.tmux.conf — Did not exist. No tmux config at all.
  • ~/scripts/ — Did not exist. No script directory.
  • ~/bin/tmux-stats — Existed. A session dashboard with an ASCII art header, per-session breakdown, and system load. Worth keeping and enhancing.
  • ~/.zshrc — Had eza/bat/fzf/starship integration, a yolo alias, and basic git aliases (gs/gl/gd/ga/gc/gp). No tmux aliases.

The foundation was bare. The .zshrc had good taste (starship, modern CLI tools) but no tmux integration. The tmux-stats script showed someone had started thinking about session management but hadn’t followed through.

Design Decisions

With the audit data in hand, every design decision had a justification:

Auto-checkpoint script: Exists because 35% of commits happen midnight-4am. Long sessions without commits are dangerous. The script auto-commits every N minutes so intermediate states are always recoverable.

Agent layout shortcuts (C-a g, C-a G, C-a 4): Exist because ~20 agents per sprint means multi-pane tmux layouts are the norm, not the exception. One keypress to split into dual/triple/quad layout.

Project aliases ordered by commit activity: soma before relay before narssr. Not alphabetical. The most-used projects get the shortest aliases.

50K scrollback: Claude Code agents produce thousands of lines of output per session. The default 2K is laughably insufficient.

Prefix C-a over C-b: Pure ergonomics. The a key is on home row under the left pinky. You press the prefix key hundreds of times per session.

What We Skipped

cc-monitor.sh — A persistent system monitoring script. The audit showed no evidence of long-running monitoring habits. Dev servers get started and stopped within sessions. There’s no daemon-watching workflow to support. Skipped.

tmux plugins (tpm, tmux-resurrect, etc.) — No evidence these would solve a real problem. The session scripts handle layout creation. Auto-checkpoint handles state preservation. Adding a plugin manager for its own sake is the kind of cargo-culting we were explicitly trying to avoid.

Powerline / status bar widgets — The existing tmux-stats script serves as the dashboard. The status bar only needs to show the session name and time. Everything else is noise at 2am.

What We Installed

Six files total:

  1. ~/.tmux.conf — Prefix C-a, vim pane nav, intuitive splits, agent layout shortcuts, vim copy mode with pbcopy, mouse on, dark cyan status bar, 50K scrollback.

  2. ~/scripts/cc-session.sh — Creates cc-<project> tmux session with 3 panes: Claude Code left, shell top-right, git log bottom-right. Path validation, verbose output.

  3. ~/scripts/cc-dual.sh — Creates dual-<project> session with two side-by-side Claude Code agents for parallel swarm work.

  4. ~/scripts/cc-checkpoint.sh — Auto-commits every N minutes. Validates git repo, counts checkpoints, designed for midnight-4am sessions where you might forget to commit.

  5. Enhanced ~/bin/tmux-stats — Added project awareness (detects Local_Dev project, shows branch/dirty/latest commit), Claude Code process counter, listening ports section, quick reference card.

  6. ~/.zshrc additions — tmux aliases (tls/ta/tk/tn), fuzzy session picker (tf), cc-clean, cc/ccr/ccp, 10 project cd aliases, port/killport/ports, kill-orphans, gcheck. All non-conflicting with existing aliases.

The Meta-Lesson

The interesting part of this session wasn’t the tmux config. It was the methodology.

Most developers install tools based on recommendations: “here’s my dotfiles, here’s my tmux.conf, here’s my vim setup.” The recommendations come from someone else’s workflow. They might be good defaults, but they’re not your patterns.

Running git log --format="%aI" across your own projects takes 10 seconds. The data is already there, sitting in .git directories. The hour distribution tells you when you need your tools to be ready. The commit clustering tells you whether you work in sprints or streams. The project ranking tells you where your access paths should be shortest.

Build for what you actually do, not what you think you should do. The data doesn’t lie, even when your self-image does.

Session Stats

  • Time: ~2 hours
  • Files created/modified: 6
  • Projects audited: 15+
  • Total commits analyzed: ~900
  • Agents spawned this session: 1 (this was a config/audit session, not a build sprint)
  • Scope creep: Zero. Stayed on-task. The counter increments.