With routines, Claude Code can now work for you at night, independently, on your code, your files and your machine.
Used properly, the routines in Claude Code save valuable time. Launched in mid-April by Anthropic, they allow you to automate repetitive tasks in your workflow. How to set up a routine? What are the best use cases? We take stock.
How to configure a Claude Code routine?
The simplest way to configure a routine is to use Claude’s graphical interface: open it, click on “Code” then on “Routines”. A Claude Code routine consists of a prompt, a trigger and one or more connectors. It runs primarily in the cloud, but can also run locally on your machine, provided that it is turned on. In cloud mode, Claude uses your GitHub repository as a workspace; locally, you will need to indicate a target folder.
Click “New Routine”, then choose “Local” to run on your computer, or “Remote” to run in the cloud. For automatic sorting of folders, choose “Local”; for an automated code review, prefer “Remote”. A graphical configurator then opens: enter the name, description of your routine, and the prompt to use, simple but precise, as you would have formulated it directly in Claude Code.
In cloud mode, you will then need to define the type of trigger: a fixed time during the day, a GitHub event (for example the opening of a PR) or an API call from your application. The usual connectors are available and can be kept or removed depending on your use case. Please note, Claude uses these tools independently, without asking you for confirmation for each action. So be careful not to give it access to sensitive connectors. For example, a routine can scan your emails every morning before you wake up and classify them automatically.
Locally, the principle is identical, with two differences: the only trigger available is the schedule, and the connectors are absent, Claude Code works only with his own tools.
Please note: the creation of routines is limited to 5 per day with a Pro account, 15 with a Max account, and 25 with a Team or Enterprise offer. The tokens consumed are deducted from your usual quota, like any classic use of Claude Code.
Let’s now look at some concrete use cases to get the most out of routines: three scenarios in the cloud, three locally.
In the cloud
A thorough code review every night
This is undoubtedly the most useful use case for a developer: an automated and in-depth code review, coupled with a security audit. Scheduled every night, the routine analyzes the entire code base while the team sleeps and the token usage limit is larger, and submits a Pull Request in the morning with its fixes ranked by criticality.
Quick to use:
“Tu es un expert senior en revue de code et en audit de sécurité applicative, avec une spécialisation en OWASP Top 10, CWE et bonnes pratiques DevSecOps. Ta mission est de réaliser une revue complète de l'ensemble de cette base de code en couvrant trois axes. Premier axe, la qualité du code : lisibilité, complexité cyclomatique, duplication, respect des conventions du langage utilisé, gestion des erreurs, couverture de tests et dette technique. Deuxième axe, la documentation : présence et pertinence des docstrings, commentaires sur la logique métier complexe, README à jour, cohérence entre le code et la documentation existante. Troisième axe, la sécurité : injections (SQL, commandes, XSS), gestion des secrets et variables d'environnement, dépendances vulnérables, authentification et autorisation, validation des entrées utilisateur, exposition de données sensibles dans les logs, configuration CORS, chiffrement des données au repos et en transit. Pour chaque problème identifié, indique le fichier et le numéro de ligne concernés, classe la criticité (critique, élevée, moyenne, faible), explique brièvement le risque ou l'impact, et propose une correction concrète. Une fois l'analyse terminée, applique directement les corrections dans le code en créant une nouvelle branche nommée claude-code/audit-{date}, puis ouvre une Pull Request avec un récapitulatif structuré des modifications, en groupant les changements par catégorie (qualité, documentation, sécurité) et par criticité. Si tu rencontres une partie du code dont tu ne comprends pas l'intention métier, signale-le dans la PR plutôt que d'inventer une correction : il vaut mieux flaguer un faux positif que de casser une logique fonctionnelle.”
Automatic bug fixing
This is probably the most productive use case on a daily basis. Who doesn’t dream of an agent capable of independently handling bug tickets opened on Jira or equivalent? Claude Code can now take care of this: simply connect your ticketing tool via MCP and provide it with clear correction instructions. The agent prioritizes tickets, identifies bugs in the code, applies fixes and opens a PR.
Prompt:
"Tu es un expert senior en debugging et en résolution d'incidents logiciels, avec une solide expérience en analyse de root cause et en correction non régressive. Ta mission est de traiter automatiquement les bugs remontés dans le système de ticketing connecté (Jira, Linear, GitHub Issues ou équivalent selon le connecteur MCP disponible). Commence par récupérer la liste complète des tickets ouverts avec le label bug, incident ou équivalent, et qui ne sont pas déjà assignés ou en cours de traitement par un humain. Identifie ensuite les 5 bugs les plus prioritaires en croisant trois critères : la sévérité déclarée dans le ticket (critique, majeure, mineure), la fraîcheur du report (un bug récent sur une feature en production prime sur un bug ancien sur une feature legacy), et le périmètre fonctionnel touché (un bug qui bloque un parcours utilisateur critique comme l'authentification ou le paiement passe avant un bug d'affichage). Pour chacun de ces 5 bugs, analyse en profondeur le code concerné en remontant la stack trace ou la description du comportement, identifie la root cause précise (pas seulement le symptôme), puis propose une correction qui traite la cause et non le symptôme. Avant d'appliquer la correction, vérifie qu'elle ne casse pas de tests existants et, si la zone de code n'est pas couverte par des tests, ajoute un test unitaire ou d'intégration qui reproduit le bug et valide la correction. Crée une branche par bug, nommée claude-code/fix-{ticket-id}, et soumet une Pull Request distincte pour chaque correction afin de faciliter la revue humaine et le rollback éventuel. Dans chaque PR, structure la description ainsi : référence au ticket d'origine, description du bug observé, root cause identifiée, correction apportée, tests ajoutés ou modifiés, et risques résiduels éventuels. Si un bug semble nécessiter une décision produit (changement de comportement métier, refonte d'une feature, arbitrage UX), ne le corrige pas : ajoute un commentaire détaillé sur le ticket Jira pour expliquer pourquoi une intervention humaine est requise et passe au bug suivant dans la liste de priorité. Ne ferme jamais un ticket toi-même : laisse cette action à l'équipe après validation de la PR.“
Extensive technological monitoring
This is a different kind of use case. Claude Code can carry out targeted technological monitoring of open source projects likely to enrich your application: he analyzes your stack, identifies the relevant tools then tests them directly in an isolated environment. Finally, in the morning, you receive a structured report with a clear recommendation for each project tested.
Prompt:
“Tu es un expert en veille technologique et en évaluation de logiciels open source, avec une double compétence d'architecte logiciel et d'analyste produit. Ta mission se déroule en quatre phases. Phase 1, analyse du contexte : explore la base de code pour identifier le stack technique utilisé (langages, frameworks, librairies principales, base de données, infrastructure), les enjeux fonctionnels de l'application (lis le README, les fichiers de documentation, les noms des modules principaux et les dépendances pour reconstituer le domaine métier), et les points de friction ou les zones où des outils tiers pourraient apporter de la valeur (performances, observabilité, sécurité, DX, automatisation de tests, gestion de la donnée, etc.). Phase 2, veille ciblée : effectue une recherche sur GitHub des projets open source pertinents publiés ou significativement mis à jour au cours des trois derniers mois, en te concentrant sur ceux qui dépassent 500 étoiles ou qui montrent une croissance rapide (plus de 100 étoiles par semaine), et qui sont compatibles avec notre stack identifié en phase 1. Ecarte les projets non maintenus (dernier commit datant de plus de 6 mois), les forks sans valeur ajoutée et les projets dont la licence est incompatible avec un usage commercial (AGPL, SSPL, BSL si tu ne peux pas confirmer la compatibilité avec notre modèle d'usage). Phase 3, sélection et test : choisis entre 3 et 5 projets parmi les plus pertinents, en privilégiant la diversité des cas d'usage couverts plutôt que cinq variantes d'un même outil. Pour chacun, crée un dossier d'évaluation dans un répertoire dédié /tech-watch/{date}/{nom-du-projet}, installe le projet en suivant sa documentation officielle, configure une intégration minimale viable avec un cas d'usage représentatif de notre base de code (sans toucher au code de production : crée un sandbox isolé), et exécute au moins trois scénarios de test couvrant un cas nominal, un cas limite et un cas d'échec. Phase 4, rapport final : rédige un rapport structuré au format Markdown dans /tech-watch/{date}/rapport.md contenant pour chaque projet évalué les éléments suivants : nom et lien GitHub, description en deux phrases, métriques d'adoption (étoiles, contributeurs actifs, fréquence des releases, date du dernier commit), licence et compatibilité avec notre usage, problème que le projet résoudrait dans notre contexte spécifique (cite les fichiers ou modules concernés), résultat des tests réalisés avec captures de logs ou outputs pertinents, effort d'intégration estimé (heures de dev, impact sur le bundle, dépendances ajoutées), risques identifiés (maturité, gouvernance du projet, lock-in, performance), et recommandation finale parmi trois options : adopter rapidement, garder en watch pour réévaluation dans 3 mois, écarter. Termine le rapport par un tableau de synthèse comparatif et un classement des projets par ratio valeur/effort d'intégration. Si aucun projet réellement pertinent n'émerge de ta veille, dis-le explicitement plutôt que de remplir le rapport avec des choix médiocres : un rapport vide et honnête vaut mieux qu'un rapport rempli de bruit.”.
Locally
Automatic sorting of folders and files
It is a transversal case, useful well beyond development. Automatic sorting of your files (downloads, desktop, documents, etc.) allows you to attack each day with a clean and organized session.
Prompt:
“Tu es expert en organisation de fichiers, approche strictement conservatrice : aucune suppression, jamais. Trie les dossiers Téléchargements, Bureau et Documents de cet ordinateur. Archive dans /Archives/{année}/{mois}/ tout fichier non modifié depuis plus de 180 jours. Regroupe les fichiers actifs restants par type dans des sous-dossiers thématiques (PDF, Bureautique, Images, Vidéos, Audio, Code, Installateurs), en réutilisant les dossiers existants au nom proche plutôt que d'en créer en parallèle. Détecte les doublons par hash de contenu, garde la version la mieux rangée, déplace les autres vers /Archives/Doublons/{date}/. Renomme uniquement les fichiers au nom générique (IMG_1234, scan001) si tu peux inférer un nom fiable depuis les métadonnées ou le contexte, sinon laisse tel quel. Ne touche jamais aux dossiers système, cachés, dépôts Git, projets de dev (présence d'un package.json, pyproject.toml, Cargo.toml), ni aux dossiers contenant un fichier .noclaude. Journalise chaque action dans /Archives/journal-tri-{date}.md au format action / source / destination / raison, pour permettre une réversion manuelle. En cas d'erreur bloquante, arrête immédiatement et produis un rapport.”
A weekly cyber audit
At a time when cyber threats are increasing, carrying out a regular security audit on your machine can make the difference between detecting an anomaly in time or discovering it too late. Claude Code can take care of this automatically. Running once a week is reasonable for most uses.
Prompt:
“Tu es expert en audit de sécurité endpoint sur Windows, macOS et Linux. Identifie d'abord l'OS, sa version et le profil d'usage de la machine. Réalise ensuite un audit couvrant huit axes : état des mises à jour (OS, navigateurs, apps critiques), configuration de sécurité native (pare-feu, chiffrement disque, Gatekeeper/Defender), comptes et authentification (admin, politique de mot de passe, 2FA), applications et processus suspects (logiciels non signés, extensions douteuses, lancements automatiques), exposition réseau (ports ouverts, partages, services exposés), données sensibles exposées (fichiers .env, clés SSH sans passphrase, patterns de clés API, permissions trop larges), sauvegardes (présence, fraîcheur, isolation pour résister au ransomware), et traces d'incident (logs de connexion échouées, modifications inhabituelles, outils d'admin à distance). Classe chaque finding en quatre niveaux : critique, élevé, moyen, informationnel. Contraintes absolues : n'exécute aucune commande qui modifierait l'état du système, ne cherche pas à élever tes privilèges si une vérification les requiert (mentionne-le simplement dans le rapport), et ne lis jamais le contenu de fichiers personnels, uniquement leurs métadonnées et permissions. Rédige le rapport dans /Documents/audits-cyber/rapport-{date}.md avec un résumé exécutif et un score de posture sur 100, puis 10 recommandations priorisées indiquant pour chacune : le problème, l'impact, la commande ou procédure exacte de correction, et le temps estimé. Si certaines vérifications n'aboutissent pas, liste-les honnêtement plutôt que de masquer les angles morts.”
Automatic transcription of audio recordings
Do you record meetings or voice notes on your computer, but regularly forget to transcribe them? Claude Code can take care of it. The routine detects new audio files every night and transcribes them via Whisper, with a model adapted to the hardware configuration of your computer.
Prompt:
“Tu es expert en transcription audio automatisée avec Whisper. Identifie d'abord la configuration matérielle de la machine (OS, RAM disponible, présence et type de GPU) afin de choisir un modèle Whisper adapté : tiny ou base pour une machine modeste sans GPU (moins de 8 Go de RAM exploitable), small ou medium pour une configuration standard, large-v3 ou turbo si un GPU dédié avec au moins 8 Go de VRAM est disponible. Privilégie l'implémentation faster-whisper pour ses performances supérieures à OpenAI Whisper en CPU, ou whisper.cpp si l'environnement le permet. Si Whisper n'est pas installé, installe-le via pip dans un environnement virtuel dédié (/.venv-whisper) sans polluer l'environnement système. Scanne le dossier cible {chemin-dossier-audio} et identifie tous les fichiers audio supportés (mp3, wav, m4a, flac, ogg, opus, mp4 pour la piste audio). Pour chacun, détecte automatiquement la langue parlée plutôt que de la présupposer, sauf si un fichier .lang situé à côté du fichier audio force une langue spécifique. Transcris chaque fichier et produis pour chacun un fichier .md du même nom à côté de l'audio, contenant : métadonnées (date du fichier, durée, langue détectée, modèle utilisé), transcription complète avec horodatages toutes les 30 secondes au format [hh:mm:ss], et résumé exécutif en 5 lignes en tête du document. Ne retranscris jamais un fichier qui dispose déjà d'un .md associé daté postérieurement à l'audio (évite le travail en double sur les exécutions successives de la routine). Stocke les transcriptions volumineuses (plus de 30 minutes d'audio) dans un sous-dossier /Transcriptions/ pour ne pas polluer le dossier source. Journalise dans /Transcriptions/journal-{date}.md la liste des fichiers traités, ignorés et échoués avec la raison. Si un fichier échoue (corruption, format non supporté, mémoire insuffisante), passe au suivant plutôt que d'arrêter la routine.”
