Fondations : bien démarrer avec Claude Code
Avant de plonger dans les astuces avancées, il faut poser les bases. Ces premiers tips concernent le setup initial - des choses simples qui évitent beaucoup de frustration ensuite.
Lancer Claude Code depuis la racine du projet
Toujours lancer claude depuis le répertoire racine de votre projet. Claude Code va "zipper" le contexte de ce répertoire dans le premier token - c'est pour ça que vous voyez des tokens utilisés même avant d'avoir tapé quoi que ce soit. Si vous avez des fichiers de règles (CLAUDE.md), c'est de là qu'ils seront lus.
Exécuter /init immédiatement
La commande /init analyse votre codebase et crée un fichier CLAUDE.md initial dans le répertoire .claude/. Claude identifie l'architecture (Next.js 15, Swift UI, etc.), les patterns et les dépendances. C'est indispensable pour les nouveaux projets.
Comprendre la hiérarchie des fichiers de règles
Il existe deux niveaux de CLAUDE.md :
- Projet - dans
.claude/CLAUDE.mddu répertoire courant (règles spécifiques au projet) - Global - dans
~/.claude/CLAUDE.md(règles qui s'appliquent à tous vos projets)
La commande /memory permet de visualiser quelles règles sont actives.
Le fichier CLAUDE.md : votre arme secrète
Pour 80% des utilisateurs, un bon CLAUDE.md suffit à obtenir d'excellents résultats sans toucher aux fonctionnalités avancées. 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 précis 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 spécifiques au projet
- Boucle de build/validation - comment compiler, tester, vérifier
La boucle de validation est cruciale
C'est probablement le conseil le plus important de toute la vidéo. Avoir des commandes de build et de validation dans le CLAUDE.md permet à 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 1Priorité de haut en bas
Le CLAUDE.md est lu de haut en bas, avec une priorité décroissante. Placez les règles 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 entraînée sur du code public - elle ne connait pas vos conventions spécifiques. À chaque erreur répétée, mettez à jour le CLAUDE.md pour éviter qu'elle ne se reproduise.
Faire mettre à jour les règles par Claude lui-même
Ne modifiez jamais le CLAUDE.md manuellement. Demandez à Claude : "Mets à jour les règles pour qu'on ne refasse plus cette erreur." C'est plus rapide et ça garantit la cohérence du fichier.
Compound engineering : committer le CLAUDE.md
Une fois votre CLAUDE.md mature, committez-le dans le repo pour que vos collègues en bénéficient. Attention : retirez les chemins absolus et les infos personnelles, et gardez le fichier compact - chaque coéquipier chargera ce contexte à chaque session.
Raccourcis clavier essentiels
Si vous passez des heures dans Claude Code, ces raccourcis deviennent des réflexes.
Shift+Tab : basculer entre plan et edit
Shift+Tab bascule entre le mode plan (lecture seule, pas de modifications de fichiers) et le mode édit (accepte les modifications). L'auteur utilise le plan mode presque exclusivement au début 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 géré bien la reprise. Vous pouvez appuyer sur Up pour re-éditer votre dernier prompt, ou simplement donner une nouvelle instruction.
Double Escape : effacer ou revenir en arrière
- Avec du texte dans l'input - double Escape efface tout le contenu
- Input vide - double Escape permet de revenir en arrière (rewind) à un point précédent de la conversation et restaurer ce contexte
Screenshots : glisser-déposer
Prenez une capture d'Ă©cran 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 zéro
Efface le contexte actuel. Utile quand vous changez de feature et que l'ancien contexte risque de polluer le nouveau. Équivalent à ouvrir une nouvelle instance Claude.
/context - auditer votre contexte
Affiche une représentation visuelle du contexte actuel. Si Claude Code régresse en qualité ou si vos coûts explosent, regardez quels éléments consomment le plus de tokens. Les MCPs sont souvent les plus gros consommateurs.
/compact - compresser le contexte
Compacte (résume) votre conversation actuelle. Claude Code fait ça automatiquement lors des longues sessions. L'auteur l'utilise rarement, sauf pour sauvegarder un état dans son "second brain" (voir plus bas).
/models - changer de modele
Permet de basculer entre Opus, Sonnet et Haïku. L'auteur recommandé Opus des que possible - la qualité de raisonnement compense largement la latence supplémentaire.
/resume - récupérer une session perdue
Si vous fermez accidentellement une instance, /resume restaure le contexte de la session précédente. Un filet de sécurité pour ne pas perdre un contexte qu'on a mis du temps à construire.
/mcp - gérer les MCPs
Liste les MCPs installes. L'auteur est minimaliste avec les MCPs : il n'installe que ceux strictement nécessaires pour le projet en cours, car ils gonflent la fenêtre de contexte. Pour certains projets (Xcode, Next.js), ils sont incontournables.
Git comme filet de sécurité
Utilisez des skills git pour que Claude géré 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 démarre jamais une feature en mode édit. Il commence toujours en plan mode, itere avec Claude, argumente, challenge les propositions. La génération 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." Évitez les sessions où vous enchaînez "essaie ceci", "non essaie ça", "reviens en arrière". Le contexte se pollue et l'IA se perd. Mieux vaut investir du temps dans la planification initiale et exécuter proprement.
Persister le contexte : le concept de "second brain"
L'idée : sauvegarder l'état de votre travail dans un fichier local (par exemple .claude/CLAUDE.md du projet) à la fin d'une session. Au début de la session suivante, chargez ce contexte à la demande (lazy loading). Ça 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
Plutôt que d'utiliser un outil externe (Asana, Jira), l'auteur garde ses to-dos directement dans son fichier de contexte local, en lazy loading. Ça fonctionne pour des projets personnels ; pour le travail en équipe, utilisez un MCP connecté à votre outil de gestion.
La boucle de build : pensez validation
Au-delà du simple build, pensez aux boucles de validation avancées :
- Debugging - demander Ă 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 - intégration end-to-end, tests unitaires automatiques
Utiliser Opus quand c'est possible
Opus est plus lent mais la qualité de raisonnement est supérieure. Comme l'auteur travaille avec plusieurs instances en parallèle, la latence n'est pas un problème - pendant qu'une instance réfléchit, il travaille dans une autre.
Interrompre les mauvaises hypothèses
Surveillez les mots-clés dans le "thinking" de Claude : "je ne suis pas sur", "je suppose que". Si vous voyez des hypothèses incorrectes ou des erreurs en cascade, interrompez immédiatement 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 clé pour devenir un power user.
Skills : des workflows récurrents
Un skill est un fichier .md qui définit un workflow réutilisable. Pour en créer un, faites le workflow manuellement une fois, puis dites à Claude : "Sauvegarde ce qu'on vient de faire dans un nouveau skill appelé X."
Derrière le rideau, c'est un fichier Markdown avec un system prompt. Claude le détecte automatiquement grâce aux répertoires de skills et aux descriptions. Depuis un changement récent d'Anthropic, skills et slash commands sont désormais interchangeables - un skill crée est aussi accessible via /nom-du-skill.
Ne jamais créer les skills manuellement
Prenez l'habitude de demander à Claude de créer et mettre à jour les skills. Par exemple : "Étends le skill fetch-hackernews pour chercher aussi sur Twitter et Apple News." Claude met à jour le fichier .md du skill.
MCPs : avec parcimonie
Astuce : pas besoin de chercher un MCP sur le web. Dites Ă 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 exécutent des tâches en parallèle et protègent votre fenêtre de contexte. Mais l'auteur met en garde : beaucoup de gens les utilisent mal.
Un sub-agent ne ramène que son output, pas le chemin qu'il a pris pour y arriver. Si une tâche à besoin du contexte complet (tests qui doivent connaitre le code, debugging qui nécessite l'historique), gardez-la dans la session principale.
Les bons cas d'usage pour les sub-agents :
- Tâches atomiques et isolées
- Side effects qui n'ont pas besoin du contexte principal
- Investigations en parallèle
Les mauvais cas d'usage : "CEO agent", "product agent", "design agent" - ces rĂ´les multi-agents dispersent le contexte au lieu de le concentrer.
Le principe : amener le travail au contexte
Plutôt que d'éparpiller le contexte entre plusieurs agents, ramenez le travail vers une fenêtre de contexte condensée et fraiche. C'est le principe directeur.
Workflows avances : développer en parallèle
Plusieurs instances Claude Code simultanées
C'est le game changer selon l'auteur. Avec iTerm2, il ouvre plusieurs panneaux (Cmd+D) et jongle entre les instances :
- Instance 1 : développe 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 ça à jouer à Starcraft : donner un ordre à une unité, passer à la suivante, revenir vérifier.
Notifications sonores
Activez un son de notification quand Claude termine une exécution. Ça permet de savoir quand revenir à un onglet. L'auteur a même teste du text-to-speech pour résumer le résultat, mais c'était trop intrusif.
Git worktrees pour le code en parallèle
Si vous lancez plusieurs instances sur le même projet, elles vont entrer en conflit sur les fichiers. La solution : git worktrees, qui permet de cloner plusieurs copies de travail du même repo avec des branches séparées.
/chrome : naviguer le web depuis Claude Code
/chrome ouvre un navigateur que Claude peut contrôler - prendre des screenshots, cliquer, taper du texte, naviguer. Idéal quand vous n'avez pas d'API mais que vous pouvez accéder au service via le web. Et c'est composable : un skill peut lancer Chrome, scraper des données, et revenir avec les résultats.
Hooks : automatiser les actions pré/post exécution
Comme les hooks git (pré-commit, post-commit), Claude Code permet de définir des actions avant et après chaque exécution. Cas d'usage typiques :
- Post-exécution - linting automatique, formatage du code
- Pré-exécution - bloquer les commandes destructrices (
rm -rf, suppressions de base de données)
Demandez Ă Claude de les configurer pour vous - ne les maintenez pas manuellement.
Le mode dangerously-skip-permissions
claude --dangerously-skip-permissions désactivé les confirmations. Pratique pour les environnements jetables, mais risque : l'auteur a du reflasher des machines Linux après des commandes trop agressives. Utilisez /permissions pour garder des gardes-fous sur les opérations destructrices.
Plugins : le meilleur des composables
Un plugin est une combinaison de skills, MCPs, sub-agents et scripts bash. Anthropic propose un écosystème de plugins téléchargeable, et la communauté partage les siens. Explorez ce qui existe avant de réinventer.
Context is king
Le message central de cette vidéo tient en une phrase : donnez à Claude le contexte dont il a besoin, et rien de plus.
- Gardez le contexte frais - commencez en plan mode, validez, puis exécutez
- Gardez le contexte condense - Ă©vitez 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 là pour gérer cette fenêtre de contexte. Maitrisez ça, et vous exploiterez Claude Code à 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 vidéo originale
Les 50 tips en démo live dans le terminal, avec des exemples concrets sur des projets iOS et Next.js.
Regarder sur YouTube