DEV Community: Avinash Seethalam

Building a Complete Developer Terminal Setup for Claude Code — Part 6: Dotfiles and Wrap-up

Avinash Seethalam — Sun, 26 Apr 2026 11:55:31 +0000

A setup you can't reproduce is a setup you'll eventually lose. Hard drives fail, Macs get replaced, and without a dotfiles repo everything built in this series disappears with them. This final part covers packaging everything into a maintainable dotfiles repo and wrapping up the series.

The Dotfiles Repo

A dotfiles repo is a version-controlled collection of your configuration files. The goal is simple: clone the repo on a new machine, follow the checklist, and have a fully configured environment in under an hour.

mkdir ~/dotfiles
cd ~/dotfiles
git init

Copy all configuration files in:

# Claude Code
mkdir -p .claude/hooks
cp ~/.claude/statusline.sh .claude/statusline.sh
cp ~/.claude/hooks/notify-stop.sh .claude/hooks/notify-stop.sh
cp ~/.claude/hooks/notify-permission.sh .claude/hooks/notify-permission.sh
cp ~/.claude/settings.json .claude/settings.json

# Terminal
cp ~/.tmux.conf .tmux.conf
cp ~/.zshrc .zshrc

# Starship
mkdir -p .config
cp ~/.config/starship.toml .config/starship.toml

Commit and push:

git add .
git commit -m "Initial dotfiles — Claude Code, tmux, starship, zsh"
gh repo create dotfiles --private --source=. --push

File Structure

dotfiles/
├── README.md
├── .tmux.conf
├── .zshrc
├── .config/
│   └── starship.toml
└── .claude/
    ├── settings.json
    ├── statusline.sh
    └── hooks/
        ├── notify-stop.sh
        └── notify-permission.sh

Fresh Machine Checklist

The README in the repo contains the full step-by-step setup guide. The checklist at the end covers every action in sequence:

[ ] Install Homebrew
[ ] Install core dependencies: brew install git jq node fzf
[ ] Install iTerm2 and set JetBrains Mono Nerd Font
[ ] Set terminal type to xterm-256color
[ ] Import tokyo-night color theme
[ ] Install zsh-autosuggestions and zsh-syntax-highlighting
[ ] Install fzf and run key bindings setup
[ ] Install starship and apply tokyo-night preset
[ ] Install tmux and clone tpm
[ ] Copy .tmux.conf and install plugins with Ctrl+B I
[ ] Install Claude Code
[ ] Copy .claude/settings.json, statusline.sh, and hook scripts
[ ] chmod +x the statusline and hook scripts
[ ] Add plugin marketplaces in Claude Code
[ ] Install all 9 plugins and reload
[ ] Verify plugin counts: 9 plugins · 35 skills · 18 agents · 10 hooks · 2 plugin MCP servers · 1 plugin LSP server
[ ] Verify claude-mem worker at http://localhost:37777
[ ] Test sound notifications with afplay
[ ] Test statusline with mock JSON input
[ ] Create tmux sessions and save layout with Ctrl+B Ctrl+S

What I'd Do Differently

If I were starting this setup from scratch with the knowledge I have now, I'd install claude-mem and pyright-lsp on day one. They have the highest ongoing return of anything in the stack — persistent memory and real-time type checking compound in value over time in a way that one-time tools don't.

I'd also build the statusline earlier. Flying blind on token usage and rate limits for the first weeks of Pro plan use cost me more than the hour it took to write the script.

The one thing I'd skip entirely is trying to get visual notification banners working. osascript and terminal-notifier are both unreliable on macOS Sequoia. afplay is the right answer and I should have gone there first.

The Full Stack

Layer	Tool	Purpose
Terminal	iTerm2 + tokyo-night	True color, Nerd Font support
Multiplexer	tmux + resurrect	Persistent sessions, 3-pane layout
Prompt	Starship tokyo-night	Git, Python, time at a glance
Shell	zsh + autosuggestions + fzf	Faster command entry
AI IDE	Claude Code	Primary development tool
Statusline	Custom bash script	Real-time token/cost/rate limit visibility
Hooks	`afplay` sound notifications	Async task completion awareness
Plugins	9 curated plugins	Code review, memory, type checking, workflow
Config	Private dotfiles repo	Reproducible setup in under an hour

The Series

Part 1 — The Problem and Overview
Part 2 — Custom Statusline
Part 3 — Sound Notification Hooks
Part 4 — Plugin Stack
Part 5 — Terminal Environment
Part 6 — Dotfiles and Wrap-up (this article)

All scripts and configuration files are at https://github.com/ai-with-avinash/claude-code-best-setup.

If you build on this setup or find improvements, I'd genuinely like to know — leave a comment or open a PR on the dotfiles repo.

Building a Complete Developer Terminal Setup for Claude Code — Part 5: Terminal Environment

Avinash Seethalam — Sun, 26 Apr 2026 11:48:59 +0000

The terminal environment around Claude Code matters as much as Claude Code itself. You spend hours in this environment — the less friction it has, the more thinking you can direct at the actual work.

This part covers everything outside Claude Code: iTerm2, tmux, starship, fzf, and zsh plugins.

iTerm2

Replace macOS Terminal with iTerm2. The reasons that matter for this setup specifically are true 24-bit color rendering (ANSI color gradients in the statusline render correctly), better escape code support (the blinking compaction warning needs this), and mouse support in tmux.

brew install --cask iterm2

Two settings to configure immediately after installing:

Font — install JetBrains Mono Nerd Font for starship icons and powerline segments:

brew install --cask font-jetbrains-mono-nerd-font

Then in iTerm2: Settings → Profiles → Text → Font → set to JetBrainsMono Nerd Font, size 13.

Terminal type — in iTerm2: Settings → Profiles → Terminal → Report Terminal Type → set to xterm-256color.

Color theme — download and import the tokyo-night theme:

curl -L -o ~/Downloads/tokyo-night.itermcolors "https://raw.githubusercontent.com/folke/tokyonight.nvim/main/extras/iterm/tokyonight_night.itermcolors"

Then Settings → Profiles → Colors → Color Presets → Import → select the file → apply.

tmux

tmux is a terminal multiplexer. For Claude Code development the value is twofold: persistent sessions that survive terminal restarts, and multiple panes visible simultaneously without switching tabs.

brew install tmux

My standard 3-pane layout:

┌─────────────────────┬──────────────┐
│                     │  Logs/Watch  │
│    Claude Code      ├──────────────┤
│                     │     Git      │
└─────────────────────┴──────────────┘

Claude Code runs in the large left pane. Test output or log watching runs top right. Git and manual commands run bottom right. Everything visible at once — no tab switching mid-flow.

Essential config — add to ~/.tmux.conf:

set -g mouse on              # trackpad scrolling
set -g history-limit 50000   # large scrollback buffer
set -sg escape-time 0        # no delay for escape key — important for Claude Code

Session persistence — install tmux-resurrect and tmux-continuum:

git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

Add to ~/.tmux.conf:

set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-restore 'on'
set -g @resurrect-capture-pane-contents 'on'
run '~/.tmux/plugins/tpm/tpm'

Press Ctrl+B then I inside tmux to install plugins. Save layout with Ctrl+B then Ctrl+S. After this, closing iTerm2 and reopening it restores your exact layout — pane positions, working directories, and running processes.

Starship Prompt

The default macOS prompt tells you almost nothing. Starship shows git branch, git status, Python version, and time directly in your prompt:

ocr-eval-framework on  main [x!?] via 🐍 v3.12.9  18:43

The [x!?] git status indicators: x = staged changes, ! = unstaged modifications, ? = untracked files. At a glance you know your exact repo state without running git status.

brew install starship
starship preset tokyo-night -o ~/.config/starship.toml
echo 'eval "$(starship init zsh)"' >> ~/.zshrc
source ~/.zshrc

fzf

fzf replaces linear Ctrl+R command history search with an interactive fuzzy finder. Type any fragment of a previous command and it filters in real time across your entire history. For long evaluation commands with specific flags you ran three sessions ago, this is invaluable.

brew install fzf
$(brew --prefix)/opt/fzf/install  # say y to all three prompts
source ~/.zshrc

Three shortcuts now available:

Ctrl+R — fuzzy search command history
Ctrl+T — fuzzy search files, paste path to prompt
Alt+C — fuzzy search directories and cd into selected

zsh Plugins

Two additions that change daily terminal use immediately:

zsh-autosuggestions shows previous commands in grey as you type based on history. Right arrow to accept the suggestion. After a day of use your muscle memory adapts and you stop retyping long paths from scratch.

zsh-syntax-highlighting colors commands green (valid) or red (invalid) as you type. Catches typos before you press Enter.

brew install zsh-autosuggestions zsh-syntax-highlighting
echo 'source /opt/homebrew/share/zsh-autosuggestions/zsh-autosuggestions.zsh' >> ~/.zshrc
echo 'source /opt/homebrew/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh' >> ~/.zshrc
source ~/.zshrc

The Full Visual Stack

With everything configured, your terminal looks like this:

Dark navy tokyo-night background in iTerm2
JetBrains Mono Nerd Font rendering icons cleanly
tmux status bar at the bottom showing session name and time
Starship prompt showing directory, git branch, git status, Python version
Claude Code statusline above the prompt showing tokens, cost, rate limits
Grey autosuggestions completing commands as you type
Green/red syntax highlighting on every command

Every layer of information has a deliberate place. Nothing is decorative.

All configuration files are at https://github.com/ai-with-avinash/claude-code-best-setup.

← Back to Part 4 | Continue to Part 6 → Dotfiles and Wrap-up

Building a Complete Developer Terminal Setup for Claude Code — Part 4: Plugin Stack

Avinash Seethalam — Sun, 26 Apr 2026 11:46:21 +0000

By Avinash, GenAI Practice Lead | Part 1 | Part 2 | Part 3 | Part 4 of 6

Claude Code has a growing plugin ecosystem. The temptation is to install everything — more agents, more skills, more coverage. This is the wrong approach, especially on a Pro plan.

Every plugin injects instructions into your session context at startup. A plugin with 38 agents and 156 skills adds a meaningful token overhead to every single session, whether you use those skills or not. On Pro where you're paying per input token, a bloated plugin stack is a recurring tax on every conversation.

I installed, evaluated, and removed several plugins before settling on 9 that earn their place. Here's the final stack and the reasoning behind each.

The 9 Plugins

caveman — strips filler from Claude's responses. No pleasantries, no hedging, just signal. The benchmarks show ~65% output token reduction on coding tasks. In practice the savings are real and the response style actually improves for tight coding loops — you get code and decisions, not explanations you didn't ask for. Activate with /caveman, deactivate with "normal mode" before switching to documentation or client-facing writing.

claude-mem — persistent memory across sessions. This is the most impactful plugin in the stack. Without it every Claude Code session starts completely blank — no knowledge of what you built yesterday, no context on architectural decisions made last week. With it, the session opens with a compressed summary of relevant past work injected automatically. For multi-week projects this eliminates the re-establishment overhead that quietly consumes 10-15 minutes of every session. It runs a background worker on port 37777 with a web viewer for your observation history.

code-review — 5 parallel Sonnet agents reviewing your code before pushes. Covers CLAUDE.md compliance, bug detection, historical context, PR history, and code comments simultaneously. Trigger with /code-review after any meaningful change.

pr-review-toolkit — deeper review covering tests, error handling, type design, code quality, and simplification. Use this before anything that goes into a production codebase or published whitepaper. Run with /pr-review-toolkit:review-pr all.

feature-dev — three-agent workflow for new features: explore codebase → architect solution → review quality. Reserve it for moments where you'd naturally step back and think about design before writing code. Overkill for bug fixes, well-suited for new model wrappers or evaluation dimensions.

commit-commands — auto-generates meaningful commit messages from staged changes. Replaces the cognitive overhead of writing commit messages at the end of a long session when you're tired and just want to push.

context7 — pulls current SDK documentation into context automatically when you're working with external libraries. When your code references a LiteLLM function or a Boto3 call, context7 fetches the current docs rather than relying on Claude's training data which may be stale on specific SDK versions.

taches-cc-resources — a collection of workflow commands worth knowing: /create-plans for structured project planning with PLAN.md, /debug-like-expert for systematic debugging with evidence gathering, and /ask-me-questions for requirement clarification before starting a large ambiguous task.

pyright-lsp — Python language server via Pyright. Gives Claude real-time type errors, import resolution, and go-to-definition across your codebase. Without it Claude reads files reactively when something breaks. With it, it sees problems as they exist in your code continuously.

What I Removed

everything-claude-code — 38 agents, 156 skills, 72 legacy command shims. The context footprint is enormous and the coverage largely duplicates what the targeted plugins above already handle. Removed.

Installing the Stack

Add the marketplaces first — these commands run inside a Claude Code session, not in your terminal:

/plugin marketplace add anthropics/claude-code
/plugin marketplace add anthropics/claude-plugins-official
/plugin marketplace add glittercowboy/taches-cc-resources
/plugin marketplace add thedotmack/claude-mem
/plugin marketplace add JuliusBrussee/caveman

Then install:

/plugin install code-review@claude-code-plugins
/plugin install pr-review-toolkit@claude-code-plugins
/plugin install feature-dev@claude-code-plugins
/plugin install commit-commands@claude-code-plugins
/plugin install context7@claude-plugins-official
/plugin install pyright-lsp@claude-plugins-official
/plugin install taches-cc-resources@taches-cc-resources
/plugin install claude-mem@thedotmack
/plugin install caveman@caveman

Reload with /reload-plugins. Expected output: 9 plugins · 35 skills · 18 agents · 10 hooks · 2 plugin MCP servers · 1 plugin LSP server.

Quick Reference

Plugin	Trigger	When to use
caveman	`/caveman`	All coding sessions
claude-mem	Auto	Always on
code-review	`/code-review`	Before any meaningful push
pr-review-toolkit	`/pr-review-toolkit:review-pr`	Before production or published code
feature-dev	`/feature-dev`	New features requiring design thinking
commit-commands	`/commit-commands:commit`	Every commit
context7	Auto	Working with external SDKs
taches-cc-resources	`/create-plans`, `/debug-like-expert`	Planning and complex debugging
pyright-lsp	Auto	Always on for Python projects

← Back to Part 3 | Continue to Part 5 → Terminal Environment

Building a Complete Developer Terminal Setup for Claude Code — Part 3: Sound Notification Hooks

Avinash Seethalam — Sun, 26 Apr 2026 11:40:26 +0000

By Avinash, GenAI Practice Lead | Part 1 | Part 2 | Part 3 of 6

The problem is simple: Claude Code finishes a task while you're reading documentation, reviewing a PR, or staring out the window. You have no idea it's done. You check back 5 minutes later to find it waiting. Multiply this across a full workday and the lost time adds up significantly.

The solution is a sound notification. Hear the sound, look at the screen. Simple.

Getting there was less simple than I expected.

What I Tried First

osascript is the standard macOS approach for sending notifications from bash:

osascript -e 'display notification "Task completed" with title "Claude Code ✅" sound name "Hero"'

On macOS Sequoia this runs silently and does nothing. No error, no notification. Apple tightened notification sandboxing in recent versions and osascript notifications now require Script Editor to be registered in System Settings → Notifications — and on many machines it never appears there at all.

terminal-notifier is the community-standard alternative:

brew install terminal-notifier
terminal-notifier -title "Claude Code ✅" -message "Task completed" -sound "Hero"

On Apple Silicon Macs running Sequoia, terminal-notifier 2.0.0 sends no notification and produces no error. After removing Gatekeeper quarantine flags with sudo xattr -dr com.apple.quarantine, trying the .app bundle path directly, and verifying the binary location — still nothing. The package is effectively broken on modern macOS.

What Actually Works

afplay is a macOS command-line audio player. It ships with every Mac, requires zero setup, and plays system sounds reliably:

afplay /System/Library/Sounds/Hero.aiff

No notification banner. Just sound. And for the actual use case — knowing when Claude is done without watching the screen — sound alone is sufficient. You're already in the terminal when you care about the visual output.

The Three Hooks

Claude Code fires hooks on specific events. I set up two hook scripts covering three scenarios:

Task complete (Stop event) → Hero sound
The most important hook. Fires when Claude finishes responding. Deep tone, clearly distinct from system sounds.

Permission needed (permission_prompt) → Glass sound
Fires when Claude needs your approval before proceeding. Higher pitch, slightly urgent. You hear this and know you need to look at the screen and make a decision.

Awaiting input (idle_prompt) → Ping sound
Fires when Claude is waiting for your next message. Softer, lower priority.

The notify-permission.sh script reads the notification_type field from the JSON payload using jq to distinguish between permission_prompt and idle_prompt and play the appropriate sound.

Wiring Up the Hooks

In ~/.claude/settings.json:

"hooks": {
  "Stop": [
    {
      "matcher": "",
      "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/notify-stop.sh"}]
    }
  ],
  "Notification": [
    {
      "matcher": "permission_prompt|idle_prompt",
      "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/notify-permission.sh"}]
    }
  ]
}

Also add the hook scripts to the permissions allow list so Claude Code doesn't prompt for approval every time they run:

"permissions": {
  "allow": [
    "Bash(bash ~/.claude/hooks/notify-stop.sh)",
    "Bash(bash ~/.claude/hooks/notify-permission.sh)"
  ]
}

Hooks only activate for new sessions — restart Claude Code after updating settings.json.

Testing the Sounds

Before wiring up the hooks, verify all three sounds play on your machine:

afplay /System/Library/Sounds/Hero.aiff
afplay /System/Library/Sounds/Glass.aiff
afplay /System/Library/Sounds/Ping.aiff

If any of these don't play, check System Settings → Sound → Output volume. afplay respects system volume but is not affected by Do Not Disturb.

Both hook scripts are at https://github.com/ai-with-avinash/claude-code-best-setup.

← Back to Part 2 | Continue to Part 4 → Plugin Stack

Building a Complete Developer Terminal Setup for Claude Code — Part 2: Custom Statusline

Avinash Seethalam — Sun, 26 Apr 2026 10:31:31 +0000

Building a Complete Developer Terminal Setup for Claude Code — Part 2: Custom Statusline

By Avinash, GenAI Practice Lead | Part 1 | Part 2 of 6

⚠️ Note: This setup is macOS-specific. All tools, commands, and configurations in this series are tested on macOS (Apple Silicon). Linux and Windows users will need to adapt certain steps, particularly around afplay, brew, iTerm2, and system font installation.

Claude Code supports a statusLine configuration that pipes a live JSON object to a bash script on every update. Most developers ignore this. I spent time building it out properly and it's now the most-glanced piece of my development environment.

Here's what my statusline shows in a real session:

Claude Sonnet 4.6 [Pro] | ⎇ feature/docling-eval | in:42k out:8k | ctx 61% | $0.0284 | +142/-38 | 5h 31% ⏱ 3h12m | 7d 18% ⏱ 4d6h

Each segment is deliberate. Let me walk through them.

What Each Segment Shows

Model name — Claude Sonnet 4.6 [Pro]. Useful when switching between Sonnet and Opus mid-project. You always know what you're paying for.

Git branch — ⎇ feature/docling-eval. The script uses workspace.current_dir from the JSON payload for accuracy in worktree setups, not the shell's current directory.

Token usage — in:42k out:8k. Input and output tokens in compact k format. Abbreviated above 1000, raw below — so early in a session you see in:340 out:89 and it flips to in:1k naturally as it grows.

Context % — ctx 61% with color thresholds tuned for Pro plan. Green below 50%, yellow at 50%, orange at 60%, red at 75%. These are tighter than defaults because on Pro every token in a compacted context gets re-billed.

Cost — $0.0284 to 4 decimal places. Three decimal places rounds sub-cent sessions in a way that loses signal. At 4dp you can see the actual cost of a session clearly.

Lines changed — +142/-38. Only appears when there are actual file edits. Stays clean during pure Q&A work.

5-hour rate limit — 5h 31% ⏱ 3h12m. Usage percentage and countdown to reset. On Pro this is what tells you whether to push through a task or wrap up cleanly.

7-day rate limit — 7d 18% ⏱ 4d6h. The weekly ceiling is the one that bites during multi-day project sprints. Knowing you're at 18% on Wednesday is actionable in a way that daily usage alone isn't.

Compaction warning — at 75% context the display shows a blinking ⚠ COMPACT. This fires earlier than the default because on Pro, hitting auto-compaction mid-task reruns your entire context through the API.

The Implementation

The script is pure bash with jq as the only dependency. jq is a command-line JSON parser — install it with brew install jq.

Wire it up in ~/.claude/settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

The script reads from stdin (input=$(cat)), extracts fields with jq, applies color logic with ANSI escape codes, and outputs a single line. The JSON payload contains everything — model info, context window state, cost, rate limits, and workspace path.

Testing Without a Live Session

You don't need to start a Claude Code session to test the script. Pipe mock JSON directly:

echo '{"model":{"display_name":"Claude Sonnet 4.6"},"workspace":{"current_dir":"/your/project"},"context_window":{"total_input_tokens":12000,"total_output_tokens":3000,"used_percentage":45},"cost":{"total_cost_usd":0.0084,"total_lines_added":42,"total_lines_removed":7},"rate_limits":{"five_hour":{"used_percentage":38,"resets_at":'"$(( $(date +%s) + 7200 ))"'},"seven_day":{"used_percentage":22,"resets_at":'"$(( $(date +%s) + 345600 ))"'}}}' | ~/.claude/statusline.sh

The reset timestamps are computed from now + seconds so the countdown shows real numbers.

One Tradeoff Worth Knowing

The used_percentage field is calculated from input tokens only — it does not include output tokens. So the context % reflects input-side pressure, which is the more meaningful signal for context window exhaustion, but it may differ slightly from what /context reports. The script displays raw input and output token counts separately precisely for this reason.

The full script is at https://github.com/ai-with-avinash/claude-code-best-setup.

← Back to Part 1 | Continue to Part 3 → Sound Notification Hooks

Building a Complete Developer Terminal Setup for Claude Code — Part 1: The Problem

Avinash Seethalam — Sun, 26 Apr 2026 10:12:40 +0000

By Avinash, GenAI Practice Lead

⚠️ Note: This setup is macOS-specific. All tools, commands, and configurations in this series are tested on macOS (Apple Silicon). Linux and Windows users will need to adapt certain steps, particularly around afplay, brew, iTerm2, and system font installation.

I lead a GenAI practice and manage a broad portfolio of active AI projects. A significant part of my day is spent inside Claude Code — building model evaluation frameworks, debugging pipelines, writing architecture documents, and reviewing code with my team. Claude Code is genuinely powerful, but after weeks of daily use I kept running into the same friction points.

Sessions started completely blind every time. No memory of what we built yesterday, no context on decisions made last week. I'd spend the first 10 minutes of every session re-establishing context that Claude had already processed the day before.

There was no visibility into token usage or cost while working. I'd hit a rate limit mid-task with no warning, losing momentum at the worst possible moment. On a Pro plan where every token has a cost, flying blind is expensive.

Claude finishing a task while I was context-switched elsewhere meant I'd come back 5 minutes later to find it waiting. No notification, no signal — just a blinking cursor.

And the terminal itself was a plain, low-information environment. No git context, no Python version, no time — just a prompt.

These aren't complaints about Claude Code. They're gaps in the surrounding environment that any developer can close with the right setup. So I spent a day closing them.

What I Built

Over a focused session I assembled a complete terminal environment optimised specifically for Claude Code development on macOS. Here's the full stack:

Claude Code layer:

Custom bash statusline showing model, git branch, token usage, cost, context %, and rate limit countdowns
Sound notification hooks using macOS afplay for task completion, permission requests, and idle state
9 curated plugins covering code review, persistent memory, Python type checking, and workflow automation

Terminal layer:

iTerm2 with tokyo-night color theme and JetBrains Mono Nerd Font
tmux with a 3-pane layout and session persistence across restarts
Starship prompt with tokyo-night preset showing git status and Python version
fzf for fuzzy command history search
zsh-autosuggestions and zsh-syntax-highlighting

Everything is committed to a dotfiles repo at https://github.com/ai-with-avinash/claude-code-best-setup with a fresh machine checklist so the entire setup can be reproduced on a new Mac in under an hour.

The Series

This is Part 1 of 6. Each subsequent article covers one layer of the setup in detail:

Part 2 — Custom Statusline: real-time token, cost, and rate limit visibility
Part 3 — Sound Notification Hooks: knowing when Claude is done without watching the screen
Part 4 — Plugin Stack: 9 plugins that earn their place and what I removed
Part 5 — Terminal Environment: iTerm2, tmux, starship, fzf, and zsh
Part 6 — Dotfiles Repo: packaging everything for reproducibility

Each part is self-contained — you can read them in any order depending on what's most relevant to your setup. But if you're starting fresh, the sequence matters and Part 2 is where I'd begin.

Continue to Part 2 → Custom Statusline