50 Claude Code tips: everything an engineer learned in 6 months

Fundamentals: getting started with Claude Code

Before diving into advanced tips, you need to lay the groundwork. These first tips cover the initial setup - simple things that save a lot of frustration later on.

Launch Claude Code from the project root

Always launch claude from your project's root directory. Claude Code will "zip up" the context of that directory into the first token - that's why you see tokens being used even before you've typed anything. If you have rule files (CLAUDE.md), that's where they'll be read from.

Run /init immediately

The /init command analyzes your codebase and creates an initial CLAUDE.md file in the .claude/ directory. Claude identifies the architecture (Next.js 15, Swift UI, etc.), the patterns, and the dependencies. This is essential for new projects.

Understand the rule file hierarchy

There are two levels of CLAUDE.md:

Project - in .claude/CLAUDE.md of the current directory (project-specific rules)
Global - in ~/.claude/CLAUDE.md (rules that apply to all your projects)

The /memory command lets you see which rules are active.

The CLAUDE.md file: your secret weapon

For 80% of users, a good CLAUDE.md is enough to get excellent results without touching any advanced features. It's the most powerful lever you have.

Keep the file compact

Aim for around 300 lines. The bigger the file, the more tokens it consumes, and the more likely the AI is to ignore some instructions. A concise, precise file beats an exhaustive, verbose one.

What to put in it

Technical architecture - stack, framework, file structure
Domain context - Swift UI, Next.js, etc.
Design patterns - project-specific conventions
Build/validation loop - how to compile, test, verify

The validation loop is crucial

This is probably the most important tip in the whole video. Having build and validation commands in the CLAUDE.md lets Claude self-correct in a loop. If you've ever wondered why the AI doesn't produce working code on the first try, it's often because this feedback loop is missing.

# Exemple de section validation dans CLAUDE.md
## Build & Validation
1. xcodebuild -scheme MonApp -destination 'platform=iOS Simulator'
2. Verifier que le build compile sans erreur
3. Si erreur, corriger et reprendre a l'etape 1

Top-to-bottom priority

The CLAUDE.md is read top to bottom, with decreasing priority. Put the most important rules first. Use strong phrasing: "NEVER do X" and "ALWAYS do Y".

Add code examples

If your project uses homegrown patterns (a DSL, internal conventions), add concrete snippets. The AI is trained on public code - it doesn't know your specific conventions. Every time it makes the same mistake, update the CLAUDE.md so it doesn't happen again.

Have Claude update the rules itself

Never edit the CLAUDE.md by hand. Ask Claude: "Update the rules so we don't make this mistake again." It's faster and keeps the file consistent.

Compound engineering: commit the CLAUDE.md

Once your CLAUDE.md matures, commit it to the repo so your teammates benefit from it. Careful: strip out absolute paths and personal information, and keep the file compact - every teammate will load this context in every session.

Essential keyboard shortcuts

If you spend hours in Claude Code, these shortcuts become reflexes.

Shift+Tab: toggle between plan and edit

Shift+Tab toggles between plan mode (read-only, no file modifications) and edit mode (accepts modifications). The author uses plan mode almost exclusively at the start of every feature.

Escape: interrupt Claude

If Claude heads in the wrong direction, press Escape to interrupt it. Don't be afraid to do it - Claude Code handles resuming well. You can press Up to re-edit your last prompt, or just give a new instruction.

Double Escape: clear or rewind

With text in the input - double Escape clears the entire content
Empty input - double Escape lets you rewind to an earlier point in the conversation and restore that context

Screenshots: drag and drop

Take a screenshot and drag it straight into the Claude Code terminal. Essential for UI/UX work. Combine it with a Figma MCP for visual validation loops.

Essential slash commands

/clear - start from scratch

Clears the current context. Useful when you're switching features and the old context risks polluting the new one. Equivalent to opening a new Claude instance.

/context - audit your context

Shows a visual representation of the current context. If Claude Code's quality drops or your costs spike, check which elements are consuming the most tokens. MCPs are often the biggest consumers.

/compact - compress the context

Compacts (summarizes) your current conversation. Claude Code does this automatically during long sessions. The author rarely uses it, except to save a state into his "second brain" (see below).

/models - switch models

Lets you switch between Opus, Sonnet, and Haiku. The author recommends Opus whenever possible - the reasoning quality more than makes up for the extra latency.

/resume - recover a lost session

If you accidentally close an instance, /resume restores the previous session's context. A safety net so you don't lose a context that took a while to build.

/mcp - manage MCPs

Lists installed MCPs. The author is minimalist with MCPs: he only installs the ones strictly necessary for the current project, since they bloat the context window. For some projects (Xcode, Next.js), they're unavoidable.

Git as a safety net

Use git skills so Claude handles your commits, summaries, and test plans. Claude Code's rewind is a last resort - git remains more reliable for checkpoints.

Workflows: how to work efficiently

Always start in plan mode

The author never starts a feature in edit mode. He always starts in plan mode, iterates with Claude, argues, and challenges its proposals. Generating code is the easy part - building the right context is the real work.

Fresh context beats stuck context

"Context is best served fresh and condensed." Avoid sessions where you chain "try this," "no, try that," "go back." The context gets polluted and the AI loses its way. It's better to invest time in initial planning and execute cleanly.

Persisting context: the "second brain" concept

The idea: save the state of your work into a local file (for example the project's .claude/CLAUDE.md) at the end of a session. At the start of the next session, load that context on demand (lazy loading). This lets you switch between projects without losing your train of thought.

# Fin de session
"Sauvegarde le travail qu'on vient de faire dans mon CLAUDE.md local"

# Debut de session suivante
"Charge mon contexte depuis mon repertoire local"

Tracking your todos in Claude Code

Rather than using an external tool (Asana, Jira), the author keeps his to-dos directly in his local context file, lazy-loaded. This works for personal projects; for team work, use an MCP connected to your project management tool.

The build loop: think validation

Beyond a simple build, think about advanced validation loops:

Debugging - ask Claude to add logs, run the app, read the logs, debug
Performance - hook up a Perfetto MCP, do a run, read the traces
Web - use Puppeteer or /chrome to navigate and validate visually
Tests - end-to-end integration, automated unit tests

Use Opus whenever possible

Opus is slower, but the reasoning quality is superior. Since the author works with several instances in parallel, latency isn't an issue - while one instance is thinking, he's working in another.

Interrupt bad assumptions

Watch for keywords in Claude's "thinking": "I'm not sure", "I'm assuming that". If you spot incorrect assumptions or cascading errors, interrupt immediately with Escape and correct course.

Composability: skills, MCPs, and sub-agents

Claude Code is built on four composable primitives. Understanding how they fit together is the key to becoming a power user.

Skills: recurring workflows

A skill is a .md file that defines a reusable workflow. To create one, do the workflow manually once, then tell Claude: "Save what we just did into a new skill called X."

Behind the scenes, it's a Markdown file with a system prompt. Claude detects it automatically thanks to the skills directories and descriptions. Since a recent Anthropic change, skills and slash commands are now interchangeable - a created skill is also accessible via /skill-name.

Never create skills manually

Get into the habit of asking Claude to create and update skills. For example: "Extend the fetch-hackernews skill to also search Twitter and Apple News." Claude updates the skill's .md file.

MCPs: use sparingly

Tip: you don't need to search the web for an MCP. Tell Claude "Find me a good Figma MCP" - and ask it to install it too. But be careful: MCPs bloat your context. Only install the ones essential for the current project.

Sub-agents: for atomic work

Sub-agents run tasks in parallel and protect your context window. But the author warns: a lot of people use them wrong.

A sub-agent only brings back its output, not the path it took to get there. If a task needs full context (tests that must know the code, debugging that requires history), keep it in the main session.

Good use cases for sub-agents:

Atomic, isolated tasks
Side effects that don't need the main context
Parallel investigations

Bad use cases: "CEO agent," "product agent," "design agent" - these multi-agent roles scatter the context instead of concentrating it.

The principle: bring the work to the context

Rather than spreading the context across several agents, bring the work back to a condensed, fresh context window. That's the guiding principle.

Advanced workflows: developing in parallel

Several simultaneous Claude Code instances

This is the game changer, according to the author. With iTerm2, he opens several panes (Cmd+D) and juggles between instances:

Instance 1: develops a feature in plan mode
Instance 2: does an architecture investigation
Instance 3: works on another project

Quick navigation between panes with Cmd+[ and Cmd+]. Between tabs with Cmd+Shift+[/]. He compares it to playing Starcraft: give an order to a unit, move on to the next, come back to check.

Sound notifications

Enable a notification sound when Claude finishes a run. This lets you know when to switch back to a tab. The author even tried text-to-speech to summarize the result, but it was too intrusive.

Git worktrees for parallel code

If you run several instances on the same project, they'll conflict over files. The solution: git worktrees, which let you clone several working copies of the same repo with separate branches.

/chrome: browsing the web from Claude Code

/chrome opens a browser Claude can control - taking screenshots, clicking, typing text, navigating. Ideal when you don't have an API but can access the service through the web. And it's composable: a skill can launch Chrome, scrape data, and come back with the results.

Hooks: automating pre/post execution actions

Like git hooks (pre-commit, post-commit), Claude Code lets you define actions before and after each run. Typical use cases:

Post-execution - automatic linting, code formatting
Pre-execution - blocking destructive commands (rm -rf, database deletions)

Ask Claude to set them up for you - don't maintain them by hand.

Dangerously-skip-permissions mode

claude --dangerously-skip-permissions disables confirmations. Handy for disposable environments, but risky: the author has had to reflash Linux machines after commands that got too aggressive. Use /permissions to keep guardrails on destructive operations.

Plugins: composability at its best

A plugin is a combination of skills, MCPs, sub-agents, and bash scripts. Anthropic offers a downloadable plugin ecosystem, and the community shares its own. Explore what already exists before reinventing it.

Context is king

The central message of this video comes down to one sentence: give Claude the context it needs, and nothing more.

Keep context fresh - start in plan mode, validate, then execute
Keep context condensed - avoid unnecessary MCPs, compact it, use /clear
Keep context relevant - lazy loading, second brain, targeted skills

Claude Code is a context engineering tool with a coding agent wrapped around it. All the slash commands, the skills, the sub-agents - it's all there to manage that context window. Master that, and you'll unlock Claude Code's full potential.

Hello. Hello there. How's it going everybody? Today we're going to go over my 50 cloud code tips. I've been working with cloud code basically every day for about 6 months now. And I feel like I've learned a ton of things. And yes, I am one of those engineers that are basically not writing code anymore. I'm still in cloud code like 12 hours a day actively pair programming with cloud code basically and reviewing a ton of code. I still read every single line of code. That's actually my biggest bottleneck right now, the reviewing of the code. But I thought it would be great to show you kind of the best tips that I've learned along the way. And these are kind of tips that I wish I knew when I was first getting started.

We're going to start off with some foundation stuff like setting up very quick setup stuff, a little bit about like cloud.md rules, like what you should put in, what you should think about, and kind of some of the advanced stuff for later.

So, I got my terminal here. For tip number one, you want to run cloud code in your root directory of whatever project you're working on. You really want to do this because if you have rule files or any kind of setup, the initial root directory is where Claude is going to zip up the context into that first token.

One of the first things that you want to do is run /init. What this does is Claude will go and look at your codebase and do an analysis and then create that initial CLAUDE.md file in the .claude directory. It does take some time. It's kind of going and saying, oh, this is a Next.js 15 app, it's like a portfolio site.

That CLAUDE.md file kind of runs on a hierarchy. There is a checked-in memory which is the current root directory and then there's a user memory, your global one in ~/.claude/CLAUDE.md.

Looking at the CLAUDE.md that Claude just created, it's a pretty good one to get started. You don't want it to be too large. I think around 300 lines is about a decent place that you want to aim for. Every time you increase that initial context window, you're going to use more tokens, but also the more bloat you have in your context, the less likely the AI will do exactly what you're trying to do.

The things I like to put is high-level technical architecture and the requirements, domain context, high-level architecture and the file path, and some of the high-level design patterns. One of the important things is having your build flow, your validation flow. Having this loop of validation is so amazing because the AI will just be able to self-improve and keep going until it fixes itself.

Validation is probably one of the most important topics when you're thinking about trying to build good AI agentic coding systems or any workflows. What is the validation loop? Because that will dramatically improve how good your AI will be.

Keyboard shortcuts: if you're going to be in cloud code all day every day, you should learn the most useful hotkeys. Shift+Tab toggles between accept edits and plan mode. I actually use plan mode quite heavily, almost exclusively whenever I start a new feature. I always just want to verify and double check my assumptions about the codebase.

Escape interrupts. If especially during plan mode, you want to look at the thinking and see if it's going off track. If it is, you just hit escape. Don't be scared to interrupt - Claude Code has a really good way of deduping and entering prompts in a nice queue.

Tip number eight: if you ever had something really big or you copy pasted something, double tap escape and it'll clear the input. On an empty input, double tap escape lets you rewind to a previous point and restore that context point.

Screenshots - you can take a screenshot and drag it over and just drop it in. If you are doing any kind of UI work, you'll definitely use this workflow. I also highly recommend finding a Figma MCP for validation.

/clear is basically a way to clear the context. Really good if you want to start a new feature and you don't want the old context to influence the new project.

/context gives you a visual representation of the current context. This is useful because it gives you an opportunity to reason about the context. I always say context is best served fresh and condensed. MCPs are one of the very common things that blows up your tokens.

/compact takes your current context window and summarizes it. I usually just let the auto-compaction work. The only time I use this is if I want to save some version of my context into my local second brain.

/models is useful. I usually default to Opus, but if you're cost sensitive and you know certain workflows work well in Sonnet, you could change that.

/resume lets you recover your context when you accidentally killed an instance. You don't lose all the work in building up that context window.

/mcp shows the MCPs you have installed. I try very hard to not use MCPs because they blow up your context window. I only install ones needed for that specific project.

Git: you could ask Claude Code to manage your git. I write a lot of my summaries and test plans using Claude Code. I have my own templates so Claude sounds more like me. Use git as a safety net - it's better than the rewind feature.

For the CLAUDE.md, it actually reads top to bottom and keeps the priority from top to bottom. Add things that are "never do something" and "always do this" with clear snippets of examples. Think about how unique your project is - how many things about your project is homegrown that the AI may have never seen.

Whenever you run into something that Claude gets wrong, fix it manually and then update your CLAUDE.md rules so that it never does that mistake again. You shouldn't manually edit the rules - just ask Claude to update them for you.

Using keywords to trigger your skills: I have build commands inside my rules. When I say "use my Xcode MCP to build," it will try to build the app.

Compound engineering: take your CLAUDE.md and start committing it into the codebase. Get rid of anything generic like file paths. Be mindful of how large it becomes - every time someone hits Claude in that directory, it loads that CLAUDE.md.

Dangerously skip permissions: claude --dangerously-skip-permissions. Claude Code will no longer ask you to accept. You only want to do this in environments you can throw away. I've messed up some Linux machines because I was going too aggressive. Use /permissions to keep some safety guards.

For workflows, I always start with plan mode. I'm iterating with Claude Code, arguing with it. I never just purely accept the first answers - I always challenge it. Once Claude Code builds up that context and has good execution specs, the generation of the code is actually the easy part.

You could have multiple Claude instances and then juggle these. I could say "start working on my live activities feature" in one, and "test out this iOS architecture" in another. I could always create another one, go to a different project.

Fresh context beats bloated context. That's why you want to start with plan mode, make sure it's good and then execute. Instead of "try this, try that, try this, try that" which bloats the context and confuses the AI.

Persisting context: the second brain concept. Save to my local CLAUDE.md, then load it next session. I keep todos inside Cloud Code itself. I have a bunch of stuff that I'm tracking, but because I keep all the todos in my local index and I lazy load it, it allows me to context switch from project to project.

Think about the build cycle: you could ask Claude Code to add debug logs, run the app, control the emulator, read the logs, and debug that way. For performance, hook into Perfetto MCPs. For web, use Puppeteer with /chrome. There's so many validation loops you could think of.

Use Opus if you can afford it. Because I have multiple Claude instances running at all times, even if one takes a long time it doesn't matter - I gave the command and go to the next one.

Look out for assumptions or key words like "I'm not really sure." If you see it going and making assumptions, just interrupt it and course correct.

Skills: all a skill is is a workflow. Let's say I tell Claude go fetch Hacker News for latest iOS news, then save a summary to my local directory. That's technically a workflow. You just say "save what we just did into a new skill called fetch-hackernews." Behind the scenes, it's actually just an MD file with a system prompt.

Claude has specific directories that is looking for skills. Commands is basically now interchangeable with skills - a pretty recent change where they combined commands and skills. So now you can do /fetch-hackernews and it'll rerun that system prompt.

Never manually create these kind of stuff. Get in the habit of asking Claude to update and manage these skills.

MCPs: you don't actually need to search the web for an MCP. You could ask Claude to find it and install it for you.

Sub-agents: the main reason to create a sub-agent is for parallel work but also to protect your context window. A lot of people use sub-agents incorrectly - the part that brings back from the sub-agent is only the output, not the full context of how it got there. For work that needs context, keep it within the context window.

What are really good things for sub-agents: things that are atomic in nature that you want to run as side effects. The most common clowny use case is CEO agent, product agent, design agent - I don't believe in that workflow. You want to bring the work to the context rather than spread out the context.

Parallel development: I have multiple Claude instances running at all times. Using iTerm, Command+D creates new instances. Juggle between terminals using Command+left bracket and right bracket. I rename the tabs like "local" and "remote SSH." It really feels like playing Starcraft - switching and talking to it, literally working on multiple projects at the same time. My bottleneck right now is really how much context switching I can do in my head.

Enable notifications - a little sound when it finishes execution. At one point I had text to speech where it reads a summary, but that was too much.

Git worktrees is another way to do multiple code execution. If you have multiple instances, you won't be able to make code edits on the same project unless you use git worktrees. It's a way to clone multiple instances of your codebase with different forking branches.

/chrome is a really cool tool. It opens a browser that you can navigate. You could have it as part of composable commands - a command that goes to Chrome, scrapes stuff, and comes back with the data. It's really good for powerful debugging, navigating the web, and filling out forms.

Hooks and automation: similar to GitHub's pre-hooks and post-commit. These are hooks you can define before executing or after executing. Ask Claude to add these for you. A good example for post tool use: linting and formatting your code. For blocking destructive operations like removing your entire database.

Explore the plugin ecosystem. All a plugin is is a combination of any of these composable things - a skill that triggers an MCP that triggers sub-agents, or maybe a bash script attached to a skill. Anthropic has their own plugins structure with a bunch of plugins you could download.

Context is king. Keep it fresh, keep it relevant. Give Claude the context that it needs and nothing more. Go and build something amazing.

Published in February 2026. Written by Emmanuel Lemal. Report an error