I recently wrote up some notes for a friend that was just getting started on Claude Code, so I decided to clean them up and post them here in case anyone takes away a few useful tidbits for themselves. There are a lot of these "Claude tips & tricks" style posts, but I enjoy reading them every time I see another one.
Fyi on me: professional software engineer for 29 years, plus another dozen or so years before that growing up coding in front of the beautiful glow of a computer screen. My AI coding has evolved starting last fall from ChatGPT copy/paste -> Github Copilot in Jetbrains -> Cursor -> Github Copilot in VS Code -> Claude Code CLI. I'm loving that most recent stop on the AI train.
Planning & Kicking off work
Make use of the planning mode (shift-tab twice). This is a great way to get Claude to really think things through and design out the work before it dives in. You can go back and forth with it on options (e.g. ask it for a bunch of options with pros and cons on each if you’ll be using some new tech you haven’t used before), or to make changes to design choices you don’t like, and then you work with Claude to sculpt the plan into exactly what you want before it starts. I’ve seen a much higher chance of success on the build results vs if you just gave Claude the initial prompt in regular mode where it starts coding right away. Logically, this makes sense to me. It’s the same as if you were doing that with an engineer on your team. You don’t want that engineer to run off and start coding before they’ve fully formed and vetted their plan.
Detailed spec to kick things off when doing bigger or delicate tasks: I find I am writing longer and longer specs the more I work with Claude, often a page or two long, with my longest being one I spent an hour writing out before feeding it to Claude. It’s rare that I will start a new task with only a few sentences.
Markdown format for your specs / prompts: when doing a bigger spec or something that I want to get just right, I write it in the Markdown format. It’s really nice and simple. You don’t have to overthink the format at all. #, ##, ### for organizing your thoughts into logical sections and subsections, and “-“ for lists of items. It’s pretty natural to write in Markdown, and I’ve adopted it for my own personal todo list files. I feel more confidence in prompts where I’ve organized it with Markdown because there is less ambiguity with my instructions.
I like to ask Claude to write its final plan (from planning mode) along with a detailed todo list into a Markdown plan document when I’m at the “I approve this plan, go ahead and implement” stage before it leaves planning mode. It’s also an opportunity to clearly state which phases/tasks from the plan you want Claude to implement until it stops. Otherwise sometimes it just does Phase 1 of the work and then waits for you to tell it to continue with Phase 2, 3, and beyond. The Markdown doc is also useful because sometimes if Claude is doing a very large build for you, it might eventually forget some of the items from the original plan that it was supposed to do, especially if you need to iterate with Claude halfway through its work in order to get one of the earlier Phases right. You can point Claude back at the Markdown doc later to remind it of the missing steps. I also typically ask Claude to update the Markdown doc as it works to update the status of which steps it completed, but I find it’s a mixed bag getting Claude to do a thorough job of updating it as it goes. But you can prompt Claude later to update the doc to reflect the state of the implemented work.
Mockup: a very cool thing a friend did that I'll start using was to ask Claude Code to generate a mockup of the planned UI or interface (even an interactive mockup if you want). It generates the mockup much quicker than a full build, and it gives you a chance to provide Claude feedback, make changes, and then use the mockup as part of its spec for the real build.
Configurations
CLAUDE.md is handy for instructions you want Claude to (nearly) always keep in mind (I say nearly, because it seems like the CLAUDE.md info slides out of context at times, unfortunately). I give it context about the overall project. I include some of the key parts of my initial spec and/or what the overall objective is with the project. I tell it the command line build and launching instructions (I’m typically having Claude write a nice clean / build / launch / deploy script for me, which I then have Claude document in the CLAUDE.md file). I tell it where the log files can be found. Over time, my CLAUDE.md gets extended with “Always do this…” or “Never do this…” comments from me as well.
I've found it useful to add instructions to my CLAUDE.md to help Claude keep things tidy, such as: "When Claude generates .md markdown files, it should place them in docs/ai/". Otherwise you can end up with docs sprinkled all over your project. The same goes for test scripts and other debug one-offs Claude will create.
.claude/commands/ is very helpful. You can write prompt-like instructions into markdown files in this directory in your project, and then it automatically creates each as a new “/“ command in your project’s Claude sessions. Example commands I use: /commit (.claude/commands/commit.md) to git add my unstaged files, draft a commit message and git commit everything. Or /bl (.claude/commands/bl.md) with instructions to do a clean build, clear the existing output log files, launch my app, and then check the results of the log file output.
.claude/settings.json is handy for allow-listing various commands (e.g. grep) that you want Claude to always do without asking for your approval.
Project vs Global commands: you can create those .claude/commands/ in your project's .claude directory, or you can create commands that will work across all of your Claude projects by putting them in your home directory's ~/.claude/commands directory.
/statusline: this recently added feature is quite nice. Type /statusline and Claude will help you configure what appears under your Claude Code CLI prompt box. I have mine set to show me my project name (based on the project's root working directory name), my git status along with how many files are currently modified, and the current model Claude is using, all with some nice colors and dividers. The /statusline can show you quite a bit more than that if you like. The code for the statusline ends up in ~/.claude/statusline.sh.
Prompting / Models
“Think” prompt keyword: Claude has some special behavior for spending more time (and tokens if you worry about that) thinking and researching and coming up with a plan or solution. "think" < "think hard" < "think harder" < "ultrathink." These are useful, I like using them. I ramp up the thinking level depending on the complexity of the task we’re planning together.
Opus vs Sonnet: by default Claude will start your day using Opus for everything. You can change the /model but I leave it be. If you’ve been cranking away hard on lots of parallel sessions then you’ll see Claude switch to Sonnet partway through your day for usage limit reasons. I do feel like Opus does a better job with big coding jobs, so it’s a bit of a bummer when it switches to Sonnet. But I carry on and keep working. Nothing to be done about it since I’m already on the 20x plan. Anthropic recently added this /model option: “Opus Plan Mode: Use Opus 4.1 in plan mode, Sonnet 4 otherwise” which I haven’t tried out but seems like it will be a nice balance and preserve Opus for your planning throughout the day.
Auto-compacting: I see a lot of fear of the auto-compact. This is when the context fills up and Claude needs to summarize the conversation and pending tasks so it can flush its context and have room to continue. It generally does a decent job, but I have seen Claude lose some sense of what it needed to do or how things worked after the auto-compact. Coding typically goes smoother if I don’t run into auto-compaction partway through a task. My approach is that after I’ve finished a major task and it’s all debugged and committed, I /clear to completely wipe the context in order to reduce the odds that my next large task will hit auto-compaction halfway through. If I’m doing lots of small tasks with Claude then I don’t worry about using /clear and instead I’m happy to keep a long running Claude session going, but I’ll trigger the /compact myself if I happen to notice I’m down to a low single-digit % remaining until auto-compaction. That said, it’s really not all that often I tripped up by auto-compaction if Claude needs to do it during a task and so I don’t stress over this too much.
Claude control
Esc: you can pause Claude at any time by hitting Escape. Useful if you don’t like what it’s doing or need to change anything.
Esc Esc: you won’t need to use this often but it’s good to know about it. I’ve used this when Claude has errored out or complained that I’ve prompted it to do something it is not allowed to do (I guess it thought I was asking for something nefarious…video game coding can have dangerous sounding trigger words). Pressing Escape twice brings up a stack of your previous prompts, and you can step back to a previous one and do a fresh prompt from that point forward.
Feel free to type in something for Claude while it’s in the middle of working. If you see Claude make a wrong assumption, or you want to add a task to the current work, or want to give it more debug info, you are welcome to enter it in and Claude will pick up your additional prompt shortly after and incorporate it. Very handy.
@: Claude is really good at finding your code files when you prompt in simple English, but I like using the @ to reference specific files in the project tree. When I want to mention a class name, I’m more likely to @ and type the class file, for two reasons: 1) it has nice tab auto-completion, 2) it makes the request very explicitly clear for Claude.
Ctrl-R: I don’t use this much, but it’s interesting. Hit Ctrl-R while Claude is working and you’ll see a much more verbose output of what it is doing.
claude -r: super useful command line option when launching Claude. This lets you rejoin an earlier Claude session. This is very handy if you rebooted or Claude crashed, or if you want to ask Claude to do a task in some earlier session where it built up very useful context on a particular topic.
Workflow
Git: I regularly use Claude to do my git add/commits when I’m ready to submit to my repo. It writes a nicer git commit message than I would. I don’t auto-approve Claude for doing git commands, though. I manually trigger this when I’m ready, after finishing my testing and reviewing the diffs in VS Code. Claude likes to start doing git adds and commits after every change , which is annoying because it wants to commit things I haven’t even tested yet. I’ve added instructions to my CLAUDE.md files to tell Claude not to do that, but sometimes it gets excited and wants to get back into that mode again.
Screenshots & logs. Drag in an image or Ctrl-V to paste an image from your clipboard. It’s always good to give Claude more actionable data to help it fix a problem. Screenshots aren’t foolproof though. There are times Claude says “the screenshot shows it has been fixed” when clearly the screenshot showed nothing of the sort. And for logs: yeah you can copy & paste output into Claude, but it’s even nicer when you let Claude know where the log files are and you tell it to check the logs itself. Let Claude add your log directories external to your project directory when it asks; this way it can check the log files itself without asking you each time.
Feedback loops: this is a dream setup, but it can be hard to achieve. It’s worth working with Claude on scripts and tools to do this, though. When you are trying to get Claude to fix something tricky or its having a hard time with a fix, try to get Claude set up with everything it needs to build and launch your app with the right config and command line settings and access to the output logs (or giving Claude access to an MCP tool that can take screenshots for it, like Peekaboo MCP on the Mac). And then tell Claude to do all of those things in a loop forever until it solves the problem. Claude will loop those steps, adding debug info, trying again, inspecting the output, and then repeating the cycle until it gets it. Or blows up trying. Another approach is to tell Claude to be a debug log class/helper, and direct Claude to write its debug output here and create a feedback loop with this, in order to keep Claude’s debugging a bit more partitioned from your console, logs or other outputs.
Cleanups: Claude can create a lot of one-off scripts and debug logging during its debugging phases, which is all perfectly fine. I've found Claude can clean all of these up quite nicely. This is another chance for a handy .claude/command where you tell Claude how you want the project tidied up prior to committing to your repo.
git restore: I find it important to commit my working and tested changes to git before embarking on another Claude prompt. This is good for all the normal good coding practices. But it's especially good when working with AI because I find that if I'm struggling to get good results from a new Claude prompt - and follow-up prompts are not steering Claude in the right direction - that it's often best togit restoreback to the last commit and try again. Mentally, it can be tough to pull the trigger and give up on a prompt’s results because with Claude you always feel like you are one prompt away from getting the result you want. But things can get messy if you are stuck prompting Claude over and over and it’s still not delivering the result you want, and I've gotten great results from git-restoring and refining my initial prompt based on how I saw things go sideways during the last attempt. This is also a good time to /clear to wipe the bad paths from Claude’s context before you try again fresh with an improved prompt.
Handy links
Anthropics's Common workflows is filled with great tips: https://docs.anthropic.com/en/docs/claude-code/common-workflows
An easy way to check your Claude Code usage:
npm install -g ccusage( https://github.com/ryoppippi/ccusage )