How I vibe(7)

Name

How I vibe

tags

I am a process driven developer. I find my work more fulfilling when I understand and am confident in my solution.

Solving the problem is more rewarding than knowing the answer.

But, Developers are paid to provide answers and AI provides a lot of answers. This post outlines my setup, workflow, and gotchas.

Setup

git Worktrees

I use hidden-bare git worktrees to allow me to have multiple agents running at the same time.

~/Code/myRepo
├── .git
├── .myRepo
├── feature
│   ├── new-feature-one 
│   └── new-feature-two
└── main

To set this up, you clone the repository into the .myRepo folder, then .git is a simple redirection to that folder.

 mkdir myRepo
 cd myRepo
 git clone --bare $REPO_URL .myRepo
 echo "gitdir: ./.myRepo" > .git
 git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*" 

The last line is really important if you ever want to review your coworkers' work; it tells git how to fetch remote branches within the worktrees.

Note: When using Graphite (or manually stacking changes), each stack gets its own worktree.

At work, where I'm making a lot more branches, I have a script that creates the worktree, installs all the dependencies, and opens it in tmux.

tmux

Worktrees map 1:1 with Tmux sessions. I have three key components that make tmux function: a CLI tool create sessions, a fuzzy finder for those sessions, and Claude status for each session shown in the fuzzy finder.

First, my script - bmm - just reads the current git repository and branch/worktree name and creates or attaches to a tmux session. Next, I have a Television picker to switch tmux sessions. The picker's preview panel also shows the status of all Claude Code sessions. This lets me quickly see what agents need my attention. You can find the picker, preview, and claude code hooks at their respective links. Lastly, I have a tmux key-bind (<prefix>-t) to open the picker in a popup window.

Other Small Setup Notes

  • Write a script to create worktrees & install dependencies for repositories you branch in often.
  • Have a dedicated thumb key for the tmux prefix.

Workflow

After creating the worktree, I use a customized version of obra/superpowers to guide the agent, steps with human interaction are denoted by "H". The agent is always in "auto" mode, I don't use "plan" mode.

  • (H) Prompt
    • (H+A) Refine
  • Implement
    • Automated Feedback
  • (H) Code Review
    • Back to Prompt/Implement, maybe with a /compact.

My initial prompts are often a short, bulleted descriptions of what needs to be done. Sometimes the ticket can be used with light editing. Creating a larger more detailed plan is the left to the agent. It's very important to verify the agents plan during the "Refine" step, it's easier to correct the agent before it starts writing code and dilutes its context. The implementation steps are almost completely agent driven. However, it does rely on a thorough, reliant, and fast automated checks.

Lastly, the Code Review step is just boring old code review. I have a NeoVim plugin that allows me to annotate the changes locally, much like the GihHub PR review process. nvim +Review pulls up the current unstaged changes, and nvim +"Review commits" lets me select a span to review.

Depending on the scale of the changes, I'll have the agent make a new plan, or for simple fixes it can go straight to implementation. If the changes are completely wrong, use the existing context in the agent to generate a 'seed' prompt to steer a fresh agent in the right direction.