akshay-diwadkar/skills

Créer un diagramme

Construisez un modèle partagé, planifiez le diagramme, puis créez-le via le modèle et les validateurs inclus. Par défaut, utilisez narrative-architecture pour les publics mixtes (parties prenantes, développeurs, gestionnaires) sauf si l'utilisateur demande explicitement exact-code-graph ou executive-concept-map.

Workflow

1. Explorer

   • Inspectez le référentiel avant de poser des questions dont l'environnement peut répondre : documentation, points d'entrée, manifestes, schémas, tests, routes, pipelines, artefacts générés et diagrammes existants.
   • Séparez les faits découverts des inférences lors du résumé de vos constatations.

2. Questionner

   • Lisez question-framework.md.
   • Tenez un registre temporaire des écarts entre la demande et les preuves, et ne posez que des questions qui ne peuvent pas être répondues par l'inspection du référentiel ou le contexte antérieur de l'utilisateur.
   • Posez au maximum trois questions bloquantes liées par tour. Citez la demande et les preuves du référentiel, expliquez pourquoi la réponse modifie le diagramme, présentez deux à quatre options lorsque c'est possible, et recommandez-en une avec ses compromis.
   • Intégrez les réponses, ré-explorez les limites modifiées, et répétez. Ne passez pas à la planification tant que le but, le public, l'emplacement de sortie, les entités, les relations, les omissions, la politique de preuves et le chemin de vérification ne sont pas connus et que le modèle résolu n'est pas explicitement confirmé.

3. Planifier

   • Lisez html-output-guide.md pour la taxonomie des types de nœuds, les types d'arêtes, le schéma des métadonnées et la forme de la charge utile du constructeur.
   • Demandez à l'utilisateur où créer le diagramme HTML avant de proposer le plan final.
   • Acceptez soit un chemin complet .html soit un répertoire. Si l'utilisateur donne un répertoire, générez un nom de fichier descriptif en kebab-case à partir du titre du diagramme.
   • Si le fichier cible résolu existe déjà, demandez avant de l'écraser. Si le répertoire cible n'existe pas, demandez avant de le créer.
   • Traitez l'alignement du modèle, la création du répertoire et la confirmation d'écrasement comme des autorisations séparées ; aucune n'autorise la construction du diagramme.
   • Émettez exactement un <proposed_plan> avant toute création de fichier. Le plan doit inclure le titre, le but, le public, la fidélité, l'emplacement de sortie, les entités, les types de relations, les clusters, les hypothèses, les omissions, la politique de preuves, le comportement de génération de nom de fichier et les étapes de vérification.
   • Indiquez dans le plan que l'implémentation n'a lieu qu'après que l'utilisateur a demandé l'exécution dans un tour non-Plan lorsque le mode de collaboration environnant est le Mode Plan.

4. Construire

   • Construisez uniquement après que le plan soit approuvé et que l'exécution soit autorisée.
   • Créez une charge utile JSON avec les objets de premier niveau diagram et metadata comme décrit dans html-output-guide.md.
   • Préférez la mise en page automatique en omettant les coordonnées x/y des nœuds ; si des positions manuelles sont utilisées, chaque nœud doit inclure à la fois x et y.
   • Exécutez le constructeur inclus avec des chemins ancrés :

     python /chemin/vers/create-diagram/scripts/build_diagram.py --data <payload.json> --output <chemin-vers-sortie.html> --create-dirs --overwrite
     

     Exemple PowerShell : python C:\chemin\vers\create-diagram\scripts\build_diagram.py --data payload.json --output diagram.html Exemple Bash : python /chemin/vers/create-diagram/scripts/build_diagram.py --data payload.json --output diagram.html
   • Le HTML généré est autonome : le constructeur intègre la feuille de style locale et l'exécution RoughJS, de sorte que la sortie peut être ouverte ou servie depuis n'importe quel répertoire sans copier les actifs adjacents.
   • Omettez --create-dirs sauf si l'utilisateur a confirmé la création d'un répertoire de sortie manquant. Omettez --overwrite sauf si l'utilisateur a confirmé le remplacement.

5. Valider

   • Validez le HTML avant de l'ouvrir :

     python /chemin/vers/create-diagram/scripts/validate_diagram.py <chemin-vers-sortie.html>
     

   • Corrigez toutes les erreurs signalées (code de sortie 1) avant de continuer. Les avertissements doivent être examinés mais ne bloquent pas la vérification.

6. Vérifier

   • Ouvrez le fichier HTML dans un navigateur.
   • Confirmez que le panneau d'information s'affiche lorsque des champs de présentation existent, que les formes de nœuds spécifiques aux entités s'affichent, que le texte est lisible à l'ajustement initial, que les arêtes ont des étiquettes, que la légende est visible, que la visite guidée démarre et avance sans changer le zoom, et que le glissement, le panoramique, le zoom, les détails, le glissement de nœud, le thème et la réinitialisation fonctionnent pendant et après la visite.

Règles

• Posez au maximum trois questions étroitement liées par tour. Chacune doit inclure l'écart demande/preuve, pourquoi c'est important, deux à quatre options lorsque c'est possible, votre recommandation, et les compromis.
• N'écrivez, créez, écrasez, sauvegardez ou vérifiez aucun fichier de diagramme lorsque le mode de collaboration environnant est le Mode Plan. En Mode Plan, arrêtez-vous après avoir émis le <proposed_plan>.
• Remettez en question les termes flous : « système », « agent », « pipeline », « orchestrateur », « service » — rendez-les précis.
• Utilisez des scénarios concrets pour tester le modèle, en particulier les chemins d'échec et les transferts.
• Ne mettez pas à jour CONTEXT.md ou les ADR sauf si l'utilisateur le demande explicitement.
• Ne codez pas à la main des SVG autonomes, des toiles de type tableau de bord, des œuvres de diagramme à taille fixe ou des rendus personnalisés pour une sortie normale. Utilisez le modèle HTML partagé et modifiez uniquement DIAGRAMA_DATA plus #agent-metadata.
• Gardez la fidélité par défaut comme narrative-architecture : montrez les acteurs pertinents pour la décision, les systèmes, le flux de données, la propriété, les transferts et les chemins d'échec sans cartographier exhaustivement chaque fichier ou dépendance.
• Utilisez exact-code-graph uniquement lorsque l'utilisateur demande une fidélité d'implémentation réservée aux développeurs. Utilisez executive-concept-map uniquement lorsque le public a besoin de concepts métier, de propriété, de résultats et de risques plus que de détails d'implémentation.