Chapitre 10.4 — Output styles, statusline & settings
⏱️ TL;DR — Les finitions d’expérience. Un output style change la façon de répondre de l’agent (ton, format) sans toucher à ses capacités — utile pour un mode « pédagogique » ou un style perso (tu en connais un :
caveman, côté skill). La statusline personnalise la barre d’état. Etsettings.jsoncentralise le tout (modèle, permissions, hooks, env), à trois niveaux (user / projet / local). On fait le tour, plus la skillfewer-permission-promptspour réduire le bruit des confirmations.
🎯 Objectifs
- Comprendre ce qu’est un output style (et ce que ce n’est pas).
- Personnaliser la statusline.
- Cartographier
settings.jsonet sa hiérarchie. - Réduire les confirmations avec
fewer-permission-prompts.
Output styles : changer le ton, pas les capacités
Un output style modifie comment l’agent répond : plus explicatif, plus concis, orienté apprentissage… sans changer ce qu’il sait faire. La marketplace propose par exemple des styles explanatory (il explique ses choix) et learning (orienté pédagogie). Tu peux aussi en définir un perso.
À ne pas confondre :
| Output style | Skill de communication (ex. caveman) | Thème (theme.css) | |
|---|---|---|---|
| Change | le style de réponse (réglage) | le style, via une capacité activable | l’apparence visuelle du rendu |
| Nature | réglage de sortie | skill | CSS |
caveman (ta skill) atteint un but proche (réponses ultra-compressées) mais par le mécanisme skill. Un output style est un réglage global de la façon de répondre. Choisis selon que tu veux un style toujours actif (output style) ou activable à la demande (skill).
💡 Réflexe d’architecte — Un output style « explicatif » est excellent en apprentissage (tu veux comprendre ce que fait l’agent) ; un style concis est meilleur en production (tu veux avancer). Adapte le style à ton mode du moment, comme tu adaptes le modèle (fort/rapide, 1.2). Le style est un curseur d’expérience, pas un gadget.
La statusline
La statusline est la barre d’info en bas de la session. Tu peux la personnaliser (afficher le modèle courant, la branche git, le coût, le contexte restant…) via un script, ou avec l’aide d’une skill dédiée (statusline-setup). Utile pour garder sous les yeux ce qui compte pour toi (par ex. le contexte restant, pour anticiper une compaction — 5.2).
settings.json : la carte
On a croisé settings.json tout au long du playbook (permissions en P5, hooks en P7). Récapitulons ce qu’il centralise et sa hiérarchie :
Ce qu’on y règle (rappel + reste) :
- model / effort / fast — quel modèle, quel niveau d’effort.
- permissions — allow/deny, defaultMode (P5).
- hooks — les automatismes (P7).
- env — variables d’environnement pour les commandes.
- statusline, tui, plugins activés…
La hiérarchie suit la même logique que le CLAUDE.md (3.1) : ta config perso (user), la config partagée du repo (projet, versionnée), et tes réglages locaux (local, non versionné — pour ce qui est propre à ta machine). Range chaque réglage à son niveau : un hook de qualité d’équipe → projet ; ta préférence de modèle → user ; un port de dev perso → local.
⚠️ Piège — Mettre un réglage d’équipe au niveau user (il ne profite qu’à toi) ou un réglage perso au niveau projet versionné (il s’impose à tous). Comme pour le
CLAUDE.md, le mauvais niveau crée du bruit ou des surprises. Règle : partagé → projet, personnel transverse → user, personnel au repo → local.
Réduire les confirmations : fewer-permission-prompts
Si tu passes ton temps à confirmer des commandes sûres (rappel 5.3), la skill fewer-permission-prompts scanne tes transcripts pour repérer les commandes read-only fréquentes et te propose une allow-list prête à coller dans .claude/settings.json. C’est l’outillage de « construire son allow-list empiriquement » (5.3) : au lieu de deviner, tu pars de ce que tu confirmes réellement tout le temps.
🧭 Sur TaskFlow — Pour TaskFlow, on garderait un
settings.jsonde projet propre (hooks de qualité P7, allow/deny raisonnables), et chacun ses réglages user (modèle, style). On lanceraitfewer-permission-promptsaprès quelques sessions pour affiner l’allow-list sur les commandes qu’on confirme vraiment (npm test,git diff…). Config d’équipe partagée, confort perso au bon niveau.
✏️ Exercices
Exercice 1 — Style selon le mode. Essaie un output style explanatory sur une tâche d’apprentissage, puis reviens à ton style habituel pour produire. Lequel te convient dans quel contexte ?
✅ Solution
En apprentissage, l’explicatif t’aide à comprendre les choix de l’agent (précieux pour monter en niveau — Partie 12). En production, un style concis te fait avancer. Comme le modèle, le style s’adapte au mode : apprendre vs produire.
Exercice 2 — Allow-list empirique. Lance fewer-permission-prompts. Regarde l’allow-list proposée : reconnais-tu les commandes que tu confirmes sans cesse ? Applique-la et mesure la baisse d’interruptions.
✅ Solution
La proposition reflète tes vraies habitudes (souvent npm test, git status/diff, npm run lint). L’appliquer supprime le bruit sur l’anodin sans toucher aux garde-fous (deny). C’est « l’autonomie se gagne » (5.3) outillée : tu élargis sur du sûr, sur des bases empiriques.
🧠 Quiz de révision
1. Qu’est-ce qu’un output style change (et ne change pas) ?
Il change la façon de répondre (ton, format) — pas les capacités de l’agent. Ex. un style explanatory ou learning. À distinguer d’une skill de communication (caveman) et d’un thème visuel.
2. Output style ou skill : quand l’un plutôt que l’autre ?
Output style pour un style toujours actif (réglage global) ; skill (ex. caveman) pour un style activable à la demande. Selon que tu veux un réglage permanent ou ponctuel.
3. Quels sont les trois niveaux de settings.json ?
settings.json ?User (~/.claude/, toi partout), projet (.claude/, versionné/équipe), local (.claude/settings.local.json, perso au repo, non versionné). Même logique de portée que le CLAUDE.md.
4. Où mettre un hook de qualité d’équipe ? une préférence de modèle perso ?
Le hook d’équipe → niveau projet (versionné, partagé). La préférence de modèle → niveau user (transverse à toi). Un port de dev propre à ta machine → local.
5. Que fait fewer-permission-prompts ?
fewer-permission-prompts ?Elle scanne tes transcripts, repère les commandes read-only fréquentes, et propose une allow-list à coller dans settings.json — pour réduire les confirmations sur du sûr, sur des bases empiriques (5.3).
Chapitre suivant : Atelier — connecter TaskFlow — GitHub, navigateur, et une commande, en pratique.