task-progress-mod ⚡ : Claude Code, barre IA & résumé outils

Le volume masque le signal

Les tests peuvent sortir des centaines de lignes, dont une grande partie se résume à « tout est passé ». Un diff peut être bruyant si un fichier de verrouillage a changé. Et une sortie JSON peut transporter beaucoup plus d'informations que ce que vous cherchez réellement (par exemple, juste un statut et un total).

Le problème n'est pas seulement de « perdre du temps » à lire. C'est aussi le rythme de la supervision : pour savoir si l'agent avance bien, il faut parfois rouvrir le transcript, retrouver la sortie pertinente, puis revenir à la tâche en cours. Ça paraît léger pour une commande... jusqu'à ce que ça se répète toute la session. Là, le contrôle devient moins fluide.

Une barre de progression répond à une seule partie du problème

La première version de task-progress-mod indiquait où l'agent se trouvait dans la liste de tâches. La version 0.2 garde ça, et ajoute en plus un résumé de la dernière sortie d'outil. Par exemple :

██████░░░░ 60 % · étape 3/5 · Écriture des tests...

Bash · 214 réussis, 2 échoués - test_edge_a a échoué

La barre montre l'avancement « déclaré » dans la liste. La ligne sous la barre donne un indice sur le résultat de la dernière action. Le vrai gain, c'est qu'on a ces deux morceaux d'information au même endroit, au lieu de chercher dans le transcript à chaque fois.

Une compression pensée pour l'humain qui supervise

Quand on parle de « compression », on pense souvent à réduire la sortie envoyée au modèle pour économiser du contexte. Ça se passe dans le pipeline et, en pratique, la personne qui pilote l'agent peut ne même pas le voir.

task-progress-mod vise plutôt l'autre destinataire : vous, quand vous suivez le travail. Le mod garde la sortie complète dans le transcript, mais affiche un résumé directement dans l'interface. Résultat : vous passez moins de temps à repérer ce qui mérite vraiment votre attention.

Et cette nuance change la donne : si votre problème principal est le coût ou la limite de contexte, un mod d'affichage ne règle pas ça à lui seul. Si, au contraire, vous perdez du temps à chercher dans les logs pour comprendre « ce qui vient de se passer », le résumé répond plus directement au besoin.

Un signal rapide sur les écarts

Comme la ligne reprend le résultat du dernier outil, elle peut aussi servir à repérer un décalage. Si l'agent devait écrire des tests, mais que la dernière action résumée ressemble à autre chose, vous pouvez le voir avant même que la tâche suivante se mette à jour.

Ce n'est pas une détection fiable à 100 %. Le mod ne connaît pas forcément l'intention métier complète, et un outil « surprenant » peut être justifié par une étape intermédiaire. Par contre, ça crée un point de friction utile : une action inattendue devient plus visible. Vous décidez ensuite s'il faut inspecter le transcript ou demander une clarification.

Journaux de tests et de compilation

Pour les sorties de tests ou de compilation, le mod cherche surtout des compteurs de réussites et d'échecs, et un détail associé à un échec. Une ligne peut ressembler à :

« 214 réussis, 2 échoués - tests/test_thing.py::test_edge_a a échoué ».

Quand tout est vert, le résumé peut se limiter au nombre de tests réussis.

C'est souvent le cas le plus simple à vérifier : les détails attendus sont généralement visibles clairement dans les logs. Mais les formats varient selon les frameworks, les options de commande et les scripts du projet. Si un outil produit un rapport inhabituel, l'heuristique peut rater un compteur ou retenir un message moins pertinent. Dans tous les cas, gardez la sortie complète sous la main si le résultat influence une décision importante.

Réponses JSON

Pour une sortie JSON volumineuse, le mod cherche à afficher une structure sommaire plutôt que tout le contenu. Par exemple, une réponse avec un statut, un tableau d'environ 300 éléments et un total peut devenir :

{status: "ok", results: [...300 éléments], total: 300}

Ça aide à comprendre la forme et à vérifier des champs « de premier niveau ». En revanche, vous ne voyez pas les éléments masqués dans le tableau. Si vous cherchez une valeur précise, une anomalie, ou un risque lié à des données sensibles, il faudra aller voir la sortie détaillée et, si besoin, remonter à la commande ou au fichier qui l'a produite.

Diffs et modifications de fichiers

Sur les diffs, task-progress-mod peut condenser les changements par fichier, avec le nombre de lignes ajoutées et supprimées. Le bruit venant de fichiers de verrouillage peut aussi être regroupé, pour éviter qu'une mise à jour de dépendances ne prenne toute la ligne.

Un résumé du type :

« 1 fichier - src/index.js (+2/−1) · 1 fichier de verrouillage masqué »

donne rapidement une idée de l'étendue de la modification. Mais ça ne dit pas si le code est bien conçu, si le comportement est correct, ou si une modification générée est acceptable. Le nombre de lignes donne un périmètre, pas une revue de code.

Sorties courtes

Si la sortie est courte, elle est affichée telle quelle sur une ligne. Ça évite de transformer chaque résultat en résumé artificiel. L'étiquette de l'outil reste utile aussi : elle indique d'où vient l'info (Bash ou autre), sans devoir reconstruire tout le contexte.

Dans tous les cas, la règle est la même : utilisez la ligne pour décider où regarder, pas pour conclure que tout est validé.

Vérifier avant de s'y fier

Le dépôt annonce 63 tests de fumée, lancés via :

node tests/test_mod.js

avec un moteur simulé et sans dépendances. C'est un bon point de départ pour vérifier ce qui est couvert par le projet. Mais ça ne remplace pas un essai dans votre environnement : selon les outils utilisés, le format de leurs sorties et la version de Claude Code, les résultats peuvent varier.

Après installation, testez quelques cas représentatifs : une suite de tests réussie, une suite en échec, un diff, et une sortie longue au format JSON.

Le projet est publié sous licence MIT, d'après les informations du dépôt. Comme pour tout code installé dans un environnement de développement, prenez le temps de regarder les fichiers et vérifiez que le mode d'intégration correspond à vos règles internes avant de l'utiliser sur une machine ou un projet sensible.

Ce que le mod ne remplace pas

Il ne remplace ni les logs complets, ni les tests, ni une vérification humaine. Un résumé du type « 214 réussis » ne garantit pas que les tests couvrent bien le comportement attendu. Un diff condensé ne montre pas forcément une erreur de logique. Un statut JSON correct ne prouve pas que le contenu des données est conforme à ce que vous attendez.

Et surtout, ne confondez pas ce mod avec un outil qui réduit nécessairement le contexte transmis au modèle. Son intérêt est d'abord l'affichage et la lisibilité. Si vous voulez savoir si ça « économise » quelque chose, mesurez l'effet séparément plutôt que de supposer qu'il découle de la synthèse à l'écran.

Pour quels workflows est-il pertinent ?

Avant de l'installer, posez-vous trois questions :

• Est-ce que le problème revient souvent ? Si vous ouvrez constamment le transcript pour retrouver les résultats des commandes, un résumé en permanence peut éviter cette interruption.
• Les sorties ont-elles des formes assez prévisibles ? Les tests, diffs et structures JSON ont souvent des motifs reconnaissables. Des outils maison très spécifiques demanderont plus de vérification.
• Le résumé suffit-il pour agir ? Si vous devez auditer chaque résultat en détail, la ligne vous orientera vers le log, c'est tout. Le gain existe, mais il sera plus limité.

En équipe, commencez par un essai court. Comparez le temps passé à superviser une session et le nombre de fois où le résumé a masqué (ou mal représenté) une information utile. Le coût d'installation paraît faible, mais le vrai « coût » d'un outil d'observation, c'est la confiance que vous lui accordez. Le bon réflexe : le traiter comme un tableau de bord, pas comme une source de vérité.