Context Guard -- Economie de tokens

Le contexte est une ressource finie (200k tokens). Les tool outputs representent ~84% de l'usage. Chaque Read, chaque Bash consomme du budget. Ce skill guide l'economie a chaque etape.

Regles permanentes

1. Ne pas relire ce qui est deja en contexte

• CLAUDE.md est charge automatiquement comme instructions projet -- ne JAMAIS le relire avec Read
• Un fichier lu dans cette conversation est deja en memoire -- ne pas le relire sauf si modifie entre-temps
• Avant un Read, se demander : "J'ai deja cette info ?"

2. Grep cible au lieu de Read entier

Besoin	Mauvais (tokens++)	Bon (tokens--)
Trouver une version	Read CHANGELOG.md (260 lignes)	Grep "## \\[" CHANGELOG.md (10 lignes)
Verifier une config	Read package.json (100 lignes)	Grep "version|name" package.json (2 lignes)
Chercher un pattern	Read fichier.ts (500 lignes)	Grep "functionName" fichier.ts (5 lignes)
Localiser un fichier	Read de plusieurs fichiers	Glob "**/*.test.ts" (liste de chemins)

Regle : si tu as besoin de < 20% du fichier, utilise Grep. Read entier seulement si tu as besoin de comprendre la structure complete.

3. Bash optionnels : toujours ; exit 0

Un Bash qui echoue dans un batch parallele annule TOUS les autres appels du batch (cascade).

# MAL -- si gh absent, cascade sur tout le batch
gh issue list --limit 5

# BIEN -- jamais d'erreur, resultat vide si echec
gh issue list --limit 5 2>/dev/null; exit 0

Regle : toute commande qui peut echouer (reseau, outil optionnel, fichier absent) → 2>/dev/null; exit 0.

4. Read sur fichier optionnel : jamais en parallele

# MAL -- si .continue-here.md absent, cascade
Read(TODO.md) + Read(.continue-here.md) + Bash(git status)

# BIEN -- fichier optionnel via Bash
Read(TODO.md) + Bash(cat .continue-here.md 2>/dev/null; exit 0) + Bash(git status)

Regle : Read uniquement sur les fichiers qui existent a coup sur. Fichier incertain → Bash(cat ... 2>/dev/null; exit 0) ou Glob d'abord.

5. Paralleliser au maximum, sequentialiser au minimum

• Appels independants → un seul batch parallele
• Resultats necessaires pour la suite → batch sequentiel
• Objectif : 2 rounds max (collecter → ecrire), pas 4+

Seuil 70% -- mode economie

Quand le contexte depasse ~140k tokens (70% de 200k), appliquer des mesures plus agressives :

Action	Normal	Mode economie (>70%)
Explorer du code	Read fichiers	Subagent Explore (contexte isole)
Recherche large	Grep + Read	Agent en fond (resultat resume)
Fichier > 200 lignes	Read entier	Read avec offset/limit sur la zone cible
Plan d'implementation	Texte en conversation	Ecrire dans plans/ (hors contexte)

Subagents pour les explorations

Les subagents ont leur propre contexte isole. Utiliser un Agent pour :

• Explorer un codebase large (> 5 fichiers a lire)
• Rechercher des patterns dans beaucoup de fichiers
• Lire de la documentation longue (CHANGELOG, README externes)
• Toute tache qui genererait > 10k tokens de tool output

Le subagent renvoie un resume compact → economie nette.

Write strategy -- sauver en externe plutot qu'en contexte

Quand une analyse, recherche ou exploration produit un resultat volumineux (> 5k tokens) qui sera reutilise plus tard :

• Ecrire dans un fichier temporaire (plans/, notes/, ou /tmp) plutot que garder en contexte
• Le fichier peut etre relu cible (Grep, Read avec offset) quand necessaire
• Exemples : resultats d'audit, analyse de codebase, plan d'implementation, comparaison d'options

Regle : si le resultat ne sert pas dans les 2-3 prochains messages, le sortir du contexte.

Observation masking -- elider les outputs anciens

Les tool outputs (Read, Bash, Grep) representent ~84% du contexte consomme. Apres 3+ tours, un output verbeux n'est plus utile tel quel.

Strategie :

• Tour courant : output complet, jamais masque
• Tour precedent : output conserve (souvent reference)
• 3+ tours : l'essentiel a deja ete exploite -- ne pas relire, se fier aux decisions prises

Ne jamais elider :

• Erreurs en cours de debug (garder le detail tant que le bug n'est pas resolu)
• Fichiers activement modifies (besoin du contenu exact)
• Decisions et leurs raisons (le "pourquoi" survit mieux que le "quoi")

Regle : si tu as besoin d'info d'un output ancien, c'est un Grep cible sur le fichier source -- pas une relecture de l'output en contexte.

Placement strategique des infos

Le modele accorde plus d'attention au debut et a la fin du contexte (effet "lost-in-middle"). En pratique :

• Instructions critiques (STOP, regles absolues) → en haut du prompt
• Exemples, details → au milieu (OK si moins d'attention)
• Rappels, actions finales → en fin de prompt

Commandes lean -- reduire le bruit a la source

Les sorties de commandes representent une part massive des tokens consommes. Utiliser les versions compactes par defaut.

Git

Besoin	Verbeux (tokens++)	Lean (tokens--)
Etat du repo	git status	git status -s
Changements	git diff	git diff --stat d'abord, puis git diff [fichier] cible
Historique	git log	git log --oneline -20
Dernier commit	git log -1	git log --oneline -1
Branches	git branch -a	git branch --list (locales)
Diff d'une PR	git diff main...HEAD	git diff --stat main...HEAD d'abord

Package managers

Besoin	Verbeux (tokens++)	Lean (tokens--)
Installer deps	npm install	npm install --silent
Installer deps	pnpm install	pnpm install --silent
Installer deps	pip install -r req.txt	pip install -q -r req.txt
Installer deps	composer install	composer install -q
Audit	npm audit	npm audit --json | node -e "..." (parser les criticals)

Tests

Besoin	Verbeux (tokens++)	Lean (tokens--)
Lancer les tests	pytest	pytest -q --tb=short
Lancer les tests	vitest run	vitest run --reporter=dot
Lancer les tests	go test ./...	go test -short ./...
Lancer les tests	phpunit	phpunit --no-progress --compact
Un seul test	pytest tests/	pytest tests/test_x.py::test_name -q

Build et lint

Besoin	Verbeux (tokens++)	Lean (tokens--)
Build	npm run build	npm run build --silent
TypeScript	tsc	tsc --noEmit --pretty false
ESLint	eslint .	eslint . --format compact
Prettier check	prettier --check .	prettier --check . --log-level warn

Conteneurs et infra

Besoin	Verbeux (tokens++)	Lean (tokens--)
Containers	docker ps	docker ps --format "table {{.Names}}\t{{.Status}}"
Images	docker images	docker images --format "{{.Repository}}:{{.Tag}}\t{{.Size}}"
Pods	kubectl get pods	kubectl get pods --no-headers
Logs	docker logs [id]	docker logs --tail 50 [id]

Troncature de securite

Pour toute commande susceptible de produire une sortie longue (> 100 lignes) :

• | head -100 pour les debuts
• | tail -50 pour les fins (logs, erreurs)
• 2>&1 | head -100 pour capturer stderr aussi

Regle : si la sortie depasse 100 lignes, il y a probablement une version lean de la commande. La chercher avant de tronquer.

Anti-patterns

Anti-pattern	Impact	Alternative
Lire CLAUDE.md avec Read	+5-10k tokens gaspilles	Deja en contexte
Read entier pour chercher un mot	+2-8k tokens	Grep cible
Bash sans ; exit 0 en parallele	Cascade = tous les appels annules	Toujours ; exit 0
Read sur fichier peut-etre absent	Cascade si absent	Bash cat ou Glob
Tout faire en conversation principale	Contexte sature en 15min	Subagents pour les taches lourdes
Relire un fichier deja lu	Doublon pur	Se fier au contexte existant
4+ rounds sequentiels	Lent + tokens	Tout paralleliser en 2 rounds
git status sans -s	+500 tokens de bruit	git status -s
git diff complet d'emblee	+2-10k tokens	git diff --stat d'abord, cibler ensuite
npm install sans --silent	+200 lignes de logs	npm install --silent
pytest sans -q	+300 lignes de dots	pytest -q --tb=short
Commande a sortie longue sans troncature	Contexte sature	| head -100 ou version lean

Ce skill ne fait PAS

• Ne bloque pas le travail -- signale et guide
• Ne force pas les subagents -- les recommande quand pertinent
• Ne s'applique pas aux conversations courtes sans outil