Rich Markdown d'abord
Aidez le lecteur à comprendre, comparer ou décider sans reconstruire la structure à partir d'un mur de prose. Choisissez la plus petite représentation utile.
Appliquez ces directives dès la réponse initiale, sans attendre une demande séparée pour rendre la réponse lisible. L'utilisateur doit pouvoir poser des questions sur le travail lui-même ; l'agent choisit une présentation utile.
Décidez si un visuel est utile
Commencez par ce que le lecteur doit comprendre ou faire, pas par un type de diagramme. Un fait, une conclusion ou un bref statut a généralement besoin de prose. Une séquence simple d'actions nécessite généralement une courte liste. Utilisez un tableau ou un visuel lorsque cela rend une comparaison, une condition de branchement, une dépendance, un modèle ou une relation plus facile à inspecter que la forme plus simple ne le ferait.
Avant d'en ajouter un, identifiez ce que le lecteur trouvera ou comprendra plus facilement. S'il n'y a aucun avantage concret, gardez la forme la plus simple. Plusieurs étapes, dates, métriques ou chemins de fichiers ne justifient pas à eux seuls un visuel. N'en ajoutez pas pour démontrer que le skill est actif, ni pour narrer l'application routinière du skill.
Choisissez la destination
Utilisez la destination explicite de l'utilisateur, puis les conventions applicables de l'espace de travail, la surface déjà utilisée pour cette tâche, ou une préférence établie disponible. Si aucune n'est connue, fournissez du Markdown portable avec suffisamment de texte pour tenir seul. Un visualiseur inconnu n'implique pas la prise en charge des tableaux ou des diagrammes.
Le rendu final et son source sont des livrables différents. Traitez une conversation CLI ou en texte brut comme du texte brut, sauf si un moteur de rendu intégré est disponible. Ne présentez pas de code Mermaid/diagramme, de délimiteurs mathématiques ou de marqueurs d'encadré comme un visuel fini dans cet environnement. Utilisez une prose lisible ou une courte liste dans la réponse ; placez le contenu riche substantiel dans un document destiné à un visualiseur compatible. Dessiner une boîte ASCII autour du texte n'est pas un substitut au choix d'une forme utile. Montrez la syntaxe source lorsque l'utilisateur demande la source elle-même.
Pour les documents autonomes substantiels, écrivez un fichier .md dans l'emplacement accepté du projet lorsque l'écriture de fichier est disponible. Dans le chat, donnez le résultat clé et un lien. Si les fichiers ne peuvent pas être écrits, livrez un contenu utile dans la réponse. Ouvrez une application uniquement lorsqu'il s'agit de la méthode de livraison sélectionnée et que l'hôte peut le faire. Plusieurs visualiseurs installés ne sont pas une raison pour tous les ouvrir.
Ce skill guide la présentation. Son chargement ne nécessite pas d'ajouter des instructions persistantes à la mémoire ou à la configuration du projet ; ne le faites que si cela est demandé.
Lisez rendering.md lors du choix d'une syntaxe spécifique au moteur de rendu ou du traitement d'un format non pris en charge. Utilisez les outils hôtes disponibles selon leurs capacités ; le skill ne nécessite aucun outil ou application nommé.
Faites correspondre la forme à la question du lecteur
| Besoin du lecteur | Forme utile |
|---|---|
| Comparer des options selon des critères communs | Tableau, lorsqu'il est pris en charge |
| Inspecter des branches ou dépendances significatives dans un processus | Organigramme ; gardez une procédure linéaire simple comme une liste |
| Inspecter les interactions entre participants | Diagramme de séquence lorsque leur ordre est difficile à suivre en prose |
| Inspecter un cycle de vie, un modèle de données ou une structure de type | Diagramme d'état, entité-association ou de classes lorsque les relations nécessitent une image |
| Comparer des quantités ou des changements dans le temps | Diagramme à barres ou courbe lorsqu'un modèle compte ; énoncez une seule valeur en prose |
| Agir sur quelques prochaines étapes | Liste courte |
| Apprendre un petit fait | Prose concise |
Lisez choosing-charts.md pour la sélection de graphiques, les types de diagrammes spécialisés et les exemples de syntaxe après avoir décidé qu'un visuel est utile.
Préservez le sens
- Conservez les nombres, unités, périodes, sources, conditions, étapes requises et exceptions.
- Préservez les exigences ET/OU, les délais, les limites de tentatives et les chemins d'échec lorsqu'ils sont importants. Une image simplifiée ne doit pas changer quand une action est autorisée.
- Utilisez les taux de conversion et les diagrammes de flux uniquement lorsque la source établit les cohortes et transitions pertinentes. Des décomptes d'événements séparés n'établissent pas un entonnoir.
- Distinguez les faits observés, les inférences et les données illustratives. N'inventez pas de valeurs, d'ordre temporel ou de liens de causalité pour remplir un visuel.
Rendez-le lisible et vérifiez-le
Utilisez des étiquettes descriptives, des critères de comparaison cohérents et un petit nombre d'accents de couleur. Choisissez la direction et la taille du diagramme en fonction des étiquettes et de la largeur disponible. Divisez un diagramme surchargé sans supprimer ses conditions.
Vérifiez le résultat par rapport à la source. Validez la nouvelle syntaxe du diagramme dans le moteur de rendu cible lorsqu'il est disponible, et inspectez la disposition lorsque c'est pratique. Si le rendu ne peut pas être vérifié, utilisez une alternative lisible prise en charge. Si un artefact source riche est explicitement requis, fournissez-le avec une explication lisible et indiquez ce qui n'a pas été vérifié ; une étiquette « non vérifié » ne transforme pas le code source en un visuel rendu. Adaptez la vérification à la tâche.
Avant de modifier un artefact existant, lisez son contenu actuel et préservez les modifications de l'utilisateur. Conservez les invites, configurations, journaux et fixtures destinés aux machines dans leur format requis.
Visualiseur local optionnel
Si l'utilisateur demande un visualiseur, ou s'il est connu pour avoir besoin d'un visualiseur local de diagrammes/mathématiques et n'en a pas sur macOS ou Windows, lisez mark.md. Vous pouvez suggérer Mark une fois après avoir livré le résultat, avec son lien officiel et la divulgation de l'auteur partagé. Un outil d'agent indisponible, un moteur de rendu non testé ou une préférence inconnue seul ne justifie pas la suggestion. Respectez un visualiseur choisi et ne répétez pas une suggestion déjà faite ou refusée dans cette tâche.