I previously introduced a Claude Code book in [2026-01-16-1] , but this time I’ll write about my own workflow.

Development Environment

I work on my MacBook’s built-in display. I’m not really someone who uses external monitors.

I display the macOS built-in Terminal.app in full screen and use tmux . I don’t split tmux windows—instead, I switch between tabs (windows). I haven’t (yet?) switched to Ghostty or iTerm2 .

My editor is Emacs . Before Claude Code came along, I had tried switching to VSCode several times and given up each time, but now I no longer need to think about it. What a relief.

On a related note, Emacs’s global-auto-revert-mode is really handy. When Claude Code edits a file that’s open in Emacs, the buffer automatically refreshes. Here’s my configuration .

For the Claude Code model, I use Opus 4.6 (1M context) both personally and at work. I basically don’t use Sonnet. My personal Claude plan alternates between Pro and Max, and on Max I get the 1M context.

Workflow

I follow a 3-step workflow starting from GitHub Issues.

1. Creating a Work Plan

The starting point is a custom skill (slash command) called /create-plan-for-gh-issue .

It creates a work plan as a Markdown file based on the content of a GitHub Issue. The Issue can be for creating a PR, doing research, or anything else.

The key is to write the necessary information in the Issue. It can go in the description or comments, and it’s fine if the content is messy. It also reads attached images.

After generating the plan, I go back and forth a few times to refine it.

2. Reviewing the Work Plan

I have a separate Claude Code session review the plan. When I’m unsure, I also have Codex review it.

I don’t use Codex directly very often—instead, I use it through a custom skill called /codex-discuss .

💡 /codex-discuss will start a discussion on whatever you pass as an argument, and even without arguments, it figures out what to discuss on its own. When it’s unclear what to discuss, it asks the user. I find it valuable for getting a third-party perspective, though the downside is that it’s slow…

Since the plan is a Markdown file, it’s easy to review, and there’s no problem even if the work carries over into the next week.

Once the plan is finalized, I paste it as a comment on the GitHub Issue for record-keeping. I used to commit plans to docs/plans/ in the repository, but stopped because deleted filenames would show up in grep results as noise, and it just didn’t feel right.

3. Executing and Reviewing the Work

Plans are typically divided into Phases, with each Phase expected to result in a commit.

For now, git operations are done manually by me. For suggesting commit messages, a custom skill called /suggest-commit-message has been very useful.

Before requesting a PR review, I run /review in a separate Claude Code session, and if I’m still unsure, I discuss it with /codex-discuss.

I also tried openai/codex-plugin-cc , but it didn’t quite fit my style.

Additionally, for reviewing PRs from Dependabot, /review-dependabot-pr has been very handy.

Conclusion

I’ve summarized how I use Claude Code as of April 2026.

I try not to over-customize Claude Code. Looking at Twitter, it seems like everyone is doing advanced things, but I try not to be too influenced and instead trust my own intuition.

The Claude Code configurations I introduced above are all gathered in the following dotfiles-public repository.

I’ll continue to refine my setup going forward, and I’m also planning to try out Codex.app , which has been getting good reviews.

Gleanings

Answering Yes/No Questions from Claude Code with y/n

When Claude Code asks a Yes/No question, y or n is sufficient. It’s a small thing, but it helps reduce token usage.

Interview-Style Hearings from Claude Code

When the task at hand is vague, having Claude Code conduct an “interview-style” hearing helps organize your thoughts.

When there isn’t enough information, Claude Code autonomously asks questions.

I have the line “Use the AskUserQuestion tool when asking the user for choices or decisions” in my ~/.claude/CLAUDE.md .

Keep Claude Code Sessions Short

I try not to extend Claude Code sessions too long, even when there’s room left in the context window. My experience is that noise from intermediate steps creeps in and things start to go a bit off.

By the way, I monitor the current context window (cw) usage via the Claude Code status line.

Here’s the configuration for the status line above:

• ~/.claude/settings.json#L49-L52
• ~/.claude/scripts/statusline.js

Notification Settings from Claude Code

To avoid missing when Claude Code finishes processing, I have a setup that sends notifications to both the tmux status line and the macOS Notification Center.

An article by Yoshida-san, a former colleague, was very helpful.

• Reliably Detecting “My Turn” in Claude Code - Zenn

Yoshida-san’s article explains in detail how spinner display and unread markers work. My setup is based on that, with the following adjustments:

• Common:
  • Added a Notification hook so I can be alerted by tmux’s unread marker and a notification sound even during idle states like waiting for tool approval
• tmux:
  • Added a SessionEnd hook to clean up the spinner, fixing the issue where the spinner kept spinning after exiting with /exit or C-c C-c
  • Introduced a heartbeat file that monitors mtime as a TTL, so the spinner also auto-stops when interrupted with Esc
  • Changed the unread indicator dot color from red to cyan, as cyan looks more like an “unread” marker
• macOS Notification Center:
  • Used different sounds for Notification (Funk) and Stop (Glass), so I can distinguish “attention needed” from “completed” by ear
  • Added (tmux:N) with the window number in the notification body, so I know which window to switch back to

Here’s the actual code:

• ~/.claude/settings.json#L53-L122 (hooks configuration)
• ~/.claude/scripts/tmux-spinner.sh
• ~/.claude/scripts/macos-notify.sh
• ~/.config/tmux/tmux.conf#L22-L32