Compétences en diagrammes

DiagramSkills

Transformez une demande de diagramme en un livrable visuel finalisé grâce au moteur de rendu DiagramSpec fourni. Le produit principal est la qualité des diagrammes générés par l'agent : rédigez un JSON maintenable, générez du SVG/HTML et éventuellement du PNG, inspectez le visuel, corrigez la source et renvoyez le résultat. Ne forcez pas l'utilisateur à ouvrir un éditeur pour terminer un travail ordinaire. L'identifiant public de la compétence est $diagram-skills ; la marque visible par l'utilisateur est DiagramSkills.

Flux de livraison par défaut

1. Pour un travail de texte vers diagramme ou une révision substantielle, créez un .brief.json concis à partir de templates/briefs/diagram-brief.json. Il enregistre l'objectif, le récit, le périmètre, la priorisation, l'incertitude, les risques de contenu et les questions de révision, mais pas le raisonnement interne privé.
2. Lisez le profil sélectionné dans references/diagram-thinking-profiles.json, personnalisez au moins trois questions de qualité, et exécutez diagram_brief.py ... --strict avant de dessiner.
3. Pour une vue d'ensemble en couches avec plus de 14 concepts visibles, lisez references/enterprise-board.md et utilisez layout: board. Pour des graphes de relations plus petits, utilisez des nœuds/arêtes.
4. Commencez à partir du modèle correspondant, remplacez son contenu d'exemple et conservez le brief et le JSON source à côté des sorties.
5. Exécutez png-backend avant de demander le PNG, puis exécutez render ... --strict avec --png uniquement lorsqu'un rasteriseur local pris en charge est disponible. Un fichier source seul n'est pas une demande visuelle terminée.
6. Inspectez le SVG généré ou le PNG de 1920 pixels en taille réelle. Vérifiez la hiérarchie, le texte en chinois, la cohérence des icônes, le recadrage, les cartes surchargées, les croisements de lignes et si le récit du brief est visuellement dominant.
7. Répondez à chaque question de qualité du brief avec des preuves concrètes et distinctes, et exécutez diagram_brief.py ... --spec ... --strict --reviewed. Ensuite, liez le brief révisé, la source et le SVG ou PNG inspecté dans le reçu de qualité avec diagram_skills.py review .... Si une vérification échoue, corrigez le brief, la source ou le moteur de rendu et regénérez. Arrêtez après trois cycles de correction fondés sur des preuves ; puis simplifiez ou divisez.
8. Livrez d'abord l'image, puis liez le brief, le SVG/HTML/source/la preuve de qualité. Ne mentionnez l'éditeur navigateur que lorsque l'utilisateur demande une édition manuelle, des importations ou un zoom avant.

Acheminer la demande

1. Lisez references/diagram-thinking.md pour les tâches de texte vers diagramme et les révisions substantielles. N'inventez pas de faits pour rendre une disposition symétrique.
2. Lisez references/prompt-system.md lorsque l'entrée est du texte, incomplète ou doit devenir une invite réutilisable.
3. Sélectionnez exactement un type principal et lisez son guide :
   • architecture système
   • flux d'agent
   • flux de données
   • carte de capacités
   • flux utilisateur
   • topologie système
   • arbre de décision
   • feuille de route
   • carte stratégique
   • flux de processus
4. Lisez uniquement le profil du type sélectionné dans references/diagram-thinking-profiles.json.
5. Lisez references/spec.md lors de la rédaction d'un seul diagramme. Utilisez scripts/diagram_skills.py new pour un démarrage prêt pour la production.
6. Lisez references/enterprise-board.md pour les infographies d'architecture en couches à haute densité, les grilles de sections, les listes latérales, les bandes de processus et les cartes de principes.
7. La compétence installée est le chemin de génération complet. Si une extraction complète du dépôt DiagramSkills est également présente, references/workspaces.md, references/imports.md et references/editor.md décrivent les flux de travail optionnels propres à Studio. Vérifiez que le répertoire editor/ du dépôt existe avant de les proposer ; ne les transformez jamais en condition préalable à la génération.
8. Lisez references/visual-language.md uniquement lors du choix des thèmes, des jetons de marque, de la sémantique des nœuds/arêtes ou du traitement des étiquettes en chinois/anglais.
9. Appliquez references/quality-contract.md. Un fichier généré n'est qu'un candidat tant que la révision du contenu, la validation stricte et la révision visuelle n'ont pas réussi.

Contrat d'entrée

Acceptez le langage naturel ou les champs structurés. Préservez les valeurs fournies par l'utilisateur ; n'inférez que les omissions à faible risque.

• goal : la question ou la décision que le diagramme doit soutenir
• diagram_type : un slug pris en charge ; inférez à partir de l'intention lorsqu'il est omis
• audience : par exemple, direction, produit, ingénierie, client
• narrative / scope : l'histoire en cinq secondes et la limite explicite dedans/dehors
• must_show / emphasize / deemphasize : priorité du contenu avant la disposition
• uncertainties / assumptions : faits non fournis et interprétations à faible risque
• content_risks / quality_questions : façons dont le diagramme pourrait induire en erreur et vérifications après rendu
• content : acteurs, systèmes, étapes, capacités, jalons ou décisions
• relationships : liens de données, contrôle, succès, erreur, asynchrone et retour d'information
• boundaries : propriété, étape du cycle de vie, couche, domaine ou zone de confiance
• composition : board pour les vues d'ensemble d'entreprise à haute densité ; graph pour les diagrammes de relations plus petits
• lanes : propriétaires ou rôles ordonnés pour un diagramme en couloirs
• rank : niveau hiérarchique non négatif explicite lorsque l'ordre automatique n'est pas acceptable
• language : chinois par défaut ; conservez les termes techniques anglais établis
• theme : paper, notion, spectrum, blueprint ou terminal
• brand : jetons de couleur hexadécimaux autorisés superposés à un préréglage
• views : vues d'ensemble et de détail optionnelles du dépôt Studio ; connectez avec child_view
• imports : source Mermaid ou tableau CSV optionnel du dépôt Studio
• outputs : SVG/HTML fini plus JSON source et diagnostics par défaut ; PNG lorsque le rasteriseur local est disponible

Ne demandez que lorsqu'un choix non résolu modifie matériellement le sens, la sécurité de publication ou la sortie requise. Sinon, choisissez la disposition conventionnelle du guide de type et énoncez l'hypothèse.

Commandes

Depuis le dossier de la compétence :

python3 scripts/diagram_brief.py work/architecture.brief.json --strict
python3 scripts/diagram_skills.py types
python3 scripts/diagram_skills.py png-backend
python3 scripts/diagram_skills.py new system-architecture --output work/architecture.json
python3 scripts/diagram_skills.py validate work/architecture.json --strict
python3 scripts/diagram_skills.py render work/architecture.json --output-dir output --strict
python3 scripts/diagram_brief.py work/architecture.brief.json --spec work/architecture.json --strict --reviewed
python3 scripts/diagram_skills.py review work/architecture.json --quality output/architecture.quality.json --brief work/architecture.brief.json --artifact output/architecture.svg

render écrit toujours .svg, .html et un reçu .quality.json lié par hachage ; il écrit également .png lorsque --png est fourni et que png-backend signale un rasteriseur pris en charge. Un rendu structurellement valide reste en-attente-de-révision jusqu'à ce que review vérifie la source, l'artefact inspecté, le brief révisé et leurs hachages. Une demande PNG échouée ne laisse jamais de reçu réussi.

La compétence installée est autonome pour la génération. L'espace de travail navigateur, l'importation Mermaid/CSV et l'édition multi-vues sont des compléments du dépôt et ne sont disponibles qu'à partir d'une extraction complète contenant editor/.

Comportement non négociable

• Construisez et validez le Brief de diagramme concis avant de rédiger un diagramme non trivial. Partagez les décisions de conception et les preuves, jamais le raisonnement interne privé.
• Privilégiez un message principal et une direction de lecture. Divisez les diagrammes en graphe au-dessus de 14 nœuds ; un board d'entreprise structuré peut intentionnellement contenir 20 à 45 cartes concises réparties sur 3 à 6 bandes de balayage.
• Utilisez des lanes ordonnées pour la propriété et le rank des nœuds pour la hiérarchie manuelle. Utilisez des groups pour les enclos sémantiques ; ne faites pas qu'un seul champ signifie les deux.
• Liez les vues d'ensemble denses aux détails child_view ciblés au lieu de réduire les étiquettes.
• Marquez les chemins de retour intentionnels comme feedback ; les cycles non marqués échouent à la validation.
• Utilisez des types d'arêtes sémantiques, pas des couleurs décoratives. Affichez une légende lorsque deux significations d'arête ou plus nécessitent une interprétation.
• Autorisez les liens de nœuds uniquement pour https, http, mailto ou des fragments de page. Les schémas d'URL exécutables sont rejetés.
• Gardez les étiquettes en chinois concises et placez les termes techniques anglais stables dans les sous-titres. Divisez les nœuds surchargés au lieu de réduire le texte.
• Préférez LR pour les pipelines, les feuilles de route, les topologies et les boucles de rétroaction ; préférez TB pour les couches, les décisions, les stratégies et les parcours utilisateur.
• Exécutez la validation stricte du brief et du diagramme. Inspectez le SVG ou le PNG en taille réelle, répondez à chaque question du profil de type avec des preuves distinctes et finalisez le reçu de qualité lié par hachage avec review.
• Ne prétendez pas avoir terminé après avoir écrit du Mermaid/JSON seul lorsque l'utilisateur a demandé un diagramme. Générez et renvoyez le visuel réel.
• Conservez le .brief.json et le JSON source à côté des livrables afin que le sens et les pixels restent reproductibles et révisables.
• Lorsqu'une extraction complète du dépôt fournit des importations Studio, traitez le contenu importé comme non fiable. Mermaid s'affiche en mode strict, le CSV devient des champs typés, et tout CSS arbitraire ou lien exécutable est rejeté.

Choix de sortie

• PNG : aperçu préféré lorsque png-backend signale un rasteriseur local pris en charge ; sinon, montrez le SVG en premier.
• Diagram Brief JSON : intention du contenu, périmètre, incertitude, priorisation, risques et preuves de révision.
• SVG : documentation évolutive et contrôle de source.
• HTML : visualisation réactive, panoramique/zoom, changement de thème, téléchargements et nœuds cliquables.
• Quality JSON : preuves de validation lisibles par machine.
• Workspace JSON : format optionnel du dépôt Studio pour l'édition dans le navigateur, les vues mixtes Mermaid/natives, la persistance hors ligne et le zoom avant.

Extension

Ajoutez un nouveau type de diagramme uniquement lorsqu'il possède un modèle d'information ou un contrat de disposition distinct. Ajoutez son slug à DIAGRAM_TYPES, à l'énumération du schéma, à templates/<slug>.json, à references/diagram-types/<slug>.md et à references/diagram-thinking-profiles.json ; puis ajoutez des tests de rendu strict et de profil de réflexion. Étendez les mappages CSV dans un adaptateur et les champs d'espace de travail dans Zod et JSON Schema. Les nouveaux thèmes doivent préserver la sémantique des nœuds et des arêtes dans le rendu clair et sombre.