Contexte de démarrage dynamique
Associe --init à une commande slash comme /blog ou /ship pour charger exactement le bundle de contexte dont ce type de travail a besoin. Sans hooks de setup, sans variables d'env, sans copier-coller.
Arrêtez de configurer. Commencez à construire.
Templates SaaS avec orchestration IA.
Le contexte dont une session a besoin dépend de la tâche. Écrire un article de blog charge la voix de la marque et les workflows SEO. Livrer une fonctionnalité demande les notes d'architecture et le style de code maison. Déboguer nécessite les schémas système et les règles de gestion des erreurs qui s'appliquent.
Tu pourrais tout mettre dans CLAUDE.md et espérer que Claude sache quoi retenir. Ou tu peux donner à chaque type de session le contexte fait pour lui.
La solution simple
Un prompt se place juste après le flag --init dans Claude Code :
claude --init "/blog"
Claude démarre et la commande slash /blog s'exécute immédiatement. Tout ce dont une session blog a besoin vit dans cette commande : règles d'écriture, workflow de contenu, articles exemples, liens internes à suivre.
Zéro hook de setup. Zéro variable d'env. Zéro copie de fichier. Un fichier de commande, qui contient tout le contexte.
Cette page parle de démarrer une session avec le bon bundle, pas de gérer une session surchargée après coup. Si tu essaies de décider ce que Claude doit voir, quand il doit le voir, et ce qui doit rester hors de la fenêtre, lis Context Engineering. Si tu essaies de récupérer une session qui dérive, lis Context Management. Pour les automations à base de hooks, lis Claude Code Hooks.
Quand les hooks de setup sont excessifs
Les hooks de setup sont sortis le 25 janvier 2026. Leur rôle est de mélanger des scripts déterministes avec une supervision agentique : installations de dépendances, initialisation de base de données, tâches de maintenance courantes.
Pour du chargement de contexte par type de session, les hooks de setup ajoutent de la machinerie que tu peux éviter. Une commande slash atteint le même résultat avec moins de pièces mobiles.
| Besoin | Solution |
|---|---|
| Installer des dépendances, lancer des migrations | Setup hooks |
| Charger le contexte pour différents types de travail | Commandes slash |
| Automatisation CI/CD avec comportement déterministe | claude --init-only |
| Onboarding interactif avec questions | Setup hooks + /install true |
Notre implémentation
Voilà la structure qu'on utilise pour les sessions d'écriture de blog :
.claude/
commands/
blog.md # Context embedded in command
justfile # Launcher shortcutsTout ce qu'une session blog demande vit dans blog.md : guide de voix, notes de workflow, instructions de chargement par niveaux, vérifications SEO, règles de liens entre articles.
Le justfile donne le raccourci :
blog:
claude --init "/blog"Tape just blog et Claude démarre avec le contexte blog déjà en mémoire. La voix est définie. Les règles de liens sont définies. Le workflow se déroule tout seul sans que tu aies à rien faire.
Ce qui va dans une commande de contexte
Une commande de session solide couvre quatre bases :
Message de démarrage : Nomme le type de session et confirme que le contexte est chargé.
Documentation du workflow : Chaque étape du processus pour ce type de travail.
Matériel de référence : Chaque règle, exemple et checklist qui s'applique à toute la session.
Critères de qualité : Ce qui doit être vrai avant de considérer le travail terminé.
Le template :
---
description: Start a blog writing session with pre-loaded context
---
# Blog Session
You are starting a blog/content writing session. Report: "Blog session started."
---
## Content Workflow
[Workflow steps and process documentation]
## Brand Voice
[Guidelines and patterns]
## Quality Checklist
[Verification steps before publishing]Tout est inline. Lance la commande et Claude tient déjà chaque pièce.
Plusieurs types de sessions
Une commande par mode de travail :
.claude/commands/
blog.md # Blog writing context
feature.md # Feature development context
debug.md # Debugging context
review.md # Code review contextChacune porte ses propres règles, workflow et références. Changer de mode prend un seul mot :
just blog # Blog writing
just feature # Feature development
just debug # Debugging sessionQuatre commandes de session à copier
Le pattern devient plus utile quand tu arrêtes de penser en abstractions et que tu commences à nommer des types de sessions réels.
Session blog
claude --init "/blog"Charge :
- voix de marque
- règles de liens internes
- checklist SEO / GEO
- workflow de publication
Session feature
claude --init "/feature"Charge :
- notes d'architecture
- standards de code
- attentes de tests
- contraintes de release
Session debug
claude --init "/debug"Charge :
- workflow de débogage
- emplacements des logs
- checklist de reproduction
- règles de sécurité rollback
Session review
claude --init "/review"Charge :
- rubrique de review
- définitions de sévérité
- ce qui compte comme bloquant
- format de sortie attendu
C'est le vrai gain. Tu ne gagnes pas juste des frappes de clavier. Tu fais en sorte que chaque type de session commence avec le bon état d'esprit.
Ce qui va où
Les setups les plus propres séparent le contexte par permanence :
| Couche | Mets ça là |
|---|---|
| CLAUDE.md | Règles et conventions stables à l'échelle du repo |
| Commande de session | Le workflow et les critères qualité pour un mode de travail |
| Skills | Connaissances spécialisées à la demande qui ne doivent se charger que quand c'est déclenché |
| Setup hooks | Préparation déterministe de l'environnement et actions de démarrage |
Cette séparation est ce qui garde le système utilisable. Si tout finit dans CLAUDE.md, chaque session démarre surchargée. Si tout finit dans des hooks, le simple chargement de contexte devient plus lourd que nécessaire.
Le principal anti-pattern
L'erreur courante est d'essayer de résoudre tous les problèmes de contexte avec un seul gros fichier de base.
Ça mène généralement à :
- des fichiers CLAUDE.md surdimensionnés
- des workflows mélangés entassés ensemble
- des instructions non pertinentes qui se chargent pour chaque tâche
- un focus plus faible au démarrage de session
Le contexte de démarrage dynamique règle ça en rendant les règles spécifiques à la session explicites et temporaires. La session blog reçoit les règles blog. La session de débogage reçoit les règles de débogage. Rien d'autre ne vient gratuitement.
Pourquoi ça marche
Quelle que soit la commande que tu passes à --init, elle s'exécute avant que tu aies tapé quoi que ce soit. À ton premier message, le contexte est déjà dans la tête de Claude. Pas d'"ouvre ces fichiers d'abord". Droit dans le travail.
Pour les skills, le même trick charge la bonne configuration de skill tout seul. Pour les overrides CLAUDE.md, tu obtiens des règles spécifiques à la session sans polluer ton fichier de base.
Garde ça simple au début. Le jour où tu as besoin de scripts déterministes, d'automatisation d'installation, ou d'une supervision agentique au démarrage, passe aux setup hooks. D'ici là, une commande slash fait généralement l'affaire. Le Code Kit de ClaudeFast fait tourner exactement ce pattern. Ses commandes /blog, /team-plan et /build tirent chacune du contexte, des workflows et des critères qualité spécifiques à la session via un seul appel --init.
Arrêtez de configurer. Commencez à construire.
Templates SaaS avec orchestration IA.
La mémoire de Claude Code
Configure CLAUDE.md pour que ta stack, tes conventions et ton focus se chargent au démarrage dans le slot haute priorité que Claude suit plus strictement que le chat ou les fichiers récupérés.
Maîtriser CLAUDE.md
Traite CLAUDE.md comme un fichier de contrôle du comportement de Claude, pas comme une introduction au projet. Couvre les workflows opérationnels, la délégation, les règles de contexte et le chargement de skills.