ykdojo/claude-code-tips

Here are my tips for getting the most out of Claude Code, including a custom status line script and Claude Code running itself in a container. Also includes the dx plugin: skills for everyday dev workflows.

📺 Quick demo - See some of these tips in action with a multi-Claude workflow and voice input:

• Tip 0: Customize your status line
• Tip 1: Learn a few essential slash commands
• Tip 2: Talk to Claude Code with your voice
• Tip 3: Break down large problems into smaller ones
• Tip 4: Using Git and GitHub CLI like a pro
• Tip 5: AI context is like milk; it's best served fresh and condensed!
• Tip 6: Getting output out of your terminal
• Tip 7: Set up terminal aliases for quick access
• Tip 8: Proactively compact your context
• Tip 9: Complete the write-test cycle for autonomous tasks
• Tip 10: Cmd+A and Ctrl+A are your friends
• Tip 11: Invest in your own workflow
• Tip 12: Search through your conversation history
• Tip 13: Multitasking with terminal tabs
• Tip 14: Git worktrees for parallel branch work
• Tip 15: Manual exponential backoff for long-running jobs
• Tip 16: Claude Code as a writing assistant
• Tip 17: Markdown is the s**t
• Tip 18: Preserve links when pasting
• Tip 19: Isolated environments for long-running risky tasks
• Tip 20: The best way to get better at using Claude Code is by using it
• Tip 21: Fork and half-clone conversations
• Tip 22: Use realpath to get absolute paths
• Tip 23: Understanding CLAUDE.md vs Skills vs Slash Commands vs Plugins
• Tip 24: Interactive PR reviews
• Tip 25: Claude Code as a research tool
• Tip 26: Mastering different ways of verifying its output
• Tip 27: Claude Code as a DevOps engineer
• Tip 28: Keep CLAUDE.md simple and review it periodically
• Tip 29: Claude Code as the universal interface
• Tip 30: It's all about choosing the right level of abstraction
• Tip 31: Use auto mode
• Tip 32: Control Claude Code from your phone
• Tip 33: Learn to use artifacts
• Tip 34: Write lots of tests (and use TDD)
• Tip 35: Be braver in the unknown; iterative problem solving
• Tip 36: Running bash commands and subagents in the background
• Tip 37: The era of personalized software is here
• Tip 38: Navigating and editing your input box
• Tip 39: Spend some time planning, but also prototype quickly
• Tip 40: Simplify overcomplicated code
• Tip 41: Automation of automation
• Tip 42: Share your knowledge and contribute where you can
• Tip 43: Keep learning!
• Tip 44: Install the dx plugin
• Tip 45: Quick setup script
• Tip 46: Switch between multiple Claude accounts
• Tip 47: Use GitHub as your knowledge base
• Tip 48: Learn to review code through a TESTING.md document
• Tip 49: Turn on the concise output style

You can customize the status line at the bottom of Claude Code to show useful info. I set mine up to show the model, current directory, git branch (if any), uncommitted file count, sync status with origin, and a visual progress bar for token usage. It also shows a second line with my last message so I can see what the conversation was about:

Opus 4.5 | 📁claude-code-tips | 🔀main (scripts/context-bar.sh uncommitted, synced 12m ago) | ██░░░░░░░░ 18% of 200k tokens
💬 This is good. I don't think we need to change the documentation as long as we don't say that the default color is orange el...

This is especially helpful for keeping an eye on your context usage and remembering what you were working on. The script also supports 10 color themes (orange, blue, teal, green, lavender, rose, gold, slate, cyan, or gray).

To set this up, you can use this sample script and check the setup instructions.

There are a bunch of built-in slash commands (type / to see them all). Here are a few worth knowing:

Check your rate limits:

 Current session
 █████████▌                                         19% used
 Resets 5:39pm (America/Vancouver)

 Current week (all models)
 ██▌                                                5% used
 Resets Sep 6 at 9:59am (America/Vancouver)

 Current week (Fable)
 █████                                              10% used
 Resets Sep 6 at 9:59am (America/Vancouver)

If you want to watch your usage closely, keep it open in a tab and use Tab then Shift+Tab or ← then → to refresh.

Manage Claude's native browser integration:

 Status: Disabled
 Extension: Installed

 ❯ Manage permissions
   Reconnect extension
   Enabled by default: No

 Usage: claude --chrome or claude --no-chrome

Manage MCP (Model Context Protocol) servers:

 Manage MCP servers
 3 servers

   User MCPs (/Users/ykdojo/.claude.json)
 ❯ playwright · ✔ connected · 24 tools

   claude.ai
   → Show unused connectors (1)

   Built-in MCPs (always available)
   computer-use · ◯ disabled

View your usage statistics with a GitHub-style activity graph:

      Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug
      ················································▒▒▓▓
  Mon ················································▒▓█
      ················································██░
  Wed ················································▒░░
      ···············································█░▒█
  Fri ···············································░▒·█
      ···············································▓▓▓░

      Less ░ ▒ ▓ █ More

  Favorite model: Fable 5         Total tokens: 755.6m

  Sessions: 157                   Longest session: 16h 45m 11s
  Active days: 24/26              Longest streak: 15 days
  Most active day: Aug 27         Current streak: 9 days

  Your input and output are ~12x the tokens in Moby-Dick

Clear the conversation and start fresh.

I found that you can communicate much faster with your voice than typing with your hands. Using a voice transcription system on your local machine is really helpful for this.

On my Mac, I've tried a few different options:

• superwhisper
• MacWhisper
• Super Voice Assistant (open source, supports Parakeet v2/v3)

You can get more accuracy by using a hosted service, but I found that a local model is strong enough for this purpose. Even when there are mistakes or typos in the transcription, Claude is smart enough to understand what you're trying to say. Sometimes you need to say certain things extra clearly, but overall local models work well enough.

For example, in this screenshot you can see that Claude was able to interpret mistranscribed words like "ExcelElanishMark" and "advast" correctly as "exclamation mark" and "Advanced":

I think the best way to think about this is like you're trying to communicate with your friend. Of course, you can communicate through texts. That might be easier for some people, or emails, right? That's totally fine. That's what most people seem to do with Claude Code. But if you want to communicate faster, why wouldn't you get on a quick phone call? You can just send voice messages. You don't need to literally have a phone call with Claude Code. Just send a bunch of voice messages. It's faster, at least for me, as someone who's practiced the art of speaking a lot over the past number of years. But I think for a majority of people, it's going to be faster too.

A common objection is "what if you're in a room with other people?" I just whisper using earphones - I personally like Apple EarPods (not AirPods). They're affordable, high quality enough, and you just whisper into them quietly. I've done it in front of other people and it works well. In offices, people talk anyway - instead of talking to coworkers, you're talking quietly to your voice transcription system. I don't think there's any problem with that. This method works so well that it even works on a plane. It's loud enough that other people won't hear you, but if you speak close enough to the mic, your local model can still understand what you're saying. (In fact, I'm writing this very paragraph using that method on a flight.)

Update: Claude Code now has a built-in voice mode. I tested it and it works well, but I still personally use a local model because I find it faster.

This is one of the most important concepts to master. It's exactly the same as traditional software engineering - the best software engineers already know how to do this, and it applies to Claude Code too.

If you find that Claude Code isn't able to one-shot a difficult problem or coding task, ask it to break it down into multiple smaller issues. See if it can solve an individual part of that problem. If it's still too hard, see if it can solve an even smaller sub-problem. Keep going until everything is solvable.

Essentially, instead of going from A to B:

You can go from A to A1 to A2 to A3, then to B:

A good example of this is when I was building my own voice transcription system. I needed to build a system that could let the user select and download a model, take keyboard shortcuts, start transcribing, put the transcribed text at the user's cursor, and wrap all of this in a nice UI. That's a lot. So I broke it down into smaller tasks. First, I created an executable that would just download a model, nothing else. Then I created another one that would just record voice, nothing else. Then another one that would just transcribe pre-recorded audio. I completed them one by one like that before combining them at the end.

Highly related to this: your problem-solving skills and software engineering skills are still highly relevant in the world of agentic coding and Claude Code. It's able to solve a lot of problems on its own, but when you apply your general problem-solving and software engineering skills to it, it becomes a lot more powerful.

Just ask Claude to handle your Git and GitHub CLI tasks. This includes committing (so you don't have to write commit messages manually), branching, pulling, and pushing.

I personally allow pull automatically but not push, because push is riskier - it doesn't contaminate the origin if something goes wrong with a pull.

For GitHub CLI (gh), there's a lot you can do. One thing I started doing more after using Claude Code is creating draft PRs. This lets Claude Code handle the PR creation process with low risk - you can review everything before marking it ready for review.

And it turns out, gh is pretty powerful. You can even send arbitrary GraphQL queries through it. For example, you can even find the exact times at which GitHub PR descriptions were edited:

⏺ Bash(gh api graphql -f query='
      query {
        repository(owner: "...", name: "...") {
          pullRequest(number: ...) {
            userContentEdits(first: 100) {
              nodes { editedAt editor { login } }
            }
          }
        }
      }')

⏺ Here's the full edit history for your PR description:

  | #  | Edited At (UTC)     | Editor |
  |----|---------------------|--------|
  | 1  | 2025-12-01 00:08:34 | ykdojo |
  | 2  | 2025-12-01 15:57:21 | ykdojo |
  | 3  | 2025-12-01 16:24:33 | ykdojo |
  | 4  | 2025-12-01 16:27:00 | ykdojo |
  | 5  | 2025-12-04 00:40:02 | ykdojo |
  ...

By default, Claude Code adds a Co-Authored-By trailer to commits and an attribution footer to PRs. You can disable both by adding this to ~/.claude/settings.json:

{
  "attribution": {
    "commit": "",
    "pr": "",
    "sessionUrl": false
  }
}

Setting commit and pr to empty strings removes the attribution text entirely. This replaces the older includeCoAuthoredBy setting, which is now deprecated.

sessionUrl is a separate flag (default true): Claude Code also adds a Claude-Session: trailer to commits and a session link to PR bodies. Set it to false to turn that off.

When you start a new conversation with Claude Code, it performs the best because it doesn't have all the added complexity of having to process the previous context from earlier parts of the conversation. But as you talk to it longer and longer, the context gets longer and the performance tends to go down.

So it's best to start a new conversation for every new topic, or if the performance starts to go down.

Sometimes you want to copy and paste Claude Code's output, but copying directly from the terminal isn't always clean. Here are a few ways to get content out more easily:

• /copy command: The simplest option - just type /copy to copy Claude's last response to your clipboard as markdown
• Clipboard directly: On Mac or Linux, ask Claude to use pbcopy to send output straight to your clipboard
• Write to a file: Have Claude put the content in a file, then ask it to open it in VS Code (or your favorite editor) so you can copy from there. You can also specify a line number, so you can ask Claude to open the specific line it just edited. For markdown files, once it's open in VS Code, you can use Cmd+Shift+P (or Ctrl+Shift+P on Linux/Windows) and select "Markdown: Open Preview" to see the rendered version
• Opening URLs: If there's a URL you want to examine yourself, ask Claude to open it in your browser. On Mac, you can ask it to use the open command, but in general asking to open in your favorite browser should work on any platform
• GitHub Desktop: You can ask Claude to open the current repo in GitHub Desktop. This is particularly useful when it's working in a non-root directory - for example, if you asked it to create a git worktree in a different directory and you haven't opened Claude Code from there yet

You can combine some of these together too. For example, if you want to edit a GitHub PR description, instead of having Claude edit it directly (which it might mess up), you can have it copy the content into a local file first. Let it edit that, check the result yourself, and once it looks good, have it copy and paste it back into the GitHub PR. That works really well. Or if you want to do that yourself, you can just ask it to open it in VS Code or give it to you via pbcopy so you can copy and paste it manually.

Of course, you can run these commands yourself, but if you find yourself doing it repetitively, it's helpful to let Claude run them for you.

Since I use the terminal more because of Claude Code, I found it helpful to set up short aliases so I can launch things quickly. Here are the ones I use:

• c for Claude Code (this is the one I use the most)
• ch for Claude Code with Chrome integration
• cr for claude remote-control, to start a server you can drive from your phone
• gb for GitHub Desktop
• co for VS Code
• q for going to the project directory where I have most projects. From there I can manually cd into an individual folder to work on that project, or I can just launch Claude Code with c to let it basically have access to any project it needs to access.

To set these up, add lines like this to your shell config file (~/.zshrc or ~/.bashrc):

alias c='claude'
alias ch='claude --chrome'
alias cr='claude remote-control'
alias gb='github'
alias co='code'
alias q='cd ~/Desktop/projects'

Once you have these aliases, you can combine them with flags: c -c continues your last conversation, and c -r shows a list of recent conversations to resume. These work with ch too (ch -c, ch -r) for Chrome sessions.

There's a /compact command in Claude Code that summarizes your conversation to free up context space. Automatic compaction also happens when the full available context is filled (you can make it run earlier with /autocompact). But I found that it's better to proactively do it and manually tune it. I turned off auto-compact with /config so I have more control over when and how compaction happens.

The way I do this is to ask Claude to write a handoff document before starting fresh. Something like:

Put the rest of the plan in the system-prompt-extraction folder as HANDOFF.md. Explain what you have tried, what worked, what didn't work, so that the next agent with fresh context is able to just load that file and nothing else to get started on this task and finish it up.

Claude will create a file summarizing the current state of work:

⏺ Write(experiments/system-prompt-extraction/HANDOFF.md)
  ⎿  Wrote 129 lines to experiments/system-prompt-extraction/HANDOFF.md
     # System Prompt Slimming - Handoff Document
     ## Goal
     Reduce Claude Code's system prompt by ~45% (currently at 11%, need ~34% more).
     ## Current Progress
     ### What's Been Done
     - **Backup/restore system**: `backup-cli.sh` and `restore-cli.sh` with SHA256 verification
     - **Patch system**: `patch-cli.js` that restores from backup then applies patches
     ...

After Claude writes it, review it quickly. If something's missing, ask for edits:

Did you add a note about iteratively testing instead of trying to do everything all at once?

Then start a fresh conversation. For the fresh agent, you can just give the path of the file and nothing else like this, and it should work just fine:

> experiments/system-prompt-extraction/HANDOFF.md

In subsequent conversations, you can ask the agent to update the document for the next agent.

I've also created a /handoff slash command that automates this - it checks for an existing HANDOFF.md, reads it if present, then creates or updates it with the goal, progress, what worked, what didn't, and next steps. You can find it in the skills folder, or install it via the dx plugin.

If you want Claude Code to run something autonomously, like git bisect, you need to give it a way to verify results. The key is completing the write-test cycle: write code, run it, check the output, and repeat.

For example, let's say you're working on Claude Code itself and you notice /compact stopped working and started throwing a 400 error. A classic tool to find the exact commit that caused this is git bisect. The nice thing is you can let Claude Code run bisect on itself, but it needs a way to test each commit.

For tasks that involve interactive terminals like Claude Code, you can use tmux. The pattern is:

1. Start a tmux session
2. Send commands to it
3. Capture the output
4. Verify it's what you expect

Here's a simple example of testing if /context works:

tmux kill-session -t test-session 2>/dev/null
tmux new-session -d -s test-session
tmux send-keys -t test-session 'claude' Enter
sleep 2
tmux send-keys -t test-session '/context' Enter
sleep 1
tmux capture-pane -t test-session -p

Once you have a test like this, Claude Code can run git bisect and automatically test each commit until it finds the one that broke things.

This is also an example of why your software engineering skills still matter. If you're a software engineer, you probably know about tools like git bisect. That knowledge is still really valuable when working with AI - you just apply it in new ways.

Another example is simply writing tests. After you let Claude Code write some code, if you want to test it, you can just let it write tests for itself too. And let it run on its own and fix things if it can. Of course, it doesn't always go in the right direction and you need to supervise it sometimes, but it's able to do a surprising amount of coding tasks on its own.

Sometimes you need to be creative with how you complete the write-test cycle. For example, if you're building a web app, you could use Playwright MCP, Chrome DevTools MCP, or Claude's native browser integration (through /chrome). I haven't tried Chrome DevTools yet, but I've tried Playwright and Claude's native integration. Overall, Playwright generally works better. It does use a lot of context, but the 200k context window is normally enough for a single task or a few smaller tasks.

The main difference between these two seems to be that Playwright focuses on the accessibility tree (structured data about page elements) rather than taking screenshots. It does have the ability to take screenshots, but it doesn't normally use them to take actions. On the other hand, Claude's native browser integration focuses more on taking screenshots and clicking on elements by specific coordinates. It can click on random things sometimes, and the whole process can be slow.

This might improve over time, but by default I would go with Playwright for most tasks that aren't visually intensive. I'd only use Claude's native browser integration if I need to use a logged-in state without having to provide credentials (since it runs in your own browser profile), or if it specifically needs to click on things visually using their coordinates.

This is why I disable Claude's native browser integration by default and use it through the ch shortcut I defined previously. That way Playwright handles most browser tasks, and I only enable Claude's native integration when I specifically need it.

Additionally, you can ask it to use accessibility tree refs instead of coordinates. Here's what I put in my CLAUDE.md for this:

# Claude for Chrome

- Use `read_page` to get element refs from the accessibility tree
- Use `find` to locate elements by description
- Click/interact using `ref`, not coordinates
- NEVER take screenshots unless explicitly requested by the user

I've also run into a couple of issues with it - it doesn't always pick the local browser (#74667), and there's no way to enable it from a Remote Control session, like when I'm working from my phone (#74671) - so I built Browser Bridge, an open source alternative that addresses both.

In my personal experience, I've also had a situation where I was working on a Python library (Daft) and needed to test a version I built locally on Google Colab. The trouble is it's hard to build a Python library with a Rust backend on Google Colab - it doesn't seem to work that well. So I needed to actually build a wheel locally and then upload it manually so that I could run it on Google Colab. I also tried monkey patching, which worked well in the short term before I had to wait for the whole wheel to build locally. I came up with these testing strategies and executed them by going back and forth with Claude Code.

Another situation I encountered is I needed to test something on Windows but I'm not running a Windows machine. My CI tests on the same repo were failing because we had some issues with Rust on Windows, and I had no way of testing locally. So I needed to create a draft PR with all the changes, and another draft PR with the same changes plus enabling Windows CI runs on non-main branches. I instructed Claude Code to do all of that, and then I tested the CI directly in that new branch.

I've been saying this for a few years now: Cmd+A and Ctrl+A are friends in the world of AI. This applies to Claude Code too.

Sometimes you want to give Claude Code a URL, but it can't access it directly. Maybe it's a private page (not sensitive data, just not publicly accessible), or something like a Reddit post that Claude Code has trouble fetching. In those cases, you can just select all the content you see (Cmd+A on Mac, Ctrl+A on other platforms), copy it, and paste it directly into Claude Code. It's a pretty powerful method.

This works great for terminal output too. When I have output from Claude Code itself or any other CLI application, I can use the same trick: select all, copy, and paste it back to CC. Pretty helpful.

Some pages don't lend themselves well to select all by default - but there are tricks to get them into a better state first. For example, with Gmail threads, click Print All to get the print preview (but cancel the actual print). That page shows all emails in the thread expanded, so you can Cmd+A the entire conversation cleanly. For asking questions about a YouTube video or summarizing it, you can click "Show transcript" on a YouTube video and then do Cmd+A or Ctrl+A.

This applies to any AI, not just Claude Code.

Personally, I've created my own voice transcription app from scratch with Swift. I created my own custom status line from scratch using Claude Code, this one with bash.

But you don't have to go overboard like that. Just taking care of your own CLAUDE.md, making sure it's as concise as possible while being able to help you achieve your goals - stuff like that is helpful. And of course, learning these tips, learning these tools, and some of the most important features.

All of these are investments in the tools you use to build whatever you want to build. I think it's important to spend at least a little bit of time on that.

You can ask Claude Code about your past conversations, and it'll help you find and search through them. Your conversation history is stored locally in ~/.claude/projects/, with folder names based on the project path (slashes become dashes).

For example, conversations for a project at /Users/yk/Desktop/projects/claude-code-tips would be stored in:

~/.claude/projects/-Users-yk-Desktop-projects-claude-code-tips/

Each conversation is a .jsonl file. You can search through them with basic bash commands:

# Find all conversations mentioning "Reddit"
grep -l -i "reddit" ~/.claude/projects/-Users-yk-Desktop-projects-*/*.jsonl

# Find today's conversations about a topic
find ~/.claude/projects/-Users-yk-Desktop-projects-*/*.jsonl -mtime 0 -exec grep -l -i "keyword" {} \;

# Extract just the user messages from a conversation (requires jq)
cat ~/.claude/projects/.../conversation-id.jsonl | jq -r 'select(.type=="user") | .message.content'

Or just ask Claude Code directly: "What did we talk about regarding X today?" and it'll search through the history for you.

When running multiple Claude Code instances, staying organized is more important than any specific technical setup like Git worktrees. I recommend focusing on at most three or four tasks at a time.

My personal method is what I would call a "cascade" - whenever I start a new task, I just open a new tab on the right. Then I sweep left to right, left to right, going from oldest tasks to newest. The general direction stays consistent, except when I need to check on certain tasks, get notifications, etc.

Here's what my setup typically looks like:

In this example:

1. Leftmost tab - A persistent tab running my voice transcription system (always stays here)
2. Second tab - Setting up a Docker container
3. Third tab - Checking disk usage on my local machine
4. Fourth tab - Working on an engineering project
5. Fifth tab (current) - Writing this very tip

If you're working on multiple things at the same time in the same project and you don't want them to get conflicted, Git worktrees are a great way to do that. You can just ask Claude Code to create a git worktree and start working on it there - you don't have to worry about the specific syntax.

The basic idea is that you can work on a different branch in a different directory. It's essentially a branch + a directory.

You can add this layer of Git worktrees on top of the cascade method I discussed in the multitasking tip.

A git worktree is just like any other git branch, but with a new directory specifically assigned to it.

So if you're working on, let's say, the main branch and feature-branch-1, then without git worktrees, you can only work on them one at a time because your project folder can only be set to one branch at a time.

However, with a git worktree, you can keep working on the main branch (or any other branch for that matter) in the original project folder, and at the same time work on feature-branch-1 in a new folder.

When waiting on long-running jobs like Docker builds or GitHub CI, you can ask Claude Code to do manual exponential backoff. Exponential backoff is a common technique in software engineering, but you can apply it here too. Ask Claude Code to check the status with increasing sleep intervals - one minute, then two minutes, then four minutes, and so on. It's not programmatically doing it in the traditional sense - the AI is doing it manually - but it works pretty well.

This way the agent can continuously check the status and let you know once it's done.

(For GitHub CI specifically, gh run watch exists but outputs many lines continuously, which wastes tokens. Manual exponential backoff with gh run view <run-id> | grep <job-name> is actually more token-efficient. This is also a general technique that works well even when you don't have a dedicated wait command handy.)

For example, if you have a Docker build running in the background:

And it keeps going until the job completes.

Claude Code is an excellent writing assistant and partner. The way I use it for writing is I first give it all the context about what I'm trying to write, and then I give it detailed instructions by speaking to it using my voice. That gives me the first draft. If it's not good enough, I try a few times.

Then I go through it line by line, pretty much. I say okay, let's take a look at it together. I like this line for these reasons. I feel like this line needs to move over there. This line needs to change in this particular way. I might ask about reference materials as well.

So it's this sort of back-and-forth process, maybe with the terminal on the left and your code editor on the right:

That tends to work really well.

Typically when people write a new document, they might use something like Google Docs or maybe Notion. But now I honestly think the most efficient way to go about it is markdown.

Markdown was already pretty good even before AI, but with Claude Code in particular, because it's so efficient as I mentioned with regards to writing, it makes the value of markdown higher in my opinion. Whenever you want to write a blog post or even a LinkedIn post, you can just talk to Claude Code, have it be saved as markdown, and then go from there.

A quick tip for this one: if you want to copy and paste markdown content into a platform that doesn't accept it easily, you can paste it into a fresh Notion file first, then copy from Notion into the other platform. Notion converts it to a format that other platforms can accept. If regular pasting doesn't work, try Command + Shift + V to paste without formatting.

It turns out the reverse also works. If you have text with links from other places, let's say from Slack, you can copy it. If you paste it directly into Claude Code, it doesn't show the links. But if you put it in a Notion document first, then copy from there, you get it in markdown, which of course Claude Code can read.

Alternatively, you can just ask Claude Code to read your clipboard. It normally knows exactly what command to use - on Mac, that's pbpaste - and it's able to use that command to fetch the content without changing the formatting.

Isolated environments are great for --dangerously-skip-permissions sessions where you don't have to give permission for each little thing. You can just let it run on its own for a while. This is useful for research or experimentation, things that take a long time and maybe could be risky.

There are two major ways of going about it:

1. You can run it in a container. I even created a preset environment to make running containerized Claude Code sessions easy.
2. You can take it a step further by setting up a whole machine Claude Code can fully control, computer use included.

There's also auto mode, which is a sensible default in general - Claude runs autonomously while a classifier reviews each command and only stops for risky ones. But this still doesn't remove the risks and the need for approval entirely, so for tasks where you want it to have complete independence, you can still use a container.

You can take this further by having your local Claude Code control another Claude Code instance running inside a container. The trick is using tmux as the control layer:

1. Your local Claude Code starts a tmux session
2. In that tmux session, it runs or connects to the container
3. Inside the container, Claude Code runs with --dangerously-skip-permissions
4. Your outer Claude Code uses tmux send-keys to send prompts and capture-pane to read output

This gives you a fully autonomous "worker" Claude Code that can run experimental or long-running tasks without you approving every action. When it's done, your local Claude Code can pull the results back. If something goes wrong, it's all sandboxed in the container.

Beyond just Claude Code, you can run different AI CLIs in containers - Codex, Antigravity CLI, or others. I tried OpenAI Codex for code review, and it works well. The point isn't that you can't run these CLIs directly on your host machine - you obviously can. The value is that Claude Code's UI/UX is smooth enough that you can just talk to it and let it handle the orchestration: spinning up different models, sending data between containers and your host. Instead of manually switching between terminals and copy-pasting, Claude Code becomes the central interface that coordinates everything.

Recently I saw a world-class rock climber being interviewed by another rock climber. She was asked, "How do you get better at rock climbing?" She simply said, "By rock climbing."

That's how I feel about this too. Of course, there are supplementary things you can do, like watching videos, reading books, learning about tips. But using Claude Code is the best way to learn how to use it. Using AI in general is the best way to learn how to use AI.

I like to think of it like a billion token rule instead of the 10,000 hour rule. If you want to get better at AI and truly get a good intuition about how it works, the best way is to consume a lot of tokens. And nowadays it's possible. I found that especially since Opus 4.5, the models have been powerful enough but affordable enough that you can run multiple sessions at the same time. You don't have to worry as much about token usage, which frees you up a lot.

Sometimes you want to try a different approach from a specific point in a conversation without losing your original thread. Claude Code has native forking:

• /branch - branches the current session from within a conversation
• --fork-session - use with --resume or --continue (e.g., claude -c --fork-session)

Since --fork-session has no short form, you can add this function to your ~/.zshrc or ~/.bashrc to use --fs as a shortcut:

claude() {
  local args=()
  for arg in "$@"; do
    if [[ "$arg" == "--fs" ]]; then
      args+=("--fork-session")
    else
      args+=("$arg")
    fi
  done
  command claude "${args[@]}"
}

This intercepts all claude commands, expands --fs to --fork-session, and passes everything else through unchanged. Works with aliases too (see Tip 7): c -c --fs, ch -c --fs, etc.

When a conversation gets too long, the half-clone-conversation script keeps only the later half. This reduces token usage while preserving your recent work. The first message is tagged with [HALF-CLONE <timestamp>] (e.g., [HALF-CLONE Jan 7 14:30]). There's also a quarter-clone variant (--quarter, or the quarter-clone skill) that keeps only the last quarter, tagged with [QUARTER-CLONE <timestamp>] - useful when even half is too much.

To set it up manually, symlink the script and skills:

ln -s /path/to/this/repo/scripts/half-clone-conversation.sh ~/.claude/scripts/half-clone-conversation.sh
ln -s /path/to/this/repo/skills/half-clone ~/.claude/skills/half-clone
ln -s /path/to/this/repo/skills/quarter-clone ~/.claude/skills/quarter-clone

Or install via the dx plugin - no symlinks needed.

Optionally, you can use a hook to automatically trigger /half-clone when your context gets too long. The check-context script runs after every Claude response and checks context usage. If it's over 85%, it tells Claude to run /half-clone, which creates a new conversation with only the later half so a new agent can continue there.

To set it up, first copy the script:

cp /path/to/this/repo/scripts/check-context.sh ~/.claude/scripts/check-context.sh
chmod +x ~/.claude/scripts/check-context.sh

Then add the hook to your ~/.claude/settings.json:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/scripts/check-context.sh"
          }
        ]
      }
    ]
  }
}

This requires auto-compact to be disabled (/config > Auto-compact > false), otherwise Claude Code may compact the context before the hook gets a chance to fire. When triggered, the hook blocks Claude from stopping and tells it to run /half-clone. The advantage over auto-compact is that half-clone is deterministic and fast - it keeps your actual messages intact instead of summarizing them.

The half-clone script needs to read ~/.claude (for conversation files and history). To avoid permission prompts from any project, add this to your global settings (~/.claude/settings.json):

{
  "permissions": {
    "allow": ["Read(~/.claude)"]
  }
}

When you need to tell Claude Code about files in a different folder, use realpath to get the full absolute path:

realpath some/relative/path

These are somewhat similar features and I initially found them pretty confusing. I've been unpacking them and trying my best to wrap my head around them, so I wanted to share what I learned.

CLAUDE.md is the simplest one. It's a bunch of files that get treated as the default prompt, loaded into the beginning of every conversation no matter what. The nice thing about it is the simplicity. You can explain what the project is about in a particular project (./CLAUDE.md) or globally (~/.claude/CLAUDE.md).

Skills are like better-structured CLAUDE.md files. They can be invoked by Claude automatically when relevant, or manually by the user with a slash (e.g., /my-skill). For example, you could have a skill that opens a Google Translate link with proper formatting when you ask how to pronounce a word in a certain language. If those instructions are in a skill, they only load when needed. If they were in CLAUDE.md, they'd already be there taking up space. So skills are more token-efficient in theory.

Slash Commands are similar to skills in that they're ways of packaging instructions separately. They can be invoked manually by the user, or by Claude itself. If you need something more precise, to invoke at the right time at your own pace, slash commands are the tool to use.

Skills and slash commands are pretty similar in the way they function. The difference is the intention of the design - skills are primarily designed for Claude to use, and slash commands are primarily designed for the user to use. However, they have ended up merging them, as I had suggested this change.

Plugins are a way to package skills, slash commands, agents, hooks, and MCP servers together. But a plugin doesn't have to use all of them. Anthropic's official frontend-design plugin is essentially just a skill and nothing else. It could be distributed as a standalone skill, but the plugin format makes it easier to install.

For example, I built a plugin called dx that bundles skills from this repo together. You can see how it works in the Install the dx plugin section.

Claude Code is great for PR reviews. The procedure is pretty simple: you ask it to retrieve PR information using the gh command, and then you can go through the review however you want.

You can do a general review, or go file by file, step by step. You control the pace. You control how much detail you want to look into and the level of complexity you want to work at. Maybe you just want to understand the general structure, or maybe you want to have it run tests too.

The key difference is that Claude Code acts as an interactive PR reviewer, not just a one-shot machine. Some AI tools are good at one-shot reviews (including the latest GPT models), but with Claude Code you can have a conversation.

Claude Code is amazing for any sort of research. It's essentially a Google replacement or deep research replacement, but more advanced in a few different ways. Whether you're researching why certain GitHub Actions failed (which I've been doing a lot recently), doing sentiment or market analysis on Reddit, exploring your codebase, or exploring public information to find something - it's able to do that.

The key is giving it the right pieces of information and instructions about how to access those pieces of information. It might be gh terminal command access, or the container approach (Tip 19), or Reddit through the reddit-fetch skill, or private information through an MCP like Slack MCP, or the Cmd+A / Ctrl+A method (Tip 10) - whatever it is. Additionally, if Claude Code has trouble loading certain URLs, you can try using Playwright MCP or Claude's native browser integration (see Tip 9). For scientific research, I created a paper-search plugin for searching academic papers.

In fact, I was even able to save $10,000 by using Claude Code for research.

One way to verify its output if it's code is to have it write tests and make sure the tests look good in general. That's one way, but you can of course check the code it generates as it goes, just on the Claude Code UI. Another thing is you can use a visual Git client like GitHub Desktop for example. I personally use it. It's not a perfect product, but it's good enough for checking changes quickly. And having it generate a PR as I probably mentioned earlier in this post is a great way as well. Have it create a draft PR, check the content before turning it into a real PR.

Another one is letting it check itself, its own work. If it gives you some sort of output, let's say from some research, you can say "are you sure about this? Can you double check?" One of my favorite prompts is to say "double check everything, every single claim in what you produced and at the end make a table of what you were able to verify" - and that seems to work really well.

I wanted to specifically create a separate tip for this because it's been really amazing for me. Whenever there are GitHub Actions CI failures, I just give it to Claude Code and say "dig into this issue, try to find the root cause." Sometimes it gives you surface level answers, but if you just keep asking - was it caused by a particular commit, a particular PR, or is it a flaky issue? - it really helps you dig into these nasty issues that are hard to dig into by hand. You would need to wade through a bunch of logs and that would be super painful to do manually, but Claude Code is able to handle a lot of that.

I've packaged this workflow as a /gha slash command - just run /gha <url> with any GitHub Actions URL and it will automatically investigate the failure, check for flakiness, identify breaking commits, and suggest fixes. You can find it in the skills folder, or install it via the dx plugin.

Once you identify what the particular problem was, you can just create a draft PR and go through some of the tips I mentioned earlier - check the output, make sure it looks good, let it verify its own outputs, and then turn it into a real PR to actually fix the issue. It's been working really well for me personally.

It's important to keep CLAUDE.md simple and as concise as possible. You can just start with no CLAUDE.md at all. And if you find that you keep telling Claude Code the same thing over and over again, then you can just add it to CLAUDE.md. I know there is an option to do that through the # symbol, but I prefer to just ask Claude Code to either add it to the project level CLAUDE.md or the global CLAUDE.md and it'll know what to edit exactly.

It's also important to periodically review your CLAUDE.md files because they can get outdated over time. Instructions that made sense some time ago might no longer be relevant, or you might have new patterns that should be documented. I created a skill for this called review-claudemd that analyzes your recent conversations and suggests improvements for your CLAUDE.md files.

I used to think with Claude Code, CLI is like the new IDE, and it's still true in a way. I think it's a great first place to open your project whenever you want to make quick edits and stuff like that. But depending on the severity of your project, you want to be more careful about the outputs than just staying at the vibe coding level.

But what's also true, the more general case of that, is that Claude Code is really the universal interface to your computer, the digital world, any sort of digital problem that you have. You can let it figure it out in many cases. For example, if you need to do a quick edit of your video, you can just ask it to do that - it'll probably figure out how to do that through ffmpeg or something similar. If you want to transcribe a bunch of audio files or video files that you have locally, you can just ask it to do that - it might suggest to use Whisper through Python. If you want to analyze some data that you have in a CSV file, it might suggest to use Python or JavaScript to visualize that. And of course with internet access - Reddit, GitHub, MCPs - the possibilities are endless.

It's also great for any operations you want to perform on your local computer. For example, if you're running out of storage, you can just ask it to give you some advice on how to clean that up. It'll look through your local folders and files, try to find what's taking up a lot of space, and then give you advice on how to clean them up - maybe delete particularly large files. In my case, I had some Final Cut Pro files that were really large that I should have cleaned up. Claude Code told me about it. Maybe it'll tell you to clean up unused Docker images and containers using docker system prune. Or maybe it'll tell you to clean up some cache that you never realized was still there. No matter what you want to do on your computer, Claude Code is the first place I go to now.

I think it's kind of interesting because the computer started with a text interface. And we're, in a way, coming back to this text interface that you can spin up three or four tabs at a time, as I mentioned earlier. To me, that's really exciting. It feels like you have a second brain, in a way. But because of the way it's structured, because it's just a terminal tab, you can open up a third brain, a fourth brain, a fifth brain, a sixth brain. And as the models become more powerful, the proportion of the thinking that you can delegate to these things - not the important things, but things that you don't want to do or that you find boring or too tedious - you can just let them take care of it. As I mentioned, a good example of that is looking into GitHub Actions. Who wants to do that? But it turns out these agents are really good at those boring tasks.

As I mentioned earlier, sometimes it's okay to stay at the vibe coding level. You don't necessarily have to worry about every single line of code if you're working on one-time projects or non-critical parts of the codebase. But other times, you want to dig in a little deeper - look at the file structure and functions, individual lines of code, even checking dependencies.

The key is that it's not binary. Some people say vibe coding is bad because you don't know what you're doing, but sometimes it's totally fine. But other times, it is helpful to dig deeper, use your software engineering skills, understand code at a granular level, or copy and paste parts of the codebase or specific error logs to ask Claude Code specific questions about them.

It's sort of like you're exploring a giant iceberg. If you want to stay at the vibe coding level, you can just fly over the top and check it from far away. Then you can go a little bit closer. You can go into diving mode. You can go deeper and deeper, with Claude Code as your guide.

Auto mode lets Claude decide whether a command is safe to run in context, instead of asking you to approve every single one. (You can cycle to it with shift+tab.) I've been using it for a while and it's been working really well so far.

The main thing it fixes is mindless approving. When a command is too long to read carefully, or you're getting tired, you end up approving things without really thinking about them. Auto mode takes that pressure off, so I think it's a good default.

To make it the default, add this to ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

If you still want to be careful, you can always approve things manually without auto mode. And if you want to give it complete independence, you can run Claude Code in a container with --dangerously-skip-permissions.

Note that auto mode is now the default option on Pro, Max, and Team plans.

Remote Control lets you drive Claude Code from your phone, which pairs really well with auto mode - you can kick something off, walk away, and check on it from anywhere. There are a couple of ways to use it.

Run /remote-control inside an existing session, follow the instructions, and you can drive that same session from your phone. Because it's the same session, you can go back and forth between your phone and your computer. You can also use /rc for short.

Or start a server with claude remote-control --spawn=worktree --capacity=N, which lets you start brand new sessions from your phone, not just attach to one you already have open. Here --spawn=worktree gives each new session its own git worktree so they don't step on each other, and --capacity sets how many can run at once. I have this aliased to cr, so it's just cr --spawn=worktree --capacity=N.

Personally I prefer the /rc method, and I turn it off when I'm not using it. A potential attacker who gets access to your Claude Code session essentially has access to everything on your computer, so I'd rather be careful. The exception is when I have a totally isolated environment - then it's super convenient to be able to start a Claude Code session from anywhere from your phone, with access to your full dev environment.

If you do want Remote Control enabled automatically for every new session, turn on "Enable Remote Control for all sessions" through /config, or set "remoteControlAtStartup": true in ~/.claude/settings.json. It's off by default.

Docs: Remote Control.

If you're building a front-end app with HTML, CSS, and JavaScript, an artifact is a great way to check your output quickly and even share it. Ask Claude Code to put the page in an artifact, and it publishes it to claude.ai and gives you a link.

The nice thing about it is that it's gated behind your Anthropic login: a new artifact is only visible to you, so you can check it privately or share it privately.

It works great from your phone as well. In the Claude mobile app, tap the artifact card and it opens right there in the app.

One thing to keep in mind: an artifact is a single self-contained page with no backend, and most external requests are blocked - scripts from a few allowlisted CDNs (like cdnjs) work, but otherwise bundle libraries and assets into the file first.

As you write more code with Claude Code, it becomes easier to make mistakes. PR reviews and visual Git clients help catch issues (as I mentioned earlier), but writing tests is crucial as your codebase grows larger.

You can have Claude Code write tests for its own code. Some people say AI can't test its own work, but it turns out it can - similar to how the human brain works. When you write tests, you're thinking about the same problem in a different way. The same applies to AI.

I've found that TDD (Test-Driven Development) works really well with Claude Code:

1. Write tests first
2. Make sure they fail
3. Commit the tests
4. Write the code to make them pass

By writing failing tests first and committing them before implementation, you create a clear contract for what the code should do. Claude Code then has a concrete target to hit, and you can verify the implementation is correct by running the tests.

If you want to be extra sure, review the tests yourself to make sure they don't do anything stupid like just returning true.

Since I started using Claude Code more intensely, I've noticed that I became more and more brave in the unknown.

For example, when I started working at Daft, I noticed a problem with our frontend code. I'm not an expert in React, but I decided to dig into it anyway. I just started asking questions about the codebase and about the problem. Eventually I was able to solve it because I knew how to iteratively solve problems with Claude Code.

A similar thing happened recently. I was building a guide for users of Daft and ran into some very specific issues: cloudpickle not working with Google Colab with Pydantic, and a separate issue with Python and a bit of Rust where things weren't printing correctly in JupyterLab even though they worked fine in the terminal. I had never worked with Rust before.

I could have just created an issue and let other engineers handle it. But I thought, let me dig into the codebase. Claude Code came up with an initial solution, but it wasn't that good. So I slowed down. A colleague suggested we just disable that part, but I didn't want any regression. Can we find a better solution?

What followed was a collaborative and iterative process. Claude Code suggested potential root causes and solutions. I experimented with those. Some turned out to be dead ends, so we went in a different direction. Throughout this, I controlled my pace. Sometimes I went faster, like when letting it explore different solution spaces or parts of the codebase. Sometimes I went slower, asking "what does this line mean exactly?" Controlling the level of abstraction, controlling the speed.

Eventually I found a pretty elegant solution. The lesson: even in the world of the unknown, you can do a lot more with Claude Code than you might think.

When you have a long-running bash command in Claude Code, you can press Ctrl+B to move it to run in the background. Claude Code knows how to manage background processes - it can check on their output later.

This is useful when you realize a command is taking longer than expected and you want Claude to do something else in the meantime. You can then either have it use the exponential backoff method I mentioned in Tip 15 to check on progress, or just let it work on something else entirely while the process runs.

Claude Code also has the ability to run subagents in the background. If you need to do long-running research or have an agent check on something periodically, you don't have to keep it running in the foreground. Just ask Claude Code to run an agent or task in the background, and it'll handle it while you continue with other work.

Beyond just running things in the background, subagents are useful when you have a large task to break down. For example, if you have a huge codebase that you need to analyze, you can have subagents analyze it in different ways or look at different parts of the codebase in parallel. Just ask Claude to spawn multiple subagents to handle different pieces.

You can customize subagents by just asking:

• How many - ask Claude to spawn the number you want
• Background vs foreground - ask to run them in the background, or press Ctrl+B
• Which model - ask for Fable, Opus, Sonnet, or Haiku depending on the complexity of each task (by default, subagents inherit the main conversation's model)

We're entering an era of personalized, custom software. Since AI came out - ChatGPT in general, but especially Claude Code - I've noticed that I'm able to create a lot more software, sometimes just for myself, sometimes for small projects.

As I mentioned earlier in this document, I've created a custom transcription tool that I use every day to talk to Claude Code. I've created ways to customize Claude Code itself. I've also done a bunch of data visualization and data analysis tasks using Python much faster than I could otherwise.

Here's another example: korotovsky/slack-mcp-server, a popular Slack MCP with almost 1,000 stars, is designed to run as a Docker container. I had trouble using it smoothly inside my own Docker container (Docker-in-Docker complications). Instead of fighting with that setup, I just asked Claude Code to write a CLI using Slack's Node SDK directly. It worked really well.

This is an exciting time. Whatever you want to get done, you can ask Claude Code to do it. If it's small enough, you can build it in an hour or two. I even created a slide deck template - a single HTML file with CSS and JavaScript that lets you embed an interactive, persistent terminal process inside.

Claude Code's input box is designed to emulate common terminal/readline shortcuts, which makes it feel natural if you're used to working in the terminal. Here are some useful ones:

Navigation:

• Ctrl+A - Jump to the beginning of the line
• Ctrl+E - Jump to the end of the line
• Option+Left/Right (Mac) or Alt+Left/Right - Jump backward/forward by word

Editing:

• Ctrl+W - Delete the previous word
• Ctrl+U - Delete from cursor to beginning of line
• Ctrl+K - Delete from cursor to end of line
• Ctrl+C - Clear the current input
• Ctrl+G - Open your prompt in an external editor (useful for pasting long text, since pasting directly into the terminal can be slow)

If you're familiar with bash, zsh, or other shells, you'll feel right at home.

For Ctrl+G, the editor is determined by your EDITOR environment variable. You can set it in your shell config (~/.zshrc or ~/.bashrc):

export EDITOR=vim      # or nano, code, nvim, etc.

Or in ~/.claude/settings.json (requires restart):

{
  "env": {
    "EDITOR": "vim"
  }
}

Entering newlines (multi-line input):

The quickest method works everywhere without any setup: type \ followed by Enter to create a newline. For keyboard shortcuts, run /terminal-setup in Claude Code. On Mac Terminal.app, I use Option+Enter - it only works after checking "Use Option as Meta key" in Terminal → Settings → Profiles → Keyboard.

Pasting images:

• Ctrl+V (Mac/Linux) or Alt+V (Windows) - Paste an image from your clipboard

Note: On Mac, it's Ctrl+V, not Cmd+V.

Turning off prompt suggestions:

If you find the prompt suggestions (the predicted next message that shows up in your input box) annoying, you can turn them off. Run /config and toggle off "Prompt suggestions", or set this in ~/.claude/settings.json:

{
  "promptSuggestionEnabled": false
}

You want to spend enough time planning so that Claude Code knows what to build and how to build it. This means making high-level decisions early: what technology to use, how the project should be structured, where each functionality should live, which files things should go in. It's important to make good decisions as early as you can.

Sometimes prototyping helps with that. Just by making a simple prototype quickly, you might be able to say "okay, this technology works for this particular purpose" or "this other technology works better."

For example, I was recently experimenting with creating a diff viewer. I first tried a simple bash prototype with tmux and lazygit, then tried making my own git viewer with Ink and Node. I had a lot of trouble with different things and ended up not publishing any of these results. But what I got reminded of through this project is the importance of planning and prototyping. I found that just by planning a little bit better at the beginning before you let it write code, you're able to guide it better. You still need to guide it throughout the process of coding, but letting it plan a little first is really helpful.

You can use plan mode for this by pressing Shift+Tab to switch to it. Or you can just ask Claude Code to make a plan before writing any code.

I've found that Claude Code sometimes overcomplicates things and writes too much code. It makes changes you didn't ask for. It just seems to have a bias for writing more code. The code might work correctly if you've followed the other tips in this guide, but it's going to be hard to maintain and hard to check. It can be kind of a nightmare if you don't review it enough.

So sometimes you want to check the code and ask it to simplify things. You could fix things yourself, but you could also just ask it to simplify. You can ask questions like "why did you make this particular change?" or "why did you add this line?"

Some people say if you write code only through AI, you'll never understand it. But that's only true if you don't ask enough questions. If you make sure you understand every single thing, you can actually understand code faster than otherwise because you can ask AI about it. Especially when you're working on a large project.

Note that this applies to prose as well. Claude Code often tries to summarize previous paragraphs in the last paragraph, or previous sentences in the last sentence. It can get pretty repetitive. Sometimes it's helpful, but most of the time you'll need to ask it to remove or simplify it.

At the end of the day, it's all about automation of automation. What I mean by that is I've found it's the best way to not just become more productive, but also make the process more fun. At least to me, this whole process of automation of automation is really fun.

I personally started with ChatGPT and wanted to automate the process of copy-pasting and running commands that ChatGPT gave me in the terminal. I automated that whole process by building a ChatGPT plugin called Kaguya. I've consistently worked towards more and more automation since then.

Nowadays, luckily, we don't even have to build a tool like that because tools like Claude Code exist and they work really well. And as I've used it more and more, I found myself thinking, well, what if I could automate the process of typing? So I used Claude Code itself to build my voice transcription app, as I mentioned earlier.

Then I started to think, I find myself repeating myself sometimes. So I would put those things in CLAUDE.md. Then I would think, okay, sometimes I go through running the same command over and over again. How can I automate that? Maybe I can ask Claude Code to do it. Or maybe I can put them in skills. Or maybe I can even have it create a script so I don't have to repeat the same process over and over again.

I think ultimately that's where we're heading. Whenever you find yourself repeating the same task or the same command over and over again, a couple of times is okay, but if you repeat it over and over again, then think about a way to automate that whole process.

This tip is a bit different from the others. I found that by learning as much as you can, you're able to share your knowledge with people around you. Maybe through posts like these, maybe even books, courses, videos. I also recently had an internal session for my colleagues at Daft. It's been very rewarding.

And whenever I share tips, I often get information back. For example, I shared about the difference between slash commands and skills (Tip 23), and I learned new things from comments on that Reddit post.

So sharing your knowledge isn't just about establishing your brand or solidifying your learning. It's also about learning new things through that process. It's not always a one-way street.

When it comes to contributing, I've been sending issues to the Claude Code repo. I thought, okay, if they listen, cool. If they don't, that's totally fine. I didn't have any expectations. But in version 2.0.67, I noticed they took multiple suggestions from reports I made:

• Fixed scroll position resetting after deleting a permission rule in /permissions
• Added search functionality to /permissions command

It's kind of amazing how fast the team can react to feature requests and bug reports. But it makes sense because they're using Claude Code to build Claude Code itself.

There are several effective ways to keep learning about Claude Code:

Ask Claude Code itself - If you have a question about Claude Code, just ask it. Claude Code has a specialized subagent for answering questions about its own features, slash commands, settings, hooks, MCP servers, and more.

Check the release notes - Type /release-notes to see what's new in your current version. This is the best way to learn about the latest features.

Learn from the community - The r/ClaudeAI subreddit is a great place to learn from other users and see what workflows people are using.

This repo is also a Claude Code plugin called dx (developer experience). It bundles several tools from the tips above into a single install:

Install with two commands:

claude plugin marketplace add ykdojo/claude-code-tips
claude plugin install dx@ykdojo

After installing, the commands are available as /dx:half-clone, /dx:handoff, and /dx:gha. The reddit-fetch skill is invoked automatically when you ask about Reddit URLs. The review-claudemd skill analyzes your recent conversations and suggests improvements for your CLAUDE.md files. For the half-clone command, see the recommended permission.

Recommended companion: Playwright MCP for browser automation - add with claude mcp add -s user playwright npx @playwright/mcp@latest

If you want to set up multiple recommendations from this repo at once, there's a setup script that handles many of them:

bash <(curl -s https://raw.githubusercontent.com/ykdojo/claude-code-tips/main/scripts/setup.sh)

The script shows you everything it will configure and lets you skip any items:

INSTALLS:
  1. DX plugin - skills like /dx:gha, /dx:handoff, and reddit-fetch

SETTINGS (~/.claude/settings.json):
  2. Status line - shows model, git branch, uncommitted files, token usage at bottom of screen
  3. Disable auto-updates - prevents Claude Code from auto-updating
  4. Lazy-load MCP tools - only loads MCP tool definitions when needed, saves context
  5. Read(~/.claude) permission - allows the half-clone command to read conversation history
  6. Read(//tmp/**) permission - allows reading temporary files without prompts
  7. Disable attribution - removes Co-Authored-By from commits and attribution from PRs

SHELL CONFIG (~/.zshrc or ~/.bashrc):
  8. Aliases: c=claude, ch=claude --chrome, cs=claude --dangerously-skip-permissions
  9. Fork shortcut: --fs expands to --fork-session (e.g., claude -c --fs)

Skip any? [e.g., 1 4 7 or Enter for all]:

If you have multiple Claude accounts (for example, personal vs work), here's how you can switch between them quickly.

On macOS your login lives in a single Keychain entry, but the CLAUDE_CODE_OAUTH_TOKEN env var overrides it, so you can launch as a specific account. The env var works on Linux and Windows too (their logins live in ~/.claude/.credentials.json instead). Here's an example of how you can set this up on Mac - feel free to adapt it to your own system.

Mint a one-year token per account (claude setup-token opens a browser - log into the account you want), then store each in the Keychain so it's not plaintext in your dotfiles:

claude setup-token   # log in as each account, copy the token
security add-generic-password -s "claude-token-work"     -a "$USER" -U -w
security add-generic-password -s "claude-token-personal" -a "$USER" -U -w

Add two functions to your ~/.zshrc that look up the token and pass any args through to claude:

clw() { CLAUDE_CODE_OAUTH_TOKEN="$(security find-generic-password -s claude-token-work     -a "$USER" -w)" claude "$@"; }
clp() { CLAUDE_CODE_OAUTH_TOKEN="$(security find-generic-password -s claude-token-personal -a "$USER" -w)" claude "$@"; }

Now clw and clp run as each account (e.g. clw --resume), while plain claude still uses your Keychain login. Tokens last about a year, so re-run setup-token to refresh.

I've been using GitHub as my knowledge base - kind of a Notion replacement. Instead of opening up a Notion document, I just create a new repo or find an existing private repo where I can put my notes. I dictate my thoughts and develop my notes there, and if I have some research to do, I let Claude Code do the research and update those repos.

I also have repos for skills. If I have to repeat the same type of work over and over again, it's nice to be able to have that in a skill format so I can reuse those workflows.

The one missing piece is search: GitHub's own search doesn't work well for private repos. I wrote about that problem and how I solved it in The missing private GitHub search - it's a skill that mirrors all your repos locally and searches them with ripgrep, so I can just ask Claude Code "which repo has X" and it finds it.

See: Why GitHub is the best knowledge base

When you need to review a large amount of code (Claude Code generated code, a PR from your teammate, or an external PR), the real challenge is building a mental model of what's going on. And the question is, how do you know if this is correct? You can read the code. You can write tests. But there is another way that's one level above those.

What I recommend is to have Claude Code test everything in the given code thoroughly, let it document how it tested and verified everything in a TESTING.md document, and review that document manually instead. You can go back and forth on it to get a good format for you to review. If it's too long, ask it to make it shorter. If it's too short, ask for more information. If it has jargon you don't understand, ask it to explain or simplify.

Here is a real example: TESTING.md from this repo. It started with the review of one external PR, where Claude Code reproduced the bug on a real Windows runner in GitHub Actions, verified the fix, and summarized everything it tested. Now it's a running log that we keep updating with each review. Tracking it in git this way gives you a record of how everything has been tested. If someone asks, how do you know if something works as intended, then you can just point them to this document.

Set Claude Code's output style to Concise: run /config, go to Output style, and pick Concise (or set "outputStyle": "Concise" in ~/.claude/settings.json; requires v2.1.237 or later).

Before I switched this on, Claude would sometimes ramble about something and I'd have to say "you're talking too much, can you give me a TLDR?" With this setting, I need to do that much less often. I think it's a good default for most people - and if you need more details about certain things, you can just ask follow-up questions.

It only affects the visible response text, not the thinking, so you're not losing any reasoning quality.

📺 Related talk: Claude Code Masterclass - lessons and project examples from 31 months of agentic coding

📝 Story: How I got a full-time job with Claude Code

📰 Newsletter: Agentic Coding with Discipline and Skill - bring the practice of agentic coding to the next level