Fondations : bien demarrer avec Claude Code
Avant de plonger dans les astuces avancees, il faut poser les bases. Ces premiers tips concernent le setup initial — des choses simples qui evitent beaucoup de frustration ensuite.
Lancer Claude Code depuis la racine du projet
Toujours lancer claude depuis le repertoire racine de votre projet. Claude Code va "zipper" le contexte de ce repertoire dans le premier token — c'est pour ca que vous voyez des tokens utilises meme avant d'avoir tape quoi que ce soit. Si vous avez des fichiers de regles (CLAUDE.md), c'est de la qu'ils seront lus.
Executer /init immediatement
La commande /init analyse votre codebase et cree un fichier CLAUDE.md initial dans le repertoire .claude/. Claude identifie l'architecture (Next.js 15, Swift UI, etc.), les patterns et les dependances. C'est indispensable pour les nouveaux projets.
Comprendre la hierarchie des fichiers de regles
Il existe deux niveaux de CLAUDE.md :
- Projet — dans
.claude/CLAUDE.mddu repertoire courant (regles specifiques au projet) - Global — dans
~/.claude/CLAUDE.md(regles qui s'appliquent a tous vos projets)
La commande /memory permet de visualiser quelles regles sont actives.
Le fichier CLAUDE.md : votre arme secrete
Pour 80% des utilisateurs, un bon CLAUDE.md suffit a obtenir d'excellents resultats sans toucher aux fonctionnalites avancees. C'est le levier le plus puissant.
Garder le fichier compact
Viser environ 300 lignes. Plus le fichier est gros, plus il consomme de tokens et plus l'IA risque d'ignorer certaines instructions. Un fichier concis et precis bat un fichier exhaustif et verbeux.
Que mettre dedans
- Architecture technique — stack, framework, structure de fichiers
- Contexte domaine — Swift UI, Next.js, etc.
- Design patterns — conventions specifiques au projet
- Boucle de build/validation — comment compiler, tester, verifier
La boucle de validation est cruciale
C'est probablement le conseil le plus important de toute la video. Avoir des commandes de build et de validation dans le CLAUDE.md permet a Claude de s'auto-corriger en boucle. Si vous vous demandez pourquoi l'IA ne produit pas du code qui fonctionne du premier coup, c'est souvent parce qu'il manque cette boucle de feedback.
# 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 1Priorite de haut en bas
Le CLAUDE.md est lu de haut en bas, avec une priorite decroissante. Placez les regles les plus importantes en premier. Utilisez des formulations fortes : "Ne JAMAIS faire X" et "TOUJOURS faire Y".
Ajouter des exemples de code
Si votre projet utilise des patterns maison (DSL, conventions internes), ajoutez des snippets concrets. L'IA est entrainee sur du code public — elle ne connait pas vos conventions specifiques. A chaque erreur repetee, mettez a jour le CLAUDE.md pour eviter qu'elle ne se reproduise.
Faire mettre a jour les regles par Claude lui-meme
Ne modifiez jamais le CLAUDE.md manuellement. Demandez a Claude : "Mets a jour les regles pour qu'on ne refasse plus cette erreur." C'est plus rapide et ca garantit la coherence du fichier.
Compound engineering : committer le CLAUDE.md
Une fois votre CLAUDE.md mature, committez-le dans le repo pour que vos collegues en beneficient. Attention : retirez les chemins absolus et les infos personnelles, et gardez le fichier compact — chaque coequipier chargera ce contexte a chaque session.
Raccourcis clavier essentiels
Si vous passez des heures dans Claude Code, ces raccourcis deviennent des reflexes.
Shift+Tab : basculer entre plan et edit
Shift+Tab bascule entre le mode plan (lecture seule, pas de modifications de fichiers) et le mode edit (accepte les modifications). L'auteur utilise le plan mode presque exclusivement au debut de chaque feature.
Escape : interrompre Claude
Si Claude part dans une mauvaise direction, appuyez sur Escape pour l'interrompre. N'ayez pas peur de le faire — Claude Code gere bien la reprise. Vous pouvez appuyer sur Up pour re-editer votre dernier prompt, ou simplement donner une nouvelle instruction.
Double Escape : effacer ou revenir en arriere
- Avec du texte dans l'input — double Escape efface tout le contenu
- Input vide — double Escape permet de revenir en arriere (rewind) a un point precedent de la conversation et restaurer ce contexte
Screenshots : glisser-deposer
Prenez une capture d'ecran et glissez-la directement dans le terminal Claude Code. Indispensable pour le travail UI/UX. Combinez avec un MCP Figma pour des boucles de validation visuelles.
Commandes slash essentielles
/clear — repartir de zero
Efface le contexte actuel. Utile quand vous changez de feature et que l'ancien contexte risque de polluer le nouveau. Equivalent a ouvrir une nouvelle instance Claude.
/context — auditer votre contexte
Affiche une representation visuelle du contexte actuel. Si Claude Code regresse en qualite ou si vos couts explosent, regardez quels elements consomment le plus de tokens. Les MCPs sont souvent les plus gros consommateurs.
/compact — compresser le contexte
Compacte (resume) votre conversation actuelle. Claude Code fait ca automatiquement lors des longues sessions. L'auteur l'utilise rarement, sauf pour sauvegarder un etat dans son "second brain" (voir plus bas).
/models — changer de modele
Permet de basculer entre Opus, Sonnet et Haiku. L'auteur recommande Opus des que possible — la qualite de raisonnement compense largement la latence supplementaire.
/resume — recuperer une session perdue
Si vous fermez accidentellement une instance, /resume restaure le contexte de la session precedente. Un filet de securite pour ne pas perdre un contexte qu'on a mis du temps a construire.
/mcp — gerer les MCPs
Liste les MCPs installes. L'auteur est minimaliste avec les MCPs : il n'installe que ceux strictement necessaires pour le projet en cours, car ils gonflent la fenetre de contexte. Pour certains projets (Xcode, Next.js), ils sont incontournables.
Git comme filet de securite
Utilisez des skills git pour que Claude gere vos commits, summaries et test plans. Le rewind de Claude Code est un dernier recours — git reste plus fiable pour les checkpoints.
Workflows : comment travailler efficacement
Toujours commencer en plan mode
L'auteur ne demarre jamais une feature en mode edit. Il commence toujours en plan mode, itere avec Claude, argumente, challenge les propositions. La generation de code est la partie facile — construire le bon contexte est le vrai travail.
Un contexte frais bat un contexte bloque
"Context is best served fresh and condensed." Evitez les sessions ou vous enchainez "essaie ceci", "non essaie ca", "reviens en arriere". Le contexte se pollue et l'IA se perd. Mieux vaut investir du temps dans la planification initiale et executer proprement.
Persister le contexte : le concept de "second brain"
L'idee : sauvegarder l'etat de votre travail dans un fichier local (par exemple .claude/CLAUDE.md du projet) a la fin d'une session. Au debut de la session suivante, chargez ce contexte a la demande (lazy loading). Ca permet de basculer entre projets sans perdre le fil.
# 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"Tracker ses todos dans Claude Code
Plutot que d'utiliser un outil externe (Asana, Jira), l'auteur garde ses to-dos directement dans son fichier de contexte local, en lazy loading. Ca fonctionne pour des projets personnels ; pour le travail en equipe, utilisez un MCP connecte a votre outil de gestion.
La boucle de build : pensez validation
Au-dela du simple build, pensez aux boucles de validation avancees :
- Debugging — demander a Claude d'ajouter des logs, lancer l'app, lire les logs, debugger
- Performance — brancher un MCP Perfetto, faire un run, lire les traces
- Web — utiliser Puppeteer ou
/chromepour naviguer et valider visuellement - Tests — integration end-to-end, tests unitaires automatiques
Utiliser Opus quand c'est possible
Opus est plus lent mais la qualite de raisonnement est superieure. Comme l'auteur travaille avec plusieurs instances en parallele, la latence n'est pas un probleme — pendant qu'une instance reflechit, il travaille dans une autre.
Interrompre les mauvaises hypotheses
Surveillez les mots-cles dans le "thinking" de Claude : "je ne suis pas sur", "je suppose que". Si vous voyez des hypotheses incorrectes ou des erreurs en cascade, interrompez immediatement avec Escape et corrigez le cap.
Composabilite : skills, MCPs et sub-agents
Claude Code repose sur quatre primitives composables. Comprendre comment elles s'emboitent est la cle pour devenir un power user.
Skills : des workflows recurrents
Un skill est un fichier .md qui definit un workflow reutilisable. Pour en creer un, faites le workflow manuellement une fois, puis dites a Claude : "Sauvegarde ce qu'on vient de faire dans un nouveau skill appele X."
Derriere le rideau, c'est un fichier Markdown avec un system prompt. Claude le detecte automatiquement grace aux repertoires de skills et aux descriptions. Depuis un changement recent d'Anthropic, skills et slash commands sont desormais interchangeables — un skill cree est aussi accessible via /nom-du-skill.
Ne jamais creer les skills manuellement
Prenez l'habitude de demander a Claude de creer et mettre a jour les skills. Par exemple : "Etends le skill fetch-hackernews pour chercher aussi sur Twitter et Apple News." Claude met a jour le fichier .md du skill.
MCPs : avec parcimonie
Astuce : pas besoin de chercher un MCP sur le web. Dites a Claude "Trouve-moi un bon MCP Figma" — et demandez-lui de l'installer aussi. Mais attention : les MCPs gonflent votre contexte. N'installez que ceux indispensables pour le projet en cours.
Sub-agents : pour le travail atomique
Les sub-agents executent des taches en parallele et protegent votre fenetre de contexte. Mais l'auteur met en garde : beaucoup de gens les utilisent mal.
Un sub-agent ne ramene que son output, pas le chemin qu'il a pris pour y arriver. Si une tache a besoin du contexte complet (tests qui doivent connaitre le code, debugging qui necessite l'historique), gardez-la dans la session principale.
Les bons cas d'usage pour les sub-agents :
- Taches atomiques et isolees
- Side effects qui n'ont pas besoin du contexte principal
- Investigations en parallele
Les mauvais cas d'usage : "CEO agent", "product agent", "design agent" — ces roles multi-agents dispersent le contexte au lieu de le concentrer.
Le principe : amener le travail au contexte
Plutot que d'eparpiller le contexte entre plusieurs agents, ramenez le travail vers une fenetre de contexte condensee et fraiche. C'est le principe directeur.
Workflows avances : developper en parallele
Plusieurs instances Claude Code simultanees
C'est le game changer selon l'auteur. Avec iTerm2, il ouvre plusieurs panneaux (Cmd+D) et jongle entre les instances :
- Instance 1 : developpe une feature en plan mode
- Instance 2 : fait une investigation d'architecture
- Instance 3 : travaille sur un autre projet
Navigation rapide entre les panneaux avec Cmd+[ et Cmd+]. Entre les onglets avec Cmd+Shift+[/]. Il compare ca a jouer a Starcraft : donner un ordre a une unite, passer a la suivante, revenir verifier.
Notifications sonores
Activez un son de notification quand Claude termine une execution. Ca permet de savoir quand revenir a un onglet. L'auteur a meme teste du text-to-speech pour resumer le resultat, mais c'etait trop intrusif.
Git worktrees pour le code en parallele
Si vous lancez plusieurs instances sur le meme projet, elles vont entrer en conflit sur les fichiers. La solution : git worktrees, qui permet de cloner plusieurs copies de travail du meme repo avec des branches separees.
/chrome : naviguer le web depuis Claude Code
/chrome ouvre un navigateur que Claude peut controler — prendre des screenshots, cliquer, taper du texte, naviguer. Ideal quand vous n'avez pas d'API mais que vous pouvez acceder au service via le web. Et c'est composable : un skill peut lancer Chrome, scraper des donnees, et revenir avec les resultats.
Hooks : automatiser les actions pre/post execution
Comme les hooks git (pre-commit, post-commit), Claude Code permet de definir des actions avant et apres chaque execution. Cas d'usage typiques :
- Post-execution — linting automatique, formatage du code
- Pre-execution — bloquer les commandes destructrices (
rm -rf, suppressions de base de donnees)
Demandez a Claude de les configurer pour vous — ne les maintenez pas manuellement.
Le mode dangerously-skip-permissions
claude --dangerously-skip-permissions desactive les confirmations. Pratique pour les environnements jetables, mais risque : l'auteur a du reflasher des machines Linux apres des commandes trop agressives. Utilisez /permissions pour garder des gardes-fous sur les operations destructrices.
Plugins : le meilleur des composables
Un plugin est une combinaison de skills, MCPs, sub-agents et scripts bash. Anthropic propose un ecosysteme de plugins telechargeable, et la communaute partage les siens. Explorez ce qui existe avant de reinventer.
Context is king
Le message central de cette video tient en une phrase : donnez a Claude le contexte dont il a besoin, et rien de plus.
- Gardez le contexte frais — commencez en plan mode, validez, puis executez
- Gardez le contexte condense — evitez les MCPs inutiles, compactez, utilisez /clear
- Gardez le contexte pertinent — lazy loading, second brain, skills cibles
Claude Code est un outil de context engineering avec un agent code autour. Toutes les commandes slash, les skills, les sub-agents — tout est la pour gerer cette fenetre de contexte. Maitrisez ca, et vous exploiterez Claude Code a son plein potentiel.
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.
Voir la video originale
Les 50 tips en demo live dans le terminal, avec des exemples concrets sur des projets iOS et Next.js.
Regarder sur YouTube