haslanli/glance

Que fait glance ?

Quelqu'un a une réponse pour laquelle il n'a ni le temps ni le contexte. Après un coup d'œil, il devrait savoir ce que cela signifie, quoi faire et ce qui n'est pas encore connu. tldr compresse une réponse pour un lecteur qui en parle déjà la langue ; glance traduit la réponse et la montre.

Commandes

Si les arguments sont help (ou --help, -h, ?), affichez ce bloc exactement et arrêtez-vous :

/glance            re-raconte la dernière réponse en un coup d'œil
/glance <quoi>     re-raconte une réponse, une partie de celle-ci, ou plusieurs : "votre réponse sur la construction",
                   "seulement les chiffres", "tout ce que nous avons fait aujourd'hui", "toutes les décisions jusqu'à présent",
                   ou du texte collé
/glance on         re-raconte la dernière réponse, puis répondez de cette façon jusqu'à /glance off
/glance super      comme on, mais chaque puce est réduite à un fragment
/glance off        retour aux réponses normales
/glance status     indique quel mode est actif
/glance help       affiche ceci

- Chaque nombre, nom, chemin, étape, avertissement et question ouverte est conservé.
- Lorsque la réponse contient des données, elle obtient une image : un graphique, des tuiles, une grille, des cartes ou un tableau remodelé.
- Un mode dure jusqu'à /glance off, dans cette conversation uniquement.
- Dans /btw, les modes ne se reportent pas : dans le terminal, /btw répond une fois et ne conserve rien ; dans l'application de bureau, /btw ouvre un chat latéral, donc un mode défini là-bas reste dans ce chat latéral.

Quelle réponse

• Sans arguments, on ou super : la dernière réponse que Claude a donnée avant cette commande. Pas tout le fil de discussion sauf demande, pas le message de l'utilisateur, pas la sortie brute des outils. Si cette réponse était elle-même un glance, prenez celle d'avant. S'il n'y en a pas, dites-le en une ligne et arrêtez-vous.
• Tous les autres arguments sont une instruction. Lisez-la comme le ferait un collègue : elle peut pointer vers une réponse ("votre réponse sur la migration", "deux messages plus haut"), réduire le périmètre ("seulement les chiffres", "juste les décisions" ; gardez tout à l'intérieur, supprimez tout à l'extérieur), couvrir plusieurs réponses ou toute la session ("tout ce que nous avons fait aujourd'hui", "toutes les décisions jusqu'à présent", "итог всего прогресса"), contenir du texte collé, ou combiner ces éléments. Si deux réponses correspondent, prenez la plus récente et nommez-la en une courte ligne. Si aucune ne correspond, dites-le en une ligne et arrêtez-vous ; ne re-racontez jamais autre chose à la place.
• Demandé dans les propres mots de l'utilisateur plutôt qu'avec /glance ("покажи кратко", "trop long, juste l'essentiel", "où en sommes-nous avec tout ça ?") : lisez la requête comme l'instruction, dans la langue où elle est, et répondez dans cette langue.
• Seule la réponse est une source. Re-racontez ce que dit la réponse choisie, rien des fichiers, sorties d'outils ou données vues plus tôt dans la conversation, même si c'est plus détaillé : si la réponse a fusionné trois services en une ligne, le glance conserve cette ligne.
• Déjà court et simple (quelques lignes qu'un non-expert peut suivre) : retournez-la telle quelle, avec une ligne disant qu'elle est déjà en un coup d'œil.
• En mode : effectuez normalement le travail du tour (outils, vérifications, modifications), puis donnez la réponse sous forme de glance.

Plusieurs réponses ou toute la session

Lorsque l'instruction couvre plus d'une réponse (les progrès jusqu'à présent, un récapitulatif de la session, tout depuis un certain point, chaque décision), re-racontez-les toutes comme un seul glance :

• Sources : chaque réponse que Claude a donnée dans cette période, les décisions que l'utilisateur a énoncées en cours de route, et la liste de tâches que Claude a conservée, s'il y en a une. Ignorez les glances précédents, car ils re-racontent des réponses déjà dans la période. Construisez uniquement à partir de la conversation : ne lisez pas l'historique git, les fichiers ou les traceurs pour combler les lacunes, car le lecteur demande ce qui a été trouvé et fait ici. Si une partie de la période n'est plus dans la conversation (par exemple, les tours précédents ont été condensés en un résumé), utilisez ce qui est là et dites en une ligne ce qu'il couvre.
• Un seul glance, pas un par réponse. La première phrase dit où en sont les choses globalement. Regroupez les puces autour des questions du lecteur sur toute la période (ce qui est fait, ce qui a été décidé, ce qui est encore ouvert, ce qui vient ensuite), étiquetées dans les propres mots de ce contenu. Nommez l'étape à laquelle appartient un fait seulement là où c'est nécessaire pour lui donner un sens.
• Fusionnez, et gardez tout. Un fait que plusieurs réponses répètent apparaît une fois. Chaque nombre, nom, chemin, commande, avertissement et question ouverte de chaque réponse reste présent.
• La réponse ultérieure l'emporte. Lorsqu'une réponse ultérieure met à jour ou contredit une réponse antérieure (une nouvelle mesure, un correctif qui a atterri, une décision inversée), utilisez la version ultérieure et dites-le en quelques mots juste à côté : "/search 280 ms (350 ms avant le correctif de distribution)". Une question ouverte qu'une réponse ultérieure a réglée n'est plus ouverte.
• L'image a toujours au plus trois sections. Donnez-les aux données qui importent le plus sur toute la période, généralement une section par étape qui a des données ; le reste va dans un tableau compact ou les puces.
• La longueur est mesurée par rapport à toutes les sources de réponse ensemble.

Forme d'un glance

Dans cet ordre :

1. La réponse, en mots de tous les jours. Une ou deux phrases courtes, environ 25 mots au maximum, comme vous le diriez à un ami : "Votre facture a plus que doublé à cause de deux changements début octobre." Pas le phrasé original, pas de jargon, pas de métaphores qui nécessitent une explication.
2. L'image, quand il y a des données. Voir ci-dessous.
3. Des puces pour ce que l'image ne montre pas : causes, étapes, décisions, mises en garde, questions ouvertes.
   • Regroupez-les autour des questions du lecteur (pourquoi c'est arrivé, quoi faire, ce qui est encore inconnu, ce qui est attendu d'eux), et étiquetez chaque groupe dans les propres mots de ce contenu ("Deux changements début octobre", "Correctifs, les moins chers d'abord"). Ne réutilisez pas les titres de l'original et n'utilisez pas un ensemble fixe d'étiquettes.
   • Une ligne par puce, deux au maximum, écrites sous forme de phrases courtes plutôt que de phrases complètes (voir Longueur).
   • La première fois qu'un terme arrêterait un non-expert et qu'il en a besoin pour suivre la réponse, ajoutez une explication de 2 à 4 mots entre crochets. N'expliquez pas les mots de tous les jours et limitez-vous à un ou deux par glance.
   • Les commandes, le code, les chemins et le texte d'erreur restent mot pour mot, en formatage de code.

Rien d'autre. La phrase vient avant l'image, les puces viennent juste après, et aucun paragraphe entre les deux ne reformule la réponse ou ne décrit l'image.

L'image

Quand. Chaque fois que la réponse contient des données : des nombres à comparer (entre éléments, groupes ou dans le temps), plusieurs éléments avec les mêmes détails, des valeurs qui ont changé, ou un statut pour chacun des nombreux éléments. Dans ces cas, l'image est la valeur par défaut, pas un supplément. Lorsque la réponse est surtout un raisonnement avec quelques nombres dedans, sautez l'image.

Quoi. Tout ce qui rend ces données lisibles en un coup d'œil. Choisissez en fonction de ce que la réponse dit de ses données, pas de son sujet ou par habitude : deux factures peuvent nécessiter deux images différentes. Lisez la première phrase de la réponse et demandez-vous ce que le lecteur doit voir pour y croire.

• le total est passé de A à B, et la réponse donne les changements qui composent l'écart → un pont dont les étapes s'additionnent exactement
• un élément a causé presque tout le changement → commencez par cet élément comme une tuile (sa part lorsque c'est un calcul arithmétique exact), le reste sous forme de barres
• chaque ligne a des valeurs pour plusieurs périodes, et la façon dont chaque ligne a évolué est importante → un tableau avec une petite tendance en ligne par ligne
• les éléments sont passés d'une valeur à une autre et sont jugés par rapport à un budget, un objectif ou un rival que la réponse donne → lignes avant → après avec le benchmark atténué sous chaque valeur
• problèmes, échecs, pertes ou gaspillages regroupés par cause → une liste de causes : chaque cause avec une barre pour son nombre ou son montant et les éléments affectés en dessous
• 1 à 4 chiffres dont parle la réponse → tuiles de titre (un seul nombre est une tuile, jamais un graphique avec une seule barre)
• une valeur par rapport à sa limite ou son tout (un disque à 92 % plein, un budget à 80 % dépensé), ou plusieurs éléments chacun par rapport à sa propre limite → jauges
• une série sur des périodes ou catégories (jusqu'à 12) → colonnes ; plus de points dans le temps → une ligne
• montants entre éléments → barres sur une échelle, les plus grandes d'abord
• un total divisé en 2 à 6 parties, lorsque la réponse parle de la répartition → une barre divisée au-dessus de la liste des parties ; pour comparer les parties entre elles → barres
• changements qui montent pour certains éléments et descendent pour d'autres, tous dans une seule unité → barres divergentes à partir d'une ligne zéro
• avant → après, ou quelques nombres pour chacun de plusieurs éléments (les unités peuvent différer par ligne) → un tableau avec une colonne alignée par nombre, les lignes à regarder teintées en bleu, et une barre contre la ligne lorsque la réponse donne une cible ou une limite
• un statut pour chaque élément dans chaque paramètre (une matrice de test) → un tableau avec une colonne par paramètre et un mot dans chaque cellule, où seules les cellules en échec deviennent rouges
• options avec les mêmes détails → la comparaison, avec l'option recommandée marquée

Jamais de camembert, jamais de deuxième axe y, jamais plus de deux lignes sur un graphique, et aucune couleur en dehors de la palette du kit : bleu doux, bleu et rouge. Lorsqu'une forme ci-dessus ne peut pas montrer les données honnêtement sur une seule échelle et une seule unité, utilisez le tableau.

Une image d'une à trois sections (par exemple des tuiles, puis le graphique principal, puis une liste). Chaque valeur est imprimée sur l'image, donc rien n'attend derrière un survol ; le kit nomme les deux exceptions (une ligne avec de nombreux points, une tendance en ligne) et leur donne une lecture au survol.

Interactive seulement quand elle le mérite. L'image reste statique à moins que les données aient trop de lignes à prendre en compte à la fois (environ 15 ou plus) ou que la réponse découpe les mêmes lignes de deux manières ou plus (par titre et par langue, par mois et par service). Utilisez alors le tableau interactif du kit (tri, filtres, une boîte de recherche pour les longues listes) ou son commutateur de vue, et respectez ces règles :

• La première vue, avant que quelqu'un ne clique, répond déjà à la question : chaque ligne affichée, triée et marquée comme le serait l'image statique, ou la tranche dont parle la réponse.
• Les contrôles ne montrent les données de l'original que d'une autre manière. Pas de simulations, projections, lignes de tendance, moyennes ou nombres que l'original n'a pas, et aucun contrôle qui modifie ou calcule une valeur.
• Les filtres utilisent les propres catégories et mots de la réponse ("Pertes seulement", "Échec"), jamais un regroupement qu'elle ne fait pas.
• Une vue filtrée indique combien de lignes elle affiche ("12 sur 40 affichées").
• Un tableau avec ses contrôles, jamais plusieurs graphiques câblés ensemble dans un tableau de bord.
• Sans outil visuel, il n'y a rien à cliquer : donnez le tableau complet, trié comme le serait la première vue.

Comment.

• Avec un outil visuel (dans l'application de bureau Claude, y compris son chat latéral /btw, l'outil de visualisation) : appelez read_me avec les modules mockup et data_viz (ajoutez chart uniquement pour un graphique en lignes). Lisez ensuite references/ui-kit.md dans le dossier de cette compétence et construisez l'image à partir de celui-ci : collez exactement son bloc CSS, commencez par le résumé d'une phrase pour lecteur d'écran, utilisez uniquement ses composants et ne les restylez pas. Là où le guide de l'outil et le kit diffèrent, le kit l'emporte. Dessinez avec show_widget. La phrase de réponse est le premier texte de votre réponse, écrite avant d'appeler show_widget (appeler read_me d'abord est correct), afin que le lecteur obtienne la réponse avant l'image ; les puces viennent après.
• Lorsque la réponse explique une facture ou un changement de dépenses, lisez d'abord references/bills.md : il dit ce qu'un tel lecteur a besoin de voir et laquelle des formes ci-dessus convient.
• Sans outil visuel (un terminal, ou /btw dans le terminal) : un tableau markdown, remodelé comme ci-dessous, ou avant → après dans les puces.
• La couleur ne porte de signification que : bleu doux pour chaque marque ordinaire, bleu pour ce qu'il faut regarder, rouge pour ce qui est négatif. Expliquez-le avec des étiquettes directes ou une courte légende.
• Les valeurs et étiquettes vont sur l'image ; les phrases d'explication restent dans la réponse.

Remodelez, et faites-le exactement correct. Ne copiez pas les tableaux de l'original tels quels lorsqu'un remodelage se lit plus rapidement : triez par ce qui compte (généralement le plus grand changement ou l'élément le plus important en premier), marquez les lignes qui comptent, ou transformez le tableau en graphique. Cependant, quel que soit le remodelage, il doit rester correct :

• Mêmes lignes, mêmes valeurs, mêmes unités que l'original. Rien n'est supprimé, fusionné ou arrondi.
• Triez sur une clé qui est dans les données (par exemple le changement en dollars), puis vérifiez l'ordre une fois trié.
• Marquez uniquement ce que l'original soutient : "pire" seulement là où il le dit ou où les chiffres se sont clairement déplacés dans le mauvais sens ; "recommandé" seulement pour ce qu'il recommande.
• Ajoutez un nombre dérivé (une différence, une part) seulement sur l'image, seulement lorsque c'est un calcul arithmétique exact sur les valeurs de l'original et que l'image en a besoin (une étape de pont, la part d'un élément principal) ; étiquetez-le comme calculé. Sinon, n'ajoutez aucun nombre, et jamais un nouveau compte ou une nouvelle comparaison dans les puces.
• Si une valeur dans l'original n'est pas claire, conservez-la exactement comme écrit.

Concevez-le précisément. Le kit s'occupe de l'espacement, des tailles de police, de l'alignement, du mode sombre et des panneaux étroits, donc ne le remplacez pas. Ce qu'il ne peut pas décider pour vous :

• Un seul point de départ. La figure, l'élément ou les lignes dont parle la réponse se démarquent en bleu (hi, ou at pour les lignes de tableau). Tout le reste reste bleu doux et secondaire.
• Même ordre, mêmes noms. Les éléments apparaissent dans le même ordre et sous les mêmes noms dans les tuiles, le graphique, les lignes et les puces.
• Même unité, nombre en premier. Dans une même ligne ou série, écrivez chaque valeur de la même manière ("8 vCPU", "4 vCPU"), avec la même unité, séparateurs et décimales que l'original. Les qualificatifs comme "dédié" vont dans la petite ligne sous la valeur, limitée à environ 20 caractères ; les notes plus longues appartiennent aux puces.
• Faites ressortir les cellules décisives. Au maximum un inconvénient signalé par option, celui que l'original donne comme sa raison, avec quelques mots ("serré avec Postgres", "hors budget"). Marquez l'option recommandée. Le lecteur ne devrait pas avoir à scanner chaque cellule pour voir pourquoi.
• Une ligne par ligne. Utilisez le nom que l'original utilise, gardé court, de sorte que chaque ligne de tableau reste sur une seule ligne et ait la même hauteur. Si un nom a besoin d'explication, expliquez-le dans les puces en mots simples.
• Bleu dit regardez ici ; rouge dit négatif. Le bleu va sur ce dont parle la réponse, même si c'est une mauvaise nouvelle : le service qui a fait grimper la facture est en bleu. Le rouge va seulement sur une valeur qui dépasse une limite donnée par la réponse (une limite, une cible ou un budget) ou qui échoue : son nombre, la partie de sa barre qui dépasse la limite, le nom de l'élément, et le nom de l'élément lui-même. Le rouge ne s'utilise pas ailleurs.

La police est la même partout. Inter, la police du kit, est utilisée dans tout le contenu de la réponse. Les polices de code (monospace) sont pour le code et les chemins.

Où le chercher dans les réponses

Le glance se lit comme une conversation. Il suit le rythme de la réponse originale, sans la répéter. Chaque section de l'image montre une partie différente des données, avec les mêmes catégories, ordre et noms que la réponse. Les puces ajoutent les détails non visuels comme les étapes, les avertissements ou les questions ouvertes.

Résumé

glance est une compétence pour reformater une réponse existante en un format plus court et plus visuel, idéal pour les utilisateurs qui n'ont pas le temps ou le contexte pour la version longue. Elle utilise des commandes comme /glance, /glance on ou /glance super pour s'activer, et /glance off pour revenir à la normale. Toutes les données sont préservées, seules les formulations sont réduites.

Sans outil visuel (terminal), une table markdown suffit ; avec un outil visuel, l'image est dessinée avec show_widget et le kit UI. Ne jamais modifier les valeurs, ne jamais ajouter de données ni supprimer de faits. La réponse est structurée pour être lue rapidement, avec une seule phrase de conclusion au début.